HANDLEDNING TILL TEKNISK BILAGA - TB 2007

HANDLEDNING TILL TEKNISK BILAGA - TB 2007

Introduktion

Mallen för den Tekniska Bilagan, TB 2007 är liksom denna handledning framtagna av en arbetsgrupp inom NEA, Nätverket för Elektroniska Affärer, under våren 2007. TB 2007 är en bilaga till NEA:s standardavtal om e-kommunikation (E-kommunikationsavtal) som ibland också kallas EDI-avtal eller Överföringsavtal (Interchange Agreement). Avtalet för e-kommunikation är avsett att tillämpas för automatiserad elektronisk utväxling av strukturerade meddelanden, oavsett formatstandard. De omfattar inte e-postmeddelanden och är inte i första hand avsedda att tillämpas på separata meddelanden av mer tillfällig natur.

Tekniska Bilagans målgrupp är företag och andra organisationer som ska utväxla EDI-meddelanden mellan varandras informationssystem. Ett annat tänkbart användningsområde är för att beställa en tjänst från en tredjepartsleverantör (t.ex. VAN-operatör), som anslutning av ny part eller uppförande av nytt meddelande.

En Teknisk Bilaga skall vara skriftlig, men behöver inte undertecknas.

Mall för den Tekniska Bilagan kan laddas ned från xxx.xxx.xx. Synpunkter och frågor om denna mall kan ställas till xxxxxx@xxx.xx.

TB och Allmänna Bestämmelser

Tabellen visar kopplingen mellan den Tekniska Bilagan (TB) och Allmänna Bestämmelser i E- kommunikationsavtalet.

Avsnitt	Avsnittsrubrik i TB	Referens till Allmänna Bestämmelser
1	Inledning	3.2 och 15.2
2	Kontaktuppgifter	Ej aktuellt
3	EDI-meddelanden	1.2 med flera
4	Format/syntax	3.1
5	Utväxling av EDI-meddelande	3.1, 1.5
6	Kommunikation	3.1, 5.2
7	Identifiering	3.1
8	Utväxlingsloggar	1.4, 1.6, 6.1, 6.2, 8.3, 8.4, 8.5 10.1, 14.3
9	Kvittenser	1.7, 7.1, 8.4, 8.5
10	Säkerhet	10.1
11	Öppethållande	5.1

TB punkt 1 - Inledning

Här ska anges vilka parter som den Tekniska Bilagan upprättas mellan, t.ex. namn på en köpare och en säljare. Det ska framgå om det är en ny Teknisk Bilaga, dvs. en ny EDI-relation, eller om det är en uppdatering av en tidigare Teknisk Bilaga. Vid ändringar, t.ex. ett nytt meddelande eller ändring av kontaktuppgifter, är det viktigt att uppdatera TB så att dokumentationen är korrekt. Den gamla bilagan skall därmed upphöra att gälla. En ändring i TB behöver inte innebära att E-kommunikationsavtalet ändras, utan detaljer i ett TB kan i de flesta fall uppdateras oberoende av avtalet. Se också Allmänna Bestämmelser avsnitt 3.2.

TB punkt 2 - Kontaktuppgifter

Kontaktuppgifter för parterna ska helst vara till en funktion, t.ex. helpdesk, och inte till en person. I de flesta fall räcker det att ange kontakter för applikations- respektive kommunikationsfrågor. I de fall

fler kontaktpersoner behöver anges, repeteras kontaktinformation en gång till. Ett sådant exempel kan vara kontakter för säkerhetsfrågor. I de fall någon av parterna använder en tredjepartsleverantör (t.ex. VAN) anges ofta dennes kontaktinformation under Kommunikationsfrågor.

Exempel på hur tabellen kan fyllas i:

Part 1			Part 2
Applikationsfrågor:			Applikationsfrågor:
Kontakt:	Orderkontoret		Kontakt:	Inköpsavdelningen
Telefon:	00224466		Telefon:	00000000
Telefon (mobil):	000 0000000		Telefon (mobil):	000 0000000
E-post:	xxxxx@xxxxxxxx.xxx		E-post:	xxxxx@xxxxxx.xx
Kommunikationsfrågor:			Kommunikationsfrågor
Kontakt:	Helpdesk hos XYZ-data AB		Kontakt:	Intern IT-service
Telefon:	1234567		Telefon:	0000000
Telefon (mobil):	0000000000		Telefon (mobil):	000000000
E-post:	xxxxxxx@xxx-xxxx.xxx		E-post:	Xx-xxxxxxx@xxxxxx.xx

