15 april 2019
Prenumerera på SFTI

Kommunikation och tredjepartstjänster

Om ni inte redan e-fakturerar och ska införa e-faktura bör ni i stället börja använda PEPPOL som kommunikation.

Hur verifierar jag transportfilen?

Transportprofilen baseras på en delmängd av ebMS (ebXML Message Service). För ebMS finns en Java open-sourcelösning för ebMS som heter Hermes Messaging Gateway v2.0/H2O som är utvecklad av Center for e-Commerce Infrastructure Delvelopment (CECID) vid University of Hong Kong.

SFTI håller ingen egen tjänst för verifiering av transportprofil Bas utan vi hänvisar till referensimplementationer, exempelvis hos CECID; organisation har en fri testtjänst, Swallow, som kan användas för att skicka och ta emot meddelanden.

Alternativ kan vara att först köra överföringar mellan egna sänd- resp mottagningsfunktioner och därefter testköra mot annans ebMS-lösning som del i en införandeprocess. Det finns flera VAN-operatörer som är igång med ebMS eller som håller på att testa. Tullen har kommit långt med utveckling av en egen lösning. Kommersiella produkter med generellt stöd för ebMS finns från bl.a. Axway, Cleo Communications, IBM Websphere, Inois, Sterling Commerce and Xenos group samt en rad lösningar baserade på öppen källkod.

Tekniska kansliet har också en enkel testapplikation/demo som utvecklare kan få tillgång till på begäran (exempel begränsad till viss miljö). Eventuellt kan vi komma att anordna ytterligare någon interoperabilitetsdag om intresse finns.

Vad innebär transportfil Bas?

Transport Profil Bas version 2.0 har tagits fram som en profil (delmängd) av ebXML Message Service Specification Version 2.0, ebMS, se ebMS är utvecklad av UN/CEFACT och OASIS gemensamt.

Transportprofil Bas specificerar överföring av elektroniska meddelanden (som till exempel Svefaktura) med protokollet HTTP/S. Ett meddelande för utväxling byggs upp av två eller flera MIME-delar, där den första är ett kuvert enligt SOAP version 1.1 och de övriga MIME-delarna var och en innehåller en fil med nyttodata (t ex en Svefaktura per MIME-del). Transportprofilen ger även kvittens av mottagande (eller felmeddelande) i samma överföringssession.

Transportprofil Bas har tagits fram för att ge framför allt sändare en enkel och billig kommunikationsmetod med god funktion. Den kan användas direkt mellan säljare och köpare eller vid meddelande­utväxling via tredje part, men det är inte krav att använda den för Svefaktura om säljare eller köpare redan har andra lösningar i drift.

Observera att vi rekommenderar att transportprofilen används tillsammans med samverkansprofilen, men att det kan finnas situationer där användare kör transportprofilen utan samverkansspecifikation eller tillämpar en egen bilateralt överenskommen samverkansspecifikation.

Hur en faktura bör styras (routas) rätt till mottagare?

Först vill vi peka på en princip att arbeta mot: tredjepartstjänster/mellanhänder skall klara av att arbeta med enbart kuvertinformation och inte behöva extrahera adresseringsinformationen ur de elektroniska dokument som skall överföras. Det tekniska argumentet är att elektroniska dokument skall kunna förmedlas utan att förmedlaren har installerat tolkande programvara för just det formatet/den versionen som används (om en tredje part har uppdraget att skapa eller konvertera blir givetvis förutsättningen annan).

Bland specifikationerna i SFTI erbjuds kuverteringsfunktion:

  • Dels genom Transportprofil Bas. Används Transportprofilen tillsammans med Samverkans­specifikationen gäller ISO 2-bokstavs landskod följt av organisations­nummer som primär identifiering av parterna; parterna kan dessutom själva avtala om att använda sekundär parts-ID.
  • Dels genom SBDH, Standard Business Document Header. Här är parterna fria att avtala användning om identifierare inkl utgivare av identifierarna. Se vidare avsnitt ”SFTI Tekniska kuvert”.

