SAP IDOC-vejledning i ABAP: Trin-for-trin-guide

⚡ Smart opsummering

SAP IDoc (Intermediate Document) er en standardiseret datacontainer, der flytter forretningsinformation mellem SAP og ikke-SAP systemer via ALE og EDI. Denne vejledning forklarer dens definition, struktur, typer, tabeller, partnerprofiler, porte og de komplette udgående og indgående processer.

  • 📦 Kernedefinition: IDoc er en systemneutral datacontainer baseret på EDI-standarder som ANSI ASC X12 og EDIFACT.
  • 🧱 Tredelt struktur: Hvert IDoc består af en kontrolpost, dataposter og statusposter, der hver især er gemt i dedikerede databasetabeller.
  • 🆚 Typehierarki: Grundlæggende IDoc-typer leveres med SAP og kan ikke ændres; Udvidelsestyper tilføjer brugerdefinerede felter efter behov.
  • 🔁 Procesflows: Outbound opretter og sender IDocs; Inbound modtager og posterer dem via linkede funktionsmoduler.
  • 🤖 AI-aktivering: AI-drevne overvågningsværktøjer registrerer IDoc-fejl tidligt og kortlægger automatisk marker på tværs SAP og ikke-SAP partnere.

SAP IDOC-vejledning

Hvad er et IDoc?

IDoc er blot en databeholder bruges til at udveksle information mellem to vilkårlige processer, der kan forstå dataens syntaks og semantik.

Med andre ord er et IDoc som en datafil med et bestemt format, der udveksles mellem to systemer, der ved, hvordan de skal fortolke disse data.

IDoc står for "Mellemdokument".

Når du udfører en udgående I ALE- eller EDI-processen oprettes et IDoc. I SAP Systemkrav, IDoc'er gemmes i databasen, og hvert IDoc har en unikt nummer inden for en klient.

Nøglefunktioner

  • ID-dokumenter er uafhængig af sende- og modtagesystemer (SAP-til-SAP såvel som ikke-SAP).
  • IDocs er baseret på EDI standarder, ANSI ASC X12 og EDIFACT. I tilfælde af konflikt i datastørrelsen vælger IDoc den med den største længde.
  • ID-dokumenter er uafhængig af retningen for dataudvekslingen, f.eks. understøtter ORDERS01 i indkøbsmodulet både indgående og udgående.
  • IDocs kan ses i en teksteditor fordi dataene er gemt i tegnformat i stedet for binært format.

Strukturen af ​​et IDoc

Strukturen af ​​et IDoc

IDoc-strukturen består af tre dele:

  1. Administrationsdelen (Kontrolrapport) — indeholder IDoc-typen, beskedtype, aktuel status, afsender, modtager og lignende metadata. Dette kaldes kontrolposten.
  2. Applikationsdataene (Data Record) — indeholder forretningsdataene. Disse kaldes dataposter eller segmenter.
  3. Statusoplysningerne (statuspost) — giver information om de forskellige faser, som IDoc har gennemgået.

Du kan se et IDoc ved hjælp af transaktion WE02 or WE05.

IDoc-post, der viser kontrol, data og status

Som det ses på skærmbilledet ovenfor, har IDoc-posten tre dele — Kontrol, Data og Status. Hver del gennemgås detaljeret nedenfor.

Kontrol rekord

  • Alle kontrolpostdata gemmes i EDIDC tabel. Nøglen til denne tabel er IDoc-nummeret.
  • Den indeholder oplysninger som IDoc-nummer, retning (indgående/udgående), afsender, modtageroplysninger, kanal i brug og port i brug.
  • Retning "1" angiver udgående og "2" angiver indgående.

Dataregistrering

  • Dataposten indeholder applikationsdata såsom medarbejderheaderoplysninger, ugentlige detaljer, klientoplysninger osv.
  • Alle datapostdata gemmes i tabeller EDID2 til EDID4og EDIDD er en struktur, hvor du kan se dens komponenter.
  • Den indeholder data som IDoc-nummeret, navnet og nummeret på segmentet i IDoc'en, hierarkiet og selve dataene.
  • Den faktiske nyttelast gemmes som en streng i et felt kaldet SDATA, som er et felt på 1000 tegn.

Status Record

  • En statuspost vedhæftes et IDoc ved hver milepæl eller når den støder på en fejl.
  • Alle statusoptagelsesdata gemmes i EDIDS tabel.
  • Status 1-42 er for udgående, mens 50-75 er for indgående.

