Als een inkomende order-IDoc in SAP mislukt

Ja, om mislukte orders te vinden en te diagnosticeren, met één voorwaarde. De IDoc-status van SAP vertelt je of een inkomende order de applicatie heeft bereikt. Status 53 betekent dat het applicatiedocument is geboekt, status 51 dat het niet is geboekt, en de statusrecords bevatten de fouten die de applicatie heeft weggeschreven. Dat is een bruikbare controle. Het is nog geen uitzonderingsproces: iemand moet nog steeds elke 51 in bezit nemen, de oorzaak oplossen en beslissen over een resend. Dit steunt op de SAP-pagina “Testing Inbound Processing” en op de troubleshootinggids van Oracle voor de Siebel Connector for SAP R/3.

Orders die aankwamen maar nooit zijn geboekt

Je klant heeft de inkoopbon gestuurd. EDI of een middlewarelaag maakte er een inkomende IDoc van. De klant verwacht een bevestiging en de medewerker orderinvoer gaat ervan uit dat de verkooporder bestaat. Een mislukte order komt meestal aan het licht via een telefoontje van de klant, een gemiste leverdatum of een vestiging die vraagt waar de order is gebleven. Vaak gebeurt dat na een ERP-overgang, als partnerprofielen en mappings nog nieuw zijn; zie wat er na een ERP-livegang vaak misgaat. De SAP-pagina “Testing Inbound Processing” beschrijft hoe je de uitkomst controleert: gebruik de functie IDoc Display, lees de huidige status en klik op de statusrecords om de fouten te zien die de applicatie heeft weggeschreven.

Wat de statuscodes en statusrecords je vertellen

De SAP-pagina beschrijft dit in een testcontext, voor een uitgebreid of nieuw IDoc-type. Het voorbeeld gebruikt basistype ORDERS01 met de uitbreiding Z1ORDERS en berichttype ORDERS, en voert de afzender in als partnertype KU (klant) met partnerfunctie AG (SP). Als de applicatie het document heeft geaccepteerd, is de huidige status 53 (applicatiedocument geboekt). Anders is het 51 (applicatiedocument niet geboekt). De pagina zegt ook dat je moet controleren of de applicatie de IDoc-gegevens in de juiste tabellen heeft weggeschreven. Wij lezen dit zo: status 51 is het signaal, de statusrecords zijn de diagnose, en ook bij een 53 loont een steekproef tegen de verkooporder.

Waar het herstel en de resend plaatsvinden

De gids van Oracle voor de Siebel Connector for SAP R/3 behandelt IDocs tussen SAP en Siebel. Voor IDocs die vanuit Siebel naar SAP zijn gestuurd en niet worden verwerkt, staat dat er veel oorzaken kunnen zijn en dat je moet beginnen met het zoeken naar de IDoc in SAP met transactie WE02 of WE05. Staat de IDoc er niet, dan is het Sender Partner Number mogelijk niet gezet. Staat hij er wel, controleer dan het statusrecord op foutinformatie. In het deel over IDocs die van SAP naar Siebel gaan, zegt de gids dat specifieke applicatiefouten in het statusrecord binnen SAP gecorrigeerd moeten worden en dat de IDoc verwijderd of opnieuw verstuurd moet worden, en dat BD87 gebruikt kan worden voor handmatige resend. Die passage gaat over de uitgaande richting, dus wij zouden de herverwerkingsroute voor inkomende order-IDocs met je SAP-team bevestigen voordat je die in een procedure opneemt. Dat levert twee soorten fouten op: de IDoc kwam nooit aan, een kwestie van partner of interface, en de IDoc kwam aan met status 51, meestal een datakwestie zoals een afwijking in klant, materiaal of prijsstelling.

Wie is eigenaar van een mislukte order-IDoc?

De vraag is of status 51 en de statusrecords je uitzonderingen in de orderinvoer aansturen, of ze alleen starten.

Wat je dit kwartaal doet

• Haal alle inkomende order-IDocs met status 51 van de afgelopen 30 dagen op, gegroepeerd per afzenderpartner en foutmelding.
• Benoem één eigenaar voor ontbrekende IDocs en één voor status 51, en leg vast wie mag verwijderen of opnieuw versturen.
• Meet de tijd van het aanmaken van de IDoc tot de geboekte verkooporder, en van status 51 tot de resend.
• Neem een steekproef van IDocs met status 53 en controleer elk tegen een verkooporder met de juiste regels en prijzen.
• Bevestig met je SAP-team welke transactie jouw systeem gebruikt om inkomende IDocs opnieuw te verwerken, en wie die mag uitvoeren.

Wat dit betekent voor een knelpunt van $1M of meer

Als mislukte IDocs één symptoom zijn naast e-mailorders, inkoopbonnen als pdf, prijsuitzonderingen en substituties, dan is de orderdesk het domein dat je opnieuw ontwerpt, niet de interface. Los eerst de flow op en automatiseer dan wat overblijft: regels voor de voorspelbare stappen, zoals status 51 routeren op soort fout, AI voor het rommelige deel, zoals de foutmelding lezen naast de originele inkoopbon, en mensen die de ingrijpende beslissingen goedkeuren, zoals een prijsoverschrijving of een resend. AI beslist nooit alleen. Lees hoe wij uitzonderingen in orderinvoer aanpakken binnen het bredere domein offerte-tot-order.

Grenzen van dit bewijs

De SAP-pagina beschrijft het testen van inkomende verwerking voor nieuwe of uitgebreide IDoc-types, niet de dagelijkse monitoring in productie. De gids van Oracle is geschreven voor de Siebel Connector for SAP R/3, en de resendrichtlijn staat in de richting van SAP naar Siebel. Geen van beide documenten laat zien hoe vaak inkomende order-IDocs mislukken of wat mislukkingen kosten aan vertraagde orders of tijd van klantenservice. Geen van beide laat zien hoe jouw eigen SAP-release of interfaceopzet zich gedraagt, en geen van beide biedt benchmarks voor oplostijd.