Просмотр будущих проводок

[Kirvisniemi]

Есть интересная задача - "Просмотр будущих проводок".

Суть задачи - добавляется новый пункт меню в кнопку "УЧЕТ" к счету, заказу и т.д, который при его выборе выводит будущие проводки (записи, которые должны появится в General Ledger Entry (таблица 17)). Документ при этом конечно не учитывается.

Наверняка кто-нибудь сталкивался - посоветуйте оптимальный подход.

Пока есть такие идеи:
1) лезем в 12 кодюнит, заводим там временную таблицу, в которую скидываем проводки, в триггере FinishCodeunit пишем ERROR('') для отката транзакций.
Перед еррором выводим форму с будущими проводками
- недостаток: если в таблицу 17 у нас попадут записи не из 12 кодюнита, а из какого-нибудь друго, то этих проводок мы не отследим

2) лезем в 17 таблицу, вешаем на триггер OnInsert заполнение своей собственной таблицы (дублера таблицы 17). в кодюните 12 заменяем INSERT на INSERT(TRUE). В триггер FinishCodeunit добавляем ERROR('').
Перед еррором выводим форму с будущими проводками.
- недостаток: после того как сработает еррор, транзакция откатится и соотственно наша собственная таблица тоже подчистится

Как лучше сделать?

[anatoliy]

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

помоему криво , но обдумать такой вариант можно.

[Kirvisniemi]

Цитата:

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

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

А если похожих документов просто нет? Неее, тут надо подумать

[Галина]

Мда.. что только из Navision не делают

[Yoil]

Тупая идея: сделать еще одну фирму, копировать документ туда, там учитывать, смотреть на результат

[Kirvisniemi]

Цитата:

Сообщение от Дуд

Тупая идея: сделать еще одну фирму, копировать документ туда, там учитывать, смотреть на результат

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

[rmv]

Другого выхода кроме как обвешать кодеюниты учета вставкой в свои/временные таблицы на каждый insert (поиск ".Insert" рулит) не вижу.
Либо учитывать в специальной созданной для этого фирме и результаты учета тянуть оттуда. В варианте перед учетом придеться синхронизировать настроечные табллицы и справочники

[mazzy]

Цитата:

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

Пока есть такие идеи:
1) лезем в 12 кодюнит, заводим там временную таблицу, в которую скидываем проводки, в триггере FinishCodeunit пишем ERROR('') для отката транзакций.
Перед еррором выводим форму с будущими проводками
- недостаток: если в таблицу 17 у нас попадут записи не из 12 кодюнита, а из какого-нибудь друго, то этих проводок мы не отследим

<{POST_SNAPBACK}>

Примерно так сделано в русской Аксапте.
Только получившиеся проводки копируются, транзакция откатывается, форма показывается.
Минусы - вероятность блокировок возрастает.

Цитата:

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

2) лезем в 17 таблицу, вешаем на триггер OnInsert заполнение своей собственной таблицы (дублера таблицы 17). в кодюните 12 заменяем INSERT на INSERT(TRUE). В триггер FinishCodeunit добавляем ERROR('').
Перед еррором выводим форму с будущими проводками.
- недостаток: после того как сработает еррор, транзакция откатится и соотственно наша собственная таблица тоже подчистится

<{POST_SNAPBACK}>

Это не единственный недостаток.
Где-то в глубинах Навижина может быть создание проводок на основании текущей в этой или в других таблицах. Например, создание проводки округления возможно только после создание всех проводок с данным номером документа.

Поэтому вариант 2 не годится в общем случае.

[Kirvisniemi]

Цитата:

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

Цитата:

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

Пока есть такие идеи:
1) лезем в 12 кодюнит, заводим там временную таблицу, в которую скидываем проводки, в триггере FinishCodeunit пишем ERROR('') для отката транзакций.
Перед еррором выводим форму с будущими проводками
- недостаток: если в таблицу 17 у нас попадут записи не из 12 кодюнита, а из какого-нибудь друго, то этих проводок мы не отследим

Примерно так сделано в русской Аксапте.
Только получившиеся проводки копируются, транзакция откатывается, форма показывается. Минусы - вероятность блокировок возрастает.

