Магазин бреше, якщо залишки на сайті — чутки. Контур — обмін з 1С, BAS або складом: номенклатура, ціни, кількість, замовлення назад в облік. В українському intro це не перший абзац: багато ФОП живуть без 1С. Коли облік уже є — обмін стає головним ризиком запуску.
Спочатку контракт: хто господар артикула й ціни, що робити з оплаченим замовленням, якщо склад відмовив. Потім обмін і звірка. Разовий CSV — не обмін.
Вітрина: Woo, OpenCart, Horoshop API, кастом. Ядро обліку — інтеграція з 1С. Бітрикс тут вторинний.
Вузький двосторонній обмін часто 4–8 тижнів після доступів. Чистка довідника — окрема робота.
Типовий мінімум: номенклатура вниз на сайт, замовлення вгору в 1С/BAS, статуси назад. Гуртові ціни й резерв — наступний етап. Логи такі, щоб менеджер бачив: замовлення пішло, прийнято, помилка поля. Доступи до копії бази, не до бойової каси — умова старту. Якщо обліку немає, не вигадуємо 1С «про всяк випадок»: це окремий проєкт і окремий бюджет.
Приймання обміну: десять позицій, дві ціни, одне замовлення з сайту стає документом з тим самим складом. Різні назви характеристик — мапінг, не ручна праця менеджера. Повні нічні вивантаження й денні дельти розділяємо. Алерт «обмін не ходив N годин» обов’язковий. Якщо 1С немає — не вигадуємо її в кошторисі магазину. BAS і «просто Excel складу» теж різні контури: Excel — імпорт, не двосторонній обмін. Розклад обміну пишемо в runbook, щоб нічна вивантаження не збігалася з інвентаризацією. Якщо BAS і сайт роз’їхалися по артикулах, спочатку довідник, потім коннектор. Тестовий стенд обліку обов’язковий: на бойову базу не котимо перший обмін.
