T-FLEX + ЛОЦМАН + 1С:ERP: как построить единый контур данных производства

В промышленной автоматизации редко бывает одна система, которая одинаково хорошо решает все задачи.

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

Поэтому архитектура T-FLEX + ЛОЦМАН:PLM + 1С:ERP сама по себе не является проблемой. Проблемой становится отсутствие понятной границы ответственности между системами.

Что должна делать каждая система

Начинать интеграцию нужно не с API и формата XML, а с ответа на вопрос: какая система является источником конкретных данных?

Система	Основная зона ответственности	Типичные данные
T-FLEX CAD	Конструкторская разработка	3D-модели, чертежи, сборки, конструкторские данные
ЛОЦМАН:PLM	Управление инженерными данными и ЖЦИ	структуры изделий, версии, документы, атрибуты, состояния
Технологический контур	Технологическая подготовка производства	операции, маршруты, материалы, оборудование, нормы
1С:ERP	Управление производством и ресурсами	номенклатура, заказы, материалы, этапы, мощности, выпуск, себестоимость

T-FLEX PLM позиционируется как единая платформа управления жизненным циклом изделия, объединяющая CAD, PDM/PLM и инструменты технологической подготовки. T-FLEX DOCs выступает хранилищем инженерной информации, которая может передаваться в ERP через XML или специализированные программные модули/API.

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

Следовательно, задача интеграции — не «скопировать ЛОЦМАН в 1С», а передать в ERP именно тот набор инженерных данных, который нужен для производственного управления.

Почему простая синхронизация справочников не решает задачу

На первом этапе интеграционного проекта часто формулируют задачу так:

Технически это выглядит понятно. Но промышленное изделие — это не просто набор строк справочника.

Нужно учитывать:

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

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

Главный принцип: источник данных должен быть один

Одна из самых опасных архитектурных ошибок — разрешить пользователям редактировать одну и ту же сущность во всех системах.

Например:

• конструктор меняет состав изделия в ЛОЦМАН;
• технолог вручную исправляет его в 1С;
• планировщик добавляет ещё одну позицию непосредственно в ERP;
• следующая выгрузка из PLM перезаписывает часть изменений.

Через несколько месяцев никто уже не понимает, какая версия является актуальной.

Поэтому для каждой сущности нужно определить system of record.

Сущность	Источник	Потребители
Конструкторская структура	PLM	Технология, ERP
3D / чертёж	T-FLEX	PLM, технологический контур
Технологический маршрут	Технологический контур	ERP, производство
Номенклатура для учёта	ERP / согласованный MDM-контур	PLM, производство, закупки
Производственный заказ	1С:ERP	производство, аналитика
Факт выпуска	1С:ERP / MES	аналитика, себестоимость

Конкретное распределение зависит от методологии предприятия. Но сам принцип должен быть формализован до разработки интеграции.

Какой поток данных должен получиться

Для типового машиностроительного предприятия поток можно представить так:

Важный момент: это не обязательно означает односторонний обмен.

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

Что передавать из ЛОЦМАН в 1С:ERP

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

1. Номенклатура

Изделия, детали, сборочные единицы, материалы, стандартные изделия и покупные компоненты.

Здесь важно заранее определить правила идентификации:

• внутренний идентификатор PLM;
• код ERP;
• обозначение;
• наименование;
• единица измерения;
• тип объекта;
• признак собственного или покупного изделия.

2. Состав изделия

Это одна из самых важных частей интеграции.

ERP должна получить не просто список компонентов, а структуру с отношениями родитель → дочерний объект и необходимыми параметрами:

Поле	Пример
Родитель	Корпус К-204
Компонент	Крышка К-204.01
Количество	2 шт.
Единица	шт.
Версия	03
Статус	Утверждено

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

3. Технологические данные

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

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

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

Версии — самая недооценённая часть интеграции

Представим ситуацию.

Конструктор изменил толщину детали и выпустил новую версию. PLM уже содержит актуальную структуру, а в 1С по-прежнему используется старая спецификация.

Если просто выполнить синхронизацию, возникает вопрос:

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

На практике это может быть связано с:

• состоянием объекта;
• утверждением документа;
• извещением об изменении;
• датой ввода в действие;
• конкретным производственным заказом;
• остатками уже выпущенных деталей.

Без этого автоматическая синхронизация может стать источником производственных ошибок.

Не каждое изменение нужно сразу отправлять в ERP

Это ещё одна важная граница.

