Обмен 1С с маркетплейсами и сайтом
Расхождение по строке видно в сверке сразу, до ручного разбора выгрузок дело не доходит
Проверяется: журнал операций и схема соответствия полей
РозницаРаботаем по NDA
Остатки в 1С, на сайте и в кабинетах площадок расходятся: одна и та же единица товара продаётся дважды, заказ приходит на позицию, которой нет. Цены правят руками в трёх местах, справочники не совпадают ни артикулом, ни единицами измерения. Обмен обычно уже есть — типовая обработка или самописный скрипт, — но падает он молча, и расхождение обнаруживает покупатель, а не сотрудник.
Что съедает срок и бюджет на самом деле
Почти никогда — не модель. Ниже места, из-за которых такие проекты встают, и что мы с каждым делаем.
Разные модели данных
У площадки свой идентификатор товара, свои единицы, свои схемы поставки (склад продавца или склад площадки) и свой набор статусов заказа. Отображение «поле в поле» не работает — нужна таблица соответствий и решение, какая система хозяин каждого поля.
Асинхронность и лимиты API площадок
Обновление цен и остатков принимается пачками и применяется с задержкой, часть запросов отбивается лимитом. Ответ «200 OK» не означает, что данные применились, поэтому нужны проверка постфактум и повтор с нарастающей паузой.
Резервирование
Между продажей на площадке и появлением заказа в 1С проходит время, и в этом окне тот же товар успевают купить в другом канале. Это вопрос правил, а не техники: какой канал приоритетный и какой буфер остатка держим по каждому.
Молчаливые отказы и дубли
Типовой обмен пишет ошибку в лог и идёт дальше, а площадка может прислать заказ повторно или с изменённым составом. Без учёта каждой выгрузки, статуса применения и ключа идемпотентности в базе появляются два документа на одну продажу.
Ограничение, которое определяет решение
Ключи API площадок дают право менять цены и снимать товар с продажи, поэтому они не лежат в коде обработки и не в общей папке: секрет-хранилище, разные ключи для теста и продуктива, ограничение по IP там, где площадка это позволяет. Отдельно фиксируется правило по персональным данным покупателей — в 1С переносится минимум, необходимый для отгрузки, а не полная выгрузка кабинета, и обмен идёт по защищённому каналу без промежуточных публичных сервисов и сторонних коннекторов, через которые проходит ваш трафик.
Как проверить, что работа сделана
Приёмка проходит на боевых данных в три захода. Первый: расхождение остатков и цен между 1С и каждой площадкой на контрольном списке из нескольких сотен позиций по сверочному отчёту, снятому не в момент выгрузки, а через сутки работы.
Второй: разбор искусственных сбоев — площадка отвечает ошибкой лимита, канал недоступен полчаса, заказ приходит повторно и с изменённым составом. Система должна догнать состояние сама, без ручного перезапуска и без дублей, и это должно быть видно по журналу.
Третий: развёртывание обмена с нуля по инструкции на тестовой базе силами вашего администратора — если не повторяется, работа не принята.
О чём спросить любого подрядчика
- Первый вопрос подрядчику — что происходит с расхождениями, а не как быстро идёт выгрузка.
- Наличие сверочного отчёта и оповещений отличает обмен от скрипта, который однажды перестанет работать незаметно.
- Спросите про повторную доставку заказа и ключ идемпотентности: если формулировка незнакома, дубли будут.
- Уточните, кто ведёт таблицу соответствий номенклатуры после сдачи — это не разовая работа.
- Проверьте, переживает ли обмен получасовую недоступность площадки без ручного вмешательства.
- И убедитесь, что ключи API не зашиты в код обработки и что ваш трафик не идёт через чужой промежуточный сервис.
Порядок работ по этапам
На каждом этапе назван результат, который остаётся у заказчика. На проверке — признак, по которому работу не приняли бы.
- Сверка системСопоставили карточку товара в 1С, на сайте и в кабинетах площадок: где живёт цена, где остаток, где статус заказа. Подняли те самые Excel-выгрузки, по которым разбирали спорные строки, и выделили расхождения, которые повторяются из раза в раз.
- Владение полямиЗафиксировали, какая система владеет каждым полем: цена и остаток идут из 1С, статус заказа приходит с площадки. Прямые вызовы между системами заменили очередью с повтором при отказе и ключом идемпотентности на заказ, от ночной полной выгрузки отказались в пользу событий с периодической сверкой.
- Сборка обменаСобрали адаптеры к 1С и к API площадок, затем очередь и обработчики, затем сверочную витрину и оповещение о неприменившейся выгрузке. На стенде гоняли обмен на копии номенклатуры, намеренно обрывая ответы площадки.
- Проверка повторовПовторяли одну и ту же выгрузку и один и тот же заказ, проверяя, что дубля не возникает, и сверяли остатки после схождения очереди. Провалом считали расхождение остатка между 1С и площадкой при пустой очереди и задвоенный заказ при повторной отправке.
- Передача администраторуПередали исходники обмена, схему соответствия полей, журнал операций и инструкцию администратору. Показали, как подключить новую площадку, как читать сверочную витрину и что делать по оповещению о неприменившейся выгрузке.
Как это устроено внутри
Обмен собран как набор адаптеров на Go за общей шиной: коннектор 1С ходит по OData, коннекторы сайта и площадок — по их HTTP-контрактам, между ними стоит NATS JetStream. Прямой вызов из 1С в площадку заменён публикацией события, потому что площадка отвечает не всегда и её недоступность иначе останавливала бы проведение документа — сообщение лежит в потоке и повторяется с возрастающей паузой. Владение полем зафиксировано таблицей в PostgreSQL: остатки и цены пишет только 1С, статус заказа — только площадка, встречная запись отбрасывается на входе адаптера. Заказ проводится по идемпотентному ключу «площадка плюс внешний номер», уникальный индекс не даёт повтору создать дубль; справочники кешируются в Redis, сверочная витрина считает расхождения и шлёт оповещение о неприменившейся выгрузке, метрики очередей уходят в Prometheus и Grafana.
- Go
- chi
- PostgreSQL
- Redis
- NATS JetStream
- Docker Compose
- 1С OData
- Prometheus
- Grafana
Похожая задача у вас?
Разберём её на созвоне за 40 минут: назовём объём работ, ограничения контура и по каким числам вы будете принимать результат. Если задача не наша — скажем прямо.