IE2017

Производственный учет "с нуля" на конструкторе

Отраслевые решения - Производство

Эта статья не только для того, чтобы  продемонстрировать возможности конструктора виртуальных документов из поста http://infostart.ru/public/384253/ на довольно сложном примере, но также для того, чтобы показать, как можно сделать буквально на коленке прозрачный учет производства для небольших (а может, и больших) производственных предприятий. Заодно некоторые вещи, которые меня в УПП/ERP не устраивают, тут сделаны по другому.

На мой взгляд в 1С есть пробел в автоматизации небольших производств. Есть блоки производства в БП, УНФ, но у них нет тех возможностей, что в больших конфигурациях. Основная беда с УПП,ERP – отсутствие прозрачности даже если система внедрена и работает. Грубо говоря, хорошо, когда к УПП приставлен методист, который может объяснить происхождение тех или иных цифр и  найти/поправить учетные ошибки, но если его нет, то система представляет из себя непредсказуемый черный ящик.  Непрозрачность происходит от того, что системы большие и сложные – они создавались для того, чтобы охватить потребности большинства предприятий (хотя то, что подходит для машиностроения, плохо подходит для молокозавода – но это уже другой вопрос). Т.е. использовался подход к универсальности типа «швейцарского ножа». А что если написать систему под конкретное производство, применить принцип «от простого к сложному» ? На конструкторе это заняло у меня минут 40 вместе с проверкой расчетов.

Автоматизируем такой пример из 2х цехов-переделов:

 

Схема производства



Отдельно склады и цеха, т.е. склады и НЗП, я делать не стал. Кстати, в типовых производственных конфах на маленьких предприятиях некоторым неудобно, что сырье обязательно списывать на 20ку, чтобы из него что-то произвести, а нельзя просто взять со склада. Второй момент – тут материальная партионная себестоимость получается сразу, без всяких препроведений и расчетов себестоимости.

За производство отвечает «виртуальный документ» Выпуск продукции. Он списывает сырье или ПФ,  и на выходе получается продукция или П/Ф с суммой себестоимости. Так можно выстроить сколько угодно переделов.

 

Выпуск продукции


Естественно, предварительно я «закупаю» сырье для производства сразу в цеха вирутальными документами «Поступление».

 Себестоимость мы получаем сразу в виде новой партии. Т.е. если мы продадим товар, то сразу спишется «материальная» себестоимость.

Но без косвенных затрат это был бы просто аналог документа «Комплектация» и никакое не «производство». Поэтому приходуем затраты. Для затрат я сделал виртуальный документ «Затраты» - в течение месяца затраты им приходуются, а в конце месяца другими документами распределяются.

Затраты

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

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

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

Уравнение

Для этого я сделал 3 документа – 3 шага. Это примерно как действия в расчете себестоимости, только отдельными документами.

Шаг 1 нужен для того, чтобы распределить затраты между выпущенной продукцией за месяц и зафиксировать  показатель, который я назвал «База». Это количество всего за месяц выпущенной продукции. Это нужно, чтобы поделить затраты между остатками и расходом. На выходе Шага 1 получается таблица распределения между  партиями выпущенной продукции – это вспомогательный виртуальный регистр для шагов 2 и 3.

 Шаг 1

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

 Шаг 2

Шаг 3 – оставшиеся затраты распределяются на проданную за месяц продукцию. В таб. части «Остатки затрат» - только остатки после предыдущего шага. Результат приплюсовывается к «виртуальном» регистру «Продажи», который сразу содержит себестоимость . Таким образом, в результате мы получили в регистрах себестоимость остатков и себестоимость продаж полную с учетом прямых и косвенных затрат.

Шаг 3


В итоге я получил в регистрах нужные движения - полная себестоимость, распреденная на остатки и затраты. Конструктор на этом заканчивается. Конечные отчеты нужно писать самому. Но, кстати говоря, отчет типа "Валовая прибыль" пишется просто по одному регистру - там сразу себестоимость. Товары на складах также сразу содержат себестоимость. Кстати, к своему стыду, я так и не понял смысла разделения этих регистров в типовых - например, Продажи/ ПродажиСебестоимость.Может, кто знает?

Результат

В этом примере я использовал принцип распределения затрат пропорционально количеству выпуска. В УПП/ERP можно выбрать другие принципы в настройках. Здесь это заложено в заполнялке Шага 1.

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

Прошу рассматривать данный пост просто как эксперимент по проверке альтернативных подходов к автоматизации. Не воспринимайте его слишком серьезно. Спасибо за внимание.



Скачать файлы

