When asking for help with a script that doesn't work, it is helpful to post a copy of the script.
You can do that by using screen capture, or by printing the script to PDF.
Even better is to post a copy of your file; or a clone of your file.
If you want to print an invoice, it's best to do that from a layout based on the line items (ie your 'InvoiceParts').
Create a layout based on the InvoicePart table occurrence (Layout Setup: Show records from ...), and all you need is (from the context of an Invoice record):
If [ IsEmpty ( InvoicePart::InvoiceID ) ]
Go to Related Record [ from: InvoicePart ; layout: YourNewInvoicePrintLayout ; matching only ; current only ]
which means the relationship itself performs the Find for you
Wow. Now only if there was some documents that had something with relation to this :/
Thank you though. What is the point of having the if statement end the script if invoiceID is empty? (It is currently auto-generated from creation. Is it just an emergency backup incase something went wrong?)
What is the point of having the if statement end the script if invoiceID is empty? (It is currently auto-generated from creation. Is it just an emergency backup incase something went wrong?)
Yes. Error trapping is a crucial component of coding. Just consider Murphy's Law.
If the reference to that field is empty, that means that is is empty in the first related record, meaning there are no related records. That's why you reference a field that isn't supposed to be empty, like the primary key. (Speaking of which, it seems that your InvoicePart table doesn't have one.)
GtRR is usually used to do something to/with those related records. If there are no RR to Gt, you'll remain on the current layout, and the next commands/steps will be applied to the records of that layout - with consequences ranging from the mundane (like here) to the catastrophic (Delete all Records [ dialog: off ], anyone?).
I figured that having a key for every invoicePart would be redundant since I won't ever be displaying them all and is used just as a storage (to me it makes sense, but to you it may not. I come from C# and C++ programming, which is not similar really). Should I be adding a key id to all the invoicePart?
It's not about displaying them all, but being able to identify each one unambiguously. In fact, every table (with the exception of Utility tables) should have a primary key.
Next thing you know your users want a sophisticated way to select products and add them as line item. Once you get there, you'll find yourself saying: "I need to find the newly added line item in the display portal and go to the amount field so the user can easily enter the desired amount ..."
In a join table you could create a primary key by concatenating all foreign keys to get a unique key - but then it is so much simpler to just define an auto-enter serial number or a UUID, and it avoids any complications that could arise from later changes.
Plenty of documentation. Next step is to read it.
There are loads of documentations. But they are so simplified, that more than half the time it goes back to something similar to looking in the dictionary for a definition of apple to get "an apple is an apple"
The way it currently works, I already do have each "line item"/invoicePart containing a specific wanted amount.
This is a response to what?
There are loads of documentations. But they are so simplified
Nope, it's that you don't have the big picture yet.
The common theme is complexity out of simplicity (and I think that is true not just for FM). You have three tables with a simple structure, and already you could do loads of things with them, thanks to the relational interplay that can be as complex as you need it.
Same with the documentation. Most commands and functions have a simple API. The art is to know when to use what how where (and why (and who, if this were journalism school ...)).
looking in the dictionary for a definition of apple to get "an apple is an apple"
Horse, n. "A horse is a four-legged animal that breeds other horses."
Looking in the dictionary, I get this result.
apple |ˈapəl| noun1 the round fruit of a tree of the rose family, which typically has thin red or green skin and crisp flesh. Many varieties have been developed as dessert or cooking fruit or for making cider.• [ with modifier ] an unrelated fruit that resembles an apple in some way. See also custard apple, thorn apple.2 (also apple tree)the tree which bears apples.[Genus Malus, family Rosaceae: numerous hybrids and cultivars.]3 (the Apple) short for Big Apple.PHRASES the apple never falls far from the tree proverb family characteristics are usually inherited.the apple of one's eye a person of whom one is extremely fond and proud.[originally denoting the pupil of the eye, considered to be a globular solid body, extended as a symbol of something cherished.]apples and oranges N. Amer. (of two people or things) irreconcilably or fundamentally different.a rotten (or bad) apple informal a bad or corrupt person in a group, typically one whose behavior is likely to have a detrimental influence on his or her associates.[with reference to the effect that a rotten apple has on fruit with which it is in contact.]upset the applecart spoil a plan or disturb the status quo.ORIGIN Old English æppel, of Germanic origin; related to Dutch appel and German Apfel .