Немецкий запрос на интеграцию Odoo почти всегда называет три стороны: налогового консультанта с DATEV, интернет-магазин на Shopware или JTL и, с прошлого года, электронный счёт. Техническая часть подключения редко бывает проблемой. Проблема в том, что каждая из трёх сторон ждёт данные в форме, которую Odoo сам по себе не выдаёт, и что в начале проекта об этом никто не говорит.
Поэтому по порядку: что на самом деле есть в стандартном образе, чего в нём нет и какие швы мне приходилось шить вручную.
Что Odoo даёт для Германии - посчитано, а не предположено
В рабочем образе Odoo 19 Community 659 модулей. Немецкий среди них ровно один: l10n_de, план счетов. Модулей с DATEV в названии нет вообще. Европейский модуль one-stop-shop l10n_eu_oss на месте, как и список форматов электронных счетов, в котором уже есть XRechnung.
Одна эта цифра определяет форму любого немецкого проекта. Бухгалтерский экспорт - это либо ваша собственная работа, либо чужой продукт. Неизменяемость проводок - настройка, которую сначала нужно найти. Электронный счёт ближе, чем думает большинство. А всё, что нужно магазину, целиком зависит от коннектора.
DATEV: экспорт - ваша задача, и формат в ней - меньшая половина
Раз в коробке ничего нет, вопрос только в том, кто напишет экспорт: платный модуль, партнёр или я. Кто бы ни писал, сложность не в CSV. DATEV нужны проводки, а не документы: счёт и корреспондирующий счёт, налоговый ключ, номер документа, по которому сверяется ваш консультант, и дата, попадающая в правильный период. Odoo охотно отдаст все четыре - как только кто-то решит, какой счёт Odoo соответствует какому номеру в плане счетов консультанта и что делать со случаями, для которых номера нет вовсе.
Именно случаи без номера портят закрытие месяца: возврат, переходящий через границу периода, оплата, пришедшая раньше счёта, выплата маркетплейса одной строкой на двести заказов. Поэтому я прошу у консультанта проводки за прошлый месяц ещё до того, как напишу первую строку кода экспорта: этот файл говорит о маппинге больше, чем любое совещание.
GoBD: неизменяемость - это переключатель, и включать его нужно рано
То, чего требуют немецкие правила, в Odoo есть, и по умолчанию оно выключено. У журналов есть restrict_mode_hash_table; если его включить, каждая проведённая запись получает inalterable_hash и secure_sequence_number, так что изменённую строку можно обнаружить. У компании есть restrictive_audit_trail для журнала изменений, который нельзя чистить.
Две ловушки. Первая: у журнала есть ещё и has_unhashed_entries - честное признание того, что всё проведённое до включения режима осталось вне цепочки, и никакая последующая настройка этого не исправит. Включайте режим при запуске системы, а не когда объявили проверку. Вторая ловушка - сама интеграция: коннектор, который «исправляет» проведённый счёт, потому что в магазине изменили заказ, ломает ровно то свойство, которое должен доказывать хеш. Исправления - это новые документы, кредит-нота или сторно, и коннектор нужно писать так с первого дня.
Магазин: Shopware или JTL, и вопрос в том, кто владеет данными
Оба общаются достаточно бегло - Shopware через свой Admin API, JTL через собственную базу и коннектор, - и ни то ни другое не причина, по которой проекты идут вкривь. Причина в том, что остатки и цены существуют на обеих сторонах, и обе стороны считают себя правыми.
Одна таблица решает это до любого кода: слева каждое поле, которое пересекает границу, справа единственная система, которой разрешено его менять. Остатками владеет Odoo, магазину о них сообщают. Цены обычно принадлежат магазину, потому что там проходят акции. Любое поле, для которого ответ - «обе», в течение квартала превратится в обращение в поддержку.
Затем немецкая деталь, которая отнимает больше всего времени: магазины думают в ценах брутто, Odoo - в нетто. Вычтите девятнадцать процентов из 49,99 € и прибавьте обратно, несколько тысяч раз, и разница в центах проявится в бухгалтерии бесконечным списком мелких расхождений, которые никто не может объяснить. Один раз решите, какая сторона главная для цифры, которую видит покупатель, передавайте её именно так, а другая сторона пусть пересчитывает от неё.
Электронный счёт: XRechnung уже в коробке
С начала 2025 года немецкие компании обязаны уметь принимать структурированные счета; обязанность их отправлять вводится поэтапно. Хорошая новость: Odoo 19 уже поддерживает формат - в карточке клиента в списке форматов счетов есть «Germany (XRechnung)» рядом с Factur-X и Peppol BIS 3.0. Сам доступ к Peppol живёт в отдельных модулях.
Для интеграции это означает одно: счёт, который покидает вашу систему, - это документ с полями, а не PDF с их картинкой. Всё, что нужно XML, - ссылка покупателя, разбивка налогов, единица измерения - должно быть в записи до запуска экспорта, и обычно это возвращает меня к коннектору магазина собирать поля, которые никто не сопоставил.
С чего я начинаю такой проект
Один созвон и три вопроса, от которых зависит оценка: какой план счетов использует ваш консультант и должен ли экспорт повторять сложившуюся практику проводок; включён ли режим хеширования и с какого времени; какая система владеет остатками, ценой и карточкой клиента. Ответы помещаются на одну страницу, и эта страница - спецификация интеграции.
Если коннектор у вас уже есть и работает, полезный вопрос другой: что он делает, если его запустить дважды, и как вы узнаете, что прошлой ночью он не запускался вовсе? Обычно меня зовут именно за этим.