Heart-Profit ERP
September 30, 2024, 07:15:19 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: Blokkeren wijzigen "Komt Retour J/N"  (Read 807 times)
0 Members and 0 Guests are viewing this topic.
Heart Informatisering B.V.
Partner
******
Offline Offline

Posts: 27468


View Profile WWW
« on: November 03, 2016, 02:28:37 pm »

Bij een Debet Verkooporder kunnen we (op headerniveau) een rubriek "Komt Retour J/N" met "Ja" vullen i.g.v. een zgn. "DryDock" situatie. Binnen dit ontwerp leveren we bijvoorbeeld 1000 Verschijningen aan een schip welke in een drydock ligt maar willen we de mogelijkheid open houden om later alle niet verbruikte goederen retour te kunnen boeken op dezelfde order, waarna het saldo in rekening wordt gebracht. Ofwel, na verloop van tijd stuurt de klant 200 Verschijningen retour, wordt de Faktuur opgemaakt en krijgt ze een rekening waarop 800 Verschijningen in rekening worden gebracht. Voordeel voor zowel u als uw klant is dat er niet over en weer met Creditnota's hoeft te worden gewerkt.

De 200 Verschijningen die Retour komen, kunnen middels VO-Regelmenu optie Q worden geregistreerd. Dit genereert een zogenaamde Verkooporderregel-Credit die door de fakturatie gesaldeerd zal worden met de levering. Overigens wordt ook hier een rubriek "Komt Retour J/N" gebruikt, maar nu voor een ander doel: om aan te geven of de goederen die u gaat crediteren daadwerkelijk aan u retour gestuurd zullen gaan worden of niet. Wordt deze rubriek op "Ja" gezet, dan zal er een Ontvangstorder worden gegenereerd waarmee expeditie de 200 Verschijningen volgens de normale Goederen Ontvangst procedure terug op voorraad kan boeken. Zowel aantal, prijs als kostprijs zal nu worden gekorrigeerd op de Faktuur.

Nb: Overigens wás het ook mogelijk om een V.O. regel Credit te maken zónder dat de Goederen Retour kwamen, maar, dit kon wel eens een optie zijn die door ons zelf bedacht is, en niet werkt binnen het mechanisme van verrekenen op dezelfde Faktuur! In die situatie werd op zich alleen aantal en prijs tegengeboekt, maar niet de kostprijs. Hoewel dit niet verkeerd lijkt, levert het wel een totaal ander resultaat op voor de statistieken, en daarmee moeten we het eigenlijk als "fout" betitelen.

Bedenk ook maar dat als we geen DryDock hebben, en we 1000 Vrs geleverd en gefakureerd hebben, we op twee manieren kunnen crediteren: of we crediteren een prijs (waarbij dan het aantal niet aan de orde is) ňf we crediteren aantal en prijs (in welk geval we een CreditVerkooporder moeten maken en 1:1 met die Credit Verkooporderregel een Retour Inkooporder wordt gegenereerd). En dan zouden we hier toestaan dat we iets NIET retour kunnen krijgen, dus geen Retour Inkooporder, maar wel aantallen crediteren? Het klopt gewoon niet!

Dit DryDock maatwerk is ongeveer 20 jaar geleden ontwikkeld, maar pas recentelijk in gebruik genomen. Hierdoor komen nu pas een aantal onvolkomenheden aan het licht. Van de klant voor wie e.e.a. ontwikkeld is weten we ook dat ze ALTIJD de goederen retour boeken. Retour "Nee" is derhalve ook geblokkeerd vanuit deze Releasenote. Mocht iemand daardoor iets niet meer kunnen, dan kunnen we dat alsnog beoordelen (maar dan wellicht met praktijk voorbeelden). Merk ook op dat als we "Komt Retour J/N" bij een V.O.-Regel-Q niet op Nee mogen zetten, we ook net zo goed de defaultwaarde op Ja kunnen zetten, of nog beter, er niet eens meer om vragen. Toch doen we dat vooralsnog even niet, opdat de gebruiker dezelfde handelingen moet blijven verrichten als voorheen, en dan wel volgt dat ze iets ineens niet meer kan. Zouden we de rubriek weghalen, dan merkt de gebruiker niets, en gaat er mogelijk ineens iets anders werken zonder dat iemand dit in de gaten heeft...

Terug naar de "Komt Retour J/N" van de Debet Verkooporder:

"Komt Retour J/N" op headerniveau wordt alleen gebruikt om de default waarde voor de gelijknamige rubriek op Verkooporderregelniveau te setten. Op zich spreekt het voor zich dat "Komt Retour J/N" alleen aan de orde is voor Debetorders, immers, op een Creditorder leveren we zelfs niets en zou "Komt Retour" hooguit iets anders kunnen bedoelen dat hier voor ogen.

Hiermee komen we meteen op het 1e probleem: "Komt Retour J/N" was voor Creditregels geblokkeerd. Mocht een Creditregel worden gewijzigd dan werd "Komt Retour J/N" zelfs hard op Nee gezet (je mocht immers toch geen Ja invullen). Hier had het zo moeten werken dat alleen een Creditregel van een Credit Verkooporderregel niet op Ja mocht staan; een Creditregel op een Debetorder betreft de door VO-Regelmenu optie Q gegenereerde Verkooporderregel-Credit, en daar werd juist met deze rubriek aangegeven of de Voorraad retour kwam ja/nee.

Resultaat is dat als zo'n Verkooporderregel-Credit werd gewijzigd (LOVRWY) dan werd "Komt Retour J/N" op "Nee" gezet, met als gevolg dat de Fakturatie niet meer op zoek ging naar retour ontvangen goederen en diens kostprijzen, en enkel de aantallen crediteerde, maar niet de kostprijs van de retouren in mindering bracht op de Faktuur.

Een tweede probleem, wellicht iets minder voor de hand liggend omdat de gebruiker zou mogen verwachten dat ze daarmee ellende zou gaan veroorzaken, was dat we achteraf bij de oorspronkelijke Verkooporderregel waarop we de 100 Verschijningen hadden geleverd, middels Wijzigen Verkooporderregels (LOVRWY) rubriek "Komt Retour J/N" alsnog weer op "Nee" konden zetten, ook al was er al een Verkooporderregel-Credit gegenereerd. Het effekt daarvan was dat de fakturatie niet eens op zoek ging naar eventuele retouren, immers, "Komt Retour" stond op Nee.

M.i.v. deze Releasenote zijn beide problemen verholpen.

FunktieOmschrijvingDtm.Vl.WyzDtm.L.Wyz
LOUFGNCO    Omschrijving (nog) niet bekend    10-12-2015    02-11-2016
LOUFGNLL    Omschrijving (nog) niet bekend    14-07-2016    02-11-2016
LOVRGNCR    Toevoegen Verkooporderregel-Credit    10-08-2016    03-11-2016
LOVRWY      Wijzigen Verkooporderregels    04-07-2016    02-11-2016
LOVRWY1     Omschrijving (nog) niet bekend    01-12-2015    02-11-2016
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1 RC2 | SMF © 2001-2005, Lewis Media Valid XHTML 1.0! Valid CSS!
Page created in 0.159 seconds with 20 queries.