![]() |
#1 |
Участник
|
Закрытие склада. Разъехались InventSettlement и LedgerTrans
Привет всем.
Ковырял закрытие склада, обнаружил странное поведение : Простановки отметки о разнесенности InventSettlement \Classes\InventAdjustPostClosing\updatePosted ставится для любых записей с ненулевой коррекцией : X++: update_recordset inventSettlement setting posted = NoYes::Yes where inventSettlement.TransDate == transDate && inventSettlement.Voucher == voucher && inventSettlement.CostAmountAdjustment != 0 // <GEEU> && inventSettlement.InventTransCurrency_RU == this.inventTransCurrency_RU() // </GEEU> && inventSettlement.Posted == NoYes::No && inventSettlement.Cancelled == _canceled; (см. \Classes\InventAdjustPostClosing\updateItem и далее по коду) идет только для непустых InventSettlement.BalanceSheetAccount InventSettlement.BalanceSheetPosting OperationsAccount.OperationsAccount OperationsAccount.OperationsPosting Что очень странно. У нас это привело к тому что суммы коррекций в InventSettlement разошлись на сотни рублей с суммами разнесенными в LedgerTrans. Проблема проявилась для переносов. Как посоветуете лечить ? 1. Заполнять принудительно BalanceSheet* и Operations* поля ? 2. Поправить постирование InventSettlement ? 2-й способ кажется более надежным. Но похоже изначально в архитектуру закрытия склада и проведения коррекций была заложена возможность оставлять счета пустыми. Не хочется ломать систему об колено... P.S. Dax 2009 SP5 |
|
![]() |
#2 |
Moderator
|
А зачем сравнивать эти две суммы ? Просто мысленно переименуй Posted в Processed и все станет на места. А если вы сделали отчеты для сравнения inventSettlement и LedgerTrans, то просто добавьте в условия фильтрации проверку на пустоту счетов и коррсчетов и разносок по счету и коррсчету.
|
|
![]() |
#3 |
Участник
|
Пожалуй, ты поспешил с ответом. Не могу согласится с таким подходом.
Это эквивалентно тому, что мы отказывается от какой либо корреляции между модулем управление запасами и главной книгой. |
|
![]() |
#4 |
Moderator
|
Мы не отказываемся от корреляции. Просто галочка inventSettlement.posted говорит не о том что реально какие-то проводки ГК были созданы, а о том что запись была обработана модулем разноски. А для сверки с ГК надо проверять комбинацию posted+Account+OffsetAccount+Posted+OffsetPosting. Просто изначально имя поля posted было выбрано неудачно и это создает впечатление что оно действительно помечает сопоставления разнесенные в ГК. Назвали бы 'Processed' - путаницы бы не было.
|
|
![]() |
#5 |
Участник
|
Ага.
Но у меня вопрос связан не с названием поля InventSettlement.posted Возможно я не совсем понятно проблему описал. Можно вообще поле posted выкинуть из рассмотрения. Суть в том, что возможна ситуация, когда в InventSettlement.costAmountAdjustment ненулевая коррекция (и, соответсвенно, в поле InventTrans.CostAmountAdjustment), и пустые счета разноски InventSettlement.BalanceSheetAccount и InventSettlement.OperationsAccount. Это приводит к тому, что двигается себестоимость в модуле управления запасами, но нет соответствующих проводок в LedgerTrans. Я считаю это неправильно. Легко получить ситуацию когда весь товар продан в 0, а на счете учета запасов (10, 41 и.т.п.) болтается остаток. Ну и множество других вариаций. ![]() |
|
![]() |
#6 |
Moderator
|
И между прочим, inventAdjustPosting пропускает записи с пустыми счетами и разносками не потому что это баг, а потму что это коррекции к складским проводкам, по которым исходная операция принципиально не разносилась в ГК (карантинные заказы, WMS-заказы, переносы внутри одного сайта и тп). Причем под "принципиально не разносились" подразумевается что они не разнеслись не потому что себестоимость была нулевая, а просто в силу своего эконоимического смысла. Если ты в такие коррекции начнешь счета писать или просто сломаешь разноску чтобы в ГК всегда разносилось, то у тебя породятся коррекции по операциям, которые в ГК не попали.В этом случае будет куча левых проводок между складскими счетами и счетами прибылей и убытков. По складским счетам этих левых оборотов будет нулевым, но поскольку P/L не сальдируется, бухгалтера тебе спасибо не скажут
![]() |
|
![]() |
#7 |
Участник
|
Цитата:
И между прочим, inventAdjustPosting пропускает записи с пустыми счетами и разносками не потому что это баг, а потму что это коррекции к складским проводкам, по которым исходная операция принципиально не разносилась в ГК
Я имею в виду что способ лечения был неудачный. Ценой разваливания сумм по модулям. Зачем тогда функционал выверки нужен ? Ведь почему переносы не разносились в ГК ? - Они по смыслу не должны были менять себестоимость в модуле управления запасами. По ним даже коррекция проводок невозможна. Но если возникает ситуация когда сумма приходной и расходной части переноса не дает 0, то уже надо разносить. Т.е. это просто баг реализации по отключению разноски. Замели под половичок и ладно. Можно кровотечение из носа прекратить, перетянув шею жгутом ? Конечно. Но... Надо все равно в ГК разносить операции по которым есть коррекция. Например на счета учета ошибок InventAdj::errorAccountBalanceSheet() InventAdj::errorPostingOperations() В подавляющем большинстве случаев, перед разноской в ГК, после группировки сумм в Inventsettlement плюсы и минусы от переносов закрываются в 0, исключение - всякая экзотика, типа ошибок округления, которая приводит к неравенству приходной и расходной части переноса. Она и вылезет на счета прибылей и убытков. Т.е. не будет никаких гигантских оборотов по дебету и кредиту. (Я нигде не предлагал постировать в ГК разноску переносов) |
|
![]() |
#8 |
Участник
|
Цитата:
Сообщение от Logger
![]() В подавляющем большинстве случаев, перед разноской в ГК, после группировки сумм в Inventsettlement плюсы и минусы от переносов закрываются в 0, исключение - всякая экзотика, типа ошибок округления, которая приводит к неравенству приходной и расходной части переноса. Она и вылезет на счета прибылей и убытков. Т.е. не будет никаких гигантских оборотов по дебету и кредиту.
Не очень хорошо получается, (но по крайней мере лучше чем просто выкинуть суммы из разноски). Можно попробовать одну из половинок переноса как сторно проводить, тогда валюта баланса не поедет. Либо InventSettlement не трогать, а просто разносить в ГК записи InventSettlement с пустыми счетам ГК - назначая им какие-то условленные счета, например счета учета ошибок и сворачивая дебет и кредит. Вот тогда получится, что и оборотов лишних не будет. И суммы все разнесутся. Последний раз редактировалось Logger; 12.08.2014 в 11:28. |
|
![]() |
#9 |
Moderator
|
Если ты борешься с cитуацией, когда себестоимость прихода и расхода в переносе не равны - то это последствия принципиального архитектурного бага в пересчете склада. Если не хочется ломать закрытие намертво - могу порекомендовать делать все пересчеты с очень большим количеством итераций (типа 200 - для этого надо поломать проверку числа итераций - это не страшно).
Если хочется решать проблему более капитально - надо слегка дописать закрытие чтобы перед началом первой итерации (то есть - первой итерации которая себестоимость прогоняет, а не проводки сопоставляет), оно рассчитывало бы разницы между приходными и приходными проводками по всяческим переносам и производствам, а потом эту коррецию стандартным механизмом применяло бы к приходным проводкам. Последний раз редактировалось fed; 12.08.2014 в 12:18. |
|
|
За это сообщение автора поблагодарили: Logger (20). |
![]() |
#10 |
Участник
|
Цитата:
Сообщение от fed
![]() Если ты борешься с митуацией, когда себестоимость прихода и расхода в переносе не равны - то это последствия принципиального архитектурного бага в пересчете склада. Если не хочется ломать закрытие намертво - могу порекомендовать делать все пересчеты с очень большим количеством итераций (типа 200 - для этого надо поломать проверку числа итераций - это не страшно).
Боюсь число итераций тут не всегда поможет. Иногда по кругу бегает одна и та же сумма - не уменьшаясь. Но она, конечно, не очень большая. Единицы или десятки рублей. Редко сотни. Цитата:
Сообщение от fed
![]() Если хочется решать проблему более капитально - надо слегка дописать закрытие чтобы перед началом первой итерации (то есть - первой итерации которая себестоимость прогоняет, а не проводки сопоставляет), оно рассчитывало бы разницы между приходными и приходными проводками по всяческим переносам и производствам, а потом эту коррецию стандартным механизмом применяло бы к приходным проводкам.
P.S. Если я правильно понимаю, ты считаешь что можно не постировать в главную книгу записи Inventsettlement c ненулевым значением CostAmountAdjustment ? Про этот способ ты ничего не написал. А мне он кажется самым надежным. |
|
![]() |
#11 |
Moderator
|
Цитата:
Вообще - если там всю цепочку просмотреть, то в момент разноски исходной складской проводки, система заполняет поле inventTransPosting.isPosted. Закрытие/пересчет исходя из значения этого поля заполняют/незаполняют счета в сопоставлениях. Если разноски в ГК исходной проводки не было - коррекцию разносить тоже не нужно. |
|
![]() |
#12 |
Участник
|
Цитата:
Почему коррекцию разносить не нужно ? Переносы почему в ГК не постируются ? Потому что они ничего не меняют в себестоимости. А если по итогам закрытия сальдо по всем сопоставлениям по проводкам по переносам отлично от нуля, значит исходное предположение о том что переносы не меняют себестоимость - оказалось неверно для рассматриваемой ситуации. И тогда, очевидно, надо постировать. Т.е. то что переносы не постируются, это не аксиома, а следствие предположения, что они ничего не должны менять в себестоимости. Но оно оказывается не всегда верно. |
|
![]() |
#13 |
Moderator
|
Переносы меняют себестоимость. Просто в стандартной аксапте считается что только разные сайты соответствуют разным счетам бухгалтерского учета. Ну и поскольку счет хранения объекта не меняется, то проводку создавать не обязательно. С изменением или неизменением себестоимости это не связано.
|
|
![]() |
#14 |
Участник
|
Ну хорошо, пусть так.
В такой терминологии - описанную мной выше ситуацию как назовем ? Если сумма коррекций по всем переносам затронутым закрытием склада не равна 0, то счет хранения объекта изменился или нет ? |
|
![]() |
#15 |
Moderator
|
Счет не изменился. Если ты товар только переносил внутри сайта, не продавал, не списывал в производство, не списывал журналом P/L, не терял в интентаризации и тп - то он так и остался на том же счете.
|
|
![]() |
#16 |
Участник
|
Денис, я не буду дальше спорить. Наверно каждый останется при своем мнении.
P.S. Напоследок все же скажу (мне кажется что ситуация очевидна, а ты, как бы поточнее выразиться, придираешься к мелочам и формулировкам, а не к сути) : Я думаю, что ситуация когда коррекция на приходную и расходную части переноса отличается, - как раз и подпадает под твое определение о смене счета. Формально счет не поменялся, но сальдо на нем изменилось. Если например был перенос между сайтами, то получится что ушла одна сумма,а пришла на другой сайт другая сумма. Теперь делаем сайт одинаковыми. Что изменилось ? Принципиально - ничего. С чего бы тогда сальдо по счету не должно уменьшится ? |
|
![]() |
#17 |
Moderator
|
По хорошему, перенос не должен к изменению суммы приводить (если это не перенос по новой стандартной себестоимости, конечно). То что это иногда случается - это баг. Есть еще вариант коррекции запасов в наличии по приходной проводке переноса, но это не перенос, а некая независимая операция.
Да и к слову сказать - проводку по переносу между сайтами сделали ТОЛЬКО для того чтобы поддержать разные стандартные себестоимости на разных сайтах. Я когда-то видел спеку на это дело. |
|
|
За это сообщение автора поблагодарили: gl00mie (5). |
![]() |
#18 |
Участник
|
Цитата:
Т.е. изначально предполагалось что номенклатура будет рассчитываться при этом по стандартной себестоимости ? И именно для этого случая все и проектировали ? Любопытно. ![]() |
|
![]() |
#19 |
Moderator
|
Именно. Просто если у тебя движения между счетами нету, но при этом со складского счета почему-то списали отклонения - это странно выглядит...
|
|
Теги |
inventsettlement, журнал переноса, закрытие склада, разноска запасов |
|
|