DigiInkoop berichten - Procesmodel Extern

DigiInkoop berichten - Procesmodel Extern Versie 1.1 Datum 14 augustus 2014 Status Definitief

Colofon Product DigiInkoop Versienummer 1.1 Contact Functioneel beheer DigiInkoop Organisatie Logius Postbus 96810 2509 JE Den Haag servicecentrum@logius.nl Bijlage(n) - Pagina 2 van 20

Inhoud Colofon... 2 Inhoud... 3 1 Inleiding... 4 1.1 Scope... 4 1.2 Leeswijzer... 4 1.3 Gerelateerde documenten... 5 2 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 3 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 Beschrijving UBL HRXML A.1. Bestelaanvraag De Aanvrager bij de Klant geeft z n behoefte aan. De verantwoordelijke bij de Klant beoordeelt de behoefte. Geen (alleen interne berichten) Geen (alleen interne berichten) Processtap Beschrijving UBL A.2. Offerte Proces 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. Vraag: Antwoord: UBL:RequestForQuotation UBL:Quotation Pagina 6 van 20

HRXML Reactie: Vraag: Antwoord: Reactie: UBL:RequestForQuotationCancellation HRXML:StaffingOrder HRXML:HumanResource HRXML:HumanResource Processtap Beschrijving A.3. Inkooporder 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 HRXML Inkooporder: Bestelbevestiging: Inkooporder: Bestelbevestiging: UBL:Order UBL:OrderResponse HRXML:StaffingOrder HRXML:HumanResource Processtap Beschrijving UBL HRXML A.4. Tijdschrijven Bij inhuur schrijft de inhuurkracht tijd in het tijdschrijfsysteem. Na goedkeuring door de verantwoordelijke bij de Klant wordt de tijdkaart naar de Leverancier verstuurd. N.V.T. HRXML:Timecard Processtap Beschrijving UBL HRXML A.5. Levering 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:DespatchAdvice N.V.T. Pagina 7 van 20

2.2 Subproces: Van ontvangst tot en met factuur Processtap Beschrijving UBL HRXML B.1. Ontvangst Na levering van de goederen of inhuur boekt de Ontvanger de ontvangst/prestatie in bij de Klant Geen Geen Processtap Beschrijving UBL HRXML B.2. Voorstelfactuur 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:Invoice HRXML:Invoice Processtap Beschrijving UBL HRXML B.3. Factuur 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:Invoice HRXML:Invoice Pagina 8 van 20

Processtap Beschrijving UBL HRXML B.4. Goedkeuring 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. Geen (alleen interne berichten) Geen (alleen interne berichten) 2.3 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. Klant 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. Leverancier Verkoper Persoon die producten of diensten levert aan de Pagina 11 van 20

