Erpnext: Gap analysis to reach german market requirements

[wojosc]

• [ ] Naming Series: It would be nice if all or the most common naming series like customer, quotation, sales order, sales invoice could be set via wizard/first run of ERPNext. Or have a once pre-defined set for german semi-standards (provided by community).

• [x] Numbers/Digits: In Germany we seperate the thousends with a dot and the decimal place as comma (instead of dot/point) eg 4.599,99 € https://discuss.erpnext.com/t/v12-1-6-decimals-in-currencies-not-working/53486/21

• [ ] Currency is either EUR 4.599,99 or 4.599,99 €

• [ ] Adresses are Street No, "second Adress line", Postalcode (5 digits or less), City. County is not commonly used.

• [ ] A standard print view following DIN 5008 (https://en.wikipedia.org/wiki/DIN_5008) work already in progress. https://github.com/frappe/erpnext/issues/19714

• [ ] Landline telephone numbers are still commonly used over mobile numbers.

• [ ] Adressing customers is more old fassion. We would start an E-Mail with "Dear Sir or Madam," or "Dear Mrs. Schmidt,"it would be nice if titles like Dr. Prof. etc. where optional.

• [ ] On quotations and invoices it is common to have subtotals at the end of the page. This subtotal is then carried forward on the next page (tax requirement)

• [ ] To meet tax requirements an invoice needs to be non-changable after submit. We have worked on a solution with Raffael https://github.com/tueit/pdf_on_submit

• [ ] There is a tax-related company which provides software for tax consultants called DATEV https://www.datev.com/. For ERPNext to have a realistic chance in the field of invoicing it is more or less mandetory to have some kind of implementation/interface/import-export function to this platform. This could be xml or something similar there is a thread on this also: https://discuss.erpnext.com/t/erpnext-datev-kompatibel-machen/44127/80 https://discuss.erpnext.com/t/german-chapter-datev-connector/42933
  https://github.com/frappe/erpnext/pull/18755

• [ ] There is coming feature which will be addressed in Europe called ZugFeRD. Implemting this could acctualy be paramount in the european market beeing a great chance for ERPNext to become a success. https://www.ferd-net.de/front_content.php?idcat=227&lang=4

• [ ] Integration to german banks would be very usefull
  https://discuss.erpnext.com/t/erpnext-fints-connector-german-banks/49155/11

• [ ] Some translations would be necesary for ease of use for non-it-affin personal https://discuss.erpnext.com/t/missing-translation-when-using-relink/43493/5

• [ ] Some minor translation issues here and there

[wojosc]

Numbers/Digits: In Germany we seperate the thousends with a dot and the decimal place as comma (instead of dot/point) eg 4.599,99 € https://discuss.erpnext.com/t/v12-1-6-decimals-in-currencies-not-working/53486/21

Seems to work now...

[barredterra]

Adresses are Street No, "second Adress line", Postalcode (5 digits or less), City. County is not commonly used.

https://github.com/frappe/erpnext/blob/develop/erpnext/regional/germany/address_template.html

[mariotruss]

@barredterra Is this in the core already?

[barredterra]

Yes!

I just added a fix: https://github.com/frappe/erpnext/pull/19828 , please let me know what you think.

[barredterra]

Minor issue: https://github.com/frappe/erpnext/issues/19855

[barredterra]

I created two pull requests to add the German CoA "SKR03":

• https://github.com/frappe/erpnext/pull/19845
• https://github.com/frappe/erpnext/pull/19856

Please upvote the one you like more and leave a comment why.

[barredterra]

Compliance to the GoBD, including this report, is a hard requirement in case any German company is supposed to do their accounting with ERPNext:

• https://docs.microsoft.com/en-us/dynamics365/finance/localizations/emea-deu-gdpdu-audit-data-export
• Specification (German)

[barredterra]

https://wiki.erpnext.org/display/ENG/German+Legal+Requirements

[crescent28]

@wojosc Create a discuss post for community to contribute for this kind of requirements.

[christf]

GoBD is fairly easy when used in combination with a git repository that was configured for the purpose (no history rewriting on the master branch, each change creates a commit that is pushed on submet). Conversions to pdf actually do not help.

[wojosc]

In v13 there will be an immutable ledger. I think this will cover most of the requirements. I suggest to wait for that befor we proceed any further.

[barredterra]

@christf you are legally required to keep the PDF you sent to a business partner, unless you are able to reproduce it exactly in the future. We cannot reproduce it exactly, so we have to keep it.