Конструктор может работать над новой версией изделия несколько дней. В этот момент PLM содержит незавершённые изменения. ERP не должна автоматически получать каждый промежуточный вариант.

Поэтому нужен бизнес-триггер публикации.

Например:

Такой подход гораздо безопаснее, чем постоянная двусторонняя синхронизация каждой записи.

Интеграционная шина: зачем она нужна

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

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

Для ЛОЦМАН:PLM существует концепция Интеграционной шины предприятия, предназначенной для обмена между PLM/PDM, ERP и MES-системами. В документации АСКОН отдельно выделены задачи устранения различий моделей данных, унификации терминологии, типов данных и единиц измерения, а также выявления конфликтов при обмене.

Это хорошо показывает саму архитектурную проблему: интеграция — это не только транспорт данных. Это ещё и преобразование семантики.

Mapping: где чаще всего ломается интеграция

Предположим, в PLM есть объект:

{
    "code": "A-204.01",
    "name": "Крышка",
    "unit": "шт",
    "version": "03"
}

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

Поэтому нужен mapping:

PLM	Integration Layer	1С:ERP
code	ItemIdentity	Артикул / Код
name	ItemName	Наименование
unit	UnitCode	Единица хранения
version	Revision	Версия / состояние

Хороший integration layer не должен просто «переименовывать поля». Он должен проверять бизнес-правила.

Например:

• существует ли номенклатура в ERP;
• совпадает ли единица измерения;
• можно ли публиковать текущую версию;
• существует ли родительский объект;
• не создаётся ли дубликат;
• не изменилась ли уже утверждённая спецификация.

Почему прямой доступ к базам — плохая идея

В старых интеграционных проектах можно встретить архитектуру:

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

После обновления PLM или ERP меняется структура таблиц, внутренние идентификаторы или правила хранения данных — и интеграция начинает зависеть от конкретной версии продукта.

Гораздо устойчивее работать через поддерживаемые интерфейсы и отдельный интеграционный слой.

Современные решения T-FLEX предоставляют API и механизмы обмена, а документация ЛОЦМАН указывает интеграцию с ERP и 1С:Предприятие как отдельное направление взаимодействия.

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

Как обрабатывать ошибки

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

Типовые ошибки:

• не найдена номенклатура;
• не найден родитель структуры;
• неизвестная единица измерения;
• версия уже изменилась;
• объект находится не в том состоянии;
• 1С временно недоступна;
• ошибка в обязательном реквизите;
• конфликт двух изменений.

Поэтому интеграция должна иметь минимум:

• очередь сообщений;
• идемпотентность;
• retry для временных ошибок;
• dead-letter очередь для неразрешимых сообщений;
• журнал интеграционных операций;
• correlation ID;
• контроль версии объекта;
• понятный интерфейс повторной обработки.

Идемпотентность: один из главных принципов

Представим, что PLM отправил структуру изделия, а интеграционный сервис не получил подтверждение от 1С из-за сетевого сбоя.

Система повторяет сообщение.

Если обработчик неидемпотентен, в ERP может появиться дубль.

Поэтому каждое сообщение должно иметь устойчивый идентификатор:

{
    "eventId": "plm-7f3a...",
    "entityId": "A-204.01",
    "entityVersion": "03",
    "eventType": "StructureApproved"
}

ERP или integration layer должен уметь определить: это новая команда или повторная доставка уже обработанного события?

Что делать с обратной связью из ERP

После передачи инженерных данных интеграция не заканчивается.

Производственный контур может сообщать:

• создана ли производственная спецификация;
• принята ли структура;
• есть ли ошибки в данных;
• по каким заказам используется изделие;
• какая версия фактически участвует в производстве.

В некоторых сценариях полезно возвращать в PLM информацию о производственном использовании версии изделия. Это особенно важно при управлении изменениями.

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

Как связать PLM и производственные изменения

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

Например:

1. Изделие К-204 версии 03 используется в производственном заказе.
2. Конструктор выпускает версию 04.
3. Версия 04 проходит согласование.
4. Интеграция передаёт изменение в ERP.
5. ERP должна определить, для каких новых заказов использовать версию 04.
6. Уже запущенные заказы продолжают работать по правилам предприятия.

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

Единый контур не означает единую модель данных

Это принципиальное различие.

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

Например, конструктор видит:

Технолог видит:

ERP видит:

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

Какой integration layer нужен между системами

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

Функция	Что делает
Transport	Получает и отправляет сообщения
Mapping	Преобразует модели данных
Validation	Проверяет бизнес-правила
Orchestration	Определяет порядок и условия обработки

