Metodik och metodbeskrivning för EDI införande

Metodik och metodbeskrivning för EDI införande VERKSAMHETSGRÄNSNITT FÖR EDI-SAMVERKAN mellan VBS (VerksamhetsBaserade System) av: Birgit Norén, aktuell tillhörighet: FMV:Electro:InfoSyst Thomas Wahlqvist, aktuell tillhörighet: EDI Constructions AB 08-655 09 30 1995 Norén & Wahlqvist

INNEHÅLL 1. INLEDNING 1.1 Bakgrund 1.2 Allmänt 1.3 Uppgift 1.4 Syfte 1.5 Arbetsgruppens sammansättning 2. EDI-SAMVERKAN BYGGER PÅ SAMFÖRSTÅND 2.1 Standardisering 2.2 EDI-samverkan mellan VBS:er 2.3 Avtalade informationsutbyten 2.4 Gemensam tolkning av begrepp i förstudiefasen 2.5 Logiska och semantiska strukturer i implementeringsfasen. 2.6 Överblick, kontroll och styrningsmöjligheter i förvaltningsfasen. 3. FÖRSTUDIEFASENS PROBLEM 3.1 Funktionella meddelanden och begrepp 3.2 EDIFACT en transportsträcka 3.3 Meddelandestandard och tillämpningsanvisningar 3.4 Subset eller standardavvikelse 4. IMPLEMENTERINGENS PROBLEM 4.1 Dataklasser 4.2 Implicit och explicit decimalseparator 4.3 Null och noll 4.4 Synonymer och alias 4.5 Precision och sort 4.6 Förekomst 5. FÖRVALTNINGENS PROBLEM 5.1 Spårbarhet 5.1.1 Borttappade filer 5.1.2 Borttappade meddelande 5.1.3 Borttappade datauppgifter 5.2 Arkivering 5.3 Nya meddelandeversioner 5.4 Nya meddelanden 6. RUBRIKER I BEGREPPSTABELL BILAGA 1 TABELL/MALL BILAGA 2 EXEMPEL PÅ EXTRAKT UR TABELL/MALL 2

1. INLEDNING 1.1 Bakgrund Kunskap, verktyg och metoder för utvecklingen av EDIFACT har sedan 80-talet har varit relaterade till själva standardutvecklingen. Presentationer och utbildningar har varit relaterade till standardiseringsarbetets inriktning på utveckling. Exempelvis EDIFACT-meddelandets samt segments och kompositers (sammansatta dataelement) eller elements form, maximala längd och förekomst. Metodik och metoder för att tillämpa EDI har varit och är fortfarande starkt eftersatt. Denna rapport är ett bidrag till ett kulturarv kring tillämpning av EDI. 1.2 Allmänt I föreliggande rapport redovisas ett verksamhetsgränssnitt för EDIFACTmeddelandetillämpning/mall som beskriver avtalat informationsutbyte mellan VBS:er. Vi har belyst tillämpningen av EDI med avseende på förstudie-, implementerings- och förvaltningsfasen med tonvikt på verksamhetsgränssnittet. Verksamhetsgränssnittet, i form av en begreppstabell, beskriver samverkan mellan avsändande respektive mottagande VBS och bidrar bl a till att skapa överblick avseende givna termers innebörd (tolkning) i såväl bakomliggande ADB-system som inom aktuellt verksamhetsområde. Olika kategorier av befattningshavare har olika ansvarsområden och därmed olika möjligheter att fylla i uppgifter om avtalat informationsutbyte. Termens eventuella representation i ADB-system fylls t ex i av de som ansvarar för systemförvaltningen emedan övriga uppgifter exempelvis fylls i av andra kategorier av befattningshavare. EDIFACT-meddelandetillämpning är anpassningsbar, lätt att anpassa till nya krav. Sålunda kan nya uppgifter läggas till i tabellen alltefter som nya behov identifieras. Ett nytt krav kan innebära alltifrån att nya uppgifter om en term läggs till, till att en ny kolumn läggs till i existerande tabell eller att existerande tabell delas upp i ett antal tabeller som är relaterade till varandra (en katalog/ett tabellverk). Genom att vi har använt ett kalkylprogram, (Excel) för att framställa tabellen, kan urval av lämpliga kolumner göras vid presentation av denna tabell. Man kan för att förenkla urvalsförfarandet makroprogrammera fram automatiska växlingar. För närvarande finns två presentationssätt. 1.3 Uppgift Uppgiften har varit att ta fram verktyg för att fastställa information i gränssnittet mot EDIkonverterare med avseende på datakvalitet och kvantitet för överföring mellan två VBS. Vad två VBS behöver veta om varandra är händelser, åtgärder och begrepp. Vi har i denna utgåva koncentrerat oss på mallen för att beskriva begrepp. Vi avser att under hösten 1995 komma med förslag på lösning för mallar avseende händelser och åtgärder. 3

