Трансляция

[sev]

дошло наконец...) про дебеты и кредиты...)))

[Starling]

Недавно удалось запустить трансляцию на DAX2009. Решил поделиться впечатлениями и задать пару вопросов. Итого:

1. Нормальной документации по этой функциональности найти так и не удалось. Пришлось разбираться через код.
2. В целом стандартный функционал очень неплохо покрыл требования заказчика.
3. Были выявлены ошибки:
   • В методах checkRange, convertTrans класса RTSLDimensionConvert идет неправильная работа с фин. аналитиками. Об этом уже упоминалось на форуме.
   • В методе fixTransDifference класса rtslLedgerTranslation был вот такой кусок кода:

     voucherLedgerTrans.TransType == tmpLedgerTrans.TransType // RU-708-411-7GLy

     Наличие этого кода приводила к тому, что в ряде случае система отдельно рассматривала дебетовую и кредитовую проводки, что приводило к дисбалансу.

     Зачем этот код добавили, для меня вопрос остался открытым. Я его просто закомментировал, пока ни каких спец эффектов обнаружено не было

     Может, кто подскажет, зачем это было сделано.

   • Периодически при трансляции система не может корреспондировать проводки. Ошибка проявляется если в одном ваучере много проводок (например, сопоставление аванса и отгрузки со сторно налогов). Ошибка не стабильна - зачастую если транслировать только один ваучер, то ошибки нет. Если же этот ваучер транслировать в куче с другими проводками, то ошибка возникает. Таких проводок у нас порядка 1%. Пока после трансляции корреспондируем вручную. Есть ощущение, что ошибка не в самой трансляции, а в движке корреспонденции. Могу ошибаться. Может, кто уже сталкивался с этим?
4. Модификации (в целом не много):
   • Добавили синхронизацию курсов валют и аналитик. Получилось не универсально, но требования конкретного заказчика закрыли.
   • Добавили возможность не только умножать, но и делить на индексы, так как иначе погрешность округления была очень большой.
   • Добавили еще пару механизмов формирования проводок в УПР компании, но это уже больше заморочки клиента. Можно было бы изменить правила формирования БУХ проводок и выкрутиться стандартом, не захотели
5. Удивило:
   • Удаление проводок ГК при отмене трансляции. Клиенту долго рассказывали о том, какое «зло» удаление. И тут на те – в стандарте проводки удаляются. Но, ИМХО, в данном случае вполне оправданное решение

Самый грустный момент это производительность. Тормозит жутко. В целом если транслировать один раз в месяц, то можно и подождать. Но клиент желает транслировать ежедневно. И тут уже проблемы.

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

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

[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 добавить – это пока смущает.