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

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

Что находилось в одной строке

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

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

Строка была не готовой карточкой НСИ, а следом конкретной рабочей ситуации.

Дедупликация — не удаление одинаковых строк

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

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

Автоматическое объединение может уничтожить важное различие. Отказ от объединения сохраняет мусор.

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

Опасность поиска по подстроке

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

Появились ограничения:

  • модели принимаются только по белому списку;
  • короткие совпадения без контекста запрещены;
  • производитель не считается моделью;
  • при нескольких кандидатах связь не создаётся;
  • статус «требует проверки» лучше автоматического выбора.

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

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

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

Пустая ссылка лучше выдуманной связи.

Четыре разные сущности

Нельзя смешивать:

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

Одна запасная часть может подходить нескольким моделям, а один механизм использует множество СЗЧ. Поэтому применимость хранится отдельной связью «многие ко многим», а не единственным реквизитом карточки товара.

Три уровня наименования

Для будущего обмена с ERP сформировалась трёхуровневая модель:

  1. Номенклатура судна — рабочее название экипажа и исходный смысл.
  2. Корпоративная номенклатура ERP — нормализованная позиция компании.
  3. Номенклатура поставщика — внешний уровень закупочного процесса.

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

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

Импорт не должен сразу создавать учётный факт

Файл инвентаризации не должен писать прямо в остатки. Сначала он создаёт черновик документа:

файл
→ распознавание колонок
→ сохранение исходных значений
→ нормализация
→ поиск кандидатов
→ протокол
→ ручная проверка
→ проведение документа
→ движения

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

Нечёткий поиск — последняя ступень

Сопоставление строится последовательно:

  1. точный код, артикул или каталожный номер;
  2. нормализованное наименование;
  3. нечёткий поиск похожих строк;
  4. ручное решение при нескольких кандидатах.

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