Корректировки в проводках закрытия склада

[Sergey Petrov]

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

Суть в следующем: склад закрываем ежемесячно после второго рабочего дня месяца. Используется закрытие склада с использованием алгоритма "средняя на дату".

Пользователи заметили, что по одной из номенклатурных позиций себестоимость завышена аж в 7 с лишним раз. Полез разбираться - выясняется следующая картина:

Есть складская проводка списания со ссылкой "Средневзвешенное закрытие запасов". В поле складской проводки "Количество" имеем -268 шт. В поле "Фин. сумма" складской проводки имеем -699.63 EUR. В поле "Корректировка" имеем аж -4006.88 EUR. "Сопоставленное количество" целых -556 шт. Соответственно, "Сумма сопоставления" -4706.51 EUR ("Фин. сумма" плюс "Корректировка").
Смотрю в сопоставления по данной складской проводке. Вижу 3 не отменённых сопоставления с одним кодом в поле "Проводка":
Дата______Принцип_____Сопоставленное__Сумма_________Корректировка
______________________количество_______сопоставления
31.10.2010 Ср. на дату__-556_____________-1 439.86_______-740.23
30.11.2010 Ср. на дату___________________-3 270.39_______-3 270.39
02.12.2010 Ср. на дату____________________3.74___________3.74
При этом все три указанных сопоставления с галкой "Разнесено".
"Ср. на дату" в поле "Принцип" - "Средневзвешенная на дату".
Больше никаких сопоставлений (не отменённых) нет.

По номеру проводки в сопоставлении нахожу ещё одну (уже приходную) складскую проводку закрытия с такой же зашкаливающей себестоимостью и коррекциями:
В поле "Количество" этой складской проводки имеем 288 шт. (что характерно, эти 288 шт. плюс 268 шт. в расходной проводке как раз дают "Сопоставленное количество" в ней). В поле "Фин. сумма" имеем 740.23 EUR (как раз сумма корректировки в первом сопоставлении по расходной проводке). В поле "Корректировка" этой второй складской проводки имеем опять 3266.65 EUR. "Сопоставленное количество" 288 шт. как положено. Соответственно, "Сумма сопоставления" 4006.88 EUR ("Фин. сумма" плюс "Корректировка").
Смотрю в сопоставления по этой складской проводке. Вижу опять 3 не отменённых сопоставления с тем же кодом в поле "Проводка":
Дата______Принцип_____Сопоставленное__Сумма_________Корректировка
______________________количество_______сопоставления
31.10.2010 Ср. на дату___288_____________740.23
30.11.2010 Ср. на дату___________________3 270.39
02.12.2010 Ср. на дату___________________-3.74
При этом все три указанных сопоставления БЕЗ галки "Разнесено".
"Ср. на дату" в поле "Принцип" - "Средневзвешенная на дату".
Кроме того, в неотменённых сопоставлениях по этой же приходной складской проводке закрытия имеются ещё 2 сопоставления (уже с другими кодами в поле "Проводка"):
Дата______Принцип_____Сопоставленное__Сумма_________Корректировка
______________________количество_______сопоставления
30.11.2010 Коррект.____________________________________3 270.39
02.12.2010 Коррект.____________________________________-3.74
При этом оба указанных сопоставления с галкой "Разнесено".
"Коррект." в поле "Принцип" - "Корректировка".

Подобных "наборов" складских проводок несколько. Плюс к тому были перемещения на другой склад, так что, всё это ещё и не по одному складу...

Итак, вопросы: что бы всё это значило? И как понять, что послужило причиной столь существенных корректировок? Как её можно вычислить? Что делать с данной номенклатурной позицией, у которой себестоимость так завышена?

Заранее благодарю за помощь и внимание!

P.S. Прошу прощения за доморощенные "таблицы" - не нашёл в инструментарии создания сообщений как можно вставить таблицы в текст.

[Logger]

А в чем проблема, собственно ? Большая корректировка - не есть ошибка. Нужно смотреть на сумму корректировки и изначальной суммы проводки, т.е. InventTrans.costamountPosted + InventTrans.costamountAdjustment
Если она нормальная, не скачет, то можно не волноваться.

Посмотрите также тут :
Denis Fedotenko: Себестоимость и закрытие склада

и поправьте опечатки в тегах к теме.

[Sergey Petrov]

Спасибо, уважаемый Logger.
В складской проводке списания по закрытию склада InventTrans.CostAmountPosted ("Фин. сумма") = -669.63 EUR. В той же проводке InventTrans.CostAmountAdjustment ("Корректировка") = -4006.88 EUR. Если бы не было корректировки, то сумма сопоставления и пр. сомнення не вызвали бы. InventTrans.CostAmountPosted - вполне адекватная величина. Проблема именно в возникшей корректировке и её источнике.

