How to move the value of a field to another field

[darkdino]

Hello ,  i am developing a sales system for a company , and they have 3 types of payment CHECK, CREDIT, CASH, they need to sum this at the end of the day, so what i want to do is to insert this values in a dropdown list, so if they choose CASH, to move the value of the total to the field CASH, or if they choose credit it moves the value of the total to the credit field.

Can any one help me?

attached is the screenshot

 

Thanks

[comment]

This raises more questions than answers.

First, if TOTAL is a calculation field, then its value cannot be "moved" to anywhere. At most, it can be copied to another field. This raises the question why would you need to store the same value in two places.

I would also ask what if a customer wants to pay part credit, part cash. And if that's not possible, why would you need a separate field for each type of payment?

No doubt you could work something out using either auto-entered calculated values on the three payment fields, or a script triggered by the modification of PaymentType field. But I suspect you need to further think this through.

[darkdino]

Thanks for your answer, i solved it with copy and a script  triggered by the modification of PaymentType, 

The Manager told me they want separate fields because they want to track how much is in credit how much is in cash and how much is in checks.

However you are right if they pay half credit and half cash i can modify it any way entering the value manually.

Also they want to track the cash flow for each day, then i can browse by date and make a summary field of the cash field

 

 

 

 

[LaRetta]

The Manager told me they want separate fields because they want to track how much is in credit how much is in cash and how much is in checks.

There is a distinction and sometimes big difference, as in this case, between what a Manager wants as a result and what you should design on the back-end structural side.

If you have a single record which holds dollars for a check and another field for cash, you will never be able to generate a report which groups all checks, then a sub-total, all cash, then a sub-total ... and that is just one example of the problems your manager's design would cause.  A record should hold a PaymentType field which designates it is cash, check, on account, credit card etc.  Another field called Reference holds the check#, MO#.  And then you have the amount (for that one type you are entering).  This also provides you a bank deposit slip as a bonus.

As is, you are placing things that are alike (a method of payment) as fields when they should be records.  In this manner, you can still generate the reports your managers wish but it provides reporting flexibility because you can then group into record sets and sort/aggregate the values.

Another point is that cash, check is not a set number.  What if next week, Manger says, "Now I also want you to group them by money order and net-10"?  Records are very easy to add but fields are not, particularly when you consider all the places you've placed these fields throughout your solution.  It would mean major change.

As Comment suggests, it would be good to think this through.  Your are starting to make one of the most common mistakes in the business but it's a doozy.  Oh, and welcome to FMForums.  :-)

[comment]

Two short notes (LaRetta already covered the most important parts):

1.

i solved it with copy and a script  triggered by the modification of PaymentType, 

You should not use copy/paste in your scripts, because (1) it destroys the user's clipboard and (2) it requires the fields to be on the current layout. Unless your script is meant to assist the user in data entry, you should work directly at the data level and use the Set Field[] script step.

2.

The Manager told me they want separate fields because they want to track how much is in credit how much is in cash and how much is in checks.

That's actually easier to do if the amount is in a single field. You just need to find the relevant records and sort them by type. A single summary field will do the sub-totals and the grand total for you. And if they can pay half credit and half cash, then you will want to enter those payments as separate records in a related table.