ベンダー
English

Expert Group on e-invoicing: a flop?

Create a vendor selection project
Click to express your interest in this report
Indication of coverage against your requirements
A subscription is required to activate this feature. Contact us for more info.
Celent have reviewed this profile and believe it to be accurate.
We are waiting for the vendor to publish their solution profile. Contact us or request the RFX.
Projects allow you to export Registered Vendor details and survey responses for analysis outside of Marsh CND. Please refer to the Marsh CND User Guide for detailed instructions.
Download Registered Vendor Survey responses as PDF
Contact vendor directly with specific questions (ie. pricing, capacity, etc)
2009/12/22

コメント

  • this "flop-story" is the smallest of minority views... the strongest support we did get was from Business Europe and DG Taxud... do I need to say more?

  • SME's may be interesting but they don't move large processes. Thats a fact. I would suggest (not my idea - it has been tried before) to concentrate on getting the large Multi-mnational corporations on-board like they attepted with Bolero.

    Also, politics are not bad if they drive the project forward. It is only if some parties want to disrupt the effort....

    If countries and vendors want to move things their way, that is why they are in the process. I wouldnt fear that.

    Keep us posted - great article

  • Thank you both for your strong and passionate comments.
    My intention when posting this piece was not to be negative on the activity performed by the Group. On the contrary, I think we all have to appreciate the time and dedication of experts who worked as volunteers.
    My point is more to uncover potential threats to the outcome of the Group's results. I.e., when I interact with corporate executives, bank representatives, and solution vendors, and listen to their concerns, I feel something must be fixed.
    Their perception is that in some parts there is lack of clarity and suspects of conflicts of interest. And, as I know by experience, perception is reality.
    Now, I cannot cliam that I represent the entirety of the players in this space, but I can claim I have a good perspective as an analyst, since our daily activity is to interact with clients who belong to each of the categories. My reccoemndation to the Expert Group is to carefully consider the reactive feedback from the users, avoiding a defensive approach, because what is in discussion is not the effort and contribution of the Expert Group, rather than clear guidance in some parts of the document. Moreover, I would say that the request for clear guidance proves the role of the Expert Group as a recognized authority in the field.

    As per the topic regarding the role of SMEs vs. large corporations, I do agree on the fact that success can be better driven by getting a few large MNCs onboard. The point, though, is that one of the most significant areas where guidance was expected, i.e., standards, is left open until the CII will be mature enough to be adopted. I expect the frequently asked question to be: what do we do in the meantime?
    That means, how can MNCs be influenced is the field is still left "unguarded"?

  • The impression is problems have been jumped not solved by the EG.

    Also there is not only an isolated "invoicing" problem.

    The trade world needs a consistent set of business documents... about 60 if I am not wrong...

    yes because the Invoice IS a trade document issued by the creditor (except the case of self-invoice), and this is not well understood by some finance people.

    Talking about the CII document, it incorporates all codelists, which is wrong as codelists and their taxonomies are updated independently and driven by the world business requirements that are moving so fast today.

    For instance the UN/Locode codelist includes all ports, inland ports, intermodal ports, so on... and what's happen if tomorrow a new inland port is coming up ? Maybe a volunteer will visit the UN/ECE site to update the codelist... but CEFACT will include their new port on the next 6 month version of their CII.
    Who can wait 6 months ?

    There are business cases more critical than a location... (do you remember the Turkish currency ???) and this explain why codelists cannot be constrained to a document or to a CEFACT "directory" version (e.g D09A)

    Actual taxation codelists could be not sufficient for all EU countries as there could be a lack of communication of such fiscal information to the codelist maintainers. That's is not a problem itself, we are many countries now... but we need codelists are decoupled from business documents. We need a strong policy to update EU codelists... no mention about these important things.

    Why important ??? The codelists are the last mile to the interoperability, it is not a case that OASIS has standardized Genericode for that purpose.

    But there are many other aspects the EG has never considered...

    About EG volunteers, I believe they get paid for this work with European money. But maybe I am wrong :)

    Thanks for starting this blog.

  • I also think "equal treatment" concept is at the same time dangerous and misunderstanding. And that the latin expresion "mutatis mutandi" should be used, because paper documents are essentially different from electronic documents, and each kind of documents must have its specific security measures.

    I don´t agree with keeping paper invoices without additional security measures, while electronic invoices are secured from the beginning with electronic signature, and this should´t be changed.

    By the way, UBL is mature enough to be used right now, while CII is not ready yet. I still don´t understand why the expert group suggest using CII instead of UBL. Everybody agree that both are based in Core Components, so it will be very easy in the future migrate from UBL to CII, but now only UBL is usable at all. Even more because of the agreement between OASIS and UN/CEFACT, CII will be a "future" version of UBL, so UBL could be managed as the actual version of CII.

    I know, this seems to be a buzzword, but in my opinion has been used politically.

  • Well, 1st of all CII is just an Invoice, so we should use the CEFACT/XML name instead.
    The main issue is many people has limited the choice to the only Invoice which is wrong.
    If we evaluate the actual CEFACT work we could be shocked because this XML effort is not eligible anymore to substitute the plain old EDIFact.

    Why ?
    Let's analyze the 195 EDIFact messages available into D09A... we will find useful information to understand what's happen:

    - eFinance messages are handled by ISO20022
    - Health is HL7
    - Trade - UBL 2.0 and UBL 2.1 are the realization of the actual trade world needs.
    - Customs - is WCO and they have a separate standardization channel
    - Utilities - UBL 2.1 has many things to say
    - Shipping & Transport - Transport is well handled by UBL 2.x, while Shipping is a specific industry that is slow to update (they still use EDIFact D93, D95B, D96A)
    - Recruitment messages - who knows
    - Insurance - who knows

    So, if you remove all business domains that are standardized outside CEFACT (for many reasons)... what we have in our hands ?

    Finally the question is:

    For which crazy reason UN/CEFACT has decided to ignore UN/ECE and MoU/MG of e-Business orientations directed to use UBL 2.0 as 1st valid stone for a global e-Business Standard ?

    CEFACT is today ignoring the "business" value of UBL, all business documents designed by experts around the work after a long standardization effort of about 10 years.

    This way CEFACT looses the opportunity to have 60 wanderful business messages and all UBL adopters.

    It seems to me that all of this is not logical, and clearly an error.

    Let's think about this.

    The main issue is the poor knowledge about e-Business efforts, unfortunately few people has a global vision on the whole Financial Supply Chain like you !

    Best regards

    Roberto Cisternino

  • My point is that the problem is more focused on the process of e-invoicing, and not in the XML "flavour" of the invoice. That's why I can't understand neither why not use and standarize UBL today, currently used even by several european countries, in order to empower the process, and to push forward the e-invoice.