Производитель игрушек отгружает продукцию в крупные торговые сети и обменивается с ними документами через Контур.EDI. Сети заказывают товар «в ассортименте»: одна строка в их заказе — это десяток артикулов разных цветов и размеров, которые в 1С учитываются по отдельности. Контур. EDI с наборами 1С работать не умеет, а разработка на стороне вендора оказалась слишком долгой и дорогой. Мы сделали доработку сами — теперь заказ, подтверждение, реализация, УПД с кодами маркировки формируются в несколько кликов, а сеть видит в документах привычную ей номенклатуру.
С какой проблемой пришёл клиент
Заказчик — крупная фабрика игрушек, которая производит более миллиона единиц продукции в год. После перехода на 1С:ERP нужно было поднять электронный обмен документами с покупателями — федеральными сетями. Обмен идёт через Контур.EDI. На этапе тестирования обмена мы упёрлись в конфликт двух логик учёта.
У сети во входящем заказе указана «Игрушка №1 в ассортименте» — это одна номенклатурная позиция. Одна строка в заказе, одна строка в счёте, одна строка в УПД.
У производителя за этой строкой стоят разные артикулы: несколько расцветок, несколько размеров. Каждый — со своей себестоимостью, своими остатками, своими кодами маркировки «Честного знака». Свалить их в одну позицию нельзя: развалится складской учёт и маркировка.
В 1С для компановки одной номенклатуры с разными характеристиками есть готовая сущность — наборы. Набор позволяет вести учёт по отдельным товарам, но выбирать и показывать их как единое целое: удобно и для печатных форм, и для обмена. Ровно то, что нужно.
Проблема в том, что Контур.EDI про наборы 1С ничего не знает. Если в его настройках сопоставить входящую позицию сети с набором 1С, то в заказ клиента запишется сам набор — как обычная номенклатура.
"Что это означало для сотрудников: либо руками разбирать каждый входящий заказ на артикулы, а потом руками же собирать их обратно в позиции сети — для подтверждения, для счёта-фактуры, для УПД. Либо не пользоваться EDI вообще. Первое — это часы рутины каждый день и гарантированные расхождения в документах. Второе — не вариант, потому что заказы от сетей приходят только так."
Александр
ведущий разработчик
Почему не помогло «просто заказать доработку у вендора»
Сначала мы проверили очевидную гипотезу: может, поддержка наборов где-то есть, просто мы её не нашли. Контур.EDI — зрелый продукт с адаптациями под самые разные случаи, версия для 1С у него своя. Мы написали в техподдержку Контура. Ответ: поддержки наборов 1С нет.
Тогда клиент пошёл вторым логичным путём — спросил у Контура, сколько будет стоить доработать решение на их стороне. Логика правильная: своё решение вендор знает лучше всех. Но озвученные цена и сроки оказались несопоставимы с задачей.
Мы предложили сделать это сами. И сразу зафиксировали для себя главное ограничение: лезть в модуль Контура минимально и только там, где без этого не обойтись. Он чужой, объёмный, регулярно обновляется. Чем глубже в него залезешь, тем дороже будет каждое следующее обновление.
Что мы сделали
Заказ пришёл: набор разворачиваем в товары
Сеть присылает заказ, пользователь нажимает «Обработать входящее сообщение» — в 1С создаётся заказ клиента.
Мы добавили проверку в событие перед записью заказа: если заказ новый и в нём есть позиции с типом «набор» — заменяем их составом набора прямо на лету. Позицию-набор убираем, добавляем входящие в него товары.
Два важных следствия:
- Разворачивает набор тот же самый код, который отрабатывает при обычном подборе товаров через интерфейс. То есть заказ получается ровно такой, как если бы менеджер набрал его руками.
- Модуль Контура при этом не затронут вообще. Доработка живёт в заказе клиента и не зависит от того, что и когда вендор поменяет у себя.
Отвечаем сети: товары сворачиваем обратно в набор
Теперь обратная задача. Сеть ждёт от нас подтверждение заказа, а мы отправляем ей то, что лежит в заказе клиента, — то есть развёрнутые артикулы. Для сети это чужая номенклатура: её собственные позиции в подтверждении отменяются как отсутствующие, а вместо них приходят непонятные строки со статусом «Уточнён».
Мы встроились в момент, когда Контур собирает таблицу товаров для исходящего сообщения, и научили её отдавать не отдельные артикулы, а те наборы, из которых они были развёрнуты. Подтверждение уходит в сеть в её собственных позициях, со статусом строк «Подтверждён» — сходятся и количество, и цены, и суммы.
Вот здесь без правок в модуле Контура обойтись уже не удалось. Мы сделали их точечными, чтобы было удобно поддерживать и только там, где это необходимо.
Дальше по цепочке: реализация, счёт-фактура, УПД
Один документ автоматизировать мало — рутина просто переезжает на следующий шаг. Поэтому тем же принципом мы прошли всю цепочку:
- Счёт-фактура. При отправке возникала та же проблема, что и с подтверждением: номенклатура подтягивалась из реализации в развёрнутом виде. Свёртку в наборы добавили и сюда.
- Коды маркировки «Честный знак». После свёртки в наборы УПД уходили в Контур.Диадок без кодов маркировки: коды были подобраны в 1С на артикулы, а в исходящем сообщении артикулов уже нет.
Мы переназначили принадлежность кодов — те, что относятся к комплектующим, теперь считаются кодами набора, и в строку попадает ровно столько кодов, сколько единиц товара в набор входит. Сами коды при этом не меняются и не теряются: их состав в документе совпадает с тем, что физически уходит на отгрузку, а в «Честный знак» данные передаются в прежнем виде.
Попутно: реализация без оглядки на статус отгрузки
Эта задача с наборами напрямую не связана, но всплыла на том же участке. Контур создавал реализацию только с оглядкой на статус отгрузки в заказе. А в работе между контрагентами есть нюансы, которые требуют обмена электронными документами фактической отгрузки. Неотгруженные товары блокировали отправку сообщения в Контуре.
Научили обработку вводить реализацию на основании заказа без учёта состояния отгрузки — и по одной строке, и для группы сообщений сразу.
Переключатель на случай «а давайте посмотрим без вас»
Отдельно клиент попросил возможность отключать код для работы с наборами. Просьба абсолютно понятная: когда в чужом продукте появляется чужая доработка, при любой непонятной ситуации хочется первым делом проверить, не в ней ли дело.
Мы добавили в настройки Контура два собственных переключателя — на свёртку в наборы и на заполнение кодов маркировки. Включаются и выключаются они прямо в интерфейсе настроек, перезапуска и участия программиста не требуют.
Как мы ловили ошибки, которые не видно глазами
Один эпизод хорошо показывает, почему такие проекты не заканчиваются в день релиза.
Доработка уже работала на боевых данных, когда на одной паре «заказ — реализация» свёртка внезапно отвалилась. Система писала, что товарный состав заказа и реализации не совпадает. Открываем оба документа — состав идентичный, отличий нет.
Отличия нашлись в невидимой части. У реализации есть вторая табличная часть — «Виды запасов», — и типовая логика Контура берёт товары именно из неё. А там одна строка товара оказалась разбита на две из-за разной аналитики вида запаса. Для человека документы одинаковые, для программы — нет.
Мы доработали логику так, чтобы подобные ошибки больше не возникали. Случай редкий, но именно на таких редких случаях обычно и рушится доверие к автоматизации.
Что получилось в итоге
Обмен с торговыми сетями работает полным циклом: входящий заказ → заказ клиента → подтверждение → реализация → счёт-фактура и УПД с кодами маркировки → паллетный лист.
- Сеть видит свои позиции, наш заказчик — свои. Никто не подстраивается под чужой учёт, никто не сверяет строки вручную.
- Ручной пересборки документов нет. Разворот и свёртка происходят автоматически, менеджер просто отрабатывает требуемые действия в списке сообщений Контура.
- Обновления Контура не блокированы. Доработки специально помечены в коде и отключаются настройкой. Перенести их на новую версию — понятная и быстрая процедура.
- Ядро решения было готово за месяц. Остальное время ушло на цепочку смежных документов, боевое тестирование и сопровождение.
Почему мы рассказываем этот кейс
Он про типичную ситуацию: есть отраслевой стандарт обмена, есть ваша учётная модель, и они не совпадают. Вендор под вас подстраиваться не будет — вы у него один из тысячи.
Выход почти всегда есть, и он редко лежит в плоскости «перепишем чужой модуль». Гораздо чаще нужно найти несколько точек на стыке систем и аккуратно встроиться в них так, чтобы обе стороны продолжали жить своей жизнью.
Сколько это стоит
Сейчас такой проект стоил бы примерно 260 000 рублей.
Сам подход мы переносим на другие проекты: логика разворота и свёртки наборов уже написана, и на похожей задаче не придётся начинать с нуля. Но объём работ зависит от вашей конфигурации, учётной модели, набора документов в обмене.
Если у вас похожая история — EDI, маркировка, обмен с сетями или любая другая интеграция, которая «почти работает, но не с вашей номенклатурой», — расскажите, что именно не сходится. Посмотрим, решается ли это так же малой кровью.
