Copyright

Copyright © 2016-2025 Biometria ekonomisk förening, which is “Copyright Owner” below. All rights reserved by the Copyright Owner under the laws of the United States, Sweden, the European Economic Community, and all states, domestic and foreign. This document may be downloaded and copied provided that all copies retain and display the copyright and any other proprietary notices contained in this document. This document may not be sold, modified, edited, or taken out of context such that it creates a false or misleading statement or impression as to the purpose or use of the specification. Use of this Standard, in accord with the foregoing limited permission, shall not create for the user any rights in or to the copyright, which rights are exclusively reserved to the Copyright Owner.

Biometria, the Confederation of European Paper Industries AISBL ("papiNet"), and the members of all papiNet^® Groups (collectively and individually, "Presenters") make no representations or warranties, express or implied, including, but not limited to, warranties of merchantability, fitness for a particular purpose, title, or noninfringement. The presenters do not make any representation or warranty that the contents of this document are free from error, suitable for any purpose of any user, or that implementation of such contents will not infringe any third party patents, copyrights, trademarks or other rights. By making use of this document, the user assumes all risks and waives all claims against Presenters.

In no event shall Presenters be liable to user (or other person) for direct, indirect, special or consequential damages arising from or related to any use of this document, including, without limitation, lost profits, business interruption, loss of programs, or other data on your information handling system even if Presenters are expressly advised of the possibility of such damages.

Use of Documents in papiNet Implementations

Documents may be used as templates for a papiNet implementation. The Presenters grant the right to modify and edit them to fit an actual implementation project provided all copies display the copyright and any other proprietary notices contained in this document. Such modified documents must not be distributed beyond the trading partners implementing or maintaining a papiNet connection.

Översikt

Detta use case beskriver Biometrias redovisningar och beräkningar för råvaru – och transportaffärer. Transportuppgifter som tillhandahålls av det utförande transportföretaget kan också distribueras ut av Biometria.

Vidare stöds även ett API för hantering av händelsestyrda mätbesked och lagrade mätbesked.

Läsaren behöver vara medveten om att Biometrias gränssnitt förmedlar data om två olika slags affärer; virkesaffären för råvaran samt transportaffären för förflyttningen av råvaran från ett hämtställe till en mottagningsplats.

Läsanvisning

Denna beskrivning läses med fördel tillsammans med Process and Transaction overview (PTO) dokumentet ”SDC Use Case L – Report measured quantities and calculated amounts” härefter refererat som “PTO SDC Use Case L” i det här dokumentet.

Då det står råvara i detta dokument, innebär det råvara för en mottagare. För levererande part kan det vara dennes färdigvara (stockar, grotflis, bränslekross etc) eller biprodukt (spån, cellulosaflis, returträ etc).

Biometrias system VIOL 3 erbjuder gränssnitt för att ta emot respektive skicka information. Dessa integrationsgränssnitt förmedlar data från externa parter till VIOL 3 respektive från VIOL 3 till externa parter. Detta use case beskriver hur motsvarande uppgifter kommer att förmedlas mellan Biometria och externa parter i elektroniska affärsdokument (e-dokument) som följer standarden papiNet, vilken använder märkspråket XML och dokumentscheman. Dessutom finns för detta use case ett s k webb-API som erbjuder funktionalitet för att skapa och hämta mätbesked.             

Begrepp

papiNet-begrepp

papiNet-standardens termer är på engelska och används flitigt i det dokument du just nu läser. Var god referera till dokumentet papiNet Data Dictionary för att se definitionerna för respektive term, exempelvis termerna OrderParty och LogisticsBuyerAgent. Detta uppdateras regelbundet och kan laddas hem från webbplatsen http://www.papiNet.org via menyvalet THE STANDARD → Download Current Version → V2R40 - namespaced version → Documentation. Branschgruppen Forest Wood Supply & Bioproducts inom papiNet har utarbetat verksamhetsregler och publicerat dem i dokumentet FWS Business Rules. Dessa ska följas och kan laddas hem i senaste version på webbplatsen http://www.papiNet.org under menyvalet USER GROUPS → Forest Wood Supply & Bioproducts → Helpful Implementation Material.

Varje e-dokument ska valideras OK mot sitt dokumentschema innan det sänds till VIOL 3. Då det i dokumentet beskrivs att ett e-dokument ”sänds/skickas till VIOL 3” menas att Biometria mottar ett e-dokument i egenskap av TransmissionReceiver.

Produkt

I detta use case förekommer elementet Product i de flesta av Biometrias e-dokument för standarden papiNet. För de produkter och handelssortiment som Biometria klassificerar som ”icke-skogliga” förmedlar Biometria i elementet Product utöver ProductIdentifier och namn (ProductDescription) inte någon annan information än attributet med icke-skoglig produkttyp (OtherProductsType) i elementet OtherProducts.

Roller

Tabell 1 visar de roller som kan användas för involverade aktörer (parter) i detta use case. Med ’papiNet-roll’ avses den PartyType i papiNet som en viss verksamhetsroll i Biometrias system motsvarar.

