A portal cannot have dynamic rows.
I think the general thought of portals is that they're not meant to be printed. I break that rule a few times in my work, but generally the data in a portal can be dynamic, so printing it is not a good idea.
The better option is to redo the layout in a list view. You can redesign your invoice on a list view and get all the rows you need.
Does anyone know how to get around this problem?
Invoices are typically printed on a layout based on the line items table in list view (which for your practical purposes is unlimited in length). Using different layouts, purpose-built for different workflows, mean that the attributes of a portal you use for data entering don't constrain you in any way when it comes to printing those same data.
you need to print from the line items table.
To see an example, look at the invoices database in the start solutions. Naviate via the Layout Manager to "Print/Send Invoices". That is a great example of using a list view to create an invoice. Use that as your model and your invoice will print all the line-items for your order.
In addition to what erolst said, Portals do not cross page boundaries well. Invoices will work just fine from a List based layout (unless you ever have to output an Invoice with NO line items.) this is highly unlikely with an Invoice or Purchase Order. But... With a Statement this can become a bit of a problem, many times a Statement may need to be sent, that had no activity in the Statement period. This requires an alternative approach, such as a virtual list approach or creating a single previous balance holder field so a record can exist. In FM12 or later I would imagine some of these things may also be addressed with ExecuteSQL.
I would agree with most that you should be printing from the line items context, but maybe what you're thinking of is the option to specify sliding and visibility. If you have a portal with, say, 20 rows showing, and the options under for sliding checked to slide up, and also check the box to resize the enclosing parts, it will only draw the portal for how many rows are shown.
Set anything below the portal to slide up as well, and it will move up under the portal rows shown, but this will only work in preview mode, or when print. Browse mode will show all portal rows.
The big downside here is that you must define your portal display enough rows that you would expect to be showing, it will only show a maximum of how many rows are defined in the portal setup. That makes it less useful, but this can be useful in certain circumstances.
As has already been pointed out, a list view may work best for you based on the line item table occurence. So that stated I'm working on one that is based on the line item table, but each item may have a number of details lines it has to show. Somewhere between 0 and 15. So for the report, I added a 15 line portal to the body section of the list view based layout and set the Sliding and Visibility options for remove balnk space by: with Sliding up based on All Objects above and Also resize enclosing part. I also set this on each field in the portal.
The result is that the portal and body section shrink when in print preview mode.
Thanks Bruce, I've tried this method of using a sliding portal that will resize depending on the number of rows as required - this works fine. However, will this work if I need to print the portal across two pages?
I'm not sure. I have heard some remarks indicating that this may be an issue. I suggest trying it. Please let us know how you make out.