Copyright

Copyright © 2019-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 stödet till transportaffären gällande information om förflyttning av råvara från lastning till mottagningsbesked inför lossning vid mottagningsplatser. Vidare även hantering av transportuppgifter för kostnadsberäkning och redovisning samt fakturaunderlag för transportrelaterade tilläggstjänster. 

Förutsättningar för att råvara lastats och transporterats är dels att det finns en transportorder om att transport ska utföras, dels att det finns information om tillgänglig råvara att lasta. Detta kan ske på många olika sätt, alltifrån telefonsamtal till fullödiga digitala lösningar. 

Dessa förutsättningar hanteras helt och hållet av transportaffärens parter utifrån den information om avtalsobjekt, produktion och destinering av råvara som kan erhållas av Biometria, vilket beskrivs i SDC Use Case H, J och K.

I detta use case behöver läsaren vara medveten om att Biometrias gränssnitt förmedlar data för två olika slags affärer: råvaruaffären för råvaran och transportaffären för förflyttning av råvara.

 

Läsanvisning

Denna beskrivning läses med fördel tillsammans med Process and Transaction Overview (PTO) dokumentet ”SDC Use Case M – Manage data on raw material shipment and information about performed transport”, härefter refererat som “PTO SDC Use Case M” 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.

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 EndUser 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
Mottagare av råvara	EndUser
Mätande företag	MeasuringParty
Transportaffären
Aktör som tillhandahåller administration av logistiktjänster	LogisticsServiceProvider
Aktör som utför lossning av råvara	UnloadingOperator
Ansvarigt transportföretag	OriginalLogisticsSupplier
Befraktare	OriginalLogisticsBuyerAgent
Köpare av transport	LogisticsBuyerAgent
Logistikinformationsmottagare	NotifyParty
Säljare av transport	LogisticsSupplier
Transportansvarig råvarupart	LogisticsPlanningParty
Transportsedelansvarig	OrderParty
Utförande transportföretag	Carrier

Tabell 1

 

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

• I detta use case finns i transportaffären avseende transporttjänster, i respektive transportaffärsled aktörer som är säljare/leverantör (LogisticsSupplier) och köpare (LogisticsBuyerAgent).
• I transportaffärens första affärsled är LogisticsBuyerAgent alltid befraktare och särskiljs i detta användningsfall från övriga köpare med begreppet

OriginalLogisticsBuyerAgent då man behöver tydliggöra att en aktör har rollen befraktare.

• Säljare/leverantör av transporttjänster LogisticsSupplier, är i första affärsledet det ansvariga transportföretaget, och särskiljs i detta användningsfall från övriga säljare/leverantörer genom användning av begreppet
• I verksamhetsprocesser som handlar om utförandet av transport finns även aktörsrollen utförande transportföretag (Carrier) samt aktör som tillhandahåller administration av logistiktjänster (LogisticsServiceProvider). En viss aktör kan ha flera olika roller samtidigt.
• I transportaffären förekommer även i VIOL 3 rollen Transportsedelansvarig

(OrderParty) som används för en aktör som administrerar fakturaunderlaget.

• Aktörer i transportaffären kan även använda sig av partners för planering av transporterna. Sådan partner kallas transportansvarig råvarupart (LogisticsPlanningParty).
• Det kan även förekomma annan partner som behöver delges information om transporter för sin egen informationsbearbetning och informationsspridning. Sådan partner kallad logistikinformationsmottagare (NotifyParty), kan också användas.

Vem som är transportansvarig råvarupart respektive logistikinformationsmottagare i en specifik transportaffär framgår av den transportinstruktion som utfärdats för transportaffären. För närmare beskrivning av transportinstruktionen, se SDC Use Case K.

Vidare förekommer i detta use case även aktören mätande företag (MeasuringParty) som är verksamt vid den mätplats där ekipage och transporterad råvara mäts in, samt aktörerna mottagare av råvara (EndUser) och den aktör som utför lossning av råvara (UnloadingOperator).

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 M finns här ett motsvarande avsnitt som textuellt förtydligar bilden samt refererar till den/de integrationsfunktion(er) som där kan medverka.  

 

