Трансляция

[sev]

Подскажите, пожалуйста. Где можно хоть что-нибудь прочитать про механизм трансляции в аксапта? Или как всегда тыкаться наугад...
В чем принципиальное отличие от консолидации?

[mazzy]

ищите. обсуждалось неоднократно.

[sev]

ой, все прочитал, но не все понятно...Например, что есть методы трансляции и можно ли их вручную формировать...

[sev]

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

[sev]

Написано, что импортировано 147 проводок. При этом успешно завершена трансляция только двух, при этом перехожу в план счетов компании-приемника, там один счет завел, на нем ноль проводок. Просмотр проводок перед импортом -выдаются все проводки с нулями. при этом, когда проваливаюсь в документ ГК -там цифра есть...В общем, мягко говоря,не разобрался пока...(

[kosenkov]

Даю алгоритм действий :

If (Вы новичок в Аксапта) and (трансяция Вам не "горит") Then

Забудьте о трансляции месяца на три;

else

1. Поиск по форуму по слову "трансляция";
2. Внимательная вычитка веток, особенно самой большой и приаттаченного к ней файла;
3. Эксперименты с Аксапта, пробуйте, пробуйте.
4. Четко сформулированные, конкретные вопросы, ответы на которые Вы не сумели найти после вышеперечисленного - задавайте, Вам ответят.

EndIf;

[EVGL]

Дисбаланс и тр. разница: трансляционная разница возникает, когда есть дебет и кредит, но курсы разные. Дисбаланс: кредит транслируется, а дебет - нет или наоборот. Очевидно, в одном документе ГК может быть и то, и другое.

Все настройки - в компании-источнике.

Читайте OnlineHelp по F1: зря я его, что ли, писал?

[sev]

спасибо огромное за помощь. Что же касается "алгоритма действий" - не новичок, но трансляцией никогда не пользовались и уже заколебало очень сильно вычитывать то, что должно быть в документации.

[sev]

в хэлпе сп4 на поле группа правил, как и на большинстве других критичных,
содержится следующая информация(скопировал).

Настраивая ширину параметра "Расширенный тип данных", можно контролировать ширину идентификационного ключа в категоризирующих таблицах программы.


Пример расширенных типов данных, расширяющих SysGroup Системное имя Метка Текст справки
CustGroupId Группа клиентов Группа клиентов
FreightZoneId UPS зона Код зоны доставки UPS службы
ItemGroupId Ном. группа Идентификация номенклатурной группы
PaymCode Условия оплаты Код сроков оплаты.
RouteOprId Операция Идентификация операции



Стандартная ширина установлена на 10 символов.

Можно установить и меньшее значение (например, 5), если вы предпочитаете использовать номера или короткие коды для различных идентификаторов.
Можно установить и большее значение (например, 20), если вы предпочитаете использовать более длинные коды для различных идентификаторов.

IntelliMorph автоматически упорядочивает формы и отчеты в соответствии с новой длиной поля.

Различные значения длины
Если вы предпочитаете различные значения длины для различных идентификационных ключей, это можно сделать в Репозитарии прикладных объектов следующим образом:

Откройте Репозитарий прикладных объектов как разработчик.
Выберите расширенный тип данных, для которого требуется другая длина.
Откройте окно свойств объекта и очистите параметр "Расширения", удалив значение "SysGroup".
Задайте необходимую длину для свойства "StringSize".

В отличие от других расширений в расширенных типах данных, наследование свойства SysGroup его потомкам можно разорвать.

[EVGL]

sorry

[sev]

Евгений, подскажите, пожалуйста еще про методы трансляции. Что они определяют. Он один - трансляцияГК? или какие -то еще бывают...Видимо, функционально не добавляются... Еще раз спасибо за четкие ответы...Может, хэлп-то в другом сервис-паке лучше? Посоветуйте. Может в 2.5 вообще посмотреть?

[EVGL]

Метод трансляции в стандартной версии один - "Трансляция ГК". Методы программируются, один метод - один системный класс, поэтому функционально добавить новый нельзя. Мистер BOAL написал в свое время в CITP-R дополнительный метод трансляции для клиентов, который преобразует не только LedgerTrans, но и CustTrans.

С хелпом - не знаю... В свое время написал подробнейший. По крайней мере, ко всем формам. Еще где-то в архивах осталась requirement spec., но без разрешения MS я ее выкладывать права не имею. Не помню уже, к 2.5 или к 3.0. В ранних SP к 3.0 была еще, вроде.

[sev]

да я понял, что написали...Найти бы, где он. Вы к 2.5 писали?

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

[mnt_dx]

Цитата:

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

а почему нет? Дт часть проводки может идти на один счет, Кт на другой или никуда не идти.

Цитата:

Удаление проводок ГК при отмене трансляции. Клиенту долго рассказывали о том, какое «зло» удаление. И тут на те – в стандарте проводки удаляются. Но, ИМХО, в данном случае вполне оправданное решение

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

[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.