Prijsbepaling dmv toepassen vermenigvuldigingsfactor op Prijs Referentie Artikel

[Richard Masseling]

Hallo Pascal,

ik heb je een mail gestuurd.

[pascal]

Dank, ik ga ernaar kijken.

[Peter Stordiau]

Volgens mij wordt dit een moeizaam verhaal (temidden van wat al redelijk chaos lijkt te zijn). Daarom nu sowieso : op basis van nacalculatie (en de eerste paar uren zitten er al in).

Het loslaten van een faktor, letterlijk op de eigenlijk door het systeem bepaalde prijs (zeg zoals het momenteel gebeurt langs welke en hoeveelwegen ook), kan op zich wel worden gemaakt, mits de aanname mag zijn dat het eerdere maaterk in deze (van dit topic, zeg maar) gewoon blijft bestaan. Dus, het lijkt me dat jullie de reeds her en der ingevulde faktoren dan moeten weghalen. Je mag ze ook laten staan, maar dan wegen ze ook wel mee in de eindprijs, welke eindprijs als laatste dus nog eens wordt vermenigvuldigd met de nieuwe faktor, noem 'm Eindprijs Faktor.

Dit is op zich zo spannend niet, ware het niet dat wij er niet goed meer uitkomen waar die Eindprijs Faktor moet als veld moet worden geregistreerd, en hoe een refererend artikel dat (met name) waarvandaan doet. Ook en vooral : de bestaande methode begrijpen wij al niet meer, omdat ook daar is gemaakt wat jullie wilden, zeg maar buiten onze logica (lees : u vraagt, wij draaien, maar daardoor snappen we er geen bal van). ... En dan werkt het kennelijk ook nog eens niet, of, dus niet.
Van de (eer ?) vorige keer kan ik mij nog herinneren dat
a. jullie eigenlijk niet meer weten hoe je met de Prijsregistratie moet omgaan (Pascal, dat heb je ook toegegeven destijds);
b. je weet zelf ook nauwelijks meer waar je wat hoe waarom hebt geregistreerd.
Anvullend :
c. er is dan ook nog steeds een mechanisme aktief dat alles dubbel berekent (heb ik nog iets voor in de database moeten "browsen" wat dat juist veroorzaakte, en eigenlijk klopt er geen bal van. Of je daar iets van merkt weet ik niet.

De moraal is helaas dat dit nu nog meer "u vraagt wij draaien" wordt, domweg omdat we het niet kunnen volgen. Dit zit 'm dus met name in waar wat wordt geregistreerd, denkend aan Artikelniveau, Artikel/Verschijning / Kenmerken (gebruik je niet meer, meen ik) en hoe een ander Artikel met andere Verschijningsvorm - stel 100st voor het gemak -refereert aan een Verschijningsvorm met 75 stuks. Let wel, de methode voor het maatwerk van dit topic, werkt dus zo.

Moraal : zeg ons maar wat we moeten doen, en we doen het. En dat is niets iets simpels als "graag een faktor van het ene Artikel naar het andere". In detail uitwerken.
En laat ik nou denken dat je dat niet lukt.

Je wilt iets wat simpel is, maar niet kan worden gemaakt. Daar lijkt het op ...

[pascal]

Prijsstructuren en opbouw is bij ons inderdaad in de jaren uitgegroeid tot een complex geheel.
Reden voor deze aanpassing is om dit systeem gestructureerder en minder complex te maken. Veel prijzen die in Excel berekend worden en ingeschoten worden willen we in Profit laten opbouwen (dus met meerprijzen en ook deze vermenigvuldigingsfactor).
Zijn we al mee bezig, een deel van de prijzen die in eerdere jaren zijn ingeschoten worden nu opgebouwd via basisprijzen/meerprijzen in Profit.

Met deze vermenigvuldigingsfactor willen we een deel van de prijzen die we nu niet of heel lastig in Profit kunnen opbouwen - en dientengevolge dus nog via Excel ingeschoten worden - nu wel door Profit laten bepalen.
Dit geeft meer inzicht in de opbouw en scheelt veel handwerk.

We gaan uitwerken hoe de prijsopbouw nu bij ons werkt voor de verschillende artikelgroepen/varianten en hoe we de vermenigvuldigingsfactor daarin willen gebruiken.

[Peter Stordiau]

We gaan uitwerken hoe de prijsopbouw nu bij ons werkt voor de verschillende artikelgroepen/varianten

Dit mag uiteraard, maar hoef je voor ons niet te doen hoor.

Je wilt een Faktor op de Eindprijs. Zeg maar (Entiteit)  waar dit veldje moet komen (met die Faktor) en naar wat (ook een Entiteit) dit moet refereren.

Voorbeeld van Entiteiten :
Artikel
Vrschijninsgvorm
Artikel/Verschijning
Kenmerk-Domein
Prijsopslag Debiteur
Kortingsstaffel

[pascal]

De prijs van artikelen definieren we onder menu 3-4-1 Standaar Prijs/Kortingsafspraken (1e afbeelding).
Opties 3-4-2 t/m 3-4-5 doen we niks mee.

Onder 3-4-1 gebruiken we vervolgens alleen optie 1: Raadplegen/Onderhoud Standaard Prijs/Kortingsafspraken (2e afbeelding).
Opties 3-4-1-2 t/m 3-4-1-5 gebruiken we dus ook niet.

We gebruiken de prijsafspraken op Klient-identiteit, Prijslijst-identiteit en Artikelgroep-identiteit.

Een artikelprijs kan opgebouwd worden uit 1 of meerdere van deze prijs/kortingsafspraken en daarbij evt prijs op basis van referentie-artikel, tabblad 7 van de artikelgegevens (3e afbeelding).

[Peter Stordiau]

OK. Mooi gedaan !
N.b.: Dit is niet erg van belang omdat je immers stelt/wilt dat de faktor op de Eindprijs moet worden losgelaten. Hoe die eindprijs tot stand komt mag ik niet over gaan. Voor jezelf is het wel belangrijk. Dus goed dat jullie het hebben uitgewerkt.

Zolang je maar nergens iets met Prijzen en Verschijningsvormen (Artikel/Verschijningen) of Kenmerken gaat doen, lijkt het mij dat het wel goed komt met die Faktor. Het lijkt mij dat je op het zelfde Tabblad 7 onder de reeds bestaande regel met de Referentie en verdere velden, net zo'n regel wil hebben, maar nu eentje die werkt op de Eindprijs (de bestaande werkt op de Basisprijs). De bestaade gaat dan Basisprijs Referentie [...] heten en de nieuwe "Eindprijs Referentie [...].

Het enige wat we verder aanpassen is
a. De door het systeem initieel berekende Eindprijs opslaan;
b. De Eindprijs vermenigvuldigen met de faktor en de nieuwe prijs terugschrijven in het Prijsveld;
c. Ervoor zorgen dat e.e.a. wijzigbaar is;
d. Daarvoor ook weergeven wat de Eindprijs oorspronkelijk was, en wat de Prijs na verwerking met de Faktor;
e. Het bieden van de mogelijkheid om de Prijs handmatig aan te passen, inklusief "Opnieuw Eindprijs Faktor toepassen J/N ?" (je kan relatief aan de via de Faktor berekende Prijs, de Prijs handmatig willen aanpassen);
f. De Bepaling Verkoopprijs (Verkooporderregel-Menu L) aanpassen.
g. ?

Ad c.:
Hoe precies moeten we uitwerken, maar het meest simpele voorbeeld betreft het wijzigen van de Verkooporderregel en het willen Wijzigen van de Prijs omdat je nu eenmaal ook een Prijs handmatig wilt kunnen wijzigen.
Heart Intern : Het bijhouden van de initiële Eindprijs kan gebeuren in VRGLPRYS; deze wordt al gebruikt voor gelijksoortige zaken met Koersen. Is de Bedrijfsparameter A - "Valutakode in Externe Administratie" ingevuld, dan mag de EindPrijs Faktor niet worden toegepast (vdBosch gebruikt dit uiteraard niet).

Benodigde tijd om dit te realiseren naar verwachting : tussen de 12 en de 20 uur. Maar het zou meer kunnen worden, vooral afhankelijk van of jullie zelf uiteindelijk e.e.a. toch iets anders willen.

[pascal]

Dank voor het denkwerk - ik denk dat we hier al een heel eind mee komen!
Ik ga dit aanstaande woensdag met Verkoop bespreken en kom er dan zsm op terug.

[pascal]

We hebben de aanpassing besproken, onze opmerkingen en vragen staan hieronder:

Het lijkt mij dat je op het zelfde Tabblad 7 onder de reeds bestaande regel met de Referentie en verdere velden, net zo'n regel wil hebben, maar nu eentje die werkt op de Eindprijs (de bestaande werkt op de Basisprijs). De bestaade gaat dan Basisprijs Referentie [...] heten en de nieuwe "Eindprijs Referentie [...].

Lijkt me een goed idee.
Heeft deze nieuwe regel dan ook dezelfde funktionaliteit zodat je ook kunt "/Afronden op"?
Wel belangrijk, want we ronden soms af op 1.000 (hele euro's) en soms op 0.050 ('stuivers').
We ronden trouwens zelf altijd naar boven af!

Het enige wat we verder aanpassen is
a. De door het systeem initieel berekende Eindprijs opslaan;
b. De Eindprijs vermenigvuldigen met de faktor en de nieuwe prijs terugschrijven in het Prijsveld;

Per prijslijst en per klant kan er een andere prijsafpraak gelden voor hetzelfde artikel of artikelgroep.
Hoe ziet dat er dan uit – worden alle mogelijke prijzen voor het artikel opgeslagen?
Bv prijs van een artikel voor klant waar prijslijst AP3 is gevuld is anders dan voor klant met prijslijst AP1.
En een klant kan bv ook prijsafspraken op klient-identiteit hebben.
Of een combinatie van basisprijs specifiek voor de klant en een algemene meerprijs (praktijkvoorbeelden hiervan kan ik evt mailen).

Zie ook post van mij hierboven:
We gebruiken de prijsafspraken op Klient-identiteit, Prijslijst-identiteit en Artikelgroep-identiteit.
Een artikelprijs kan opgebouwd worden uit 1 of meerdere van deze prijs/kortingsafspraken en daarbij evt prijs op basis van referentie-artikel, tabblad 7 van de artikelgegevens (3e afbeelding).

c. Ervoor zorgen dat e.e.a. wijzigbaar is;
d. Daarvoor ook weergeven wat de Eindprijs oorspronkelijk was, en wat de Prijs na verwerking met de Faktor;

Als ik het goed begrijp wordt de Eindprijs voor toepassen Faktor, en Eindprijs na toepassen Faktor weergegeven? Dit is inderdaad handig voor de traceerbaarheid van de prijs.
Maar hoe werkt dit in geval van meerdere mogelijke eindprijzen per artikel, zie opmerking punt b?

e. Het bieden van de mogelijkheid om de Prijs handmatig aan te passen, inklusief "Opnieuw Eindprijs Faktor toepassen J/N ?" (je kan relatief aan de via de Faktor berekende Prijs, de Prijs handmatig willen aanpassen);
f. De Bepaling Verkoopprijs (Verkooporderregel-Menu L) aanpassen.
g. ?

Wanneer we een Prijs/Kortingsafspraak wijzigen moet deze wijziging doorgevoerd worden in de opgeslagen Eindprijzen.
Gaat dit automatisch of moet er iets voor gemaakt worden zoals een 'massaal herberekenen Eindprijzen artikelen'?
Volgens mij doen jullie ook zoiets met de kostprijzen van artikelen en bestaat er ook een funktie om deze massaal te herberekenen (menu 1-5-1)?

Voor de rest een duidelijk verhaal - ik hoop dat mijn verhaal ook duidelijk is
Zoniet dan hoor ik het graag. Mocht je praktijkvoorbeelden nodig hebben dan kan ik die mailen.

[Peter Stordiau]

Pascal, help het als ik je (expliciet) verder dat de opgeslagen Eindprijs de Prijs van de Verkooporderregel betreft ?
Volgens mij zie jij een opgeslagen prijs elders voor je ?

Met dit in het achterhoofd, nogmaals dit toch cruciale :
Het maakt mij totaal niet uit hoe de Prijs op de Verkooporderregel tot stand is gekomen ... ik doe niets anders dan de Faktor erop loslaten. of er nou 100, 2.000 of 10.000.724,65 in staat. Als de Faktor 1,1 is dan wordt de prijs die je vandaag nog zou zien, straks met 1,1 vermenigvuldigd. 0,9 (kleiner dan 1) mag ook.

Heeft deze nieuwe regel dan ook dezelfde funktionaliteit zodat je ook kunt "/Afronden op"?

Ja, wordt 100% het zelfde. Maar wat is ingevuld mag uiteraard anders zijn.

Als ik het goed begrijp wordt de Eindprijs voor toepassen Faktor, en Eindprijs na toepassen Faktor weergegeven?

Ja. Maar waar jij hetj handig vindt voor de traceerbaarheid, zou het mij gaan om het inzicht in hoe je e.e.a. zou willen wijzigen. Je kan dus de oorspronkelijke Eindprijs (virtueel) wijzigen en de Faktor er wederom op loslaten, of je wijzigt de berekende Eindprijs en zegt dat je de Faktor er *niet* meer op moet loslaten. In beide gevallen wijzig je in het zelfde Prijsveld (zoals altijd al), maar je kan dus kiezen hoe je het doet.
Het systeem mag nooit de eigenlijk (oorsponkelijk) berekende Eindprijs weggeooien, want dan kan je nooit meer terug naar de basis. Beetje lastig uitleggen, maar vertrouw er op dat het nuttig is en ook dat het goed komt.

Maar hoe werkt dit in geval van meerdere mogelijke eindprijzen per artikel, zie opmerking punt b?

Is dus "niet van toepassing".

Wanneer we een Prijs/Kortingsafspraak wijzigen moet deze wijziging doorgevoerd worden in de opgeslagen Eindprijzen.

Eveneens dus "niet van toepassing". Als je maar niet wilt dat de opgelapgen Prijzen bij de Verkooporderregel met e.o.a. berekening kunnen worden aangepast. Dat wil je ook niet (en e.e.a. bewijst dat je nog niet begreep dat het de Prijzen in de Verkoopordergegel zijn die worden opgeslgen inde Verkooporderregel.

Zo maar even ...

[pascal]

Pascal, help het als ik je (expliciet) verder dat de opgeslagen Eindprijs de Prijs van de Verkooporderregel betreft ?
Volgens mij zie jij een opgeslagen prijs elders voor je ?

Dit helpt zeker! Ik zat automatisch te denken aan een prijs opgeslagen bij het artikel om 1 of ander reden, wat ingewikkeld klinkt.
Bij verkooporderregel klinkt inderdaad logisch, wordt de rest ook een stuk duidelijker!

Ik ga het bespreken met Verkoop, kom er zsm op terug

[pascal]

Nog even besproken met Verkoop. Wanneer ik het goed begrijp:

Pascal, help het als ik je (expliciet) verder dat de opgeslagen Eindprijs de Prijs van de Verkooporderregel betreft ?

Dit geldt ook voor offerteregels en kontraktregels neem ik aan?

En wanneer je een verkooporder uit kontrakt genereert, neemt hij de prijs uit het kontrakt mee? Stel je hebt handmatig de prijs van een artikel aangepast voor klant X, dan moet de verkooporderregel deze prijs overnemen. Dan moet hij dus niet de eindprijs opnieuw berekenen en niet opnieuw gaan berekenen.

Als je maar niet wilt dat de opgelapgen Prijzen bij de Verkooporderregel met e.o.a. berekening kunnen worden aangepast. Dat wil je ook niet (en e.e.a. bewijst dat je nog niet begreep dat het de Prijzen in de Verkoopordergegel zijn die worden opgeslgen inde Verkooporderregel.

Dit klopt helemaal.

En mbt mijn opmerking:

Wanneer we een Prijs/Kortingsafspraak wijzigen moet deze wijziging doorgevoerd worden in de opgeslagen Eindprijzen.
Gaat dit automatisch of moet er iets voor gemaakt worden zoals een 'massaal herberekenen Eindprijzen artikelen'?
Volgens mij doen jullie ook zoiets met de kostprijzen van artikelen en bestaat er ook een funktie om deze massaal te herberekenen (menu 1-5-1)?

Dit hoeft dus niet gemaakt te worden. Zoals je terecht opmerkt "niet van toepassing".

[Peter Stordiau]

Pascal, help het als ik je (expliciet) verder dat de opgeslagen Eindprijs de Prijs van de Verkooporderregel betreft ?

Dit geldt ook voor offerteregels en kontraktregels neem ik aan?

Da's een goeie. ... Het heeft even wat uitzoekwerk gevergd, maar, ja, daar kan het ook. N.b.: Bij de Kontraktregels moet je wel "Prijs berekenen" aanzetten, maar dat wist je zelf denk ik eerder dan wij.

Uiteraard zit er wat additionele complexiteit in voor ons aangaande het niet dubbel mogen hanteren van de faktor. Dus bijvoorbeeld, als je vanuit de Offerte komt alwaar een de prijs op welke wijze ook tot stand is gekomen, zal deze prijs 1 op 1 worden overgenomen in de Verkooporderregel. Dus daar zal nooit ineens nog de Faktor erop worden losgelaten (of deze nou is toegepast in de Offerteregel of niet). Ditto geldt voor het Kontrakt.

Zoiets dus ... dit gaat wel werken ...

[pascal]

Top, hou ons op de hoogte!

[Peter Stordiau]

Ah, OK, dus hij kan !
Nou, super !