Автоматизация предприятий пищевой отрасли на базе 1С:ERP

Об авторе

Руководитель проектов ВЦ Раздолье. Имеет несколько сертификатов 1С:Специалист по 1С:ERP . Выполнил 4 проекта комплексной автоматизации на предприятиях пищевой промышленности.

Содержание

1. Введение
1.1. Вводное слово
1.2.     Основные Требования к прозрачности состава изделия на всех этапах «жизненного цикла» продукции на предприятии
1.3. Возможности «1С:ERP» для контроля состава изделия на любом этапе «жизненного цикла» продукции на предприятии

2. Основные понятия и настройки
2.1. Понятие «партия» и «Серия». Чем они отличаются в 1С
2.2. Особенности учёта по fefo, отличия от FIFO .. 7
2.3.     Особенности партионного учёта и оптимальные настройки Серийного учёта в «1С:ERP»
2.4.     Особенности и Оптимальные настройки складского учёта в «1С:ERP»

3. Рассматриваемый пример
3.1. Информация о предприятии.
3.2. Структура складов и цехов предприятия.
3.3. Типовая спецификация изделия на предприятии.
3.4. Дополнительные общепроизводственные расходы предприятия на производство.

4. Основной процесс движения ТМЦ в производстве
4.1. Поступление сырья и входящий контроль
4.2. Формирование заказа на производство и резерв сырья
4.3. Передача сырья в производство
4.4. Списание сырья до выпуска продукции
4.5. Выпуск продукции
4.6. Производство готовой продукции и выпуск возвратных отходов
4.7. Реализация продукции

5. Инструменты системы для разузлования серии/партии номенклатуры по всем этапам цикла
5.1. Состав изделия
5.2. Структура себестоимости изделия

6. Заключение
6.1. Процессы, реализованные на типовом функционале
6.2. Рекомендуемые доработки конфигурации
6.3. Вывод

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

В данной статье описаны основные особенности такого учёта на типовой конфигурации «1С:ERP 2», разобраны основы производственного учёта, а так же собраны основные задачи, которые требуют доработки конфигурации, и лучшие практики по их реализации, использованные на нескольких производственных предприятиях пищевого сектора.

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

• Группировка готовой продукции по дате выпуска или другим параметрам;
• Детализация себестоимости продукции до каждой партии;
• Разузлование состава изделия до конкретных партий использованных материалов;
• Контроль используемых серий при перемещениях между складами и рабочими участками;
• Реже - штрихкодирование серий материалов и готовой продукции для автоматизации учета ТМЦ на предприятии

Данные требования являются обобщающими требованиями верхнего уровня, которые предъявляются каждым производственным предприятием, решившим автоматизировать серийное производство на базе любого программного продукта.

Перечисленные выше требования реализуются и предприятиями, которые вынуждены вести производственный учёт по методу «котла» - осуществлять списание материалов и выпуск продукции без учета конкретных партий. В этом случае серии и партии материалов и продукции учитываются и контролируются вне системы (журналы, бирки, этикетки).

Конфигурация «1С:Управление предприятием ERP 2» даже в рамках типового функционала позволяет автоматизировать серийный и партионный учёт, отвечая всем основным требованиям к контролю прозрачности, кроме штрихкодирования серий. В рамках данной статьи мы рассмотрим основные возможности 1С: ERP на примере предприятия пищевой отрасли, в которой контроль состава изделия – одно из основных требований к учету в производстве.

Для начала необходимо разобраться в понятиях - чем отличается серия от партии?

Партия – это одна или несколько единиц конкретных ТМЦ, оприходованных единым документом. Номером и датой партии в данном случае будет являться номер и дата документа оприходования (поступление товаров, оприходование излишков, выпуск продукции и т.д.);

Серия – это одна или несколько единиц конкретных ТМЦ, объединённых по параметрам производства.

Рассмотрим на примере:

