[C#/ALG] Facturen & Kortingsregels

[beany]

Ik ben bezig met een applicatie waaruit facturen gedraaid moeten gaan worden. Opzich is dit niet het probleem. Echter, het programma gaat door een paar honderd bedrijven gebruikt worden, en ieder bedrijf heeft zijn eigen wensen wat betreft kortingen. De 1 wil over een factuur x procent korting geven als de factuur groter is dan Y euro, en de ander wil x procent meer korting geven als medicijn Z is gebruikt, en weer een ander wil korting geven als de klant de afgelopen 6 maanden elke maand minimaal 150 euro heeft besteed en ga zo maar door. Het aantal kortingsregels kan behoorlijk uit de klauwen lopen.

Nu is de vraag natuurlijk hoe dit generiek op te gaan lossen. Mijn eerste gedachte was om een aparte DLL te maken met daarin alle kortings functies. Echter, dit is niet erg flexibel en voor de klant totaal niet aan te passen. Wel lekker uurtje factuurtje schrijven voor ons natuurlijk, zonder korting

Een andere oplossing is een script engine gebruiken. LUA(met de lua interface lib voor .Net) lijkt mij de meest geschikte. Dat maakt het geheel een stuk flexibeler. Alleen denk ik dat een eindgebruiker weinig zal snappen van lua, het blijft een programmeer-taaltje. Want het lijkt mij het meest efficiente als een eindgebruiker zijn eigen kortingsregels kan ingeven.

Weer een andere oplossing is het door de gebruiker laten ingeven van simpele regels. Iets als:

code:

korting TotaalFactuur
   Als FactuurBedrag > 500 dan Factuur.Korting = 5%
   Als FactuurBedrag > 1000 dan Factuur.Korting = 7%
einde korting
korting AantalBezoeken
   Als Klant.Bezoeken(vandaag, vandaag - maand(1)) >= 5 dan Factuur.Consult.Korting = 50%
einde korting

En dan de kortingen(TotaalFactuur, AantalBezoeken) kunnen koppelen aan klant, klantgroepen, factuurtypen etc.

Dit zou wel het mooiste zijn, alleen hoe maak ik zoiets? Of, zijn er andere methoden om een flexibele manier aan te bieden? Zijn er mensen die hier ook tegen aan zijn gelopen, en hoe is dat opgelost?

[MMUilwijk]

Waarom neem je hier niet iets voor op in je database? Ik heb zo 123 geen voorbeeld model liggen, maar het moet natuurlijk goed mogelijk zijn om iets generieks te bedenken om zo de regels als het ware vast te leggen in je database.

Daarnaast kun je de regels wellicht ook nog op een andere manier opslaan (XML o.i.d?). Met behulp van een goed doordachte interface kunnen je klanten dan zelf rekenregels opnemen. Omdat het altijd wel over je verkoopproces gaat vereist het niet extreem veel flexibiliteit ten aanzien van je business entities (zal altijd wel iets te maken hebben met entiteiten klant, order, artikelen)

[Webgnome]

Ik zou zelf gaan voor de laatste oplossing. Een interpreter (hoewel ik het zelf nooit heb gedaan) kan niet heel erg lastig zijn.

Ergens krijg je je input vandaan (formule??) in de vorm van een simpele String. Je zou dan via regex bepaalde standaard woorden die in jou 'taal' beschikbaar zijn kunnen opzoeken en dan door het analyzeren van die string verder uitzoeken wat nou precies de bedoeling is.

Maar voordat je dit doet zul je eerst dus moeten nadenken over welke vaste variabelen je hebt in je taaltje.

[beany]

Het probleem is eigenlijk dat ze de meest idiote regels hebben. In de trant van:

Als van medicijn A minimaal 5ml is gebruikt EN factuurtype Foo is gebruikt EN het zaterdag OF maandag is EN de behandelaar Meneer X is EN medicijn uit batch 12345 komt DAN krijgt de klant korting.

Ook wordt er veelvuldig gebruik gemaakt van staffels.

Dus mijn gevoel zegt dat simpele database regels niet gaat werken. Ook XML denk ik niet, kan het niet echt onderbouwen.

Ik ben gewoon een beetje bang dat als ik een weg in sla, dat ik op het einde van de rit er achter kom dat ik flexibileit mis en de boel kan gaan ombouwen.

En met een eigen interpreter zit je ook met zaken als rekenwerk. Bijvoorbeeld (10(-1)*2+3-5)/3. Volgens mij niet geheel eenvoudig te maken??

[Voutloos]

Maar is die flexibiliteit wel een wens van het gros van je klanten? Want ze mogen allemaal meebetalen aan de implementatie van Het Kortings Systeem^TM, terwijl misschien voor 80% vd klanten enkel een paar eenvoudige kortingsproducten en support voor een regeltje als 'boven €x, y% korting' gewoon meer dan zat is?

[Niemand_Anders]

Heb je al eens naar Windows Workflow Foundation gekeken? Onderdeel van het .net platform vanaf versie 3.0.

Het inladen van workflows per bedrijf is vrij simpel en de rules (xml bestand) zijn on-the-fly aan te passen. Hiermee kun je voor elk bedrijf de meeste gekke business rules formuleren.

Wij zijn werkzaam in de financiele sector en ook daar heeft elk bedrijf zijn eigen wensen. Workflow Foundation (WF) was voor ons in elk geval een uitkomst. Sindsdien gebruiken wij WF op elke plek waar wat meer dynamische business rules mogelijk moeten zijn (denk aan validatie). Omdat de business rules niet hardcoded zijn, zijn updates ook gemakkelijk door te voeren zonder dat een onderdeel aan de andere kant van je applicatie ophoud met werken..

[chris]

Ja, wat je eigenlijk doet hier is een compiler schrijven. Dit is niet persé heel lastig, maar het helpt wel als je enige ervaring er mee hebt. Je hebt een aantal stappen:

1. Parsen van de syntax naar een AST (Abstract Syntax Tree)
2. AST checken op correctheid
3. AST vertalen naar je applicatie, dus een semantiek er aan hangen.

[PV85]

Zoals ik hierboven kan opmaken heb je eigenlijk één of meer voorwaarden met daaraan gekoppeld een korting in de vorm van een bedrag of %.

Als je de OF regels in je voorwaarden negeert, dan heb je eigenlijk alleen maar EN regels, wat betekent dat je de gebruiker gewoon een lijstje met voorwaardes kan laten opstellen, en daaraan een korting op de factuur kan koppelen.

De OF regels kun je negeren, want die kan de gebruiker realiseren door gewoon nog een lijstje voorwaarden op te stellen, met daaraan dezelfde korting. Hierdoor hou je de opzet een beetje simpel voor de gebruiker lijkt me. Dit betekent wel dat je meer regels kwijt bent in sommige gevallen, maar zoveel zullen dat er vast niet zijn.

[beany]

Nou, het is nog wel wat complexer. Het hangt allemaal aan elkaar. Kortingen worden wel of niet gegeven ook aan de hand van voorgaande kortingen die wel of niet zijn gegeven.

Ik ben bang dat het toch een interpreter achtig iets moet gaan worden nu ik er wat langer over aan het nadenken ben.

[CodeIT]

Een eigen interpreter geeft het meeste vrijheid maar is imho niet erg gebruiksvriendelijk, ervan uitgaande dat de gebruikers de regels zelf moeten maken.
Ik vind de manier die Outlook gebruikt voor 'Rules' wel een chique oplossing. Veel variabelen en toch gebruiksvriendelijk (en volgens mij koppelbaar).

[bigbeng]

Je wil iets ongestructureerds gaan structureren. Dat wordt lastig. Ik denk dat het een beter idee is om met de klant om de tafel te gaan en te zeggen: "<Insert wat Voutloos al zei>". Je kunt proberen ze in te laten zien dat dat niet gaat (voor een prijs die zij redelijk achten).
Een andere mogelijkheid is om ze met het handje een kortingspercentage bij een factuur in te laten geven. Als ze echt van die achterlijke kortingsconstructies willen, dan zullen ze het helaas met handwerk moeten doen.

Een parser/interpreter/rulebased engine kan een optie zijn om dit soort "kennissysteem"-achtige issues op te lossen, maar ik denk dat het beter is de klant op een wat gestructureerdere manier te laten werken om zo processen efficienter te maken.

[PV85]

Mja interpreters zijn niet de makkelijkste dingen om te schrijven, er wat boeken over lezen voordat je er aan begin is geen slecht idee.
In principe zou je alles met een GUI kunnen doen, alleen wordt het bij ingewikkelde kortingsregels erg snel onoverzichtelijk.
Ik zou het altijd simpel houden, dat je het daardoor 5% van de gebruikers niet makkelijk maakt is dan jammer, het is altijd beter dan al je gebruikers opschepen met een interpreter achtige taal terwijl ze maar een paar simpele kortingsregels willen invoeren.

[ Voor 32% gewijzigd door PV85 op 07-07-2008 16:00 ]

[kenneth]

bigbeng schreef op maandag 07 juli 2008 @ 15:53:
Je wil iets ongestructureerds gaan structureren. Dat wordt lastig. Ik denk dat het een beter idee is om met de klant om de tafel te gaan en te zeggen: "<Insert wat Voutloos al zei>". Je kunt proberen ze in te laten zien dat dat niet gaat (voor een prijs die zij redelijk achten).

Bij alle honderd klanten?

Ik ben met je eens: automatiseren is organiseren. Maar de praktijk is helaas wat weerbarstiger.

beany, is WF geen optie dan?

[beany]

kenneth schreef op maandag 07 juli 2008 @ 16:00:
[...]
Bij alle honderd klanten?

Ik ben met je eens: automatiseren is organiseren. Maar de praktijk is helaas wat weerbarstiger.

beany, is WF geen optie dan?

Paar honderd klanten zelfs...

Een hoop wensen zullen wel generiek zijn(staffels bijvoorbeeld) maar er zijn een hoop rare wensen. Het pakket wordt een nieuwe versie, van de grond af aan opbouwen. De oude is een character-based applicatie. Dus de kennis(en de ervaring met de wensen) is ruim aanwezig. Daar uit is dus gebleken dat er echt een hoop rare dingen tussen zitten. En de klanten zijn er ook erg rechtlijnig in: 'dit is niet mogelijk? gaan we wel bij de concurrent shoppen'.

Workflow... ik moet daar eens in gaan duiken. Voornamelijk kijken of het mogelijk is dat de klanten zelf met workflow regels in elkaar kan gaan hangen. Geen idee of dit dan mogelijk is met workflow. Ik neem aan dat we daar dan een user interface voor moeten gaan maken?

[Hydra]

Ik zou zelf iets in de trant van de outlook rule assistant maken. Een wizard waarin je dus je eigen rules samen kunt stellen. Beter goed gejat

[chris]

Een parser / interpreter bouwen is wel érg leuk. Het lijkt misschien moeilijk, maar met een beetje oefenen valt het allemaal best mee. Misschien moet ik eens een nederlandstalige tutorial schrijven, dat zou wel leuk zijn denk ik. Is daar interesse voor?

[Face_-_LeSS]

chris schreef op maandag 07 juli 2008 @ 17:18:
... Misschien moet ik eens een nederlandstalige tutorial schrijven, dat zou wel leuk zijn denk ik. Is daar interesse voor?

Altijd

[PV85]

chris schreef op maandag 07 juli 2008 @ 17:18:
Een parser / interpreter bouwen is wel érg leuk. Het lijkt misschien moeilijk, maar met een beetje oefenen valt het allemaal best mee. Misschien moet ik eens een nederlandstalige tutorial schrijven, dat zou wel leuk zijn denk ik. Is daar interesse voor?

*meldt zich

[beany]

Een goeie tutorial is altijd welkom lijkt mij

[bomberboy]

Als ik het goed begrijp wil je eigenlijk een soort van Rule-engine gaan implementeren. Persoonlijk zou ik dit niet zelf doen maar een third party library gebruiken.

Zelf heb ik een 4-tal jaar geleden (toen nog als student) een project gemaakt waarbij de java-petstore werd uitgebreid met een rule-engine om gelijkaardige regeltjes te implementeren. Daarbij maakten we gebruik Jess: http://herzberg.ca.sandia.gov/ (uiteraard voor Java).

Het was daarbij dan mogelijk om heel complexe regels te definiëren. Combinaties van kortingen, kortingen enkel geldig voor bepaalde klanten enz. Ook andere regeltjes zoals je kon bv. geen kat en een hond tegelijk kopen want die zouden met elkaar vechten enz. Of je kreeg korting indien je 2 vogeltjes tegelijk kocht want die konden in één kooi, maar bij 3 dan weer niet, want dan waren er twee kooitjes nodig (bij 4 dan weer wel enz) En allerlei combinaties.

Ik vermoed dat er ook wel gelijkaardige producten zullen bestaan voor C#, maar heb er persoonlijk geen ervaring mee. Na even snel googlen kom je bv. hier terecht: http://csharp-source.net/open-source/rule-engines
Die Drools.Net die daar vermeld wordt bestaat ook in Java-smaak en daar heb ik toch al positieve dingen over gehoord. Uiteraard moet je zelf een evaluatie maken van wat jouw exacte noden zijn en hoe de beschikbare libraries die kunnen invullen (en of hun commerciële of open source licenties in jouw licentiemodel passen).

De taak die dan voor jou overblijft is het maken van een eenvoudig guitje waarin je eindgebruikers de regels makkelijk zelf kunnen ingeven en testen. Want meestal is de syntax van zo'n rule-engine iets minder intuïtief. En je wil uiteraard ook niet dat alles de soep indraait omdat er ergens een puntkomma vergeten wordt

[ Voor 0% gewijzigd door bomberboy op 07-07-2008 17:35 . Reden: typo ]

[beany]

Hmmm, wederom een kwestie dus van de juiste zoekwoordjes gebruiken in google...

Drools.Net ziet er erg interessant uit. Zal daar eens even mee gaan spelen.

In iedergeval zijn er wel opties dus: WF, Drools.Net en een eigen simpele interpreter/rules engine.

Drools.Net lijkt erg ok, maar een eigen rules engine heeft weer het voordeel dat als iets niet kan in Drools, je het er zelf bij kan bouwen zonder eerst 1000'en regels code van Drools te moeten doorploegen.

Lastig, keuze's

[Webgnome]

beany schreef op maandag 07 juli 2008 @ 18:43:
Hmmm, wederom een kwestie dus van de juiste zoekwoordjes gebruiken in google...

Drools.Net ziet er erg interessant uit. Zal daar eens even mee gaan spelen.

In iedergeval zijn er wel opties dus: WF, Drools.Net en een eigen simpele interpreter/rules engine.

Drools.Net lijkt erg ok, maar een eigen rules engine heeft weer het voordeel dat als iets niet kan in Drools, je het er zelf bij kan bouwen zonder eerst 1000'en regels code van Drools te moeten doorploegen.

Lastig, keuze's

Ik begrijp uit je verhaal dat je het op commerciele basis doet dus dan is de keuze niet zo heel erg lastig. Kijk wat het minste tijd kost (maar wel goed!) en ga daarvoor.

[Niemand_Anders]

Windows Workflow Foundation heeft een ingebouwde rule-engine. Verder wordt WF door veel bedrijven gebruikt en daardoor is er ook veel informatie over te vinden. De MSDN bevat zelfs enkele tutorials hoe je WF in C#/VB.net projecten kunt gebruiken.

Weliswaar is WF geen opensource, maar de broncode is door Microsoft wel beschikbaar gesteld. Daardoor kun je bij het debuggen ook door de code van Microsoft steppen.

Aangezien je aangaf dat je eventueel klanten zelf rules te laten maken is het handig om te weten dat je de workflow designers ook zelf kunt hosten. Ook exception management vind ik een sterk onderdeel van WF.

Mijn ervaring is dat de Microsoft oplossingen erg goed met elkaar werken en dat de MSDN zeer veel documentatie over WF bevat. Wat betreft de kosten, WF komt bij het .NET framework (3.x) en is dus eveneens kosteloos.

[Verwijderd]

Vreemd genoeg zie ik hier niks staan over DSL's (Domain Specific Languages),

beany:
Kijk eens naar het werk dat Oren Eini (Ayande) hierin gedaan heeft: http://www.ayende.com/
en dan vooral het project 'rhino-dsl'.
(SVN: https://rhino-tools.svn.s...ino-tools/trunk/rhino-dsl)

Hiermee kan je eenvoudig je eigen DSL engine schrijven.

dit maakt het volgende bijvoorbeeld mogelijk (stukje uit de Unit tests van het project):

OrderProcessRules.boo (tekst bestand):

code:

when User.IsPreferred and Order.TotalCost > 1000:
    AddDiscountPrecentage  5
    ApplyFreeShipping
when not User.IsPreferred and Order.TotalCost > 1000:
    SuggestUpgradeToPreferred 
    ApplyFreeShipping
when User.IsNotPreferred and Order.TotalCost > 500:
    ApplyFreeShipping

of:

code:

task "warn if website is alive":
    every 3.Minutes() 
    starting now
    when WebSite("http://example.org").IsAlive
    then:
        notify "[e-mail]", "server up!"

In plaats van een geheel eigen parser te schrijven, maak je een nieuwe klasse die erft van DslEngine. Je implementeerd de methodes die je nodig hebt, en je krijgt een complete DSL engine.

Ook van de hand van Oren is het boek 'Writing domain specific languages in Boo'

P.s.: Het is geen eenvoudige stof, maar zeker niet zo moeilijk als het schrijven van je eigen AST / parser.

[ Voor 22% gewijzigd door Verwijderd op 08-07-2008 10:04 ]

[D-Raven]

Ik sluit me aan bij Niemand_Anders. Ga eens naar Windows Workflow Foundation kijken.
Het is eenvoudiger dan het schrijven van een eigen parser, of het modelleren van je eigen DSL met boo.
Tuurlijk, je hebt meer flexibiliteit als je een eigen DSL in boo schrijft. Maar dan heb je nog de faciliteiten eromheen niet.
Daarnaast tot op heden ben ik nog niet tegen functionele beperkingen in de rules engine van WF aangelopen. Dus ik vermoed dat het schrijven van een eigen DSL ten opzichte van het gebruik van WF op het gebied van flexibiliteit geen meerwaarde zal brengen.

[P_de_B]

Heb je budget voor een externe rule engine? Zoiets: http://www.ilog.com/products/rulesnet/studio.cfm bijvoorbeeld?

[ Voor 26% gewijzigd door P_de_B op 08-07-2008 16:24 ]