TB punkt 3 – EDI-meddelanden

Med Standardiserad process menas en viss process eller scenario där man utväxlar EDI-meddelanden mellan två parters informationssystem enligt en modell framtagen av en branschorganisation eller liknande instans, t.ex. BEAst, GS1, Odette, PapiNet och SFTI. EDI-meddelande är benämningen på den information, transaktion, som skickas mellan parterna, t.ex. en Bokning, Leveransavisering eller Faktura. Meddelandebeskrivningar kan vara framtagna av den ena parten eller av parterna gemensamt, men bygger i många fall på en etablerad meddelandebeskrivning (ibland kallat MIG, Message Implementation Guideline) som är framtagen av en branschorganisation. Det rekommenderas att meddelandebeskrivningar dokumenteras och att de blir en underbilaga till den Tekniska Bilagan.

Standard är i de flesta fall Edifact eller XML.

Exempel på hur tabellen kan fyllas i:

Standardiserad process	EDI-Meddelande	Meddelande- beskrivning	Beteckning	Standard	Avsändare	Under- bilaga nr.
Supply chain	Fakturaspecifikation	PapiNet, ver. 2.31	Message: Delivery- MessageWood Type: PackingSpecification	XML ver. 1.0	Part 1	1
Supply chain	Leveransplan	Odette	DELFOR	Edifact D.03A	Part 1	1
Avrop mot ramavtal, ESAP 6	Affärstransaktion Pris- och sortiment- lista. Ny/ersättning	AT 6.1.1, ver. 2.30		UN/Edifact, D.96A, EAN006	Part 1	1
Forecast process	Notify of Bill of material	RosettaNet ver. 4.1	PIP 2C8	XML DTD	Part 1	1

TB punkt 4 – Format och syntax

I praktiken är det nästan uteslutande Edifact eller XML som används som formatstandard, men det kan även förekomma andra standarder och även interna format, s.k. inhouseformat. I tabellens exempel definieras två vanligt förekommande val för format- och syntaxparametrar, det ena med Edifact och det andra med XML som formatstandard.

	Regel - Ex 1: Edifact	Regel - Ex 2: XML
Syntax och version	ISO 9735, ver. 3	Schema, XSD från W3C från 2002
Gränstecken	UNA:+.? '	Ej aktuellt

Teckenmängd	UNOC	Ej aktuellt
Teckenrepresentation	ISO 8859-1	UTF-8

TB punkt 5 - Utväxling av EDI-meddelande

Olika parter kan ha olika stöd för hur EDI-meddelanden och filer kan paketeras, hanteras och överföras. Det är inte ovanligt att det förekommer begränsningar eller önskemål, t.ex. att man inte ska skicka olika meddelandetyper i samma överföring. När det förekommer sådana begränsningar ska de därför dokumenteras. De val som finns i tabellen är olika relevanta i olika formatstandarder.

Förklaringar till tabellens innehåll:

▪ Med Överföring menas en fil som innehåller ett eller flera EDI-meddelanden, t.ex. många beställningar i en och samma överföring. Överföringsidentiteten blir densamma för alla EDI- meddelanden.

▪ I vissa fall kan EDI-meddelanden vara av olika meddelandetyp, dvs. man blandar t.ex. beställningar, fakturor och andra meddelandetyper i en och samma överföring.

▪ Med Utväxlad fil menas att man skickar flera överföringar i samma fil (t.ex. mer än en UNB-nivå i filen), dvs. att flera överföringar/filer skickas i samma utväxlingsfil.

TB punkt 6 - Kommunikation

Under denna punkt dokumenteras vilka kommunikationsuppgifter som gäller för gränssnittet mellan parterna. Kommunikationsadresser, liksom andra kommunikations- och säkerhetsparametrar, utväxlas av praktiska skäl ofta i samband med anslutning. Om det endast är någon enstaka kommunikations- uppgift kan den läggas i tabellen som en ny rad. I de flesta fall är det dock ett flertal uppgifter för kommunikation och då skall dessa dokumenteras i en särskild kommunikationsbilaga. Den hanteras då som en underbilaga till den Tekniska Bilagan.

Att ha en alternativ kommunikationsmetod är att rekommendera för att minska sårbarheten. I sådana fall anges även denna metod. Användning för en alternativ metod kan vara både som reservmetod och för tester. Om det är olika metoder för test och reservmetod, repeteras de tre sista raderna i tabellen.