Предприятие закупает молоко. Поставщик поставляет 40 тонн цельного коровьего молока с одного надоя, которые приезжают 2-мя транспортными средствами. Поставщик предоставил ветеринарный паспорт на продукцию, в паспорте обозначено, что серия молока – 212020 от 01.05.2020 в обоих транспортных средствах.

Далее рассмотрим варианты:

• Оба транспортных средства приезжают единовременно по единым документам и принимаются вместе - № накладной 1477 от 05.05.2020;
• Транспортные средства прибывают с разницей во времени, со своим пакетом документов, приёмка производится отдельно - № накладной 1478 от 05.05.2020 и 1479 от 06.05.2020.

В первом случае мы получим следующую аналитику:

• молоко цельное 40 тонн – партия № 1477 от 05.05.2020 – серия № 212020 от 01.05.2020.

Во втором случае:

• Молоко цельное 40 тонн:
• 20 тонн – партия 1478 от 05.05.2020 – серия 212020 от 01.05.2020;
• 20 тонн – партия 1479 от 05.05.2020 – серия 212020 от 01.05.2020.

Теперь немного изменим вводные данные: оба транспортных средства пребывают в одно время, но надои разные: 212020 от 01.05.2020 и 212021 от 02.05.2020. Принимаются по накладной № 1480 от 05.05.2020. В результате мы получим:

• Молоко цельное 40 тонн:
• 20 тонн – партия № 1480 от 05.05.2020 – серия 212020 от 01.05.2020;
• 20 тонн – партия № 1480 от 05.05.2020 – серия 212021 от 02.05.2020.

Стоит дополнить, что аналитика «Партия номенклатуры» не является доступной в отчетах в общем понимании работы системы, система при снятии остатков или контроле оборотов ТМЦ оперативно фиксирует только серии, партии же определяются в регламентных заданиях закрытия месяца, чтобы корректно связать серийный и партионный учёт, а также правильно рассчитать себестоимость.

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

Учёт по FEFO отличается от учета по FIFO по следующему принципу:

• FIFO – дословно, первый пришел, первый ушел – классический партионный учёт, который контролирует списание партии в зависимости от параметра «дата поступления». Подразделяется на «скользящая» и «взвешенная оценка» (в 1С: ERP не применяется с релиза 2.4.8). Скользящая оценка - списание и оценка запасов производится в порядке поступления номенклатуры на склад.

Нередко происходят ситуации, когда вновь поступающее сырьё обладает меньшим сроком хранения, чем уже имеющееся в наличии, соответственно, во избежание появления некондиционного сырья, необходимо в первую очередь передать в производство эту поступающую партию, а уже потом – ту, что хранится на остатках. С данной задачей типовой функционал «1 C : ERP » справляется практически «из коробки». Рассмотрим особенности настройки серийного учёта для решения этой основополагающей задачи автоматизации пищевой промышленности.

Начнём с партионного учёта.

Перейдём к сериям.

Рассмотрим их отдельно.

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

Авторасчёт по FEFO остатков серий требует указания серии только при поступлении, при отгрузке указание серий не используется, система рассчитывает их автоматически. Минусом выбора данной политики является невозможность построения множества отчётов с аналитикой до серии, возможен только 1 отчёт – «Остатки товаров по срокам годности».

Казалось бы, если предприятию требуется вести учёт по FEFO – включаем авторасчёт, и без дополнительных трудозатрат получаем сквозную аналитику!

Но здесь на сцену выходят отличия в бизнес-процессах предприятий и их взаимодействия с покупателями. Рассмотрим некоторые из них:

• Могут предъявляться требования к минимальному сроку годности сырья для производства конкретной продукции;
• При использовании аналогов сырья необходимо анализировать срок годности по всем аналогам и брать соответствующий аналог в случае, если его остаточный срок хранения – наименьший;
• Производятся экспериментальные продукты из конкретных партий сырья с целью определения их качества;
• Продукты с истёкшим сроком годности в производство не допускаются.