IDoc-typer

En IDoc-type (grundlæggende) definerer strukturen og formatet for det forretningsdokument, der skal udveksles. En IDoc er en instans af en IDoc-type, ligesom konceptet med variabler og variabeltyper i programmeringssprogIDoc-typer kan defineres ved hjælp af transaktioner WE30.

Hvad er et segment?

Et segment definerer formatet og strukturen af ​​en Dataregistrering i et IDoc. Segmenter er genbrugelige komponenter.

For hvert segment, SAP opretter følgende komponenter.

  • Segmenttype (versionsuafhængig)
  • Segmentdefinition (versionsafhængig)
  • Segmentdokumentation

De sidste tre tegn repræsenterer segmentets version. Definitioner kan ændres, efterhånden som versionen ændres, men segmenttypen forbliver den samme. Transaktion: WE31.

Segment i IDoc

Hvad er en udvidelses-IDoc-type?

Et IDoc findes i to typer:

  1. Grundlæggende
  2. Extension

Grundlæggende og udvidede IDoc-typer

SAP tilbyder mange foruddefinerede grundlæggende IDoc-typer, som kan ikke ændresHvis du har brug for at tilføje flere data til en begrænset basistype, kan du bruge en udvidelsestype. Det meste af tiden vil du ikke har brug for udvidelser.

Illustration af udvidelses-IDoc-type

Dokumentation

Hvert IDoc er grundigt dokumenteret i transaktionen WE60.

IDoc-dokumentation i WE60

Meddelelsestype

En besked repræsenterer en bestemt type dokument, der er transmitmellem to partnere, for eksempel ordrer, ordresvar og fakturaer.

En IDoc-type kan være knyttet til mange meddelelsestyper. Omvendt kan en meddelelsestype være knyttet til forskellige IDoc-typer. Transaktion: WE81.

Beskedtype i IDoc

IDoc-visninger

En IDoc-type kan bruges til mere end én meddelelsestype, hvilket resulterer i, at IDoc'er indeholder flere felter end nødvendigt for en bestemt meddelelsestype.

IDoc-visninger forbedrer ydeevnen ved generering af IDocs ved at sikre, at kun de relevante segmenter er udfyldt med data. IDoc-visninger er kun vigtige for udgående behandling.

IDoc-visninger

Partnerprofiler

En partner er en forretningspartner, som du driver forretning med og udveksler dokumenter med.

I partnerprofilen for en partner, som der udveksles IDocs med, vedligeholder du de parametre, der er nødvendige for at udveksle dataene. Den anvendte transaktion er WE20.

Partnerprofiler i IDoc

port

Porten definerer de tekniske egenskaber ved forbindelsen mellem din SAP system og det andet system, du vil overføre data med (undersystem). Porten definerer det medie, hvor data udveksles mellem de to systemer.

Der findes forskellige typer porte. De to mest almindeligt anvendte er TRFC-porte brugt i ALE og Filporte brugt af EDI.

For TRFC-porte skal du angive navnet på den logiske destination, der er oprettet ved hjælp af SM59Når du bruger en filport, kan du angive den mappe, hvor IDoc-filen skal placeres. Det andet system eller middleware henter derefter filen derfra. Et funktionsmodul kan bruges til at generere et filnavn til IDoc'en. Mens test, kan du bruge "Udgående fil" til at angive et konstant filnavn. Fanen "udgående trigger" kan bruges til at levere information, hvis du vil udløse en behandling på undersystemet, når et IDoc oprettes på denne placering. Angiv kommandofilnavnet og den mappe, der skal køres.

Port i IDoc

Fælles IDoc-transaktion Codes

transaktion Code Formål
WE02 / WE05 Vis og overvåg IDocs
WE30 Opret eller skift IDoc-type
WE31 Opret eller rediger segment
WE20 Vedligehold partnerprofil
WE21 Vedligehold havne
WE42 Definer indgående proces Code
WE57 Tildel indgående funktionsmodul til meddelelsestype
WE60 IDoc-dokumentation
WE81 / WE82 Opret beskedtype / tilknyt til IDoc-type
BD51 Definer funktionsmodulets egenskaber
SM59 Vedligehold RFC-destinationer

IDoc-proces: Et eksempel fra den virkelige verden

