Heart-Profit ERP

Is het bij het printen van een verzamelfactuur mogelijk om dit per werk te realiseren??

Momenteel worden alle werken van een debiteur dan door elkaar heen op een factuur gezet en is het niet meer herkenbaar wat waar bij hoort.

Een optie dat wel alles bij elkaar opstaat, maar dan met een betere vermelding per werk / of afleveradres zou wellicht ook een idee zijn....

Alvast bedankt voor de reactie.
:11c:

Kun je "per werk" definiëren ?
Dus, is dat een Verkoopordernummer, een Kontrakt, anders ?

sorry, per contract

Eigenlijk is het antwoord : neen, kan niet. Dit is het gevolg van meerdere aspekten (die feitelijk allen bij jullie liggen, en dan de wijze waarop je voor het overige in het systeem werkt), maar toch wel met het volgende ideetje :

Faktureren kun je doen "op" een Orderreferentie ("Alleen Orderreferentie" aldaar). Het zou zo maar kunnen dat jullie in staat zijn (of al doen) om de Orderreferentie te vullen met iets wat 1 op 1 is het het "werk". Maar, dat verwacht ik eerlijk gezegd niet. Echter :

Omdat deze betreffende wijze van selektie bij de Fakturering (welke Verkooporders moeten mee) best gemakkelijk kan worden uitgebreid met een soortgelijke selektie zoals "Alleen Projekt", en ik zou denken dat bij "Projekt" in de Verkooporder bij jullie toch iets staat wat 1 op 1 is het "het werk", zou dat de oplossing moeten zijn. Of ? ...

Houd je wel in de gaten dat zowel Orderreferentie als Projekt zich op Verkooporder Header niveau bevinden, en de door jou aangegeven "Kontract" feitelijk Regelniveau impliceert (ik denk eerlijk gezegd dat het antwoord "Kontrakt" niet juist is, en dat je liever Projekt ziet ... maar mag je zelf zeggen hoor).
Overigens ... even uitgezocht ... het zou zo moeten zijn dat een Kontrakt bij jullie 1 op 1 is met het Projekt zoals genoemd, maar waarbij het zo zou moeten zijn dat je op Regelniveau geen Kontrakten door elkaar kan gebruiken omdat het anders met het Projekt op header niveau konflikteert.

:wacko::wacko:

ingaande op je "ideetje", we werken wel al wel met een orderreferentie, als de klant bv een werknummer wat hoort bij een contract/project op z'n factuur wil zien --> op alle verkooporders welke uit het contract zijn gegenereerd staat dus de orderreferentie gevult.

het klopt dat in 1 verkooporder niet verschillende contracten gebruikt mogen worden (1 contract "soort" per verkooporder)

m.a.w. als wij de orderreferentie correct vullen per project zou je (na een evt aanpassing) een duidelijke verzamelfactuur moeten kunnen krijgen??

Dat lijkt mij wel ja ...  :smile:

da's mooi
hoe doe ik dat dan???? cq hoe ziet het eruit?? cq wat kost het dan......???????

Dat kost niets, want het zit er al in.
Hoe het eruit ziet ? da's een goeie ... dat weten wij natuurlijk niet (want de layout's maken jullie zelf). Gewoon eerst maar eens proberen, zou ik zeggen, en dan wel in de Testbestanden natuurlijk (daar zal je toch ook wel iets te faktureren hebben ?).

We hebben in de testomgeving een aantal facturen gegenereerd, waaronder een verzamelfactuur. Deze komt goed uit de printer, behalve dat de velden 'Orderreferentie' (variabele %UF-ORREF%)  , 'Projekt' (variabele %UF-PROJEKT%) en 'Project omschr' (variabele %UF-PROJOMS%) op de verzamelfactuur niet geprint worden. Op de 'gewone' factuur (uit 1 verkooporder) gaat dit wel goed.
Waarom print hij deze variabelen op de verzamelfactuur niet uit, aangezien het om hetzelfde werk gaat?

