AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 29.04.2009, 17:14   #1  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,427 / 1771 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Баг на форме "Проводки по сопоставлению"
Наткнулся на баг на форме CustVendTransPostingLog_RU (Проводки по сопоставлению).
Видимо для того чтобы была возможность переходить к проводкам по сопоставлению с обоих сопоставленных проводок, авторы отказались
X++:
this.query().dataSourceTable(tablenum(CustVendTransPostingLog_RU)).clearDynalinks();
от стандартного поведения Dynalink и запрограммировали собственное
X++:
public void linkActive()
{
    transRecIdRange.value(strfmt('(' +
                          new DictField(tablenum(CustVendTransPostingLog_RU),
                                        fieldnum(CustVendTransPostingLog_RU, TransRecId)).name() +
                          ' == %1' + ')' + ' || ' +
                          '(' +
                          new DictField(tablenum(CustVendTransPostingLog_RU),
                                        fieldnum(CustVendTransPostingLog_RU, OffSetRecId)).name() +
                          ' == %1' + ')',
                          custVendTrans.RecId));

    super();
}
Но т.к. эта форма общая и для поставщиков и для клиентов, связь с проводками должна происходить не только по RecId, но и по TableId. Предлагаю пофиксить эту багу следующим образом:
X++:
public void linkActive()
{

    transRecIdRange.value(strfmt('(((' +
                          new DictField(tablenum(CustVendTransPostingLog_RU),
                                        fieldnum(CustVendTransPostingLog_RU, TransRecId)).name() +
                          ' == %1' + ')' + ' || ' +
                          '(' +
                          new DictField(tablenum(CustVendTransPostingLog_RU),
                                        fieldnum(CustVendTransPostingLog_RU, OffSetRecId)).name() +
                          ' == %1' + '))' + ' && ' +
                          '(' +
                          new DictField(tablenum(CustVendTransPostingLog_RU),
                                        fieldnum(CustVendTransPostingLog_RU, RefTableId)).name() +
                          ' == %2' + '))',
                          custVendTrans.RecId,
                          custVendTrans.TableId)); // <--

    super();
}
Старый 29.04.2009, 17:36   #2  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Вечно в *_RU какие-то извращения...
Старый 29.04.2009, 17:43   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
на мой субъективный взгляд - таблица custVendTransPostingLog_ru - сама по себе одна большая ошибка
Старый 29.04.2009, 18:19   #4  
SEKL is offline
SEKL
Участник
Сотрудники Microsoft Dynamics
 
48 / 27 (1) +++
Регистрация: 15.08.2007
Адрес: Denmark
В текущей версии ситуация следующая:

refTableIdRange.value(queryValue(custVendTrans.TableId));

Почему CustVendTransPostingLog_RU считается ошибкой не очень понял
Старый 29.04.2009, 18:21   #5  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
А для какой Аксапты вы это делали ?
Если трешка, то там и так сработает - там RecId уникальный в пределах компании, так что достаточно ссылки по recId.
Старый 29.04.2009, 18:27   #6  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от SEKL Посмотреть сообщение
В текущей версии ситуация следующая:

refTableIdRange.value(queryValue(custVendTrans.TableId));

Почему CustVendTransPostingLog_RU считается ошибкой не очень понял
"Текущая" это какая ?
Ax 4.0 ?
или 2009 ?
Старый 29.04.2009, 18:30   #7  
DSPIC is offline
DSPIC
Боец
 
1,077 / 1234 (44) ++++++++
Регистрация: 11.04.2008
Цитата:
Сообщение от Logger Посмотреть сообщение
А для какой Аксапты вы это делали ?
Если трешка, то там и так сработает - там RecId уникальный в пределах компании, так что достаточно ссылки по recId.
Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома
Старый 29.04.2009, 18:31   #8  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома
Согласен.
Но тем не менее в 3-ке указанный функционал срабатывал корректно.
Старый 29.04.2009, 18:34   #9  
kashperuk is offline
kashperuk
Участник
Аватар для kashperuk
MCBMSS
Соотечественники
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,361 / 2084 (78) +++++++++
Регистрация: 30.05.2004
Адрес: Atlanta, GA, USA
Цитата:
Сообщение от DSPIC Посмотреть сообщение
Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома
Я бы не ставил это в один ряд с аксиомой.
Никогда не знаешь, что может измениться в следующих версиях
Старый 29.04.2009, 18:36   #10  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от SEKL Посмотреть сообщение
Почему CustVendTransPostingLog_RU считается ошибкой не очень понял
А ты можешь в двух словах сформулировать - какой смысл в этой таблице ? Насколько я помню, ее завели в 2.5sp2 чтобы хранить информацию о проводках сделанных по сопоставлению (чтобы потом легче откатывать было). НО: В западной версии проводки по сопоставлению откатываются без всяких логов сопоставления - просто за счет данных о профилях в исходных записях custVendTrans/custvendSettlement/taxTrans и тп.
Можно было вычислять эти данные и без создания таблицы во первых, во вторых - вариант тупо пробежаться по логу и отсторнировать проводки по ГК все равно не работает - приходится при сторнировании очередной записи в settlement или trans, искать что-то в этом странном логе.
Дальше - хуже. При реализации оплаченного НДС в версии 2.5sp5 (кажется) туда еще засунули налоговый код и начали данные из этой таблицы использовать для каких-то рассчетов по зачету НДС по книжкам. И теперь схему зачета НДС по оплате фактически отменили - а таблица продолжает жить.

Получается, что если эта таблица является чисто информационным логом для изучения пользователем - то непонятно:
  1. почему ее не чистят, время от времени,раз это не транзакционная таблица, а просто лог;
  2. Непонятно почему данные оттуда берут для каких-то рассчетов или для принятия решения о ветвлении программной логики.
Если же это транзакционная таблица с полезными данными, то:
  1. Получается что она по большому счету в значительной степени дублирует информацию custVendSettlement, taxTrans,custVendTrans,ledgerTrans и тп.
  2. Получается что она в общем не особо хорошо нормализована (хотя я не фанат нормализации ради нормализации) и в ней есть куча полей, заведенных ради какой-то конкретной ситуации; Даже если эту информацию действительно надо было хранить ради каких-то ситуаций с требованиями российского бухучета, то правильнее было бы добавлять новые поля в таблицы сопоставлений, проводок, налогов и так далее;
  3. Не понятно почему из транзакционной таблицы данные время от времени удаляются (например если мы отменяем сопоставление той же датой что и проводили оригинальное сопоставление).

Последний раз редактировалось fed; 29.04.2009 в 18:41. Причина: Чуток переструктурировал и причесал для читаемости
За это сообщение автора поблагодарили: mazzy (2).
Старый 29.04.2009, 18:42   #11  
online
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Она же не дает досопоставить уже сопоставленные частично проводки, если в них появились открытые остатки.

Плюс были проблемы с расщеплением CustVendTransOpen по dueDate.- Потом нормально не сопоставишь.
Старый 29.04.2009, 18:47   #12  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,890 / 5647 (194) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Logger Посмотреть сообщение
Она же не дает досопоставить уже сопоставленные частично проводки, если в них появились открытые остатки.

Плюс были проблемы с расщеплением CustVendTransOpen по dueDate.- Потом нормально не сопоставишь.
Гипотеза N1. Интересно сколько различных не связанных друг с другои способов использования этой таблицы назовет почтенная публика
Кстати - спасибо что напомнил. До появления этой таблицы и ее использования для зачетов НДС можно было сопоставлять одну и ту же накладную с одним и тем же платежом несколько раз одной и той же датой. Но - поскольку логика классов разнесения платежей на строки фактуры от применения такого подхода ломалась - пришлось поставить проверку на custVendtransPostingLog_ru. Которую, кстати, можно было прекрасно заменить проверкой по custVendSettlement...
Старый 29.04.2009, 19:19   #13  
SEKL is offline
SEKL
Участник
Сотрудники Microsoft Dynamics
 
48 / 27 (1) +++
Регистрация: 15.08.2007
Адрес: Denmark
Денис, спасибо за замечания по данной таблице

Первоначальная суть этой таблицы заключается именно в том, что отмена сопоставления должна откатывать сопоставление, а не пересчитывать его заново, как было в международной версии.

В DAX 2009 наконец добавили некий признак CustVendSettlement для того, чтобы откатывать все проводки, рожденные в конкретной сессии сопоставления.

Безусловно это лог, который можно считать транзакционным. Данные оттуда действительно используются в самых различных целях. Например при расчете курсовых разниц. То, что записи удаляются наверное не очень хорошо, но не уверен.

По поводу нормализации вообще воздержусь от комментариев. Откройте форму EmplTable в DAX 2009 и посчитайте число источников данных.
Теги
баг, ошибка, проводки по сопоставлению, сопоставление, форма

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Почему на форме "Пользовательские настройки", когда я перехожу в нее из формы, отсутствует закладка "Запрос"? Hans DAX: Администрирование 0 05.07.2007 13:52
Фильтрация в форме "В наличии" по агрегатному полю "Физ. наличие" miaa DAX: Программирование 13 29.08.2006 23:45
поле "Документы к обновлению" в форме "Обработка закупки" sev DAX: Функционал 3 08.12.2005 17:21
Знак в форме ГК/Бухгалтерские проводки chel DAX: Функционал 7 11.03.2005 04:28
Как сбросить флаг "Используется" в форме "Складской журнал" ATimTim DAX: Функционал 1 24.06.2004 19:19
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 13:11.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.