gifts2017

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

Опубликовал Дмитрий Воронцов (informa1555) в раздел Отраслевые решения - Производство

Эта статья не только для того, чтобы  продемонстрировать возможности конструктора виртуальных документов из поста 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) 15
.dt 131,47Kb
22.08.15
15
.dt 131,47Kb Скачать

См. также

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


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

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


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

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

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

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

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