Включение подборок в разные выгрузки: флажки, пустые значения и повторный экспорт

Подборка и направление выгрузки

Учебный каталог имеет несколько подборок и две внешние витрины. Одна подборка нужна обеим, другая только первой, третья временно не участвует. Если хранить один общий признак «экспортировать», таких различий не выразить. Независимые флажки помогают редактору управлять составом, но их значение должно быть связано с конкретным направлением и понятным результатом.

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

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

Независимые настройки

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

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

Как формируется список категорий

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

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

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

Пустой список и снятие последнего флажка

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

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

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

Повторный экспорт

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

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

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

Изменение самой подборки

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

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

В учебном наборе одну включённую подборку переименовывают, затем удаляют допустимым способом. Сравнивают сформированный набор и результат получателя. Если доступ к последнему отсутствует, подтверждают только внутренний пакет и отмечают ограничение. Такой отчёт честнее общего «выгрузка исправлена», которое скрывает неизвестный конечный эффект.

Товар в нескольких подборках

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

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

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

Административный интерфейс

Редактор видит флажки рядом с понятным описанием: в какую выгрузку попадёт подборка и когда изменение вступит в силу. Если обработка отложена, статус не должен выглядеть как уже подтверждённый внешний результат. Можно показать сохранённую настройку и состояние последней передачи отдельно. Это уменьшает путаницу между «я нажал сохранить» и «получатель обновлён».

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

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

Наблюдение и отчёт

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

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

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

Снятие последнего флажка

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

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

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

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

Смежная тема разобрана в материале Интеграция интернет-магазина с 1С: правила обмена.

Вопросы по теме

Как управлять составом выгрузки по витринам без отдельных копий каталога?

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

Документация и источники

• 1С-Битрикс: обмен с 1С: Наличие компонентов обмена CommerceML; конкретные правила проекта проверяются отдельно.