[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
|
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
|
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
|
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
|
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
|
Once the payments are processed by your bank, you can directly import
|
||||||
the account statement inside Odoo. The bank reconciliation process will
|
the account statement inside Odoo. The bank reconciliation process will
|
||||||
@ -113,7 +117,8 @@ Troubleshooting
|
|||||||
The bank refuses my SEPA file
|
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
|
they don't, or cannot provide relevant informations, please forward the
|
||||||
error message to your Odoo partner.
|
error message to your Odoo partner.
|
||||||
|
|
||||||
|
@ -18,6 +18,7 @@ Applications
|
|||||||
bi
|
bi
|
||||||
documents
|
documents
|
||||||
fsm
|
fsm
|
||||||
|
sign
|
||||||
point_of_sale
|
point_of_sale
|
||||||
inventory
|
inventory
|
||||||
manufacturing
|
manufacturing
|
||||||
@ -62,6 +63,7 @@ Applications
|
|||||||
timesheets
|
timesheets
|
||||||
planning
|
planning
|
||||||
fsm
|
fsm
|
||||||
|
sign
|
||||||
point_of_sale
|
point_of_sale
|
||||||
inventory
|
inventory
|
||||||
manufacturing
|
manufacturing
|
||||||
|
@ -524,8 +524,8 @@ build your tables. Then, copy-paste the generated formatting into your document.
|
|||||||
|
|
||||||
.. _contributing/specialized-directives:
|
.. _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:
|
Use these additional directives to fine-tune your content:
|
||||||
|
|
||||||
|
@ -7,6 +7,4 @@ Optimize your Day-to-Day work
|
|||||||
|
|
||||||
optimize/partner_autocomplete
|
optimize/partner_autocomplete
|
||||||
optimize/outlook_extension
|
optimize/outlook_extension
|
||||||
optimize/onsip
|
|
||||||
optimize/setup
|
|
||||||
optimize/gamification
|
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/multi_companies
|
||||||
general/auth
|
general/auth
|
||||||
general/payment_acquirers
|
general/payment_acquirers
|
||||||
|
general/voip
|
||||||
general/calendars
|
general/calendars
|
||||||
general/in_app_purchase
|
general/in_app_purchase
|
||||||
general/developer_mode
|
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
|
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
|
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
|
When a product movement needs to be done, Odoo finds available products that can be assigned to
|
||||||
products in order to optimize the distance for the worker, for quality
|
the transfer. The way Odoo assigns these products depends on the *Removal Strategy* defined in
|
||||||
control purpose or due to reason of product expiration.
|
the *Product Category* or on the *Location*.
|
||||||
|
|
||||||
When a product movement needs to be done, Odoo will find available
|
What happens inside the warehouse?
|
||||||
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**.
|
|
||||||
|
|
||||||
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
|
.. image:: media/empty-dock.png
|
||||||
--> Settings`:
|
:align: center
|
||||||
|
:alt: empty stock waiting for deliveries at the docks.
|
||||||
|
|
||||||
.. image:: media/removal01.png
|
Here, vendor trucks unload pallets of goods at the docks. Then, operators scan the products in the
|
||||||
:align: center
|
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
|
.. image:: media/entering-stocks.png
|
||||||
:align: center
|
:align: center
|
||||||
|
:alt: products entering stock via the receiving area.
|
||||||
|
|
||||||
Check **Track lots or serial numbers**, **Manage several location per
|
Next, several orders for the same product are made, but you didn’t receive the goods the same day
|
||||||
warehouse** and **Advanced routing of products using rules**, then click
|
and they don’t have the same expiration date. In that situation, you logically prefer sending those
|
||||||
on **Apply**.
|
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`
|
.. image:: media/packing-products.png
|
||||||
and open the location on which you want to apply a removal strategy.
|
:align: center
|
||||||
|
:alt: products being packed at packing area for delivery, taking expiration dates into account.
|
||||||
|
|
||||||
.. image:: media/removal03.png
|
.. note::
|
||||||
:align: center
|
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
|
When using a **First In, First Out** strategy, a demand for some products triggers a removal rule
|
||||||
stocked first will move out first. Companies should use FIFO method if
|
which requests a transfer for the lot/serial number that has entered your stock the first.
|
||||||
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.
|
|
||||||
|
|
||||||
Go to :menuselection:`Inventory --> Configuration --> Locations`,
|
To be clearer, let’s imagine that you have three lots of nails in your warehouse. Those three have
|
||||||
open the stock location and set **FIFO** removal strategy.
|
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
|
Last In, First Out (LIFO)
|
||||||
32 Gb`` available.
|
-------------------------
|
||||||
|
|
||||||
You can find details of available inventory in inventory valuation
|
The same way as for FIFO, the **Last In, First Out** strategy is based on moving products based on the
|
||||||
report.
|
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
|
To better understand, let’s imagine three lots of screws in your warehouse. Those three have the
|
||||||
:align: center
|
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
|
.. note::
|
||||||
Gb`` are assigned with the **oldest** lots, using the FIFO removal
|
This strategy is banned in many countries and can lead to only have old or obsolete products
|
||||||
strategy.
|
in your stock.
|
||||||
|
|
||||||
.. image:: media/removal05.png
|
First Expire, First Out (FEFO)
|
||||||
:align: center
|
------------------------------
|
||||||
|
|
||||||
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
|
Let’s imagine three lots of 6-eggs boxes (in this specific case, don’t forget to use
|
||||||
last, moves out the first. LIFO is used in case of products which do not
|
:doc:`units of measure <../../management/products/uom>`). Those three have the following numbers:
|
||||||
have a shelf life.
|
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`,
|
Then, you can remember that for every order of a product with the *FEFO* strategy, a transfer is
|
||||||
open the stock location and set **LIFO** removal strategy.
|
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``
|
Use Removal Strategies
|
||||||
on ``WH/Stock`` location.
|
======================
|
||||||
|
|
||||||
.. image:: media/removal06.png
|
To identify some units from other ones, you need to track them, either by *lot* or by *serial number*.
|
||||||
:align: center
|
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
|
.. note::
|
||||||
Gb`` are assigned with the **newest** lots, using the LIFO removal
|
To work with the *FEFO* strategy, activate the *Expiration Dates* feature.
|
||||||
strategy.
|
|
||||||
|
|
||||||
.. image:: media/removal07.png
|
Next, you need to define your removal strategy, on *Product Categories* via
|
||||||
:align: center
|
: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
|
FIFO (First In, First Out)
|
||||||
warehouse according to their expiration date.
|
--------------------------
|
||||||
|
|
||||||
Go to :menuselection:`Inventory --> Configuration --> Setting`.
|
As said, a *FIFO* strategy implies that products stocked first move out first. Companies should use
|
||||||
Check the option **Define Expiration date on serial numbers**.
|
that method if they are selling products with short demand cycles, such as clothes, and to ensure
|
||||||
Then click on **Apply** to save changes.
|
they are not stuck with outdated styles in stock.
|
||||||
|
|
||||||
.. image:: media/removal08.png
|
For this example, we created three lots of white shirts. Those are from the All/Clothes category,
|
||||||
:align: center
|
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:
|
.. image:: media/inventory-valuation.png
|
||||||
**best before date**, **end of life date**, **alert date** and **removal date**.
|
:align: center
|
||||||
These dates can be set from :menuselection:`Inventory Control --> Serial Numbers/Lots`.
|
:alt: view of the white shirt lots inventory valuation.
|
||||||
|
|
||||||
.. image:: media/removal09.png
|
The lot 000001 contains 5 shirts, 000002 contains 3 shirts, and 000003 contains 2. As it can be
|
||||||
:align: center
|
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
|
On the delivery order linked to the picking, you can see that the oldest lot numbers have been
|
||||||
serial/lot number start deteriorating, without being dangerous yet.
|
reserved thanks to the *FIFO* strategy.
|
||||||
|
|
||||||
- **End of Life Date:** This is the date on which the goods with this
|
.. image:: media/reserved-lots-FIFO.png
|
||||||
serial/lot number may become dangerous and must not be consumed.
|
: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
|
LIFO (Last In, First Out)
|
||||||
serial/lot number should be removed from the stock. Using the FEFO
|
-------------------------
|
||||||
removal strategy goods are picked for delivery orders using this date.
|
|
||||||
|
|
||||||
- **Alert Date:** This is the date on which an alert should be sent
|
With a *LIFO* strategy, that’s quite the opposite. In fact, the products that are brought the
|
||||||
about the goods with this serial/lot number.
|
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
|
Even if our white shirts are clothes, we can say that they are timeless. So, let’s use them to
|
||||||
to latest. Lots without a removal date defined will be picked after
|
test our *LIFO* strategy. Once again, open the product category via :menuselection:`Inventory
|
||||||
lots with removal dates.
|
--> Configuration --> Product Categories` and change the removal strategy to *LIFO*.
|
||||||
|
|
||||||
All dates except **removal date** are for informational and reporting purposes only.
|
.. image:: media/last-in-first-out.png
|
||||||
Lots that are past any or all of the above expiration dates may still be picked
|
:align: center
|
||||||
for delivery orders, and no alerts will be sent when lots pass their **alert date**.
|
: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.
|
Now, create a sale order for 4 white shirts and check that the reserved products are from lots
|
||||||
After enabling expiration dates on serial numbers, four new fields will become available
|
000003 and 000002.
|
||||||
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.
|
|
||||||
|
|
||||||
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
|
By activating *Expiration Dates*, it becomes possible to define different dates on the serial/lot
|
||||||
:menuselection:`Configuration --> Locations` and choose FEFO.
|
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
|
.. image:: media/removal-date.png
|
||||||
:align: center
|
:align: center
|
||||||
|
:alt: view of the removal date for 0000001.
|
||||||
|
|
||||||
Let's take an example, there are ``3`` lots of ``ice cream`` available in
|
Lots are picked based on their removal date, from earliest to latest. Lots without a removal date
|
||||||
``WH/Stock`` location: ``LOT0001``, ``LOT0002``, ``LOT0003`` with
|
defined are picked after lots with removal dates.
|
||||||
different expiration date.
|
|
||||||
|
.. 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** |
|
| **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
|
.. image:: media/reserved-hand-cream.png
|
||||||
removal strategy **FEFO**.
|
:align: center
|
||||||
|
:alt: two hand cream lots reserved for sell with the FEFO strategy.
|
||||||
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`
|
|
@ -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,
|
You can open multiple tabs and drag-and-drop them to arrange the layout as you wish,
|
||||||
for instance side by side.
|
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
|
Logs
|
||||||
----
|
----
|
||||||
A viewer to have a look to your server 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 |
|
| | Mails | | X |
|
||||||
+---------------------+-----------------+-----------+-----------+
|
+---------------------+-----------------+-----------+-----------+
|
||||||
|
| | Monitoring | | X |
|
||||||
|
+---------------------+-----------------+-----------+-----------+
|
||||||
| | Backups | | X |
|
| | Backups | | X |
|
||||||
+---------------------+-----------------+-----------+-----------+
|
+---------------------+-----------------+-----------+-----------+
|
||||||
| | Settings | X | X |
|
| | Settings | X | X |
|
||||||
|
@ -11,6 +11,7 @@ Practical Information
|
|||||||
db_management/db_online
|
db_management/db_online
|
||||||
db_management/db_premise
|
db_management/db_premise
|
||||||
db_management/hosting_changes
|
db_management/hosting_changes
|
||||||
|
db_management/db_upgrade
|
||||||
portal/my_odoo_portal
|
portal/my_odoo_portal
|
||||||
support
|
support
|
||||||
legal
|
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/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)
|
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/duplicate_a_planning.rst planning/overview/duplicate_a_planning.rst # (#567)
|
||||||
planning/send_planned_shifts.rst planning/overview/send_planned_shifts.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/team_communication.rst discuss/overview/team_communication.rst # (#655)
|
||||||
discuss/overview.rst discuss/overview/get_started.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 :
|
# 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/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)
|
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.
|