Används annat kommunikationsprotokoll blir andra regler för kuvertering och identifiering tillämpliga. Men realiteten är att fortfarande används protokoll som har dåligt stöd för kuverterings-/adresserings­information, och i sådana fallen är förmedlaren (resp mottagaren) hänvisad till att kontrollera identifierande element inne i Svefakturan (motsv).

Tekniska kansliet rekommenderar i sådana lägen att säljares och köpares PartyIdentification används - men samtidigt har önskemålet från användare varit att partskoder inte skulle krävas i Svefakturans Basversion. Därmed uppstår behov av flera olika alternativ:

  • a) använd GS1 GLN i PartyIdentification (från tekniska kansliet förordar vi detta val, notera att även attributet identificationSchemeAgencyID skall användas i detta fall): <cac:PartyIdentification>
    <cac:ID identificationSchemeAgencyID="9">7300010000001</cac:ID></cac:PartyIdentification>
  • b) använd annan avtalad kod i PartyIdentification (några har valt organisationsnr för detta):
    <cac:PartyIdentification>
    <cac:ID>123</cac:ID>
    </cac:PartyIdentification>
  • c) använd partens organisationsnummer enligt officiell registrering, det vill säga i PartyTaxScheme, med inplacering enligt:
    <cac:PartyTaxScheme>
    <cac:CompanyID>5566778899</cac:CompanyID>
    <cac:TaxScheme><cac:ID>SWT</cac:TaxScheme></cac:PartyTaxScheme>
    OBS! Partens momsregistreringsnummer skall undvikas för adresseringssyfte.

Den interna adresseringen hos mottagaren är tänkt att ske med hjälp av beställarreferens 1 (och 2, vid behov). Det är helt upp till köparen att anvisa hur detta skall lösas.

Hur bör vi lösa hanteringen av server-certifikat?

Motivet för användning av SSL är insynsskydd under överföring och stöd för mottagar­identifiering. Transport­profilen kräver ingen teknisk autentisering från avsändaren. Däremot måste e-relationen vara känd och en överenskommelse i någon form vara registrerad hos mottagaren för att Svefakturor ska kunna tas emot. Mottagarens egentliga autentisering av utställaren görs baserat på Svefakturans innehåll och interna rutiner. Mottagaren ska emellertid använda ett server-certifikat så att avsändare kan verifiera att Svefakturan skickats till korrekt mottagare (not – meddelanden skickas på avsändarens risk). Detaljer kring detta får mottagaren lämna.

Det har inte gjorts någon begränsning av certifikatutgivare, även självsignerade certifikat kan användas. Vi menar att länk till server-certifikatet, hellre än textinformation, underlättar för fakturautställare och ger möjlighet till automatisering. Men även en text avsedd som guide till icke-tekniker kan ha ett värde – det bör dock upplevas hanterbart av den som återkommande skickar fakturor och i förhållande till många partners! I fall att Transportprofil Bas skall användas hör information avseende server-certifikatet till det som bör meddelas när en ny relation etableras.

Hur fungerar SFTI tekniska kuvert?

På begäran av några tredjepartsoperatörer har SFTI tagit fram ett tekniskt kuvert, baserat på Standard Business Document Header (SBDH), för att ge möjlighet till bättre buntnings- och adresseringsfunktioner i de fall man använder protokoll (t ex FTP) som saknar inbyggda sådana funktioner. Om man använder SBDH kan man placera ett eller flera XML-meddelanden (till exempel Svefakturor), även dokument av olika typ, i samma tekniska kuvert.

Det tekniska kuvertet skall inte användas om kommunikationsprotokollet har tillfredsställande adresserings- och buntningsfunktioner (som till exempel Transportprofil Bas).

Att tänka på om vi använder tredjepartstjänster för utväxlingen av Svefaktura?

Med tredjepartstjänster menar vi här leverantörer som kontrakterats för att utföra vissa funktioner eller tillföra mervärden vid elektronisk meddelandeutväxling.