Factuurnummers in de test:
gewone factuur 116420
verzamelfactuur 116419
:13c:

Hallo Pascal,

de genoemde Variabelen zijn Header Variabelen. I.g.v. van een Faktuur van een Verkooporder zullen deze Variabelen gevuld worden omdat er maar sprake is van 1 Verkooporder en zodoende de Orderreferentie enz. bekend is en voor deze Faktuur.

In geval van een Verzamelfaktuur zal er van meerdere Verkooporders 1 Faktuur worden gemaakt. In dat geval hoeft dus de Orderrefentie niet gelijk te zijn en zal deze niet afgedrukt worden. Daarvoor zijn dan weer Herhalende Variabelen %HH:ORREFO:xx%, %HH:PROJOMS:xx% en de %HH:PROJOMSE:xx% variabelen die op regelniveau de gegevens afdrukt. Helaas is voor het Projekt-id (nog) geen Layout-Variabele op Regelniveau aanwezig (Kost 0,5 uur).

In het geval van Faktureren op basis van Orderreferentie, zullen dus nog steeds meerdere Verkooporders op deze Verzamelfaktuur terecht komen, echter de Orderreferentie is voor al deze Verkooporders wel gelijk aan alkaar.

Dus als je het op Header-niveau gerealiseerd wilt hebben, zouden we dat op een andere manier moeten gaan oplossen. Waarschijnlijk een drietal nieuwe Variabelen. We zouden namelijk alle Faktuur-regels moeten gaan doorlopen en bepalen of de Orderrefentie, Projekt/-Omschrijving van de opgenomen Verkooporder niet afwijken t.o.v. elkaar en dan deze nieuwe Variabelen vullen.

Voor de verzamelfacturen die wij maken zijn de Orderreferentie en Projekt/-Omschrijving altijd voor alle faktuur-regels gelijk; de verkooporders die het betreft worden altijd uit hetzelfde kontrakt gegenereerd. Wat mij betreft kan in de header desnoods gewoon de Orderreferentie, Projekt en Projekt-Omschrijving uit de eerste regel overgenomen worden.

Dit is op zich ook niet verkeerd denk ik, maar hoeft voor ons niet perse.

vraagje mbt het draaiende bolletje: ik neem aan dat, aangezien hij nog draait, ook mijn post welke eronder staat wordt meegenomen?
Want van mij mogen de benodigde aanpassingen die nodig zijn, uitgevoerd worden.
Of moet er dan ook daar een draaiende bol komen?

Pascal,

je wilt dus een 3-tal nieuwe Header Variabelen die gevuld worden a.d.h.v. de eerste regel?
 

Ja, perfect.

Zie http://ha1.heartprofit.nl/profit/index.php?topic=19893.0;topicseen en staat op je systeem.

wat een toeval - ik was net een quick-reply aan het typen toen ik de notify van je binnenkreeg :smile:

bij deze is mijn vraag al beantwoord, bedankt.

We kunnen nu mbv de 3 nieuwe variabelen de header vullen met de gegevens van de 1e verkooporder.
Maar printen van een verzamelfaktuur per werk (per kontrakt in Profit) lukt nog niet.

Wanneer ik bij de debiteur aangeef dat hij een verzamelfaktuur moet ontvangen (klant LARHAR) en vervolgens ga ik naar 3-3-3 Genereren fakturen en ik geef hier een range op bij Eerste t/m Laatste Verkoopordernr (in dit geval 20080925001 / 20080925006) wordt keurig een verzamelfaktuur afgedrukt. Maar dus nog niet per werk/kontrakt: zie schermafdruk.

