Seems you cannot have multiple PlaceInBottoms. Found workaro

Miklos_Hollender
Member Posts: 1,598
...workaround 
Let's see if anyone has a better workaround here and if not we can move it to Tips and Tricks.
(Yeah, I know we are not supposed to make Classic reports anymore, but as long as they use it sometimes we still need to modify an invoice.)
At any rate: my job was to print the bank details in invoice footer (PlaceInBottom) except when the invoice is factored, in that case print the factoring text.
I used the usual two sections, CurrReport.SHOWOUTPUT approach, and it turned out it does not work because Navision reserves space in the bottom for both so one of them won't be printed to the bottom, but upper, and the other of them is often printed onto a next page.
(It is OK to have multiple footers with conditional output, just not PlaceInBottoms!)
The workaround was to set up various Standard Texts / Extended Texts, and have a function in some general setup table that taxes a Standard Text Code as a parameter plus a Text50 Array of 100 elements as a VAR, and assigns the first 100 records into the variable (... FINDSET THEN REPEAT i := i +1; TextArray := ExtendedTextLine.Text; UNTIL (ExtendedTextLine.NEXT = 0) or (i >= 100); ), and then basically put TextArray[1], TextArray[2], etc. as many as needed in textboxes in the footer.
That way I only need one PlaceInBottom footer.
It is not ideal because there are less formatting options. But nothing else seemed to work.
I wonder how this will look in RDLC reports

Let's see if anyone has a better workaround here and if not we can move it to Tips and Tricks.
(Yeah, I know we are not supposed to make Classic reports anymore, but as long as they use it sometimes we still need to modify an invoice.)
At any rate: my job was to print the bank details in invoice footer (PlaceInBottom) except when the invoice is factored, in that case print the factoring text.
I used the usual two sections, CurrReport.SHOWOUTPUT approach, and it turned out it does not work because Navision reserves space in the bottom for both so one of them won't be printed to the bottom, but upper, and the other of them is often printed onto a next page.
(It is OK to have multiple footers with conditional output, just not PlaceInBottoms!)
The workaround was to set up various Standard Texts / Extended Texts, and have a function in some general setup table that taxes a Standard Text Code as a parameter plus a Text50 Array of 100 elements as a VAR, and assigns the first 100 records into the variable (... FINDSET THEN REPEAT i := i +1; TextArray := ExtendedTextLine.Text; UNTIL (ExtendedTextLine.NEXT = 0) or (i >= 100); ), and then basically put TextArray[1], TextArray[2], etc. as many as needed in textboxes in the footer.
That way I only need one PlaceInBottom footer.
It is not ideal because there are less formatting options. But nothing else seemed to work.
I wonder how this will look in RDLC reports

0
Comments
-
To solve the problem of conditional report fields, the solution that I use involves creating global variables in the report to suit my purpose, placing these variables in the report sections, and then assigning these variables the appropriate values in the OnAfterGetRecord section of the report. I set them blank when not needed. I think it is possible, though I have not tried it, to overlay more than one field on top of another in the case of differing field sizes and formats. Then, only the non-blank of the two will print. I use text fields for numeric values, formatted appropriately, so that when I don't want them to print, I simply set the assignment to blank (null). This allows me to print zeroes when I want or blanks when I don't want to see zeroes for zero values
From what I gather, you may be doing this already but with the added effort of storing the values in the table first. If you can create the values on the fly (like totals), then my suggestion is to refrain from storing any temporary information in the table(s) since it's more difficult to maintain, causes more data to transfer on every SELECT * statement, and increases the size of your database unnecessarily. Of course, this is just my two cents.0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions