Căsuța de intrare care gândește alături de dumneavoastră: PaperOffice AI în n8n, pas cu pas

Bine ați venit la PaperOffice AI Academy. În acest episod, construim o căsuță de intrare inteligentă în n8n care gândește alături de dumneavoastră. Ajunge un lot de scanări și, la final, fiecare document este recunoscut, arhivat, verificat și corelat cu comanda sa. Unde ceva nu se potrivește, o persoană ia decizia.

Rezultatul mai întâi: O execuție reală, oamenii decid

Înainte de a construi orice, să analizăm mai întâi rezultatul: o execuție reală. Apoi, îl vom construi pas cu pas. Exemplul nostru este o scanare în lot cu șase pagini: o comandă de achiziție, o notă de livrare și patru facturi. Pe una dintre ele, apare brusc un număr nou de cont bancar. Trimit lotul de scanare către webhook. Șase pagini într-un singur PDF, exact așa cum ies din scanner. În lista de execuție, rularea începe. Split separă documentele, IDP citește câmpurile, iar fiecare factură marcată trece prin verificarea Ultra. Acest proces durează câteva minute, așa că voi accelera timpul. Execuția a recunoscut șase documente, le-a arhivat și a corelat comenzile. Pentru fiecare document cu un motiv, există acum o sarcină deschisă. Fluxul de lucru este în așteptare și își suspendă activitatea până la luarea deciziilor dumneavoastră. În PaperOffice, sarcinile sunt listate sub Human in the Loop, fiecare având motivul său. PaperOffice cunoaște deja această factură. Este a doua copie a facturii Iberica, cu ștampila de încasare. Fluxul de lucru raportează duplicatul, iar vizualizarea de revizuire indică factura originală. O resping, cu un motiv. Pentru această factură, verificarea raportează un risc ridicat de fraudă: furnizorul indică un nou cont bancar. De la un scor de șapte, un document este automat pus în carantină. Resping și această factură. Factura în valoare de patruzeci și șapte de mii cinci sute de euro nu prezintă nimic neobișnuit. Înainte de a o aproba, confirm câmpurile extrase. Apoi: Approve. Celelalte trei sarcini primesc aceeași decizie. Fiecare decizie declanșează execuția prin intermediul celui de-al doilea webhook. După ultima, procesul se încheie: aproximativ treizeci de minute. Majoritatea acestui timp, fluxul de lucru așteaptă pur și simplu deciziile. Rezultatul în PaperOffice: documentele aprobate se află în Northstar Documents, iar facturile sunt inalterabile până la sfârșitul anului 2036. Sub Activities se află nota fluxului de lucru. Duplicatul se află în Workspace-ul Quarantine, cu un Legal Hold și o notă asociată. Nu mai poate fi șters. Și aceasta este exact căsuța de intrare pe care o construim acum, pas cu pas, cu noduri HTTP simple în n8n. Zece etape.

Etapa 1 din 10: Intrare

Etapa unu este intrarea. Am pregătit nodurile pentru fiecare etapă. Le lipesc și le poziționez corespunzător. Webhook-ul primește fișierul prin POST. Este protejat de Header-Auth: doar cei care trimit cheia corectă în antet primesc acces. Răspunsurile nu sunt automate, ci sunt gestionate prin noduri de răspuns dedicate. Dacă fișierul lipsește, procesul continuă direct cu răspunsul, iar expeditorul primește imediat un mesaj de eroare clar.

Etapa 2 din 10: Split Agent

Etapa doi este Split Agent. Îl conectez la intrare, mai exact la ramura în care se află fișierul. Un singur apel către API-ul PaperOffice, un POST către interfața job-ului. Datele de autentificare sunt stocate ca Header-Auth în n8n, nu în interiorul nodului însuși. Corpul conține șablonul pdf_ai_split, modelul ultra, canalul de procesare, o regulă pentru numele fișierelor, limba și, desigur, fișierul. Jobul rulează în fundal. Astfel, fluxul de lucru verifică jobul la fiecare șase secunde până la finalizare. Odată ce lotul a fost divizat, fluxul de lucru răspunde cu 202 Accepted și continuă cu restul operațiunilor, fără a-l obliga pe expeditor să aștepte.

