Залишки товарів в OpenCart можуть відрізнятися від даних складу або маркетплейсу через резерви, затримку оновлення, помилкове зіставлення чи кілька джерел. Перш ніж масово перезаписувати кількість, потрібно зрозуміти, яке значення є правильним і хто його публікує.
У коді CRM PRO є розділ складу, джерела й механізми Stock Hub. Нижче — порядок звірки на одному контрольному товарі. Доступні операції залежать від установленої збірки та інтеграції; наявність розділу не означає автоматичну двосторонню синхронізацію всіх каналів.
Визначте, яку кількість порівнюєте
Фізична кількість на складі, доступна для продажу кількість і значення в каналі можуть мати різний зміст. Урахуйте погоджені резерви, обробку повернень і правило показу наявності.
- Фізичний залишок описує товари у визначеному джерелі.
- Доступний залишок враховує правила вашого процесу.
- Кількість у каналі є останнім опублікованим значенням.
Не віднімайте резерв двічі лише через те, що його враховують дві системи. Спочатку домовтеся про визначення, потім порівнюйте числа. Саме це часто пояснює розбіжність без помилки API.
Оберіть джерело основних даних
Визначте, де приймається рішення про кількість: у магазині, обліковій системі чи окремому складському джерелі. Далі запишіть напрям передавання для кожного каналу й процес, який його виконує.
Кілька джерел не повинні означати кілька суперечливих авторів
Якщо один процес бере дані з XML, а інший публікує старе значення через API, правильний результат може зникнути після наступного циклу. У CRM PRO перевірте налаштовані джерела складу та їхні ролі. Не змінюйте конфігурацію всіх джерел одночасно, поки не відтворено проблему на одному товарі.
Звірте ідентифікацію товару
Перевірте, як позиція OpenCart пов’язана із записом у джерелі й пропозицією майданчика. Артикул, внутрішній product_id та зовнішній ID не завжди є тим самим значенням. Варіант із певним кольором або розміром потребує власної правильної відповідності.
- Знайдіть контрольний товар у кожній потрібній системі.
- Звірте назву, артикул і варіант.
- Перевірте унікальність зв’язку.
- Зафіксуйте поточні значення й час їх отримання.
Якщо зіставлено інший товар, повторна синхронізація лише повторюватиме помилку.
Проведіть контрольний тест на погодженому прикладі
Для схеми звірки можна використати синтетичний SKU-DEMO-001: у джерелі кількість 7, у магазині й каналі потрібно перевірити відповідні значення з урахуванням ваших правил. Це приклад методики, а не реальні показники ShopX.
Для дозволеного тестового товару запишіть вихідний стан, виконайте одну погоджену зміну та простежте шлях до каналу. Не використовуйте популярну робочу позицію для довільних експериментів. Окремо перевірте нульовий залишок і відновлення наявності. Якщо для тесту потрібні записи, їх потрібно погодити та виконувати з актуальною резервною копією.
Порівнюйте не лише числа, а й час
Для кожного етапу визначте час зміни в джерелі, час отримання магазином, час відправлення й час підтвердження каналу. Остання успішна спроба та остання спроба з помилкою — різні події.
Затримка CRON, черга запитів або обмеження API можуть пояснити тимчасову різницю. Водночас часті повтори без контролю не гарантують актуальності. Перевірте конкретну відповідь та фактичне значення. Не очищайте журнал лише тому, що він містить помилки: збережений технічний контекст допомагає знайти етап збою.
Відокремте складський облік від публікації
Перевірте, чи джерело використовується для обліку, для отримання даних або лише для публікації. У коді CRM PRO передбачені різні сценарії Stock Hub; їхня наявність не означає, що всі вони повинні бути ввімкнені одночасно.
Експорт каталогу теж може впливати на кількість у каналі
Якщо використовується Pricer PRO, узгодьте роль фіда та API-оновлень із поточним обліком. Після правильного API-запиту наступний імпорт не повинен повертати старі дані. Порівняння задач двох модулів є в окремому матеріалі про CRM PRO і Pricer PRO.
Урахуйте продажі, скасування та повернення
Події замовлення можуть змінювати доступну кількість за правилами магазину. Перевірте, коли створюється резерв, коли він знімається та як підтверджується повернення товару. Не припускайте, що будь-яка назва статусу автоматично виконує складську операцію.
Наприклад, позначка повернення в CRM описує стан запису; її слід відрізняти від фактичного приймання товару й зміни обліку. Порядок роботи зі статусами пояснено в інструкції з повернень CRM PRO. Не виправляйте наслідок масовим перезаписом, поки не визначена подія, яка створює розбіжність.
Коли розбіжність можна вважати усуненою
- Один і той самий товар правильно ідентифікований у джерелах.
- Зміст фізичної та доступної кількості погоджено.
- Відомо, який процес публікує дані.
- Контрольна зміна й нульова наявність перевірені.
- Час оновлення та результат API або імпорту зрозумілі.
- Наступний цикл не повертає старе значення.
Збережіть контрольний приклад і технічні результати без персональних даних. Після цього розширюйте перевірку на потрібний обсяг. Можливості складу та обмеження інтеграцій звіряйте з описом CRM PRO і конкретною конфігурацією магазину.