DeliveryMessage(DeliveryMessage) för leverans av råvara

Integrationssekvensen visas i dokumentet ”PTO SDC Use Case M” i diagrambilden med underrubriken "Delivery Message for shipped goods, issued by a logistics party".

Sekvensen initieras genom att Carrier, LogisticsSupplier eller LogisticsServiceProvider i transportverksamhetens process ”Issue a Delivery Message” sänder följesedel i form av e-dokumentet DeliveryMessage(DeliveryMessage) till ServiceProvider. E-dokumentet utfärdas vid det tillfälle då en skattad kvantitet av råvara har lastats på lastbärare vid ”startplats transport”. Det kan till exempel handla om timmer som lastats på en timmerbil vid ett avlägg i skogen, sågspån som lastats i en container vid ett sågverk eller timmer som lastats på en järnvägsvagn vid en terminal.

ServiceProvider hanterar dokumentet i processen ”Verify document and store content” och kvitterar transaktionen med ett BusinessAcknowledgement.

ServiceProvider upprättar eller uppdaterar därefter följesedeln i processen ”Process information about pending delivery”, resultatet förmedlas genom e-dokumentet BusinessAcceptance. Sändande part kan välja att uppdatera status och ska kvittera detta genom BusinessAcknowledgement.

Alternativt kan en följesedel registreras in via en VIOL 3-klient vilket åskådliggörs i PTO-dokumentet i diagrambilden med underrubriken "Delivery Message for shipped goods, from Service Provider". När det görs så kan följesedeln kopplas till transportverksamhetens egen identitet på följesedeln genom att ange denna som en referens i klienten.

Syftet med att meddela informationen till ServiceProvider är främst att dess innehåll ska förmedlas till det mätande företaget, men andra parter kan också prenumerera på informationen, se avsnitt 3.2 nedan.

Transaktionerna mellan processerna ’Issue a Delivery Message’ till  ’ Process information about pending delivery’ stödjs av integrationsfunktionen  ’Leveransinnehåll IN’ (se vidare kapitel ’Integrationsfunktioner’).  

DeliveryMessage(DeliveryMessage) för vidarebefordrad information om leverans av råvara

Integrationssekvensen visas i dokumentet ”PTO SDC Use Case M” i diagrambilden med underrubriken "Delivery Message for shipped goods, from Service Provider" i ServiceProviders process ”Distribute data about pending delivery”.

Informationen i det inkomna e-dokumentet förmedlas till mätande företag, MeasuringParty för att företaget ska kunna förbereda sig på att utföra mätning av råvara i processen ”Prepare for measuring”.

Parterna EndUser, OriginalLogisticsBuyerAgent, LogisticsPlanningParty, OriginalLogisticsSupplier samt NotifyParty kan prenumerera på det e-dokument som ServiceProvider kan utfärda med information från det sparade innehållet i följesedeln.

EndUser använder informationen för att mottagningen av råvara ska kunna ske effektivt på mottagningsplatsen i processen ”Prepare for goods arrival”. Transportaffärens parter, OriginalLogisticsBuyerAgent, LogisticsPlanningParty, OriginalLogisticsSupplier samt NotifyParty använder informationen för att till exempel skapa sig möjlighet att hålla reda på tillgänglig volym vid olika väglager, vilket sker i processen “Administrate result of shipped goods”. Eftersom DeliveryMessage kan innehålla flera olika handelssortiment innebär det att flera olika parter med samma roll kan få e-dokumentet.

E-dokumentet DeliveryMessage(DeliveryMessage) ska kvitteras med e-dokumentet BusinessAcknowledgement av den som får dokumentet.

Transaktionerna mellan processerna ’Distribute data about pending delivery’ till ’Administrate result of shipped goods’ stöds av integrationsfunktionen  ’Leveransinnehåll UT’ (se vidare kapitel ’Integrationsfunktioner’).  

ShipmentStatus vid transport av råvara

Integrationssekvensen visas i dokumentet ”PTO SDC Use Case M” i diagrambilden med underrubriken ”Shipment Status for vehicle during transportation, issued by a logistics party”.

