Indholdsfortegnelse:

Transkript

1 ITIT

2 Indholdsfortegnelse: Forord... 3 Formål... 4 Transmissionssystem og -opbygning... 5 Ordbog/begreber... 8 Transaktionsdefinitioner... 9 Ændringslog XML-schema-definitioner Oracle AQ GET- og PUT-procedurer Bilag 1: Eksempler på transaktioner ITIT ver juli 2014 Side 2 af 31

3 Forord ////////// ITIT ver juli 2014 Side 3 af 31

4 Formål Formål: Formålet med en dataudvekslingsstandard er at sikre, at det er de samme data-definitioner og udvekslingstransaktioner, der benyttes hos både afsendere og modtagere af transaktioner Datadefinitioner og udvekslingstransaktioner bør så vidt muligt være system-uafhængige. Nomenklatur: Til brug for ændringsstyring versioneres standarden efter nomenklatur på formen X.Y.Z, hvor: X angiver versionsnumret. Værdien ændres kun ved gennemgribende revidering af standarden. Y angiver betydningsfulde ændringer til versionen i principper, funktionalitet og transaktioner (eks. ændringer i feltlængder og/eller tilføjelse/fjernelse af felter m.v.) Z angiver mindre ikke betydningsfulde ændringer til versionen (typisk ændringer i værdilister og redaktionelle ændringer). Bemærk at ændringer i Y-værdi nulstiller Z-værdi. Alle ændringer føres i ændringslog. Vedligeholdelse: Ansvaret for vedligeholdelse af standarden varetages af Bladkompagniets IT-afdeling. Gyldighed: Nærværende standard benævnes ITIT version. 3.y.z. ITIT ver juli 2014 Side 4 af 31

5 Transmissionssystem og -opbygning Transmissionssystem: Bladkompagniets integrations strategi baserer sig på Oracle teknologi, herunder Oracle InterConnect. De systemløsninger, som understøtter Bladkompagniets forretningsområder, skal alle anvende den nedenfor beskrevede integrations-strategi. Bladkompagniets integrations-strategi er baseret på en hub-and-spoke løsning. Hvert forretnings-system er at betragte som en spoke i løsningen og Oracle InterConnect er hub en. Hver spoke (forretnings-system) har en ind- og en ud-kø, hvor forretnings-systemet har ansvaret for at hente de meddelelser, der ligger på ind,køen og behandle dem, samt at aflevere meddelelser på ud,køen, som skal sendes til andre forretnings-systemer eller til BK s samarbejdspartnere. Figur 1 viser Hub and Spoke løsningen. REBS KØS Oracle InterConnect PAK ERP ABO Figur 1 Alle meddelelser, som sendes igennem integrations løsningen, sendes som enkelt transaktioner. Kø-systemet, som anvendes i integrations-løsningen, er Oracle AQ. AQ køerne er sat op på hver forretnings system database. De to køer som standard er sat op ligger i ICSPOKE skemaet og der er vil blive givet adgang til de databasebrugere, som skal hente og aflevere meddelelser. Køerne har følgende navne: BK_IN_QUE. Køen hvor forretnings-system modtager meddelelser fra. BK_OUT_QUE. Køen hvor forretnings-system afleverer meddelelser til. Køerne er sat op således, at når meddelelsen er hentet fra køen, vil den blive registreret at den er hentet men ikke fjernet. Enten skal det enkelte forretnings-system hente og aflevere direkte på køerne eller anvende BK_AQ_GET og BK_AQ_PUT som er to BK standard procedurer. Anvendelse af disse to procedurer kan ses i afsnittet Oracle AQ GET- og PUT-procedurer ITIT ver juli 2014 Side 5 af 31