Наименование Файл Версия Размер
Демо-база с примером (UPD 22.08.2015)
.dt 131,47Kb
22.08.15
18
.dt 131,47Kb 18 Скачать

См. также

Комментарии
1. Ирина Павленко (PAVI) 1642 20.08.15 10:52 Сейчас в теме
Я правильно поняла, что "фишка" в том, что все сделано на операциях БУ?
Что касается алгоритма действий, то для ERP практически та же последовательность действий описана в http://infostart.ru/public/387452/.
Есть подобная и для УПП.
2. Ирина Павленко (PAVI) 1642 20.08.15 10:55 Сейчас в теме
то модули проведения документов должны быть максимально простыми и не скрывать за собой никаких алгоритмов – просто запись данных документа в регистр и ничего больше.


Для большинства документов так оно и есть. Но при расчете себестоимости Вы и сами какие-то алгоритмы применяете. А если встречный выпуск встретится, то Вашими "благими пожеланиями будет устлана дорога в ад" )))

Есть блоки производства в БП, УНФ, но у них нет тех возможностей, что в больших конфигурациях.


Большие конфигурации с большими возможностями не могут работать только на операциях БУ )))
3. Дмитрий Воронцов (informa1555) 473 20.08.15 11:02 Сейчас в теме
(1) PAVI, Нет, это сделано не на проводках, а на конструкторе http://infostart.ru/public/384253/
4. Дмитрий Воронцов (informa1555) 473 20.08.15 11:29 Сейчас в теме
(2) PAVI, Да не работаю я на регистрах БУ)) Фишка в том что с помощью конструктора упомянутого выше я быстрое делаю под конкретное производство конкретные "документы" без всего лишнего. Т.е. как бы пишу решение с нуля под заказчика. Конструктор это позволяет. Подход "написанное под задачу решение" vs "адаптированное универсальное решение" - в этом суть поста. По поводу того какие алгоритмы для расчета встречки используются в ERP/УПП я лучше умолчу.
5. борян петров (TODD22) 15 21.08.15 09:10 Сейчас в теме
(4) informa1555,
По поводу того какие алгоритмы для расчета встречки используются в ERP/УПП я лучше умолчу.

Как понимать эту фразу? Механизмы используемые в типовых плохие или ваши хорошие?
6. Дмитрий Воронцов (informa1555) 473 21.08.15 15:36 Сейчас в теме
(5) TODD22, ну про охрениарды денег которые могут "нарисоваться" в РАУЗЕ при встречных потоках затрат знает наверно каждый внедренец)) Это уже байка такая. Вот хорошая статья : http://infostart.ru/public/273813/ Я мыслю так: если система не знает как рассчитывать встречку она должна ее сначала найти, потом либо итерационно (либо как в раузе) рассчитать и тот и тот способ обладает недостатками которые отлично расписаны в приведенной ссылке - это проблема как раз универсального решения. Если в решении жестко прописать как должна рассчитываться с/стоимость в случае со встречным выпуском, то и проблемы не будет. Т.е. прописать также как считал бы человек на калькуляторе. Не будет же экономист чтобы посчитать затраты искать решение системы СЛУ, правильно?
7. Франко Деллиани (Franco) 65 21.08.15 17:34 Сейчас в теме
Ошибки

1.В 8.3.6 (при снятии совместимости) зарезервирован термин «ПараметрыВыбора». Соответственно, при выборе цеха ошибка присвоения, например:
ПараметрыВыбора = Новый Структура("ВидРесурсов", ЗначениеОтбора(Объект.ВидОперации,Элемент.Имя));

2.Оператор «Выполнить» не доступен в веб-клиенте.
informa1555; +1 Ответить 1
8. Дмитрий Воронцов (informa1555) 473 22.08.15 08:26 Сейчас в теме
(7) Franco, Спасибо. "ПараметрыВыбора " исправил. По поводу Выполнить на веб клиенте чет не соображу как заменить. Похоже никак. Не будет на веб клиенте это работать
9. Франко Деллиани (Franco) 65 22.08.15 09:07 Сейчас в теме
(8) informa1555,
Никак. Только думать, как обрабатывать на сервере
10. Вадим Латышев (pro1c@inbox.ru) 160 19.09.15 19:38 Сейчас в теме
(8) informa1555,

все! на этом все закончилось?
11. Дмитрий Воронцов (informa1555) 473 20.09.15 10:36 Сейчас в теме
(10) pro1c@inbox.ru, Если имеется ввиду будут ли еще публикации с "конструктором" - надеюсь что будут.
Оставьте свое сообщение