Заказ на продажу. Зафиксировать мгновенную себестоимость

[ena_ax]

Коллеги, есть такая небольшая проблемка.

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

Как бы все хорошо.

Но в течение месяца мгновенная себестоимость по некотрым позициям огромная, и как следствие огромноы суммы по проводкам себестоимости. Что самоо по себе не страшно, но не красиво.

Хочу привести себестоимость к примерно реальной.

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

Ax 4.0 SP2

[pitersky]

Из написанного вами я, честно говоря, вообще не увидел проблемы.
Мгновенная себестоимость зависит от PostedQty и PostedValue инвентсума. Если система получила большую себестоимость - значит, так оно по проводкам и выходит. Зачем что-то править?

[EVGL]

Может, он физическую имеет в виду?

[CDR]

Цитата:

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

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

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

[Bega]

Да, видимо больше ничего не осталось делать, как наводить красоту У нас как-то бухгалтеры хотели красивой мгновенной, но как-то удалось убедить, что не нужна она реальная. Место где она считается: InventMovement::financialIssueCostValue().

[Bega]

Цитата:

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

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

Если калькуляция произв.заказов происходит в конце месяца, то весь месяц проводки по ним идут с физическим статусом. Не очень понятно, действительно, почему она огромная, но в любом случае, без доработок она близкой к реальной никогда не будет. Разве что использовать стандартную стоимость.

[ena_ax]

Цитата:

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

Из написанного вами я, честно говоря, вообще не увидел проблемы.
Мгновенная себестоимость зависит от PostedQty и PostedValue инвентсума. Если система получила большую себестоимость - значит, так оно по проводкам и выходит. Зачем что-то править?

Представьте, что по каким то причинам, у вас PostedValue - имеет большое значение. Не важно как это получилось, например раньше же была ошибка, когда себестоимость увеличивалась по экспоненте.

Эта себестоимость отражается при разноске Заказов на продажу. Реальная себестоимость будет расчитана в конце месяца, и все огромные суммы по себестоимости списания скорректируются.
Но пока мы закроем склад, будет уже середина следующего месяца, и в этом месяце тоже огромные суммы по списанию. Если бы я мог закрыть склад последним днем месяца, то и проблем бы не было.

Другими словами, у меня мгновенная себестоимость (таких позиций немного) сильно отличается от фактической. Это я и хочу исправить.

[ena_ax]

Цитата:

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

Да, видимо больше ничего не осталось делать, как наводить красоту У нас как-то бухгалтеры хотели красивой мгновенной, но как-то удалось убедить, что не нужна она реальная. Место где она считается: InventMovement::financialIssueCostValue().

спасибо, посмотрю.

Цитата:

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

Если калькуляция произв.заказов происходит в конце месяца, то весь месяц проводки по ним идут с физическим статусом. Не очень понятно, действительно, почему она огромная, но в любом случае, без доработок она близкой к реальной никогда не будет. Разве что использовать стандартную стоимость.

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

Я предполагаю, что это временная мера, на один период.

[glibs]

Если попробовать сейчас запустить пересчет вместо закрытия, это проблему не решит?

Вы мгновенную себестоимость считаете у включением физической стоимости? Если нет, то откуда берутся завышения финансовой стоимости приходов?

[Bega]

Цитата:

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

спасибо, посмотрю.

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

[ena_ax]

Цитата:

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

Если попробовать сейчас запустить пересчет вместо закрытия, это проблему не решит?

Вы мгновенную себестоимость считаете у включением физической стоимости? Если нет, то откуда берутся завышения финансовой стоимости приходов?

Проблему не решит, так как приходные проводки еще финансово не обработаны.
Нет, физическая стоимость не участвует. У приходов нет завышенной стоимости, только у расходов.

Цитата:

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

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

понятно. буду иметь в виду.

[glibs]

Цитата:

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

...
У приходов нет завышенной стоимости, только у расходов.
...

А откуда она тогда берется у расходов?

Себестоимость остатков завышенная или нормальная?

[ena_ax]

Цитата:

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

А откуда она тогда берется у расходов?

Себестоимость остатков завышенная или нормальная?

Я выше уже писал. В какой именно момент это произошло не знаю, да это сейчас и не важно.
Закрытие склада пересчитывает себестоимость, тут все хорошо. Но делаю я это в середине следующего месяца, и в этом месяце реализация идет по завышенной себестоимости. В момент закрытия проводки закрываемого периода естественно пересчитываются, а текущего месяца нет.
Например, закрываю период сентябрь 16.10.2010.
Проводки до 30.09.2010 пересчитываются. Проводки в период 01.10.2010 - 16.10.2010 не пересчитываются. Они и вносят вклад в мгновенную себестоимость.
И так из месяца в месяц.

[CDR]

Если по складским проводкам все хорошо, может имеет смысл выполнить пересчет InventSum по нужным номенклатурам?
Пересчет InventSum

[pitersky]

Пересчёт InventSum ничего не даст - считаться будет по проводкам, а текущий InventSum из них и вышел. Да и вообще, надо не симптомы болезни лечить, а причину. Автор, найдите проводки с завышенными суммами, убедитесь, что они действительно завышенные, и если да - переоцените их. Тогда мгновенная себестоимость сама встанет куда надо.

[Biosoft]

У нас помнится из за огромной мгновенной себестоимости вообще журналы не разносились.
Проблема возникала по сырью , где идут большие вагонные поставки и существует большой разрыв по времени между физическим приходованием и финансовой разноской.
Выяснилось , что проблема возникала, когда по номенклатуре образуется относительно небольшой финансовый склад (например финансово в наличии имеем 2 тн на сумму 2000 руб), в этот момент бухгалтер разносила накладные расходы (делала коррекции на приходы) . А сумма накладных расходов по вагонным поставкам ,понятно, не маленькая , например 500 тыс .
В результате выполненной бухгалтером процедуры имеем среднюю мгновенную цену равную 251 тыс руб.