DigiInkoop berichten - Procesmodel Extern

DigiInkoop berichten - Procesmodel Extern

Versie 1.1

Datum Status

14 augustus 2014 Definitief

Definitief | DigiInkoop berichten – Procesmodel (Extern) | 14 augustus 2014

Colofon

Product Versienummer Contact Organisatie

DigiInkoop 1.1 Functioneel beheer DigiInkoop Logius Postbus 96810 2509 JE Den Haag [email protected]

Bijlage(n)

-

Pagina 2 van 20


Inhoud

Colofon .......................................................................................... 2 Inhoud ........................................................................................... 3 1

2

3

Inleiding................................................................................... 4 1.1

Scope ................................................................................... 4

1.2

Leeswijzer ............................................................................ 4

1.3

Gerelateerde documenten ....................................................... 5

Proces ...................................................................................... 6 2.1

Subproces: Van bestelaanvraag tot en met ontvangst ................ 6

2.2

Subproces: Van ontvangst tot en met factuur............................ 8

2.3

Manieren van Factureren ........................................................ 9

Berichten ................................................................................ 10 3.1

Berichtstandaarden .............................................................. 10

3.2

Afspraken, Aannames en Uitgangspunten ............................... 10

3.3 UBL Overheid NL berichten ................................................... 11 3.3.1 Samenhang Partijen en Rollen ......................................... 11 3.3.2 UBL:RequestForQuotation ............................................... 13 3.3.3 UBL:Quotation ............................................................... 13 3.3.4 UBL:RequestForQuotationCancellation .............................. 13 3.3.5 UBL:Order ..................................................................... 13 3.3.6 UBL:OrderResponse ....................................................... 14 3.3.7 UBL:DespatchAdvice (ASN) ............................................. 14 3.3.8 UBL:Invoice (VoorstelFactuur) ......................................... 14 3.3.9 UBL:Invoice (ReactieVoorstelFactuur) ............................... 14 3.3.10 UBL:Invoice (Factuur) .................................................. 15 3.4 HRXML Overheid NL berichten ............................................... 16 3.4.1 Identificatie partijen ....................................................... 16 3.4.2 (Her)gebruik berichten.................................................... 17 3.4.3 HRXML:StaffingOrder (Offerteaanvraag) ........................... 17 3.4.4 HRXML:HumanResource (Offerte) .................................... 17 3.4.5 HRXML:HumanResource (OfferteAfwijzing) ........................ 18 3.4.6 HRXML:StaffingOrder (InkoopOrder) ................................ 18 3.4.7 HRXML:HumanResource (BestelBevestiging)...................... 18 3.4.8 HRXML:Timecard............................................................ 19 3.4.9 HRXML:Invoice (VoorstelFactuur) ..................................... 19 3.4.10 HRXML:Invoice (ReactieVoorstelFactuur) ........................ 19 3.4.11 HRXML:Invoice (Factuur).............................................. 20

Pagina 3 van 20


1

Inleiding

DigiInkoop bestaat uit een online inkoopsysteem (ePurchase Voorziening, of ePV) en het koppelvlak Digipoort voor berichtuitwisseling. Dit document beschrijft welke berichten een leverancier kan uitwisselen met een overheidsorganisatie tijdens het inkoopproces. De leverancier wisselt deze berichten uit met de ePV of met het eigen inkoopsysteem van de overheidsorganisatie, maar in beide gevallen gaat het om hetzelfde proces en dezelfde berichten en is dit voor de leverancier gelijk. 1.1

Scope Dit document richt zich op de ‘externe’ berichten tussen de leverancier en de overheid, ongeacht of deze van de ePV (bij een Deelnemer A) of de klantorganisatie zelf (bij een Deelnemer B) komen. Dit is hieronder schematisch weergegeven met de rode pijlen in Figuur 1. Daarnaast zijn er specifieke interne berichten tussen de ePV en de klantorganisatie (bij een Deelnemer A), die apart beschreven zijn.

Figuur 1 – Scope 1.2

Leeswijzer Hoofdstuk 2 beschrijft de stappen in het inkoopproces waarbinnen de berichtuitwisseling plaatsvindt. Hoofdstuk 3 beschrijft de individuele berichten per berichtstandaard en de eisen waar deze aan moeten voldoen om binnen het proces de juiste informatie uit te kunnen wisselen.

Pagina 4 van 20


1.3

Gerelateerde documenten Dit document maakt onderdeel uit van een bredere set aan documentatie die u kunnen helpen bij het aansluiten op de berichten van DigiInkoop. Hieronder zijn de documenten in samenhang weergegeven.