Biometria verksamhetsroll	PartyType i papiNet
Tjänsteleverantör	ServiceProvider
Råvaruaffären
Juridisk köpare	Buyer
Juridisk säljare	Seller
Köpare	BuyerAgent
Mätande företag	MeasuringParty
Säljare	Supplier
Transportaffären
Administration av logistiktjänster	LogisticsServiceProvider
Köpare	LogisticsBuyerAgent
Transportansvarig råvarupart	LogisticsPlanningParty
Säljare	LogisticsSupplier
Logistikinformationsmottagare	NotifyParty

Tabell 1

 

Biometria agerar i rollen ’Tjänsteleverantör’ (ServiceProvider) och realiserar sina tjänster i systemet VIOL 3.

I detta use case finns för själva råvaruaffären i respektive affärsled aktörer av typ juridisk säljare (Seller), säljare/leverantör (Supplier), köpare (BuyerAgent), juridisk köpare (Buyer) och logistikinformationsmottagare (NotifyParty). Till skillnad från råvaruaffären förekommer i transportaffären i detta use case endast de utförande aktörerna i respektive affärsled och är då aktörer av typ säljare/leverantör (LogisticsSupplier), köpare (LogisticsBuyerAgent) och transportansvarig råvarupart (LogisticsPlanningParty). I båda fallen förekommer även mätande företag (MeasuringParty) och i transportaffären förekommer utförande transportföretag (Carrier) samt aktör som tillhandahåller administration av logistiktjänster (LogisticsServiceProvider).

Seller är den juridiske säljaren i ett givet affärsled om denna skiljer från den utförande säljaren. Supplier respektive LogisticsSupplier är alltid den utförande säljaren i ett givet affärsled. Buyer är alltid juridisk köpare i ett givet affärsled. BuyerAgent respektive LogisticsBuyerAgent utför som ombud köpet på uppdrag av den juridiske köparen i det aktuella affärsledet. Råvaruaffärsparten BuyerAgent är exempelvis en distriktsförvaltning eller en enskild virkesköpare vars virkeshandel ska följas upp separat i virkesredovisningen. BuyerAgent saknas om det är den juridiske köparen som utför köpet med egen identitet, eftersom det då inte finns något ombud. BuyerAgent finns alltid om köpet utförs av en annan aktör inom köparens organisation med eget ID hos Biometria eller av något externt ombud.

Transaktioner och kvittenser

Samarbete mellan processer sker i form av transaktioner för att uppnå en kontrollerad överlämning av ansvar vid övergång mellan olika processer. Med transaktion avses att varje meddelande (t.ex. e-dokument) handskakas med en kvittens för att kunna säkerställa om överlämningen av ansvar mellan processer är korrekt utförd eller ej.

För papiNet-baserade e-dokument används kvittenserna BusinessAcknowledgement och BusinessAcceptance för att kontrollera och styra överlämningen. Dessa kvittenser och deras mekanismer vid överlämningen beskrivs mer detaljerat i dokumentet “Appendix 1, Biometria Technical Communication Guidelines for VIOL 3”.

Beskrivning av processer och deras samverkan via transaktioner 

För varje diagrambild i PTO SDC Use Case L finns här ett motsvarande avsnitt som textuellt förtydligar bilden samt refererar till den/de integrationsfunktion(er) som där kan medverka.

Mottagningsrapport råvara

Integrationssekvensen för detta delmoment visas i dokumentet ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Report acceptance to measure goods – Trade”.

VIOL 3-processen ”Distribute acceptance to measure goods” beskriver en mätning av en leverans med mätmetoden mottagningskontroll (”mottktrl”). Detta leder till en kvantitetsredovisning och där ett e-dokument MeasuringTicket av typen ArrivalTicket med en referens till råvarukontrakt i aktuellt led skapas. E-dokumentet förmedlas till en eller flera av de möjliga prenumeranterna; Buyer, BuyerAgent, Seller, Supplier och/eller NotifyParty. Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement.

Transaktionerna mellan processerna ”Distribute acceptance to measure goods” till ”Update data about acceptance to measure goods” stöds av integrationsfunktionen ’Kvantitet råvara UT’ (se vidare kapitel ’Integrationsfunktioner’).

Redovisning av kvantitet råvara

Integrationssekvensen för detta delmoment visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Report measured quantities and calculated amounts – Trade”.

VIOL 3-processen ”Report quantities for product deal” resulterar i en kvantitetsredovisning för en utförd råvarumätning. Detta leder till att det skapas ett e-dokument MeasuringTicket av typen ArrivalTicket eller av typen MeasuringTicket. Vilken typ som skapas beror på om mätningstjänsten är ersättningsgrundande eller ej. E-dokumentet innehåller en referens till råvarukontrakt och det förmedlas till en eller flera av de möjliga prenumeranterna; Buyer, BuyerAgent, Seller, Supplier och/eller NotifyParty. Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement.

