Metadata-Version: 2.1
Name: odoo-addon-edi_core_oca
Version: 18.0.1.7.2.2
Requires-Python: >=3.10
Requires-Dist: PyYAML
Requires-Dist: odoo-addon-base_edi==18.0.*
Requires-Dist: odoo==18.0.*
Requires-Dist: openupgradelib
Summary: Define backends, exchange types, exchange records, basic automation and views for handling EDI exchanges.
Home-page: https://github.com/OCA/edi-framework
License: LGPL-3
Author: ACSONE,Dixmit,Camptocamp,Odoo Community Association (OCA)
Author-email: support@odoo-community.org
Classifier: Programming Language :: Python
Classifier: Framework :: Odoo
Classifier: Framework :: Odoo :: 18.0
Classifier: License :: OSI Approved :: GNU Lesser General Public License v3 (LGPLv3)
Classifier: Development Status :: 4 - Beta
Description-Content-Type: text/x-rst

.. image:: https://odoo-community.org/readme-banner-image
   :target: https://odoo-community.org/get-involved?utm_source=readme
   :alt: Odoo Community Association

===
EDI
===

.. 
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !! This file is generated by oca-gen-addon-readme !!
   !! changes will be overwritten.                   !!
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
   !! source digest: sha256:5e54bc58f7c88ff2eaac2207226e25488a4aa47b800e1cdc606f485cf0523830
   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

.. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
    :target: https://odoo-community.org/page/development-status
    :alt: Beta
.. |badge2| image:: https://img.shields.io/badge/license-LGPL--3-blue.png
    :target: http://www.gnu.org/licenses/lgpl-3.0-standalone.html
    :alt: License: LGPL-3
.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fedi--framework-lightgray.png?logo=github
    :target: https://github.com/OCA/edi-framework/tree/18.0/edi_core_oca
    :alt: OCA/edi-framework
.. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
    :target: https://translation.odoo-community.org/projects/edi-framework-18-0/edi-framework-18-0-edi_core_oca
    :alt: Translate me on Weblate
.. |badge5| image:: https://img.shields.io/badge/runboat-Try%20me-875A7B.png
    :target: https://runboat.odoo-community.org/builds?repo=OCA/edi-framework&target_branch=18.0
    :alt: Try me on Runboat

|badge1| |badge2| |badge3| |badge4| |badge5|

Base EDI backend.

Provides following models:

1. EDI Backend, to centralize configuration
2. EDI Backend Type, to classify EDI backends (eg: UBL, GS1, e-invoice,
   pick-yours)
3. EDI Exchange Type, to define file types of exchange
4. EDI Exchange Record, to define a record exchanged between systems

Also define a mixin to be inherited by records that will generate EDIs.

In addition, the module ships an ``edi.configuration`` mechanism that
lets users react to EDI events declaratively, by writing small Python
snippets attached to event triggers. This can be used as a lightweight
alternative to component event listeners: configurations can react
globally (on any exchange) or be scoped to a specific partner (or any
related record), exchange type, backend and target model. See
``CONFIGURE.md`` for details.

**Table of contents**

.. contents::
   :local:

Configuration
=============

This module aims to provide an infrastructure to simplify
interchangability of documents between systems providing a configuration
platform. It will be inherited by other modules in order to define the
proper implementations of components.

In order to define a new Exchange Record, we need to configure:

- Backend Type
- Exchange Type
- Backend
- Components

Jobs
----

- **Internal User**: might be an EDI user without even knowing about it,
  triggering EDI flows by some of his actions on business records; does
  not need access to related queue jobs.

- **EDI User**: more conscious EDI user that might sometimes need to
  debug things a bit further and thus needs access to related queue
  jobs.

- **EDI Manager**: full configuration access.

Code to execute
---------------

By default, EDI Framework uses fields on ``edi.backend`` to get the
right function to execute. Each function is related to a model where the
specific function is defined. This models needs to inherit the specific
handler of each case.

- receive: model ``edi.oca.handler.receive`` with function receive.
- process: model ``edi.oca.handler.process`` with function process.
- generate: model ``edi.oca.handler.generate`` with function generate.
- send: model ``edi.oca.handler.send`` with function send.
- check: model ``edi.oca.handler.check`` with function check.
- validate on inputs: model ``edi.oca.handler.input.validate`` with
  function input_validate.
- validate on outputs: model ``edi.oca.handler.output.validate`` with
  function input_validate.

You can see an example on the tests fake_models.

For a more complex behaviour, you can use ``edi_component_oca`` module
to use components.

User EDI generation
-------------------

On the exchange type, it might be possible to define a set of models, a
domain and a snippet of code. After defining this fields, we will
automatically see buttons on the view to generate the exchange records.
This configuration is useful to define a way of generation managed by
user.

Exchange type rules configuration
---------------------------------

Exchange types can be further configured with rules. You can use rules
to:

1. make buttons automatically appear in forms
2. define your own custom logic

Go to an exchange type and go to the tab "Model rules". There you can
add one or more rule, one per model. On each rule you can define a
domain or a snippet to activate it. In case of a "Form button" kind, if
the domain and/ the snippet is/are satisfied, a form btn will appear on
the top of the form. This button can be used by the end user to manually
generate an exchange. If there's more than a backend and the exchange
type has not a backend set, a wizard will appear asking to select a
backend to be used for the exchange.

In case of "Custom" kind, you'll have to define your own logic to do
something.

Custom event handlers via ``edi.configuration``
-----------------------------------------------

The framework can dispatch EDI lifecycle events to user-defined
configurations, providing a declarative alternative to component events.
Each ``edi.configuration`` record links a **trigger** (an
``edi.configuration.trigger`` code) to a **snippet** (``snippet_do``)
that is executed every time the matching event fires on an exchange
record.

Built-in events fired by ``EDIExchangeRecord`` include:

- ``on_edi_exchange_done`` — exchange processed successfully
- ``on_edi_exchange_error`` — exchange ended in error
- ``on_edi_exchange_done_ack_received`` — ACK file received
- ``on_edi_exchange_done_ack_missing`` — expected ACK not received
- ``on_edi_exchange_done_ack_received_error`` — ACK received with errors
- ``on_edi_exchange_<action>_complete`` — generic action completion
  (e.g. ``generate_complete``, ``send_complete``), fired once on the
  exchange record and once on its related record when present

The snippet receives at least two variables in its evaluation context:

- ``conf`` — the current ``edi.configuration`` record
- ``record`` — the target of the event (either the
  ``edi.exchange.record`` itself or its related business record)

Plus the standard ``edi_exec_snippet_do`` extras (``operation``,
``edi_action``, ``old_value``, ``vals``, ...).

Two complementary lookup modes are available, and they can be combined
freely on the same flow.

Global event configurations
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Use this mode when you want a configuration to react to events on **any
business record** that travels through EDI, with no per-partner setup.

Tick **Global Configuration** (``is_global``) on the
``edi.configuration``. When an event fires, the framework calls
``edi.configuration.edi_get_conf_global(exchange_record, trigger)``
which selects all active global configurations whose ``trigger`` matches
the event code, filtered by the originating exchange record:

- **Exchange type** (``type_id``): must match the exchange record's
  type, or be left empty to apply to every type
- **Backend** (``backend_id``): must match the exchange record's
  backend, or be left empty to apply to every backend
- **Model** (``model_id`` / ``model_name``): must match the related
  record model (e.g. ``sale.order``, ``account.move``), or be left empty
  to apply to every model

Empty values mean "applies to all". Inactive configurations and
non-global configurations are ignored. All matching configurations are
executed in sequence.

Typical use cases:

- Posting a generic chatter message on every exchange that ends in error
- Pushing a notification to an external system every time an ACK is
  received for a given backend
- Logging extra audit information for every exchange of a given type

Partner-specific (relation-based) event configurations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Use this mode when the reaction must depend on the partner (or any other
related record) involved in the exchange.

In this case configurations are **not** marked as global. Instead, the
business record exposes an ``edi_config_ids`` relation (via
``edi.exchange.consumer.mixin._edi_config_field_relation``, which by
default returns ``self.env["edi.configuration"]`` and can be overridden,
for example to point at ``self.partner_id.edi_config_ids``). When an
event fires on the business record (e.g. on create, on write, on
send-via-email/EDI), the framework calls
``edi_confs.edi_get_conf(trigger)`` on that relation and runs the
matching snippets.

Compared with global configurations:

- **Discovery** comes from the record's own relation, not from a
  database-wide search; this is the right place to model "this partner
  wants this behaviour" rules
- **Filtering** is reduced to ``trigger`` and (optionally)
  ``backend_id``, since the recordset is already narrowed by the
  relation
- The same ``snippet_do`` API applies, so a snippet can be reused
  verbatim between global and partner-specific configurations

Typical use cases:

- Sending a specific EDI flow only for a subset of partners
- Customising the document generation per customer (e.g. different email
  template, different transport)
- Switching between EDI and email delivery based on partner preferences

Usage
=====

After certain operations or manual execution, Exchange records will be
generated. This Exchange records might be input records or outputs
records.

The change of state can be manually executed by the system or be managed
through by ir.cron.

Output Exchange records
-----------------------

An output record is intended to be used for exchange information from
Odoo to another system.

The flow of an output record should be:

- Creation
- Generation of data
- Validation of data
- Sending data
- Validation of data processed properly by the other party

Input Exchange records
----------------------

An input record is intended to be used for exchange information another
system to odoo.

The flow of an input record should be:

- Creation
- Reception of data
- Checking data
- Processing data

Known issues / Roadmap
======================

14.0.1.0.0
----------

The module name has been changed from edi to edi_oca.

18.0.1.4.0
----------

Components dependancy has been removed and set on a new dependant module
``edi_component_oca``. Module ``edi_oca`` has been_renamed to
``edi_core_oca``.

Changelog
=========

18.0.1.7.0 (2026-05-20)
-----------------------

Features
~~~~~~~~

- Introduce a new system for **global EDI events** based on
  ``edi.configuration`` that can replace the use of component events.

  Any ``edi.configuration`` flagged as ``is_global`` is now picked up by
  ``EDIExchangeRecord._trigger_edi_event`` and its ``snippet_do`` is
  executed whenever the matching event fires (``done``, ``error``,
  ``ack_received``, ``ack_missing``, ``ack_received_error``,
  ``<action>_complete``, ...).

  Filtering is performed via the new
  ``edi.configuration.edi_get_conf_global`` model method, which selects
  active global configurations matching the event trigger code and, when
  set, the exchange type, the backend and the related record model
  carried by the exchange record (empty values still mean "applies to
  all"). This lets integrators subscribe to EDI events declaratively
  from the UI instead of writing component listeners.

  Full test coverage is included for the dispatch on all ``notify_*``
  events (both on the exchange record and on the related record target)
  and for the new filtering rules.

  Last but not lease: add minimal docs for edi.configuration.
  (`#global-edi-conf-events <https://github.com/OCA/edi-framework/issues/global-edi-conf-events>`__)

Bug Tracker
===========

Bugs are tracked on `GitHub Issues <https://github.com/OCA/edi-framework/issues>`_.
In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us to smash it by providing a detailed and welcomed
`feedback <https://github.com/OCA/edi-framework/issues/new?body=module:%20edi_core_oca%0Aversion:%2018.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Do not contact contributors directly about support or help with technical issues.

Credits
=======

Authors
-------

* ACSONE
* Dixmit
* Camptocamp

Contributors
------------

- Simone Orsi <simahawk@gmail.com>
- Enric Tobella <enric.tobella@dixmit.com>
- Manuel Regidor <manuel.regidor@sygel.es>
- Thien Vo <thienvh@trobz.com>
- Jordi Masvidal <jordi.masvidal@forgeflow.com>

Maintainers
-----------

This module is maintained by the OCA.

.. image:: https://odoo-community.org/logo.png
   :alt: Odoo Community Association
   :target: https://odoo-community.org

OCA, or the Odoo Community Association, is a nonprofit organization whose
mission is to support the collaborative development of Odoo features and
promote its widespread use.

.. |maintainer-simahawk| image:: https://github.com/simahawk.png?size=40px
    :target: https://github.com/simahawk
    :alt: simahawk
.. |maintainer-etobella| image:: https://github.com/etobella.png?size=40px
    :target: https://github.com/etobella
    :alt: etobella

Current `maintainers <https://odoo-community.org/page/maintainer-role>`__:

|maintainer-simahawk| |maintainer-etobella| 

This module is part of the `OCA/edi-framework <https://github.com/OCA/edi-framework/tree/18.0/edi_core_oca>`_ project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.