Exempel på tredjeparter är operatörer som arbetar med kommunikations- och distributionstjänster, fatkuraväxlar, banker. Förutom rena kommunikationstjänster kan de skapa mervärden genom att överbrygga skilda datanät och protokoll, bidra till ökad säkerhet och tillgänglighet (ofta i samarbete med andra operatörer), överbrygga tekniska meddelandeformat genom konverteringstjänster, erbjuda tjänster för leverantörsanslutning liksom tjänster för à jourhållande/förvaltning av alla handelspartners profiler (identitet, kontaktinformation, format som hanteras, etc). Tjänsterna kan ibland erbjudas av den som levererar affärssystemet men sköts ofta av annan leverantör.

Användning av Svefaktura kräver inte tredjepartstjänster. I synnerhet genom Transportprofil Bas öppnas möjligheten att kommunicera direkt mellan leverantör och köpare.

Det lämnas till var och en att bedöma förhållandet mellan mervärden och åtföljande kostnader när tredjepartsoperatören anlitas. Varje part som deltar i elektronisk handel skall själv få avgöra om tredjepartsoperatör behövs. Den som anlitar en operatör tar också ansvar för operatörens åtgärder (eller brist på åtgärder), liksom för kostnaderna, i förhållande till sina handels­partners. Om tredjepartsoperatören väljer att anlita underleverantör är det rimligt att på motsvarande sätt kräva att tredjeparten tar det fulla ansvaret för sin underleverantör. Om båda de kommersiella parterna använder samma tredjepartsoperatör ligger det på operatören att vara tydlig med vilka åtgärder som utförs för respektive kommersiell part.

Nätverket för elektroniska affärer (NEA) arbetar med att ta fram en vägledning för utformning av avtal med tredjepartstjänster.

Används Transportprofil Bas mellan leverantör och köpare, eller mellan ev operatörer som de anlitar, visas genom utställande av transportkvittens att ett eller flera meddelanden kommit mottagaren till handa på den elektroniska adress som mottagaren anvisat. Används annat protokoll för överföring behöver mottagningspunkt och sätt att dokumentera ansvars­övergången leverantör-köpare dokumenteras. Med flera mellanhänder, och kanske dessutom olika protokoll inblandade, ökar behovet av tydlighet.

Vid förmedling av elektroniska dokument via tredjepartstjänst behöver operatören en enkel och tillförlitlig metod för att fånga information om meddelandenas adressering. I dag är det vanliga förfarandet att operatören läser meddelandena för att därur härleda adressinformation. Detta kräver att operatören kan tolka meddelandeformatet. Vi menar att tredjepartsoperatörer måste avkrävas stöd för meddelandeförmedling baserat på enbart kuvertinformation (se avsnitt ”Förklara hur en faktura bör styras (routas) rätt till mottagare”). Därigenom vinner vi tre saker:

a) om förmedlare inte behöver kunna tolka meddelandeformat blir användare friare att byta såväl förmedlare som meddelande­versioner/-typer;

b) förmedlingstjänsten blir mer generellt användbar, och

c) vi kan kräva integritetsåtaganden av mellanhänder vid elektronisk kommunikation (jämför traditionell post där förmedlaren förväntas att inte läsa eller tolka innehållet!).
Det som här sagts utesluter inte att en part kan anlita sin operatör för meddelandekontroll/formatvalidering om nyttan motiverar kostnaden.

En tredjepartoperatör får inte förändra elektroniska meddelandens innehåll. Konvertering måste ibland tillgripas, men bör om möjligt undvikas. Om det sker får konvertering mellan format endast ske på endera leverantörens eller köparens uppdrag och ansvar.

Problemet vid konvertering är att det sällan går att göra en 1:1-översättning mellan olika meddelandeformat, dvs det är svårt att ”backa” ett konverterat meddelande så att det ursprungliga formatet återställs. Vid konvertering av fakturor är kravet att ursprungsformat skall sparas i fall av informations­förlust (not – Riksarkivet ställer krav på sparande genomgående). Det är därför avgörande om konvertering sker på leverantörens eller köparens uppdrag, då det avgör i vilket format fakturan anses utställd. Konvertering leder även till ett svårlöst revisorskrav, genom att åtgärden förväntas vara spårbar inifrån uppdrags­givarens affärssystem.

Hjälpte informationen på sidan dig?

Tipsa:



Tack för att du hjälper oss!