Observera att för varje mätning och därefter utförd kvantitetsredovisning av leveransen skapas det antingen ett e-dokument MeasuringTicket av typen ArrivalTicket eller ett e-dokument MeasuringTicket av typen MeasuringTicket beroende på mätningstjänst.

Transaktionerna mellan processerna ”Report quantities for product deal” till ”Update measured quantity” stöds av integrationsfunktionen ’Kvantitet råvara UT’ (se vidare kapitel ’Integrationsfunktioner’).

Versionshanteringen av redovisningar beskrivs mer fördjupat i kapitlet ”Versionshantering av dokument”.

Kvantitet råvara transport

Integrationssekvensen visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Report measured quantities and calculated amounts Transport”.

Oberoende av vilken mätningstjänst som använts vid råvarumätningen, ersättningsgrundande eller ej för råvaruaffären, betraktas den som ersättningsgrundande i transportaffären. Det leder till att kvantitetsredovisning av råvara transport alltid använder e-dokumentet MeasuringTicket av typen MeasuringTicket med MeasuringTicketContextType="LogisticsService".

För redovisning av kvantitet råvara transport är sekvensen densamma som för den i ”Report measured quantities and calculated amounts - Trade”. Skillnaden är att ”Calculate and report quantities for transport deal” också tar hänsyn till transport vid beräkningen och när e-dokument MeasuringTicket skapas.

Notera att denna kvantitetsredovisning av råvara för transport därför använder samma redovisningsidentitet (MeasuringNumber) och version (VersionNumber) som använts för redovisningen av integrationsfunktionen kvantitet råvara.

Möjliga prenumeranter här är parterna i logistikaffären; LogisticsBuyerAgent och/eller LogisticsSupplier. Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement. Vid prenumeration får alla parter i alla transportaffärsled samma kvantitetsredovisningsidentitet och information.

Transaktionerna mellan processerna ”Calculate and report quantities for transport deal” till ”Update delivered quantity” stöds av integrationsfunktionen ’Kvantitet råvara transport UT’ (se vidare kapitel ’Integrationsfunktioner’).

Versionshanteringen av redovisningar beskrivs mer fördjupat i kapitlet ”Versionshantering av dokument”.

Transportuppgifter

Integrationssekvensen visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Distribute transport details – Transport”.

Transportuppgifter tillhandahålls av det utförande transportföretaget (Carrier) som skickar dessa till ServiceProvider där uppgifterna lagras i processen ”Record shipment data”.

I processen ”Distribute transport details” skapas e-dokumentet ShipmentStatus som innehåller transportuppgifter. E-dokumentet skickas till en eller flera av de möjliga prenumeranterna i alla förekommande transportaffärsled; LogisticsBuyerAgent och/eller LogisticsSupplier. Även LogisticsPlanningParty kan prenumerera på edokumentet ShipmentStatus. Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement.

Observera! Om en tidigare säljare/leverantör av transport (LogisticsSupplier) eller köpare av transport (LogisticsBuyerAgent) ”plockas bort” från transportaffärskedjan är den parten inte längre berättigad att i den rollen få information om ShipmentStatus och tidigare förmedlad information ska ignoreras. Den borttagne parten kommer att i dessa fall få ett borttagningsbesked om denna förändring av ServiceProvider genom att e-dokumentet OtherDocument(Notification) distribueras ut till den parten.

Transaktionerna mellan processerna ”Distribute transport details” till ”Verify Document” stöds av integrationsfunktionen ’Transportuppgifter UT’ (se vidare kapitel ’Integrationsfunktioner’).

Värde råvara

Integrationssekvensen visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Report measured quantities and calculated amounts – Trade”.

Då samtliga värdegrundande mätningar är utförda kan prisräkning utföras i VIOL 3processen ”Calculate product compensation amounts”. I VIOL 3-processen ”Report product compensation amounts” distribueras ett e-dokument MeasuringTicket av typen InvoiceSpecification med MeasuringTicketContextType="Product". Det innehåller värde baserat på de värdegrundande kvantiteter som tidigare förmedlats i MeasuringTicket av typen MeasuringTicket.

Notera att det utförs endast en värderedovisning per råvaruaffärsled för ett mätningsflöde. Vid prenumeration får endast de parter som finns i samma råvaruaffärsled samma värderedovisningsidentitet och information.

E-dokumentet MeasuringTicket av typen InvoiceSpecification innehåller referenser till de värdegrundande mätningarna. Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement.

Transaktionerna mellan processerna ”Report product compensation amounts” till ”Update data for invoicing and reconciliation” stöds av integrationsfunktionen ’Värde råvara UT’ (se vidare kapitel ’Integrationsfunktioner’).

Versionshanteringen av redovisningar beskrivs mer fördjupat i kapitlet ”Versionshantering av dokument”.

Värde transport

Integrationssekvensen visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Report measured quantities and calculated amounts Transport”.