We willen dus graag voor bepaalde klanten per werk een verzamelfaktuur kunnen printen. Onderstaand voorbeeld bevat 6 verkooporderregels: de eerste 4 uit 1 kontrakt > hiervoor willen we graag 1 faktuur. De 5e regel komt uit een ander kontrakt, hiervoor moet een 2e faktuur gegenereerd worden. De laatste regel komt uit nog een ander kontrakt, hiervoor moet tenslotte nog een aparte faktuur gemaakt worden.

Om dit te realiseren en ook nog eens per klant aan te kunnen kiezen of de faktuur per kontrakt gegenereerd moet worden, moet er waarschijnlijk een aanpassing aangevraagd worden? Nieuwe layout (net als week/maandfaktuur)?

Dit is nog niet zo zeer een reaktie op bovenstaande, maar meer een soort samenvatting van een telefoontje met nlevers-cornet.
Ik vrees dat het allemaal nauwelijks is te volgen ... dus eerst maar eens kijken of dat is gelukt.

Als een Verkooporder vanuit een Kontrakt wordt gemaakt, komt in de Orderreferentie het Kontraktnummer te staan.
Een Kontrakt kan wel 1 op 1 met een Projekt/werk zijn, maar dat hoeft niet (meerdere Projekten voor 1 Kontrakt (wat op zich bijvoorbeeld 2 jaar loopt)).

vdB claimt dat als een klant (lees : aannemer) bestelt, deze geen Orderreferentie o.i.d. noemt of heeft, maar wel het "werknummer" noemt.

Over verschillende Verkooporders heen, zie je op deze wijze dezelfde Orderreferenties, en ik claim dat dit onjuist is; je kan nu niet meer met de klant communiceren over "de" order.
Voorheen merkte niemand dit, maar nu lijkt het toch de konstatering dat er een gegeven ontbreekt om een Verzamelfaktuur te maken, en nog te kunnen zien welke Verkooporder bij welke Faktuurregels hoort.
Uiteindelijk lijkt het al in eerder stadium fout te gaan, namelijk de selektie van welke Verkooporders er moeten worden gefaktureerd, waar men wil verzamelen op "werk", ofwel Projekt. Merk op dat dit momenteel (nog) kan worden vertaald naar "verzamelen op Orderreferentie", maar wat juist niet meer zal kunnen als de Orderreferentie een werkelijke Orderreferentie wordt, en het Kontraktnummer (o.i.d.) in een daarvoor nieuw bestemd veld komt te staan.


Wat ik overigens niet begrijp is waar het veld Projekt-ID is gebleven, wat ik zou verwachten op Verkooporder Headerniveau, en waarvan mij bijstaat dat dit juist hiervoor is gemaakt (en nog voor vdB ook).

:wacko:
:blink:

Zie http://ha1.heartprofit.nl/profit/index.php?topic=20793.0

Als toelichting op onze werkwijze mbt verzamelfakturen, zie onderstaand voorbeeld van Nathalie:

Contract à klant Timmerhuis in dit geval geeft aan dat voor het hele werk Beltrum het werknummer 824 geldt, dit wordt vermeld onder referentie.
Bij een afroep zal de klant zeggen : voor werk Beltrum heb ik nodig……, indien er dan onduidelijkheden zouden zijn kun je voor de volledigheid vragen naar het werk/referentie nummer.  Dit nummer wordt op het moment dat er van het contract afgeboekt wordt automatisch overgenomen naar het veld orderreferentie van de verkooporder, zodat dit zichtbaar wordt op de factuur, wat de klant graag wil inzake zijn eigen factuur afhandeling. zie afbeelding 1

Aan een zelfde contract kunnen meerdere afleveradressen hangen, maar ook hier geldt dat overal hetzelfde referentienummer van de klant hangt. zie afbeelding 2

Het werk/referentienummer komt terug in/op de verkooporder en later dus op de factuur. zie afbeelding 3

Een contract staat voor meerdere leveringen (evt. op meerdere adressen) waar eenzelfde referentie aanhangt.
Een klant zal indien er een vraag is over een levering aangeven naar welk adres het is gegaan op welke dag en zal evt. het referentienummer melden àterugzoeken gebeurd dus niet op referentienummer maar op verkoopordernummer of vrachtbriefnummer.

