ВсеИнструменты API: как настроить интеграцию поставщика через EDI, 1С и ЭДО

Интеграция поставщика с ВсеИнструменты через EDI, 1С и электронный документооборот

Интеграция с ВсеИнструменты.ру часто ищется как «ВсеИнструменты API», но для поставщика важно сразу правильно понять архитектуру обмена. В открытой части партнёрского портала сеть не предлагает классическую публичную REST API-документацию с набором endpoint, токеном и JSON-запросами. Вместо этого для поставщиков описан электронный обмен данными, а опубликованный операторами процесс строится вокруг EDI-сообщений и юридически значимого ЭДО.

Это не означает, что автоматизация невозможна. Наоборот: заказы, подтверждения, отгрузки, цены, товарные справочники и УПД можно встроить в 1С, ERP, WMS, собственную учётную систему или серверный модуль интернет-магазина. Просто интеграция обычно строится не по схеме «ваша система → API ВсеИнструменты», а по цепочке «ваша система → интеграционный слой или EDI-оператор → ВсеИнструменты».

Ниже разберём, как устроена такая интеграция, какие документы участвуют в обмене, где место 1С и сайта, что нужно автоматизировать в первую очередь и какие ошибки чаще всего приводят к расхождениям в заказах и поставках. Материал актуализирован на 19 октября 2026 года.

Есть ли у ВсеИнструменты API для поставщиков

Когда разработчик слышит слово API, обычно он представляет HTTP-интерфейс: авторизация по токену, методы получения заказов, обновления остатков, передачи цен и изменения статусов. Для многих маркетплейсов это действительно основной способ работы. У поставщика ВсеИнструменты модель другая.

На официальном портале для поставщиков сеть говорит о доступе к электронному обмену данными, отчётности по продажам и остаткам, работе через личный кабинет и взаимодействии после заключения договора. В опубликованной документации EDI-операторов для ВсеИнструменты фигурируют стандартные сообщения ORDERS, ORDRSP, DESADV, PRICAT, PRODCAT и УПД.

Поэтому корректнее говорить не «прямой публичный API ВсеИнструменты для поставщика», а «интеграция поставщика с ВсеИнструменты через EDI и ЭДО».

При этом технически API всё равно может присутствовать внутри решения. Например, EDI-оператор может дать собственный API, коннектор к 1С или модуль для ERP. Тогда ваша программа общается по API с оператором, а оператор уже преобразует данные в формат, согласованный с торговой сетью. Для бизнеса итог тот же: ручная работа заменяется автоматическим обменом.

Сначала определите, с какой стороны вы интегрируетесь

Одна из главных причин путаницы — под запросом «ВсеИнструменты API» скрываются две совершенно разные задачи.

Сценарий 1. Вы поставщик ВсеИнструменты

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

Сценарий 2. Вы интернет-магазин или дилер и закупаете товары у ВсеИнструменты

Здесь направление данных противоположное: нужно получить ассортимент, закупочные или доступные цены, наличие и затем, возможно, оформить заказ. Такой сценарий нельзя автоматически считать тем же интерфейсом, который используется поставщиками сети. Возможность программного обмена, доступные данные и условия интеграции нужно отдельно уточнять для конкретного B2B-доступа и договорной модели.

Смешивать эти два сценария опасно: можно выбрать готовое решение, которое умеет выгружать каталог для покупателя, а затем обнаружить, что оно вообще не умеет обрабатывать поставочные ORDERS и DESADV.

Что такое EDI и чем он отличается от обычного REST API

EDI (Electronic Data Interchange) — электронный обмен структурированными коммерческими документами между компаниями. Система передаёт не произвольные JSON-объекты, а документы определённого бизнес-смысла: заказ, ответ на заказ, уведомление об отгрузке, каталог цен и так далее.

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

Условная архитектура

1С / ERP / WMS / сайт
        ↓
интеграционный модуль
        ↓
API / коннектор EDI-оператора
        ↓
EDI + ЭДО
        ↓
ВсеИнструменты.ру

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

Какие сообщения участвуют в обмене

По актуальной базе знаний Ediweb для работы с сетью используются ORDERS, ORDRSP, DESADV, PRICAT, PRODCAT и УПД. У каждого документа своя роль. Если их смешать в одном «универсальном обмене заказом», будет трудно контролировать состояние поставки и разбирать ошибки.