Figuur 2 - Gerelateerde documenten Deze documenten zijn allemaal te vinden op de website van Logius, op www.logius.nl. Hierbij zijn vooral de berichtstandaarden van belang, als aanvulling op dit document. Dit zijn zip-bestanden met de specificaties en voorbeeldberichten van UBL Overheid NL en HRXML Overheid NL. U kunt daarbij het beste beginnen bij de implementatiewijzer van iedere berichtstandaard. Deze is te vinden in de DOC-map van de zip-bestanden. Deze berichtstandaarden zijn te vinden via: https://www.logius.nl/ondersteuning/gegevensuitwisseling/digiinkoop-voorleveranciers-via-digipoort/

Deze berichtstandaarden staan niet op zichzelf, maar zijn gebaseerd op (inter)nationale standaarden. UBL Overheid NL is gebaseerd op de internationale UBL standaard en HRXML Overheid NL is gebaseerd op de nationale SETU standaard, welke weer een nadere specificatie is van HRXML.

Pagina 5 van 20


2

Proces

DigiInkoop ondersteunt het inkoopproces van de (rijks)overheid. Een overheidsorganisatie treedt hierbij op als klant naar een leverancier. Het inkoopproces bestaat uit twee subprocessen: A. Van bestelaanvraag tot en met levering (zie paragraaf 2.1) B. Van ontvangst tot en met factuur (zie paragraaf 2.2) Deze subprocessen beschreven in de volgende paragrafen, waarbij per stap de berichten zijn benoemd die uitgewisseld worden tussen Klant en Leverancier. 2.1

Subproces: Van bestelaanvraag tot en met ontvangst

Processtap

A.1. Bestelaanvraag

Beschrijving

De Aanvrager bij de Klant geeft z’n behoefte aan. De verantwoordelijke bij de Klant beoordeelt de behoefte.

UBL Berichttype

Geen (alleen interne berichten)

HRXML Berichttype


Processtap

A.2. Offerte Proces

Beschrijving

Na de Bestelaanvraag start het Offerte Proces waar een aantal berichten elkaar in vraag/antwoord/reactie opvolgen. De Vraag is de Offerteaanvraag. Het Antwoord is de Offerte. De Reactie is een Inkooporder (zie volgende stap) of een Afwijzing van de Offerte. Deze processtap is optioneel.

UBL Berichttype

Vraag: Antwoord:

UBL:RequestForQuotation UBL:Quotation Pagina 6 van 20


Reactie:

UBL:RequestForQuotationCancellation

HRXML Berichttype

Vraag: Antwoord: Reactie:

HRXML:StaffingOrder HRXML:HumanResource HRXML:HumanResource

Processtap

A.3. Inkooporder

Beschrijving

De Inkoper maakt een Inkooporder aan. Dit kan op basis van een goedgekeurde Bestelaanvraag, of een gegunde Offerte. Als reactie op de Inkooporder stuurt de leverancier een Bestelbevestiging. Bij inhuur bevat deze de inhuurkracht en bij goederen de hoeveelheid en het moment van leveren.

UBL Berichttype

Inkooporder: Bestelbevestiging:

UBL:Order UBL:OrderResponse

HRXML Berichttype

Inkooporder: Bestelbevestiging:

HRXML:StaffingOrder HRXML:HumanResource

Processtap

A.4. Tijdschrijven

Beschrijving

Bij inhuur schrijft de inhuurkracht tijd in het tijdschrijfsysteem. Na goedkeuring door de verantwoordelijke bij de Klant wordt de tijdkaart naar de Leverancier verstuurd.

UBL Berichttype

N.V.T.

HRXML Berichttype

HRXML:Timecard

Processtap

A.5. Levering

Beschrijving

Bij goederen kan de Leverancier een Advanced Shipping Notice (ASN) sturen. Hierin kondigt de Leverancier de levering aan. De Klant kan zich hiermee voorbereiden op de levering.

UBL Berichttype

UBL:DespatchAdvice

HRXML Berichttype

N.V.T.

Pagina 7 van 20


2.2

Subproces: Van ontvangst tot en met factuur

Processtap

B.1. Ontvangst

Beschrijving

Na levering van de goederen of inhuur boekt de Ontvanger de ontvangst/prestatie in bij de Klant

UBL Berichttype

Geen

HRXML Berichttype

Geen

Processtap

B.2. Voorstelfactuur

Beschrijving

De Klant stuurt een Voorstelfactuur op basis van de geboekte ontvangst/prestatie. Dit wordt reverse billing genoemd. Deze stap is optioneel en wordt alleen uitgevoerd in overleg tussen Klant en Leverancier. NB: Dit is geen self-billing waarbij de Klant ook het factuurnummer en de datum meegeeft, maar betreft alleen de goederen/prestaties en de bedragen.

UBL Berichttype

UBL:Invoice

HRXML Berichttype

HRXML:Invoice

Processtap

B.3. Factuur

Beschrijving

