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

[Kirvisniemi]

Если кому интересно, расскажу как все удалось реализовать.

Т.к. в ходе экспериментов выяснилось, что не все кодюниты постят данные в G/L Entry через кодюнит 12, пришлось пойти единственным верным путем - повесится на триггер OnInsert таблицы G/L Entry.

Шаг 1. Поскольку во всех стандартных модулях, работающих с таблицей G/L в коде написан просто INSERT, наш код в триггере OnInsert вызываться не будет. Следовательно везде нужно поменять INSERT на INSERT(TRUE).
Я сделал просто - выгрузил все кодюниты в txt-файл и поиском нашел все переменные, ссылающиеся на G/L (это просто - достаточно поискать строку ":record 17;"). Переменных оказалось не много, а уж кодюнитов, осуществляющих непосредственную работу с G/L и вовсе всего три:
12 (Gen. Jnl.-Post Line),
413 (AnalysisViewEntryToGLEntries) и
432 (Consolidate).
Во всех них я подправил INSERT на INSERT(TRUE)

Шаг 2. Поскольку для отката транзакции нужно было выбрать место до которого уже сформировались все проводки, кодюнит 12 для этих не подошел. Пришлось вставлять тривиальный ERROR('') в четыре кодюнита:
80 (Sales-Post),
90 (Purch.-Post),
5704 (TransferOrder-Post Shipment) и
5705 (TransferOrder-Post Receipt)
Последние два нужны только для учета перемещений.
Имейте ввиду, что 80 и 90 кодюниты напичканы COMMIT'ами и перед каждым нужно поставить проверку флага "Режим будущих проводок". В режиме будущих проводок ничего коммитится не должно.

Шаг 3. Т.к для хранения будущих транзакций нельзя было использовать таблицу (потому что при откате транзакции все записи сразу были бы стерты), пришлось выбирать из двух вариантов - либо использовать кодюнит с SingleInstance=Yes, либо писать проводки в файл. И тот и другой способы имеют свои достоинства и недостатки. Я решил остановиться на кодюните и сохранять данные в массиве. Этот же кодюнит по совместительству выполняет функцию хранению флага "Режим будущих проводок" для текущего юзера.

Шаг 4. Во все нужные документы я добавил новый пункт меню "Просмотр будущих проводок". Код остался точно такое же как и при учете. До него добавил выставление флага "Режим будущих проводок"

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

Что имеем в результате:
работающий механизм просмотра будущих проводок, не блокирующий работу и даже имеющий поддержку будущего функционала (если будут писать INSERT(TRUE)

[rmv]

Очень интересное решение!
Хотя на мой взгляд можно было бы обойтись без .Insert(true) просто обернув вызов учетных кодеюнитов, в этом случае ломка стандартного функционала минимальна. Примерно таким образом:
GLE.loctable;
if GLE.find('+') then LastEntryNo:=GLE."Entry No."
else LastEntryNo:=1;
codeunit80.SetNoCommit(true);
codeunit80.run(SalesHeader)
TransferPostedEntriesToArray(LastEntryNo)
if ErrorCodeunit.run then
TransferPostedEntriesFromArray(tempGLE);

[anatoliy]

Раскажите о работающем варианте. Очень интересно.

[anatoliy]

Извините не увидел предыдущий пост.

[Константин!]

TO rmv

Попытался сделать по вашему алгоритму Тестовый учет
в ходе написания выеснилось что строчка
if ErrorCodeunit.run then не прокатит в Транзакции Записи в которых нет Commit-ов (система не разришает использовать возврашаемое значение)

Сделал примерно так (я смотрел записи в 17 таблицы после учета журнала оплат)

1) создаем CodeUnit в нем пишем

OnRun(VAR Rec : Record "Gen. Journal Line")
{  GLEntry.LOCKTABLE;
   IF GLEntry.FIND('+') THEN
	 LastEntry:=GLEntry."Entry No."
   ELSE
	 LastEntry:=1;
   GlPostBach.SetNoCommit(TRUE);
   GlPostBach.RUN(Rec);
   TransferPostedEntriesToArray(LastEntry);
   ERROR('');
}
TransferPostedEntriesToArray(EntryNo : Integer)
{  GLEntry.RESET;
   GLEntry.SETFILTER("Entry No.",'%1..',EntryNo+1);
   IF GLEntry.FIND('-') THEN BEGIN
	 i:=0;
	 REPEAT
	   i+=1;
	   TempArrayGLE[i]:=GLEntry;
	 UNTIL GLEntry.NEXT=0;
   END;
}
TransferPostedEntriesFromArray()
{  tempGLEntry.DELETEALL;
	i:=0;
	EndLoop:=FALSE;
	REPEAT
	  i+=1;
	  IF ArrayGLE[i]."Entry No." <> 0 THEN BEGIN
		 tempGLEntry:=ArrayGLE[i];
		 tempGLEntry.INSERT;
	  END
	  ELSE
		EndLoop:=TRUE;
	UNTIL EndLoop;
	FORM.RUN(20,tempGLEntry);
}

2) В форме фин журнал создаем кнопку "Тестовый Учет"
туда пишем

  
  IF TestPost.RUN(Rec) THEN;
  TestPost.TransferPostedEntriesFromArray;

TestPost - это CodeUnit созданы в пункте 1

[IGG]

Мы смотрим проводки так....
Есть функционал удаления учтенных документов
Бюстгалтер учитывает запись.
Смотрит - какую-то фигню напорол.
Есть функционал восстановления операции из учтенных журналов либо стандартный из счетов покупки-продажи.
Поднял операцию, старую проводку удалил, исправленную учел.

[rmv]

Константин! - очень рад что у Вас получилось .
IGHG - можно и так, но цель автора топика - посмотреть будущие проводки, а не провести учет, посмотреть проводки и отменить.

[Beetlejuice]

Граждане! Покажите глупому ламеру, где в кодеюнитах 80-х,90-х, 413 и 432-м формируются записи в 17 таблице, минуя 12-й кодеюнит.

Почему расматривается формирование дублирующих 17-ю таблицу записей в функции финишкодеюнит. Других функций видимо нет???

[IGG]

Куда приезжать?