Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 3086 days old. Please don't post here. Open a new topic instead.

Recommended Posts

  • Newbies
Posted (edited)

 

Hi, 

I am trying to set fields in a related customer record based on a choice made in a payments table portal row.

 

The scenario is that in n the Payments portal row, the user will select a PaymentType from choices governed by a Value List. The Type chosen, will then set either one of two fields in a related Customer record via an attached script trigger - currently onObjectExit.

 

if paymentType "Annual Membership" is selected, the Customer::Membership StartDate will be set with the date of the payment. But if  paymentType "Monthly" is selected, the Customer::SubsLastPaid field will be set with the date of the payment.

Reference: Script 1.png

Isolating either of the Set Field Script steps in my example (see attached Script 1.png) works fine. But weird things happen if combined into the same Script as they are. For example, If I select  “Annual Payments” for the paymentType, the Customers::memStartDate updates fine, but any entry in the Customers::SubsLastPaid gets erased!

 

 

 

Reference: Script 2.png (The If Else script)

So I thought about it and tried the following (see attached Script 2.png) which makes sense as read, but obviously messes up syntactically because I don’t know the correct format. What happens is that the relevant paymentType gets selected and the associated Customers field just gets populated with a ? (Question Mark)

 

 

Can any experts help me solve this. I’d really appreciate it.

 

Thanks.

 

Script 1.png

 

Script 2.png

Edited by sonicarc
Posted (edited)
9 hours ago, sonicarc said:

The scenario is that in n the Payments portal row, the user will select a PaymentType from choices governed by a Value List. The Type chosen, will then set either one of two fields in a related Customer record via an attached script trigger - currently onObjectExit.

There is something very wrong with this requirement. If PaymentType is an attribute of payment, it should be a field in Payments - and modifying it should not affect any attribute of customer. It sounds like you are using a script where you should be using an unstored calculation field.

 

Edited by comment
  • Newbies
Posted

Hi comment, Thanks for the reply,

Yes, paymentType is in the Payments Table. I have a layout for customer check in that shows a summary of subscription details. On this layout is a payment portal to update the following fields for a related record in the Payment Table: paymentTimestamp, paymentAmount, paymentType ( value list).

Maybe I just need to have the Member Start Date and LastSubsPaid fields in the Payments table too, instead of in the Customers Table. I'll try them as unstored calculation fields in Payments.

I'm, only 3 months into my FM adventure and making great progress, but this foxed me. In a couple of months I know I wont have these issues of logic.

Cheers.

Posted
14 minutes ago, sonicarc said:

Maybe I just need to have the Member Start Date and LastSubsPaid fields in the Payments table too, instead of in the Customers Table. I

By their names, they seem to describe the customer, not any specific payment - so they should be in the Customers table. My point is that they should be calculated dynamically, based on all related Payments - not set ad hoc as a result of modifying a specific payment.

  • Like 1
  • Newbies
Posted

Thanks, I now understand the logic behind your explanation and I will crack on to see if I can apply it. I do like the learning curve.

Thanks very much for your advice.

This topic is 3086 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.