De Leverancier stuurt de Factuur. Dit kan als reactie op een Voorstelfactuur, waarbij hetzelfde bericht wordt aangevuld met een factuurnummer en factuurdatum van de Leverancier. Wanneer er geen Voorstelfactuur wordt gebruikt, verbindt de Financiële Administratie van de Klant de Factuur aan de Inkooporder. Bij inhuur kan de Leverancier de eerder ontvangen tijdkaart met de Factuur meesturen als bijlage.

UBL Berichttype

UBL:Invoice

HRXML Berichttype

HRXML:Invoice

Pagina 8 van 20


2.3

Processtap

B.4. Goedkeuring

Beschrijving

De Factuur wordt goedgekeurd door een intern proces van de Klant. Bij een gerelateerde Inkooporder die overeenkomt kan dit mogelijk automatisch. Anders dient de Factuur handmatig geaccordeerd te worden door de Klant.

UBL Berichttype


HRXML Berichttype


Manieren van Factureren De berichtuitwisseling rond een Factuur kan op een aantal manieren plaatsvinden. Er kan direct gefactureerd worden vanuit de Leverancier, of er kan reverse billing gebruikt worden, waarbij de Klant een Voorstel Factuur gestuurd wordt die altijd gevolgd wordt door een Reactie Factuur. Deze situatie kunnen ook voorkomen bij een Credit Factuur, waardoor er in totaal zes soorten factuurberichten gestuurd kunnen worden tussen Klant en Leverancier. Dit is hieronder weergegeven.

In UBL wordt er bij alle berichten het berichttype UBL:Invoice gebruikt. Om welk van de zes soorten facturen het gaat is afhankelijk van de zender (Klant of Leverancier) het InvoiceTypeCode element en het BillingReference element.

Pagina 9 van 20


3

Berichten

3.1

Berichtstandaarden Afhankelijk van het soort inkoop (goederen/diensten of inhuur) worden er twee berichtstandaarden gebruikt:  

UBL Overheid NL voor goederen/diensten en HRXML Overheid NL (SETU) voor Inhuur.

Dit zijn verbijzonderingen van (inter)nationale standaarden om de berichten te vereenvoudigen en beter te laten aansluiten op de werkprocessen van de Rijksoverheid. De HRXML Overheid NL berichtenstandaard gebruikt bepaalde berichten op verschillende momenten in het proces op verschillende manieren, met verschillende vulling. (voorbeeld: de StaffingOrder wordt gebruikt als bericht voor de Offerteaanvraag en als bericht voor de InkoopOrder). In de UBL Overheid NL standaard is voor iedere type bericht een eigen specificatie. Wel kan het Factuur bericht (UBL:Invoice) worden verstuurd als VoorstelFactuur ook wel ‘reversed-billing’ genoemd. Hierop wordt dan gereageerd met hetzelfde bericht aangevuld met het Factuurnummer en factuurdatum van de leverancier. Klant en leverancier kunnen afspreken om deze manier van factureren te gebruiken. Sommige stappen in het proces zijn optioneel. In de keten van het proces is er tussen de opeenvolgende berichten wel een bepaalde samenhang. Bijvoorbeeld geen BestelBevestiging zonder een voorafgaande InkoopOrder of bijvoorbeeld geen Offerte zonder OfferteAanvraag. Gebruik van berichten, die de processtappen ondersteunen, stemmen klant en leverancier af. In deze afstemming kunnen zij ook afspraken maken over de verwachte tijdsspanne die tussen de berichten mogen zitten. En in deze afspraken moet staan welke berichten in het inkoopproces gebruikt worden. Functionele afspraken tussen de klant en leverancier bepalen of het gebruik van optionele berichten verplicht zijn.

3.2

Afspraken, Aannames en Uitgangspunten Om gebruik te kunnen maken van de berichtspecificaties en om hiermee een succesvolle machine-naar-machine koppeling te maken zijn er een aantal afspraken, aannames en uitgangspunten over het gebruik van elementen. De belangrijkste zijn:  De ontvangende partij moet alle velden uit het bericht kunnen lezen.  Binnen berichten kunnen Elementen verplicht of optioneel zijn. Deze verplichting kan een onderliggende technische reden hebben (correcte aflevering) of een functionele reden.  Relevante gegevens die je ontvangt stuur je retour.  Berichten bestaan uit een Kop niveau (Header) en een Regel niveau (Line)

Pagina 10 van 20




 





Bepaalde gegevens kunnen op Kop niveau voorkomen, in dat geval gelden deze gegevens voor het hele bericht (zoals b.v. valuta, afleveradres) Indien deze gegevens op Regel niveau voorkomen mogen deze NIET op Kop niveau voorkomen en moeten deze gegevens op ALLE regels staan. Sommige datum velden bevatten ook tijd (type:DateTime) in andere velden moeten datum en tijd in verschillende elementen staan. Het KvK nummer van de verzendende partij staat altijd op het bericht. Voor overheden is het bedrijfsidentificatienummer het OIN. DigiInkoop hanteert deze nummers voor de unieke identificatie van partijen in het systeem. Als er een technisch element voor een bepaald gegeven in het bericht aanwezig is, dan wordt dit gegeven in dit element geplaatst.