Partij Rollen Omschrijving Verzender Boekhouder Klant. Persoon/partij die de goederen verzendt naar de Klant. 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 UBL 1 Verstuurt Ontvangt Aanvrager OriginatorCustomerParty RequestForQuotation RequestForQuotation Quotation Cancellation Inkoper BuyerCustomerParty Order OrderResponse Ontvanger DeliveryCustomerParty DespatchAdvice Boekhouder AccountingCustomerParty Invoice (Voorstelfactuur) Verkoper SellerSupplierParty Quotation, OrderResponse Verzender DespatchSupplierParty DespatchAdvice Boekhouder AccountingSupplierParty Invoice (Factuur) Invoice (Factuur) RequestForQuotation, RequestForQuotationCancell ation Order 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. De Klant identificatie van de Leverancier, 2. De Klant identificatie van zichzelf, 3. De Leverancier identificatie van de Klant, 4. De Leverancier identificatie van zichzelf. Daarnaast worden ook de ID s van officiële instanties gebruikt voor identificatie. Dit zijn: BTW nummer (Belastingdienst) KvK-nummer (Kamer van Koophandel) OIN (OverheidsIdentificatieNummer) 1 Ga voor een volledig overzicht van UBL 2.0 parties naar http://docs.oasis-open.org/ubl/os-ubl- 2.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 RequestForQuotation/ID Offerteaanvraag nummer RequestForQuotation/OriginatorCustomerParty Aanvrager (Klant) RequestForQuotation/SellerSupplierParty 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 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 Quotation/ID Quotation/RequestForQuotationDocumentReference/ID Quotation/ValidityPeriod/EndTime Offerte nummer Offerteaanvraag nummer Einddatum Geldigheid Offerte 3.3.4 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 RequestForQuotationCancellation/IssueDate RequestForQuotationCancellation/RejectionNote RequestForQuotationCancellation/DocumentReference/ID Datum afwijzing Reden afwijzing Offerte nummer Leverancier 3.3.5 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 ID IssueDate BuyerCustomerParty AccountingCustomerParty SellerSupplierParty Delivery OrderLine/LineItem/ID OrderLine/LineItem/Quantity OrderLine/LineItem/Price Betekenis Inkooporder nummer Datum Inkooporder Gegevens van de Inkoper Gegevens van de te factureren partij Gegevens van de leverancier Afleveringgegevens bv. locatie en datum. (Op kop- of regelniveau) Inkooporder regel nummer Hoeveelheid 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 OrderReference/ID Delivery/PromisedDeliveryPeriod/EndDate OrderLine/LineItem/ID Betekenis Het Inkooporder nummer waarop de bevestiging betrekking heeft. Toegezegde datum (Kop of regel niveau) 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. Element Invoice/ID Invoice/IssueDate Invoice/InvoiceTypeCode Betekenis Voorstel factuurnummer Voorstel factuurdatum De code om aan te geven wat voor een factuur het is. VD = Voorstel debitnota of VC = Voorstel creditnota 3.3.9 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. Element Invoice/ID Invoice/IssueDate Invoice/InvoiceTypeCode Invoice/BillingReference/InvoiceDocumentReference/ID Betekenis Factuurnummer leverancier Factuurdatum leverancier De code om aan te geven wat voor een factuur het is. D = Debitnota of C = Creditnota Voorstel factuurnummer 3.3.10 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 Invoice/ID Invoice/IssueDate Invoice/InvoiceTypeCode Invoice/OrderReference/ID Betekenis Factuurnummer leverancier Factuurdatum leverancier D = Debitnota of C = Creditnota 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 Wordt gebruikt voor Van Naar StaffingOrder OfferteAanvraag (RFQ) InkoopOrder Klant Leverancier HumanResource Offerte OfferteAfwijzing BestelBevestiging Leverancier Klant Timecard Tijdkaart Klant Leverancier Invoice VoorstelFactuur Klant Leverancier ReactieVoorstelFactuur Factuur Leverancier Klant 3.4.3 HRXML:StaffingOrder (Offerteaanvraag) De klant heeft een open positie en plaatst een offerteaanvraag richting de leverancier(s) met het StaffingOrder (=SO) bericht. Belangrijke elementen SO/OrderId/IdValue SO/OrderId/@validTo SO/RequiredResponseDate SO/OrderClassification/@orderType SO/StaffingPosition/PositionHeader/PositionTitle SO/StaffingPosition/PositionDateRange/StartDate SO/StaffingPosition/PositionDateRange/ExpectedEndDate SO/StaffingPosition/Rates/Amount SO/StaffingPosition/Rates/Amount/@rateAmountPeriod Offerteaanvraag nummer Sluitingsdatum van de aanvraag Uiterste reactie datum. RFQ Functieomschrijving Gewenste startdatum inzet Verwachte einddatum inzet Maximum Tarief 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 HR/HumanResourceId/IdValue HR/HumanResourceId/@idOwner HR/HumanResourceStatus/@status HR/ReferenceInformation/OrderId/IdValue HR/UserArea/HumanResourceAdditionalNL/OfferId/IdValue HR/ResourceInformation/PersonName HR/ResourceInformation/AvailabilityDate/AvailabilityStartDate HR/ResourceInformation/AvailabilityDate/AvailabilityEndDate HR/Rates/Amount HR/Rates/Amount/@rateAmountPeriod Persoonsid van de leverancier StaffingCompany x:assigned Offerteaanvraag nummer Offerte nummer Container voor contractant Startdatum Einddatum Tarief per periode (zie Period) 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 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 HumanResource/HumanResourceId/IdValue HumanResource/ReferenceInformation/OrderId/IdValue HumanResource/HumanResourceStatus/@status HumanResource/UserArea/HumanResourceAdditionalNL/OfferId HumanResource/HumanResourceComments Persoonsid van de leverancier Offerteaanvraag nummer Rejected Offerte nummer leverancier Afwijzingsbericht 3.4.6 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 SO/OrderId/IdValue SO/OrderClassification/@orderType SO/OrderClassification/@orderStatus SO/UserArea/StaffingOrderAdditionalNL/OfferId/IdValue SO/UserArea/StaffingOrderAdditionalNL/RFQOrderId/IdValue SO/ReferenceInformation/StaffingCustomerOrgUnitId SO/CustomerReportingRequirements/PurchaseOrderNumber SO/StaffingPosition/Rates/@rateType SO/StaffingPosition/Rates/@rateStatus SO/StaffingPosition/Rates/Amount SO/StaffingPosition/Rates/Amount/@rateAmountPeriod SO/StaffingPosition/Rates/Class InkoopOrder nummer order New Offerte nummer leverancier Offerteaanvraag nummer klant Klant (sub) Organisatie onderdeel InkoopOrder Nummer bill dit tarief factureren agreed tarief is afgesproken 35.40 Het tarief (per periode) hourly de periode van het tarief 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 HR/HumanResourceId/IdValue HR/HumanResourceId/@idOwner HR/HumanResourceStatus/@status HR/ReferenceInformation/OrderId/IdValue HR/ResourceInformation/PersonName/GivenName Identificatienr inhuurkracht StaffingCompany x:confirmed InkoopOrder Nummer klant Voornaam kandidaat Pagina 18 van 20