Не совсем уловил, что не так в тэгах. Но это - детали.

[Geo]

Вопрос: себестоимость чего именно завышена?
Буквально пару дней назад обнаружил, что стандартные складские отчеты неправильно обрабатывают это самое "Средневзвешенное закрытие запасов". Может быть, дело в отчетах?

Автогенерящиеся проводки типа "Средневзвешенное закрытие запасов" - это новое в АХ 2009. Похоже, что отчеты поправить они забыли...

[Sergey Petrov]

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

История следующая: в одном из подразделений создали Заказ на продажу. При попытке его отгрузки система сообщила об отрицательной доходности по Заказу. Доходность определяется из сравнения цены, установленной в строке Заказа на продажу, и себестоимости зарезервированного лота на складе (себестоимость оказалась выше цены). Стали разбираться, почему себестоимость именно такая на складе - выяснилось, что по складским проводкам товар пришёл на этот склад с уже завышенной себестоимостью. Пришёл он ещё в октябре (то есть, на момент, когда выяснилась кривизна себестоимости склад уже был неоднократно закрыт).
Перемещения между складами выполняются с использованием Заказов на перемещение (это - функционал, введённый в DAX2009). При этом используется наша доработка, позволяющая увеличивать себестоимость товара на сумму ТТИ в момент его оприходования на целевой склад (себестоимость приходной проводки на целевой склад увеличивается на рассчитываемую сумму ТТИ).
Стал искать, откуда на склад пришло такое дорогое чудо и выяснилось, что себестоимость завышена у целой цепочки проводок. Про проводки закрытия склада на складе-источнике Заказа на перемещение я уже писал.

Теперь про те проводки, которые относятся непосредственно к строкам самого Заказа на перемещение.
Для всех складских проводок, связанных с данной проблемной строкой Заказа на перемещение, имеются сопоставления, выполненные при закрытиях склада (было уже 2 закрытия и оба там "отметились").
Везде закрытия склада вносят корректировки.
Сопоставленных количеств по приходным проводкам на целевой склад нет нигде.
Сопоставленные количества по остальным проводкам совпадают с количествами в самих проводках только в сопоставлениях, выполненных первым закрытием склада (октябрь закрывали). Второе закрытие склада вызывает только корректировки без сопоставленных количеств.
Все эти сопосталения "Разнесены".
Приходные складские проводки на целевой склад "открыты" (InventTrans.ValueOpen = NoYes::Yes). Все остальные "Закрыты".
Сравнил с аналогичными проводками по другим строкам того же Заказа на перемещение.
Для приходных проводок на целевой склад закрытие склада вообще не выполняло сопоставлений (сопоставления типа "Корректировка" только те, которые "накручивают" ТТИ в нашем самописном функционале при оприходовании товара на целевой склад).
Для проводок по транзитному складу есть сопоставления типа "Маркировка", выполненные при закрытии склада (одном, предпоследнем, которое октябрь закрывало).
Для расходных проводок со склада-источника есть сопоставления типа "Средневзвешенная на дату", выполненные также при закрытии склада (одном, предпоследнем).
Приходные складские проводки на целевой склад "открыты" (InventTrans.ValueOpen = NoYes::Yes). Все остальные "Закрыты".

ВОПРОС: может ли закрытие склада откорректировать себестоимость в складских проводках, относящихся к строкам Заказа на перемещение (лоты в проводках по строке Заказа на перемещение разные)? Как определить источник, откуда система берёт сумму корректировки (было уже два закрытия и оба вызвали корректировки, других поступлений на целевой склад из Заказа на перемещение не было)?

[fed]

Я бы начал разбираться с выяснения того - каким образом, фиктивный перенос получил сопаставленное количество БОЛЬШЕЕ чем количество по переносу. Все остальное - скорее всего просто следствия.
Я по аналогичной проблеме переписывался с одним португальцем. У него тоже сопоставленные количества поплыли и он пытался найти источник проблемы. Я ему заочно помочь не смог, но спустя какое-то время он мне написал что проблема решилась сама собой после установки какого-то последнего RollUp. Я посмотрел изменения закрытия на SYP-слое в RU5 и обнаружил там пару изменений, относящихся к средней. Наиболее интересное изменение связано с обработкой крахов сервера. То есть - в недрах закрытия есть некий код, ответственный за обработку ситуации при которой у нас закрытие было остановлено на лету из за перезагрузки сервера БД (например) и система должна продолжить закрытие, повторно использовав созданную проводку фиктивного переноса. В ru5 (может и в более ранних) есть мелкое изменение в обработке этой ситуации. Я, правда, не понял как оно может повлиять, но все равно - каким-то образом, совокупность правок в свежих rollupах правит эту проблему...

[Ivanhoe]