Verksamhetsgränssnittets tabell, är uppdelad i tre grupper av kolumnrubriker relaterade till: AVSÄNDANDE VBS, CAMA respektive MOTTAGANDE VBS. För att ytterligare tydliggöra innebörden av verksamhetsgränssnittets olika begrepp följer en definition och ett regelverk för hur tabellerna bör utnyttjas i bilaga 1 och 2. 1.4 Syfte Begreppstabellen syftar till att dels tydliggöra förekomsten av tvetydigheter och avvikelser mellan parternas VBS, så att man kan eliminera flertalet missförstånd och belysa avvikelser från branschstandard såväl som EDI-parts krav. Denna skrift syftar också till att motivera användandet av det framtagna verksamhetsgränsnittet, begreppstabellen. 1.5 Arbetsgruppens sammansättning Birgit Norén, Thomas Wahlqvist, aktuell tillhörighet FMV:Electro:InfoSyst aktuell tillhörighet EDI Constructions AB 4

2. EDI-SAMVERKAN BYGGER PÅ SAMFÖRSTÅND 2.1. Standardisering Vad vore man idag om man inte uppfunnit standardisering som ett hjälpmedel att åstadkomma reproducerbarhet av olika produkter och företeelser. Standardisering utgör en förutsättning inom många olika verksamheter. Att järnvägens spårvidd alltid håller samma mått framstår kanske som självklart. Detta beror dock på en noggrann standardisering. Att elström i väggkontakten är 220 volt är likaledes en produkt av standardisering. Givetvis utgör vårt språk också en form av standardisering. Inte minst inom datortekniken är standardiseringen av språk och begreppsdefinitioner en nödvändighet. 2.2 EDI-samverkan mellan VBS:er Vad två VBS:er behöver veta om varandra för att kommunicera är: Händelser Begrepp Åtgärder Samverkan mellan VBS inbegriper händelser, åtgärder och förekomst av informationer i primärverksamheten. För att säkerställa betydelsen av dokumentet bör, i detalj, beskrivas vilka händelser och åtgärder i primärverksamheten samt informationsmässiga förutsättningar som måste föreligga överföringen av dokumentet. Initialt fordras att begreppen klargörs, med avseende på dess innebörd, kvalitet och villkor för överföring. Om betydelseskillnaden är ovidkommande eller betydelsefull. Exempelvis kan avsändaren skicka Avsändningsdatum emedan mottagaren förväntar sig Ankomstdatum. 5

