Heart-Profit ERP
July 01, 2024, 03:57:00 pm *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: kredietlimieten en geblokkeerde orders  (Read 3453 times)
0 Members and 1 Guest are viewing this topic.
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« on: June 25, 2008, 10:54:34 am »

Wij willen wat strakker gaan werken met kredietlimieten.
Dat betekent in ons geval dat wij dan moeten gaan werken met orders welke geblokkeerd worden op basis van de financiele info.
Ik weet dat dit werkt, we hebben het nu n.l. als melding aan staan.

Echter ik heb een probleem met enkele grote klanten, welke soms voor een heel jaar orders insturen. Die vliegen dan over hun kredietlimiet.
Om daar nu elke order weer te laten deblokkeren door een "controller" is ook niet echt slim.

Mijn vraag is de volgende:
Zou het mogelijk zijn om een run te verzinnen welke de openstaande orders met blok status uitfilterd, deze op leverdatum sorteerd naar klant en dan de orders tot het bedrag van de kredietlimieten weer vrijgeeft?

Dat betekent dat de verkoopbinnendienst n.l. binnen hun bevoegdheid die order toch kan laten uitleveren.

Voorstel is selectie:
klant van/tot
leverdatum van/tot

Dit om de te voorkomen dat het een hele zware run wordt om te draaien

Hoe denken jullie hierover?

mvg

Marco
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #1 on: June 25, 2008, 01:10:47 pm »

Eigenlijk is het (dan) zo dat je (formeel dus) van een Verkooporder voor over een maand niet kan weten of per dan de Kredietlimiet overschreden zal zijn. Dit zou een "aantal dagen" vergen, met daarin bijvoorbeeld 5, en waarbij die 5 afgaat van de Leverdatum om vervolgens pas op die Leverdatum - 5 te gaan kijken of de Kredietlimiet (nog of intussen !!) is overschreden.

Klinkt leuk ? Ja. Maar het werkt denk ik niet gezien de ontbrekende voorziening om de impliciet verstrijkende tijd zijn werk te laten doen.
Het is ook verre van makkelijk als je bedenkt dat dat aantal dagen op (stel) -5 staat, maar jouw procedure zo is dat je 10 dagen vooruit inkoopt (of het systeem dit domweg doet gezien een betreffende Levertijd) en je dus intussen spullen hebt ingekocht voor iets wat je wellicht voorlopig niet (of nooit) gaat leveren.
Tja ...

Ik ga maar eens een poging ondernemen om te stellen dat wat je doet niet helemaal lekker is (lukt me misschien niet hoor, maar ik probeer het in elk geval);

Ik wil niet zeggen dat wat je hier doet riekt naar Afroepen, maar het lijkt op z'n minst iets als een Kontrakt te behelsen. Zijn we daarmee geholpen ? nee, ik denk het niet, althans, niet bij de manier waarop het systeem momenteel werkt. Wèl geldt het volgende :

Als je dit ziet als een soort van Afroep (c.q. Kontraktwerking), dan zie je in elk geval dat die Afroep een expliciete aktie is, die je als trigger mag zien voor het gaan bekijken van de Kredietlimiet. Dus, zie iets voor je van het op het juiste (betreffende) moment opnemen van de Verkooporder, die dan - gelijk de andere normale Verkooporders - hun werk aangaande de Kredietlimiet echt wel doen.
We hebben nu niets te maken met de Behoefterun (kan niets te vroeg doen) en de Kredietlimiet van dat moment moeten we maar als aktueel zien (maar, kan net zoals altijd nog wachten op dat ene faktuurbetalinkje).

Aannemend dat ik nog een beete op een spoor zit waarmee je kunt leven, gaat het er dus nog slechts om hoe we het geheel (ook jullie) zo ver krijgen dat je die Verkooporders pas gaat inbrengen op het moment surpreme;

