Импорт прайса завершился без явной ошибки, но связь с CRM оборвалась до получения подтверждения. Повторить запрос кажется естественным. Однако если первый запрос уже создал товары, второй может создать их ещё раз. Проверить только количество строк в исходном файле здесь недостаточно.
Чтобы повторная загрузка была управляемой, сначала нужно договориться о двух разных ключах: какой товар вы обновляете и какую операцию выполняете. Первый помогает сопоставлять карточки, второй позволяет отличить повтор доставки от новой команды.
Ключ товара должен переживать изменение цены
Название, цена и положение строки в Excel неудобны для поиска существующей карточки. Название редактируют, цена меняется по смыслу задачи, строки сортируют. Если включить такие значения в ключ товара, обычное обновление может превратиться в создание новой позиции.
В учебном каталоге поставщик использует артикул 00127. Во втором каталоге такой же артикул относится к другой детали. Для внутренних предложений магазина можно рассмотреть ключ из кода поставщика и его артикула. Но если одному артикулу соответствуют несколько упаковок, размеров или складов, состав ключа придётся уточнить.
Не существует единственного набора полей, подходящего любой CRM. Его выбирают по правилам источника и вашей модели учёта. Даже внешне аккуратный код нужно проверить на реальных исключениях: повторное использование артикула, смена поставщика, вариант товара и удалённая карточка.
| Изменение | Должна ли появиться новая карточка |
|---|---|
| Поставщик изменил цену | Обычно обновляется прежнее предложение, если ключ не изменился |
| У товара другой размер | Зависит от того, учитываются ли варианты отдельными позициями |
| Появился второй поставщик того же изделия | Нужно сохранить связь с изделием и отдельные условия предложения |
| В строке потерялся артикул | Не создавать карточку автоматически без согласованного правила |
Таблица показывает вопросы для проектирования, а не универсальную инструкцию учёта.
Повтор операции отличается от новой поставки данных
Представим, что готовый пакет содержит сто обновлений. Вы отправили его, не получили ответ и отправили снова. Это повтор одной операции. На следующий день пришёл новый прайс с теми же товарами, но другими ценами. Это уже новая операция, даже если состав карточек совпадает.
В HTTP есть понятие идемпотентности: несколько одинаковых запросов имеют тот же предполагаемый эффект, что один. Метод и правила его применения важны; нельзя автоматически приписывать это свойство любому запросу создания записи. Определение приведено в RFC 9110.
Для конкретной CRM выясните, поддерживает ли нужный метод идентификатор операции, обновление по внешнему ключу или другой механизм защиты от повторов. Если поддерживает, применяйте его по документации. Наличие поля с названием id само по себе ещё не делает повтор безопасным.
Внутренний журнал может связывать эти сведения так. Это учебная запись интеграции, а не тело запроса к универсальному методу CRM:
{
"external_key": "supplier-a:00127",
"operation_id": "prices-20261028-01",
"batch": 2,
"status": "awaiting_confirmation"
}
Здесь первый ключ обозначает предложение поставщика, второй обозначает пакет обновления, а статус напоминает, что результат получателя ещё предстоит проверить.
Сначала подготовить изменения, затем записывать
Практичный промежуточный результат импорта состоит не из одной колонки «готово», а из списка предполагаемых действий. Для каждого внешнего ключа видно: обновить существующую карточку, создать новую или передать строку на разбор. Причина решения тоже должна быть доступна.
На этом шаге удобно обнаружить две строки с одинаковым ключом и разными ценами. Выбор последней строки без объяснения может скрыть проблему источника. Лучше явно определить, какой признак задаёт актуальность предложения, либо остановить неоднозначную группу до проверки.
Отдельно посмотрите на пустые значения. Пустая цена может означать отсутствие предложения, ошибку чтения или действительно команду очистки. Если не различать эти варианты, импорт случайно удалит полезные сведения. Правило «пустое не перезаписывает заполненное» тоже нельзя применять ко всем полям без разбора: иногда удаление значения является необходимым изменением.
Что делать после неопределённого ответа CRM
Если ответ потерялся, не считайте операцию ни завершённой, ни заведомо не выполненной. Используйте предусмотренный CRM способ проверки: запрос состояния операции, чтение записи по ключу или журнал результатов пакета. Только после этого выбирайте повтор или ручной разбор.
Для крупных пакетов сохраняйте сведения о результате каждой части. Иначе повтор всего файла затронет уже подтверждённые изменения. При этом локальная отметка «отправлено» означает только отправку, а не приём данных получателем.
До рабочей загрузки подготовьте несколько контрольных случаев: повтор того же пакета, новый пакет с изменённой ценой, два одинаковых ключа, отсутствующий ключ и обрыв ответа. Проверьте не только отсутствие дублей, но и то, что нужная цена действительно обновилась.
В Akmelo можно подготовить и проверить записи перед передачей получателю. Правила создания и обновления карточек на стороне CRM определяются её API и вашим сценарием интеграции. Подготовленная выгрузка сама по себе не подтверждает, что CRM приняла изменения.
Хороший итог такой проверки предельно конкретен: вы знаете, какой товар затрагивается, почему выбрано именно это действие и как выяснить результат после сбоя связи. Тогда повторный импорт становится штатной операцией, а не попыткой угадать состояние базы.