Вот вы все про систему спрашиваете. А у вас вон какая "чудесная" доработка сделана! В стандарте по перемещениям нельзя сделать корректировку прихода (на форуме обсуждалось не единожды). Тестируйте доработку, %90 что виновата именно она.

[Ivanhoe]

Цитата:

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

Вопрос: себестоимость чего именно завышена?
Буквально пару дней назад обнаружил, что стандартные складские отчеты неправильно обрабатывают это самое "Средневзвешенное закрытие запасов". Может быть, дело в отчетах?

Речь про стандартные отчеты? Подскажи, плиз, чтобы на грабли не наступить.

[Sergey Petrov]

Цитата:

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

Я посмотрел изменения закрытия на SYP-слое в RU5 и обнаружил там пару изменений, относящихся к средней. Наиболее интересное изменение связано с обработкой крахов сервера. То есть - в недрах закрытия есть некий код, ответственный за обработку ситуации при которой у нас закрытие было остановлено на лету из за перезагрузки сервера БД (например) и система должна продолжить закрытие, повторно использовав созданную проводку фиктивного переноса. В ru5 (может и в более ранних) есть мелкое изменение в обработке этой ситуации.

Да, да, да, было дело! Пришлось отменять закрытие один раз (как раз закрытие октября), потому что оно пошло не через пакетный сервер, а на локальном клиентском компе.
Уважаемый fed, не могли бы Вы поподробнее про изменения на SYP-слое в RU5?

[fed]

Цитата:

Сообщение от Sergey Petrov

Да, да, да, было дело! Пришлось отменять закрытие один раз, потому что оно пошло не через пакетный сервер, а на локальном клиентском компе.
Уважаемый fed, не могли бы Вы поподробнее про изменения на SYP-слое в RU5?

Может быть - проще его прямолинейно перелить на ваше приложение и посмотреть ? В международной версии, по большому счету, три изменения:
1. Иначе считается открытое количество на дату. Если проводка была финансово обновлена ПОСЛЕ даты закрытия, то возвращается ноль
2. Для всех складских моделей КРОМЕ средней - берется финансовая дата, вместо физической
3. В операции восстановления после рухнувшего закрытия, проводка с фиктивным переносом ищется по финансовой дате, вместо физической (хотя с другой стороны - они, вроде бы, должны быть всегда равны).

Есть подозрение что пункт 1 на самом деле был подправлен еще в sp1.
В российской версии добавилось еще НЗП, которое, в вашем случае, категорически не рекомендуется к переносу (оно, помниться, отключается функциональным ключем - так что можно просто не переносить всю эту ветку).

[Sergey Petrov]

Цитата:

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

Я бы начал разбираться с выяснения того - каким образом, фиктивный перенос получил сопаставленное количество БОЛЬШЕЕ чем количество по переносу. Все остальное - скорее всего просто следствия.

Большое спасибо, fed, за мысль. Вытащил я такие проводки (Abs(InventTrans.Qty) < Abs(InventTrans.QtySettled)). Их оказалось у нас не много, но и не мало - 10 проводок по 10 разным номенклатурным позициям. Все проводки по закрытию склада. Все в одном месяце (октябрь злополучный). Все открытые.

"Кто виноват" - мы с этим вроде как определились. Теперь следующий вопрос, всегда следующий в паре - "что делать?"...
Обновление приложения, надеюсь, даст нам защиту от таких неприятностей в дальнейшем. Но что можно предпринять сейчас в сложившейся ситуации? Есть какие-нибудь соображения на сей счёт?
1. Есть ли какие-нибудь штатные средства для решения проблемы (чтобы в дальнейшем прекратить корректировки при закрытии склада по этим и связанным с ними проводкам)?
2. Что делать с денежными средствами, которые система на всё это откуда-то брала при каждом закрытии склада (коих уже 2)?

Заранее огромное спасибо за помощь!

[fed]

Может быть - попробовать отменить закрытия склада и попробовать руками удалить эти самые фиктивные переносы вместе со всеми сопоставлениями в которых они участвовали ? Если я правильно понимаю - при отмене закрытия система их самостоятельно не удалит...

[Sergey Petrov]

Цитата:

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

Может быть - попробовать отменить закрытия склада и попробовать руками удалить эти самые фиктивные переносы вместе со всеми сопоставлениями в которых они участвовали ? Если я правильно понимаю - при отмене закрытия система их самостоятельно не удалит...

Надо попробовать на тестовых данных. Разверну последний бэкап и откачу последние два закрытия - за ноябрь и декабрь. Посмотрим, что останется в проводках закрытия и в сопоставлениях по ним. Я так полагаю, что все сопоставления, имеющиеся на данный момент, будут после отката закрытия с галкой "Отменено" (но они всё-таки будут). Вопрос в том, каким путём система пойдёт при повторном запуске закрытия склада. Будет ли снова создавать эти "странные" сопоставления с бОльшими, чем нужно, количествами и дикими коррекциями, или всё вернёт в нормальное состояние. В последнем я почему-то сомневаюсь... Иначе, почему бы ей с первого раза всё не закрыть как положено после прерывания закрытия склада, которое имело место?...

