Прекарах над десет години в внедряване на Odoo за компании в България и Югоизточна Европа. Малки семейни бизнеси, средни производители, многофирмени групи с дъщерни дружества в три държави. Това, което научих през това време, е, че разликата между това, което хората очакват от софтуера, и това, което софтуерът всъщност предоставя, почти винаги е комуникационен проблем. Софтуерът не разбира какво има предвид потребителят. Потребителят не знае как да говори на езика на софтуера. И така, те говорят един през друг, завинаги.
AI трябваше да реши този проблем. И в някои отношения го направи. Но начинът, по който AI обикновено е свързан с ERP системите днес, създава нова версия на същия стар проблем — освен че този път AI не разбира бизнеса, защото никой не му е дал правилния контекст, с който да работи.
Това е историята за това защо се случва така и какво изградихме, за да го адресираме.
Начинът, по който хората мислят, срещу начина, по който базите данни мислят
Когато търговец отвори поръчка в Odoo, той вижда пълна картина: клиент, дата, списък с продукти с количества и цени, склад, условия за плащане, обща сума. Всичко на един екран. В ума му, тази поръчкаетази картина — последователна, смислена, в контекст.
Базата данни вижда нещо съвсем различно. Тя вижда десетки колони, разпределени в три таблици, свързани чрез външни ключове.partner_id = 1423. amount_total = 540.00. warehouse_id = 2. Числа без история, без отношения, без значение в изолация.
Тази напрегнатост — между начина, по който хората разбират информацията и начина, по който тя всъщност е структурирана в системата — е в основата на всяка трудност при внедряването на ИИ в ERP. И архитектурното решение, което вземате относно това как да преодолеете тази пропаст, определя дали вашият ИИ асистент е наистина полезен или просто скъпа търсачка.
Когато търговски мениджър поиска "поръчки от Петров над 1,000 лв. миналия месец", той мисли като бизнесмен. Системата трябва да отговори като такъв — а не като SQL заявка.
Какво избра Odoo 19 EE да направи — и защо е разбираемо
Odoo 19 Enterprise вгражда ИИ директно в ядрото. Индексиране по полета чрез pgvector в PostgreSQL, конфигурируеми агенти, действия на ИИ сървъра, търсене на естествен език. Подходът има ясна логика: данните вече са в Postgres, pgvector е разширение, няма нищо ново за инсталиране. Бързо за доставка, лесно за активиране, нулева допълнителна инфраструктура.
Но когато погледнете какво всъщност се случва, когато потребител зададе въпрос, се появяват пукнатини.
Проблемът с фрагментацията
Когато Odoo 19 индексира продажна поръчка, той го прави поле по поле. Името на клиента става един вектор. Общата сума става друг. Датата става трети. Всеки вектор съдържа стойността на едно поле — без да знае, че тези три стойности принадлежат на една и съща бизнес транзакция.
В малки бази данни с прости модели на данни, това работи адекватно. С над 50 000 записа и вида релационна сложност, която генерират производствени или дистрибуционни клиенти — продажни поръчки с 15 реда, всеки свързан с продуктови шаблони с множество варианти — качеството на резултатите забележимо се влошава. ИИ трябва да реконструира картината от фрагменти. И от нашия опит с реални клиенти, потребителите спират да се доверяват на ИИ след първите няколко разочароващи отговора.
Разходите за инфраструктура
pgvector споделя същата PostgreSQL инстанция с вашите бизнес данни. Търсенето на векторна подобие е изчислително интензивно. За клиенти с големи обеми на транзакции — производители, които управляват MRP, дистрибутори с постоянни движения на стоките — сме видели как това допълнително натоварване влияе на отзивчивостта на системата по начини, които е трудно да се оправдаят пред финансов директор, който просто иска ERP да бъде бърз.
Заключването
Когато вашата ИИ архитектура е интегрирана в версията на Odoo, вашият избор на модел за вграждане, стратегия за индексиране и всички свързани параметри са обвързани с цикъла на издаване на Odoo. Миграцията от версия 19 до 20 означава реконструиране на целия ИИ индекс — процес, чиято сложност в производствена среда не е тривиална.
Odoo 19 EE прави прагматичен избор: максимална леснота на настройка при минимална зависимост от инфраструктурата. Въпросът е дали тези приоритети съвпадат с вашите — особено ако мислите за ИИ не като функция, която да отметнете, а като дългосрочна стратегическа инвестиция.
Единицата на контекста
Модулът, който изградихме —ai_tokenizer, вграден вl10n_bg_claude_terminal— започва от различна предпоставка:единицата на AI контекста е екранът, а не полето.
Формулярният изглед на Odoo е естественото определение на бизнес обект от гледната точка на потребителя. Той включва всичко: директни полета, разрешени Many2one отношения (клиент с град, кредитен лимит, категория), One2many редове (редове на поръчки с продукти, количества, цени) и агрегати (общи суми, данъци, статус). Всичко това е видимо с един поглед.
Вземаме всичко на този екран и го превеждаме в единкомпозитен документ— структурирано текстово съдържание, четимо от човек, съдържащо пълния бизнес контекст на записа. Този документ е това, което се индексира.
Когато Клод получи това, той вижда точно това, което вижда търговецът. Не изолирани числа. Пълна картина на бизнес транзакция — на езика на бизнеса, а не на езика на базата данни.
Проницателността е проста, но значима: ИИ трябва да разбира бизнеса така, както хората го разбират — в контекст, в отношения, в смисъл. Не като набор от стойности в колони.
Как работи на практика
Архитектурата има три ясно отделени слоя, всеки с една единствена отговорност.
Резултатът: когато потребителят попита “покажи ми последните поръчки от Петров”, Клод вече има пълната картина на всяка поръчка — не набор от стойности на полета за реконструкция, а завършен, четим от човек бизнес документ. Отговорът е бърз, точен и контекстуално завършен.
Когато ти е нужно сега
В случаи, когато фоновият процес е твърде бавен — току-що сте създали запис и искате Claude да знае за него незабавно — терминалната панел на Claude в Odoo включва бутон „Токенизирай сега“. Едно кликване, синхронна обработка, актуализации на статусния значок в реално време. Значката показва дали текущият запис е индексиран, остарял или в очакване.
Сигурност: къде живеят данните е важно
За много организации — особено в регулирани сектори — въпросът закъде отиват даннитее по-важен от въпроса заколко добър е ИИ. Архитектурата е проектирана с този приоритет в ума.
Какво променя това за вашия екип
За бизнес анализатори и мениджъри
Въпроси на естествен език — “покажи ми клиенти, чиито поръчки са намалели с повече от 30% в сравнение с миналото тримесечие” — получават отговор с пълен контекст за всяка поръчка: кои продукти, какви количества, кой търговец, какви бележки са добавени. Не само числа. Пълната картина.
За екипи по НИРД и продукти
Claude Code CLI с достъп до Qdrant означава, че разработчик може да попита “какви персонализации са направени на sale.order за клиент X” и да получи отговор, основан на реални данни — а не на документация, която може да е остаряла. Прегледът на кода, отстраняването на грешки в работния поток и анализът на данни стават значително по-бързи, когато ИИ вече знае контекста.
За ИТ архитекти и CTO-та
Системата е модулна и заменяема на всеки етап. Смяната на модела за вграждане от локален Ollama на Voyage AI или OpenAI е промяна в конфигурацията — без модификация на кода, без изграждане на индекса от нулата. Независимостта от цикъла на издаване на Odoo е стратегическо предимство. И за 50 до 100 клиенти на Odoo, системата работи с отделна Qdrant колекция за всяка база данни — пълна изолация между клиентите, мащабируема до милиони записи на един Qdrant инстанс.
Къде отива това
Изграждаме това в три етапа, всеки от които е качествено различен слой на способност.
Кодът е отворен
Основната инфраструктура на MCP и двигателят за токенизация са и двата с отворен код под LGPL-3.0. Ако искате да видите как всъщност изглежда разговорният ERP в продукция, или ако обмисляте AI за собствената си реализация на Odoo, кодът е най-добрата отправна точка.
Ако имате въпроси относно архитектурата, относно конкретни сценарии на внедряване или относно това как би изглеждало за вашата организация — свържете се с нас. Ние работим с това в продукция и сме щастливи да споделим какво сме научили.
Поддържач на OCA l10n-bulgaria · 10+ години опит с внедряване на Odoo · bl-consulting.net