Всяка поръчка в една хронология, от приемането до платената фактура.
Процесите от поръчката до плащането, от покупката до плащането и от заявката за услуга до фактурата минават през ERP, CRM, електронен магазин, склад, транспорт и счетоводство. Свързваме тези системи с документирани API и събития, даваме на всяка поръчка един статус във всички тях и изпращаме всяко изключение към агент, който подготвя решение, а човек го одобрява.
За български производители, търговци и дистрибутори, които продават, купуват и фактурират и в други държави от ЕС.
07Преглед на потока и отстраняване на причинитеЧовек
Поръчка за продажба, поръчка за покупка или заявка за услуга се записва веднъж в системата, която отговаря за нея, и се разпространява към другите системи чрез документирани API и събития. Събитията за статус изграждат една хронология за всяка поръчка. Когато стъпка не успее или излезе извън допустимото отклонение, агент събира контекста и предлага решение, което човек одобрява, преди то да бъде изпълнено в основната система. Фактурите се обменят и съпоставят като структурирани електронни фактури, а собствениците на процесите преглеждат потока и състоянието на интерфейсите.
Преди и след
Какво се променя в ежедневната работа
Днес
Със системата
Днес
Днес: Повторно въвеждане при всяко предаване
Поръчка от електронния магазин или от търговците се въвежда отново в ERP системата, а данните за доставката и фактурата се преписват на ръка в системите за склад, транспорт и счетоводство.
Със системата
Със системата: Въвежда се веднъж, използва се навсякъде
Всяка поръчка, доставка и фактура се създава в системата, която отговаря за нея, и се публикува като събитие. Другите системи се абонират за събитието, вместо да въвеждат данните отново.
Днес
Днес: Вчерашният статус
Заради нощните пакетни интерфейси обслужването на клиенти, планирането и счетоводството виждат различно, остаряло състояние на една и съща поръчка. Клиентът, който пита къде е доставката, чака обратно обаждане.
Със системата
Със системата: Един актуален статус
Всяка поръчка или заявка има една хронология, изградена от събитията на всички системи, през които минава. Обслужването на клиенти, планирането и счетоводството виждат едни и същи факти, както и решението Обслужване на клиенти и граждани, когато отговаря на въпроси за статус.
Днес
Днес: Изключения в пощенските кутии
Липси на склад, разлики в цените, неуспешни доставки и отхвърлени електронни фактури се решават по имейл и в таблици, а после никой не може да каже кой какво е решил.
Със системата
Със системата: Изключенията пристигат с предложение
Агент събира данните зад всяко изключение и предлага решение. Човек го одобрява, редактира или отхвърля на едно работно място за изключения, а решението се записва.
Днес
Днес: Основни данни, които се разминават
Един и същ клиент, доставчик, продукт или цена съществува в няколко системи с различни стойности и никой не отговаря за това коя стойност е вярната.
Със системата
Със системата: Един собственик за всеки вид данни
Клиентите, доставчиците, продуктите и цените имат договорена основна система и посочен собственик. Дубликатите и конфликтите се съобщават на този собственик, а не се поправят мълчаливо по-надолу по веригата.
Днес
Днес: Всяка промяна добавя интерфейс
Нов канал за продажби, онлайн платформа за търговия или юридическо лице означава още една пряка връзка. Изискванията за електронно фактуриране в различните държави добавят и формат, и мрежа към всеки процес.
Със системата
Със системата: Новите връзки използват същите интерфейси
Нов канал, юридическо лице или мрежа за електронни фактури се свързва веднъж с документираните API и събития, вместо поотделно с всяка система.
Работен процес
Как протича работният процес
Когато данните са чисти, основният път не изисква ръчна работа. Когато поръчка, доставка или фактура се отклони, цикълът за изключения я довежда до човек с доказателствата и с предложение, а одобрената корекция се връща през същия интеграционен слой.
Примерен работен процес
7 стъпки · 1 човешка проверка
Легенда
Система
AI агент
Човек
Човешка проверка
Път при изключение
Свързани процеси: примерен работен процес с цикъл за изключения
Прочетете диаграмата като текст
Основният път води от еднократното записване на бизнес събитие в основната му система, през разпространението му към другите системи чрез API и събития и изграждането на една хронология за всяка поръчка, до фактурирането, съпоставянето и плащането. Завършва с преглед на потока от собствениците на процесите и отстраняване на причините за изключенията.
Когато стъпка не успее, закъснее или излезе извън допустимото отклонение, изключението напуска основния път след стъпката с хронологията. Агент събира контекста и предлага решение, а човек го одобрява, редактира или отхвърля. Одобреното действие се изпълнява в основната система и се връща към стъпката за разпространение като ново събитие.
Стъпката за одобрение е човешката проверка: никое финансово осчетоводяване, промяна на цена или кредитен лимит и никой ангажимент към клиент не се прави без човек.
01
Стъпка 1: Еднократно записване на събитиетоСистема
Поръчка за продажба от електронния магазин, от онлайн платформа, по EDI или от търговците, поръчка за покупка или заявка за услуга се създава в системата, която отговаря за нея. Тази система публикува бизнес събитие в плик CloudEvents, описано в договор AsyncAPI. Хартиените и PDF поръчки и фактурите от доставчици минават първо през решението Обработка на документи.
02
Стъпка 2: Разпространение чрез API и събитияСистема
Интеграционният слой доставя събитието до системите за склад, транспорт, счетоводство и CRM чрез техните документирани API (OpenAPI). Получателите са идемпотентни, така че повторено съобщение никога не създава втора пратка или фактура, а недоставените съобщения чакат в опашка за грешки, за да бъдат изпратени отново.
03
Стъпка 3: Една хронология за всяка поръчкаСистема
Събитията за статус от всички системи (потвърдена, комплектована, изпратена, доставена, фактурирана, платена) се свързват по бизнес номера в една хронология. Правилата за етапи и допустими отклонения създават изключение, когато стъпка не успее, закъснее или не съвпадне: липса на склад, цена извън договореното отклонение, неуспешна доставка, отхвърлена електронна фактура.
04
Стъпка 4: Събиране на контекст и предложениеAI агент
За всяко изключение агент чете нужното от участващите системи: поръчката, наличностите, ценовото споразумение, статуса при превозвача и условията на клиента. Той предлага решение с обосновка и с използваните данни, например заместващ артикул, коригирана цена, нова дата на доставка или кредитно известие.
Път при изключение: Неуспешна стъпка или отклонение
05
Стъпка 5: Одобрение в рамките на праговетеЧовек
Служител в обслужването на клиенти, логистиката или счетоводството вижда изключението, доказателствата и предложението на работното място за изключения и го одобрява, редактира или отхвърля. Одобреното действие се изпълнява чрез API на основната система, която публикува промяната като ново събитие.
Път при изключение: Неуспешна стъпка или отклонение· Връща се към стъпка 2
Човешка проверка
Агентите никога не осчетоводяват финансови операции, не променят цени или кредитни лимити и не поемат ангажименти към клиенти без одобрение. Праговете за всеки вид действие определят кой одобрява, а всяко предложение и решение се записва.
06
Стъпка 6: Фактуриране, съпоставяне и плащанеСистема
Изходящите фактури излизат от ERP системата като структурирани електронни фактури по EN 16931: към българските публични възложители, а към партньори в други държави от ЕС например чрез точка за достъп до Peppol (Peppol BIS Billing 3.0). Входящите фактури от доставчици се съпоставят с поръчките за покупка и стоковите разписки, а статусът на плащането от банката или платежния доставчик затваря хронологията.
07
Стъпка 7: Преглед на потока и отстраняване на причинитеЧовек
Собствениците на процесите и интеграционният екип преглеждат редовно изключенията по причина, грешките в интерфейсите и конфликтите в основните данни. Те отстраняват причината там, където е: в запис с основни данни, в правило за отклонение или в съответствието на полетата, вместо да решават едно и също изключение отново.
Компоненти
Какво бихме изградили
01
Интеграционен слой, задвижван от събития
API и събития, проектирани първо като договор, между ERP, CRM, електронен магазин, склад, транспорт и счетоводство, описани в OpenAPI и AsyncAPI с пликове CloudEvents, върху съществуващата Ви интеграционна платформа или изградени директно в облака.
Договорена основна система и собственик за всеки вид данни, правила за съпоставяне на клиенти, доставчици и продукти и отчети за дубликати и конфликти за хората, които отговарят за тях.
Услуга, която свързва събитията в една хронология за всяка поръчка или заявка, прилага правилата за етапи и отклонения и показва потока и изключенията на собствениците на процесите.
Опашка от изключения със събрания контекст и предложението на агента, с действия за одобрение, редакция и отхвърляне и с прагове за одобрение за всеки вид действие, прилагани там, където действието се изпълнява.
Фактури по EN 16931 в UBL или CII, включително Peppol BIS Billing 3.0, изпращани и получавани чрез точка за достъп или доставчик на услуги за електронни фактури, проверени преди изпращане, като отхвърлените фактури отиват на работното място за изключения.
Наблюдение и известяване за всеки интерфейс, ръководства за екипа по експлоатация и контролирано повторно изпращане на неуспешни съобщения, внедрени като инфраструктура като код във Вашия облачен абонамент.
Структурирани електронни фактури и отговори за статус
Банкови извлечения и известия за плащания
Ядро на решението
Свързани процеси
Системи, с които работи
Продажби, покупки и финанси в SAP S/4HANAПлатформаSAP
Salesforce Sales, Service и Commerce CloudПлатформаSalesforce
Продажби, склад, покупки и счетоводство в OdooПлатформаOdoo
Платформи за електронна търговия, онлайн платформи и API на превозвачи
Системи за управление на склада и транспорта
Точка за достъп до Peppol, доставчици на електронни фактури, банки и платежни доставчици
Управление на продуктовата информация и платформата за данни
Контролни механизми
Вградени механизми за контрол
Граници на достъпа
Всяка интеграция и агентът работят със собствена служебна идентичност във всяка система, ограничена до операциите на API, които са им нужни. Агентът може да чете от различни системи, за да събере контекст, но може да записва само чрез кратък списък от одобрени действия, изпълнявани от API на основната система и никога чрез пряк достъп до базата данни.
Човешка проверка
Праговете за одобрение се определят за всеки вид действие заедно със собственика на процеса: какво агентът може само да предложи, какво одобрява член на екипа и какво изисква втори одобряващ. Финансовите осчетоводявания, промените на цени и кредитни лимити и ангажиментите към клиенти винаги чакат човек. Действия с малко въздействие, които могат да се отменят, например повторно изпращане на неуспешно съобщение, могат да се изпълняват без одобрение, ако собственикът е съгласен.
Проследимост
Всяко събитие, предложение, одобрение, отхвърляне и изпълнено действие се записва към номера на поръчката или заявката, с данните, които агентът е използвал, версията на модела и на инструкциите и одобряващия. Оспорена фактура или жалба от клиент може да бъде проследена стъпка по стъпка.
Защита на данните
Данните за контакт на клиенти и доставчици отиват само до системите, които се нуждаят от тях. Хронологията съхранява бизнес номера и статуси, а не пълни записи, а записите следват срока за съхранение, който определяте. Обработването остава в договорения регион.
Прозрачност на изкуствения интелект
Предложенията на агента са маркирани като такива на работното място за изключения, с доказателствата и обосновката до тях. Основните системи остават меродавни: хронологията показва това, което те отчитат, и никога не ги отменя.
Показатели
Какво бихме измервали
Договаряме тези показатели с Вас по време на проучването и вземаме изходното състояние от записите на сегашните системи и интерфейси, преди нещо да се промени.
Какво бихме измервали
Показател
Защо е важно
Как бихме го измерили
01Цикъл на поръчката
Защо е важноПоказателят, който клиентите забелязват първи и който показва къде чакат поръчките.
Как бихме го измерилиВремето от получаването на поръчката до доставката и до плащането, по канал и юридическо лице, от събитията в хронологията.
02Поръчки без ръчна намеса
Защо е важноПоказва каква част от потока работи с чисти данни и договорени правила.
Как бихме го измерилиДелът на поръчките и заявките, които стигат до плащане без ръчна стъпка или изключение, по данни от хронологията.
03Изключения по причина и време за решаване
Защо е важноПоказва кои причини да отстраните първо и дали работното място за изключения смогва.
Как бихме го измерилиБрой изключения по код на причината и времето от откриването до изпълненото решение, от записите на работното място за изключения.
04Дял на отхвърлените електронни фактури
Защо е важноОтхвърлените фактури забавят плащането и обикновено сочат грешки в основните данни или в съответствието на полетата.
Как бихме го измерилиДелът на изпратените и получените електронни фактури, които са отхвърлени, по причина, от отговорите на точката за достъп или на доставчика.
05Грешки в интерфейсите и време за възстановяване
Защо е важноПоказва дали интеграционният слой е надежден и дали грешките се забелязват и отстраняват бързо.
Как бихме го измерилиНеуспешни съобщения за всеки интерфейс и времето от грешката до успешното повторно изпращане, от наблюдението на интеграциите.
06Дубликати и конфликти в основните данни
Защо е важноПовечето изключения водят началото си от данни, които се различават между системите.
Как бихме го измерилиОткрити дубликати и противоречиви стойности за всеки вид данни и система, от отчетите за съпоставяне.
Не определяме целеви стойности, преди да има изходно измерване.
Внедряване
Как бихме го въвели
Фаза 01
Проучване и карта на процеса
Един процес, например от поръчката до плащането за един канал за продажби, и един вид изключение. Описваме системите, интерфейсите, собствениците на данни и начина, по който изключенията се решават днес.
Критерии за завършване
Описани процес, системи и собственици на данни
Договорени първи вид изключение и прагове за одобрение
Изходно състояние от сегашните записи
Фаза 02
Интеграция и хронология
Документирани API и събития за системите в обхвата, а хронологията работи успоредно със съществуващите интерфейси, без да ги променя.
Критерии за завършване
Публикувани и версионирани описания на събитията
Хронологията съвпада с основните системи при извадка от поръчки
Изпробвани повторно изпращане и ръководства
Фаза 03
Пилот на работното място за изключения
Агентът предлага решения за избрания вид изключение, а хората одобряват всяко предложение. Сравняваме предложенията с това, което служителите биха направили.
Критерии за завършване
Качеството на предложенията отговаря на договорените критерии
Определени прагове и одобряващи за всеки вид действие
Записите са прегледани от финансите и вътрешния контрол
Фаза 04
Разширяване и изключване на старото
Още видове изключения, канали, юридически лица и процеси, например от покупката до плащането, всички върху същите описания. Старите преки интерфейси се изключват един по един.
Критерии за завършване
Всеки нов поток е върху същите описания и наблюдение
Поръчки по заявка и за резервни части от ERP системата към склада и превозвачите, с потвърждения от доставчици и електронни фактури, съпоставени с поръчките за покупка.
Искания за присъединяване и монтаж, проследени от работната поръчка през посещението на терен до фактурата, и материали, купени по рамкови споразумения.
Работни поръчки за поддръжка, поръчки към подизпълнители и фактурите им, проследени от заявката до плащането в общинско дружество за градски транспорт.
От покупката до плащането в общини и държавни агенции: входящи електронни фактури по EN 16931, съпоставени с договорите по Закона за обществените поръчки и с приемо-предавателните протоколи преди плащане.
Илюстративен пример
Доставчик на автомобилни компоненти
Ситуация
Доставчик на автомобилни компоненти с два завода в България доставя на клиенти в няколко държави от ЕС. Поръчките и графиците за доставка пристигат по EDI и по имейл, превозвачите съобщават за проблеми по имейл, а фактурите към всеки клиент се изготвят по различен начин.
Система
Поръчките, наличностите, пратките и фактурите се движат като събития между EDI връзките, ERP системата, складовата система и превозвачите, а всяка поръчка има една хронология. Фактурите излизат като структурирани електронни фактури във формата и мрежата, които изисква държавата на клиента, а ERP системата е подготвена за структурираните фактури, които предвижда законопроектът от 5 ноември 2026 г.
Човешки контрол
Липсите на материали и неуспешните доставки отиват на едно работно място за изключения, където агент предлага нова дата на доставка или частична пратка. Отделът по продажбите одобрява всяко предложение, а промените на цени и кредитните известия изискват одобрение от финансите.
Какво бихме измервали
Дял на поръчките без ръчна намеса по клиент и канал, изключения по причина и време за решаване и дял на отхвърлените електронни фактури по държава.
България
Един процес, еврото и новите правила за фактурите
Много български производители и търговци работят с ERP системи, превозвачи и банки в няколко държави от ЕС. От 1 януари 2026 г. България е в еврозоната и цените, фактурите и плащанията в страната вече са в евро. Публичните възложители приемат електронни фактури по EN 16931 от 2019 г., а законопроект, внесен в Народното събрание на 5 ноември 2026 г., предвижда структурирани електронни фактури от 1 юли 2028 г., обменяни чрез акредитирани доставчици в мрежа, основана на стандарта CEF eDelivery AS4. Проектираме един интеграционен слой, в който форматът и мрежата на всяка държава стоят зад едни и същи събития, така че ново изискване означава нова връзка, а не нов процес.
Актът за данните, приложим от 12 септември 2025 г., определя правила за смяна на услугите за обработка на данни, затова поддържаме описанията на събитията и експорта на данни преносими. Агентите на работното място за изключения са проектирани с оглед на Акта за изкуствения интелект, а интеграциите идват със записан достъп и документирани компоненти за клиентите, които трябва да покажат сигурност на веригата на доставки по Закона за киберсигурност.
Не. ERP, CRM, електронният магазин и складовата система вършат всяка своята работа. Изграждаме интеграцията около тези основни системи, договаряме коя система отговаря за кои данни и даваме на процеса една хронология през всички тях. Когато стара система за поръчки или ERP пречи на промените, решението Модернизация на стари системи първо я поставя зад API.
02Заменяте ли интеграционния ни софтуер?
Не, ако си върши работата. Надграждаме интеграционната платформа или брокера на съобщения, които вече използвате, и добавяме описания на интерфейсите, наблюдение и повторно изпращане там, където липсват. Ако няма такава платформа, изграждаме директно в облака. Повече ще намерите на страницата Интеграции и API.
03Могат ли агентите да действат самостоятелно?
Само в рамките на праговете, които договорите за всеки вид действие, и само за действия с малко въздействие, които могат да се отменят, например повторно изпращане на неуспешно съобщение. Финансовите осчетоводявания, цените, кредитните лимити и ангажиментите към клиенти винаги изискват човек. Прочетете статията Къде AI агентите се нуждаят от човешко одобрение.
04Как се вписват изискванията за електронно фактуриране?
В България публичните възложители приемат и обработват електронни фактури по EN 16931 от 1 ноември 2019 г., а законопроект, внесен в Народното събрание на 5 ноември 2026 г., предвижда структурирани електронни фактури от 1 юли 2028 г. В другите държави от ЕС националните изисквания влизат в сила на различни дати, а пакетът „ДДС в цифровата ера“ прави структурираното електронно фактуриране стандарт за вътреобщностните доставки между предприятия от 1 юли 2030 г. Разглеждаме електронната фактура като още едно събитие в процеса: издадена от ERP системата, изпратена чрез точка за достъп или доставчик и обработена на работното място за изключения, ако бъде отхвърлена. Вижте статията Електронни фактури и Peppol в България.
05Как избягвате поредната крехка мрежа от преки връзки?
Системите публикуват и използват документирани събития и API през един слой, а не чрез преки връзки помежду си. Описанията са версионирани, получателите са идемпотентни, неуспешните съобщения могат да се изпратят отново, а всеки поток има посочен собственик. Нов канал се абонира за съществуващите събития, вместо да добавя връзка към всяка система.
06С какъв обхват да започнем?
С един процес и един вид изключение, например от поръчката до плащането за един канал за продажби, с липсите на склад като първо изключение. Така се доказват събитията, хронологията и одобрението, преди да се добави още. Повече за етапите на работа ще намерите на страницата Нашият подход.
Обсъдете потоците си от поръчки и фактури
Изберете един процес и държавите, в които протича. Ще опишем с Вас системите, интерфейсите и изключенията и ще предложим първа версия, която работи за всички Ваши юридически лица.