Цена партнёрского магазина не обновляется после автоматизации: где проверить цепочку пересчёта

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

Сначала определите, какая цена устарела

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

Пусть в учебном примере базовая сумма изменилась с 1000 до 1200 условных единиц. По принятому правилу партнёру положено 90% базы. Сохранённое значение 900 тогда требует проверки: ожидаемый учебный результат составляет 1080. Здесь арифметика иллюстрирует договорённое правило, а не действующие условия какого-либо магазина. Если скидка на самом деле зависит от группы товара, срока акции или валюты, сначала уточняют формулу, а уже потом объявляют сумму ошибочной.

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

Постройте короткую карту зависимостей

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

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

Проверьте отдельно ручное и автоматическое обновление

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

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

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

Выберите место пересчёта, которое можно контролировать

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

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

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

Защитите расчёт от повторов и смены правил

Повтор одного задания не должен повторно применять скидку к уже уменьшенной цене. В учебном примере пересчитывать нужно 90% от базовых 1200, а не 90% от сохранённых 1080. У производного поля должен быть однозначный исходник. Иначе повтор после сетевой ошибки незаметно уменьшит цену ещё раз.

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

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

Не публикуйте новый фид посередине перерасчёта

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

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

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

Матрица приёмки для партнёрской цены

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

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

Что передать администратору после исправления

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

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

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

Как разобрать гонку двух пересчётов

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

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

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

Как обращаться с кэшем партнёрской выгрузки

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

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

Связанные разборы

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

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

Нужно ли хранить партнёрскую цену отдельным полем?

Это зависит от экспорта и нагрузки. Отдельное поле требует явного пересчёта при изменении исходных данных; расчёт при чтении требует общей формулы для всех получателей.

Почему ручное сохранение помогает, а импорт нет?

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

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

• Цены каталога 1С-Битрикс: Модель каталога предусматривает отдельные операции над ценами; статья не утверждает конкретный обработчик исходного проекта.
• Обмен 1С-Битрикс с 1С: Разделение импорта и экспорта CommerceML; правила частичного обновления нужно проверять в конкретном проекте.