Перш ніж шукати винних, варто зробити одну річ: визначити, на якому боці зупинилися дані. Обмін — це ланцюжок з трьох ланок: база формує дані, щось їх передає, сайт їх приймає. Поки не зрозуміло, де саме розрив, будь-які правки будуть навмання.
Найпростіший спосіб: візьміть один конкретний товар, у якого точно змінився залишок. Подивіться його кількість у базі, потім у логу обміну, потім у базі даних сайту або в адмінці. Ланка, після якої число перестає бути правильним, і є місцем поломки.
1. Завдання за розкладом просто зупинилося
Найчастіша причина з великим відривом і, на щастя, найпростіша. Обмін зазвичай запускає регламентне завдання на стороні 1С або планувальник на сервері. Воно зупиняється після перезавантаження сервера, оновлення конфігурації, зміни пароля облікового запису, під яким працює, або банально тому, що хтось вимкнув його й забув увімкнути.
Як перевірити: у налаштуваннях регламентних завдань подивіться дату й час останнього успішного виконання. Якщо там позавчора — далі можна не шукати. Заодно перевірте, чи не встановлений прапорець «Виконання вимкнено» і чи не заблокований користувач, від імені якого воно запускається.
2. Обмін іде, але передає не ті склади
У налаштуваннях обміну майже завжди є перелік складів, залишки з яких потрапляють на сайт. Якщо додали новий склад і не внесли його в налаштування — товари з нього для сайту не існують. Те саме буває, коли товар фізично переміщений на склад, який в обмін не входить.
Як перевірити: подивіться, на якому складі лежить проблемний товар, і звірте з переліком складів у налаштуваннях обміну.
3. Залишок є, але він увесь у резерві
Багато схем обміну передають не фізичний залишок, а доступний до продажу — тобто за вирахуванням того, що вже зарезервовано під оформлені замовлення. Логіка правильна, але вона дає несподіваний результат: на складі десять штук, а на сайті нуль, бо всі десять зарезервовані під замовлення, які місяць висять необробленими.
Як перевірити: подивіться звіт по резервах для цього товару. Якщо резерв дорівнює залишку — причина знайдена. Лікується не правкою обміну, а наведенням порядку в замовленнях: скасуванням прострочених і встановленням терміну життя резерву.
4. Товар на сайті не пов'язаний з товаром у базі
Обмін знаходить відповідність між позиціями за артикулом, кодом або унікальним ідентифікатором. Якщо зв'язок розірвався, обмін просто не знає, куди записати кількість. Найчастіше це стається, коли товар на сайті створили руками в адмінці, а не отримали з бази, або коли комусь у базі змінили артикул.
Як перевірити: порівняйте артикул товару в базі й на сайті посимвольно. Особливу увагу зверніть на пробіли на початку й у кінці, на кирилічну «С» замість латинської «C» і на провідні нулі, які Excel любить з'їдати при вивантаженні прайсу.
5. Дублі товарів у базі
Один і той самий товар заведений двічі: у першої картки залишок нульовий, у другої — реальний. Обмін бере ту, яку знаходить першою, і передає нуль. Симптом характерний: на сайті то з'являються, то зникають залишки без видимої логіки.
Як перевірити: пошук по частині назви або по артикулу в довіднику номенклатури. Якщо знайшлися двійники — потрібне об'єднання карток, а не правка обміну.
6. Кеш на боці сайту
Дані дійшли, у базі даних сайту правильна кількість, а сторінка показує стару. Значить, сторінка віддається з кешу — його може тримати сам движок, плагін кешування, CDN або навіть браузер відвідувача.
Як перевірити: відкрийте сторінку товару в режимі анонімного перегляду. Якщо там правильна кількість — справа в кеші браузера. Якщо стара — очистіть кеш сайту й перевірте ще раз. Правильне рішення: налаштувати скидання кешу картки товару після оновлення залишків, а не вимикати кешування зовсім.
7. Обмін падає з помилкою, якої ніхто не бачить
Найнеприємніший варіант: завдання запускається за розкладом, відпрацьовує три секунди, отримує помилку й тихо завершується. Ззовні виглядає так, ніби все працює. Причини бувають різні: сайт змінив ключ доступу до API, скінчилося місце на диску, база була заблокована в момент обміну, оновився SSL-сертифікат.
Як перевірити: журнал реєстрації в базі за період обміну, лог самого обміну, якщо він ведеться, і лог помилок веб-сервера. Шукайте записи зі статусом помилки в момент, коли завдання мало відпрацювати.
Що зробити, щоб це не повторювалося
Усі перелічені причини об'єднує одне: про поломку дізнаються не з системи, а від клієнта, який купив те, чого немає. Це виправляється трьома речами.
- Логування кожного обміну. Коли запустився, скільки позицій передав, що не пройшло і чому. Без цього діагностика перетворюється на здогадки.
- Сповіщення про тишу. Якщо успішного обміну не було довше за встановлений час — повідомлення в Telegram. Це найдешевша страховка, яку можна придумати.
- Регулярна звірка. Раз на тиждень автоматичний звіт про розбіжності між залишками в базі й на сайті. Дозволяє ловити проблеми зіставлення, які ніяк інакше не проявляються.
Якщо пройшли весь список і причину не знайшли — напишіть мені, подивлюся логи. Діагностика простих випадків нічого не коштує. А якщо обміну ще немає й ви тільки плануєте його робити, подивіться, як це влаштовано, на сторінці про інтеграцію 1С із сайтом.