Going to a "related record" - I think!

[exposbabe]

Basic business database model with three tables:
-customer info/table
-order/invoicing layout (and table)
-payments layout/table

I've got the relationships between then (simple, linked by customer ID) and everything seems to work, except one bug I can't seem to figure out.

The string of events, the way I have it set up (the way my husband wants it!) is this:

First thing, go to the customer info layout: fill in the relevant name and address stuff. A customer ID number is auto-assigned serially.

Then, I have a script to send it to an "order layout", to fill out order numbers, price, cost.

Then, depending on what's needed, it does some calculations and prints out an invoice or not. bla bla bla.


What I WANT it to do is go from the "customer info" layout to the "ordering layout", autofilling the customer number and name that have just been autofilled or typed, so that I can fill in the rest of the relevant data.

It won't do it. It goes to the "ordering" layout, but is at the previous record.

How can I get it to make that jump, ensuring that this new ordering record is related to the relevant customer info record?

I hope this is clear.

Thanks for your help. I'm not quite sure how all the script steps work yet, so there may be something quite obvious I'm missing.




SM

 

[JeanW]

Maybe I'm missing something, or it is there but you didn't mention it..

>>First thing, go to the customer info layout: fill in the relevant name and address stuff. A customer ID number is auto-assigned serially.
This is on new record level, right ? So, goto custInfoLayout, make new record, fill in data....

>>Then, I have a script to send it to an "order layout", to fill out order numbers, price, cost.
What is 'it' ? and what are the script steps to send it ?
Does your script creates a record based upon the CustID ?

How do you 'go' to the customer record ? Is it a script ?
Can you give the details ?

If you have a relationship between customer and order, based upon customerID and you use a go to related record step, FM will go to the related record(s).
So you need something more than just a ID to uniquely identify the new record.
Not knowing the details of your navigation, I think you're missing a commit record step in the creation routine of records in your order file.
As long as the new record is not committed, it nearly doesn't exist for FM, hence the previous record, but, on the other hand, if you use the GTRR step, it has to find the record, or 'a' record....

 

[exposbabe]

Here's what I've done (making sure records are committed along the way).

The "customer info" record is a "new record" add.
I fill in all of that info.

Then, I scripted the button to
-move to the "order form record" (which is based on a related table)
-create a new record.
-save the customer ID number from the "customer info record", and paste it into the "customer ID field"

The rest of the relevant related fields fill in automatically. - depending on circumstance which is also built into the script), then a summary "report" of both for the files is printed.

It all happens like clockwork.

I'm sure there is probably a more correct or simple way to do it. But I'm all about end result here, in my first kick at this can.

 

[JeanW]

>>save the customer ID number from the "customer info record", and paste it into the "customer ID field"

Do you use copy and paste here ?

You could use the variable $ in your script to push the needed data to make the relatinship in the order table.

Something along these lines:

/*you're in the parent record*/
freeze window
set variable [$key; Parent:arentID]
set variable [$other; other value ]
/*as many as needed*/
go to layout [child]
new record/request
set field [child:arentID; $key ]
set field [child:therfield ; $other ]
/*and so on*/

This way you 'stay' in the new created record.