3.3

UBL Overheid NL berichten De berichtenstandaard UBL Overheid NL, kortweg UBL, ondersteunt een typisch inkoopproces tussen Klant en Leverancier. De verschillende stappen in het inkoopproces worden door verschillende UBL berichten ondersteund. Zie onderstaande figuur.

3.3.1

Samenhang Partijen en Rollen De twee partijen die als Klant en Leverancier met elkaar communiceren doen dit op basis van verschillende rollen in het inkoopproces. Zo zal de Klant vanuit de rol van “Inkoper” de daadwerkelijke bestelling doen en in de rol van “Boekhouder” de betaling afhandelen. De volgende tabel bevat de rollen die DigiInkoop onderkent tijdens de berichtuitwisseling. Partij

Rollen

Omschrijving

Aanvrager

De persoon met de behoefte die een aanvraag vastlegt.

Inkoper

Verantwoordelijk voor het aanvullen van aanvragen en/of het uitvoeren van het tactisch inkoopproces (specificeren, selecteren, contracteren en contracten relatiebeheer)

Ontvanger

Ontvangt producten en registreert de ontvangst in het inkoopsysteem van de Klant.

Boekhouder

Heet ook Crediteurenadministratie. Verantwoordelijk voor het verwerken en betalen van facturen.

Verkoper

Persoon die producten of diensten levert aan de

Klant

Leverancier

Pagina 11 van 20


Partij

Rollen

Omschrijving Klant.

Verzender

Persoon/partij die de goederen verzendt naar de Klant.

Boekhouder

Heet ook Debiteurenadministratie. Verantwoordelijk voor het beoordelen van uren en voorstelfacturen en het versturen van facturen.

De benoemde rollen zijn hieronder gerelateerd aan de ‘Parties’ die in UBL gedefinieerd zijn. Rollen

Partij UBL1

Verstuurt

Ontvangt

Aanvrager

OriginatorCustomerParty

RequestForQuotation RequestForQuotation Cancellation

Quotation

Inkoper

BuyerCustomerParty

Order

OrderResponse

Ontvanger

DeliveryCustomerParty

Boekhouder

AccountingCustomerParty

Invoice (Voorstelfactuur)

Invoice (Factuur)

Verkoper

SellerSupplierParty

Quotation, OrderResponse

RequestForQuotation, RequestForQuotationCancell ation Order

Verzender

DespatchSupplierParty

DespatchAdvice

Boekhouder

AccountingSupplierParty

Invoice (Factuur)

DespatchAdvice

Invoice (Voorstelfactuur)

Deze ‘parties’ of rollen worden in UBL geïdentificeerd met ID’s (identificatienummers). Deze ID’s worden benoemd door de Klant met CustomerAssignedAccountID, of door de Leverancier met SupplierAssignedAccountID. Hierdoor kunnen er vier verschillende ID’s gebruikt worden bij de berichtuitwisseling, namelijk:

1. 2. 3. 4.

De Klant identificatie van de Leverancier, De Klant identificatie van zichzelf, De Leverancier identificatie van de Klant, De Leverancier identificatie van zichzelf.

Daarnaast worden ook de ID’s van officiële instanties gebruikt voor identificatie. Dit zijn:

  

1

BTW nummer (Belastingdienst) KvK-nummer (Kamer van Koophandel) OIN (OverheidsIdentificatieNummer)

Ga voor een volledig overzicht van UBL 2.0 parties naar http://docs.oasis-open.org/ubl/os-UBL2.0/UBL-2.0.html#PARTYROLES. Pagina 12 van 20


3.3.2

UBL:RequestForQuotation Dit bericht bevat een gestructureerde aanvraag voor goederen en/of diensten richting een verkoper/leverancier. Het heeft als doel om een prijsstelling en beschikbaarheids informatie te verkrijgen over goederen of diensten. Zie onderstaande tabel voor een aantal belangrijke elementen: Element Vulling RequestForQuotation/ID RequestForQuotation/OriginatorCustomerParty RequestForQuotation/SellerSupplierParty

Offerteaanvraag nummer Aanvrager (Klant) Verkoper (Leverancier)

Indien de Aanvrager vervolgens een bestelling/order plaatst, neemt hij de rol van Inkoper (BuyerCustomer) aan. Binnen de klantorganisatie kan dit ook een ander persoon zijn. 3.3.3

3.3.4

3.3.5

UBL:Quotation Met dit offerte bericht reageert een verkoper/leverancier op het offerteaanvraag bericht, hiermee communiceert hij de mogelijke levering van goederen en/of diensten. Het bericht bevat de prijsstelling en de beschikbaarheid van de goederen of de te leveren diensten. Tevens bevat het bericht de leveringsvoorwaarden van de goederen. Element

