> B2B rendelésrögzítés automatizálása e-mailből LLM-mel: megbízható postafiók, tételkinyerés, szabályok kódban, idempotencia és GDPR.
>
> Web page: https://balazscsorba.com/hu/blog/b2b-email-order-entry-llm · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/b2b-email-order-entry-llm.md) · [Deutsch](https://balazscsorba.com/de/blog/b2b-email-order-entry-llm.md)
> Author: Balázs Csorba · Published: 2026-10-14 · Keywords: email order entry automation, sales order automation, automate order entry from email, AI order processing ERP, order desk automation, PDF order to ERP, sales order automation ROI, order entry error rate, touchless order processing, order validation rules ERP

[Blog](https://balazscsorba.com/hu/blog)/Webfejlesztés

# E-mailes rendelésrögzítés automatizálása: e-mailből ERP-rendelés

B2B rendelésrögzítés automatizálása e-mailből LLM-mel: megbízható postafiók, tételkinyerés, szabályok kódban, idempotencia és GDPR.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. október 14.·9 perc olvasás

-   Order entry
-   ERP
-   Document AI
-   Idempotency
-   GDPR

![Borítékokból rendezett sorok lesznek egy írótáblán, amely egy dobozra mutat.](https://balazscsorba.com/images/blog/b2b-email-order-entry-llm/cover.webp?v=ca0b45ff5b)

## A lényeg röviden

-   Az e-mailes rendelésrögzítés automatizálásánál a modell soha nem ír az ERP-be; típusos rendelést javasol, amelynek ugyanazokon az ellenőrzéseken kell átmennie, mint egy kézzel rögzítettnek.
-   Rendelés csak akkor jön létre automatikusan, ha minden tétel minden szabálynak megfelel; minden más a hibás szabály megnevezésével kivételsorba kerül.
-   A Microsoft Graph egy webhook-értesítést csak 3 másodpercen belüli 2xx válasz után tekint kézbesítettnek, ezért előbb írja sorba és válaszoljon 202-vel, csak utána dolgozzon.
-   Az ERP-létrehozó hívás idempotenciakulcsa és a tételszintű ujjlenyomat megakadályozza a duplikált vevői rendelést, a rendelésautomatizálás tipikus incidensét.
-   A B2B rendelési e-mailek is tartalmaznak megnevezett munkatársak személyes adatait, ezért a jogalapról, a nyers levél megőrzéséről és az adatfeldolgozói szerződésekről előre dönteni kell.

Ezen az oldalon

1.  [Mit automatizáljunk, és mi marad emberi?](https://balazscsorba.com/#what-to-automate-and-what-to-keep-human)
2.  [A folyamat a postafióktól az ERP-ig](https://balazscsorba.com/#the-pipeline-from-mailbox-to-erp)
3.  [Hogyan figyelhető megbízhatóan a postafiók?](https://balazscsorba.com/#listening-to-the-mailbox-reliably)
4.  [Hogyan nyerhetők ki a rendelési tételek egy e-mailből?](https://balazscsorba.com/#extracting-order-lines-not-documents)
5.  [Mely ellenőrzési szabályok döntenek a rendelés létrehozásáról?](https://balazscsorba.com/#validation-rules-as-code)
6.  [Hogyan előzhetők meg a duplikált ERP-rendelések?](https://balazscsorba.com/#idempotency-and-audit-trails)
7.  [Mit követel meg a GDPR a rendelési e-maileknél?](https://balazscsorba.com/#gdpr-practicalities-for-order-emails)
8.  [Mennyit ér az e-mailes rendelésautomatizálás?](https://balazscsorba.com/#what-it-is-worth)
9.  [Mikor ne automatizálja az e-mailes rendelésrögzítést?](https://balazscsorba.com/#change-management-and-when-not-to-use-it)
10.  [Ellenőrzőlista egy e-mailes rendelésrögzítési pilothoz](https://balazscsorba.com/#order-entry-checklist)
11.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

Az **e-mailes rendelésrögzítés automatizálása** az e-mailben, PDF-ként, táblázatként vagy az üzenet szövegében érkező megrendelésekből vevői rendelést hoz létre az ERP-ben. Egy dokumentummodell vagy LLM beolvassa a rendelést és strukturált tételeket javasol; determinisztikus kód ellenőrzi őket szerződések, árak, készlet és korábbi rendelések alapján; a rendelés pedig csak akkor jön létre, ha minden ellenőrzés sikeres. Minden más egy ember elé kerül.

Ez a cikk azt tárgyalja, mi történik az ERP-be írás előtt: a postafiók megbízható figyelése, tételek kinyerése dokumentumok helyett, ellenőrzési szabályok kódban, idempotencia és audit nyomvonal, GDPR a rendelési levelekhez, az üzleti indoklás, és a rendelésfelvevő csapat mint valódi felhasználó. Ha nem a rendelések, hanem az ajánlatok jelentik a szűk keresztmetszetet, olvassa el az [ajánlatkérések automatizálása LLM-mel](https://balazscsorba.com/hu/blog/llm-rfq-quote-automation) című cikket, amely ugyanazt a kinyerési réteget használja.

## Mit automatizáljunk, és mi marad emberi?

Automatizálja a fogadást, a kinyerést és az ellenőrzést; az ERP-rendelés létrehozásáról determinisztikus szabályok döntsenek, és minden kivétel maradjon emberé. A szabály, amelyre a tervezés épül: a modell soha nem ír az ERP-be. Típusos rendelést javasol, amelynek ugyanazokon az ellenőrzéseken kell átmennie, mint a rendelésfelvevők által begépelt rendelésnek.

A rendelések kevésbé elnézőek, mint az ajánlatok. Egy hibás ajánlat javítható, mielőtt az ügyfél elfogadja; egy duplikált vagy rossz mennyiségű rendelés azonnal készletet mozgat, számlát indít és bizalmat rombol. Ezért automatikus létrehozás csak akkor megengedett, ha minden tétel minden szabályon átment, a részleges bizalom sosem elég. A B2B kereskedelmi rendszerekkel szerzett tapasztalatom szerint a rendelés létrehozása a könnyű rész. A nehéz az, hogy az ügyfél levele az egyetlen nyoma annak, amit szerinte megrendelt, ezért a kinyerési bizonyítékok és a kivételsor fontosabbak a modellnél.

## A folyamat a postafióktól az ERP-ig

A folyamatnak egyetlen útja van az ERP-be, egy ellenőrző kapun át, és egyetlen kerülőútja hiba esetén: egy ember, aki a javított rendelést ugyanazon a kapun küldi vissza. Sürgős rendelésekre sincs megkerülő út, mert éppen ott keletkeznek a duplikátumok.

![E-mailes rendelési folyamat ellenőrző kapuval Az e-mail Microsoft Graph vagy IMAP útján érkezik, és bármilyen feldolgozás előtt sorba kerül. A kinyerés típusos rendelési tételeket készít belőle. Kódban írt szabályokból álló ellenőrző kapu dönt: ha minden tétel érvényes, egy ERP-író idempotenciakulccsal létrehozza a vevői rendelést, és visszaigazolás megy az ügyfélnek; ha bármely szabály sérül, a rendelés a hibás szabály megnevezésével kivételsorba kerül, egy ember javítja, majd ugyanahhoz az ellenőrző kapuhoz tér vissza. Megkerülő út nincs.](https://balazscsorba.com/images/blog/b2b-email-order-entry-llm/diagram-7.webp?v=8658353023)

A postafióktól az ERP-ig tartó folyamat: az ellenőrző kapu az egyetlen út az ERP-be, és a javított kivételek ugyanezen a kapun mennek át újra.

Minden szakasz eltárolja a saját eredményét: a nyers üzenetet, a javasolt rendelést, a szabályok eredményét, az ERP bizonylatszámát és a visszaigazolást. Minden, ami a létrehozó hívás után jön, például az outbox, az ERP API-val szembeni újrapróbálkozás és az éjszakai egyeztetés, rendszerek közötti szinkronizáció, és a webshop meglévő rendelési integrációját kell használnia.

## Hogyan figyelhető megbízhatóan a postafiók?

A Microsoft 365-ben, amelyet a legtöbb osztrák és német B2B cég használ, iratkozzon fel a Graph változásértesítéseire, ellenőrizzen mindegyiket, írja sorba és válaszoljon azonnal. Egy értesítés csak akkor számít kézbesítettnek, ha a végpont 3 másodpercen belül 2xx választ ad; különben a Graph legfeljebb 4 órán át próbálkozik újra ([Microsoft Learn](https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks)).

```
// Graph change-notification endpoint (sketch): validate, persist, answer fast
app.post('/graph/notifications', async (req, res) => {
  if (req.query.validationToken)                                   // subscription handshake
    return res.type('text/plain').send(String(req.query.validationToken))

  for (const n of req.body.value ?? []) {
    if (n.clientState !== process.env.GRAPH_CLIENT_STATE) continue  // ignore forged notifications
    await queue.send({ subscriptionId: n.subscriptionId, resource: n.resource })
  }
  res.sendStatus(202)                // fetch, parse and extract later, from the queue worker
})
```

Ugyanez az oldal leírja a fontos hibamódokat. Ha 10 percen belül a válaszok több mint 10%-a túllépi a 3 másodpercet, a végpont lassúnak minősül, és az új értesítések 10 perccel késnek. Ha több mint 15% túllépi a 10 másodperces ablakot, „drop” jelölést kap, az értesítéseket 10 percig eldobják, és az eldobott értesítések nem állíthatók helyre. Ezért nem végez a kezelő semmilyen elemzést. Kis forgalomnál egy külön IMAP-mappa időzített lekérdezése is elfogadható. A postafiókbeli másolat mindkét esetben megszűnik hiteles forrás lenni, amint a rendelést kinyerték és naplózták.

## Hogyan nyerhetők ki a rendelési tételek egy e-mailből?

A tételeket szigorú sémába nyerje ki, minden értelmezett érték mellett tartsa meg a nyers szöveget, a mértékegység-átváltást pedig kódban végezze. A tételenkénti kinyerés más feladat, mint egy dokumentum összefoglalása: az olyan mennyiségeknek, mint a „2 Karton à 12 Stk.”, az ügyfél saját cikkszámainak, a szállítási dátumra utaló kifejezéseknek és a korábbi rendelésre utaló „wie letztes Mal” hivatkozásoknak mind olyan mezőkbe kell eljutniuk, amelyeket egy szabály ellenőrizni tud.

```
{
  "orderReference": "PO-88213",
  "lines": [
    {
      "position": "10",
      "customerPartNo": "4711-22",
      "supplierPartNo": null,
      "description": "Rillenkugellager 6204 2RS",
      "quantityRaw": "2 Karton à 12 Stk.",
      "quantity": 2,
      "unitRaw": "Karton à 12",
      "requestedDate": "2026-10-28",
      "source": { "page": 1, "bbox": [72, 310, 520, 326] }
    }
  ],
  "referencesPreviousOrder": false
}
// code, not the model, converts "2 Karton à 12" into 24 pieces (UN/ECE Rec 20 code H87)
```

A strukturált kimenet a formát garantálja, nem az üzleti érvényességet. Az Azure OpenAI szigorú módja például minden mezőt kötelezőnek ír elő, így az ismeretlen értékek nullázható uniókká válnak, és nem támogatja a `minimum`, `pattern` vagy `format` kulcsszót ([Microsoft Learn](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/structured-outputs)). A tartományok, a mértékegységkódok, például az UN/ECE 20. ajánlás szerintiek, amelyeket a Peppol rendelési kódlistái is használnak ([Peppol BIS](https://docs.peppol.eu/poacc/upgrade-3/)), és a dátumablakok ezért kódba kerülnek. Minden mezőhöz csatolja az oldalt és a befoglaló keretet az ellenőrző nézethez; a Mistral OCR 4.1 2026 októberében 1000 oldalanként 4 dollárért ad bekezdésszintű kereteket és blokkszintű bizalmi értéket ([Mistral](https://docs.mistral.ai/models/ocr-4-1)). Magát az elemzési réteget az [Unstructured dokumentumfeldolgozáshoz](https://balazscsorba.com/hu/blog/unstructured) című cikk tárgyalja.

## Mely ellenőrzési szabályok döntenek a rendelés létrehozásáról?

Olyan szabályok, amelyek a nyilvántartó rendszerből olvasnak és kódban futnak. Rendelésenként csak két kimenet van: minden tétel érvényes, akkor létrehozás; bármi más, akkor kivételsor a hibás szabály megnevezésével. A modell egyes szabályokhoz értéket javasolhat, de egyikről sem dönt.

Szabály

Hiteles forrás

Az LLM szerepe

Determinisztikus ellenőrzés

Hiba esetén

Ismert ügyfél

ERP, CRM

nincs

küldő domain és szerződés, nem csak a From fejléc

kivétel

Megállapodott ár

árazás, ERP

kiolvassa a rendelésen szereplő árat

van szerződéses ár és egyezik

kivétel

Cikkpárosítás

ERP, kereszthivatkozás

jelölteket javasol

csak pontos azonosító vagy ismert kereszthivatkozás

kivétel

Mennyiség és egység

cikktörzs

nyers szöveget nyer ki

átváltás, minimum és lépcső

kivétel

Elérhetőség

ERP, ATP

nincs

szállítható a részszállítási szabály szerint

kivétel vagy részszállítás visszaigazolása

Szállítási dátum

ERP, naptár

értelmezi a kifejezést

a dátum teljesíthető és jövőbeli

kivétel

Duplikátum

rendelésnapló

jelzi a „wie letztes Mal” utalást

azonos ügyfél és tétel-ujjlenyomat egy időablakon belül

kivétel, soha nem automatikus

A szabályokat az ERP valódi mezőire írja, minimális rendelési mennyiség, csomagolási egység, szállíthatósági ellenőrzés és szállítási ütemterv, és verziózza őket. A szabály verziója minden döntéssel együtt az audit naplóba kerül, így egy módosított szabály visszakövethető azokhoz a rendelésekhez, amelyeket átengedett.

## Hogyan előzhetők meg a duplikált ERP-rendelések?

Vigyen végig egy idempotenciakulcsot a létrehozó híváson, és tartson ügyfelenkénti tételszintű ujjlenyomatot. A duplikált vevői rendelés a rendelésautomatizálás tipikus incidense: egy újrapróbált webhook, egy újraindult worker, vagy egy ügyfél, aki ugyanazt a PDF-et „bitte bestätigen” megjegyzéssel újra elküldi.

A Stripe API jó referencia a kulcs szemantikájához: a kliens által generált, legfeljebb 255 karakteres kulcs, újrapróbálkozáskor az első kérés elmentett válasza, hiba, ha a paraméterek eltérnek az eredeti kéréstől, és a kulcsok legalább 24 óra után törölhetők ([Stripe](https://docs.stripe.com/api/idempotent_requests)). A kulcsot az üzenetazonosítóból és a melléklet hash-éből képezze, soha ne személyes adatból. A kulcs a technikai újrapróbálkozásokat fogja meg; az ügyfélből és a tételek halmazából képzett, időablakon belüli ujjlenyomat pedig az üzleti duplikátumot, vagyis a kétszer elküldött rendelést.

![Egy rendelés csak bővíthető eseménynaplója Öt esemény balról jobbra, mindegyik hozzáfűzve és soha nem módosítva: a beérkezett üzenet az üzenetazonosítóval és a melléklet hash-ével; a kinyerésből származó javasolt rendelés; a lefuttatott ellenőrzések a szabályverziókkal; a létrehozott vevői rendelés az ERP-számmal és az idempotenciakulccsal; végül az ügyfélnek elküldött visszaigazolás.](https://balazscsorba.com/images/blog/b2b-email-order-entry-llm/diagram-24.webp?v=2af5762805)

Az audit nyomvonal: rendelésenként öt csak hozzáfűzhető esemény, így minden ERP vevői rendelés visszakövethető a pontos e-mailig és azokig a szabályverziókig, amelyek átengedték.

## Mit követel meg a GDPR a rendelési e-maileknél?

A GDPR B2B-ben is érvényes. A (14) preambulumbekezdés kizárja a jogi személyekre vonatkozó adatokat, például a cégnevet és a cég elérhetőségeit, de egy megnevezett munkatárs aláírással és közvetlen telefonszámmal küldött rendelési levele továbbra is személyes adat ([GDPR, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679)).

-   **Jogalap:** a 6. cikk (1) b), a szerződés teljesítése, lefedi a rendelés feldolgozását; a visszaélés- és csalásellenőrzés a 6. cikk (1) f) szerinti jogos érdeken alapul.
-   **Adatfeldolgozók:** az útvonal minden OCR- vagy modellszolgáltatójával a 28. cikk szerinti adatfeldolgozói szerződés kell, a folyamatnak pedig a 32. cikk szerinti megfelelő biztonság.
-   **Adattakarékosság:** a modellnek a rendelési dokumentumot küldje, ne a teljes levélláncot aláírásokkal és előzményekkel; a [személyes adatok kitakarása LLM-folyamatokban](https://balazscsorba.com/hu/blog/pii-redaction-llm-pipelines) a technikákat mutatja be.
-   **Korlátozott tárolhatóság:** az 5. cikk (1) e) szerint, amint a rendelés az ERP-ben van, a nyers levélnek meghatározott megőrzési idő és archiválási vagy törlési lépés kell.

**Ellenőrizze a megőrzést, mielőtt törlést ígér**

Ne ígérje meg, hogy a postafiókbeli másolat feldolgozás után törlődik, amíg nem ellenőrizte a tenant saját megőrzési beállításait. A Microsoft 365 megőrzési szabályai a felhasználótól vagy a folyamattól függetlenül is megtarthatják a leveleket, így az ígéret az ügyfél konfigurációján múlik, nem az Ön kódján.

Egy rendelésrögzítő asszisztens nem szerepel az EU AI Act III. mellékletének nagy kockázatú listáján; kezelje belső termelékenységi eszközként, és ne állítson olyan megfelelőségi státuszt, amelyet nem ellenőrzött.

## Mennyit ér az e-mailes rendelésautomatizálás?

Annyit ér, amennyi rögzítési percet megtakarít, amennyi hó végi csúcsot elnyel és amennyi hibás rendelést megállít, és egyikre sincs publikált B2B viszonyszám. A cikkhez nem sikerült nyilvános, e-mailes rendelésenkénti költséget vagy hibaarányt ellenőrizni, ezért az indoklás képletekből és a rendelésfelvevő csapat saját alapértékéből épül fel.

-   **Munkaidő:** a tételenkénti költség a rögzítési perc szorozva a teljes bérköltséggel, szemben a tételenkénti ellenőrzési perccel szorozva a bérrel, plusz a dokumentumonkénti kinyerési költséggel. Viszonyítási pontként az O\*NET az amerikai rendelésfeldolgozók 2025-ös medián bérét óránként 22,20 dollárban adja meg, ami rezsi nélkül percenként nagyjából 0,37 dollár; 78 900 foglalkoztatott, akiknek feladata a rendelési adatok és a készlet ellenőrzése is ([O\*NET](https://www.onetonline.org/link/summary/43-4151.00)).
-   **Kinyerési költség:** ehhez képest kicsi; 2026 októberében az Amazon Textract szövegre oldalanként 0,0015, táblázatokkal 0,015 dollárt kér ([AWS](https://aws.amazon.com/textract/pricing/)), a Google Document AI OCR pedig 1000 oldalanként 1,50 dollárt ([Google Cloud](https://cloud.google.com/document-ai/pricing)).
-   **Hibás rendelések:** jóváírás, pótszállítás, oda-vissza fuvar és az ügyfél saját következményköltsége. Nevezze meg ezeket az elemeket és mérje őket a pilotban, ahelyett hogy iparági számot idézne.
-   **Csúcsok:** a felvétel nélküli kapacitás hó végén a hátralék életkorában és a kivételek túlcsordulásában látszik, nem megtakarított létszámban.

Az olyan szállítók, mint a Conexiom, nagy léptékben hirdetik ezt a folyamatot, évi több mint 1,5 milliárd tételt és 40-nél több ERP-integrációt állítva ([Conexiom](https://conexiom.com/)); ezt annak piaci bizonyítékaként kezelje, hogy a probléma valós, ne viszonyszámként. A döntéshozó, jellemzően operatív igazgató, ügyfélszolgálati vezető vagy order-to-cash felelős, az „e-mailes rendelésrögzítés automatizálása” kifejezésre keres, és az ígéret a kézi beavatkozás arányának csökkenése a csapat saját számain mérve, soha nem létszámleépítés.

## Mikor ne automatizálja az e-mailes rendelésrögzítést?

Ne automatizáljon, ha a rendelésszám nem indokol egy kivételsort, ha a szerződéses árak elérhetetlenek, ha az ügyfelek már EDI- vagy Peppol-rendelést küldenek, ilyenkor a csatornát javítsa PDF-elemzés helyett, vagy ha a jogi osztály nem fogad el LLM-et az ügyféldokumentumok útjában; ekkor determinisztikus sablonok és önmagában az OCR a tartalék megoldás.

A rendelésfelvevő csapat egyszerre felhasználó, ellenőr és változási kockázat. Induljon a „az AI fogalmaz, ember küld” elvvel, tegye közzé a kézi beavatkozás arányát, legyen a javítás egy kattintás, és minden javítást kezeljen olyan értékként, amely javítja a párosítást. Ahol használatot vagy személyenkénti teljesítményt naplóz, vonja be korán az üzemi tanácsot; az [AI-eszközök és az üzemi tanács](https://balazscsorba.com/hu/blog/works-council-ai-tools-austria-germany) az osztrák és német keretet mutatja be.

## Ellenőrzőlista egy e-mailes rendelésrögzítési pilothoz

1.  Állítson össze referenciakészletet két-négy hét valódi, anonimizált postafiók-előzményből.
2.  A kinyerés pontosságát mezőnként mérje, ne dokumentumonként.
3.  Nézze meg, mely szabályok buknak el leggyakrabban, és javítsa a mögöttük lévő adatokat.
4.  Küldje el kétszer ugyanazt a rendelést, és pontosan egy vevői rendelést várjon.
5.  Futtasson végponttól végpontig tartó tesztet az egyetlen hiteles ERP-írón keresztül; én Playwright MCP-vel vezérelném egy tesztlevéltől a létrejött rendelésig.
6.  Egyeztessen a rendelésfelvevő csapattal a kivételsor válaszidejéről.
7.  Írja le és érvényesítse a nyers levelek megőrzési szabályát.
8.  Rögzítse a kinyerési modell verzióját, és minden változáskor futtassa újra a referenciakészletet.

Egy rögzített hatókörű pilot néhány hétnyi valódi postafiók-előzményen, kinyerési riporttal, működő kivételsorral és egy ERP tesztkliensen validált létrehozási úttal, jól körülhatárolt projekt. Ha ilyet tervez, a [B2B e-kereskedelmi munkám](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer) lefedi azt az ERP- és katalógusoldalt, amelyen múlik.

## Források

1.  [Microsoft Learn: Receive change notifications through webhooks (Microsoft Graph)](https://learn.microsoft.com/en-us/graph/change-notifications-delivery-webhooks)
2.  [Microsoft Learn: Azure OpenAI structured outputs](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/structured-outputs)
3.  [Stripe API reference: Idempotent requests](https://docs.stripe.com/api/idempotent_requests)
4.  [Regulation (EU) 2016/679 (GDPR), EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679)
5.  [Peppol BIS Upgrade 3: ordering profiles and code lists](https://docs.peppol.eu/poacc/upgrade-3/)
6.  [O\*NET OnLine: Order Clerks (43-4151.00)](https://www.onetonline.org/link/summary/43-4151.00)
7.  [Amazon Textract pricing](https://aws.amazon.com/textract/pricing/)
8.  [Google Cloud: Document AI pricing](https://cloud.google.com/document-ai/pricing)
9.  [Mistral AI: OCR 4.1 model card](https://docs.mistral.ai/models/ocr-4-1)
10.  [Conexiom: sales order automation (vendor)](https://conexiom.com/)

## Gyakori kérdések

Mi az e-mailes rendelésrögzítés automatizálása?

Olyan folyamat, amely beolvassa az e-mailben érkező megrendeléseket, dokumentummodellel vagy LLM-mel kinyeri a tételeket, ellenőrzi őket szerződések, árak, készlet és duplikátumok szerint, és csak akkor hozza létre a vevői rendelést az ERP-ben, ha minden szabály teljesül. Minden más egy ember elé kerül a kivételsorban.

Létrehozhat-e egy LLM közvetlenül vevői rendelést az ERP-ben?

Nem kellene. A modell javasoljon strukturált rendelést, és determinisztikus kód döntse el, létrejöhet-e, azon az egy integrációs úton, amely az idempotenciát és az audit naplózást is kezeli. Ugyanazok az ellenőrzések érvényesek, mint egy rendelésfelvevő által begépelt rendelésnél.

Hogyan előzhetők meg a duplikált rendelések az e-mail-automatizálásnál?

Idempotenciakulccsal az ERP-létrehozó hívásban, amely az üzenetből és a tartalomból képződik, valamint egy ügyfelenkénti, időablakon belüli tételszintű ujjlenyomattal, amely felismeri a különböző utakon kétszer elküldött rendelést. Úgy tesztelje, hogy ugyanazt a levelet kétszer elküldi, és pontosan egy vevői rendelést vár.

Megengedett-e a GDPR szerint a rendelési e-mailek AI-alapú feldolgozása?

Igen, körültekintéssel. A megnevezett munkatársaktól érkező rendelési levelek B2B-ben is személyes adatok. A rendeléshez kapcsolódó feldolgozás a szerződés teljesítésén alapul, a szolgáltatókkal adatfeldolgozói szerződés kell, a promptok csak a rendelés tartalmát tartalmazzák, a nyers levélnek pedig meghatározott megőrzési idő kell, amelyet a saját tenant megőrzési beállításaival is összevetett.

Mennyit takarít meg az e-mailes rendelésautomatizálás?

Nem találtunk ellenőrzött publikált viszonyszámot az e-mailes rendelésenkénti költségre. Számolja ki a saját adataiból: tételenkénti rögzítési perc szorozva a teljes bérköltséggel, szemben a tételenkénti ellenőrzési perccel és a dokumentumonkénti kinyerési költséggel. Az amerikai rendelésfeldolgozók medián bére 2025-ben óránként 22,20 dollár volt, rezsi nélkül percenként nagyjából 0,37 dollár.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[B2B e-kereskedelem és PIM →](https://balazscsorba.com/hu/expertise/b2b-ecommerce-developer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Schema.org strukturált adatok B2B webshopokhoz: bejelentkezés mögötti árak, egységek és változatok](https://balazscsorba.com/hu/blog/schema-org-structured-data-b2b-shop)
-   [AI-asszisztens a B2B webshop ügyfélszolgálatához: eszközök, jogosultságok és átadás embernek](https://balazscsorba.com/hu/blog/ai-assistant-b2b-shop-customer-support)
-   [AI-csevegő UI Vue-ban és Nuxtban: akadálymentes streaming](https://balazscsorba.com/hu/blog/vue-ai-chat-ui-streaming-accessibility)
-   [LLM-fordítási pipeline i18n-hez: glosszárium, helyőrzők és review](https://balazscsorba.com/hu/blog/llm-translation-pipeline-i18n)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)