И для решения данных задач авторасчёт не подходит. Поэтому рекомендуется применять именно управление остатками, хотя эта политика и не решит на автоматизированном уровне данные вопросы, но позволит именно управлять сериями на уровне пользователя, а также реализовать достаточно простые доработки, которые решат все описанные выше задачи.

Но не всё так хорошо, как может показаться, и к этому мы придём ближе к анализу себестоимости.

Неотъемлемой частью серийного учёта является настройка складского учёта.

Первое, с чем стоит определиться, будет ли применяться ордерная схема. Для понимания, ордерная схема – это разделение документов оперативного учёта на финансовые (первичные документы, такие, как ТОРГ-12, ТОРГ-13, Т-11 и т.д.) и количественные (складские ордера). Проще говоря – при ордерной схеме кладовщик имеет свой упрощенный документ, в котором он вводит в систему только количественные данные о номенклатуре, а финансовая и бухгалтерская информация оформляется в стандартных первичных документах, которые оформляет бухгалтерия.

От решения применяется ли ордерная схема зависит, в каком документе будет требоваться указание серий. Для выбранной нами политики (УОС по FEFO ), в случае применения ордерной схемы, серии указываются в приходных и расходных ордерах, а также в документе «Пересчет товаров» (та же инвентаризация остатков), что упрощает пользователям работу.

В этом случае диспетчеры, бухгалтеры и прочие операционные сотрудники оформляют первичные документы без дополнительной нагрузки, а кладовщики, как непосредственные материально ответственные лица (МОЛ), которые эти серии принимают и отгружают, указывают их в своих стандартных для всех операций документах. Если ордерная схема не применяется, пользователь обязан указывать серию в первичном документе. Рассмотрим безордерную схему, как наиболее разнообразную в учёте серий.

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

На предприятии 3 передела. Готовая продукция сразу возле линии контролируется ОТК, далее с линии она передаётся на склад готовой продукции, с которого перед отгрузкой перемещается в зону экспедиции (производится сборка заказа с использованием упаковочных материалов), и далее направляется к покупателю. Дополнительно, при формовке теста по заданным нормативам формируется возвратных отход (обрезки), который в дальнейшем снова передаётся в производство.

Кладовщики оформляют документы прихода, перемещения и расхода.

Диспетчер производства оформляет списание сырья и выпуск продукции, а также акцептует переданное со складов сырьё.

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

Менеджеры по продажам оформляют отгрузочные документы.

На предприятии применяется необходимая и достаточная структура складов:

• Склад закупки (ОТК);
• Бункер;
• Молочный резервуар;
• Холодильник;
• Атмосферный склад;
• Прочие материалы;
• Зона заморозки;
• Склад заготовки;
• Склад готовой продукции;
• Зона экспедиции;
• Прочие склады (брака, малоценки и т.д.) в нашем примере мы не рассматриваем.

На предприятии используются цеха:

• Тестомесильный цех;
• Цех формовки;
• Хлебопечь;
• Цех фасовки.

Рассмотрим формирование спецификации на предприятии:

• Предприятие учитывает технологические потери производства (5%);
• Предприятие не фиксирует нормативы по электроэнергии и газу в спецификациях, распределяет их пропорционально количеству выпущенной продукции;
• Трудозатраты нормируются, но зарплатный учёт ведётся вне системы;
• Возвратные отходы по фиксированной стоимости нормированы для формовки.

Дополним стандартную информацию нюансами реальных предприятий:

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

Рассмотрим пункт про учёт технологических потерь подробнее – можно просто и очевидно добавить 5% норматива к материалу, и тем самым получить норматив с учетом технологических потерь. Данное решение слабо тем, что в итоговой структуре себестоимости предприятие не увидит долю этих затрат. Для данного предприятия — это не критично, потому что нормировка единая – 5%. Но что делать, если материалов сотни, а вариантов потерь – десятки, если тоже не сотни?