Sekvensen initieras genom att Carrier, LogisticsSupplier eller LogisticsServiceProvider i transportverksamhetens process ”Inform about shipment events” sänder in underlag för transportstatus i form av e-dokumentet ShipmentStatus till ServiceProvider. Edokumentet utfärdas vid varje tillfälle då det finns ny information om en transport som planeras ankomma, eller har ankommit, till en mottagningsplats via en mätplats.

ServiceProvider hanterar dokumentet i processen ”Verify document and store content” och kvitterar transaktionen med ett BusinessAcknowledgement. ServiceProvider upprättar eller uppdaterar därefter innehållet i följesedeln i processen ”Process shipment event information”, resultatet förmedlas med edokumentet BusinessAcceptance. Sändande part kan välja att uppdatera status och ska kvittera detta genom BusinessAcknowledgement.

Syftet med att meddela informationen till ServiceProvider är att mätande företag respektive mottagare av råvaran ska få tillgång till insänd information om transporten och därmed kunna förbereda sig på sina respektive arbetsuppgifter.

Ett transportstatus skapas även i samband med registrering av följesedel. /transportstatus via en VIOL 3-klient, vilket åskådliggörs i PTO-dokumentet i diagrambilden med underrubriken "Shipment Status for vehicle during transportation, from Service Provider", se avsnitt 3.4 nedan.

Transaktionerna mellan processerna ’Inform about shipment events’ till ’Process shipment event information’ stödjs av integrationsfunktionen ’Transportstatus IN’ (se vidare kapitel ’Integrationsfunktioner’).  

Information om transport av råvara

Integrationssekvensen visas i PTO-dokumentet i diagrambilden med underrubriken "Shipment Status for vehicle during transportation, from Service Provider" i ServiceProviders process ”Distribute shipment events”.  

Informationen i det inkomna e-dokumentet förmedlas till mätande företag, MeasuringParty, för att företaget ska kunna förbereda sig på att utföra mätning av råvara i processen ”Plan for measuring”.

Parterna EndUser och NotifyParty kan erhålla e-dokumentet ShipmentStatus genom att teckna prenumeration på integrationsfunktionen ”Transportstatus UT” i sina roller i råvaruaffären. Dessa parter använder informationen för att planera mottagningen av råvara på mottagningsplatsen i processen ”Plan for goods arrival”.

E-dokumentet ShipmentStatus ska kvitteras med e-dokumentet BusinessAcknowledgement av den som får dokumentet.

Transaktionerna mellan processerna ’Inform about shipment events’ till ’Process shipment event information’ stödjs av integrationsfunktionen ’Transportstatus UT’ (se vidare kapitel ’Integrationsfunktioner’).  

MeasuringTicket(ReceptionTicket) vid Mottagningsbesked inför lossning

Integrationssekvensen visas i PTO-dokumentet i diagrambilden med underrubriken ”Reception Ticket for arrived goods”.

I processen ”Reception verification of arrived goods” förmedlar det mätande företaget information till ServiceProvider med information och status från utförd mottagningskontroll av en leverans.

Efter att ServiceProvider mottagit denna information i processen ”Manage reception ticket data” skapas ett mottagningsbesked inför lossning som i processen ”Issue reception ticket” skickas till EndUser om en prenumeration finns uppsatt. Syftet är att ge EndUser ett underlag att delge den aktör som utför lossning vid mottagningsplatsen.

Detta besked förmedlas genom E-dokumentet MeasuringTicket av typen ReceptionTicket med MeasuringTicketContextType="LogisticsService".

EndUser hanterar e-dokumentet i processen ”Initiate unloading of arrived goods” och kvitterar transaktionen med ett BusinessAcknowledgement.

Observera! För att EndUser t ex ska kunna bilda sig en uppfattning om på vilka lastbärare som leveransens råvara finns placerad, förutsätts att EndUser har uppsatta prenumerationer för integrationsfunktionerna beskrivna i tidigare kapitel i detta dokument;

• ’DeliveryMessage(DeliveryMessage) för vidarebefordrad information om leverans av råvara’.
• ShipmentStatus för vidarebefordrad ’Information om transport av råvara’.

