Трансляция

[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.
   • Мне кажется, что при ежедневной трансляции такой подход должен значительно ускорить производительность. Если же транслировать сразу месяц, то эффекта не будет ни какого. Но нам это и не нужно.