ТЗ на интеграцию сайта со складом

Коротко: Грамотное ТЗ на интеграцию сайта с складом должно объединять передачу товарных остатков, управление ценами и сквозную работу с маркировкой «Честный знак». Техническое задание обязано включать требования к обмену через ЭДО, поддержку 2D-сканеров для Data Matrix и автоматическую синхронизацию статусов заказов, чтобы избежать штрафов за нарушение правил оборота товаров в 2026 году.

Кстати, в AmSales мы делаем автоматизацию склада и интеграцию с 1С под ключ. Если нужна помощь - напишите нам.

Функциональные требования к обмену данными

Когда вы ставите задачу разработчикам, важно понимать: интеграция - это не просто «перенос цифр». Это настройка двустороннего коридора, по которому данные бегают туда и обратно. Если вы просто настроите выгрузку остатков с сайта на склад, вы получите классическую проблему: клиент купил товар, который уже забронирован другим покупателем в офлайне или в другом канале продаж. В итоге - отмена заказа, негативный отзыв и потеря лояльности.

Правильное ТЗ на разработку интеграции должно четко разделять, какие данные являются ведущими. В большинстве случаев «мастер-системой» выступает складская программа (например, 1С:Управление торговлей или специализированная WMS). Именно склад является первоисточником правды о том, сколько единиц товара физически лежит на полке. Сайт же выступает витриной, которая лишь транслирует эти данные. Однако при создании заказа сайт должен мгновенно отправлять информацию в склад, чтобы зарезервировать товар.

Существует два основных метода обмена: пакетный и событийный (Real-time). Пакетный метод, когда данные передаются раз в час или раз в сутки, в 2026 году практически не применим для e-commerce. Это слишком медленно. Современная автоматизация складского учета в интернет-магазине строится на API-запросах. Как только менеджер на складе провел приемку или отгрузку, сайт должен получить обновление в течение нескольких секунд. Это критично, если вы работаете с высокооборачиваемыми категориями товаров.

При составлении требований к ТЗ на разработку интеграции обязательно пропишите логику обработки ошибок. Что должен делать сайт, если сервер 1С временно недоступен? Он должен ставить запросы в очередь и повторять попытку позже, а не просто выдавать ошибку пользователю или, что еще хуже, «забывать» о заказе. В ТЗ должен быть раздел «Обработка исключений», где описаны сценарии: обрыв связи, неверный формат данных, дублирование артикулов и так далее.

Основные сущности для синхронизации

Для корректной работы системы необходимо настроить обмен не только по количеству, но и по набору атрибутов. В таблицу соответствия должны попасть: SKU (артикул), GTIN (международный идентификатор), наименование, цена, вес, габариты и, что крайне важно, статус маркировки. Если вы не свяжете артикул на сайте с GTIN в системе «Честный знак», вы не сможете корректно реализовать продажи маркированных групп.

Синхронизация остатков и цен в реальном времени

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

В ТЗ нужно детально прописать механику резервирования. Есть два пути: «жесткий» резерв и «мягкий». При жестком резерве товар списывается со складских остатков сразу в момент оформления заказа на сайте. Это самый безопасный вариант для малого и среднего бизнеса. При мягком резерве товар считается доступным, пока менеджер не подтвердит заказ вручную. Однако в 2026 году, когда конкуренция и скорость доставки диктуют свои правила, «мягкий» резерв часто становится причиной хаоса на складе.

С ценами ситуация еще сложнее. Цена на сайте может зависеть от множества факторов: региона пользователя, текущей маркетинговой акции, объема корзины или статуса клиента (опт/розница). Интеграция должна уметь передавать не одну цифру, а сложную структуру цен. Например, если в 1С настроена автоматическая переоценка из-за изменения курса валют или стоимости закупки, сайт должен подхватить эти изменения мгновенно, чтобы не продавать товар по себестоимости.

Пример из практики: интернет-магазин электроники настроил интеграцию так, что цена обновлялась раз в сутки. В результате из-за резкого скачка курса валют в течение дня компания продала 50 смартфонов по старой цене, что привело к прямому убытку в несколько сотен тысяч рублей. Решение - использовать триггерную модель: изменение цены в учетной системе инициирует немедленную отправку команды на обновление цен на сайте через API.

