Această serie a început cu cum se mapează Protocolul Context Model, standardul deschis publicat de Anthropic în 2024, pe un API de transport maritim, apoi a dărâmat serverele MCP de transport care au fost livrate în 2026, apoi a acoperit cum să securizezi unul. Toate cele 3 părți anterioare se opresc în același punct: agentul a rezervat o încărcătură. Această parte este ceea ce urmează și este partea cu care companiile se luptă de fapt. O rezervare care nu ajunge niciodată în sistemul de evidență nu este o rezervare în care echipa dvs. financiară are încredere. Deci, adevărata întrebare de integrare nu este „poate agentul să rezerve?”, ci „poate agentul să scrie acea rezervare înapoi în SAP, Oracle sau NetSuite fără a sparge registrul”.
Scriu acest lucru din perspectiva marketplace-ului, unde expunem rezervările printr-un API și urmărim cum clienții le integrează în back office-ul lor. Apelul de rezervare este jumătatea ușoară. Scrierea înapoi este cea care consumă timp de inginerie.
De ce write-back este jumătatea mai dificilă
Rezervarea unei încărcături este o acțiune unică, satisfăcătoare. Reconcilierea ei este o lungă istorie de cel puțin 4 obligații separate. Expedierea trebuie să apară ca o înregistrare pe care cineva din departamentul financiar o recunoaște. Costul ei trebuie să fie înregistrat în contul corect. Starea ei trebuie să fie actualizată pe măsură ce camionul se deplasează. Când ajunge factura transportatorului, numărul final trebuie să fie stabilit în raport cu estimarea inițială. Fiecare dintre acestea este o înregistrare separată într-un sistem conceput cu mult înainte ca cineva să își imagineze un agent AI care ține pixul.
Greșește asta și paguba este tăcută, dar reală. O comandă de transport duplicat umflă provizioanele. O rezervare care nu se sincronizează niciodată lasă o expediție în mișcare fără costuri asociate. Un status care nu se mai actualizează îl trimite pe un dispecer înapoi la apeluri de verificare manuală, ceea ce este exact munca pe care agentul ar fi trebuit să o elimine. Agentul pare impresionant în demonstrație și creează un backlog de reconciliere în producție.
Fluxul de referință, de la început până la sfârșit
Eliminați denumirile producătorilor și fiecare configurație funcțională urmează același drum. Agentul rulează în cadrul unui asistent precum Claude sau Copilot. Acesta apelează piața MCP pentru a obține o cotă de preț și apoi pentru a rezerva. Apelul de rezervare returnează un identificator de rezervare și un cost structurat. Agentul, sau un serviciu subțire din spatele acestuia, scrie apoi rezultatul respectiv în ERP sub forma unei înregistrări de transport, iar de aici înainte ERP-ul este sursa de adevăr, în timp ce piața îi furnizează actualizări.
- **Cotație și rezervare** prin intermediul pieței MCP. Răspunsul de rezervare transportă un ID de rezervare stabil și o defalcare a costurilor, nu doar un total.
- Creează înregistrarea de marfă în ERP, ștampilată cu acel ID de rezervare, astfel încât legătura să persiste.
- Status sincronizare pe măsură ce expedierea avansează, ideal din evenimente, mai degrabă decât dintr-o buclă de interogare care suprasolicită API-ul.
- Decontați costul când ajunge factura transportatorului, potrivind numărul final cu estimarea inițială.
ID-ul de rezervare este coloana vertebrală a întregului flux. Este valoarea care permite fiecărui pas ulterior să găsească înregistrarea căreia îi aparține și este valoarea care face ca o reîncercare să fie sigură, nu periculoasă.
Maparea unei rezervări de marfă pe modelul obiect ERP
Cele 3 sisteme pe care rulează majoritatea echipelor de transport expediabil efectuează aceeași rezervare în forme în mod vizibil diferite, deci cartografierea este locul unde planurile de integrare trăiesc sau mor. Trecerea de mai jos este cea pe care o oferim clienților atunci când aceștia întreabă ce câmp merge unde.
| Câmpul Marketplace | SAP TM | NetSuite / Oracle |
| ID rezervare | Număr comandă de expediere | Cheia pe Chitanța Articolului sau PO |
| Cost estimat | Cost estimat pe comanda de transport | Costul estimat la sosire |
| Factură transportator | Document de Decontare a Transportului | Costul real de achiziție prin Contabilitatea primirilor |
| Etape de status | Evenimente comandă de expediție | Recepție și stare de îndeplinire a articolelor |
Costul rareori ajunge ca 1 număr, așa că și detalierea se potrivește. Transportul principal și combustibilul sunt cunoscute la rezervare și postate ca fiind cheltuiala de transport estimată. Accesoriile, cum ar fi reținerea sau taxa de descărcare, apar de obicei doar pe factura transportatorului, astfel încât acestea ajung în Documentul de Decontare Marfă la decontare, mai degrabă decât în Comanda de Transport originală.
SAP Transportation Management
SAP TM modelează călătoria ca pe o comandă de transport, iar banii ca pe un document separat de decontare a transportului. Această separare este utilă, deoarece permite crearea înregistrării operaționale la momentul rezervării și postarea laturii financiare mai târziu, când factura este lichidată. Un agent care introduce date în SAP TM ar trebui să creeze comanda de transport la momentul rezervării și să lase decontarea pentru factura transportatorului, în loc să impună un cost final într-o înregistrare care nu are încă unul.
Oracle și NetSuite
Oracle și NetSuite se bazează pe ciclul de achiziție și recepție, unde transportul tinde să apară ca un cost de livrare, repartizat pe bunurile pe care le-a transportat. Aici, sarcina agentului este de a atașa rezervarea și costul acesteia la comanda de achiziție sau la nota de recepție corectă, astfel încât cheltuiala cu transportul să urmeze stocul, în loc să plutească ca o taxă orfană. Estimarea se înregistrează la rezervare, totalul actualizat la decontare, iar costul de livrare se recalculează de acolo.
Lecția comună tuturor celor trei este respectarea modelului în care scrieți. O rezervare pe piață este un singur obiect din partea noastră. Pe partea ERP devine 2 înregistrări, una operațională și una financiară, iar cele mai curate integrări păstrează aceste 2 elemente separate.
Idempotența: capcana care dublează rezervările
Rețelele eșuează în timpul unui apel. Un agent reîncearcă. Fără protecție, acea reîncercare creează o a doua comandă de expediere pentru o expediere care are deja una, iar acum acumulările dvs. sunt incorecte într-un mod pe care nimeni nu-l observă până la sfârșitul lunii. Idempotența este soluția și nu este opțională odată ce banii sunt implicați.
Modelul este simplu. Fiecare scriere care creează sau finalizează o înregistrare poartă o cheie de idempotență, iar ID-ul de rezervare este cel natural. Serviciul orientat spre ERP verifică dacă o înregistrare există deja pentru acea cheie înainte de a scrie. Dacă există, serviciul actualizează în loc să insereze, sau pur și simplu returnează înregistrarea existentă. O reîncercare devine astfel o operațiune sigură care nu face nimic în loc de una duplicat. Când expunem o rezervare prin MCP-ul nostru, returnăm un ID stabil exact din acest motiv, astfel încât back office-ul să aibă un punct de ancorare de încredere pentru a construi scrieri idempotente. Modelul presupune verificarea unei înregistrări existente, indexată după ID-ul de rezervare, înainte de scriere: dacă una există, o actualizează, altfel creează comanda de transport. Prima rulare creează, fiecare reîncercare după un timeout actualizează aceeași înregistrare, iar o rețea instabilă nu costă mai mult decât o căutare redundantă.
Identitate peste graniță
Un agent care acționează pe cont propriu nu este o persoană, iar ERP-ul dorește să știe cine a schimbat ce. Abordarea curată este o identitate de serviciu dedicată pentru integrare, limitată la puținele acțiuni pe care le efectuează efectiv, mai degrabă decât un agent care împrumută permisiunile extinse ale unui utilizator uman. Un cont de serviciu care poate crea comenzi de marfă și înregistra decontări, și nimic altceva, menține raza de acțiune restrânsă și fișa de audit corectă. Acesta este același mod de gândire, centrat pe scop și cu privilegii minime, din partea de securitate a acestei serii, aplicat și pe partea ERP a conexiunii.
Ce ar trebui să expună un MCP la piață pentru a face "write-back"-ul curat
Un server cu un singur transportator poate fi vag cu privire la obiectul său de rezervare, deoarece există o singură formă de învățat. Un server de marketplace nu poate, deoarece clientul face reconcilierea între mulți transportatori într-un singur registru. 3 lucruri fac diferența.
- Un ID de rezervare stabil care nu se schimbă pe durata de viață a expedierii, astfel încât înregistrarea ERP să rămână legată prin fiecare actualizare.
- O defalcare structurată a costurilor, nu un total unic, astfel încât transportul principal, combustibilul și accesoriile să poată fi mapate la conturile corecte, iar etapa de decontare să aibă ceva de reconciliat.
- Stare ca evenimente, astfel încât ERP-ul să afle despre un moment important atunci când acesta se întâmplă, în loc să verifice o modificare care s-ar putea să nu apară ore în șir.
Când acești trei sunt prezenți, rescrierea ERP este majoritar deterministică. Când lipsesc, fiecare client reconstruiește aceași legătură fragilă, iar rezervarea agentului devine o problemă de reconciliere deghizată convenabil.
O listă de verificare de referință înainte de a conecta un agent la registrul contabil
- Ancorați fiecare scriere ERP la ID-ul rezervării de pe piață și faceți ca acel ID să fie cheia de idempotență.
- Creează înregistrarea operațională la momentul rezervării și înregistrează decontarea financiară atunci când factura este achitată, nu înainte.
- Mapați defalcarea costurilor în conturi în mod deliberat, în loc să aruncați un total unic într-o singură linie.
- Starea de antrenare din evenimente, unde puteți, și reveniți la interogare doar cu un interval rezonabil.
- Oferiți integrării propria identitate de serviciu cu scop limitat, nu un login uman larg.
- Concilierea estimării cu valoarea reală la decontare și semnalarea discrepanței în loc să o suprascrieți în tăcere.
Nimic din toate acestea nu este unic agenților. Este disciplina de care orice integrare de transport de marfă sistem-la-sistem are deja nevoie. Agentul pur și simplu face rezervarea mai rapidă, ceea ce înseamnă că scrierea reciprocă trebuie să fie la fel de fiabilă pentru a ține pasul.
Întrebări frecvente
Poate un agent AI să introducă direct o rezervare de transport în SAP sau NetSuite?
Da, prin API-ul propriu al ERP-ului și o identitate de serviciu cu scop definit, cu ID-ul de rezervare al pieței utilizat ca cheie de idempotenta, astfel încât reîncercările să nu creeze duplicate. Agentul propune scrierea, dar un serviciu subțire ar trebui să o efectueze împotriva ERP-ului, astfel încât logica să rămână testabilă și permisiunile să rămână limitate.
Ce se defectează cel mai des la revenirea datelor în ERP?
Înregistrări duplicate din reîncercări neprotejate și costuri care nu se decontează niciodată deoarece integrarea postează o estimare și uită să o reconcilieze cu factura transportatorului. Ambele sunt rezolvate prin ancorarea scrierilor la un ID de rezervare stabil și prin menținerea separată a pașilor operaționali și financiari.
De ce contează atât de mult ID-ul de rezervare?
Este legătura dintre piață și registru. Fiecare actualizare de status, document și decontare își găsește înregistrarea prin intermediul acelui ID, iar acesta servește și ca cheie de idempotență care face ca o reîncercare să fie sigură. Un obiect de rezervare fără un ID stabil forțează back office-ul să ghicească, ceea ce duce la duplicate și costuri orfane.
Actualizările de stare ar trebui interogate (polled) sau împinse (pushed)?
Împins acolo unde piața suportă evenimente, deoarece interogările fie rămân în urma etapelor importante, fie suprasolicită API-ul pentru a fi la curent. O integrare pragmatică preia evenimente pentru momentele importante și utilizează un interval modest de interogare doar ca o soluție de rezervă.
Aceasta finalizează seria MCP în 4 părți, actualizată la zi în 2026. Dacă ați ajuns aici prima dată, începeți cu ghid de protocol, vedeți serverele livrate în demontare și securizați-o cu ghid de securitate.