Specifikation för leverantörsreskontra

Information om gjorda inköp med belopp, köpare- och leverantörsinformation - 2020-10-09

Denna version:: https://lankadedata.se/spec/leverantorsreskontra/1.0
Senaste versionen:: https://lankadedata.se/spec/leverantorsreskontra/
Författare:: Eric Hjelmestam - MetaSolutions AB; Matthias Palmér - MetaSolutions AB; Mathias Axell - MetaSolutions AB
Attribution:: Arbete i Sambruk projekt “REF DATA” https://sambruk.github.io/Open-Accounts-Payable/
Licens:: CC-BY 4.0

1. Introduktion

Med leverantörsreskontra menas uppgifter som återfinns om gjorda inköp såsom värde på inköp, leverantörsnamn, inköpande organisation och identifierare till faktura. I texten nedan används för enkelhets skull ordet “ett inköp” för att benämna detta.

Denna specifikation definierar en enkel tabulär informationsmodell för inköp. Specifikationen innefattar också en beskrivning av hur informationen uttrycks i formatet CSV, JSON och länkade data (RDF). Som grund förutsätts CSV kunna levereras då det är praktiskt format och skapar förutsägbarhet för mottagare av informationen. Det är också ett format som gör datautdrag enklare då snarlika processer ofta finns.

Uttrycket i länkade data återanvänder konstruktioner från andra initiativ och ger därmed en grund för interoperabilitet med data som uttrycks utan kunskap om denna specifikation.

2. Datamodell

Datamodellen är tabulär, där varje rad motsvarar exakt ett inköp och varje kolumn motsvarar en egenskap för detta inköp. 12 kolumner är definierade, där de första 9 är obligatoriska, om köparen är en kommun bör kolumn 12, kommun_id, som innehåller kommunkod anges.

Observation 1Vi väljer att använda beskrivande men korta kolumnnamn som uttrycks med gemener, utan mellanslag (understreck för att separera ord) och utan å, ä och ö. Orsaken till detta är:

Observation 2För en enskild organisation är den första kolumnen (kopare) samma för alla rader. Det kan tyckas onödigt att upprepa detta för varje rad. Alternativet (som valts bort) är att varje mängd inköp måste kompletteras med denna information om datafiler från flera organisationer ska kombineras.

Observation 3Kolumn 2, faktura_nr, är en förutsättning för att den egna organisationen enkelt kunna göra en automatiserad förfrågan i en e-tjänst om begäran av fakturakopia.

