--- title: "Автоматично въвеждане на поръчки от имейл и PDF в ERP: проверки и изключения" url: https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp description: "Практичен модел за превръщане на B2B поръчки от имейл и PDF в проверени ERP чернови, без дублиране и скрити грешки." --- # Автоматично въвеждане на поръчки от имейл и PDF в ERP: проверки и изключения Практичен модел за превръщане на B2B поръчки от имейл и PDF в проверени ERP чернови, без дублиране и скрити грешки. - Поръчки и доставки - Имейли и документи - Интеграции и CRM Integric AI · 09.06.2026 г. · обновена 02.11.2026 г. · 10 мин. ![Склад с високи стелажи, пълни с кашони](https://integric.ai/img/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp.jpg) Съдържание 1. [Работният поток започва от контролирана входяща поща](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BD%D0%B8%D1%8F%D1%82-%D0%BF%D0%BE%D1%82%D0%BE%D0%BA-%D0%B7%D0%B0%D0%BF%D0%BE%D1%87%D0%B2%D0%B0-%D0%BE%D1%82-%D0%BA%D0%BE%D0%BD%D1%82%D1%80%D0%BE%D0%BB%D0%B8%D1%80%D0%B0%D0%BD%D0%B0-%D0%B2%D1%85%D0%BE%D0%B4%D1%8F%D1%89%D0%B0-%D0%BF%D0%BE%D1%89%D0%B0) 2. [OCR, AI и правила вършат различна работа](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#ocr-ai-%D0%B8-%D0%BF%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%B0-%D0%B2%D1%8A%D1%80%D1%88%D0%B0%D1%82-%D1%80%D0%B0%D0%B7%D0%BB%D0%B8%D1%87%D0%BD%D0%B0-%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B0) 3. [Клиентът и редовете се съпоставят със справочни данни](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D1%8A%D1%82-%D0%B8-%D1%80%D0%B5%D0%B4%D0%BE%D0%B2%D0%B5%D1%82%D0%B5-%D1%81%D0%B5-%D1%81%D1%8A%D0%BF%D0%BE%D1%81%D1%82%D0%B0%D0%B2%D1%8F%D1%82-%D1%81%D1%8A%D1%81-%D1%81%D0%BF%D1%80%D0%B0%D0%B2%D0%BE%D1%87%D0%BD%D0%B8-%D0%B4%D0%B0%D0%BD%D0%BD%D0%B8) 4. [Чернова в ERP, а не обещание към клиента](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D1%87%D0%B5%D1%80%D0%BD%D0%BE%D0%B2%D0%B0-%D0%B2-erp-%D0%B0-%D0%BD%D0%B5-%D0%BE%D0%B1%D0%B5%D1%89%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BA%D1%8A%D0%BC-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D0%B0) 5. [Повторният опит не трябва да създава втора поръчка](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D0%BF%D0%BE%D0%B2%D1%82%D0%BE%D1%80%D0%BD%D0%B8%D1%8F%D1%82-%D0%BE%D0%BF%D0%B8%D1%82-%D0%BD%D0%B5-%D1%82%D1%80%D1%8F%D0%B1%D0%B2%D0%B0-%D0%B4%D0%B0-%D1%81%D1%8A%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0-%D0%B2%D1%82%D0%BE%D1%80%D0%B0-%D0%BF%D0%BE%D1%80%D1%8A%D1%87%D0%BA%D0%B0) 6. [Илюстративен сценарий: поръчка с клиентски кодове](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D0%B8%D0%BB%D1%8E%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B8%D0%B2%D0%B5%D0%BD-%D1%81%D1%86%D0%B5%D0%BD%D0%B0%D1%80%D0%B8%D0%B9-%D0%BF%D0%BE%D1%80%D1%8A%D1%87%D0%BA%D0%B0-%D1%81-%D0%BA%D0%BB%D0%B8%D0%B5%D0%BD%D1%82%D1%81%D0%BA%D0%B8-%D0%BA%D0%BE%D0%B4%D0%BE%D0%B2%D0%B5) 7. [Приемането се доказва с представителен тестов набор](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D0%BF%D1%80%D0%B8%D0%B5%D0%BC%D0%B0%D0%BD%D0%B5%D1%82%D0%BE-%D1%81%D0%B5-%D0%B4%D0%BE%D0%BA%D0%B0%D0%B7%D0%B2%D0%B0-%D1%81-%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%B8%D1%82%D0%B5%D0%BB%D0%B5%D0%BD-%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2-%D0%BD%D0%B0%D0%B1%D0%BE%D1%80) 8. [Кога по-прост или стандартизиран вариант е по-добър](https://integric.ai/blog/avtomatichno-vavezhdane-porachki-email-pdf-erp#%D0%BA%D0%BE%D0%B3%D0%B0-%D0%BF%D0%BE-%D0%BF%D1%80%D0%BE%D1%81%D1%82-%D0%B8%D0%BB%D0%B8-%D1%81%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%B8%D0%B7%D0%B8%D1%80%D0%B0%D0%BD-%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82-%D0%B5-%D0%BF%D0%BE-%D0%B4%D0%BE%D0%B1%D1%8A%D1%80) **Автоматично въвеждане на поръчки** е подходящо за B2B компании, които получават заявки като текст в имейл, Excel файл, сканиран формуляр или PDF от различни клиенти. Целта не е документът просто да бъде „прочетен“, а от него да се създаде проверена чернова на поръчка в ERP: правилният клиент, правилните артикули, мерни единици и количества, плюс видима опашка за всичко неясно. Това не е OCR на фактури и не е синхронизация между онлайн магазин и склад. При този процес входът е клиентска B2B поръчка извън стандартизиран канал, а изходът е ERP чернова, не окончателно потвърждение към клиента. ## Работният поток започва от контролирана входяща поща Добрата реализация не следи произволно личните кутии на търговците. Тя използва служебен адрес или споделена поща, например `orders@`, с определени собственици, права и правила за съхранение. При ново съобщение се запазват идентификаторът на писмото, подателят, получаването, темата и допустимите приложения. Оригиналът остава достъпен чрез препратка за последваща проверка. Още на входа са нужни ограничения. Не всяко приложение трябва да стига до компонента за прочит. Проверяват се позволените файлови формати, реалният тип на файла, размерът и резултатът от антивирусна проверка или проверка в изолирана среда. [OWASP препоръчва](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) да не се вярва само на разширението или на подадения `Content-Type`, да се зададат лимити и файловете да се съхраняват отделно от публичната част на приложението. Потокът трябва да разграничава поне следните входове: - поръчка в текста на имейла без приложение; - един PDF, който съдържа една поръчка; - няколко приложения, от които само едно е поръчката; - документ с повече от една страница или повече от една поръчка; - препратено съобщение и повторно изпратен вече получен файл; - нечетлив, защитен с парола или неподдържан документ. Неподдържаният вход не се изтрива и не се маркира като обработен. Той се записва като изключение с ясна причина и връзка към оригиналното писмо. ## OCR, AI и правила вършат различна работа Трите понятия често се смесват, но решават различни части от задачата. **OCR** разпознава символи от сканирана страница и ги превръща в машинно четим текст. То е необходимо при снимка или сканиран PDF, но само по себе си не знае дали „12“ е количество, цена, номер на ред или част от адрес. **Моделът за извличане** свързва стойностите с бизнес полета: номер и дата на поръчката, клиент, адрес за доставка и редове с артикули. Официалната документация на [Google Document AI](https://docs.cloud.google.com/document-ai/docs/overview) прави същото разграничение между OCR за текст и оформление и извличане на структурирани полета, таблици и двойки ключ-стойност. [Amazon Textract](https://docs.aws.amazon.com/textract/latest/dg/how-it-works-analyzing.html) също описва отделно извличането на текст, формуляри и таблици. Това са примери за възможности, а не причина да се избере конкретен доставчик. **Детерминистичните правила** решават дали извлеченото може да се използва. Те сравняват стойности със справочници и връщат еднозначен резултат: клиентският код съществува или не; SKU е активен или не; мерната единица е позволена или не; количеството е положително число или не. AI не трябва да „предполага“ кой артикул е имал предвид клиентът, когато два сходни кода съществуват в каталога. Практичният поток комбинира трите слоя. При машинно генериран PDF OCR може изобщо да не е нужен. При фиксиран шаблон са достатъчни координати и правила. AI извличането е полезно, когато различни клиенти използват различни оформления, но резултатът му пак минава през строгата бизнес валидация. ## Клиентът и редовете се съпоставят със справочни данни Първо се определя купувачът. Адресът на подателя може да бъде сигнал, но не е надежден единствен ключ: един клиент има няколко служители, а външен счетоводител може да изпраща от негово име. По-силен резултат се получава от комбинация между договорен клиентски номер, данни в документа, регистриран домейн и предварително поддържана таблица за съпоставяне. Следват продуктовите редове. За всеки ред са нужни поне: - оригиналният текст от документа; - клиентски и вътрешен продуктов код, когато са налични; - описание; - количество и мерна единица; - договорена опаковка или преобразуване между брой, кашон и палет; - желана дата или адрес за доставка, ако процесът ги използва. Тези стойности се проверяват срещу основните справочни данни за клиенти, продукти и позволени единици. В документацията за [Dynamics 365 Intelligent Order Management](https://learn.microsoft.com/en-us/dynamics365/intelligent-order-management/data-management) Microsoft описва същото разграничение: справочните данни могат да валидират клиентски номера и продукти, докато самата поръчка е транзакционният запис. Конкретното ERP може да има други имена на полетата, но принципът е същият. Нееднозначното съпоставяне е изключение, а не покана за най-близко съвпадение. Ако клиентът пише „вода 1.5“ и каталогът съдържа няколко марки и опаковки, автоматизацията не трябва сама да избира. Ако в документа пише 10 кашона, а ERP приема бройки, преобразуването е позволено само когато за конкретния артикул има одобрено правило. ## Чернова в ERP, а не обещание към клиента След успешни проверки интеграцията създава ERP поръчка със статус „чернова“ или еквивалентния непотвърден статус. Към нея се записват източникът, оригиналният номер на поръчката, външният идентификатор и резултатите от проверките. Това разделение е важно. Коректно въведени редове не означават автоматично, че компанията може да приеме поръчката. Наличност, актуална цена, кредитен лимит, минимално количество, транспорт и срок за доставка може да изискват отделни проверки или човешко решение. Затова първата работеща версия обикновено не изпраща финално потвърждение до клиента. Тя уведомява отговорния служител, че има готова чернова или изключение. Опашката за човешка проверка трябва да показва конкретната причина, а не общо „AI грешка“. Полезни категории са: непознат клиент, неразпознат SKU, две възможни съвпадения, невалидна единица, липсващо количество, несъвпадение между общ брой и редове, неподдържан файл и ERP отказ. Проверяващият вижда оригиналния фрагмент до предложената стойност, коригира я и продължава процеса. Поправката може да стане пример за последващо подобрение, но не бива автоматично да променя справочник или правило. ## Повторният опит не трябва да създава втора поръчка Дублирането възниква лесно: клиентът препраща същия PDF, пощенският тригер подава съобщението повторно или ERP приема заявката, но отговорът се губи. Решението е идемпотентност: еднакъв бизнес вход води до един и същ резултат дори при повторна обработка. Използвайте две различни идентичности. Бизнес ключът, например клиент плюс неговия номер на поръчка, показва коя поръчка е засегната. Отделен отпечатък на имейла и файла показва дали е пристигнало същото копие. Версията на документа не бива просто да създава нов бизнес ключ: променен PDF със същия номер може да е ревизия или искане за отмяна и трябва да се свърже със съществуващата поръчка за проверка. Когато клиентски номер липсва, случаят остава за човешко решение, вместо да се измисля несигурна идентичност. [AWS Builders’ Library](https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/) обяснява защо повторното API повикване трябва да има същия ефект като еднократното и защо записването на ключа и промяната трябва да се координират атомарно. Ако ERP приема ключ за идемпотентност, подавайте стабилния бизнес ключ и изисквайте повторението да върне вече създадения резултат. Ако не приема, собственото хранилище трябва атомарно да резервира уникалния ключ преди повикването, да пази състояние „в процес“ и да сверява неясния резултат след прекъсване. Отделна операция „провери, после създай“ не е достатъчна, защото два едновременни работни процеса могат да минат проверката преди някой да запише резултата. При недостъпно ERP входящите поръчки остават в опашка със статус „чака запис“, без да се маркират като завършени. Временните грешки се повтарят ограничено с пауза; невалидните данни и отказаните права не се лекуват с безкрайни опити. [Ръководството на Microsoft за фонови задачи](https://learn.microsoft.com/en-us/azure/architecture/best-practices/background-jobs) препоръчва разграничаване на временни от постоянни грешки, идемпотентна обработка и отделна опашка за входове, които системата не може да обработи. Това е архитектурен модел, приложим и извън Azure. ## Илюстративен сценарий: поръчка с клиентски кодове Следващият пример е измислен за обяснение и не е клиентски резултат. Дистрибутор получава PDF от регистриран адрес на B2B клиент. Документът съдържа номер `PO-417`, адрес за доставка и три продуктови реда. Системата извлича данните, намира клиента по договорения номер и проверява редовете в ERP справочника. Първият SKU съществува и количеството е в позволена единица. Вторият използва клиентски код, за който има еднозначна таблица към вътрешния SKU. При третия е посочено „5 пакета“, но продуктът има две активни опаковки и няма договорено преобразуване. Вместо да избере една, потокът поставя цялата поръчка в опашката с маркиран трети ред. Служителят избира правилната опаковка и одобрява. Интеграцията създава ERP чернова и записва връзката между `PO-417` и ERP номера. Малко по-късно клиентът препраща същия PDF. Проверка на бизнес ключа и файловия отпечатък открива съществуващата чернова и прикачва новото съобщение към историята, без да създава втора поръчка. Ако файлът носи същия номер, но променено съдържание, той се маркира като възможна ревизия и чака човек, вместо да отвори нова поръчка. Едва след проверки за наличност и търговски условия служителят потвърждава поръчката по обичайния процес. ## Приемането се доказва с представителен тестов набор Демонстрация с два чисти PDF файла не е приемателен тест. Преди пускане се събира разрешен и обезличен, когато е възможно, набор от реалните типове вход: различни клиенти, шаблони, сканове, дълги таблици, липсващи полета, повторни поръчки и документи, които трябва да бъдат отказани. За всеки пример предварително се записва очакваният клиент, редове и краен статус. Приемателните критерии трябва да са по бизнес поле, не една обща „точност“. Критични са правилният клиент, SKU, количество и мерна единица. Отделно се оценява дали непознатите случаи правилно отиват за проверка. [Google Document AI](https://docs.cloud.google.com/document-ai/docs/evaluate) описва измерване чрез precision, recall и F1 върху анотиран тестов набор и показва, че прагът на увереност променя баланса между грешни приемания и пропуснати стойности. Бизнесът определя приемливия праг според риска; няма универсален процент за всяка поръчка. Освен извличането се тестват целите сценарии: 1. повторно подаване на същия имейл и на същия PDF в нов имейл; 2. прекъсване след приемане от ERP, но преди получен отговор; 3. временно недостъпно ERP и последващо безопасно възстановяване; 4. липсващ клиент, невалиден SKU и двусмислена единица; 5. корекция и одобрение от човек с видима история; 6. сверка между всички входове, ERP черновите и останалите изключения. Журналът трябва да показва кой вход е получен, коя версия на извличането и правилата е използвана, какво е валидирано, кой е коригирал стойност и кой ERP запис е създаден. Не е необходимо в логовете да се копира целият документ. [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html) препоръчва чувствителни лични, търговски и удостоверителни данни да се премахват, маскират или защитават, а достъпът и промените по журналите да се контролират. ## Кога по-прост или стандартизиран вариант е по-добър Процес, автоматизиран по поръчка с OCR или AI не е автоматично най-разумният избор. При малък брой кратки поръчки, които служител така или иначе трябва да прегледа подробно, добра ERP форма или контролиран импорт от Excel може да струва по-малко усилие и да е по-прозрачен. Когато големи партньори могат да изпращат стандартизирани съобщения, EDI или договорен CSV/API формат е по-надежден от четене на PDF. UNECE поддържа актуални [UN/EDIFACT директории](https://unece.org/uncefact/unedifact/2021-2024) със структурирани съобщения за търговски документи, включително поръчки. Ако такъв канал е реалистичен, той трябва да се оцени преди документен AI. Автоматичното въвеждане има най-голям смисъл, когато неструктурираните канали няма да изчезнат, ръчната работа е повтаряема и компанията може да поддържа надеждни клиентски и продуктови справочници. Качественият резултат не е поток, който „разбира всичко“, а система, която създава безопасни ERP чернови, спира при съмнение и оставя всяка поръчка проследима. Следващата стъпка е да подберете поръчки с различни формати и да опишете проверките преди запис. Вижте как това влиза в [автоматизацията на документи и процеси](https://integric.ai/produkti/avtomatizatsiya-na-procesi). Услуга [**Автоматизация на процеси**По-малко преписване на документи и данни](https://integric.ai/produkti/avtomatizatsiya-na-procesi) · [Безплатен анализ](https://integric.ai/meet) Въпроси ## Често задавани въпроси Не намирате отговора? Опишете процеса и ще ви отговорим конкретно. [Задайте въпрос](https://integric.ai/contact) Може ли всяка PDF поръчка да се въведе автоматично в ERP? · Не. Четливите и повтаряеми документи са добри кандидати, но липсващ клиент, неразпознат артикул, неясна мерна единица или противоречиви количества трябва да изпратят поръчката за човешка проверка. Достатъчен ли е OCR за обработка на поръчки от имейл? · OCR превръща изображението в текст, но не гарантира, че правилно е разбрал ролята на всяка стойност. За различни оформления може да е нужен модел за извличане, а продуктовите кодове, мерните единици и клиентите трябва да се валидират с детерминистични правила и ERP справочници. Как се предотвратяват двойни поръчки при повторен имейл или ERP грешка? · Разделете идентичността на поръчката от отпечатъка на конкретния файл или имейл. Бизнес ключът трябва да се запази атомарно или да се подаде като ERP ключ за идемпотентност; отделна предварителна проверка не е достатъчна. Променен документ със същия номер се насочва като ревизия, а не като нова поръчка. Трябва ли автоматизацията да потвърждава поръчката директно на клиента? · Обикновено не в първата версия. Без проверка на наличност, цена, кредитен лимит, срок и търговски условия ERP черновата не е приета поръчка. Финалното потвърждение трябва да следва одобрения бизнес процес. Продължете по темата ## Прочетете още - [· Следваща статия**Автоматизация на договори: извличане на срокове, одобрения и напомняния**Практичен модел за договорен процес с официално хранилище, проверени срокове, контрол на версиите, човешки одобрения и ясна отговорност. · 25.06.2026 г.9 мин.](https://integric.ai/blog/avtomatizaciya-dogovori-srokove-odobreniya) - [· Автоматизация на процеси**Автоматизация на общата служебна поща: как заявките стигат до правилния екип**Практичен работен поток за обща служебна поща: приемане, класификация, извличане на данни, разпределяне, проследяване и преглед на изключенията. · 19.07.2026 г.8 мин.](https://integric.ai/blog/avtomatizaciya-sluzhebna-poshta-zayavki) - [· Автоматизация на процеси**API интеграция: какво трябва да провери бизнесът, преди да свърже две системи**Практичен контролен списък за достъп, данни, лимити, грешки и поддръжка преди свързването на две бизнес системи чрез API. · 24.05.2026 г.8 мин.](https://integric.ai/blog/api-integraciya-biznes-sistemi) - [· Как да започнете**Пилотен проект или пълно внедряване: как да ограничите риска при AI автоматизация**Практичен метод за избор между PoC, ограничен пилот и пълно внедряване на AI автоматизация с ясни тестове, критерии и план за връщане назад. · 07.06.2026 г.10 мин.](https://integric.ai/blog/piloten-proekt-ai-avtomatizaciya) Безплатен анализ ## Да разгледаме един процес Опишете накратко коя повтаряща се задача отнема най-много време. Ще преценим дали има смисъл да се автоматизира и коя е разумната следваща стъпка. [Запазете безплатен анализ](https://integric.ai/meet) · [Вижте реални проекти](https://integric.ai/kazusi) Продължителност 30 минути Цена Безплатно Фокус Един конкретен процес Резултат Ясна следваща стъпка