Попробовал сделать такой вариант. Работает.
Сразу всплыли недочеты:
- как я и предполагал, проводки в G/Ledger попадают не только через 12 кодюнит :-( - форма показывает не все будущие проводки
- блокировок нет, потому что форма показывается в немодальном режиме и транзакция успевает откатиться (однако данные из формы не пропадают). НО: есть сложность в синхронизации пользовательских действий. Например пользователь может открыть счет и посмотреть его будущие проводки. А затем сворачивает форму (не закрывает, а сворачивает!), открывает другой счет и снова смотрит будущие проводки.
Еще одно НО: одновременно будущие проводки могут смотреть несколько пользователей и где-то надо хранить флаг "будущности" для каждого юзера

Цитата:

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

Цитата:

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

2) лезем в 17 таблицу, вешаем на триггер OnInsert заполнение своей собственной таблицы (дублера таблицы 17). в кодюните 12 заменяем INSERT на INSERT(TRUE). В триггер FinishCodeunit добавляем ERROR('').
Перед еррором выводим форму с будущими проводками.

Это не единственный недостаток.
Где-то в глубинах Навижина может быть создание проводок на основании текущей в этой или в других таблицах. Например, создание проводки округления возможно только после создание всех проводок с данным номером документа. Поэтому вариант 2 не годится в общем случае.

Верно. Потому и ломаю голову...

[mazzy]

Цитата:

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

А затем сворачивает форму (не закрывает, а сворачивает!), открывает другой счет и снова смотрит будущие проводки.
Еще одно НО: одновременно будущие проводки могут смотреть несколько пользователей и где-то надо хранить флаг "будущности" для каждого юзера

<{POST_SNAPBACK}>

Обрати внимание: я писал слово "записывает".
В Аксапте используется механизм временных таблиц для хранения промежуточных итогов.

Оставлять ТОЛЬКО на экране - принципиально неправильно.

[Kirvisniemi]

Цитата:

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

В Аксапте используется механизм временных таблиц для хранения промежуточных итогов.
Оставлять ТОЛЬКО на экране - принципиально неправильно.

В Navision, в форму можно передать временную таблицу, после чего код, вызвавший открытие формы может преспокойно завершиться и временную переменную типа record убить. Но в форме содержимое останется.
Не думаю что это неправильно - т.к. задача показать проводки реализуется.

Тут проблема в том, как отследить появление записей в G/L минуя 12 кодюнит "Gen. Jnl.-Post Line" - слишком много функционала надо перелопатить.

Пахнет коммерческой разработкой :-)

[rmv]

Может я чего не понимаю... но в 12 и 80/90 задействована не только 17 таблица.. А как же 21,25 измерения в конце концов?

[Kirvisniemi]

Цитата:

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

Может я чего не понимаю... но в 12 и 80/90 задействована не только 17 таблица.. А как же 21,25 измерения в конце концов?

Будущие проводки вне таблицы 17 меня не интересуют.

[rmv]

Сорри за предыдущий пост ... недопонял вариант решения.

[TarasNBV]

Мы когда-то сталкивались с подобной задачей - сделать тестовый отчет по 17 таблице. Решение было довольно сложным - почти полное дублирование процесса учета. Почему нельзя все обрабатывать только в 12-м кодеюните - его вызов происходит в нескольких местах (это первое) и для нескольких строк он может вызываеться соотв. кол-во раз.

В этом нелегком деле остается только пожелать удачи!

[rmv]

Если делать через error можно попробовать совершенно извратский способ:.
1. Перед учетом лочим 17 таблицу и запоминаем номер последний операции.
2. После учета все проводки после запомненной операций пишем к примеру в файл.
3. Мягко вызываем ошибку if ErrorCodeunit.run (в теле - error).
4. Восстанавливаем данные из файла в свою таблицу.

[Kirvisniemi]

2rmv: насчет файла - оч.хорошая идея

[rmv]

Ну в общем случае решение можно сформулировать так.
1. Провести учет.
2. Положить результаты учета куда-нить, откуда они не удаляться при откате транзакции.
3. Мягко откатить транзакцию.
4. Восстановить результаты учета в свои таблицы.
Куда класть - в файл, в массив rec17[10000] может быть даже в поток - это дела вкуса
Дерзайте

[Kirvisniemi]

попробую класть в файл.
кстати имя для файла придется придумывать в зависимости от ника пользователя и номера транзакции :-)

[rmv]

Чтобы не заморачиваться - проще положить в массив.

После отката транзакции восстановить во временную таблицу (ту же 17 - какая экономия клиенту на лишней таблице ) и показать на форме.

Если пойти дальше - объявить двухмерный массив recoredref'ов, анализировать не только 17 таблицу но и все книги операций - и рисовать Виртуальный Навигатор ))...