На мой взгляд в 1С есть пробел в автоматизации небольших производств. Есть блоки производства в БП, УНФ, но у них нет тех возможностей, что в больших конфигурациях. Основная беда с УПП,ERP – отсутствие прозрачности даже если система внедрена и работает. Грубо говоря, хорошо, когда к УПП приставлен методист, который может объяснить происхождение тех или иных цифр и найти/поправить учетные ошибки, но если его нет, то система представляет из себя непредсказуемый черный ящик. Непрозрачность происходит от того, что системы большие и сложные – они создавались для того, чтобы охватить потребности большинства предприятий (хотя то, что подходит для машиностроения, плохо подходит для молокозавода – но это уже другой вопрос). Т.е. использовался подход к универсальности типа «швейцарского ножа». А что если написать систему под конкретное производство, применить принцип «от простого к сложному» ? На конструкторе это заняло у меня минут 40 вместе с проверкой расчетов.
Автоматизируем такой пример из 2х цехов-переделов:
Отдельно склады и цеха, т.е. склады и НЗП, я делать не стал. Кстати, в типовых производственных конфах на маленьких предприятиях некоторым неудобно, что сырье обязательно списывать на 20ку, чтобы из него что-то произвести, а нельзя просто взять со склада. Второй момент – тут материальная партионная себестоимость получается сразу, без всяких препроведений и расчетов себестоимости.
За производство отвечает «виртуальный документ» Выпуск продукции. Он списывает сырье или ПФ, и на выходе получается продукция или П/Ф с суммой себестоимости. Так можно выстроить сколько угодно переделов.
Естественно, предварительно я «закупаю» сырье для производства сразу в цеха вирутальными документами «Поступление».
Себестоимость мы получаем сразу в виде новой партии. Т.е. если мы продадим товар, то сразу спишется «материальная» себестоимость.
Но без косвенных затрат это был бы просто аналог документа «Комплектация» и никакое не «производство». Поэтому приходуем затраты. Для затрат я сделал виртуальный документ «Затраты» - в течение месяца затраты им приходуются, а в конце месяца другими документами распределяются.
Весь дальнейший расчет себестоимости я сделаю исключительно на заполнялках табличных частей. Причем везде используется один и тот же алгоритм – распределение одной таб. части на другую и получение реультата в 3ю. Я по-прежнему считаю, что модули проведения документов должны быть максимально простыми и не скрывать за собой никаких алгоритмов – просто запись данных документа в регистр и ничего больше. Таким образом, помимо скорости проведения мы еще получаем прозрачность для пользователя.
В конце месяца у нас накопились затраты. Их надо распределить. Но главная задача даже не пропорционально чему распределить, а как сделать так, чтобы эти затраты отразились на остатках произведенной продукции и приплюсовались к себестоимости уже проданных товаров.
Для этого мы используем принцип черного ящика. На входе у нас накопившиеся затраты, а на выходе результат, который мы хотим получить – это остатки на конец месяца и себестоимость проданных товаров из тех, что были произведены в этом месяце. Последнее важно, т.к. нам не надо, чтобы на товары, произведенные в предыдущем месяце, падали затраты этого месяца. Т.е. нужно сделать так, чтобы затраты распределились между остатками и проданным товаром.
Для этого я сделал 3 документа – 3 шага. Это примерно как действия в расчете себестоимости, только отдельными документами.
Шаг 1 нужен для того, чтобы распределить затраты между выпущенной продукцией за месяц и зафиксировать показатель, который я назвал «База». Это количество всего за месяц выпущенной продукции. Это нужно, чтобы поделить затраты между остатками и расходом. На выходе Шага 1 получается таблица распределения между партиями выпущенной продукции – это вспомогательный виртуальный регистр для шагов 2 и 3.
Шаг 2 нужен для того, чтобы «откусить» часть затрат на выпуск и приплюсовать их к партиям остатков выпущенной продукции на складах. В таб. части «Остатки затрат» видно, что затраты пока присутствуют все как есть.
Шаг 3 – оставшиеся затраты распределяются на проданную за месяц продукцию. В таб. части «Остатки затрат» - только остатки после предыдущего шага. Результат приплюсовывается к «виртуальном» регистру «Продажи», который сразу содержит себестоимость . Таким образом, в результате мы получили в регистрах себестоимость остатков и себестоимость продаж полную с учетом прямых и косвенных затрат.
В итоге я получил в регистрах нужные движения - полная себестоимость, распреденная на остатки и затраты. Конструктор на этом заканчивается. Конечные отчеты нужно писать самому. Но, кстати говоря, отчет типа "Валовая прибыль" пишется просто по одному регистру - там сразу себестоимость. Товары на складах также сразу содержат себестоимость. Кстати, к своему стыду, я так и не понял смысла разделения этих регистров в типовых - например, Продажи/ ПродажиСебестоимость.Может, кто знает?
В этом примере я использовал принцип распределения затрат пропорционально количеству выпуска. В УПП/ERP можно выбрать другие принципы в настройках. Здесь это заложено в заполнялке Шага 1.
В итоге из нескольких десятков строчек кода я получил систему, на мой взгляд простую и с понятным происхождением каждой цифры. Пример простой, но его можно усложнить, при этом также эксплуатируя принцип распределения.Такую систему можно оставить у заказчика и не бояться, что она выдаст какой-нибудь сюрприз при расчете себестоимости.
Прошу рассматривать данный пост просто как эксперимент по проверке альтернативных подходов к автоматизации. Не воспринимайте его слишком серьезно. Спасибо за внимание.
