comment

Your runtime users can produce a PDF by printing and selecting (manually) the option to print to PDF. If you want to automate it for them, you will have to use a plugin or OS-level scripting. See also: https://fmforums.com/topic/98652-save-as-versus-print/?do=findComment&comment=448649

I presume QBXML is an XML file (there is very little one can learn about it by Googling it or 'quickbooks xml'). If so, you can import it as you would any XML file - with the help of an XSLT stylesheet to transform the document into Filemaker's own FMPXMLRESULT grammar. I am afraid that without seeing an example of the input file or its schema that's about all I can say.

Okay, then please explain what exactly do you mean by a "checklist", what is it used for and why is it necessary to recreate it periodically. Usually you create something in a database only when something new was created in real life. A mere passage of time is not a good reason to make any changes. Please leave that to the forum moderators.

I am afraid not. You have posted this under Interface Design, but it looks to me like a question about database structure. Based on the parts that I did understand, I would say that you need to have a Sites table and an Equipment table, related by SiteID. Possibly a third table for types of equipment. Then - I would think - comes a table of Issues, which would be linked to Equipment by Equipment ID: Sites -< Equipment -< Issues This is based on the assumption then whenever a piece of equipment develops an issue, a record in the Issues table would be created. Once the issue has been solved, the record would closed (e.g by entering a date into a ClosedDate field). But this doesn't fit your description of preparing a weekly checklist, or having a N/A value (indicating what?).

Come to think of it, that's not entirely true. Suppose you add a field that cannot be empty (such as ClientID) into the portal and give it an object name. You could then use the GetLayoutObjectAttribute() function to get the object's content - and hide the portal when it's empty.

This is not going to be simple - and I am afraid it might turn out to be slow too (these two often go together). In a nutshell, portal filtering works at layout level - and you have no access to its results except by viewing them on screen. So your plan to use the results of portal filtering in order to show or hide the portal cannot work. You will have to replicate those results using another method. And that method will have to test each and every record in the Clients (?) table for the conditions stated in your portal filtering formula. This could be done using a custom recursive function or ExecuteSQL(). Or even a script triggered by modification of one of the global fields. The simplest one to implement would probably be to add an unstored calculation field to the Clients table to do the PatternCounts, and look at the aggregate result from the context of Shift. You could also switch the portal filtering to use the same field and eliminate at least some of the duplication. You don't really need those fields: just use the x relational operator with any two fields (or even no fields at all).

If you want to place the totals in a fixed position relative to the bottom of the page, then you must use the footer part for this. But that will only work if the entire invoice fits on a single page.

I don't understand what you mean by "it not work to fix the position".

Please provide more details about your setup. How exactly is the relationship defined, and what exactly is your filtering expression? --- A semantic note: There is no such thing. A portal shows related records. The result of a search is a found set.

I am afraid you're not being clear now. A button can be either inside the first portal row or outside it. If it's inside, it will be repeated for each row. If it's not repeated, then it's outside the portal for all intents and purposes. In any case, what I said earlier still applies: if it's a button, then clicking it will not change the current selection. If you're doing something in-between that will cause you to exit the current portal row (such as opening a popover), then Filemaker will not know which portal row to delete.

To display products grouped by their name, sort them by name and use a layout with a sub-summary part and no body part.

Do you mean the button is outside the portal? Well, that depends on whether it's a button or a popover button. Clicking a button does not change the current selection, so it doesn't really matter if the button is outside the portal. If it's a popover, you will need some method to remember the active portal and the active portal row number - e.g. by running a script triggered on object enter. Consider also what might happen if user clicks the button accidentally, when no portal row is actually active (but one might have been active beforehand).

I am afraid your description is not clear enough. What does your solution actually do for your customers? Are you the one working with it, or do your customers operate it? Not sure what is the point of that either. -- P.S. Please update your profile to reflect your version and OS.

I can't answer that without knowing what exactly we are doing here, and - most importantly - for what purpose.

I don't see why not. I suppose it could be something like: SELECT Field1 FROM YourTable WHERE StartDate = CURRENT_DATE - DAYOFWEEK(CURRENT_DATE) + 1 assuming weeks start on Sunday.