Heart-Profit ERP

Vorig jaar is het voor ons mogelijk gemaakt een artikelprijs te bepalen mbv Prijs Referentie Artikel, zie:
http://ha1.heartprofit.nl/profit/index.php?topic=28434.0

Dus veld Prijs Referentie Artikel wordt gevuld en mbv artikelgroepen kunnen we opslagen toevoegen (bv meerprijs steen in Eccoton Milieukeur ten opzichte van een gewone steen). Dit werkt goed.
Zie voorbeeld prijsbepaling SHSGRIJM in schermafdrukken - prijs op basis van Prijs Referentie Artikel SHSGRIJK met een meerprijs via artikelgroep ME1.

Er zijn echter heel veel artikelen die we niet mbv een meerprijs kunnen bepalen door er een bedrag bij op te tellen, maar waarop een vermenigvuldigingsfaktor toegepast moet worden.
Die prijzen berekenen we nu nog zelf en schieten we vervolgens in. Dit is echter veel werk.

Het zou mooi zijn wanneer we een vermenigvuldigingsfaktor toe kunnen passen op een Prijs Referentie Artikel.
Om een idee  te geven, het gaat bv om:
Dubbelklinker (DK) kost 2,3 keer zoveel als de Klinker (BKK)
Anderhalf-dubbelklinker (ADK) kost 3,4 keer zoveel als de BKK
Dubbel-dubbelklinker (DDK) kost 4,5 keer zoveel als de BKK
Bisschopsmuts (BM) kost 2,75 keer zoveel als de BKK

