Invoice Layout - Disable showing customer code in PDF/Print

Similar to my earlier post about invoice layout (Different Invoice Layout in Preview, Print, PDF), I now bumped into another issue that I assume is easily fixed.

I have started to use Customer Codes for internal purposes. This field is identified as “recipient.code”. If empty, nothing shows in entry/edit mode, nor in preview/print/pdf. Now that I have added codes, suddenly, it is shown directly behind the Customer Name (“recipient.name”) field.

This is the standard layout code for the customer contact area:

                    <div><b>{{ recipient.name }}</b> {{ recipient.code }}</div>
                    <div>{{ recipient.address | newline_to_br }}</div>
                    <div>{{ recipient.identifier }}</div>

Which I simply changed to:

                    <div><b>{{ recipient.name }}</b></div>
                    <div><br>&nbsp;</div>
                    <div>{{ recipient.address | newline_to_br }}</div>
                    <div><br>&nbsp;</div>
                    <div>{{ recipient.identifier | newline_to_br }}</div>

NB: this includes my bit of code to force a line break, as explained in the other post.

As you can see, I removed the “{{ recipient.code }}” bit, but the inclusion is persistent and removing this will not prevent the customer code to appear in the entry/edit mode. It will also not prevent the customer code field from showing on the print and in the PDF.

I do not want this code to appear anywhere.

How can I make sure that the Customer Code (recipient.code) field is really removed from the layout?

you seem to have modified the theme.
if yes, then have you selected the modified theme for your transactions?
read the last part of this guide https://guides.manager.io/10366

it should be noted that themes will only change the appearance of your final document and not the form itself.

Update:

The layout template chosen was a modified “plain” theme. In an earlier version of Manager, there was no option checkbox to select a per instance modified theme, but a default modified one was chosen. Hence: all invoices made in the past stick to that layout, while new invoices allow to override per instance with any available theme/layout.

I am now going to copy and paste the modified plain theme into a new “version 2” of the original layout and play around with the possibilities. I suspect that the new method allows easier replacement and adjustment.

Removal of customer codes is covered by the last subsection in this Guide: https://guides.manager.io/7716.

As for selection of themes, your statements were a little confusing. To be clear:

  • You can set a default theme for every transaction type under Form Defaults.
  • Regardless of what theme has or has not been set as a default, any transaction’s theme can be edited on a case by case basis.
  • Themes on existing transactions are not affected by changes to default themes. These are effectively only on new transactions.

@Tut:

Agreed. I was looking at it from my perspective, using the existing invoices. New invoices made with the later version have the option to change per instance, whereas earlier, I chose once and used one and the same layout always.

I did not use the form defaults, since I was accustomed to one layout being used at all instances. Moreover, using the form defaults I had to select a customer, which, to me, was unclear as to whether I would have to select a theme per customer, or that it would serve as a general approach to always selecting the same theme.

As we often clone existing invoices, the question then becomes if these will be according to the earlier attached layout/theme, or according to a new layout/theme.

@sharpdrivetek:

To me, as an average skilled user, it would be expected to see the form itself as one and the same, whether as mail, as PDF or as print. The app GUI can be anything and must not mirror the exact same layout. As long as it shows the same information that is being used, it is OK.

The same is true now, but you now have the ability to set different themes for different transaction types. So sales invoices can use one theme, while delivery notes use another. In both cases, though, old transactions stay in the theme selected for them. New ones adopt any theme set for them.

That behavior was done away with shortly after Form Defaults were introduced. If your version is still requiring that, update your software. And if you read the former version of the relevant Guide, it told you to select a customer/supplier in order to set other form fields, then delete the customer/supplier.

No. Theme defaults are by transaction type.

Read the Guide: Manager Cloud. See especially the final section.

This does not happen, because different PDF generators and browsers behave differently, even when rendering the same HTML. This fact has nothing to do with Manager itself. When you click the PDF button, you are using Manager’s internal PDF generator. When you look at something on screen, you are seeing the result of a browser. When you click Print, you get the result of your printer driver. If your operating system allows a “print to PDF” function, you are getting the operating system’s PDF generator. The same thing happens with any program, web site, etc. Word processing documents do not always print identically on different printers or render the same when converted to PDF. And when you print from your browser, you seldom get exactly what you were seeing on screen.

@Tut:

Thanks for the explanation. That is obvious. But, within that given, I expect that the code of the theme layout at least is similar and is reflected in the result. And this does seem the case. So, I stand corrected. But since I was looking at a difference between versions and the (correct) method of keeping existing layouts as they were before a change of theme, it did not show. The checkbox for layout override is now present, but I was unaware of it.

Thanks for your time and help.

Be aware that you may need different themes to produce approximately similar results when using PDF versus Print. For example, due to the vagaries of my printer driver, I have themes with different margin paddings to achieve the same printed margin, depending on whether printing a PDF or printing directly with the operating system’s internal capabilities.

I say approximately similar because Manager’s internal PDF generator substitutes Google’s Noto font when generating a PDF, probably not what your browser was using. This is required to support the 70 languages Manager is translated into. So no matter what you see on the screen, you may experience font substitution.