Compare commits
1 Commits
14.0-chpr-
...
14.0-domai
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
dcf8dd1701 |
[IMP] install/maintain: add section about search engine indexation
task-3179504 |
|
|
@@ -281,8 +281,8 @@ Git
|
|||
The following requires `Git <git_>`_ to be installed on your machine and that you have basic
|
||||
knowledge of Git commands. To clone a Git repository, you must choose between cloning with HTTPS or
|
||||
SSH. If you do not know the difference between the two, the best option is most likely HTTPS. If you
|
||||
are following the :doc:`Getting started </developer/tutorials/getting_started>` developer tutorial,
|
||||
or plan on contributing to Odoo source code, choose SSH.
|
||||
are following the :doc:`Getting started </developer/howtos/rdtraining>` developer tutorial, or plan
|
||||
on contributing to Odoo source code, choose SSH.
|
||||
|
||||
.. note::
|
||||
**The Enterprise Git repository does not contain the full Odoo source code**. It is only a
|
||||
|
|
@@ -437,7 +437,7 @@ just logged into your own Odoo database!
|
|||
<odoo-bin -r>` CLI argument.
|
||||
|
||||
.. seealso::
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/reference/cli>`.
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/cli>`.
|
||||
|
||||
.. _setup/install/source/linux:
|
||||
|
||||
|
|
@@ -471,8 +471,8 @@ Git
|
|||
The following requires `Git <git_>`_ to be installed on your machine and that you have basic
|
||||
knowledge of Git commands. To clone a Git repository, you must choose between cloning with HTTPS or
|
||||
SSH. If you do not know the difference between the two, the best option is most likely HTTPS. If you
|
||||
are following the :doc:`Getting started </developer/tutorials/getting_started>` developer tutorial,
|
||||
or plan on contributing to Odoo source code, choose SSH.
|
||||
are following the :doc:`Getting started </developer/howtos/rdtraining>` developer tutorial, or plan
|
||||
on contributing to Odoo source code, choose SSH.
|
||||
|
||||
.. note::
|
||||
**The Enterprise Git repository does not contain the full Odoo source code**. It is only a
|
||||
|
|
@@ -632,7 +632,7 @@ just logged into your own Odoo database!
|
|||
<odoo-bin -r>` CLI argument.
|
||||
|
||||
.. seealso::
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/reference/cli>`.
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/cli>`.
|
||||
|
||||
.. _setup/install/source/mac_os:
|
||||
|
||||
|
|
@@ -666,8 +666,8 @@ Git
|
|||
The following requires `Git <git_>`_ to be installed on your machine and that you have basic
|
||||
knowledge of Git commands. To clone a Git repository, you must choose between cloning with HTTPS or
|
||||
SSH. If you do not know the difference between the two, the best option is most likely HTTPS. If you
|
||||
are following the :doc:`Getting started </developer/tutorials/getting_started>` developer tutorial,
|
||||
or plan on contributing to Odoo source code, choose SSH.
|
||||
are following the :doc:`Getting started </developer/howtos/rdtraining>` developer tutorial, or plan
|
||||
on contributing to Odoo source code, choose SSH.
|
||||
|
||||
.. note::
|
||||
**The Enterprise Git repository does not contain the full Odoo source code**. It is only a
|
||||
|
|
@@ -830,7 +830,7 @@ just logged into your own Odoo database!
|
|||
<odoo-bin -r>` CLI argument.
|
||||
|
||||
.. seealso::
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/reference/cli>`.
|
||||
:doc:`The exhaustive list of CLI arguments for odoo-bin </developer/cli>`.
|
||||
|
||||
.. _setup/install/docker:
|
||||
|
||||
|
|
|
|||
|
|
@@ -167,7 +167,7 @@ In the above commands, the argument:
|
|||
* ``--stop-after-init`` will immediately shutdown the server instance after it completed the operations you asked.
|
||||
|
||||
More options are available and detailed in the
|
||||
:doc:`CLI documentation </developer/reference/cli>`.
|
||||
:doc:`CLI documentation </developer/cli>`.
|
||||
|
||||
You can find in the logs (*~/logs/odoo.log*) the addons path used by Odoo.sh to run your server.
|
||||
Look for "*odoo: addons paths*":
|
||||
|
|
|
|||
|
|
@@ -42,7 +42,7 @@ instance will be held temporarily unavailable for maintenance reason.
|
|||
|
||||
This method is equivalent to perform an upgrade of the module through the Apps menu,
|
||||
or through the :code:`-u` switch of
|
||||
:doc:`the command line </developer/reference/cli>`.
|
||||
:doc:`the command line </developer/cli>`.
|
||||
|
||||
In the case the changes in the commit prevent the server to restart,
|
||||
or if the modules update fails,
|
||||
|
|
|
|||
|
|
@@ -146,7 +146,7 @@ Manually
|
|||
--------
|
||||
|
||||
If you want to create your module structure manually,
|
||||
you can follow the :doc:`/developer/tutorials/getting_started` tutorial to understand
|
||||
you can follow :doc:`Build an Odoo module </developer/howtos/backend>` to understand
|
||||
the structure of a module and the content of each file.
|
||||
|
||||
Push the development branch
|
||||
|
|
|
|||
|
|
@@ -16,7 +16,7 @@ accounts, smart matching suggestions, etc.
|
|||
|
||||
.. seealso::
|
||||
- `Odoo Tutorials: Accounting <https://www.odoo.com/slides/accounting-19>`_
|
||||
- :doc:`Accounting Cheat Sheet <accounting/getting_started/cheat_sheet>`
|
||||
- :doc:`Accounting Cheat Sheet <accounting/getting_started/memento>`
|
||||
|
||||
|
||||
.. toctree::
|
||||
|
|
|
|||
|
|
@@ -8,6 +8,6 @@ Getting started
|
|||
:titlesonly:
|
||||
|
||||
getting_started/main_concept
|
||||
getting_started/cheat_sheet
|
||||
getting_started/memento
|
||||
getting_started/initial_configuration
|
||||
getting_started/process_overview
|
||||
|
|
|
|||
|
|
@@ -1,253 +0,0 @@
|
|||
:code-column:
|
||||
:custom-css: accounting.css
|
||||
:custom-js: accounts.js,chart-of-accounts.js,entries.js,misc.js,reconciliation.js
|
||||
|
||||
======================
|
||||
Accounting cheat sheet
|
||||
======================
|
||||
|
||||
.. h:div:: intro-list
|
||||
|
||||
.. rst-class:: intro-balance
|
||||
|
||||
The **Balance Sheet** is a snapshot of the company's finances at a specific date (as opposed to
|
||||
the Profit and Loss, which is an analysis over a period).
|
||||
|
||||
* .. rst-class:: intro-assets
|
||||
|
||||
**Assets** represent the company's wealth and the goods it owns. Fixed assets include buildings
|
||||
and offices, while current assets include bank accounts and cash. The money owed by a client is
|
||||
an asset. An employee is not an asset.
|
||||
|
||||
* .. rst-class:: intro-liabilities
|
||||
|
||||
**Liabilities** are obligations from past events that the company will have to pay in the
|
||||
future (utility bills, debts, unpaid suppliers). Liabilities could also be defined as a source
|
||||
of financing which is provided to the company, also called *leverage*.
|
||||
|
||||
* .. rst-class:: intro-equity
|
||||
|
||||
**Equity** is the amount of the funds contributed by the owners of the company (founders or
|
||||
shareholders) plus previously retained earnings (or losses). Each year, net profits (or losses)
|
||||
may be reported as retained earnings or distributed to the shareholders (as a dividend).
|
||||
|
||||
What is owned (an asset) has been financed through debts to reimburse (liabilities) or equity
|
||||
(profits, capital).
|
||||
|
||||
A difference is made between **assets** and **expenses**:
|
||||
- An **asset** is a resource with economic value that an individual, corporation, or country owns
|
||||
or controls with the expectation that it will provide a future benefit. Assets are reported on
|
||||
a company's balance sheet. They are bought or created to increase a firm's value or benefit its
|
||||
operations.
|
||||
- An **expense** is the costs of operations a company bears to generate revenues.
|
||||
|
||||
.. h:div:: intro-list
|
||||
|
||||
.. rst-class:: intro-p-l
|
||||
|
||||
The **profit and loss** (P&L) report shows the company's performance over a specific period of
|
||||
time, usually a quarter or a fiscal year.
|
||||
|
||||
* .. rst-class:: intro-gross-profit
|
||||
|
||||
The **revenue** refers to the money earned by the company by selling goods and/or services.
|
||||
|
||||
* .. rst-class:: intro-gross-profit
|
||||
|
||||
The **cost of goods sold** (COGS, or also known as "Cost of Sale") refers to the sale of
|
||||
goods' costs (e.g., the cost of the materials and labor used to create the goods).
|
||||
|
||||
* .. rst-class:: intro-gross-profit
|
||||
|
||||
The **Gross profit** equals the revenues from sales minus the cost of goods sold.
|
||||
|
||||
* .. rst-class:: intro-opex
|
||||
|
||||
**Operating expenses** (OPEX) include administration, sales and R&D salaries, rent and
|
||||
utilities, miscellaneous costs, insurances, and anything beyond the costs of products sold
|
||||
or the cost of sale.
|
||||
|
||||
.. h:div:: doc-aside accounts-table
|
||||
|
||||
.. placeholder
|
||||
|
||||
.. rst-class:: doc-aside
|
||||
|
||||
.. highlights:: Assets = Liabilities + Equity
|
||||
|
||||
Chart of accounts
|
||||
=================
|
||||
|
||||
The **chart of accounts** lists all the company's accounts: both Balance sheet accounts and P&L
|
||||
accounts. Every transaction is recorded by debiting and crediting multiple accounts in a journal
|
||||
entry. In a way, a chart of accounts is like a company's DNA!
|
||||
|
||||
Every account listed in the chart of accounts belongs to a specific category. In Odoo, each account
|
||||
has a unique code and belongs to one of these categories:
|
||||
|
||||
- **Equity and subordinated debts**
|
||||
- **Equity** is the amount of money invested by a company's shareholders to finance the
|
||||
company's activities.
|
||||
- **Subordinated debts** are the amount of money lent by a third party to a company to finance
|
||||
its activities. In the event of the dissolution of a company, these third parties are
|
||||
reimbursed before the shareholders.
|
||||
- **Fixed assets** are tangible (i.e., physical) items or properties that a company purchases and
|
||||
uses to produce its goods and services. Fixed assets are long-term assets. This means the assets
|
||||
have a useful life of more than one year. They also include properties, plants, and equipments
|
||||
(also known as "PP&E") and are recorded on the balance sheet with that classification.
|
||||
- **Current assets and liabilities**
|
||||
- The **current assets** account is a balance sheet line item listed under the Assets section,
|
||||
which accounts for all company-owned assets that can be converted to cash within one year.
|
||||
Current assets include cash, cash equivalents, accounts receivable, stock inventory,
|
||||
marketable securities, prepaid liabilities, and other liquid assets.
|
||||
- **Current liabilities** are a company's short-term financial obligations due within one year.
|
||||
An example of a current liability is money owed to suppliers in the form of accounts payable.
|
||||
- **Bank and cash accounts**
|
||||
- A **bank account** is a financial account maintained by a bank or other financial institution
|
||||
in which the financial transactions between the bank and a customer are recorded.
|
||||
- A **cash account**, or cash book, may refer to a ledger in which all cash transactions are
|
||||
recorded. The cash account includes both the cash receipts and the cash payment journals.
|
||||
- **Expenses and income**
|
||||
- An **expense** is the costs of operations a company bears to generate revenues. It is simply
|
||||
defined as the cost one is required to spend on obtaining something. Common expenses include
|
||||
supplier payments, employee wages, factory leases, and equipment depreciation.
|
||||
- The term "**income**" generally refers to the amount of money, property, and other transfers
|
||||
of value received over a set period of time in exchange for services or products.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
.. h:div:: example
|
||||
|
||||
\*: Customer Refund and Customer Payment boxes cannot be simultaneously selected as they are contradictory.
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
.. highlights:: Balance = Debit - Credit
|
||||
|
||||
.. h:div:: chart-of-accounts
|
||||
|
||||
.. placeholder
|
||||
|
||||
Journal entries
|
||||
===============
|
||||
|
||||
Every financial document of the company (e.g., an invoice, a bank statement, a pay slip, a capital
|
||||
increase contract) is recorded as a journal entry, impacting several accounts.
|
||||
|
||||
For a journal entry to be balanced, the sum of all its debits must be equal to the sum of all its
|
||||
credits.
|
||||
|
||||
.. h:div:: doc-aside journal-entries
|
||||
|
||||
examples of accounting entries for various transactions. (see entries.js)
|
||||
|
||||
.. _accounting/reconciliation:
|
||||
|
||||
Reconciliation
|
||||
==============
|
||||
|
||||
:doc:`Reconciliation <../../accounting/bank/reconciliation/use_cases>` is the process of linking
|
||||
journal items of a specific account and matching credits and debits.
|
||||
|
||||
Its primary purpose is to link payments to their related invoices to mark them as paid. This is done
|
||||
by doing a reconciliation on the accounts receivable account and/or the accounts payable account.
|
||||
|
||||
Reconciliation is performed automatically by the system when:
|
||||
|
||||
- the payment is registered directly on the invoice
|
||||
- the links between the payments and the invoices are detected at the bank matching process
|
||||
|
||||
.. h:div:: doc-aside reconciliation-example
|
||||
|
||||
.. rubric:: Customer Statement Example
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Accounts Receivable |Debit |Credit |
|
||||
+=========================+=========================+=======================+
|
||||
|Invoice 1 |100 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Partial payment 1/2 | |70 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Invoice 2 |65 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Partial payment 2/2 | |30 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Payment 2 | |65 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Invoice 3 |50 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
| | | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Total to pay |50 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|
||||
Bank Reconciliation
|
||||
===================
|
||||
|
||||
Bank reconciliation is the matching of bank statement lines (provided by your bank) with
|
||||
transactions recorded internally (payments to suppliers or from customers). For each line in a bank
|
||||
statement, it can be:
|
||||
|
||||
- **matched with a previously recorded payment**: a payment is registered when a check is received
|
||||
from a customer, then matched when checking the bank statement.
|
||||
- **recorded as a new payment**: the payment's journal entry is created and reconciled with the
|
||||
related invoice when processing the bank statement.
|
||||
- **recorded as another transaction**: bank transfer, direct charge, etc.
|
||||
|
||||
Odoo should automatically reconcile most transactions; only a few should need manual review. When
|
||||
the bank reconciliation process is finished, the balance on the bank account in Odoo should match
|
||||
the bank statement's balance.
|
||||
|
||||
.. rst-class:: checks-handling
|
||||
|
||||
Checks Handling
|
||||
===============
|
||||
|
||||
There are two approaches to managing checks and internal wire transfers:
|
||||
|
||||
- Two journal entries and a reconciliation
|
||||
- One journal entry and a bank reconciliation
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
The first journal entry is created by registering the payment on the
|
||||
invoice. The second one is created when registering the bank statement.
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |
|
||||
+=========================+==============+============+===============+
|
||||
|Account Receivable | |100 |Invoice ABC |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Undeposited funds |100 | |Check 0123 |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |
|
||||
+=========================+==============+============+===============+
|
||||
|Undeposited funds | |100 |Check 0123 |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Bank |100 | | |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
A journal entry is created by registering the payment on the invoice. When
|
||||
reconciling the bank statement, the statement line is linked to the
|
||||
existing journal entry.
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |Bank Statement |
|
||||
+=========================+==============+============+===============+===============+
|
||||
|Account Receivable | |100 |Invoice ABC | |
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|Bank |100 | | |Statement XYZ |
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|
|
@@ -180,7 +180,6 @@ them unusable by using the **Deprecated** feature.
|
|||
To do so, check the :guilabel:`Deprecated` box in the account's settings, and save.
|
||||
|
||||
.. seealso::
|
||||
* :doc:`../cheat_sheet`
|
||||
* :doc:`../../payables/supplier_bills/assets`
|
||||
* :doc:`../../payables/supplier_bills/deferred_expenses`
|
||||
* :doc:`../../receivables/customer_invoices/deferred_revenues`
|
||||
|
|
|
|||
|
|
@@ -14,7 +14,7 @@ entries are automatically balanced (sum of debits = sum of credits).
|
|||
|
||||
.. seealso::
|
||||
- :doc:`Understand Odoo's accounting transactions per document
|
||||
<cheat_sheet>`
|
||||
<memento>`
|
||||
|
||||
Accrual and Cash Basis Methods
|
||||
==============================
|
||||
|
|
|
|||
|
|
@@ -0,0 +1,249 @@
|
|||
:code-column:
|
||||
:custom-css: accounting.css
|
||||
:custom-js: accounts.js,chart-of-accounts.js,entries.js,misc.js,reconciliation.js
|
||||
|
||||
======================
|
||||
Accounting cheat sheet
|
||||
======================
|
||||
|
||||
.. h:div:: intro-list
|
||||
|
||||
.. rst-class:: intro-p-l
|
||||
|
||||
The **Profit and Loss** (P&L) report shows the performance of the company
|
||||
over a specific period (usually the current year).
|
||||
|
||||
* .. rst-class:: intro-gross-profit
|
||||
|
||||
The **Gross Profit** equals the revenues from sales minus the cost of
|
||||
goods sold.
|
||||
|
||||
* .. rst-class:: intro-opex
|
||||
|
||||
**Operating Expenses** (OPEX) include administration, sales and R&D
|
||||
salaries as well as rent and utilities, miscellaneous costs, insurances,
|
||||
… anything beyond the costs of products sold.
|
||||
|
||||
.. rst-class:: intro-balance
|
||||
|
||||
The **Balance Sheet** is a snapshot of the company's finances at a specific
|
||||
date (as opposed to the Profit and Loss which is an analysis over a period)
|
||||
|
||||
* .. rst-class:: intro-assets
|
||||
|
||||
**Assets** represent the company's wealth, things it owns. Fixed assets
|
||||
includes building and offices, current assets include bank accounts and
|
||||
cash. A client owing money is an asset. An employee is not an asset.
|
||||
|
||||
* .. rst-class:: intro-liabilities
|
||||
|
||||
**Liabilities** are obligations from past events that the company will
|
||||
have to pay in the future (utility bills, debts, unpaid suppliers).
|
||||
|
||||
* .. rst-class:: intro-equity
|
||||
|
||||
**Equity** is the amount of the funds contributed by the owners (founders
|
||||
or shareholders) plus previously retained earnings (or losses).
|
||||
|
||||
.. rst-class:: intro-retained
|
||||
|
||||
Each year, net profits (or losses) are reported to retained earnings.
|
||||
|
||||
.. h:div:: doc-aside accounts-table
|
||||
|
||||
.. placeholder
|
||||
|
||||
What is owned (an asset) has been financed through debts to reimburse
|
||||
(liabilities) or equity (profits, capital).
|
||||
|
||||
A difference is made between buying an assets (e.g. a building) and expenses
|
||||
(e.g. fuel). Assets have an intrinsic value over time, versus expenses having
|
||||
value in them being consumed for the company to "work".
|
||||
|
||||
|
||||
.. rst-class:: doc-aside
|
||||
|
||||
.. highlights:: Assets = Liabilities + Equity
|
||||
|
||||
Chart of Accounts
|
||||
=================
|
||||
|
||||
The **chart of accounts** lists all the accounts, whether they are balance
|
||||
sheet accounts or P&L accounts. Every financial transaction (e.g. a payment, an
|
||||
invoice) impacts accounts by moving value from one account (credit) to an other
|
||||
account (debit).
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
.. highlights:: Balance = Debit - Credit
|
||||
|
||||
.. h:div:: chart-of-accounts
|
||||
|
||||
.. placeholder
|
||||
|
||||
|
||||
Journal Entries
|
||||
===============
|
||||
|
||||
Every financial document of the company (e.g. an invoice, a bank statement, a
|
||||
pay slip, a capital increase contract) is recorded as a journal entry,
|
||||
impacting several accounts.
|
||||
|
||||
For a journal entry to be *balanced*, the sum of all its debits must be equal
|
||||
to the sum of all its credits.
|
||||
|
||||
.. h:div:: doc-aside journal-entries
|
||||
|
||||
examples of accounting entries for various transactions. Example:
|
||||
|
||||
Example 1: Customer Invoice:
|
||||
|
||||
Explanation:
|
||||
|
||||
- You generate a revenue of $1,000
|
||||
- You have a tax to pay of $90
|
||||
- The customer owes $1,090
|
||||
|
||||
Configuration:
|
||||
|
||||
- Income: defined on the product, or the product category
|
||||
- Account Receivable: defined on the customer
|
||||
- Tax: defined on the tax set on the invoice line
|
||||
|
||||
The fiscal position used on the invoice may have a rule that
|
||||
replaces the Income Account or the tax defined on the product by another
|
||||
one.
|
||||
|
||||
Example 2: Customer Payment:
|
||||
|
||||
Explanation:
|
||||
|
||||
- Your customer owes $1,090 less
|
||||
- Your receive $1,090 on your bank account
|
||||
|
||||
Configuration:
|
||||
|
||||
- Bank Account: defined on the related bank journal
|
||||
- Account Receivable: defined on the customer
|
||||
|
||||
.. _accounting/reconciliation:
|
||||
|
||||
Reconciliation
|
||||
==============
|
||||
|
||||
Reconciliation is the process of linking journal items of a specific account,
|
||||
matching credits and debits.
|
||||
|
||||
Its primary purpose is to link payments to their related invoices in order to
|
||||
mark invoices that are paid and clear the customer statement. This is done by
|
||||
doing a reconciliation on the *Accounts Receivable* account.
|
||||
|
||||
An invoice is marked as paid when its Accounts Receivable journal items are
|
||||
reconciled with the related payment journal items.
|
||||
|
||||
Reconciliation is performed automatically by the system when:
|
||||
|
||||
* the payment is registered directly on the invoice
|
||||
* the links between the payments and the invoices are detected at the bank
|
||||
matching process
|
||||
|
||||
|
||||
.. h:div:: doc-aside reconciliation-example
|
||||
|
||||
.. rubric:: Customer Statement Example
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Accounts Receivable |Debit |Credit |
|
||||
+=========================+=========================+=======================+
|
||||
|Invoice 1 |100 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Payment 1.1 | |70 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Invoice 2 |65 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Payment 1.2 | |30 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Payment 2 | |65 |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Invoice 3 |50 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
| | | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|Total To Pay |50 | |
|
||||
+-------------------------+-------------------------+-----------------------+
|
||||
|
||||
|
||||
Bank Reconciliation
|
||||
===================
|
||||
|
||||
Bank reconciliation is the matching of bank statement lines (provided by your
|
||||
bank) with transactions recorded internally (payments to suppliers or from
|
||||
customers). For each line in a bank statement, it can be:
|
||||
|
||||
matched with a previously recorded payment:
|
||||
a payment is registered when a check is received from a customer, then
|
||||
matched when checking the bank statement
|
||||
recorded as a new payment:
|
||||
the payment's journal entry is created and :ref:`reconciled
|
||||
<accounting/reconciliation>` with the related invoice when processing the
|
||||
bank statement
|
||||
recorded as another transaction:
|
||||
bank transfer, direct charge, etc.
|
||||
|
||||
Odoo should automatically reconcile most transactions, only a few of them
|
||||
should need manual review. When the bank reconciliation process is finished,
|
||||
the balance on the bank account in Odoo should match the bank statement's
|
||||
balance.
|
||||
|
||||
.. rst-class:: checks-handling
|
||||
|
||||
Checks Handling
|
||||
===============
|
||||
|
||||
There are two approaches to manage checks and internal wire transfer:
|
||||
|
||||
* Two journal entries and a reconciliation
|
||||
* One journal entry and a bank reconciliation
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
The first journal entry is created by registering the payment on the
|
||||
invoice. The second one is created when registering the bank statement.
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |
|
||||
+=========================+==============+============+===============+
|
||||
|Account Receivable | |100 |Invoice ABC |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Undeposited funds |100 | |Check 0123 |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |
|
||||
+=========================+==============+============+===============+
|
||||
|Undeposited funds | |100 |Check 0123 |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|Bank |100 | | |
|
||||
+-------------------------+--------------+------------+---------------+
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
A journal entry is created by registering the payment on the invoice. When
|
||||
reconciling the bank statement, the statement line is linked to the
|
||||
existing journal entry.
|
||||
|
||||
.. rst-class:: table-sm d-c-table
|
||||
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|Account |Debit |Credit |Reconciliation |Bank Statement |
|
||||
+=========================+==============+============+===============+===============+
|
||||
|Account Receivable | |100 |Invoice ABC | |
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|Bank |100 | | |Statement XYZ |
|
||||
+-------------------------+--------------+------------+---------------+---------------+
|
||||
|
|
@@ -365,12 +365,6 @@ For **vendor bills**, **three** types of configurations are technically identifi
|
|||
- All invoice lines either have :guilabel:`Consumable` products, or a tax with
|
||||
:guilabel:`Goods` as tax scope.
|
||||
|
||||
.. warning::
|
||||
Odoo does not offer the
|
||||
`Conservazione Sostitutiva <https://www.agid.gov.it/index.php/it/piattaforme/conservazione>`_
|
||||
requirements. Other providers and **Agenzia delle Entrate** supply free and certified storage to
|
||||
meet the requested conditions.
|
||||
|
||||
.. _italy/internal-reverse:
|
||||
|
||||
Internal reverse charge
|
||||
|
|
|
|||
|
|
@@ -67,4 +67,5 @@ Offering my own services
|
|||
|
||||
I am more than welcome to offer my own IAP services through Odoo Apps! It is the perfect opportunity
|
||||
to get recurring revenue for an ongoing service use rather than — and possibly instead of — a sole
|
||||
initial purchase. Please, find more information at: :doc:`/developer/howtos/provide_iap_services`.
|
||||
initial purchase. Please, find more information at: :doc:`In-App Purchase
|
||||
</developer/api/iap>`.
|
||||
|
|
|
|||
|
|
@@ -17,4 +17,3 @@ can be applied. Users and access rights can be added and changed at any point.
|
|||
users/language
|
||||
users/access_rights
|
||||
users/companies
|
||||
users/portal
|
||||
|
|
|
|||
|
|
@@ -1,132 +1,424 @@
|
|||
:code-column:
|
||||
:custom-css: accounting.css
|
||||
:custom-js: coa-valuation-continental.js,coa-valuation-anglo-saxon.js,misc.js
|
||||
|
||||
=================================
|
||||
Inventory Valuation Configuration
|
||||
Inventory valuation configuration
|
||||
=================================
|
||||
|
||||
All of a company's stock on-hand contributes to the valuation of its inventory. That value should
|
||||
be reflected in the company's accounting records to accurately show the value of the company and
|
||||
all of its assets.
|
||||
Inventory valuation refers to how you value your stock. It’s a very
|
||||
important aspect of a business as the inventory can be the biggest asset
|
||||
of a company.
|
||||
|
||||
By default, Odoo uses a periodic inventory valuation (also known as manual inventory valuation).
|
||||
This method implies that the accounting team posts journal entries based on the physical inventory
|
||||
of the company, and that warehouse employees take the time to count the stock. In Odoo, this method
|
||||
is reflected inside each product category, where the :guilabel:`Costing Method` field will be set
|
||||
to `Standard Price` by default, and the :guilabel:`Inventory Valuation` field will be set to
|
||||
`Manual`.
|
||||
Inventory valuation implies two main choices:
|
||||
|
||||
.. image:: inventory_valuation_config/inventory-valuation-fields.png
|
||||
:align: center
|
||||
:alt: The Inventory Valuation fields are located on the Product Categories form.
|
||||
- The cost method you use to value your goods (standard, fifo, avco)
|
||||
- The way you record this value into your accounting books (manually or automatically)
|
||||
|
||||
Alternatively, automated inventory valuation is an integrated valuation method that updates the
|
||||
inventory value in real-time by creating journal entries whenever there are stock moves initiated
|
||||
between locations in a company's inventory.
|
||||
Those two concepts are explained in the sections below.
|
||||
|
||||
.. note::
|
||||
Automated inventory valuation is a method recommended for expert accountants, given the extra
|
||||
steps involved in journal entry configuration. Even after the initial setup, the method will
|
||||
need to be periodically checked to ensure accuracy, and adjustments may be needed on an ongoing
|
||||
basis depending on the needs and priorities of the business.
|
||||
Costing Methods: Standard, FIFO, AVCO
|
||||
=====================================
|
||||
|
||||
Types of Accounting
|
||||
-------------------
|
||||
The costing method is defined in the product category. There are three
|
||||
options available. Each of them is explained in detail below.
|
||||
|
||||
Accounting entries will depend on the accounting mode: Continental or Anglo-Saxon.
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
.. tip::
|
||||
Verify the accounting mode by activating the :ref:`developer-mode`
|
||||
and navigating to :menuselection:`Accounting --> Configuration --> Settings`.
|
||||
Standard Price
|
||||
.. rst-class:: values-table
|
||||
|
||||
In Anglo-Saxon accounting, the costs of goods sold (COGS) are reported when products are sold or
|
||||
delivered. This means that the cost of a good is only recorded as an expense when a customer is
|
||||
invoiced for a product. Interim Stock Accounts are used for the input and output accounts, and are
|
||||
both Asset Accounts in the Balance Sheet.
|
||||
.. list-table::
|
||||
:widths: 28 18 18 18 18
|
||||
:header-rows: 1
|
||||
:stub-columns: 1
|
||||
|
||||
In Continental accounting, the cost of a good is reported as soon as a product is received into
|
||||
stock. Additionally, a *single* Expense account is used for both input and output accounts in
|
||||
the Balance Sheet.
|
||||
* - Operation
|
||||
- Unit Cost
|
||||
- Qty On Hand
|
||||
- Delta Value
|
||||
- Inventory Value
|
||||
* -
|
||||
- €10
|
||||
- 0
|
||||
-
|
||||
- €0
|
||||
* - Receive 8 Products at €10
|
||||
- €10
|
||||
- 8
|
||||
- +8*€10
|
||||
- €80
|
||||
* - Receive 4 Products at €16
|
||||
- €10
|
||||
- 12
|
||||
- +4*€10
|
||||
- €120
|
||||
* - Deliver 10 Products
|
||||
- €10
|
||||
- 2
|
||||
- | -10*€10
|
||||
|
|
||||
- €20
|
||||
* - Receive 2 Products at €9
|
||||
- €10
|
||||
- 4
|
||||
- +2*€10
|
||||
- €40
|
||||
|
||||
Costing Methods
|
||||
---------------
|
||||
In **Standard Price**, any product will be valued at the cost that you defined
|
||||
manually on the product form. Usually, this cost is an estimation based
|
||||
on the material and labor needed to obtain the product. This cost must
|
||||
be reviewed periodically.
|
||||
|
||||
Below are the three costing methods that can be used in Odoo for inventory valuation.
|
||||
Average Price
|
||||
.. rst-class:: values-table
|
||||
|
||||
- **Standard Price**: is the default costing method in Odoo. The cost of the product is manually
|
||||
defined on the product form, and this cost is used to compute the valuation. Even if the purchase
|
||||
price on a Purchase Order differs, the valuation will still use the cost defined on the product
|
||||
form.
|
||||
- **Average Cost (AVCO)**: calculates the valuation of a product based on the average cost of that
|
||||
product, divided by the total number of available stock on-hand. With this costing method,
|
||||
inventory valuation is *dynamic*, and constantly adjusts based on the purchase price of products.
|
||||
- **First In First Out (FIFO)**: tracks the costs of incoming and outgoing items in real-time and
|
||||
uses the real price of the products to change the valuation. The oldest purchase price is used as
|
||||
the cost for the next good sold until an entire lot of that product is sold. When the next
|
||||
inventory lot moves up in the queue, an updated product cost is used based on the valuation of
|
||||
that specific lot. This method is arguably the most accurate inventory valuation method for a
|
||||
variety of reasons, however, it's highly sensitive to input data and human error.
|
||||
.. list-table::
|
||||
:widths: 28 18 18 18 18
|
||||
:header-rows: 1
|
||||
:stub-columns: 1
|
||||
|
||||
.. warning::
|
||||
Changing the costing method greatly impacts inventory valuation. It's highly recommended to
|
||||
consult an accountant first before making any adjustments here.
|
||||
* - Operation
|
||||
- Unit Cost
|
||||
- Qty On Hand
|
||||
- Delta Value
|
||||
- Inventory Value
|
||||
* -
|
||||
- €0
|
||||
- 0
|
||||
-
|
||||
- €0
|
||||
* - Receive 8 Products at €10
|
||||
- €10
|
||||
- 8
|
||||
- +8*€10
|
||||
- €80
|
||||
* - Receive 4 Products at €16
|
||||
- €12
|
||||
- 12
|
||||
- +4*€16
|
||||
- €144
|
||||
* - Deliver 10 Products
|
||||
- €12
|
||||
- 2
|
||||
- | -10*€12
|
||||
|
|
||||
- €24
|
||||
* - Receive 2 Products at €6
|
||||
- €9
|
||||
- 4
|
||||
- +2*€6
|
||||
- €36
|
||||
|
||||
Configure automated inventory valuation in Odoo
|
||||
-----------------------------------------------
|
||||
In **AVCO (Average Cost)**, each product has the same value and this
|
||||
value is the average purchase cost of the product. With this costing method, the
|
||||
cost of the product is recomputed as each receipt.
|
||||
|
||||
Make changes to inventory valuation options by navigating to :menuselection:`Inventory -->
|
||||
Configuration --> Product Categories`, and choose the category/categories where the automated
|
||||
valuation method should apply.
|
||||
The average cost does not change when products leave the warehouse.
|
||||
|
||||
.. note::
|
||||
It is possible to use different valuation settings for different product categories.
|
||||
FIFO
|
||||
.. rst-class:: values-table
|
||||
|
||||
Under the :guilabel:`Inventory Valuation` heading are two labels: :guilabel:`Costing Method` and
|
||||
:guilabel:`Inventory Valuation`. Pick the desired :guilabel:`Costing Method` using the drop-down
|
||||
menu (e.g. :guilabel:`Standard`, :guilabel:`Average Cost (AVCO)`, or :guilabel:`First In First Out
|
||||
(FIFO)` and switch the :guilabel:`Inventory Valuation` to :guilabel:`Automated`.
|
||||
.. list-table::
|
||||
:widths: 28 18 18 18 18
|
||||
:header-rows: 1
|
||||
:stub-columns: 1
|
||||
|
||||
.. seealso::
|
||||
:doc:`Using the inventory valuation <using_inventory_valuation>`
|
||||
* - Operation
|
||||
- Unit Cost
|
||||
- Qty On Hand
|
||||
- Delta Value
|
||||
- Inventory Value
|
||||
* -
|
||||
- €0
|
||||
- 0
|
||||
-
|
||||
- €0
|
||||
* - Receive 8 Products at €10
|
||||
- €10
|
||||
- 8
|
||||
- +8*€10
|
||||
- €80
|
||||
* - Receive 4 Products at €16
|
||||
- €12
|
||||
- 12
|
||||
- +4*€16
|
||||
- €144
|
||||
* - Deliver 10 Products
|
||||
- €16
|
||||
- 2
|
||||
- | -8*€10
|
||||
| -2*€16
|
||||
- €32
|
||||
* - Receive 2 Products at €6
|
||||
- €11
|
||||
- 4
|
||||
- +2*€6
|
||||
- €44
|
||||
|
||||
.. note::
|
||||
When choosing :guilabel:`Average Cost (AVCO)` as the :guilabel:`Costing Method`, the numerical
|
||||
value in the :guilabel:`Cost` field for products in the respective product category will no
|
||||
longer be editable, and will appear grayed out. The :guilabel:`Cost` amount will instead
|
||||
automatically update based on the average purchase price both of inventory on hand and the costs
|
||||
accumulated from validated purchase orders.
|
||||
In **FIFO (First In First Out)**, the products are valued at their
|
||||
purchase cost. When a product leaves the stock, that’s the “First in,
|
||||
first out” rule that applies.
|
||||
|
||||
On the same screen, the :guilabel:`Account Stock Properties` fields will appear, as they are now
|
||||
required fields given the change to automated inventory valuation. These accounts are defined as
|
||||
follows:
|
||||
Pay attention, that this is a financial FIFO. The first value “in”
|
||||
is the first value “out”, no matter the storage location, warehouse
|
||||
or serial number.
|
||||
|
||||
- :guilabel:`Stock Valuation Account`: when automated inventory valuation is enabled on a product,
|
||||
this account will hold the current value of the products.
|
||||
- :guilabel:`Stock Input Account`: counterpart journal items for all incoming stock moves will be
|
||||
posted in this account, unless there is a specific valuation account set on the source location.
|
||||
This is the default value for all products in a given category, and can also be set directly on
|
||||
each product.
|
||||
- :guilabel:`Stock Output Account`: counterpart journal items for all outgoing stock moves will be
|
||||
posted in this account, unless there is a specific valuation account set on the destination
|
||||
location. This is the default value for all products in a given category, and can also be set
|
||||
directly on each product.
|
||||
FIFO is advised if you manage all your workflows into Odoo (Sales,
|
||||
Purchases, Inventory). It suits any kind of users.
|
||||
|
||||
Access reporting data generated by inventory valuation
|
||||
------------------------------------------------------
|
||||
Inventory Valuation: Manual or Automated
|
||||
========================================
|
||||
|
||||
To start, go to :menuselection:`Accounting --> Reporting --> Balance Sheet`. At the top of the
|
||||
dashboard, change the :guilabel:`As of` field value to :guilabel:`Today`, and adjust the filtering
|
||||
:guilabel:`Options` to :guilabel:`Unfold All` in order to see all of the latest data displayed,
|
||||
all at once.
|
||||
There are two ways to record your inventory valuation in your accounting
|
||||
books. As the costing method, this is defined in your product category.
|
||||
Those two methods are detailed below.
|
||||
|
||||
Under the parent :guilabel:`Current Assets` line item, look for the nested :guilabel:`Stock
|
||||
Valuation Account` line item, where the total valuation of all of the inventory on hand is
|
||||
displayed.
|
||||
It is important to also note that the accounting entries will depend on
|
||||
your accounting mode: it can be continental or anglo-saxon. In
|
||||
continental accounting, the cost of a good is taken into account as soon
|
||||
as the product is received in stock. In anglo-saxon accounting, the cost
|
||||
of a good is only recorded as an expense when this good is invoiced to a
|
||||
final customer. In the tables below, you can easily compare those two
|
||||
accounting modes.
|
||||
|
||||
Access more specific information with the :guilabel:`Stock Valuation Account` drop-down menu, by
|
||||
selecting either the :guilabel:`General Ledger` to see an itemized view of all of the journal
|
||||
entries, or by selecting :guilabel:`Journal Items` to review all of the individualized journal
|
||||
entries that were submitted to the account. As well, annotations to the :guilabel:`Balance Sheet`
|
||||
can be added by choosing :guilabel:`Annotate`, filling in the text box, and clicking
|
||||
:guilabel:`Save`.
|
||||
Usually, based on your country, the correct accounting mode will be
|
||||
chosen by default. If you want to verify your accounting mode, activate
|
||||
the :ref:`developer mode <developer-mode>` and open your accounting
|
||||
settings.
|
||||
|
||||
.. image:: inventory_valuation_config/stock-valuation-breakdown-in-accounting.png
|
||||
:align: center
|
||||
:alt: See the full inventory valuation breakdown in Odoo Accounting app.
|
||||
Manual Inventory Valuation
|
||||
--------------------------
|
||||
|
||||
In this case, goods receipts and deliveries won’t have any direct impact
|
||||
on your accounting books. Periodically, you create a manual journal
|
||||
entry representing the value of what you have in stock. To know that
|
||||
value, go in :menuselection:`Inventory --> Reporting --> Inventory Valuation`.
|
||||
|
||||
This is the default configuration in Odoo and it works
|
||||
out-of-the-box. Check following operations and find out how
|
||||
Odoo is managing the accounting postings.
|
||||
|
||||
Continental Accounting
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
Vendor Bill
|
||||
.. rst-class:: values-table
|
||||
|
||||
============================= ===== ======
|
||||
\ Debit Credit
|
||||
============================= ===== ======
|
||||
Assets: Inventory 50
|
||||
Assets: Deferred Tax Assets 4.68
|
||||
Liabilities: Accounts Payable 54.68
|
||||
============================= ===== ======
|
||||
|
||||
Configuration:
|
||||
* Purchased Goods: defined on the product or on the internal category of related product (Expense Account field)
|
||||
* Deferred Tax Assets: defined on the tax used on the purchase order line
|
||||
* Accounts Payable: defined on the vendor related to the bill
|
||||
Goods Receptions
|
||||
No Journal Entry
|
||||
Customer Invoice
|
||||
.. rst-class:: values-table
|
||||
|
||||
===================================== ===== ======
|
||||
\ Debit Credit
|
||||
===================================== ===== ======
|
||||
Revenues: Sold Goods 100
|
||||
Liabilities: Deferred Tax Liabilities 9
|
||||
Assets: Accounts Receivable 109
|
||||
===================================== ===== ======
|
||||
|
||||
Configuration:
|
||||
* Revenues: defined on the product or on the internal category of related product (Income Account field)
|
||||
* Deferred Tax Liabilities: defined on the tax used on the invoice line
|
||||
* Accounts Receivable: defined on the customer (Receivable Account)
|
||||
|
||||
The fiscal position used on the invoice may have a rule that replaces the
|
||||
Income Account or the tax defined on the product by another one.
|
||||
Customer Shipping
|
||||
No Journal Entry
|
||||
Manufacturing Orders
|
||||
No Journal Entry
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<hr style="float: none; visibility: hidden; margin: 0;">
|
||||
|
||||
At the end of the month/year, your company does a physical inventory
|
||||
or just relies on the inventory in Odoo to value the stock into your books.
|
||||
|
||||
Create a journal entry to move the stock variation value from your
|
||||
Profit&Loss section to your assets.
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
.. rst-class:: values-table
|
||||
|
||||
===================================== ===== ======
|
||||
\ Debit Credit
|
||||
===================================== ===== ======
|
||||
Assets: Inventory X
|
||||
Expenses: Inventory Variations X
|
||||
===================================== ===== ======
|
||||
|
||||
If the stock value decreased, the **Inventory** account is credited
|
||||
and the **Inventory Variations** debited.
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<hr style="float: none; visibility: hidden; margin: 0;">
|
||||
|
||||
Anglo-Saxon Accounting
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
Vendor Bill
|
||||
.. rst-class:: values-table
|
||||
|
||||
============================= ===== ======
|
||||
\ Debit Credit
|
||||
============================= ===== ======
|
||||
Assets: Inventory 50
|
||||
Assets: Deferred Tax Assets 4.68
|
||||
Liabilities: Accounts Payable 54.68
|
||||
============================= ===== ======
|
||||
|
||||
Configuration:
|
||||
* Purchased Goods: defined on the product or on the internal category of related product
|
||||
(Expense Account field)
|
||||
* Deferred Tax Assets: defined on the tax used on the purchase order line
|
||||
* Accounts Payable: defined on the vendor related to the bill
|
||||
Goods Receptions
|
||||
No Journal Entry
|
||||
Customer Invoice
|
||||
.. rst-class:: values-table
|
||||
|
||||
===================================== ===== ======
|
||||
\ Debit Credit
|
||||
===================================== ===== ======
|
||||
Revenues: Sold Goods 100
|
||||
Liabilities: Deferred Tax Liabilities 9
|
||||
Assets: Accounts Receivable 109
|
||||
===================================== ===== ======
|
||||
|
||||
Configuration:
|
||||
* Revenues: defined on the product or on the internal category of related
|
||||
product (Income Account field)
|
||||
* Deferred Tax Liabilities: defined on the tax used on the invoice line
|
||||
* Accounts Receivable: defined on the customer (Receivable Account)
|
||||
|
||||
The fiscal position used on the invoice may have a rule that replaces the
|
||||
Income Account or the tax defined on the product by another one.
|
||||
Customer Shipping
|
||||
No Journal Entry
|
||||
Manufacturing Orders
|
||||
No Journal Entry
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<hr style="float: none; visibility: hidden; margin: 0;">
|
||||
|
||||
At the end of the month/year, your company does a physical inventory
|
||||
or just relies on the inventory in Odoo to value the stock into your books.
|
||||
|
||||
Then you need to break down the purchase balance into both the inventory and
|
||||
the cost of goods sold using the following formula:
|
||||
|
||||
Cost of goods sold (COGS) = Starting inventory value + Purchases – Closing inventory value
|
||||
|
||||
To update the stock valuation in your books, record such an entry:
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
.. rst-class:: values-table
|
||||
|
||||
===================================== ===== ======
|
||||
\ Debit Credit
|
||||
===================================== ===== ======
|
||||
Assets: Inventory (closing value) X
|
||||
Expenses: Cost of Good Sold X
|
||||
Expenses: Purchased Goods X
|
||||
Assets: Inventory (starting value) X
|
||||
===================================== ===== ======
|
||||
|
||||
Automated Inventory Valuation
|
||||
-----------------------------
|
||||
|
||||
In that case, when a product enters or leaves your stock, an accounting
|
||||
entry will be automatically created. This means your accounting books
|
||||
are always up-to-date. This mode is dedicated to expert accountants and
|
||||
advanced users only. As opposed to periodic valuation, it requires some
|
||||
extra configuration & testing.
|
||||
|
||||
First, you need to define the accounts that will be used for those
|
||||
accounting entries. This is done on the product category.
|
||||
|
||||
Continental Accounting
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. h:div:: valuation-chart-continental doc-aside
|
||||
|
||||
.. placeholder
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<hr style="float: none; visibility: hidden; margin: 0;">
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
**Configuration:**
|
||||
|
||||
- Accounts Receivable/Payable: defined on the partner (Accounting tab)
|
||||
|
||||
- Deferred Tax Assets/Liabilities: defined on the tax used on the invoice line
|
||||
|
||||
- Revenues/Expenses: defined by default on product's internal category; can be
|
||||
also set in product form (Accounting tab) as a replacement value.
|
||||
|
||||
- Inventory Variations: to set as Stock Input/Output Account in product's internal
|
||||
category
|
||||
|
||||
- Inventory: to set as Stock Valuation Account in product's internal category
|
||||
|
||||
Anglo-Saxon Accounting
|
||||
~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. h:div:: valuation-chart-anglo-saxon doc-aside
|
||||
|
||||
.. placeholder
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<hr style="float: none; visibility: hidden; margin: 0;">
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
**Configuration:**
|
||||
|
||||
- Accounts Receivable/Payable: defined on the partner (Accounting tab)
|
||||
|
||||
- Deferred Tax Assets/Liabilities: defined on the tax used on the
|
||||
invoice line
|
||||
|
||||
- Revenues: defined on the product category as a default, or specifically
|
||||
to a specific product.
|
||||
|
||||
- Expenses: this is where you should set the "Cost of Goods Sold" account.
|
||||
Defined on the product category as a default value, or specifically on
|
||||
the product form.
|
||||
|
||||
- Goods Received Not Purchased: to set as Stock Input Account in product's
|
||||
internal category
|
||||
|
||||
- Goods Issued Not Invoiced: to set as Stock Output Account in product's
|
||||
internal category
|
||||
|
||||
- Inventory: to set as Stock Valuation Account in product's internal category
|
||||
|
||||
- Price Difference: to set in product's internal category or in product
|
||||
form as a specific replacement value
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 29 KiB |
|
|
@@ -21,3 +21,4 @@ deliver and invoice what has been sold.
|
|||
sales/products_prices
|
||||
sales/amazon_connector
|
||||
sales/ebay_connector
|
||||
sales/advanced
|
||||
|
|
|
|||
10
content/applications/sales/sales/advanced.rst
Normal file
|
|
@@ -0,0 +1,10 @@
|
|||
:nosearch:
|
||||
|
||||
===============
|
||||
Advanced Topics
|
||||
===============
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
advanced/portal
|
||||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 40 KiB |
|
|
@@ -33,7 +33,7 @@ Installation
|
|||
./odoo-bin --geoip-db= ~/Downloads/GeoLite2-City.mmdb
|
||||
|
||||
.. seealso::
|
||||
- :doc:`CLI documentation </developer/reference/cli>`.
|
||||
- :doc:`CLI documentation </developer/cli>`.
|
||||
|
||||
.. warning::
|
||||
``GeoIP`` Python library can also be used. However this version is discontinued since January
|
||||
|
|
|
|||
|
|
@@ -1022,7 +1022,7 @@ Document metadata
|
|||
| `code-column` | | Show a dynamic side column that can be used to display interactive |
|
||||
| | tutorials or code excerpts. |
|
||||
| | | For example, see |
|
||||
| | :doc:`/applications/finance/accounting/getting_started/cheat_sheet`. |
|
||||
| | :doc:`/applications/finance/accounting/getting_started/memento`. |
|
||||
+-----------------+--------------------------------------------------------------------------------+
|
||||
| `hide-page-toc` | Hide the "On this page" sidebar and use full page width for the content. |
|
||||
+-----------------+--------------------------------------------------------------------------------+
|
||||
|
|
|
|||
|
|
@@ -14,6 +14,8 @@ Learn through tutorials and get help using reference guides.
|
|||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
developer/tutorials
|
||||
developer/howtos
|
||||
developer/reference
|
||||
developer/api
|
||||
developer/cli
|
||||
developer/iot
|
||||
|
|
|
|||
12
content/developer/api.rst
Normal file
|
|
@@ -0,0 +1,12 @@
|
|||
:nosearch:
|
||||
|
||||
===
|
||||
API
|
||||
===
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
api/external_api
|
||||
api/iap
|
||||
api/extract_api
|
||||
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
|
@@ -1,6 +1,9 @@
|
|||
=======================
|
||||
Provide an IAP services
|
||||
=======================
|
||||
|
||||
.. _api/iap:
|
||||
|
||||
===============
|
||||
In-App Purchase
|
||||
===============
|
||||
|
||||
In-App Purchase (IAP) allows providers of ongoing services through Odoo apps to
|
||||
be compensated for ongoing service use rather than — and possibly instead of
|
||||
|
|
@@ -22,7 +25,7 @@ App Developer:
|
|||
Overview
|
||||
========
|
||||
|
||||
.. figure:: provide_iap_service/players.png
|
||||
.. figure:: iap/players.png
|
||||
:align: center
|
||||
|
||||
The Players
|
||||
|
|
@@ -37,7 +40,7 @@ Overview
|
|||
bridge/translator between an Odoo system and the actual service.
|
||||
|
||||
|
||||
.. figure:: provide_iap_service/credits.jpg
|
||||
.. figure:: iap/credits.jpg
|
||||
:align: center
|
||||
|
||||
The Credits
|
||||
|
|
@@ -64,7 +67,7 @@ Overview
|
|||
.. note:: In the following explanations we will ignore the External Service,
|
||||
they are just a detail of the service you provide.
|
||||
|
||||
.. figure:: provide_iap_service/normal.png
|
||||
.. figure:: iap/normal.png
|
||||
:align: center
|
||||
|
||||
'Normal' service flow
|
||||
|
|
@@ -84,7 +87,7 @@ Overview
|
|||
been rendered, possibly (depending on the service) displaying or
|
||||
storing its results in the client's system.
|
||||
|
||||
.. figure:: provide_iap_service/no-credit.png
|
||||
.. figure:: iap/no-credit.png
|
||||
:align: center
|
||||
|
||||
Insufficient credits
|
||||
|
|
@@ -171,16 +174,16 @@ The service has *seven* important fields:
|
|||
how you **use it, its relevance** to make your service work and inform the
|
||||
client on how they can **access, update or delete their personal information**.
|
||||
|
||||
.. image:: provide_iap_service/menu.png
|
||||
.. image:: iap/menu.png
|
||||
:align: center
|
||||
|
||||
.. image:: provide_iap_service/service_list.png
|
||||
.. image:: iap/service_list.png
|
||||
:align: center
|
||||
|
||||
.. image:: provide_iap_service/creating_service.png
|
||||
.. image:: iap/creating_service.png
|
||||
:align: center
|
||||
|
||||
.. image:: provide_iap_service/service_created.png
|
||||
.. image:: iap/service_created.png
|
||||
:align: center
|
||||
|
||||
You can then create *credit packs* which clients can purchase in order to
|
||||
|
|
@@ -211,7 +214,7 @@ A credit pack is essentially a product with five characteristics:
|
|||
pack to another.
|
||||
|
||||
|
||||
.. image:: provide_iap_service/package.png
|
||||
.. image:: iap/package.png
|
||||
:align: center
|
||||
|
||||
.. _iap-odoo-app:
|
||||
|
|
@@ -280,7 +283,7 @@ local value via your application and additional parts via a remote service.
|
|||
</record>
|
||||
</odoo>
|
||||
|
||||
.. image:: provide_iap_service/button.png
|
||||
.. image:: iap/button.png
|
||||
:align: center
|
||||
|
||||
We can now implement the action method/callback. This will *call our own
|
||||
|
|
@@ -509,7 +512,7 @@ parameters we can use to make things clearer to the end-user.
|
|||
JSON-RPC2_ Transaction API
|
||||
==========================
|
||||
|
||||
.. image:: provide_iap_service/flow.png
|
||||
.. image:: iap/flow.png
|
||||
:align: center
|
||||
|
||||
* The IAP transaction API does not require using Odoo when implementing your
|
||||
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 132 KiB After Width: | Height: | Size: 132 KiB |
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 6.3 KiB After Width: | Height: | Size: 6.3 KiB |
|
Before Width: | Height: | Size: 30 KiB After Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 59 KiB After Width: | Height: | Size: 59 KiB |
|
Before Width: | Height: | Size: 35 KiB After Width: | Height: | Size: 35 KiB |
|
|
@@ -1,23 +1,56 @@
|
|||
:show-content:
|
||||
:hide-page-toc:
|
||||
|
||||
=============
|
||||
How-to guides
|
||||
=============
|
||||
=========
|
||||
Tutorials
|
||||
=========
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
howtos/rdtraining
|
||||
howtos/website
|
||||
howtos/backend
|
||||
howtos/profilecode
|
||||
howtos/company
|
||||
howtos/localization
|
||||
howtos/translations
|
||||
howtos/provide_iap_services
|
||||
howtos/connect_device
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<!-- 12 col on small screen, 6 on md, 3 on xl, 3 on xxl -->
|
||||
<div class="row row-cols-1 row-cols-md-2 row-cols-xl-3 row-cols-xxl-4 g-4 mb-4">
|
||||
<!-- Big card with badge rounded-pill -->
|
||||
<a class="o_toctree_card col-md-12 col-xl-8 col-xxl-6" href="howtos/rdtraining.html">
|
||||
<div class="card h-100">
|
||||
<div class="card-body pb-0">
|
||||
<h4 class="card-title text-primary mb-1">Getting started</h4>
|
||||
<p class="card-text text-dark fw-normal">
|
||||
Learn how to develop your own module with the Odoo framework. This
|
||||
step-by-step tutorial is crafted for newcomers and any other individual
|
||||
curious about Odoo development.
|
||||
</p>
|
||||
</div>
|
||||
<div class="card-footer border-0">
|
||||
<span class="badge rounded-pill bg-dark mt-auto mb-2">Beginner</span>
|
||||
</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<!-- Small card with badge rounded-pill -->
|
||||
<a class="o_toctree_card col" href="howtos/website.html">
|
||||
<div class="card h-100">
|
||||
<div class="card-body pb-0">
|
||||
<h4 class="card-title text-primary mb-1">Building a website</h4>
|
||||
<p class="card-text text-dark fw-normal">
|
||||
Build your first website modules with Odoo.
|
||||
</p>
|
||||
</div>
|
||||
<div class="card-footer border-0">
|
||||
<span class="badge rounded-pill bg-dark mt-auto mb-2">Beginner</span>
|
||||
</div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a class="o_toctree_card col" href="howtos/profilecode.html">
|
||||
<div class="card h-100 pb-0">
|
||||
|
|
@@ -69,28 +102,4 @@ How-to guides
|
|||
</div>
|
||||
</a>
|
||||
|
||||
<a class="o_toctree_card col" href="howtos/provide_iap_services.html">
|
||||
<div class="card h-100 pb-0">
|
||||
<div class="card-body">
|
||||
<h4 class="card-title text-primary mb-1">Provide IAP services</h4>
|
||||
<p class="card-text text-dark fw-normal">
|
||||
Learn how to provide ongoing services with Odoo's In-App Purchase (IAP).
|
||||
</p>
|
||||
</div>
|
||||
<div class="card-footer border-0"></div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
<a class="o_toctree_card col" href="howtos/connect_device.html">
|
||||
<div class="card h-100 pb-0">
|
||||
<div class="card-body">
|
||||
<h4 class="card-title text-primary mb-1">Connect with a device</h4>
|
||||
<p class="card-text text-dark fw-normal">
|
||||
Learn how to enable a module to detect and communicate with an IoT device.
|
||||
</p>
|
||||
</div>
|
||||
<div class="card-footer border-0"></div>
|
||||
</div>
|
||||
</a>
|
||||
|
||||
</div>
|
||||
|
|
|
|||
|
|
@@ -1,4 +1,3 @@
|
|||
:orphan:
|
||||
|
||||
.. _howto/base:
|
||||
.. _howto/module:
|
||||
|
|
@@ -7,9 +6,6 @@
|
|||
Building a Module
|
||||
=================
|
||||
|
||||
.. danger::
|
||||
This tutorial is outdated. We recommend reading :doc:`getting_started` instead.
|
||||
|
||||
.. warning::
|
||||
This tutorial requires :ref:`having installed Odoo <setup/install>`
|
||||
|
||||
|
|
@@ -4,7 +4,7 @@ Accounting Localization
|
|||
|
||||
.. warning::
|
||||
This tutorial requires knowledges about how to build a module in Odoo (see
|
||||
:doc:`../tutorials/getting_started`).
|
||||
:doc:`/developer/howtos/backend`).
|
||||
|
||||
Building a localization module
|
||||
==============================
|
||||
|
|
|
|||
|
|
@@ -5,7 +5,7 @@ Profiling Odoo code
|
|||
.. warning::
|
||||
|
||||
This tutorial requires :ref:`having installed Odoo <setup/install>`
|
||||
and :doc:`writing Odoo code <../tutorials/getting_started>`
|
||||
and :doc:`writing Odoo code <backend>`
|
||||
|
||||
Graph a method
|
||||
==============
|
||||
|
|
|
|||
83
content/developer/howtos/rdtraining.rst
Normal file
|
|
@@ -0,0 +1,83 @@
|
|||
:show-content:
|
||||
|
||||
.. _howto/rdtraining:
|
||||
|
||||
===============
|
||||
Getting started
|
||||
===============
|
||||
|
||||
Welcome to the Getting Started Odoo tutorial! If you reached this page that means you are
|
||||
interested in the development of your own Odoo module. It might also mean that you recently
|
||||
joined the Odoo company for a rather technical position. In any case, your journey to the
|
||||
technical side of Odoo starts here.
|
||||
|
||||
This training is split in two parts:
|
||||
|
||||
- The first part is the :ref:`core training <howtos/rdtraining/core_training>`. Its objective is to
|
||||
give you an insight of the most important parts of the Odoo development framework. The chapters
|
||||
should be followed in their given order since they cover the development of a new Odoo application
|
||||
from scratch in an incremental way. In other words, each chapter depends on the previous one.
|
||||
- The second part covers a set of :ref:`advanced topics <howtos/rdtraining/advanced_topics>`. Each
|
||||
topic can be followed independently, but requires the :ref:`core training
|
||||
<howtos/rdtraining/core_training>`.
|
||||
|
||||
.. attention::
|
||||
Are you following this training as part of your technical onboarding as an Odoo employee? Then,
|
||||
we ask you to complete the first part of the training before joining your new team and the second
|
||||
part the month after.
|
||||
|
||||
All topics are built around a business case we will enhance along the way. The reader is expected
|
||||
to actively take part in the training by writing the solution for each exercise.
|
||||
|
||||
Ready? Let's get started!
|
||||
|
||||
.. _howtos/rdtraining/core_training:
|
||||
|
||||
Core training
|
||||
=============
|
||||
|
||||
.. toctree::
|
||||
:caption: Advanced Topics
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
rdtraining/0*
|
||||
rdtraining/1*
|
||||
|
||||
* :doc:`rdtraining/01_architecture`
|
||||
* :doc:`rdtraining/02_setup`
|
||||
* :doc:`rdtraining/03_newapp`
|
||||
* :doc:`rdtraining/04_basicmodel`
|
||||
* :doc:`rdtraining/05_securityintro`
|
||||
* :doc:`rdtraining/06_firstui`
|
||||
* :doc:`rdtraining/07_basicviews`
|
||||
* :doc:`rdtraining/08_relations`
|
||||
* :doc:`rdtraining/09_compute_onchange`
|
||||
* :doc:`rdtraining/10_actions`
|
||||
* :doc:`rdtraining/11_constraints`
|
||||
* :doc:`rdtraining/12_sprinkles`
|
||||
* :doc:`rdtraining/13_inheritance`
|
||||
* :doc:`rdtraining/14_other_module`
|
||||
* :doc:`rdtraining/15_qwebintro`
|
||||
* :doc:`rdtraining/16_guidelines_pr`
|
||||
|
||||
.. _howtos/rdtraining/advanced_topics:
|
||||
|
||||
Advanced topics
|
||||
===============
|
||||
|
||||
.. toctree::
|
||||
:caption: Advanced Topics
|
||||
:titlesonly:
|
||||
|
||||
rdtraining/B_acl_irrules
|
||||
rdtraining/C_data
|
||||
rdtraining/E_unittest
|
||||
rdtraining/J_reports
|
||||
rdtraining/K_dashboard
|
||||
|
||||
* :doc:`rdtraining/B_acl_irrules`
|
||||
* :doc:`rdtraining/C_data`
|
||||
* :doc:`rdtraining/E_unittest`
|
||||
* :doc:`rdtraining/J_reports`
|
||||
* :doc:`rdtraining/K_dashboard`
|
||||
|
|
@@ -1,4 +1,4 @@
|
|||
.. _tutorials/getting_started/01_architecture:
|
||||
.. _howto/rdtraining/01_architecture:
|
||||
|
||||
================================
|
||||
Chapter 1: Architecture Overview
|
||||
|
|
@@ -78,6 +78,8 @@ Static web data
|
|||
None of these elements are mandatory. Some modules may only add data files (e.g. country-specific
|
||||
accounting configuration), while others may only add business objects. During this training, we will
|
||||
create business objects, object views and data files.
|
||||
:ref:`Web controllers <howto/rdtraining/G_website>` and
|
||||
:ref:`static web data <howto/rdtraining/I_jswidget>` are advanced topics.
|
||||
|
||||
Module structure
|
||||
----------------
|
||||
|
Before Width: | Height: | Size: 85 KiB After Width: | Height: | Size: 85 KiB |
|
|
@@ -100,7 +100,7 @@ Then, clone the two repositories with SSH as explained in the :ref:`Installing O
|
|||
.. tip::
|
||||
Cloning the repositories will take a while, enjoy a cup of coffee while you wait.
|
||||
|
||||
.. _tutorials/getting_started/02_setup/development_repository:
|
||||
.. _howto/rdtraining/02_setup/development_repository:
|
||||
|
||||
Configure the Git repositories
|
||||
==============================
|
||||
|
|
@@ -134,9 +134,9 @@ needed.
|
|||
Install the dependencies
|
||||
========================
|
||||
|
||||
As seen in :ref:`tutorials/getting_started/01_architecture`, Odoo's server runs on Python and uses
|
||||
PostgreSQL as an RDBMS. In the context of a development machine, the easiest approach is to install
|
||||
everything locally. To do so, follow once again the :ref:`Installing Odoo guide
|
||||
As seen in :ref:`howto/rdtraining/01_architecture`, Odoo's server runs on Python and uses PostgreSQL
|
||||
as an RDBMS. In the context of a development machine, the easiest approach is to install everything
|
||||
locally. To do so, follow once again the :ref:`Installing Odoo guide
|
||||
<setup/install/source/linux/prepare>`.
|
||||
|
||||
.. tip::
|
||||
|
|
@@ -378,4 +378,4 @@ Here is a list of commands:
|
|||
Quit the debugger. The program being executed is aborted.
|
||||
|
||||
Now that your server is running, it's time to start :ref:`writing your own application
|
||||
<tutorials/getting_started/03_newapp>`!
|
||||
<howto/rdtraining/03_newapp>`!
|
||||
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 15 KiB After Width: | Height: | Size: 15 KiB |
|
|
@@ -1,4 +1,4 @@
|
|||
.. _tutorials/getting_started/03_newapp:
|
||||
.. _howto/rdtraining/03_newapp:
|
||||
|
||||
============================
|
||||
Chapter 3: A New Application
|
||||
|
|
@@ -105,5 +105,4 @@ Did it not appear? Maybe try removing the default 'Apps' filter ;-)
|
|||
|
||||
You can even install the module! But obviously it's an empty shell, so no menu will appear.
|
||||
|
||||
All good? If yes, then let's :ref:`create our first model
|
||||
<tutorials/getting_started/04_basicmodel>`!
|
||||
All good? If yes, then let's :ref:`create our first model <howto/rdtraining/04_basicmodel>`!
|
||||
|
Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 24 KiB |
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 27 KiB After Width: | Height: | Size: 27 KiB |
|
|
@@ -1,14 +1,14 @@
|
|||
.. _tutorials/getting_started/04_basicmodel:
|
||||
.. _howto/rdtraining/04_basicmodel:
|
||||
|
||||
==================================
|
||||
Chapter 4: Models And Basic Fields
|
||||
==================================
|
||||
|
||||
At the end of the :ref:`previous chapter <tutorials/getting_started/03_newapp>`, we were able to
|
||||
create an Odoo module. However, at this point it is still an empty shell which doesn't allow us to
|
||||
store any data. In our real estate module, we want to store the information related to the
|
||||
properties (name, description, price, living area...) in a database. The Odoo framework provides
|
||||
tools to facilitate database interactions.
|
||||
At the end of the :ref:`previous chapter <howto/rdtraining/03_newapp>`, we were able to create an Odoo
|
||||
module. However, at this point it is still an empty shell which doesn't allow us to store any data.
|
||||
In our real estate module, we want to store the information related to the properties
|
||||
(name, description, price, living area...) in a database. The Odoo framework provides tools to
|
||||
facilitate database interactions.
|
||||
|
||||
Before moving forward in the exercise, make sure the ``estate`` module is installed, i.e. it
|
||||
must appear as 'Installed' in the Apps list.
|
||||
|
|
@@ -282,7 +282,7 @@ useful or necessary:
|
|||
|
||||
|
||||
Now that we have created our first model, let's
|
||||
:ref:`add some security <tutorials/getting_started/05_securityintro>`!
|
||||
:ref:`add some security <howto/rdtraining/05_securityintro>`!
|
||||
|
||||
|
||||
.. [#autofields] it is possible to :ref:`disable the automatic creation of some
|
||||
|
|
@@ -1,16 +1,16 @@
|
|||
.. _tutorials/getting_started/05_securityintro:
|
||||
.. _howto/rdtraining/05_securityintro:
|
||||
|
||||
==========================================
|
||||
Chapter 5: Security - A Brief Introduction
|
||||
==========================================
|
||||
|
||||
In the :ref:`previous chapter <tutorials/getting_started/04_basicmodel>`, we created our first table
|
||||
intended to store business data. In a business application such as Odoo, one of the first questions
|
||||
to consider is who\ [#who]_ can access the data. Odoo provides a security mechanism to allow access
|
||||
In the :ref:`previous chapter <howto/rdtraining/04_basicmodel>`, we created our first table intended
|
||||
to store business data. In a business application such as Odoo, one of the first questions to consider
|
||||
is who\ [#who]_ can access the data. Odoo provides a security mechanism to allow access
|
||||
to the data for specific groups of users.
|
||||
|
||||
The topic of security is covered in more detail in :doc:`../restrict_data_access`. This chapter aims
|
||||
to cover the minimum required for our new module.
|
||||
The topic of security is covered in more detail in :ref:`howto/rdtraining/B_acl_irrules`. This chapter
|
||||
aims to cover the minimum required for our new module.
|
||||
|
||||
Data Files (CSV)
|
||||
================
|
||||
|
|
@@ -104,7 +104,8 @@ Here is an example for our previous ``test.model``:
|
|||
- ``model_id/id`` refers to the model which the access right applies to. The standard way to refer
|
||||
to the model is ``model_<model_name>``, where ``<model_name>`` is the ``_name`` of the model
|
||||
with the ``.`` replaced by ``_``. Seems cumbersome? Indeed it is...
|
||||
- ``group_id/id`` refers to the group which the access right applies to.
|
||||
- ``group_id/id`` refers to the group which the access right applies to. We will cover the concept
|
||||
of groups in the :ref:`advanced topic <howto/rdtraining/N_security>` dedicated to the security.
|
||||
- ``perm_read,perm_write,perm_create,perm_unlink``: read, write, create and unlink permissions
|
||||
|
||||
.. exercise:: Add access rights.
|
||||
|
|
@@ -118,7 +119,7 @@ Here is an example for our previous ``test.model``:
|
|||
|
||||
Restart the server and the warning message should have disappeared!
|
||||
|
||||
It's now time to finally :ref:`interact with the UI <tutorials/getting_started/06_firstui>`!
|
||||
It's now time to finally :ref:`interact with the UI <howto/rdtraining/06_firstui>`!
|
||||
|
||||
.. [#who] meaning which Odoo user (or group of users)
|
||||
|
||||
|
|
@@ -1,12 +1,12 @@
|
|||
.. _tutorials/getting_started/06_firstui:
|
||||
.. _howto/rdtraining/06_firstui:
|
||||
|
||||
========================================
|
||||
Chapter 6: Finally, Some UI To Play With
|
||||
========================================
|
||||
|
||||
Now that we've created our new :ref:`model <tutorials/getting_started/04_basicmodel>` and its
|
||||
corresponding :ref:`access rights <tutorials/getting_started/05_securityintro>`, it is time to
|
||||
interact with the user interface.
|
||||
Now that we've created our new :ref:`model <howto/rdtraining/04_basicmodel>` and its corresponding
|
||||
:ref:`access rights <howto/rdtraining/05_securityintro>`, it is time to interact with
|
||||
the user interface.
|
||||
|
||||
At the end of this chapter, we will have created a couple of menus in order to access a default list
|
||||
and form view.
|
||||
|
|
@@ -17,7 +17,7 @@ Data Files (XML)
|
|||
**Reference**: the documentation related to this topic can be found in
|
||||
:ref:`reference/data`.
|
||||
|
||||
In :ref:`tutorials/getting_started/05_securityintro`, we added data through a CSV file. The CSV
|
||||
In :ref:`howto/rdtraining/05_securityintro`, we added data through a CSV file. The CSV
|
||||
format is convenient when the data to load has a simple format. When the format is more complex
|
||||
(e.g. load the structure of a view or an email template), we use the XML format. For example,
|
||||
this
|
||||
|
|
@@ -65,10 +65,10 @@ Actions can be triggered in three ways:
|
|||
3. as contextual actions on object
|
||||
|
||||
We will only cover the first case in this chapter. The second case will be covered in a
|
||||
:ref:`later chapter <tutorials/getting_started/10_actions>` while the last is the focus of an
|
||||
advanced topic. In our Real Estate example, we would like to link a menu to the ``estate.property``
|
||||
model, so we are able to create a new record. The action can be viewed as the link between the menu
|
||||
and the model.
|
||||
:ref:`later chapter <howto/rdtraining/10_actions>` while the last is the focus of an advanced topic.
|
||||
In our Real Estate example, we would like to link a menu to the ``estate.property`` model, so we
|
||||
are able to create a new record. The action can be viewed as the link between the menu and
|
||||
the model.
|
||||
|
||||
A basic action for our ``test.model`` is:
|
||||
|
||||
|
|
@@ -86,7 +86,7 @@ A basic action for our ``test.model`` is:
|
|||
- ``name`` is the name of the action.
|
||||
- ``res_model`` is the model which the action applies to.
|
||||
- ``view_mode`` are the views that will be available; in this case they are the list (tree) and form views.
|
||||
We'll see :ref:`later <tutorials/getting_started/15_qwebintro>` that there can be other view modes.
|
||||
We'll see :ref:`later <howto/rdtraining/15_qwebintro>` that there can be other view modes.
|
||||
|
||||
Examples can be found everywhere in Odoo, but
|
||||
`this <https://github.com/odoo/odoo/blob/09c59012bf80d2ccbafe21c39e604d6cfda72924/addons/crm/views/crm_lost_reason_views.xml#L57-L70>`__
|
||||
|
|
@@ -287,7 +287,7 @@ Note that the default ``active=False`` value was assigned to all existing record
|
|||
The ``state`` will be used later on for several UI enhancements.
|
||||
|
||||
Now that we are able to interact with the UI thanks to the default views, the next step is
|
||||
obvious: we want to define :ref:`our own views <tutorials/getting_started/07_basicviews>`.
|
||||
obvious: we want to define :ref:`our own views <howto/rdtraining/07_basicviews>`.
|
||||
|
||||
.. [#refresh] A refresh is needed since the web client keeps a cache of the various menus
|
||||
and views for performance reasons.
|
||||
|
Before Width: | Height: | Size: 239 KiB After Width: | Height: | Size: 239 KiB |
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 143 KiB After Width: | Height: | Size: 143 KiB |
|
Before Width: | Height: | Size: 62 KiB After Width: | Height: | Size: 62 KiB |
|
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 29 KiB |
|
|
@@ -1,11 +1,11 @@
|
|||
.. _tutorials/getting_started/07_basicviews:
|
||||
.. _howto/rdtraining/07_basicviews:
|
||||
|
||||
======================
|
||||
Chapter 7: Basic Views
|
||||
======================
|
||||
|
||||
We have seen in the :ref:`previous chapter <tutorials/getting_started/06_firstui>` that Odoo is able
|
||||
to generate default views for a given model. In practice, the default view is **never** acceptable
|
||||
We have seen in the :ref:`previous chapter <howto/rdtraining/06_firstui>` that Odoo is able to
|
||||
generate default views for a given model. In practice, the default view is **never** acceptable
|
||||
for a business application. Instead, we should at least organize the various fields in a logical
|
||||
manner.
|
||||
|
||||
|
|
@@ -228,4 +228,4 @@ services *OR* have a unit price which is *NOT* between 1000 and 2000'::
|
|||
|
||||
Looking good? At this point we are already able to create models and design a user interface which
|
||||
makes sense business-wise. However, a key component is still missing: the
|
||||
:ref:`link between models <tutorials/getting_started/08_relations>`.
|
||||
:ref:`link between models <howto/rdtraining/08_relations>`.
|
||||
|
Before Width: | Height: | Size: 26 KiB After Width: | Height: | Size: 26 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 9.3 KiB After Width: | Height: | Size: 9.3 KiB |
|
Before Width: | Height: | Size: 9.6 KiB After Width: | Height: | Size: 9.6 KiB |
|
|
@@ -1,11 +1,11 @@
|
|||
.. _tutorials/getting_started/08_relations:
|
||||
.. _howto/rdtraining/08_relations:
|
||||
|
||||
===================================
|
||||
Chapter 8: Relations Between Models
|
||||
===================================
|
||||
|
||||
The :ref:`previous chapter <tutorials/getting_started/07_basicviews>` covered the creation of custom
|
||||
views for a model containing basic fields. However, in any real business scenario we need more than
|
||||
The :ref:`previous chapter <howto/rdtraining/07_basicviews>` covered the creation of custom views
|
||||
for a model containing basic fields. However, in any real business scenario we need more than
|
||||
one model. Moreover, links between models are necessary. One can easily imagine one model containing
|
||||
the customers and another one containing the list of users. You might need to refer to a customer
|
||||
or a user on any existing business model.
|
||||
|
|
@@ -78,10 +78,10 @@ In practice a many2one can be seen as a dropdown list in a form view.
|
|||
and search views
|
||||
|
||||
This exercise is a good recap of the previous chapters: you need to create a
|
||||
:ref:`model <tutorials/getting_started/04_basicmodel>`, set the
|
||||
:ref:`model <tutorials/getting_started/05_securityintro>`, add an
|
||||
:ref:`action and a menu <tutorials/getting_started/06_firstui>`, and
|
||||
:ref:`create a view <tutorials/getting_started/07_basicviews>`.
|
||||
:ref:`model <howto/rdtraining/04_basicmodel>`, set the
|
||||
:ref:`model <howto/rdtraining/05_securityintro>`, add an
|
||||
:ref:`action and a menu <howto/rdtraining/06_firstui>`, and
|
||||
:ref:`create a view <howto/rdtraining/07_basicviews>`.
|
||||
|
||||
Tip: do not forget to import any new Python files in ``__init__.py``, add new data files in
|
||||
``__manifest.py__`` or add the access rights ;-)
|
||||
|
|
@@ -185,7 +185,7 @@ operations like ``recs1 | recs2``.
|
|||
|
||||
Tip: in the view, use the ``widget="many2many_tags"`` attribute as demonstrated
|
||||
`here <https://github.com/odoo/odoo/blob/5bb8b927524d062be32f92eb326ef64091301de1/addons/crm_iap_lead_website/views/crm_reveal_views.xml#L36>`__.
|
||||
The ``widget`` attribute will be explained in detail in :ref:`a later chapter of the training <tutorials/getting_started/12_sprinkles>`.
|
||||
The ``widget`` attribute will be explained in detail in :ref:`a later chapter of the training <howto/rdtraining/12_sprinkles>`.
|
||||
For now, you can try to adding and removing it and see the result ;-)
|
||||
|
||||
One2many
|
||||
|
|
@@ -263,4 +263,4 @@ for convenience.
|
|||
|
||||
Still alive? This chapter is definitely not the easiest one. It introduced a couple of new concepts
|
||||
while relying on everything that was introduced before. The
|
||||
:ref:`next chapter <tutorials/getting_started/09_compute_onchange>` will be lighter, don't worry ;-)
|
||||
:ref:`next chapter <howto/rdtraining/09_compute_onchange>` will be lighter, don't worry ;-)
|
||||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
|
@@ -1,13 +1,14 @@
|
|||
.. _tutorials/getting_started/09_compute_onchange:
|
||||
.. _howto/rdtraining/09_compute_onchange:
|
||||
|
||||
========================================
|
||||
Chapter 9: Computed Fields And Onchanges
|
||||
========================================
|
||||
|
||||
The :ref:`relations between models <tutorials/getting_started/08_relations>` are a key component of
|
||||
any Odoo module. They are necessary for the modelization of any business case. However, we may want
|
||||
links between the fields within a given model. Sometimes the value of one field is determined from
|
||||
the values of other fields and other times we want to help the user with data entry.
|
||||
The :ref:`relations between models <howto/rdtraining/08_relations>` are a key component of any Odoo
|
||||
module. They are necessary for the modelization of any business case.
|
||||
However, we may want links between the fields within a given model. Sometimes the
|
||||
value of one field is determined from the values of other fields and other times we want to help the
|
||||
user with data entry.
|
||||
|
||||
These cases are supported by the concepts of computed fields and onchanges. Although this chapter is
|
||||
not technically complex, the semantics of both concepts is very important.
|
||||
|
|
@@ -52,8 +53,7 @@ method should set the value of the computed field for every record in
|
|||
|
||||
By convention, :attr:`~odoo.fields.Field.compute` methods are private, meaning that they cannot
|
||||
be called from the presentation tier, only from the business tier (see
|
||||
:ref:`tutorials/getting_started/01_architecture`). Private methods have a name starting with an
|
||||
underscore ``_``.
|
||||
:ref:`howto/rdtraining/01_architecture`). Private methods have a name starting with an underscore ``_``.
|
||||
|
||||
Dependencies
|
||||
------------
|
||||
|
|
@@ -301,5 +301,5 @@ When using stored computed fields, pay close attention to the dependencies. When
|
|||
depend on other computed fields, changing a value can trigger a large number of recomputations.
|
||||
This leads to poor performance.
|
||||
|
||||
In the :ref:`next chapter <tutorials/getting_started/10_actions>`, we'll see how we can trigger some
|
||||
business logic when buttons are clicked.
|
||||
In the :ref:`next chapter<howto/rdtraining/10_actions>`, we'll see how we can trigger some business
|
||||
logic when buttons are clicked.
|
||||
|
Before Width: | Height: | Size: 254 KiB After Width: | Height: | Size: 254 KiB |
|
Before Width: | Height: | Size: 229 KiB After Width: | Height: | Size: 229 KiB |
|
Before Width: | Height: | Size: 46 KiB After Width: | Height: | Size: 46 KiB |
|
|
@@ -1,13 +1,13 @@
|
|||
.. _tutorials/getting_started/10_actions:
|
||||
.. _howto/rdtraining/10_actions:
|
||||
|
||||
==================================
|
||||
Chapter 10: Ready For Some Action?
|
||||
==================================
|
||||
|
||||
So far we have mostly built our module by declaring fields and views. We just introduced business
|
||||
logic in the :ref:`previous chapter <tutorials/getting_started/09_compute_onchange>` thanks to
|
||||
computed fields and onchanges. In any real business scenario, we would want to link some business
|
||||
logic to action buttons. In our real estate example, we would like to be able to:
|
||||
logic in the :ref:`previous chapter <howto/rdtraining/09_compute_onchange>` thanks to computed fields
|
||||
and onchanges. In any real business scenario, we would want to link some business logic to action buttons.
|
||||
In our real estate example, we would like to be able to:
|
||||
|
||||
- cancel or set a property as sold
|
||||
- accept or refuse an offer
|
||||
|
|
@@ -125,9 +125,9 @@ and its
|
|||
Object Type
|
||||
===========
|
||||
|
||||
In :ref:`tutorials/getting_started/06_firstui`, we created an action that was linked to a menu. You
|
||||
may be wondering if it is possible to link an action to a button. Good news, it is! One way to do it
|
||||
is:
|
||||
In :ref:`howto/rdtraining/06_firstui`, we created an action that was linked to a menu.
|
||||
You may be wondering if it is possible to link an action to a button. Good news, it is! One
|
||||
way to do it is:
|
||||
|
||||
.. code-block:: xml
|
||||
|
||||
|
|
@@ -135,5 +135,5 @@ is:
|
|||
|
||||
We use ``type="action"`` and we refer to the :term:`external identifier` in the ``name``.
|
||||
|
||||
In the :ref:`next chapter <tutorials/getting_started/11_constraints>` we'll see how we can prevent
|
||||
encoding incorrect data in Odoo.
|
||||
In the :ref:`next chapter <howto/rdtraining/11_constraints>` we'll see how we can prevent encoding
|
||||
incorrect data in Odoo.
|
||||
|
Before Width: | Height: | Size: 186 KiB After Width: | Height: | Size: 186 KiB |
|
Before Width: | Height: | Size: 120 KiB After Width: | Height: | Size: 120 KiB |
|
Before Width: | Height: | Size: 97 KiB After Width: | Height: | Size: 97 KiB |
|
|
@@ -1,11 +1,11 @@
|
|||
.. _tutorials/getting_started/11_constraints:
|
||||
.. _howto/rdtraining/11_constraints:
|
||||
|
||||
=======================
|
||||
Chapter 11: Constraints
|
||||
=======================
|
||||
|
||||
The :ref:`previous chapter <tutorials/getting_started/10_actions>` introduced the ability to add
|
||||
some business logic to our model. We can now link buttons to business code, but how can we prevent
|
||||
The :ref:`previous chapter <howto/rdtraining/10_actions>` introduced the ability to add some
|
||||
business logic to our model. We can now link buttons to business code, but how can we prevent
|
||||
users from entering incorrect data? For example, in our real estate module nothing prevents
|
||||
users from setting a negative expected price.
|
||||
|
||||
|
|
@@ -123,7 +123,7 @@ prefer SQL over Python constraints.
|
|||
|
||||
Our real estate module is starting to look good. We added some business logic, and now we make sure
|
||||
the data is consistent. However, the user interface is still a bit rough. Let's see how we can
|
||||
improve it in the :ref:`next chapter <tutorials/getting_started/12_sprinkles>`.
|
||||
improve it in the :ref:`next chapter <howto/rdtraining/12_sprinkles>`.
|
||||
|
||||
.. _PostgreSQL's documentation:
|
||||
.. _table_constraint:
|
||||
|
Before Width: | Height: | Size: 316 KiB After Width: | Height: | Size: 316 KiB |
|
Before Width: | Height: | Size: 225 KiB After Width: | Height: | Size: 225 KiB |
|
Before Width: | Height: | Size: 128 KiB After Width: | Height: | Size: 128 KiB |
|
|
@@ -1,13 +1,13 @@
|
|||
.. _tutorials/getting_started/12_sprinkles:
|
||||
.. _howto/rdtraining/12_sprinkles:
|
||||
|
||||
=============================
|
||||
Chapter 12: Add The Sprinkles
|
||||
=============================
|
||||
|
||||
Our real estate module now makes sense from a business perspective. We created
|
||||
:ref:`specific views <tutorials/getting_started/07_basicviews>`, added several
|
||||
:ref:`action buttons <tutorials/getting_started/10_actions>` and
|
||||
:ref:`constraints <tutorials/getting_started/11_constraints>`. However our user interface is still a bit
|
||||
:ref:`specific views <howto/rdtraining/07_basicviews>`, added several
|
||||
:ref:`action buttons <howto/rdtraining/10_actions>` and
|
||||
:ref:`constraints <howto/rdtraining/11_constraints>`. However our user interface is still a bit
|
||||
rough. We would like to add some colors to the list views and make some fields and buttons conditionally
|
||||
disappear. For example, the 'Sold' and 'Cancel' buttons should disappear when the property
|
||||
is sold or canceled since it is no longer allowed to change the state at this point.
|
||||
|
|
@@ -268,7 +268,7 @@ behavior customizations, we can add the ``options`` attribute to several field w
|
|||
Have a look at the :ref:`FieldMany2ManyTags widget documentation <reference/js/widgets>`
|
||||
for more info.
|
||||
|
||||
In :ref:`tutorials/getting_started/06_firstui`, we saw that reserved fields were used for
|
||||
In :ref:`howto/rdtraining/06_firstui`, we saw that reserved fields were used for
|
||||
specific behaviors. For example, the ``active`` field is used to automatically filter out
|
||||
inactive records. We added the ``state`` as a reserved field as well. It's now time to use it!
|
||||
A ``state`` field is used in combination with a ``states`` attribute in the view to display
|
||||
|
|
@@ -507,7 +507,7 @@ Every time the partner name is changed, the description is modified.
|
|||
|
||||
- Create a stat button on ``estate.property.type`` pointing to the ``estate.property.offer``
|
||||
action. This means you should use the ``type="action"`` attribute (go back to the end of
|
||||
:ref:`tutorials/getting_started/10_actions` if you need a refresher).
|
||||
:ref:`howto/rdtraining/10_actions` if you need a refresher).
|
||||
|
||||
At this point, clicking on the stat button should display all offers. We still need to filter out the
|
||||
offers.
|
||||
|
|
@@ -516,8 +516,8 @@ Every time the partner name is changed, the description is modified.
|
|||
as equal to the ``active_id`` (= the current record,
|
||||
`here is an example <https://github.com/odoo/odoo/blob/df37ce50e847e3489eb43d1ef6fc1bac6d6af333/addons/event/views/event_views.xml#L162>`__)
|
||||
|
||||
Looking good? If not, don't worry, the :ref:`next chapter
|
||||
<tutorials/getting_started/13_inheritance>` doesn't require stat buttons ;-)
|
||||
Looking good? If not, don't worry, the :ref:`next chapter <howto/rdtraining/13_inheritance>` doesn't
|
||||
require stat buttons ;-)
|
||||
|
||||
.. _order_by:
|
||||
https://www.postgresql.org/docs/current/queries-order.html
|
||||
|
Before Width: | Height: | Size: 25 KiB After Width: | Height: | Size: 25 KiB |
|
Before Width: | Height: | Size: 276 KiB After Width: | Height: | Size: 276 KiB |
|
Before Width: | Height: | Size: 283 KiB After Width: | Height: | Size: 283 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |