Импорт прайс-листа поставщика в CMS: как проверить изменения до публикации

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

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

Импорт прайс-листа в CMS начинается со смысла полей

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

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

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

Товар сопоставляют по идентификатору, а не похожему названию

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

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

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

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

Пустая цена, ноль и отсутствующая строка — разные состояния

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

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

Упомянутая документация Odoo различает отсутствие поля и импорт пустого значения. Это веская причина проверить такое различие и в своей системе. В задании на разработку не стоит ограничиваться фразой «пустые поля игнорировать», не объяснив, как впоследствии намеренно удалять неверную информацию.

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

Карта полей демонстрационного файла

Ниже приведён иллюстративный пример карты полей. Фактические названия нужно согласовать с поставщиком и моделью CMS. Демонстрационная цена 12,50 EUR не является рыночными данными или предложением.

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

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

Предпросмотр изменений должен быть понятным

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

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

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

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

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

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

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

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

Что блокировать, а что отправлять на проверку

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

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

Загрузка файла — ещё и граница безопасности. OWASP описывает риск CSV injection: табличная программа воспринимает недоверенное значение как формулу. Не предусматривайте выполнение формул поставщика как стандартный способ получения цен. При экспорте отчёта об ошибках тоже нужно проверить, как недоверенное содержимое будет открываться и отображаться.

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

Приёмочные тесты с ошибочными строками

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

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

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

Откат не должен перезаписывать более поздние исправления

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

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

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

Что подготовить перед разработкой CMS

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

Модель контента CMS помогает определить поля и связи, а выбор авторитетного источника данных — договориться, кто может их менять. Требования к импорту должны превратить эти решения в проверяемую приёмку пакета.

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