ORDERS — заказ от ВсеИнструменты

ORDERS приходит со стороны торговой сети. Он содержит состав заказа и служит исходной точкой дальнейшего процесса. В документации оператора описаны два варианта заказа: заказ на резерв и заказ на отгрузку. Для заказа на отгрузку передаётся дата доставки.

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

ORDRSP — ответ поставщика на заказ

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

Типичная автоматизация выглядит так: входящий ORDERS создаёт внутренний заказ или резерв, система проверяет доступный остаток, после чего формирует ORDRSP. Если товара меньше, чем запросила сеть, ответ должен содержать фактически подтверждаемое количество, а не исходное количество из ORDERS.

По документации Ediweb в процессе ВсеИнструменты ORDRSP также используется для подтверждения наличия. Для некоторых сценариев сначала приходит заказ на резерв, затем после ответа сеть формирует заказ на поставку. Именно поэтому нельзя строить интеграцию по принципу «получил первый ORDERS — сразу отгрузил».

DESADV — уведомление об отгрузке

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

В документации для сети среди значимых данных фигурируют номер и дата заказа покупателя, ориентировочная дата поставки, штрихкод, артикул покупателя, артикул поставщика, описание товара, отправленное количество, единица измерения, ставка НДС и другие поля поставки.

Если склад отгрузил 98 единиц вместо 100, а DESADV ушёл на 100, расхождение обнаружится уже на приёмке или в документах. Поэтому DESADV лучше формировать из подтверждённого складского факта, а не из первоначального заказа.

PRICAT — каталог цен

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

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

PRODCAT — каталог товаров

PRODCAT отвечает за товарный справочник. Он помогает передавать и сопоставлять данные о номенклатуре. Для интеграции это особенно важно, потому что один и тот же товар может иметь несколько идентификаторов: внутренний ID в 1С, артикул поставщика, код торговой сети, штрихкод GTIN/EAN и ID в промежуточной системе.

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

УПД — юридически значимый документ

После фактической поставки процесс закрывается УПД. В базе знаний Ediweb для ВсеИнструменты указана работа с УПД с функциями СЧФДОП, СЧФ и ДОП для соответствующих налоговых сценариев. УПД относится уже не просто к оперативному EDI, а к юридически значимому электронному документообороту.

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

Как выглядит полный цикл заказа

Если упростить процесс до понятной технической последовательности, получится следующая цепочка:

ВсеИнструменты формирует ORDERS.
EDI-оператор принимает документ и передаёт его поставщику.
Интеграционный модуль загружает ORDERS в 1С/ERP.
Номенклатура сопоставляется с внутренними товарами.
Система проверяет доступное количество и возможность поставки.
Формируется ORDRSP с подтверждением или корректировкой количества.
После получения заказа на фактическую поставку склад комплектует товар.
На основании реальной отгрузки формируется DESADV.
Товар принимается торговой сетью.
Формируется и подписывается УПД.
Статус документов и возможные расхождения возвращаются в учётную систему.

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

Где в этой схеме 1С

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

Хорошая архитектура обычно разделяет несколько зон ответственности:

1С/ERP — номенклатура, остатки, резервы, внутренние документы, цены и финансовый учёт;
WMS — фактическая сборка и отгрузка, если склад управляется отдельной системой;
EDI-слой — обмен коммерческими сообщениями с сетью;
ЭДО — юридически значимые документы и подпись;
сайт — витрина и собственный канал продаж, если он вообще участвует в процессе.

Если сайт на 1С-Битрикс уже получает каталог и остатки из 1С, не стоит делать его промежуточным источником данных только ради ВсеИнструменты. Чем длиннее цепочка «1С → сайт → интеграция → EDI», тем больше точек, где данные могут устареть или потеряться.

Можно ли интегрировать ВсеИнструменты с сайтом на 1С-Битрикс

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

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

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

Тяжёлую обработку не нужно выполнять в пользовательском HTTP-запросе. Для регулярного обмена лучше использовать cron, очередь заданий или отдельный worker. Общие принципы такой архитектуры мы разбирали в статье про очереди и пакетную обработку в интеграциях.

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