Voorbeeld:
BKK8ROODK normale rode klinker kost (fictief) 250,- per SD (stuks duizend)
DK8ROODK = BKK8ROODK x 2,3 = 250,- x 2,3 = 575,- per SD
ADK8ROODK = 250,- x 3,4 = 805,- per SD
DDK8ROODK = 250,- x 4,5 = 1125,- per SD
BM8ROODK = 250,- x 2,75 = 688,- per SD (687,50 afgerond op hele euro's).

Lastig puntje misschien: prijzen per SD (duizend) ronden we af op hele euro's.
Bij prijzen in ST/M2 ea eenheden ronden we af op 'stuivers' (0,05).
Nu passen we de vermenigvuldigingsfaktor alleen maar toe op artikelen die per duizend verkocht worden, maar het zou natuurlijk kunnen dat we dit ooit in de toekomst wel willen. Of dat een andere klant die dit gaat gebruiken dit wil. Weet niet of hier rekening mee gehouden kan/moet worden, of dat de wijze van afronding instelbaar gemaakt moet worden?

Dus als we hiernaast een "Faktor : " opnemen met als default 1.00 en we passen die toe op de gevonden prijs in het Referentie Artikel - en we behandelen onder water de omrekeningen (van bijvoorbeeld SD naar SH - noem je niet echt, maar moet wel) ...

2 uur.

Om de afrondingen juist te laten verlopen ... inderdaad, lijkt lastiger. Ik doe even 1,5 uur onder het voorbehoud dat we niet ergens "definities" moeten aanleggen van waar hoe af te ronden. Dus dit moet meer automatisch. Voorbeeldje : als de gevonden Referentieprijs op hele euros is, ronden we af op hele euros. Is het op centen (als het goed is op 0,05) dan op 0,05. Is het op centen bedoeld maar is de prijs toevallig op hele euros ... pech gehad.

Hmm ... Kunnen we niet gewoon een extra veldje erbij maken met "Afronden op : " ? ... lijkt mij wel te werken.
Kan wel voor die zelfde 1,5 uur.

Lijkt me een goed plan, maar dan wel met de optie:


Dit lijkt me de beste en meest flexibele optie.

3,5 uur is bij deze akkkoord.
:13c:

Helaas zie ik dat deze aanpassing nog niet gereed is. We willen deze aanpassing gebruiken voor de nieuwe prijslijsten van volgend jaar. Is er zicht op of dit binnenkort klaar is?

Nee. :smile:
Help nog maar een keer herinneren als het echt penibel wordt. Als dat nu al is, wacht dan nog een week. Enz.
Haha.

In september was het nog niet penibel.. nu wordt het al wat penibeler (een maand is zo om)

Hallo Pascal,

e.e.a. is afgerond zie http://ha1.heartprofit.nl/profit/index.php?topic=29743.0;topicseen, hiervoor heb je wel een Upgrade nodig.

gr,
Richard

Top, dank voor de service!
Ik zal overleggen wanneer de upgrade aangevraagd kan worden.

Inmiddels heb ik de upgrade in de Test-omgeving gezet en kan ik deze aanpassing testen.

Wanneer het artikel waar een vermenigvuldigingsfaktor overheen moet 1 ingeschoten prijs heeft gaat dit goed.
Bv. DK8ZWKVK = BKK8ZWKVK * 2,3 afgerond op hele euro's.
Prijs BKK8ZWKVK = 261,- (prijs haalt hij van prijslijst AP3).
Prijs DK8ZWKVK = 600,- dit is goed. Want 261,- * 2,3 = 600,30 euro, afgerond op hele euro's is dit 600 euro.

Het lijkt niet goed te gaan bij DK8ROODK.
Hier referentie-artikel BKK8ROODK. deze heeft 2 groepen:
KB8 Basisprijs
MB1 Meerprijs kleurnummer 1001, 1003.

KB8 prijs/kortingsafspraak voor KB8 en prijslijst AP3 is 188,- /SD
MB1 prijs/kortingsafspraak voor MB1 is 17,- /SD (is onafhankelijk van prijslijst)
Totaalprijs BKK8ROODK is dus 188+17=205,-

Hier ook de faktor 2,3 ingevuld, zie onderstaande schermafdruk.
daaronder de prijsopbouw van artikel BKK8ROODK en vervolgens van DK8ROODK.
ik verwacht een prijs van 205,- * 2,3 = 471,50 > afronding op hele euro's wordt 472,-
Profit komt met een prijs van 431,2941

Kunnen jullie eens kijken wat er misgaat, of wat ik wellicht fout doe?

Ik vermoed eigenlijk dat niemand heeft gezegd dat die factor zo maar op *alle* prijzen moet worden losgelaten. Dat zou wat mij betreft nooit (mogen) werken ...

Ik snap denk ik wel wat je bedoelt, functioneel gezien. Dus zoek prijs en indien gevonden pas factor toe.
Maar wij als klant willen logischerwijs dat de totaalprijs van het artikel vermenigvuldigt wordt.


Ik interpreteer de 'gevonden prijs' als zijnde de prijs van het artikel (incl alle opslagen)
Zo werkt het nu nl ook.
Wanneer ik nl als referentieartikel BKK8ROODK invul bij de DK8ROODK en ik voeg een meerprijs toe dan pakt hij ook de 205,- (dus totaalprijs) en niet alleen de 188,- (zie laatste plaatje onderaan).

Is deze systematiek v/d totaalprijs ook toe te passen op die vermenigvuldiging?
Ik ben geen programmeur, maar hoop dat je snapt wat ik bedoel?

Kan dit probleem opgelost worden? Aangegeven manier is wel zoals we hier werken. Uitleg in de startpost is op zich ook uitgebreid en duidelijk vind ik.

Klein schopje - is dit wellicht toch mogelijk te maken? Zou voor ons zeker werk en kans op fouten besparen.

Hallo Pascal,


wat gaat er volgens jou niet goed aan http://ha1.heartprofit.nl/profit/index.php?topic=28434.0 gevolgd door http://ha1.heartprofit.nl/profit/index.php?topic=29743.0;topicseen

De Vemenigvuldigingsfaktor moet dus worden toegepast op de gevonden "Basisprijs" en niet op "alle prijzen" zoals jij stelt met

Richard, ik snap de uitleg waarom het alleen op de basisprijs werkt.
Maar ik wil graag weten of er een aanpassing gemaakt kan worden die de vermenigvuldigingsfaktor op "alle prijzen" toepast.
Zoja, dan hoor ik graag hoeveel uur zou dit kosten.

Hallo Pascal,

ik heb je een mail gestuurd.

Dank, ik ga ernaar kijken.

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). :smile:

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 ...

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.

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

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).

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.

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.

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

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!


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).


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?

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 :wink:
Zoniet dan hoor ik het graag. Mocht je praktijkvoorbeelden nodig hebben dan kan ik die mailen.

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.


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


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.


Is dus "niet van toepassing".


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 ... :smile:

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 :smile:

Nog even besproken met Verkoop. Wanneer ik het goed begrijp:
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.

Dit klopt helemaal.

En mbt mijn opmerking:
Dit hoeft dus niet gemaakt te worden. Zoals je terecht opmerkt "niet van toepassing".

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 ...

Top, hou ons op de hoogte!

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

