For this reason to be able to produce filenames with the prior format of “Number - Recipient”, additional editing of the filename is required and also copying and pasting of the customer’s/recipient’s name.
The resulting procedure is much slower than the previous, making the process unnecessary tedious.
Changing the tab title to “Reference - Date - Recipient” would streamline this operation, and improving the resulting filename with the addition of “date”.
Manager is a web-server based app. In it’s heart a web-server is running that’s creating all pages of the program (desktop version included).
Every page created, get’s a “page title” that is controlled 100% by Manager’s code. I repeat 100%, not even 1% below that.
Then user’s browser, uses that title to generate the auto-filled filename for PDF export. Believe me it’s 100% doable, and a time saving feature for every day use.
The way I posted this topic, is meant to be for the developer. The usual user, would have asked for a “better filename proposition when exporting”, but instead in an effort to facilitate the development, I took the extra mile, found the solution for the problem and explained it.
So now, I 'm changing the title to reflect the typical user.
I agree that filenames of PDFs that those not wanting to use the legacy PDF generator should be much more intuitive. However, I disagree that date should be part of a filename. Each file has a creation date embedded in it and you can always sort on these files in the folder of whatever main operating system you use. Also dates appear when opening files such as receipts, etc.
Thanks @lubos, there is unfortunately a problem. Many of the imported bank statements do not have reference numbers. So when trying the new print to PDF for a payment it provides “OUR COMPANY NAME” — Payment — 0 — View.pdf as filename.
Indeed, the internal pdf generator is even worse as it would just name the same Payment 0.pdf. The difference is that we would only create PDFs when sending emails and therefore use the legacy pdf generator as it is much more convenient to use.The description with { fields } that we included in the email template has all the details needed to explain what the attachment is about and therefore less of an issue than downloading several pdf files via print that all have exactly the same file name but totally different content.
In the case of print to pdf, you first will need to open such pdf to know to whom to email it and also to copy over some description in the email body that explains what is attached. With so many identical file names and the lack of being able to automatically include content from the attachments into the email this is too cumbersome and one more reason why pdf generation as part of Manager should not even be a legacy product but one that needs fixing or being restricted to fixed templates where only some theming such as logo and colours could be changed.
Are you using the “Print” Button or the “PDF” one?
From the photos it seems that you are using the “PDF”. The point of the post is that you should get the same outcome when you press “print” and then save to PDF from the printer menu…
I haven’tposted any photow because I have the same outcome as the first photo. version 22.1.11
@lubos, it seems that on my server edition, the problem is fixed. The page title changes, when I am pressing print. But on desktop edition this isn’t happening. I guess that’s why you wrote improved.
Is there a way to improve the file name. When I print say a quote, I get this
Dalacor — Sales Quote — 476 — View.
I would prefer to have what the pdf inbuilt printer had which was
Quote 476 - Client Name.
When you are doing multiple quotes for different clients, one wants to have the quote number and client name. My company name and View is irrelevant.
I do realise that Manager is getting the name from the Tab name and breadcrumb name. Perhaps if Manager was updated to include the client name in the breadcrumb name and the print dialog removed the dashes then it would work more like the old inbuilt pdf printer as that naming format is much better.
@Wornout, if you go back to the beginning of this thread, you will see that the issue discussed was never about all file names being the same. It was about what information to show. If all your PDFs have the same filename, that implies you are not using reference numbers. It also implies you are eliminating dates that are automatically appended to filenames, and that you must be deleting transaction type names, too.
Can you provide a screen shot of a directory with several Manager-generated PDF files? It seems very implausible that the program is producing what you describe.
so now they save with the invoice number but with my name not the company/Person who is on the manager file
these were sales invoices to 3 different companies
This is what I was asking if there was an update on
“Front Desk 2018 (2021-01-02) (2021-11-09)” looks like the name of the Manager business file to me. You can rename the business file to something more appropriate which will then change the default pdf file name.
I suspect what you would like is the customer name to be included not just the invoice number and date.
@Wornout post 14 by @dalacor explains in full what the differences are including the source of the difference. However there is an additional important difference:
The PDF generator does not prompt for a filename and automatically saves it to the browsers’ download default folder. The filename convention was decided by the developer and some may prefer while others would like it.
The Print function always prompts for filename and folder location and as such you can give it any name you like and place in any folder. This makes the file-management much easier on your system. Yes it would take a bit of time to give the file a name and select a folder but you can organize the folders any way you like and much easier find whatever you need.
I still prefer and use the internal PDF generator as it allows us emailing invoices, receipts, reports, etc directly from Manager to suppliers, customers, tax accountant, etc. I think that the Print-to indeed shifts the issue of PDF generation from Manager application to your own system and thus makes life easier for @lubos but it is in my view an enormous set-back to no longer have it as it rapidly moved from the more elegant Legacy feature to Obsolete feature. In essence it is not obsolete for us as users because it is used and preferred over the clumsy workflow needed when using print-to where you have to save a file, attach it to an email where you have to enter any details that you would now include in the email template. Much more work for us but admittedly much less headache for the developer.
