При интеграции интернет-магазина на платформе InSales с историческими конфигурациями 1С, такими как Управление торговлей 10.3, пользователи часто сталкиваются с критической проблемой: система выгружает лишь суммарный остаток товара по всем складам. В то время как современный бизнес требует отображения актуального наличия в конкретных точках (например, ПСК, МСК, СПБ), типовой механизм обмена схлопывает все данные в одну цифру. Рассмотрим подробно, почему это происходит и какими способами можно реализовать полноценную «мультискладность».
Прежде всего, разберем причину «замкнутого круга», о котором упоминается в обсуждении. Конфигурация УТ 10.3 построена на обычных формах и использует стандарт обмена CommerceML 2.05. В базовой реализации этого протокола, заложенной в типовую обработку ОбменССайтом, информация об остатках передается в упрощенном виде. Система обращается к регистру накопления ТоварыНаСкладах, суммирует количество по выбранным в фильтре складам и записывает результат в один узел XML-файла.
Для платформы InSales такой файл выглядит как команда обновить «Основной склад». Чтобы сайт «увидел» разные склады, данные должны передаваться либо в расширенном формате XML, где у каждого остатка есть идентификатор склада, либо через прямой запрос к API InSales. Поскольку штатный модуль 1С для УТ 10.3 не обновлялся под современные требования мультискладовости, разработчики модуля на стороне сайта часто перекладывают ответственность на программистов 1С, и наоборот.
Проанализируем самый надежный технический путь — модификацию кода 1С для формирования корректного файла offers.xml. Нам необходимо изменить логику выгрузки так, чтобы вместо одного общего тега количества формировалась структура с детализацией.
Разберем по шагам, что должен сделать программист в конфигураторе:
ОбменССайтом (или во внешнем модуле, если он используется) процедуру, отвечающую за формирование предложений (offers).СУММА(КоличествоОстаток), необходимо получать данные в разрезе измерения Склад.Склады, где опишем все склады организации с их уникальными идентификаторами (GUID).Остатки. Пример структуры должен выглядеть следующим образом:
<Остатки>
<Остаток>
<СкладИд>ID-склада-из-1С-1
<Количество>10
<Остаток>
<СкладИд>ID-склада-из-1С-2
<Количество>25
Важный нюанс: После такой доработки на стороне InSales в настройках интеграции нужно активировать опцию «Учитывать остатки по складам из XML». Также убедитесь, что в административной панели сайта созданы склады с соответствующими внешними идентификаторами, которые вы передаете из 1С.
Выясним преимущества работы через API. Файловый обмен (через HTTP-запрос файла XML) — это технология прошлого десятилетия. Современный подход подразумевает использование внешних обработок (файлы .epf), которые взаимодействуют напрямую с веб-сервисом сайта. В УТ 10.3 расширения не поддерживаются, поэтому мы используем именно внешнюю обработку.
Проанализируем алгоритм работы такой обработки:
PUT или POST запрос к API InSales на эндпоинт обновления остатков.Этот метод позволяет избежать проблем с «пустыми остатками» (как в сообщении №11), так как мы можем жестко прописать сопоставление (мэппинг) между Справочник.Склады в 1С и ID складов в InSales. Если ваш специалист «буксует», рекомендуем рассмотреть приобретение или разработку коннектора, работающего через API, так как это снимет ограничения формата CommerceML.
Рассмотрим ситуацию, когда бюджет на разработку ограничен. Можно применить метод «виртуальных потоков». Его суть заключается в создании нескольких настроек обмена в 1С (планов обмена).
Выполним следующие действия:
Проанализируем риски: Этот метод сложен в поддержке. Если складов станет 20, вам придется запускать 20 обменов. Кроме того, часто возникает проблема, когда товар числится на нескольких складах, и при поочередной загрузке файлы могут затирать данные друг друга, если логика сайта не настроена на инкрементальное обновление конкретных складов.
Разберем типичную ошибку из сообщения №11. Когда пользователь ставит отбор по родителю «Главный склад», сайт видит нулевые остатки. Это происходит из-за того, что в УТ 10.3 остатки хранятся на конкретных складах (элементах справочника), а не на группах. Если в настройках обмена указана группа, типовой запрос может не производить рекурсивный обход подчиненных складов.
Рекомендация: Всегда выбирайте в отборах только конечные элементы (склады-места хранения), а не группы складов. Проверьте также тип склада: он должен быть «Оптовый» или «Розница», но никак не «НТТ», если это не предусмотрено вашей логикой учета.
Для реализации качественной интеграции 1С:УТ 10.3 и InSales с разделением по складам, мы рекомендуем:
1. Использовать специализированные внешние модули от интеграторов, которые работают через API. Это самый стабильный вариант для старых конфигураций 1С.
2. Если выбран путь доработки штатного модуля, необходимо переписать функцию формирования XML, внедрив структуру <Остатки> с атрибутами СкладИд.
3. Обязательно проверить настройки «Мультискладовости» в панели управления InSales, так как без активной функции на стороне сайта любые данные из 1С будут суммироваться в один общий остаток.