Наиболее оптимальным решением является выделение технологических потерь отдельно в ресурсной спецификации – это решит данный вопрос без дополнительных доработок или настроек отчетов, но создаст проблему – все строки придётся дублировать, вручную считать количество потерь и менять статью калькуляции на соответствующую:

Кроме того, – в «Этапах производства» и обработке по формированию заказов по потребностям будет двойное количество строк (еще одну критичную проблему рассмотрим позднее). В случае, когда материалов сотни – вопрос важный. Здесь необходимо расставлять приоритеты – либо сохранение типовой конфигурации, либо детализированная себестоимость, но с необходимостью доработок системы.

Выбирая второй путь, рекомендуется автоматизировать заполнение потерь в спецификации. Это возможно сделать, добавив норму потерь либо в номенклатуру, либо в группу номенклатуры, либо в вид номенклатуры, либо в другую подходящую аналитику номенклатуры. Так же норму потерь нужно добавить в расчет потерь в спецификации. Такая доработка проста и удобна, но не решает вопрос задвоения строк в документах. Убрать задвоения в этапах непросто по технической причине – аналитика в этапах производства «Статья калькуляции» является аналитикой в движениях ключевого для 1С:ERP регистра «Себестоимость товаров».

Сделать это непросто, но реально, если вопрос критичный.

Справедливости ради, нужно добавить, что использование цеховых кладовых и их пополнение по потребностям исключит доработку Требования-накладной или заказа на материалы в производство, но тогда возникнет другая проблема. При ведении регламентированного учёта остатки в кладовой – это 20-ый счет, что неприемлемо для пищевого производства при закрытии месяца. А также несколько нарушится бизнес-процесс потребления по требованию-накладной (заборной карте). В целом, выбор проектного решения – вопрос обсуждения на каждом конкретном предприятии.

Спецификации формируются по аналогичной схеме:

Добавим 5% технологических потерь.

Отдельно вынесем важный вопрос с точки зрения системы – базовые единицы измерения. Как бы предприятию не хотелось вести учет весового продукта в единых единицах измерения, автоматический расчет 1С:ERP ограничен 3-мя знаками после запятой, что накладывает определённые ограничения.

Для понимания рассмотрим пример:

Какая проблема получится в производственном учете? Когда появится заказ менее, чем на тонну теста, мы потеряем те самые проценты потерь, которые указывали. А если на тонну расходуются граммы материалов (например, в сладкую начинку для булочек/конфет добавляется коньяк/корица и т.д.) – то мы получим следующую картину, которую придётся исправлять вручную:

Пустые строки обусловлены автоматическим округлением системы количества: менее 0,0005 до значения 0.

Если такие заказы – разовое явление, то можно не обращать внимания, но если нет, рекомендуется руководствоваться следующими правилами:

• В спецификациях нормировать данные на минимальную единицу выпуска продукции, то есть – если учёт в тоннах, то заказы на килограммы невозможны, только тонна и более. Если заказы на килограммы возможны – то нормировать на килограмм.
• Единица учета готовой продукции – не больше минимальной выпускаемой единицы, например – норма выпуска рассчитывается на 100 кг – единица измерения продукции кг или центнер (на практике не встречал). Можно, конечно, поставить норму 0,1 тн, но при производстве 0,357 тн начнётся потеря значимых знаков после запятой для материалов, поэтому не рекомендую.
• Единица измерения материалов – не больше минимальной потребляемой величины при расчете до 3-го знака после запятой (тысячные), то есть – если минимальное потребление сырья по нормативам 0,001 кг, допустим на 1 тонну продукции, то производство 2,5 тонн приведёт к округлению до 0,003, а если это сырьё – вино 300-летней выдержки

Стоит добавить, что процесс производства на предприятии характеризуется тем, что тесто-заготовка делается с запасом по планам продаж и производства, а заготовка, выпечка или упакованная продукция снабжается из имеющихся остатков теста. Если теста не хватает, на тесто подается отдельный заказ.

Учтя всё вышесказанное, подытожим настройки спецификаций.