Transaktionerna mellan processerna ’Issue reception ticket’ till ’Initiate unloading of arrived goods’ stödjs av integrationsfunktionen ’Mottagningsbesked inför lossning UT’ (se vidare kapitel ’Integrationsfunktioner’).  

ShipmentStatus med transportuppgifter för kostnadsberäkning och redovisning

Integrationssekvensen visas i PTO-dokumentet i diagrambilden med underrubriken ”Shipment Status with all properties for calculation of transport costs”.

E-dokumentet ShipmentStatus med transportuppgifter för kostnadsberäkning och redovisning, utfärdas av en part i transportaffären vid den tidpunkt då transportuppgifter för transportvärdeberäkning finns tillgängliga hos transportparten gällande transport av handelssortiment från ett avtalsobjekts avlägg.

Informationen om transportuppgifter förmedlas i e-dokumentets element ShipmentEventInformation med attributet ShipmentEventQualifierType=CostBasisCompleted. E-dokumentet skall skickas till Biometria för råvara som transporteras via mätplats som fått en mätorder från Biometria.

Det primära syftet med att skicka in e-dokumentet till ServiceProvider är att tillhandahålla transportaffärskedjan för redovisning av kvantiteter råvara transport och värde transport som görs till olika parter. Uppgifterna kan också vara underlag för transportvärdeberäkning, i de fall sådan beräkning ska göras.

ServiceProvider hanterar dokumentet i processen ”Verify document and store content” och kvitterar transaktionen med ett BusinessAcknowledgement. ServiceProvider upprättar eller uppdaterar därefter innehållet i följesedeln i processen ”Process cost related information about the shipment”. Besked om huruvida den uppdateringen kunde slutföras eller ej förmedlas i e-dokumentet BusinessAcceptance. Sändande part kan välja att uppdatera status och ska kvittera detta genom BusinessAcknowledgement.

Transaktionerna mellan processerna ’Provide cost related information about the shipment’ till ’Process cost related information about the shipment’ stödjs av integrationsfunktionen ’Underlag transportuppgifter IN’ (se vidare kapitel ’Integrationsfunktioner’).  

 

Invoice(ProForma/ProFormaCreditNote) som fakturaunderlag för transportrelaterade tilläggstjänster

Integrationssekvensen visas i PTO-dokumentet i diagrambilden med underrubriken ”Invoice for additional transport related charges”.

E-dokumentet Invoice(ProForma) och Invoice(ProFormaCreditNote) används som fakturaunderlag för transportrelaterade tilläggstjänster som inte hanteras via leveranser. Exempel på detta är ersättning till entreprenörer som utför arbete på virkesterminaler, transportföretag som utför snöröjning eller åkare som vill erhålla ersättning för väntetid på mottagningsplatsen. Fakturaunderlaget förenklar administrationen då själva fakturahanteringen elimineras. E-dokumentet används i vissa fall även om möjlighet finns att hantera kostnaden via tillägg och avdrag i redovisning av transportaffären i Viol. Skälet är då helt enkelt att befraktaren vill säkerställa en bättre kontroll på de kostnader som uppkommer vid olika aktiviteter.

Parterna i transportaffären ansvarar för att i Viol registrera de uppgifter som ligger till grund för att e-dokumentet Invoice(ProForma) eller Invoice(ProFormaCreditNote) kan utfärdas av ServiceProvider, som i detta fall är Biometria.

E-dokumentet Invoice(ProForma) eller Invoice(ProFormaCreditNote) kvitteras med e-dokumentet BusinessAcknowledgement.

Transaktionerna mellan processerna ’Issue invoice specification for additional transport related charges’ till ’Update data for reconciliation and invoicing’ stöds av integrationsfunktionen ’Fakturaunderlag tilläggstjänster UT’ (se vidare kapitel ’Integrationsfunktioner’).

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;

• Fakturaunderlag tilläggstjänster UT
• Leveransinnehåll IN
• Leveransinnehåll UT
• Mottagningsbesked inför lossning UT
• TransportStatus IN
• TransportStatus UT
• Underlag transportuppgifter IN

Varianter i detta Use Case 

