Баг на форме "Проводки по сопоставлению"

[S.Kuskov]

Наткнулся на баг на форме CustVendTransPostingLog_RU (Проводки по сопоставлению).
Видимо для того чтобы была возможность переходить к проводкам по сопоставлению с обоих сопоставленных проводок, авторы отказались

this.query().dataSourceTable(tablenum(CustVendTransPostingLog_RU)).clearDynalinks();

от стандартного поведения Dynalink и запрограммировали собственное

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. Предлагаю пофиксить эту багу следующим образом:

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();
}

[DSPIC]

Вечно в *_RU какие-то извращения...

[fed]

на мой субъективный взгляд - таблица custVendTransPostingLog_ru - сама по себе одна большая ошибка

[SEKL]

В текущей версии ситуация следующая:

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

Почему CustVendTransPostingLog_RU считается ошибкой не очень понял

[Logger]

А для какой Аксапты вы это делали ?
Если трешка, то там и так сработает - там RecId уникальный в пределах компании, так что достаточно ссылки по recId.

[Logger]

Цитата:

Сообщение от SEKL

В текущей версии ситуация следующая:

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

Почему CustVendTransPostingLog_RU считается ошибкой не очень понял

"Текущая" это какая ?
Ax 4.0 ?
или 2009 ?

[DSPIC]

Цитата:

Сообщение от Logger

А для какой Аксапты вы это делали ?
Если трешка, то там и так сработает - там RecId уникальный в пределах компании, так что достаточно ссылки по recId.

Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома

[Logger]

Цитата:

Сообщение от DSPIC

Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома

Согласен.
Но тем не менее в 3-ке указанный функционал срабатывал корректно.

[kashperuk]

Цитата:

Сообщение от DSPIC

Завязка на RecId (если уж...) всегда используется в паре с tableId. - аксиома

Я бы не ставил это в один ряд с аксиомой.
Никогда не знаешь, что может измениться в следующих версиях

[fed]

Цитата:

Сообщение от SEKL

Почему CustVendTransPostingLog_RU считается ошибкой не очень понял

А ты можешь в двух словах сформулировать - какой смысл в этой таблице ? Насколько я помню, ее завели в 2.5sp2 чтобы хранить информацию о проводках сделанных по сопоставлению (чтобы потом легче откатывать было). НО: В западной версии проводки по сопоставлению откатываются без всяких логов сопоставления - просто за счет данных о профилях в исходных записях custVendTrans/custvendSettlement/taxTrans и тп.
Можно было вычислять эти данные и без создания таблицы во первых, во вторых - вариант тупо пробежаться по логу и отсторнировать проводки по ГК все равно не работает - приходится при сторнировании очередной записи в settlement или trans, искать что-то в этом странном логе.
Дальше - хуже. При реализации оплаченного НДС в версии 2.5sp5 (кажется) туда еще засунули налоговый код и начали данные из этой таблицы использовать для каких-то рассчетов по зачету НДС по книжкам. И теперь схему зачета НДС по оплате фактически отменили - а таблица продолжает жить.

Получается, что если эта таблица является чисто информационным логом для изучения пользователем - то непонятно:

1. почему ее не чистят, время от времени,раз это не транзакционная таблица, а просто лог;
2. Непонятно почему данные оттуда берут для каких-то рассчетов или для принятия решения о ветвлении программной логики.

Если же это транзакционная таблица с полезными данными, то:

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

[Logger]

Она же не дает досопоставить уже сопоставленные частично проводки, если в них появились открытые остатки.

Плюс были проблемы с расщеплением CustVendTransOpen по dueDate.- Потом нормально не сопоставишь.

[fed]

Цитата:

Сообщение от Logger

Она же не дает досопоставить уже сопоставленные частично проводки, если в них появились открытые остатки.

Плюс были проблемы с расщеплением CustVendTransOpen по dueDate.- Потом нормально не сопоставишь.

Гипотеза N1. Интересно сколько различных не связанных друг с другои способов использования этой таблицы назовет почтенная публика
Кстати - спасибо что напомнил. До появления этой таблицы и ее использования для зачетов НДС можно было сопоставлять одну и ту же накладную с одним и тем же платежом несколько раз одной и той же датой. Но - поскольку логика классов разнесения платежей на строки фактуры от применения такого подхода ломалась - пришлось поставить проверку на custVendtransPostingLog_ru. Которую, кстати, можно было прекрасно заменить проверкой по custVendSettlement...

[SEKL]

Денис, спасибо за замечания по данной таблице

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

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

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

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