Кейсы

Сопоставление номенклатуры поставщиков в 1С:ERP: как мы перевели подбор из ручного режима в полуавтоматический

Доработка
В спецификации проекта — 2000 строк оборудования. У каждого поставщика — свои названия, свои единицы измерения, свой язык. Чтобы загрузить один счёт в 1С, закупщик вручную подбирал каждую позицию из справочника. При следующей загрузке от того же поставщика — всё заново. Мы разработали механизм автоматического сопоставления, который запоминает результаты, фильтрует подбор по проекту, сам пересчитывает единицы измерения — и работает при загрузке счетов, обработке спецификаций и загрузке прайсов из Excel.
Этот кейс — часть большого проекта по внедрению 1С:ERP (подробнее — в обзорной статье). Как устроена подсистема планирования и закупок, в которую встроено сопоставление, — отдельном кейсе.

О клиенте

Крупная строительная компания, работающая на государственных объектах. Несколько тысяч сотрудников, около 200 пользователей 1С. Одновременно в работе — порядка 30 проектов. Компания закупает специализированное оборудование у десятков поставщиков, в том числе иностранных.

С чем столкнулись

При загрузке данных от поставщиков — прайсов, счетов, накладных — нужно связать каждую строку документа с позицией справочника «Номенклатура» в 1С. Звучит просто, но на практике это одна из самых трудоёмких операций в закупках.
Названия не совпадают. Поставщик называет товар по-своему: на другом языке, в другом формате, с другими сокращениями. Один и тот же товар у разных поставщиков может выглядеть как совершенно разные позиции.
Единицы измерения разные. Компания учитывает кабель в метрах, а поставщик продаёт в штуках. Или наоборот. Каждый раз — ручной пересчёт количества.
Каждый раз — с нуля. При повторной загрузке от того же поставщика ту же работу приходилось делать заново. Система не запоминала предыдущие сопоставления.
Слишком большой выбор. Когда закупщик открывал справочник для ручного подбора, перед ним были тысячи позиций по всем проектам сразу. Найти нужную сложно, ошибиться — легко.
Сопоставление нужно в трёх местах. При загрузке входящих счетов через сервис Энтера — закупщик фотографирует первичный документ, сервис распознаёт его и передаёт данные в 1С, но позиции нужно связать с номенклатурой. При обработке проектных спецификаций — инженеры описывают оборудование текстом, а закупщикам нужна конкретная номенклатура для заказа. При загрузке прайсов из Excel — поставщик присылает файл с ценами, и их нужно привязать к позициям в базе.
Три точки входа: Энтера / Спецификации / Прайсы → единый механизм сопоставления → Номенклатура 1С
Три точки входа: Энтера / Спецификации / Прайсы → единый механизм сопоставления → Номенклатура 1С

Как устроен механизм

Мы строили его итеративно. Начали ещё в 1С:Управление торговлей, после перехода компании на ERP перенесли наработки и развивали уже в новой системе.

Многоуровневый поиск

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

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


Андрей
тех. лид проекта

Запоминание сопоставлений

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

Фильтрация по проекту

У каждого строительного объекта — своя номенклатура. Искать нужную позицию среди тысяч записей всей базы — долго и рискованно. Мы добавили фильтр: если закупщик указал проект, список подбора ограничивается номенклатурой, которая фигурирует в плане именно этого объекта. Все виды поиска — и автоматический, и ручной подбор — учитывают фильтр. Если проект не указан — подбор работает по полной базе, как раньше.
Дополнительное ограничение: при сопоставлении по проекту создание новой номенклатуры заблокировано. Если позиции нет в плане — значит, её не должно быть и в документе.

Пересчёт единиц измерения

Компания учитывает кабель в метрах, поставщик продаёт в штуках. Мы добавили механизм, который запоминает соответствие единиц для каждой позиции: «для номенклатуры N наши 1000 м = 1 шт от поставщика». При загрузке документа обработка автоматически пересчитывает количество. Соответствие задаётся один раз — дальше всё работает само.

Корректное создание номенклатуры

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

Сопоставление по коду спеки

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

Доработки интерфейса

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

Как мы разобрались с «непобедимой» позицией

Отдельная история, которая хорошо показывает, почему типовые механизмы не всегда работают «из коробки».
Типовое сопоставление стабильно не находило позиции одного из производителей оборудования — хотя они были в базе. Мы провели расследование и выяснили причину.
Полное наименование такой позиции в счёте поставщика — это несколько десятков технических характеристик, аббревиатур и кодов: модель, грузоподъёмность, скорость, габариты, мощность, класс исполнения. При разбиении на слова получалось 87 фрагментов — включая цифры, единицы измерения и коды. Типовой алгоритм требует минимальный коэффициент соответствия 30, а каждое отдельное «слово» из такой строки давало коэффициент 1. Алгоритм фактически находил нужную позицию, но отбрасывал её как «недостаточно похожую».
Решение: переключили источник слов для словаря сопоставления с полного наименования на сокращённое — оно содержит ключевые слова без технических подробностей. И добавили настраиваемый порог минимальной длины слова — чтобы однобуквенные фрагменты и цифры не «разбавляли» результат. Подготовили инструмент для перезаполнения словаря — чтобы изменения применились ко всей базе номенклатуры.

Что получилось

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

Стоимость и сроки

Механизм сопоставления разрабатывался и дорабатывался на протяжении года. Начинали ещё в 1С:Управление торговлей, после перехода на ERP перенесли и развивали дальше. Стоимость подобного проекта — от 330 000 рублей. Общая стоимость проекта внедрения ERP, сроки и состав работ — в обзорной статье.
Если у вас похожая ситуация — поставщики с разной номенклатурой, ручной подбор, потерянное время — напишите, разберёмся.