Syftet med varianter är att illustrera för dig som läser hur detta use case kan användas när vissa specifika förutsättningar gäller för processerna och hur detta då resulterar i olika varianter av och innehåll i transaktionerna som då utväxlas mellan processerna. 

Vid behov kan en variant delas upp i flera sekvenser.

Notera att dessa varianter finns ej illustrerade i dokumentet ”PTO SDC Use Case M’’.

Variant M1 – Fakturaunderlag för transportrelaterade tilläggstjänster åt transportköpare Woodstock AB

Följande exempelfiler finns. De beskrivs inte närmare här.

SDCUseCaseM1-Invoice-ProForma-LogisticsService-1-yyyymmdd.xml SDCUseCaseM1-BusinessAcknowledgement-1-yyyymmdd.xml

Variant M2 – Barrmassaved till Granstads massafabrik AB

Transportföretaget Tung transport AB är Carrier och använder ett IT-system för transporter som Skogsbolaget AB Transportavd i egenskap av LogisticsServiceProvider tillhandahåller. Tung transport AB lastar råvara från ett avtalsobjekt för transport till råvarumottagaren Granstads massafabrik AB enligt en transportorder med DeliveryInstructionNumber DITTR-20171201-014 och DeliveryInstructionSequenceNumber 1.

Alla exempelfiler i denna variant antas bli kvitterade (BusinessAcknowledgement) med status Success av mottagaren av respektive e-dokument.

Lastning vid avlägg 1

En trave med barrmassaved lastas på svenskregistrerade lastbilen ABC 124 från avlägg 1 på avtalsobjektet för transport till mottagningsplatsen Granstads massafabrik. Skogsbolaget AB Transportavd skickar som LogisticsServiceProvider ett DeliveryMessage med DeliveryMessageNumber DMSBT20171228-057 till Biometria. Mottagare av råvaran är Granstads massafabrik AB. Signal ingår om att sortimentet är slut på avlägg 1 i samband med denna lastning.

SDCUseCaseM2-DeliveryMessage-DeliveryMessage-1-yyyymmdd.xml

I samband med lastningen skickar Skogsbolaget AB Transportavd också ett ShipmentStatus med ShipmentEventIdentifier STVT20171228-5-1 till Biometria. I detta ges information om att lastning är utförd för DeliveryMessage med DeliveryMessageNumber DMSBT20171228-057 och att transporten efter lastning har avgått med en uppskattad ankomsttidpunkt till slutpunkt transport.  

SDCUseCaseM2-ShipmentStatus-1-yyyymmdd.xml

Biometria använder information från mottaget DeliveryMessage och distribuerar som ServiceProvider ett nytt DeliveryMessage med DeliveryMessageNumber SDCDM0005545 till mottagaren av råvaran (EndUser), Granstads massafabrik AB.

SDCUseCaseM2-DeliveryMessage-DeliveryMessage-2-yyyymmdd.xml

Biometria använder information från mottaget ShipmentStatus och distribuerar som ServiceProvider ett nytt ShipmentStatus med ShipmentEventIdentifier BIOL1687783534096-TTB7R till mottagaren av råvaran (EndUser), Granstads massafabrik AB.

SDCUseCaseM2-ShipmentStatus-3-yyyymmdd.xml

Lastning vid avlägg 2

Ekipaget fortsätter till avlägg 2 och lastar ytterligare två travar med barrmassaved, den ena traven på fordonet ABC 124 och den andra traven på det svenskregistrerade släpet CBA 322. Skogsbolaget AB Transportavd skickar ett DeliveryMessage med DeliveryMessageNumber DMSBT20171228-073 till Biometria.

SDCUseCaseM2-DeliveryMessage-DeliveryMessage-3-yyyymmdd.xml

I samband med lastningen skickas ett ShipmentStatus till Biometria (visas inte med exempelfil).

Biometria använder information från mottaget DeliveryMessage och distribuerar som ServiceProvider ett nytt DeliveryMessage med DeliveryMessageNumber SDCDM0005574 till mottagaren av råvaran (EndUser), Granstads massafabrik AB.

SDCUseCaseM2-DeliveryMessage-DeliveryMessage-4-yyyymmdd.xml

