Коррекция ГК и пересчет себестоимости

[greenfin]

Час добрый, господа! Изучаю процедуру закрытия склада, DAX 2009 Rollup6. Интересует следующий момент: после того как система рассчитает фактическую себестоимость, производится разноска рассчитанной коррекции в Главную книгу (LedgerTrans). Вопрос: разноска рассчитанной коррекции в ГК в штатном функционале возможна только отдельными проводками на основании данных содержащихся в таблице InventSettlement? Т.е. изменения в ранее созданные проводки в ГК по операциям, для которых рассчитана коррекция не вносятся? Или возможен другой вариант в штатном функционале: на рассчитанную коррекцию создаются новые проводки в ГК, но данные проводки создаются в «рамках» ранее имеющихся операций, для которых рассчитана эта коррекция?
Имеется производственная необходимость после пересчета в разрезе первичного документа смотреть операции по бух.проводкам уже с корректированной суммой.

[Logger]

Цитата:

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

Имеется производственная необходимость после пересчета в разрезе первичного документа смотреть операции по бух.проводкам уже с корректированной суммой.

Зачем же для этого курочить механизмы разноски ?
Мы подобную проблему решили, написав отчет, которые проходит по проводкам InventTrans, соответствующим документу и собирает по ним все неотменённые коррекции, группирует их в нужных разрезах по счетам Гк и финансовым аналитикам и выплевывает в Excel.
Если есть желание видеть их прямо в Аксапте то можно пихать во времянку и отображать на форме.

[Ivanhoe]

В общем случае, проводки по закрытию склада могут вообще идти одной строкой по всем номенклатурам (при условии совпадения счета ГК, аналитик и соответствующей настройки в диалоге закрытия).

В стандарте, по складской проводке можно легко посмотреть итоговую себестоимость - смотрите не только поле "себестоимость", а еще приплюсуйте поле "Коррекция". Если же нужны именно проводки ГК да еще и по конкретному документу - придется делать модификации (и учитываем первое ограничение). В 2009 появились подробные отчеты по складским операциям - как международные, так и русская оборотка по складу - возможны они вам подойдут?

[greenfin]

Спасибо за ответы. С отчетами идея понятна, но в данном случае, к сожалению, отчет не поможет, т.к. коррекции в «рамках» операции необходимо просматривать непосредственно в системе при просмотре операций ГК.
Есть мысли по доработке функционала в части отражения коррекции по ГК после закрытия склада. Прошу высказать критику на мысли в части следующей доработки:
На основании данных содержащихся в таблице InventSettelment, через номер складской проводки (InventTrandid) в таблице складских проводок (InventTrans) определяем номер операции ГК (Voucher). Через номер операции (Voucher) в таблице бухгалтерских проводок (LedgerTrans) определяем дату операции (TransDate), связи корреспонденции в полях (BondBatch_Ru) и (createdTransaction) для каждой операции бухгалтерских проводок. Создаем дополнительную таблицу, которая будет содержать такие поля: «TransDate», «Voucher», «BondBatch_Ru», «createdTransaction» – это взяли из таблицы бухгалтерских проводок, а также ссылку на строку из таблицы InventSettelment, для которой была найдена данная информация. Ссылаться планирую через Recid. В таблицу InventSettelment добавить признак, указывающий, что для данной строки в таблице складских проводок была найдена строка (строки) с одним номером операции ГК (Voucher). Группировку данных перед записью в таблицу складских проводок производить по данным содержащимся в InventSettelment, только к штатной группировке добавим данные из дополнительной таблицы. Из дополнительной таблицы будет использован для группировки номер операции (Voucher). После группировки, данные строки в таблицу бухгалтерских проводок вставляем с номером операции из дополнительной таблицы, также дату операции и связь корреспонденции берем из дополнительной таблицы. Также в дополнительной таблице будет три поля: два содержать ссылку на строку в бухгалтерских проводках (дебет, кредит), которые были созданы, третье поле - признак удаления. Ссылку на операции в таблице бухгалтерских проводках планирую сделать через поле Recid.
Строки таблицы InventSettelment, у которых в признаке (новое добавляемое) указано, что найдено несколько номеров операций ГК обрабатывать будем штатным функционалом.
В части отмены операции пересчета допускаем два варианта: первый – создание сторнирующих проводок по аналогичному принципу; второе – удаление ранее созданных бухгалтерских проводок, для этого в дополнительной таблице и предусматриваю ссылки на строки в бухгалтерских проводках и признак что данные были удалены из бухгалтерских проводок.
Выбор варианта обновления ГК выводим на параметры, задаваемые перед закрытием склада, так же на параметры по отмене операции закрытия выводим условия: удалять или сторнировать данные.
Просьба указать на «подводные камни». Проверка на то, что для одного InventTransid найден один номер операции ГК делается на случай, если в системе возникнут данные с одним номером складских проводок для которых будет произведена раздельная финн.обработка.

[Ivanhoe]

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

[Logger]

Чем же вам не подходит вариант временной таблицы ?
Её результат можно и на форме отображать, так что пользователь не отличит от обычной формы проводок. Зато рисков что-то сломать существенно меньше.

[greenfin]

Цитата:

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

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

Пользователи имеют право (доступ) просматривать бухгалтерские операции из таких документов, как: накладные из модуля расчеты с поставщиками, накладные из модуля расчеты с клиентами, по складским журналам, производственным заказам и др. Работают и с анализом счета, ОСВ по ГК и напрямую с аудиторским следом. В штатном функционале, при просмотре бухгалтерских операций из выше описанных источников, информация отражается не в полном объеме: нет данных о коррекции. Т.е. отсутствует так сказать её (информации) прозрачность и полнота.
Данную информацию просматривают работники бухгалтерии, ФЭО и др.

