Portal spanning multiple pages

[jasonwood]

I use a portal for line items on an invoice... but what if a customer buys more items than are able to fit on the first page?

How can you design a second page with a portal that will continue on where it left off?

THANKS!

[Vaughan]

Avoid the portal: print the invoice from the related database, where each line item is a record.

[danjacoby]

In addition to Vaughan's advice (which is excellent, as usual), you can also create sub-summary parts in the related file to show totals, subtotals, etc.

[jasonwood]

I don't really understand how I could efficiently and reliably print an invoice from the line items database... but I did figure out how to make a second page.

I simply put my line items portal in my body, everything else in the header and footer, and make the body twice as big as would fit on a single page.

The problem... now it always prints two pages, even if the body on the second page is blank.

Maybe I should have two layouts, one for regular invoices, and one for extra long ones, but I would need to have a condition in my printing script that would decide which one to use. Any ideas?

Something like...

If number of portal rows >= 12, go to layout 2Page, else 1Page

Print

Go to original layout

problem is that I am not aware of a way to determine the number of portal rows (or related records through a script).

Thanks again!

[BobWeaver]

The real question is how you can reliably print with portals. Portals were never really recommended for printing, although there some situations where there is no alternative. Invoices usually are not one of these situations. Printing from the line items file is the usual method. In the line items file, you find the records with the required invoice number(s); sort by invoice number, print from a layout that has an invoice number subsummary part which includes the specifics of the invoice (customer name, address, invoice number etc.) and the body part which contains the line items. To get the invoice data, you can create a reverse relationship back to the invoice file.

[Vaughan]

First create the invoice layout in the line items database, then create a "View Invoice" script that changes to the layout etc.

Create a script in the master database that includes these steps:

Go to Related Records [lineitemsrelationship]

Perform Script [external, lineitems - View Invoice script]

Refresh Window [bring to front]

The "Go to Related Records" step finds all the related line items records which are then viewed by the "View Invoice" script. The "Refresh Window" step is there to bring the user back to the master database after the View Invoice script has finished -- this makes the peocess seamless and the users need never know they've switched databases.

It beats mucking around with portals. Try it.

[LiveOak]

I kind of like using a Title Header part to give a full header with ship to, bill to etc. on the first page, followed by a Header part to give an abbreviated header on a second page. A Grand Summary will put the totals after the last of the items, a Title Footer will put the totals (or notes, etc.) at the bottom of the last page.

-bd

[jasonwood]

That's an interesting method, and I certainly see how it would work, but I can't help feeling a little backwards about it!:-)

Since I have everything working almost perfectly as it is, I think I'll leave that method for my next database... what I did to solve my dilemma is this...

Put a field in Line Items called "globalPageCount"

In the "PRINT" script in the invoices database, include...

Show related records (Line Items)

Run external script "Check Number of Pages"

This script in Line Items that puts either 1 or 2 in globalPageCount depending on "status(currentFoundCount)"

Then, depending on the value of globalPageCount, the invoice decides which layout to use.

This seems to be working nicely in my setup.

Thanks guys for getting me thinking!

[Vaughan]

Seriously, the portal method is the *wrong* method because FM Inc never designed protals for flexible printing -- sliding/printing does not work in portals for instance. (They never designed portals for printing because the other alternatives are all vastly superior.)

Try this method -- it don't take long and it'll be so much easier now and in the long term. Now, not next project because you'll end up having to re-do it once you see how it all works.

[joecollver]

Something I haven't seen people bring up in these portal/printing/invoice threads is the issue of invoices where the information for each item is more than one line. The invoice I'm working with has at least two dozen fields for each item, all formatted to look like a table inside a rounded rectangle.

After finding out the hard way that portals are the WRONG way to print this layout, I'm a little worried that the method Vaughan and BobWeaver give won't work for invoices that need more than one row for each item.

There's a good possibility I'm being an idiot and there's nothing to worry about, but if this is the case, could anyone tell me a good way to avoid having these large rectangles split in two when they reach the end of the page?

You help is appreciated

[BobWeaver]

There is nothing preventing you from having several rows of fields in the body part of your print layout. And you can build all the outlines, borders etc. with graphic parts much like a web page is built up piece by piece. With a normal style report printed from the line items file, there is no limit to the number of records you can print, whereas a portal has a maximum number of lines that can be displayed. A non-portal report is generally more flexible because you can include all kinds of sub-summaries.

Having said that, I have been rethinking the arguments against printing portals since I have had a couple of recent situations where groups of data on the same output page had to be sorted and summarized according to different criteria. Portals were the only reasonable option that I could come up with. With recent versions of Filemaker, printing portals seems to be reliable (for me anyway). I don't remember the specifics, but earlier versions seemed to act strangely sometimes when printing portals.

I guess it comes down to the amount of effort required to achieve the type of results you want.

[joecollver]

So here's what I think I need to do:

1) Create a new layout in Line Items file, with title header, body, and footer

2) Create a reverse relationship back to the Invoice file, and put all of these fields (shipping date, carrier, port of arrival, etc.) in the title header.

3) Copy the rounded rectangle-table contraption from the old layout, minus the portal, and put it in the body of the new layout.

4) use Vaughan's fancy script to direct get from the Invoices file to the Line items file, find and sort the records I need, and display them.

Sounds great, but, being new to this, I still have a couple of questions.

1. In this layout, what makes the body of the layout automatically repeat itself for all of the records in the found set?

2. How come after entering multiple test records in the Invoice file of the solution framework, I can't for the life of me find a single entry in the Line items file? The relationship is there, the data can't be in the Invoices file itself, so where is it hiding from me?

Again, thanks for the help.

[kennedy]

1. In this layout, what makes the body of the layout automatically repeat itself for all of the records in the found set?

For any layout, if you View as List, it repeats the body for each record in the Found Set. You can specify that a particular layout can only be viewed as a list.

Hopefully someone smarter than me will help on #2, as I didn't even understand the question.

[joecollver]

yeah after a little more reading and tweaking I found the answers to both the questions. Thanks for the help.

the second problem was solved when I did a search on the line items file for the record I needed and out it popped.

It's embarrassing to find out 15 minutes after you post a question that the answer is so readily obvious.

[SteveB]

I tried to print using portals which didn't span more than 1 page. What I got was occassionally having one row print on top of the following row, which I'm convinced is caused by FM and not the print driver for an HP Laserjet 4L. I've never seen this problem with any other software.

Because I can't trust portal printing, I am now printing from the child databases and not the portal. If you can't guarantee what the user will be printing to, you are much better off doing away with portal printing!

[joecollver]

Yeah I was having the same problem... random rows printing on top of other rows... I'd bring the ones that weren't printing to the front which would only make other rows disappear.

but now that it's out of the portal and in the lineitems file the layout works fine.