Biometria använder information från mottaget ShipmentStatus och distribuerar ett nytt ShipmentStatus (visas inte med exempelfil).

Ankomst till mätplats

Ekipaget med en lastbil och ett släp anländer till mätplatsen för Granstads massafabrik. I samband med att mottagningskontroll utförs skickar Biometria ett MeasuringTicket(ReceptionTicket) till råvarumottagaren för vidare hantering hos mottagarens truckföretag som skall utföra lossning av den transporterade råvaran. I detta ges information om hur de travar som ingår i DeliveryMessage med

DeliveryMessageNumber DMSBT20171228-073 blivit bedömda i mottagningskontrollen samt att för en av travarna finns information om att provtagning skall utföras för den.

SDCUseCaseM2-MeasuringTicket-ReceptionTicket-LogisticsService-1yyyymmdd.xml

Slutrapport för utförd transport från avlägg 1

Transportföretaget ställer samman detaljer om den utförda transporten som påverkar kostnadsberäkning för transporten. Skogsbolaget AB Transportavd skickar ett ShipmentStatus med ShipmentEventIdentifier TT20171228-055-1-1 till Biometria. I detta ges information om att kostnadsunderlaget är sammanställt för DeliveryMessage med DeliveryMessageNumber DMSBT20171228-057 och att transportuppgifter finns tillhanda.

SDCUseCaseM2-ShipmentStatus-2-yyyymmdd.xml

Slutrapport för utförd transport från avlägg 2

Transportföretaget ställer samman detaljer om den utförda transporten som påverkar kostnadsberäkning för transporten. Skogsbolaget AB Transportavd skickar ett ShipmentStatus till Biometria. I detta ges information om att kostnadsunderlaget är sammanställt för DeliveryMessage med DeliveryMessageNumber DMSBT20171228-073 och att transportuppgifter finns tillhanda (visas inte med exempelfil).

Variant M3 – Samverkan mellan transport och mätning

I denna variant beskrivs hur några olika sekvenser som kan uppstå under transport och mätning av en leverans hanteras med de ingående delarna i SDC Use Case M.

Det finns inga exempelfiler för variant M3.

Förteckning av sekvenser i denna variant.

• Leverans som blir accepterad vid mätning
• Omdirigering av leverans
• Mätningsvägrad leverans
• Mätningsvägrad del av en leverans
• Uppdatera leveransinnehåll
• Omstart av leveransavisering

Leverans som blir accepterad vid mätning

Detta fall beskriver ett normalfall med de steg som leveransavisering innebär för en transportör där transporterad råvara accepteras vid mätning och lossas hos mottagaren.

• Lastning
  • DeliveryMessage skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera råvaran som transporteras.

• Mätning
  • Den transporterade råvaran blir bedömd som leveransgill.
• Lossning
  • ShipmentStatus skickas till VIOL 3 med besked om att den transporterade råvaran har lossats hos mottagaren.
• Inlämning av underlag för transportkostnad
  • ShipmentStatus med CostBasisCompleted för den transporterade råvaran skickas till VIOL 3.

Omdirigering av leverans

Detta fall beskriver de steg som leveransavisering innebär för en transportör där råvara lastas för transport till mottagare A. Transporten blir därefter omdirigerad till mottagare B av transportledaren innan transporten har anlänt mät- och mottagningsplatsen hos mottagare A.

• Lastning
  • DeliveryMessage för mottagare A skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare A.
• Omdirigering begärd av transportledaren
  • DeliveryMessage för mottagare A skickas till VIOL 3 med uppdaterad information om att den lastade råvaran till mottagare A är inställd (DeliveryMessageStatusType=Cancelled).
  • ShipmentStatus skickas till VIOL 3 med information om att transporten av lastade råvaran till mottagare A är inställd (ShipmentStatusType=Cancelled).
  • DeliveryMessage för mottagare B skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare B.

 

Avbruten omdirigering/återupptag av tidigare leveransavisering sker med samma mönster som beskrivs för omdirigering ovan.

Mätningsvägrad leverans

Detta fall beskriver de steg som leveransavisering innebär för en transportör där den transporterade råvaran vid mätning blir bedömd som ”ej leveransgill”.

 

