ALE, EDI & IDocs Introduktion og forskel: SAP tutorial

Hvad er EDI?

EDI, som står for Electronic Data Interchange, er elektronisk udveksling af strukturerede forretningsdata mellem forskellige applikationer. En indkøbsordre, der er oprettet i én virksomhed, kan derfor ankomme til en leverandørs system som en salgsordre, uden at nogen skal indtaste den igen.

EDI Architecture

Som diagrammet ovenfor viser, EDI ArchiTeksturen består af tre lag –

1. EDI-aktiverede applikationerDe understøtter automatisk behandling af forretningstransaktioner.
2. IDoc-grænsefladen: Dette blev designet som en åben grænseflade. IDoc-grænsefladen består af IDoc-typer og funktionsmoduler, der danner grænsefladen til applikationen.
3. EDI-undersystemet: Dette konverterer IDoc-typerne til EDI-meddelelsestyper og omvendt. Denne komponent af EDI-arkitekturen er ikke leveret af SAP.

Fordele ved EDI-processen

• Færre dataindtastningsfejl
• Reduceret behandlingscyklustid
• Tilgængelighed af data i elektronisk form
• Reduceret papirarbejde
• Reducerede omkostninger
• Reduceret varebeholdning og bedre planlægning
• Standardkommunikationsmidler
• Bedre forretningsprocesser
• Konkurrencefordel

Hvad er ALE?

EDI når ud til handelspartnere. ALE løser spejlproblemet internt i virksomheden, hvor flere SAP Systemerne skal holde trit.

ALE understøtter fordelingen af ​​forretningsfunktionerne og processen på tværs af løst koblede SAP R/3-systemer (forskellige versioner af SAP R/3). Forbindelser fra R/2 og ikke SAP systemer er også understøttet.

ALE støtter-

• Fordeling af applikationer mellem forskellige udgivelser af R/3-systemer
• Fortsat dataudveksling efter en udgivelsesopgradering uden at kræve særlig vedligeholdelse
• Kundespecifikke udvidelser.
• Kommunikationsgrænseflader, der tillader forbindelser til ikke-SAP systemer.
• Kobling af R/3 og R/2 systemer.

Hvad er IDOC?

Både ALE og EDI kræver dataudveksling, og begge overfører opgaven til det samme objekt.

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

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

IDOC står for "Mellemdokument".

Når vi udfører en udgående ALE eller EDI Process, en IDOC oprettes. I en indgående ALE- eller EDI-proces, en IDOC tjener som input til at oprette et ansøgningsdokument. I den SAP Systemkrav, IDOC'er gemmes i databasen. Hver IDOC har en unikt nummer (inden for en klient).

IDOC'er er baseret på EDI-standarder, ANSI ASC X12 og EDIFACTI tilfælde af konflikt i datastørrelsen vælges den med den største længde. IDOC'er er uafhængig af retningen for dataudvekslingen, for eksempel bruges ORDRES01 i indkøbsmodulet både indgående og udgående. IDOC'er kan ses i en teksteditor fordi data gemmes i tegnformat i stedet for binært format. IDOC'er er uafhængig af sende- og modtagesystemer (SAP-til-SAP såvel som ikke-SAP).

IDoc-struktur: Kontrol-, data- og statusposter

Det er kun nyttigt at vide, at et IDoc er en container, når du kan læse, hvad der er indeni. Hvert IDoc, uanset meddelelsestype, er bygget op af tre posttyper.

Statusnumre giver dig også et hurtigt overblik over retningen. CodeDokumenter i området 01 til 49 tilhører udgående IDoc'er, hvor 03 betyder "sendt til port" og 12 betyder "afsendt". CodeDokumenter fra 50 og opefter tilhører indgående IDocs, hvor 53 betyder "ansøgningsdokument sendt" og 51 betyder "ansøgningsdokument ikke sendt".

Hvordan fungerer ALE- og IDoc-processen?

Ovenstående poster gennemgår en fast rækkefølge af trin. Forståelse af denne rækkefølge er det, der giver dig mulighed for at finde ud af, hvor en fejlende grænseflade stoppede.

Udgående proces

1. Ansøgningsdokumentet er oprettet. En bruger eller et batchjob gemmer et forretningsdokument, f.eks. en indkøbsordre.
2. Meddelelseskontrol er udløst. Outputbestemmelsen finder en meddelelsestype, for eksempel ORDRER, og en partnerprofil, der angiver, at der skal produceres et IDoc.
3. IDoc'en genereres. Et selektionsfunktionsmodul læser applikationstabellerne og udfylder kontrol- og dataposterne. IDoc'en modtager status 30, "klar til afsendelse".
4. IDoc'en sendes til havnen. Portdefinitionen bestemmer mediet, som kan være en fil, et fjernfunktionskald eller en XML-overførsel. Status bliver 03.
5. Delsystemet eller partneren modtager det. For EDI konverterer delsystemet IDoc'en til en EDIFACT- eller ANSI X12-meddelelse. En vellykket transmission returnerer status 16.

Indgående proces

1. IDoc'en ankommer gennem porten og skrives til databasen med status 50.
2. Partnerprofilen er kontrolleret. SAP slår afsenderen, beskedtypen og den tildelte proceskode op.
3. Proceskoden kalder et funktionsmodul, som validerer segmenterne i forhold til den grundlæggende type.
4. Ansøgningsdokumentet er offentliggjort. Succes giver status 53. En fejl giver status 51, og IDoc'en forbliver i databasen med den vedhæftede fejlmeddelelse.
5. Mislykkede IDoc'er genbehandles efter at stamdataene er rettet, uden at partneren behøver at sende noget igen.

Fordi IDoc'en gemmes i hvert trin, går der ingen data tabt, når et trin fejler. Den holdbarhed er hovedårsagen SAP Integrationer er stadig afhængige af IDocs årtier efter deres introduktion.

Forskellen mellem ALE og EDI

Når alle tre begreber er defineret, bliver sondringen let at angive.

ALE bruges til at understøtte distribuerede, men integrerede processer på tværs af flere SAP systemer, hvorimod EDI bruges til udveksling af forretningsdokumenter mellem forretningspartneres systemer (som kan være ikke-SAP systemer).

ALE er SAP's teknologi til understøttelse af et distribueret miljø, hvorimod EDI er en proces, der bruges til udveksling af forretningsdokumenter, som nu har fået et standardformat.

En IDoc er en datacontainer, der bruges til dataudveksling via både EDI- og ALE-processer. Den delte container er grunden til, at de to teknologier næsten altid studeres sammen.

Fælles IDoc-transaktion Codesi SAP

Det daglige arbejde med ALE og EDI foregår via et lille sæt transaktionskoder. Tabellen nedenfor grupperer dem efter den opgave, de udfører.

En praktisk fejlfindingsvane er at starte ved WE02 for at aflæse status og derefter bruge BD87 til at genbehandle, når den grundlæggende årsag er løst.

Ofte Stillede Spørgsmål