[i just realised I have overlooked some of the posts in this thread. But having spent a good hour on fine tuning this answer, I'll just leave it, hoping it will help somebody some day...]
Hi Kuroneko:
You sound like you could use a quick and dirty solution now, and then you might want to dig into the finer database theory later.
First of all. I'm not sure from the pictures whether you are running FileMaker 7 or 8. So I don't know if your system supports 'script variables', so I will sketch an old fashioned solution.
You need to move the quote data to a new empty invoice. For this purpose you build a new relationship called 'GetQuoteData' in your invoice db:
The primary key is a new global field in your invoice db: QNUMBER_g
The foreign key is the QNUMBER in your quotes db, which must be a unique.
Make sure new QNUMBER_g field has the same data type (e.g. 'number') as the QNUMBER field.
Now you need to go to the Invoice file and make a script called "Make Invoice from Quote" that looks something like this:
SetField [ QNUMBER_g ; get(ScriptParameter) ]
GoToBrowseMode
Commit Record
GoToLayout [ Invoice layout ]
NewRecord
SetField [ CustomerName ; GetQuoteData::CustomerName ]
SetField [ CustomerAddress ; GetQuoteData::CustomerAddress ]
... and you simply make as many SetField script steps that's needed to fill in all the fields that corresponds between the two files, and end it with a:
Commit Record
Now you go back to the Quote file and make a new script called "Make Quote into Invoice". This script consists of one script step:
Perform Script [ "Make Invoice from Quote" (in quote file) ; parameter: QNUMBER ]
This script calls your new script in the invoice file WITH A SCRIPT PARAMETER. And the value that goes in the script parameter is naturally our QNUMBER.
Having done this script, you produce your magic button and attach your "Make Invoice from Quote"-script to the button.
In this way we get that quote number parsed to the global key field in the invoice file, thus creating the connection between the new invoice and the quote.
If your boss was a little visionary, he would like to be able to track that particular invoice back to that particular quote. And if he likes that, you should make the field a regular field instead of a global field.
This can be helpful even if he wants to make more invoices from the same quote.
Now, this is a fairly basic outline of the principles. You can add all kinds of controls and tests along the line to ensure data integrity and avoid human errors.
For one, you might want to include a "Show Custom Dialog" + and "If (get(lastmessagechoice) = ...) to top of the button script so it doesn't fire unintensionally, if you happen to push it.
Sorry, if it's a bit basic and long, but when I don't know your skills I thought it best to make a full cooking recipe.
Hope this can help you keep your job ;-) ...
First a disclaimer. I'm well aware that WebDirect (FM13) is not build or supported for iOS or Android tablets. I've read the specifications. And yes, things should probably be done in PHP instead. Which is no doubt, what will happen eventually. But for a number of reasons, I'm involved in a couple of projects, where we have decided to examine the borders of WebDirects compatibilty first. So I would like to hear any concrete findings from other crazy persons who have been experimenting on the wild side with WebDirect. What kind of functions and design methods work for you. What should we avoid in striving for a solution to best survive in e.g. Chrome on an Android tablet? Any experiences with Raspberry? Why is this interesting? Well, unless you publish your WebDirect solution on an intranet or another very controlled environment, there will always be users who will try to use whatever browser is at hand. So we might as well prepare and try to recognize and understand the things that can and will go wrong in those situations. Maybe we might even collect some useful feedback for the good developers at FMI. ;-)