Vulling

Quotation/ID

Offerte nummer

Quotation/RequestForQuotationDocumentReference/ID

Offerteaanvraag nummer

Quotation/ValidityPeriod/EndTime

Einddatum Geldigheid Offerte

UBL:RequestForQuotationCancellation Met dit bericht wijst de klant een aangeboden Offerte af. Het nummer van de offerte staan in dit bericht. Dit berichttype is een uitbreiding op UBL 2.0, omdat overheidsorganisaties verplicht zijn een offerte expliciet af te wijzen bij een aanbesteding die aan een ander leverancier gegund wordt. Element

Vulling

RequestForQuotationCancellation/IssueDate

Datum afwijzing

RequestForQuotationCancellation/RejectionNote

Reden afwijzing

RequestForQuotationCancellation/DocumentReference/ID

Offerte nummer Leverancier

UBL:Order Dit bericht bevat de gegevens voor het bestellen/inkopen van goederen en diensten. Bestellen/inkopen is een samenwerking die een contractuele verplichting legt tussen de Klant en de Leverancier. Belangrijke elementen: Element

Betekenis

ID

Inkooporder nummer

IssueDate

Datum Inkooporder

BuyerCustomerParty

Gegevens van de Inkoper

AccountingCustomerParty

Gegevens van de te factureren partij

SellerSupplierParty

Gegevens van de leverancier

Delivery

Afleveringgegevens bv. locatie en datum. (Op kop- of regelniveau)

OrderLine/LineItem/ID

Inkooporder regel nummer

OrderLine/LineItem/Quantity

Hoeveelheid

OrderLine/LineItem/Price

Prijs

OrderLine/LineItem/Item

Container voor gegevens van het artikel

Indien er eerder een offerte was afgegeven dan staat de referentie naar die offerte in: Order/QuotationDocumentReference/ID Pagina 13 van 20


3.3.6

UBL:OrderResponse Met dit bericht stuurt de leverancier bestelbevestiging op een eerder binnengekomen order bericht. Belangrijke afspraken en elementen in de bestelbevestiging zijn: Element

Betekenis

OrderReference/ID

Het Inkooporder nummer waarop de bevestiging betrekking heeft.

Delivery/PromisedDeliveryPeriod/EndDate

Toegezegde datum (Kop of regel niveau)

OrderLine/LineItem/ID

Moet overeenkomen met Inkooporder regel nummer

OrderLine/LineItem/Quantity

Toezegging te leveren hoeveelheid.

Alle regels die je uit de Order krijgt moet je terug sturen in de OrderResponse met dezelfde nummer referentie als uit de order. In het bericht OrderResponse is geen element voor het afwijzen van een inkooporder (dit geldt alleen voor UBL; in HRXML is dit wel mogelijk!). Via het OrderResponse bericht zijn beperkt wijzigingen mogelijk. Alleen hoeveelheid en Leverdatum kunnen gewijzigd worden. Verder kan de leverancier ook zijn VerkoopOrderNummer opgeven. 3.3.7

UBL:DespatchAdvice (ASN) Het bericht DespatchAdvice (ook ASN of Advanced Shipping Notice) beschrijft het vervoer of de levering van goederen en diensten. De verzendende partij stuurt het DespatchAdvice aan de ontvanger om de verzending van artikelen te bevestigen. Dit heeft als doel dat de ontvanger zich kan voorbereiden op het ontvangen van artikelen. Bijvoorbeeld bij locaties waar niet altijd ontvangen kan worden of niet altijd personeel aanwezig is. De DespatchAdvice regel hoeft niet één-op-één overeen te komen met de orderregels. De DespatchAdvice regel bevat een order regel referentie ID.

3.3.8

UBL:Invoice (VoorstelFactuur)2 Een VoorstelFactuur (ook wel reversed-bill genaamd) is een facturatie methodiek waarbij de klant op basis van een gedane Prestatieverklaring (ook genoemd een geboekte Ontvangst) een voorstelfactuur opmaakt en deze (elektronisch) verzendt naar de Leverancier. Indien de Leverancier de VoorstelFactuur accepteert, stuurt hij het bericht retour (zie ReactieVoorstelFactuur) anders stuurt hij een ‘losse’ Factuur zonder referentie naar de VoorstelFactuur. Wijzigingen in de gegevens zijn niet toegestaan. Afhandeling van afwijzingen in het VoorstelFactuur proces moeten worden afgestemd tussen Klant en Leverancier.

3.3.9

Element

Betekenis

Invoice/ID

Voorstel factuurnummer

Invoice/IssueDate

Voorstel factuurdatum

Invoice/InvoiceTypeCode

De code om aan te geven wat voor een factuur het is. VD = Voorstel debitnota of VC = Voorstel creditnota

UBL:Invoice (ReactieVoorstelFactuur) In de ReactieVoorstelFactuur stuurt de leverancier het eerder ontvangen VoorstelFactuur bericht retour, aangevuld met z’n eigen Factuur nummer,

