Documentation required about edi HOT 8 CLOSED

@bealdav some clarification:

edi framework seems an abstract [...]

Is not "abstract", is quite "concrete" actually. It's generic enough so that you can plug it with any existing or new EDI/non-EDI exchanges.

Of course it makes more sense for interchanging data with third parties and keep track of these exchanges.

THE solution of the future for any kind of exchange

It's for the present as well ;)

more ready to go

It is ready, you just have to know how to use it and understand the main concepts and low level behaviors. I'd say like 80/90% of the modules out there probably but in this case there is some more complex stuff.

That's my fault, of course, since I couldn't find the time yet to write some good docs. 😓

@john-herholz-dt thanks for your feedback 🙏

Is there anything planned for a great refactoring or re-organisation of this repository? I would like to contribute.

I'd like to split framework modules out. However, this won't help solving your problem.

My biggest headache with the EDI framework right now is - it is not telling when what happens how.
For example: Setup Exchange Type and the exchange record will get create, generated, validated and send.

This is up to your implementation. We cannot decide when you want to produce or process a file.
If you think you need some training, feel free to contact me at simone.orsi <at> camptocamp.com

So improving the Usability on the exchange type would be much better.
More dropdowns, less code fields or text fields.

If you have any proposal to improve the UI, feel free to open a PR or an issue as RFC 😉

Finally, please remember that being a "framework" it tries to not make any business logic decision and leaves to the specific modules (eg: edi_sale* or edi_purchase*) the implementation of the logic or a basic configuration.

Maybe - when time allows - we can organize a sprint to work all together on specific subjects.
Meanwhile we can create a shared doc or use discussions on the new repo for the framework to find out what are the most rated pain points and/or improvements we can work on.

My $0.02 😉

from edi.

@johnny-longneck thanks for reaching out and raising the problem.
Docs are one of my ROADMAP targets, at least for the EDI framework.
Unfortunately I'm too busy right now to work on this.

If you are in a hurry, please send me an email at simone.orsi <at> camptocamp.com.
If not, can you please list here your requirements?
If you can, write them as a use case from top to bottom and I'll try to reply w/ as much details as possible.
If this works, then you can take care of adding a piece of documentation 😉

From what I see in your description you need to send PO UBL over FTP.
You'll need this #669 (WIP) + edi_storage_oca + a bit of configuration.

from edi.

Hey @simahawk thanks for your reply.
That's a deal that I could add documentation - once I know how it works.

For now our special use case is:

Suppliers mostly don't support UBL format and we work with them via XML exchanges.

As a seller I want to send an partner specific XML document with the purchase information to the seller via SFTP on purchase order action "send via E-Mail" (Note: on confirmation is too late, since we need to check their reply)

Later I will also need to send custom template documents (txt files, xml files) for stock.picking to our delivery partners.

As of now: I cannot get anything added to the Job Queue | Exchange list.
(Probably it does not work with out custom component, right)

from edi.

In #669 you have a good example on how to achieve it.
The only difference would be that your "generate" method of the output component won't generate UBL but something else.
Tip: copy edi_purchase_ubl_oca from that PR, rename after your project, adapt the component and the exchange type.
For the storage, install edi_storage_oca and configure a storage on the edi backend.
In theory you don't need to configure anything on the exchange type because the storage will be used automatically.

from edi.

Hi @johnny-longneck edi framework seems an abstract and generic way to build exchange, problably THE solution of the future for any kind of exchange.
If you only want to deal with exchange of files (no web services) an alternative and more ready to go could be

https://github.com/OCA/server-tools/tree/14.0/attachment_synchronize
https://github.com/OCA/server-tools/tree/14.0/attachment_queue

my 2 cts

from edi.

Hey @simahawk ,
I started working on our company's EDI project and started with migrations of base modules from this repo.

I was hoping for a centralized way to handle EDI but as far as I investigate the modules, it seems, it is totally loose.
At the moment I cannot get anything to create a simple file in the exchange tree view for me.

As I look into the modules it seems invoice creation and sending is done via button, but not in the exchange list of the EDI backend? Sale Order UBL is also just embedding the reports with UBL XML (which is great but not what I am looking for)
...and so on.

Can you please please please give me the most basic example how to setup the EDI Framework to:
Auto generate a record, let's say purchase order, on purchase order action_confirm.
The generated record should be visible in the exchange record tree view
Explain how the transmission is triggered.

Also: is there any module example already where an input record of an exchange is validated and imported?
If I cannot get this running, I will end up with my own implmentation but I was really hoping for a community based EDI solution for Odoo.

Kind regards,
John

from edi.

Hi @john-herholz-dt Let me try to show you an example 😄

As an example I will use l10n_es_facturae the electronic spanish invoice send to state customers using a platform called FACe:

https://github.com/OCA/l10n-spain/tree/14.0/l10n_es_facturae_face/

We generate the EDI record when we post the invoice. It is notified using a listener:

https://github.com/OCA/l10n-spain/blob/14.0/l10n_es_facturae_face/components/account_move_l10n_es_facturae_listener.py#L22

The hook to execute it was defined here:
https://github.com/OCA/edi/blob/14.0/edi_account_oca/models/account_move.py#L21

As you can see, the listener checks if the move is from a customer that needs this sending and then generates the record here.
https://github.com/OCA/l10n-spain/blob/14.0/l10n_es_facturae_face/components/account_move_l10n_es_facturae_listener.py#L38-L40

In this example, the electronic invoice is generated automatically in the same line (but not sent)

The file is generated using a template (https://github.com/OCA/l10n-spain/blob/14.0/l10n_es_facturae_face/data/edi_output.xml#L3-L12) But it could be done using a component (as we had on 13.0) https://github.com/OCA/l10n-spain/blob/13.0/l10n_es_facturae_face/components/edi_output_l10n_es_facturae.py#L8-L15

Later, when edi cron is executed, it will proceed with the send. In this case, it is using a strange webservice, so the sending is done with another component. https://github.com/OCA/l10n-spain/blob/14.0/l10n_es_facturae_face/components/edi_send_l10n_es_facturae_face.py#L18
We could have proceeded with the automatic generation, but we usually leave it to the cron in order to avoid a block for the user. Also, if we use an standard sending like sftp or something like that, we can avoid to do it using edi_storage

So, this is an example of how EDI works to send data. Do you need the reception too? An example for that could be https://github.com/OCA/server-ux/tree/14.0/document_quick_access_folder_auto_classification

from edi.

Hi @etobella ,
this was extremely helpful!

I just wonder why the basic modules implement the events but not the listeners.
The flexible nature for components is a great idea but the motivation "Make it simple for non-developers" completely fails at the moment.

Is there anything planned for a great refactoring or re-organisation of this repository? I would like to contribute.
My biggest headache with the EDI framework right now is - it is not telling when what happens how.
For example: Setup Exchange Type and the exchange record will get create, generated, validated and send.
So improving the Usability on the exchange type would be much better.
More dropdowns, less code fields or text fields.

But for now I will go on with my research, trying to get our project here running and contribute on the migration of existing modules.
Thanks a lot!

from edi.