Запрос «ВсеИнструменты API остатки» особенно часто вводит в заблуждение. Официальный портал поставщика говорит о доступе к отчётности по продажам и остаткам, но в опубликованном Ediweb перечне основных сообщений для сети отдельный стандартный поток передачи остатка поставщика не выделен рядом с ORDERS, ORDRSP, DESADV, PRICAT и PRODCAT.

Поэтому механизм остатков нельзя придумывать самостоятельно. До разработки нужно зафиксировать с менеджером сети и EDI-оператором:

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

Самая опасная ошибка — выгружать физический складской остаток без учёта резервов. Если на складе лежит 100 единиц, но 70 уже зарезервированы под другие заказы, обещать сети 100 нельзя.

Как правильно сопоставить товары

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

Для каждого товара полезно хранить отдельные технические поля:

внутренний ID товара;
артикул поставщика;
код товара ВсеИнструменты, если он передаётся и используется в процессе;
штрихкод;
единицу измерения;
коэффициент упаковки;
ставку НДС и другие реквизиты, если они нужны документам;
дату последней успешной синхронизации.

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

Единицы измерения и упаковки — скрытый источник ошибок

Даже когда артикул совпадает, количество может трактоваться по-разному. В учёте поставщика товар хранится штуками, торговая сеть заказывает упаковками, а в коробе лежит 12 единиц. Если коэффициент не зафиксирован, заказ на 10 упаковок может превратиться в отгрузку 10 штук вместо 120.

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

Цены: почему PRICAT нельзя отправлять «как получится»

Цена в поставочной интеграции — это договорное значение, а не просто число из поля PRICE. Перед автоматизацией необходимо определить:

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

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

Идемпотентность: один документ не должен создаваться дважды

Сетевые интеграции работают в условиях повторных доставок, таймаутов и retry. Один и тот же ORDERS может технически попасть в обработчик повторно. Если каждая доставка создаёт новый заказ в 1С, через несколько часов появятся дубли.

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

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

Очередь вместо синхронной обработки

EDI-интеграция не должна зависеть от того, открыт ли браузер менеджера и успеет ли PHP выполнить длинную операцию за один запрос. Надёжнее разделить получение события и бизнес-обработку.

Например:

коннектор получает ORDERS;
сохраняет исходный документ;
создаёт задачу в очереди;
worker сопоставляет товары и создаёт заказ;
результат фиксируется в журнале;
при временной ошибке выполняется повторная попытка;
после нескольких неудач задача переводится в состояние для ручного разбора.

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

Какие ошибки нужно логировать

Фраза «обмен не работает» бесполезна для поддержки. В журнале должно быть достаточно информации, чтобы за несколько минут понять, на каком этапе произошёл сбой.

Минимальный набор:

тип сообщения: ORDERS, ORDRSP, DESADV, PRICAT, PRODCAT, УПД;
внешний идентификатор документа;
связанный внутренний ID;
дата и время получения или отправки;
статус обработки;
номер попытки;
код и категория ошибки;
понятное сообщение для администратора;
технические детали для разработчика.

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

Какие ошибки считать временными, а какие постоянными

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

Полезно разделить ошибки минимум на три группы:

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

Для каждой группы нужен свой сценарий: retry, аварийное уведомление разработчику или задача менеджеру.

Как работать с изменениями заказа

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

При каждом изменении система должна ответить на вопросы:

какая версия данных сейчас актуальна;
успел ли склад начать сборку;
был ли уже отправлен ORDRSP;
был ли сформирован DESADV;
можно ли автоматически применить изменение;
нужно ли участие менеджера.

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

Маркированные товары

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

До внедрения важно выяснить у сети и оператора, на каком этапе передаются коды, кто формирует агрегаты, как обрабатываются расхождения и какие дополнительные модули EDI/ЭДО нужны. Эту часть нельзя универсализировать без знания категории товара.

УПД, электронная подпись и МЧД

Автоматизация заканчивается не на DESADV. Для полноценного процесса необходимо понимать, кто подписывает УПД и как устроены полномочия. Если документ подписывает не руководитель организации, может потребоваться машиночитаемая доверенность в соответствии с используемой схемой ЭДО.

С технической стороны важно не хранить закрытый ключ электронной подписи внутри веб-проекта или в каталоге сайта. Работа с подписью должна выполняться средствами оператора, сертифицированного ПО или защищённого рабочего места.

Кабинет оператора или полная автоматизация

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

