Автоматично въвеждане на поръчки е подходящо за B2B компании, които получават заявки като текст в имейл, Excel файл, сканиран формуляр или PDF от различни клиенти. Целта не е документът просто да бъде „прочетен“, а от него да се създаде проверена чернова на поръчка в ERP: правилният клиент, правилните артикули, мерни единици и количества, плюс видима опашка за всичко неясно.
Това не е OCR на фактури и не е синхронизация между онлайн магазин и склад. При този процес входът е клиентска B2B поръчка извън стандартизиран канал, а изходът е ERP чернова, не окончателно потвърждение към клиента.
Работният поток започва от контролирана входяща поща
Добрата реализация не следи произволно личните кутии на търговците. Тя използва служебен адрес или споделена поща, например orders@, с определени собственици, права и правила за съхранение. При ново съобщение се запазват идентификаторът на писмото, подателят, получаването, темата и допустимите приложения. Оригиналът остава достъпен чрез препратка за последваща проверка.
Още на входа са нужни ограничения. Не всяко приложение трябва да стига до компонента за прочит. Проверяват се позволените файлови формати, реалният тип на файла, размерът и резултатът от антивирусна проверка или проверка в изолирана среда. OWASP препоръчва да не се вярва само на разширението или на подадения Content-Type, да се зададат лимити и файловете да се съхраняват отделно от публичната част на приложението.
Потокът трябва да разграничава поне следните входове:
- поръчка в текста на имейла без приложение;
- един PDF, който съдържа една поръчка;
- няколко приложения, от които само едно е поръчката;
- документ с повече от една страница или повече от една поръчка;
- препратено съобщение и повторно изпратен вече получен файл;
- нечетлив, защитен с парола или неподдържан документ.
Неподдържаният вход не се изтрива и не се маркира като обработен. Той се записва като изключение с ясна причина и връзка към оригиналното писмо.
OCR, AI и правила вършат различна работа
Трите понятия често се смесват, но решават различни части от задачата.
OCR разпознава символи от сканирана страница и ги превръща в машинно четим текст. То е необходимо при снимка или сканиран PDF, но само по себе си не знае дали „12“ е количество, цена, номер на ред или част от адрес.
Моделът за извличане свързва стойностите с бизнес полета: номер и дата на поръчката, клиент, адрес за доставка и редове с артикули. Официалната документация на Google Document AI прави същото разграничение между OCR за текст и оформление и извличане на структурирани полета, таблици и двойки ключ-стойност. Amazon Textract също описва отделно извличането на текст, формуляри и таблици. Това са примери за възможности, а не причина да се избере конкретен доставчик.
Детерминистичните правила решават дали извлеченото може да се използва. Те сравняват стойности със справочници и връщат еднозначен резултат: клиентският код съществува или не; SKU е активен или не; мерната единица е позволена или не; количеството е положително число или не. AI не трябва да „предполага“ кой артикул е имал предвид клиентът, когато два сходни кода съществуват в каталога.
Практичният поток комбинира трите слоя. При машинно генериран PDF OCR може изобщо да не е нужен. При фиксиран шаблон са достатъчни координати и правила. AI извличането е полезно, когато различни клиенти използват различни оформления, но резултатът му пак минава през строгата бизнес валидация.
Клиентът и редовете се съпоставят със справочни данни
Първо се определя купувачът. Адресът на подателя може да бъде сигнал, но не е надежден единствен ключ: един клиент има няколко служители, а външен счетоводител може да изпраща от негово име. По-силен резултат се получава от комбинация между договорен клиентски номер, данни в документа, регистриран домейн и предварително поддържана таблица за съпоставяне.
Следват продуктовите редове. За всеки ред са нужни поне:
- оригиналният текст от документа;
- клиентски и вътрешен продуктов код, когато са налични;
- описание;
- количество и мерна единица;
- договорена опаковка или преобразуване между брой, кашон и палет;
- желана дата или адрес за доставка, ако процесът ги използва.
Тези стойности се проверяват срещу основните справочни данни за клиенти, продукти и позволени единици. В документацията за Dynamics 365 Intelligent Order Management Microsoft описва същото разграничение: справочните данни могат да валидират клиентски номера и продукти, докато самата поръчка е транзакционният запис. Конкретното ERP може да има други имена на полетата, но принципът е същият.
Нееднозначното съпоставяне е изключение, а не покана за най-близко съвпадение. Ако клиентът пише „вода 1.5“ и каталогът съдържа няколко марки и опаковки, автоматизацията не трябва сама да избира. Ако в документа пише 10 кашона, а ERP приема бройки, преобразуването е позволено само когато за конкретния артикул има одобрено правило.
Чернова в ERP, а не обещание към клиента
След успешни проверки интеграцията създава ERP поръчка със статус „чернова“ или еквивалентния непотвърден статус. Към нея се записват източникът, оригиналният номер на поръчката, външният идентификатор и резултатите от проверките.
Това разделение е важно. Коректно въведени редове не означават автоматично, че компанията може да приеме поръчката. Наличност, актуална цена, кредитен лимит, минимално количество, транспорт и срок за доставка може да изискват отделни проверки или човешко решение. Затова първата работеща версия обикновено не изпраща финално потвърждение до клиента. Тя уведомява отговорния служител, че има готова чернова или изключение.
Опашката за човешка проверка трябва да показва конкретната причина, а не общо „AI грешка“. Полезни категории са: непознат клиент, неразпознат SKU, две възможни съвпадения, невалидна единица, липсващо количество, несъвпадение между общ брой и редове, неподдържан файл и ERP отказ. Проверяващият вижда оригиналния фрагмент до предложената стойност, коригира я и продължава процеса. Поправката може да стане пример за последващо подобрение, но не бива автоматично да променя справочник или правило.
Повторният опит не трябва да създава втора поръчка
Дублирането възниква лесно: клиентът препраща същия PDF, пощенският тригер подава съобщението повторно или ERP приема заявката, но отговорът се губи. Решението е идемпотентност: еднакъв бизнес вход води до един и същ резултат дори при повторна обработка.
Използвайте две различни идентичности. Бизнес ключът, например клиент плюс неговия номер на поръчка, показва коя поръчка е засегната. Отделен отпечатък на имейла и файла показва дали е пристигнало същото копие. Версията на документа не бива просто да създава нов бизнес ключ: променен PDF със същия номер може да е ревизия или искане за отмяна и трябва да се свърже със съществуващата поръчка за проверка. Когато клиентски номер липсва, случаят остава за човешко решение, вместо да се измисля несигурна идентичност.
AWS Builders’ Library обяснява защо повторното API повикване трябва да има същия ефект като еднократното и защо записването на ключа и промяната трябва да се координират атомарно. Ако ERP приема ключ за идемпотентност, подавайте стабилния бизнес ключ и изисквайте повторението да върне вече създадения резултат. Ако не приема, собственото хранилище трябва атомарно да резервира уникалния ключ преди повикването, да пази състояние „в процес“ и да сверява неясния резултат след прекъсване. Отделна операция „провери, после създай“ не е достатъчна, защото два едновременни работни процеса могат да минат проверката преди някой да запише резултата.
При недостъпно ERP входящите поръчки остават в опашка със статус „чака запис“, без да се маркират като завършени. Временните грешки се повтарят ограничено с пауза; невалидните данни и отказаните права не се лекуват с безкрайни опити. Ръководството на Microsoft за фонови задачи препоръчва разграничаване на временни от постоянни грешки, идемпотентна обработка и отделна опашка за входове, които системата не може да обработи. Това е архитектурен модел, приложим и извън Azure.
Илюстративен сценарий: поръчка с клиентски кодове
Следващият пример е измислен за обяснение и не е клиентски резултат.
Дистрибутор получава PDF от регистриран адрес на B2B клиент. Документът съдържа номер PO-417, адрес за доставка и три продуктови реда. Системата извлича данните, намира клиента по договорения номер и проверява редовете в ERP справочника.
Първият SKU съществува и количеството е в позволена единица. Вторият използва клиентски код, за който има еднозначна таблица към вътрешния SKU. При третия е посочено „5 пакета“, но продуктът има две активни опаковки и няма договорено преобразуване. Вместо да избере една, потокът поставя цялата поръчка в опашката с маркиран трети ред.
Служителят избира правилната опаковка и одобрява. Интеграцията създава ERP чернова и записва връзката между PO-417 и ERP номера. Малко по-късно клиентът препраща същия PDF. Проверка на бизнес ключа и файловия отпечатък открива съществуващата чернова и прикачва новото съобщение към историята, без да създава втора поръчка. Ако файлът носи същия номер, но променено съдържание, той се маркира като възможна ревизия и чака човек, вместо да отвори нова поръчка. Едва след проверки за наличност и търговски условия служителят потвърждава поръчката по обичайния процес.
Приемането се доказва с представителен тестов набор
Демонстрация с два чисти PDF файла не е приемателен тест. Преди пускане се събира разрешен и обезличен, когато е възможно, набор от реалните типове вход: различни клиенти, шаблони, сканове, дълги таблици, липсващи полета, повторни поръчки и документи, които трябва да бъдат отказани. За всеки пример предварително се записва очакваният клиент, редове и краен статус.
Приемателните критерии трябва да са по бизнес поле, не една обща „точност“. Критични са правилният клиент, SKU, количество и мерна единица. Отделно се оценява дали непознатите случаи правилно отиват за проверка. Google Document AI описва измерване чрез precision, recall и F1 върху анотиран тестов набор и показва, че прагът на увереност променя баланса между грешни приемания и пропуснати стойности. Бизнесът определя приемливия праг според риска; няма универсален процент за всяка поръчка.
Освен извличането се тестват целите сценарии:
- повторно подаване на същия имейл и на същия PDF в нов имейл;
- прекъсване след приемане от ERP, но преди получен отговор;
- временно недостъпно ERP и последващо безопасно възстановяване;
- липсващ клиент, невалиден SKU и двусмислена единица;
- корекция и одобрение от човек с видима история;
- сверка между всички входове, ERP черновите и останалите изключения.
Журналът трябва да показва кой вход е получен, коя версия на извличането и правилата е използвана, какво е валидирано, кой е коригирал стойност и кой ERP запис е създаден. Не е необходимо в логовете да се копира целият документ. OWASP препоръчва чувствителни лични, търговски и удостоверителни данни да се премахват, маскират или защитават, а достъпът и промените по журналите да се контролират.
Кога по-прост или стандартизиран вариант е по-добър
Процес, автоматизиран по поръчка с OCR или AI не е автоматично най-разумният избор. При малък брой кратки поръчки, които служител така или иначе трябва да прегледа подробно, добра ERP форма или контролиран импорт от Excel може да струва по-малко усилие и да е по-прозрачен.
Когато големи партньори могат да изпращат стандартизирани съобщения, EDI или договорен CSV/API формат е по-надежден от четене на PDF. UNECE поддържа актуални UN/EDIFACT директории със структурирани съобщения за търговски документи, включително поръчки. Ако такъв канал е реалистичен, той трябва да се оцени преди документен AI.
Автоматичното въвеждане има най-голям смисъл, когато неструктурираните канали няма да изчезнат, ръчната работа е повтаряема и компанията може да поддържа надеждни клиентски и продуктови справочници. Качественият резултат не е поток, който „разбира всичко“, а система, която създава безопасни ERP чернови, спира при съмнение и оставя всяка поръчка проследима.
Следващата стъпка е да подберете поръчки с различни формати и да опишете проверките преди запис. Вижте как това влиза в автоматизацията на документи и процеси.