Exempel på hur tabellen kan fyllas i:

Kommunikationsuppgifter	Ange val
1. Används Tredjepartsleverantör (t.ex. VAN)?	Part 1: NEJ Part 2: XX
2. Om ja, ange leverantör	Part 1:     Part 2: VAN-operatören AB
3. Typ av nättjänst	Internet
4. Kommunikationsprotokoll	AS2
Alternativ kommunikationsmetod
5. Ska alternativ metod anges?	NEJ
6. Om ja ovan, ange typ av nättjänst
7. Om ja ovan, ange kommunikationsprotokoll

TB punkt 7 - Identifiering

För att identifiera parterna vid en överföring krävs unika identiteter och helst enligt en nummerserie som bygger på en internationell standard. Som identitet för Överföring kan användas organisations- nummer, VAT-nummer, lokaliseringsnummer (GLN) eller annan identitet som parterna kommit överens om, t.ex. kund- och leverantörsnummer. Denna identitet finns i en inledande post i överföringen. Vid användning av Edifact sker det i UNB-segmentet och om XML är aktuellt kan det finnas i en SOAP-header.

Genom att använda unika identiteter på en överförings parter blir det möjligt att spåra enskilda

överföringar (ej att förväxla med överföringsreferens). Därutöver kan det vara aktuellt att identifiera andra slags parter som förekommer i de EDI-meddelanden som utväxlas. Om det förekommer flera sådana identiteter anges de genom att fler rader läggs till i tabellen. Även här kan ett nummer användas som identitet, t.ex. lokaliseringsnummer (GLN), kund- eller leverantörsnummer eller annan identitet som parterna kommer överens om. Exempel på identiteter som kan vara aktuella är ett företags olika regioner, butiker, lagerplatser, godsmottagare eller liknande. Denna typ av information kan med fördel också utväxlas i ett särskilt meddelande för partsinformation.

Exempel på hur tabellen kan fyllas i:

Identiteter	Part 1	Part 1
Överföringidentitet (obligatoriskt)	VAT-nummer: SE556666919101	GLN: 7310000000010
Ytterligare identiteter	Part 1	Part 1
Parts/Parters identitet (vid behov, kan repeteras)	Ej aktuellt	Distrikt A: 7310000000027 Distrikt B: 7310000000034 Distrikt C: 7310000000041

TB punkt 8 - Utväxlingsloggar

Loggar kan finnas i olika system som är inblandade för att hantera överföringen av EDI-meddelanden, t.ex. affärssystem, integrationssystem och hos en tredjepartsleverantör. Med logg i det här fallet avses kommunikationssystemet, dvs. det system som utväxlar överföringar med motparten och genererar kvittenser om att EDI-meddelanden kommit fram. När en överföring är loggad innebär det att också ingående EDI-meddelanden i överföringen är loggade. Utväxlingsloggens syfte är inte att säkerställa affärshändelsers spårbarhet eller arkivering enligt bokföringslag, arkivregler eller andra tillämpliga lagrum (hit räknas även arkiveringskrav vid konvertering med informationsförlust), utan detta måste lösas av respektive part i berörda applikationer. Observera att olika systemleverantörer benämner loggfunktioner på olika sätt. Definitionerna i detta dokument har ändrats sedan den förra utgåvan av Teknisk Bilaga (TB 2004).

Loggning skall ske både vid sändande och mottagande av överföringar. Enligt Allmänna Bestämmelser gäller att en överföring, och däri ingående EDI-meddelanden, anses sänd när den loggats som sänd i sändande parts Utväxlingslogg. På motsvarande sätt anses den ha kommit mottagaren till handa när den loggats som mottagen i mottagarens Utväxlingslogg. I de fall kvittens överenskommits, vilket starkt rekommenderas, gäller det istället när kvittens skickats. Det innebär att sändarens ansvar för överföringen med dess ingående EDI-meddelanden gäller fram till loggning av överföring i mottagarens Utväxlingslogg respektive mottagarens sändning av kvittens. Se även Allmänna bestämmelser och avsnitt ”9. Kvittenser”.

I de fall kvittenser inte används är det därför viktigt att veta att avsändaren av meddelandet inte har kännedom om meddelandet kommit fram och vet därmed inte om ansvaret övergått till mottagaren. Det är därför en stark rekommendation att kvittenser används. Avsändaren av meddelandet bör också bevaka att denne verkligen får en kvittens från mottagaren. Observera att om kvittensen skulle försvinna på vägen har ansvaret för meddelandet ändå övergått till mottagaren när denne loggat mottagandet och skickat tillbaka en kvittens.