Een Kontrakt met Afroepgedachte werkt wat mij betreft 100%, maar vereist dan ook wel dat de klant op een gegeven moment weer belt met "ja, nu graag !".

Is dat zo in jouw geval ?
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #2 on: June 25, 2008, 02:04:48 pm »

Helaas,

De praktijk is andersom.
De klant stuurt 52 weekorders of 12 maandorders in en geeft aan dat die gewoon geleverd moeten worden.
Het komt wel af en toe voor dat ze een keer roepen "nu ff niet" of "doe er maar 2" maar meestal loopt het gewoon 1:1.

Vandaar dus dat ik vroeg of het mogelijk zou zijn dat deblokkeren binnen het gestelde van het kunnen voldoen aan de waarde van de kredietlimiet als een functie in te bouwen.

En dan gaat het aleen maar om het de-blokkeren van die orders en niets meer dan dat. Immers als die figuur mij betaald heeft en het systeem zegt dat levering zou mogen, waarom zou dan niet "iedereen" die order uit moeten kunnen laten leveren.

Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Menno
Knowledgable
**
Offline Offline

Posts: 398

Het is niet zo moeilijk, als je denkt.


View Profile
« Reply #3 on: June 25, 2008, 03:45:28 pm »

Goed idee, maar hoe maak je het onderscheid tussen Verkooporders welke geblokkeerd zijn doordat de Kredietlimiet is overschreden en Verkooporders welke om een andere reden (handmatig) geblokkeerd zijn. De door jou voorgestelde run zal enkel vast kunnen stellen dat de Kredietlimiet niet langer overschreden is en de Verkooporder op basis daarvan de-blokkeren.
Logged

Heart-Profit company ID : HA
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #4 on: June 25, 2008, 04:23:00 pm »

Dat wilde ik gaan sturen door bij die mensen de kredietlimiet op 1 euro te gaan zetten.
Lees, is eigenlijk boter bij de vis, c.q. vooruitbetaling.

(Ja ook wij hebben dat soort klanten)

Anders gaat het inderdaad fout en zou je die "om andere reden" geblokkeerde orders inderdaad perongeluk vrij kunnen geven

Maar om daarvoor een heel dubbel blokkeringssysteem te gaan maken lijkt me weer overdreven.
Want dan heb je ipv een J/N een J/N/H (handmatig) veld nodig en moeten alle controles die ook op andere plaatsen gebruikt worden (zoals leveren oid) ook daarop anticiperen.

Wat je natuurlijk ook kan doen met dat soort orders is de leverdatum naar 31/12/2050 gooien, tegen die tijd ben je toch waarschijnlijk wat anders aan het doen.....
(deze truuk gebruiken wij momenteel bv als we nog wachten op een LC uit het verre Oosten of zo, dat duurt soms maanden, en daar kun je geen productie op plannen)

Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #5 on: June 26, 2008, 09:44:38 am »

Dat wordt niets zo ...
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #6 on: June 26, 2008, 10:30:50 am »

Hoezo niet,
Als ik een functie heb die het in de eerste post van deze tread gestelde doet ben ik tevreden.
Dat dat zijn limiteringen heeft ben ik mij bewust.

Dat is iets waarmee wij om moeten gaan.
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #7 on: June 26, 2008, 10:38:09 am »

Helaas, zo werkt dat niet met een pakket. Sorry.
Logged

Heart-Profit company ID : HA
moderator all boards
Peter Stordiau
Administrator
Partner
*****
Offline Offline

Posts: 4073


Just testing


View Profile WWW
« Reply #8 on: June 26, 2008, 11:06:20 am »

Dit is wat je nodig hebt :


TV/WY/VW/RA Redenen voor Blokkering (22 uur).

Aktiveren / Deaktiveren Reden voor Blokkering Debiteur in Verkooporderheader (feitelijk : Koppelen/Ontkoppelen) via combobox (5,5 uur).

Aanpassen funkties die momenteel Geblokkeerd J/N van de VOHeader respekteren, op bovenstaande (4,5 uur).
(zodra één Reden aktief is geldt de status Geblokkeerd).