HR/ResourceInformation/PersonName/PreferredGivenName HR/ResourceInformation/PersonName/FamilyName HR/ResourceInformation/PersonName/FamilyName/@primary HR/Res..Info../EntityContactInfo/ContactMethod/Mobile HR/Res..Info../EntityContactInfo/ContactMethod/InternetEmailAddress HR/ResourceInformation /AvailabilityDate/AvailabilityStartDate Roepnaam kandidaat Achternaam kandidaat TRUE (FALSE=partnernaam) Mobiele nummer kandidaat Email adres kandidaat Startdatum Bij het BestelBevestiging is het attribuut HumanResource/HumanResourceStatus/@status gevuld met de waarde 'x:confirmed'. 3.4.8 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 TimeCard/Id TimeCard/ReportedResource/Person/Id/IdValue TimeCard/AdditionalData/StaffingAdditionalData/ CustomerReportingRequirements/PurchaseOrderNumber TimeCard/ReportedTime/TimeInterval/././ CustomerReportingRequirements/PurchaseOrderLineItem TimeCard/ReportedTime/TimeInterval/StartDateTime TimeCard/ReportedTime/TimeInterval/EndDateTime TimeCard/ReportedTime/TimeInterval/Duration TimeCard/ReportedTime/TimeInterval/RateOrAmount/@type Unieke id van de tijdkaart De id van de inhuurkracht Inkoopordernummer Verwijzing naar Inkooporder regelnummer Start datum/tijd Eind datum/tijd Duur Soort (hourly, daily) 3.4.9 HRXML:Invoice (VoorstelFactuur) Hieronder een aantal belangrijke elementen bij het VoorstelFactuur bericht. Belangrijke elementen Invoice/Header/DocumentIds/DocumentId/Id Invoice/Header/User../Staf../Cust /PurchaseOrderNumber Invoice/Line/UserArea/Staf../Cust../PurchaseOrderLineItem Invoice/Header/Type Invoice/Header/Reason Invoice/Header/TotalAmount Invoice/Line/Price/Amount Invoice/Line/ItemQuantity VoorstelFactuurnummer Inkoopordernummer Inkooporder regelnummer Debit Self-Billed = VoorstelFactuur Totaal bedrag VoorstelFactuur Tarief (b.v. per uur) Aantal (b.v. uren) 3.4.10 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

Belangrijke elementen Invoice/Header/DocumentIds/DocumentId/Id Invoice/Header/DocumentDateTime Invoice/Header/Type Invoice/Header/Reason Invoice/Header/Doc..Ref../InvoiceDoc..Ref../Doc..Ids/Doc..Id/Id Factuurnummer leverancier Factuurdatum leverancier Debit Regular Factuur VoorstelFactuurnummer 3.4.11 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 Invoice/Header/DocumentIds/DocumentId/Id Invoice/Header/DocumentDateTime Invoice/Header/Type Invoice/Header/Reason Invoice/Header/Parties/RemitToParty Invoice/Header/Parties/BillToParty Invoice/Header/Parties/SupplierParty Invoice/Header/Parties/CustomerParty Factuurnummer leverancier Factuurdatum leverancier Debit Regular Factuur Factureer gegevens leverancier Factureer gegevens klant Leverancier Klant Pagina 20 van 20