Kolumner i datmodellen
#	Kolumnnamn	Värdemängd	Exempel och förklaring
1	kopare	organisationsnummer	Ange organisationsnummer för inköpande organisation [Exempel: "212000-1710" för Skövde kommun.]
2	faktura_nr	heltal eller text	Ange en unik och stabil identifierare för en faktura, förslagsvis det faktiska fakturanummer som finns i ekonomisystemet. Ibland kallar man det också verifikationsnummer. Undvik mellanslag och andra tecken som inte passar bra i en URI (webbadress).
3	leverantor	text	Ange namnet på leverantören. Förslagsvis stor bokstav först och sen gemener, men specifika skrivningar av leverantörers namn bör respekteras bara det sker konsekvent.
4	leverantor_id	organisationsnummer	Ange organisationsnummer för levererande organisation [Exempel: "556036-0793” Saab AB.]
5	forvaltning	text	Ange namn på förvaltningen som har gjort inköpet. Tex "Ekonomikontoret". Förslagsvis stor bokstav först och sen gemener, men specifika skrivningar av förvaltningens namn bör respekteras bara det sker konsekvent.
6	konto_nr	heltal	Ange kontonummer där inköpet har bokats enligt den kontoplan som används tex “64310” för facklitteratur.
7	konto_text	text	Ange texten på konto där inköpet har bokats enligt den kontoplan som används tex “facklitteratur”.
8	belopp	decimaltal	Ange det belopp utan moms som inköpet avser.
9	datum	datum	Ange datum när fakturan registreras enligt “2012-06-14” utan mellanslag.
10	grund	D \| R \| U \| A	Referens till vilken grund inköpet har gjorts på, antingen Direkt, via Ramavtal, Upphandling eller på Annat sätt.
11	avtal	url	Länk som identifierar avtal eller lagrum som grund för inköp, använd i första hand webbadresser som inleds med http:// eller https://.
12	kommun_id	text	Ange SCB:s kommunkod för er kommun. Exempel: "0163" för Sollentuna kommun. Observera att en kommunkod måste vara exakt 4 siffror lång, inledande nollor får alltså inte tas bort.

2.1 Förtydlingar kring värdemängder

Alla regular expressions angivna i tabellen nedan (förkortat reg. exp.) förutsätter att de matchar exakt, dvs inga inledande eller eftersläpande tecken tillåts. Det innebär att om uttrycket i tabellen nedan anges som -?\d+ (vilket motsvarar matcha heltal av obegränsad längd, eventuellt med ett minus framför) motsvaras det av det mer kompletta regular expression uttrycket som inleds av /^ och avslutas med $/, dvs /^-?\d+$/.

Kolumner i datmodellen
Värdemängd	Reg. Exp.	Exempel och förklaring
organisationsnummer	\d{6}-\d{4}	Ett organisationsnummer anges med 6+4 siffror med ett bindestreck emellan. Exempelvis: "212000-1710" för Skövde kommun.
heltal	-?\d+	Heltal anges alltid som en radda siffror utan mellanrum eventuellt med ett inledande minus. Se xsd:integer för en längre definition.
decimaltal	-?\d+\.\d+	Decimaltal anges i enlighet med xsd:decimal. Notera att i Sverige används ofta decimalkomma inte punkt. För att vara enhetlig mellan olika dataformat bör decimalpunkt användas istället (på det undviks problem med CSV formatet som använder komma som separator). Den kanoniska representationen i xsd:decimal är påbjuden, dvs inga inledande nollor eller +, samt att man alltid ska ha en siffra innan och efter decimalpunkt. Noll skrivs som 0.0 och ett utelämnat värde tolkas som noll.
datum	\d{4]-\d{2}-\d{2}	Datum skrivs på formatet 2010-01-01 och motsvarar antingen xsd:date. Ingen tid ska anges, inte heller tidszon.
url	-	En URL är en webbadress enligt specifikationen RFC 1738. I detta sammanhang förutsätts schemana http eller https. För webbadresser med speciella tecken tillåts UTF-8 enkodade domäner och pather, se då RFC 3986. Observera att man inte får utelämna schemat, dvs "www.example.com" är inte en tillåten webbadress, däremot är "http://www.example.com" ok. Relativa webbadresser accepteras inte heller. (En fullständig regular expression utelämnas då den är både för omfattande och opedagogisk.)

3. CSV formatet

Det enklaste formatet att stödja är CSV formatet enligt RFC4180. Se exemplet i Appendix A. Det som krävs är att första raden indikerar vilka kolumner som stöds (mellan X och Y stycken):

Utöver det som sägs i RFC4180 krävs alltid att informationen är uttryckt med teckenkodning UTF-8. På grund av att CSV har funnits länge och det finns en uppsjö av olika ramverk och program som inte alla följer RFC4180 så uppmanas man följa devisen:

För den här specifikationen innebär det att implementatörer rekommenderas även stödja semikolonseparerade filer. Orsaken är att Microsoft Excel använder semikolon istället för komma i CSV filer på operativsystem med svenska som default. Detta på grund av att komma används för decimaltal vilket ofta förekommer i CSV-filer vilket skulle kräva en omfattande användning av dubbla citationstecken kring värden. Denna specifikation kräver dock att man använder punkt i decimaltal (se 2.1).

För att särskilja data som är semikolonseparerade från kommaseparerade måste första raden se ut som:

3.2 Åtkomst via HTTP

3.2 Schema

Du som är nöjd med att leverera eller använda data utifrån vad som beskrivs skriftligen i denna specifikation och exemplifieras i appendixen kan ignorera detta avsnitt.

De två sistnämnda kommer sig av att schemat också tillhandahåller saknad information, bland annat hur man konverterar ett visst CSV uttryck till RDF. Mer specifikt innehåller metadatan hur rader konverteras till instanser av . till instanser av schema.orgs Invoice.

Valet av schema.org gjordes eftersom den tillhandahåller en mängd egenskaper som till stor del täcker in skolinformationen. För den som är intresserad går det att hitta andra representationer av skolor som RDF/länkade data.

4. JSON formatet

4.1 Åtkomst via HTTP

Samma gäller som för CSV förutom att content-type ska vara "application/json".

4.2 Schema

5. Beskrivning i datakatalog

För den som vill lägga in sin data som en datamängd i en datakatalog ska man använda sig av W3C rekommendationen DCAT. För svenska behov är det DCAT-AP-SE som gäller. För att göra det enklare att hitta alla datamängder som följer specifikationen på t.ex. dataportal.se är det viktigt att man markerar dessa datamängder. Man bör då göra följande: