[ADD] Added base_edi_exchange module

[wpichler]

Base module for edi exchange of messages. No real function in this module. I will provide additional modules (they need code cleanup) with exchange functions.
Basic idea here is:

• Special Modules will extend the base_edi_exchange with for example a holodeck (AS2/AS4) based edi exchange
• So you can setup a new exchange.
• You can set an exchange on a partner.
• When you have a sale order for example - and the partner on the sale order does has an edi exchange attached - then you can directly send the sale order to the partner using the attached edi exchange

[bealdav]

Hi @wpichler thanks for your PR. Have you noticed https://github.com/OCA/storage/tree/12.0 strongly maintained for 10, 12 and 13 odoo version.

I think you could build your module based on them. What do you think ?

[wpichler]

Hi @wpichler thanks for your PR. Have you noticed https://github.com/OCA/storage/tree/12.0 strongly maintained for 10, 12 and 13 odoo version.

I think you could build your module based on them. What do you think ?

I havn't seen this modules until now...

I think these modules could be a great dependency for the file based exchange types.

I do have theses exchange types done / planned:

• plain directory (odoo does write the files in a directory directly on server - some other scripts can then send the files to the other party)
• holodeck (based on plain directory) - odoo does write files in directory with holodeck information file and holodeck file structure. The holodeck server than processes the files - the module will read the responses...
• ftp / sftp: Write files using ftp/sftp to a target - pool the target for response files
• mail: Send files using email - also receive responses per mail

So the storage modules would be a great base for the plain directory exchange module - with this the ftp / sftp exchange will get obsolete - and i can support every storage type in the storage repository.

I will integrate it - thanks for your hint !

[bealdav]

holodeck ? this kind of that ? http://holodeck-b2b.org

[wpichler]

holodeck ? this kind of that ? http://holodeck-b2b.org

exact - so we can support AS2 / AS4 exchange of ubl files with odoo ;-)

This is already implemented on my test system - i do prepare the modules for oca now

[florian-dacosta]

Hi @wpichler

We had done some modules to exchange file between Odoo and external system also.
And I think we should find a way to converge toward a same solution
A little explanation :

So in v9 for instance, we had :

• https://github.com/OCA/server-tools/tree/9.0/attachment_base_synchronize
  This module extends ir_attachment (inherits) to implement a kind of workflow on attachment.
  Basically, you can create an attachment with a special type. (the type will decide what action has to be executed of the file, it could be export (to sftp, aws, etc...) or, in case it was a file imported from an external system, it can be any action, like, create a bank statement, etc...

• https://github.com/OCA/server-tools/tree/9.0/external_file_location
  This module implement connection with external system (sftp, ftp, filestore)

I had started to migrate these module to version 12. Started renaming it, and base it on storage project, instead of re-implementing the connection logic with external system.
Here are the modules :

• https://github.com/akretion/server-tools/tree/12-mig-attachmet_base_sync/base_attachment_queue
  Correspond to attachment_base_synchronize

• https://github.com/akretion/server-tools/tree/12-mig-external_file_location/attachment_synchronize
  Replace external file location and depend on storage_backend

Then, after thinking more, I think we could get rid of the attachment_base_synchronize module and keep only the second one.
Indeed, we could replace the first module by the module queue_job. Because it just re-implement a queue of attachment... So it seems logic to depend on queue_job, instead of extending the ir_attachment model.

So, how I would see it, would be a module attachment_synchronize (or another name) or maybe
That, depend on queue_job and storage_backend.
This module would be quite simple :

1. Implement the task notion on top of storage_backend (one2many) https://github.com/akretion/server-tools/blob/12-mig-external_file_location/attachment_synchronize/models/task.py
   This task are used for importing and exporting file.
   a) Import :
   We have a cron that looks the task of type import, and create attachement + 1 job linked to it and a type (create bank statement, or do some specific stuff).
   b) Export
   If a module needs to export file to an external system, it calls a method on the storage_backend_task, that create a job linked to the file with the type "export".

What do you think about it?

[wpichler]

Hi @wpichler

We had done some modules to exchange file between Odoo and external system also.
And I think we should find a way to converge toward a same solution
A little explanation :

So in v9 for instance, we had :

• https://github.com/OCA/server-tools/tree/9.0/attachment_base_synchronize
  This module extends ir_attachment (inherits) to implement a kind of workflow on attachment.
  Basically, you can create an attachment with a special type. (the type will decide what action has to be executed of the file, it could be export (to sftp, aws, etc...) or, in case it was a file imported from an external system, it can be any action, like, create a bank statement, etc...
• https://github.com/OCA/server-tools/tree/9.0/external_file_location
  This module implement connection with external system (sftp, ftp, filestore)

I had started to migrate these module to version 12. Started renaming it, and base it on storage project, instead of re-implementing the connection logic with external system.
Here are the modules :

• https://github.com/akretion/server-tools/tree/12-mig-attachmet_base_sync/base_attachment_queue
  Correspond to attachment_base_synchronize
• https://github.com/akretion/server-tools/tree/12-mig-external_file_location/attachment_synchronize
  Replace external file location and depend on storage_backend

Then, after thinking more, I think we could get rid of the attachment_base_synchronize module and keep only the second one.
Indeed, we could replace the first module by the module queue_job. Because it just re-implement a queue of attachment... So it seems logic to depend on queue_job, instead of extending the ir_attachment model.

So, how I would see it, would be a module attachment_synchronize (or another name) or maybe
That, depend on queue_job and storage_backend.
This module would be quite simple :

1. Implement the task notion on top of storage_backend (one2many) https://github.com/akretion/server-tools/blob/12-mig-external_file_location/attachment_synchronize/models/task.py
   This task are used for importing and exporting file.
   a) Import :
   We have a cron that looks the task of type import, and create attachement + 1 job linked to it and a type (create bank statement, or do some specific stuff).
   b) Export
   If a module needs to export file to an external system, it calls a method on the storage_backend_task, that create a job linked to the file with the type "export".

What do you think about it?

I like the idea to bundle efforts - but i think it will not work in this case.

The base_edi_exchange does just define basic properties to be able to transfer files to an endpoint, and to import files from an endpoint. The endpoint can also be a non storage endpoint - like send it using mail (or use http post or whatever). So i think we can not replace base_edi_exchange with the functions from storage or attachment_synchronize.
But the file system specific handlers can use the storage modules for the file transfer to aws / sftp...

Or did i not understand something here correct ?

[bealdav]

Hi @wpichler do you have any code example of concrete edi exchange with standard edi protocol ? Message INVRPT ?

[wpichler]

Hi @wpichler do you have any code example of concrete edi exchange with standard edi protocol ? Message INVRPT ?

This addons are about the exchange of edi messages - not about the construction of such messages.
INVRPT is, as far as i can see, an older edifact format - not UBL - seems to be EANCOM.

I've now included all edi exchange related modules - so you can get an idea here....

[bealdav]

Thanks a lot

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[simahawk]

if we need this kind of feat in 12.0 it would be better to backport edi(_oca) from v13

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.