Conclusieà de administratie van de klant wil het referentienummer zien op de factuur; klant zelf (uitvoerder) communiceert anders dan HP het in gedachten heeft, maar is daarom niet onjuist!! Aangezien er op meerdere manieren gecommuniceerd kan worden en wij het op deze manier doen en dus het systeem gebruiken en niet misbruiken…..,maar als het zo zou zijn dat je een referentie maar één keer mag gebruiken is het al niet logisch dat het op deze manier in HP zit en moet dat dus door HP opgelost worden zonder dat wij daar “last” (lees kosten) van hebben.

Voor een verzamelfactuur zou je dus logischerwijs gebruik moeten kunnen maken van  selectie op veld referentie dan wel op contract/project. Waarna er dus op een factuur alleen maar gegevens staan van één en hetzelfde werk en op een volgende factuur een ander werk. Dat dan op de verzamelfactuur niet meer herkenbaar is om welke verkooporders het gaat is vervelend, maar volgens Pascal op te lossen door een ander lay-out te gebruiken.

Het lijkt mij als gebruiker dus niet zo heel erg moeilijk om het systeem zo te maken dat het mogelijk is om datgene er uit te krijgen is wat ik als gebruiker graag zou willen hebben….zonder dat een andere gebruiker er last of profijt ;) van heeft.

Voor vragen, neem aub contact op Nathalie

Nathalie,

Ik vrees dat je het wat te negatief brengt;
E.e.a. heef helemaal niets te maken met hoe Heart-Profit in elkaar zit, maar met hoe deze wereld in elkaar zit. Dat jij dat anders ziet dan bijvoorbeeld ik, is duidelijk. Maar dat houdt nog niet in dat je daarmee een oplossing afdwingt.

Waarom zeg ik dit ? geen idee. Omdat je het wat TE negatief brengt. Dus.

Ik probeer uit te leggen hoe wij werken, zodat dat voor jou duidelijker wordt...
Ik dwing niet iets af, maar vind wel dat er een oplossing mogelijk moet zijn voor deze kwestie.
Dus bij deze de vraag hoe ziet een mogelijke oplossing er uit, aangezien we daar toch uiteindelijk naar toe proberen te werken!!

Wij werken hier iets uit. Is nog niet gelukt want Wouter (waar je feitelijk al veel mee hebt doorgenomen) is even druk.
Komt goed !

Helemaal Top!!!

Fakturen van klanten waarbij aangegeven is dat ze verzamelfakturen moeten ontvangen, gaan nu ineens per werk :smile:
Hebben jullie al iets aangepast in het systeem?

Nee. Niet bewust in elk geval.
Ik denk eerder dat Nathalie iets heeft veranderd aan de inrichting n.a.v. het gesprek met Wouter vorige week. Zou dat kunnen ?

ik ben geheel onschuldig, sorry.
het lijkt erop dat er in de update iets heeft gezeten ofzo....

Nou, graag gedaan dan. Alleen jammer dat nu niemand meer weet wat de status is. Althans, wij hier niet.

Om het even niet te moeilijk te maken : wat is nu jullie behoefte nog aangaande dit topic ?

ik ga nu het één en ander testen en als ik nog wat mis horen jullie dat.
dus op dit moment hoeven jullie even niets te doen en gaan wij er weer mee aan het werk.

Wanneer het ene werk uit een kontrakt komt en het andere niet, dan wordt de verzamelfactuur keurig gesplitst (werkje uit een kontrakt op een faktuur, het werkje niet uit een kontrakt op een 2e faktuur).
Ga je nu verzamelfakturen printen waarbij er 2 werkjes uit 2 verschillende kontrakten komt, wordt alles op 1 faktuur gezet, in plaats van per werk een faktuur te genereren.

