How to stored a field?

[Mark Pastoril]

how i can stored a field when it depends from a related field from the other table, 

The field is the senior citizen discount field which only calculates when the customer is registered as a senior citizen.

if not , it will not calculate.

Table 1-Customer (senior citizens discount field)

one to many relationship

Table 2-Transactions(look up the senior citizen discount field and make a discount if the discount field is yes)

[Wim Decorte]

The person becomes a senior citizen only once, in that sense it does not make sense to try and 'calculate' that over and over.  Calculations become unstored by design when you reference a related field.

What I would do: run a nightly routine that evaluates people's birthdays and statically toggles them to 'senior citizen' if they

[Mark Pastoril]

your right sir, but they will have to register before they can avail the discount that's the time that his transaction will implement the discount,that's why i have to store this field.so that it will calculate until the customer is registered .

sample.

if the customer has the bill for the month of Jan-Feb-mar 2019.

but the   customer only registered for the month of Apr-2019.

the field only calculates the discount of Apr-2019 bill, not the entire bill of jan-feb-mar2019.

[comment]

Use a field with auto-entered calculated value (not a calculation field). The calculation formula can be something like =

If ( Customers::SeniorCitizen ; Preferences::SeniorCitizenDiscountRate )

 

Edited December 13, 2019 by comment

[Mark Pastoril]

yes this is my actual calculation

If ( wb::SCDiscount="Yes" and Consumption<=30;AmountDue*.05;0)

but i don't know whats wrong, that it will not run if I enter new data?

Edited December 16, 2019 by Mark Pastoril

[comment]

If you want the calculation to re-evaluate when the local fields are modified, you must uncheck the "Do not replace existing value …" option.

--
P.S. Once again, hard-coding values that are likely to change at some point (such as consumption limit or discount rate) into a calculation formula is bad practice. 

 

[Mark Pastoril]

is my calculation correct?why is it not running.

regarding this field, i just used this code, 'coz it is the way our office processing is.

[Wim Decorte]

Structurally there is nothing wrong with the calculation but we don't know if it is correct in the context of where the user is when you expect a result. You will have to tell us more about the "not running"

Can you give us a full example of the record's data and what result you get and what result you expect in the circumstances.

Since the calculation seems to contain one related field you also have to tell us what TO you are on and how the relationship is set up to the related TO.

[Mark Pastoril]

There 2 tables in my app.

Customers-table

Transactions -Table which is connected to each other by customersid

Customers table fields includes 

*accountname,*Address,*Meter, and SCDiscount=No/Yes

*Transactions fields-*Previous Reading,*Present Reading*,*usage, and *Discount field=(SCDiscount field from Customers table)

when i used the Discount field in a layout, it shows the result of Discount=No/Yes, so this means that the two fields is succesfully connected.

but when i create a new field (discount rate which is an auto-enter calculation field) then i used this code:

If (Discount="Yes" and Consumption<=30;AmountDue*.05;0)

when entering new field the result always shows 0, even if the calculation meets the criteria.

any help please?

[comment]

Does the attached demo work for you?

DiscountAE.fmp12

[Wim Decorte]

And here's another one.  What it shows is that it is not your calculation that is wrong but the rest of your structure and we can't really tell until until we see all the details of your fields.  But hopefully between this and @comment's demo you'll be able to see what combination of field options to use to make the calculation work in the right circumstances.

 

Note that as mentioned, for these kinds of historical transactions, you do not want to rely on hard-coded values in your calculations, if you set up the fields incorrectly and it affects their updating then you may inadvertently change a bunch of historical billing records.  Plus you will have no insight whatsoever in what rates were in effect at what time.  So use a 'Rates' table that your calculations refer to, to pick up the proper active rate.  And to go one step further, adding a transaction record is something I would do in a scripted fashion with the calculations in a script and not at the field level.

Pastoril.fmp12

[Mark Pastoril]

Good day sir.

Merry Christmas and Happy New Year

just came back from a very long vacation, tried the sample from sir Wim Decorte and it worked for my application.Thanks also for #comment for the ideas.

it really helped me a lot, I will continue developing my application and continue to post questions here. I hope you will continue to support and answer my questions. Thanks & God bless.