Отчёт об обмене данными: что запросить у подрядчика при расхождении цен и заказов

Неверная цена требует разбора конкретной передачи

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

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

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

Соберите признаки до нового запуска

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

Время тоже требует пояснения. Запись о начале сеанса и время последнего изменения товара обозначают разные события, поэтому подрядчик указывает часовой пояс и объясняет, к какому моменту относится каждая отметка, иначе последовательность легко прочитать в обратном порядке.

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

Отправлено и обработано — разные этапы

Передача файла не означает применения его содержания. В алгоритме 1С-Битрикс режим mode=file отвечает за выгрузку файла на сайт, а ответ success на этом этапе означает доставку. Для заказчика это объяснение, почему сообщение об успешной передаче не закрывает вопрос о расхождении: исполнитель ещё показывает, что произошло после получения данных и какой товар они затронули.

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

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

Кому принадлежит значение и куда оно движется

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

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

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

Что сообщает ошибка и чего в ней пока нет

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

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

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

История может исчезнуть раньше разбора

Журнал нельзя считать бессрочным архивом. В общих настройках обмена для описанного модуля поле «Количество дней хранения истории» определяет, когда записи становятся устаревшими. Подрядчик называет действующее значение для магазина. Универсальный срок в статье был бы выдумкой, поскольку компания выбирает его с учётом своего порядка разбора и объёма сохраняемых данных.

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

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

Как принять исправление на том же объекте

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

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

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

Письмо, с которым можно открыть задачу

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

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

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

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