Complex Adobe Acrobat calculation

Question

I have a complex pricing form that I created in Excel to use for all my quoting, however quoting is becoming more and more time consuming and I wanted to create a PDF version that people can tweak options to fit their budget.

I've tried to figure out Javascript but the formatting is alien and I can't find anybody who has created a similar calculation, is anybody able to help ?

There will be multiple 'sections' where the totals of each section will be calculated into a grand total, but each 'section' is basically the same.
But the trick is that I would like each 'section' to have a base cost that only shows after a valid quantity is entered (eg. 25+).
Each radio button 'choice' has to have a unique value also, eg . SizeChoice1=1, SizeChoice2=2, SizeChoice3=3.
So a summary of the content (excel style) is:

if QTY >25 (250+(SizeChoice(1,2or3)*QTY)+(ColourChoice(1,2or3)*QTY)+StockChoice(1,2or3)*QTY), if QTY<25 = 0

And also preferably a total that is rounded up, if possible.

Answer 1

Are the choices mutually exclusive? Probably not. But if so, you would use checkboxes instead of radio buttons, give the ones which belong together the same name, but a different return value. And they behave like radio buttons.

It is a very good idea to not want to simply translate an Excel formula into (Acrobat) JavaScript, because the concepts behind Excel formulas and Acrobat JavaScript are too far away, and it is only the question when you horrendously fall on your nose (I know what I am talking about; I have been burnt too many times when I was in a good mood and agreed to turn the client's Excel spreadsheet into a PDF form.

What you would do instead is do a quick analysis of the form, and what it should do. And then, you can build up the form following that logic. Keep in mind that (Acrobat) JavaScript allows to create loops (ideal when you have functional blocks, and use a counter in their field names), or functions (which you can call wherever you need, passing arguments). Also keep in mind the field event sequence, which has the great side effect that you can consolidate all the logic into one single field, which is not even part of the fields being involved in the calculation.

In your case, the calculation does depend a lot on the choice of the field names. Do it well, your code is short and elegant, do it not so well, your code will be a mess.

Now, for your example, there is not sufficient information on what it should do. So, it might be a good idea to add the findings of your quick analysis to the question.

I think I know what you want to do, and in this case, the whole thing gets pretty simple.