Compare commits
51 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| c38f860301 | |||
| 8114d07bff | |||
| 86e8741509 | |||
| e69e853f44 | |||
| 3bb92d5472 | |||
| 97f9ae1b95 | |||
| 7f0153afff | |||
| a00b6cf990 | |||
| 71fbef5e5f | |||
| 7f747f05dd | |||
| 3c58f305b5 | |||
| c7a6b67a87 | |||
| 7d45830ac8 | |||
| 91165a7012 | |||
| 498280b932 | |||
| 38640aeb0e | |||
| 65f8645bed | |||
| 058e379a40 | |||
| 372a9b09f9 | |||
| 6458e07f44 | |||
| de2241eb7c | |||
| 9b7d3d559b | |||
| daa25ce5d9 | |||
| 36d407830e | |||
| 3f87216e36 | |||
| 0b6c2466a8 | |||
| 5a19d0c718 | |||
| 8aae97b838 | |||
| e38438c0ae | |||
| beeeff9068 | |||
| daebf2e579 | |||
| 9f18e77815 | |||
| 1ac6e5e975 | |||
| dd94839b20 | |||
| a04b9e1f2f | |||
| 6cc9c9a75e | |||
| f552c117a8 | |||
| 108f731916 | |||
| d1779bf4e5 | |||
| 2e3e7ad35c | |||
| 08c43b3deb | |||
| a6f1cd2cf9 | |||
| 50daadf7d1 | |||
| 2b04033868 | |||
| f8cb28ce14 | |||
| 208c1b8e81 | |||
| 7dfc3fe2c9 | |||
| 06a3323dcb | |||
| c22f90137b | |||
| 92a90f60e8 | |||
| 5769e8f617 |
@@ -231,6 +231,7 @@ sphinx.transforms.i18n.docname_to_domain = (
|
||||
# is populated. If a version is passed to `versions` but is not listed here, it will not be shown.
|
||||
versions_names = {
|
||||
'master': "Master",
|
||||
'saas-18.1': "Odoo Online",
|
||||
'18.0': "Odoo 18",
|
||||
'saas-17.4': "Odoo Online",
|
||||
'saas-17.2': "Odoo Online",
|
||||
|
||||
@@ -23,7 +23,7 @@ Edit Security Settings --> Delete Account`. It can also be accessed by going to
|
||||
Upon clicking the :guilabel:`Delete Account` button, a pop-up window appears, requesting
|
||||
confirmation for the account deletion.
|
||||
|
||||
.. image:: odoo_account/delete-account.png
|
||||
.. image:: odoo_accounts/delete-account.png
|
||||
:align: center
|
||||
:alt: Clicking on the Delete Account button will populate a window verifying the change.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 18 KiB After Width: | Height: | Size: 18 KiB |
@@ -31,6 +31,12 @@ This matrix shows the support status of every version.
|
||||
- On-Premise
|
||||
- Release date
|
||||
- End of support
|
||||
* - Odoo SaaS 18.1
|
||||
- |green|
|
||||
- N/A
|
||||
- N/A
|
||||
- January 2025
|
||||
-
|
||||
* - **Odoo 18.0**
|
||||
- |green|
|
||||
- |green|
|
||||
@@ -38,17 +44,17 @@ This matrix shows the support status of every version.
|
||||
- October 2024
|
||||
- October 2027 (planned)
|
||||
* - Odoo SaaS 17.4
|
||||
- |green|
|
||||
- |red|
|
||||
- N/A
|
||||
- N/A
|
||||
- July 2024
|
||||
-
|
||||
- October 2024
|
||||
* - Odoo SaaS 17.2
|
||||
- |green|
|
||||
- |red|
|
||||
- N/A
|
||||
- N/A
|
||||
- April 2024
|
||||
-
|
||||
- October 2024
|
||||
* - **Odoo 17.0**
|
||||
- |green|
|
||||
- |green|
|
||||
|
||||
@@ -390,8 +390,8 @@ few exceptions.
|
||||
filestore before deploying the new version.
|
||||
|
||||
In case of an issue with your production database, you can request the assistance of Odoo by going
|
||||
to the `Support page and selecting "An issue related to my future upgrade (I am testing an upgrade)"
|
||||
<https://www.odoo.com/help?stage=migration>`_.
|
||||
to the `Support page and selecting "An issue related to my upgrade (production)"
|
||||
<https://www.odoo.com/help?stage=post_upgrade>`_.
|
||||
|
||||
.. _upgrade-sla:
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 3.0 KiB |
|
Before Width: | Height: | Size: 4.2 KiB |
|
Before Width: | Height: | Size: 3.1 KiB |
|
Before Width: | Height: | Size: 7.5 KiB |
|
Before Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 9.2 KiB |
@@ -101,14 +101,13 @@ Tax Report
|
||||
----------
|
||||
|
||||
Once all the transactions involving taxes have been posted for the period you want to report, open
|
||||
your :guilabel:`Tax Report` by going to :menuselection:`Accounting --> Reporting -->
|
||||
Audit Reports: Tax Report`. Make sure to select the right period you want to declare by using the
|
||||
date filter, this way you can have an overview of your tax report. From this view, you can easily
|
||||
access different formats of your tax report, such as `PDF` and XLSX. These include all the values to
|
||||
report to the tax authorities, along with the amount you have to pay or be refunded.
|
||||
the :guilabel:`Tax Report` by going to :menuselection:`Accounting --> Reporting --> Tax Report`.
|
||||
Select the period you want to declare using the date filter to have an overview of the tax report.
|
||||
From the report, click :guilabel:`PDF` or :guilabel:`XLSX` to download the desired format of the tax
|
||||
report, or click :guilabel:`Save` to save the report to the Documents app. The report includes all
|
||||
the values to report to the tax authorities, along with the amount to be paid or refunded.
|
||||
|
||||
.. image:: tax_returns/tax_return_report.png
|
||||
:align: center
|
||||
:alt: download the PDF with your Tax Report in Odoo Accounting
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -91,9 +91,10 @@ To buy credits, go to :menuselection:`Accounting --> Configuration --> Settings
|
||||
and click on :guilabel:`Buy credits`, or go to :menuselection:`Settings --> Odoo IAP` and click on
|
||||
:guilabel:`View My Services`.
|
||||
|
||||
.. important::
|
||||
If you are on Odoo Online and have the Enterprise version, you benefit from free trial credits to
|
||||
test the feature.
|
||||
.. note::
|
||||
Enterprise Odoo users with a valid subscription get free credits to test IAP features before
|
||||
deciding to purchase more credits for the database. This includes demo/training databases,
|
||||
educational databases, and one-app-free databases.
|
||||
|
||||
.. seealso::
|
||||
- `Our Privacy Policy <https://iap.odoo.com/privacy#header_6>`_
|
||||
|
||||
@@ -333,8 +333,9 @@ This government-certified system entails the use of a :ref:`certified POS system
|
||||
Certified POS system
|
||||
--------------------
|
||||
|
||||
The Odoo POS system is certified for the major versions of databases hosted on **Odoo Online** and
|
||||
**Odoo.sh**. Please refer to the following table to ensure that your POS system is certified.
|
||||
The Odoo POS system is certified for the major versions of databases hosted on **Odoo Online**,
|
||||
**Odoo.sh**, and **On-Premise**. Please refer to the following table to ensure that your POS system
|
||||
is certified.
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
@@ -344,22 +345,26 @@ The Odoo POS system is certified for the major versions of databases hosted on *
|
||||
- Odoo Online
|
||||
- Odoo.sh
|
||||
- On-Premise
|
||||
* - Odoo 18.0
|
||||
- Certified
|
||||
- Certified
|
||||
- Certified
|
||||
* - Odoo 17.0
|
||||
- Certified
|
||||
- Certified
|
||||
- Not certified
|
||||
- Certified
|
||||
* - Odoo 16.0
|
||||
- Certified
|
||||
- Certified
|
||||
- Not certified
|
||||
- Certified
|
||||
* - Odoo 15.0
|
||||
- Certified
|
||||
- Certified
|
||||
- Not certified
|
||||
- Certified
|
||||
* - Odoo 14.0
|
||||
- Certified
|
||||
- Certified
|
||||
- Not certified
|
||||
- Certified
|
||||
|
||||
.. seealso::
|
||||
:doc:`/administration/supported_versions`
|
||||
|
||||
|
Before Width: | Height: | Size: 31 KiB |
@@ -205,11 +205,11 @@ An Odoo local server works as a bridge between your computer and your Odoo datab
|
||||
Download the Odoo Community installer from the page https://www.odoo.com/page/download and start the
|
||||
installation on your computer.
|
||||
|
||||
Select :guilabel:`Local Proxy Mode` as the type of install.
|
||||
Select :guilabel:`Odoo IoT` as the type of install.
|
||||
|
||||
.. image:: egypt/install-odoo-local-proxy.png
|
||||
:align: center
|
||||
:alt: Selection of "Local Proxy Mode" during the installation of Odoo Community.
|
||||
:alt: Selection of "Odoo IoT" during the installation of Odoo Community.
|
||||
|
||||
.. note::
|
||||
This installation of Odoo only works as a server and does not install any Odoo apps on your
|
||||
|
||||
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 10 KiB |
@@ -392,7 +392,7 @@ user is requested by the **State** to:
|
||||
|
||||
- Select a tax with the option :guilabel:`Has exoneration of tax (Italy)` ticked, and the
|
||||
:guilabel:`Exoneration` set to `N3.3`;
|
||||
- Use the generic :abbr:`SdI (Sistema di Interscambio)` :guilabel:`Codice Destinatario` `2R4GT08`.
|
||||
- Use the generic :abbr:`SdI (Sistema di Interscambio)` :guilabel:`Codice Destinatario` `2R4GTO8`.
|
||||
The invoice is then routed by a dedicated office in San Marino to the correct business.
|
||||
|
||||
Bills
|
||||
@@ -457,3 +457,60 @@ recipient office.
|
||||
government `website <http://www.fatturapa.gov.it/>`_.
|
||||
- The :abbr:`CUU (Codice Univoco Ufficio)` must be included in the electronic invoice
|
||||
corresponding to the element **1.1.4** (:guilabel:`CodiceDestinario`).
|
||||
|
||||
Ri.Ba. (Ricevuta Bancaria)
|
||||
==========================
|
||||
|
||||
:abbr:`Ri.Ba. (Ricevuta Bancaria)` is a payment method widely used in Italy where vendors request
|
||||
payments through their bank, which forwards the request to the customer's own bank and takes
|
||||
responsibility for the collection. This enables payment automation and reduces risks for the vendor.
|
||||
|
||||
The vendor generally uploads a fixed-format text file with the list of payments to the bank's web
|
||||
portal.
|
||||
|
||||
.. note::
|
||||
- Ri.Ba. are exclusively for **domestic payments** in Italy. For recurring international
|
||||
payments, please use `SEPA Direct Debt (SDD) <../accounting/payments/batch_sdd>`_
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
#. Check that the `l10n_it_riba` module is :ref:`installed <general/install>`.
|
||||
#. Go to :menuselection:`Settings --> Users & Companies --> Companies` and select the company that
|
||||
will use Ri.Ba.
|
||||
#. Fill out the required :guilabel:`SIA Code`.
|
||||
|
||||
.. image:: italy/sia-code.png
|
||||
:alt: The company's SIA code
|
||||
|
||||
.. note::
|
||||
The :guilabel:`SIA Code` identifies businesses within the Italian banking network and is used
|
||||
to receive money through specific payment methods. It consists of one letter and four digits
|
||||
(e.g., T1234) and can usually be found on the bank's portal or obtained by contacting the bank.
|
||||
|
||||
#. Ensure the Company's bank account has an Italian IBAN.
|
||||
|
||||
.. seealso::
|
||||
How to configure :doc:`Bank Accounts <../accounting/bank>`
|
||||
|
||||
Accept Ri.Ba. for your invoices
|
||||
-------------------------------
|
||||
|
||||
Payments of type :abbr:`Ri.Ba. (Ricevuta Bancaria)` can be registered from the :guilabel:`Invoices`
|
||||
(:menuselection:`Accounting --> Customers --> Invoices`).
|
||||
|
||||
.. important::
|
||||
Make sure that your invoice involves a Partner that has a bank account with an Italian IBAN.
|
||||
|
||||
Then, all Payments must be grouped in a **Batch Payment**.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Batch Payments <../accounting/payments>`
|
||||
- :doc:`Create a Batch Payment <../accounting/payments/batch>`
|
||||
|
||||
Once you press the :guilabel:`Validate` button for the Batch Payment, the :abbr:`Ri.Ba. (Ricevuta
|
||||
Bancaria)` file is generated and attached to the Batch Payment, so you can download it and upload it
|
||||
through your bank's web portal.
|
||||
|
||||
.. image:: italy/riba-attachment.png
|
||||
:alt: The Ri.Ba. file attached
|
||||
|
||||
|
After Width: | Height: | Size: 40 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 8.2 KiB |
|
Before Width: | Height: | Size: 28 KiB |
|
Before Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 73 KiB |
@@ -74,16 +74,14 @@ When ready, change the provider's :guilabel:`State` to :guilabel:`Enabled` for a
|
||||
Import an Authorize.Net statement
|
||||
=================================
|
||||
|
||||
.. _authorize-import-template:
|
||||
|
||||
Export from Authorize.Net
|
||||
-------------------------
|
||||
|
||||
.. _authorize-import-template:
|
||||
|
||||
.. admonition:: Template
|
||||
|
||||
`Download the Excel import template <https://docs.google.com/spreadsheets/d/1CMVtBWLLVIrUpYA92paw-cL7-WdKLbaa/edit?usp=share_link&ouid=105295722917050444558&rtpof=true&sd=true>`_
|
||||
|
||||
To export a statement:
|
||||
:download:`Download the Excel import template. <authorize/authorize-net-magic-sheet.xlsx>`
|
||||
|
||||
- Log in to Authorize.Net.
|
||||
- Go to :menuselection:`Account --> Statements --> eCheck.Net Settlement Statement`.
|
||||
|
||||
|
Before Width: | Height: | Size: 117 KiB |
|
Before Width: | Height: | Size: 2.6 KiB |
@@ -18,7 +18,6 @@ page. Next, navigate to the :guilabel:`Senders & Domains` section and click on :
|
||||
SEND API Settings`.
|
||||
|
||||
.. image:: mailjet_api/api-settings.png
|
||||
:align: center
|
||||
:alt: SMTP and Send API Settings link in the Senders & Domains section of Mailjet.
|
||||
|
||||
Then, copy the :abbr:`SMTP (Simple Mail Transfer Protocol)` configuration settings onto a notepad.
|
||||
@@ -37,7 +36,6 @@ port number. The settings are needed to configure Mailjet in Odoo, which is cove
|
||||
<email_servers/restriction>`.
|
||||
|
||||
.. image:: mailjet_api/smtp-config.png
|
||||
:align: center
|
||||
:alt: SMTP configuration from Mailjet.
|
||||
|
||||
Next, click on the button labeled :guilabel:`Retrieve your API credentials` to retrieve the Mailjet
|
||||
@@ -125,7 +123,6 @@ Copy the TXT record information to a notepad and then navigate to the domain's :
|
||||
Name System)` provider to complete validation.
|
||||
|
||||
.. image:: mailjet_api/host-value-dns.png
|
||||
:align: center
|
||||
:alt: The TXT record information to input on the domain's DNS.
|
||||
|
||||
Setup in the domain's DNS
|
||||
@@ -163,7 +160,6 @@ Identified Mail) records to input into the :abbr:`DNS (Domain Name System)` prov
|
||||
360042412734-Authenticating-Domains-with-SPF-DKIM>`_
|
||||
|
||||
.. image:: mailjet_api/authenticate.png
|
||||
:align: center
|
||||
:alt: Authenticate the domain with SPF/DKIM records in Mailjet.
|
||||
|
||||
.. _maintain/mailjet-api/odoo-setup:
|
||||
@@ -191,27 +187,4 @@ than that of any transactional email server(s). Finally, save the settings and :
|
||||
Connection`.
|
||||
|
||||
.. image:: mailjet_api/server-settings.png
|
||||
:align: center
|
||||
:alt: Odoo outgoing email server settings.
|
||||
|
||||
.. important::
|
||||
In order for the notifications feature to work using Mailjet, there are three settings that need
|
||||
to be set in Odoo.
|
||||
|
||||
#. The :guilabel:`From Filter` needs to be set on the server configuration. It is recommended
|
||||
to set it as a domain and not a full email address. It should match the domain in the two
|
||||
proceeding steps. More information can be referenced :ref:`here
|
||||
<email_communication/from_filter>`.
|
||||
#. The :guilabel:`mail.default.from` system parameter must have the value
|
||||
`notifications\@yourdomain.com`.
|
||||
#. The :guilabel:`mail.default.from_filter` system parameter must have the value
|
||||
`yourdomain.com`. Replace `yourdomain` with the custom domain for the Odoo database. If there
|
||||
isn't one, then use the :guilabel:`mail.catchall.domain` system parameter.
|
||||
|
||||
For more information see :ref:`Using a default email address <email_communication/default>`.
|
||||
|
||||
The :guilabel:`System Parameters` can be accessed by activating the :ref:`developer mode
|
||||
<developer-mode>`.
|
||||
|
||||
Once the setup is complete, the Odoo database is ready to use the Mailjet email server for mass
|
||||
mailing or transactional emails!
|
||||
|
||||
|
Before Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 9.6 KiB |
|
Before Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 9.6 KiB |
|
Before Width: | Height: | Size: 7.9 KiB |
|
Before Width: | Height: | Size: 3.3 KiB |
|
Before Width: | Height: | Size: 39 KiB |
|
Before Width: | Height: | Size: 5.5 KiB |
|
Before Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 5.5 KiB |
|
Before Width: | Height: | Size: 6.9 KiB |
|
Before Width: | Height: | Size: 9.2 KiB |
|
Before Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 2.2 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
Before Width: | Height: | Size: 8.5 KiB |
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 22 KiB |
|
Before Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 7.8 KiB |
|
Before Width: | Height: | Size: 5.4 KiB |
|
Before Width: | Height: | Size: 9.7 KiB |
|
Before Width: | Height: | Size: 15 KiB |
|
Before Width: | Height: | Size: 2.8 KiB |
@@ -1,9 +1,166 @@
|
||||
:nosearch:
|
||||
:show-content:
|
||||
|
||||
.. |UoM| replace:: :abbr:`UoM (Unit of Measure)`
|
||||
.. |UoMs| replace:: :abbr:`UoMs (Units of Measure)`
|
||||
|
||||
|
||||
=================
|
||||
Configure product
|
||||
=================
|
||||
|
||||
A group of products in Odoo can be further defined using:
|
||||
|
||||
- :doc:`Units of measure (UoM) <configure/uom>`: a standard quantity for specifying product amounts
|
||||
(e.g., meters, yards, kilograms). Enables automatic conversion between measurement systems in
|
||||
Odoo, such as centimeters to feet.
|
||||
|
||||
- *Ex: Purchasing fabric measured in meters but receiving it in yards from a vendor.*
|
||||
|
||||
- :doc:`configure/package`: A physical container used to group products together, regardless of
|
||||
whether they are the same or different.
|
||||
|
||||
- *Ex: A box containing assorted items for delivery, or a storage box of two hundred buttons on a
|
||||
shelf.*
|
||||
|
||||
- :doc:`configure/packaging`: groups the *same* products together to receive or sell them in
|
||||
specified quantities.
|
||||
|
||||
- *Ex: Cans of soda sold in packs of six, twelve, or twenty-four.*
|
||||
|
||||
Comparison
|
||||
==========
|
||||
|
||||
This table provides a detailed comparison of units of measure, packages, and packaging to help
|
||||
businesses evaluate which best suits their requirements.
|
||||
|
||||
.. list-table::
|
||||
:header-rows: 1
|
||||
:stub-columns: 1
|
||||
|
||||
* - Feature
|
||||
- Unit of measure
|
||||
- Packages
|
||||
- Packaging
|
||||
* - Purpose
|
||||
- Standardized measurement for product units (e.g., cm, lb, L)
|
||||
- Tracks the specific physical container and its contents
|
||||
- Groups a fixed number of items together for easier management (e.g., packs of 6, 12 or 24)
|
||||
* - Product uniformity
|
||||
- Defined per product; saved as one |UoM| in the database
|
||||
- Allows mixed products
|
||||
- Same products only
|
||||
* - Flexible
|
||||
- Converts between vendor/customer |UoMs| and database |UoM|
|
||||
- Items can be added or removed from the container
|
||||
- Quantities are fixed (e.g., always packs of 6, 12 or 24)
|
||||
* - Complexity
|
||||
- Simplest for unit conversions
|
||||
- More complex due to container-level inventory tracking
|
||||
- Simpler; suitable for uniform product groupings
|
||||
* - Inventory tracking
|
||||
- Tracks product quantities within the warehouse in the specific |UoM| defined in the product
|
||||
form
|
||||
- Tracks package location and contents within the warehouse
|
||||
- Tracks grouped quantities but not individual items' locations
|
||||
* - Smooth barcode operations
|
||||
- Not available
|
||||
- Requires scanning both the package and individual items for reception. (even if there are 30
|
||||
items in a package). Can enable the :ref:`Move Entire Packages
|
||||
<inventory/product_management/move-entire-pack>` feature to update the package's contained
|
||||
items' locations, when moving the package
|
||||
- Scanning a packaging barcode automatically records all included units. (e.g. 1 pack = 12
|
||||
units)
|
||||
* - Product lookup
|
||||
- Not available
|
||||
- Scanning a product's barcode identifies its typical storage location in the Odoo database
|
||||
- Barcode identifies grouped quantity, not storage location
|
||||
* - Unique barcodes
|
||||
- Not available
|
||||
- Unique barcodes for individual packages (e.g. Pallet #12)
|
||||
- Barcodes set at the packaging type level (e.g. for a pack of 6)
|
||||
* - Reusability
|
||||
- Not applicable
|
||||
- Can be disposable or reusable, configured via the :ref:`Package Use
|
||||
<inventory/warehouses_storage/cluster-pack>` field
|
||||
- Disposable only
|
||||
* - Container weight
|
||||
- Not applicable
|
||||
- Weight of the container itself is included in the *Shipping Weight* field of a package
|
||||
(:menuselection:`Inventory app --> Products --> Packages`)
|
||||
- Weight of the container is defined in the *Package Type* settings
|
||||
* - Lot/serial number tracking
|
||||
- Requires manual adjustments to track |UoMs| via lots (See :ref:`use case
|
||||
<inventory/product_management/lots-uom>` for details)
|
||||
- Applies only to contained products
|
||||
- Applies to both contained products and the container
|
||||
* - Custom routes
|
||||
- Cannot be set
|
||||
- Cannot be set
|
||||
- Routes can define specific warehouse paths for a particular packaging type
|
||||
|
||||
Use cases
|
||||
=========
|
||||
|
||||
After comparing the various features, consider how these businesses, with various inventory
|
||||
management and logistics workflows, came to their decision.
|
||||
|
||||
Pallets of items using packaging
|
||||
--------------------------------
|
||||
|
||||
A warehouse receives shipments of soap organized on physical pallets, each containing 96 bars. These
|
||||
pallets are used for internal transfers and are also sold as standalone units. For logistical
|
||||
purposes, the pallet's weight must be included in the total shipping weight for certain deliveries.
|
||||
Additionally, the pallet requires a barcode to facilitate tracking, and the number of individual
|
||||
bars of soap must be included in the stock count when the pallet is received.
|
||||
|
||||
After evaluating various options, *product packaging* was the most suitable solution. Packaging
|
||||
enables assigning a barcode to a pallet, identifying it as a "pallet type" containing 96 soap bars.
|
||||
This barcode streamlines operations by automatically registering the grouped quantity. Key
|
||||
distinctions include:
|
||||
|
||||
- **Warehouse tracking limitations**: Odoo tracks only the total quantity, not the number of
|
||||
packagings. For instance, if a pallet with 12 and 24 quantities is received, Odoo records 36
|
||||
quantities, not the pallet details.
|
||||
- **Packaging barcodes are type-specific, not unique**: Barcodes represent packaging types (e.g.,
|
||||
"pallet of 96 soap bars") but do not uniquely identify individual pallets, such as Pallet #1 or
|
||||
Pallet #2.
|
||||
|
||||
Capture product information using barcode
|
||||
-----------------------------------------
|
||||
|
||||
An Odoo user expects the **Barcode** app to display the typical storage location of a product by
|
||||
scanning a barcode for a container.
|
||||
|
||||
*Packages* was the most suitable. When the :ref:`appropriate setting is enabled
|
||||
<inventory/warehouses_storage/enable-package>`, scanning a package barcode displays its contents in
|
||||
the **Barcode** app.
|
||||
|
||||
Packages represent physical containers, enabling detailed tracking of the items they hold.
|
||||
Scanning a package provides visibility into its contents and facilitates operations, like inventory
|
||||
moves.
|
||||
|
||||
.. _inventory/product_management/lots-uom:
|
||||
|
||||
Track different units of measure in storage
|
||||
-------------------------------------------
|
||||
|
||||
A fruit juice distributor tracks multiple |UoMs| for their operations:
|
||||
|
||||
- Fruits are purchased in tons.
|
||||
- Juice is produced and stored in kilograms.
|
||||
- Small samples are stored in grams for recipe testing.
|
||||
|
||||
*Unit of Measure* was most suitable. Odoo automatically converts tons to kilograms during
|
||||
receipts. However, since Odoo tracks only one |UoM| per product in the database, the company uses
|
||||
lot numbers to differentiate |UoMs|:
|
||||
|
||||
- LOT1: Grams (g)
|
||||
- LOT2: Kilograms (kg)
|
||||
|
||||
Manual inventory adjustments are required to convert between lots, such as subtracting 1 kg from
|
||||
LOT2 to add 1,000 g to LOT1. While functional, this workaround can be time-consuming and prone to
|
||||
errors.
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
|
||||
@@ -45,6 +45,17 @@ the :guilabel:`Operations` heading, activate the :guilabel:`Packages` feature. T
|
||||
:align: center
|
||||
:alt: Activate the *Packages* setting in Inventory > Configuration > Settings.
|
||||
|
||||
.. _inventory/product_management/move-entire-pack:
|
||||
|
||||
When moving packages internally, the *Move Entire Packages* feature can be enabled on an operation
|
||||
type to update a package's contained item's location upon updating the package's location.
|
||||
|
||||
To do that, go to :menuselection:`Inventory app --> Configuration --> Operations Types` and select
|
||||
the desired operation this feature will apply to (may have to set it for multiple).
|
||||
|
||||
On the operation type page, in the :guilabel:`Packages` section, tick the :guilabel:`Move Entire
|
||||
Packages` checkbox.
|
||||
|
||||
.. _inventory/warehouses_storage/pack:
|
||||
|
||||
Pack items
|
||||
|
||||
|
Before Width: | Height: | Size: 23 KiB |
|
Before Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 5.2 KiB |
|
Before Width: | Height: | Size: 15 KiB |
@@ -30,7 +30,7 @@ To do that, go to the :menuselection:`Inventory app --> Configuration --> Settin
|
||||
the :guilabel:`Traceability` section, and click the box next to :guilabel:`Lots & Serial Numbers`.
|
||||
Then, click the :guilabel:`Save` button to save changes.
|
||||
|
||||
.. image:: product_tracking/product_tracking/differences-enabled-setting.png
|
||||
.. image:: product_tracking/differences-enabled-setting.png
|
||||
:align: center
|
||||
:alt: Enabled lots and serial numbers feature in inventory settings.
|
||||
|
||||
@@ -42,7 +42,7 @@ or food. Lots and can be used to trace a product back to a group, which is espec
|
||||
managing product recalls or expiration dates.
|
||||
|
||||
.. example::
|
||||
.. image:: product_tracking/product_tracking/differences-lot.png
|
||||
.. image:: product_tracking/differences-lot.png
|
||||
:align: center
|
||||
:alt: Created lot with quantity of products in it.
|
||||
|
||||
@@ -59,7 +59,7 @@ identifiable when it travels through the supply chain. This can be especially us
|
||||
manufacturers that provide after-sales services related to products they sell and deliver.
|
||||
|
||||
.. example::
|
||||
.. image:: product_tracking/product_tracking/differences-serial-numbers.png
|
||||
.. image:: product_tracking/differences-serial-numbers.png
|
||||
:align: center
|
||||
:alt: List of serial numbers for product.
|
||||
|
||||
@@ -89,7 +89,7 @@ Doing so reveals all existing lots and serial numbers, and each can be expanded
|
||||
quantities with that assigned number. For unique serial numbers that are *not* reused, there should
|
||||
*only* be one product per serial number.
|
||||
|
||||
.. image:: product_tracking/product_tracking/differences-tracking.png
|
||||
.. image:: product_tracking/differences-tracking.png
|
||||
:align: center
|
||||
:alt: Reporting page with drop-down lists of lots and serial numbers.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 51 KiB |
|
Before Width: | Height: | Size: 54 KiB After Width: | Height: | Size: 54 KiB |
|
Before Width: | Height: | Size: 60 KiB After Width: | Height: | Size: 60 KiB |
|
Before Width: | Height: | Size: 47 KiB After Width: | Height: | Size: 47 KiB |
@@ -28,8 +28,8 @@ Receive (and store) consignment stock
|
||||
=====================================
|
||||
|
||||
With the feature enabled in Odoo, consignment stock can now be received into a warehouse. From the
|
||||
main :menuselection:`Inventory` dashboard, click into the :guilabel:`Receipts`
|
||||
section. Then, click :guilabel:`Create`.
|
||||
main :menuselection:`Inventory` dashboard, click into the :guilabel:`Receipts` section. Then, click
|
||||
:guilabel:`Create`.
|
||||
|
||||
.. note::
|
||||
Consignment stock is not actually purchased from the vendor; it is simply received and stored.
|
||||
@@ -74,9 +74,9 @@ quotation is complete, click :guilabel:`Confirm`.
|
||||
:align: center
|
||||
:alt: Sales order of consignment stock.
|
||||
|
||||
Once the :abbr:`RFQ (Request for Quotation)` has been confirmed, it will become a sales order. From
|
||||
here, the products can be delivered by clicking on the :guilabel:`Delivery` smart button, and
|
||||
selecting :guilabel:`Validate` to validate the delivery.
|
||||
Once the quotation has been confirmed, it becomes a sales order. From here, the products can be
|
||||
delivered by clicking on the :guilabel:`Delivery` smart button, and selecting :guilabel:`Validate`
|
||||
to validate the delivery.
|
||||
|
||||
Traceability and reporting of consignment stock
|
||||
===============================================
|
||||
@@ -88,19 +88,19 @@ To find inventory reports, go to :menuselection:`Inventory --> Reporting`, and c
|
||||
view.
|
||||
|
||||
.. note::
|
||||
Since the consignee does not actually own consigment stock, these products are *not* reflected
|
||||
Since the consignee does not actually own consignment stock, these products are *not* reflected
|
||||
in the :guilabel:`Stock Valuation` report, and have no impact on the consignee's inventory
|
||||
valuation.
|
||||
|
||||
Product moves report
|
||||
--------------------
|
||||
|
||||
To view all information about on-hand stock moves, navigate to the the :guilabel:`Product Moves`
|
||||
To view all information about on-hand stock moves, navigate to the :guilabel:`Product Moves`
|
||||
dashboard by going to :menuselection:`Inventory --> Reporting --> Product Moves`. For consignment
|
||||
products, the information in this report is the same as any other product: the history
|
||||
of its product moves can be reviewed; the :guilabel:`Quantity Done` and :guilabel:`Reference`
|
||||
document are available; and its :guilabel:`Locations` are available, as well. The consignment stock
|
||||
will originate from :guilabel:`Partner Location/Vendors`.
|
||||
products, the information in this report is the same as any other product: the history of its
|
||||
product moves can be reviewed; the :guilabel:`Quantity Done` and :guilabel:`Reference` document are
|
||||
available; and its :guilabel:`Locations` are available, as well. The consignment stock will
|
||||
originate from :guilabel:`Partner Location/Vendors`.
|
||||
|
||||
.. tip::
|
||||
To view a consignment product's moves by ownership, select the :guilabel:`Group By` filter,
|
||||
@@ -120,6 +120,6 @@ Stock on hand report
|
||||
|
||||
View the :guilabel:`Stock On Hand` dashboard by navigating to :menuselection:`Inventory -->
|
||||
Reporting --> Inventory Report`. From this report, the :guilabel:`Locations` of all stock on-hand
|
||||
are displayed, in addition to the quantities per location. For consigment products, the
|
||||
are displayed, in addition to the quantities per location. For consignment products, the
|
||||
:guilabel:`Owner` column will be populated with the owner of those products, or the original vendor
|
||||
who supplied the products in the first place.
|
||||
|
||||
|
Before Width: | Height: | Size: 8.6 KiB |
|
Before Width: | Height: | Size: 8.4 KiB |
|
Before Width: | Height: | Size: 11 KiB |
|
Before Width: | Height: | Size: 29 KiB |
|
Before Width: | Height: | Size: 18 KiB |
|
Before Width: | Height: | Size: 76 KiB |
|
Before Width: | Height: | Size: 18 KiB |
@@ -25,7 +25,7 @@ To do so, navigate to the :menuselection:`Apps` application from the main Odoo d
|
||||
Then, remove the :guilabel:`Apps` filter, and type in `Delivery Costs` in the :guilabel:`Search...`
|
||||
bar. After finding the :guilabel:`Delivery Costs` module, click :guilabel:`Activate` to install it.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/install-module.png
|
||||
.. image:: setup_configuration/install-module.png
|
||||
:align: center
|
||||
:alt: Install the Delivery Costs module.
|
||||
|
||||
@@ -43,7 +43,7 @@ Methods`.
|
||||
#. Scroll to the :guilabel:`Shipping` section and enable the :guilabel:`Delivery Methods` feature
|
||||
by checking the corresponding checkbox.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/enable-delivery.png
|
||||
.. image:: setup_configuration/enable-delivery.png
|
||||
:align: center
|
||||
:alt: Enable the *Delivery Methods* feature by checking the box in Configuration > Settings.
|
||||
|
||||
@@ -97,7 +97,7 @@ To enable free shipping if the amount of the order exceeds a specified amount, c
|
||||
- :guilabel:`Free if order amount is above`: `$100.00`
|
||||
- :guilabel:`Delivery Product`: `[SHIP] Flat`
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/new-shipping-method.png
|
||||
.. image:: setup_configuration/new-shipping-method.png
|
||||
:align: center
|
||||
:alt: Example of filling out a shipping method.
|
||||
|
||||
@@ -124,7 +124,7 @@ Once finished, click either :guilabel:`Save & New` to add another rule, or :guil
|
||||
To charge customers $20 in shipping for orders with five or fewer products, set the
|
||||
:guilabel:`Condition` to `Quantity <= 5.00`, and the :guilabel:`Delivery Cost` to `$20`.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/pricing-rule.png
|
||||
.. image:: setup_configuration/pricing-rule.png
|
||||
:align: center
|
||||
:alt: Display window to add a pricing rule. Set a condition and delivery cost.
|
||||
|
||||
@@ -150,7 +150,7 @@ Shipping cost is the :guilabel:`Delivery cost` specified in the rule that satisf
|
||||
|
||||
:guilabel:`Margin on Rate` is `10%` and :guilabel:`Additional margin` is `$9.00`.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/delivery-cost-example.png
|
||||
.. image:: setup_configuration/delivery-cost-example.png
|
||||
:align: center
|
||||
:alt: Show example of "Based on rules" shipping method with margins configured.
|
||||
|
||||
@@ -201,7 +201,7 @@ the shipping method form.
|
||||
`Furniture Delivery`, a delivery product with a fixed rate of `$200`, is added to sales order
|
||||
`S00088`.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/delivery-product.png
|
||||
.. image:: setup_configuration/delivery-product.png
|
||||
:align: center
|
||||
:alt: Show delivery order on the sales order line.
|
||||
|
||||
@@ -212,7 +212,7 @@ The shipping method added to the sales order is linked to the shipping carrier d
|
||||
delivery order. To add or change the delivery method on the delivery itself, go to the
|
||||
:guilabel:`Additional Info` tab and modify the :guilabel:`Carrier` field.
|
||||
|
||||
.. image:: setup_configuration/setup_configuration/delivery-order.png
|
||||
.. image:: setup_configuration/delivery-order.png
|
||||
:align: center
|
||||
:alt: Shipping carrier information on the delivery form.
|
||||
|
||||
|
||||
@@ -6,8 +6,8 @@ Set up the *Bpost* shipping connector in Odoo to manage Bpost shipments to clien
|
||||
Odoo. To configure it, complete these steps:
|
||||
|
||||
#. Create a Bpost account.
|
||||
#. Get the :ref:`Account ID and passphrase <inventory/shipping/Bpost-account>`.
|
||||
#. Set up the shipping method in Odoo.
|
||||
#. Get the :ref:`Account ID and passphrase <inventory/shipping_receiving/bpost-account>`.
|
||||
#. :ref:`Set up the shipping method in Odoo <inventory/shipping_receiving/bpost-method>`.
|
||||
|
||||
Upon completion, it is possible to calculate the cost of shipping, based on package size and weight,
|
||||
have the charges applied directly to a Bpost business account, and automatically print Bpost
|
||||
@@ -19,8 +19,8 @@ tracking labels through Odoo.
|
||||
- :doc:`dhl_credentials`
|
||||
- :doc:`ups_credentials`
|
||||
|
||||
Bpost account setup
|
||||
===================
|
||||
Account setup
|
||||
=============
|
||||
|
||||
To begin, go to the `Bpost website <https://parcel.bpost.be/en/home/business>`_ to create, or log
|
||||
into, the company's Bpost business account. When creating the Bpost account, have the company's VAT
|
||||
@@ -30,25 +30,24 @@ Follow the website's steps to complete registration, and sign up for shipping se
|
||||
submits a request to enter a contractual business relationship between the company and Bpost.
|
||||
|
||||
.. important::
|
||||
Odoo **cannot** be integrated with `non-business Bpost
|
||||
<https://bpost.freshdesk.com/support/solutions/articles/174847-account-id-and-passphrase>`_
|
||||
accounts.
|
||||
Odoo **cannot** be integrated with `non-business Bpost <https://www.odoo.com/r/Z4wZ>`_ accounts.
|
||||
|
||||
After completing the setup, get the Bpost account ID and passphrase, by navigating to the
|
||||
:guilabel:`Shipping Manager` menu item.
|
||||
|
||||
.. _inventory/shipping/bpost-account:
|
||||
.. _inventory/shipping_receiving/bpost-account:
|
||||
|
||||
On the :guilabel:`Shipping Manager` page, go to the :guilabel:`Admin` tab, then the
|
||||
:guilabel:`General Settings` tab, to find the :guilabel:`Account ID` and :guilabel:`Passphrase`
|
||||
needed to configure Odoo's shipping method.
|
||||
|
||||
.. image:: bpost/credentials.png
|
||||
:align: center
|
||||
:alt: In the *Admin* tab, show the Account ID and Passphrase.
|
||||
|
||||
Configure Bpost shipping method
|
||||
===============================
|
||||
.. _inventory/shipping_receiving/bpost-method:
|
||||
|
||||
Shipping method configuration
|
||||
=============================
|
||||
|
||||
With those necessary credentials, configure the Bpost shipping method in Odoo by going to
|
||||
:menuselection:`Inventory app --> Configuration --> Shipping Methods`.
|
||||
@@ -69,23 +68,20 @@ Product`, refer to the :doc:`Configure third-party carrier <third_party_shipper>
|
||||
In the :guilabel:`Bpost Configuration` tab, complete the following fields:
|
||||
|
||||
- :guilabel:`Bpost Account Number` (required field): enter the company's unique :ref:`account ID
|
||||
<inventory/shipping/bpost-account>` from the Bpost website.
|
||||
<inventory/shipping_receiving/bpost-account>` from the Bpost website.
|
||||
- :guilabel:`Passphrase` (required field): enter the :ref:`passphrase
|
||||
<inventory/shipping/bpost-account>` from the Bpost website.
|
||||
<inventory/shipping_receiving/bpost-account>` from the Bpost website.
|
||||
- :guilabel:`Bpost Delivery Nature`: select either :guilabel:`Domestic` or :guilabel:`International`
|
||||
shipping services. Choosing :guilabel:`Domestic` shows the :guilabel:`Options` section, while
|
||||
:guilabel:`International` enables the :guilabel:`Bpost Shipment Type` and :guilabel:`Bpost Parcel
|
||||
Return Instructions` fields.
|
||||
- :guilabel:`Bpost Package Type`: select the type of shipping service from the drop-down menu.
|
||||
|
||||
For `domestic delivery
|
||||
<https://help.shipmondo.com/en/articles/6092265-bpost-belgium-parcel-types-and-requirements>`_,
|
||||
the options are: :guilabel:`bpack 24h Pro`, :guilabel:`bpack 24h business`, or :guilabel:`bpack
|
||||
Bus`.
|
||||
For `domestic delivery <https://www.odoo.com/r/uOVM>`_, the options are: :guilabel:`bpack 24h
|
||||
Pro`, :guilabel:`bpack 24h business`, or :guilabel:`bpack Bus`.
|
||||
|
||||
For `international delivery <https://www.bpost.be/en/business-parcels-send/international>`_, the
|
||||
options are: :guilabel:`bpack World Express Pro`, :guilabel:`bpack World Business`, or
|
||||
:guilabel:`bpack Europe Business`.
|
||||
For `international delivery <https://www.odoo.com/r/s6G>`_, the options are: :guilabel:`bpack
|
||||
World Express Pro`, :guilabel:`bpack World Business`, or :guilabel:`bpack Europe Business`.
|
||||
- :guilabel:`Bpost Shipment Type` (required field): for international deliveries, declare the type
|
||||
of goods in the package as :guilabel:`SAMPLE`, :guilabel:`GIFT`, :guilabel:`GOODS`,
|
||||
:guilabel:`DOCUMENTS`, or :guilabel:`OTHER`.
|
||||
@@ -105,6 +101,5 @@ For domestic deliveries, these features are available in the :guilabel:`Options`
|
||||
validating the delivery order.
|
||||
|
||||
.. image:: bpost/bpost.png
|
||||
:align: center
|
||||
:alt: Show Bpost shipping method.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
|
Before Width: | Height: | Size: 6.0 KiB After Width: | Height: | Size: 6.0 KiB |
|
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 21 KiB |
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 4.6 KiB After Width: | Height: | Size: 4.6 KiB |
|
Before Width: | Height: | Size: 9.0 KiB After Width: | Height: | Size: 9.0 KiB |
|
Before Width: | Height: | Size: 6.3 KiB After Width: | Height: | Size: 6.3 KiB |
|
Before Width: | Height: | Size: 17 KiB |
|
Before Width: | Height: | Size: 21 KiB |
@@ -38,7 +38,7 @@ The following is a list of available shipping connectors in Odoo:
|
||||
- United States of America
|
||||
* - :doc:`Sendcloud <sendcloud_shipping>`
|
||||
- Some European countries (see details below)
|
||||
* - Bpost
|
||||
* - :doc:`Bpost <bpost>`
|
||||
- Belgium
|
||||
* - Easypost
|
||||
- North America
|
||||
|
||||
@@ -82,7 +82,7 @@ field, there are:
|
||||
correct the quantity, five units are moved from `WH/Stock` to `Virtual Locations/Inventory
|
||||
Adjustment`.
|
||||
|
||||
.. image:: inventory_management/inventory_management/inventory-loss.png
|
||||
.. image:: inventory_management/inventory-loss.png
|
||||
:align: center
|
||||
:alt: Product ends up in Virtual Locations/Inventory Adjustment.
|
||||
|
||||
@@ -93,7 +93,7 @@ field, there are:
|
||||
products shipped between different addresses, such as :ref:`Physical Locations/Inter-warehouse
|
||||
transit <inventory/warehouses_storage/interwarehouse-transit>`.
|
||||
|
||||
.. image:: inventory_management/inventory_management/locations.png
|
||||
.. image:: inventory_management/locations.png
|
||||
:align: center
|
||||
:alt: List of locations in Odoo.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 16 KiB |
|
Before Width: | Height: | Size: 3.4 KiB |
|
Before Width: | Height: | Size: 19 KiB After Width: | Height: | Size: 19 KiB |
|
Before Width: | Height: | Size: 90 KiB After Width: | Height: | Size: 90 KiB |
@@ -8,35 +8,75 @@ Replenishment
|
||||
.. |MTO| replace:: :abbr:`MTO (Make to Oder)`
|
||||
.. |PO| replace:: :abbr:`PO (Purchase Order)`
|
||||
.. |MO| replace:: :abbr:`MO (Manufacturing Order)`
|
||||
.. |POs| replace:: :abbr:`POs (Purchase Orders)`
|
||||
.. |MOs| replace:: :abbr:`MOs (Manufacturing Orders)`
|
||||
.. |SO| replace:: :abbr:`SO (Sales Order)`
|
||||
|
||||
In Odoo, there are two strategies for automatically replenishing inventory: *reordering rules* and
|
||||
the *make to order (MTO)* route. Although these strategies differ slightly, they both have similar
|
||||
consequences: triggering the automatic creation of a |PO| or |MO|. The choice of which strategy to
|
||||
use depends on the business's manufacturing and delivery processes.
|
||||
In Odoo, stock can be replenished one of three ways: *reordering rules*, the *make to order* (MTO)
|
||||
route, or using the *master production schedule* (MPS).
|
||||
|
||||
Terminology
|
||||
===========
|
||||
Each replenishment mechanism triggers the creation or suggestion of a purchase order (PO) or
|
||||
manufacturing order (MO), with the best choice depending on the business process.
|
||||
|
||||
.. cards::
|
||||
|
||||
.. card:: Reordering rules
|
||||
:target: replenishment/reordering_rules
|
||||
:tag: Recommended
|
||||
:large:
|
||||
|
||||
Automatically suggest or generate POs or MOs when stock falls below a minimum level.
|
||||
|
||||
.. card:: MTO
|
||||
:target: replenishment/mto
|
||||
:tag: Beginner-friendly
|
||||
|
||||
Automatically generate POs or MOs when sales orders are confirmed.
|
||||
|
||||
.. card:: MPS
|
||||
:target: ../../manufacturing/management/use_mps
|
||||
|
||||
Manage long-term replenishment based on inputted sales forecasts, via a dashboard.
|
||||
|
||||
Replenishment strategies
|
||||
========================
|
||||
|
||||
Replenishment report and reordering rules
|
||||
-----------------------------------------
|
||||
|
||||
The replenishment report is a list of all products that have a negative forecast quantity.
|
||||
Reordering rules are rules that can be set up to maintain a minimum stock level. They are often
|
||||
configured to support manufacturing or sales requirements. When a product's stock falls at or below
|
||||
the minimum level, Odoo generates (or suggests) a purchase or manufacturing order to replenish stock
|
||||
to the maximum level.
|
||||
|
||||
*Reordering rules* are used to ensure there's always a minimum amount of a product in-stock, in
|
||||
order to manufacture products and/or fulfill sales orders. When the stock level of a product reaches
|
||||
its minimum, Odoo automatically generates a purchase order with the quantity needed to reach the
|
||||
maximum stock level.
|
||||
When using automatic reordering rules, Odoo generates a new order. When using manual, Odoo suggests
|
||||
orders on the replenishment report. For detailed guidance, refer to the :doc:`replenishment report
|
||||
<replenishment/report>` and :doc:`reordering rules <replenishment/reordering_rules>`.
|
||||
|
||||
Reordering rules can be created and managed in the replenishment report, or from the product form.
|
||||
Key points include:
|
||||
|
||||
- :ref:`Automatic reordering rules <inventory/warehouses_storage/auto-rr>`: Automatically create
|
||||
|POs| or |MOs| when stock falls below the minimum level. While this is convenient, it is less
|
||||
flexible.
|
||||
- :ref:`Manual reordering rules <inventory/warehouses_storage/manual-rr>`: Generate suggestions in
|
||||
the replenishment report for user review, allowing adjustments and batch orders while meeting
|
||||
deadlines.
|
||||
- :ref:`Just-in-time logic <inventory/warehouses_storage/just-in-time>`: A strategy to replenish
|
||||
only what is needed to prevent overstocking.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`replenishment/reordering_rules`
|
||||
- :doc:`replenishment/report`
|
||||
|
||||
.. _inventory/management/products/strategies:
|
||||
|
||||
Make to order
|
||||
-------------
|
||||
|
||||
*Make to order (MTO)* is a procurement route that creates a draft purchase order (or manufacturing
|
||||
order) each time a sales order is confirmed, **regardless of the current stock level**.
|
||||
An |MTO| strategy means that procurement or production is triggered only after a sales order has
|
||||
been confirmed. This strategy is recommended when products are customizable, demand is
|
||||
unpredictable, there is limited storage capacity, and when products are high in value and low in
|
||||
demand. In such cases, it does not make sense to keep on-hand inventory.
|
||||
|
||||
Unlike products replenished using reordering rules, Odoo automatically links the sales order to the
|
||||
|PO| or |MO| generated by the |MTO| route.
|
||||
@@ -51,159 +91,29 @@ as the |PO| or |MO| is not confirmed.
|
||||
The |MTO| route is the best replenishment strategy for products that are customized, and/or for
|
||||
products that have no stock kept on-hand.
|
||||
|
||||
.. seealso::
|
||||
:doc:`replenishment/mto`
|
||||
|
||||
Configuration
|
||||
=============
|
||||
Master production schedule
|
||||
--------------------------
|
||||
|
||||
Replenishment report and reordering rules
|
||||
-----------------------------------------
|
||||
The :abbr:`MPS (Master Production Schedule)` is a dashboard where products and their forecasted
|
||||
quantities are entered. Based on confirmed manufacturing and purchase orders, the dashboard
|
||||
recommends amounts to order or produce.
|
||||
|
||||
To access the replenishment report, go to :menuselection:`Inventory app --> Operations -->
|
||||
Replenishment.`
|
||||
This a useful **manual** tool for keeping track of quantities. The :abbr:`MPS (Master Production
|
||||
Schedule)` **should absolutely not** be used alongside reordering rules, as the automated workflow
|
||||
disrupts its manual replenishment method.
|
||||
|
||||
By default, the replenishment report dashboard shows every product that needs to be manually
|
||||
reordered. If there is no specific rule for a product, Odoo assumes the :guilabel:`Min Quantity` and
|
||||
:guilabel:`Max Quantity` stock are both `0.00`
|
||||
|
||||
.. note::
|
||||
For products that don't have a set reordering rule, Odoo calculates the forecast based on
|
||||
confirmed sales orders, deliveries, and receipts. For products that have a set reordering rule,
|
||||
Odoo calculates the forecast normally, but also takes into account the purchase/manufacturing
|
||||
lead time and security lead time.
|
||||
|
||||
.. important::
|
||||
Before creating a new reordering rule, make sure the product has a *vendor* or a *bill of
|
||||
materials* configured on the product form. To check this, go to :menuselection:`Inventory app
|
||||
--> Products --> Products`, and select the product to open its product form. The vendor, if
|
||||
configured, is listed in the :guilabel:`Purchase` tab, and the bill on materials, if configured,
|
||||
is found in the :guilabel:`Bill of Materials` smart button at the top of the form.
|
||||
|
||||
The :guilabel:`Product Type`, located in the :guilabel:`General Information` tab on the product
|
||||
form, **must** be set to :guilabel:`Storable Product`. By definition, a consumable product does
|
||||
not have its inventory levels tracked, so Odoo cannot account for a consumable product in the
|
||||
replenishment report.
|
||||
|
||||
.. image:: replenishment/replenishment/replenishment-report-dashboard.png
|
||||
:align: center
|
||||
:alt: Replenishment report listing all items needing to be purchased to meet current needs.
|
||||
|
||||
To create a new reordering rule from the replenishment report, go to :menuselection:`Inventory app
|
||||
--> Operations --> Replenishment`, click :guilabel:`Create`, and select the desired product from the
|
||||
drop-down menu in the :guilabel:`Product` column. If necessary, a :guilabel:`Min Quantity` and a
|
||||
:guilabel:`Max Quantity` can be configured in the corresponding columns on the
|
||||
:guilabel:`Replenishment` report page, as well.
|
||||
|
||||
To create a new reordering rule from the product form, go to :menuselection:`Inventory app -->
|
||||
Products --> Products`, and select a product to open its product form. Click the
|
||||
:guilabel:`Reordering Rules` smart button, click :guilabel:`Create`, and fill out the fields.
|
||||
|
||||
Replenishment report fields
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The following fields are on the :guilabel:`Replenishment` report. If any of these fields are not
|
||||
visible, click the :guilabel:`⋮ (additional options)` icon on the far right side of the report, then
|
||||
click the checkbox next to a field to make it visible.
|
||||
|
||||
- :guilabel:`Product`: the product that requires a replenishment.
|
||||
- :guilabel:`Location`: the specific location where the product is stored.
|
||||
- :guilabel:`Warehouse`: the warehouse where the product is stored.
|
||||
- :guilabel:`On Hand`: the amount of product currently available.
|
||||
- :guilabel:`Forecast`: the amount of product available after all current orders (sales,
|
||||
manufacturing, purchase, etc.) are taken into account.
|
||||
- :guilabel:`Preferred Route`: how the product is procured, either :guilabel:`Buy`,
|
||||
:guilabel:`Manufactured`, :guilabel:`Dropship`, etc.
|
||||
- :guilabel:`Vendor`: the company from which the product is acquired.
|
||||
- :guilabel:`Bill of Materials`: the bill of materials for the product (if one is configured).
|
||||
- :guilabel:`Trigger`: how the replenishment is created, either :guilabel:`Auto` (automatically,
|
||||
once the :guilabel:`On Hand` quantity goes below the :guilabel:`Min Quantity`) or
|
||||
:guilabel:`Manual` (only when the replenishment is requested).
|
||||
- :guilabel:`Procurement Group`: the reference number for how the product is being acquired, such as
|
||||
a sales order, purchase order, or manufacturing order.
|
||||
- :guilabel:`Min Quantity`: the minimum amount of product that should be available. When inventory
|
||||
levels goes below this number, the replenishment is triggered.
|
||||
- :guilabel:`Max Quantity`: the amount of product that should be available after replenishing the
|
||||
product.
|
||||
- :guilabel:`Multiple Quantity`: if the product should be ordered in specific quantities, enter the
|
||||
number that should be ordered. For example, if the :guilabel:`Multiple Quantity` is set to `5`,
|
||||
and only 3 are needed, 5 products are replenished.
|
||||
- :guilabel:`To Order`: the amount of product that is currently needed, and will be ordered, if the
|
||||
:guilabel:`Order Once` or :guilabel:`Automate Orders` button is clicked.
|
||||
- :guilabel:`UoM`: the unit of measure used to acquire the product.
|
||||
- :guilabel:`Company`: the company for which the product is acquired.
|
||||
|
||||
By default, the quantity in the :guilabel:`To Order` field is the quantity required to reach the set
|
||||
:guilabel:`Max Quantity`. However, the :guilabel:`To Order` quantity can be adjusted by clicking on
|
||||
the field and changing the value. To replenish a product manually, click :guilabel:`Order Once`.
|
||||
|
||||
To automate a replenishment from the :guilabel:`Replenishment` page, click :guilabel:`Automate
|
||||
Orders` on the right-side of the line, represented by a :guilabel:`🔄 (circular arrow)` icon.
|
||||
|
||||
When this button is clicked, Odoo will automatically generate a draft |PO|/|MO| every time the
|
||||
forecasted stock level falls below the set :guilabel:`Min Quantity` of the reordering rule.
|
||||
|
||||
On the :guilabel:`Replenishment` page, a reordering rule or manual replenishment can be temporarily
|
||||
deactivated for a given period, by clicking the :guilabel:`🔕 (snooze)` icon on the far-right of the
|
||||
line.
|
||||
|
||||
.. image:: replenishment/replenishment/reordering-rule-snooze-settings.png
|
||||
:align: center
|
||||
:alt: Snooze options to turn off notifications for reordering for a period of time.
|
||||
|
||||
A |PO| or |MO| created by a manual replenishment has a :guilabel:`Replenishment Report` as the
|
||||
source document. A |PO| or |MO| created by an automated reordering rule has the |SO| reference
|
||||
number(s) that triggered the rule as the source document.
|
||||
|
||||
.. image:: replenishment/replenishment/rfq-source-document.png
|
||||
:align: center
|
||||
:alt: Quote request list shows which quotes are directly from the replenishment report.
|
||||
|
||||
Make to order (MTO) route
|
||||
=========================
|
||||
|
||||
Since the |MTO| route is recommended for customized products, the route is hidden by default.
|
||||
|
||||
To activate the |MTO| route in Odoo:
|
||||
#. Go to :menuselection:`Inventory app --> Configuration --> Settings`.
|
||||
#. Activate the :guilabel:`Multi-Step Routes` setting, located under the :guilabel:`Warehouse`
|
||||
section, and click :guilabel:`Save`.
|
||||
#. Then, go to :menuselection:`Inventory app --> Configuration --> Routes`.
|
||||
#. Click on :menuselection:`Filters --> Archived` to show archived routes.
|
||||
#. Select the checkbox next to :guilabel:`Replenish on Order (MTO)`, and click on
|
||||
:menuselection:`Action --> Unarchive`.
|
||||
|
||||
.. note::
|
||||
Activating the :guilabel:`Multi-Step Routes` setting also activates :guilabel:`Storage
|
||||
Locations`. If these features aren't applicable to the warehouse, disable these settings after
|
||||
unarchiving the |MTO| route.
|
||||
|
||||
To set a product's procurement route to |MTO|, go to :menuselection:`Inventory app --> Products -->
|
||||
Products`, and click on the desired product to open its product form.
|
||||
|
||||
Then, click the :guilabel:`Inventory` tab, and in the :guilabel:`Routes` section of options, select
|
||||
:guilabel:`Replenish on Order (MTO)`.
|
||||
|
||||
For products purchased directly from a vendor, make sure the :guilabel:`Buy` route is selected, in
|
||||
addition to the :guilabel:`Replenish on Order (MTO)` route. Also, make sure a vendor is configured
|
||||
in the :guilabel:`Purchase` tab of the product form.
|
||||
|
||||
For products manufactured in-house, make sure the :guilabel:`Manufacture` route is selected, in
|
||||
addition to the :guilabel:`Replenish on Order (MTO)` route. Also, make sure a bill of materials is
|
||||
configured for the product, which is accessible via the :guilabel:`Bill of Materials` smart button
|
||||
on the product form.
|
||||
|
||||
.. note::
|
||||
The |MTO| route cannot be selected alone. |MTO| **only** works if the :guilabel:`Manufacture` or
|
||||
:guilabel:`Buy` route is also selected.
|
||||
|
||||
.. image:: replenishment/replenishment/acoustic-block-screen-replenish.png
|
||||
:align: center
|
||||
:alt: Replenish on Order selected on the product form.
|
||||
.. seealso::
|
||||
:doc:`../../manufacturing/management/use_mps`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
replenishment/mto
|
||||
replenishment/reordering_rules
|
||||
replenishment/report
|
||||
replenishment/lead_times
|
||||
replenishment/resupply_warehouses
|
||||
replenishment/warehouse_replenishment_transfer
|
||||
|
||||
@@ -2,9 +2,11 @@
|
||||
Lead times
|
||||
==========
|
||||
|
||||
.. |RFQ| replace:: :abbr:`RFQ (Request for Quotation)`
|
||||
|
||||
Accurately forecasting delivery dates is vital for fulfilling customer expectations. In Odoo, the
|
||||
*Inventory* app allows for comprehensive lead time configuration, allowing coordination and planning
|
||||
of manufacturing orders, deliveries, and receptions.
|
||||
**Inventory** app allows for comprehensive lead time configuration, allowing coordination and planning
|
||||
of manufacturing orders, deliveries, and receipts.
|
||||
|
||||
Lead time types
|
||||
===============
|
||||
@@ -37,6 +39,10 @@ process. Here's a summary of the types of lead times in Odoo:
|
||||
are set to replenish to order, the need appears on the *Replenishment report* earlier, according
|
||||
to the specified number of days.
|
||||
|
||||
- :ref:`Days to Purchase lead time <inventory/warehouses_storage/days-to-purchase>`: days needed for
|
||||
the vendor to receive a request for quotation (RFQ) and confirm it. It advances the deadline to
|
||||
schedule a |RFQ| by a specified number of days.
|
||||
|
||||
- :ref:`Manufacturing lead time <inventory/management/manuf-lt>`: the number of days needed to
|
||||
complete a manufacturing order (MO) from the date of confirmation. This lead time includes
|
||||
weekends (non-working hours in Odoo), and is used to forecast an approximate production date for a
|
||||
@@ -227,6 +233,15 @@ set to account for potential delays in supplier deliveries.
|
||||
:align: center
|
||||
:alt: Set security lead time for purchase from the Inventory > Configuration > Settings.
|
||||
|
||||
.. _inventory/warehouses_storage/days-to-purchase:
|
||||
|
||||
Days to purchase lead time
|
||||
--------------------------
|
||||
|
||||
To set it up, go to :menuselection:`Inventory app --> Configuration --> Settings`. Under the
|
||||
:guilabel:`Advanced Scheduling` section, in the :guilabel:`Days to Purchase` field, specify the
|
||||
number of days required for the vendor to confirm a |RFQ| after receiving it from the company.
|
||||
|
||||
.. _inventory/management/manuf-lt:
|
||||
|
||||
Manufacturing lead times
|
||||
|
||||
@@ -13,6 +13,8 @@ manufactured in-house triggers the creation of a manufacturing order. The creati
|
||||
manufacturing order occurs every time a sales order is created, regardless of the current stock
|
||||
level of the product being ordered.
|
||||
|
||||
.. _inventory/warehouse_storage/mto-route:
|
||||
|
||||
Unarchive the Replenish on Order (MTO) route
|
||||
============================================
|
||||
|
||||
|
||||
@@ -2,38 +2,71 @@
|
||||
Reordering rules
|
||||
================
|
||||
|
||||
.. |SO| replace:: :abbr:`SO (Sales Order)`
|
||||
.. |SOs| replace:: :abbr:`SOs (Sales Orders)`
|
||||
.. |RFQ| replace:: :abbr:`RFQ (Request for Quotation)`
|
||||
.. |RFQs| replace:: :abbr:`RFQs (Requests for Quotations)`
|
||||
.. |POs| replace:: :abbr:`POs (Purchase Orders)`
|
||||
.. |MO| replace:: :abbr:`MO (Manufacturing Order)`
|
||||
.. |MOs| replace:: :abbr:`MOs (Manufacturing Orders)`
|
||||
.. |BoM| replace:: :abbr:`BoM (Bill of Materials)`
|
||||
.. |BoMs| replace:: :abbr:`BoMs (Bills of Materials)`
|
||||
|
||||
.. _inventory/management/reordering_rules:
|
||||
|
||||
Reordering rules are used to keep forecasted stock levels above a certain threshold without
|
||||
*Reordering rules* are used to keep forecasted stock levels above a certain threshold without
|
||||
exceeding a specified upper limit. This is accomplished by specifying a minimum quantity that stock
|
||||
should not fall below and a maximum quantity that stock should not exceed.
|
||||
|
||||
Reordering rules can be configured for each product based on the route used to replenish it. If a
|
||||
product uses the *Buy* route, then a Request for Quotation (RFQ) is created when the reordering rule
|
||||
is triggered. If a product uses the *Manufacture* route, then a Manufacturing Order (MO) is created
|
||||
instead. This is the case regardless of the selected replenishment route.
|
||||
product uses the *Buy* route, then a *request for quotation* (RFQ) is created when the reordering
|
||||
rule is triggered. If a product uses the *Manufacture* route, then a *manufacturing order* (MO) is
|
||||
created instead. This is the case regardless of the selected replenishment route.
|
||||
|
||||
.. seealso::
|
||||
- `Odoo Tutorials: Automatic Reordering Rules <https://www.youtube.com/watch?v=XEJZrCjoXaU>`_
|
||||
- `Odoo Tutorials: Manual Reordering Rules <https://www.youtube.com/watch?v=deIREJ1FFj4>`_
|
||||
|
||||
Configure products for reordering rules
|
||||
=======================================
|
||||
To set up reordering rules for the first time, refer to:
|
||||
|
||||
In order to use reordering rules for a product, it must first be correctly configured. Begin by
|
||||
navigating to :menuselection:`Inventory app --> Products --> Products`, then select an existing
|
||||
product, or create a new one by clicking :guilabel:`New`.
|
||||
- :ref:`Reordering rules setup <inventory/warehouses_storage/configure-rr>`
|
||||
- :ref:`Trigger <inventory/product_management/trigger>`
|
||||
- :ref:`Preferred route <inventory/warehouses_storage/route>`
|
||||
|
||||
On the product form, under the :guilabel:`General Information` tab, make sure that the
|
||||
:guilabel:`Product Type` is set to :guilabel:`Storable Product`. This is necessary because Odoo only
|
||||
tracks stock quantities for storable products, and this number is used to trigger reordering rules.
|
||||
To understand and optimize replenishment using advanced features, see:
|
||||
|
||||
- :ref:`Just-in-time logic <inventory/warehouses_storage/just-in-time>`
|
||||
- :ref:`Visibility days <inventory/product_management/visibility-days>`
|
||||
|
||||
.. _inventory/warehouses_storage/configure-rr:
|
||||
|
||||
Reordering rules setup
|
||||
======================
|
||||
|
||||
To configure automatic and manual reordering rules, complete the following:
|
||||
|
||||
#. :ref:`Product type configuration <inventory/warehouses_storage/set-product-type>`
|
||||
#. :ref:`Create rule <inventory/warehouses_storage/rr-fields>`
|
||||
|
||||
.. _inventory/warehouses_storage/set-product-type:
|
||||
|
||||
Product type configuration
|
||||
--------------------------
|
||||
|
||||
A product must be configured correctly to use reordering rules. Begin by navigating to
|
||||
:menuselection:`Inventory app --> Products --> Products`, then select an existing product, or create
|
||||
a new one by clicking :guilabel:`New`.
|
||||
|
||||
On the product form, under the :guilabel:`General Information` tab, set the :guilabel:`Product Type`
|
||||
to :guilabel:`Storable Product`. This is necessary because Odoo only tracks stock quantities for
|
||||
storable products, and quantities are needed to trigger reordering rules.
|
||||
|
||||
.. image:: reordering_rules/product-type.png
|
||||
:align: center
|
||||
:alt: Set the Product Type as Storable.
|
||||
|
||||
Next, click on the :guilabel:`Inventory` tab and select one or more routes from the
|
||||
:guilabel:`Routes` section. Doing so tells Odoo which route to use to replenish the product.
|
||||
Next, click the :guilabel:`Inventory` tab and select one or more routes from the :guilabel:`Routes`
|
||||
section. Doing so tells Odoo which route to use to replenish the product.
|
||||
|
||||
.. image:: reordering_rules/select-routes.png
|
||||
:align: center
|
||||
@@ -49,94 +82,104 @@ they sell the product for, so that Odoo knows which company the product should b
|
||||
:alt: Specify a vendor and price on the Purchase tab.
|
||||
|
||||
If the product is replenished using the :guilabel:`Manufacture` route, it needs to have at least one
|
||||
Bill of Materials (BoM) associated with it. This is necessary because Odoo only creates
|
||||
manufacturing orders for products with a :abbr:`BoM (Bill of Materials)`.
|
||||
*bill of materials* (BoM) associated with it. This is necessary because Odoo only creates
|
||||
manufacturing orders for products with a |BoM|.
|
||||
|
||||
If a :abbr:`BoM (Bill of Materials)` does not already exist for the product, select the
|
||||
:guilabel:`Bill of Materials` smart button at the top of the product form, then click
|
||||
:guilabel:`New` to configure a new :abbr:`BoM (Bill of Materials)`.
|
||||
If a |BoM| does not already exist for the product, select the :guilabel:`Bill of Materials` smart
|
||||
button at the top of the product form, then click :guilabel:`New` to configure a new |BoM|.
|
||||
|
||||
.. image:: reordering_rules/bom-smart-button.png
|
||||
:align: center
|
||||
:alt: The Bill of Materials smart button on a product form.
|
||||
|
||||
.. _inventory/warehouses_storage/rr-fields:
|
||||
|
||||
Create new reordering rules
|
||||
===========================
|
||||
---------------------------
|
||||
|
||||
To create a new reordering rule, navigate to :menuselection:`Inventory app --> Configuration -->
|
||||
Reordering Rules`, then click :guilabel:`New`, and fill out the new line as follows:
|
||||
Reordering Rules`, then click :guilabel:`New`, and fill out the following fields in the new line:
|
||||
|
||||
- :guilabel:`Product`: The product that is replenished by the rule.
|
||||
- :guilabel:`Location`: The location where the product is stored.
|
||||
- :guilabel:`Min Quantity`: The minimum quantity that can be forecasted without the rule being
|
||||
triggered. When forecasted stock falls below this number, a replenishment order for the product is
|
||||
created.
|
||||
- :guilabel:`Max Quantity`: The maximum quantity that stock is replenished up to.
|
||||
- :guilabel:`Multiple Quantity`: Specify if the product should be replenished in batches of a
|
||||
certain quantity (e.g., a product could be replenished in batches of 20).
|
||||
- :guilabel:`UoM`: The unit of measure used for reordering the product. This value can simply be
|
||||
`Units` or a specific unit of measurement for weight, length, etc.
|
||||
- :guilabel:`Product`: The product that requires replenishment.
|
||||
- :guilabel:`Location`: The specific location where the product is stored.
|
||||
- :guilabel:`Min Quantity`: The minimum amount of product that should be available. When inventory
|
||||
levels goes below this number, the replenishment is triggered.
|
||||
- :guilabel:`Max Quantity`: The amount of product that should be available after replenishing the
|
||||
product.
|
||||
- :guilabel:`Multiple Quantity`: If the product should be ordered in specific quantities, enter the
|
||||
number that should be ordered. For example, if the :guilabel:`Multiple Quantity` is set to `5`,
|
||||
and only 3 are needed, 5 products are replenished.
|
||||
|
||||
.. image:: reordering_rules/reordering-rule-form.png
|
||||
:align: center
|
||||
:alt: The form for creating a new reordering rule.
|
||||
|
||||
.. tip::
|
||||
Reordering rules can also be created from each product form. To do so, navigate to
|
||||
:menuselection:`Inventory app --> Products --> Products`, then select a product. Click on
|
||||
:menuselection:`Reordering Rules smart button --> New`, then fill out the new line, as detailed
|
||||
above.
|
||||
Reordering rules can also be created from the :guilabel:`Reordering Rules` smart button on the
|
||||
product form.
|
||||
|
||||
.. note::
|
||||
To learn how the :guilabel:`On Hand`, :guilabel:`Forecast`, and :guilabel:`To Order` fields are
|
||||
calculated using on-hand quantities and future demand, see the :ref:`Just-in-time logic
|
||||
<inventory/warehouses_storage/just-in-time>` section.
|
||||
|
||||
For advanced usage of reordering rules, learn about the following reordering rule fields:
|
||||
|
||||
- :ref:`Trigger <inventory/product_management/trigger>`
|
||||
- :ref:`Preferred route <inventory/warehouses_storage/route>`
|
||||
- :ref:`Vendor <inventory/warehouses_storage/set-vendor>`
|
||||
- :ref:`Bill of materials <inventory/warehouses_storage/set-bom-field>`
|
||||
- :ref:`Procurement group <inventory/warehouses_storage/procurement-grp>`
|
||||
- :ref:`Visibility days <inventory/product_management/visibility-days>`
|
||||
- :ref:`Preferred route <inventory/product_management/route>`
|
||||
|
||||
.. note::
|
||||
The fields above are not available by default, and must be enabled by selecting the
|
||||
:guilabel:`(slider)` icon in the far-right corner, and selecting the desired column from the
|
||||
drop-down menu.
|
||||
:icon:`oi-settings-adjust` :guilabel:`(adjust)` icon in the far-right corner and selecting the
|
||||
desired column from the drop-down menu.
|
||||
|
||||
.. _inventory/product_management/trigger:
|
||||
|
||||
Trigger
|
||||
=======
|
||||
|
||||
When stock falls below the reordering rule's minimum, set the reordering rule's *trigger* to
|
||||
*automatic* to automatically create purchase or manufacturing orders to replenish stock.
|
||||
A reordering rule's *trigger* can be set to *automatic* or *manual*. While both function the same
|
||||
way, the difference between the two types of reordering rules is how the rule is launched:
|
||||
|
||||
Alternatively, setting the reordering rule's trigger to *manual* displays the product and forecasted
|
||||
stock on the *replenishment dashboard*, where the procurement manager can review the stock levels,
|
||||
lead times, and forecasted dates of arrival.
|
||||
- :ref:`Auto <inventory/warehouses_storage/auto-rr>`: A purchase or manufacturing order is
|
||||
automatically created when the forecasted stock falls below the reordering rule's minimum
|
||||
quantity. By default, the :guilabel:`Auto` trigger is selected.
|
||||
- :ref:`Manual <inventory/warehouses_storage/manual-rr>`: The :doc:`Replenishment report <report>`
|
||||
lists products needing replenishment, showing current/forecasted stock, lead times, and arrival
|
||||
dates. Users can review forecasts before clicking *Order Once*.
|
||||
|
||||
.. seealso::
|
||||
:doc:`../replenishment`
|
||||
|
||||
.. tip::
|
||||
The :guilabel:`Replenishment` dashboard is accessible by going to :menuselection:`Inventory app
|
||||
--> Operations --> Replenishment`.
|
||||
|
||||
To enable the :guilabel:`Trigger` field, go to :menuselection:`Inventory app --> Configuration -->
|
||||
Reordering Rules`. Then, click the :guilabel:`(slider)` icon, located to the far-right of the column
|
||||
titles, and enable the :guilabel:`Trigger` option from the additional options drop-down menu that
|
||||
appears.
|
||||
|
||||
.. image:: reordering_rules/enable-trigger.png
|
||||
:align: center
|
||||
:alt: Enable the Trigger field by toggling it in the additional options menu.
|
||||
To enable the :guilabel:`Trigger` field, go to :menuselection:`Inventory app --> Operations -->
|
||||
Replenishment` or :menuselection:`Inventory app --> Configuration --> Reordering Rules`. Then, click
|
||||
the :icon:`oi-settings-adjust` :guilabel:`(adjust)` icon, located to the far-right of the column
|
||||
titles, and tick the :guilabel:`Trigger` checkbox.
|
||||
|
||||
In the :guilabel:`Trigger` column, select :guilabel:`Auto` or :guilabel:`Manual`. Refer to the
|
||||
sections below to learn about the different types of reordering rules.
|
||||
|
||||
.. _inventory/warehouses_storage/auto-rr:
|
||||
|
||||
Auto
|
||||
----
|
||||
|
||||
Automatic reordering rules, enabled by setting the reordering rule's :guilabel:`Trigger` field to
|
||||
:guilabel:`Auto`, generate purchase or manufacturing orders when:
|
||||
*Automatic reordering rules*, enabled by setting the reordering rule's :guilabel:`Trigger` field to
|
||||
:guilabel:`Auto`, generate purchase or manufacturing orders when either:
|
||||
|
||||
#. the scheduler runs, and the *On Hand* quantity is below the minimum
|
||||
#. a sales order is confirmed, and lowers the *Forecasted* quantity of the product below the minimum
|
||||
#. The scheduler runs, and the *Forecasted* quantity is below the minimum, or
|
||||
#. A sales order is confirmed, and lowers the *Forecasted* quantity of the product below the
|
||||
minimum.
|
||||
|
||||
If the :guilabel:`Buy` route is selected, then an |RFQ| is generated. To view and manage |RFQs|,
|
||||
navigate to :menuselection:`Purchase app --> Orders --> Requests for Quotation`.
|
||||
|
||||
If the :guilabel:`Manufacture` route is selected, then an |MO| is generated. To view and manage
|
||||
|MOs|, navigate to :menuselection:`Manufacturing app --> Operations --> Manufacturing Orders`.
|
||||
|
||||
When no route is selected, Odoo selects the :guilabel:`Route` specified in the :guilabel:`Inventory`
|
||||
tab of the product form.
|
||||
|
||||
.. tip::
|
||||
The scheduler is set to run once a day, by default.
|
||||
@@ -157,102 +200,35 @@ Automatic reordering rules, enabled by setting the reordering rule's :guilabel:`
|
||||
:align: center
|
||||
:alt: Show automatic reordering rule from the Reordering Rule page.
|
||||
|
||||
If the :guilabel:`Buy` route is selected, then an :abbr:`RFQ (Request for Quotation)` is generated.
|
||||
To view and manage :abbr:`RFQs (Requests for Quotation)`, navigate to :menuselection:`Purchase app
|
||||
--> Orders --> Requests for Quotation`.
|
||||
|
||||
If the :guilabel:`Manufacture` route is selected, then an :abbr:`MO (Manufacturing Order)` is
|
||||
generated. To view and manage :abbr:`MOs (Manufacturing Orders)`, navigate to
|
||||
:menuselection:`Manufacturing app --> Operations --> Manufacturing Orders`.
|
||||
|
||||
When no route is selected, Odoo selects the :guilabel:`Route` specified in the :guilabel:`Inventory`
|
||||
tab of the product form.
|
||||
|
||||
.. _inventory/product_management/manual-rr:
|
||||
.. _inventory/warehouses_storage/manual-rr:
|
||||
|
||||
Manual
|
||||
------
|
||||
|
||||
Manual reordering rules, configured by setting the reordering rule's :guilabel:`Trigger` field to
|
||||
:guilabel:`Manual`, list a product on the replenishment dashboard when the forecasted quantity
|
||||
falls below a specified minimum. Products on this dashboard are called *needs*, because they are
|
||||
needed to fulfill upcoming sales orders, for which the forecasted quantity is not enough.
|
||||
*Manual reordering rules*, configured by setting the reordering rule's :guilabel:`Trigger` field to
|
||||
:guilabel:`Manual`, list a product on the :doc:`replenishment dashboard <report>` when the
|
||||
forecasted quantity falls below a specified minimum. Products on this dashboard are called *needs*,
|
||||
because they are needed to fulfill upcoming sales orders, for which the forecasted quantity is not
|
||||
enough.
|
||||
|
||||
The replenishment dashboard, accessible by navigating to :menuselection:`Inventory app -->
|
||||
Operations --> Replenishment`, considers sales order deadlines, forecasted stock levels, and vendor
|
||||
lead times. It displays needs **only** when it is time to reorder items.
|
||||
|
||||
.. note::
|
||||
If the one-day window for ordering products is too short, skip to the :ref:`visibility days
|
||||
<inventory/product_management/visibility-days>` section to make the need appear on the
|
||||
replenishment dashboard a specified number of days in advance.
|
||||
lead times. It displays needs **only** when it is time to reorder items, thanks to the :guilabel:`To
|
||||
Reorder` filter.
|
||||
|
||||
.. image:: reordering_rules/manual.png
|
||||
:align: center
|
||||
:alt: Click the Order Once button on the replenishment dashboard to replenish stock.
|
||||
|
||||
.. _inventory/product_management/visibility-days:
|
||||
|
||||
Visibility days
|
||||
===============
|
||||
|
||||
.. important::
|
||||
Ensure :doc:`lead times <lead_times>` are understood before proceeding with this section.
|
||||
|
||||
When :ref:`manual reordering rules <inventory/product_management/manual-rr>` are assigned to a
|
||||
product, *visibility days* make the product appear on the replenishment dashboard
|
||||
(:menuselection:`Inventory app --> Operations --> Replenishment`) a certain number of days in
|
||||
advance.
|
||||
|
||||
.. example::
|
||||
A product has a manual reordering rule set to trigger when the stock level falls below four
|
||||
units. The current on-hand quantity is ten units.
|
||||
|
||||
The current date is February twentieth, and the *delivery date* on a sales order (in the
|
||||
:guilabel:`Other Info` tab) is March third — twelve days from the current date.
|
||||
|
||||
The :ref:`vendor lead time <inventory/management/purchase-lt>` is four days, and the
|
||||
:ref:`purchase security lead time <inventory/management/purchase-security-lt>` is one day.
|
||||
|
||||
When the :guilabel:`Visibility Days` field of the reordering rule is set to zero, the product
|
||||
appears on the replenishment dashboard five days before the delivery date, which, in this case,
|
||||
is February twenty-seventh.
|
||||
|
||||
.. image:: reordering_rules/need-dates.png
|
||||
:align: center
|
||||
:alt: Graphic representing when the need appears on the replenishment dashboard: Feb 27.
|
||||
|
||||
To see the product on the replenishment dashboard for the current date, February twentieth, set
|
||||
the :guilabel:`Visibility Days` to `7.00`.
|
||||
|
||||
To determine the number of visibility days needed to see a product on the replenishment dashboard,
|
||||
subtract *today's date* from the *date the need appears* on the replenishment dashboard.
|
||||
|
||||
.. math::
|
||||
|
||||
Visibility~days = Need~appears~date - Today's~date
|
||||
|
||||
.. example::
|
||||
Referring to the example above, today's date is February twentieth, and the need for the product
|
||||
appears on February twenty-seventh.
|
||||
|
||||
(February 27 - February 20 = 7 days)
|
||||
|
||||
Incorrectly setting the :guilabel:`Visibility Days` fewer than seven days in this case results in
|
||||
the need **not** appearing on the replenishment dashboard.
|
||||
|
||||
.. image:: reordering_rules/visibility-days.png
|
||||
:align: center
|
||||
:alt: Show the replenishment dashboard with the correct and incorrect visibility days set.
|
||||
|
||||
.. _inventory/product_management/route:
|
||||
.. _inventory/warehouses_storage/route:
|
||||
|
||||
Preferred route
|
||||
===============
|
||||
|
||||
Odoo allows for multiple routes to be selected under the :guilabel:`Inventory` tab on each product
|
||||
form. For instance, it is possible to select both :guilabel:`Buy` and :guilabel:`Manufacture`, thus
|
||||
enabling the functionality of both routes.
|
||||
Odoo allows for multiple routes to be selected as replenishment methods under the
|
||||
:guilabel:`Inventory` tab on each product form. For instance, it is possible to select both
|
||||
:guilabel:`Buy` and :guilabel:`Manufacture`, indicating to Odoo that the product can be bought or
|
||||
manufactured.
|
||||
|
||||
Odoo also enables users to set a preferred route for a product's reordering rule. This is the route
|
||||
that the rule defaults to if multiple are selected. To select a preferred route, begin by navigating
|
||||
@@ -263,10 +239,249 @@ Click inside of the column on the row of a reordering rule, and a drop-down menu
|
||||
routes for that rule. Select one to set it as the preferred route.
|
||||
|
||||
.. image:: reordering_rules/select-preferred-route.png
|
||||
:align: center
|
||||
:alt: Select a preferred route from the drop-down.
|
||||
|
||||
.. important::
|
||||
If multiple routes are enabled for a product but no preferred route is set for its reordering
|
||||
rule, the product is reordered using the selected route that is listed first on the
|
||||
:guilabel:`Inventory` tab of the product form.
|
||||
|
||||
Advanced uses
|
||||
-------------
|
||||
|
||||
Pairing :guilabel:`Preferred Route` with one of the following fields on the replenishment report
|
||||
unlocks advanced configurations of reordering rules. Consider the following:
|
||||
|
||||
.. _inventory/warehouses_storage/set-vendor:
|
||||
|
||||
- :guilabel:`Vendor`: When the selected :guilabel:`Preferred Route` is :guilabel:`Buy`, setting the
|
||||
:guilabel:`Vendor` field to one of the multiple vendors on the vendor pricelist indicates to Odoo
|
||||
that the vendor is automatically populated on |RFQs| when a reordering rule triggers the creation
|
||||
of a purchase order.
|
||||
|
||||
.. _inventory/warehouses_storage/set-bom-field:
|
||||
|
||||
- :guilabel:`Bill of Materials`: When the :guilabel:`Preferred Route` is set to
|
||||
:guilabel:`Manufacture`, and there are multiple |BoMs| in use, specifying the desired |BoM| in the
|
||||
replenishment report, draft manufacturing orders are created with this |BoM| in use.
|
||||
|
||||
.. _inventory/warehouses_storage/procurement-grp:
|
||||
|
||||
- :guilabel:`Procurement Group`: This is a way to group related |POs| or |MOs| that are tied to
|
||||
fulfilling a specific demand, like an |SO| or a project. It helps organize and track which orders
|
||||
are linked to a particular demand.
|
||||
|
||||
.. note::
|
||||
Procurement groups link replenishment methods to demand, enabling smart buttons to appear when
|
||||
using the :ref:`MTO route <inventory/warehouse_storage/mto-route>`.
|
||||
|
||||
.. figure:: reordering_rules/po-smartbutton.png
|
||||
:alt: Showing smart button to PO.
|
||||
|
||||
Sales order (demand) with a linked purchase order (replenishment method).
|
||||
|
||||
In the context of reordering rules:
|
||||
|
||||
- Reordering rules do not automatically assign a procurement group, which is why there are no
|
||||
smart buttons that link |SOs| to |POs|, unlike the :abbr:`MTO (Make to Order)` route.
|
||||
- To enable smart buttons for products replenished by reordering rules (not :abbr:`MTO (Make to
|
||||
Order)`), with specific quantities linked to specific demands (e.g. |SOs|), assign a procurement
|
||||
group.
|
||||
- Without a procurement group, demands for the same product can be combined into a single |RFQ|,
|
||||
even if the reordering rule is executed multiple times for those demands. This allows for more
|
||||
efficient procurement by consolidating demands into fewer orders.
|
||||
|
||||
Selecting a procurement group in the :guilabel:`Procurement Group` field on the replenishment
|
||||
report ensures that all linked orders are grouped under the same demand, based on the defined
|
||||
route.
|
||||
|
||||
.. exercise::
|
||||
How can you set the *Procurement Group*, *Vendor*, and *Preferred Route* fields on the
|
||||
replenishment report to generate a single |RFQ| for five different products in sales order
|
||||
SO35, given they share the same vendor, Azure Interior, and ensure other demands for these
|
||||
products are handled separately?
|
||||
|
||||
.. spoiler:: View the answer
|
||||
|
||||
#. Set the :guilabel:`Procurement Group` to `SO35`, in the reordering rule for all five
|
||||
products. This groups the demands for `SO35` in the same |RFQ| or |MO|.
|
||||
#. Set the :guilabel:`Vendor` to `Azure Interior` to ensure the |RFQ| is created for the
|
||||
same supplier.
|
||||
#. Set the :guilabel:`Preferred Route` to :guilabel:`Buy` to generate an |RFQ|.
|
||||
#. Click the :guilabel:`Order Once` button to generate a single |RFQ| for the five products
|
||||
tied to `SO35`.
|
||||
|
||||
| After placing the order, remove `SO35` from the :guilabel:`Procurement Group` field of the
|
||||
five products' reordering rules. This ensures future demands for these products are
|
||||
managed separately and assigned to different |RFQs| (the usual behavior).
|
||||
|
||||
.. _inventory/warehouses_storage/just-in-time:
|
||||
|
||||
Just-in-time logic
|
||||
==================
|
||||
|
||||
*Just-in-time logic* in Odoo minimizes storage costs by placing orders precisely to meet deadlines.
|
||||
This is achieved using the :ref:`forecasted date <inventory/warehouses_storage/forecasted-date>`,
|
||||
which determines when replenishment is necessary to avoid overstocking.
|
||||
|
||||
The forecasted date is the **earliest possible date** to receive a product if the replenishment
|
||||
process starts immediately. It is calculated by summing the lead times linked to the replenishment
|
||||
process, such as :ref:`vendor lead times <inventory/management/purchase-lt>` and :ref:`purchasing
|
||||
delays <inventory/management/purchase-security-lt>` for purchases, or :ref:`manufacturing lead times
|
||||
<inventory/management/manuf-lt>` for production. Both automatic and manual reordering rules work
|
||||
this way.
|
||||
|
||||
.. example::
|
||||
For a product with a 5-day total lead time and a sales order delivery date in 10 days, Odoo waits
|
||||
5 days to place the order, ensuring it arrives just in time for delivery.
|
||||
|
||||
Important considerations:
|
||||
|
||||
- **If this feels risky**, consider adding buffer time or :doc:`adjusting lead times <lead_times>`
|
||||
for more flexibility.
|
||||
- While lead times and just-in-time logic provide additional control, **reordering rules work
|
||||
perfectly fine without them**. Keeping delivery dates on sales orders as their *creation date*
|
||||
ensures purchases are immediately triggered when needed
|
||||
|
||||
.. _inventory/warehouses_storage/forecasted-date:
|
||||
|
||||
Forecasted date and To Order quantity
|
||||
-------------------------------------
|
||||
|
||||
To view the *forecasted date*, go to the replenishment report and click the :icon:`fa-info-circle`
|
||||
:guilabel:`(info)` icon for the desired reordering rule. The :guilabel:`Replenishment Information`
|
||||
pop-up window displays the :guilabel:`Forecasted Date` and various lead times.
|
||||
|
||||
The *forecasted date* is the total time needed to procure a product in Odoo. It is calculated by
|
||||
summing the lead times linked to the product's replenishment process. The total of these lead times,
|
||||
added to the current date, determines when Odoo checks for demanded stock.
|
||||
|
||||
.. important::
|
||||
The forecasted date is the **earliest possible date** the customer can receive the product if the
|
||||
replenishment process began right **now**. It is calculated by adding all lead times related to
|
||||
the product to the current date.
|
||||
|
||||
.. example::
|
||||
A manual reordering rule is set up with no minimum or maximum quantities.
|
||||
|
||||
- Vendor lead time is 4 days, the purchase security lead time is 1 day, and the days to purchase
|
||||
is 2 days.
|
||||
- Today's date is November 26.
|
||||
- These add up to 7 days, making the forecasted date, December 3rd.
|
||||
|
||||
A confirmed |SO| for 5 units has a delivery date of December 3rd (7 days from today). This demand
|
||||
will appear on the replenishment report today, in the **To Order** field.
|
||||
|
||||
However, if the delivery date were later than December 3rd, it would not yet appear on the
|
||||
report. Odoo only displays quantities to replenish when they fall within the forecasted date
|
||||
window, ensuring orders are placed precisely when needed.
|
||||
|
||||
.. image:: reordering_rules/replenishment-info.png
|
||||
:alt: Show forecasted date in Odoo.
|
||||
|
||||
The *just-in-time* logic ensures replenishment happens only when it's necessary for the forecasted
|
||||
date's demand, helping avoid overstocking.
|
||||
|
||||
For example:
|
||||
|
||||
- If the forecasted quantity drops below the minimum **on** the forecasted date, replenishment must
|
||||
begin immediately to avoid shortages.
|
||||
- If the quantity drops below the minimum **after** the forecasted date, replenishment can wait.
|
||||
|
||||
The **To Order** quantity is the total demand on the forecasted date.
|
||||
|
||||
By timing purchase orders based on the combined lead times, Odoo optimizes stock levels, keeping
|
||||
inventory minimal while ensuring future requirements are ordered at the last possible
|
||||
moment—strategic procrastination without the stress!
|
||||
|
||||
Common confusion about forecasted quantities
|
||||
--------------------------------------------
|
||||
|
||||
|SOs| due **after** the :guilabel:`Forecasted Date` are not accounted for in the
|
||||
:guilabel:`Forecast` quantities of the reordering rule.
|
||||
|
||||
They are, however, accounted for on the forecasted report that is opened by clicking the
|
||||
:icon:`fa-area-chart` :guilabel:`(graph)` icon on the replenishment report, as this one represents
|
||||
the **long-term forecasted quantity**.
|
||||
|
||||
.. example::
|
||||
|
||||
.. figure:: reordering_rules/zero-forecast.png
|
||||
:alt: Forecast and To Order quantities is zero.
|
||||
|
||||
Continuing the above example, when the sales order's deadline is adjusted to December 4th, the
|
||||
:guilabel:`Forecast` and :guilabel:`To Order` quantities are zero.
|
||||
|
||||
.. figure:: reordering_rules/five-forecast.png
|
||||
:alt: Show forecasted report.
|
||||
|
||||
Opening the :guilabel:`Forecasted Report` shows the :guilabel:`Forecasted` units is `5.00`.
|
||||
|
||||
.. _inventory/product_management/visibility-days:
|
||||
|
||||
Visibility days
|
||||
===============
|
||||
|
||||
*Visibility days* enable the ability to determine if additional quantities should be added to the
|
||||
planned replenishment. Odoo checks if forecasted stock on the forecasted date will drop below the
|
||||
minimum in the reordering rule. **Only if** it is time to reorder, visibility days check additional
|
||||
future demand by the specified number of days.
|
||||
|
||||
This feature helps consolidate orders by grouping immediate and near-future needs, reducing
|
||||
transport costs and enabling supplier discounts for larger orders.
|
||||
|
||||
To set visibility days to incorporate orders for a specified number of days in the future, navigate
|
||||
to :menuselection:`Inventory app --> Operations --> Replenishment`, or by clicking the *Reordering
|
||||
Rules* smart button from the product form.
|
||||
|
||||
Next, enable the :guilabel:`Visibility Days` field by clicking the :icon:`oi-settings-adjust`
|
||||
:guilabel:`(adjust)` icon to the far right and choosing the feature from the drop-down menu. Then,
|
||||
enter the desired visibility days.
|
||||
|
||||
.. important::
|
||||
The forecasted date is never pushed forward or extended; Odoo only checks the extra visibility
|
||||
days if the stock falls below the minimum threshold on the forecasted date.
|
||||
|
||||
Example where visibility days is triggered
|
||||
------------------------------------------
|
||||
|
||||
A product shipped from Asia has a combined vendor lead time of 30 days and a shipping cost of $100
|
||||
(including :doc:`landed costs
|
||||
<../../product_management/inventory_valuation/integrating_landed_costs>` and tariffs).
|
||||
|
||||
- November 4: Current date. The forecasted date is December 4 (30 days later).
|
||||
- |SO| 1: Requires the product by Dec 4. Odoo places the order today, costing $100.
|
||||
- |SO| 2: Requires the product by Dec 19. Normally, Odoo would order on Nov 19, costing an
|
||||
additional $100.
|
||||
- |SO| 3: Requires the product by Dec 25. Normally, Odoo would order on Nov 25, costing another
|
||||
$100.
|
||||
|
||||
Ordering separately for these sales orders totals $300 in shipping costs.
|
||||
|
||||
.. image:: reordering_rules/forecasted-date.png
|
||||
:alt: Show forecasted date visualization.
|
||||
|
||||
Setting :guilabel:`Visibility Days` to `20.0` allows Odoo to "look ahead" 20 days from December 4
|
||||
(|SO| 1's forecasted date) to December 24.
|
||||
|
||||
- It groups |SO| 2's order with |SO| 1, reducing shipping costs by consolidating orders.
|
||||
- |SO| 3, which is due on Dec 25, is one day late and is not grouped with the other two orders.
|
||||
|
||||
.. image:: reordering_rules/visibility-days.png
|
||||
:alt: Visibility days visualization.
|
||||
|
||||
Counterexample where visibility days is not triggered
|
||||
-----------------------------------------------------
|
||||
|
||||
Considering the example above, if |SO| 1 does not exist, then:
|
||||
|
||||
- **November 4**: Current date. The forecasted date is December 4 (30 days later).
|
||||
- **November 5**: The forecasted date shifts to December 5.
|
||||
- |SO| 2: Requires the product by December 19. Odoo will only trigger the order on November 19,
|
||||
meaning the user will not see a replenishment notification until then.
|
||||
|
||||
This shows that visibility days complement just-in-time logic by optimizing it to balance
|
||||
replenishment costs more effectively.
|
||||
|
||||
.. image:: reordering_rules/counterexample.png
|
||||
:alt: Example where the visibility days does not trigger.
|
||||
|
||||
|
After Width: | Height: | Size: 10 KiB |
|
Before Width: | Height: | Size: 16 KiB |