Med Överföringslogg menas en logg där man sparar uppgifter om vad som utväxlats. De uppgifter som bör förekomma är följande:

▪ Avsändare. Identitet på överföringens avsändare.

▪ Mottagare. Identitet på överföringens mottagare.

▪ Datum och Tid. Tidsstämpling som visar när överföringen skapades respektive togs emot.

▪ Meddelandetyp. Visar typ av EDI-meddelande, t.ex. en beställning.

▪ Överföringsreferens. En unik identitet för överföringen som skapas av överföringens avsändare.

▪ Status. Visar om kvittens erhållits och är en information som bör arkiveras under rimlig tid för att kunna verifiera om EDI-meddelande kommit fram eller ej.

Med Meddelandelogg avses en funktion där de transaktioner som skickats eller mottagits arkiveras, av legala skäl eller för att möjliggöra omsändning. Tiden för att lagra denna typ av information kan variera mycket beroende på sammanhang och typ av meddelande.

En annan typ av logg är händelseloggen, men i de flesta fall avses med detta en intern systemlogg.

TB punkt 9 - Kvittenser

Kvittenser är en viktig driftfunktion som alltid bör finnas med vid utväxling av EDI-meddelanden för att undvika driftstörningar. Det ger avsändare och mottagare kontroll på att meddelanden kommit fram. Samtidigt är kvittensen beviset för att ansvaret för det meddelande som skickats har övergått från den ena parten till den andra. I de flesta fall används den typ av kvittenser som finns inom ramarna för det valda kommunikationsprotokollet. Kvittenser kan vara både positiva och negativa.

Det kan också skilja mellan hur parter väljer att generera kvittenser. Det vanligaste är att det sker direkt efter att ett meddelande mottagits till partens kommunikationssystem, men det förekommer också att kvittensen genereras efter någon form av kontroll, t.ex. syntaxkontroll. Det är därför viktigt att överenskomma och dokumentera hur kvittenser ska genereras. Det förekommer också att man har olika slags kvittenser för olika meddelandetyper och i sådana fall repeteras raderna i TB för varje typ av kvittens.

I exemplet på hur tabellen kan fyllas i skickar Part 2 kvittens både direkt efter mottagande och efter kontroll. Tabellen har därför repeterats.

Kvittens	Part 1	Part 2
Typ av kvittens	EERP (OFTP)	EERP (OFTP)
Ange när kvittens skickas (t.ex. efter mottagande eller kontroll)	Efter mottagande	Efter mottagande
Ange tidpunkt för kvittens	Senast efter 5 minuter	Senast efter 5 minuter
Ange vad kvittensen täcker (t.ex. alla eller vissa meddelandetyper)	Alla meddelandetyper	Alla meddelanden utom Faktura
Kvittens två
Typ av kvittens	Nej	EERP (OFTP)
Ange när kvittens skickas		Efter syntaxkontroll
Ange tidpunkt för kvittens		Senast efter 15 minuter
Ange vad kvittensen täcker		Faktura

TB punkt 10 - Säkerhet

Säkerhet vid e-affärer är ett brett begrepp men i den Tekniska Bilagan är det bara vissa funktioner som behöver definieras. Därutöver hänvisas i TB till att parterna skall ha funktioner som upprätthåller grundläggande krav.

Med signering menas en teknisk metod för att åstadkomma autenticitet (äkthet), integritet (förändringsskydd) och icke-förnekbarhet. Med kryptering menas en teknisk metod för att åstadkomma konfidentialitet (insynsskydd). Det finns en rad metoder för att uppnå dessa funktioner, t.ex. de som anges som exempel i tabellen nedan.

I de flesta fall behöver information om nycklar och andra säkerhetsparametrar utväxlas för att kunna tillämpa signering och kryptering. Detta görs vid anslutning och kan hanteras som en underbilaga till den Tekniska Bilagan, t.ex. tillsammans med kommunikationsadresser och andra parametrar för kommunikation.

Exempel på hur tabellen kan fyllas i:

Säkerhet	Ja/Nej	Metod
Signering	Ja	PGP
Kryptering	Ja	SSL

TB punkt 11 - Öppethållande

Parterna anger vilka öppettider som gäller, dvs. då systemen är tillgängliga för att ta emot respektive skicka EDI-meddelanden.