Indholdsfortegnelse:



Relaterede dokumenter
Indholdsfortegnelse:

KISS. KISS ver

SelskabMasterKom. Per Kjærulf-Møller ApS 13. november KomTabel-layout. Art: 41 Sendes: Begge veje

Grænseflade til indberetning af institutionsmæssige stamoplysninger til EfterUddannelse.dk

SelskabMasterKom. Danpot KomTabel-layout. Art: 41 Sendes: Begge veje

Håndbog Til CPR services. Bilag 8 GCTP-standard m.m. CPR-kontoret

Håndbog Til CPR services

DK530. Snitfladebeskrivelse mv. for overførsel af erstatningsanmodning fra behandlere til "danmark"

1 Brug af snitfladebeskrivelsen Formål og beskrivelse Hvad er formålet med snitfladen? Beskrivelse af snitfladen...

Nedenstående oversigt viser elementerne i den meddelelse, der skal overføres fra fødeafdeling til kirkekontor/sogn.

Unitel EDI Indbetalingskort advisering August 2003

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Unitel til pc Kommasepareret format for Posteringsdata August 2010

Vejledning til SLS webservice Løbende løndele

Formatbeskrivelse til ERH - Bankens Erhvervsformat (BEC format) Oktober 2005

Navision Stat 7.0. CVR Integration. Overblik. Side 1 af april 2015 ØS/ØSY/MAG

Unitel til pc Kommasepareret format for kreditadvis på indenlandske bankoverførsler September 2007

DKAL Snitflader Masseforsendelse

Incitamentsprogrammer, Filer til banken - Business Online

DK701. Snitfladebeskrivelse mv. om overførsel af erstatnings-anmodning fra Hospitaler til "danmark" 30. april 2002 IT-afdelingen, danmark

Corporate Netbank Posteringsdata ver. 2, 3 og 4 DK August 2015

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade København Ø

Bilag 10. Dataindhold i SUP-databaser. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen

Eksport FI-indbetalinger i Netbanken

Vigtigste funktionstaster Microsoft Dynamics C / NAV 2013

Unitel EDI MT940 Juni Baseret på: SWIFT Standards - Category 9 MT940 Customer Statement Message (januar 2004)

Layout af afstemningsfil til grænsefladekontrol af webservicen SkoleopholdIndberetninger. Beskrivelse af de enkelte felter

1 Brug af feltbeskrivelsen Formål og beskrivelse Hvad er formålet med feltbeskrivelsen? Modtagelse af data...

- P-nummer medtages på niveauerne anvisning og alternativ adresse.

Vejledning til SLS webservice - Afgang

Indholdsfortegnelse. August 2005 Side 1 af 11

RETNINGSLINJER FOR ADRESSEVALIDERING

Bilag 5. Snitflade mellem udtræksprogram og database. Udkast af 12. juni Udarbejdet for. SUP-Styregruppen

Brugervejledning Datavask

Integration af online tilbud

Bekendtgørelse om ændring af bekendtgørelse om ret til sygehusbehandling m.v.

Datatransport Import & Eksport af data Generelt Import/eksport Felter i Import og Eksport... 5

Vejledning - web-baseret indberetningssystem vedr. forebyggende foranstaltninger for udsatte børn og unge.

Indholdsfortegnelse...1 ORDRE Upload/download...2 Opbygning af Ordrefil...3 Ordrehoved...4 Kontaktinformation...6 Ordrelinier...7 Afstemning...

ExternalCalendarServiceForDFDG og PlannerExternalCalendarService

BEK nr 1334 af 27/11/2017 (Gældende) Udskriftsdato: 26. juni 2019

Betalinger til udlandet fra Sverige Business Online

Beskrivelse Tælleværket KEBL9 opdateres ikke når kunden er 'kun mod kontant'.

Indholdsfortegnelse. Faktura upload/download - August 2005 Side 1 af 15

Unitel EDI EDI/4-format: Status- og fejladvis Indpakning af forsendelser fra Unitel EDI. August 2007

Vejledning til SLS webservice - Afgang

STANDARD FOR ELEKTRONISK STATISTIK INDBERETNING - FRAVÆRSSTATISTIK

Teknisk vejledning til AR260 - inkl. valideringsregler

Snitfladebeskrivelse for GO000002Q Betalingsadministration Send sagsoplysninger til KMD Opus Debitor. Version 1.0,

Indberetningsstruktur for Elevplanindberetning

Integration af DocuBizz og Helios

DKAL Snitflader REST Register

VEJLEDNING REGISTRERING AF ANKOMSTTIDER (TRANSPORT & LOGISTIK, INF119) SÆROMDELINGS- OG UDSKYDELSESREGLER

BESTILLING AF MANGLENDE PUBLIKATIONER LEVERINGSREKLAMATIONER KØB KØRSEL

LeverandørService Beskrivelse af elektronisk uddata fra Nets

IDAP manual Analog modul

NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS

Elektronisk signering manual 1.3

Løsningsbeskrivelse til bestilling af SMS-notifikation

Digital post Snitflader Bilag A5 - REST HTTP returkoder Version 6.3

ADK 1.0 KRAVSPECIFIKATION

CPR Centrale Personregister Side 1 af 53

I bekendtgørelse nr. 293 af 27. marts 2017 om ret til sygehusbehandling m.v. foretages følgende ændringer:

Layout af afstemningsfil til grænsefladekontrol af webservicen KostopholdIndberetninger. Beskrivelse af de enkelte felter