För värdeberäkning av transport gäller att då samtliga transportvärdegrundande mätningar är utförda och transportuppgifter är framtagna, kan prisräkning utföras i processen ”Calculate transport compensation”. Prisberäkningen för värde transport baseras på mätresultat för transport där de värdegrundande kvantiteterna tidigare förmedlats i e-dokument MeasuringTicket av typen MeasuringTicket samt i edokumentet ShipmentStatus för Transportuppgifter.

I processen ”Report transport compensation amounts” distribueras det beräknade transportvärdet i e-dokumentet MeasuringTicket av typen InvoiceSpecification med MeasuringTicketContextType="LogisticsService". Mottagande part kvitterar transaktionen med ett BusinessAcknowledgement.

Notera att det utförs endast en transportvärderedovisning per transportaffärsled för ett mätningsflöde.

Vid prenumeration får endast de parter som finns i samma transportaffärsled samma värderedovisningsidentitet och information.

Transaktionerna mellan processerna ”Report transport compensation amounts” till ”Update data for invoicing and reconciliation” stöds av integrationsfunktionen ’Värde transport UT (se vidare kapitel ’Integrationsfunktioner’).

Versionshanteringen av redovisningar beskrivs mer fördjupat i kapitlet ”Versionshantering av dokument”.             

Mätbesked, skapa och hämta

Integrationssekvensen för detta delmoment visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken ”Measuring note for measured quantities and calculated amounts – Trade”. ’Mätbesked, skapa och hämta’ erbjuder att händelsestyrda mätbesked kan skapas samt att lagrade mätbesked kan hämtas från Biometria av behörig part genom att nyttja API ’Mätbesked’.

Transaktionerna mellan processerna “Set trigger for event-controlled Measuring note” till ”Produce, archive & distribute Measuring note” samt “Download Measuring note” till ”Read Measuring note from archive” stöds av integrationsfunktionen ’Mätbesked, skapa och hämta IN’ (se vidare kapitel ’Integrationsfunktioner’).

Allmänt

Enligt Skogsstyrelsens föreskrifter (SKSFS 2014:11) om virkesmätning 18 § så ska den som utfört virkesmätningen lämna mätbesked till virkessäljaren och virkesköparen inom skälig tid efter mätning av virkespartiet avslutats, om inte säljaren och köparen har avtalat något annat. Dessa föreskrifter är en del i lagstiftningen om virkesmätning (VML).

Mätbeskeden skall innehålla uppgifter om följande:

• Virkets kvantitet med uppdelning på egenskapsklasser
• Det som eventuellt registrerats enligt föreskrift (SKSFS 2014:11) 9 §
• Den som utfört virkesmätningen
• Datum och plats för virkesmätningen
• Uppgifter som identifierar virkespartiet
• Vilken mätmetod inklusive information om eventuella omvandlingstal som tillämpats
• Virkessäljaren och virkesköparen

Med ”kvantitet” menas kvantiteten av den ersättningsgrundande enhet som angetts i förstaledskontraktet. Den kvantitet som ska redovisas på mätbeskedet avser kvantiteten av det angivna måttslaget på förstaledskontraktets rader. Om det på förstaledskontraktet framgår att andra måttslag accepteras kommer kvantiteten av detta måttslag att redovisas på mätbesked, förutsatt att andra måttslag tillämpats vid mätningen.

Mätbesked skapas och redovisas för de förstaledsaffärer som lyder under Skogsstyrelsens föreskrifter, oavsett om säljaren utgörs av en eller flera privata ägare (person) eller en organisation.

Mätbesked avses gälla för avtalsformerna:

• Avverkningsuppdrag
• Leverans
• Leveransrotköp – fast pris
• Leveransrotköp – pris per sortiment
• Skördarmätt uppdrag

Involverade processer visas i ”PTO SDC Use Case L” i diagrambilden med underrubriken "Measuring note for measured quantities and calculated amounts – Trade’’.

Administration av Mätbesked

I processen ’’Administration of Measuring note’’ kan en säljare och/eller köpare förmedla en begäran via VIOL 3-klient till processen ’’Manage Triggers, Distribution & Archive for Measuring note’’ om följande;

Via klient

• Uppdatera inställningar som styr periodicitet för periodvisa mätbesked.
• Ange om avbeställning av mätbesked ska göras eller ändras för den/de organisation(er) som man har behörighet till.

Skapa mätbesked

Om parametern ”Omfattas av VML” = ”Nej” är satt i förstaledskontraktet eller att avtalsformen är ’Rotpost’ skapas inga mätbesked, varför det inte heller är möjligt att ta ställning till någon distribution.

”Skapa mätbesked” innebär att redovisade leveranser sammanställs av VIOL 3 i ett mätbesked och lagras där. Redovisade leveranser kan avse värdeberäknade eller ej värdeberäknade leveranser.

Det innebär dock inte per automatik att mätbeskeden även distribueras. Det går inte att manuellt avstyra funktionen ”skapa mätbesked”. Varje enskilt mätbesked skapas med en unik identitet.