Kunnen jullie hier eens naar kijken? Vraag aub even naar Nathalie voor eventueel aanvullende info.

*schopje*

Als er meerdere Verkooporders op een Verzameldfaktuur komen te staan dan komt dat omdat
ALLE volgende gegevens van de betreffende Verkooporders overeenkomen :
 
De Valutakode is gelijk,
Betalingskondities zijn gelijk,
Leveringskondities zijn gelijk,
ABC-Transaktie is gelijk,
Verkoopmaatschappij is gelijk,
(niet-)Intracommunautaire Levering is gelijk,
Opdracht tot Export is gelijk,
Samenvoegen met Debiteur is gelijk,
Landkode is gelijk en
type Verkooporder is gelijk.

Niet meer en niet minder.

Dat het werk en niet-werk 2 fakturen zijn geworden, komt omdat niet alle bovenstaande gegevens overeenkomen (waarschijnlijk andere Betalings-/Leveringskodities ??).
Dat er bij jullie 2 werken uit 2 verschillende kontrakten bij elkaar op een verzamelfaktuur staan komt dus omdat wel is voldaan aan alle bovenstaande voorwaarden!

oke

dan staat het voorgaande "probleem" nog steeds, dus svp weer opnieuw naar kijken (als Wouter nu wel tijd heeft).

thanks Nathalie

Luister en huiver ...

Ten eerste, zie de langere tekst hieronder, wat een deeltje uit het ontwerp voor jullie betreft (waarbij het totaal de 1000 A4 denk ik wel haalt :swoon:).

Ten tweede, daarin staat dus precies wat ik met Nathalie enkele weken geleden telefonisch heb besproken, met daarmee mijn eigen opmerking nog eens aanhalend "er zou een Projekt-id in de Verkooporder Header moeten staan".

Ten derde, met Yvonne's mooie rijtje, kan je nu goed zien dat daar precies dat Projekt-id ook in zou moeten.

Ten vierde, ik heb altijd gelijk (kompleet overbodige opmerking natuurlijk :fishy:).

Ten vijfde, met onderstaande tekst erbij loop ik naar Yvonne met de vraag of zij (oude) sporen kan vinden van het Projekt-id in Toevoegen (enz.) Verkooporder, of desnoods de LOVO tabel. Vervolgens komt Yvonne er mee dat jullie samen juist gisteren tot precies deze oplossing zijn gekomen omdat bleek dat er een Projekt-id in de LOVO tabel aanwezig was.

Ten zesde, dit kost 7 uur voor ook het uitzoekwerk, en niet alleen de 1,5 voor de benodigde aanpassing die Yvonne heeft doorgegeven. :sorry:.

Let op : Ik denk niet dat ik het ermee eens ben dat het Projekt-id dan weliswaar onderwater aanwezig is, je het nog nèt kunt zien bij F1-Weergeven, maar dat je het zelf niet kan invullen of overschrijven. Wat mij betreft leidt dit tot totale onduidelijkheid, en een raadplaatje als fakturen er toch een keer niet juist uitkomen, met daarbij dus ook nog de onhebbelijkheid dat je het niet goed kan krijgen. *Ik* zeg dus dat de intussen met Yvonne afgesproken aanpassing niet is toegestaan zonder dat Toevoegen en Wijzigen Verkooporder Header m.b.t. kunnen invullen van Projekt-id wordt aangepast. Zie ook onderstaande langere tekst.

Extra kosten : 1 uur.