Ещё один, скорее риторический, вопрос - если отменить два имевших место закрытия (за ноябрь и октябрь), а потом закрывать сразу по конец ноября - можно ли так делать? Или снова закрывать по-месячно?

[fed]

Цитата:

Сообщение от Sergey Petrov

Ещё один, скорее риторический, вопрос - если отменить два имевших место закрытия (за ноябрь и октябрь), а потом закрывать сразу по конец ноября - можно ли так делать? Или снова закрывать по-месячно?

Эээ. Можно попробовать. Поскольку средняя на дату считается на дату , то можно попробовать просто тупо закрыть весь период одним закрытием.

[Sergey Petrov]

Спасибо за поддержку, fed!
Завтра займусь техническими и изыскательскими вопросами. Результаты обязательно опубликую здесь.

[fed]

Цитата:

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

Вот вы все про систему спрашиваете. А у вас вон какая "чудесная" доработка сделана! В стандарте по перемещениям нельзя сделать корректировку прихода (на форуме обсуждалось не единожды). Тестируйте доработку, %90 что виновата именно она.

Я как-то разбирался с возможностью подобной доработки. Никаких противопоказаний не нашел. То есть - это не очень идейно (поскольку по всяким там GAAPам нельзя транспортные расходы между складами вешать на себестоимость), но при аккуратном исполнении - вполне безобидно. Да и к слову сказать, учитывая что в аксапте нету нормальных закупок/продаж с точкой консигнации, и их приходиться через перемещения модулировать - может и не так уж это безидейно...

[Ivanhoe]

Цитата:

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

Я как-то разбирался с возможностью подобной доработки. Никаких противопоказаний не нашел. То есть - это не очень идейно (поскольку по всяким там GAAPам нельзя транспортные расходы между складами вешать на себестоимость), но при аккуратном исполнении - вполне безобидно. Да и к слову сказать, учитывая что в аксапте нету нормальных закупок/продаж с точкой консигнации, и их приходиться через перемещения модулировать - может и не так уж это безидейно...

Насчет "идейности" согласен. И доработка зачастую полезная. Ключевое в моем посыле "аккуратное исполнение". Автор же априори считает, что проблема в стандарте, а не в модификации.

[Sergey Petrov]

Цитата:

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

Автор же априори считает, что проблема в стандарте, а не в модификации.

Уважаемый Ivanhoe, мои выводы основаны на том, что изначальнная себестоимость по приходным складским проводкам в строке Заказа на перемещение, образованная нашим доморощенным функцоналом (без коррекций), довольно адекватна.
Неадекватные коррекции появляются при закрытии склада и при пересчёте склада (коррекции без количеств, о которых я упоминал, - следствие перечсёта складов по указанной номенклатурной позиции (вычитал в общепризнанном бестселлере - статье fed о закрытии склада)).

[Sergey Petrov]

Прошу помощи, коллеги!
Отмена на тестовом приложении последнего закрытия склада сегодня идёт целый день.

Может, я как-то не так его выполняю? Что делал: нашёл в "Закрытии и коррекции" соответствующую запись (тип "Закрывающий"), нажал кнопку "Отмена", в открывшенмся окне выбрал "Отменить операцию" и поставил всё в пакет. Пакет выполняется уже 7 часов.

В форме с пакетными заданиями просмотр задач даёт странную картину:задача "Отмена - Начать" уже завершена; задача "Отмена - Завершить" в статусе "Ожидание"; куча задач "Обработка элемента ..." в статусе "Готово". Что с этой феерией делать?

Сама задача в статусе "Выполнение". Процент выполнения = 0,03.

[fed]

Извиняюсь за наивный вопрос - а вы уверены что у вас не упал батч-сервер, который все это обрабатывает ? Задачи "Обработка элемента" порождаются на каждое сочетание "Номенклатура-Ваучер закрытия-Дата закрытия", которые система находит в отменяемом закрытии. "Отмена-завершить" ждет завершения всех пакетов по отмене сопоставлений по отдельной номенклатуре. То что эти пакеты находяться в статусе "Готово", но не переходят в статус "Исполнение", может говорить либо о том что у вас тупо упал батч-сервер, либо о том что вообще нету батч-сервера, который обслуживал бы соответствующую пакетную очередь (которую было бы неплохо посмотреть в параметрах батча). Правда учитывая, что у задачи обработки элемента и задача завершения, наследуют эту очередь из задачи инициализации, не очень понятно на каком именно сервере тогда инициализация отработала.