Axapta не умеет правильно считать себестоимость складских переносов и заказов на перемещение

[iknutov]

Возможно это тема уже звучала, но мне бы хотелось описать свое решение этой задачи. Была сделана доработка класса InventCostItemDim. Разработка не сложная, правда работает очень хороша. В результате запуска пересчета склада система выравнивает себестоимость прихода и расхода. Данная проблема возникает у тех компаний, которые используют партионный учет и метод расчета себестомисости ФИФО. Я выложил проект. Правда в нем две таблицы и два класса. Таблица InventParameters не нужна, там только галочка, которая включает функционал альтернативного пересчета. Ее импортировать не нужно. В проекте еще два класса InventUpd_Financial и сам класс пересчета склада InventCostItemDim. Класс InventUpd_Financial я изменил для того, чтобы в момент разноски переноса себестоимость прихода партии была равна себестоимости расхода по партии. Кто не знает: если мы перемещаем что то с одного склада на другой без указания конкретной партии, то при перемещении нескольких партий одновременно себестоимость прихода усредняется. Общая стоимость прихода равна общей стоимости расхода, но в разрезе партий все выглядит плачевно.

[gl00mie]

Цитата:

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

Класс InventUpd_Financial я изменил для того, чтобы в момент разноски переноса себестоимость прихода партии была равна себестоимости расхода по партии. Кто не знает: если мы перемещаем что то с одного склада на другой без указания конкретной партии, то при перемещении нескольких партий одновременно себестоимость прихода усредняется. Общая стоимость прихода равна общей стоимости расхода, но в разрезе партий все выглядит плачевно.

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

[Raven Melancholic]

Эта проблема, действительно, давно известна. В DAX2009 даже запретили по одной строке переноса проводить несколько складских проводок если в них отличаются аналитики, входящие в финансовый склад.
Исправление только для частного случая, действительно, простое, даже если затронуть закрытие склада.
Проблемы начинаются тогда, когда рассматриваешь общие случаи, связанные с тем, что журнал переноса предназначен не только для перемещения между складами, а все остальное что в расходе, что в приходе остается тем же самым.
Например, перенос создан как раз для того, чтобы выполнить изменение партии или серийного номера (какой-нибудь пересорт).

[fed]

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

[Logger]

Цитата:

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

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

Если делать универсальное решение, то надо делать аналог бухгалтерской корреспонденции счетов. Тогда протаскивать себестоимость будет просто - для каждой расходной проводки внутри лота можно будет однозначно найти приходную проводку по ключу InventTransId + Bond.

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

А кто-нить разбирался как с этим дело обстоит в 2012-й ?

[fed]

Цитата:

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

А кто-нить разбирался как с этим дело обстоит в 2012-й ?

Там точно такой же костинг как в 2009ой. В 2012R2 соптимизировали закрытие склада на предмет лучшей балансировки нагрузки между хелперами (но попробовать пока не удалось). Кроме того - сделали новый вариант средней (на основе стандартной). То есть - никаких сопоставлений и закрытий по этой средней нету, а есть что-то типа стандартной себестоимости у которой в конце периода считается и задним числом поститься новая средняя. (Но в деталях могу сильно заблуждаться - я пока в коде новой средней не копался).

[iknutov]

Я с этой проблемой сталкиваюсь на всех проектах. Восприятия со стороны заказчика разные, но в целом негативные. То что делает аксапта это просто нарушение партионного учета. Решали по разному. Сейчас это решение можно расширить. Например определить набор складаких аналитик по которым ведется финансовый склад и для них создавать ключ. Мне кажется все будет прекрасно работать. Я тестировал, все выглядит даже лучше чем ожидал.

[iknutov]

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

[iknutov]

Закрытие склада или пересчет как раз и ориентированы на среднюю по партиям в перемещениях. Так код стандартный написан.

[Ivanhoe]

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

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

[iknutov]

На проблему можно еще глубже посмотреть. Если сделать перемещение количества, которое перекрывает несколько партий, потом сделать резервирование, далее несколько раз изменяем количество в меньшу и большую сторону. Открываем складские проводки и видим просто хаос. Полное несоответствие по количеству. Чтобы вернуть все назад ставим количество 0, потом возвращаем количество назад. Только после этого все возвращается в нормалтное русло. Пользователям конечно трудно это объяснить. Но это требуется для партионного учета.

[iknutov]

Как вы себе представляете переместить около 500 строк или более. А еще если пользователь сначала готовит журнал, потом в конце дня делает резерв и разносит журнал. Не реально. Либо с этим дружить либо доработать. Мне было легче переделать.

[Logger]

Цитата:

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

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

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