• Lastning
  • DeliveryMessage för mottagare A skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare A.
• Mätning
  • Den transporterade råvaran blir bedömd som ”ej leveransgill”.
• Omdirigering orsakad av mätningsvägran o DeliveryMessage för mottagare A skickas till VIOL 3 med uppdaterad information om att den lastade råvaran till mottagare A är inställd (DeliveryMessageStatusType=Cancelled).
  • ShipmentStatus skickas till VIOL 3 med information om att transporten av lastade råvaran till mottagare A är avvisad (ShipmentStatusType=Rejected).
  • DeliveryMessage för mottagare B skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare B.

Mätningsvägrad del av en leverans

Detta fall beskriver de steg som leveransavisering innebär för en transportör där en delmängd av den transporterade råvaran vid mätning blir bedömd som ”ej leveransgill”.

• Lastning till mottagare A o DeliveryMessage för mottagare A skickas till VIOL 3 med information om lastad råvara. Råvaran är lastad på två lastbärare och totalt tre travar.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare A.
• Mätning hos mottagare A o En de tre travarna med den transporterade råvaran blir bedömd som ”ej leveransgill” till mottagare A.
• Lossning av den leveransgilla delen av råvaran hos mottagare A o DeliveryMessage för mottagare A skickas till VIOL 3 med uppdaterad information om lastad råvara. Den råvaran som inte är leveransgill ingår inte. o ShipmentStatus skickas till VIOL 3 med besked om att den transporterade råvaran har lossats hos mottagare A.
• Inlämning av underlag för transportkostnad o ShipmentStatus med CostBasisCompleted för den transporterade råvaran till mottagare A skickas till VIOL 3.
• Omdirigering till mottagare B av den del av råvaran som inte är leveransgill o DeliveryMessage för mottagare B skickas till VIOL 3 med information om kvarvarande lastad råvara som inte var leveransgill till mottagare A.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare B.
• Mätning hos mottagare B o Den transporterade råvaran blir bedömd som leveransgill till mottagare B.
• Lossning hos mottagare B o ShipmentStatus skickas till VIOL 3 med besked om att den transporterade råvaran har lossats hos mottagare B.
• Inlämning av underlag för transportkostnad o ShipmentStatus med CostBasisCompleted för den transporterade råvaran till mottagare B skickas till VIOL 3.

Uppdatera leveransinnehåll

Detta fall beskriver de steg som leveransavisering innebär för en transportör där information om lastad råvara behöver ändras efter att man har skickat in ett leveransinnehåll. De ändringar som görs i detta fall avser sådant som inte är angivet i den transportorder som transportören har utfört lastning mot. Man kan exempelvis uppdatera uppgifter om vilka travpositioner eller lastbärare ett sortiment har lastats på i leveransen, som ju inte är angivet i förväg i transportordern. Däremot får man exempelvis inte ändra transporterat sortiment till något sortiment som inte redan finns med i samma transportorder.

• Lastning o DeliveryMessage skickas till VIOL 3 med information om lastad råvara.

o ShipmentStatus skickas till VIOL 3 för att avisera råvaran som transporteras.

• Uppdatering av leverans o DeliveryMessage skickas till VIOL 3 med uppdaterad information om lastad råvara.

Mätning och lossning av råvara följer fortsatt enligt beskrivning av respektive fall som sedan följer. Mätning av transporterad råvara utförs med den information som är känd för mätprocessen när första mätoperationen i mätningsflödet startas.

Omstart av leveransavisering

Detta fall beskriver de steg som leveransavisering innebär för en transportör där informationen om lastad och transporterad råvara är felaktig, eller av annat skäl inte är tillgänglig på rätt sätt när mätning skall utföras. Transporterad råvara i denna situation blir ändå bedömd som tillåten att mäta och lossa hos mottagaren.

• Lastning o DeliveryMessage för mottagare A skickas till VIOL 3 med information om lastad råvara.
  • ShipmentStatus skickas till VIOL 3 för att avisera den lastade råvaran till mottagare A.
• Mätning
  • Den transporterade råvaran går inte att mäta utifrån den information som är känd.
