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
).
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
).
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.
.
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
).
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.
Show Posts
