Интеграция интернет-магазина на Laravel с 1С: цены, остатки и заказы без дублей

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

Для интернет-магазина на Laravel обмен нужно проектировать под конкретную конфигурацию 1С и правила компании. Разберём, что должно попасть в задание, как принимать цены и остатки, что делать с повторами и какие сведения показывать в админке. Примеры ниже учебные: они помогают согласовать требования и не описывают чужую боевую базу.

Начните с паспорта обмена

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

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

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

Разделите формат данных и способ их доставки

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

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

Не выбирайте библиотеку только потому, что в названии есть «Laravel 1C». Посмотрите, какие версии фреймворка она поддерживает, обрабатывает ли ваши характеристики и дополнительные реквизиты, как сообщает об ошибках. Старый пример для другой версии Laravel не является готовым решением для нового проекта.

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

Назначьте источник истины для каждого поля

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

Для каждой группы укажите направление передачи, идентификатор, возможность ручного изменения и действие при конфликте. Поле «Комментарий покупателя» должно дойти до согласованного места в 1С, а не просто присутствовать в выгрузке. На приёмке найдите его в созданном документе.

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

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

Название товара может меняться и повторяться. Артикул тоже не всегда уникален между поставщиками. Для обмена нужны согласованные устойчивые идентификаторы, включая идентификатор характеристики, если у одного товара есть варианты. Иначе красная футболка размера M и размера L могут получить один остаток.

В официальной документации Bagisto варианты показаны как отдельные позиции с собственными артикулами и остатками. Этот экран иллюстрирует задачу сопоставления; он не подтверждает наличие готового обмена Bagisto с вашей 1С. Для собственной модели Laravel требуется такое же явное соответствие торговой единицы данным учёта.

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

Согласуйте формулу доступного остатка

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

Учебный пример: физический остаток — 17 единиц, резерв в 1С — 3, новые резервы сайта, ещё не попавшие в 1С, — 2. При такой модели доступно 17 − 3 − 2 = 12. После приёма этих заказов резерв 1С становится 5, а соответствующие локальные резервы перестают вычитаться отдельно: 17 − 5 = 12. Если оставить обе части, сайт ошибочно покажет 10.

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

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

Передавайте цену вместе с условиями расчёта

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

Возьмём учебный заказ: три единицы по 1 390 ₽ дают 4 170 ₽. Скидка 10% на товары составляет 417 ₽, доставка — 390 ₽. Итог — 4 143 ₽. В учёте должны совпасть не только эти 4 143 ₽, но и позиции, количество, распределение скидки и отдельная услуга доставки. Случайное совпадение общей суммы не подтверждает правильность состава.

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

Повтор сообщения не должен создавать повтор операции

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

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

В документации Bagisto история файлового импорта показывает состояние, исходный файл, ошибки и итог обработки. Это пример полезной прозрачности, а не готовая интеграция с 1С: внутренний импорт по шаблону и обмен учётными данными решают разные задачи.

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

Покажите менеджеру задержку до того, как её заметит покупатель

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

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

Попросите показать остановку обработчика в тестовой среде. Сколько времени проходит до обнаружения? Кто получает сообщение? Что продолжает работать? Как запускается повтор и чем подтверждается восстановление? Ответы нужно проверить, а не оставить в виде пункта «настроен мониторинг».

Примите обмен по набору отклонений

1. Повторите тот же каталог: товары обновились, дубли не появились.
2. Измените один вариант: обновилась нужная характеристика, остальные остались прежними.
3. Передайте неполный или ошибочный пакет: поведение соответствует согласованному правилу.
4. Проверьте резерв до и после подтверждения 1С: количество не вычитается дважды.
5. Передайте заказ со скидкой и доставкой: совпали состав и сумма.
6. Повторите заказ после условного обрыва соединения: в 1С один документ.
7. Измените разрешённый статус и повторите старое сообщение: заказ не вернулся в неверное состояние.
8. Проверьте комментарий покупателя в интерфейсе 1С.
9. Остановите фоновые задачи: ошибка обнаружена, после восстановления очередь обработана.
10. Сопоставьте контрольный набор документов в обеих системах и сохраните результат проверки.

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

Как подготовить заявку на интеграцию

Пришлите в CAPS название и релиз конфигурации 1С, описание текущего магазина, состав обмена и два-три проблемных примера без персональных данных. Если интеграция уже работает, полезнее всего описать конкретное расхождение: где появилась неправильная сумма, потерянный комментарий или лишний документ.

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