Электронный документооборот, продажи через маркетплейс, чеки по 54-ФЗ и реквизиты поставщиков обычно закрываются четырьмя разными сервисами, и данные между ними переносят руками. Смысл связки — убрать вторую базу, где те же данные живут параллельно.
Проблема
- Документы ЭДО в отдельной системе: статус подписания смотрели в интерфейсе оператора, входящие заводили вручную вместе с карточкой поставщика.
- Продажи через маркетплейс учитывали отдельно от обычных: заказы, статусы и остатки переносили руками.
- Чеки пробивали второй раз: продажа уже была в системе, а чек оформлялся в приложении кассы.
- Реквизиты заполняли руками: КПП, ОГРН, ОКВЭД, адрес по ЕГРЮЛ, данные банка по БИК.
Решение
Собрали интеграции в единый контур поверх Odoo: четыре блока, каждый убирал свой участок ручной работы.
1. ЭДО: СБИС прямо в карточке счёта
Модуль синхронизации счетов и УПД с электронным документооборотом СБИС. Вместо четырёх отдельных кнопок — одна: показывает статус документа цветом и текстом («Ожидает», «Подписан», «Отменён») и по клику обновляет его. Классификацию статусов развели: «Ожидает аннулирования» больше не попадает в «Отменён»; в УПД ставка НДС указывается простым процентом, а акт сверки уходит контрагенту прямо из мастера.
Входящие система забирает сама по расписанию: запрашивает реестр за период, скачивает документы и создаёт черновики счетов. Поставщик определяется по ИНН и заводится, если его ещё нет; строки сопоставляются с номенклатурой, дубликаты отсекаются по идентификатору вложения, а найденный заказ на закупку счёт привязывает к себе построчно.
2. Маркетплейс: продажи на Ozon в том же учёте
Продажи через Ozon идут в той же ERP, что и обычные, — по отдельной методике маркетплейса. Оплату получает Ozon и он же пробивает чек своей ККТ: собственной кассы селлеру не нужно. Датой реализации считается не дата заказа, а дата из отчёта о реализации товаров — он первичный документ для учёта. На эту дату начисляется выручка по полной цене продажи, а вознаграждение площадки и её расходы вместе с остатком к перечислению разведены между собой. Модель одна для всех трёх схем доставки. Заказы маркетплейса приходят в систему автоматически, с сопоставлением номенклатуры и остатками.
3. ККТ: очередь чеков на Эвотор
Задача — закрыть Точку продаж так, чтобы чек на смарт-кассе Эвотор печатался без ручного дублирования продажи, включая оплату картой. Ограничение сразу: у Эвотора нет публичного облачного API, который позволял бы серверу удалённо приказать конкретному терминалу напечатать чек или запустить эквайринг, — это доступно только приложению на самом терминале. Поэтому сделали ту половину, которую можно закрыть средствами ERP, и зафиксировали REST-контракт под приложение-компаньон.
Кассир пробивает продажу в POS как обычно, и как только заказ оплачен, система сама собирает состав чека с позициями, ставками НДС и разбивкой по наличным и карте — и ставит чек в очередь. Очередь забирается порциями, а после печати в учёт возвращаются номера ФН, ФД, ФП либо текст ошибки. Статус чека виден в карточке заказа POS, там же кнопка возврата зависшего чека в очередь.
4. Реквизиты: DaData без нового интерфейса
Автозаполнение реквизитов по ИНН, банка по БИК и подсказки по адресу подключены так, что нового поля ввода не появилось: модуль перехватывает штатный механизм автодополнения контрагента в Odoo, который по умолчанию обращается к зарубежному сервису, и для российского ИНН отправляет запрос в DaData. Пользователь видит то же поле, просто подсказки стали настоящими.
По ИНН подтягиваются КПП, ОГРН, ОКПО, ОКВЭД и организационно-правовая форма, статус организации и адрес по ЕГРЮЛ — он у юрлица часто не совпадает с адресом доставки. Адрес разбирается на улицу, город, регион и индекс. Кнопка «Заполнить по БИК» подтягивает реквизиты банка и его статус по данным ЦБ. Отдельное задание обновляет статус существующих контрагентов.
Результат
- Статусы документов ЭДО видны прямо в карточке счёта — без переключения между системами.
- Входящие приходят черновиками счетов, уже сопоставленными с поставщиком и заказом на закупку.
- Продажи через Ozon учитываются в той же ERP, что и обычные, — по документам маркетплейса.
- Кассовые чеки печатаются из очереди заказов, фискальные данные возвращаются в карточку продажи.
- Реквизиты заполняются по ИНН за секунды, ручной перенос убран на четырёх участках — но спорные строки входящих документов система не создаёт сама.
С чего начать
Если учётная система уже есть, а ЭДО, маркетплейс, касса и реквизиты живут отдельными сервисами, начинать стоит с разбора: где данные вводятся дважды и какие статусы приходится смотреть в чужом окне. Блоки подключают по одному, и первыми — ЭДО и входящие документы.
Состав интеграции зависит от площадок, кассового парка и требований бухгалтерии; точную оценку даём после аудита. Мы ведём российскую локализацию и интеграции ЭДО, маркетплейсов и ККТ на Odoo.
Свяжитесь с нами: +7 913 916-61-17, info@erpha.ru