Sorry wat kort door de bocht, maar hij kan inderdaad :smile:
Je uitleg over prijzen offerte-regels en kontrakt-regels doorgenomen met Verkoop, dat wordt netjes geregeld.
Dus akkoord bij deze.

We hebben de vermenigvuldigingsfactor getest en deze doet het zoals afgesproken. Dat is super.

Zoveel mogelijk artikelen getest en laten berekenen, gaat allemaal goed.
Maar nu ontdekken we toch een aantal exotische artikelen die naast de vermenigvuldigingsfactor nog een extra opslag moeten krijgen. Dit zijn bv DDK-artikelen in halfsteens machinaal pakket.

De DKK moet in dit geval 4,5x zo duur worden als de BKK, maar vereist nog een meerprijs voor het machinale pakket.
Dit kan via een meerprijs-groep MKU Meerprijs machinaal DDK halfsteens.
Deze prijs wordt gevuld bij 3-4-1-1 Raadplegen Prijs/Kortingsafspraken, "Artikelgroep-ident"

Zou het dus mogelijk zijn dat artikelen waar vermenigvuldigingsfactor wordt toegepast, ook de artikelgroep(en) met prijs/kortingsafspraak (zoals deze MKU) meeneemt?
Dus in dit geval prijs DDK halfsteens machinaal = 4,5x  prijs BKK + prijsafspraak artikelgroep MKU?

Tweede puntje: we kunnen de Eindprijs Faktor afronden (op bv hele euro's).
Kan dit ook altijd naar boven afgerond worden? Dus 1200,4 euro > wordt 1201 euro? Wellicht via parameter?

Bij voorbaat dank!

Pascal,

ik heb je een mail gestuurd.

Richard, laatste aanpassing getest en dat gaat goed.
Kun je nog kijken naar onderstaande?

Bij het testen kom ik erachter dat funktie 3-4-7-6-8 erg langzaam is in Test.
Deze gebruik ik regelmatig (en dan voor duizenden artikelen).
Zie schermafdruk: testje met een tiental artikelen duurt in Test erg lang, in Produktie gewoon snel.

En wat nog open stond:

Bij voorbaat dank!

Hallo Pascal,

Printen Verkoopprijzen Debiteur is aangepast en staat inmiddels bij je op het systeem in de Test-omgeving.

Ik heb het getest, printen verkoopprijzen loopt nu weer snel, top!

(staat er nog maar 1 puntje open mbt de afronding  :wink:)

Wij vragen ons af wat je hier bedoelt ...
1. De Eindprijs naar boven afronden waarna je nog een keer de Opslagen erop loslaat, of
2. Nadat alles is berekend de prijs nog een keer naar boven afronden.

Mijn persoonlijke opmerkingen :
- Met alle opslagen en toestanden die er al eeuwig in zitten wilde je dit ook niet;
- Iedereen gebruikt dit soort zaken maar niemand heeft ooit zoiets gewild;
- Je gaat een prijs van 1200.4 (dat is meer dan twaalf-honderd euro op 1 euro naar boven afronden ??

Ik wil wel weten welke mieghummel (zie laatste punt) dit verzint, dan kan ik 'm even bellen. Ik meen het.
Hij of zij mag mij ook bellen, want we doen het domweg niet. :gotit: ... Of ik begrijp iets niet, dat kan ook. :smile:

Even een stukje uitleg: we gebruiken van oudsher een excel-bestand voor de prijsbepaling van bepaalde artikelen, oa artikelen waar een vermenigvuldigingsfactor toegepast wordt (maar na doorvoeren van deze nieuwe aanpassing via Profit berekend kan worden).
In dit Excel-bestand is de formule voor de prijsbepaling zo dat sommige van deze artikelen automatisch afgerond worden naar boven; dit is al heel lang zo en nooit veranderd.

Wanneer we nu deze prijs via Profit laten berekenen ipv Excel kun je dus een prijsverschil krijgen.
Hierdoor komen de prijzen uit Excel (en afgesproken met klant) niet meer overeen met Profit - dat is ook de reden het aan te kaarten.
Vraag is (zoals je terecht opmerkt) hoe erg dat kleine verschil is - hoogstens een miniem voordeel voor de klant, maar die zal daar niet over gaan klagen :wink:
Wel aanpassen heeft ook nog als nadeel dat je de berekening ingewikkelder maakt dan hij nu is, wat weer iets meer moeite kost qua beheer en ook weer meer kans op fouten.

Dit overdenkend is het laten vervallen van de afronding naar boven (en accepteren van enkele kleine verschillen) dus de beste oplossing  :smile: