Трансляция

[sev]

Еще. такая ситуация. понимаю, что где-то что-то сам не то делаю...Система говорит -импортировано 173, при этом 4 проводки транслировано. но в LedgerTranse ни одной нет. На вскидку не скажете, в чем может быть причина?

[EVGL]

Цитата:

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

Еще. такая ситуация. понимаю, что где-то что-то сам не то делаю...Система говорит -импортировано 173, при этом 4 проводки транслировано. но в LedgerTranse ни одной нет. На вскидку не скажете, в чем может быть причина?

Курсы настроены так, что суммы уходят в ноль? Трансляции это все равно, а вот ГК такие проводки просто не сохраняет (и правильно делает).

[sev]

Когда кредит -да, это значит что транслируется только кредит счета, или и дебет, и кредит счета, или кредит корр.счета?
Сделал закупку 10 -60, основную и вторичную валюту поставил рубли, пока без смысла, чтобы просто хоть как-то отработало. Настроил трансляцию счет 10 корр счет 60. Если ставлю кредит -Да, система говорит, проводк не найдено. Если ставлю кредит-Нет, система говорит дисбаланс на такую же сумму и тоже не транслирует ничего. Как быть?

[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 заполняется в процессе трансляции. Получается что таблица, которая входит в запрос, «инсертится» в процессе выполнения этого запроса.
Когда-то у меня были проблемы с такой реализацией.
Спасибо – будем пробовать.
О результатах постараюсь отписаться.