Одна позиция торговой сети — десяток позиций в 1С. Как мы научили Контур.EDI работать с наборами 1С

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

Заказчик — крупная фабрика игрушек, которая производит более миллиона единиц продукции в год. После перехода на 1С:ERP нужно было поднять электронный обмен документами с покупателями — федеральными сетями. Обмен идёт через Контур.EDI. На этапе тестирования обмена мы упёрлись в конфликт двух логик учёта.

У сети во входящем заказе указана «Игрушка №1 в ассортименте» — это одна номенклатурная позиция. Одна строка в заказе, одна строка в счёте, одна строка в УПД.

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

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

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

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

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

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

Сеть присылает заказ, пользователь нажимает «Обработать входящее сообщение» — в 1С создаётся заказ клиента.

Мы добавили проверку в событие перед записью заказа: если заказ новый и в нём есть позиции с типом «набор» — заменяем их составом набора прямо на лету. Позицию-набор убираем, добавляем входящие в него товары.

Два важных следствия:

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

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

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

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

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

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

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

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

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

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

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

Отличия нашлись в невидимой части. У реализации есть вторая табличная часть — «Виды запасов», — и типовая логика Контура берёт товары именно из неё. А там одна строка товара оказалась разбита на две из-за разной аналитики вида запаса. Для человека документы одинаковые, для программы — нет.

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

Обмен с торговыми сетями работает полным циклом: входящий заказ → заказ клиента → подтверждение → реализация → счёт-фактура и УПД с кодами маркировки → паллетный лист.

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

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

Сейчас такой проект стоил бы примерно 260 000 рублей.

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

Если у вас похожая история — EDI, маркировка, обмен с сетями или любая другая интеграция, которая «почти работает, но не с вашей номенклатурой», — расскажите, что именно не сходится. Посмотрим, решается ли это так же малой кровью.