Кабинет EDI-оператора подходит, если

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

Автоматическая интеграция нужна, если

заказы приходят регулярно;
ассортимент большой;
остатки и резервы ведутся в 1С/ERP/WMS;
ручной перенос уже создаёт ошибки;
важно подтверждать заказы быстро;
нужно контролировать SLA и историю обмена;
работа идёт одновременно с несколькими торговыми сетями.

Главный критерий — не количество API-методов, а стоимость ручной ошибки. Если одна неверная отгрузка создаёт больше затрат, чем месяц эксплуатации интеграции, автоматизация уже имеет экономический смысл.

Если торговых сетей несколько

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

Лучше создать единый внутренний формат:

Внутренний заказ
  ├─ контрагент
  ├─ внешний ID
  ├─ позиции
  ├─ подтверждённое количество
  ├─ дата поставки
  ├─ статус
  └─ история документов

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

Так бизнес-логика остаётся единой, а различия форматов изолируются в интеграционном слое.

Как подготовить 1С к интеграции

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

Проверьте:

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

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

Какой модуль интеграции нужен

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

1. Транспорт

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

2. Парсер и валидатор

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

3. Маппинг

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

4. Бизнес-логика

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

5. Генератор исходящих сообщений

Формирует ORDRSP, DESADV и другие документы на основании фактического состояния учётной системы.

6. Журнал и мониторинг

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

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

Безопасность интеграции

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

Базовые требования:

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

Подробнее о хранении секретов — в статье про API-ключи, OAuth и токены.

Мониторинг: интеграция не должна ломаться молча

Самый дорогой сбой — тот, который произошёл утром, а обнаружился вечером, когда заказ уже просрочен. Поэтому кроме журнала нужен мониторинг.

Полезные контрольные события:

новый ORDERS не обработан дольше допустимого времени;
для заказа не сформирован ORDRSP;
DESADV создан, но не отправлен;
в очереди растёт количество ошибок;
более N документов подряд не прошли;
соединения с оператором не было несколько часов;
появился неизвестный внешний товар;
УПД отклонён или требует исправления.

Уведомления можно отправлять в email, Telegram, корпоративный чат или систему мониторинга. Но само уведомление должно содержать номер документа и понятную причину, а не только «ошибка интеграции».

Сверка — обязательная часть обмена

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

Полезно регулярно сравнивать:

полученные ORDERS и созданные внутренние заказы;
подтверждённые количества и фактические резервы;
DESADV и реальные складские отгрузки;
отправленные УПД и документы в учёте;
ошибочные документы, которые не были повторно обработаны.

Сверка превращает потенциально скрытую потерю документа в контролируемую задачу.

Тестовый контур перед запуском

Нельзя проверять интеграцию только одним счастливым сценарием «один товар, одна штука, всё совпало». До промышленного запуска нужно прогнать набор сценариев.

Обычный заказ с несколькими товарами.
Товар полностью отсутствует.
Доступна только часть количества.
Неизвестный артикул.
Дублирующий ORDERS.
Повторная отправка ORDRSP.
Изменение количества перед отгрузкой.
Расхождение между заказом и фактической отгрузкой.
Временная недоступность EDI-оператора.
Ошибка авторизации.
Некорректная цена.
Ошибка в УПД и повторное формирование.

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

Как проходит внедрение интеграции на практике

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

Этап 1. Сбор требований

Фиксируем договорную модель, оператора, перечень документов, участников процесса, склады, номенклатуру, цены и ответственность сотрудников.

Этап 2. Описание схемы данных

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

Этап 3. Прототип обмена

Добиваемся технического получения и отправки тестового документа без сложной бизнес-логики.

Этап 4. Автоматизация бизнес-процесса

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

Этап 5. Обработка ошибок

Добавляем очередь, retry, журнал, ручное повторение и уведомления.

Этап 6. Тестовые поставки

Проверяем реальные цепочки документов на ограниченном объёме.

Этап 7. Промышленный запуск

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

Этап 8. Поддержка

Следим за изменениями форматов, обновлениями 1С, сертификатов, правил ЭДО и требований торговой сети.

Что нужно запросить до начала разработки

Чтобы разработчик не проектировал интеграцию по догадкам, соберите пакет исходных данных:

