Compare commits
207 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| 7d43958d7b | |||
| b84e81d3a1 | |||
| 4f098945d7 | |||
| 86fac322d3 | |||
| 958fa599e1 | |||
| 0604fb56f9 | |||
| 3fe09dd653 | |||
| 06eaf3a0c7 | |||
| 14c0438764 | |||
| db3db3c727 | |||
| 1be6f341dd | |||
| 39541bb745 | |||
| 157c1e18ea | |||
| ab5c9feb40 | |||
| 6c3385cf90 | |||
| b53427ddde | |||
| e6dbd3d9e4 | |||
| 646bfe2e2c | |||
| e620f27378 | |||
| f10c8d4ad2 | |||
| b4cab2a3db | |||
| 999c8db465 | |||
| 6ec9eb1fcc | |||
| baab56946f | |||
| 73499c595e | |||
| 2c1277d0f7 | |||
| fc98af5814 | |||
| d0b7363de5 | |||
| 65f1e3ce0a | |||
| a48ebe55bf | |||
| 3d28850a40 | |||
| 83a68e4b9b | |||
| be60243eff | |||
| d07052aa57 | |||
| b89d3e56c2 | |||
| 8d87bfe462 | |||
| b72d340b3c | |||
| a197b6c57d | |||
| f0cf3c68ac | |||
| 1f31ba3f06 | |||
| 2f0d98c9f7 | |||
| 4210a31408 | |||
| 080dc64e54 | |||
| 95f8067ed5 | |||
| f453b2266f | |||
| d88b185c27 | |||
| 62a4db0c7d | |||
| de2999c01d | |||
| 494ae5a555 | |||
| 283c843eeb | |||
| b0cc13d4fe | |||
| 6016ed4e93 | |||
| 6c561112a8 | |||
| 7a8f551d67 | |||
| 67adf2fc3b | |||
| 6f3ca9f4a3 | |||
| d1836f349f | |||
| e765370016 | |||
| 15beccfd50 | |||
| cec2e1f322 | |||
| 9cb186f87b | |||
| 075eea9326 | |||
| b5507c4940 | |||
| 64fabeb801 | |||
| 6667e3ec35 | |||
| 7b917cd1c3 | |||
| 884c1b3126 | |||
| b339573354 | |||
| 668420655f | |||
| abb3589471 | |||
| 588801185a | |||
| 78d1f23686 | |||
| e72b21d734 | |||
| 5ff951e927 | |||
| 78b3ca7521 | |||
| 9e3cb9eeaf | |||
| 9115d5d7a4 | |||
| c5b4336b52 | |||
| 78d289c677 | |||
| 14a9073ac9 | |||
| 4eb1baa5c5 | |||
| a2fbef0bc9 | |||
| 0f8e20e0aa | |||
| dfc42d4b62 | |||
| 5bd89e30b9 | |||
| 35602b9f50 | |||
| 79fa32eb3d | |||
| 3905b642fa | |||
| 5b581c31a5 | |||
| 90fffd3039 | |||
| 6fb216f70d | |||
| d4eece9b5f | |||
| 52e107681a | |||
| be6f7e1662 | |||
| 28f9d0c02c | |||
| 643ec40050 | |||
| 629a2852b6 | |||
| 77c1f6ff95 | |||
| 045fb847e8 | |||
| b963e4c7f9 | |||
| 3a3a224b17 | |||
| 86bd9fd91b | |||
| 6935a84404 | |||
| 31387885d6 | |||
| f8dce88995 | |||
| 78d998f5fc | |||
| 3ef14b8254 | |||
| 6d219133e0 | |||
| 2a52e0979b | |||
| f72e7a25e0 | |||
| c21233db05 | |||
| 5d7abe69ac | |||
| f18c11cb41 | |||
| 8c4cb060f0 | |||
| 07e7787668 | |||
| d4b8665fe2 | |||
| 3e7c00af02 | |||
| eff6545537 | |||
| 41cdeab0fa | |||
| 630d4385f4 | |||
| 30b173ff25 | |||
| 620b50f9e2 | |||
| 7612732f7f | |||
| f08db8544a | |||
| de4795724b | |||
| 556b5c4bc3 | |||
| 0c162ecf18 | |||
| 922f540fa6 | |||
| 1defbf7383 | |||
| fd3f3ca5cf | |||
| f10dcbdaf6 | |||
| 883442e483 | |||
| 41442270a3 | |||
| 58d246b8f4 | |||
| eb0c42803d | |||
| 2b8a578c9b | |||
| c27c6f8928 | |||
| 0a2b5e76e1 | |||
| 37af135d31 | |||
| b093bdc871 | |||
| 392d99c2fb | |||
| 38f66dd0f9 | |||
| 688285086b | |||
| 5264899901 | |||
| 70a99d8f87 | |||
| d5f2bf3b8c | |||
| 9be26ea17a | |||
| 48321d0e6b | |||
| 8e548bf770 | |||
| 6fd7446ad9 | |||
| 0dd8974ca1 | |||
| 4cad0e2f82 | |||
| 1a412b334a | |||
| e96721a308 | |||
| 829eb7b851 | |||
| d0af3f6bd1 | |||
| b2a37a0129 | |||
| a7e8e9724a | |||
| a70258c823 | |||
| 16e10c53db | |||
| 4219829976 | |||
| c2190a438c | |||
| 5b44376e52 | |||
| 7067cf372a | |||
| ebbd736540 | |||
| 4fe046b9d0 | |||
| 07c50eae7a | |||
| 671cca36a6 | |||
| 246450c957 | |||
| cc37e41de0 | |||
| 6cff316d86 | |||
| 03c9226547 | |||
| d87112ddef | |||
| 6605ec1988 | |||
| d105f614af | |||
| 10f936247a | |||
| 6a198ad1ce | |||
| 7dc0dc37d2 | |||
| 09e0b8affc | |||
| f3a6cc6779 | |||
| 36b20ff16c | |||
| 068020901c | |||
| 6da7dcccea | |||
| 48679b52e9 | |||
| f85a667236 | |||
| 44f202cff9 | |||
| 4b1b3db6f2 | |||
| db2ee387a9 | |||
| f7cb830798 | |||
| 86bd83705d | |||
| b4eaf1c223 | |||
| 5ec7aff3c5 | |||
| 49ad6221a8 | |||
| 32441c88fc | |||
| 89539f7379 | |||
| 4d88c4ec20 | |||
| 66b08cd4fd | |||
| 4e6983c135 | |||
| f53aca7b32 | |||
| cdc510295c | |||
| 86207443b1 | |||
| d25eecbe13 | |||
| dd6bf8b6c7 | |||
| d53c676288 | |||
| dbb82d83e2 | |||
| a8ef31f215 | |||
| a3e1378919 |
@@ -1,63 +1,122 @@
|
||||
[main]
|
||||
host = https://www.transifex.com
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:administration]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/administration.po
|
||||
source_file = locale/sources/administration.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:administration]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/administration.po
|
||||
source_file = locale/sources/administration.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = administration
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:applications]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/applications.po
|
||||
source_file = locale/sources/applications.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:applications]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/applications.po
|
||||
source_file = locale/sources/applications.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = applications
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:finance]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/finance.po
|
||||
source_file = locale/sources/finance.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:finance]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/finance.po
|
||||
source_file = locale/sources/finance.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = finance
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:general]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/general.po
|
||||
source_file = locale/sources/general.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:general]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/general.po
|
||||
source_file = locale/sources/general.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = general
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:index]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/index.po
|
||||
source_file = locale/sources/index.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:index]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/index.po
|
||||
source_file = locale/sources/index.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = index
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:inventory_and_mrp]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/inventory_and_mrp.po
|
||||
source_file = locale/sources/inventory_and_mrp.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:inventory_and_mrp]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/inventory_and_mrp.po
|
||||
source_file = locale/sources/inventory_and_mrp.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = inventory_and_mrp
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:marketing]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/marketing.po
|
||||
source_file = locale/sources/marketing.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:marketing]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/marketing.po
|
||||
source_file = locale/sources/marketing.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = marketing
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:productivity]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/productivity.po
|
||||
source_file = locale/sources/productivity.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:productivity]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/productivity.po
|
||||
source_file = locale/sources/productivity.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = productivity
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:sales]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/sales.po
|
||||
source_file = locale/sources/sales.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:sales]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/sales.po
|
||||
source_file = locale/sources/sales.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = sales
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:services]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/services.po
|
||||
source_file = locale/sources/services.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:services]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/services.po
|
||||
source_file = locale/sources/services.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = services
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:user_settings]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/settings.po
|
||||
source_file = locale/sources/settings.pot
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-16-doc:r:websites]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/websites.po
|
||||
source_file = locale/sources/websites.pot
|
||||
source_lang = en
|
||||
[o:odoo:p:odoo-17-doc:r:user_settings]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/settings.po
|
||||
source_file = locale/sources/settings.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = settings
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
[o:odoo:p:odoo-17-doc:r:websites]
|
||||
file_filter = locale/<lang>/LC_MESSAGES/websites.po
|
||||
source_file = locale/sources/websites.pot
|
||||
type = POT
|
||||
minimum_perc = 0
|
||||
resource_name = websites
|
||||
replace_edited_strings = false
|
||||
keep_translations = false
|
||||
source_lang = en
|
||||
|
||||
@@ -86,12 +86,13 @@ static: $(HTML_BUILD_DIR)/_static/style.css
|
||||
|
||||
# Called by runbot for the ci/documentation_guideline check.
|
||||
test:
|
||||
@python tests/main.py $(SOURCE_DIR)/administration $(SOURCE_DIR)/applications $(SOURCE_DIR)/contributing $(SOURCE_DIR)/developer $(SOURCE_DIR)/services redirects
|
||||
@python tests/main.py $(SOURCE_DIR)/administration $(SOURCE_DIR)/applications $(SOURCE_DIR)/contributing $(SOURCE_DIR)/developer redirects
|
||||
|
||||
# Similar as `test`, but called only manually by content reviewers to trigger extra checks.
|
||||
review:
|
||||
@read -p "Enter content path: " path; read -p "Enter max line length (default: 100): " line_length; \
|
||||
@read -p "Enter relative content path: " path; read -p "Enter max line length (default: 100): " line_length; \
|
||||
if [ -z "$$path" ]; then echo "Error: Path cannot be empty"; exit 1; fi; \
|
||||
if echo $$path | grep -q 'content/'; then path=`echo $$path | sed 's|content/||'`; fi; \
|
||||
if [ -z "$$line_length" ]; then line_length=100; fi; \
|
||||
export REVIEW=1; \
|
||||
python tests/main.py --max-line-length=$$line_length $(SOURCE_DIR)/$$path
|
||||
|
||||
@@ -213,6 +213,7 @@ sphinx.transforms.i18n.docname_to_domain = (
|
||||
# is populated. If a version is passed to `versions` but is not listed here, it will not be shown.
|
||||
versions_names = {
|
||||
'master': "Master",
|
||||
'17.0': "Odoo 17",
|
||||
'saas-16.4': "Odoo Online",
|
||||
'saas-16.3': "Odoo Online",
|
||||
'saas-16.2': "Odoo Online",
|
||||
@@ -221,7 +222,6 @@ versions_names = {
|
||||
'saas-15.2': "Odoo Online",
|
||||
'15.0': "Odoo 15",
|
||||
'14.0': "Odoo 14",
|
||||
'13.0': "Odoo 13",
|
||||
}
|
||||
|
||||
# The language names that should be shown in the language switcher, if the config option `languages`
|
||||
@@ -478,8 +478,24 @@ def _generate_alternate_urls(app, pagename, templatename, context, doctree):
|
||||
_version = _version or app.config.version
|
||||
_lang = _lang or app.config.language or 'en'
|
||||
_canonical_page = f'{pagename}.html'
|
||||
|
||||
# legal translations have different URLs schemes as they are not managed on transifex
|
||||
# e.g. FR translation of /terms/enterprise => /fr/terms/enterprise_fr
|
||||
if pagename.startswith('legal/terms/'):
|
||||
if _lang in legal_translations and not pagename.endswith(f"_{_lang}"):
|
||||
# remove language code for current translation, set target one
|
||||
_page = re.sub("_[a-z]{2}$", "", pagename)
|
||||
if 'terms/i18n' not in _page:
|
||||
_page = _page.replace("/terms/", "/terms/i18n/")
|
||||
_canonical_page = f'{_page}_{_lang}.html'
|
||||
elif _lang == 'en' and pagename.endswith(tuple(f"_{l}" for l in legal_translations)):
|
||||
# remove language code for current translation, link to original EN one
|
||||
_page = re.sub("_[a-z]{2}$", "", pagename)
|
||||
_canonical_page = f'{_page.replace("/i18n/", "/")}.html'
|
||||
|
||||
if app.config.is_remote_build:
|
||||
_canonical_page = _canonical_page.replace('index.html', '')
|
||||
|
||||
return f'{_root}' \
|
||||
f'{f"/{_version}" if app.config.versions else ""}' \
|
||||
f'{f"/{_lang}" if _lang != "en" else ""}' \
|
||||
|
||||
@@ -47,3 +47,4 @@ functionalities, including functional support, upgrades, and hosting. `Pricing
|
||||
install/deploy
|
||||
install/cdn
|
||||
install/email_gateway
|
||||
install/geo_ip
|
||||
|
||||
@@ -330,7 +330,7 @@ in ``/etc/nginx/sites-enabled/odoo.conf`` set:
|
||||
proxy_pass http://odoochat;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection $connection_upgrade;
|
||||
proxy_set_header X-Forwarded-Host $host;
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
@@ -339,7 +339,7 @@ in ``/etc/nginx/sites-enabled/odoo.conf`` set:
|
||||
# Redirect requests to odoo backend server
|
||||
location / {
|
||||
# Add Headers for odoo proxy mode
|
||||
proxy_set_header X-Forwarded-Host $host;
|
||||
proxy_set_header X-Forwarded-Host $http_host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
@@ -439,51 +439,71 @@ Odoo static files are located in each module's :file:`static/` folder, so static
|
||||
by intercepting all requests to :samp:`/{MODULE}/static/{FILE}`, and looking up the right module
|
||||
(and file) in the various addons paths.
|
||||
|
||||
.. example::
|
||||
Say Odoo has been installed via the **debian packages** for Community and Enterprise and the
|
||||
:option:`--addons-path <odoo-bin --addons-path>` is ``'/usr/lib/python3/dist-packages/odoo/addons'``.
|
||||
It is recommended to set the ``Content-Security-Policy: default-src 'none'`` header on all images
|
||||
delivered by the web server. It is not strictly necessary as users cannot modify/inject content
|
||||
inside of modules' :file:`static/` folder and existing images are final (they do not fetch new
|
||||
resources by themselves). However, it is good practice.
|
||||
|
||||
Using the above NGINX (https) configuration, the following location block should be added to
|
||||
serve static files via NGINX.
|
||||
Using the above NGINX (https) configuration, the following ``map`` and ``location`` blocks should be
|
||||
added to serve static files via NGINX.
|
||||
|
||||
.. code-block:: nginx
|
||||
.. code-block:: nginx
|
||||
|
||||
location @odoo {
|
||||
# copy-paste the content of the / location block
|
||||
}
|
||||
map $sent_http_content_type $content_type_csp {
|
||||
default "";
|
||||
~image/ "default-src 'none'";
|
||||
}
|
||||
|
||||
# Serve static files right away
|
||||
location ~ ^/[^/]+/static/.+$ {
|
||||
root /usr/lib/python3/dist-packages/odoo/addons;
|
||||
try_files $uri @odoo;
|
||||
expires 24h;
|
||||
}
|
||||
server {
|
||||
# the rest of the configuration
|
||||
|
||||
location @odoo {
|
||||
# copy-paste the content of the / location block
|
||||
}
|
||||
|
||||
# Serve static files right away
|
||||
location ~ ^/[^/]+/static/.+$ {
|
||||
# root and try_files both depend on your addons paths
|
||||
root ...;
|
||||
try_files ... @odoo;
|
||||
expires 24h;
|
||||
add_header Content-Security-Policy $content_type_csp;
|
||||
}
|
||||
}
|
||||
|
||||
The actual ``root`` and ``try_files`` directives are dependant on your installation, specifically on
|
||||
your :option:`--addons-path <odoo-bin --addons-path>`.
|
||||
|
||||
.. example::
|
||||
Say Odoo has been installed via the **source**. The two git repositories for Community and
|
||||
Enterprise have been cloned in :file:`/opt/odoo/community` and :file:`/opt/odoo/enterprise`
|
||||
respectively and the :option:`--addons-path <odoo-bin --addons-path>` is
|
||||
``'/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'``.
|
||||
|
||||
Using the above NGINX (https) configuration, the following location block should be added to
|
||||
serve static files via NGINX.
|
||||
.. tabs::
|
||||
|
||||
.. code-block:: nginx
|
||||
.. group-tab:: Debian package
|
||||
|
||||
location @odoo {
|
||||
# copy-paste the content of the / location block
|
||||
}
|
||||
Say Odoo has been installed via the **debian packages** for Community and Enterprise, and
|
||||
that the :option:`--addons-path <odoo-bin --addons-path>` is
|
||||
``'/usr/lib/python3/dist-packages/odoo/addons'``.
|
||||
|
||||
# Serve static files right away
|
||||
location ~ ^/[^/]+/static/.+$ {
|
||||
root /opt/odoo;
|
||||
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
|
||||
expires 24h;
|
||||
}
|
||||
The ``root`` and ``try_files`` should be:
|
||||
|
||||
.. warning::
|
||||
The actual NGINX configuration you need is highly dependent on your own installation. The two
|
||||
above snippets only highlight two possible configurations and may not be used as-is.
|
||||
.. code-block:: nginx
|
||||
|
||||
root /usr/lib/python3/dist-packages/odoo/addons;
|
||||
try_files $uri @odoo;
|
||||
|
||||
.. group-tab:: Git sources
|
||||
|
||||
Say Odoo has been installed via the **sources**, that both the Community and Enterprise git
|
||||
repositories were cloned in :file:`/opt/odoo/community` and :file:`/opt/odoo/enterprise`
|
||||
respectively, and that the :option:`--addons-path <odoo-bin --addons-path>` is
|
||||
``'/opt/odoo/community/odoo/addons,/opt/odoo/community/addons,/opt/odoo/enterprise'``.
|
||||
|
||||
The ``root`` and ``try_files`` should be:
|
||||
|
||||
.. code-block:: nginx
|
||||
|
||||
root /opt/odoo;
|
||||
try_files /community/odoo/addons$uri /community/addons$uri /enterprise$uri @odoo;
|
||||
|
||||
Serving attachments
|
||||
-------------------
|
||||
|
||||
@@ -1,6 +1,9 @@
|
||||
==========================================
|
||||
Geo IP Installation (On-Premises Database)
|
||||
==========================================
|
||||
======
|
||||
Geo IP
|
||||
======
|
||||
|
||||
.. note::
|
||||
This documentation only applies to On-premise databases.
|
||||
|
||||
Installation
|
||||
============
|
||||
@@ -32,8 +35,8 @@ Installation
|
||||
.. seealso::
|
||||
- :doc:`CLI documentation </developer/reference/cli>`.
|
||||
|
||||
Test GeoIP Geolocation In Odoo Website
|
||||
======================================
|
||||
Test GeoIP geolocation in your Odoo website
|
||||
===========================================
|
||||
|
||||
Edit a web page to include some geo-ip information such as the country name of the current
|
||||
request IP address. To do so:
|
||||
@@ -54,10 +54,10 @@ Odoo needs a `PostgreSQL <https://www.postgresql.org/>`_ server to run properly.
|
||||
$ sudo systemctl start postgresql
|
||||
|
||||
.. warning::
|
||||
`wkhtmltopdf` is not installed through **pip** and must be installed manually in `version 0.12.5
|
||||
<https://github.com/wkhtmltopdf/wkhtmltopdf/releases/tag/0.12.5>`_ for it to support headers and
|
||||
footers. Check out the `wkhtmltopdf wiki <https://github.com/odoo/odoo/wiki/Wkhtmltopdf>`_ for
|
||||
more details on the various versions.
|
||||
`wkhtmltopdf` is not installed through **pip** and must be installed manually in `version 0.12.6
|
||||
<https://github.com/wkhtmltopdf/packaging/releases/tag/0.12.6.1-3>`_ for it to support headers
|
||||
and footers. Check out the `wkhtmltopdf wiki <https://github.com/odoo/odoo/wiki/Wkhtmltopdf>`_
|
||||
for more details on the various versions.
|
||||
|
||||
Repository
|
||||
----------
|
||||
|
||||
@@ -229,7 +229,7 @@ PostgreSQL user.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo -u postgres createuser -s $USER
|
||||
$ sudo -u postgres createuser -d -R -S $USER
|
||||
$ createdb $USER
|
||||
|
||||
.. note::
|
||||
@@ -254,7 +254,7 @@ PostgreSQL user.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo -u postgres createuser -s $USER
|
||||
$ sudo -u postgres createuser -d -R -S $USER
|
||||
$ createdb $USER
|
||||
|
||||
.. note::
|
||||
@@ -413,10 +413,10 @@ Dependencies
|
||||
$ sudo npm install -g rtlcss
|
||||
|
||||
.. warning::
|
||||
`wkhtmltopdf` is not installed through **pip** and must be installed manually in `version 0.12.5
|
||||
<https://github.com/wkhtmltopdf/wkhtmltopdf/releases/tag/0.12.5>`_ for it to support headers and
|
||||
footers. Check out the `wkhtmltopdf wiki <https://github.com/odoo/odoo/wiki/Wkhtmltopdf>`_ for
|
||||
more details on the various versions.
|
||||
`wkhtmltopdf` is not installed through **pip** and must be installed manually in `version 0.12.6
|
||||
<https://github.com/wkhtmltopdf/packaging/releases/tag/0.12.6.1-3>`_ for it to support headers
|
||||
and footers. Check out the `wkhtmltopdf wiki <https://github.com/odoo/odoo/wiki/Wkhtmltopdf>`_
|
||||
for more details on the various versions.
|
||||
|
||||
.. _install/source/running_odoo:
|
||||
|
||||
|
||||
@@ -52,7 +52,7 @@ able to read (IMAP) and send (SMTP) emails in the Microsoft 365 setup. First, cl
|
||||
Add a Permission` button and select :guilabel:`Microsoft Graph` under :guilabel:`Commonly Used
|
||||
Microsoft APIs`. After, select the :guilabel:`Delegated Permissions` option.
|
||||
|
||||
In the search bar, search for the following :guilabel:`Deregulated permissions` and click
|
||||
In the search bar, search for the following :guilabel:`Delegated permissions` and click
|
||||
:guilabel:`Add permissions` for each one:
|
||||
|
||||
- :guilabel:`SMTP.Send`
|
||||
|
||||
@@ -30,8 +30,8 @@ Upgrade
|
||||
Trigger a database upgrade.
|
||||
|
||||
.. seealso::
|
||||
For more information about the upgrade process, check out the :doc:`Odoo Online upgrade
|
||||
documentation <../upgrade/odoo_online>`.
|
||||
For more information about the upgrade process, check out the :ref:`Odoo Online upgrade
|
||||
documentation <upgrade/request-test-database>`.
|
||||
|
||||
.. _odoo_online/duplicate:
|
||||
|
||||
@@ -129,6 +129,5 @@ users, click :guilabel:`Add more users`.
|
||||
To remove users, select them and click :guilabel:`Remove`.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`../../applications/general/users/manage_users`
|
||||
- :doc:`../../applications/general/users/delete_account`
|
||||
|
||||
- :doc:`/applications/general/users/manage_users`
|
||||
- :doc:`/applications/general/users/odoo_account`
|
||||
|
||||
@@ -1,3 +1,4 @@
|
||||
:hide-page-toc:
|
||||
|
||||
.. _supported_versions:
|
||||
|
||||
@@ -16,9 +17,6 @@ Odoo provides support and bug fixing **for the 3 last major versions** of Odoo.
|
||||
- Online versions are *not* released for Odoo.sh and On-Premise installations.
|
||||
- Online versions are listed below as *SaaS*.
|
||||
|
||||
What's the support status of my Odoo?
|
||||
=====================================
|
||||
|
||||
This matrix shows the support status of every version.
|
||||
|
||||
**Major releases are in bold type.**
|
||||
@@ -33,6 +31,12 @@ This matrix shows the support status of every version.
|
||||
- On-Premise
|
||||
- Release date
|
||||
- End of support
|
||||
* - **Odoo 17.0**
|
||||
- |green|
|
||||
- |green|
|
||||
- |green|
|
||||
- November 2023
|
||||
- November 2026 (planned)
|
||||
* - Odoo saas~16.4
|
||||
- |green|
|
||||
- N/A
|
||||
@@ -62,7 +66,7 @@ This matrix shows the support status of every version.
|
||||
- |green|
|
||||
- |green|
|
||||
- October 2022
|
||||
- October 2025 (planned)
|
||||
- November 2025 (planned)
|
||||
* - Odoo saas~15.2
|
||||
- |red|
|
||||
- N/A
|
||||
@@ -80,21 +84,27 @@ This matrix shows the support status of every version.
|
||||
- |green|
|
||||
- |green|
|
||||
- October 2021
|
||||
- October 2024 (planned)
|
||||
- November 2024 (planned)
|
||||
* - **Odoo 14.0**
|
||||
- |green|
|
||||
- |green|
|
||||
- |green|
|
||||
- |red|
|
||||
- |red|
|
||||
- |red|
|
||||
- October 2020
|
||||
- November 2023 (planned)
|
||||
- November 2023
|
||||
* - **Odoo 13.0**
|
||||
- |red|
|
||||
- |red|
|
||||
- |red|
|
||||
- October 2019
|
||||
- October 2022
|
||||
* - Older versions
|
||||
- |red|
|
||||
- |red|
|
||||
- |red|
|
||||
- Before 2019
|
||||
- Before 2022
|
||||
|
||||
.. note::
|
||||
.. admonition:: Legend
|
||||
|
||||
|green| Supported version
|
||||
|
||||
@@ -102,7 +112,9 @@ This matrix shows the support status of every version.
|
||||
|
||||
N/A Never released for this platform
|
||||
|
||||
🏁 Future version, not released yet
|
||||
.. important::
|
||||
Even though we don't support older versions, you can always `upgrade from any version
|
||||
<https://upgrade.odoo.com/>`_.
|
||||
|
||||
.. |green| raw:: html
|
||||
|
||||
@@ -111,14 +123,3 @@ This matrix shows the support status of every version.
|
||||
.. |red| raw:: html
|
||||
|
||||
<span class="text-danger" style="font-size: 32px; line-height: 0.5">●</span>
|
||||
|
||||
I run an older version of Odoo/OpenERP/TinyERP
|
||||
==============================================
|
||||
|
||||
Odoo 12.0, 11.0, 10.0, 9.0, and 8.0 are not supported anymore, on any platform.
|
||||
|
||||
OpenERP 7.0, 6.1, 6.0 and 5.0 are not supported anymore, on any platform.
|
||||
|
||||
TinyERP 4.0, 3.0, 2.0 and 1.0 are not supported anymore, on any platform.
|
||||
|
||||
Even though we don't support older versions, you can always `upgrade from any version <https://upgrade.odoo.com/>`_.
|
||||
|
||||
@@ -29,3 +29,24 @@ We advise that:
|
||||
- Your scheduled actions should be
|
||||
`idempotent <https://stackoverflow.com/a/1077421/3332416>`_: they must not
|
||||
cause side-effects if they are started more often than expected.
|
||||
|
||||
How do I know if I need more workers ?
|
||||
--------------------------------------
|
||||
|
||||
Workers are abstract units of resources allocated to your database. The more workers you have the more it can be accessed concurrently.
|
||||
|
||||
As a general rule of thumb, you should allocate about **1 worker per 25 users and 1 worker for every 5000 daily visitors**. However, this can vary considerably based on database usage, website characteristics, and code customizations.
|
||||
|
||||
Speed is only impacted if you have too much concurrency.
|
||||
|
||||
If things are getting slow, here are a couple of indications to tell if it's due to a high concurrency.
|
||||
|
||||
- When things gets slow, **everything is slowed down**, not just specific operations.
|
||||
- **The slowness comes and goes**, typically it's better outside of business hours. (There can be other reasons for this as well.)
|
||||
- :ref:`Open your monitoring <odoosh-gettingstarted-branches-tabs-monitoring>`, there is a graph indicating the number of **"concurrent requests (max)"**. This graphs is often high or shows a flat upper bound during a prolonged period of time.
|
||||
- Some requests get a **"429 Too Many Requests"** response code.
|
||||
|
||||
If you have these symptoms it's advisable to try increasing your workers.
|
||||
|
||||
.. warning::
|
||||
Sometimes this high concurrency is temporary or illegitimate, it's possible your website is being crawled or that you have misconfigured third party applications excessively sollicitating your database. To identify this, have a look at the IP adresses in your odoo logs to see if some are flooding.
|
||||
|
||||
@@ -208,6 +208,8 @@ 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.
|
||||
|
||||
.. _odoosh-gettingstarted-branches-tabs-monitoring:
|
||||
|
||||
Monitoring
|
||||
----------
|
||||
|
||||
@@ -295,7 +297,7 @@ Upgrade
|
||||
Available for production and staging branches for valid projects.
|
||||
|
||||
.. seealso::
|
||||
:doc:`Upgrade - Odoo.sh <../../upgrade/odoo_sh>`
|
||||
:doc:`Upgrade documentation <../../upgrade>`
|
||||
|
||||
.. _odoosh-gettingstarted-branches-tabs-settings:
|
||||
|
||||
|
||||
@@ -1,226 +1,372 @@
|
||||
:show-content:
|
||||
|
||||
.. |assistance-contact| replace::
|
||||
If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or
|
||||
our `Sales department`_.
|
||||
.. _Sales department: mailto:sales@odoo.com
|
||||
|
||||
=======
|
||||
Upgrade
|
||||
=======
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
.. _administration/upgrade:
|
||||
|
||||
upgrade/odoo_online
|
||||
upgrade/odoo_sh
|
||||
upgrade/on_premise
|
||||
upgrade/faq
|
||||
An upgrade is the process of moving your database from an older version to a newer :doc:`supported
|
||||
version <maintain/supported_versions>` (e.g., Odoo 14.0 to Odoo 16.0). Frequently upgrading is
|
||||
essential as each version comes with new and improved features, bug fixes, and security patches.
|
||||
|
||||
An upgrade is switching to a newer version of Odoo (e.g., Odoo 14.0 to Odoo 15.0).
|
||||
.. _upgrade_faq/rolling_release:
|
||||
|
||||
.. spoiler:: Automatic upgrades: Odoo Online's Rolling Release process
|
||||
|
||||
The Rolling Release process allows Odoo Online customers to upgrade their database directly from
|
||||
a message prompt sent to the database administrator as soon as a new version is released. The
|
||||
invitation to upgrade is only sent if no issues are detected during the automatic tests.
|
||||
|
||||
.. image:: upgrade/rr-upgrade-message.png
|
||||
:alt: The upgrade message prompt on the top right of the database
|
||||
|
||||
It is strongly recommended to manually :ref:`test the upgrade first <upgrade/test_your_db>`.
|
||||
Clicking :guilabel:`I want to test first` redirects to `the database manager
|
||||
<https://www.odoo.com/my/databases/>`_, where it is possible to request an upgraded test database
|
||||
and check it for any discrepancies.
|
||||
|
||||
It is **not** recommended to click :guilabel:`Upgrade Now` without testing first, as it
|
||||
immediately triggers the live production database upgrade.
|
||||
|
||||
If the Rolling Release process detects an issue with the upgrade, it will be deactivated until
|
||||
the issue is resolved.
|
||||
|
||||
An upgrade does not cover:
|
||||
|
||||
* Changing :ref:`editions <upgrade-faq/editions-change>` (i.e., Community to Enterprise edition)
|
||||
* Switching :ref:`hosting type <upgrade-faq/hosting-types-switch>` (i.e., On-Premise to Odoo Online
|
||||
or Odoo.sh)
|
||||
* Migration from another ERP to Odoo
|
||||
- Downgrading to a previous version of Odoo
|
||||
- :doc:`Switching editions <maintain/enterprise>` (e.g., from Community to Enterprise)
|
||||
- :doc:`Changing hosting type </administration/maintain/hosting_changes>` (e.g., from on-premise
|
||||
to Odoo Online)
|
||||
- Migrating from another ERP to Odoo
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
.. warning::
|
||||
If your database contains custom modules, it cannot be upgraded until a version of your custom
|
||||
modules is available for the target version of Odoo. For customers maintaining their own custom
|
||||
modules, we recommend to parallelize the process by :ref:`requesting an upgraded database
|
||||
<upgrade/request-test-database>` while also :doc:`upgrading the source code of your custom
|
||||
modules </developer/howtos/upgrade_custom_db>`.
|
||||
|
||||
.. seealso::
|
||||
- :ref:`upgrade/sla`
|
||||
|
||||
.. _upgrade/process-workflow:
|
||||
Upgrading in a nutshell
|
||||
-----------------------
|
||||
|
||||
Process workflow
|
||||
================
|
||||
#. Request an upgraded test database (see :ref:`obtaining an upgraded test database
|
||||
<upgrade/request-test-database>`).
|
||||
|
||||
The upgrade process in a nutshell:
|
||||
#. If applicable, upgrade the source code of your custom module to be compatible with the new
|
||||
version of Odoo (see :doc:`/developer/howtos/upgrade_custom_db`).
|
||||
|
||||
#. You create a test upgrade request.
|
||||
#. Odoo processes the request automatically by running the database through an upgrade script, which
|
||||
takes between 20 and 120 minutes.
|
||||
#. Odoo delivers a test database.
|
||||
#. You test your database for possible discrepancies (see :ref:`upgrade/test-guidance`).
|
||||
#. If there are any discrepancies, you report them to the Upgrade support team via the help portal
|
||||
(see :ref:`upgrade/test-assistance`).
|
||||
#. We fix the issues and send you a new test database.
|
||||
#. Once you have 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 (this is done automatically on Odoo Online).
|
||||
#. Thoroughly test the upgraded database (see :ref:`testing the new version of the database
|
||||
<upgrade/test_your_db>`).
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Upgrade process for Odoo Online <upgrade/odoo_online>`
|
||||
- :doc:`Upgrade process for Odoo.sh <upgrade/odoo_sh>`
|
||||
- :doc:`Upgrade process for On-Premise <upgrade/on_premise>`
|
||||
#. Report any issue encountered during the testing to Odoo via the `support page
|
||||
<https://odoo.com/help?stage=migration>`__.
|
||||
|
||||
.. _upgrade/testing-phase:
|
||||
#. Once all issues are resolved and you are confident that the upgraded database can be used as
|
||||
your main database without any issues, plan the upgrade of your production database.
|
||||
|
||||
Testing
|
||||
=======
|
||||
#. Request the upgrade for the production database, rendering it unavailable for the time it takes
|
||||
to complete the process (see :ref:`upgrading the production database <upgrade/upgrade-prod>`).
|
||||
|
||||
This 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 many times as you need (one at a time).
|
||||
#. Report any issue encountered during the upgrade to Odoo via the `support page
|
||||
<https://odoo.com/help?stage=post_upgrade>`__.
|
||||
|
||||
Once you receive your upgraded test database, check that all data, processes, and functionality are
|
||||
still correct and working as expected.
|
||||
.. _upgrade/request-test-database:
|
||||
|
||||
If you do find discrepancies, :ref:`report your issues <upgrade/test-assistance>` and :ref:`request
|
||||
a new test database <upgrade/test-db-request>` when the reported issues are fixed in the upgrade
|
||||
script.
|
||||
|
||||
If you do not find any discrepancies, you can move on to the upgrade of your production database.
|
||||
|
||||
.. important::
|
||||
A test database is only intended for testing and remains completely unrelated to your present or
|
||||
future production database. Any data you add, or changes you make, will not be reflected in your
|
||||
upgraded production database.
|
||||
|
||||
.. note::
|
||||
Test databases are neutered and features are disabled to prevent them from having an impact on
|
||||
the production database:
|
||||
|
||||
#. The serial number of the database is modified (to prevent it from sending information as if it
|
||||
was the production database).
|
||||
#. The :ref:`base URL of the database <domain-name/web-base-url>` is reset to
|
||||
``http://localhost:8069`` and the email domain to ``localhost``.
|
||||
#. Scheduled actions are disabled (the calendar synchronization, the bank statement
|
||||
synchronization, the planned automated actions, the fetching of incoming mail servers, etc.).
|
||||
#. Outgoing mail servers are disabled by archiving the existing ones and adding a
|
||||
fake/non-working one.
|
||||
#. Payment providers and delivery carriers are reset to test environment.
|
||||
#. Accounting localization Electronic Data Interchange (EDI) services are disabled.
|
||||
#. A system parameter is set to tell the database has been neutered.
|
||||
|
||||
.. _upgrade/test-db-request:
|
||||
|
||||
Request a test database
|
||||
=======================
|
||||
|
||||
Follow the instructions available per hosting type on the `website form
|
||||
<https://upgrade.odoo.com>`_ and select *Testing* purpose.
|
||||
|
||||
.. image:: upgrade/test-purpose.png
|
||||
:align: center
|
||||
:alt: Selection of the "Testing" purpose in the upgrade form on Odoo
|
||||
|
||||
.. _upgrade/test-guidance:
|
||||
|
||||
Test guidance
|
||||
=============
|
||||
|
||||
Every business and organization has its own operational needs and has to test its specific Odoo
|
||||
database individually. We recommend you look at `the test scenario
|
||||
<https://docs.google.com/document/d/1ypNs7JKPOsjNbKpdiKFH7Al6g6whZ9jr7f7duAQ5E1w/>`_ for further
|
||||
information.
|
||||
|
||||
.. todo:: change link "test scenario" once the related doc is published
|
||||
|
||||
.. _upgrade/test-assistance:
|
||||
|
||||
Assistance
|
||||
----------
|
||||
|
||||
If you encounter an issue in the **test database**, please get in touch with Odoo Upgrade Support
|
||||
via the `Odoo Support page <https://www.odoo.com/help>`_.
|
||||
|
||||
Under the *Ticket Description* section, select *An issue related to my upgrade* ticket type.
|
||||
|
||||
.. image:: 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. This will slow down the processing and response time.
|
||||
|
||||
Please provide as much detail as you can (i.e., videos and screenshots to illustrate your issue).
|
||||
This will avoid clarifying questions and speed up the resolution process significantly.
|
||||
|
||||
.. note::
|
||||
* The purpose of the test phase is not to correct existing data or configurations in your
|
||||
database.
|
||||
* |assistance-contact|
|
||||
|
||||
.. _upgrade/steps-production:
|
||||
|
||||
The production launch
|
||||
=====================
|
||||
|
||||
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 <upgrade/testing-phase>` are completed to your satisfaction, submit the
|
||||
request to upgrade your production database via our `website form <https://upgrade.odoo.com>`_.
|
||||
Select *Production* purpose.
|
||||
|
||||
.. important::
|
||||
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)
|
||||
|
||||
.. _upgrade/production-assistance:
|
||||
|
||||
Assistance
|
||||
----------
|
||||
|
||||
If you encounter issues or problems in the **production database**, please get in touch with **Odoo
|
||||
Support**:
|
||||
|
||||
#. Connect to our `Odoo Support page <https://www.odoo.com/help>`_.
|
||||
#. 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 (i.e., videos and screenshots to illustrate your issue).
|
||||
This will avoid clarifying questions and speed up the resolution process significantly.
|
||||
|
||||
.. warning::
|
||||
If you choose *An issue related to my upgrade* as ticket type, the request will be redirected
|
||||
to another team than the support one and will slow down the processing and response time.
|
||||
|
||||
.. _upgrade/assistance:
|
||||
|
||||
Help
|
||||
====
|
||||
|
||||
.. _upgrade/contact:
|
||||
|
||||
Contact our upgrade service support
|
||||
Obtaining an upgraded test database
|
||||
-----------------------------------
|
||||
|
||||
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 happy to answer it as soon as possible.
|
||||
The `Upgrade page <https://upgrade.odoo.com/>`_ is the main platform for requesting an upgraded
|
||||
database. However, depending on the hosting type, you can upgrade from the command line
|
||||
(on-premise), the `Odoo Online database manager <https://odoo.com/my/databases>`_, or your `Odoo.sh
|
||||
project <https://odoo.sh/project>`_.
|
||||
|
||||
.. _upgrade/supported-versions:
|
||||
.. note::
|
||||
The Upgrade platform follows the same `Privacy Policy <https://www.odoo.com/privacy>`_ as the
|
||||
other Odoo.com services. Visit the `General Data Protection Regulation page
|
||||
<https://www.odoo.com/gdpr>`_ to learn more about how Odoo handles your data and privacy.
|
||||
|
||||
Supported versions
|
||||
------------------
|
||||
.. tabs::
|
||||
|
||||
Please note that Odoo provides support and bug fixing only for the three last major versions of
|
||||
Odoo.
|
||||
.. group-tab:: Odoo Online
|
||||
|
||||
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 longer support (before having to
|
||||
upgrade again).
|
||||
Odoo Online databases can be manually upgraded via the `database manager
|
||||
<https://odoo.com/my/databases>`_.
|
||||
|
||||
The database manager displays all databases associated with the user's account. Databases
|
||||
not on the most recent version of Odoo display an arrow in a circle icon next to their name,
|
||||
indicating that they can be upgraded.
|
||||
|
||||
.. image:: upgrade/databases-page.png
|
||||
:alt: The database manager with an upgrade button next to the name of a database.
|
||||
|
||||
Click the **arrow in a circle** icon to start the upgrade process. In the popup, fill in:
|
||||
|
||||
- The **version** of Odoo you want to upgrade to, usually the latest version
|
||||
- The **email** address that should receive the link to the upgraded database
|
||||
- The :guilabel:`Purpose` of the upgrade, which is automatically set to :guilabel:`Test` for
|
||||
your first upgrade request
|
||||
|
||||
.. image:: upgrade/upgrade-popup.png
|
||||
:alt: The "Upgrade your database" popup.
|
||||
|
||||
The :guilabel:`Upgrade in progress` tag is displayed next to the database name until
|
||||
completion. Once the process succeeds, an email containing a link to the upgraded test
|
||||
database is sent to the address provided. The database can also be accessed from the database
|
||||
manager by clicking the dropdown arrow before the database name.
|
||||
|
||||
.. image:: upgrade/access-upgraded-db.png
|
||||
:alt: Clicking the menu arrow displays the upgraded test database.
|
||||
|
||||
.. group-tab:: Odoo.sh
|
||||
|
||||
Odoo.sh is integrated with the upgrade platform to simplify the upgrade process.
|
||||
|
||||
.. image:: upgrade/odoo-sh-staging.png
|
||||
:alt: Odoo.sh project and tabs
|
||||
|
||||
The **latest production daily automatic backup** is then sent to the `upgrade platform
|
||||
<https://upgrade.odoo.com>`_.
|
||||
|
||||
Once the upgrade platform is done upgrading the backup and uploading it on the branch, it is
|
||||
put in a **special mode**: each time a **commit is pushed** on the branch, a **restore
|
||||
operation** of the upgraded backup and an **update of all the custom modules** occur. This
|
||||
allows you to test your custom modules on a pristine copy of the upgraded database. The log
|
||||
file of the upgrade process can be found in your newly upgraded staging build by going to
|
||||
:file:`~/logs/upgrade.log`.
|
||||
|
||||
.. important::
|
||||
In databases where custom modules are installed, their source code must be up-to-date with
|
||||
the target version of Odoo before the upgrade can be performed. If there are none, the
|
||||
"update on commit" mode is skipped, the upgraded database is built as soon as it is
|
||||
transferred from the upgrade platform, and the upgrade mode is exited.
|
||||
|
||||
Check out the :doc:`/developer/howtos/upgrade_custom_db` page for more information.
|
||||
|
||||
.. group-tab:: On-premise
|
||||
|
||||
The standard upgrade process can be initiated by entering the following command line on the
|
||||
machine where the database is hosted:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t <target version>
|
||||
|
||||
The following command can be used to display the general help and the main commands:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ python <(curl -s https://upgrade.odoo.com/upgrade) --help
|
||||
|
||||
An upgraded test database can also be requested via the `Upgrade page
|
||||
<https://upgrade.odoo.com/>`_.
|
||||
|
||||
.. important::
|
||||
In databases where custom modules are installed, their source code must be up-to-date with
|
||||
the target version of Odoo before the upgrade can be performed. Check out the
|
||||
:doc:`/developer/howtos/upgrade_custom_db` page for more information.
|
||||
|
||||
.. note::
|
||||
- For security reasons, only the person who submitted the upgrade request can download it.
|
||||
- For storage reasons, the database's copy is submitted without a filestore to the upgrade
|
||||
server. Therefore, the upgraded database does not contain the production filestore.
|
||||
- Before restoring the upgraded database, its filestore must be merged with the production
|
||||
filestore to be able to perform tests in the same conditions as it would be in the new
|
||||
version.
|
||||
- The upgraded database contains:
|
||||
|
||||
- A `dump.sql` file containing the upgraded database
|
||||
- A `filestore` folder containing files extracted from in-database records into
|
||||
attachments (if there are any) and new standard Odoo files from the targeted Odoo
|
||||
version (e.g., new images, icons, payment provider's logos, etc.).
|
||||
This is the folder that should be merged with the production filestore
|
||||
in order to get the full upgraded filestore.
|
||||
|
||||
.. note::
|
||||
You can request multiple test databases if you wish to test an upgrade more than once.
|
||||
|
||||
.. _upgrade/upgrade_report:
|
||||
|
||||
.. note::
|
||||
When an upgrade request is completed, an upgrade report is attached to the successful upgrade
|
||||
email, and it becomes available in the Discuss app for users who are part of the "Administration
|
||||
/ Settings" group. This report provides important information about the changes introduced by
|
||||
the new version.
|
||||
|
||||
.. _upgrade/test_your_db:
|
||||
|
||||
Testing the new version of the database
|
||||
---------------------------------------
|
||||
|
||||
It is essential to spend some time testing the upgraded test database to ensure that you are not
|
||||
stuck in your day-to-day activities by a change in views, behavior, or an error message once the
|
||||
upgrade goes live.
|
||||
|
||||
.. note::
|
||||
Test databases are neutralized, and some features are disabled to prevent them from impacting the
|
||||
production database:
|
||||
|
||||
#. Scheduled actions are disabled.
|
||||
#. Outgoing mail servers are disabled by archiving the existing ones and adding a fake one.
|
||||
#. Payment providers and delivery carriers are reset to the test environment.
|
||||
#. Bank synchronization is disabled. Should you want to test the synchronization, contact your
|
||||
bank synchronization provider to get sandbox credentials.
|
||||
|
||||
Testing as many of your business flows as possible is strongly recommended to ensure they are
|
||||
working correctly and to get more familiar with the new version.
|
||||
|
||||
.. admonition:: Basic test checklist
|
||||
|
||||
- Are there views that are deactivated in your test database but active in your production
|
||||
database?
|
||||
- Are your usual views still displayed correctly?
|
||||
- Are your reports (invoice, sales order, etc.) correctly generated?
|
||||
- Are your website pages working correctly?
|
||||
- Are you able to create and modify records? (sales orders, invoices, purchases, users, contacts,
|
||||
companies, etc.)
|
||||
- Are there any issues with your mail templates?
|
||||
- Are there any issues with saved translations?
|
||||
- Are your search filters still present?
|
||||
- Can you export your data?
|
||||
|
||||
.. spoiler:: Example of end-to-end testing
|
||||
|
||||
- Checking a random product in your product catalog and comparing its test and production data to
|
||||
verify everything is the same (product category, selling price, cost price, vendor, accounts,
|
||||
routes, etc.).
|
||||
- Buying this product (Purchase app).
|
||||
- Confirming the reception of this product (Inventory app).
|
||||
- Checking if the route to receive this product is the same in your production database
|
||||
(Inventory app).
|
||||
- Selling this product (Sales app) to a random customer.
|
||||
- Opening your customer database (Contacts app), selecting a customer (or company), and checking
|
||||
its data.
|
||||
- Shipping this product (Inventory app).
|
||||
- Checking if the route to ship this product is the same as in your production database
|
||||
(Inventory app).
|
||||
- Validating a customer invoice (Invoicing or Accounting app).
|
||||
- Crediting the invoice (issuing a credit note) and checking if it behaves as in your production
|
||||
database.
|
||||
- Checking your reports' results (Accounting app).
|
||||
- Randomly checking your taxes, currencies, bank accounts, and fiscal year (Accounting app).
|
||||
- Making an online order (Website apps) from the product selection in your shop until the
|
||||
checkout process and checking if everything behaves as in your production database.
|
||||
|
||||
This list is **not** exhaustive. Extend the example to your other apps based on your use of Odoo.
|
||||
|
||||
If you face an issue while testing your upgraded test database, you can request the assistance of
|
||||
Odoo via the `support page <https://odoo.com/help?stage=migration>`__ by selecting the option
|
||||
related to testing the upgrade. In any case, it is essential to report any
|
||||
problem encountered during the testing to fix it before upgrading your production database.
|
||||
|
||||
You might encounter significant differences with standard views, features, fields, and models during
|
||||
testing. Those changes cannot be reverted on a case-by-case basis. However, if a change introduced
|
||||
by a new version breaks a customization, it is the responsibility of the maintainer of your custom
|
||||
module to make it compatible with the new version of Odoo.
|
||||
|
||||
.. tip::
|
||||
Do not forget to test:
|
||||
|
||||
- Integrations with external software (EDI, APIs, etc.)
|
||||
- Workflows between different apps (online sales with eCommerce, converting a lead all the way to
|
||||
a sales order, delivery of products, etc.)
|
||||
- Data exports
|
||||
- Automated actions
|
||||
- Server actions in the action menu on form views, as well as by selecting multiple records on
|
||||
list views
|
||||
|
||||
.. _upgrade/upgrade-prod:
|
||||
|
||||
Upgrading the production database
|
||||
---------------------------------
|
||||
|
||||
Once the :ref:`tests <upgrade/test_your_db>` are completed and you are confident that the upgraded
|
||||
database can be used as your main database without any issues, it is time to plan the go-live day. It
|
||||
can be planned in coordination with Odoo's upgrade support analysts, reachable via the `support page
|
||||
<https://odoo.com/help>`__.
|
||||
|
||||
Your production database will be unavailable during its upgrade. Therefore, we recommend planning
|
||||
the upgrade at a time when the use of the database is minimal.
|
||||
|
||||
As the standard upgrade scripts and your database are constantly evolving, it is also recommended
|
||||
to frequently request another upgraded test database to ensure that the upgrade process is
|
||||
still successful, especially if it takes a long time to finish. **Fully rehearsing the upgrade
|
||||
process the day before upgrading the production database is also recommended.**
|
||||
|
||||
.. important::
|
||||
- Going into production without first testing may lead to:
|
||||
|
||||
- Users failing to adjust to the changes and new features
|
||||
- Business interruptions (e.g., no longer having the possibility to validate an action)
|
||||
- Poor customer experience (e.g., an eCommerce website that does not work correctly)
|
||||
|
||||
The process of upgrading a production database is similar to upgrading a test database with a few
|
||||
exceptions.
|
||||
|
||||
.. tabs::
|
||||
|
||||
.. group-tab:: Odoo Online
|
||||
|
||||
The process is similar to :ref:`obtaining an upgraded test database
|
||||
<upgrade/request-test-database>`, except for the purpose option, which must be set to
|
||||
:guilabel:`Production` instead of :guilabel:`Test`.
|
||||
|
||||
.. warning::
|
||||
Once the upgrade is requested, the database will be unavailable until the upgrade is
|
||||
finished. Once the process is completed, it is impossible to revert to the previous
|
||||
version.
|
||||
|
||||
.. group-tab:: Odoo.sh
|
||||
|
||||
The process is similar to :ref:`obtaining an upgraded test database
|
||||
<upgrade/request-test-database>` on the :guilabel:`Production` branch.
|
||||
|
||||
.. image:: upgrade/odoo-sh-prod.png
|
||||
:alt: View from the upgrade tab
|
||||
|
||||
The process is **triggered as soon as a new commit is made** on the branch. This
|
||||
allows the upgrade process to be synchronized with the deployment of the custom modules'
|
||||
upgraded source code.
|
||||
If there are no custom modules, the upgrade process is triggered immediately.
|
||||
|
||||
.. important::
|
||||
The database is unavailable throughout the process. If anything goes wrong, the platform
|
||||
automatically reverts the upgrade, as it would be for a regular update. In case of success,
|
||||
a backup of the database before the upgrade is created.
|
||||
|
||||
The update of your custom modules must be successful to complete the entire upgrade process.
|
||||
Make sure the status of your staging upgrade is :guilabel:`successful` before trying it in
|
||||
production. More information on how to upgrade your custom modules can be found on
|
||||
:doc:`/developer/howtos/upgrade_custom_db`.
|
||||
|
||||
.. group-tab:: On-premise
|
||||
|
||||
The command to upgrade a database to production is similar to the one of upgrading a test
|
||||
database except for the argument `test`, which must be replaced by `production`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ python <(curl -s https://upgrade.odoo.com/upgrade) production -d <your db name> -t <target version>
|
||||
|
||||
An upgraded production database can also be requested via the `Upgrade page
|
||||
<https://upgrade.odoo.com/>`_.
|
||||
Once the database is uploaded, any modification to your production database will **not** be
|
||||
present on your upgraded database. This is why we recommend not using it during the upgrade
|
||||
process.
|
||||
|
||||
.. important::
|
||||
When requesting an upgraded database for production purposes, the copy is submitted without
|
||||
a filestore. Therefore, the upgraded database filestore must be merged with the production
|
||||
filestore before deploying the new version.
|
||||
|
||||
In case of an issue with your production database, you can request the assistance of Odoo via the
|
||||
`support page <https://odoo.com/help?stage=post_upgrade>`__ by selecting the option related to
|
||||
the upgrade in production.
|
||||
|
||||
.. seealso::
|
||||
:doc:`maintain/supported_versions`
|
||||
|
||||
.. _upgrade/sla:
|
||||
|
||||
Service-level agreement (SLA)
|
||||
=============================
|
||||
-----------------------------
|
||||
|
||||
With Odoo Enterprise, upgrading a database to the most recent version of Odoo is **free**, including
|
||||
any support required to rectify potential discrepancies in the upgraded database.
|
||||
@@ -230,7 +376,7 @@ Information about the upgrade services included in the Enterprise Licence is ava
|
||||
upgrade services you can expect.
|
||||
|
||||
Upgrade services covered by the SLA
|
||||
-----------------------------------
|
||||
===================================
|
||||
|
||||
Databases hosted on Odoo's cloud platforms (Odoo Online and Odoo.sh) or self-hosted (On-Premise) can
|
||||
benefit from upgrade services at all times for:
|
||||
@@ -245,7 +391,7 @@ Upgrade services are limited to the technical conversion and adaptation of a dat
|
||||
modules and data) to make it compatible with the version targeted by the upgrade.
|
||||
|
||||
Upgrade services not covered by the SLA
|
||||
---------------------------------------
|
||||
=======================================
|
||||
|
||||
The following upgrade-related services are **not** included:
|
||||
|
||||
@@ -256,9 +402,6 @@ The following upgrade-related services are **not** included:
|
||||
<studio/automated-actions/action>`; and
|
||||
- **training** on using the upgraded version's features and workflows.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Upgrade FAQ <upgrade/faq>`
|
||||
- :doc:`Odoo.sh documentation <odoo_sh>`
|
||||
- :doc:`Supported Odoo versions <maintain/supported_versions>`
|
||||
|
||||
|
After Width: | Height: | Size: 2.9 KiB |
|
After Width: | Height: | Size: 2.6 KiB |
@@ -1,228 +0,0 @@
|
||||
.. |assistance-contact| replace::
|
||||
If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or
|
||||
our `Sales department`_.
|
||||
.. _Sales department: mailto:sales@odoo.com
|
||||
|
||||
===
|
||||
FAQ
|
||||
===
|
||||
|
||||
.. _upgrade-faq/why:
|
||||
|
||||
Why upgrade
|
||||
===========
|
||||
|
||||
* You benefit from the latest features of the :ref:`new major version
|
||||
<upgrade-faq/release-notes>` released by Odoo.
|
||||
* If you are in an :ref:`unsupported version <upgrade/supported-versions>`, you get a new version
|
||||
with support.
|
||||
|
||||
.. _upgrade-faq/when:
|
||||
|
||||
When to upgrade
|
||||
===============
|
||||
|
||||
Whenever you want. You can make your upgrade request as soon as a new version is released or when
|
||||
your version turns unsupported, and you still wish to enjoy support.
|
||||
|
||||
.. _upgrade-faq/availability:
|
||||
|
||||
Availability of the new version
|
||||
===============================
|
||||
|
||||
As soon as Odoo announces the release of a new major version, you can create a test upgrade request
|
||||
to try the latest version. Please note that at this point, the upgrade scripts will only have been
|
||||
tested with demo data. Please report any issue you might encounter while testing via the `Odoo
|
||||
Support page <https://www.odoo.com/help>`_ and make sure to be happy with your test version before
|
||||
requesting the upgrade of your database in production.
|
||||
|
||||
.. _upgrade-faq/duration:
|
||||
|
||||
Duration of the upgrade
|
||||
=======================
|
||||
|
||||
It is impossible to give time estimates for every upgrade request.
|
||||
|
||||
In general, the "smaller" the database, the quickest the upgrade request is completed. 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.
|
||||
|
||||
You can expect the time it takes for the platform to upgrade the test database to be similar to the
|
||||
production upgrade.
|
||||
|
||||
.. _upgrade-faq/project:
|
||||
|
||||
Duration of the upgrade project
|
||||
-------------------------------
|
||||
|
||||
It depends on the user involvement (the time spent on testing, reporting problems, etc.) and the
|
||||
issues encountered that might need to be addressed by our technical team.
|
||||
|
||||
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
|
||||
* User commitment
|
||||
|
||||
.. _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.
|
||||
|
||||
Depending on your situation, the custom code could be upgraded by our services, by one of our
|
||||
partners, or you can do it yourself.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _upgrade-faq/upgrade-or-migration:
|
||||
|
||||
Upgrade or Migration
|
||||
====================
|
||||
|
||||
An upgrade is switching to a newer version of Odoo, while a migration reflects the change of
|
||||
:ref:`editions <upgrade-faq/editions-change>` or change of :ref:`hosting type
|
||||
<upgrade-faq/hosting-types-switch>`.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _upgrade-faq/editions-change:
|
||||
|
||||
Editions change (from Community to Enterprise)
|
||||
==============================================
|
||||
|
||||
The upgrade always returns an Enterprise edition of Odoo, whether the database you sent was a
|
||||
community or enterprise edition. It is required to have an enterprise subscription to upgrade.
|
||||
|
||||
.. note::
|
||||
If you need assistance on this matter, please contact us via the `Odoo Support page
|
||||
<https://www.odoo.com/help>`_.
|
||||
|
||||
.. seealso::
|
||||
- `Editions <https://www.odoo.com/page/editions>`_
|
||||
|
||||
.. _upgrade-faq/hosting-types-switch:
|
||||
|
||||
Switching the hosting types (On-premise vs. Odoo 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
|
||||
<../maintain/hosting_changes>`.
|
||||
|
||||
.. note:: |assistance-contact|
|
||||
|
||||
.. _upgrade-faq/upgrade-report:
|
||||
|
||||
The Upgrade Report
|
||||
==================
|
||||
|
||||
When an upgrade request completes successfully (test or production), you receive an email
|
||||
notification about it that includes an 'Upgrade Report'. This report is also sent to you via the
|
||||
Discuss app. It contains valuable information regarding changes that occurred during the upgrade.
|
||||
While it serves as a guide to possible issues to look out for, it is not an exhaustive list. It
|
||||
remains imperative that you test the upgraded database thoroughly and report any discrepancies you
|
||||
might find, before you decide to upgrade your production database.
|
||||
|
||||
.. _upgrade-faq/custom-views:
|
||||
|
||||
Custom views
|
||||
============
|
||||
|
||||
During the upgrade, some custom views might get disabled for technical reasons. Therefore they might
|
||||
have to be fixed after the upgrade. The :ref:`Upgrade Report <upgrade-faq/upgrade-report>` that is
|
||||
generated after the upgrade is available in the Discuss app, and lists all the custom views that
|
||||
might be impacted by this.
|
||||
|
||||
.. _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.
|
||||
|
||||
How long is my test available for
|
||||
=================================
|
||||
|
||||
An Odoo Online test database is available for one month by default. We can extend this trial period
|
||||
upon request. For Odoo.sh or on-premise, there is no restriction.
|
||||
|
||||
How many tests to perform before upgrading to production?
|
||||
=========================================================
|
||||
|
||||
As many as needed. When you are comfortable with the database, run a last test upgrade 48 hours
|
||||
before requesting your production upgrade and test your workflows one last time.
|
||||
|
||||
How to/Where to report upgrade issues?
|
||||
======================================
|
||||
|
||||
If you encounter issues during the upgrade process, please contact the Odoo Support through the
|
||||
`Odoo Support page <https://www.odoo.com/help>`_.
|
||||
|
||||
- To report an issue discovered during the testing phase, please select **An issue related to my
|
||||
upgrade (test phase)**.
|
||||
- To report an issue discovered post-upgrade, please select **An issue related to my upgrade
|
||||
(production)**.
|
||||
|
||||
Upgrading to production
|
||||
=======================
|
||||
|
||||
Once you have completed 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.
|
||||
|
||||
How is my data handled in the Upgrade Platform?
|
||||
===============================================
|
||||
|
||||
The Odoo Upgrade platform uses the same Privacy Policy as the rest of Odoo.com services.
|
||||
|
||||
Your data is hosted on servers that follow our security guidelines, namely:
|
||||
|
||||
- SSL - All web connections to client instances are protected with 256-bit SSL encryption
|
||||
(HTTPS with a 2048-bit modulus SSL certificate), and running behind Grade A SSL stacks. All our
|
||||
certificate chains are using SHA-2 already.
|
||||
- Safe System - Our servers are running recent Linux distribution with up-to-date security patches,
|
||||
with firewall and intrusion countermeasures (not disclosed for obvious reasons).
|
||||
|
||||
Servers are located at the same locations as our Cloud providers with the following services:
|
||||
|
||||
- Restricted perimeter, physically accessed by authorized data center employees only
|
||||
- Physical access control with security badges or biometrical security
|
||||
- Security cameras monitoring the data center locations 24/7
|
||||
- Security personnel on-site 24/7
|
||||
|
||||
The uploaded and migrated databases uploaded to the Upgrade platform are kept for up to 3 months and
|
||||
are permanently deleted following that period.
|
||||
|
||||
You can learn more about privacy and data handling at Odoo by visiting our `General Data Protection
|
||||
Regulation page <https://www.odoo.com/gdpr>`_.
|
||||
|
||||
Rolling Release (applicable to Odoo Online databases)
|
||||
=====================================================
|
||||
|
||||
This feature allows customers to upgrade their database directly from a message prompt sent to the
|
||||
database administrator as soon as the new version is released. Odoo first tests the upgrade to the
|
||||
next version. The rolling release upgrade option is displayed if the automated tests are successful.
|
||||
The message offers two options:
|
||||
|
||||
#. To 'Upgrade Now', which immediately triggers the upgrade of your live production database.
|
||||
|
||||
#. To take you to your `database manager <https://www.odoo.com/my/databases/>`_ where you can
|
||||
`request an upgraded test database <https://upgrade.odoo.com/#online/>`_ and check the upgraded
|
||||
test database for any discrepancies.
|
||||
|
||||
When you choose to proceed with the production upgrade directly, make sure all users have saved
|
||||
their work and are logged out. The upgrade takes approximately 15 minutes. During this time your
|
||||
database is unreachable. If you notice any problem after the upgrade, please report it via the `Odoo
|
||||
Support page <https://www.odoo.com/help>`_.
|
||||
|
||||
.. note::
|
||||
If you are using the Website or Studio app, we recommend you always do a test upgrade before
|
||||
upgrading your production instance.
|
||||
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 24 KiB |
@@ -1,92 +0,0 @@
|
||||
===========
|
||||
Odoo Online
|
||||
===========
|
||||
|
||||
Odoo databases can be manually upgraded directly from the main Odoo website. To upgrade an Odoo
|
||||
database, navigate to the `database manager <https://www.odoo.com/my/databases>`_ page and sign in.
|
||||
|
||||
The database manager page displays all of the Odoo databases associated with the user's account. Any
|
||||
databases that are not already on the most recent version of Odoo display an **arrow in a circle**
|
||||
icon next to the database name, indicating that the database can be upgraded.
|
||||
|
||||
.. image:: odoo_online/databases-page.png
|
||||
:align: center
|
||||
:alt: The database manager page with an upgrade button next to the name of a database.
|
||||
|
||||
.. important::
|
||||
- If the database's version is **lower** than the latest major release: the database must be
|
||||
upgraded within two months. After these two months, an automatic upgrade is initiated.
|
||||
- If the database's version is **equal** to or **higher** than the latest major release:
|
||||
you can disregard the invitation to upgrade, as the database probably would not benefit from
|
||||
new features every two months.
|
||||
|
||||
If a database is *not* on the latest online version, its administrator should receive an invitation
|
||||
to upgrade on the database's dashboard, displayed as an **arrow in a circle**.
|
||||
|
||||
.. image:: odoo_online/database-notification.png
|
||||
:alt: Invitation to upgrade on the database dashboard.
|
||||
|
||||
.. note::
|
||||
Versions that are not supported anymore become deprecated and must be updated to avoid
|
||||
security issues. It is recommended to initiate the upgrade yourself and not wait for the
|
||||
automatic upgrade, as the former method allows you to request a test upgrade of the database to
|
||||
check for any discrepancies.
|
||||
|
||||
Test database
|
||||
=============
|
||||
|
||||
Click on the **arrow in a circle** icon to start the upgrade process. On the :guilabel:`Upgrade your
|
||||
database` pop-up, select the version of Odoo that the platform will be upgraded to. In the
|
||||
:guilabel:`Email to notify` field, enter an email address that will receive email notifications
|
||||
about the database upgrade.
|
||||
|
||||
There is also a :guilabel:`Purpose` section on the pop-up that is used to specify the reason for the
|
||||
upgrade. However, at this stage of the process, the only selectable option is :guilabel:`Test`, as
|
||||
Odoo requires users to create a test copy of the upgraded database before converting the actual
|
||||
database.
|
||||
|
||||
.. image:: odoo_online/upgrade-pop-up.png
|
||||
:align: center
|
||||
:alt: The "Upgrade your database" pop-up.
|
||||
|
||||
After filling out the form, click the :guilabel:`Upgrade` button. The pop-up disappears and the
|
||||
database being upgraded shows a red :guilabel:`Upgrade in progress` tag next to its name. An email
|
||||
confirming that the upgrade is in progress is also sent to the email address specified on the
|
||||
pop-up.
|
||||
|
||||
.. image:: odoo_online/upgrade-in-progress.png
|
||||
:align: center
|
||||
:alt: The "Upgrade in progress" tag next to the database name.
|
||||
|
||||
Once the upgrade is complete, a new test database appears on the `database manager
|
||||
<https://www.odoo.com/my/databases>`_ page. To access the test database, click the drop-down arrow
|
||||
(:guilabel:`⯆`) to the left of the main database's name. Doing so makes the test version appear
|
||||
below it. Finally, click the green :guilabel:`Connect` button on the right side of the test
|
||||
version's row to go to the database.
|
||||
|
||||
.. image:: odoo_online/test-database.png
|
||||
:align: center
|
||||
:alt: A test database on the database manager page.
|
||||
|
||||
Except for being on the newer version of Odoo, the test database is an exact copy of the one being
|
||||
upgraded. It is important to do extensive testing in this database to ensure that the upgrade has
|
||||
not altered or corrupted any data, and that all workflows still proceed as expected.
|
||||
|
||||
Production database
|
||||
===================
|
||||
|
||||
After confirming the integrity of the new version, return to the `database manager
|
||||
<https://www.odoo.com/my/databases>`_ page. Once again, click on the **arrow in a circle** icon next
|
||||
to the database being upgraded. The :guilabel:`Upgrade your database` pop-up appears as before,
|
||||
except that there is now a :guilabel:`Production` option under the :guilabel:`Purpose` section.
|
||||
|
||||
Select the :guilabel:`Production` option and then click :guilabel:`Upgrade` to begin the upgrade
|
||||
process. As before, a notification email is sent to the email address provided and a red
|
||||
:guilabel:`Upgrade in progress` tag appears next to the name of the database.
|
||||
|
||||
The production database is then taken offline and will be upgraded automatically. The time it takes
|
||||
to upgrade the production database should be similar to the time that was necessary to upgrade the
|
||||
test database. Make sure to inform database users of the scheduled downtime.
|
||||
|
||||
After the upgrade is finished, the :guilabel:`Upgrade in progress` tag disappears and the database
|
||||
is upgraded to the version specified.
|
||||
|
Before Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 5.6 KiB |
|
Before Width: | Height: | Size: 8.3 KiB |
|
Before Width: | Height: | Size: 6.2 KiB |
|
Before Width: | Height: | Size: 15 KiB |
@@ -1,132 +0,0 @@
|
||||
=======
|
||||
Odoo.sh
|
||||
=======
|
||||
|
||||
.. _upgrade/odoo_sh/overview:
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
Odoo.sh is integrated with the upgrade platform to make the upgrade process easier.
|
||||
|
||||
.. note::
|
||||
The :guilabel:`Upgrade` tab is available in the branches view. It is only available for valid
|
||||
projects with a valid production build.
|
||||
|
||||
.. image:: odoo_sh/odoo-sh-menu.png
|
||||
:align: center
|
||||
:alt: Click on the upgrade menu
|
||||
|
||||
The suggested upgrade steps on Odoo.sh are:
|
||||
|
||||
#. On a :guilabel:`Development` branch, upgrade your custom modules to keep them compatible with the
|
||||
new version and thoroughly **test them**.
|
||||
#. Switch that branch to the :guilabel:`Staging` branch, **upgrade** the last daily production
|
||||
backup and **test it**. Write upgrade scripts if necessary.
|
||||
#. Trigger the production upgrade from your :guilabel:`Production` branch and sit tight.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`../../administration/upgrade`
|
||||
- :doc:`Upgrade FAQ <../upgrade/faq>`
|
||||
- :doc:`Introduction to Odoo.sh <../odoo_sh/overview/introduction>`
|
||||
|
||||
.. _upgrade/odoo_sh/custom-modules:
|
||||
|
||||
Upgrade your custom modules
|
||||
===========================
|
||||
|
||||
The first step is to upgrade your custom modules to keep them compatible with the new version. Fork
|
||||
your :guilabel:`Production` branch in the :guilabel:`Development` stage, then go to the settings of
|
||||
your :guilabel:`Development` branch and select the Odoo version you target. If needed, modify your
|
||||
code to be compatible with the new version. Make sure to **test** your features are still working
|
||||
correctly.
|
||||
|
||||
.. note::
|
||||
Depending on your contract, the upgrade of your custom modules can be done by yourself, by your
|
||||
Partner or by Odoo (if you hold a subscription including maintenance of customizations).
|
||||
|
||||
.. _upgrade/odoo_sh/testing-phase:
|
||||
|
||||
Upgrade your database on a staging branch
|
||||
=========================================
|
||||
|
||||
Take the upgraded development branch and drag & drop it to :guilabel:`Staging`.
|
||||
|
||||
Go to the :guilabel:`Upgrade` tab and select the :guilabel:`target version`. Then, click on
|
||||
:guilabel:`Test Upgrade`.
|
||||
|
||||
.. image:: odoo_sh/odoo-sh-staging.png
|
||||
:align: center
|
||||
:alt: Odoo.sh project and tabs
|
||||
|
||||
The **latest production daily automatic backup** is sent to the
|
||||
`upgrade platform <https://www.upgrade.odoo.com>`_ to start the upgrade test process.
|
||||
|
||||
.. note::
|
||||
You can follow the upgrade process by going to the :guilabel:`Upgrade` menu of your
|
||||
:guilabel:`Production` branch.
|
||||
|
||||
When the upgraded backup is ready on the `upgrade platform <https://www.upgrade.odoo.com>`_, it is
|
||||
automatically downloaded back to your project.
|
||||
|
||||
The branch is now in a **special mode**: each time a **commit is pushed** on the branch, a
|
||||
**restore operation** of the upgraded backup occurs, and an **update of all the custom modules**
|
||||
happens. This allows you to quickly iterate on your custom modules upgrade scripts. The log file of
|
||||
the upgrade process can be found at :file:`~/logs/upgrade.log` in your newly upgraded staging build.
|
||||
|
||||
.. note::
|
||||
- The **special upgrade mode** is automatically closed after 30 days.
|
||||
- It may happen that custom modules are no longer needed after an upgrade. Custom modules in the
|
||||
upgraded database are set to be updated. If the modules are missing in the code, the update
|
||||
fails, thus failing the whole process. An empty module with a manifest and possibly some custom
|
||||
upgrade script are necessary to clean up the database. The complete removal of the module has
|
||||
to be handled afterwards.
|
||||
|
||||
Functionally test your upgraded database
|
||||
========================================
|
||||
|
||||
Now that the test upgraded database is available on your staging branch, **thoroughly test it** and
|
||||
make sure everything runs as it's supposed to. Once you are satisfied with the result, you are ready
|
||||
to upgrade your production database.
|
||||
|
||||
Production upgrade
|
||||
==================
|
||||
|
||||
Once you are happy with your testing, you can start the process on the :guilabel:`Production`
|
||||
branch.
|
||||
|
||||
On your :guilabel:`Production` branch, go to the :guilabel:`Upgrade` tab, select the
|
||||
:guilabel:`targeted version` and click on the :guilabel:`start Upgrade` button.
|
||||
|
||||
.. image:: odoo_sh/odoo-sh-prod.png
|
||||
:align: center
|
||||
:alt: View from the upgrade tab
|
||||
|
||||
The actual process is **triggered as soon as you push a new commit** in your branch. Make sure you
|
||||
are pushing code that is compatible with the new version. For example by merging the code from your
|
||||
upgraded staging branch.
|
||||
|
||||
.. note::
|
||||
You can see the progress of the upgrade by going to the :guilabel:`Upgrade` tab of the main
|
||||
branch.
|
||||
|
||||
.. image:: odoo_sh/odoo-sh-progress.png
|
||||
:align: center
|
||||
:alt: View showing the progress of the upgrade
|
||||
|
||||
.. important::
|
||||
Your database is unavailable throughout the process.
|
||||
|
||||
.. note::
|
||||
If anything goes wrong, the platform automatically reverts the upgrade, the same as it would be
|
||||
for a regular update. In case of success, a backup is always made.
|
||||
|
||||
The update of your custom modules must be successful to complete the entire upgrade process. Make
|
||||
sure the status of your staging upgrade is :guilabel:`successful` before trying it in production.
|
||||
|
||||
.. note::
|
||||
It may happen that custom modules are no longer needed after an upgrade. Custom modules in the
|
||||
upgraded database are set to be updated. If the modules are missing in the code, the update
|
||||
fails, thus failing the whole process. An empty module with a manifest and possibly some custom
|
||||
upgrade script are necessary to clean up the database. The complete removal of the module has to
|
||||
be handled afterwards.
|
||||
|
Before Width: | Height: | Size: 4.3 KiB |
|
Before Width: | Height: | Size: 42 KiB |
|
Before Width: | Height: | Size: 69 KiB |
|
Before Width: | Height: | Size: 31 KiB |
@@ -1,76 +0,0 @@
|
||||
==========
|
||||
On-Premise
|
||||
==========
|
||||
|
||||
Test upgrade request
|
||||
====================
|
||||
|
||||
There are two ways to create your upgrade request.
|
||||
|
||||
Upgrade request via command line
|
||||
--------------------------------
|
||||
|
||||
For technically-advanced users and partners, the upgrade process can be initiated via the following
|
||||
command line on the server where the database is hosted:
|
||||
|
||||
:command:`python <(curl -s https://upgrade.odoo.com/upgrade) test -d <your db name> -t
|
||||
<target version>`
|
||||
|
||||
The above command creates the database dump, sends it to the upgrade platform, and initiates the
|
||||
automated upgrade process. During the upgrade, you can follow the live logs on your screen.
|
||||
Once the upgrade process is completed successfully, the upgraded database is restored onto the
|
||||
server (as a duplicate test database).
|
||||
|
||||
Upgrade request via the Odoo Upgrade Portal
|
||||
-------------------------------------------
|
||||
|
||||
#. Download a recent copy of your database and select the option :guilabel:`pg_dump custom format
|
||||
(without filestore)`.
|
||||
#. Upload this dump file at https://upgrade.odoo.com and select *Testing* as the aim.
|
||||
Odoo performs the automated upgrade process. Once it is completed, you receive an email with a
|
||||
link to download the upgrade database dump file.
|
||||
#. Import the upgraded database into your on-premise environment and manually test all processes and
|
||||
workflows.
|
||||
|
||||
.. note::
|
||||
- For security reasons, only the person who submitted the upgrade request is able to download it.
|
||||
- Any problem found during testing should be reported via the `helpdesk
|
||||
<https://odoo.com/help>`_.
|
||||
- For storage reasons, the copy of your database is submitted without a filestore to the upgrade
|
||||
server. Therefore, the upgraded database does not contain the production filestore.
|
||||
- Before restoring the upgraded database, its filestore must be merged with the production
|
||||
filestore to be able to perform tests in the same conditions as it would be in the new version.
|
||||
- The upgraded database contains:
|
||||
|
||||
- A `dump.sql` file containing the upgraded database.
|
||||
- A `filestore` folder containing files that were extracted from in-database records into
|
||||
attachments (if there are any) and new standard Odoo files from the targeted Odoo version
|
||||
(like new images, icons, payment provider's logos, etc.). This is the folder that should be
|
||||
merged with the production filestore in order to get the full upgraded filestore.
|
||||
|
||||
Upgrade your production database
|
||||
================================
|
||||
|
||||
Once you have completed the testing successfully, you can proceed to upgrade your live database in
|
||||
production. Download your upgraded database from the link in the email and import it onto your live
|
||||
environment.
|
||||
|
||||
.. important::
|
||||
- Same as in the test phase, when requesting an upgrade for production purposes, the copy of your
|
||||
database is submitted without a filestore.
|
||||
- Therefore, the upgraded database filestore must be merged with the production filestore before
|
||||
deploying the new version.
|
||||
|
||||
Custom modules (if applicable)
|
||||
==============================
|
||||
|
||||
The upgrade of a database that contains custom modules is a two-step process.
|
||||
|
||||
#. The standard upgrade is done when your upgrade request is completed.
|
||||
#. Your custom modules also need to be upgraded to keep them compatible with the new version.
|
||||
|
||||
Depending on your contract, the upgrade of your custom modules can be done
|
||||
|
||||
#. by yourself.
|
||||
#. by your Partner.
|
||||
#. by Odoo (if you hold a subscription to 'Maintenance of Customizations').
|
||||
|
After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 8.0 KiB |
|
Before Width: | Height: | Size: 6.0 KiB |
|
After Width: | Height: | Size: 17 KiB |
@@ -96,6 +96,12 @@ gains and losses after reconciling the journal items.
|
||||
.. seealso::
|
||||
:doc:`Manage a bank in a foreign currency <accounting/bank/foreign_currency>`
|
||||
|
||||
Branch management
|
||||
=================
|
||||
|
||||
Multiple branches can be managed thanks to multi-company hierarchies. This allows to post journal
|
||||
entries on each branch as well as setting up a common lock date managed by the main company.
|
||||
|
||||
International standards
|
||||
=======================
|
||||
|
||||
@@ -203,8 +209,7 @@ available methods are standard price, average price, :abbr:`LIFO (Last-In, First
|
||||
:abbr:`FIFO (First-In, First-Out).`
|
||||
|
||||
.. seealso::
|
||||
:doc:`View the impact of the valuation methods on transactions
|
||||
<../inventory_and_mrp/inventory/management/reporting/inventory_valuation_config>`
|
||||
:doc:`../inventory_and_mrp/inventory/warehouses_storage/inventory_valuation/inventory_valuation_config`
|
||||
|
||||
Retained earnings
|
||||
=================
|
||||
@@ -216,6 +221,8 @@ and loss balance is automatically reported on the balance sheet report.
|
||||
.. seealso::
|
||||
:doc:`Accounting Cheat Sheet <accounting/get_started/cheat_sheet>`
|
||||
|
||||
.. _fiduciaries:
|
||||
|
||||
Fiduciaries
|
||||
===========
|
||||
|
||||
|
||||
@@ -107,9 +107,9 @@ If your connection with the proxy is disconnected, you can reconnect with the pr
|
||||
:guilabel:`Fetch Account` button.
|
||||
|
||||
.. note::
|
||||
This disconnection can be caused by the Odoo support. In this case, please contact the `support
|
||||
<https://www.odoo.com/help>`_ directly with your client id or the reference of the error listed
|
||||
in the chatter.
|
||||
If you are unable to reconnect using the :guilabel:`Reconnect` button, please contact the
|
||||
`support <https://www.odoo.com/help>`_ directly with your client id or the reference of the error
|
||||
listed in the chatter.
|
||||
|
||||
.. _MigrationOnlineSync:
|
||||
|
||||
|
||||
@@ -69,13 +69,13 @@ Transactions can be matched automatically with the use of :doc:`reconciliation m
|
||||
:ref:`matching existing entries <reconciliation/existing-entries>`, :ref:`manual operations
|
||||
<reconciliation/manual-operations>`, :ref:`batch payments <reconciliation/batch-payments>`, and
|
||||
:ref:`reconciliation model buttons <reconciliation_models_button>`.
|
||||
#. If the resulting entry isn't fully balanced, balance it by adding another existing counterpart
|
||||
#. If the resulting entry is not fully balanced, balance it by adding another existing counterpart
|
||||
entry or writing it off with a :ref:`manual operation <reconciliation/manual-operations>`.
|
||||
#. Click the :guilabel:`Validate` button to confirm the reconciliation and move to the next
|
||||
transaction.
|
||||
|
||||
.. tip::
|
||||
If you aren't sure how to reconcile a particular transaction and would like to deal with it
|
||||
If you are not sure how to reconcile a particular transaction and would like to deal with it
|
||||
later, use the :guilabel:`To Check` button instead. All transactions marked as :guilabel:`To
|
||||
Check` can be displayed using the :guilabel:`To Check` filter.
|
||||
|
||||
@@ -112,7 +112,7 @@ has a search bar that allows you to search for specific batch payments.
|
||||
Manual operations
|
||||
-----------------
|
||||
|
||||
If there isn't an existing entry to match the selected transaction, you may instead wish to
|
||||
If there is not an existing entry to match the selected transaction, you may instead wish to
|
||||
reconcile the transaction manually by choosing the correct account and amount. Then, complete any
|
||||
of the relevant optional fields.
|
||||
|
||||
@@ -123,6 +123,10 @@ of the relevant optional fields.
|
||||
account by clicking on the new line in the resulting entry section and selecting the
|
||||
:guilabel:`Account` to record the open balance.
|
||||
|
||||
.. note::
|
||||
Lines are silently reconciled unless a write-off entry is required, which launches a
|
||||
reconciliation wizard.
|
||||
|
||||
.. image:: reconciliation/fully-paid.png
|
||||
:alt: Click on fully paid to manually set an invoice as entirely paid.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 6.9 KiB After Width: | Height: | Size: 7.6 KiB |
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 67 KiB |
@@ -21,6 +21,8 @@ vendors because of modifications to confirmed customer invoices or vendor bills.
|
||||
:doc:`return </applications/sales/sales/products_prices/returns>` if a storable product is
|
||||
returned.
|
||||
|
||||
.. _accounting/issue-credit-note:
|
||||
|
||||
Issue a credit note
|
||||
===================
|
||||
|
||||
@@ -72,6 +74,8 @@ prefilled with the same details from the original invoice.
|
||||
|
||||
This is the option to **modify** the content of a *validated* invoice.
|
||||
|
||||
.. _accounting/issue-debit-note:
|
||||
|
||||
Issue a debit note
|
||||
==================
|
||||
|
||||
|
||||
@@ -2,194 +2,175 @@
|
||||
Deferred revenues
|
||||
=================
|
||||
|
||||
**Deferred revenues**, or **unearned revenue**, are payments made in advance by customers for
|
||||
products yet to deliver or services yet to render.
|
||||
**Deferred revenues**, or **unearned revenues**, are invoices addressed to customers
|
||||
for goods yet to be delivered or services yet to be rendered.
|
||||
|
||||
Such payments are a **liability** for the company that receives them since it still owes its
|
||||
customers these products or services. The company cannot report them on the current **Profit and
|
||||
Loss statement**, or *Income Statement*, since the payments will be effectively earned in the future.
|
||||
The company cannot report them on the current **profit and loss statement**, or *income statement*,
|
||||
since the goods and services will be effectively delivered/rendered in the future.
|
||||
|
||||
These future revenues must be deferred on the company's balance sheet until the moment in time they
|
||||
can be **recognized**, at once or over a defined period, on the Profit and Loss statement.
|
||||
These future revenues must be deferred on the company's balance sheet among the current liabilities
|
||||
until they can be **recognized**, at once or over a defined period, on the profit and loss
|
||||
statement.
|
||||
|
||||
For example, let's say we sell a five-year extended warranty for $ 350. We already receive the money
|
||||
now but haven't earned it yet. Therefore, we post this new income in a deferred revenue account and
|
||||
decide to recognize it on a yearly basis. Each year, for the next 5 years, $ 70 will be recognized
|
||||
as revenue.
|
||||
For example, let's say a business sells a software license of $1200 for 1 year. They immediately
|
||||
invoice it to the customer but can't consider it earned yet, as the future months of licensing have
|
||||
not yet been delivered. Therefore, they post this new revenue in a deferred revenue account and
|
||||
recognize it on a monthly basis. Each month, for the next 12 months, $100 will be recognized as
|
||||
revenue.
|
||||
|
||||
Odoo Accounting handles deferred revenues by spreading them in multiple entries that are
|
||||
automatically created in *draft mode* and then posted periodically.
|
||||
Odoo Accounting handles deferred revenues by spreading them in multiple entries that are posted
|
||||
periodically.
|
||||
|
||||
.. note::
|
||||
The server checks once a day if an entry must be posted. It might then take up to 24 hours before
|
||||
you see a change from *draft* to *posted*.
|
||||
you see a change from :guilabel:`Draft` to :guilabel:`Posted`.
|
||||
|
||||
Prerequisites
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Such transactions must be posted on a **Deferred Revenue Account** rather than on the default income
|
||||
account.
|
||||
Make sure the default settings are correctly configured for your business. To do so, go to
|
||||
:menuselection:`Accounting --> Configuration --> Settings`. The following options are available:
|
||||
|
||||
Configure a Deferred Revenue Account
|
||||
------------------------------------
|
||||
Journal
|
||||
The deferral entries are posted in this journal.
|
||||
Deferred Expense Account
|
||||
Expenses are deferred on this Current Asset account until they are recognized.
|
||||
Deferred Revenue Account
|
||||
Revenues are deferred on this Current Liability account until they are recognized.
|
||||
Generate Entries
|
||||
By default, Odoo :ref:`automatically generates <customer_invoices/deferred/generate_on_validation>`
|
||||
the deferral entries when you post a customer invoice. However, you can also choose to
|
||||
:ref:`generate them manually <customer_invoices/deferred/generate_manually>` by selecting the
|
||||
:guilabel:`Manually & Grouped` option instead.
|
||||
Amount Computation
|
||||
Suppose an invoice of $1200 must be deferred over 12 months. The :guilabel:`Equal per month`
|
||||
computation accounts for $100 each month, while the :guilabel:`Based on days` computation
|
||||
accounts for different amounts depending on the number of days in each month.
|
||||
|
||||
To configure your account in the **Chart of Accounts**, go to :menuselection:`Accounting -->
|
||||
Configuration --> Chart of Accounts`, click on *Create*, and fill out the form.
|
||||
.. _customer_invoices/deferred/generate_on_validation:
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues01.png
|
||||
:align: center
|
||||
:alt: Configuration of a Deferred Revenue Account in Odoo Accounting
|
||||
Generate deferral entries on validation
|
||||
=======================================
|
||||
|
||||
.. tip::
|
||||
Make sure the :guilabel:`Start Date` and :guilabel:`End Date` fields are visible in the
|
||||
:guilabel:`Invoice Lines` tab. In most cases, the :guilabel:`Start Date` should be in the same
|
||||
month as the :guilabel:`Invoice Date`.
|
||||
|
||||
For each line of the invoice that should be deferred, specify the start and end dates of the
|
||||
deferral period.
|
||||
|
||||
If the :guilabel:`Generate Entries` field in the **Settings** is set to :guilabel:`On invoice/bill
|
||||
validation`, Odoo automatically generates the deferral entries when the invoice is validated. Click
|
||||
the :guilabel:`Deferred Entries` smart button to see them.
|
||||
|
||||
One entry, dated on the same day as the invoice, moves the invoice amounts from the income account
|
||||
to the deferred account. The other entries are deferral entries which, month after month, move
|
||||
the invoice amounts from the deferred account to the income account to recognize the revenue.
|
||||
|
||||
.. example::
|
||||
You can defer a January invoice of $1200 over 12 months by specifying a start date of 01/01/2023
|
||||
and an end date of 12/31/2023. At the end of August, $800 is recognized as an income,
|
||||
whereas $400 remains on the deferred account.
|
||||
|
||||
Reporting
|
||||
=========
|
||||
|
||||
The deferred revenue report computes an overview of the necessary deferral entries for each account.
|
||||
To access it, go to :menuselection:`Accounting --> Reporting --> Deferred Revenue`.
|
||||
|
||||
To view the journal items of each account, click on the account name and then :guilabel:`Journal
|
||||
Items`.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenue_report.png
|
||||
:alt: Deferred revenue report
|
||||
|
||||
.. note::
|
||||
This account's type must be either *Current Liabilities* or *Non-current Liabilities*
|
||||
Only invoices whose accounting date is before the end of the period of the report
|
||||
are taken into account.
|
||||
|
||||
Post an income to the right account
|
||||
-----------------------------------
|
||||
.. _customer_invoices/deferred/generate_manually:
|
||||
|
||||
Select the account on a draft invoice
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Generate grouped deferral entries manually
|
||||
==========================================
|
||||
|
||||
On a draft invoice, select the right account for all the products of which the incomes must be
|
||||
deferred.
|
||||
If you have a lot of deferred revenues and wish to reduce the number of journal entries created, you
|
||||
can generate deferral entries manually. To do so, set the :guilabel:`Generate Entries` field in the
|
||||
**Settings** to :guilabel:`Manually & Grouped`. Odoo then aggregates the deferred amounts in a
|
||||
single entry.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues02.png
|
||||
:align: center
|
||||
:alt: Selection of a Deferred Revenue Account on a draft invoice in Odoo Accounting
|
||||
At the end of each month, go to :menuselection:`Accounting --> Reporting --> Deferred Revenue` and
|
||||
click the :guilabel:`Generate Entries` button. This generates two deferral entries:
|
||||
|
||||
Choose a different Income Account for specific products
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
- One dated at the end of the month which aggregates, for each account, all the deferred amounts
|
||||
of that month. This means that a part of the deferred revenue is recognized at the end of that
|
||||
period.
|
||||
- The reversal of this created entry, dated on the following day (i.e., the first day of the
|
||||
next month) to cancel the previous entry.
|
||||
|
||||
Start editing the product, go to the *Accounting* tab, select the right **Income Account**, and
|
||||
save.
|
||||
.. example::
|
||||
There are two invoices:
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues03.png
|
||||
:align: center
|
||||
:alt: Change of the Income Account for a product in Odoo
|
||||
- Invoice A: $1200 to be deferred from 01/01/2023 to 12/31/2023
|
||||
- Invoice B: $600 to be deferred from 01/01/2023 to 12/31/2023
|
||||
|
||||
.. tip::
|
||||
It is possible to automate the creation of revenue entries for these products (see:
|
||||
`Automate the Deferred Revenues`_).
|
||||
In January
|
||||
At the end of January, after clicking the :guilabel:`Generate Entries` button, there are the
|
||||
following entries:
|
||||
|
||||
Change the account of a posted journal item
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
- Entry 1 dated on the 31st January:
|
||||
|
||||
To do so, open your Sales Journal by going to
|
||||
:menuselection:`Accounting --> Accounting --> Sales`, select the journal item you
|
||||
want to modify, click on the account, and select the right one.
|
||||
- Line 1: Expense account -1200 -600 = **-1800** (cancelling the total of both invoices)
|
||||
- Line 2: Expense account 100 + 50 = **150** (recognizing 1/12 of invoice A and invoice B)
|
||||
- Line 3: Deferred account 1800 - 150 = **1650** (amount that has yet to be deferred later
|
||||
on)
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues04.png
|
||||
:align: center
|
||||
:alt: Modification of a posted journal item's account in Odoo Accounting
|
||||
- Entry 2 dated on the 1st February, the reversal of the previous entry:
|
||||
|
||||
Deferred Revenues entries
|
||||
=========================
|
||||
- Line 1: Expense account **1800**
|
||||
- Line 2: Deferred account **-150**
|
||||
- Line 3: Expense account **-1650**
|
||||
|
||||
Create a new entry
|
||||
------------------
|
||||
In February
|
||||
At the end of February, after clicking the :guilabel:`Generate Entries` button, there are the
|
||||
following entries:
|
||||
|
||||
A **Deferred Revenues entry** automatically generates all journal entries in *draft mode*. They are
|
||||
then posted one by one at the right time until the full amount of the income is recognized.
|
||||
- Entry 1 dated on the 28th February:
|
||||
|
||||
To create a new entry, go to :menuselection:`Accounting --> Accounting --> Deferred Revenues`, click
|
||||
on *Create*, and fill out the form.
|
||||
- Line 1: Expense account -1200 -600 = **-1800** (cancelling the total of both invoices)
|
||||
- Line 2: Expense account 200 + 100 = **300** (recognizing 2/12 of invoice A and invoice B)
|
||||
- Line 3: Deferred account 1800 - 300 = **1500** (amount that has yet to be deferred later
|
||||
on)
|
||||
|
||||
Click on **select related purchases** to link an existing journal item to this new entry. Some
|
||||
fields are then automatically filled out, and the journal item is now listed under the **Related
|
||||
Sales** tab.
|
||||
- Entry 2 dated on the 1st March, the reversal of the previous entry.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues05.png
|
||||
:align: center
|
||||
:alt: Deferred Revenue entry in Odoo Accounting
|
||||
From March to October
|
||||
The same computation is done for each month until October.
|
||||
|
||||
Once done, you can click on *Compute Revenue* (next to the *Confirm* button) to generate all the
|
||||
values of the **Revenue Board**. This board shows you all the entries that Odoo will post to
|
||||
recognize your revenue, and at which date.
|
||||
In November
|
||||
At the end of November, after clicking the :guilabel:`Generate Entries` button, there are the
|
||||
following entries:
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues06.png
|
||||
:align: center
|
||||
:alt: Revenue Board in Odoo Accounting
|
||||
- Entry 1 dated on the 30th November:
|
||||
|
||||
What does "Prorata Temporis" mean?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
- Line 1: Expense account -1200 -600 = **-1800** (cancelling the total of both invoices)
|
||||
- Line 2: Expense account 1100 + 550 = **1650** (recognizing 11/12 of invoice A and invoice
|
||||
B)
|
||||
- Line 3: Deferred account 1800 - 1650 = **150** (amount that has yet to be deferred later
|
||||
on)
|
||||
|
||||
The **Prorata Temporis** feature is useful to recognize your revenue the most accurately possible.
|
||||
- Entry 2 dated on the 1st December, the reversal of the previous entry.
|
||||
|
||||
With this feature, the first entry on the Revenue Board is computed based on the time left between
|
||||
the *Prorata Date* and the *First Recognition Date* rather than the default amount of time between
|
||||
recognitions.
|
||||
In December
|
||||
There is no need to generate entries in December. Indeed, if we do the computation for
|
||||
December, we have an amount of 0 to be deferred.
|
||||
|
||||
For example, the Revenue Board above has its first revenue with an amount of $ 4.22 rather than
|
||||
$ 70.00. Consequently, the last entry is also lower and has an amount of $ 65.78.
|
||||
In total
|
||||
If we aggregate everything, we would have:
|
||||
|
||||
Deferred Entry from the Sales Journal
|
||||
-------------------------------------
|
||||
- invoice A and invoice B
|
||||
- two entries (one for the deferral and one for the reversal) for each month from January to
|
||||
November
|
||||
|
||||
You can create a deferred entry from a specific journal item in your **Sales Journal**.
|
||||
|
||||
To do so, open your Sales Journal by going to
|
||||
:menuselection:`Accounting --> Accounting --> Sales`, and select the journal item you want to defer.
|
||||
Make sure that it is posted in the right account (see:
|
||||
`Change the account of a posted journal item`_).
|
||||
|
||||
Then, click on *Action*, select **Create Deferred Entry**, and fill out the form the same way you
|
||||
would do to `create a new entry`_.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues07.png
|
||||
:align: center
|
||||
:alt: Create Deferred Entry from a journal item in Odoo Accounting
|
||||
|
||||
Deferred Revenue Models
|
||||
=======================
|
||||
|
||||
You can create **Deferred Revenue Models** to create your Deferred Revenue entries faster.
|
||||
|
||||
To create a model, go to :menuselection:`Accounting --> Configuration --> Deferred Revenue Models`,
|
||||
click on *Create*, and fill out the form the same way you would do to create a new entry.
|
||||
|
||||
.. tip::
|
||||
You can also convert a *confirmed Deferred Revenue entry* into a model by
|
||||
opening it from :menuselection:`Accounting --> Accounting --> Deferred
|
||||
Revenues` and then, by clicking on the button *Save Model*.
|
||||
|
||||
Apply a Deferred Revenue Model to a new entry
|
||||
---------------------------------------------
|
||||
|
||||
When you create a new Deferred Revenue entry, fill out the **Deferred Revenue Account** with the
|
||||
right recognition account.
|
||||
|
||||
New buttons with all the models linked to that account appear at the top of the form. Clicking on a
|
||||
model button fills out the form according to that model.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues08.png
|
||||
:align: center
|
||||
:alt: Deferred Revenue model button in Odoo Accounting
|
||||
|
||||
.. _deferred-revenues-automation:
|
||||
|
||||
Automate the Deferred Revenues
|
||||
==============================
|
||||
|
||||
When you create or edit an account of which the type is either *Current Liabilities* or *Non-current
|
||||
Liabilities*, you can configure it to defer the revenues that are credited on it automatically.
|
||||
|
||||
You have three choices for the **Automate Deferred Revenue** field:
|
||||
|
||||
#. **No:** this is the default value. Nothing happens.
|
||||
#. **Create in draft:** whenever a transaction is posted on the account, a draft *Deferred Revenues
|
||||
entry* is created, but not validated. You must first fill out the form in
|
||||
:menuselection:`Accounting --> Accounting --> Deferred Revenues`.
|
||||
#. **Create and validate:** you must also select a Deferred Revenue Model (see:
|
||||
`Deferred Revenue Models`_). Whenever a transaction is posted on the account, a *Deferred
|
||||
Revenues entry* is created and immediately validated.
|
||||
|
||||
.. image:: deferred_revenues/deferred_revenues09.png
|
||||
:align: center
|
||||
:alt: Automate Deferred Revenue on an account in Odoo Accounting
|
||||
|
||||
.. tip::
|
||||
You can, for example, select this account as the default **Income Account** of a product to fully
|
||||
automate its sale. (see: `Choose a different Income Account for specific products`_).
|
||||
|
||||
.. seealso::
|
||||
* :doc:`../get_started/chart_of_accounts`
|
||||
* `Odoo Academy: Deferred Revenues (Recognition) <https://www.odoo.com/r/EWO>`_
|
||||
Therefore, at the end of December, invoices A and B are fully recognized as income
|
||||
only once in spite of all the created entries thanks to the reversal mechanism.
|
||||
|
||||
|
After Width: | Height: | Size: 6.6 KiB |
|
Before Width: | Height: | Size: 6.7 KiB |
|
Before Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 6.0 KiB |
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 27 KiB |
|
Before Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 4.9 KiB |
|
Before Width: | Height: | Size: 5.6 KiB |
|
Before Width: | Height: | Size: 5.4 KiB |
@@ -72,33 +72,6 @@ You can define a specific e-invoicing format for each customer. To do so, go to
|
||||
.. image:: electronic_invoicing/customer-form.png
|
||||
:alt: Select an EDI format for a specific customer
|
||||
|
||||
Peppol formats
|
||||
--------------
|
||||
|
||||
Use the fields :guilabel:`Peppol e-address (EAS)` and :guilabel:`Peppol Endpoint` to identify the
|
||||
recipient in the Peppol Network.
|
||||
|
||||
.. seealso::
|
||||
`Peppol BIS Billing 3.0 - Electronic Address Scheme (EAS) code list
|
||||
<https://docs.peppol.eu/poacc/billing/3.0/codelist/eas/>`_
|
||||
|
||||
.. example::
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
|
||||
* - Partner's country
|
||||
- Peppol e-address (EAS)
|
||||
- Peppol Endpoint
|
||||
* - Luxembourg
|
||||
- 9938 - Luxemburg VAT number
|
||||
- a valid Luxemburgish VAT number
|
||||
* - Netherlands
|
||||
- 0190 - Dutch Originator's Identification Number
|
||||
- a valid OIN number
|
||||
* - Belgium
|
||||
- 9925 - Belgium VAT number
|
||||
- a valid Belgian VAT number
|
||||
|
||||
National electronic invoicing
|
||||
-----------------------------
|
||||
|
||||
@@ -121,3 +94,184 @@ e-invoicing option to generate and attach the e-invoice file.
|
||||
|
||||
.. image:: electronic_invoicing/send-window.png
|
||||
:alt: The Peppol option is checked and an e-invoicing XML file is attached to the email.
|
||||
|
||||
Peppol
|
||||
======
|
||||
|
||||
The `Peppol <https://peppol.org/about/>`_ network ensures the exchange of documents and information
|
||||
between enterprises and governmental authorities. It is primarily used for electronic invoicing, and
|
||||
its access points (connectors to the Peppol network) allow enterprises to exchange electronic
|
||||
documents.
|
||||
|
||||
Odoo is an **access point** and an :abbr:`SMP (Service Metadata Publisher)`, enabling electronic
|
||||
invoicing transactions without the need to send invoices and bills by email or post.
|
||||
|
||||
If not done yet, :ref:`install <general/install>` the :guilabel:`Peppol` module (`account_peppol`).
|
||||
|
||||
.. important::
|
||||
- Peppol registration is **free** and available in Odoo Community
|
||||
- You can send **Customer Invoices** and **Credit Notes** and receive **Vendor Bills** and
|
||||
**Refunds** via Peppol.
|
||||
- You can send in one of the following supported document formats: **BIS Billing 3.0, XRechnung
|
||||
CIUS, NLCIUS**.
|
||||
- | The following **countries** are eligible for **Peppol registration in Odoo**:
|
||||
| Andorra, Albania, Austria, Bosnia and Herzegovina, Belgium, Bulgaria, Switzerland, Cyprus,
|
||||
Czech Republic, Germany, Denmark, Estonia, Spain, Finland, France, United Kingdom, Greece,
|
||||
Croatia, Hungary, Ireland, Iceland, Italy, Liechtenstein, Lithuania, Luxembourg, Latvia,
|
||||
Monaco, Montenegro, North Macedonia, Malta, Netherlands, Norway, Poland, Portugal, Romania,
|
||||
Serbia, Sweden, Slovenia, Slovakia, San Marino, Turkey, Holy See (Vatican City State)
|
||||
|
||||
Registration
|
||||
------------
|
||||
|
||||
Go to :menuselection:`Accounting --> Configuration --> Settings`. If you do not have the
|
||||
Peppol module installed, first tick the :guilabel:`Enable PEPPOL` checkbox and then **manually
|
||||
save**.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-install.png
|
||||
:alt: Peppol module installation
|
||||
|
||||
Fill in the following information:
|
||||
|
||||
- :guilabel:`Peppol EAS`. This is the Peppol Electronic Address Scheme and usually depends on your
|
||||
company's country. Odoo often prefills this with the most commonly used EAS code in your country.
|
||||
For example, the preferred EAS code for most companies in Belgium is 0208.
|
||||
- :guilabel:`Peppol Endpoint`. This is usually a Company Registry number or a VAT number.
|
||||
- :guilabel:`Phone Number`, including the country code (e.g., `+32` in Belgium)
|
||||
- :guilabel:`Primary contact email`
|
||||
|
||||
.. seealso::
|
||||
- `Peppol EAS - European Commision <https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Code+lists/>`_
|
||||
- `Peppol Endpoint - OpenPeppol eDEC Code Lists <https://docs.peppol.eu/edelivery/codelists/>`_
|
||||
(open the "Participant Identifier Schemes" as HTML page)
|
||||
|
||||
If you are migrating from another access point, insert the :guilabel:`Migration key` from the
|
||||
previous provider.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-settings.png
|
||||
:alt: Configuration for peppol
|
||||
|
||||
Finally, click :guilabel:`Validate registration`. If you want to explore or demo Peppol, you can
|
||||
choose to register in :guilabel:`Demo` mode. Otherwise, select :guilabel:`Live`.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-demo-mode.png
|
||||
:alt: Peppol demo mode selection
|
||||
|
||||
.. note::
|
||||
When testing Peppol, the system parameter `account_peppol.edi.mode` can be changed to `test`.
|
||||
Then, a radio button appears with the option to register on the test server.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-system-parameter.png
|
||||
:alt: Peppol test mode parameter
|
||||
|
||||
.. image:: electronic_invoicing/peppol-test-mode-settings.png
|
||||
:alt: Peppol test mode selection
|
||||
|
||||
Now, you can request a verification code to be sent to you by clicking :guilabel:`Verify phone
|
||||
number`.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-registration-verify.png
|
||||
:alt: phone validation request verification
|
||||
|
||||
A text message containing a code is sent to the phone number provided to finalize the verification
|
||||
process.
|
||||
|
||||
.. image:: electronic_invoicing/phone-registration.png
|
||||
:alt: phone validation
|
||||
|
||||
Once you enter the code and click :guilabel:`Confirm`, you can see that your registration is pending
|
||||
activation. From this point onwards, the default journal for receiving Vendor Bills can be set.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-registration-pending.png
|
||||
:alt: pending application
|
||||
|
||||
It should be automatically activated within a day.
|
||||
|
||||
.. tip::
|
||||
It is also possible to manually trigger the cron that checks the registration status by going to
|
||||
:menuselection:`Settings --> Technical --> Scheduled Actions --> PEPPOL\: update participant
|
||||
status`.
|
||||
|
||||
Your application status should be updated soon after you are registered on the Peppol network.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-registration-active.png
|
||||
:alt: active application
|
||||
|
||||
All invoices and vendor bills can now be sent directly using the Peppol network.
|
||||
|
||||
Contact verification
|
||||
--------------------
|
||||
|
||||
Before sending an invoice to a contact using the Peppol network, it is necessary to verify that they
|
||||
are also registered as a Peppol participant.
|
||||
|
||||
To do so, go to :menuselection:`Accounting --> Customers --> Customers` and open the customer's
|
||||
form. Then go to :menuselection:`Accounting tab --> Electronic Invoicing`, select the correct
|
||||
format, and make sure their :guilabel:`Peppol EAS code` and the :guilabel:`Endpoint` are filled in.
|
||||
Then, click :guilabel:`Verify`. If the contact exists on the network, their Peppol endpoint validity
|
||||
is set to Valid.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-contact-verify.png
|
||||
:alt: verify contact registration
|
||||
|
||||
.. important::
|
||||
While Odoo prefills both the EAS code and the Endpoint number based on the information available
|
||||
for a contact, it is better to confirm these details directly with the contact.
|
||||
|
||||
It is possible to verify the Peppol participant status of several customers at once.
|
||||
To do so, go to :menuselection:`Accounting --> Customers --> Customers` and switch to the list view.
|
||||
Select the customers you want to verify and then click :menuselection:`Actions --> Verify Peppol`.
|
||||
|
||||
Send invoices
|
||||
-------------
|
||||
|
||||
Once ready to send an invoice via the Peppol network, simply click :guilabel:`Send & Print` on the
|
||||
invoice form. To queue multiple invoices, select them in the list view and click
|
||||
:menuselection:`Actions --> Send & Print`; they will be sent in a batch later on. Both
|
||||
:guilabel:`BIS Billing 3.0` and :guilabel:`Send via PEPPOL` checkboxes need to be ticked.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-send-print.png
|
||||
:alt: Send peppol invoice
|
||||
|
||||
Posted invoices that can be sent via Peppol are marked as :guilabel:`Peppol Ready`.
|
||||
To display them, use the :guilabel:`Peppol Ready` filter or access the Accounting dashboard and
|
||||
click :guilabel:`Peppol ready invoices` on the corresponding sales journal.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-ready-invoices.png
|
||||
:alt: Filter Peppol ready invoices
|
||||
|
||||
Once the invoices are sent via Peppol, the status is changed to :guilabel:`Processing`. The
|
||||
status is changed to `Done` after they have been successfully delivered to the contact's Access
|
||||
Point.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-message-processing.png
|
||||
:alt: Peppol message status
|
||||
|
||||
.. tip::
|
||||
By default, the Peppol status column is hidden on the Invoices list view. You can choose to have
|
||||
it displayed by selecting it from the optional columns, accessible from the top right corner of
|
||||
the Invoices list view.
|
||||
|
||||
A cron runs regularly to check the status of these invoices. It is possible to check the status
|
||||
before the cron runs by clicking :guilabel:`Fetch Peppol invoice status` in the corresponding
|
||||
sales journal on the Accounting dashboard.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-fetch-message-status.png
|
||||
:alt: Fetch invoice Peppol status
|
||||
|
||||
Receive vendor bills
|
||||
--------------------
|
||||
|
||||
Once a day, a cron checks whether any new documents have been sent to you via the Peppol network.
|
||||
These documents are imported, and the corresponding vendor bills are created automatically as
|
||||
drafts.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-receive-bills.png
|
||||
:alt: peppol receive bills
|
||||
|
||||
If you want to retrieve incoming Peppol documents before the cron runs, you can do so from the
|
||||
Accounting dashboard on the main Peppol purchase journal that you set up in the settings. Just click
|
||||
:guilabel:`Fetch from Peppol`.
|
||||
|
||||
.. image:: electronic_invoicing/peppol-fetch-bills.png
|
||||
:alt: Fetch bills from Peppol
|
||||
|
||||
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 15 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 5.8 KiB |
|
After Width: | Height: | Size: 6.1 KiB |
|
After Width: | Height: | Size: 6.6 KiB |
|
After Width: | Height: | Size: 5.1 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 8.7 KiB |
|
After Width: | Height: | Size: 8.3 KiB |
|
After Width: | Height: | Size: 5.4 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 6.9 KiB |
|
After Width: | Height: | Size: 6.9 KiB |
@@ -25,7 +25,9 @@ transportation, insurance, customs clearance, and other relevant aspects of the
|
||||
- **DDP**: Delivered duty paid
|
||||
|
||||
.. seealso::
|
||||
:doc:`../reporting/intrastat`
|
||||
- :doc:`../reporting/intrastat`
|
||||
- :doc:`../customer_invoices`
|
||||
- :doc:`../vendor_bills`
|
||||
|
||||
.. _incoterms/invoices:
|
||||
|
||||
@@ -35,6 +37,16 @@ Define an Incoterm
|
||||
To define an Incoterm manually, create an invoice or bill, click the :guilabel:`Other Info` tab, and
|
||||
select the :guilabel:`Incoterm`.
|
||||
|
||||
Incoterm location
|
||||
-----------------
|
||||
|
||||
A location relevant to the chosen Incoterm can be added to the invoice or bill under
|
||||
:guilabel:`Other Info` in the :guilabel:`Incoterm Location` field.
|
||||
|
||||
.. example::
|
||||
If the chosen Incoterm code is `CIF` (Cost, Insurance, Freight), the associated location might be
|
||||
the destination port where the goods will be delivered.
|
||||
|
||||
.. _incoterms/default:
|
||||
|
||||
Default Incoterm configuration
|
||||
|
||||
@@ -187,7 +187,8 @@ Send yourself a sample invoice by email to make sure everything is correctly con
|
||||
* :doc:`get_started/chart_of_accounts`
|
||||
* :doc:`bank/bank_synchronization`
|
||||
* :doc:`../fiscal_localizations`
|
||||
* `Odoo Tutorials: Accounting Basics <https://www.odoo.com/r/lsZ>`_
|
||||
* `Odoo Tutorials: Accounting and Invoicing - Getting started [video]
|
||||
<https://www.odoo.com/slides/slide/getting-started-1692>`_
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
@@ -1,167 +1,439 @@
|
||||
=================================
|
||||
Inventory average price valuation
|
||||
=================================
|
||||
===============================
|
||||
Average price on returned goods
|
||||
===============================
|
||||
|
||||
As stated in the :doc:`inventory valuation page
|
||||
</applications/inventory_and_mrp/inventory/management/reporting/inventory_valuation_config>`,
|
||||
one of the possible costing method you can use in perpetual stock
|
||||
valuation, is the average cost.
|
||||
.. |AVCO| replace:: :abbr:`AVCO (Average Cost Valuation)`
|
||||
.. _inventory/avg_cost/definition:
|
||||
|
||||
This document answers to one recurrent question for companies using that
|
||||
method to make their stock valuation: how does a shipping returned to
|
||||
its supplier impact the average cost and the accounting entries? This
|
||||
document is **only** for the specific use case of a perpetual valuation (as
|
||||
opposed to the periodic one) and in average price costing method (as
|
||||
opposed to standard of FIFO).
|
||||
*Average cost valuation* (AVCO) is an inventory valuation method that evaluates cost based on the
|
||||
total cost of goods bought or produced during a period, divided by the total number of items
|
||||
on-hand. Inventory valuation is used to:
|
||||
|
||||
Definition of average cost
|
||||
==========================
|
||||
- reflect the value of a company's assets;
|
||||
- keep track of the amount of unsold goods;
|
||||
- account for monetary value in goods that have yet to generate profit;
|
||||
- report on flow of goods throughout the quarter.
|
||||
|
||||
The average cost method calculates the cost of ending inventory and cost
|
||||
of goods sold on the basis of weighted average cost per unit of
|
||||
inventory.
|
||||
Because |AVCO| uses the weighted average to evaluate the cost, it is a good fit for companies that
|
||||
sell only a few different products in large quantities. In Odoo, this costing analysis is
|
||||
*automatically updated* each time products are received.
|
||||
|
||||
The weighted average cost per unit is calculated using the following
|
||||
formula:
|
||||
Thus, when shipments are returned to their supplier, Odoo automatically generates accounting entries
|
||||
to reflect the change in inventory valuation. However, Odoo does **not** automatically update the
|
||||
|AVCO| calculation, because :ref:`this can potentially create inconsistencies with inventory
|
||||
valuation <inventory/avg_price/leaving_inventory>`.
|
||||
|
||||
- When new products arrive in a warehouse, the new average cost is
|
||||
recomputed as:
|
||||
.. note::
|
||||
This document addresses a specific use case for theoretical purposes. Navigate :ref:`here
|
||||
<inventory/management/inventory_valuation_config>` for instructions on how to set up and use
|
||||
|AVCO| in Odoo.
|
||||
|
||||
.. image:: avg_price_valuation/avg01.png
|
||||
.. seealso::
|
||||
- :ref:`Using inventory valuation <inventory/reporting/using_inventory_val>`
|
||||
- :ref:`Other inventory valuation methods <inventory/inventory_valuation_config/costing_methods>`
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To use average cost inventory valuation on a product, navigate to :menuselection:`Inventory -->
|
||||
Configuration --> Product Categories` and select the category that will be using |AVCO|. On the
|
||||
product category page, set :guilabel:`Costing Method` to `Average Cost (AVCO)` and
|
||||
:guilabel:`Inventory Valuation` to `Automated`.
|
||||
|
||||
.. seealso::
|
||||
:ref:`Inventory valuation configuration <inventory/management/inventory_valuation_config>`
|
||||
|
||||
Using average cost valuation
|
||||
============================
|
||||
|
||||
The average cost method adjusts the inventory valuation when products are received in the warehouse.
|
||||
This section explains how it works, but if the explanation is unnecessary, skip to the :ref:`return
|
||||
to supplier use case <inventory/avg_cost/return>` section.
|
||||
|
||||
.. _inventory/avg_cost/formula:
|
||||
|
||||
Formula
|
||||
-------
|
||||
|
||||
When new products arrive, the new average cost for each product is recomputed using the formula:
|
||||
|
||||
.. math::
|
||||
Avg~Cost = \frac{(Old~Qty \times Old~Avg~Cost) + (Incoming~Qty \times Purchase~Price)}{Final~Qty}
|
||||
|
||||
- **Old Qty**: product count in stock before receiving the new shipment;
|
||||
- **Old Avg Cost**: calculated average cost for a single product from the previous inventory
|
||||
valuation;
|
||||
- **Incoming Qty**: count of products arriving in the new shipment;
|
||||
- **Purchase Price**: estimated price of products at the reception of products (since vendor bills
|
||||
may arrive later). The amount includes not only the price for the products, but also added costs,
|
||||
such as shipping, taxes, and :ref:`landed costs <inventory/reporting/landed_costs>`. At reception
|
||||
of the vendor bill, this price is adjusted;
|
||||
- **Final Qty**: quantity of on-hand stock after the stock move.
|
||||
|
||||
.. _inventory/avg_cost/definite_rule:
|
||||
|
||||
.. important::
|
||||
When products leave the warehouse, the average cost **does not** change. Read about why the
|
||||
average cost valuation is **not** adjusted :ref:`here <inventory/avg_price/leaving_inventory>`.
|
||||
|
||||
.. _inventory/avg_cost/math_table:
|
||||
|
||||
Compute average cost
|
||||
--------------------
|
||||
|
||||
To understand how the average cost of a product changes with each shipment, consider the following
|
||||
table of warehouse operations and stock moves. Each is a different example of how the average cost
|
||||
valuation is affected.
|
||||
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Incoming Value| Inventory Value | Qty On Hand | Avg Cost |
|
||||
+================================+===============+===================+===============+============+
|
||||
| | | $0 | 0 | $0 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Receive 8 tables at $10/unit | 8 * $10 | $80 | 8 | $10 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Receive 4 tables at $16/unit | 4 * $16 | $144 | 12 | $12 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Deliver 10 tables | -10 * $12 | $24 | 2 | $12 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
|
||||
.. _inventory/avg_cost/ex-1:
|
||||
|
||||
.. exercise::
|
||||
Ensure comprehension of the above computations by reviewing the "Receive 8 tables at $10/unit"
|
||||
example.
|
||||
|
||||
Initially, the product stock is 0, so all values are $0.
|
||||
|
||||
In the first warehouse operation, `8` tables are received at `$10` each. The average cost is
|
||||
calculated using the :ref:`formula <inventory/avg_cost/formula>`:
|
||||
|
||||
.. math::
|
||||
Avg~Cost = \frac{0 + 8 \times $10}{8} = \frac{$80}{8} = $10
|
||||
|
||||
- Since the *incoming quantity* of tables is `8` and the *purchase price* for each is `$10`,
|
||||
- The inventory value in the numerator is evaluated to `$80`;
|
||||
- `$80` is divided by the total amount of tables to store, `8`;
|
||||
- `$10` is the average cost of a single table from the first shipment.
|
||||
|
||||
To verify this in Odoo, in the *Purchase* app, order `8` quantities of a new product, `Table`,
|
||||
with no previous stock moves, for `$10` each.
|
||||
|
||||
In the table's :guilabel:`Product Category` field in the :guilabel:`General Information` tab of
|
||||
the product form, click the :guilabel:`➡️ (arrow)` icon, to open an :guilabel:`External Link` to
|
||||
edit the product category. Set the :guilabel:`Costing Method` to `Average Cost (AVCO)` and
|
||||
:guilabel:`Inventory Valuation` to `Automated`.
|
||||
|
||||
Then, return to the purchase order. Click :guilabel:`Confirm Order`, and click :guilabel:`Receive
|
||||
Products` to confirm receipt.
|
||||
|
||||
Next, check the inventory valuation record generated by the product reception by navigating to
|
||||
:menuselection:`Inventory --> Reporting --> Inventory Valuation`. Select the drop-down for
|
||||
`Table`, and view the :guilabel:`Total Value` column for the *valuation layer* (:dfn:`inventory
|
||||
valuation at a specific point in time = on-hand quantity * unit price`). The 8 tables in-stock
|
||||
are worth $80.
|
||||
|
||||
.. image:: avg_price_valuation/inventory-val-8-tables.png
|
||||
:align: center
|
||||
:alt: Show inventory valuation of 8 tables in Odoo.
|
||||
|
||||
.. tip::
|
||||
When the product category's :guilabel:`Costing Method` is set to :guilabel:`AVCO`, then the
|
||||
average cost of a product is also displayed on the :guilabel:`Cost` field, under the
|
||||
:guilabel:`General Information` tab, on the product page itself.
|
||||
|
||||
Product delivery (use case)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For outgoing shipments, :ref:`outbound products have no effect on the average cost valuation
|
||||
<inventory/avg_cost/definite_rule>`. Although the average cost valuation is not recalculated, the
|
||||
inventory value still decreases because the product is removed from stock and delivered to the
|
||||
customer location.
|
||||
|
||||
.. exercise::
|
||||
To demonstrate that the average cost valuation is not recalculated, examine the "Deliver 10
|
||||
tables" example.
|
||||
|
||||
.. math::
|
||||
Avg~Cost = \frac{12 \times $12 + (-10) \times $12}{12-10} = \frac{24}{2} = $12
|
||||
|
||||
#. Because 10 tables are being sent out to customers, the *incoming quantity* is `-10`. The
|
||||
previous average cost (`$12`) is used in lieu of a vendor's *purchase price*;
|
||||
#. The *incoming inventory value* is `-10 * $12 = -$120`;
|
||||
#. The old *inventory value* (`$144`) is added to the *incoming inventory value* (`-$120`), so
|
||||
`$144 + -$120 = $24`;
|
||||
#. Only `2` tables remain after shipping out `10` tables from `12`. So the current *inventory
|
||||
value* (`$24`) is divided by the on-hand quantity (`2`);
|
||||
#. `$24 / 2 = $12`, which is the same average cost as the previous operation.
|
||||
|
||||
To verify this in Odoo, sell `10` tables in the *Sales* app, validate the delivery, and then
|
||||
review the inventory valuation record by going to in :menuselection:`Inventory --> Reporting -->
|
||||
Inventory Valuation`. In the topmost valuation layer, delivering `10` tables reduces the
|
||||
product's value by `-$120`.
|
||||
|
||||
**Note**: What is not represented in this stock valuation record is the revenue made from this
|
||||
sale, so this decrease is not a loss to the company.
|
||||
|
||||
.. image:: avg_price_valuation/inventory-val-send-10-tables.png
|
||||
:align: center
|
||||
:alt: Show how deliveries decrease inventory valuation.
|
||||
|
||||
.. _inventory/avg_cost/return:
|
||||
|
||||
Return items to supplier (use case)
|
||||
===================================
|
||||
|
||||
Because the price paid to suppliers can differ from the price the product is valued at with the
|
||||
|AVCO| method, Odoo handles returned items in a specific way.
|
||||
|
||||
#. Products are returned to suppliers at the original purchase price, but;
|
||||
#. The internal cost valuation remains unchanged.
|
||||
|
||||
The above :ref:`example table <inventory/avg_cost/math_table>` is updated as follows:
|
||||
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Qty*Avg Cost | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+================================+===============+===================+===============+============+
|
||||
| | | $24 | 2 | $12 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Return 1 table bought at $10 | -1 * $12 | $12 | 1 | $12 |
|
||||
+--------------------------------+---------------+-------------------+---------------+------------+
|
||||
|
||||
In other words, returns to vendors are perceived by Odoo as another form of a product exiting the
|
||||
warehouse. To Odoo, because the table is valued at $12 per unit, the inventory value is reduced by
|
||||
`$12` when the product is returned; the initial purchase price of `$10` is unrelated to the table's
|
||||
average cost.
|
||||
|
||||
.. example::
|
||||
To return a single table that was purchased for `$10`, navigate to the receipt in the *Inventory*
|
||||
app for the :ref:`8 tables purchased in Exercise 1 <inventory/avg_cost/ex-1>` by going to the
|
||||
:guilabel:`Inventory Overview`, clicking on :guilabel:`Receipts`, and selecting the desired
|
||||
receipt.
|
||||
|
||||
Then, click :guilabel:`Return` on the validated delivery order, and modify the quantity to `1` in
|
||||
the reverse transfer window. This creates an outgoing shipment for the table. Select
|
||||
:guilabel:`Validate` to confirm the outgoing shipment.
|
||||
|
||||
Return to :menuselection:`Inventory --> Reporting --> Inventory Valuation` to see how the
|
||||
outgoing shipment decreases the inventory value by $12.
|
||||
|
||||
.. image:: avg_price_valuation/inventory-valuation-return.png
|
||||
:align: center
|
||||
:alt: Inventory valuation for return.
|
||||
|
||||
.. _inventory/avg_price/leaving_inventory:
|
||||
|
||||
Eliminate stock valuation errors in outgoing products
|
||||
-----------------------------------------------------
|
||||
|
||||
Inconsistencies can occur in a company's inventory when the average cost valuation is recalculated
|
||||
on outgoing shipments.
|
||||
|
||||
To demonstrate this error, the table below displays a scenario in which 1 table is shipped to a
|
||||
customer and another is returned to a supplier at the purchased price.
|
||||
|
||||
+------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Qty*Price | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+==========================================+===============+===================+===============+============+
|
||||
| | | $24 | 2 | $12 |
|
||||
+------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Ship 1 product to customer | -1 \* $12 | $12 | 1 | $12 |
|
||||
+------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Return 1 product initially bought at $10 | -1 \* $10 | **$2** | **0** | $12 |
|
||||
+------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
|
||||
In the final operation above, the final inventory valuation for the table is `$2` even though there
|
||||
are `0` tables left in stock.
|
||||
|
||||
.. admonition:: Correct method
|
||||
|
||||
Use the average cost to value the return. This does not mean the company gets $12 back for a $10
|
||||
purchase; the item returned for $10 is valued internally at $12. The inventory value change
|
||||
represents a product worth $12 no longer being accounted for in company assets.
|
||||
|
||||
Anglo-Saxon accounting
|
||||
======================
|
||||
|
||||
In addition to using |AVCO|, companies that use **Anglo-Saxon accounting** also keep a holding
|
||||
account that tracks the amount to be paid to vendors. Once a vendor delivers an order, **inventory
|
||||
value** increases based on the vendor price of the products that have entered the stock. The holding
|
||||
account (called **stock input**) is credited and only reconciled once the vendor bill is received.
|
||||
|
||||
.. seealso::
|
||||
- :ref:`Anglo-Saxon vs. Continental <inventory/inventory_valuation_config/accounting>`
|
||||
|
||||
The table below reflects journal entries and accounts. The *stock input* account stores the money
|
||||
intended to pay vendors when the vendor bill has not yet been received. To balance accounts when
|
||||
returning products that have a price difference between the price the product is **valued at** and
|
||||
the price it was bought for, a *price difference* account is created.
|
||||
|
||||
.. _inventory/avg_price/price-table:
|
||||
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Operation | Stock Input | Price Diff | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+=========================================+===============+==============+===================+===============+============+
|
||||
| | | | $0 | 0 | $0 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive 8 tables at $10 | ($80) | | $80 | 8 | $10 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor bill $80 | $0 | | $80 | 8 | $10 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive 4 tables at $16 | ($64) | | $144 | 12 | $12 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor bill $64 | $0 | | $144 | 12 | $12 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Deliver 10 tables to customer | $0 | | $24 | 2 | $12 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Return 1 table initially bought at $10 | **$10** | **$2** | **$12** | 1 | $12 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor refund $10 | $0 | $2 | $12 | 1 | $12 |
|
||||
+-----------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
|
||||
Product reception
|
||||
-----------------
|
||||
|
||||
Summary
|
||||
~~~~~~~
|
||||
|
||||
At product reception, Odoo ensures companies can pay for goods that were purchased by preemptively
|
||||
moving an amount matching the price of received goods into the :doc:`liability account
|
||||
</applications/finance/accounting/get_started/cheat_sheet>`, **Stock Input**. Then, once the bill
|
||||
has been received, the amount in the holding account is transferred to *Accounts Payable*. Transfers
|
||||
into this account means the bill has been paid. **Stock Input** is reconciled once the vendor bill
|
||||
is received.
|
||||
|
||||
Inventory valuation is a method of calculating how much each in-stock product is worth internally.
|
||||
Since there is a difference between the price the product is **valuated at** and the price the
|
||||
product was actually **purchased for**, the **Inventory Valuation** account is unrelated to the
|
||||
crediting and debiting operations of the **Stock Input** account.
|
||||
|
||||
To conceptualize all this, follow the breakdown below.
|
||||
|
||||
Accounts balanced at received products
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
In this example, a company starts with zero units of a product, `table`, in stock. Then, 8 tables
|
||||
are received from the vendor:
|
||||
|
||||
#. The **Stock Input** account stores `$80` of credit owed to the vendor. The amount in this account
|
||||
is unrelated to the inventory value.
|
||||
#. `$80` worth of tables came **in** (**debit** the *Inventory Value* account `$80`), and
|
||||
#. `$80` must be paid **out** for received goods (**credit** the *Stock Input* account `$80`).
|
||||
|
||||
In Odoo
|
||||
*******
|
||||
|
||||
Odoo generates an accounting journal entry when shipments that use |AVCO| costing method are
|
||||
received. Configure a :guilabel:`Price Difference Account` by selecting the :guilabel:`➡️ (arrow)`
|
||||
icon next to the :guilabel:`Product Category` field on the product page.
|
||||
|
||||
Under :guilabel:`Account Properties`, create a new :guilabel:`Price Difference Account` by typing in
|
||||
the name of the account and clicking :guilabel:`Create and Edit`. Then set the account
|
||||
:guilabel:`Type` as `Expenses`, and click :guilabel:`Save`.
|
||||
|
||||
.. image:: avg_price_valuation/create-price-difference.png
|
||||
:align: center
|
||||
:alt: Create price difference account.
|
||||
|
||||
- When products leave the warehouse: the average cost **does not** change
|
||||
Then, receive the shipment in the *Purchase* app or *Inventory* app, and navigate to the
|
||||
:menuselection:`Accounting app --> Accounting --> Journal Entries`. In the list, find the
|
||||
:guilabel:`Reference` that matches the warehouse reception operation for the relevant product.
|
||||
|
||||
Defining the purchase price
|
||||
---------------------------
|
||||
.. image:: avg_price_valuation/search-for-entry-of-tables.png
|
||||
:align: center
|
||||
:alt: Show accounting entry of 8 tables from the list.
|
||||
|
||||
The purchase price is estimated at the reception of the products (you
|
||||
might not have received the vendor bill yet) and reevaluated at the
|
||||
reception of the vendor bill. The purchase price includes the cost you
|
||||
pay for the products, but it may also includes additional costs, like
|
||||
landed costs.
|
||||
Click on the line for 8 tables. This accounting journal entry shows that when the 8 tables were
|
||||
received, the `Stock Valuation` account increased by `$80`. Conversely, the **Stock Input** account
|
||||
(set as `Stock Interim (Received)` account by default) is credited `$80`.
|
||||
|
||||
Average cost example
|
||||
====================
|
||||
.. image:: avg_price_valuation/accounting-entry-8-tables.png
|
||||
:align: center
|
||||
:alt: Debit stock valuation and credit stock input 80 dollars.
|
||||
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Delta Value | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+=============================+===============+===================+===============+============+
|
||||
| | | $0 | 0 | $0 |
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
| Receive 8 Products at $10 | +8\*$10 | $80 | 8 | $10 |
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
| Receive 4 Products at $16 | +4\*$16 | $144 | 12 | $12 |
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
| Deliver 10 Products | -10\*$12 | $24 | 2 | $12 |
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
+-----------------------------+---------------+-------------------+---------------+------------+
|
||||
Accounts balanced at received vendor bill
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
At the beginning, the Avg Cost is set to 0 set as there is no product in
|
||||
the inventory. When the first reception is made, the average cost
|
||||
becomes logically the purchase price.
|
||||
In this example, a company starts with zero units of a product, table, in stock. Then, 8 tables are
|
||||
received from the vendor. When the bill is received from vendor for 8 tables:
|
||||
|
||||
At the second reception, the average cost is updated because the total
|
||||
inventory value is now ``$80 + 4*$16 = $144``. As we have 12 units on
|
||||
hand, the average price per unit is ``$144 / 12 = $12``.
|
||||
#. Use `$80` in the **Stock Input** account to pay the bill. This cancels out and the account now
|
||||
holds `$0`.
|
||||
#. Debit **Stock Input** `$80` (to reconcile this account).
|
||||
#. Credit **Accounts payable** `$80`. This account stores the amount the company owes others, so
|
||||
accountants use the amount to write checks to vendors.
|
||||
|
||||
By definition, the delivery of 10 products does not change the average
|
||||
cost. Indeed, the inventory value is now $24 as we have only 2 units
|
||||
remaining of each ``$24 / 2 = $12``.
|
||||
In Odoo
|
||||
*******
|
||||
|
||||
Purchase return use case
|
||||
========================
|
||||
Once the vendor requests payment, navigate to the :menuselection:`Purchase app --> Orders -->
|
||||
Purchase` and select the :abbr:`PO (Purchase Order)` for 8 tables. Inside the :abbr:`PO (Purchase
|
||||
Order)`, select :guilabel:`Create Bill`.
|
||||
|
||||
In case of a product returned to its supplier after reception, the
|
||||
inventory value is reduced using the average cost formulae (not at the
|
||||
initial price of these products!).
|
||||
Switch to the :guilabel:`Journal Items` tab to view how `$80` is transferred from the holding
|
||||
account, `Stock Interim (Received)` to `Accounts Payable`. :guilabel:`Confirm` the bill to record
|
||||
the payment to the vendor.
|
||||
|
||||
Which means that the above table will be updated as follow:
|
||||
.. image:: avg_price_valuation/receive-8-table-bill.png
|
||||
:align: center
|
||||
:alt: Show bill linked to the purchase order for 8 tables.
|
||||
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Delta Value | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+===============================================+===============+===================+===============+============+
|
||||
| | | $24 | 2 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Return of 1 Product initially bought at $10 | -1\*$12 | $12 | 1 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
On product delivery
|
||||
-------------------
|
||||
|
||||
Explanation: counter example
|
||||
----------------------------
|
||||
In the :ref:`above example table <inventory/avg_price/price-table>`, when 10 products are delivered
|
||||
to a customer, the **Stock Input** account is untouched because there are no new products coming in.
|
||||
To put it simply:
|
||||
|
||||
Remember the definition of **Average Cost**, saying that we do not update
|
||||
the average cost of a product leaving the inventory. If you break this
|
||||
rule, you may lead to inconsistencies in your inventory.
|
||||
#. **Inventory valuation** is credited `$120`. Subtracting from inventory valuation represents
|
||||
`$120` worth of products exiting the company.
|
||||
#. Debit **Accounts Receivable** to record revenue from the sale.
|
||||
|
||||
As an example, here is the scenario when you deliver one piece to the
|
||||
customer and return the other one to your supplier (at the cost you
|
||||
purchased it). Here is the operation:
|
||||
.. image:: avg_price_valuation/sell-10-tables.png
|
||||
:align: center
|
||||
:alt: Show journal items linked to sale order.
|
||||
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Delta Value | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+===============================================+===============+===================+===============+============+
|
||||
| | | $24 | 2 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Customer Shipping 1 product | -1\*$12 | $12 | 1 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Return of 1 Product initially bought at $10 | -1\*$10 | **$2** | **0** | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
.. spoiler:: Understand Anglo-Saxon expensing
|
||||
|
||||
As you can see in this example, this is not correct: an inventory
|
||||
valuation of $2 for 0 pieces in the warehouse.
|
||||
In the accounting journal entry invoicing a customer for 10 tables, the accounts **Product
|
||||
Sales**, **Tax Received**, and **Accounts Receivable** all pertain to the sale of the product.
|
||||
**Accounts Receivable** is the account where the customer payment will be received.
|
||||
|
||||
The correct scenario should be to return the goods at the current
|
||||
average cost:
|
||||
Anglo-Saxon accounting recognizes the cost of goods sold (COGS) once the sale is made. So, up
|
||||
until the product is sold, scrapped, or returned, costs of keeping the product in stock are not
|
||||
accounted for. The **Expense** account is debited `$120` to log the costs of storing 10 tables
|
||||
during this period of time.
|
||||
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Operation | Delta Value | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+===============================================+===============+===================+===============+============+
|
||||
| | | $24 | 2 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Customer Shipping 1 product | -1\*$12 | $12 | 1 | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
| Return of 1 Product initially bought at $10 | -1\*$12 | **$0** | **0** | $12 |
|
||||
+-----------------------------------------------+---------------+-------------------+---------------+------------+
|
||||
On product return
|
||||
-----------------
|
||||
|
||||
On the other hand, using the average cost to value the return ensure a
|
||||
correct inventory value at all times.
|
||||
In the :ref:`above example table <inventory/avg_price/price-table>`, when returning 1 product to a
|
||||
vendor purchased at `$10`, a company expects `$10` in the **Accounts Payable** account from the
|
||||
vendor. However, **Stock Input** account must be debited `$12` because the average cost is `$12` at
|
||||
the time of the return. The missing `$2` is accounted for in the :guilabel:`Price Difference
|
||||
Account`, which is set up in the product's :guilabel:`Product Category`.
|
||||
|
||||
Further thoughts on anglo saxon mode
|
||||
------------------------------------
|
||||
.. note::
|
||||
Behavior of *price difference accounts* varies from localization. In this case, the account is
|
||||
intended to store differences between vendor price and *automated* inventory valuation methods.
|
||||
|
||||
For people in using the **anglo saxon accounting** principles, there is
|
||||
another concept to take into account: the stock input account of the
|
||||
product, which is intended to hold at any time the value of vendor bills
|
||||
to receive. So the stock input account will increase on reception of
|
||||
incoming shipments and will decrease when receiving the related vendor
|
||||
bills.
|
||||
Summary:
|
||||
|
||||
Back to our example, we see that when the return is valued at the
|
||||
average price, the amount booked in the stock input account is the
|
||||
original purchase price:
|
||||
#. Debit **Stock Input** account `$10` to move the table from stock to stock input. This move is to
|
||||
indicate that the table is to be processed for an outgoing shipment.
|
||||
#. Debit **Stock Input** an additional `$2` to account for the **Price Difference**.
|
||||
#. Credit **Stock Valuation** `$12` because the item is leaving the stock.
|
||||
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Operation | stock input | price diff | Inventory Value | Qty On Hand | Avg Cost |
|
||||
+===============================================+===============+==============+===================+===============+============+
|
||||
| | | | $0 | 0 | $0 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive 8 Products at $10 | ($80) | | $80 | 8 | $10 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor bill $80 | $0 | | $80 | 8 | $10 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive 4 Products at $16 | ($64) | | $144 | 12 | $12 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor bill $64 | $0 | | $144 | 12 | $12 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Deliver 10 Products | $0 | | $24 | 2 | $12 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Return of 1 Product initially bought at $10 | **$10** | **$2** | **$12** | 1 | $12 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
| Receive vendor refund $10 | $0 | $2 | $12 | 1 | $12 |
|
||||
+-----------------------------------------------+---------------+--------------+-------------------+---------------+------------+
|
||||
.. image:: avg_price_valuation/expensing-price-difference-account.png
|
||||
:align: center
|
||||
:alt: 2 dollar difference expensed in Price Difference account.
|
||||
|
||||
This is because the vendor refund will be made using the original
|
||||
purchase price, so to zero out the effect of the return in the stock
|
||||
input in last operation, we need to reuse the original price. The price
|
||||
difference account located on the product category is used to book the
|
||||
difference between the average cost and the original purchase price.
|
||||
Once the vendor's refund is received,
|
||||
|
||||
#. Credit **Stock Input** account `$10` to reconcile the price of the table.
|
||||
#. Debit **Accounts Payable** `$10` to have the accountants collect and register the payment in
|
||||
their journal.
|
||||
|
||||
.. image:: avg_price_valuation/return-credit-note.png
|
||||
:align: center
|
||||
:alt: Return to get 10 dollars back.
|
||||
|
||||
|
After Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 5.3 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 13 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 33 KiB |
@@ -3,48 +3,39 @@ Chart of accounts
|
||||
=================
|
||||
|
||||
The **chart of accounts (COA)** is the list of all the accounts used to record financial
|
||||
transactions in the general ledger of an organization.
|
||||
transactions in the general ledger of an organization. The chart of accounts can be found under
|
||||
:menuselection:`Accounting --> Configuration --> Chart of Accounts`.
|
||||
|
||||
The accounts are usually listed in the order of appearance in the financial reports. Most of the
|
||||
time, they are listed as follows :
|
||||
When browsing your chart of accounts, you can sort the accounts by :guilabel:`Code`,
|
||||
:guilabel:`Account Name`, or :guilabel:`Type`, but other options are available in the drop-down menu
|
||||
|
||||
- Balance Sheet accounts:
|
||||
.. image:: chart_of_accounts/drop-down.png
|
||||
:alt: Drop-down toggle button
|
||||
|
||||
- Assets
|
||||
- Liabilities
|
||||
- Equity
|
||||
|
||||
- Profit & Loss:
|
||||
|
||||
- Income
|
||||
- Expense
|
||||
|
||||
When browsing your chart of accounts, you can filter the accounts by number, in the left column, and
|
||||
also group them by :guilabel:`Account Type`.
|
||||
|
||||
.. image:: chart_of_accounts/chart-of-accounts.png
|
||||
:align: center
|
||||
.. image:: chart_of_accounts/chart-of-accounts-sort.png
|
||||
:alt: Group the accounts by type in Odoo Accounting
|
||||
|
||||
Configuration of an account
|
||||
===========================
|
||||
|
||||
The country you select at the creation of your database (or additional company on your database)
|
||||
determines which **fiscal localization package** is installed by default. This package includes a
|
||||
standard chart of accounts already configured according to the country's regulations. You can use
|
||||
it directly or set it according to your company's needs.
|
||||
The country you select during the creation of your database (or additional company in your database)
|
||||
determines which :doc:`fiscal localization package <../../fiscal_localizations>` is installed by
|
||||
default. This package includes a standard chart of accounts already configured according to the
|
||||
country's regulations. You can use it directly or set it according to your company's needs.
|
||||
|
||||
To create a new account, go to :menuselection:`Accounting --> Configuration --> Chart of Accounts`,
|
||||
click :guilabel:`Create`, and fill in (at the minimum) the required fields
|
||||
(:guilabel:`Code, Account Name, Type`).
|
||||
|
||||
.. warning::
|
||||
It is not possible to modify the **fiscal localization** of a company once a journal entry has
|
||||
been posted.
|
||||
|
||||
To create a new account, go to :menuselection:`Accounting --> Configuration --> Chart of Accounts`,
|
||||
click on :guilabel:`Create`, and fill out the form.
|
||||
|
||||
Code and name
|
||||
-------------
|
||||
|
||||
Each account is identified by its **code** and **name**, which also indicates the account's purpose.
|
||||
Each account is identified by its :guilabel:`Code` and :guilabel:`Name`, which also indicate the
|
||||
account's purpose.
|
||||
|
||||
.. _chart-of-account/type:
|
||||
|
||||
@@ -59,7 +50,7 @@ Correctly configuring the **account type** is critical as it serves multiple pur
|
||||
- Generate opening entries
|
||||
|
||||
To configure an account type, open the :guilabel:`Type` field's drop-down selector and select the
|
||||
right type among the following list:
|
||||
corresponding type from the following list:
|
||||
|
||||
+---------------+--------------+-------------------------+
|
||||
| Report | Category | Account Types |
|
||||
@@ -101,32 +92,33 @@ right type among the following list:
|
||||
|Other | Other | Off-Balance Sheet |
|
||||
+---------------+--------------+-------------------------+
|
||||
|
||||
Assets, deferred expenses, and deferred revenues automation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Assets
|
||||
~~~~~~
|
||||
|
||||
Some **account types** display a new field **to automate** the creation of :ref:`assets
|
||||
<assets-automation>` entries, :ref:`deferred expenses <deferred-expenses-automation>` entries,
|
||||
and :ref:`deferred revenues <deferred-revenues-automation>` entries.
|
||||
Some **account types** can **automate** the creation of :ref:`asset <assets-automation>` entries.
|
||||
To **automate** entries, click :guilabel:`View` on an account line and go to the
|
||||
:guilabel:`Automation` tab.
|
||||
|
||||
You have three choices for the :guilabel:`Automation` field:
|
||||
You have three choices for the :guilabel:`Automation` tab:
|
||||
|
||||
#. :guilabel:`No`: this is the default value. Nothing happens.
|
||||
#. :guilabel:`Create in draft`: whenever a transaction is posted on the account, a draft entry is
|
||||
created, but not validated. You must first fill out the corresponding form.
|
||||
#. :guilabel:`Create and validate`: you must also select a **model**. Whenever a transaction is
|
||||
posted on the account, an entry is created and immediately validated.
|
||||
created but not validated. You must first fill out the corresponding form.
|
||||
#. :guilabel:`Create and validate`: you must also select a :guilabel:`Deferred Expense Model`.
|
||||
Whenever a transaction is posted on the account, an entry is created and immediately validated.
|
||||
|
||||
Default taxes
|
||||
-------------
|
||||
|
||||
Select a **default tax** that will be applied when this account is chosen for a product sale or
|
||||
purchase.
|
||||
In the :guilabel:`View` menu of an account, select a **default tax** to be applied when this
|
||||
account is chosen for a product sale or purchase.
|
||||
|
||||
Tags
|
||||
----
|
||||
|
||||
Some accounting reports require **tags** to be set on the relevant accounts. By default, you can
|
||||
choose among the tags that are used by the *Cash Flow Statement*.
|
||||
Some accounting reports require **tags** to be set on the relevant accounts. To add a tag, under
|
||||
:guilabel:`View`, click the :guilabel:`Tags` field and select an existing tag or :guilabel:`Create`
|
||||
a new one.
|
||||
|
||||
Account groups
|
||||
--------------
|
||||
@@ -134,31 +126,29 @@ Account groups
|
||||
**Account groups** are useful to list multiple accounts as *sub-accounts* of a bigger account and
|
||||
thus consolidate reports such as the **Trial Balance**. By default, groups are handled automatically
|
||||
based on the code of the group. For example, a new account `131200` is going to be part of the group
|
||||
`131000`.
|
||||
`131000`. You can attribute a specific group to an account in the :guilabel:`Group` field under
|
||||
:guilabel:`View`.
|
||||
|
||||
Create account groups manually
|
||||
------------------------------
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. note::
|
||||
Regular users should not need to create account groups manually. The following section is only
|
||||
intended for rare and advanced use cases.
|
||||
|
||||
To create a new account group, :ref:`developer mode <developer-mode>` and head to
|
||||
:menuselection:`Accounting app --> Configuration --> Account Groups`. Here, create a new group and
|
||||
enter the :guilabel:`name, code prefix, and company` to which that group account should be
|
||||
available. Note that you must enter the same code prefix in both :guilabel:`From` and :guilabel:`to`
|
||||
fields.
|
||||
To create a new account group, activate :ref:`developer mode <developer-mode>` and head to
|
||||
:menuselection:`Accounting --> Configuration --> Account Groups`. Here, create a new group and enter
|
||||
the :guilabel:`name, code prefix, and company` to which that group account should be available. Note
|
||||
that you must enter the same code prefix in both :guilabel:`From` and :guilabel:`to` fields.
|
||||
|
||||
.. image:: chart_of_accounts/account-groups.png
|
||||
:align: center
|
||||
:alt: Account groups creation.
|
||||
|
||||
To display your **Trial Balance** report with your account groups, go to :menuselection:`Accounting
|
||||
app-->Reporting-->Trial Balance`, then open the :guilabel:`Options` menu and select
|
||||
:guilabel:`Hierarchy and Subtotals`.
|
||||
To display your **Trial Balance** report with your account groups, go to
|
||||
:menuselection:`Accounting --> Reporting --> Trial Balance`, then open the :guilabel:`Options` menu
|
||||
and select :guilabel:`Hierarchy and Subtotals`.
|
||||
|
||||
.. image:: chart_of_accounts/trial-balance.png
|
||||
:align: center
|
||||
.. image:: chart_of_accounts/chart-of-accounts-groups.png
|
||||
:alt: Account Groups in the Trial Balance in Odoo Accounting
|
||||
|
||||
Allow reconciliation
|
||||
@@ -171,15 +161,18 @@ For example, an invoice paid with a credit card can be marked as :guilabel:`paid
|
||||
its payment. Therefore, the account used to record credit card payments needs to be configured as
|
||||
**allowing reconciliation**.
|
||||
|
||||
To do so, check the :guilabel:`Allow Reconciliation` box in the account's settings, and save.
|
||||
To do so, check the :guilabel:`Allow Reconciliation` box in the account's settings, and
|
||||
:guilabel:`Save`; or enable the button from the chart of accounts view.
|
||||
|
||||
.. image:: chart_of_accounts/chart-of-accounts-reconciliation.png
|
||||
:alt: Allow reconciliation for accounts in Odoo Accounting
|
||||
|
||||
Deprecated
|
||||
----------
|
||||
|
||||
It is not possible to delete an account once a transaction has been recorded on it. You can make
|
||||
them unusable by using the **Deprecated** feature.
|
||||
|
||||
To do so, check the :guilabel:`Deprecated` box in the account's settings, and save.
|
||||
them unusable by using the **Deprecated** feature: check the :guilabel:`Deprecated` box in the
|
||||
account's settings, and :guilabel:`Save`.
|
||||
|
||||
.. seealso::
|
||||
* :doc:`cheat_sheet`
|
||||
|
||||
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 2.4 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 461 B |
|
Before Width: | Height: | Size: 22 KiB |
@@ -129,6 +129,8 @@ Example
|
||||
|
||||
.. placeholder
|
||||
|
||||
.. _cheat_sheet/journals:
|
||||
|
||||
Journal entries
|
||||
===============
|
||||
|
||||
|
||||
@@ -4,15 +4,15 @@
|
||||
Payments
|
||||
========
|
||||
|
||||
In Odoo, payments can either be linked automatically to an invoice or bill or be stand-alone records
|
||||
for use at a later date.
|
||||
In Odoo, payments can either be automatically linked to an invoice or bill or be stand-alone records
|
||||
for use at a later date:
|
||||
|
||||
If a payment is **linked to an invoice or bill**, it reduces the amount due of the invoice. You can
|
||||
have multiple payments related to the same invoice.
|
||||
- If a payment is **linked to an invoice or bill**, it reduces/settles the amount due of the
|
||||
invoice. You can have multiple payments related to the same invoice.
|
||||
|
||||
If a payment is **not linked to an invoice or bill**, the customer has an outstanding credit with
|
||||
your company, or your company has an outstanding debit with a vendor. You can use those outstanding
|
||||
amounts to reduce unpaid invoices/bills.
|
||||
- If a payment is **not linked to an invoice or bill**, the customer has an outstanding credit with
|
||||
your company, or your company has an outstanding debit with a vendor. You can use those
|
||||
outstanding amounts to reduce/settle unpaid invoices/bills.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Internal transfers <payments/internal_transfers>`
|
||||
@@ -23,59 +23,54 @@ amounts to reduce unpaid invoices/bills.
|
||||
Registering payment from an invoice or bill
|
||||
===========================================
|
||||
|
||||
When clicking on :guilabel:`Register payment` in a customer invoice or vendor bill, it generates a
|
||||
new journal entry and changes the amount due according to the amount of the payment. The counterpart
|
||||
is reflected in an outstanding receipts or payments account. At this point, the customer invoice or
|
||||
vendor bill is marked as :guilabel:`In payment`. Then, when the outstanding account is reconciled
|
||||
with a bank statement line, the invoice or vendor bill changes to the :guilabel:`Paid` status.
|
||||
When clicking :guilabel:`Register payment` in a customer invoice or vendor bill, it generates a new
|
||||
journal entry and changes the amount due according to the payment amount. The counterpart is
|
||||
reflected in an :ref:`outstanding <bank/outstanding-accounts>` **receipts** or **payments** account.
|
||||
At this point, the customer invoice or vendor bill is marked as :guilabel:`In payment`. Then, when
|
||||
the outstanding account is reconciled with a bank statement line, the invoice or vendor bill changes
|
||||
to the :guilabel:`Paid` status.
|
||||
|
||||
The information icon near the payment line displays more information about the payment. You can
|
||||
access additional information, such as the related journal, by clicking on :guilabel:`View`.
|
||||
access additional information, such as the related journal, by clicking :guilabel:`View`.
|
||||
|
||||
.. image:: payments/information-icon.png
|
||||
:alt: See detailed information of a payment
|
||||
:alt: See detailed information of a payment.
|
||||
|
||||
.. note::
|
||||
- The customer invoice or vendor bill should be in the status :guilabel:`Posted` to register the
|
||||
- The customer invoice or vendor bill must be in the :guilabel:`Posted` status to register the
|
||||
payment.
|
||||
- When clicking on :guilabel:`Register payment`, you can select the amount to pay and make a
|
||||
partial or full payment.
|
||||
- If your main bank account is set as :ref:`outstanding account
|
||||
<bank/outstanding-accounts>`, and the payment is made in Odoo (not related to a
|
||||
bank statement), invoices and bills are directly registered in the status :guilabel:`Paid`.
|
||||
- If you unreconciled a payment, it still appears in your books but is no longer linked to the
|
||||
- If you unreconcile a payment, it still appears in your books but is no longer linked to the
|
||||
invoice.
|
||||
- If you (un)reconcile a payment in a different currency, a journal entry is automatically
|
||||
created to post the currency exchange gains/losses (reversal) amount.
|
||||
- If you (un)reconcile a payment and an invoice having cash basis taxes, a journal entry is
|
||||
automatically created to post the cash basis tax (reversal) amount.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`bank/reconciliation`
|
||||
.. tip::
|
||||
- If your main bank account is set as an :ref:`outstanding account
|
||||
<bank/outstanding-accounts>`, and the payment is registered in Odoo (not through a related
|
||||
bank statement), invoices and bills are directly registered as :guilabel:`Paid`.
|
||||
|
||||
Registering payments not tied to an invoice or bill
|
||||
===================================================
|
||||
|
||||
When a new payment is registered via the menu :menuselection:`Customers / Vendors --> Payments`, it
|
||||
is not directly linked to an invoice or bill. Instead, the account receivable or the account payable
|
||||
are matched with the outstanding account until they are manually matched with their related invoice
|
||||
or bill.
|
||||
When a new payment is registered via :menuselection:`Customers / Vendors --> Payments` menu, it is
|
||||
not directly linked to an invoice or bill. Instead, the account receivable or the account payable is
|
||||
matched with the **outstanding account** until it is manually matched with its related invoice or
|
||||
bill.
|
||||
|
||||
Matching invoices and bills with payments
|
||||
-----------------------------------------
|
||||
|
||||
A blue banner appears when you validate a new invoice or bill and there is an outstanding payment
|
||||
for this specific customer or vendor. It can easily be matched from the invoice or the bill by
|
||||
clicking on :guilabel:`ADD` under :guilabel:`Outstanding Credits` or :guilabel:`Outstanding Debits`.
|
||||
A blue banner appears when you validate a new invoice/bill and an **outstanding payment** exists for
|
||||
this specific customer or vendor. It can easily be matched from the invoice or bill by clicking
|
||||
:guilabel:`ADD` under :guilabel:`Outstanding Credits` or :guilabel:`Outstanding Debits`.
|
||||
|
||||
.. image:: payments/add-option.png
|
||||
:alt: Shows the ADD option to reconcile an invoice or a bill with a payment
|
||||
:alt: Shows the ADD option to reconcile an invoice or a bill with a payment.
|
||||
|
||||
The invoice or bill is now marked as :guilabel:`In payment` until it is reconciled with the bank
|
||||
statement.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`bank/reconciliation`
|
||||
The invoice or bill is now marked as :guilabel:`In payment` until it is reconciled with its
|
||||
corresponding bank statement.
|
||||
|
||||
.. _payments/batch-payments:
|
||||
|
||||
@@ -83,11 +78,11 @@ Batch payment
|
||||
-------------
|
||||
|
||||
Batch payments allow you to group different payments to ease :doc:`reconciliation
|
||||
<bank/reconciliation>`. They are also useful when you deposit checks to the bank or
|
||||
for SEPA Payments. To do so, go to :menuselection:`Accounting --> Customers --> Batch Payments` or
|
||||
:menuselection:`Accounting --> Vendors --> Batch Payments`. In the list view of payments, you can
|
||||
select several payments and group them in a batch by clicking on :menuselection:`Action --> Create
|
||||
Batch Payment`.
|
||||
<bank/reconciliation>`. They are also useful when you deposit :doc:`checks <payments/checks>` to the
|
||||
bank or for :doc:`SEPA payments <payments/pay_sepa>`. To do so, go to :menuselection:`Accounting -->
|
||||
Customers --> Batch Payments` or :menuselection:`Accounting --> Vendors --> Batch Payments`. In the
|
||||
list view of payments, you can select and group several payments in a batch by clicking
|
||||
:menuselection:`Action --> Create Batch Payment`.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`payments/batch`
|
||||
@@ -99,36 +94,50 @@ Payments matching
|
||||
-----------------
|
||||
|
||||
The :guilabel:`Payments matching` tool opens all unreconciled customer invoices or vendor bills and
|
||||
gives you the opportunity to process them all one by one, doing the matching of all their payments
|
||||
and invoices at once. You can reach this tool from the :menuselection:`Accounting Dashboard -->
|
||||
Customer Invoices / Vendor Bills`, and click on :guilabel:`⋮` and select :guilabel:`Payments
|
||||
Matching`, or by going to :menuselection:`Accounting --> Reconciliation`.
|
||||
allows you to process them individually, matching all payments and invoices in one place. You can
|
||||
reach this tool from the :menuselection:`Accounting Dashboard --> Customer Invoices / Vendor Bills`,
|
||||
click the drop-down menu button (:guilabel:`⋮`), and select :guilabel:`Payments Matching`, or go to
|
||||
:menuselection:`Accounting --> Accounting --> Reconciliation`.
|
||||
|
||||
.. image:: payments/payments-journal.png
|
||||
:alt: Payments matching menu in the drop-down menu.
|
||||
|
||||
.. note::
|
||||
During the :doc:`reconciliation <bank/reconciliation>`, if the sum of the debits
|
||||
and credits does not match, there is a remaining balance. This either needs to be reconciled at a
|
||||
later date or needs to be written off directly.
|
||||
During the :doc:`reconciliation <bank/reconciliation>`, if the sum of the debits and credits does
|
||||
not match, there is a remaining balance. This either needs to be reconciled at a later date or
|
||||
needs to be written off directly.
|
||||
|
||||
Batch payments matching
|
||||
-----------------------
|
||||
|
||||
To reconcile several outstanding payments or invoices at once, for a specific customer or vendor,
|
||||
the batch reconciliation feature can be used. Go to :menuselection:`Accounting --> Reporting -->
|
||||
Aged Receivable / Aged Payable`. You now see all transactions that have not been reconciled yet, and
|
||||
when you select a customer or vendor, the :guilabel:`Reconcile` option is displayed.
|
||||
You can use the **batch reconciliation feature** to reconcile several outstanding payments or
|
||||
invoices simultaneously for a specific customer or vendor. Go to your **Accounting Dashboard** and
|
||||
open your **bank journal**. In the **bank reconciliation** view, select a **transaction**, and click
|
||||
the :guilabel:`Batch Payments` tab. From here, you can reconcile your
|
||||
:doc:`batch payments <payments/batch>` with your outstanding payments or invoices.
|
||||
|
||||
.. image:: payments/reconcile-option.png
|
||||
:alt: See the reconcile option
|
||||
:alt: The batch payment reconcile option.
|
||||
|
||||
Registering a partial payment
|
||||
=============================
|
||||
|
||||
To register a **partial payment**, click :guilabel:`Register payment` from the related invoice or
|
||||
bill, and enter the amount received or paid. Upon entering the amount, a prompt appears to decide
|
||||
whether to :guilabel:`Keep open` the invoice or bill, or :guilabel:`Mark as fully paid`. Select
|
||||
:guilabel:`Keep open` and click :guilabel:`Create payment`. The invoice or bill is now marked as
|
||||
:guilabel:`Partial`. Select :guilabel:`Mark as fully paid` if you wish to settle the invoice or bill
|
||||
with a difference in the amount.
|
||||
|
||||
.. image:: payments/payment-difference.png
|
||||
:alt: Partial payment of an invoice or bill.
|
||||
|
||||
Reconciling payments with bank statements
|
||||
=========================================
|
||||
|
||||
Once a payment has been registered, the status of the invoice or bill is :guilabel:`In payment`. The
|
||||
next step is to reconcile it with the related bank statement line to have the transaction finalized
|
||||
and the invoice or bill marked as :guilabel:`Paid`.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`bank/reconciliation`
|
||||
next step is :doc:`reconciling <bank/reconciliation>` it with the related bank statement line to
|
||||
have the transaction finalized and the invoice or bill marked as :guilabel:`Paid`.
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
@@ -141,6 +150,5 @@ and the invoice or bill marked as :guilabel:`Paid`.
|
||||
payments/internal_transfers
|
||||
payments/pay_sepa
|
||||
payments/pay_checks
|
||||
payments/multiple
|
||||
payments/forecast
|
||||
payments/trusted_accounts
|
||||
|
||||
|
Before Width: | Height: | Size: 5.1 KiB After Width: | Height: | Size: 6.3 KiB |
@@ -25,7 +25,6 @@ window, select the :guilabel:`Journal` linked to your bank account and :guilabel
|
||||
the :guilabel:`Payment Method`, and click :guilabel:`Create Payment`.
|
||||
|
||||
.. image:: batch/batch-payments.png
|
||||
:align: center
|
||||
:alt: Registering a customer payment as part of a batch deposit
|
||||
|
||||
Add payments to a batch deposit
|
||||
@@ -36,14 +35,12 @@ Payments`, and click :guilabel:`New`. Next, select the :guilabel:`Bank` and choo
|
||||
Deposit` as the :guilabel:`Payment Method`.
|
||||
|
||||
.. image:: batch/batch-customer-payment.png
|
||||
:align: center
|
||||
:alt: Filling out a new inbound batch payment form
|
||||
|
||||
Click :guilabel:`Add a line`. In the pop-up window, tick all payments to include in the batch
|
||||
deposit, then click :guilabel:`Select`.
|
||||
|
||||
.. image:: batch/batch-lines-selection.png
|
||||
:align: center
|
||||
:alt: Selecting all payments to include in the batch deposit
|
||||
|
||||
Once done, click :guilabel:`Validate` to finalize the batch deposit.
|
||||
@@ -60,7 +57,6 @@ Items` on the related bank account. Go to the :guilabel:`Batch Payments` tab to
|
||||
batch and click :guilabel:`Validate` to finalize the process.
|
||||
|
||||
.. image:: batch/batch-reconciliation.png
|
||||
:align: center
|
||||
:alt: Reconciling the batch payment with all its transactions
|
||||
|
||||
.. note::
|
||||
|
||||
|
Before Width: | Height: | Size: 7.4 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 7.5 KiB |
|
Before Width: | Height: | Size: 8.0 KiB After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 47 KiB |