Синхронизация двух Odoo для проекта SPL в Дубае

Задача: подготовить обмен данными для магазина SPL в Дубае

Для проекта Service Parts Logistics (SPL, теперь ЗАПЧАСТЬ.РФ) два Odoo-инстанса должны обмениваться операционными данными в режиме, близком к реальному времени: продажи, закупки, отгрузки, складские остатки и переписка по документам. При сбоях возникает риск расхождения данных между системами и остановки обработки заказов.

Червяков Владислав выполнял эту работу как сотрудник kt.team. Этот кейс относится к его профессиональному опыту; ниже описаны его зона ответственности и результат работы над интеграцией.

Как устроена синхронизация

• Архитектура обмена: Червяков Владислав проектировал структуру синхронизации и границы ответственности двух Odoo-инстансов.
• Данные: между системами передаются заказы, закупки, отгрузки, остатки, сообщения и вложения.
• Устойчивость: очереди и обработка ошибок позволяют выявлять сбои и восстанавливать обмен.

Результат оптимизации обмена

• Ежедневно синхронизировались примерно 100 заказов и закупок, 200 отгрузок и 500 сообщений с вложениями.
• После оптимизации число инцидентов на контуре обмена снизилось примерно с 15 до 3–4 в неделю.

Подробнее о похожих задачах: интеграции Odoo, сопровождение Odoo и интеграция магазина Tridoks с Odoo и Stripe (в работе).

Технологии и подход

Модули Odoo, Python, REST/RPC, очереди обмена и работа с ошибками. Архитектура разделяет потоки данных между двумя системами и помогает локализовать сбои синхронизации.

Техническое продолжение: архитектура интеграции Odoo и восстановление интеграции после сбоев. В статьях опыт SPL явно отделён от общих инженерных рекомендаций.