6 Transaktionsopbygning: Alle transaktioner udveksles i XML og skal overholde XML-schema-definitionen beskrevet i afsnittet XML-schemadefinitioner. I XML-schemaet er selve meddelelsen beskrevet som attributten og message som en string. Indholdet i attributten skal være CDATA : <![CDATA[ meddelelsen som XML; se afsnittet XML-schema-definitioner pkt. transaktion ]]> attributten TRANSFORKORTELSE i BK_HEADER og overordnede tag i meddelelses XML skal være ens Nærværende standards transaktions-beskrivelser angiver indholdet af transaktionerne, herunder datatyper, længder og værdier. En samlet transaktion er opbygget af en header og data-angivelse. Indholdet af header-delen indeholder oplysninger/data til brug for transmissionssystemet. Indholdet aftales specifik imellem afsender og modtager. Headeroplysninger er altid de samme på alle transaktioner imellem afsender og modtager (med undtagelse af de transaktionsspecifikke oplysninger) Generelt: For standarden gælder følgende overordnede principper: datofelter er i formatet ÅÅÅÅMMDD Fra- og til-datoer er incl. Tidsstempling er i formatet ÅÅÅÅMMDDTTMISS (timer angives i intervallet 00 23) Afsender (master) har ansvaret for at data er konsistente og dermed at forretningsregler er defineret og overholdt (master-slave-forhold - slave gør nøjagtig hvad master beder om). Afsender (master) er således også ansvarligt for sletning af evt. fremtidige records før en master-record kan lukkes Transaktioner afsendes med det samme til slave, når aktion er foretaget i master-system Alle transaktioner har definerede nøgle-felter (markeret med *). Nøgle-felter kan ikke opdateres og benyttes til at styre I(nsert)-, U(pdate)-, D(elete)- og C(lose)-logik (se afsnittet vedr. periodestyring) Ansvaret for opfølning af evt. fejl i modtagelsessystemet påhviler modtageren Al kommunikation til og fra pakkerisystemet går igennem kørselssystemet (da Turnr skal føjes til data) I nummeriske felter skal altid angives en værdi. Såfremt et numerisk felt er mandatory kan værdien 0 (nul) ikke benyttes (skal være et positivt heltal) I nummeriske felter kan ikke angives negative værdier. Valideringsprincip: I alle transaktioner skal (felt-)valideringer ske efter følgende princip/rækkefølge: Format-validering: Indhold af felt skal være i overensstemmelse med angivede datatype og format Simpel-indholds-validering: Indhold af felt skal have en valid værdi i forhold til gyldig periode og/eller aftalte/tilladte værdilister Logisk-indholds-validering: Indhold af felt skal være validt i forhold til logiske relationer med andre data Det påhviler afsender at tilsikre, at transaktionerne er valid og i overensstemmelse med valideringsreglerne. Modtager validerer iht. reglerne. ITIT ver juli 2014 Side 6 af 31

