DIN 5008 Print Format

[wojosc]

Is your feature request related to a problem? Please describe. Standard Print Formats in ERPNext are not suitable for German market as some requirements are not sufficient. As a lot of invoices are still sent via paper in an envelope so we need the address to be visible in the envelopes windows. This is a country wide standard in A4 with certain boarder sizes etc. I noticed that using "print" in ERPNext and using PDF->Print make two different things. These should be synchronized.

Describe the solution you'd like I'm looking forward to a standard business letter format following DIN 5008 https://de.wikipedia.org/wiki/DIN_5008 .It would be great if I where to able to use the drag & drop feature you have implemented in Print Format, though we would not need the description. The customer name will do, a description like "customer" set in front of the customers name is not necessary. In the German version you will also find the right mesurements https://de.wikipedia.org/wiki/DIN_5008

Describe alternatives you've considered We have had a custom made solution by @barredterra but he had trouble getting the right format into the system. It did some how work, but the regular print view was completely different to the one we see when generating the PDF.

Additional context Furthermore especially on invoices it is recommended to have a subtotal at the end of the page which is carried forward to the next page.

The final touch: Also it is sufficient to have the company logo printed only on the first page. Many customers will even go so far to have pre-printed paper with their company logo and footer containing information like phone, address, website etc...

Here are some references: https://rechnungen-muster.de/rechnungsvorlagen

[wojosc]

Please add Label "regional", "accounting", "DIN"

[barredterra]

This is the specification (Form B):

What we have so far:

CSS

Previously, all mm values from the specification had to be multiplied by 1.29 to match wkhtmltopdf's resolution. This is not necessary anymore with frappe 12.0.20 and wkhtmltopdf 0.12.5 (with patched qt).

#header {
    text-align: right;
    width: 100%;
    /* ( 45 mm - 10 mm margin ) */
    height: 35mm;
    /* Overwrite empty header inserted by frappe */
    margin-top: -10mm;
    overflow: hidden;
    padding-left: 32.25mm;
    padding-right: 25.8mm;
    position: relative;
}

#sender {
    position: relative;
    font-size: 75%;
    height: 17.7mm;
}

#sender p {
    position: absolute;
    bottom: 0;
}

#address {
    float: left;
    width: 85mm;
    padding-left: 5mm;
    margin-left: 20mm;
    height: 45mm;
    overflow: hidden;
}

#contact {
    width: 75mm;
    height: 40mm;
    overflow: hidden;
    margin-top: 5mm;
    margin-left: 20mm;
}

#contact>table {
    float: right;
    width: 100%;
}

#subject {
    margin-bottom: 2em;
    height: 5mm;
    font-weight: bold;
}

#faltmarke-1 {
    position: absolute;
    /* ( 105 mm - 10 mm margin ) */
    top: 95mm;
}

#lochmarke {
    position: absolute;
    /* ( 148.5 mm - 10 mm margin ) */
    top: 138.5mm;
}

#faltmarke-2 {
    position: absolute;
    /* ( 210 mm - 10 mm margin ) */
    top: 200mm;
}

#text {
    margin-top: 8.46mm;
    margin-left: 25mm;
    margin-right: 20mm;
}

#contact td {
    padding: 1.5px !important;
}

.text-right {
    text-align: right;
}

/* --- Nice page breaks for tables --- */
table {
    page-break-inside: auto
}

tr {
    page-break-inside: avoid;
    page-break-after: auto
}

thead {
    display: table-header-group
}

tfoot {
    display: table-footer-group
}
/* ---------------------------------- */

/* ------------- Footer ------------- */
#pagenum {
    text-align: right;
    margin-right: 20mm;
    margin-top: 4.23mm;
    margin-bottom: 4.23mm;
}

.footer-table>tbody>tr>td:not(:last-child) {
    padding: 0 30px 0 0 !important;

}

.footer-table>tbody>tr>td:last-child {
    padding: 0 !important;
}

.footer-table {
    font-size: 10pt;
    margin-left: 25mm;
    padding-right: 20mm;
}
/* ---------------------------------- */

HTML Skeleton