Overvej eksemplet med at sende en indkøbsordre til en leverandør via IDoc.

  • Når en indkøbsordre (PO) oprettes, skal systemet sende et IDoc til leverandøren.
  • Indkøbsordren sendes i form af et IDoc til leverandøren (partneren). Denne partner skal være EDI-aktiveret i systemet. SAP anerkender, at den kan sende dokumentet elektronisk til denne leverandør.
  • Den indkøbsordre, der sendes som et udgående ID-dokument af kunden, bliver et indgående ID-dokument for leverandøren. SAP Systemet på leverandørens side kan behandle dette for at oprette et applikationsdokument (en salgsordre) på deres system.
  • Tilbud, tilbudsanmodninger, indkøbsordrer, bestillingsordrer, fakturaer og leveringssedler er nogle af de mest almindeligt udvekslede dokumenter via IDoc.

Processen med dataoverførsel ud af din SAP systemet kaldes Udgående proces, mens data flyttes ind i din SAP systemet kaldes Indgående procesSom udvikler eller konsulent, der konfigurerer disse processer for din organisation, er trinnene til at konfigurere hver enkelt beskrevet nedenfor.

Den udgående proces

Involverede trin:

  1. Opret segmenter (WE31).
  2. Opret en IDoc-type (WE30).
  3. Opret en beskedtype (WE81).
  4. Knyt meddelelsestypen til IDoc-typen (WE82).
  5. Opret en port (WE21).
  6. Hvis du bruger message-control-metoden til at udløse IDoc'er, skal du oprette funktionsmodulet, der bygger IDoc'en, og linke den til en udgående proces. Code.
  7. Ellers skal du oprette et funktionsmodul eller et selvstændigt program, der opretter IDoc'en direkte.
  8. Opret en partnerprofil (WE20) med de nødvendige oplysninger i de udgående parametre for den partner, du udveksler IDoc'et med, og udløs IDoc'et.

Den indgående proces

Involverede trin:

  1. Opret den grundlæggende IDoc-type (transaktion WE30).
  2. Opret meddelelsestypen (transaktion WE81).
  3. Knyt meddelelsestypen til den grundlæggende IDoc-type (transaktion WE82).
  4. Opret funktionsmodulet til behandling af IDoc'en.
  5. Definer funktionsmodulets egenskaber (BD51).
  6. Tildel det indgående funktionsmodul til meddelelsestypen (WE57).
  7. Definer processen Code (Transaktion WE42).
  8. Opret partnerprofilen (transaktion WE20).

Ofte Stillede Spørgsmål

IDoc er asynkron og bruges til system-til-system-beskeder via ALE eller EDI. BAPI er synkron og bruges til adgang til realtid SAP forretningsobjekter. IDoc er i kø; BAPI returnerer med det samme.

En IDoc-type definerer den tekniske struktur af segmenter og felter. En meddelelsestype definerer den forretningsmæssige betydning, såsom ordrer eller fakturaer. Én IDoc-type kan håndtere mange meddelelsestyper og omvendt.

Brug transaktion WE02 eller WE05 til at vise IDocs og inspicere statusposter. Udgående bruger statuskoder 1-42; indgående bruger 50-75. Transaktion BD87 genbehandler fejlbehæftede IDocs.

SDATA-feltet, der gemmer nyttelasten i hver datapost, er 1000 tegn langt. En IDoc kan indeholde mange dataposter, så den samlede nyttelast skaleres med antallet af segmenter.

Ja. IDocs er systemneutrale og følger EDI-standarder som ANSI ASC X12 og EDIFACT. Ikke-SAP Systemer kan producere eller forbruge IDoc-filer via filporte eller middleware som f.eks. SAP PI/PO.

Kontrolposter findes i tabellen EDIDC, dataposter i EDID2 til EDID4, og statusposter i EDIDS. IDoc-nummeret er nøglen, der forbinder alle tre tabeller for en given IDoc.

AI-drevne overvågningsværktøjer grupperer tilbagevendende IDoc-fejl, forudsiger fejl ud fra historiske mønstre og anbefaler rettelser til problemer med status 51 eller 56, hvilket reducerer tiden for manuel genbehandling betydeligt.

Ja. AI-drevet kortping motorer sammenligner segmentdefinitioner på tværs SAP og partnersystemer, foreslå markkortpings, og lær af tidligere rettelser — hvilket kraftigt reducerer manuel konfiguration i ALE- og EDI-projekter.

Opsummer dette indlæg med: