ZUGFeRD and ERPNext

ERPNext Feature Requests
1

Dear all,

we come accross ZUGFeRD as a carrier for electronic invoices more and more often. It seems that this is a trend in Western Europe. The technology is quite handy: you simply take a PDF-invoice, add the electronic invoice XML to it and send it to your customer. The customer in turn loads this into his ERP(Next) and automatically processes it.

Now, there seems to be a Python package that closes the gap to what ERPNext already has: factur-x · PyPI

It seems that also other ERP systems are looking into this (e.g. o…). Has anyone else come accross this? Is there other interest? We would be open to partner in the development of this… What we would need in my opinion would be from Sales Invoice → Create ZUGFeRD invoice (output is a pdf with xml content) and from the customer → import ZUGFeRD invoice (the output is a new purchase invoice).

4 Likes
2

This is something we will be looking at soon, yes.

3

Why don’t we just attach the xml to any invoice that gets created? :thinking:

4

makes perfect sense if you ask me.

As you have already created the “PDF on Submit” you might as well just ad an “XML on Submit” which can also be attached in an e-mail?!

5

Sounds doable :+1:

6

Hi @wojosc and @rmeyer,

thanks for your feedback and input on this. We currently have a working prototype based on the work from factur-x (GitHub - akretion/factur-x: Python lib for Factur-X, the e-invoicing standard for France and Germany). It would absolutely make sense to include this with all Sales Invoices, and certainly help to promote the technolgy. It is also important to add some sort of visible not to the invoice print format so that the receiver knows that it can be processed. I will share a link to the sources/app as soon as it reaches a somewhat stable state…

Can we hook the standard pdf-generation with additional code conditionally, i.e. only for Sales Invoices?

1 Like
7

So far we have built a modul in which you can choose the DocTypes on which a PDF should be created. For now we have

  • Invoice
  • Quotation
  • Sales Order
  • Delivery Note
8

That’s what we’re doing in the app. For a real integration, we would need to modify frappe.utils.pdf.get_pdf().

9

I have seen a certain mode of development from your side in the past at least in one example

  1. creating a custom App
  2. getting community members for beta testing/feedback/cooperation
  3. merging the Custom App into your own erpnext fork
  4. abandonment of the Custom App

can you kindly clarify whether this initiative has the same or similar fate ahead or would you commit to work this into the core ERPNext code this time for the benefit of everyone participating in the development in one way or the other?

10

Hi @rmeyer,
thanks for sharing!

11

Hi @vrms,

thanks for your input. While I think

might not really be justified, let me elaborate: we had started the fullsize as a proof-of-concept app. Many people liked it, others, mainly from the core maintainers, did not like it. Maintaining it separately made little sense, so we moved it into our larger app (actually the same as moving it to the core, but there was no interest). Please note that ERPNextSwiss is in no way a fork, but actually an additional app for ERPNext. It extends a variety of functionalities, amongst them the fullsize view. You are always free to use the code from the original app wherever you like, we stick to a full open source policy.

As to the ZUGFeRD initiative, as you can see, I have asked for feedback last October. There was actually no feedback, so I have to conclude there was no interest until - started by a different thread - interest arose last week. I strongly believe that ZUGFeRD will be a game changer in Western Europe, and ERPNext will profit from having this capability. If this is from an additional app or in the core seems secondary to me. Seeing it in the core would certainly be nice and desirable, however, I have no impact on that. But again I assure you that the work done on this will be provided on an open source basis to the public.

Another two thoughts on the app strategy:

  • having a separate app for each feature would be moving towards a plug-in model. According to the ERPNext-chosen approach of the monolith, it seems preferable to have few, well optimised apps. This also has a positive impact on the maintenance efforts.
  • release cycles: we have no impact on the core releases. Yet, on features which are used by our enterprise customers (especially in the beginning when code might still be subject to issues, like ZUGFeRD will be at the start), we need to be able to push fixes quickly. Therefore, an individual app does appear to be the optimal way.

Let me also note here that we are indeed supporting the ERPNext community in various ways - financially, by active contribution in the forum, bug reports and pull requests and last but not least in promoting the product in the local markets.

So in short, your participation would be highly appreciated and we will make sure that this is available to the public. If you feel that merging of some apps or app strategy is unjustified, please always feel free to PM me!

1 Like
12

alright. Actually my general understanding was not correct then. Likewise my point kind of looses it’s base. Apologies for the too lush investigation into the matter. Sorry, my bad.

hm, I would not quite read this thread as “no interest from the core team”

your argumentation on that request for not merging to the core was, if I recall it corectly “erpnextswiss is a localization likewise it makes no sense to move it to the core”.

As there is a particular folder for localizations in the core this sounded a bit like a proforma argumentation (and given the basic idea you where maintaining a fork, lead to a bit of biased perception on my end.

13

Hi @vrms,

thanks for your feedback. Sorry to differentiate again, but the quoted merge request was regarding the full ERPNextSwiss app, which contains localisations (Lohnausweis, VAT declaration, …), but also the bank integration/ISO 20022 and many other things, among them FullSize. For the integration for FullSize there was no interest. On as to not merging the full app, the key point is the responsibility towards our customers, at that point it still seems preferable to be in control of the release cycles - especially when it comes to bank interaction, assume we cannot push a critical fix in short time this may lead to customers not being able to process payment, which is a risk we cannot accept. We have seen this on occasions where we had PRed security fixed e.g. for nginx config.

But that is more about the app strategy. I think you will agree that we do share all codes and have them available for everyone to use. Which, going back to the initial point, is that we consider ZUGFeRD a valuable addition to ERPNext and will push its implementation, first in the mentioned app. If this can be merged at a later stage (as of now, features will only be accepted into v12, yet we would like to have this available for v10 and v11 as well) should be decided by the core team, and we shall be happy to support this.

14

alright, thanks for clarifying.

I agree that there at times may occur discrepancies of what the core team (by design mainly committed to provide value to users of the epnext.com offering) may not always go 100% in parallel what other players in the Community may want to see as features.

Finding a way to handle this potential or even already existing conflict may even be a question for us all to solve in the future.

15

My experience in getting customizations into the core has been similar to that of the erpnextswiss team. The difference is that I did NOT have the time a resources to go back and have my developers recreate that same functions as a separate app. The work had already been done as if it would be included in the core and the PR’s were created in that fashion. The core developers disagreed with the basis of much of my alterations and rejected most of them. A select few made it into the core. I still used my development work for my clients and didn’t push the issue any further.

Again, there is no fanfare or other announcements when PR’s are made and very little if anything is done to recognize contributions that make it into the core (and I agree that it probably should stay that way!) So, much of the time there is only a single line response in your github thread that indicates the ‘use case’ did not meet the requirements to be included and that is it. The process “is what it is” and as long as we are going to keep moving the ball forward I am not sure how one could (or should) change that.

So, I think it is probably unfair to go after someone that tries to get traction for some code they are working to promote, but if nothing happens in a short period of time, they really have to be able to walk away and just use it for themselves or a select few that want to aid in the process. Otherwise they get stuck in a place that prevents them from continuing to advance forward.

So, to your statement that finding a way to handle these conflicting interests is really the correct approach (IMHO). Not necessarily the easiest thing to figure out, but the right approach.

BTW… I like the idea in the ZUGFeRD use cases. It is not popular here in the USA yet, but if it does gain ground here I will certainly be looking at it as a custom app.

BKM

2 Likes
16

Short update on this topic, we have now rolled out ZUGFeRD invoice creation with the current ERPNextSwiss release (we are using the EN16931 standard). It will automatically create a ZUGFeRD content for each PDF of a Sales Invoice that is being created (note: this requires two changes in Frappe to get it working, refer to the corresponding source codes).

We are currently testing this in productive environments, so far it seems to work very well.

At the same time we are working on the Purchase Invoice parser to go with it.

17

Good job @lasalesi,

FYI as at today your woocommerce 2way integration at Woocommerce full 2 way integration - #140 by zerodiscount is yet to work for anyone, and a lot of people have tried. Some have even reached out to you to pay to make this work, to no response or success.

The only reason we all still keep on is because you claim it works for you.

What will it take @lasalesi? What will it take? Lots of us have wasted hours on this

18

Hi @olamide_shodunke,

thanks for your feedback.

Your mentioned link is however on a different topic (WooCommerce integration has no overlap with ZUGFeRD)… Please do let me know how I can help you with your issue. Looking at how often the WooCommerceConnector is being installed, I guess there are others as well who got it working. But that should be no excuse not to help you as well!

19

I am stating it here because it is difficult to get your attention.

And no one is making that app work. We are all downloading it because we believe you when you say it works.

Please if you want to help respond to request on the woocommerce topic thread.

I repeat we have almost a dozen people on that thread trying to make it work, no one has succeeded. @EnSeal can confirm this. they are even talking to each other off line and still are not able to make this app work

Thank you

20

Thanks for your message. Again, this is off-topic in this thread. Feel free to PM me if you feel that you are not getting the attention that you need.