2

Aangezien de factuur nog niet compleet is, het factuurnummer en de datum ontbreken immers, is hier geen sprake van ‘self-billing’ en wordt ook het UBL berichttype SelfBilledInvoice niet gebruikt. Pagina 14 van 20


de huidige Factuur datum en de verwijzing naar de eerder ontvangen Voorstelfactuur. Wijzigingen in de gegevens zijn niet toegestaan.

3.3.10

Element

Betekenis

Invoice/ID

Factuurnummer leverancier

Invoice/IssueDate

Factuurdatum leverancier


De code om aan te geven wat voor een factuur het is. D = Debitnota of C = Creditnota

Invoice/BillingReference/InvoiceDocumentReference/ID

Voorstel factuurnummer

UBL:Invoice (Factuur) Als er geen afspraken tussen klant en leverancier zijn gemaakt over het gebruik van de voorstelfactuur methode of er zijn overige goederen/diensten te factureren dan kan de leverancier een ‘gewone’ factuur als bericht aanbieden. Element

Betekenis

Invoice/ID


Invoice/IssueDate



D = Debitnota of C = Creditnota

Invoice/OrderReference/ID

Inkoop Order nummer

De Factuur, VoorstelFactuur en ReactieVoorstelFactuur maken dus allen gebruik van het UBL berichttype Invoice. Aan de hand van de zender en de eventuele referenties kan opgemaakt worden om welke soort factuur het gaat.

Pagina 15 van 20


3.4

HRXML Overheid NL berichten De SETU hanteert een standaardproces dat doorlopen wordt binnen de Nederlandse sector voor inhuur van flexibele arbeid. Hieronder de procesbeschrijving van SETU met per processtap de vertaling naar het algemene Overheid inkoopproces en de HRXML Overheid NL, kortweg HRXML, berichten die gebruikt worden per stap.

Het proces begint met een aanvraag vanuit de klant, vervolgens stuurt de leverancier hierop een aanbod. De klant accepteert het aanbod door een bevestiging te sturen. Waarop de leverancier reageert met een plaatsing. Hierna verstuurt de klant tijdkaarten (of urenbriefjes) naar de leverancier. De leverancier verwerkt deze tijdkaarten in een factuur naar de klant. Ieder bericht dat in dit standaardproces voorkomt, wordt in de volgende paragrafen toegelicht, inclusief verwijzingen naar de standaard waarin het bericht gespecificeerd is. Het is vanuit de standaard niet verplicht om het volledige proces te volgen, het is ook mogelijk om een deel van de berichten uit het proces te gebruiken. Welke berichten worden uitgewisseld tussen klant en leverancier moet zijn afgestemd. 3.4.1

Identificatie partijen De SETU standaard gaat uit van een beperkt aantal partijen die met elkaar berichten uitwisselen over het inhuren van personeel. Vanuit het project DigiInkoop is echter een bredere visie neergezet, namelijk het inhuren van personeel door de overheid van een ieder die personeel aan kan bieden. Dit betekent dat partijen niet altijd bekend met elkaar zullen zijn en dat zelfs buitenlandse partijen mee kunnen doen in het berichtenverkeer. Een gevolg hiervan is dat niet langer vertrouwd kan worden op uniciteit van door communicerende partijen uitgegeven relatienummers en crediteurennummers. Voor het identificeren van de partijen zijn in de berichten ID elementen opgenomen, zoals b.v. StaffingCustomerId, StaffingCustomerOrgUnitId en StaffingSupplierId. Ieder element dat een partij identificeert heeft het attribuut @idOwner. Dit attribuut geeft aan wie de eigenaar (lees ‘uitgever’) is van het bijbehorende element. De eigenaar/uitgever is verantwoordelijk voor de uniciteit van de uitgegeven id’s. Toegestane waarden voor @idOwnder zijn: StaffingCustomer, StaffingCompany, OIN, KvK, BTW of Fi.

Pagina 16 van 20


3.4.2

(Her)gebruik berichten Binnen de HRXML SETU standaard hebben de berichten, afhankelijk van het gebruik in het proces, een andere betekenis (zie ook hoofdstuk 2). HRXML Bericht StaffingOrder HumanResource Timecard Invoice

3.4.3

Wordt gebruikt voor

Van

Naar

Klant

Leverancier

Leverancier

Klant

Tijdkaart

Klant

Leverancier

VoorstelFactuur

Klant

Leverancier

ReactieVoorstelFactuur Factuur

Leverancier

Klant

OfferteAanvraag (RFQ) InkoopOrder Offerte OfferteAfwijzing BestelBevestiging

HRXML:StaffingOrder (Offerteaanvraag) De klant heeft een open positie en plaatst een offerteaanvraag richting de leverancier(s) met het StaffingOrder (=SO) bericht. Belangrijke elementen