Цитата:

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

Чем же вам не подходит вариант временной таблицы ?
Её результат можно и на форме отображать, так что пользователь не отличит от обычной формы проводок. Зато рисков что-то сломать существенно меньше.

С временной таблицей идея интересная. В таком ключе работу временной таблицы предлагаете: при переходе к бухгалтерским операциям, из какого либо документа на форме «коды операций» сделать некий параметр. Отвечает за отображение коррекции приходящейся к данному документу. По умолчанию он пусть будет не отмечен. При необходимости указывают, что надо отразить существующую коррекцию. В данном случае на основании номера «Voucher» , присвоенного в рамках данного документа, в таблице складских проводок определяем проводки, из которых забираем номер складской проводки. На основании номеров складских проводк взятых из таблицы «InventTrans» находим записи в таблице «InventSettelment» с этими же номерами складских проводок и у которых отмечено поле «Posted». Делаем группировку в разрезе счетов и финансовых аналитик, полученные данные выводим на форму – это и есть коррекция, приходящаяся на данный документ.
При этом поле «TransDate», содержащееся в таблице «InventSettelment» не учитываем, т.к. необходимо отразить состояние операций на текущий момент времени. Верно понимаю вашу мысль?

[Ivanhoe]

Цитата:

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

Пользователи имеют право (доступ) просматривать бухгалтерские операции из таких документов, как: накладные из модуля расчеты с поставщиками, накладные из модуля расчеты с клиентами, по складским журналам, производственным заказам и др. Работают и с анализом счета, ОСВ по ГК и напрямую с аудиторским следом. В штатном функционале, при просмотре бухгалтерских операций из выше описанных источников, информация отражается не в полном объеме: нет данных о коррекции. Т.е. отсутствует так сказать её (информации) прозрачность и полнота.
Данную информацию просматривают работники бухгалтерии, ФЭО и др.

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

[pitersky]

Цитата:

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

Просматривают, понятно. Зачем? Что бы что сделать?

Рискну предположить, что в данном случае опять работает логика 1С. Пользователи на ментальном уровне не не делают разницы между проводками по модулю и в ГК, поэтому содержимое полей коррекции для них остаётся за кадром. Вот и надо делать всяческие ухищрения.

[greenfin]

Цитата:

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

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

Одной из обязанностей работника финансовой службы является контроль корректного отражения хозяйственных операций на бухгалтерских счетах. Также работники из проверяющих органов и аудиторских фирм требуют (просят) показать отражение хозяйственных операциях на счетах бухгалтерского учета по определенному (определенным) первичному документу.

Цитата:

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

Рискну предположить, что в данном случае опять работает логика 1С. Пользователи на ментальном уровне не не делают разницы между проводками по модулю и в ГК, поэтому содержимое полей коррекции для них остаётся за кадром. Вот и надо делать всяческие ухищрения.

С точки зрения бух.учета Главная книга это синтетический регистр, модульные проводки это аналитические регистры. Равенство между синтетическим регистром и аналитическими регистрами – это требование действующего законодательства. Это требование выполняется, но отсутствует наглядность данного равенства. В штатном варианте получается некое подобие черного ящика: да коррекция есть, но она вот отражается отдельной проводкой. Причем не просто отдельной проводкой, а общим чехом за период свернутой до корреспонденции с учетом финансовых аналитик.
Просьба высказать положительные и отрицательные моменты по двум направлениям: доработка отражения коррекции и второе – использование дополнительной таблицы. И что не учел в двух случаях. А также другие взгляды на решение данной задачки.

[Logger]

Цитата:

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

Верно понимаю вашу мысль?

Да примерно так.
Можно даже отдельную времянку не заводить, а просто сделать LedgerTrans.setTmp() и заполнить её нужным образом и отображать в той же форме проводок.

[fed]

Я аналогичную задачу решал более простым способом:
1. Курочился рассчет мгновенной себестоимости списания, таким образом чтобы таковая всегда была равна нолю. Соответственно - себестоимость прихода(в том случае если встречный приход создавался - например в журнале спецификаций) тоже равнялась нолю и проводки списания/прихода просто не создавались. (Хотя номер ваучера и резервировался и писался в inventTrans/inventTransPosting).
2. Разноска коррекций (InventAdjPost) была переписана так, чтобы обороты считались и разносились не в разрезе ваучера закрытия склада, а в разрезе исходного ваучера. Никто не мешает в момент разноски создать объект ledgerVoucher, с уже использованым номером ваучера, проверку на дублирование можно безнаказанно отключить.
В итоге - бухгалтера получали свою любимую проводку списания в исходном документе. При отмене закрытия/пересчета, сторно тоже пишется в исходном документе. (Бухгалтера этого не любят, но жить с этим могут).

Хотя в стратегическом плане, если подобная задача возникла, лучшее решение - это подыскать другую работу

[Logger]

Цитата:

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

Хотя в стратегическом плане, если подобная задача возникла, лучшее решение - это подыскать другую работу

Ну так ведь легко и без работы остаться.
Не знаю как у вас в Турции, а в России кризис в IT никуда не делся.

По поводу простого способа - не соглашусь. Мне кажется отображать проводки в LedgerTrans другим способом легче в реализации и безопаснее в случае ошибок при программировании.

[greenfin]

Всем спасибо за ответы. «Пойдем» по пути использования временной таблицы.