Материальные затраты:

Трудозатраты:

Этапность:

Для примера возьмём некоторые прочие расходы предприятия, чтобы посмотреть, как они лягут в производственную себестоимость:

• Газ, электроэнергия распределяются пропорционально количеству готовой продукции;
• Зарплата распределяется пропорционально количеству готовой продукции;
• Упаковочные материалы отгрузки распределяются пропорционально количеству выпущенной продукции.

Производится закупка основного производственного сырья.

Мука пшеничная:

• От основного поставщика по стандартной стоимости;
• От второго поставщика по завышенной стоимости отдельной позицией.

Молоко:

• Одной партией.

Яйца:

• 3 разные партии с разными сроками годности.

Масло сливочное:

• 2 разные партии с разными сроками годности.

Соль, сахар, дрожжи:

• Учёт серий не ведётся, одной партией.

Тара для фасовки:

• Учёт серий не ведётся, одной партией.

С данного склада сырьё в производство не передаётся, сырьё в производство передаётся непосредственно со склада заготовки, на которое оно поступает с сырьевых складов, обозначим это в схемах обеспечения для сырья:

В свою очередь настройки склада заготовки

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

Данные настройки позволяют построить следующую цепочку:

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

На ордерном складе в первичном документе серии не указываются:

Кладовщик, оформляя приходный документ, оформляет и приходный ордер, но для блокировки молока к отгрузке статус ордера оставляет «Требуется обработка»:

После проведения контрольных тестов ОТК устанавливает статус «Принято», что открывает доступность сырья к производству:

Как видно, без доработок, путём изменения бизнес-процесса, мы реализовали входной контроль молока в системе.

Входной контроль остального сырья завершается формированием документа «Перемещение товаров» на сырьевой склад, например:

Пример по серийным позициям:

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

Предприятие производит продукцию «на склад», поскольку спрос постоянный, количество к производству определяется в объёмно-календарном планировании.

Сформированные заказы на производство еще не формируют потребность, в отличие, например, от заказа клиента – они являются намерением к производству, которое еще необходимо утвердить.

Утверждение заказа к производству выполняется через перевод статуса документа «К производству» и дальнейшим формированием этапов производства – маршрутных листов производства.

В каждом этапе производства мы формируем потребность на склад заготовки, после удовлетворения которой мы можем исполнить этап. Существует определённая последовательность установки приоритета обеспечения:

• Резервировать на складе – при наличии остатка система обособит остаток для данного заказа на производство;
• Резервировать по мере поступления – снабжение складов ведётся без привязки к заказам, но сразу по мере поступления система резервирует остаток из свободного;
• Обеспечивать обособленно – и снабжение складов, и дальнейшее движение ТМЦ производится с четким обособлением под заказ;
• К обеспечению – без особых требований, отбор по факту;
• Не обеспечивать – строки в заказе становятся неактивными, потребность отпадает.

Правильная настройка схем обеспечения приводит к тому, что система автоматически понимает, с какого склада забирать тот или иной материал:

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

Правильная настройка системы минимизирует необходимость ручного ввода данных.
Обратите внимание, что достаточно нажатия всего 3-х кнопок, чтобы сформировать потребность склада заготовки на все первичные склады сырья в правильном количестве:

Данная цепочка выглядит достаточно объёмно, особенно, когда параллельно запускаются десятки этапов производства. Часто в реальной жизни систему можно оптимизировать, автоматически формируя всю цепочку документов по схемам и способам обеспечения до первичных складов прямо из этапа производства, сделав дополнительную обработку на формирование цепочки.

Стоит добавить, что масло проходит процедуру дефростации, которая по времени может занимать до 8 часов (это же возможно с мясом, курицей, кремом и прочим скоропортящимся сырьём), но в нашем модельном предприятии, поскольку оно работает на склад, процесс дефростации происходит постоянно, поэтому мы считаем, что для целей информационной системы, сразу же передаётся подготовленное охлажденное сливочное масло. Можно дополнить схему обеспечения временем поставки, но оно ограничивается детализацией до дня.

