Optimalisering berichtenstroom
tussen
leveranciers en aannemers in de infrasector concept 3.02
Producent
Een initiatief van S@les in de Bouw in samenwerking met: Dyka
DuraVermeer
Kijlstra
VolkerWessels
StruykVerwo
BAM
Vereniging Wapeningstaal Nederland (VWN) BallastNedam Wavin
2
1. Huidige en gewenste berichtenstroom
Huidige situatie: Berichtenstromen Aannemer
Afroep
Leverbon
Uitvoerders bon
Uitvoerders bon
Factuur
Planning
Leverancier
Afroepen worden geplaatst per telefoon, fax of mail. Bij de afroep wordt soms een ordernummer doorgegeven dat ook op de uitvoerdersbon en factuur moet staan. Bij afroepen wordt soms ook het uitvoerdersbonnummer opgegeven. Deze moet dan (naast ordernummer en projectnummer) op de leverbon/vrachtbrief en factuur worden meegegeven. Uitvoerdersbonnen wordt door aannemer geschreven en in enveloppe verzonden per post of gescand en gemaild. De leverancier voegt een kopie van de uitvoerdersbon bij de factuur. De leverbon gaat naar de bouwplaats en de factuur naar kantoor.
Juli 2013, versie 3.02
3
Gewenste situatie: Berichtenstromen
Aannemer
Goedkeuring leverbon
Automatische match leverbon en factuur
Alleen scenario 2 Afroep
Planning
Leverbon
Leverbon bevestiging
Factuur
Leverancier
De prijsvormingsfase blijft, zoals deze nu ook is. De afroepen worden op dezelfde wijze als nu gedaan per telefoon, fax of mail. In het schema is niet opgenomen dat gebruik kan worden gemaakt van de XML-orderbevestiging, omdat dit al onderdeel is van de huidige standaard. Voor de goedkeuring van de leverbon worden 2 scenario’s gedefinieerd, waaruit bedrijven bilateraal kunnen kiezen tijdens het jaarlijks overleg. Scenario 1 is het uitgangspunt voor de sector, omdat de verwachting is dat 99,9% van de facturen van geleverde materialen gelijk is aan de leverbon. Een extra controle op de leveranciersbon invoeren zorgt dan voor een extra handeling aan de afnemer en leverancierskant die voor veruit het grootste gedeelte van de af te leveren materialen niet van toegevoegde waarde is. Deze handeling kost uiteindelijk veel meer tijd, dan de kans dat een factuur een keer niet gelijk is aan de leverbon.Scenario 2 is dan ook voornamelijk in het leven geroepen om materialen waarop nog een bewerking op de bouwplaats plaats moet vinden te kunnen ondersteunen of als tussen fase naar scenario 1.
Juli 2013, versie 3.02
4
Scenario 1. a) Leverancier stuurt XML-leverbon c) De leverancier stuurt de XML-factuur. Bilateraal kan men afspreken dat: De factuur gelijk met de leverbon wordt gestuurd. De wijze waarop de aannemer reageert als de leverbon niet klopt. De voorwaarden wanneer de factuur mag worden verzonden, bijvoorbeeld als de aannemer binnen een afgesproken tijd niet heeft gereageerd.
Scenario 2. a) Leverancier stuurt XML-leverbon b) Uitvoerder bevestigt de levering en hiervan gaat een XML-bericht (“leverbonbevestiging”) naar de leverancier. Het betreft de hoeveelheden. c) De leverancier stuurt de XMLfactuur, na ontvangst van de “leverbon bevestiging” . Voor de “leverbonbevestiging” wordt een nieuw XML-bericht gedefinieerd.
2. Huidige en gewenste berichtenstroom Wapeningsbranche
Huidige situatie: Berichtenstromen Wapeningsbranche
Aannemer
Leverbon
Levering materiaal
Planning
Prestatie bon
Uitvoerders bon
Uitvoerders bon
Factuur
Levering dienst
Leverancier
Afroepen worden geplaatst per telefoon, fax of mail. De leverbon wordt doorgaans niet aan de aannemer gestuurd, maar het mag wel. De prestatiebon wordt wel naar de aannemer gestuurd. Uitvoerdersbon wordt door aannemer geschreven en in enveloppe verzonden per post. De leverancier voegt een kopie van de uitvoerdersbon bij de factuur. De leverbon gaat naar de bouwplaats en de factuur naar kantoor.
Juli 2013, versie 3.02
5
Gewenste situatie: Berichtenstromen Wapeningsbranche
Aannemer
Leverbon
Prestatie bon
Levering materiaal
Planning
Uitvoerders bon
Factuur
Levering dienst
Leverancier
De prijsvormingsfase blijft, zoals deze nu ook is. De afroepen worden op dezelfde wijze als nu gedaan per telefoon, fax of mail. Voor de leverbon en de prestatiebon kan hetzelfde XMLstandaardbericht worden gehanteerd, waarbij of materiaal of diensten worden ingevuld. Over manurenstaten is afgesproken dat deze als bijlage met de factuur mogen worden meegestuurd. (Advies bestandsnaam GLN_factuurnummer_urenstaat.extensie.) In het schema is niet opgenomen dat gebruik kan worden gemaakt van de XML-orderbevestiging, omdat dit al onderdeel is van de huidige standaard. Voor de goedkeuring van de prestatiebon worden 2 scenario’s gedefinieerd, waaruit bedrijven bilateraal kunnen kiezen tijdens het jaarlijks overleg. Scenario 1. b) Leverancier stuurt XML-prestatiebon c) De leverancier stuurt de XML-factuur. Bilateraal kan men afspreken dat: De factuur gelijk met de leverbon wordt gestuurd. De wijze waarop de aannemer reageert als de leverbon niet klopt. De voorwaarden wanneer de factuur mag worden verzonden, bijvoorbeeld als de aannemer binnen een afgesproken tijd niet heeft gereageerd.
Juli 2013, versie 3.02
Scenario 2. d) Leverancier stuurt XML-prestatiebon e) Uitvoerder bevestigt de levering en hiervan gaat een XML-bericht (“leverbonbevestiging”) naar de leverancier. Het betreft de hoeveelheden. f) De leverancier stuurt de XMLfactuur, na ontvangst van de “leverbon bevestiging” . Voor de “leverbonbevestiging” wordt een nieuw XML-bericht gedefinieerd.
6
3. Aandachtspunten: 1. De elektronische leverbon bevat het order- en projectnummer. 2. Voor de “leverbonbevestiging” wordt een nieuw XML-bericht gedefinieerd en aan de S@les in de Bouw-standaard toegevoegd.. 3. De scenario’s worden vastgesteld en toegevoegd aan de gebruiksregels, die door S@les in de Bouw worden vastgelegd samen met de berichten. 4. Extra actie is noodzakelijk om ook kleinere bedrijven te stimuleren om de vast te stellen berichten en procedures te volgen. 5. In de prijsvormingsfase is het voor de wapeningsbranche belangrijk dat projectgebonden specificaties kunnen worden samengesteld als basis voor de prijsregels waarop de factuurafhandeling plaatsvindt. 6. BallastNedam is ook bezig met een selfbilling procedure. Bij scenario 1 en 2 betekent dit dat de leverancier alleen een XML bon stuurt. Deze gaat door de goedkeuring heen bij Ballast Nedam. Na akkoord geeft BallastNedam een signaal naar de leverancier (in XML) dat de leverantie akkoord is. Binnen BallastNedam wordt de leverbon als inkomende factuur beschouwd. Dus wil men geen XML factuur meer ontvangen.
Juli 2013, versie 3.02