7 Datostyringsprincip: Nogle transaktioner i standarden indeholder oplysninger som er gældende for en specifik dato. For disse transaktioner gælder, at oplysningerne er gældende indtil en ny/anden transaktioner opdaterer eller annullerer oplysningerne. Data i den sidst modtagne transaktion er gældende. Periodestyringsprincip: En del transaktioner i standarden indeholder oplysninger som er gældende for en periode. For disse transaktioner gælder, at oplysningerne er gældende indtil en ny/anden transaktioner opdaterer oplysningerne. Data i den sidst modtagne transaktion er gældende. Følgende dato-definitioner er gældende: Fra-dato: Angiver fra og med hvilken dato oplysninger er gældende Til-dato: Angiver til og med hvilken dato oplysninger er gældende For periodestyrede data er udgangspunktet, at vedligeholdelse kan styres af en markering (ændringskode) i relevante transaktioner, hvor markeringen angiver den ønskede operation hos modtageren. Følgende markeringer er mulige: I (Insert) U (Update) D (Delete) Data i transaktionen indsættes Data med samme fra-dato rettes kun til-dato og/eller øvrige detail-attributter kan være ændret. Sletning af data med samme fra- og til-dato I Bilag 1er der eksempler på operationerne. Ovenstående operationer bygger på princippet om at afsender bestemmer, hvordan data skal gemmes eller med andre ord er afsender master i forhold til modtager. Følgelig giver det mening at afsender altid oplyser om fra-dato i record ved U- og D-trans. Derved sikres en entydig identifikation af, hvilken record der ønskes opdateret hhv. slettet. Konsekvensen heraf er, at det udløser fejl, såfremt fra-dato ikke er ens hos både afsender og modtager. Eks: U-trans. D-trans. Hvis modtager ikke kan finde en record med samme fra-dato, skal modtager reagere/behandle denne fejl. Hvis modtager ikke kan finde en record med samme fra-dato og til-dato, skal modtager reagere/behandle denne fejl. Derudover er der følgende generelle forudsætninger: Master (afsender) har ansvaret for at data er konsistente og dermed at forretningsregler er defineret og overholdt (master-slave-forhold - slave gør nøjagtig hvad master beder om). Nøgle-felter (markeret med #) kan ikke opdateres og benyttes til at styre I(nsert)- og U(pdate)-logik (se nedenstående vedr. periodestyring) Ansvaret for opfølgning af evt. fejl i modtagelsessystemet påhviler afsender, som bliver bekendtgjort med fejlen ved en af modtager returneret fejltransaktion, hvis en sådan er defineret. ITIT ver juli 2014 Side 7 af 31

8 Ordbog/begreber Skal udarbejdes ITIT ver juli 2014 Side 8 af 31

9 Transaktionsdefinitioner Header-angivelser: HEAD FEJL Transaktions-angivelser: 1. DVSO 2. FOKA 3. FOST 4. IFLM 5. IFST 6. LELO 7. LESO 8. PROV 9. PYST 10. UDDO 11. UDKO 12. UDST 13. VORO ITIT ver juli 2014 Side 9 af 31

10 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Valideringer: Header HEAD At kunne angive og beskrive en transaktions afsender, modtager og indhold Afsender skal findes Modtager skal findes Standard skal findes Standard-version skal findes ift. standard Transaktionsforkortelse skal findes ift. standard og standard-version Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Afsender Afsd Ja 5 Alfa. Værdi/indhold aftales imellem afsender og modtager Modtager Modt Ja 5 Alfa. Værdi/indhold aftales imellem afsender og modtager Afsender - tegnsæt AfsdTegnset Ja 6 Værdisæt Standardnavn StandardNavn Ja 6 Alfa Tilladte standarder er SALT2, KISS og ITIT Standard-version StandardVersion Ja 3 Num. Afsender - AfsdSekNr Ja 6 Num. sekvensnummer Afsender - tidstempling AfsdTidsStempling Ja 14 Num. Format er ÅÅÅÅMMDDTT24MISS Afsender - bakke-ident BakkeIdentAfsd Nej 5 Num. Modtager - bakkeident BakkeIdentModt Nej 5 Num. Afsender angiver om modtager skal modtage udgående ekstern transaktion i gammelt eller nyt head erformat Transaktionforkortelse TransForkortelse Ja 4 Alfa. Transaktionslængde TransLaengde Ja 5 Num. Samlet længde af header og transaktion Prioritet Prioritet Nej 1 Num. Værdisæt er 1 9 Fejlkode FejlKode Nej 6 Num. Fejltekst FejlTekst Nej 250 Alfa. Bemærkninger: ITIT ver juli 2014 Side 10 af 31

11 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Distributør/vognmand-stam-oplysninger DVSO ERP ABO TRL On-line At kunne udveksle/angive stamoplysninger på distributører og vognmænd Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa Tilladte værdier er I/U/D Distributør-/vognmandsnummer DistrVgmNr Ja 1 8 Num * Type Type Ja 1 Alfa Tilladte værdier er D(istributør) og V(ognmand) Navn1 Navn1 Ja 30 Alfa Navn2 Navn2 Nej 30 Alfa Navn3 Navn3 Nej 30 Alfa Gade-id GadeId Ja 9 Num BK s nye gadedatabase Husnummer HusNr Ja 4 Num Litra Litra Nej 1 Alfa Tilladte værdier er <blank>, 0-9 og A-Z Etage Etage Nej 2 Alfa Side Side Nej 4 Alfa Telefonnummer1 TlfNr1 Nej 12 Alfa Anbefales til brug for telefonnummer Telefonnummer2 TlfNr2 Nej 12 Alfa Anbefales til brug for mobilnummer Telefonnummer3 TlfNr3 Nej 12 Alfa Anbefales til brug for faxnummer Mail Nej 135 Alfa Hjemmeside Hp Nej 256 Alfa User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: 1 = Såfremt Type er en vognmand skal Distributør/vognmands-numret altid være på 8 cifre, hvor de første er har værdien 530 (kontonummer) ITIT ver juli 2014 Side 11 af 31

12 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: Forhandler-kategori FOKA At udveksle/angive oplysning om en forhandlers kategorier ERP TRL On-line Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Kontonummer * KtoNr Ja 8 Num Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD Forhandler-kategori ForhKat Ja 3 Num. Forhandler-underkæde ForhUndk Ja 5 Num Scanner-kategori ScanKat Nej 1 Alfa. Tilladte værdier er A, B, C, D eller blank/null MagScan MagScan Ja 1 Alfa Tilladte værdier er J/N User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: Det er muligt at feltet Scanner-kategori udgår på længere sigt (hvis Scanner-projektet udgår), men da dette ikke vides på nuværende tidspunkt, og RBS kræver at værdien bliver display et i det nye Kørselsreklamationssystem der laves af TRL, bliver feltet indtil videre nødt til at eksistere i den interne transaktion fra ERP til TRL. ITIT ver juli 2014 Side 12 af 31

13 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: Forhandler-stamoplysninger FOST At udveksle/angive stam oplysninger på en forhandler (adresse m.v.). TRL videresender disse oplysninger til udgivere (primært BRM/POL) via INVN/SNVNtransaktionerne ERP TRL On-line Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Kontonummer * KtoNr Ja 8 Num Adressekode * AdrKd Ja 1 Num. Tilladte værdier er 3 (Alternativ Leveringsadresse) og 4 (Forretningsadresse) Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD Regions-id RegId Ja 9 Num. Lokationsnummer LokaNr Ja 13 Num. Navn1 Navn1 Nej 30 Alfa. Forretningsnavn Navn2 Navn2 Nej 30 Alfa. Navnelinie-1 (typisk Ejer/Kæde-navn) Navn3 Navn3 Nej 30 Alfa. Navnelinie-2 (typisk Kontaktperson) Gade-id GadeId Ja 9 Num. BK s nye gadedatabase Husnummer HusNr Ja 4 Num. Litra Litra Nej 1 Alfa Tilladte værdier er <blank>, 0-9 og A-Z Etage Etage Nej 2 Alfa. Side Side Nej 4 Alfa. Telefonnummer1 TlfNr1 Nej 12 Alfa. Anbefales til brug for forretningstelefonnummer Telefonnummer2 TlfNr2 Nej 12 Alfa. Anbefales til brug for mobilnummer Telefonnummer3 TlfNr3 Nej 12 Alfa. Anbefales til brug for fax-nummer Mail Nej 135 Alfa. Hjemmeside Hp Nej 256 Alfa. Forretningsnummer ButikNr Nej 7 Alfa. Ophørsdato OphoerDato Nej 8 Dato Format er ÅÅÅÅMMDD Datoen skal være >= TilDato Ophørsdato = BFN-ophørsdato OBS: I KØS lægges + 8 dage til aht. retur og afregn. Grossistnummer GrosNr Nej 6 Num. = FakturaDebitor i Ax. Sæsonforhandler SaesonForh Ja 1 Alfa Tilladte værdier er J/N. Retur-ugedage * 1 Ugedage Ja 7 Alfa. Returret er implicit heri: NNNNNNN User Bruger Ja 5 Alfa Opdaterendes user-id 1 = Uger defineres med mandag som første dag og søndag som sidste. Markeringen af ugedage er J/N og angives på positionen svarende til ugedagen (eks. mandag, onsdag og lørdag som aktive, skal vises som JNJNNJN) Bemærkninger: Bemærk at TRL ikke ønsker at abonnere på Betalingsadresser (Adressekode-2) fra ERP, men kun på Adressekode- 3 og 4. Det skal aftales med ERP, om det det er ERP der skal styre dette, eller om det er TRL der i modtagelsesprogrammet blot skal ignorere de øvrige Adressekoder. Det er muligt at den nuværende transaktion Udleveringssted-stam-oplysninger skal udgå som selvstændig transaktion, og indbygges i denne transaktion. ITIT ver juli 2014 Side 13 af 31

14 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: Forhandler-lukninger IFLM ERP TRL Udgivere On-line Beskrivelse: Transaktionnen er den samme som er defineret i KISS ver. 2, dvs: Uddrag fra KISS pr : IFLM - Forhandleroplysninger, midlertidig lukning (BK BRM): TRART 1 kar. Alfanumerisk Transaktionsart KTONR* 8 kar. Numerisk Kontonummer IDATO* 8 kar. Numerisk Ikrafttræd.dato TDATO 8 kar. Numerisk Til-dato LKODE 2 kar. Numerisk Lukkekode RKODE 1 kar. Numerisk Regningskode TEXT 60 kar. Alfanumerisk Fri tekst USER 5 kar. Alfanumerisk Opdaterendes user-id Recordlængde: 93 karakterer. FORMÅL: Er at oprette/ændre en midlertidig lukkeperiode på en forhandler. DEADLINE: Transaktionen skal være BH i hænde senest kl dagen før udkomstdatoen - for søndag dog to dage før (d.v.s. senest fredag kl ). Dato-styring: IDATO og TDATO udfyldes med gyldighedsperiode. Der må ikke eksistere overlap i de angivne lukkeperioder. Der må angives flere fremtidige lukkeperioder. ITIT ver juli 2014 Side 14 af 31

15 Transaktions-navn: Forhandler-standsninger Transaktions-forkortelse: IFST Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: ERP TRL Udgivere On-line Beskrivelse: Transaktionnen er den samme som er defineret i KISS ver. 2, dvs: Uddrag fra KISS pr : IFST - Forhandleroplysninger, standsning af forhandler, (BK BRM): TRART 1 kar. Alfanumerisk Transaktionsart KTONR* 8 kar. Numerisk Kontonummer IDATO* 8 kar. Numerisk Ikrafttræd.dato TDATO 8 kar. Numerisk Til-dato STKOD 2 kar. Numerisk Standsekode USER 5 kar. Alfanumerisk Opdaterendes user-id Recordlængde: 32 karakterer. FORMÅL: Anvendes når en forhandler skal stoppes pga. misligeholdelse af aftaler. DEADLINE: Transaktionen skal være BH i hænde senest kl dagen før udkomstdatoen - for søndag dog to dage før (d.v.s. senest fredag kl ). DATO-STYRING: IDATO og TDATO udfyldes med gyldighedsperiode. Der må ikke eksistere overlap i de angivne standseperioder, der burde ikke kunne findes flere fremtidige standseperioder. Når en standseperiode bliver oprettet (TRART=I) vil STKOD altid være = 2 eller 3, og TDATO vil normalt altid være = (Uendelig). ITIT ver juli 2014 Side 15 af 31

16 Transaktions-navn: Leveringssted-leverance-oplysninger Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: leveringssteder. LELO ERP ABO On-line At kunne udveksle/angive leverance-oplysninger om distributørers kontraktuelle Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Leveringssted-id * LevstId Ja 8 Num Skal altid være på 8 cifre, hvor de 3 første cifre skal være 330 (kontonummer-opbygning) Leverance-nummer * LevNr Ja 1 Num. Tilladte værdier er 1-9 Distributions-art * DistrArt Ja 3 Num. Ugedage * Ugedage Ja 7 Alfa. Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD Servicekrav-tid ServTid Ja 4 Num Format er HHMI ( ) Leverance-procent LevProc Ja 3 Num. User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: 1 = Uger defineres med mandag som første dag og søndag som sidste. Markeringen af ugedage er J/N og angives på positionen svarende til ugedagen (eks. mandag, onsdag og lørdag som aktive, skal vises som JNJNNJN) ITIT ver juli 2014 Side 16 af 31

17 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Leveringssted-stam-oplysninger LESO ERP ABO On-line At kunne udveksle/angive oplysninger om distributørers kontraktuelle leveringssteder. Beskrivelse: Felt-beskirvelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Leveringssted-id * LevstId Ja 8 Num Skal altid være på 8 cifre, hvor de 3 første cifre skal være 330 (kontonummer-opbygning) Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD Kontrakt-aftale Kontrakt Ja 1 Alfa. Værdi skal altid være J Distributør-id DistrId Ja 8 Num. Distributør-område-id DistrOmrId Ja 9 Num. Gade-id GadeId Ja 9 Num. BK s nye gadedatabase Husnummer HusNr Ja 4 Num. Litra Litra Nej 1 Alfa Tilladte værdier er <blank>, 0-9 og A-Z Etage Etage Nej 2 Alfa. Side Side Nej 4 Alfa. User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: Et leveringssted kan ikke skifte distributør ITIT ver juli 2014 Side 17 af 31

18 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Beskrivelse: Produkt-vægt oplysninger PROV ERP ABO TRL On-line At kunne/udveksle angive vægtoplysninger på et produkt på en given udkomstdato Svarer til PRVA i SALT-II Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Produkt-id * ProdId Ja 5 Num. Udkomst-dato * Udkdato Ja 8 Dato Format er ÅÅÅÅMMDD Regions-id * RegId Ja 9 Num. Faktisk-Vægt Vaegt Ja 6 Num. Angives i gram Annulleret Annulleret Ja 1 Alfa Tilladte værdier er J/N User Bruger Ja 5 Alfa Opdaterendes user-id ITIT ver juli 2014 Side 18 af 31

19 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Beskrivelse: Produkt-ydelse-stam-oplysninger PYST ERP ABO TRL On-line At kunne udveksle/angive stamoplysninger på ydelser og produkter. Skal omfatte Salt-II transaktionen PRSO Felt-beskrivelse Skal Pos. Pos. Længde Felttype Bemærkninger angives fra til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Produkt-id * ProdId Ja 5 Num. Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD Udgiver-id UdgId Ja 6 Num. Produkt-navn ProdNavn Ja 30 Alfa. Produkt-forkortelse 1 ProdNavnFork Ja 5 Alfa. Produkt-titel ProdTitel Ja 14 Alfa. Regningstitel Følger-produkt-id FlgProdId Nej 5 Num. Varegruppe Varegrp Ja 6 Alfa. = Produkttype i ABDI & i TRLO (pmag, pavis, ) Produkttype ProdType Nej 10 Alfa Aviser, Magasin, Adresseret, DirectMail Adresseret Adresseret Ja 1 Alfa Tilladte værdier er J/N Labels tilladt? Label Ja 1 Alfa. Tilladte værdier er J/N Depot-produktabonnement DepotProdAbo Ja 1 Alfa Tilladte værdier er J/N Depot-produkt-løssalg DepotProdLoes Ja 1 Alfa Tilladte værdier er J/N Frieksemplar-produktabonnement FriProdAbo Ja 1 Alfa Tilladte værdier er J/N Produkt-i-abonnement ProdAbo Ja 1 Alfa Tilladte værdier er J/N Produkt-i-løssalg ProdLoes Ja 1 Alfa Tilladte værdier er J/N BK-administreretprodukt BkAdminProd Ja 1 Alfa Tilladte værdier er J/N Scanner-produkt ScanProd Ja 1 Alfa Tilladte værdier er J/N Pakke-produkt PakkeProd Ja 1 Alfa Tilladte værdier er J/N Reklamation-produktkørsel ReklProdLoes Ja 1 Alfa Tilladte værdier er J/N Distribueret-produkt DistrProd Ja 1 Alfa Tilladte værdier er J/N Moms-pligtigt-produkt MomsProd Ja 1 Alfa Tilladte værdier er J/N Produkt-sortering ProdSort Nej 5 Num. Faktura-layoutnummer FakLay Nej 2 Num. OplagBestilling OplagBestil Ja 1 Alfa Tilladte værdier er J/N Returret Returret Ja 1 Alfa Tilladte værdier er J/N User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: 1 = Forkortelse skal være unik på tværs af produkter (der tillades kun én forkortelse uanset produkt) Felterne Adresseret og Labels tilladt svarer til adresseringsformerne i SALT-II: A = Labels tilladt Omdeling/adresseret: Budomdeling, hvor bud/distributør påsætter label på produkt B = N i A og C Omdeling/uadresseret: Almindelig budlevering (som det kendes) C = Adresseret Omdeling/adresseret (påtrykt): Almindelig budlevering / udgiver har adresseret produkt ITIT ver juli 2014 Side 19 af 31

20 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Beskrivelse: Udkomst-oplysninger UDKO ERP ABO + TRL On-line At kunne udveksle/angive udkomstoplysninger på et produkt på en given udkomstdato Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Produkt-id * ProdId Ja 5 Num. Udkomst-dato * UdkDato Ja 8 Dato Format er ÅÅÅÅMMDD Annulleret Annulleret Ja 1 Alfa Tilladte værdier er J/N Ordre-dato-til- OrdreDatoLoes Nej 8 Dato Format er ÅÅÅÅMMDD distributions-dato- løssalg Ordre-dato-til- OrdreDatoAbo Nej 8 Dato Format er ÅÅÅÅMMDD distributions-dato- abonnement Omdelings-fra-dato-til- OmdFraDatoAbo Nej 8 Dato Format er ÅÅÅÅMMDD distributions-dato- abonnement Omdelings-til-dato-til- OmdTilDatoAbo Nej 8 Dato Format er ÅÅÅÅMMDD distributions-dato- abonnement Alternativ-produkt-idabonnement AltProdIdAbo Nej 5 Num. Alternativ-udkomstdato-abonnement AltUdkDatoAbo Nej 8 Dato Format er ÅÅÅÅMMDD Bundtstørrelse Bdt Nej 5 Num. Udgave-nummer UdgaveNr Nej 7 Num. Regningsuge RgnUge Nej 6 Num. Format er ÅÅÅÅUU Returuge RetUge Nej 6 Num. Format er ÅÅÅÅUU Forhandler-købspris ForhKoebPris Nej 8 Num Format er KKKKKØØØ Forhandler-udsalgspris ForhUdsPris Nej 8 Num Format er KKKKKØØØ EAN-nummer EanNr Nej 13 Num = Stregkoden i Ax Stregkode Stregkode Nej 18 Alfa = Fuld stregkode i Ax Add-on-kode AddOn Nej 6 5 Alfa Stød-/læg-størrelse StoedLaeg Nej 5 3 Num Feltet er Num3 i SALT-II Vejledende vægt VejlVaegt Nej 6 Num Folieret Folie Ja 1 Alfa Adresse-placering AdrPlads Nej 8 Alfa Modtagelsesdato-afdata-fra-udgiver DataDatoFraUdgAbo Nej 8 Dato Format er ÅÅÅÅMMDD Afsendelsesdato-afdata-til-udgiver DataDatoTilUdgAbo Nej 8 Dato Format er ÅÅÅÅMMDD Overdragelsesdato Overdragelsesdato Nej 8 Dato Format er ÅÅÅÅMMDD SidsteSalgsDato SidsteSalgsDato Nej 8 Dato Format er ÅÅÅÅMMDD Pakkestang-omdeling PakkestangOmd Nej 2 Num Tilladte værdier 1-99 Pakkedata-dato-fra-dist PakDataDatoDist Nej 8 Dato Format er ÅÅÅÅMMDD Pakkedata-dato-tilpakkeri PakDataDatoPakkeri Nej 8 Dato Format er ÅÅÅÅMMDD Pakningsnr_løssalg PakkenrLoes Ja 2 Num Tilladte værdier 0 99 User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: Ad Pakningsnr i Loessalg: Hvis produktet ikke skal pakkes angives værdien 0 ITIT ver juli 2014 Side 20 af 31

21 Transaktions-navn: Transaktions-forkortelse: Afsender: Modtagere: Udvekslingsform: Formål / anvendelse: Udkomst-Distributions-Oplysninger UDDO ERP ABO + TRL On-line At kunne udveksle distributionsoplysninger på et produkt på en given udkomstdato Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Produkt-id * ProdId Ja 5 Num. Udkomst-dato * UdkDato Ja 8 Dato Format er ÅÅÅÅMMDD Annulleret Annulleret Ja 1 Alfa Tilladte værdier er J/N Distributions-dato * DistrDato Ja 8 Dato Format er ÅÅÅÅMMDD Distribution-løssalg DistrLoes Ja 1 Alfa. Tilladte værdier er J/N Distribution-abonnement. DistrAbo Ja 1 Alfa. Tilladte værdier er J/N Køreliste-løsalg KoerlLoes Ja 1 Alfa. Tilladte værdier er J/N Køreliste-abonnement KoerlAbo Ja 1 Alfa. Tilladte værdier er J/N BK-følgeseddel BkFlgSed Ja 1 Alfa. Tilladte værdier er J/N User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: ITIT ver juli 2014 Side 21 af 31

22 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: Udgiver-stam-oplysninger UDST At kunne udveksle/angive stamoplysninger på udgivere ERP ABO TRL On-line Beskrivelse: Felt-beskrivelse XML Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra til Ændringskode Kode Ja 1 Alfa Tilladte værdier er I/U/D Udgiver-id * UdgId Ja 6 Num. Navn UdgNavn Ja 30 Alfa. Navn forkortelse 1 UdgNavnFork Ja 5 Alfa. Koncern_udgiver_id KoncernId Nej 6 Num User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: 1 = Forkortelse skal være unik på tværs af udgivere (der tillades kun én forkortelse uanset udgiver) ITIT ver juli 2014 Side 22 af 31

23 Transaktions-navn: Transaktions-forkortelse: Formål / anvendelse: Afsender: Modtagere: Udvekslingsform: Vognmand-Rute-Oplysninger VORO At udveksle/angive hvilke ruter der er solgt til hvilken vognmand indefor en given periode ERP TRL On-line Beskrivelse: Felt-beskrivelse Xml Skal Pos. Pos. Længde Felttype Bemærkninger tag angives fra Til Ændringskode Kode Ja 1 Alfa. Tilladte værdier er I/U/D Kontonummer * KtoNr Ja 8 Num Skal altid være på 8 cifre, hvor de 3 første cifre skal være530 Rutenummer * RuteNr Ja 10 Num. Fra-dato * FraDato Ja 8 Dato Format er ÅÅÅÅMMDD Til-dato TilDato Nej 8 Dato Format er ÅÅÅÅMMDD User Bruger Ja 5 Alfa Opdaterendes user-id Bemærkninger: Der er kun det planlagte salg af Ruter til Vognmænd, der registreres i ERP (= Kontraktforholdene) der udveksles via denne transaktion til TRL. Hvis Styringsafdelingen under distributionen laver et ikke-planlagt salg af Ruter til Vognmænd, skal dette evt. i en overgangsordning opsamles manuelt (som det sker idag) og indrapportes til ERP via manuelle rutiner/skuffesystemer. ERP skal naturligvis på sigt abonnere på Rute/Turnr-stamdata fra TRL, dette skal evt. i en overgangsordning opsamles manuelt (som det sker idag) og indrapporteres til ERP via manuelle rutiner/skuffesystemer. ITIT ver juli 2014 Side 23 af 31

24 Ændringslog Dato Ændring af Ændringsbeskrivelse ITIT ver udsendt. Reviderede transaktioner og tilføjelse af brødtekst m.m.m. Columbus er også modtager ITIT ver udsendt Transaktionen Udgiver-Stam-Oplysninger har ændret forkortelse til UDGS (havde sammenfald med anden transaktion) Transaktionen Produkttype-stam-oplysninger er udgået (funktionalitet dækkes i stedet af tilføjelse af felt på Produktydelse-stam-oplysninger) Transaktionen Turnummer-stam-oplysninger udgår (forslag var ej heller udarbejdet endeligt) Produkt-stam-oplysninger ændrer navn og forkortelse til Produktydelse-stam-oplysninger hhv. PYSO og har fået tilføjet et felt mere Distributionsprodukt Transaktionen Ydelse-stam-oplysninger udgår (funktionalitet dækkes i stedet af tilføjelse af felt på Produkt-ydelse-stamoplysninger) ITIT ver udsendt internt Transaktionen Produkt-ydelse-stam-oplysninger er tilføjet 4 felter mere - efterleverings-produkt-abonnement, sikkerhedsleveringsprodukt-abonnement, særleverings-produkt-abonnement og momspligtigt-produkt Feltet Distributions-produkt i transaktionen Produkt-ydelse-stamoplysninger har ændret navn til ydelses-produkt Transaktionen Produkt-udkomst-oplysninger er tilføjet 3 felter mere Forhandler-købspris, forhandler-udsalgspris og EAN ITIT ver udsendt internt ITIT ver udsendt. Columbus er også modtager nummer Side 11- Ny transaktion Udleveringssted-leveringssted-relation tilføjet Side 12 Ny transaktion Kalender-undtagelser tilføjet Side 16 Tidligere felter Efterleverings-produkt-abonnement, Sikkerhedsleverings-produkt-abonnement, Særleveringsprodukt udgår Side 16 feltet ydelse ændrer navn til Distribueret-produkt Side 16 feltet Layoutnummer ændrer navn til ERP-layoutnummer Side 17 prisfelter og EAN-nummer tilføjet længde og felttype, samt format på prisfelter Side 24 Nyt felt Initiel-distributør tilføjet Side 28 Feltet Leveringssted-kontonummer udgår Side 30 Ny transaktion Udleveringssted-leveringssted-relation Side 37 Antalsfelter ændret til Nej i skal-angives Side 50 Ny transaktion Kalender-undtagelser Generelt: I alle transaktioner har kolonnen/overskirften Felt skiftet navn til Felt-beskrivelse. Endvidere har alle transaktioner fået tilføjet kolonne XML tag. Side 17 Felterne Forhandler-købspris og Forhandlerudsalgspris har ændret længde til 8 og formatet ændret til KKKKKØØØ. Feltet EAN-nummer har ændret længde til 13 Side 36 Feltet Leveringsnummer har ændret navn til Leverancenummer Side 50 Felt for Dagsforkortelse er udgået ITIT ver udsendt Side 10, 11 og 12 i ver indeholdende oversigter over transaktioner er flyttet ned bagerst i versionen. Oversigt vil senere fremgå an indholdfortegnelse Side 10 HEAD XML-tags ændret grundt allerede kodede/opsatte progammel ITIT ver juli 2014 Side 24 af 31