Valet ”Mätbesked” i förstaledskontraktet i kombination med eventuell avbeställning på aktörsnivå i mätbeskedsklienten avgör om mätbesked ska distribueras till köpare och säljare, endast till säljare, eller inte alls.

För att veta vilken sammanställning som ska bearbetas så tittar man på följande: avtalsform, ersättningsgrundande mätning (skördarmätning eller industrimätning) och mätmetod, se bild nedan.

Två typer av händelser kan initiera att ett mätbesked ska skapas;

1. Periodvis, slutet på en definierad periodfrekvens inträffar, tex. vecka/or månader.
2. Begäran om att händelsestyrt mätbesked ska skapas.

 

1. Periodvis

Om inget aktivt val har gjorts i processen ’’Administration of Measuring note’’ är skapandefrekvensen för period förutbestämd till att vara månadsvis. 

När en utgång för en period inträffar i processen ’’Expiry of trigger’’ förmedlas detta till processen ’’Produce, archive & distribute Measuring note’’ där mätbesked skickas ut med redovisning för den period som konfigurerats. 

Ett nytt periodvist mätbesked genereras endast om det kommit nya händelser mot avtalsobjektet (t.ex. nya leveranser, korrigerade leveranser eller nya retro/omprisräkningar) sedan förra gången ett mätbesked genererades. De periodvisa mätbeskeden sammanställs på samma sätt som de händelsestyrda mätbeskeden.

2. Händelsestyrt

I processen ’’Set trigger for event-controlled Measuring note’’ kan en behörig användare förmedla en begäran till processen ’’Produce, archive & distribute Measuring note’’ om att;

• Via klient
  • Skapa ett händelsestyrt mätbesked.

• Via API
  • Skapa ett händelsestyrt mätbesked.

Det finns en automatisk väntetid så att när den löpt ut triggas ett automatiskt skapande (och utskick om det inte är avbeställt) av det händelsestyrda mätbeskedet. Denna väntetid sätts av köparen på aktörsnivå och är valbar från 1 till 365 dygn. Om inget aktivt val görs är den förinställd på 365 dygn. Det innebär alltså att nytt mätbesked skapas efter denna tidpunkt om det finns nya leveranser, korrigerade leveranser eller nya retro-/omprisräkningar även då signal inte har inkommit från köparen.

Ett nytt händelsestyrt mätbesked genereras endast om det kommit nya händelser mot avtalsobjektet. Med nya händelser avses nya leveranser, korrigerade leveranser eller nya retro-/omprisräkningar sedan förra gången ett mätbesked genererades.             

Distribution

Efter att ett mätbesked har skapats lagras det i VIOL 3 såsom stipulerat i bokföringslag och Skogsstyrelsens föreskrifter, varefter det distribueras ut till berörda parter i processen ’’Produce, archive & distribute Measuring note’’.

Enligt Skogsstyrelsens föreskrifter om distribution av mätbesked ska det vara möjligt sända till både säljare och köpare i ett förstaledskontrakt som omfattas av VML.

Distribution till parter sker som;

• Mätbesked i elektroniskt format
• Mätbesked i pappersformat

Distribution till säljare

För Säljare av samtliga aktörstyper är det möjligt att ange en kontraktsspecifik fysisk mätbeskedsadress i förstaledskontraktet.

Om Säljare är av typen ”Aktör – Person” ska det vara möjligt att få sina mätbesked till en digital brevlåda kopplad till sitt personnummer, t ex Kivra^®. I sista hand kommer mätbesked att skickas till en folkbokföringsadress som hämtas från SPAR.

Om Säljare är av typen ”Aktör – Person med GD-nummer” kommer mätbesked att skickas till angiven adress i Aktörsregistret om det inte är angivet någon mätbeskedsadress i förstaledskontraktet. Läs mer om GD-nummer hos Skatteverket.

Om Säljare är av typen ”Aktör – Juridisk enhet” kommer det vara möjligt att få sina mätbesked till en digital brevlåda. Det kommer även vara möjligt att ange en mätbeskedsadress på aktören och som sista alternativ kommer sätesadress i aktörsregistret att användas. Detta om angiven mätbeskedsadress saknas i förstaledskontraktet.

Om Säljare är av typen Aktör – Organisatorisk enhet gäller detsamma som för Aktör – Juridisk enhet med tillägget att om det skulle saknas Gata och nummer, Postnummer och Postort, så ska mätbeskedsadress alternativt sätesadress hämtas från den juridiska enheten.

Då fler än en säljare är angiven på förstaledskontraktet distribuerar Biometria mätbesked till samtliga säljare på förstaledskontraktet och till köparen. Alternativen som finns för distribution till tillagda säljare i förstaledskontraktets fält ”fler säljare” är antingen via digital brevlåda eller per post till folkbokföringsadressen som hämtas från SPAR. På mätbeskedet ska samtliga säljare visualiseras och det ska tydligt framgå att redovisningen, kvantiteter och värde avser total leverans.

 

