# Thread: The logic of it all

1. ## The logic of it all

Hi Phorum,

I have a logic problem that I can't seem to derive a solution. The long and short of it is a combination of converting an APP that I wrote for the client from A4 to A5V4 8 years ago as well as the client changing his method of charging his customer for the work he has performed.

Here is the problem: There are 10 distinct variables to be defined, was the work performed on a holiday, a Sunday, a Saturday, before 8:00AM, or after 5:00PM. It gets stickier, some clients he merely adds a predefined value in each case, others he uses a multiplier. In any event it is possible for more than either one of the above to be true, if that is the case, he wants the highest value used. For further complication he uses different values in the adds/mults for each of his customers. These values are stored in his customers profile table and populated in the jobenter form via a lookup table.

To date I have considered and applied for/next loops, select/case statements and arrays. In general I set all of the multipliers to "1" and all of the addons to "0".

The 5 multipliers are: holmult, sunmult, satmult, b4mult and aftr_mult.

At this point in time I use a select/case to determine which addon and which multiplier is the largest value in the respective group, this means that I have 2 expression modifiers. I think I am answering my question as I am typing . Now I need to set the addon value to "0" when the multiplier is prevalent and the multiplier to 1 when the addon is prevalent.

Thank you all for any insight,
efs

2. ## RE: The logic of it all

Hi Phorum,

I thought this attached script would solve the problem; however, I get an error message that arguement (holadd) is incorrect data type. I wonder now, should I have put the refreshes immediately after establishing their value instead of putting them all at the end.

efs

3. ## RE: The logic of it all

Ed,

I find I have the best luck with these kinds of things if I break the code up into small pieces, each of which is understandable. The solution is tediously developed because the number of permutations are large. (Especially if some of the hours to be billed occur in premium intervals and some do not.)

If it were me, I'd arrange my script so that

1) the interval worked is analyzed and broken down, hour by hour into various categories:

saturday hours
sunday hours
holiday hours
holiday + saturday hours
holiday + sunday hours
before 8 hours
before 8 + holiday hours
before 8 + holiday + saturday hours
before 8 + holiday + sunday hours
after 5 hours
after 5 + holiday hours
after 5 + holiday + saturday hours
after 5 + holiday + sunday hours
other hours (this category would catch hours that were between 8 & 5 and not on a holiday, saturday, or sunday)

2) having assigned the number of hours that fall in each category, I'd then compute the cumulative hourly charge in each category using lookups to retrieve customer specific terms. I do it category by category until I'd finished billing for all the hours. Then I'd sum all the subtotals.

this really is nothing more than doing it on paper, one step at a time, and then translating the steps into computer scripts.

Good luck.

-- tom

4. ## RE: The logic of it all

Hi Tom,

Thank you for responding, you did a great deal of thinking and typing. While having dinner just a bit ago, I thought about breaking it into 5 separate scripts. The reason that I elected to use select/case is because only one of the premiums get charged to a job, and the case statements are in the order of highest cost at the top decreasing as the flow goes thru the select statement. The script is supposed to perform several functions. The first being setting the appropriate operator value to the highest of holidays, etc. While at the end it insures that all other multpliers are set (refreshed) to 1 and all other addons to 0.

I think it's a monster,
Ed

5. ## RE: The logic of it all

Hi Tom,

I remarked out all lines in the script that refresh the fields in question and it seems to work perfectly, will that present a problem later on?

Thank you for any insight,
Ed

6. ## RE: The logic of it all

Ed,

the answer to that question turns on what else is happening on the form. I shouldn't think it will do any damage, since the lines you're commenting out simply update the display...

-- tom

7. ## RE: The logic of it all

Hi Tom,

That is actually good news, I didn't know that the refresh only affected the display. When I think about it the word "refresh" is self explanatory.
Thanks again for the umpteenth time,
Ed

8. ## RE: The logic of it all

Hi Tom,

I deleted the refresh lines from the above script and had it on the ondepart event of the data entry form (parentform) named "jobenter" and it worked great. Suddenly the event doesn't fire when I save the form. Is there a better place to put the script?

Thank you for any incite,
Ed

9. ## RE: The logic of it all

OOPS, I meant the cansave event.

Age is setting in,
Ed

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•