Далее, по заказам кладовщик формирует перемещение товаров (ТОРГ-13). Рассмотрим на примере яйца, чтобы понять корректность отработки системы:

Система уже автоматически подобрала серии по FEFO, в режиме авторасчета, но можно детально проверить и применить другие серии, если есть необходимость:

При этом обратите внимание, что система выбирает партии именно по FEFO, а не по FIFO, о чем написано ранее:

Система взяла более поздние партии с наименьшим сроком годности, а остаток (50 десятков) добавила из более ранней партии. Всё остальное сырьё перемещается на склад заготовки абсолютно аналогично.

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

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

Далее, анализируем возможные аналоги для муки, которые применяются на предприятии. Нас интересует мука:

Технолог производит замену:

А вот при замене количества на потери мы сталкиваемся с проблемой:

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

Аналоги, конечно, могут быть применены с коэффициентами, например, яйца С1 и С0:

Поскольку данный этап обеспечивается отдельно, обособим всё сырьё под него, чтобы система сквозной аналитикой связывала документы:

Стоит дополнить, что, по умолчанию, система не анализирует сроки годности с учётом аналогов, то есть имея 2 серии по двум номенклатурам с разными сроками годности, даже если серия аналога обладает меньшим сроком годности, система не предложит использовать аналог, поскольку расчет ведётся по позициям, указанным в спецификации. На практике же, на предприятиях пищевого сектора данное требование является распространённым, поэтому доработка автоматического применения аналога зачастую является обязательной и достаточно трудозатратной, но позволяет:

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

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

Снабжение производства сырьём производится типовым документом «Движение продукции и материалов» с видом «Передача материалов в производство» (требование-накладная Т-11) в цеха.

После удовлетворения потребности склада заготовки, кладовщики формируют требования-накладные в цеха в специальном рабочем месте, например:

Естественно, их можно сформировать на основании этапов производства.
Оформляем по заказам документы, помним, что мука идёт напрямую, поэтому формирует свою собственную потребность.

Здесь я специально обозначил, что система может сформировать единый документ на все потребности, но именно здесь мы и подошли к той критической проблеме, о которой я ранее упоминал. Система формирует требование-накладную ровно так, как строки сформированы в этапе производства. Это обусловлено привязкой формирования этапа и потребностей к идентификатору строки.

Чтобы сильно не вдаваться в технические подробности, резюмирую – ранее данная проблема практически всегда была обязательна к устранению, но сейчас необязательно выполнять доработки документа или процедуры формирования этапов, потому, что функционал по заполнению серий работает корректно и красиво:

Будет 100 аналогичных строк – система просуммирует все 100. Главное – что у нас в Т-11:

Всё правильно и красиво, а количество строк в самом документе –слабый аргумент для доработки.
Немного остановимся и сделаем промежуточный срез информации. Проверим движение серий сырья до настоящего момента, рассмотрим на примере яйца.

Лучшим вариантом для анализа истории по движению серий по складам является отчет «Ведомость по сериям номенклатуры», хотя аналогичную информацию можно получить и в основном складском отчете «Ведомость по товарам на складах».

Но оба этих отчета не очень читабельны для анализа движения конкретной серии по всем стадиям движения ТМЦ на предприятии, можно доработать отчет, добавив в него серии и склады:

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

Мы рассмотрели технологию снабжения производства по потребностям до начала производственного процесса.

В принципе, в типовом функционале, 1С:ERP поддерживает возможность постепенного насыщения производства, то есть необязательно полностью удовлетворять потребность, чтобы начать производственный процесс. Для этого применяется разбитие строк этапа на «к обеспечению» и «к отгрузке» (аналог – обеспечено). Наше модельное предприятие не запускает производство до полного обеспечения, но для тех, кому необходим данный процесс, рекомендую доработать функционал «Обеспечить частично» - указав количество продукции, которую мы можем произвести – рассчитать расход сырья по доле и разбить строки для частичного обеспечения. Особенно удобно, если количество списанного сырья указывается ПОСЛЕ выпуска партии.