договор и инструкции поставщика в части электронного обмена;
название EDI/ЭДО-оператора;
актуальные спецификации сообщений;
тестовый ORDERS;
пример корректного ORDRSP;
пример DESADV;
требования к PRICAT и PRODCAT;
правила УПД;
идентификаторы организации и точек доставки;
правила работы с артикулами и штрихкодами;
описание процессов резерва и отгрузки в 1С.

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

Типичные ошибки при интеграции с ВсеИнструменты

Ошибка 1. Искать только REST API торговой сети

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

Ошибка 2. Делать сайт главным источником данных без причины

Если учёт ведётся в 1С, интеграция через сайт добавляет лишнюю точку отказа.

Ошибка 3. Сопоставлять товар по названию

Для автоматического обмена нужны стабильные идентификаторы.

Ошибка 4. Подтверждать исходное количество без проверки свободного остатка

ORDRSP должен отражать реальную возможность поставки.

Ошибка 5. Формировать DESADV из плана, а не из факта отгрузки

Это создаёт расхождения на приёмке.

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

Результат — дубли заказов и отгрузок.

Ошибка 7. Не хранить исходный внешний документ

Без него сложно доказать, какие данные реально пришли и где возникло расхождение.

Ошибка 8. Не делать мониторинг

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

Ошибка 9. Смешивать EDI и ЭДО в один неразделимый процесс

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

Ошибка 10. Запускать без тестов на частичных и ошибочных сценариях

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

Когда можно обойтись без собственной разработки

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

Правильная цель проекта — не «написать больше кода», а убрать ручные операции и сделать обмен контролируемым.

Как оценить трудоёмкость проекта

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

На оценку влияют:

конфигурация и степень доработки 1С;
наличие WMS;
способ подключения к EDI-оператору;
количество типов документов;
объём номенклатуры;
качество справочников;
количество складов и юрлиц;
необходимость маркировки;
автоматизация УПД;
требования к мониторингу и журналу;
наличие готовых тестовых примеров.

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

Практический чек-лист интеграции ВсеИнструменты

Подтвердить, что вы подключаетесь именно как поставщик.
Получить договор и доступ в личный кабинет поставщика.
Уточнить используемого EDI/ЭДО-оператора и порядок подключения.
Получить актуальные спецификации сообщений.
Определить мастер-систему: 1С, ERP или другая система.
Зафиксировать идентификаторы товаров и правила маппинга.
Определить источник цен для PRICAT.
Согласовать механизм работы с остатками.
Настроить получение ORDERS.
Реализовать проверку остатков и ORDRSP.
Связать DESADV с фактической складской отгрузкой.
Настроить УПД и электронную подпись.
Добавить защиту от дублей.
Добавить очередь и повторные попытки.
Добавить журнал и мониторинг.
Протестировать частичные, повторные и ошибочные сценарии.
Провести несколько контролируемых поставок.
После запуска регулярно сверять документы между системами.

Итог: интеграция возможна, но начинать нужно не с поиска endpoint

Если задача звучит как «подключить ВсеИнструменты API», для поставщика первый вопрос должен быть не «где получить токен», а «какой EDI-процесс и оператор предусмотрены нашим договором». В опубликованной схеме взаимодействия торговой сети центральную роль играют ORDERS, ORDRSP, DESADV, PRICAT, PRODCAT и УПД.

Дальше это уже полноценная интеграционная задача: связать документы сети с 1С/ERP, сопоставить товары, правильно учитывать остатки и резервы, передавать фактическую отгрузку, исключить дубли, настроить ЭДО и сделать мониторинг.

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

В ЭКШН АЙТИ мы занимаемся проектированием API- и системных интеграций, доработкой обменов с 1С/ERP и технической поддержкой действующих проектов. Если у вас уже есть доступ поставщика ВсеИнструменты, спецификации EDI и примеры документов, по ним можно определить реальную архитектуру и объём разработки без догадок.

Источники и актуальность

При подготовке материала использованы открытые данные официального портала поставщиков ВсеИнструменты.ру и актуальная база знаний Ediweb по работе с сетью. Конкретные форматы, обязательные поля и схема подключения могут зависеть от договора, оператора и настроек вашей компании, поэтому перед внедрением нужно запросить действующие спецификации у вашей стороны ВсеИнструменты и EDI/ЭДО-оператора.