Множественная калькуляция производственного заказа

[DYPotapchenko]

Всем добрый день.
Ув. профессионалы, хотел бы задать следующий вопрос:

В третьей версии Аксапты (в стандартной - не локализованной) была возможность множественной калькуляции производственного заказа без его окончательного закрытия (не активная галочка Заключительное задание при закрытии заказа).
Затем данной функции не стало - вплоть до 5-ой Аксапты (с российским РоллАпом 4).

И только начиная с пятого РоллАпа она появилась снова (вместе с функциональностью калькуляции брака, побочной продукции - причём в двух способах расчёта: нормативном и пропорциональном).

Вопросы:

1) Кто-нибудь знает предысторию, т.е. почему сначала было в стандарте, потом убрали и добавили лишь в локализации?

2) У меня 4-ый РоллАп - обязательно ли поднимать его до пятого для получения возможности множественной калькуляции производственных заказов или есть какие-то альтернативы? Дело в том, что весь этот хороший функционал (учёт с/с брака, побочной продукции, а также выбор вариантов калькуляции с/с) - вряд ли когда-либо понадобится на текущем проекте - нужна только множественная калькуляция заказа.

Заранее спасибо.
С ув. Дмитрий

[fed]

1. Он там, помнится, изрядно глючил. Поэтому выключили его аж в одном из первых международных SP к 3.0. Я, кстати, считал что его вообще выключили в исходном международном 3.0 без service pack. Хотя после вашего сообщения засомневался. Вообще авторы просто не думали об НЗП. Функционал хоть как-то работал только в том случае, если при калькуляции незавершенка всегда была равна нолю.
2. Нет - не получится. Собственно функциональность и разрабатывалась из за НЗП (то есть - возможности нескольких калькуляций), а себестоимость брака и сопродукты - это некий полезный побочный продукт самого рассчета НЗП.

[Starling]

Цитата:

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

1. Он там, помнится, изрядно глючил.

А можно пример, на котором в 3-ке можно восстановить глюки?

[fed]

Цитата:

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

А можно пример, на котором в 3-ке можно восстановить глюки?

Биться об заклад не буду, но по моему там случались проблемы с себестоимостью по ГП если ГП принималась в разные периоды закрытия склада.

[Starling]

Цитата:

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

Биться об заклад не буду, но по моему там случались проблемы с себестоимостью по ГП если ГП принималась в разные периоды закрытия склада.

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

[fed]

Цитата:

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

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

Да, почти точно, будет работать.

[Daiver]

В случае множественного прихода из про-ва, необходимо будет допилить класс ProdUpdHistoricalCost. Перенести из 4-ки метод updateAverageReceiptPrice (в 5-ке его удалили) и вызвать его в методе updateProduction. Это нужно для того чтобы себестоимость корректно размазывалась на все приемки.

[Starling]

Позволю себе добавить:
БП следующий:
1. Компания занимается торговлей автомобилями.
2. Перед продажей все автомобили проходят предпродажную подготовку.
3. Все материальные затраты должны входить в себестоимость автомобиля.
Если выкинуть все если, то задачу можно было бы решить обычным журналом спецификаций, но…
Бывают ситуации, когда сделали предпродажную подготовку, а потом оказалось – что-то не списали (иногда планово, так как этого чего-то не было в наличии). Таких итераций может быть несколько. Это обычная практика.

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

Если каждый раз при этом создавать журнал спецификаций, то возникают циклы в расчете себестоимости, и нужная нам коррекция списывается на счета округлений.
Если бы можно было:
• создать ПЗ;
• списать на него запчасти и материалы по факту;
• рассчитать его себестоимость, но не закрывать;
• при необходимости в журнале отгрузочных накладных списать дополнительные запчасти и заново сделать калькуляцию.
Задача была бы решена.
В 3-ке я такое делал, но не на проекте, а в рамках тестовых примеров. Ошибок не помню.

На сколько сложна модификация, позволяющая вернуть возможность повторной калькуляции ПЗ. При условие, что приемка всегда 1 шт, одной складской проводкой?

З.Ы.: ну или может, кто посоветует альтернативный вариант?

[Raven Melancholic]

