Nested Calculations/Scripts

[gregorj]

My confusion is in how to handle the logic and syntax of multiple branching events. I am developing a POS touchscreen system in Kiosk Mode for a golf course. No keyboard input.

When a member's card is scanned it is entered into an edit box using:

Insert Text[select;Transaction::Member_ID]

Now I have a 5 digit unique member number. This in turn generates a 3 digit MTypeIDLookup number which indicates the type of price the member will pay when the transaction is selected. The member could be a Regular, Senior, Student and Others.

Now comes my confusion...How do I script this?

1 - Has member renewed this year?

If[Member::RenewalDate<01/01/2007] Renew Y - N

If YES - then the member has to renew in

order to play.

This script ends and a renewal transaction is

used to update the card.

If No - then the member has renewed for

this year and the script should go on to 2

2 - Has member used this card today? (This is to

curtail misuse.)

Transaction table has Member-ID field whereby

the transaction is Date/time stamped.

I'm not sure how to best test this test.

If YES then I should have a Yes/No selection

to override the trap. If NO then once again,

the script should continue to 3.

3 - Check if using Weekday or Weekend Rates.

The cashier has entered Weekday as Y or N in

the Cashier Table::Weekday field. If N is in

this field then the fees will be Weekend fees.

(All fees are listed in a Fees table - The

logic is as follows:

Member::Member_ID generates thru lookup...

12345

Member::MType_IDLookup (3Digit code for price

levels) 002 (Senior)

Cashier enters transaction - 3 digit code

Transaction::ProductType_ID

102 (Senior 9 Hole Rate)

Lookup Price $16.00

Anyway, I can generate the lookups seperately I just have a problem scripting the logical seperate steps to smoothly arrive at the final endif.

Thanks for your help.

Greg

[ChasCH]

It looks like you have the logic worked out.

I would start to build seperate script steps to modularize the process. like:

1 - Has member renewed this year?

If[Member::RenewalDate< ;01/01/2007]

Perform Script

else

if[card_use_flag_date = get(currentDate)

Perform Script

else

Perform Script

Perform Script

etc....til you have covered all the bases...

endif

endif

The idea is to modularize your steps as much as possible so it will be easy to test different parts of the logic.

HTH

Chas

Edited July 8, 2007 by Guest

[T-Square]

I think you could accomplish most of your tests using relationships and calculated fields.

A relationship from the Member table to the Reservation table using both a stored calculated field with today's date, and the member ID would allow a quick test of the multiple use abuse. If there is already a record at the other end, then they're abusing.

The rate that a member gets is an attribute of the Member, and presumably is assigned in the member record, either directly or indirectly. So, when a member signs up, you assign them as Senior or Regular. A simple calculated field, cRate, would calculate: if(MemberType="Senior"; 16; 30)

Better yet, put these values into a rates table, so that when your customer adds a new rate, or changes their rates altogether, they don't have to write a program. Your cRate field would then simply be: MemberRate::Amount

Similarly, the weekend-ness of the reservation is defined when the member makes the reservation, You don't test this, per se, but you take into account in the evaluation. Maybe, if you enhance your Rates table, you add a Weekend flag field, and then build the relationship to take that into account as well.

Whether a member is active should be a calc field in the member table, and should not be based on a fixed date (unless you want to be going into the calculation to change it on a regular basis). If you want to use January 1 of the current year, then:

field cRenewalCurrent

if(Member::RenewalDate > Date(1; 1; Year(Get(CurrentDate))); 1; 0)

So, ultimately, your actual workflow will not really involve all that much testing in the sense that you were asking. One possible idea:

Opening screen, Clerk puts in member number, touches Okay button. This triggers script MemberValid. This script has:

Set Field[Member::TodaysDate; Get(CurrentDate) /* Note: there are other ways to do this */ ]

If [Member::cRenewalCurrent]

If [DupeReservation::ReservationID]

Go To Layout["UseAbuse"]

Else

Go To Layout["SelectDate"]

End If

Else

Go To Layout["ExpiredGolfBum"]

End If

Once the date is selected, it should be possible to present a layout with the rate as calculated from the rate table.

HTH,

David

[gregorj]

I just want to thank both of you for leading me in the right direction. By no means do I have it all figured out but your suggestions are very helpful in me not only going forward but avoiding the snags and demons that await me around the bend.

I'm sure I'll have additional questions, but until then...Take care.

Greg