У меня проверка обмена начинается с конкретного заказа: я прослеживаю его от кабинета Ozon до документов в учётной системе. Сам факт загрузки ничего не доказывает. Заказ может попасть в базу, а возврат остаться за её пределами, удержание загрузиться повторно или товар списаться не с того склада. Внешне всё работает, документы появляются, уведомлений об ошибках нет. Поэтому интеграцию Ozon с 1С я проверяю по результату: могу ли объяснить движение товара и каждую сумму, а не просто увидеть успешное соединение.
В моих магазинах мне нужно разделять оперативную работу и финансовую сверку, иначе одни и те же данные начинают отвечать на несовместимые вопросы. Остаток нужен, чтобы не продать отсутствующий товар, заказ — чтобы организовать обработку, а финансовые документы — чтобы понять расчёты с площадкой. Эти события связаны между собой, но не обязаны отражаться одновременно. Я сам сделал сервис аналитики SellOps, потому что не нашёл готового решения, которому доверял бы, и теперь особенно внимательно смотрю на происхождение цифр. При подключении учётной системы придерживаюсь того же правила: сначала выясняю, что означает запись, и только потом решаю, куда её загружать.
Что связывать между кабинетом Ozon и учётной системой
Я начинаю с номенклатуры, потому что ошибка здесь распространяется на весь дальнейший учёт. Нужно определить, какая карточка учётной системы соответствует конкретному товару продавца на Ozon, и сохранить эту связь через устойчивые идентификаторы. Название для сопоставления ненадёжно: его можно изменить, а похожие товары легко перепутать. Отдельно проверяю характеристики, комплектацию и единицы измерения, если они используются в базе. Когда в кабинете продаётся комплект, а на складе учитываются его составляющие, обмен должен понимать правило списания, иначе количество документов будет правильным, а остаток — нет.
Следом я разделяю заказ, отгрузку и реализацию, даже если выбранное решение умеет создавать их автоматически. Заказ показывает намерение покупателя и помогает организовать исполнение, но сам по себе не подтверждает сумму окончательной продажи. Отмена до отгрузки и возврат после продажи тоже требуют разных действий в учёте. Я выясняю, какой статус запускает создание документа, какой меняет его состояние и откуда приходит основание для отражения реализации. Названия документов зависят от конфигурации и настройки учёта, поэтому универсальную схему проведения без просмотра базы я бы не обещал.
Для остатков сначала определяю источник достоверных данных и направление передачи. Если отгружаю со своего склада, доступное к продаже количество должно учитывать резервы, а не просто повторять физическое наличие. Если товар находится на складе площадки, сведения о его движении и доступности нужно сверять отдельно от остатков собственного склада. При нескольких магазинах я также проверяю, не обещан ли один и тот же свободный запас одновременно в разных кабинетах. Автоматическое обновление помогает лишь тогда, когда уже установлены правила резервирования, отмены резервов и обработки возвратов.