Технологически такой слой может быть реализован на Symfony/Go с PostgreSQL и очередями. Важно не конкретное название фреймворка, а то, чтобы интеграционная логика не была размазана по SQL-запросам, обработчикам 1С и скриптам внутри PLM.

Пример архитектуры ModernERP

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

Например, позже к контуру можно подключить MES:

Где появляется bottleneck-анализ

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

Например, можно построить цепочку:

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

AI поверх единого контура

Когда PLM и ERP связаны через контролируемый слой, AI можно подключать не к сырым таблицам, а к бизнес-инструментам.

Например:

get_product_structure()
get_product_revision()
get_production_route()
get_work_center_load()
get_material_shortages()
get_production_orders()
get_bottlenecks()

Руководитель может спросить:

AI получает структурированные данные из PLM и ERP, сопоставляет их и формирует объяснение.

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

Как запускать проект интеграции

Не стоит начинать с требования «синхронизировать всё со всем».

Практичнее идти по одному сквозному бизнес-сценарию.

1. Выбрать одну группу изделий.
2. Определить владельца данных по каждой сущности.
3. Описать жизненный цикл изделия.
4. Определить момент публикации инженерных изменений.
5. Составить mapping PLM → ERP.
6. Определить минимальный пакет данных.
7. Реализовать валидацию.
8. Добавить очередь и идемпотентную обработку.
9. Настроить журнал ошибок.
10. Проверить сценарий изменения уже используемой версии.
11. Только после этого масштабировать на остальные изделия и подразделения.

Что проверить до разработки

До написания первого коннектора стоит собрать таблицу интеграционных объектов:

Объект	Источник	Приёмник	Триггер	Ключ
Номенклатура	PLM / MDM	1С	Публикация	Уникальный идентификатор
Структура изделия	PLM	1С	Утверждение	Изделие + версия
Технологический маршрут	Технологический контур	1С	Утверждение	Изделие + версия
Производственный заказ	1С	Аналитика / MES	Изменение статуса	Номер заказа
Факт производства	1С / MES	Analytics	Проведение / событие	Документ + строка

Такая таблица часто экономит больше времени, чем несколько недель разработки. Она заставляет команду договориться о смысле данных до обсуждения конкретного API.

Типовые ошибки интеграции T-FLEX / ЛОЦМАН / 1С

Ошибка 1. Синхронизировать всё в обе стороны

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

Ошибка 2. Передавать каждое изменение

Промежуточные инженерные изменения не обязательно должны попадать в ERP. Нужен контролируемый момент публикации.

Ошибка 3. Игнорировать версии

Без версии невозможно надёжно определить, какой состав изделия должен использовать конкретный производственный заказ.

Ошибка 4. Делать mapping только по наименованию

Одинаковые названия не являются надёжным идентификатором промышленного объекта.

Ошибка 5. Делать интеграцию через прямой SQL

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

Ошибка 6. Не делать повторную обработку

В реальной эксплуатации сеть, сервисы и базы иногда недоступны. Ошибка должна становиться управляемым состоянием, а не потерянным сообщением.

Ошибка 7. Сразу подключать AI

Если базовые инженерные и производственные данные не согласованы, нейросеть только ускорит получение противоречивых ответов.

Что должно получиться в итоге

Целевой результат — не просто обмен между тремя программами.

Нужно получить сквозной цифровой контур:

T-FLEX и ЛОЦМАН отвечают за инженерную часть жизненного цикла изделия, технологический контур формирует данные подготовки производства, а 1С:ERP использует необходимые сведения для планирования, обеспечения, производства и экономического учёта.

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

Итог

T-FLEX + ЛОЦМАН + 1С:ERP можно объединить в единый информационный контур, но начинать нужно не с вопроса «какой API использовать», а с модели данных и жизненного цикла изделия.

Главные принципы:

• у каждой сущности есть источник истины;
• инженерные изменения публикуются в ERP только после нужного состояния;
• версии изделий и спецификаций являются частью интеграции;
• структуры PLM и ERP могут различаться, но связи между ними должны сохраняться;
• mapping и validation должны находиться в контролируемом интеграционном слое;
• очереди, retry и идемпотентность нужны для промышленной эксплуатации;
• 1С не должна превращаться в копию PLM;
• AI имеет смысл подключать после того, как данные и бизнес-правила уже структурированы.

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

Именно такой подход позволяет строить следующий уровень автоматизации: bottleneck-анализ, сквозное планирование, AI-аналитику и цифрового помощника руководителя производства поверх реальных данных предприятия.