Модификация совершенно простая. Больше уйдет времени на реализацию всяких тонкостей для проверок (количество проверок уже зависит от требований в конкретной ситуации). Например: проверка чтобы повторная калькуляция не выполнялась раньше первоначальной, чтобы калькуляции были в пределах одного месяца (правда это больше просьбы бухгалтеров не любящих, чтобы были обороты по суммам без количества), проверка на то, что заказ был скалькулирован с флагом "Завершение" и т.п.
В трешке эта возможность сохранилась до последнего (по крайней мере в SP6 еще можно было выполнять досписание комплектующих после калькуляции).
А из вариантов: работать с отрицательным финансовым складом и выполнять калькуляцию после того, как уже четко понятно, что больше по заказу досписаний не будет.

[Starling]

Цитата:

Сообщение от Raven Melancholic

Модификация совершенно простая.

Ну тогда попробуем.

Цитата:

Сообщение от Raven Melancholic

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

Отрицательный финансовый склад уже включен, но только это не спасает, так как подобного рода досписания могут прийтись уже на следующий период. Как результат в конце периода запчасти списаны, но продалжают числится на балансе. Да и в случае, когда досписать нужно уже после реализации тоже бывают. В этом случае не получить себестоимость реализованной продукции в конце периода не есть карашо. Можно конечно поиграться с включеним физической себестоимости прихода в расчет финансовой себестоимости списания, но если модификация действительно будет простой, то я бы лучше выбрал вариант с напильником.

[Raven Melancholic]

Цитата:

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

Ну тогда попробуем.

Следует учесть, что появятся некоторые риски. Первое что приходит в голову:

• если захотите поднять какой-либо RU (например, в пятом появилось несколько "вкусностей"), то придется достаточно скрупулезно устранять конфликты кода.
• если есть какой-либо обмен с той же 1С, то придется выпутываться из-за разных подходов в "отчете производства за смену" от 1С и множественной калькуляцией в Аксе.

[Ivanhoe]

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

[Starling]

Цитата:

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

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

Рассматриваемые любые варианты)
О накладных расходах думали. У них существенный недостаток для этой схемы – они ни как не переоцениваются закрытием склада. Т.е. списали запчастей на 100 денег – отразили соответсвующую дооценку автомобиля (накладным расходом) на эту сумму. Сделали закрытие склада и оказалось, что запчастей списали на 110 денег. В этом случае на 10 денег нужно сново делать накладной расход. С накладными на продажу примерна таже сложность. Тут есть конечно варианты согласиться на некую погрешность и «хвосты» после закрытия склада просто списвыть на себестоимость реализованой продукции журналами ГК. Но пока вариант с ПЗ кажется более красивым.
По поводу модуля проекты... очень давно с ним не работал, если память не изменяет, то в 3-ке он не позволял менять себестоимость. Что он умеет делать в 5-ке в этой части?

[Ivanhoe]

Цитата:

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

Рассматриваемые любые варианты)
О накладных расходах думали. У них существенный недостаток для этой схемы – они ни как не переоцениваются закрытием склада.

Согласен.

Цитата:

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

По поводу модуля проекты... очень давно с ним не работал, если память не изменяет, то в 3-ке он не позволял менять себестоимость. Что он умеет делать в 5-ке в этой части?

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

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

[Starling]

Цитата:

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

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

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

1. О модуле проекты действительно стоит подумать, так как в перспективе будет не только предпродажная подготовка, но и послепродажное обслуживание. Где понесенные затраты будут уже себестоимостью услуги, а не себестоимостью автомобиля.
2. На сколько я помню (а помню уже плохо) в модуле проекты коррекция в результате закрытия склада списывалась на «сбоку» стоящие счета и в затраты проекта уже не входила.

Спасибо всем откликнувшимся – пока остановимся на том, что основной вариант производство, ну и про проекты тоже забывать не будем. Нужно посмотреть, что они в 5-ке умеют делать.

[Ivanhoe]

А еще начиная с 4.0 появился модуль "Сервисное обслуживание". Не ахти какая функциональность, но тоже сервисное обслуживание можно сделать (опять же, расходы привязываются к проекту).