Что за поле LedgerBalancesTrans.LedgerBalancesVariant?

[chi]

Собственно, сабж. Даже лэйбла к нему нет (и к его расширенному типу).

[DreamCreator]

Класс LedgerVoucherBalancesList

переменная variant потом может инициализироватьи обновлять LedgerBalancesVariant

PHP-Code:

void new(LedgerBalancesMap _ledgerBalancesMap)
{
    Xsession    session = new xsession();
;
    LedgerBalances = _ledgerBalancesMap;

    variant = session.sessionId() mod 20;

    balanceList = new RecordSortedList(LedgerBalances.TableId);
} 


[chi]

А для чего это поле нужно в таблице?

[DreamCreator]

ИМХО: судя по результатам поиска в АОТ-е это поле используется при поиске (как параметр для поиска) и сортировке.

[fed]

Это поле добавлено в версии 3.0 для уменьшения взаимных блокировок.

Грубо говоря - идея следующая:
В старой Axapta (2.5/2.1) обороты по счетам и аналитикам накапливались в таблицах ledgerBalances и ledgerBalancesDim в разрезе счетов и периодов и в разрезе счетов, периодов и аналитик соответственно. Классы разноски в ledgerTrans после записи в саму ledgerTrans обновляли обороты в этих таблицах. Соответственно - если я начинал разносить журнал из 5000 строк, система обновляла одну из строк в ledgerBalances (скажем - по счету 60.01) и эта строка блокировалась до конца транзакции. При этом все остальные транзакции, которые пытались выполнить проводку на счет 60.01, ожидали ее окончания. Ну а поскольку разноска журнала из 5000 строк может занимать эдак часик, а то и два, все это приводило к высокому уровню блокировок, и большому количеству перекуров среди пользователей.

В версии 3.0 эти таблицы заменили на таблицы ledgerBalancesTrans и ledgerBalancesDimTrans. При этом - обороты по счету могут записываться в любую из 20 строк которые этому счету соответствуют. То есть - при обновлении ledgerTrans система более или менее случаным (в зависимости от номера сессии) образом выбирает одну из этих строк и пишет туда сумму оборотов. Благодаря этому - вероятность взаимных блокировок уменьшается в 20 раз. В то же время - если классам LedgerBalanceDim* или подобным необходимо посчитать обороты за период, то в общем-то, не возникает большой разницы между чтением одной строки из таблицы и чтением 20 строк из той же таблицы (Серверное железо-то теперь очень даже мощное). Так что тут проблем с производительностью не возникает.

[gaenar]

Возвращаюсь к вопросу о LedgerBalancesDimTrans.

А объясните, как может быть, что в LT только одна проводка на 800К, а в LedgerBalancesDimTrans две на ту же сумму и отличаются они только этим полем LedgerBalancesVariant? Из-за этого в отчёт попадают задвоенные обороты и выходит, что этой агрегированной таблицей пользоваться не стоит.

[mazzy]

Zitat:

Zitat von gaenar

Возвращаюсь к вопросу о LedgerBalancesDimTrans.

А объясните, как может быть, что в LT только одна проводка на 800К, а в LedgerBalancesDimTrans две на ту же сумму и отличаются они только этим полем LedgerBalancesVariant? Из-за этого в отчёт попадают задвоенные обороты и выходит, что этой агрегированной таблицей пользоваться не стоит.

1. У пользователей нет штатной возможности повлиять на промежуточные итоги (LedgerBalancesDimTrans)
2. Несоответствие итогов и проводок может создать только программист или администратор
2.1. Программист может вместо методов Insert, Update, Delete вызвать методы doInsert, doUpdate, doDelete. При вызове do-методов ядро не выполняет предопределенные процедуры. Следовательно при вызове do-методов на таблице проводок не изменятся итоги
2.2. администратор может выполнить какие-либо операции над таблицей проводок средствами СУБД.

Если программист и администратор вручную вмешиваются в базу, то они должны вручную обеспечить целостность базы. В данном случае пересчитать итоги.

Бухгалтерские итоги пересчитываются Главное меню \ Главная книга \ Периодические операции \ Пересчет данных периодов

[gaenar]

Да, после пересчёта всё хорошо. Спасибо.
Попрошу добавить в пакет на ночь.
Забывают пересчитывать вручную после смены аналитики средствами программиста.

By the way...
не могу понять, зачем в русской локализации код, отвечающий за добавление LedgerBalancesDimTrans и LedgerBalancesTrans вынесен из LedgerVoucherTransObject.postGroup() и занесён в "пост-проверку" в LedgerVoucher.post() ( в тело цикла for (more = ledgerTransList.first(ledgerTrans) ). Причём в зависимости от параметра Correspondense_RU. Видимо, из-за того, что метод splitTrans не возвращает созданный корреспондирующий LedgerTrans, и положить его в LedgerBalancesXXX сразу нет возможности.