sliding should work for you.
I already tried that but I'm not very happy with the layout. There are 2 portals under eachother and between these portals there is some text.
So for example if PRODUCTS is empty and there is only lines in SERVICES, then there would be a lot of white space between these 2.
Thanks for the reply!
As Mr. Vodka said: "Sliding should work for you".
Set the text in between to slide up as well as having the portals slide. Make sure "reduce size of enclosing part" is selected.
Aah great! Thanks PhilModJunk and Mr. Vodka!!!
I'm trying to print the same here, but can't get it to work.
can you share your file ?
I have couple of queries;
1. from which table does the report layout print? (from the master table or the line items table?)
2. how are two portal fields arranged 'under' each other?
When I tried placing one portal under another, I get the following result;
I want to print one set of lineitems from one portal, followed by one set of lineitems from another portal.
tried a different method, this time used the master table and used portals in the body part, but no luck with sliding, even if 'also resize enclosing part' is checked.
Print from the lineitems table. Put the services in a portal in the footer.
used lineitems table and placed the portal in the footer
trick didn't work :(
sliding just doesn't work.
what am i doing wrong?
So you are using a list layout for your line items and the footer for your services portal correct? Do you have the resize part option on for sliding?
And are you looking at your report in preview mode or after printing it?
Sliding is not visible in browse mode.
yes the resize part option is on.... but since the footer is always rooted to the bottom of the page, I placed the portal in a sub-summary part... it worked ! (sliding wasn't required at all, btw sliding doesn't resize a portal if there are some blank rows in the portal)
but now the problem is if the portal has more records than the number of rows in the portal, those records don't show up.
I guess my only resolution will be to copy all records to a new temporary table only for printing the invoice.
can't figure out how to copy related records to a new table.
Personnally, I wouldn't use portals at all for this if I can possibly avoid it.
Services and Items purchased, could be listed all in the same table. Filtered portals can list them separately on a data-entry layout and your invoice can be a summary report based on your line items. If you have a field in your line items table that distinguishes services from products, you can add a sub summary part that specifies this field as the "break" (sorted by) field.
Then you can find all the line item records for a given invoice, sort them by this break field and you'll have your invoice report.
Here's a link to a simple tutorial on setting up summary reports that you may find useful:
Creating Filemaker Pro summary reports--Tutorial
well I'm not using two portals for products and services, I just went with the flow of the thread topic here because my primary purpose is to learn to print from two portals in a single page.
This requirement has actually come up after my successful implementation of "how to update/com mit records between two portals in the same layout" thread.
I'm actually using three portals on the same layout, one portal for lineitems, second for different type of discounts and schemes and third for different types of taxes.
Both of you Phil and Mr. V have been helping with that problem, Mr. V gave me a good example of how to set up
taxes without portals, but that example adds up all taxes into one figure, where as it's mandatory to mention each tax separately in an invoice.
Now that I have all related records divided in four tables of which three tables function like lineitems for products, discounts and taxes, how do I print all these records onto a single invoice using reports?
Case 1: If I put records of three lineitems tables in three rows in the body of a report, then I get a report showing first set records of each table followed by second set of records and so on.
Case 2: If I don't use portals at all, then I'll have many fields for all the different types of discounts and schemes and taxes in a single table. There are very few invoices which will actually fill up all these fields, moreover, if there is any new type of discount or scheme or tax then a new field will have to be created. (demanding a significant update in the application.)
To add to the problem here, there are 12 different types of discounts, at least 4 different schemes every month based on customer's area, 4 types of taxes.
Whichever field is used has to be mentioned explicitly in an invoice.
How much space can I allocate to all these fields in an invoice?
If I allocate a line for each of them and say if a discount is not used, then that will leave a blank line in the invoice.
Case 3: If I bring together all these 'linerecords' into a temporary lineitems table only for the sake of printing then creating a report from this single table is a cakewalk. But the question is how to copy all the related lineitems records from products, discounts and taxes from three different tables into one table.
Sorry about the confusion.
Please help me resolve this printing problem.
You have two basic options for combining dissimilar records in a single "print" table. Both start with designing a table that combines all the fields needed for all the different fields of each source table. If you have filemaker pro advanced, this will be easier as you can copy and paste field definitions from one table to another. In either case, use import records, specifying a new table to duplicate the field definitions for one of the source tables and then add field definitions from the other tables. You can make some fields "multi-purpose" and store different data of the same type from different tables if you wish, just document any such use carefully.
Once you have the data setup, you can either use Import Records (there are risks here, due to a long standing bug in filemaker. See this thread: Data loss bug : Spontaneous and erroneous import matching of new fields in specified imports ! for more on it. You can avoid the main risk if you keep all field names exactly the same and use the matching names option ) or you can script a loop throught the fields and records of each source table to use either set field or a combination of set variable/set field to move data from the source tables to the "print" table.
Your last step is to design a report layout that correctly displays your disparate data from a layout where you have to use the same design for all the records. You can stack fields on top of each other when you know all but one field will always be empty. You can place one such field directly above another and use sliding printing. You can use conditional formatting and special calculation fields to label the data differently in other groups--just to name a few tricks of the trade you'll need to use to make this work.