<style>
    .print-format {
        margin-left: 0mm;
        margin-right: 0mm;
        margin-top: 10mm;
        margin-bottom: 55mm;
        font-size: 12pt;
    }
</style>

<div id="header">
    {{ letter_head }}
</div>

<div id="faltmarke-1">-</div>
<div id="lochmarke">-</div>
<div id="faltmarke-2">-</div>

<div id="address">
    <div id="sender">
        <!-- Company Address -->
    </div>
    <!-- Customer Address -->
</div>

<div id="contact">
    <table>
        <tr>
            <td>{{ _("Our Sign") }}:</td>
            <td class="text-right">{{ doc.name }}</td>
        </tr>
        <!-- Contact Information -->
        <!-- Date -->
</div>

<!-- CONTENT -->
<div id="text">
    <div id="subject">
        <!-- Subject / Heading -->
    </div>
        <!-- Greeting Text -->

        <!-- 

        Document Data 

        -->
</div>

<div id="footer-html" class="visible-pdf">
    <p id="pagenum">
        {{ _("Page {0} of {1}").format('<span class="page"></span>', '<span class="topage"></span>') }}
    </p>
    {{ footer }}
</div>

[wojosc]

is it clear to when A or B is used?

[barredterra]

I think that's a question of preference. Form B has more space for the header. In Form A that space would be available for the info block on the right or for then content.

A distinction is made between Form A with a raised address field (32 mm below the top edge of the page) and Form B with a lower address field (50 mm below the top edge of the page).

[wojosc]

Thank you. Seems unimportant in the first step I guess.

[barredterra]

The mm values from the specification are multiplied by 1.29 to match wkhtmltopdf's resolution.

I just noticed that this is not necessary anymore. (Frappe 12.0.20, wkhtmltopdf 0.12.5 (with patched qt))

[asbasawaraj]

@wojosc do you know any apps which can print in DIN 5008 format? Weclap maybe? I found this https://www.weclapp.com/de/geschaeftsbrief-vorlage/

[wojosc]

@asbasawaraj

I'm not sure what you mean here. The Format of the print is A4 and should be able to be printed from any App. The DIN 5008 Geschäftsbrief ist just the spacing etc. on the page.

What information can I deliver to answer your question?

[asbasawaraj]

I mean is there any software that can print invoices in DIN format? I would like to take a look.

[wojosc]

I don't really know of any. Those templates you found on weclapp look pretty good though. Those .doc/.docx/.pdf should work...

[asbasawaraj]

@surajshetty3416

• [ ] Sync Print Preview and PDF
• [ ] Jinja template as layout as shown above by @barredterra
• [ ] Subtotal at the end of each page

We need to estimate the development hours needed for each of the above activities.

cc: @wojosc can we focus on these three first?

[wojosc]

yes, good idea. You might remember, that I talked about "the original PDF" for accounting regularities. @barredterra had created an app for us in which you could choose which DocTypes should have this feature. All the app would do is create a PDF on submission of a DocType and attach it to the DocType. https://github.com/alyf-de/pdf_on_submit maybe this is also relevent for your first check-box?!

[asbasawaraj]

@wojosc Yes, I remember that feature discussion. Can you please share some documents which say that once an invoice is generated it should be stored in unchangeable formats. Because generating the PDF and attaching is a simple thing but it doesn't achieve anything as a user can simply delete the attachment and change values and attach the PDF again. I would like explore alternative options.

[wojosc]

it has to be clear for the tax office when and where an invoice was created. More on this you'll find in https://www.billomat.com/magazin/muss-ich-meine-rechnungen-ausdrucken-wenn-ich-sie-online-schreibe/#anker1 (not sure if google translate will do the job; by the way, that's the software that was used by seibert) Of course it is always possible to change something with a certain amount of effort. As you can delete and recreate invoices as admin in ERPNext this is also not given. But it would be tracable in some way.

The "Attach PDF on Submit" will do fine to meet legal requirements. Even the attachment in the e-mail (as already implemented) would do fine if it can be found quickly. It can be cumbersome when looking for the invoice you have sent in ERPNext when this has for example been printed on paper as it does not show it this has been done or which print view has been used.

[asbasawaraj]