Prioritering	Aktör - Juridisk enhet	Aktör - Organisatorisk enhet
1	Digital brevlåda kopplad till organisationsnummer (t ex Kivra).	Digital brevlåda kopplad till organisationsnummer (t ex Kivra).
2	Mätbeskedsadress i aktörsregistret	Mätbeskedsadress i aktörsregistret
3	Sätesadress i aktörsregistret	Sätesadress i aktörsregistret
4		Mätbeskedsadress för juridisk enhet i aktörsregistret
5		Sätesadress för juridisk enhet i aktörsregistret

 

Distribution till köpare

För Köpare av typen Aktör – Juridisk enhet och organisatorisk enhet kommer det vara möjligt att få sina mätbesked till en digital brevlåda. Om det inte finns så kommer mätbeskedsadress alternativt sätesadress i aktörsregistret att användas.

Om det för Köpare av typen Aktör – Juridisk enhet saknas Gata och nummer, Postnummer och Postort, så ska mätbeskedsadress alternativt sätesadress hämtas från den juridiska enheten.

Prioritering	Aktör - Juridisk enhet	Aktör - Organisatorisk enhet
1	Digital brevlåda kopplad till organisationsnummer (t ex Kivra®).	Digital brevlåda kopplad till organisationsnummer (t ex Kivra).
2	Mätbeskedsadress i aktörsregistret	Mätbeskedsadress i aktörsregistret
3	Sätesadress i aktörsregistret	Sätesadress i aktörsregistret
4		Mätbeskedsadress för juridisk enhet i aktörsregistret
5		Sätesadress för juridisk enhet i aktörsregistret

 

Utsökning och hämtning av lagrade mätbesked

Mätbesked ska lagras i 8 år i enlighet med bokföringslagen och i dagsläget sker detta av Biometria.

I processen ’’Download Measuring note’’ kan köparen och säljaren i de fall säljaren är en organisation förmedla en begäran (via klient eller API) till processen ’’Read Measuring note from archive’’ om utsökning av lagrade mätbesked.

Via klient

• Utsökning bland arkiverade mätbesked.
• Hämtning av arkiverade mätbesked.

Via API

• Hämtning av arkiverade mätbesked.

Integrationsfunktioner

I detta kapitel summeras och listas de integrationsfunktioner som används i detta use case. Användning av dessa finns omnämnda i föregående kapitel ’Beskrivning av processer och deras samverkan via transaktioner’.

Mer detaljerade beskrivningar av dessa integrationsfunktioner finns i respektive integrationsfunktions specifikationer.

Use case integrationsfunktioner;

• Mätbesked, skapa och hämta IN
• Kvantitet råvara transport UT
• Kvantitet råvara UT
• Transportuppgifter UT
• Värde råvara UT
• Värde transport UT             

Versionshantering av dokument

MeasuringTicket

Varje MeasuringTicket har sitt eget dokumentnummer MeasuringTicketNumber. MeasuringTicketStatus är alltid ”Original” och TransactionHistoryNumber är för dem alltid 1 i detta SDC use case. Det innebär att för en viss leverans skapas flera dokument med olika dokumentnummer som härrör från olika mätmetoder samt skilda dokumentnummer för olika affärsled. Ett dokumentnummer kommer inte att återanvändas av Biometria i någon annan mätning.

I MeasuringTicketSequence förmedlas redovisad information baserad på en mätning jämte uppgifter om informationens version (MeasuringInfoVersion). Den redovisade informationen identifieras med MeasuringNumber. I versionsuppgifterna finns ett versionsnummer (VersionNumber) samt uppgift om huruvida informationen i en version skall betraktas som ny/uppdaterad (@IsVersionCancelled=”No”) eller att informationen skall användas för att nollställa tidigare uppgifter (@IsVersionCancelled=”Yes”). Jämte uppgifterna om informationens version finns uppgift om huruvida alla versioner av redovisad information om en mätning skall betraktas som makulerade (@IsMeasuringInfoCancelled=”Yes”) eller inte (@IsMeasuringInfoCancelled=”No”).

Mottagaren av ett e-dokument får inte bygga upp affärslogik baserat på versionsnumret, annat än att ett högre värde avser nyare redovisad information om en mätning. Biometria vill också att kundföretagen vid sina implementationer beaktar att om någon MesuringTicket blir fördröjd i kommunikationen av något skäl, så innebär det att en senare (nyare) version av en mätning kan ha mottagits av mottagaren innan en tidigare version av mätningen anländer.

Biometria skickar dokumenten, och därmed redovisningsversionerna, till de olika parterna i affären. Eftersom det finns en liten risk att någon part inte läser in en tidigare redovisningsversion, kan Biometria inte garantera att alla parter har samtidig tillgång till alla versioner av en redovisning. Varje kundföretag måste själv bedöma vilka konsekvenser det eventuellt kan få i avstämningar om en affärspart refererar till en tidigare redovisningsversion som man själv inte har läst in.