Таблица моделей синхронизации

Интеграция с Честным знаком и ЭДО

В 2026 году маркировка перестала быть «дополнительной опцией» и стала фундаментом бизнес-процессов. Интеграция сайта с 1С и «Честным знаком» - это обязательный контур. Теперь недостаточно просто выписать накладную. Продажа маркированного товара требует передачи данных в ГИС МТ (Государственную информационную систему мониторинга товаров) в режиме реального времени. Если вы продаете товар через сайт, система должна «понимать», какой именно код Data Matrix был продан конкретному покупателю.

Важнейшим звеном здесь выступает ЭДО (электронный документооборот). Приемка товара от поставщика должна проходить через УПД (универсальный передаточный документ), подписанный КЭП (квалифицированной электронной подписью). Если ваша интеграция не умеет подтягивать данные из ЭДО напрямую в складскую программу, а потом на сайт, вы получите огромную дыру в учете. Товар фактически есть на складе, но в системе он еще не «введен в оборот», а значит, его нельзя продавать легально.

Роспотребнадзор в 2026 году жестко контролирует цепочки поставок. Любое расхождение между данными в чеке (через онлайн-кассу) и данными в «Честном знаке» может привести к автоматическим штрафам. Поэтому ТЗ на интеграцию должно включать проверку связки: «Поставщик - ЭДО - Склад - Сайт - Касса». Все эти элементы должны работать в едином информационном поле. Если вы используете разные платформы, убедитесь, что они поддерживают передачу кодов маркировки в составе электронных документов.

Не забывайте про роль вашей компании. В ТЗ нужно четко зафиксировать, какие функции вы выполняете: вы только розничный продавец или еще и оптовик? От этого зависит объем передаваемых данных. Оптовая отгрузка требует передачи кодов через ЭДО, а розничная продажа - через передачу сведений при применении ККТ (контрольно-кассовой техники) с поддержкой ФФД 1.2. Ошибка в выборе сценария обмена может стоить лицензии на торговлю или крупных штрафов.

Контроль дат маркировки по товарным группам

Маркировка в РФ внедряется поэтапно. Это создает для бизнеса серьезную головную боль: сегодня вы продаете обычные кроссовки, а завтра к вам приходят новые партии обуви, которые уже требуют обязательной маркировки. В 2026 году правила постоянно расширяются, и в ТЗ на интеграцию сайта с складом нужно закладывать гибкость. Система не должна быть «зацементированной» под текущий перечень товаров.

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

Интеграция должна учитывать, что до наступления даты обязательной маркировки вы можете (и должны) реализовывать остатки старого образца. ТЗ должно описывать логику: как система переключается с режима «обычный товар» на режим «маркированный товар». Это не должно требовать переписывания кода всего сайта. Достаточно иметь в справочнике товаров признак «требует маркировки» и привязку к конкретной категории. Если этот признак включен, сайт должен требовать от склада обязательного сканирования Data Matrix при сборке заказа.

Также важно учитывать Национальную систему каталогов. Каждая позиция в вашем каталоге должна иметь привязку к GTIN и описанию в Национальном каталоге. Без этого синхронизация карточек сайта и склада при вводе новых маркированных групп превратится в ад. Менеджеру придется вручную прописывать характеристики для каждой позиции, что ведет к ошибкам. Автоматизация должна позволять подтягивать данные из ГИС МТ на основе GTIN сразу при приемке товара на склад.

Работа с Data Matrix и 2D-сканерами

Забудьте о линейных штрихкодах. В 2026 году для работы с маркированным товаром на складе и в рознице обязательны 2D-сканеры. Обычный сканер просто не сможет считать плотный, зашифрованный код Data Matrix, который содержит в себе не только идентификатор товара, но и номер серии, срок годности и другие данные. В ТЗ на разработку интеграции должно быть прописано требование к оборудованию и программному обеспечению: складской терминал (ТСД) должен бесшовно передавать считанный код в учетную систему, а та, в свою очередь - уведомлять сайт о перемещении конкретной единицы с этим кодом.

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

