
(If we did have records with 0 value, they would be separated, and come after the group of blank records. In this case, we have only two groups: regular items, which have no value in the Optional field and Optional items, where the Optional field is set to 1. This is followed by records that do have a value, in numeric order (assuming the break field is formatted as a number field). FileMaker subsummary parts sort, group, and display records that have no value first. This successfully split the regular and optional items into two groups. Then I adjusted the Preview proposal script, to automatically sort the records by the “Optional” field, so that the subsummary part would show when viewed in Preview mode. Going back to my layout, I modified it and added a subsummary part, then chose the “Optional” field as the break field. This avoids the extra step of having to fill in a value of 0 in a field when we could just leave it empty and still test for a 1 in cases that are on/true. The only difference is that in FileMaker, we typically use the values “empty” and “1”. Note: this is the FileMaker version of a boolean field, where 0 is off/false, and 1 is on/true. It was formatted as a number field, where Optional items would have a value of 1 (checkbox on), and regular items would be empty (checkbox off). I decided to add a simple checkbox to the entry portal for the line items, so the user could indicate that the item was optional. I knew I’d be able to use a simple subsummary report to split the regular and optional items from each other.

When faced with a difficult problem, I always remind myself, “Solve the simple case first!” So to start, I tackled the regular/optional issue, which was straightforward. But since I’m writing this blog post, you can imagine that I eventually found a way! I knew that creating a total in the middle of the report was going to be challenging, because of the way FileMaker handles subsummary parts. At this point, I didn’t know how I was going to do that yet. They also wanted a checkbox next to each optional item, so that the proposal recipient could print out the proposal, manually mark which optional items they wanted, sign the proposal, and scan it back. Instead, they wanted the regular items to show with a total below them, and then the optional items below that. The catch was that they didn’t want the optional items to be included in the overall total. In Preview mode, It looked something like this:Īfter I built this simple report, the client told me that they’d like to be able to add some “optional” items to the proposal as well.

To produce the report, I had created a list view layout showing records from the context of the Proposal Line Items table, with merge fields placed in a Trailing Grand Summary part displayed at the bottom of the list to display the summary total and monthly amounts.

There was a Proposal table to hold data such as the proposal name, customer name, and date, and a Proposal Line Items table related by ProposalID to hold the individual items added to the proposal. I was working on designing a report for a client for their FileMaker solution, formatted as a proposal. But what if you need both a leading and trailing subsummary part for the same field on a single report? Well, you can do it, given a little creativity! Typically, you can only create one subsummary part per field on a layout.
#Filemaker baseelements 14 xml error pro
Are you creating a FileMaker Pro subsummary report? A subsummary layout part is used to sort a set of records into groups based on the values contained in a break field.