MeasuringTicket av typen ArrivalTicket eller MeasuringTicket

Versionshanteringen av MeasuringTicket vid rapportering av kvantitetsberäkning sker på följande sätt:

1. Resultatet av en ny mätning tas emot av Biometria från ett mätande företag. En kvantitetsberäkning görs i VIOL 3-processen ”Calculate quantities for product deal”. I VIOL 3processen ”Report quantities for product deal” förmedlas en MeasuringTicket av typen ArrivalTicket eller MeasuringTicket med ett nytt MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber = 1.
   
   
2. I detta e-dokument förmedlas en MeasuringTicketSequence. Den innehåller redovisad information om resultatet av en mätning med en mätmetod avseende en leverans av råvara.
   
   
3. MeasuringNumber är konstruerat av VIOL 3 och är Biometria-unikt för en redovisad mätning och en mätmetod. MeasuringInfoVersion/VersionNumber är konstruerat av VIOL 3, är högre för varje version och ökar i allmänhet med ett värde större än 1.

Versionshanteringen av MeasuringTicket vid rapportering av kvantitetskorrigering sker på följande sätt:

• Mätningen korrigeras i VIOL 3. I VIOL 3-processen ”Calculate quantities for product deal” skapas ett makulerat resultat som förmedlas ut i VIOL 3-processen ”Report quantities for product deal”. Detta resulterar i ett e-dokument med ett nytt MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber = 1.
  
  
• MeasuringNumber är samma som i tidigare skickat e-dokument för mätningen och MeasuringInfoVersion/VersionNumber är högre än i tidigare skickat e-dokument.
  
  
• MeasuringInfoVersion/@IsVersionCancelled är ”Yes”, vilket innebär att uppgifterna i tidigare skickat e-dokument skall användas för att nollställa tidigare uppgifter. Sortiment och kvantiteter redovisas på samma sätt som i tidigare skickat e-dokument.
  
  
• Mätningen med de korrigerade uppgifterna skickas ut i ett nytt e-dokument med ett nytt MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber = 1.
  
  
• MeasuringNumber är samma som i tidigare skickat e-dokument och

MeasuringInfoVersion/VersionNumber är högre än i tidigare skickat e-dokument.

• MeasuringInfoVersion/@IsVersionCancelled är ”No” och informationen om mätningen innehåller de nya korrigerade uppgifterna.

 

MeasuringTicket av typen InvoiceSpecification

Versionshanteringen av MeasuringTicket vid rapportering av värdeberäkning sker på följande sätt:

1. Då alla värdegrundande mätningar är gjorda och resultatet av dessa är förmedlade kan värdeberäkning göras baserat på dessa i VIOL 3-processerna ”Calculate product compensation amounts” och ”Calculate and report quantities for transport deal”. I VIOL 3 processerna ”Report product compensation amounts” och ”Report transport compensation amounts” förmedlas en MeasuringTicket av typen InvoiceSpecification med MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber = 1.
   
   
2. I detta e-dokument förmedlas en MeasuringTicketSequence. Den innehåller information om värdeberäkningen baserat på de värdegrundande kvantitetsredovisningarna.
   
   
3. MeasuringNumber är konstruerat av VIOL 3 och är Biometria-unikt för en mätning och en mätmetod. MeasuringInfoVersion/VersionNumber är konstruerat av VIOL 3, är större för varje version och ökar i allmänhet med ett värde större än 1.

Versionshanteringen av MeasuringTicket vid rapportering av värde orsakat av en kvantitetskorrigering sker på följande sätt:

1. Kvantitet för mätningen korrigeras i VIOL 3. Två MeasuringTicket förmedlas, ett med kvantiteter för nollställning och ett med korrigerade kvantiteter, som beskrivet tidigare i avsnitt 5.1.1 för versionshanteringen av MeasuringTicket vid rapportering av kvantitetskorrigering.
   
   
2. I VIOL 3-processerna ”Calculate product compensation amounts” och ”Calculate transport compensation amounts” beräknas en nollställning av värdet baserat på nollställd kvantitet. I VIOL 3-processerna ”Report product compensation amounts” och ”Report transport compensation amounts” förmedlas en MeasuringTicket(InvoiceSpecification) med ett nytt MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber = 1.
   
   
3. MeasuringNumber är samma som i tidigare skickat e-dokument och MeasuringInfoVersion/VersionNumber är större än i tidigare skickat e-dokument.
   
   
4. MeasuringInfoVersion/@IsVersionCancelled är ”Yes”, vilket innebär att uppgifterna i tidigare skickat e-dokument skall nollställas. Sortiment, kvantiteter och belopp redovisas på samma sätt som i tidigare skickat e-dokument.
   
   
5. Mätningen med de korrigerade uppgifterna skickas ut i en ny MeasuringTicket med ett nytt MeasuringTicketNumber där MeasuringTicketStatus = ”Original” och TransactionHistoryNumber är 1.
   
   
6. MeasuringNumber är samma som i tidigare skickat e-dokument och MeasuringInfoVersion/VersionNumber är större än i tidigare skickat e-dokument.
   
   
7. MeasuringInfoVersion/@IsVersionCancelled är ”No” och informationen innehåller de nya korrigerade uppgifterna.

