Script for a popup reminder for payment due

[JayTee]

Hi, I am a novice in scriptmaking. I have a DB where I keep records of students for a Karateschool. I have a field named 'contribution' (date field) and a 'payment due' field (calculation field). This calculation shows me the message: 'payment due' when the date in the contribution field is one year old. This allows me to generate a report. But now I want to create a script for a popup reminder for each day a payment is due. Many thanks! Regards.

[bcooney]

When faced with this need, I usually bring the message to the Main Main layout. You could have a button that turns Green (using condtl formatting) if there are any payments due. If you want, you could also display a count of records with a payment due. User clicks the button and the script finds all payments due and shows the list.

[JayTee]

When faced with this need, I usually bring the message to the Main Main layout. You could have a button that turns Green (using condtl formatting) if there are any payments due. If you want, you could also display a count of records with a payment due. User clicks the button and the script finds all payments due and shows the list.

Thanks for your reply. Could you please elaborate a little more specific on how this is done?

[bcooney]

Not sure what part you don't understand.

Main Menu is a layout based on a one record table (I usually call this table SYS). SYS would have a calc field PaymentsDue = sum (cartesian relationship::flag_PaymentDue).

flag_Payment due is a calc in the table you mention above, just like the one you use for your message. However, I'd simply have it be a boolean, that is flag=1 when a payment is due.

Back to Main Menu. Conditionally format the Payments Due button to turn green if SYS::PaymentsDue>0. Also, have this button nav to the table and find only the records where flag_Payment due =1 (you could use go to related records).

[JayTee]

Not sure what part you don't understand.

Main Menu is a layout based on a one record table (I usually call this table SYS). SYS would have a calc field PaymentsDue = sum (cartesian relationship::flag_PaymentDue).

flag_Payment due is a calc in the table you mention above, just like the one you use for your message. However, I'd simply have it be a boolean, that is flag=1 when a payment is due.

Back to Main Menu. Conditionally format the Payments Due button to turn green if SYS::PaymentsDue>0. Also, have this button nav to the table and find only the records where flag_Payment due =1 (you could use go to related records).

Still can't get it working. Allow me to explain it the best as I can. I have a database named Karate, where I keep the records of the students of a number of Karate schools.

To get a message when the payment is due for each student I created 3 fields: Payment date (datefield); Reminder (calculationfield); Payments due (summaryfield).

The field ‘Payment date’ shows the date on which the payment was done (i.e. for last year). The field ‘Reminder’ gives me the message:”Payment due” (conform the calculation set for this field). The field ‘Payments due’ gives me the number of payments that are due. See attachment.

And to get e Popup reminder when there are payments due I created a script that works ok when opening the database. See attachment.

But the field ‘Reminder’ does not update automatically when opening the database. So the field ‘Payments due’ keeps the same number that was last seen the day before and the field ‘Reminder’ stays empty (the message “Payment due” does not appear).

If I then go change the date in the field ‘Payment date’, then the field ‘Reminder’ changes as the calculation orders. So I think the calculation is working fine, but why the field ‘Reminder’ does not update automatically when the payment becomes due?

Thanks

DB fields.tiff

script.tiff

[bcooney]

OK, Jay, let's dive into this.

Can you tell me what tables you have in your system? If all you have is a generic table, "Karate," you'll need to get a bit more advanced to have a more robust and useful system. In such a system, I see the need for People, Classes, ClassTypes, Invoices (maybe), Payments, Enrollment (join btw Peo and Classes). Payments can be a child to Enrollment. So, if a Person has an unpaid Enrollment record, then a payment is due (a calc flag in People).

Your current system does not seem to keep a history of a person's enrollment or payments. I would imagine such data to be valuable.

Take a look at the Starter Template that comes with FM (Registration). I'm not a huge fan of these templates, but it does show the use of a join table between Contacts and Events.

hth,

Barbara