Gods skall transporteras från orten A till orten B. Godsmottagaren behöver därvid veta t.ex. [1] Ankomsttid för godset [2] Hur mycket utrymme han/hon behöver reserveras på lagret för leveransen. (Antal kollin, vikt, volym, ankomsttid etc.) För att effektivisera godsmottagarens planering sänds ett EDI-meddelande från godsavsändaren när transporten lämnas lastkajen. Moment [1] Händelse- färdiglastad transport [2] Begrepp- meddelande till godsmottagaren (vikt, volym ankomsttid) [3] Åtgärd Godsmottagaren reserverar lagerutrymme 2.3 Avtalade informationsutbyten Förutsättningarna för att överföra information med hjälp av EDI (EDIFACT, Odette m.fl.standard) är att det finns en absolut kontroll över begreppens innebörd. För att uppnå detta, fordras att det finns identifieringsregler för begrepp som gäller för både avsändande och mottagande sida vid EDI kommunikation. Inom delprojektet CAMA har utformats ett verksamhetsgränsnitt, (mall för att beskriva avtalade informationsutbyten med avseende på innebörd och kvalitet. För att säkerställa kvaliteten i informationsutbyte krävs möjligheter att för varje term som skall kommuniceras gå tillbaka till bakomliggande ADB-verkligheter och primärverksamheter. Detta kan åstadkommas genom att tillämpa ett verksamhetsgränssnitt (detaljerad beskrivning se avsnitt X). Ett sådant gränssnitt innefattar ett antal uppgifter som till exempel hur en term identifieras och fångas i en bakomliggande ADB-verklighet och primärverksamhet, hur data kontrolleras etc. 6

Bild: Schematisk bild över avtalat informationsutbyte. 2.4 Gemensam tolkning av begrepp i förstudiefasen I förstudiefasen syftar en ifylld begreppstabell till att eliminera avvikelser och källor till feltolkningar samt att uppmärksamma eventuella formatbegränsningar. De väsentliga kolumner utgörs av under rubrikerna AVSÄNDANDE VBS och MOTTAGANDE VBS kolumnrubrikerna Härkomst, Datalager, format,precision,längd och Avsändande krav på dataförekomst, kod och motsvarande kolumner på mottagande sida dvs. Mottagande krav på dataförekomst, kod, Datalager, ID, längd, format, precision, Ankomst, kod. AVSÄNDANDE VBS Här- Datalager Avsändande krav på dataförekomst ko format mst precision Kod ID Längd Kod Klartext 7

MOTTAGANDE VBS Mottagande krav på dataförekomst Datalager An ko längd mst Kod Klartext ID typ Bear 2.5 Logiska och semantiska strukturer i implementeringsfasen. Med en tydlig beskrivning av den datafil, som skall konverteras till EDIFACT-format kan implementering ske snabbt och felfritt. Med tydlig avses bland annat filens logisk struktur och semantiska innehåll. AVSÄNDANDE VBS Inhousefil ID Kontrollsätt av data & källor till fel MOTTAGANDE VBS Inhousefil ID Kontrollsätt av data & källor till fel En fullständigt ifylld begreppstabell tydliggör i implementeringsfasen, eventuella kvantitativa och kvalitativa datafångstbrister liksom brister i applikationen. 2.6 Överblick, kontroll och styrningsmöjligheter i förvaltningsfasen. EDI-ansvarig vid respektive VBS måste kunna överblicka, kontrollera och styra dvs kunna uppfylla sitt ansvarsåtagande. Därför måste tekniska och praktiska förutsättningar föreligga för att påverka informationsinnehåll på detaljnivå i meddelandet. En fullständigt ifylld begreppstabell tydliggör den koppling av data som EDI-överföringen innebär. 8

3. Förstudiefasens problem Att införa EDI innebär ofta, att man med hjälp av erfaren EDI-expertis, i projektform, påbörjar en förstudie. En vanlig fälla som får projekt att kantra är att EDI-standard och rekommendationer i standarden får alltför stort inflytande på datakvalitet och kvantitet. Grundläggande principfrågor vid införande av EDI. 1. Får sändande part skicka, för mottagande part irrelevant data, som visserligen följer standard men avviker med avseende på koder och kodlistor eller påfordrar mottagaren att en unik kundprofil måste föreligga hos avsändaren? 2. Skall elektroniska dokument vara självständiga bärare av information eller medges hänvisning till andra dokument med hjälp av hänvisande referensnycklar i dokumentet? 3. Skall avsändande part explicit autentifieras i dokumentet eller kan äktheten anses vara säkerställd genom avsändarens applikation? 4. Skall dokumentet sigilleras eller kan det anses vara säkerställt genom avsändarens applikation? 5. Skall dokumentet krypteras? IT-kommissionens Toppledarforum har genom Single Face to Industri angivit en inriktning på resonemanget i ovanstående frågeställningar, vilket föranleder en studie av dess rapporter. 3.1 Funktionella meddelandetyper och EDIFACT meddelandetyper När två parter skall prata sig samman för att använda EDI, kan det vara lämpligt att undvika EDIFACT-begrepp tills parterna är ense om begreppsbetydelser och om den bakomliggande verklighet som ger innebörd och fyller meddelanden och begreppen med mening. Först därefter kan det vara lämpligt att klä dessa begrepp och funktionella meddelandetyper i EDIFACT-termer samt knyta sig till de branschrekommendationer som är relevanta. Beställning, är en sådan funktionell meddelandetyp som inte står i förhållande 1 till 1, till EDIFACTmeddelandetyper, utan fordrar ett ställningstagande innan man fattar beslut om vilken EDIFACTmeddelandetyp som kan vara tillämpligt. Exempel på EDIFACT-meddelandetyper som kan fungera som beställning är: ORDERS ORDCHG DELFOR (Purchase Order, Despatch Order) (Order Change) (Delivery Forecast, Call Off) Nedan följer exempel på EDIFACT-meddelandtyper, som den funktionella meddelandetypen orderbekräftelse använder sig av, av aktiva EDI-aktörer: ORDRSP DESADV INVOIC (Order Respons) (Despatch Advice) (Invoice) 9

CONTRL KONTRL (Control Message) (Kontroll Meddelande) Valet av meddelandetyp och tillämpningsanvisningar [se punkt 2.3], kommer också att bestämma innehåll i Tabellrubrik och kolumnrubrikerna 7 och 8 i begreppstabellen. 3.2 EDIFACT en transportsträcka EDIFACT är inget självändamål, varför standardens krav eller rekommendationer bör underordnas de krav på informationsutbyte som fastställs i den bilaterala relationen. Man kan se EDIFACT, ISO 9735, som ett välorganiserat flyttfirma specialiserad på datatransporter, med väldefinierade märkningar av data-kartonger lådor och containers, med en personalstyrka som förmår att packa ner kompakt och strukturerat. 3.3 Meddelandestandard och tillämpningsanvisningar Varje år utkommer en uppsättning nya dokument från FN, UN/ECE/WP4/EDIFACT, United Nation /European Comity of Ecnomi/Working Party 4/EDIFACT. Utgåvorna av EDIFACT meddelanden varierar från år till år. Ibland varierar de med marginella skillnader, ibland stora skillnader. Dessa dokument är mycket stora. Varje dokumenttyp, exempelvis faktura, skall omfatta alla tänkbara varianter av faktura, världen över och i alla branscher och relationer. En i sig själv ohanterlig dokumenttyp med andra ord. De stora branschorganisationerna, såsom EAN och SWIFT, har tagit som sin uppgift att utveckla tillämpningsanvisningar för sin bransch och att tillföra kodlistor för sin bransch specifika behov. 10

Sedan har de nationella branschrepresentanterna exempelvis EAN Sverige resp SWEDIFACT Finans tagit fram nationella subset av dessa branschstandarder. Av ett FN meddelande om 100% nyttjas kanske 20 % av branschen och kanske 5 % i den nationella tillämpningsanvisningen och kanske 2-3 % i den bilaterala relationen. Här bör man observera att: Branschorganisationerna beaktar inte varje utgåva från FN, utan koncentrerar sig på några meddelandetyper från vissa årgångar och iordningställer entydiga tillämpningsanvisningar för dessa meddelandetyper. Exempelvis tog EAN Sverige fasta på 1990 års versioner, benämnd EDIT version 1, för att under 1994/95 presentera tillämpningsanvisningar av 1993 års versioner, benämnd EDIT version 3. 3.4 Subset eller standardavvikelse Om ett begrepp inte går att identifiera i det nationella subset av EDIFACT-meddelandet finns två vägar att gå. Den ena är att söka lösningen hos den övergripande branschorganisationens EDIFACT-regelverk eller göra en bilateral avvikelse. Mot bakgrund av en öppen tillämpning av EDIFACT där sändande part medges skicka för mottagande part irrelevanta data kan en avvikelse avseende koder vara möjlig. 11

4. Implementeringens problem I princip är överföring av EDI data mellan parter okomplicerad och trivial. Men när man närmar sig detaljnivån börjar problemen tona upp. Man får inte glömma att ett av skälen till att standarden vunnit sådan framgång är just att den är principiell och inte konkret. 4.1 Dataklasser Ett problemområde är hur dataklasser identifieras i det elektroniska dokumentet. Standarden anger inte vilken kodtyp detta skall ske med utan lämnar denna fråga öppen genom ett särskilt tilläggsfält, för att där ange vilken kodtyp som används. Exempel utgörs av varans artikelnr som kan vara EAN Artikelnr eller kundens artikelnr eller säljarens artikelnr, om säljaren har en artikelnummer- serie som är 14-ställig och mottagaren inte kan hantera så långa artikelnr uppstår problem. Klassificeringsarbetet av data inom EDIFACT är jämförbart med det stora arbete som leddes av Carl von Linné för att klassificera all värdens djur och växter. 4.2 Implicit och explicit decimalseparering (000002530 eller 00000025.30) Ett annat problemområde är numeriska fält där en ganska vanlig avvikelse från standard är att använda implicit decimalseparering. 4.3 Nil och noll ( eller 00000) Ett annat är att EDIFACT- standarden inte har löst förhållandet mellan nil och noll. Komprimeringsalgoritmen utelämnar alla numeriska värden som innehåller noll. Hur skall man då kunna veta om en vara är gratis eller om priset ej är angiven. 4.4 Synonymer och alias Ytterligare ett problemområde är att då EDI-kommunikation vanligtvis utväxlas mellan olika branscher har begrepp förskjutna betydelser eller saknas helt. Arbetet består då i att hitta lämpliga 12

synonymer. Exempelvis mottagaren önskar datum för leveransmottagandet medan avsändaren sänder avsändningsdatum från lager. Eller avsändaren sänder Shipping Date men förväntas skicka On Board Date. 4.5 Precision och sort Ett annat problemområde är precisionsavvikelser och sortangivelse. Det kan vara fråga om måttenhetsavrundingar som är oacceptabla. eller val av måttenhet. De affärsmässiga informationskraven måste ibland ställas mot både standardens rekommendationer och riktlinjer och VBS befintliga förmåga att skapa korrekt precisionsnivå. 4.6 Förekomst Uppgifter som skall tas emot i en Order kanske inte är intressanta vid inläsning till OLF-systemet, men för att i ett senare skede skicka godsavisering eller faktura, varför de måste buffras upp under tiden. 13

5. Förvaltningens problem 5.1 Spårbarhet 5.1.1 Borttappade filer Vid driftsenheter som utgör EDI-centraler eller för applikationer med EDI-funktionalitet, kan filer innehållande EDI-meddelanden, försvinna eller komma på avvägar. I ett perspektiv av hela flödet kan man se det som en lång kedja där varje länks koppling till en annan länk utgörs av en excentrisk punkt axlad från bägge länkarna. Om varje sådan punkt ges en identitet kan man identifiera flödets väg igenom. Om ankomst till varje punkt loggas och varje lämnande av punkt loggas samt även logga vilken nästa punkt skall bli, kan filer spåras genom hela flödet och med hög precision ange var fel inträffar. Exempel på några stationer i ett EDI Work Flow : VBS/INHOUSE-FIL/EDIKONVERTERING/UPPKÖAD/SÄNDNING/RPC/MTA/X.25/MTA/ RPC/KVITTERAD/ EDIKONVERTERING/KVITTERING-Steg 2/INHOUSE-FIL/ KVITTERING-steg 3/VBS 5.1.2 Borttappade meddelanden Användare av VBS är inte intresserade av entiteter såsom filer, utan av meddelanden och meddelandenr, exempelvis fakturor och fakturanr, varför även dessa uppgifter behöver loggas för att användare skall kunna beakta loggen. Vidare är också vissa värdeuppgifter av intresse såsom fakturabelopp eller ordervärde av intresse för att användaren skall kunna prioritera en felåtgärd rätt. Exempelvis en fil, med en faktura med ett fakturavärde på 200 kronor ställer inte lika stora krav på snabb åtgärd såsom en fil med en faktura med fakturavärde 200.000 kronor. Avses en utleverans är också uppgifter såsom godsmottagare av intresse. Då man kan förmoda att det är just godsmottagaren som kommer att höra av sig. Då bör man kunna söka i loggdatabasen även på detta begrepp för att snabbt spåra och vidta lämplig åtgärd snabbt. 5.1.3 Borttappade datauppgifter Man kan ofta undvika att meddelanden med väsentliga informationsbrister sänds iväg, men inte alltid. I de fall det händer kan inget annat än en väl ifylld begreppstabell ge en klar bild av källan till problemet finns. 14

5.2 Arkivering Då EDI-dokumentet i filer är det juridiska orginal-dokumentet som utgör underlag vid trätor avseende vad vem har begärt av vem och inte. Vidare faller en del dokument under arkiveringsförpliktelser under 10 år. Detta får till följd att s.k. backup rutinerna måste göra tillgängligt dels vilka filer finns på vilka media, och vilka dokument finns i vilka filer, så att exemelvis revisorer kan göra kontroller av äldre fakturor från gamla bokföringsår. Men också i det kortare perspektivet fordras också arkivering av kommunikationslogg, även om en intelligent kvittenshantering finns som omedelbart loggar kvitteringar i kommunikationsloggar. Med tveksamhet kan man förvänta att administrativ personal skall göra uttolkningar av kommunikationsprotokollens loggfiler. Exempelvis kan en betydande faktura av mottagaren förkommit varför ränta finns att fordra. Om man ej kan påvisa att mottagarens EDI-kommunikationsmodul kvitterat ut den och ej heller när detta skulle ha ägt rum, kan man svårligen motivera mottagaren att betala ränta. 5.3 Nya meddelandeversioner Nya meddelandeversioner presenteras med något års intervall av branschorganisationerna och den idealiska situationen vore att alla bytte samtidigt. Detta är dock en orealistisk tanke, varför det innebär att ett EDI-system, kommer att behöva hantera flera parallella meddelandeversioner samtidigt. Orsakerna till detta är många, exempelvis att parterna inte har råd att uppgradera eller har applikationer som inte går att uppgradera i den önskvärda takten. 5.4 Nya meddelandetyper Behov av att hantera nya meddelande kan vara två. Den ena anledningen är att man har en ny part som tillämpar en annan EDI-meddelandetyp för samma funktionella meddelandetyp än den som finns implementerad i i den egna applikationen. Exempelvis har man implementerat mottagning av EDIFACT-meddelandet DELFOR men vill samarbeta med en part som använder Odette s DELINS och man finner det affärsmässigt motiverat 15

att anpassa den egna applikationen. Den andra anledningen är att man vill utöka EDIfunktionaliteten i den egna applikationen. Detta ställer krav på den egna EDI-lösningens potencial. 16

6. RUBRIKER I BEGREPPSTABELL Rubriker Huvudrubrik Kommentarer är varierande beroende på överrenskommen meddelandetyp och tillämpningsanvisning. Exempelvis: EDIFACT-meddelande INVOIC enligt EDIT 11, (EDIT 11 är EAN Sverige s tillämpning av version 90.1 som bygger på EAN Europe Branschstandard) AVSÄNDANDE VBS Användare och applikationsansvariga för avsändande VBS samt EDI-ansvarig för avsändande VBS kan och bör fylla i de kolumner som representeras under denna rubrik. EDIFACT/CAMA När val av EDI-meddelandetyp och tillämpningsanvisning fastställts för funktionell meddelandetyp kan lämplig EDI expert fylla i dessa kolumner. MOTTAGANDE VBS Användare och applikationsansvariga för mottagande VBS samt EDI-ansvarig för mottagande VBS kan och bör fylla i de kolumner som representeras under denna rubrik. Nr Kolumnrubriker Kommentarer AVSÄNDANDE VBS Härko mst Kod 1. HÄRKOMST - Typ av härkomst, Egen Stans (ES), Beräknat av Program (BP), Eko från vad Mottagaren tidigare sänt (EM), Skapat av EDI-konverteraren (SE), Tabellkonverterat (TK), Annat, Exempe på värde: ES Program Program Skärmbild 2. PROGRAM Under denna rubrik bör anges den exakta plats i systemet där datat kan ha fått sin härkomst eller blivit modifierat. 17

Om värdet 2a är signifikant för uppgiften kan 2b utelämnas eller vise versa. 2a program 2b skärmfält-id Namn på det program som skapar värdet eller inmatningsfält i applikation Exempel på värde: FAKTURA.EXE Bild-ID och fältrubrik där datat kan iakttas/matas in. Om värdet som skall användas kan iakttas, modifieras eller matas in via bild i program, bör denna uppgift registreras i tabellen, så att eventuella fel kan härledas och åtgärdas. Exempel på värde: VISA (Faktura), Kundref Datalager ID format precision Längd 3. DATALAGER Under denna rubrik bör anges den logiska identitet, längd, typ, format och precision i datalager där datat finns lagrat. 3a id - Logisk identitet som åberopas av program för att läsa över värde till inhouse fil Exempel på värde: Kundres.kund.Fakturanr 3b längd & typ,format precision - fältets längd och typ i datalager vilken lämpligast anges med koder för Alfanumeriskt/numeriskt, längd, format och precision om numeriskt, ex.vis 999.999 Inhousefil ID Kontrollsätt av data & källor till fel 4. INHOUSEFIL Under denna rubrik bör anges fältets ID eller i förekommande fall plats i inhouse-filen samt ange hur värdet säkerställs av systemet. genom t.ex. rimlighetskontroller, kontrollberäkningar tex. checksifferkontroll av personnnummer eller annat. 4a Fältets ID i inhusefil - Var i inhouse-filen där värde finns Exempel på värde: 00081 4b Kontrollsätt av data - I klartext angivet om och ev hur säkerställande av data sker. Exempelvis rimlighetskontroller, kontrollberäkningar tex. checksifferkontroll av personnnummer okulärbesiktigat eller annat. Exempel på värde: Checksifferkontroll Avsändande krav på dataförekomst Kod Klartext 5. AVSÄNDANDE KRAV PÅ DATAFÖREKOMST Under denna rubrik bör anges krav på förekomst av data i ett specifikt meddelande, detta kan vara motiverat av krav på att meddelandet uppfyller den juridiska krav på fullständighet, eller att värden förväntas i finnas med i meddelande som returneras av part, eller annat. 5a kod - O/V/Va, anges här om data är Obligatorisk, Villkorlig eller Villkorlig med associerade termer, Va Exempel på värde: O 18

5b klartext - Radnr i tabell 6. RADNR I TABELL Radnummer i denna tabell (löpnummer eller motsvarande). EDIFACT RELATERADE UPPGIFTER Förväntat värde 7. VÄRDETYP ID - Förväntad klassidentifierare i kodform för tillhörande basuppgifts och funktion. EDIkvalificerare, och andra EDI-attribut till primärdata enligt överenskommen branschstandard. Exempel: EN (EAN Article Number) SA (Suplier Article Number) EDIFACTfil ID Förekomst typ, längd 8. EDIFACT-FIL 8a id 8b förekomst längd typ förekomst - Enligt punktnotation i EDIFACT pekare såsom NAD.COM.C506.1138 - Enligt ISO 9735 notation såsom M An..3, C An3, N4, N..4 MOTTAGANDE VBS Mottagande krav på dataförekomst Kod Klartext 19

9. MOTTAGANDE KRAV PÅ DATAFÖREKOMST Under denna rubrik bör anges mottagarens verksamhets krav på dataförekomst. 9a Kod - O/V/Va - anges här om data är Obligatorisk, Villkorlig eller Villkorlig med associerade termer, Va, Exempel på värde: O 9b Klartext Exempel på värde: Referensuppg Inhousefil ID Kontrollsätt av data & källor till fel 10. INHOUSEFIL Under denna rubrik bör anges fältets ID eller i förekommande fall plats i inhouse-filen samt ange hur värdet säkerställs av systemet. genom t.ex. rimlighetskontroller, kontrollberäkningar tex. checksifferkontroll av personnnummer eller annat. 10a Fältets ID i inhousefil - Var i inhouse-filen där värde finns uttryckt i positioner eller fältnamn Exempel på värde:faktnr 10b Kontrollsätt av data - Sätt att kontrollera datafångst hos mottagaren, att i klartext angivet om och ev hur säkerställande av data sker. Exempel kan vara kontraktsnummer mot artikelpris och leveransvilkor eller andra rimlighetskontroller, kontrollberäkningar eller annat. Exempel på värde: Priskontroll Datalager ID längd typ 11. DATALAGER Under denna rubrik bör anges den logiska identitet, längd, typ, format och precision i datalager där datat finns lagrat. 11a id - Logisk identitet som åberopas av program för att läsa över värde från inhouse fil Exempel på värde: Kundres.kund.Fakturanr 11b längd & typ,format precisi - fältets längd och typ i datalager vilken lämpligast anges med koder för Alfanumeriskt/numeriskt, längd, format och precision om numeriskt, ex.vis 999.999 Program Program Skärmbild 12. PROGRAM Under denna rubrik bör anges den exakta plats i systemet där datat kan ha fått sin ankomst, blivit modifierat. Om värdet 12a är signifikant för uppgiften kan 12b utelämnas eller vise versa. 12a program Namn på det program som ger bildskärm där inläst värde visas. 20

12b skärmfält-id begreppstabell, Exempel på värde: FAKTURA.EXE Bild-ID och ev. fältrubrik där datat kan iaktas/modifieras. Om värdet som skall användas kan iakttas, modifieras, bör denna uppgift registreras i denna så att eventuella fel kan härledas och åtgärdas. Exempel på värde: VISA (Faktura), Kundref An ko mst Bear 13. ANKOMST - Om data lagrats direkt utan att bli bearbetad, såsom tabellkonverteras eller på annat sätt modifierats såsom trunkering, substituering, beräknats. Exempel på värde: TK 21