Etapa 3 din 10: Document cu document

Etapa trei parcurge document cu document. Bucla preia întotdeauna exact un document din rezultatul Split Agent. Apoi, fluxul de lucru descarcă fișierul document prin link-ul său de descărcare.

Etapa 4 din 10: IDP Agent

Etapa patru este IDP Agent. Din nou, un singur apel, de data aceasta folosind șablonul document_idp. Pentru facturi, comenzi de achiziție și note de livrare sunt returnate următoarele câmpuri: furnizorul, numărul, data, sumele și liniile de produs, împreună cu locațiile lor corespunzătoare în documentul original.

Etapa 5 din 10: Arhivare + Knowledge Graph

Etapa cinci: Arhivarea și Knowledge Graph. document-put plasează documentul în Workspace-ul n8n Procurement. procurement_bind leagă apoi factura și nota de livrare de comanda de achiziție corespunzătoare, utilizând numărul comenzii de achiziție găsit de IDP Agent.

Etapa 6 din 10: AI-DMS Ultra

Etapa șase este AI-DMS Ultra. Nu fiecare document necesită o analiză completă; prin urmare, sunt furnizate reguli. O sumă mai mare de 1.000 de euro, o neconcordanță în tipul documentului, o sumă obligatorie lipsă sau o deviație în verificarea în trei puncte. Dacă se aplică o regulă, fluxul de lucru apelează Ultra pentru exact acest document.

Etapa 7 din 10: Audit + sarcină de revizuire

Etapa șapte: sarcina de audit și revizuire. Fluxul de lucru citește riscul de fraudă și raționamentul aferent din document. Prin interfața de sarcină, se creează apoi o sarcină pentru un utilizator uman, cu revizorul, termenul limită, urgența și documentul. Aici ajunge un parser la limita sa. LlamaParse și Mistral OCR oferă text și structură. Ele nu includ un proces de verificare cu sarcină, atribuire, termen limită și dovadă. Ar trebui să construiți acest lucru dumneavoastră înșivă.

Etapa 8 din 10: Verificarea în trei puncte

Etapa opt este verificarea în trei puncte. Bucla are două ieșiri. Prima se declanșează când toate documentele sunt finalizate. O conectez la verificarea în trei puncte. procurement_review verifică fiecare tranzacție: se potrivesc comanda de achiziție, nota de livrare și factura, atât la nivelul sumei totale din antet, cât și la nivelul fiecărei linii individuale? Dacă există vreo abatere, acest lucru va genera și o sarcină.

Etapa 9 din 10: Așteptarea intervenției utilizatorului

Etapa nouă: Așteptarea intervenției umane. Fluxul de lucru se înregistrează cu adresa sa de trezire la PaperOffice și apoi intră în modul de așteptare fără o limită de timp. Când se ia o decizie în PaperOffice, PaperOffice raportează decizia către un al doilea webhook. Acesta identifică execuția care așteaptă această sarcină și o trezește.

Etapa 10 din 10: Aplicarea deciziei

Etapa zece aplică decizia. La aprobare, fluxul de lucru ridică o blocare de audit, utilizând sarcina aprobată ca dovadă. Apoi, documentul se mută în Workspace-ul Northstar Documents, iar facturile devin inalterabile, cu o perioadă de retenție care începe la sfârșitul anului. În cazul unei respingeri, documentul rămâne blocat și i se atribuie un Legal Hold. În ambele cazuri, fluxul de lucru scrie o notă în fișier și apoi așteaptă următoarea decizie. Zece etape, un singur flux de lucru și totul rulează pe o singură platformă: un contract, date în UE, fără subprocesatori. Datele intră, datele ies. Iar odată ce documentele se află în PaperOffice, sunt posibile și mai multe fără o componentă nouă: agentul telefonic, întrebările din Claude sau ChatGPT prin MCP, căutarea și fluxurile de lucru în aplicație. În episoadele următoare, vom examina mai îndeaproape agenți individuali, precum Split, IDP și Redact. Până atunci, vă dorim o experiență plăcută la construirea soluțiilor dumneavoastră.