Vulling

SO/OrderId/IdValue


SO/OrderId/@validTo

Sluitingsdatum van de aanvraag

SO/RequiredResponseDate

Uiterste reactie datum.

SO/OrderClassification/@orderType

“RFQ”

SO/StaffingPosition/PositionHeader/PositionTitle

Functieomschrijving

SO/StaffingPosition/PositionDateRange/StartDate

Gewenste startdatum inzet

SO/StaffingPosition/PositionDateRange/ExpectedEndDate

Verwachte einddatum inzet

SO/StaffingPosition/Rates/Amount

Maximum Tarief

SO/StaffingPosition/Rates/Amount/@rateAmountPeriod

Periode voor tarief b.v. “hourly”

Het onderscheid tussen een Offerteaanvraag en InkoopOrder bericht staat het attribuut StaffingOrder/OrderClassification/@orderType. Dit attribuut heeft exact de tekstwaarde 'RFQ' voor de Offerteaanvraag en de waarde 'order' voor een InkoopOrder. 3.4.4

HRXML:HumanResource (Offerte) De leverancier reageert op de Offerteaanvraag met een Offerte. Het Offerte bericht is een variant van het HumanResource (HR) bericht. Belangrijke elementen

Vulling

HR/HumanResourceId/IdValue

Persoonsid van de leverancier

HR/HumanResourceId/@idOwner

“StaffingCompany”

HR/HumanResourceStatus/@status

“x:Assigned”

HR/ReferenceInformation/OrderId/IdValue


HR/UserArea/HumanResourceAdditionalNL/OfferId/IdValue

Offerte nummer

HR/ResourceInformation/PersonName

Container voor contractant

HR/ResourceInformation/AvailabilityDate/AvailabilityStartDate

Startdatum

HR/ResourceInformation/AvailabilityDate/AvailabilityEndDate

Einddatum

HR/Rates/Amount

Tarief per periode (zie Period)

HR/Rates/Amount/@rateAmountPeriod

Periode voor tarief b.v. “hourly”

Het onderscheid tussen een Offerte en een BestelBevestiging bericht (beide van het type HumanResource) staat in het attribuut Pagina 17 van 20


HumanResource/HumanResourceStatus/@status. Dit attribuut heeft de waarde 'x:Assigned' voor de Offerte en de waarde 'x:Confirmed' voor een BestelBevestiging. 3.4.5

3.4.6

HRXML:HumanResource (OfferteAfwijzing) Als de klant de offerte afwijst stuurt deze een Offerte Afwijzing. Dit is een HumanResource (HR) berichttype met de waarde ‘rejected’ in het attribuut HumanResource/HumanResourceStatus/@status Belangrijke elementen

Vulling

HumanResource/HumanResourceId/IdValue

Persoonsid van de leverancier

HumanResource/ReferenceInformation/OrderId/IdValue


HumanResource/HumanResourceStatus/@status

“Rejected”

HumanResource/UserArea/HumanResourceAdditionalNL/OfferId

Offerte nummer leverancier

HumanResource/HumanResourceComments

Afwijzingsbericht

HRXML:StaffingOrder (InkoopOrder) Als de klant de offerte gunt dan stuurt hij een InkoopOrder naar de leverancier. Dit bericht is van het type StaffingOrder (SO). Belangrijke elementen

Vulling

SO/OrderId/IdValue

InkoopOrder nummer

SO/OrderClassification/@orderType

“order”

SO/OrderClassification/@orderStatus

“New”

SO/UserArea/StaffingOrderAdditionalNL/OfferId/IdValue

Offerte nummer leverancier

SO/UserArea/StaffingOrderAdditionalNL/RFQOrderId/IdValue

Offerteaanvraag nummer klant

SO/ReferenceInformation/StaffingCustomerOrgUnitId

Klant (sub) Organisatie onderdeel

SO/CustomerReportingRequirements/PurchaseOrderNumber

InkoopOrder Nummer

SO/StaffingPosition/Rates/@rateType

“bill” dit tarief factureren

SO/StaffingPosition/Rates/@rateStatus

“agreed” tarief is afgesproken

SO/StaffingPosition/Rates/Amount

“35.40” Het tarief (per periode)

SO/StaffingPosition/Rates/Amount/@rateAmountPeriod

“hourly” de periode van het tarief

SO/StaffingPosition/Rates/Class

“regular” uursoort

Bij InkoopOrder bericht is het attribuut StaffingOrder/OrderClassification/@orderType gevuld met de tekstwaarde 'order'. 3.4.7

HRXML:HumanResource (BestelBevestiging) Om de aanvraagketen af te maken stuurt de leverancier een BestelBevestiging, een bericht van het type HumanResource (HR) Belangrijke elementen

Vulling

HR/HumanResourceId/IdValue

Identificatienr inhuurkracht

HR/HumanResourceId/@idOwner