Списание сырья в этапе производства выполняется в статусах «Начат» и «Завершен», и здесь мы сталкиваемся с проблемой выделения потерь в отдельные строки:

Серии потребуется указать для каждой строки, что критично и всегда требует доработки. Вариантов доработки две – либо добавить форму указания серий с её функционалом, либо добавить команду «Заполнить отгруженными сериями» (можно добавить на автоматическое срабатывание при заполнении таблицы отгруженными материалами). Оба пути оптимальны, хотя функционал команды «указать серии» достаточно широк и по-разному работает для разных политик учета серий, что может привести к упущениям, но данный вопрос возникнет и в случае разработки команды «Заполнить отгруженными сериями».

И второй критический вопрос – при ручном указании серий нет возможности указать несколько серий для общего количества, поэтому ручное указание серий в типовом функционале потребует «разбития» строк, что неприемлемо:

Так что доработка группы «расход» - обязательна.
Все неизрасходованные материалы заполняются в отдельной табличной части и возвращаются на склад.

Для корректного завершения этапа производства необходимо отразить выпуск продукции в 2 этапа:

• Указать данные в самом этапе;
• Сформировать документ «Передача продукции из производства»:

Склад автоматически встаёт из схемы обеспечения.

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

После всех этих операций завершаем этап производства.

Укрупнённо рассмотрим цепочку формирования заказов на производство для готовой продукции.

Заказы сформированы на позиции «Нарезной» и «Нарезной упаковка» по стандартным спецификациям, а заказ на «Белый» сформирован с дальнейшей целью производства его из партии теста, которое сделано из альтернативной муки. Посмотрим заказы и их структуру на примере основного заказа:

При правильных настройках система разузловывает изделие по всем необходимым полуфабрикатам.

Второй заказ полностью аналогичен на данном этапе.

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

Далее, на склад это приходит именно обособлено, чтобы понять, какое тесто на какой этап передать:

Также, система автоматически обособляет полуфабрикаты в рамках одной производственной цепочки, если указаны соответствующие настройки в разделе «Производство»:

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

Теперь мы можем применять данный аналог в производстве, если он есть.
Образуется же тесто в системе заполнением отдельной табличной части в этапе на закладке «Выпуск»:

Также могут быть списаны, как расходы.

Дополнительно, при выпуске нескольких видов продукции под заказ, система автоматически обособляет то, что пойдёт дальше, а также пропорционально делит себестоимость:

Склады тоже определены для каждого выпуска, куда положить полуфабрикат, а куда ГП.

Завершим производственную цепочку и отразим контроль ОТК.

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

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

При этом отгрузка обособлена и не будет отгружена под другой заказ.
Серии продукции указываются прямо в реализации (или ордере, если склад ордерный):

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

Пора переходить к анализу результата.

Наиболее удобным отчетом для анализа состава каждой партии конкретного изделия является отчет «Структура серии номенклатуры»:

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

Независимо от политики оценки запасов, в типовом функционале работает отчет «Анализ себестоимости выпущенной продукции», который группирует затраты по номенклатуре:

Поддержана структура выделения потерь от общего стэка материалов:

Детализация по сериям для политики FEFO в данном отчете не отрабатывает, к сожалению.

Именно здесь играет роль статья калькуляции – это группировка расходов.

Обратите внимание, что система корректно учла возвратный отход – указала его с отрицательным значением. Если задать возвратному отходу стоимость – система вычтет её из конечной стоимости изделия.

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

Каждая партия разузловывается до партии закупки, например:

А также сюда попадает зарплата (строка «замес» пустая в примере, если сумма выработки не рассчитана в системе, но при ведении зарплаты внутри 1С:ERP– соответствующая затрата дополняет себестоимость продукции), и любые прочие расходы (газ, вода и т.д.).

