Met ingang van deze Releasenote een al dan niet wat drastischere aanpassing m.b.t. het oorspronkelijk ontwerp "Drydock".
Drydock is van oorsprong ontwikkeld voor een situatie waarbij we verf leveren aan een schip welke geschilderd moet worden. Dit schip kan op allerlei plekken in de wereld in een dock liggen om geschilderd te worden. Omdat vooraf niet precies bekend zal zijn hoeveel verf er nodig is, wordt er altijd voldoende besteld (of geleverd), met daarbij de afspraak dat de niet verbruikte voorraad Retour mag worden gezonden. Wat kleiner denkend is deze situatie te vergelijken met een feestje die u zelf organiseert en waarvoor u niet weet hoeveel drank u in huis moet halen. U zorgt ervoor dat u voldoende inslaat bij de drankhandel en spreekt met de winkel af dat u mag teruggeven wat u niet verbruikt.
Natuurlijk is het altijd mogelijk om iets Retour te sturen, immers, we kunnen ten allen tijde een Credit Verkooporder maken en daarmee voorraad retour nemen. "Drydock" heeft als toevoeging dat de retouren worden verrekend met de levering en per saldo op één Faktuur in rekening worden gebracht; zowel u alsmede uw klant heeft dan niet te maken met Creditnota's. U levert 100 Verschijningen, krijgt er 20 retour en brengt er per saldo 80 in rekening.
Bij de ontwikkeling van dit maatwerk zijn twee dingen door elkaar gaan lopen, waarvan inmiddels de draad een beetje kwijt is, maar nu alsnog is gesteld hoe het gebruikt behoort te worden.
Omdat de term "Drydock J/N" te specifiek is voor de schepen-situatie is voor een algemenere term "Komt Retour J/N" gekozen. Deze rubriek is op Verkooporderregelniveau ontwikkeld, en zo goed als alle funktionaliteit in Profit is daar aan opgehangen.
Later, maar in dezelfde periode (2002), is er op Verkooporderheader niveau óók een 'Komt Retour J/N' erbij ontwikkeld, welke de defaultwaarde bevatte voor de Verkooporderregels; althans, zo lijkt het als we nu kijken naar hoe het tot vandaag werkte. Hoewel hier niets in funktionaliteit van zichtbaar is, zijn er wel ontwerpen waarin staat beschreven dat de indikator op Verkooporderheader niveau *JUIST* de situatie "Drydock" betreft, en de gelijknamige indikator op Verkooporderregelniveau enkel bedoeld is om voor een normale regel ook iets retour te kunnen boeken. En, van dit laatste is inmiddels al gesteld dat het onzin is dat iemand de indikator daarvoor op Ja moet zetten, immers, als de order nog niet gefaktureerd is, moet je altijd een regel-Credit kunnen boeken.
Ok. Hoe werkt e.e.a. vanaf heden:
a. Als bij een Verkooporderheader rubriek "Komt Retour J/N" met "Ja" wordt gevuld, impliceert dit de DryDock situatie. De Verkooporder
moet dan altijd worden goedgekeurd voor Fakturatie om de order te kunnen faktureren. U moet nl. zelf bijhouden òf er nog retouren geboekt gaan worden of niet, en zolang er nog geen retouren geboekt zijn, moet dit altijd mogelijk zijn. Tot op het moment dat bekend wordt welke retouren er zijn òf dat er géén retouren zijn, dan dient de order expliciet te worden goedgekeurd voor fakturatie en kan ze worden gefaktureerd.
b. Als op Verkooporderheaderniveau de rubriek "Komt Retour J/N" niet met "Ja" gevuld wordt, betreft het een normale Verkooporder. We noteren een bestelling, leveren de order uit en kunnen dan in principe gaan faktureren (immers, alles wat geleverd is mag gefaktureerd worden). We gaan er nu vanuit dat de klant zijn goederen niet voor niets besteld heeft, en deze niet terug zal sturen. Mocht dit toch voorkomen, desnoods omdat er manco's waren, en de order is nog niet gefaktureerd, dan mogen we altijd een Verkooporderregel-Credit toevoegen. Dit toevoegen zal dan alsnog de "Komt Retour J/N" indikator op regelniveau op "Ja" zetten.
a. & b. zijn eigenlijk voldoende. Willen we Drydock, dan zetten we de indikator op headerniveau op "Ja", en is het geen Drydock, dan verwachten we toch geen retouren, en zo toch, kunnen we altijd een Creditregel toevoegen zolang de order maar niet gefaktureerd is.
c. Dan is er nog 3e mogelijkheid, welke gepaard gaat met een Bedrijfsparameter "Verkooporder Goedkeuren bij Retour t.b.v. VO J/N". Die bedrijfsparameter (die voor de a. + b. werkwijze op "Nee" gezet moet worden) zorgt er voor dat óók als op Verkooporderregelniveau een rubriek "Komt Retour J/N" met "Ja" wordt gevuld, de order eerst moet worden goedgekeurd voor fakturatie. Feitelijk zorgt deze parameter ervoor dat alles na deze Upgrade gewoon blijft werken als vanouds, maar, uitzetten van de parameter triggert de werkwijze zoals oorspronkelijk bedoeld.
Alles heeft hier nl. ook te maken met het feit of een order al dan niet moet worden goedgekeurd voor Fakturatie, waarvoor eigenlijk geldt dat dit (behoudens voor Drydock) niet aan de orde is, omdat we toch geen retouren zullen verwachten. Bij Drydock verwachten we die retouren JUIST, en dus moet daar wel worden goedgekeurd, om te bevestigen dat alle retouren geboekt zijn en er ook niet meer zullen komen.
Resteert nog 1 laatste situatie waarin een Verkooporder moet worden goedgekeurd voor Fakturatie, en dat is de situatie waarin een Bedrijfsparameter "Verkooporders Goedkeuren voor Fakturatie J/N" met "Ja" is beantwoord; daarbij dan nog met als toevoeging dat voor Debet- en Creditorders separaat kan worden ingesteld dat goedkeuring noodzakelijk is.
Resumer: een Verkooporder moet worden goedgekeurd voor Fakturatie indien "de Bedrijfsparameter zegt dat alle Verkooporders moeten worden goedgekeurd voor fakturatie", "indien het een Drydockorder betreft", òf indien een Bedrijfsparameter zegt dat alle mogelijke retouren op orderregelniveau triggeren dat de Verkooporder moet worden goedgekeurd.
Omdat de toets "Verkooporder goedkeuren voor Fakturatie" altijd aanwezig is, is het gebruik van deze toets nu uitgebreid met een melding die aangeeft of goedkeuren überhaupt nodig is of niet; immers, als niet alle orders expliciet goedgekeurd hoeven te worden en het ook geen DryDock betreft, heeft het gebruik van die toets geen zin.
In theorie zou een nog mooiere optie zijn dat we bij Raadplegen Verkooporders aangeven òf de order nog goedgekeurd moet worden. Toch doen we dat (voor nu) nog even niet, zeker niet "standaard", juist vanwege de 3e genoemde situatie, die zou vereisen dat we om een indikator bij de Verkooporder weer te kunnen geven, we eerst alle Verkooporderregels moeten onderzoeken. Dat zou de opbouw van het scherm "Raadplegen Verkooporders" onnodig doen vertragen.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOUFGN1 | Omschrijving (nog) niet bekend | 15-02-2017 | 02-03-2017 |
| LOVOGK | Goedkeuren Verkooporder | 02-03-2017 | 02-03-2017 |