Die tekst hierna dan maar ter lering en vermaak, waarbij je overigens best mag aangeven waar zaken intussen anders zijn.
Zie ook de tekst rond de Orderreferentie (telefonische "discussie") en hoe daarmee dus rekening wordt gehouden.
Merk wel op dat dit een ontwerp betreft voor zaken ("Scoring") die niet zijn afgenomen, doch de gehanteerde principes (in Profit en in ons hoofd) niet anders zijn (geworden).
Wèl zal het zo zijn dat iemand bij BBB op een gegeven moment heeft gevraagd om de Orderreferentie door het systeem met het Kontrakt-id te laten vullen, en wat wat mij betreft fout is en blijft. Echter, alles moet in het consistente geheel worden gezien, waarvan onderstaande tekst toevallig een aardige weergave is (mocht je het kunnen volgen  :smile:).

---

In principe moet het zo zijn dat als de aannemer afroept op het Kontrakt, dat dit leidt tot een nieuwe Verkooporder, met vooral de opmerking dat dit op een dag X gebeurt, en dat op een dag Y de aannemer vraagt hoe het met z'n bestelling van dag X staat.
Dit dient te worden geregeld middels de normale Orderreferentie in de Verkooporder, eraan denkend dat juist dit fenomeen is bedoeld voor de betreffende benodigde kommunikatie tussen klant (aannemer) en leverancier (BBB).
Benadrukt wordt dat dit tegen het mechanisme van de Scoring indruist (zie eerder), omdat het uitgangspunt dient te zijn dat de aannemer zegt "noteer deze afroep maar onder xyz", terwijl de Offerte-scoring er vanuit gaat dat de Orderreferentie is gevuld met de Referentie van de Offerte. Het bestaande mechanisme zal door deze werkwijze onderuit worden gehaald, en moét ook onderuit worden gehaald. Met andere woorden, dit betreft een te noteren "aanpassing" in het eerder genoemde verslag, waarbij BBB meteen al niet meer van het standaard aanwezige Scorings-mechanisme gebruik zal kunnen maken, en waarbij een toekomstige aanpassing het hanteren van een nieuwe rubriek in de Verkooporderheader betreft (Offerte-referentie o.i.d.). Toekomstig dus, en nu niet te ontwikkelen, maar wèl te noteren.
Volledigheidshalve wordt opgemerkt dat bovenstaande niet in de teksten van BBB zelf is terug te vinden, en dat BBB zelfs expliciet zegt "wij hoeven niet op deze wijze te kommuniceren met de aanne mer". Dus, waar BBB expliciet zegt "hoeft niet" zeggen wij "gebeurt toch". Maar dan wèl op een wijze dat BBB hiervan geen last heeft, wat in theorie zou moeten inhouden dat BBB de Order referentie leeg laat, waar de aannemer inderdaad niets noemt.
Dus : géén getructe "vulling" van de Orderreferentie uit Kontrakt id o.i.d., maar gewoon beschikbaar voor "invullen of niet" zoals gebruikelijk.
Wèl zal dit zeker inhouden dat er "een rubriek" bij de Verkooporder is benodigd om aan te geven over welk Kontrakt (Projekt) het gaat, omdat zeker dàt de benodigde info voor BBB is.
Het is dan ook zo dat er een 1 op veel relatie bestaat tussen het Kontrakt (Projekt) en het aantal keren dat erop wordt afgeroepen; Iedere keer afroepen betekent "noteer maar xyz, dat refereer ik daar een volgende keer aan".
Om het geheel goed te begrijpen, en ook om de genoemde feitelijke noodzakelijkheid van een "nieuwe Verkooporder" voor een volgende afroep te verantwoorden, mag worden gedacht aan het principe van de Orderbevestiging, waar het zo zou moeten zijn dat ook een afroep zoals in deze voor BBB bedoeld, moet kunnen worden bevestigd met een Orderbevestiging, ook al vindt BBB dat ze dit echt niet zal gebruiken.

 
De rotonde wordt omschreven in een Projekt zoals dit bestaat in het systeem. Het zal dan ook zo zijn dat als er een aanvraag (van een aannemer) komt voor een Projekt waarvoor nog niet eerder een aanvraag is geweest (nog nooit eeder gehoord van deze rotonde), BBB eerst een Projekt aanmaakt voor de rotonde.

 
Wanneer de Offerte wordt gepromoveerd tot Kontrakt, zal het Kontrakt-id gelijk worden aan het Projekt-id van de Offerte; De relatie tussen "gescoorde Offerte" en het daarbij behorende Kontrakt, is dan ook 1 op 1. Dit geeft de verantwoording voor het mogen hanteren van het Projektnummer in het Kontrakt-id.
Opgemerkt wordt dat een Kontrakt (ook voor BBB) tevens gewoon rechtstreeks zal kunnen worden toegevoegd, dus zonder dat ervoor een Offerte is gemaakt. Wèl zal het voor BBB aan de orde zijn dat minimaal een Waarschuwing volgt (Esc = Terug) als -dan- een Kontrakt-id wordt ingevuld dat niet bestaat als Projekt.
Dit (indien nodig) te regelen via de Bedrijfsparameter van =0001/1=.

 
Om diverse (moeilijk te overzien) redenen, zal ook het Kontrakt een Projekt-id moeten bevatten, waarbij deze -redundant- (automatisch) wordt gevuld met het Projekt-id van de Offerte, dan wel met de hand wordt ingevuld bij rechtstreeks Toevoegen. Het belangrijkste argument zal w.s. zijn het afroepen op het Kontrakt, en dus het maken van een Verkooporder uit het Kontrakt, waarbij ook de Verkoop order het Projekt-id zal moeten kennen.
Andersom, als het Kontrakt geen Projekt kent, zal de Verkooporder die daaruit volgt het Projekt-id eveneens niet kennen;
Gezien het voorgaande dient tijdens de ontwikkeling te worden bepaald of -en in welke gevallen- het Projekt-id mag worden overschreven (desnoods met " "), wat zowel geldt voor het Kontrakt als de Verkooporder, en zelfs voor de Offerte.

 
Bedacht mag worden dat het Projekt-id, wat volgens voorgaande in zowel Offerte als Kontrakt als Verkooporder ter sprake is, belangrijker zal zijn dan de normaliter getoonde Debiteur-id.
Ook mag worden bedacht dat als het werk eenmaal in het stadium Kontrakt of Verkooporder is, de "rotonde" belangrijker is om te zien voor BBB dan "aannemer Jansen". Hieruit mag volgen dat in het specifieke geval BBB, en werkend op deze wijze, nog wèl het Debiteur-id in de betreffende RA-Overzichten mag worden ge toond, maar vooral in plaats van de Naam van de Debiteur, de Omschrijving van het Projekt moet worden getoond. Met op dat deze algemene werkwijze niét opgaat voor de Offertes, en dat juist daar de Naam van belang is, en beide ID's.

 
Als laatste :
Minimaal in theorie, zal het kunnen voorkomen dat er meerdere aannemers werken aan feitelijk hetzelfde werk, dus aan dezelfde rotonde. Met andere woorden, denkend aan al het voorgaande, moet dit "technisch kunnen". Echter, denkend aan de voor BBB uiteinde lijk gewenste scoring, zal het "genormaliseerd bekeken" nooit zo kunnen zijn dat voor beide -dus !- deel-werken aan de rotonde (stel bestrating versus het platform) eenzelfde Projekt-id door BBB wordt toegekend. Dus, de ontwikkelaar hoeft zich hiermee niet te vermoeien, ofwel, komt vanzelf goed. Hooguit geldt in deze voor BBB de "tip" dat ze in staat is beide deel-Projekten hiërarchisch te hangen onder het hoofd-Projekt ("rotonde"), wat bijna ook noodzakelijk lijkt, omdat het toch zo is dat BBB het volledige Projekt verzorgt. En, vooral denkend aan een toekomst waarbij BBB toch meer middels het systeem zal verzorgen dan momenteel (Werkorders !) lijkt het noodzakelijk dat BBB vanaf het begin op deze werkwijze anticipeert.

---