[MERGE] Forward-port of branch 13.0 to 14.0
BIN
_static/banners/db-upgrade.png
Normal file
After Width: | Height: | Size: 295 KiB |
BIN
_static/banners/hosting_changes.png
Normal file
After Width: | Height: | Size: 346 KiB |
BIN
_static/banners/sign.png
Normal file
After Width: | Height: | Size: 365 KiB |
@ -13,9 +13,13 @@ Iceland, Norway, Switzerland, Andorra, Monaco and San Marino.
|
||||
With Odoo, once you decide to pay a vendor, you can select to pay the
|
||||
bill with SEPA. Then, at the end of the day, the manager can generate
|
||||
the SEPA file containing all bank wire transfers and send it to the
|
||||
bank. The file follows the SEPA Credit Transfer 'PAIN.001.001.03'
|
||||
bank.
|
||||
|
||||
By default,the file follows the SEPA Credit Transfer **'pain.001.001.03'**
|
||||
specifications. This is a well-defined standard that makes consensus
|
||||
among banks.
|
||||
among banks. However, according to the country set on your company,
|
||||
another format can be used : **'pain.001.001.03.ch.02'** for Switzerland
|
||||
and **'pain.001.003.03'** for Germany.
|
||||
|
||||
Once the payments are processed by your bank, you can directly import
|
||||
the account statement inside Odoo. The bank reconciliation process will
|
||||
@ -113,7 +117,8 @@ Troubleshooting
|
||||
The bank refuses my SEPA file
|
||||
-----------------------------
|
||||
|
||||
Ask your bank if they support **PAIN.001.001.03 SEPA Credit Transfers**. If
|
||||
Ask your bank if they support the **SEPA Credit Transfer specification**
|
||||
(the SEPA pain version depends on the country set on your company). If
|
||||
they don't, or cannot provide relevant informations, please forward the
|
||||
error message to your Odoo partner.
|
||||
|
||||
|
@ -18,6 +18,7 @@ Applications
|
||||
bi
|
||||
documents
|
||||
fsm
|
||||
sign
|
||||
point_of_sale
|
||||
inventory
|
||||
manufacturing
|
||||
@ -62,6 +63,7 @@ Applications
|
||||
timesheets
|
||||
planning
|
||||
fsm
|
||||
sign
|
||||
point_of_sale
|
||||
inventory
|
||||
manufacturing
|
||||
|
@ -524,8 +524,8 @@ build your tables. Then, copy-paste the generated formatting into your document.
|
||||
|
||||
.. _contributing/specialized-directives:
|
||||
|
||||
Spice your writing with specialized directives
|
||||
----------------------------------------------
|
||||
Spice up your writing with specialized directives
|
||||
-------------------------------------------------
|
||||
|
||||
Use these additional directives to fine-tune your content:
|
||||
|
||||
|
@ -7,6 +7,4 @@ Optimize your Day-to-Day work
|
||||
|
||||
optimize/partner_autocomplete
|
||||
optimize/outlook_extension
|
||||
optimize/onsip
|
||||
optimize/setup
|
||||
optimize/gamification
|
||||
|
418
db_management/db_upgrade.rst
Normal file
@ -0,0 +1,418 @@
|
||||
:banner: banners/db-upgrade.png
|
||||
|
||||
.. |assistance-contact| replace::
|
||||
If you need Odoo assistance on this matter, please contact your Odoo Account Manager or contact
|
||||
our `Sales department`_.
|
||||
.. _Sales department: mailto:sales@odoo.com
|
||||
|
||||
.. _db-upgrade:
|
||||
|
||||
=======
|
||||
Upgrade
|
||||
=======
|
||||
|
||||
.. _db-upgrade/overview:
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
.. _db-upgrade/process:
|
||||
|
||||
The upgrade process
|
||||
-------------------
|
||||
|
||||
This documentation is for our *On-Premise* (self-hosted) and *Odoo.sh* customers. If you are hosted
|
||||
Online, please check our :ref:`instruction page for our Online (SaaS) customers <upgrade_button>`.
|
||||
|
||||
.. _db-upgrade/definition:
|
||||
|
||||
Definition
|
||||
~~~~~~~~~~
|
||||
|
||||
An upgrade is switching to a newer version of Odoo (e.g., Odoo 13.0 to Odoo 14.0)
|
||||
|
||||
An upgrade does not cover:
|
||||
|
||||
* changing :ref:`Editions <db-upgrade/faq/editions-change>` (i.e., Community to Enterprise edition)
|
||||
* switching :ref:`hosting type <db-upgrade/faq/hosting-types-switch>` (i.e., On-Premise to Online or
|
||||
Odoo.sh)
|
||||
* migration from another ERP to Odoo
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _db-upgrade/process-workflow:
|
||||
|
||||
Process workflow
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The upgrade process in a nutshell:
|
||||
|
||||
#. You create a test upgrade request.
|
||||
#. | The request is processed by Odoo:
|
||||
| This happens via an automated process that runs the database through an upgrade script and
|
||||
takes between 20 and 120 minutes. Only if an issue(s) arises will we have to intervene
|
||||
manually and adjust the script specifically to your database until the upgrade succeeds.
|
||||
#. Odoo delivers a test database.
|
||||
#. You test your database for possible discrepancies (see :ref:`db-upgrade/test-guidance`)
|
||||
#. If there are any discrepancies, you report them to the Upgrade support team via the
|
||||
:ref:`Help portal <db-upgrade/test-assistance>`.
|
||||
#. We will fix the issues and send you a new test database.
|
||||
#. Once you completed the testing and are happy with the result, you decide on a date and time when
|
||||
you stop users from accessing Odoo, freeze all data entries and create an upgrade request for the
|
||||
production upgrade.
|
||||
#. Odoo delivers the production database through the automated process.
|
||||
#. You restore it in your Production environment a few short hours later and continue working on the
|
||||
newly upgraded database.
|
||||
|
||||
.. _db-upgrade/service-level:
|
||||
|
||||
Service Level Agreement
|
||||
-----------------------
|
||||
|
||||
What is covered by the Enterprise Licence?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Databases hosted on Odoo’s Cloud platforms (Saas and Odoo.sh) or On-Premise (Self-Hosting) enjoy the
|
||||
following service at all times.
|
||||
|
||||
The upgrade of:
|
||||
|
||||
* standard applications
|
||||
* Studio customization (as long as the Studio app is still active)
|
||||
* customizations done by our consulting and developer services *if* they are covered by a
|
||||
‘Maintenance of Customisations’ subscription
|
||||
|
||||
The Upgrade Service is limited to the technical conversion and adaptation of your database (standard
|
||||
modules and data) to make it compatible with the targeted version.
|
||||
|
||||
What upgrading does NOT cover
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
* The cleaning of pre-existing data & configuration while upgrading
|
||||
* Any new developments and/or upgrade of your own :ref:`custom modules
|
||||
<db-upgrade/faq/custom-modules>`
|
||||
* `Training <https://www.odoo.com/learn>`_ on the new version
|
||||
|
||||
You can get more information about your Enterprise Licence on our :ref:`Odoo Enterprise Subscription
|
||||
Agreement <upgrade>` page.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _db-upgrade/get-started:
|
||||
|
||||
Get started
|
||||
===========
|
||||
|
||||
The upgrade process varies depending on where your database is hosted.
|
||||
|
||||
.. _db-upgrade/online:
|
||||
|
||||
Online (SaaS)
|
||||
-------------
|
||||
|
||||
If you are hosted Online, please check our :ref:`instruction page for our Online (SaaS) customers
|
||||
<upgrade_button>`.
|
||||
|
||||
.. _db-upgrade/odoo-sh:
|
||||
|
||||
Odoo.sh
|
||||
-------
|
||||
|
||||
If you are Odoo.sh hosted, check our :doc:`specific instructions to be able to upgrade
|
||||
<../odoo_sh/advanced/upgrade_your_database>`.
|
||||
|
||||
.. _db-upgrade/on-premise:
|
||||
|
||||
On-Premise
|
||||
----------
|
||||
|
||||
There are two possibilities:
|
||||
|
||||
#. Via the interface of our `website form <https://upgrade.odoo.com>`_
|
||||
#. | For technically-advanced users and partners, via the following command line (to be used on the
|
||||
machine where your database is hosted):
|
||||
| ``python <(curl -s beta.upgrade.odoo.com/upgrade) test -d <your db name> -t 14.0 -c <your
|
||||
subscription code>``
|
||||
|
||||
What does it do?
|
||||
~~~~~~~~~~~~~~~~
|
||||
|
||||
The above command will dump your database to a file, then send it to the upgrade platform for
|
||||
upgrade, displaying you the live logs, then restore the upgraded database back on your server as a
|
||||
duplicate test database.
|
||||
|
||||
.. _db-upgrade/steps:
|
||||
|
||||
Steps
|
||||
=====
|
||||
|
||||
.. _db-upgrade/steps-test:
|
||||
|
||||
The testing phase
|
||||
-----------------
|
||||
|
||||
.. _db-upgrade/test-process:
|
||||
|
||||
Test process
|
||||
~~~~~~~~~~~~
|
||||
|
||||
Also referred to as the pre-production phase, the test phase allows you to review an upgraded
|
||||
version of your database without affecting your production database in any way.
|
||||
|
||||
We suggest that you run the test upgrade process at least once, but you can do it as often as you
|
||||
want (one at a time).
|
||||
|
||||
Once you receive your upgraded test database, you should check that all data, processes and
|
||||
functionality are still correct and working as expected.
|
||||
|
||||
If you do find discrepancies, you'll be able to:
|
||||
|
||||
* | :ref:`Report your issues <db-upgrade/test-assistance>`
|
||||
| and/or
|
||||
* Ask for a new :ref:`test request <db-upgrade/test-db-request>` after the reported issues have
|
||||
been fixed in the upgrade script.
|
||||
|
||||
When you do not find any discrepancies, you'll be able to:
|
||||
|
||||
* Move on to the upgrade of your :ref:`production database <db-upgrade/production-live>`.
|
||||
|
||||
.. _db-upgrade/test-db-request:
|
||||
|
||||
Request a test database
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
When filling the `website form <https://upgrade.odoo.com>`_, select *Testing* purpose.
|
||||
|
||||
.. image:: media/db-upgrade-test-purpose.png
|
||||
:align: center
|
||||
:alt: Selection of the "Testing" purpose in the upgrade form on Odoo
|
||||
|
||||
.. _db-upgrade/test-guidance:
|
||||
|
||||
Test guidance
|
||||
~~~~~~~~~~~~~
|
||||
|
||||
Every business and organization has its own operational needs and will have to test its specific
|
||||
Odoo instance respectively. However, we recommend you look at `the test scenario
|
||||
<https://drive.google.com/open?id=1Lm4JqbsHBirB1wMi14UChoz_YHLjx5ec>`_ we created, a high-level idea
|
||||
of what you should test and look out for.
|
||||
|
||||
.. todo:: change link "test scenario" once the related doc is published
|
||||
|
||||
.. _db-upgrade/test-assistance:
|
||||
|
||||
Assistance
|
||||
~~~~~~~~~~
|
||||
|
||||
If you encounter issues or problems in the **test database**, please contact the Odoo Upgrade
|
||||
Support:
|
||||
|
||||
#. Connect to our `Odoo Support page <https://www.odoo.com/help>`_.
|
||||
#. Under the *Ticket Description* section, select *An issue related to my upgrade* ticket type.
|
||||
|
||||
.. image:: media/db-upgrade-test-assistance.png
|
||||
:align: center
|
||||
:alt: Selection of "An issue related to my upgrade" as Ticket Type in the support form on Odoo
|
||||
|
||||
.. warning::
|
||||
If you choose another *Ticket Description* type, the request will be redirected to another
|
||||
team than the upgrade one and will slow down the processing and response time.
|
||||
|
||||
#. Please provide as much detail as you can. Where applicable, illustrate the current and previous
|
||||
flows with videos and/or screenshots. This will avoid clarifying questions and speed up the
|
||||
resolution process significantly.
|
||||
|
||||
.. image:: media/db-upgrade-test-assistance-details.png
|
||||
:align: center
|
||||
:alt: "Detailed Description" field in the support form on Odoo
|
||||
|
||||
.. note::
|
||||
* The purpose of the test phase is not to correct existing data or configurations in your
|
||||
database.
|
||||
* |assistance-contact|
|
||||
|
||||
.. _db-upgrade/steps-production:
|
||||
|
||||
The production launch
|
||||
---------------------
|
||||
|
||||
.. _db-upgrade/production-live:
|
||||
|
||||
Production goes live
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The production upgrade request is when you decide to upgrade your current database with all your
|
||||
production data (invoices, VAT returns, inventories, current orders) to a new version of your choice.
|
||||
|
||||
After your :ref:`tests <db-upgrade/steps-test>` are completed to your satisfaction, submit the
|
||||
request to upgrade your production database via our `website form <https://upgrade.odoo.com>`_.
|
||||
Select *Production* purpose.
|
||||
|
||||
.. image:: media/db-upgrade-production-purpose.png
|
||||
:align: center
|
||||
:alt: Selection of the "Production" purpose in the upgrade form on Odoo
|
||||
|
||||
.. danger::
|
||||
Going into production without first testing may lead to:
|
||||
|
||||
- business interruptions (e.g. no longer having the possibility to validate an action)
|
||||
- poor customer experiences (e.g. an eCommerce website that does not work correctly)
|
||||
|
||||
.. _db-upgrade/production-assistance:
|
||||
|
||||
Assistance
|
||||
~~~~~~~~~~
|
||||
|
||||
If you encounter issues or problems in the **production database**, please contact the Odoo Upgrade
|
||||
Support:
|
||||
|
||||
#. Connect to our `Odoo Support page <https://www.odoo.com/help>`_.
|
||||
#. Under the *Ticket Description* section, select *An issue related to my upgrade* ticket type.
|
||||
Under the *Ticket Description* section, select the appropriate type related to your issue but
|
||||
**do not select** the option *An issue related to my upgrade*.
|
||||
|
||||
.. note::
|
||||
After upgrading to production, the support will be provided by the Support team instead of the
|
||||
Upgrade team.
|
||||
|
||||
#. Please provide as much detail as you can. Where applicable, illustrate the current and previous
|
||||
flows with videos and/or screenshots. This will avoid clarifying questions and speed up the
|
||||
resolution process significantly.
|
||||
|
||||
.. image:: media/db-upgrade-production-assistance-details.png
|
||||
:align: center
|
||||
:alt: "Detailed Description" field in the support form on Odoo
|
||||
|
||||
.. warning::
|
||||
If you choose another *Ticket Description* type, the request will be redirected to another
|
||||
team than the upgrade one and will slow down the processing and response time.
|
||||
|
||||
.. _db-upgrade/faq:
|
||||
|
||||
FAQ
|
||||
===
|
||||
|
||||
.. _db-upgrade/faq/why:
|
||||
|
||||
Why upgrade?
|
||||
------------
|
||||
|
||||
* You benefit from the latest features of the :ref:`new major version
|
||||
<db-upgrade/faq/release-notes>` released by Odoo.
|
||||
* If you are in an :ref:`unsupported version <db-upgrade/supported-versions>`, you get a new version
|
||||
with support.
|
||||
|
||||
.. _db-upgrade/faq/when:
|
||||
|
||||
When to upgrade?
|
||||
----------------
|
||||
|
||||
Whenever you want. You can make your upgrade request as soon as a new version is released on our
|
||||
`website form <https://upgrade.odoo.com>`_.
|
||||
|
||||
.. _db-upgrade/faq/availability:
|
||||
|
||||
Availability of the new version
|
||||
-------------------------------
|
||||
|
||||
Please kindly note that as soon as we announce the release of a new major version (usually at the
|
||||
end of year), the Upgrade Service team needs to adapt the upgrade scripts to it, which is why the
|
||||
new version is not immediately available for existing databases.
|
||||
|
||||
.. _db-upgrade/faq/finalization:
|
||||
|
||||
Finalization of the upgrade (:abbr:`ETA (Estimated Time of Arrival)`)
|
||||
---------------------------------------------------------------------
|
||||
|
||||
Unfortunately, it is impossible to give time estimates for every upgrade request. Odoo offers so
|
||||
many possibilities (e.g. branding, workflows, customization, etc) that it can get tricky to upgrade,
|
||||
and translate to the new structure. If you use multiple apps managing sensitive data (e.g.,
|
||||
Accounting, Inventory, etc.), some cases may still require a human intervention, making the process
|
||||
slower.
|
||||
|
||||
This is especially true during the first months following the release of a new major version, which
|
||||
can significantly lengthen the upgrade delay.
|
||||
|
||||
In general, the ‘smaller’ the database, the quickest the upgrade. A single-user database that uses
|
||||
only CRM will be processed faster than a multi-company, multi-user database that uses Accounting,
|
||||
Sales, Purchase, and Manufacturing.
|
||||
|
||||
So, in a nutshell, what can impact your upgrade lead time?
|
||||
|
||||
* Source & targeted versions
|
||||
* Installed apps
|
||||
* Volume of data
|
||||
* Amount of customization (models, fields, methods, workflows, reports, website, etc.)
|
||||
* Installation of new apps or configuration changes after the start of the test phase
|
||||
|
||||
Usually, the delays experienced during the first request (waiting time between the time you
|
||||
submitted your first request for a test upgrade) can generally give you an idea of the time to wait
|
||||
for the production request.
|
||||
|
||||
.. _db-upgrade/faq/custom-modules:
|
||||
|
||||
Upgrade of the custom modules
|
||||
-----------------------------
|
||||
|
||||
As stated in our :doc:`../legal/terms/enterprise`, section :ref:`charges_standard`, this optional
|
||||
service is subject to additional fees.
|
||||
|
||||
If you have a custom code, you can choose to have it upgraded by our services, by one of our
|
||||
`partners <https://www.odoo.com/partners>`_ or you can do it yourself.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _db-upgrade/faq/editions-change:
|
||||
|
||||
Editions change (from Community to Enterprise)
|
||||
----------------------------------------------
|
||||
|
||||
An upgrade does not cover a change of `Editions <https://www.odoo.com/page/editions>`_
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _db-upgrade/faq/hosting-types-switch:
|
||||
|
||||
Switching the hosting types (Self-hosted vs Online vs Odoo.sh)
|
||||
--------------------------------------------------------------
|
||||
|
||||
An upgrade does not cover a change of `Hosting types <https://www.odoo.com/page/hosting-types>`_.
|
||||
|
||||
Open the following link to get :doc:`more information about how to change your hosting type
|
||||
<hosting_changes>`.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _db-upgrade/faq/release-notes:
|
||||
|
||||
Release Notes by version
|
||||
------------------------
|
||||
|
||||
Open our `Release Note <https://www.odoo.com/page/release-notes>`_ page to get a summary of the new
|
||||
features and improvements made in each version.
|
||||
|
||||
.. _db-upgrade/assistance:
|
||||
|
||||
Assistance
|
||||
==========
|
||||
|
||||
.. _db-upgrade/contact:
|
||||
|
||||
Contact our Upgrade service support
|
||||
-----------------------------------
|
||||
|
||||
Should you have any more questions about the upgrade, do not hesitate to send a message to `Odoo
|
||||
Upgrade Team <mailto:upgrade@odoo.com>`_. We will be very pleased to answer it as soon as possible.
|
||||
|
||||
.. _db-upgrade/supported-versions:
|
||||
|
||||
Supported versions
|
||||
------------------
|
||||
|
||||
Please note that Odoo provides support and bug fixing only for the three last major versions of Odoo.
|
||||
|
||||
This is a factor to take into consideration before upgrading. If you are on an older version, we
|
||||
suggest you to prefer the most recent version to benefit from a longer support (before having to
|
||||
upgrade again).
|
||||
|
||||
You can get more information about our :doc:`supported versions <../support/supported_versions>`.
|
BIN
db_management/media/db-upgrade-production-assistance-details.png
Normal file
After Width: | Height: | Size: 9.5 KiB |
BIN
db_management/media/db-upgrade-production-purpose.png
Normal file
After Width: | Height: | Size: 2.8 KiB |
BIN
db_management/media/db-upgrade-test-assistance-details.png
Normal file
After Width: | Height: | Size: 13 KiB |
BIN
db_management/media/db-upgrade-test-assistance.png
Normal file
After Width: | Height: | Size: 8.7 KiB |
BIN
db_management/media/db-upgrade-test-purpose.png
Normal file
After Width: | Height: | Size: 2.9 KiB |
@ -13,6 +13,7 @@ General
|
||||
general/multi_companies
|
||||
general/auth
|
||||
general/payment_acquirers
|
||||
general/voip
|
||||
general/calendars
|
||||
general/in_app_purchase
|
||||
general/developer_mode
|
||||
|
10
general/voip.rst
Normal file
@ -0,0 +1,10 @@
|
||||
===================================
|
||||
VoIP (Voice over Internet Protocol)
|
||||
===================================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
voip/asterisk
|
||||
voip/onsip
|
||||
voip/axivox
|
@ -1,5 +1,5 @@
|
||||
============================================
|
||||
Configure your VOIP Asterisk server for Odoo
|
||||
Configure your VoIP Asterisk server for Odoo
|
||||
============================================
|
||||
|
||||
Installing Asterisk server
|
79
general/voip/axivox.rst
Normal file
@ -0,0 +1,79 @@
|
||||
=====================================
|
||||
Use VoIP services in Odoo with Axivox
|
||||
=====================================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Odoo VoIP can be set up to work together with `Axivox <https://www.axivox.com/>`_. In that case, an
|
||||
:doc:`Asterisk server <asterisk>` is not necessary as the infrastructure is hosted and managed by
|
||||
Axivox.
|
||||
|
||||
To use this service, `contact Axivox <https://www.axivox.com/contact/>`_ to open an account. Before
|
||||
doing so, verify that Axivox covers your area and the areas you wish to call.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Go to :menuselection:`Apps` and install the **VoIP Module**.
|
||||
|
||||
.. image:: media/axivox-voip-installation.png
|
||||
:align: center
|
||||
:alt: VoIP module installation on an Odoo database
|
||||
|
||||
Go to :menuselection:`Settings --> General Settings --> Integrations`, and fill out the **Asterisk
|
||||
(VoIP)** field:
|
||||
|
||||
- **PBX Server IP**: set the domain created by Axivox for your account (e.g.,
|
||||
*yourcompany.axivox.com*)
|
||||
- **WebSocket**: type in ``wss://pabx.axivox.com:3443``
|
||||
- **VoIP Environment**: set as *Production*
|
||||
|
||||
.. image:: media/axivox-voip-configuration.png
|
||||
:align: center
|
||||
:alt: Integration of Axivox as VoIP provider in an Odoo database
|
||||
|
||||
Go to :menuselection:`Settings --> Users & Companies --> Users`, then open the user's form you want
|
||||
to configure. Under the **Preferences** tab, fill out the section **PBX Configuration**:
|
||||
|
||||
- **SIP Login / Browser's Extension**: the Axivox *username*
|
||||
- **SIP Password**: the Axivox *SIP Password*
|
||||
|
||||
.. note::
|
||||
You can find all this information by logging in at https://manage.axivox.com/, selecting the user
|
||||
you want to configure, and referring to the fields as pictured below.
|
||||
|
||||
.. image:: media/axivox-manager-sip.png
|
||||
:align: center
|
||||
:alt: SIP credentials in the Axivox manager
|
||||
|
||||
Phone Calls
|
||||
===========
|
||||
|
||||
You can make phone calls by clicking on the phone icon in the navigation bar.
|
||||
|
||||
You can also receive phone calls. Odoo rings and displays a notification.
|
||||
|
||||
.. note::
|
||||
Your number is the one provided by Axivox.
|
||||
|
||||
.. image:: media/axivox-incoming-call.png
|
||||
:align: center
|
||||
:alt: Incoming VoIP call in Odoo
|
||||
|
||||
.. tip::
|
||||
If you see a *Missing Parameter* message in the **Odoo softphone**, refresh your Odoo window and
|
||||
try again.
|
||||
|
||||
.. image:: media/axivox-missing-parameter.png
|
||||
:align: center
|
||||
:alt: "Missing Parameter" error message in the Odoo softphone
|
||||
|
||||
.. tip::
|
||||
If you see an *Incorrect Number* message in the Odoo softphone, make sure to use the
|
||||
international format, leading with the plus (+) sign followed by the international country code.
|
||||
E.g., +16506913277 (where +1 is the international prefix for the United States).
|
||||
|
||||
.. image:: media/axivox-incorrect-number.png
|
||||
:align: center
|
||||
:alt: "Incorrect Number" error message in the Odoo softphone
|
BIN
general/voip/media/axivox-incoming-call.png
Normal file
After Width: | Height: | Size: 33 KiB |
BIN
general/voip/media/axivox-incorrect-number.png
Normal file
After Width: | Height: | Size: 7.2 KiB |
BIN
general/voip/media/axivox-manager-sip.png
Normal file
After Width: | Height: | Size: 12 KiB |
BIN
general/voip/media/axivox-missing-parameter.png
Normal file
After Width: | Height: | Size: 5.3 KiB |
BIN
general/voip/media/axivox-voip-configuration.png
Normal file
After Width: | Height: | Size: 20 KiB |
BIN
general/voip/media/axivox-voip-installation.png
Normal file
After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 113 KiB After Width: | Height: | Size: 113 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 57 KiB |
Before Width: | Height: | Size: 64 KiB After Width: | Height: | Size: 64 KiB |
Before Width: | Height: | Size: 136 KiB After Width: | Height: | Size: 136 KiB |
@ -1,5 +1,5 @@
|
||||
====================================
|
||||
Use VOIP services in Odoo with OnSIP
|
||||
Use VoIP services in Odoo with OnSIP
|
||||
====================================
|
||||
|
||||
Introduction
|
BIN
inventory/routes/strategies/media/empty-dock.png
Normal file
After Width: | Height: | Size: 79 KiB |
BIN
inventory/routes/strategies/media/enabled-features.png
Normal file
After Width: | Height: | Size: 16 KiB |
BIN
inventory/routes/strategies/media/entering-stocks.png
Normal file
After Width: | Height: | Size: 75 KiB |
BIN
inventory/routes/strategies/media/first-expiry-first-out.png
Normal file
After Width: | Height: | Size: 19 KiB |
BIN
inventory/routes/strategies/media/first-in-first-out.png
Normal file
After Width: | Height: | Size: 24 KiB |
BIN
inventory/routes/strategies/media/inventory-valuation.png
Normal file
After Width: | Height: | Size: 10 KiB |
BIN
inventory/routes/strategies/media/last-in-first-out.png
Normal file
After Width: | Height: | Size: 19 KiB |
BIN
inventory/routes/strategies/media/packing-products.png
Normal file
After Width: | Height: | Size: 78 KiB |
BIN
inventory/routes/strategies/media/removal-date.png
Normal file
After Width: | Height: | Size: 8.0 KiB |
Before Width: | Height: | Size: 3.6 KiB |
Before Width: | Height: | Size: 5.8 KiB |
Before Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 30 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 23 KiB |
Before Width: | Height: | Size: 8.1 KiB |
Before Width: | Height: | Size: 7.6 KiB |
Before Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 24 KiB |
BIN
inventory/routes/strategies/media/reserved-hand-cream.png
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
inventory/routes/strategies/media/reserved-lots-FIFO.png
Normal file
After Width: | Height: | Size: 10 KiB |
BIN
inventory/routes/strategies/media/reserved-lots-LIFO.png
Normal file
After Width: | Height: | Size: 10 KiB |
@ -1,192 +1,222 @@
|
||||
==================================================
|
||||
What is a removal strategy (FIFO, LIFO, and FEFO)?
|
||||
What is a Removal Strategy (FIFO, LIFO, and FEFO)?
|
||||
==================================================
|
||||
|
||||
Overview
|
||||
========
|
||||
Usually, *Removal Strategies* are defined in picking operations to select the best products to
|
||||
optimize the distance for the worker, for quality control purposes, or to first move the products
|
||||
with the closest expiration date.
|
||||
|
||||
Removal strategies are usually in picking operations to select the best
|
||||
products in order to optimize the distance for the worker, for quality
|
||||
control purpose or due to reason of product expiration.
|
||||
When a product movement needs to be done, Odoo finds available products that can be assigned to
|
||||
the transfer. The way Odoo assigns these products depends on the *Removal Strategy* defined in
|
||||
the *Product Category* or on the *Location*.
|
||||
|
||||
When a product movement needs to be done, Odoo will find available
|
||||
products that can be assigned to shipping. The way Odoo assign these
|
||||
products depend on the **removal strategy** that is defined on the **product
|
||||
category** or on the **location**.
|
||||
What happens inside the warehouse?
|
||||
==================================
|
||||
|
||||
Configuration
|
||||
=============
|
||||
Imagine a generic warehouse plan, with receiving docks and area, storage locations, picking and
|
||||
packing areas, and shipping docks. All products go through all these locations, but some rules,
|
||||
such as removal strategies, can have an effect on which products are taken for the pickings.
|
||||
|
||||
In the **Inventory** application, go to :menuselection:`Configuration
|
||||
--> Settings`:
|
||||
.. image:: media/empty-dock.png
|
||||
:align: center
|
||||
:alt: empty stock waiting for deliveries at the docks.
|
||||
|
||||
.. image:: media/removal01.png
|
||||
:align: center
|
||||
Here, vendor trucks unload pallets of goods at the docks. Then, operators scan the products in the
|
||||
receiving area, with the receiving date and, if the product has an expiration date, the expiration
|
||||
date. After that, products are stored in their respective locations.
|
||||
|
||||
.. image:: media/removal02.png
|
||||
:align: center
|
||||
.. image:: media/entering-stocks.png
|
||||
:align: center
|
||||
:alt: products entering stock via the receiving area.
|
||||
|
||||
Check **Track lots or serial numbers**, **Manage several location per
|
||||
warehouse** and **Advanced routing of products using rules**, then click
|
||||
on **Apply**.
|
||||
Next, several orders for the same product are made, but you didn’t receive the goods the same day
|
||||
and they don’t have the same expiration date. In that situation, you logically prefer sending those
|
||||
with the closest date first. Depending on the removal strategy you chose, Odoo generates a transfer
|
||||
with the products fitting your settings the best.
|
||||
|
||||
Then, open :menuselection:`Configuration --> Locations`
|
||||
and open the location on which you want to apply a removal strategy.
|
||||
.. image:: media/packing-products.png
|
||||
:align: center
|
||||
:alt: products being packed at packing area for delivery, taking expiration dates into account.
|
||||
|
||||
.. image:: media/removal03.png
|
||||
:align: center
|
||||
.. note::
|
||||
On the transfer form, you can find the product’s lot/serial number to pick for delivery.
|
||||
|
||||
Types of removal strategy
|
||||
=========================
|
||||
How does it work?
|
||||
=================
|
||||
|
||||
FIFO ( First In First Out )
|
||||
---------------------------
|
||||
First In, First Out (FIFO)
|
||||
--------------------------
|
||||
|
||||
A **First In First Out** strategy implies that the products that were
|
||||
stocked first will move out first. Companies should use FIFO method if
|
||||
they are selling perishable goods. Companies selling products with
|
||||
relatively short demand cycles, such as clothes, also may have to pick
|
||||
FIFO to ensure they are not stuck with outdated styles in inventory.
|
||||
When using a **First In, First Out** strategy, a demand for some products triggers a removal rule
|
||||
which requests a transfer for the lot/serial number that has entered your stock the first.
|
||||
|
||||
Go to :menuselection:`Inventory --> Configuration --> Locations`,
|
||||
open the stock location and set **FIFO** removal strategy.
|
||||
To be clearer, let’s imagine that you have three lots of nails in your warehouse. Those three have
|
||||
the following lot numbers: 00001, 00002, 00003, each with 5 nails boxes in it. 00001 entered the
|
||||
stock on the 23rd of May, 00002 on the 25th of May, and 00003 on the 1st of June. A customer orders
|
||||
you 6 boxes on the 11th of June. With the *FIFO* strategy selected, a transfer is requested for the
|
||||
five boxes of 00001 and one of the boxes in 00002 because 00001 has entered your stock before the
|
||||
others. The box from 00002 is taken because it has the oldest enter date after 00001.
|
||||
|
||||
Let's take one example of FIFO removal strategy.
|
||||
So, for every order of a product with the *FIFO* strategy selected, Odoo requests a transfer for the
|
||||
good that has been in your stock for the longest period.
|
||||
|
||||
In your warehouse stock (``WH/Stock``) location, there are ``3`` lots of ``iPod
|
||||
32 Gb`` available.
|
||||
Last In, First Out (LIFO)
|
||||
-------------------------
|
||||
|
||||
You can find details of available inventory in inventory valuation
|
||||
report.
|
||||
The same way as for FIFO, the **Last In, First Out** strategy is based on moving products based on the
|
||||
date they entered the stock. Here, a demand for some products triggers a removal rule that requests a
|
||||
transfer for the lot/serial number that has entered your stock the last.
|
||||
|
||||
.. image:: media/removal04.png
|
||||
:align: center
|
||||
To better understand, let’s imagine three lots of screws in your warehouse. Those three have the
|
||||
following numbers: 10001, 10002, 10003, each with 10 screw boxes in it. 10001 has entered the stock
|
||||
on the 1st of June, 10002 on the 3rd of June, and 10003 on the 6th of June. A customer orders
|
||||
7 boxes on the 8th of June. With the *LIFO* strategy selected, a transfer is requested for seven
|
||||
boxes of 10003 because that lot is the last one to have entered the stock.
|
||||
|
||||
Create one sales order ``25`` unit of ``iPod 32 GB`` and confirm it.
|
||||
So, basically, for every order of a product with the *LIFO* strategy used, a transfer for the last
|
||||
one to have entered the stock is requested.
|
||||
|
||||
You can see in the outgoing shipment product that the ``Ipod 32
|
||||
Gb`` are assigned with the **oldest** lots, using the FIFO removal
|
||||
strategy.
|
||||
.. note::
|
||||
This strategy is banned in many countries and can lead to only have old or obsolete products
|
||||
in your stock.
|
||||
|
||||
.. image:: media/removal05.png
|
||||
:align: center
|
||||
First Expire, First Out (FEFO)
|
||||
------------------------------
|
||||
|
||||
LIFO (Last In First Out)
|
||||
------------------------
|
||||
The **First Expire, First Out** strategy is a bit different from the two others. Here, it is the
|
||||
expiration date that is important and not the date the product entered the stock.
|
||||
|
||||
In this warehouse management, the products which are brought in the
|
||||
last, moves out the first. LIFO is used in case of products which do not
|
||||
have a shelf life.
|
||||
Let’s imagine three lots of 6-eggs boxes (in this specific case, don’t forget to use
|
||||
:doc:`units of measure <../../management/products/uom>`). Those three have the following numbers:
|
||||
20001, 20002, and 20003, each with 5 boxes in it. 20001 has entered the stock on the 1st of July
|
||||
and expires on the 15th of July, 20002 on the 2nd and expires on the 14th of July, and 20003 on
|
||||
the 4th and expires on the 21st of July. A customer orders 6 boxes on the 5th of July. With the
|
||||
*FEFO* strategy selected, a transfer is requested for the five boxes of 20002 and one from 20001.
|
||||
The transfer for all the boxes of the lot 20002 is because they have the closest expiration date.
|
||||
The transfer also requests one box from 20001 because it’s the lot that expires the sooner after 20002.
|
||||
|
||||
Go to :menuselection:`Inventory --> Configuration --> Locations`,
|
||||
open the stock location and set **LIFO** removal strategy.
|
||||
Then, you can remember that for every order of a product with the *FEFO* strategy, a transfer is
|
||||
requested for the product that has the nearest expiration date from the order date.
|
||||
|
||||
In our example, let's check the current available stock of ``Ipod 32 Gb``
|
||||
on ``WH/Stock`` location.
|
||||
Use Removal Strategies
|
||||
======================
|
||||
|
||||
.. image:: media/removal06.png
|
||||
:align: center
|
||||
To identify some units from other ones, you need to track them, either by *lot* or by *serial number*.
|
||||
To do so, go to :menuselection:`Configuration --> Settings`. Then, activate *Storage Location*,
|
||||
*Multi-Steps Routes*, and *Lots & Serial Numbers*.
|
||||
|
||||
Create a sale order with ``10`` units of ``Ipod 32 Gb``.
|
||||
.. image:: media/enabled-features.png
|
||||
:align: center
|
||||
:alt: features to enable in order to properly use removal strategies.
|
||||
|
||||
You can see in the outgoing shipment product that the ``Ipod 32
|
||||
Gb`` are assigned with the **newest** lots, using the LIFO removal
|
||||
strategy.
|
||||
.. note::
|
||||
To work with the *FEFO* strategy, activate the *Expiration Dates* feature.
|
||||
|
||||
.. image:: media/removal07.png
|
||||
:align: center
|
||||
Next, you need to define your removal strategy, on *Product Categories* via
|
||||
:menuselection:`Inventory --> Configuration --> Product Categories`.
|
||||
|
||||
FEFO ( First Expiry First Out )
|
||||
--------------------------------
|
||||
.. image:: media/first-in-first-out.png
|
||||
:align: center
|
||||
:alt: force removal strategy set up as first in first out.
|
||||
|
||||
In FEFO warehouse management, the products are dispatched from the
|
||||
warehouse according to their expiration date.
|
||||
FIFO (First In, First Out)
|
||||
--------------------------
|
||||
|
||||
Go to :menuselection:`Inventory --> Configuration --> Setting`.
|
||||
Check the option **Define Expiration date on serial numbers**.
|
||||
Then click on **Apply** to save changes.
|
||||
As said, a *FIFO* strategy implies that products stocked first move out first. Companies should use
|
||||
that method if they are selling products with short demand cycles, such as clothes, and to ensure
|
||||
they are not stuck with outdated styles in stock.
|
||||
|
||||
.. image:: media/removal08.png
|
||||
:align: center
|
||||
For this example, we created three lots of white shirts. Those are from the All/Clothes category,
|
||||
where we put *FIFO* as the removal strategy. In our stock location (WH/Stock), we now find the
|
||||
three lots available.
|
||||
|
||||
This will allow you to set four expiration fields for each lot or serial number:
|
||||
**best before date**, **end of life date**, **alert date** and **removal date**.
|
||||
These dates can be set from :menuselection:`Inventory Control --> Serial Numbers/Lots`.
|
||||
.. image:: media/inventory-valuation.png
|
||||
:align: center
|
||||
:alt: view of the white shirt lots inventory valuation.
|
||||
|
||||
.. image:: media/removal09.png
|
||||
:align: center
|
||||
The lot 000001 contains 5 shirts, 000002 contains 3 shirts, and 000003 contains 2. As it can be
|
||||
seen above, 000001 has entered the stock first. Let’s create a sale order of six white shirts
|
||||
to check that products from that lot are the first ones to move out.
|
||||
|
||||
- **Best Before Date**: This is the date on which the goods with this
|
||||
serial/lot number start deteriorating, without being dangerous yet.
|
||||
On the delivery order linked to the picking, you can see that the oldest lot numbers have been
|
||||
reserved thanks to the *FIFO* strategy.
|
||||
|
||||
- **End of Life Date:** This is the date on which the goods with this
|
||||
serial/lot number may become dangerous and must not be consumed.
|
||||
.. image:: media/reserved-lots-FIFO.png
|
||||
:align: center
|
||||
:alt: two lots being reserved for sell with the FIFO strategy.
|
||||
|
||||
- **Removal Date:** This is the date on which the goods with this
|
||||
serial/lot number should be removed from the stock. Using the FEFO
|
||||
removal strategy goods are picked for delivery orders using this date.
|
||||
LIFO (Last In, First Out)
|
||||
-------------------------
|
||||
|
||||
- **Alert Date:** This is the date on which an alert should be sent
|
||||
about the goods with this serial/lot number.
|
||||
With a *LIFO* strategy, that’s quite the opposite. In fact, the products that are brought the
|
||||
last move out the first. It is mostly used in case of products without a shelf life.
|
||||
|
||||
Lots will be picked based on their **removal date**, from earliest
|
||||
to latest. Lots without a removal date defined will be picked after
|
||||
lots with removal dates.
|
||||
Even if our white shirts are clothes, we can say that they are timeless. So, let’s use them to
|
||||
test our *LIFO* strategy. Once again, open the product category via :menuselection:`Inventory
|
||||
--> Configuration --> Product Categories` and change the removal strategy to *LIFO*.
|
||||
|
||||
All dates except **removal date** are for informational and reporting purposes only.
|
||||
Lots that are past any or all of the above expiration dates may still be picked
|
||||
for delivery orders, and no alerts will be sent when lots pass their **alert date**.
|
||||
.. image:: media/last-in-first-out.png
|
||||
:align: center
|
||||
:alt: last in first out strategy set up as forced removal strategy.
|
||||
|
||||
Expiration dates on lots can also be set automatically when goods are received into stock.
|
||||
After enabling expiration dates on serial numbers, four new fields will become available
|
||||
in the inventory tab of the product form: **product life time**, **product use time**,
|
||||
**product removal time**, and **product alert time**. When an integer is entered into one
|
||||
of these fields, the expiration date of a lot/serial of the product in question will be set
|
||||
to the creation date of the lot/serial number plus the number of days entered in the time
|
||||
increment field. If the time increment field is set to zero, then the expiration date of
|
||||
a lot/serial must be defined manually after the lot has been created.
|
||||
Now, create a sale order for 4 white shirts and check that the reserved products are from lots
|
||||
000003 and 000002.
|
||||
|
||||
Each of these time increment fields is used to generate one of the lot expiration date fields as follows:
|
||||
.. image:: media/reserved-lots-LIFO.png
|
||||
:align: center
|
||||
:alt: two lots being reserved for sell with the LIFO strategy.
|
||||
|
||||
Product Use Time --> Best Before Date
|
||||
.. important::
|
||||
Don’t forget that the *LIFO* strategy is banned in many countries!
|
||||
|
||||
Product Removal Time --> Removal Date
|
||||
FEFO (First Expiry, First Out)
|
||||
------------------------------
|
||||
|
||||
Product Life Time --> End of Life Date
|
||||
With the *FEFO* strategy, the way products are picked is not based on the reception date. In this
|
||||
particular case, they are dispatched according to their expiration date.
|
||||
|
||||
Product Alert Time --> Alert Date
|
||||
.. note::
|
||||
To have more information about Expiration date, please have a look at
|
||||
:doc:`the related doc <../../management/lots_serial_numbers/expiration_dates>`.
|
||||
|
||||
To set the removal strategy on location, go to
|
||||
:menuselection:`Configuration --> Locations` and choose FEFO.
|
||||
By activating *Expiration Dates*, it becomes possible to define different dates on the serial/lot
|
||||
numbers to be used in *FEFO*. These dates can be set by going to :menuselection:`Inventory -->
|
||||
Master Data --> Lots/Serial Numbers`.
|
||||
|
||||
.. image:: media/removal10.png
|
||||
:align: center
|
||||
.. image:: media/removal-date.png
|
||||
:align: center
|
||||
:alt: view of the removal date for 0000001.
|
||||
|
||||
Let's take an example, there are ``3`` lots of ``ice cream`` available in
|
||||
``WH/Stock`` location: ``LOT0001``, ``LOT0002``, ``LOT0003`` with
|
||||
different expiration date.
|
||||
Lots are picked based on their removal date, from earliest to latest. Lots without a removal date
|
||||
defined are picked after lots with removal dates.
|
||||
|
||||
.. note::
|
||||
Other dates are for informational and reporting purposes only. If not removed from the stock,
|
||||
lots that are past the expiration dates may still be picked for delivery orders!
|
||||
|
||||
To use the *FEFO* strategy, once again go to :menuselection:`Inventory --> Configuration -->
|
||||
Product Categories` and choose *FEFO* as the *Force Removal Strategy*.
|
||||
|
||||
.. image:: media/first-expiry-first-out.png
|
||||
:align: center
|
||||
:alt: view of the FEFO strategy being set up as forced removal strategy.
|
||||
|
||||
For this particular case, let’s use hand cream. As usual, we have three lots of them.
|
||||
|
||||
+-----------------------+---------------+-----------------------+
|
||||
| **Lot / Serial No** | **Product** | **Expiration Date** |
|
||||
+=======================+===============+=======================+
|
||||
| LOT0001 | Ice Cream | 08/20/2015 |
|
||||
| 0000001 | Hand Cream | 09/30/2019 |
|
||||
+-----------------------+---------------+-----------------------+
|
||||
| LOT0002 | Ice Cream | 08/10/2015 |
|
||||
| 0000002 | Hand Cream | 11/30/2019 |
|
||||
+-----------------------+---------------+-----------------------+
|
||||
| LOT0003 | Ice Cream | 08/15/2015 |
|
||||
| 0000003 | Hand Cream | 10/31/2019 |
|
||||
+-----------------------+---------------+-----------------------+
|
||||
|
||||
We will create a sale order with ``15kg`` of ``ice cream`` and confirm it.
|
||||
When we realize a sale for 25 units of Hand Cream, we can see that the lot numbers which have been
|
||||
automatically reserved by Odoo are the ones with the closest expiration date, meaning 0000001 and
|
||||
0000003.
|
||||
|
||||
The outgoing shipment related to sale order will make the move based on
|
||||
removal strategy **FEFO**.
|
||||
|
||||
It will take ``10kg`` from ``LOT0002`` and ``5kg`` from ``LOT0003`` based on the
|
||||
removal dates.
|
||||
|
||||
.. image:: media/removal11.png
|
||||
:align: center
|
||||
|
||||
.. seealso::
|
||||
|
||||
* :doc:`../../management/reporting/inventory_valuation_config`
|
||||
.. image:: media/reserved-hand-cream.png
|
||||
:align: center
|
||||
:alt: two hand cream lots reserved for sell with the FEFO strategy.
|
@ -204,6 +204,16 @@ You can also open terminals, Python consoles and even Odoo Shell consoles.
|
||||
You can open multiple tabs and drag-and-drop them to arrange the layout as you wish,
|
||||
for instance side by side.
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
This link contains various monitoring metrics of the current build.
|
||||
|
||||
.. image:: ./media/interface-branches-monitoring.png
|
||||
:align: center
|
||||
|
||||
You can zoom, change the time range or select a specific metric on each graph.
|
||||
On the graphs, annotations help you relate to changes on the build (database import, git push, etc...).
|
||||
|
||||
Logs
|
||||
----
|
||||
A viewer to have a look to your server logs.
|
||||
|
BIN
odoo_sh/getting_started/media/interface-branches-monitoring.png
Normal file
After Width: | Height: | Size: 84 KiB |
@ -72,6 +72,8 @@ In addition, they cannot use the webshell nor have access to the server logs.
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Mails | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Monitoring | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Backups | | X |
|
||||
+---------------------+-----------------+-----------+-----------+
|
||||
| | Settings | X | X |
|
||||
|
@ -11,6 +11,7 @@ Practical Information
|
||||
db_management/db_online
|
||||
db_management/db_premise
|
||||
db_management/hosting_changes
|
||||
db_management/db_upgrade
|
||||
portal/my_odoo_portal
|
||||
support
|
||||
legal
|
||||
|
@ -157,8 +157,6 @@ helpdesk/close_tickets.rst helpdesk/advanced/close_tickets.rst
|
||||
helpdesk/invoice_time.rst helpdesk/timesheet_and_invoice/invoice_time.rst # (#565)
|
||||
helpdesk/reinvoice_from_project.rst helpdesk/timesheet_and_invoice/reinvoice_from_project.rst # (#565)
|
||||
|
||||
# Redirections introduced in 13.3 :
|
||||
|
||||
planning/duplicate_a_planning.rst planning/overview/duplicate_a_planning.rst # (#567)
|
||||
planning/send_planned_shifts.rst planning/overview/send_planned_shifts.rst # (#567)
|
||||
|
||||
@ -175,8 +173,10 @@ discuss/plan_activities.rst discuss/overview/plan_activities.rst # (#6
|
||||
discuss/team_communication.rst discuss/overview/team_communication.rst # (#655)
|
||||
discuss/overview.rst discuss/overview/get_started.rst # (#655)
|
||||
|
||||
crm/optimize/onsip.rst general/voip/onsip.rst # crm/optimize/* --> general/voip/*
|
||||
crm/optimize/setup.rst general/voip/asterisk.rst # crm/optimize/setup --> general/voip/asterisk
|
||||
|
||||
# Redirections introduced in 14.0 :
|
||||
|
||||
crm/optimize/mail_client_extension.rst crm/optimize/outlook_extension.rst # mail_client_extension -> outlook_extension | mail_client_extension is the first link provided as a tip in Odoo 14 but should be updated and point directly to outlook_extension
|
||||
|
||||
crm/optimize/google_calendar_credentials.rst general/calendars/google/google_calendar_credentials.rst # (#765)
|
||||
|
10
sign.rst
Normal file
@ -0,0 +1,10 @@
|
||||
:banner: banners/sign.png
|
||||
|
||||
====
|
||||
Sign
|
||||
====
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
sign/overview
|
8
sign/overview.rst
Normal file
@ -0,0 +1,8 @@
|
||||
========
|
||||
Overview
|
||||
========
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
overview/signature_validity
|
60
sign/overview/signature_validity.rst
Normal file
@ -0,0 +1,60 @@
|
||||
=================================
|
||||
Validity of electronic signatures
|
||||
=================================
|
||||
|
||||
The legal validity of electronic signatures generated by Odoo depends on the legislation of your
|
||||
country. Companies doing business abroad should consider electronic signature laws of other
|
||||
countries as well.
|
||||
|
||||
In the European Union
|
||||
=====================
|
||||
|
||||
The `eIDAS regulation <http://data.europa.eu/eli/reg/2014/910/oj>`_ establishes the framework for
|
||||
electronic signatures in all `27 member states of the European Union
|
||||
<https://europa.eu/european-union/about-eu/countries_en>`_.
|
||||
|
||||
It distinguishes three types of electronic signatures:
|
||||
|
||||
#. Electronic signatures
|
||||
#. Advanced electronic signatures
|
||||
#. Qualified electronic signatures
|
||||
|
||||
Odoo generates the first type, regular electronic signatures, and these signatures can produce legal
|
||||
effects in the EU, as the regulation states that “an electronic signature shall not be denied legal
|
||||
effect and admissibility as evidence in legal proceedings solely on the grounds that it is in an
|
||||
electronic form or that it does not meet the requirements for qualified electronic signatures.”
|
||||
|
||||
Note that electronic signatures may not be automatically recognized as valid. You may need to bring
|
||||
supporting evidence of a signature’s validity.
|
||||
|
||||
In the United States of America
|
||||
===============================
|
||||
|
||||
The `ESIGN Act (Electronic Signatures in Global and National Commerce Act)
|
||||
<https://www.fdic.gov/regulations/compliance/manual/10/X-3.1.pdf>`_, at the interstate and
|
||||
international levels, and the `UETA (Uniform Electronic Transactions Act)
|
||||
<https://www.uniformlaws.org/committees/community-home/librarydocuments?communitykey=2c04b76c-2b7d-4399-977e-d5876ba7e034&tab=librarydocuments>`_,
|
||||
at the state level, provide the legal framework for electronic signatures. Note that `Illinois
|
||||
<https://www.ilga.gov/legislation/ilcs/ilcs5.asp?ActID=89&>`_ and `New York
|
||||
<https://its.ny.gov/electronic-signatures-and-records-act-esra>`_ have not adopted the UETA, but
|
||||
similar acts instead.
|
||||
|
||||
Overall, to be recognized as valid, electronic signatures have to meet five criteria:
|
||||
|
||||
#. A signer must show a clear intent to sign. For example, using a mouse to draw a signature can
|
||||
show intent. The signer must also have the option to opt-out of electronically signing a
|
||||
document.
|
||||
#. A signer must first express or imply their consent to conduct business electronically.
|
||||
#. The signature must be clearly attributed. In Odoo, metadata, such as the signer’s IP address, is
|
||||
added to the signature, which can be used as supporting evidence.
|
||||
#. The signature must be associated with the document being signed, for example, by keeping a record
|
||||
detailing how the signature was captured.
|
||||
#. Electronically signed documents need to be retained and available for later reference by all
|
||||
parties involved, for example, by providing the signer either a fully-executed copy or the option
|
||||
to download a copy.
|
||||
|
||||
.. note::
|
||||
The information provided here does not constitute legal advice; it is provided for general
|
||||
informational purposes only. As laws governing electronic signatures evolve rapidly, we cannot
|
||||
guarantee that the information is up to date. We advise you to should contact a local attorney to
|
||||
obtain legal advice.
|