Трансляция

[EVGL]

Цитата:

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

Мне кажется, у меня есть решение. Покритикуйте.

1. На входе указывается период, за который мы хотим транслировать. Система перебирает в цикле все проводки ГК (причем кредитовую и дебетовую часть отдельно) вне зависимости от того были они транслированы или нет.
2. Уже после того как проводка была выбрана система проверяет, была ли эта проводка уже транслирована.
3. В результате, если мы находимся в конце периода и нам реально нужно транслировать 1000 проводок ГК, система будет перебирать все 50 000, которые были в течение периода.
4. Что я хочу:
   • Добавить в LedgerTrans чек-бокс.
   • После окончания трансляции выбрать из таблицы RTSLTransLog RecId всех записей LedgerTrans, которые были транслированы в рамках текущей сессии. И обновить для них это поле
   • При отмене сессии трансляции по такому же принципу новое поле де актировать.
   • В запрос по выбору проводок добавить критерий по новому полю. В результате будем выбирать только то, что не транслировалось, т.е. 1000.
   • Мне кажется, что при ежедневной трансляции такой подход должен значительно ускорить производительность. Если же транслировать сразу месяц, то эффекта не будет ни какого. Но нам это и не нужно.

Да, 10 лет назад я не очень много понимал в производительности. Странно, что за 10 лет никто не усовершенствовал код. Есть некоторые идеи, в любом случае надо оптимизировать \Classes\RTSLLedgerTranslation\processRules:

1) Добавить в Query TransLog и делать выборку с джойном. Будет ничем не медленее вашей идеи с полем.

2) Сейчас идет выборка "от правип - к проводке", идет запрос от меньшей таблицы - к большей. Надо вывернуть наизнанку и делать выборку "от проводок - к правилам", закешировав предварительно правила, а также кэшируя результат по ключу "SourceAccountNum", причем делать обработку звездочек * не с помощью запроса, а оператором like.

[Starling]

Цитата:

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

1) Добавить в Query TransLog и делать выборку с джойном. Будет ничем не медленее вашей идеи с полем.

Можно наверно и так.
Но, если я сейчас правильно помню код, то таблица TransLog заполняется в процессе трансляции. Получается что таблица, которая входит в запрос, «инсертится» в процессе выполнения этого запроса.
Когда-то у меня были проблемы с такой реализацией.
Спасибо – будем пробовать.
О результатах постараюсь отписаться.

[Starling]

Ошибку корреспонденции походе удалось исправить, модифицировав код метода importTransactions класса rtslLedgerTranslation.

protected void importTransactions()
{
....

    while select tmpLedgerTrans         // The order defines bond sequence
        order by Voucher,
                 TransDate,
                 //BUG003, 10/10/2012 -->
                 //add - исправление ошибки корреспонденции
                 BondBatch desc,
                 BondBatchTrans desc,    // 2-2, 1-1, 0-0, 0, 0, 0
                 //BUG003 <--
                 TransType,
                 OperationsTax,
                 AccountType,           // Usial-Usial, Usial-Disbalance, ...-TransDiff
                 Txt
                 //BUG003 10/10/2012 -->
                 //comment - исправление ошибки корреспонденции
                 //BondBatch desc,
                 //BondBatchTrans desc    // 2-2, 1-1, 0-0, 0, 0, 0
                 //BUG003 <--
...

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

После внесения описанных выше изменений ошибка перестала проявляться.

[Starling]

Попробовали оба варианта:
1. Новое поля – признак того, что проводка уже транслирована.
2. Not exists join по таблице TransLog.
При первом вариант один день за 7 минут, при втором за 1 час. Но для первого пришлось еще и индекс на LedgerTrans добавить – это пока смущает.