підготовлено редакцією НАДАЛІ з використанням ШІ
Покупець обирає зелену сумку великого розміру, бачить фото маленької, а склад отримує артикул чорної. Кожне поле окремо може виглядати правдоподібно. Помилка живе між ними: колір, ціна, фотографія та залишок прив’язані до різних варіантів.
Для невеликого магазину корисне завдання ШІ тут конкретне: пояснити суперечності у зв’язках каталогу й підготувати список перевірок. Нижче наведено редакційний процес для звичайних фізичних товарів, які продають у кількох варіантах. Це не випробування програми й не інструкція для регульованих товарів, уживаних речей чи складних наборів. Почніть з однієї товарної родини, для якої можете перевірити кожну позицію.
1. Опишіть, що саме купує людина
Розділіть три рівні. Батьківська картка об’єднує товарну родину: наприклад, сумку однієї моделі. Варіант визначає конкретну комбінацію, яку замовляють: чорна, велика. Залишок описує доступну кількість цього варіанта в конкретному місці й на конкретний час.
Це робоча модель перевірки, а не вимога до будови кожної платформи. З’ясуйте, як ці рівні називаються у вашій системі. Якщо батьківська картка лише групує варіанти, не додавайте її до кількості одиниць для продажу. Два складські рядки одного варіанта на різних складах також не означають два різні товари.
Запишіть одиницю продажу: одна сумка, упаковка з двох або інша комплектація. Подарунковий напис чи сервісна опція можуть мати іншу логіку, ніж фізичний розмір. Не перетворюйте кожну кнопку на сайті на новий складський товар без погодженого правила.
2. Розведіть внутрішній артикул і GTIN
У цьому процесі SKU означає внутрішній артикул, за яким команда веде варіант. Збережіть чинний SKU та системний ID. Якщо артикул погано читається, додайте зрозумілу назву поруч, а не перейменовуйте його під час аудиту: ним можуть користуватися замовлення й інтеграції.
GTIN є ідентифікатором торгової одиниці в системі GS1; штрихкод є способом машинного зчитування закодованої інформації. Внутрішній SKU та зображення штрихкоду не замінюють перевіреного GTIN. GS1 пояснює різницю між номером і штрихкодом.
Для окремих комбінацій розміру й кольору GS1 передбачає окремі GTIN. Це стосується ідентифікації відповідних товарів, а не автоматичного присвоєння номера кожному рядку експорту. Роз’яснення GS1 про варіанти.
Не формулюйте правило «будь-яке редагування картки потребує нового GTIN». Стандарт керування GTIN розрізняє нові товари та зміни наявних. Спірний випадок має оцінити відповідальний за ідентифікацію за застосовними правилами, а не мовна модель за назвою. Для товару постачальника попросіть підтвердження належного номера; не запозичуйте його із сусіднього варіанта.
Контрольна цифра допомагає перевірити структуру номера, але не доводить правильність його присвоєння. Цю межу прямо зазначає GS1 Denmark. Порожнє поле залишайте невирішеним питанням. Не генеруйте правдоподібних цифр.
3. Складіть матрицю дозволених комбінацій
Попросіть менеджера асортименту підтвердити, які варіанти реально існують. Два кольори та два розміри утворюють чотири математичні комбінації, але постачальник може випускати лише три. ШІ не повинен створювати четверту тільки заради симетрії.
Для кожної комбінації запишіть один стан: продається, тимчасово немає залишку, знято з продажу або ніколи не входила до асортименту. Останні два стани не рівнозначні нульовому залишку. Підставою має бути специфікація, погоджений перелік або відповідь відповідального, а не відсутність рядка.
Окремо погодьте словник: чи «чорний» і «black» позначають той самий колір, чи «великий» відповідає L саме для цієї моделі. Збережіть оригінальні значення. Автоматична заміна всіх M на «середній» небезпечна, якщо в іншій групі M має інше значення.
4. Перевіряйте зв’язки, перш ніж просити пояснення
Збережіть робочу копію з датою, фільтром і переліком джерел. Мінімальні поля: ID батьківської картки, ID варіанта, SKU, опції, одиниця продажу, GTIN або статус перевірки, ID фото, ціна з валютою й умовами, склад, доступна кількість та час її оновлення. Передавайте лише дозволені дані в погоджене середовище; клієнтські замовлення для цього аудиту зазвичай не потрібні.
Звичайними фільтрами або перевірками системи знайдіть:
- варіанти без наявної батьківської картки;
- один SKU у різних комбінацій у межах погодженої системи обліку;
- дві активні картки однієї дозволеної комбінації;
- фото, ціну або залишок, прив’язані до відсутнього ID;
- ціни без валюти, а залишки без складу чи часу.
Повтор GTIN у кількох складських рядках одного товару не є автоматично помилкою. Натомість однаковий номер у різних підтверджених варіантів потребує розслідування. Порівнюйте сутності, а не лише повтори тексту.
Різна ціна для різних розмірів теж може бути правильною. Перевіряйте її проти погодженого прайсу з тією самою валютою, податковими умовами й періодом дії. Не «вирівнюйте» ціни до середньої. Для залишків відрізняйте фізичну кількість від доступної після резервів; не складайте показники з різними значеннями.
5. Навчальний приклад: три варіанти сумки
Усі записи нижче вигадані. Родина P-20 має три дозволені варіанти: чорний малий, чорний великий, зелений малий. Зеленого великого постачальник не випускає.
- V-201, SKU BAG-01: чорний малий, фото IMG-BS, 600 грн, доступно 5 одиниць.
- V-202, SKU BAG-02: чорний великий, фото IMG-GS, 700 грн, доступна кількість невідома.
- V-203, SKU BAG-03: зелений малий, фото IMG-GS, 600 грн, доступно 0 одиниць.
Погоджений реєстр фото визначає IMG-BS як чорну малу сумку, IMG-GS як зелену малу. Усі ціни мають однакові податкові умови, а відомі залишки стосуються одного складу й моменту.
Очікуваний результат: три наявні варіанти; конфлікт фото для V-202; невідомий залишок V-202; відомий нуль для V-203. Відсутність зеленого великого не є дефектом. Сума відомих доступних залишків дорівнює 5, але це не підтверджений повний залишок родини. Заміна невідомого нулем приховає прогалину.
Правильне виправлення фото потребує знайти підтверджений знімок чорної великої сумки. Не слід автоматично ставити IMG-BS: збіг кольору не підтверджує розмір. Номери GTIN у цьому прикладі навмисно не вигадані.
6. Дайте ШІ обмежене завдання
Використайте такий запит із погодженою копією:
Перевір зв’язки між батьківськими картками, варіантами, реєстром фото, прайсом і залишками. Матриця дозволених комбінацій є окремим джерелом. Для кожної суперечності поверни ID варіанта, правило, точні значення з джерел, можливий наслідок і питання до відповідального. Розрізняй підтверджений конфлікт та брак доказів. Не змінюй дані, не об’єднуй картки, не створюй SKU або GTIN, не заповнюй пропуски. Перевірку зображення не називай виконаною, якщо маєш лише його назву чи URL.
Нехай відповідальний перевірить кожен висновок за джерелом. ШІ може пояснити неузгоджені назви, але впевненість відповіді не підтверджує колір, комплектацію чи правильність номера. Для малої групи ручна перевірка може бути простішою.
7. Прийміть результат за конкретними умовами
Аудит завершений, коли кожен активний варіант має пояснене місце в матриці, незмінні ID, перевірені зв’язки та власника невирішених питань. Для кожного погодженого виправлення запишіть старе й нове значення, підставу та перевіряльника. Сам звіт не є дозволом змінювати магазин.
Після окремо погоджених змін перевірте вибір варіанта на вітрині й у тестовому кошику без оплати: фото, опції, ціна та SKU мають відповідати одному товару. Звірте також складську прив’язку. Не створюйте справжніх замовлень без дозволу. Невирішену помилку, яка може спричинити неправильне відвантаження, передайте відповідальному до наступного продажу.
Зберігайте кількість підтверджених конфліктів, хибних сигналів і відкритих питань. Менше рядків або красивіші назви не є критерієм успіху. Корисний результат: команда може пояснити, який саме товар отримає покупець після кожного дозволеного вибору.
Джерела перевірено 7 листопада 2026 року. Процес і приклад є редакційними пропозиціями; продуктові тести та вимірювання економії часу не проводилися.
Обкладинка: оригінальна концептуальна редакційна ілюстрація, згенерована для Надалі за допомогою OpenAI. Це не документальне фото, не інтерфейс продукту й не доказ тестування.