Bovenstaande leent zich ervoor om via allerlei soorten invalshoeken een blokkering ONgedaan te maken. Denk bijvoorbeeld aan het zijn binnengekomen van de LC waarvoor een separate funktie kan bestaan, en welke funktie simpel de "LC Reden" deblokkeert. N.b.: Dit is een voorbeeld omdat het makkelijker is dan jouw Kredietlimiet, en tevens aantoont hoe het mechanisme zal werken (en genoemde funktie is dus virtueel op dit moment).
Dat je hiermee ook allerlei paden op kunt om een blokkering te aktiveren is een andere kant van het verhaal, en waarbij je er aan kunt denken dat een Debiteur/Afleveradres iets in zich heeft van "Vereist LC", waarna bij Toevoegen van de Verkooporder om die reden de LC Blokkering erop komt.

Nu verder met jouw verhaal ...

Ten eerste, ik houd niet van runs. Runs lopen fout, worden niet gedraaid, en kreëren redundantie dan wel tonen aan dat het er is. In jouw geval geldt denk ik het laatste. Waarom ?

De Kredietlimiet wordt berekend c.q. toegepast op het moment van Toevoegen Verkooporder(regels) en that's it. Ofwel, een automatisch mechanisme om de blokkering die hiervan (evt. automatisch) het gevolg is, wordt niet automatisch ongedaan gemaakt. Ja, dat wist jij al (maar ik eigenlijk niet). Dit op zich zorgt ervoor dat de basis voor een run niet eens in legitieme vorm aanwezig is, en die zal er toch eerst moeten komen ...

Het is natuurlijk super-simpel : met het LC voorbeeld in de hand, is het ook wel mogelijk om bij een binnengekomen betaling een funktie uit te voeren die chronologisch  (Leverdatum) de Verkooporders afloopt en de Kredietlimiet opnieuw bepaalt, en waar van toepassing de VO Deblokkeert.
Héé ... daar is je "run" alsnog ! ... echter, dit is geen run die je handmatig hoeft te starten.

Als je e.e.a. op rigide wijze bekijkt, dan zie je dat tot op heden zo'n funktionaliteit niet mogelijk was, omdat er immers maar één Blokkering aan de orde kon zijn, en omdat de reden daarachter onbekend was, had een "run" in deze geen zin (lees : het automatisch Deblokkeren mocht domweg niet aan de orde zijn). Nu wel dus ...

Jouw "run" : 5 uur.
Loopt alle openstaande Verkooporders af en zodra de status van alle Verkooporderregels zo is dat ze als geheel kan worden geleverd, wordt ze Niet-Geblokkeerd. Deelleveringen worden dus NIET onderkend !!
Maar het werkt ook andersom : Als een VO niet geblokkeerd was voor deze Reden, maar nu zorgt minimaal 1 regel voor de overschrijding van de Kredietlimiet, dan zal de VO worden Geblokkeerd, ook al was dit ten tijde van invoer van de VO niet zo.
Merk nog op dat het vanzelf zo zal zijn dat een latere VO niet is geblokkeerd, en een eerdere wel, waarbij de eerdere een groter bedrag vertegenwoordigt dan de latere en de latere juist binnen de Kredietlimiet past.

De eerst-genoemde 22 + 5,5 uur krijg je van iemand anders en onder het voorbehoud dat die iemand anders dat ook afneemt.

Resteert 9,5 uur voor jou.
Logged

Heart-Profit company ID : HA
moderator all boards
mdekraa
Designer
*****
Offline Offline

Posts: 2068



View Profile WWW
« Reply #9 on: June 27, 2008, 04:42:50 pm »

ons deel is accoord

mvg

Marco
Logged

Heart-Profit company-ID : AD
-----------------------
There are 10 kinds of people, those who understand binairy and those that don't
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.03 seconds with 20 queries.