Спецификация изделия в ERP: состав, версии и изменения

Как устроить спецификацию изделия в ERP: состав BOM, выбор версии, нормы, замены, незавершённые заказы и проверка расчёта.

Автор: Александр Поркулевич, CEO и основатель, 404gen.

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

Материал адресован руководителю производства, технологу и владельцу ERP-модуля. Разберём программную модель BOM, выбор действующей версии, выпуск изменений и проверку расчёта. Речь о данных и поведении системы; технологические нормы и допустимость материалов задают специалисты предприятия.

Какую задачу решает спецификация

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

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

В учебном примере компания собирает настольные светильники. У белого и графитового исполнения общий блок питания, но разные корпуса. С сентября применяется новая упаковка. Заказ, выпущенный в августе и ещё находящийся в работе, не должен сам переключаться на сентябрьский состав. Этот пример показывает устройство данных и не описывает реализованный проект 404gen.

Изделие, состав и маршрут — разные сущности

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

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

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

Какие данные нужны строке состава

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

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

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

Как выбирать действующую версию

В официальной документации Microsoft Dynamics 365 версии BOM связаны с условиями применимости, включая период и количество; отдельно описаны утверждение и активация. Для собственного модуля это полезный ориентир: «самая новая запись» и «правильный состав для заказа» не всегда совпадают. См. документацию о BOM и версиях.

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

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

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

Черновик, утверждение и выпуск изменения

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

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

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

Odoo описывает работу с изменениями состава через engineering change orders: изменение проходит отдельный процесс до применения к производственным данным. Это пример разделения подготовки и выпуска, а не требование использовать конкретный продукт. Источник: документация Odoo 18 об изменениях.

Что происходит с уже открытыми заказами

Самое важное решение при выпуске версии — судьба незавершённой работы. Список затронутых заказов должен быть виден до подтверждения. Состав может измениться для новых запусков, для ещё не выданных заданий или для выбранного набора заказов после отдельного решения. Универсальная кнопка «применить везде» опасна именно своей неопределённостью.

В заказе сохраняйте использованную версию и рассчитанные строки. Если ERP ссылается только на текущую карточку, последующее редактирование справочника изменит прошлую потребность при повторном открытии. Исторический снимок нужен для объяснения, а ссылка на первоисточник — для навигации и сравнения. Одно не исключает другое.

Перед пересчётом проверьте выдачу, резервирование и фактическое потребление. Если часть старых компонентов уже выдана на участок, новая потребность не должна просто обнулить их движение. Система предлагает разницу, показывает влияние на резерв и требует согласовать способ отражения. Физическое движение остаётся отдельным фактом.

Полезен предварительный просмотр: было 20 корпусов старой версии и 40 винтов, станет 20 новых корпусов и 60 винтов. Рядом — уже выданное количество и то, что ещё можно изменить. После подтверждения сохраните автора, причину и номер операции, чтобы повторное нажатие не применило один и тот же пересчёт дважды.

Многоуровневый состав и расчёт потребности

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

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

Упаковочное ограничение поставщика следует отличать от производственной нормы. Потребность может составлять 37 деталей, а закупка — оформляться коробками по 20. Если записать 40 прямо в состав, норма станет зависеть от конкретного заказа поставщику. Правильнее сохранить чистую потребность и отдельно показать округлённое предложение закупки.

Проверьте циклы дерева: изделие А включает узел Б, а Б ошибочно включает А. Система должна обнаружить цикл до запуска расчёта, вывести понятную цепочку и остановиться. Технический таймаут или пустая потребность не объяснят технологу, какую карточку исправлять.

Замены компонентов и варианты исполнения

Аналог в справочнике не всегда является разрешённой заменой в конкретном изделии. Он может подходить по закупочному наименованию, но отличаться по монтажу или требованиям проекта. ERP хранит решение компетентного специалиста и область действия, а не самостоятельно определяет техническую эквивалентность.

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

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

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

Как связать спецификацию со складом и закупкой

Норма, потребность, доступный остаток и резерв — четыре разные величины. Норма относится к составу. Потребность зависит от количества изделий. Доступность учитывает состояние запаса. Резерв выражает обязательство под конкретный заказ. Если смешать их в одном поле «нужно», пользователи будут по-разному читать одну и ту же цифру.

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

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

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

Импорт и работа с качеством справочника

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

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

Сохраните исходный файл и отчёт сопоставления в рамках принятого срока хранения. Это помогает объяснить расхождение между старой таблицей и новой моделью. В то же время файл не должен становиться единственным источником правил: после утверждения система работает с нормализованными строками и зафиксированной версией.

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

Проверки перед запуском ERP-модуля

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

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

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

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

Как читать расхождение нормы и факта

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

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

Частые вопросы

Нужно ли создавать отдельную спецификацию для каждого заказа?

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

Можно ли хранить состав только в Excel?

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

Должна ли новая версия менять незавершённые заказы?

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

Кто определяет допустимость аналога?

Ответственный специалист предприятия. Программа проверяет наличие разрешения и область его действия. Совпадение названия или наличие товара на складе само по себе не подтверждает, что компонент подходит для изделия.

С чего начать разработку такого модуля?

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

Связанные материалы и следующий шаг

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

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