Интеграция должна поддерживать работу с несколькими типами кодов. Например, у вас есть товар с обычным штрихкодом (EAN-13) для позиций, не подлежащих маркировке, и Data Matrix для остальных. Программное обеспечение склада должно одинаково эффективно обрабатывать оба типа. В ТЗ стоит указать, что интерфейс ТСД должен быть оптимизирован под быструю работу с 2D-кодами, чтобы процесс сборки не замедлялся в разы по сравнению с обычными товарами.

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

Обработка возвратов и статусов заказов

Возврат маркированного товара - это не просто «забрать деньги и положить товар обратно на полку». Это сложная юридическая процедура в цифровом контуре. Когда клиент возвращает товар, вы обязаны изменить его статус в системе «Честный знак». Если вы просто вернете товар на склад без обновления данных в ГИС МТ, этот товар будет считаться «проданным» и «выбывшим из оборота», а по факту он будет лежать у вас на полке. Это прямой путь к автоматическому выявлению нарушений.

В ТЗ на интеграцию необходимо прописать четкий алгоритм возврата:

1. При получении возврата сотрудник сканирует Data Matrix товара.
2. Система проверяет, был ли этот код продан ранее через ваш интернет-магазин.
3. При подтверждении возврата статус товара в 1С меняется на «Возвратный», а в «Честном знаке» инициируется процедура возврата в оборот.
4. Информация о возврате передается на сайт, чтобы обновить статус заказа для клиента.

Статусы заказов также должны синхронизироваться бесшовно. Клиент на сайте должен видеть актуальную информацию: «Заказ собран», «Передан курьеру», «В пути», «Доставлен». Если склад задерживает сборку из-за проблем с маркировкой (например, не прошел код в системе), статус заказа должен автоматически меняться на «Задержка обработки», чтобы клиент не ждал в неведении. Прозрачность статусов снижает нагрузку на колл-центр и повышает доверие к бренду.

Важно предусмотреть и сценарии частичных возвратов. Если в заказе из пяти позиций клиент возвращает только одну, система должна корректно обработать возврат именно этого конкретного Data Matrix, не затрагивая остальные товары. Это требует глубокой интеграции на уровне каждой единицы товара (серийного учета), а не просто на уровне артикула. В 2026 году автоматизация складского учета в интернет-магазине без серийного учета маркированных товаров практически невозможна.

Масштабируемость системы под новые категории

Главная ошибка при проектировании интеграции - это создание системы «под текущие задачи». Сегодня вы торгуете одеждой, а через полгода решите добавить косметику или электронику. Правила маркировки, требования к передаче данных, необходимость интеграции с новыми подсистемами ЭДО - все это будет меняться. Если ваша архитектура жестко привязана к конкретным полям в базе данных, каждое расширение ассортимента превратится в дорогостоящий проект по переписыванию кода.

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

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

Также закладывайте масштабируемость по нагрузке. Если ваш оборот вырастет в 10 раз, справится ли ваш API с количеством запросов? Интеграция должна поддерживать очереди сообщений (message queues), чтобы в периоды пиковых нагрузок (черная пятница, праздники) данные не терялись, а просто обрабатывались с небольшой задержкой. Это обеспечит стабильность бизнеса при его росте, что является ключевым показателем успешной автоматизации.

Типичные ошибки при интеграции

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

• Игнорирование GTIN: попытка синхронизировать товары только по артикулам, что делает невозможной работу с «Честным знаком».
• Отсутствие обработки ошибок: когда один неверный код в заказе «вешает» всю очередь обмена данными.
• Ручной ввод маркировки: когда менеджеры вбивают коды руками, что приводит к колоссальному количеству ошибок и штрафов.
• Недостаточная частота обновления: использование пакетной выгрузки раз в день, что ведет к оверселлам.

Что запомнить

• ТЗ должно строиться на базе API и событийной модели обмена (Real-time).
• Маркировка - это сквозной процесс: от ЭДО и склада до кассы и «Честного знака».
• Обязательно наличие 2D-сканеров и поддержка Data Matrix в складском ПО.
• Система должна быть модульной, чтобы легко добавлять новые маркированные группы товаров.
• Все возвраты и изменения статусов должны автоматически отражаться в ГИС МТ.