“StaffingCompany”

HR/HumanResourceStatus/@status

“x:Confirmed”

HR/ReferenceInformation/OrderId/IdValue

InkoopOrder Nummer klant

HR/ResourceInformation/PersonName/GivenName

Voornaam kandidaat Pagina 18 van 20


HR/ResourceInformation/PersonName/PreferredGivenName

Roepnaam kandidaat

HR/ResourceInformation/PersonName/FamilyName

Achternaam kandidaat

HR/ResourceInformation/PersonName/FamilyName/@primary

TRUE (FALSE=partnernaam)

HR/Res..Info../EntityContactInfo/ContactMethod/Mobile

Mobiele nummer kandidaat

HR/Res..Info../EntityContactInfo/ContactMethod/InternetEmailAddress

Email adres kandidaat

HR/ResourceInformation /AvailabilityDate/AvailabilityStartDate

Startdatum

Bij het BestelBevestiging is het attribuut HumanResource/HumanResourceStatus/@status gevuld met de waarde 'x:Confirmed'. 3.4.8

3.4.9

3.4.10

HRXML:Timecard Het doel van de tijdkaart (of urenbriefje) is om de geaccordeerde uren van de inhuurkracht te communiceren naar de leverancier. (Afwijzingen en Correcties worden niet met berichtenverkeer ondersteund). Elke tijdkaart moet een unieke identificatie hebben om elektronische verwerking mogelijk te maken en om deze te koppelen aan andere onderdelen in het proces (personen facturen enz.). Voor de leverancier zorgt de combinatie klant_id en tijdkaart_id voor het uniek kunnen identificeren van elke tijdkaart in de leverancier organisatie. Één tijdkaart heeft betrekking op één inkooporder, dit inkooporder staat in het kopniveau. Belangrijke elementen

Vulling

TimeCard/Id

Unieke id van de tijdkaart

TimeCard/ReportedResource/Person/Id/IdValue

De id van de inhuurkracht

TimeCard/AdditionalData/StaffingAdditionalData/ CustomerReportingRequirements/PurchaseOrderNumber

Inkoopordernummer

TimeCard/ReportedTime/TimeInterval/…./…./ CustomerReportingRequirements/PurchaseOrderLineItem

Verwijzing naar Inkooporder regelnummer

TimeCard/ReportedTime/TimeInterval/StartDateTime

Start datum/tijd

TimeCard/ReportedTime/TimeInterval/EndDateTime

Eind datum/tijd

TimeCard/ReportedTime/TimeInterval/Duration

Duur

TimeCard/ReportedTime/TimeInterval/RateOrAmount/@type

Soort (hourly, daily)

HRXML:Invoice (VoorstelFactuur) Hieronder een aantal belangrijke elementen bij het VoorstelFactuur bericht. Belangrijke elementen

Vulling

Invoice/Header/DocumentIds/DocumentId/Id

VoorstelFactuurnummer

Invoice/Header/User../Staf../Cust…/PurchaseOrderNumber

Inkoopordernummer

Invoice/Line/UserArea/Staf../Cust../PurchaseOrderLineItem

Inkooporder regelnummer

Invoice/Header/Type

“Debit”

Invoice/Header/Reason

“Self-Billed” = VoorstelFactuur

Invoice/Header/TotalAmount

Totaal bedrag VoorstelFactuur

Invoice/Line/Price/Amount

Tarief (b.v. per uur)

Invoice/Line/ItemQuantity

Aantal (b.v. uren)

HRXML:Invoice (ReactieVoorstelFactuur) De reactie op een VoorstelFactuur is een ReactieVoorstelFactuur bericht. Technisch is het standaard HRXML:Invoice bericht. Hieronder een aantal belangrijke elementen bij het ReactieVoorstelFactuur bericht. Pagina 19 van 20


3.4.11

Belangrijke elementen

Vulling



Invoice/Header/DocumentDateTime


Invoice/Header/Type

“Debit”


“Regular” Factuur

Invoice/Header/Doc..Ref../InvoiceDoc..Ref../Doc..Ids/Doc..Id/Id

VoorstelFactuurnummer

HRXML:Invoice (Factuur) Als er geen afspraken tussen klant en leverancier zijn gemaakt over het gebruik van de voorstelfactuur methode of er is een andere reden dan kan de leverancier een ‘gewone’ factuur als bericht aanbieden. Belangrijke elementen

Vulling



Invoice/Header/DocumentDateTime


Invoice/Header/Type

“Debit”


“Regular” Factuur

Invoice/Header/Parties/RemitToParty

Factureer gegevens leverancier

Invoice/Header/Parties/BillToParty

Factureer gegevens klant

Invoice/Header/Parties/SupplierParty

Leverancier

Invoice/Header/Parties/CustomerParty

Klant

Pagina 20 van 20

DigiInkoop berichten - Procesmodel Extern

Recommend Documents