- beskrivelse af snitflader

Eksport af data fra Netbank

Ungebasen. Dokumentation af webservices til udveksling af data mellem Ungebasen og et kommunalt vejledningssystem PUBLICPUBLIC PUBLICPUBLICX

AuthorizationCodeService

Anvendelse af dobbelthistorik i GD2

SMS menuen Generelt Rambøll SMS eller Beredskabsalarm er et modul som er udviklet til at sende SMS beskeder til forbrugeren via Blue Idea.

Tlf Fax

Integration af online tilbud

Lokale, norske betalinger Business Online

Snitfladebeskrivelse for Snitfladebeskrivelse STD-8 KMD Boligstøtte Version 1.0.0,

MICROSOFT OUTLOOK 2010

SMS menuen Generelt Rambøll SMS eller Beredskabsalarm er et modul som er udviklet til at sende SMS beskeder til forbrugeren via Blue Idea.

EPJ-Syd SPØRGSMÅL OG SVAR I PRÆKVALIFIKATIONSFASEN FOR UDBUD VEDR. EPJ/PAS

Guideline. EAN-systemet

CPR Centrale Personregister Side 2 af 50

Betalingsservice og indbetalingskort Vejledning for dataleverandør

Efteruddannelse.dk uden EASY-A - Delleverance 4A Hent udbudsoplysninger i EU.dk - Design

Appendix C - Databeskrivelse

Rundskrivelse nr. 09/03

Rapport dannet den: 5. oktober Spil kontrol

OPBYGNING AF INSTRUMENTER. Online Designeren Record ID Felttyper Validering og variabelnavne

Formatbeskrivelse til ERH Bankens Erhvervsformat (BEC format) November 2010

* På startet udvidelse af dropfelter, så der vises sigende ledetekster

OBJEKTKODE Kodeværdi for objekttype Integer(2) 30 Objektkode 30 gælder for planer der knyttes til en lokalplan. Se evt. kodeliste for Plandk2+

XML webservice for pensionsordninger. Version 1.0 Draft A

MixVareMasterKom Bemærkninger: protokol art 47 Protokol til kommunikation af MixVarekartotekets hovedoplysninger fra gartner til DANPOT.

Importere kunderegister

BRUGERVEJLEDNING MAGENTO NEM ORDREBEHANDLING BRUGERVEJLEDNING NEDTÆLLING TIL NÆSTE LEVERING MODUL VERSION Version

Vejledning til SLS webservice Individuelt afregnet pension

KRAVSPECIFIKATION for underretningsstatistik

Call Recorder Apresa Brugermanual

Ferieregnskab (Rapport-ID: 74)

Sådan afbrydes forbindelsen Når du vil afslutte CallPilot-sessionen, skal du trykke 83 for at afbryde forbindelsen eller lægge røret på.

Digital post Snitflader Bilag C Filbaseret Version 6.3

DPR Viderestilling. Grænseflade for klient applikation

Transkript:

ITIT

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

Forord ////////// ITIT ver. 3.0.0 1.juli 2014 Side 3 af 31

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. 3.0.0 1.juli 2014 Side 4 af 31

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. 3.0.0 1.juli 2014 Side 5 af 31

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. 3.0.0 1.juli 2014 Side 6 af 31

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. 3.0.0 1.juli 2014 Side 7 af 31

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

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. 3.0.0 1.juli 2014 Side 9 af 31

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. 3.0.0 1.juli 2014 Side 10 af 31

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 Email 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. 3.0.0 1.juli 2014 Side 11 af 31

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. 3.0.0 1.juli 2014 Side 12 af 31

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 Email 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. 3.0.0 1.juli 2014 Side 13 af 31

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. 10-09-2012: 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. 15.30 dagen før udkomstdatoen - for søndag dog to dage før (d.v.s. senest fredag kl. 15.30). 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. 3.0.0 1.juli 2014 Side 14 af 31

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. 10-09-2012: 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. 15.30 dagen før udkomstdatoen - for søndag dog to dage før (d.v.s. senest fredag kl. 15.30). 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 = 99999999 (Uendelig). ITIT ver. 3.0.0 1.juli 2014 Side 15 af 31

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 (0000 2359) 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. 3.0.0 1.juli 2014 Side 16 af 31

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. 3.0.0 1.juli 2014 Side 17 af 31

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. 3.0.0 1.juli 2014 Side 18 af 31

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. 3.0.0 1.juli 2014 Side 19 af 31

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. 3.0.0 1.juli 2014 Side 20 af 31

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. 3.0.0 1.juli 2014 Side 21 af 31

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. 3.0.0 1.juli 2014 Side 22 af 31

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. 3.0.0 1.juli 2014 Side 23 af 31

Ændringslog Dato Ændring af Ændringsbeskrivelse 2005-06-24 ITIT ver. 0.7.8 udsendt. Reviderede transaktioner og tilføjelse af brødtekst m.m.m. Columbus er også modtager 2005-09-01 ITIT ver. 0.7.9 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) 2005-09-29 ITIT ver. 0.7.10 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- 2005-10-05 ITIT ver. 0.7.11 udsendt internt 2005-10-13 ITIT ver. 0.8.0 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 2005-11-01 ITIT ver. 0.8.1 udsendt Side 10, 11 og 12 i ver. 0.8.0 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. 3.0.0 1.juli 2014 Side 24 af 31