Проверим, что на производство «Белого» у нас пошла именно специальная партия теста:

И вот мы пришли к основной проблеме любого учёта по сериям в программе 1С:ERP, кроме политики «Учет себестоимости по сериям» - себестоимость готовой продукции берётся не по входящим в изделия сериям, а по FIFO или средней. Проверим моё утверждение , сформировав структуру батона «Белого»:

Мука указана правильно. Уточним для яиц, поскольку яйца тоже отбирались не по FIFO:

И здесь та же самая проблема – корректное указание в этапах и абсолютно некорректное в отчетах. Я напомню, что мы взяли тысячу десятков по 500 из партий БУ00-000005 и БУ00-000006, что можно проконтролировать через специально настроенный типовой отчёт «Ведомость по товарам на складах»:

Как можно заметить, по складу партия БУ00-000004 лежит в правильном количестве на складе, но чуть ранее в отчете «Дерево себестоимости» мы видели обратное.

Проверим другие отчеты, чтобы долго не разворачивать, проконтролируем соответствие стоимости, ведь если стоимость материалов будет хотя бы где-то отличаться, то и результирующая стоимость изменится:

Стоимость идентична. А отчет «Себестоимость товаров организации» вообще суммирует всё подряд, суммируя количество и сумму по всей колонке:

Но даже тут видно, что стоимость равна стоимости из двух предыдущих отчётов.

И везде данные по FIFO. Из чего я вынужден сделать вывод:

В текущей редакции 1С:ERP ведение учёта по FEFO в типовых отчётах не даёт возможности корректно отследить структуру себестоимости изделия и корректно рассчитать рентабельность продаж.

Данная проблема может быть решена типовыми средствами путём введения номенклатуры для пробных полуфабрикатов, например, вместо выделения только отдельной серии для теста, можно завести полуфабрикат «Тесто дрожжевое из пшеничной муки ВЫСШИЙ СОРТ» и заменить его вручную или через функционал аналогов, что не даст системе шанса взять в расчет некорректную партию полуфабриката. Но введение отдельной номенклатуры, например, для сырья по разной стоимости – методологически некорректный подход, впрочем, и пробных полуфабрикатов может быть множество, поэтому данная рекомендация может быть использована в случае упорного нежелания доработки типового функционала.

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

Самое время подвести итог всего вышеописанного и сделать выводы.

• Блок продаж (рассмотрим в отдельном материале);
• Функционал анализа остаточного срока годности (запрет на производство при истечении, отгрузка по ограниченному сроку годности и т.д.);
• Заполнение расходной части этапа производства сериями;
• Формирование цепочки документов обеспечения производства из этапа;
• Доработка СОБСТВЕННОЙ отчетности по фактической себестоимости продукции ЛИБО-;
• Доработка анализа сроков годности и механизмов FEFO для политики серий «Учет себестоимости по сериям»;

Здесь важно прокомментировать, что последняя доработка недостаточно очевидна и будет индивидуальна по требованиям каждого предприятия. И всего этого можно избежать, если у предприятия FIFO=FEFO, или наиболее ранняя партия всегда является менее годной.

Проанализировав весь массив информации, представленный в данном материале, можно сделать вывод, что конфигурация «1С:ERP 2» уже из коробки предоставляет достаточно широкий функционал для детального учёта ТМЦ на предприятии и в производстве. Все операции прослеживаются, процессы, требующие связи, связываются, структура изделий и применение аналогов прослеживается.

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

Если на Вашем предприятии FIFO=FEFO, то кастомизация типового функционала будет косметической и при грамотном внедрении типовой функционал закроет 90% потребностей.

Но даже если у Вас часто списание по FEFO не соответствует FIFO, достоинство платформы 1С в том, что отчеты всегда могут быть реализованы внешними объектами, тем самым не нарушая структуру конфигурации. Также всегда можно разработать свои выходные формы.

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