Не ожидал от вас такого.
Посмотрите, вот здесь
пересчет себестоимости в журналах переноса?
вроде все перетерли уже.

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

Все остальное - это неудачные попытки аналитиков убедить себя (в первую очередь) и заказчиков, что описанные ситуации - это, мол, всего лишь проблемы в головах пользователей, а не в Аксапте.

Самое обидное что при желании это лечится сравнительно несложно. Но никому это не надо.

[Logger]

Цитата:

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

На проблему можно еще глубже посмотреть. Если сделать перемещение количества, которое перекрывает несколько партий, потом сделать резервирование, далее несколько раз изменяем количество в меньшу и большую сторону. Открываем складские проводки и видим просто хаос. Полное несоответствие по количеству. Чтобы вернуть все назад ставим количество 0, потом возвращаем количество назад. Только после этого все возвращается в нормалтное русло. Пользователям конечно трудно это объяснить. Но это требуется для партионного учета.

см. еще :
Резервирование при переносе

Кстати, если не ошибаюсь в заказах на перемещение в 2009-й этой проблемы нет. А в переносах осталась. Я при переходе на 2009, просто применил код от перемещений с небольшими доработками к журналам переносов и все нормально работает без проблем.

Кстати если делать подобие корреспонденции, о чем я выше писал, то оно не только для себестоимости поможет. но и для вышеописанной ситуации с переносами.

[iknutov]

Цитата:

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

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

Я думаю, что вопрос с корреспонденцией не сложный даже простой. После чего можно смело применять ее в пересчете. Я подумаю и возможно сделаю.

Цитата:

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

см. еще :
Резервирование при переносе

Кстати, если не ошибаюсь в заказах на перемещение в 2009-й этой проблемы нет. А в переносах осталась. Я при переходе на 2009, просто применил код от перемещений с небольшими доработками к журналам переносов и все нормально работает без проблем.

Кстати если делать подобие корреспонденции, о чем я выше писал, то оно не только для себестоимости поможет. но и для вышеописанной ситуации с переносами.

[fed]

Цитата:

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

Все остальное - это неудачные попытки аналитиков убедить себя (в первую очередь) и заказчиков, что описанные ситуации - это, мол, всего лишь проблемы в головах пользователей, а не в Аксапте.

Много раз высказывал свое мнение: Партионный учет применим только при производстве/продажах уникальной единичной продукции, которую бочками не продают и автоматически не резервируют. Поэтому при правильном подходе к учету проблема не возникает.
Нет - я конечно сталкивался с, гм, дятлизмом, российских бухгалтеров, проигрывал политические битвы и писал проектные затычки. Но как я всегда говорю - не надо путать проектные затычки и универсальное решение.
Кстати - чтобы поддержать дискуссию: А раскажите, как вы собираетесь создавать, поддерживать и обновлять (при всяких там расщеплениях транзакций), эту корреспонденцию аналитик? Как будете заполнять и обновлять проценты (модифицируемые и подставляемые по умолчанию) распределения для этой корреспонденции?

[iknutov]

Цитата:

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

Много раз высказывал свое мнение: Партионный учет применим только при производстве/продажах уникальной единичной продукции, которую бочками не продают и автоматически не резервируют. Поэтому при правильном подходе к учету проблема не возникает.
Нет - я конечно сталкивался с, гм, дятлизмом, российских бухгалтеров, проигрывал политические битвы и писал проектные затычки. Но как я всегда говорю - не надо путать проектные затычки и универсальное решение.
Кстати - чтобы поддержать дискуссию: А раскажите, как вы собираетесь создавать, поддерживать и обновлять (при всяких там расщеплениях транзакций), эту корреспонденцию аналитик? Как будете заполнять и обновлять проценты (модифицируемые и подставляемые по умолчанию) распределения для этой корреспонденции?

Специально поддерживать ничего не требуется. При любом новом проекте происходит обновление модификации. О каких процентах идет речь? Все расщепляется автоматически при резервировании партии.

[fed]

Цитата:

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

Специально поддерживать ничего не требуется. При любом новом проекте происходит обновление модификации. О каких процентах идет речь? Все расщепляется автоматически при резервировании партии.

А если я списываю две партии, а приходую три ? (причем все разные). А поддерживать предполагается не обновление, а вот эту самую таблицу корреспонденций между приходными и расходными проводками, которую тут предложили...

[Logger]

Денис, я подумаю над твоими вопросами.
Ты правильно заметил, что сам механизм корреспонденции - самое сложное место в данном случае.

[iknutov]

Цитата:

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

Денис, я подумаю над твоими вопросами.
Ты правильно заметил, что сам механизм корреспонденции - самое сложное место в данном случае.

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