Update: I had a discussion with @scmmishra and @netchampfaris about syncing PDF preview and the actual PDF generated. We use wkhtmltopdf library to generate PDF. It is better to consider alternative approaches or libraries than fixing this specific issue as many other issues exist with wkhtmltopdf.

One alternative is to use a library called puppeteer.

@wojosc will update here as soon as we make final decision about wkhtmltopdf vs puppeteer.

More technical details as shared by Shivam on Telegram. 'We can install headless chrome on the servers It runs without the GUI on servers And use a library called pupeeter to communicate with chrome Then we can just send a command to chrome and ask it to print the page'

[wojosc]

Hi Basaw, that sounds interesting and a little dangerous? Will that be a major change to the system changing the way prints come out of the system completely? It sounds a little like it.

My technical knowledge is not broad enough to be able to make a comment here.

Best

[wojosc]

@MarioMeetsWorld which step do you consider "printing the pdf"?

[mariotruss]

I mixed up things, sorry for the confusion. What I meant is that A4 is system-wide setting. Meaning, all documents will be printed either in A4 or in Letter Format. Actually, there should be a way to choose the size for different documents or customers. This means, a German Customer gets an Invoice in A4, whereas a English Customer will receive it in Letter Format. This must be variable. Anyway, this does not contribute to this story.

[barredterra]

Actually, there should be a way to choose the size for different documents or customers.

This would be covered by locales: https://github.com/frappe/frappe/issues/9001

[wojosc]

Hi @dottenbr how did you solve this in your case? Care to share?

[wojosc]

Hey @asbasawaraj we use the following platform for creating manuals. They have an export to PDF funktion. Maybe that is sufficient. Sorry, that I didn't did for the actual part of code...

https://github.com/BookStackApp/BookStack

[dottenbr]

We don’t follow DIN 5008 strictly but we have adapted all print formats to follow “form B” as closely as possible. With that we only care about the PDF export and not about the preview.

[wojosc]

We don’t follow DIN 5008 strictly but we have adapted all print formats to follow “form B” as closely as possible. With that we only care about the PDF export and not about the preview.

How difficult would that be to implement.

For my part I can't really see the necessity for the preview as I an quickly generate and open the one PDF. I can't think of a case where this "redundancy" would be needed.

[dottenbr]

The current design is just such that you always get the preview and from that you could print. There are always slight formatting and font size differences which has to do with wkhtmltopdf. We are happy with our solution but it was honestly just minor tweaking of font sizes, margins, etc.

[wojosc]

@dottenbr is this something you can share in any reasonable way. I have been talking to @asbasawaraj about this, he will make a quote on this. Maybe his work could be speeded up thorugh your contribution. Thanks!

[mariotruss]

For my part I can't really see the necessity for the preview as I an quickly generate and open the one PDF. I can't think of a case where this "redundancy" would be needed.

I think it's somehow important to have an instant preview of the document, without the need to open a separate tab or pdf viewer. Also the language and the layout can be selected there. Frappe has decided to go with the preview. There could have been other approaches for a "preview" implementation, but leaving it out completely would be a just be a workaround and decrease UX in my opinion.

[MSc00001]

Wie integriere ich den html und css style? Ich habe unter Einstellungen -> Briefkopf den HTML-Code eingefügt und als Standard gesetzt. Unter Druckstil den css und ebenfalls Standard. Dennoch sehen meine Rechnungen nicht nach DIN5008 aus :-/

EDIT: ERPnext v12

[barredterra]

Ein neues Druckformat erstellen und dort HTML und CSS einfügen.

[MSc00001]

there is only a custom css field. And it just seems to apply to one type of document.

And is hasent any effect for the invoice.

Is this the right place for a discussion like that or is there a better place (a forum or something like that...)

Thanks

[barredterra]

@MSc00001 please create a new post on https://discuss.erpnext.com and let's discuss this there. You can tag me (@rmeyer) there. GitHub is for fixing bugs and developing features, not for Q&A.

[barredterra]

We have shared our solution at https://github.com/alyf-de/erpnext_druckformate .

the regular print view was completely different to the one we see when generating the PDF

Preview works fine with the above.

[harshit-30]

Kindly create a new issue if the said feature/request/enhancement is not yet included after v13.10.