Versionshanteringen av MeasuringTicket vid rapportering av värde orsakat av en priskorrigering sker på samma sätt som vid en kvantitetskorrigering men med den skillnaden att inga MeasuringTicket med kvantitet för nollställning respektive korrigerad kvantitet kommer att distribueras eftersom kvantiteterna förblir desamma.

ShipmentStatus

E-dokumentet ShipmentStatus är ett statusdokument och beskriver status för en eller flera transportrelaterade händelser vid en viss tidpunkt. Då uppgifterna för en eller flera händelser i ett ShipmentStatus ändras skickar avsändaren ett nytt ShipmentStatus dokument med samma händelser (ShipmentEventIdentifier). Det finns ingen ”StatusType” i ShipmentStatus som i andra papiNet e-dokument för att beskriva om det är ett ersättningsdokument eller ett originaldokument. Det finns inte heller något TransactionHistoryNumber för att tala om vilken version av dokumentet som meddelandet avser, eftersom det är ett dokument som beskriver aktuell status. För att avgöra om ett ShipmentStatus är nyare måste mottagaren beakta ShipmentStatusIssueDate. Den som tar emot ett ShipmentStatus som innehåller samma händelse men har en tidigare ShipmentStatusIssueDate än det ShipmentStatusdokument som mottagaren redan har registrerat i sitt system för denna händelse, ska ignorera det ShipmentStatus-dokument som har det äldre ShipmentStatusIssueDate. Detta följer av papiNet FWS Business Rule FWS_SS_002.

I ett ShipmentStatus är det viktigt att förmedla vilken status informationen, som förmedlas i en händelse, har. Statusen förmedlas i attributet ShipmentStatusShipment/ShipmentEventInformation/@ShipmentEventStatusType på följande sätt:

• Om uppgifterna i händelsen beskriver den första versionen av dessa uppgifter är @ShipmentEventStatusType=”Original”.
• Om uppgifterna i händelsen har annullerats är @ShipmentEventStatusType=”Cancelled”.
• I alla övriga fall är @ShipmentEventStatusType=”Amended”.

Versionshantering av ShipmentStatus vid korrigering av information i VIOL 3 sker på följande sätt:

1. Information om en händelse skapas första gången i VIOL 3:

ServiceProvider skickar ut ett ShipmentStatus som innehåller information om händelsen i ShipmentStatusShipment/ShipmentEventInformation där @ShipmentEventStatusType=”Original”.

2. Informationen om händelsen korrigeras i VIOL 3:

ServiceProvider skickar ut ett nytt dokument av typen ShipmentStatus med ett nytt ShipmentStatusNumber. Dokumentet innehåller en händelse med samma ShipmentStatusShipment/ShipmentEventInformation/ShipmentEventIdentifier och samma uppsättning av ShipmentStatusShipment/ShipmentEventInformation/DocumentReferenceInformation som det senast utskickade originalmeddelandet, men med @ShipmentEventStatusType=”Amended”.

Versionshantering av ShipmentStatus vid annullering av information i VIOL 3 sker på följande sätt:

1. Information om en händelse har tidigare skapats och skickats ut från VIOL 3:

ServiceProvider skickar ut ett ShipmentStatus som innehåller information om händelsen i

ShipmentStatusShipment/ShipmentEventInformation där @ShipmentEventStatusType=”Original” eller ”Amended”.

2. Informationen om händelsen annulleras i VIOL 3:

ServiceProvider skickar ut ett nytt dokument av typen ShipmentStatus med ett nytt

ShipmentStatusNumber. Dokumentet innehåller en händelse med samma

ShipmentStatusShipment/ShipmentEventInformation/ShipmentEventIdentifier samt den uppsättning av referenser i

ShipmentStatusShipment/ShipmentEventInformation/DocumentReferenceInformation som krävs för att koppla händelsen till det senast utskickade originalmeddelandet. Händelsen i det nya dokumentet har @ShipmentEventStatusType=”Cancelled”.

Avgränsningar

Biometrias system VIOL 3 hanterar inte juridiska parter i transportaffären,

LogisticsBuyer och LogisticsSeller. I allmän användning av standarden papiNet anger man inte ombudsrollen LogisticsBuyerAgent då det är den juridiske köparen i transportaffären, LogisticsBuyer, som utför köpet med egen identitet, eftersom det då inte finns något ombud. I e-dokument som skickas till eller från VIOL 3 används däremot alltid LogisticsBuyerAgent även om aktören samtidigt är juridisk köpare.

För transportaffären gäller att Biometrias system VIOL 3 endast tillhandahåller redovisning av transporter som rapporteras till, eller via, Biometrias mätplatsstöd och därigenom registreras i VIOL 3.