• Leveransavisering avbryts o DeliveryMessage för mottagare A skickas till VIOL 3 med uppdaterad information om att leveransen av den lastade råvaran till mottagare A är inställd (DeliveryMessageStatusType=Cancelled).
  • ShipmentStatus skickas till VIOL 3 med information om att transporten av lastade råvaran till mottagare A är inställd (ShipmentStatusType=Cancelled).
• Ny leveransavisering startas o Hantering av information för lastning, lossning och underlag med transportuppgifter för transport av lastad råvara till mottagare A görs med funktioner för Leveransavisering i antingen VIOL 3 eller i det system transportören använt för den ursprungliga leveransaviseringen.

Variant M4 – Vägtransporterad GROT-flis till Storstad energi AB

Transportföretaget Timbertrans har inget IT-system för transporter som använder någon integrationsfunktion i detta use case. Timbertrans är Carrier och skall rapportera uppgifter om utförd vägtransport som senare ska redovisas av VIOL 3.

Storstad energi AB står för mätplatsens IT-system som, utöver stöd för integrationsfunktioner i SDC Use Case N, också har stöd för integrationsfunktionen ”Underlag transportuppgifter IN” i detta use case. Storstad energi AB tillhandahåller i sin roll som LogisticsServiceProvider detta IT-system till Timbertrans för registrering av transportuppgifter som därefter ska nå VIOL 3 via integration.

LogisticsServiceProvider tilldelar råvaruleveransen ett DeliveryMessageNumber.

Alla exempelfiler i denna variant antas bli kvitterade med BusinessAcknowledgement med status Success av mottagaren av respektive e-dokument.

Slutrapport för utförd transport till Storstad energi

I denna exempelfil förekommer bland annat följande detaljer som är specifika för den utförda transporten:

Biometrias identitet på avtalsobjektet: 10003928

Transportmedel: ABC124 (svensk registreringsskylt)

Lastbärare: ABC124 och CBA322 (svenska registreringsskyltar)

Startplats transport: 1

Transportavstånd (angivet): 161,8 km

Utförande transportföretag: 89885-00000 (Timbertrans)

 

LogisticsServiceProvider skickar ett ShipmentStatus med ShipmentEventIdentifier

SEAB20241228-055-1-1 till Biometria. I detta ges information om att kostnadsunderlaget är sammanställt för DeliveryMessage med DeliveryMessageNumber DMSEAB20241228-057.

SDCUseCaseM4-ShipmentStatus-1-yyyymmdd.xml

Avgränsningar

Uppdatering av transportuppgifter för kostnadsberäkning och redovisning

Via insändning av e-dokument till Biometria kan inga förändringar förmedlas avseende transportuppgifter för kostnadsberäkning och redovisning. Detta gäller oavsett om uppgifterna har registrerats direkt i VIOL eller sänts in med ett e-dokument.

Råvara med containertransport

För transportverksamhet som hanterar råvara i container vars identitet inte i förväg har registrerats hos Biometria, krävs att den lastbärare som bär den containern kan identifieras av Biometria. Exempel på lastbärare är släpvagn.

Juridiska affärsparter i transportaffären

Biometria varken hanterar eller registrerar juridiska affärsparter i transportaffären, dvs LogisticsBuyer och LogisticsSeller. I definitionen av standarden papiNet är en LogisticsBuyerAgent ett ombud för den juridiska köparen och alltså inte den juridiske köparen själv. I e-dokument som skickas till eller från Biometria skall däremot alltid rollen LogisticsBuyerAgent användas, även då parten faktiskt är juridisk köpare och inte ett ombud för denne. Det är ett medvetet avsteg från standarden papiNet på grund av att VIOL inte håller uppgift om juridisk köpare i transportaffären.

Registrering av data via Biometrias klientgränssnitt

Uppgifter som kan sändas in med e-dokumenten DeliveryMessage respektive ShipmentStatus enligt avsnitt 3.1 respektive 3.3 kan istället registreras i klientgränssnitt (t ex GUI) som tillhandahålls av Biometria. Den beskrivning som du nu läser omfattar inte registrering via klientgränssnitt eller efterföljande vidarebefordran av informationen när Biometrias klientgränssnitt har använts.