The answer is more than just a script, but includes the layout because you have to have the value list and a script trigger for modifying the percentage field. If you'll give me your email, I'll send you a file with all of this in it or you can email me at Taylor@TaylorMadeServices.com.
Thank you, Taylor.
Well it seems that our decision makers have changed their minds on how our price increase is going to work. Now there will be a 4% price increase across the board.
So as a test, I made a field called price increase (in red) as a calculation which will take the existing price, multiply by 4% and deliver a total. Price increase= price * .04 + price
The issue I’m having is with new products and their prices.
a calculation which will take the existing price, multiply by 4% and deliver a total. P
What will you do at the next price increase?
Yes, it is just not working and more complicated than I thought.
I have a headache. LOL.
Do you need to keep track of previous prices? If not, show all records and just loop through and SetFIeld [ Price ] = 1.04 * Price.
That's exactly the question to ask here: do you want each product to have a history of its prices? If yes, you will need to add a table for them.
Or perhaps you want to keep only the last price before the current one?
Message was edited by: Michael Horak
My manager tells me that we only need the one previous price. So, I used my original 'Price increase= price * .04 + price' calculation then changed the field back to a number/currency field. That seems to work and keeps the previous price intact.
What do you think, am I safe?
You are safe for now. For the future, price changes are a fairly frequent affair and should be in the user domain, without requiring the intervention of the developer (IMHO, there should also be a DateOfEffect field, at least for the current price). All this can be scripted, though it would require some work - esp. if you want to give users the option to raise prices across the board as well as individually.
What I have done for customers is created a related table that has the price changes sorted decending by date so that the relationship always shows the latest price change in a one to many relationship. That works pretty well and keeps a history.