[IMP] inventory: CRL - replenishment & visibility days
closes odoo/documentation#11966
X-original-commit: 26f226c51b
Signed-off-by: Felicia Kuan (feku) <feku@odoo.com>
Co-authored-by: Sam Lieber (sali) <36018073+samueljlieber@users.noreply.github.com>
Co-authored-by: Liz Bender <92882399+benderliz@users.noreply.github.com>
This commit is contained in:
Felicious
parent
7e375cfd54
commit
75f0258d19
@ -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/workflows/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,158 +91,28 @@ 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/workflows/use_mps`
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
replenishment/mto
|
||||
replenishment/reordering_rules
|
||||
replenishment/report
|
||||
replenishment/lead_times
|
||||
replenishment/resupply_warehouses
|
||||
|
||||
@ -2,14 +2,15 @@
|
||||
Lead times
|
||||
==========
|
||||
|
||||
.. |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)`
|
||||
.. |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
|
||||
===============
|
||||
@ -18,52 +19,50 @@ Different lead times for different operations can impact various stages of the o
|
||||
process. Here's a summary of the types of lead times in Odoo:
|
||||
|
||||
.. image:: lead_times/all-lead-times.png
|
||||
:align: center
|
||||
:alt: Show graphic of all lead times working together.
|
||||
|
||||
- :ref:`Customer lead time <inventory/shipping_receiving/customer-lt>`: default time frame for
|
||||
- :ref:`Customer lead time <inventory/warehouses_storage/customer-lt>`: default time frame for
|
||||
fulfilling customer orders. The customer lead time is the number of days from the date the sales
|
||||
order (SO) is confirmed to the date the products are shipped from the warehouse. This is also
|
||||
known as *delivery lead time*.
|
||||
|
||||
- :ref:`Sales security lead time <inventory/shipping_receiving/sales-security-lt>`: moves the
|
||||
- :ref:`Sales security lead time <inventory/warehouses_storage/sales-security-lt>`: moves the
|
||||
*scheduled delivery date* forward by a specified number of days. This serves as a buffer to allow
|
||||
ample time to prepare the outgoing shipment earlier, considering the possibility of delays in the
|
||||
fulfillment process.
|
||||
|
||||
- :ref:`Purchase lead time <inventory/shipping_receiving/purchase-lt>`: number of days from the
|
||||
- :ref:`Purchase lead time <inventory/warehouses_storage/purchase-lt>`: number of days from the
|
||||
confirmation of a purchase order (PO) to the receipt of products. It provides insight on the time
|
||||
it takes for products to arrive at the warehouse, facilitating effective scheduling and planning
|
||||
of supplier deliveries.
|
||||
|
||||
- :ref:`Purchase security lead time <inventory/shipping_receiving/purchase-security-lt>`: advances
|
||||
- :ref:`Purchase security lead time <inventory/warehouses_storage/purchase-security-lt>`: advances
|
||||
the order deadline on a :abbr:`PO (Purchase Order)` by a specified number of days. This proactive
|
||||
approach of placing orders earlier mitigates the risk of vendor or shipping delays. Thus, for
|
||||
products that 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 <inventory/shipping_receiving/days-to-purchase>`: days needed for the
|
||||
- :ref:`Days to Purchase <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/shipping_receiving/manuf-lt>`: number of days needed to
|
||||
- :ref:`Manufacturing lead time <inventory/warehouses_storage/manuf-lt>`: 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
|
||||
finished good.
|
||||
|
||||
- :ref:`Days to prepare manufacturing order
|
||||
<inventory/shipping_receiving/prepare-manufacturing-order>`: number of days needed to replenish
|
||||
<inventory/warehouses_storage/prepare-manufacturing-order>`: number of days needed to replenish
|
||||
components, or manufacture sub-assemblies of the product. Either set one directly on the bill of
|
||||
materials (BoM), or click *Compute* to sum up purchase and manufacturing lead times of components
|
||||
in the |BoM|.
|
||||
|
||||
- :ref:`Manufacturing security lead time <inventory/shipping_receiving/manuf-security-lt>`: moves
|
||||
the scheduled date of the :abbr:`MO (Manufacturing Order)` forward by a specified number of days.
|
||||
When used in conjunction with :ref:`replenish to order
|
||||
<inventory/management/products/strategies>`, the security lead time makes the need appear earlier
|
||||
on the replenishment report.
|
||||
- :ref:`Manufacturing security lead time <inventory/warehouses_storage/manuf-security-lt>`: moves
|
||||
the scheduled date of the |MO| forward by a specified number of days. When used in conjunction
|
||||
with :ref:`replenish to order <inventory/management/products/strategies>`, the security lead time
|
||||
makes the need appear earlier on the replenishment report.
|
||||
|
||||
.. _inventory/shipping_receiving/customer-lt:
|
||||
.. _inventory/warehouses_storage/customer-lt:
|
||||
|
||||
Sales lead times
|
||||
================
|
||||
@ -81,7 +80,6 @@ not be feasible to fulfill the order by that time, which would impact other ware
|
||||
1 day. Based on the lead time inputs, Odoo suggests a delivery date in 15 days, on July 26th.
|
||||
|
||||
.. image:: lead_times/scheduled-date.png
|
||||
:align: center
|
||||
:alt: Set *Delivery Date* in a sales order. Enables delivery lead times feature.
|
||||
|
||||
The following sections demonstrate how to automatically compute expected delivery dates.
|
||||
@ -100,10 +98,9 @@ in the number of calendar days required to fulfill the delivery order from start
|
||||
Time` field.
|
||||
|
||||
.. image:: lead_times/customer.png
|
||||
:align: center
|
||||
:alt: Set *Customer Lead Time* on the product form.
|
||||
|
||||
.. _inventory/shipping_receiving/sales-security-lt:
|
||||
.. _inventory/warehouses_storage/sales-security-lt:
|
||||
|
||||
Sales security lead time
|
||||
------------------------
|
||||
@ -124,7 +121,6 @@ team to prepare for outgoing shipments earlier than the scheduled date.
|
||||
the new scheduled date for the delivery order would be April 5th.
|
||||
|
||||
.. image:: lead_times/sales-security.png
|
||||
:align: center
|
||||
:alt: View of the security lead time for sales configuration from the sales settings.
|
||||
|
||||
Deliver several products
|
||||
@ -143,7 +139,6 @@ and set the :guilabel:`Shipping Policy` to:
|
||||
date to the longest lead time among the products in the order.
|
||||
|
||||
.. image:: lead_times/shipping-policy.png
|
||||
:align: center
|
||||
:alt: Show *Shipping Policy* field in the *Other Info* tab of a quotation.
|
||||
|
||||
.. example::
|
||||
@ -154,7 +149,7 @@ and set the :guilabel:`Shipping Policy` to:
|
||||
delivery date is 5 days from today: April 7th. On the other hand, selecting :guilabel:`When all
|
||||
products are ready` configures the scheduled date to be 8 days from today: April 10th.
|
||||
|
||||
.. _inventory/shipping_receiving/purchase-lt:
|
||||
.. _inventory/warehouses_storage/purchase-lt:
|
||||
|
||||
Purchase lead times
|
||||
===================
|
||||
@ -171,11 +166,10 @@ This deadline is the date by which the order should be confirmed, in order to en
|
||||
by the expected receipt date.
|
||||
|
||||
.. image:: lead_times/vendor-lead-times.png
|
||||
:align: center
|
||||
:alt: Visualization of PO deadline and receipt date used with vendor lead times.
|
||||
|
||||
.. seealso::
|
||||
:ref:`PO scheduling with reordering rules <inventory/management/reordering_rules>`
|
||||
:doc:`PO scheduling with reordering rules <reordering_rules>`
|
||||
|
||||
Vendor lead time
|
||||
----------------
|
||||
@ -197,7 +191,6 @@ pricelist, click the :guilabel:`Add a line` button to add vendor details, such a
|
||||
vendor is set to `10 days.`
|
||||
|
||||
.. image:: lead_times/set-vendor.png
|
||||
:align: center
|
||||
:alt: Add delivery lead times to vendor pricelist on a product.
|
||||
|
||||
By setting the vendor lead time, the expected arrival date of the item is automatically determined
|
||||
@ -212,14 +205,12 @@ timeframe.
|
||||
from the :guilabel:`Receipt` smart button, located on the :guilabel:`PO (Purchase Order)`.
|
||||
|
||||
.. image:: lead_times/receipt-date.png
|
||||
:align: center
|
||||
:alt: Show expected *Receipt Date* of the product from the vendor.
|
||||
|
||||
.. image:: lead_times/scheduled-date-receipt.png
|
||||
:align: center
|
||||
:alt: Show expected *Scheduled Date* of arrival of the product from the vendor.
|
||||
|
||||
.. _inventory/shipping_receiving/purchase-security-lt:
|
||||
.. _inventory/warehouses_storage/purchase-security-lt:
|
||||
|
||||
Purchase security lead time
|
||||
---------------------------
|
||||
@ -240,24 +231,18 @@ set to account for potential delays in supplier deliveries. Then, click :guilabe
|
||||
the receipt would be April 8th.
|
||||
|
||||
.. image:: lead_times/vendor-security.png
|
||||
:align: center
|
||||
:alt: Set security lead time for purchase from the Inventory > Configuration > Settings.
|
||||
|
||||
.. _inventory/shipping_receiving/days-to-purchase:
|
||||
.. _inventory/warehouses_storage/days-to-purchase:
|
||||
|
||||
Days to purchase
|
||||
----------------
|
||||
Days to purchase lead time
|
||||
--------------------------
|
||||
|
||||
To set up the *days to purchase* lead time, 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.
|
||||
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.
|
||||
|
||||
.. image:: lead_times/days-to-purchase.png
|
||||
:align: center
|
||||
:alt: Show "Days to Purchase" configuration in the Settings page.
|
||||
|
||||
.. _inventory/shipping_receiving/manuf-lt:
|
||||
.. _inventory/warehouses_storage/manuf-lt:
|
||||
|
||||
Manufacturing lead times
|
||||
========================
|
||||
@ -265,12 +250,11 @@ Manufacturing lead times
|
||||
Lead times can help simplify the procurement process for consumable materials and components used in
|
||||
manufactured products with bills of materials (BoMs).
|
||||
|
||||
The :abbr:`MO (Manufacturing Order)` deadline, which is the deadline to begin the manufacturing
|
||||
process to complete the product by the scheduled delivery date, can be determined by configuring the
|
||||
manufacturing lead times and manufacturing security lead times.
|
||||
The |MO| deadline, which is the deadline to begin the manufacturing process to complete the product
|
||||
by the scheduled delivery date, can be determined by configuring the manufacturing lead times and
|
||||
manufacturing security lead times.
|
||||
|
||||
.. image:: lead_times/manuf-lead-times.png
|
||||
:align: center
|
||||
:alt: Visualization of the determination of planned MO date manufacturing lead times.
|
||||
|
||||
Manufacturing lead time
|
||||
@ -285,7 +269,6 @@ On the |BoM| form, click the :guilabel:`Miscellaneous` tab. Change the value (in
|
||||
:guilabel:`Manuf. Lead Time` field to specify the calendar days needed to manufacture the product.
|
||||
|
||||
.. image:: lead_times/set-manufacturing.png
|
||||
:align: center
|
||||
:alt: Manuf. Lead Time value specified on a product's Bill of Material form.
|
||||
|
||||
.. note::
|
||||
@ -295,12 +278,11 @@ On the |BoM| form, click the :guilabel:`Miscellaneous` tab. Change the value (in
|
||||
If the |BoM| product is subcontracted, the :guilabel:`Manuf. Lead Time` can be used to determine
|
||||
the date at which components should be sent to the subcontractor.
|
||||
|
||||
Establish a :abbr:`MO (Manufacturing Order)` deadline, based on the *expected delivery date*,
|
||||
indicated in the :guilabel:`Scheduled Date` field of the :abbr:`DO (Delivery Order)`.
|
||||
Establish a |MO| deadline, based on the *expected delivery date*, indicated in the
|
||||
:guilabel:`Scheduled Date` field of the :abbr:`DO (Delivery Order)`.
|
||||
|
||||
The :abbr:`MO (Manufacturing Order)` deadline, which is the :guilabel:`Scheduled Date` field on the
|
||||
:abbr:`MO (Manufacturing Order)`, is calculated as the *expected delivery date* subtracted by the
|
||||
manufacturing lead time.
|
||||
The |MO| deadline, which is the :guilabel:`Scheduled Date` field on the |MO|, is calculated as the
|
||||
*expected delivery date* subtracted by the manufacturing lead time.
|
||||
|
||||
This ensures the manufacturing process begins on time, in order to meet the delivery date.
|
||||
|
||||
@ -317,7 +299,7 @@ performed at the work center simultaneously`).
|
||||
product requires 14 days to manufacture. So, the latest date to start the :abbr:`MO
|
||||
(Manufacturing Order)` to meet the commitment date is August 1st.
|
||||
|
||||
.. _inventory/shipping_receiving/prepare-manufacturing-order:
|
||||
.. _inventory/warehouses_storage/prepare-manufacturing-order:
|
||||
|
||||
Days to prepare manufacturing order
|
||||
-----------------------------------
|
||||
@ -343,7 +325,7 @@ manufacture semi-finished products.
|
||||
purchase lead time of four days. The :guilabel:`Days to prepare Manufacturing Order` is four
|
||||
days.
|
||||
|
||||
.. _inventory/shipping_receiving/manuf-security-lt:
|
||||
.. _inventory/warehouses_storage/manuf-security-lt:
|
||||
|
||||
Manufacturing security lead time
|
||||
--------------------------------
|
||||
@ -356,15 +338,13 @@ Next, enter the desired number of calendar days. By configuring the security lea
|
||||
set to account for potential delays in the manufacturing process. Then, click :guilabel:`Save`.
|
||||
|
||||
.. image:: lead_times/manuf-security.png
|
||||
:align: center
|
||||
:alt: View of the security lead time for manufacturing from the manufacturing app settings.
|
||||
|
||||
.. example::
|
||||
A product has a scheduled shipment date on the :abbr:`DO (Delivery Order)` set for August 15th.
|
||||
The manufacturing lead time is 7 days, and manufacturing security lead time is 3 days. So, the
|
||||
:guilabel:`Scheduled Date` on the :abbr:`MO (Manufacturing Order)` reflects the latest date to
|
||||
begin the manufacturing order. In this example, the planned date on the :abbr:`MO (Manufacturing
|
||||
Order)` is August 5th.
|
||||
:guilabel:`Scheduled Date` on the |MO| reflects the latest date to begin the manufacturing order.
|
||||
In this example, the planned date on the |MO| is August 5th.
|
||||
|
||||
Global example
|
||||
==============
|
||||
@ -383,7 +363,6 @@ date from the warehouse is on September 20th. Odoo uses lead times and automated
|
||||
schedule the necessary operations, based on the outgoing shipment delivery date, September 20th:
|
||||
|
||||
.. image:: lead_times/global-example.png
|
||||
:align: center
|
||||
:alt: Show timeline of how lead times work together to schedule warehouse operations.
|
||||
|
||||
- **September 1st**: Sales order created, confirmed by salesperson.
|
||||
|
||||
@ -2,64 +2,106 @@
|
||||
Reordering rules
|
||||
================
|
||||
|
||||
.. _inventory/management/reordering_rules:
|
||||
.. |SO| replace:: :abbr:`SO (sales order)`
|
||||
.. |PO| replace:: :abbr:`PO (purchase order)`
|
||||
.. |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)`
|
||||
.. |PO| replace:: :abbr:`PO (Purchase Order)`
|
||||
.. |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)`
|
||||
.. |adjust| replace:: :icon:`oi-settings-adjust` :guilabel:`(adjust)` icon
|
||||
|
||||
*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 the
|
||||
:guilabel:`Track Inventory` checkbox is ticked. This is necessary for Odoo to track the product's
|
||||
stock levels and 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:`Replenishment method <inventory/warehouses_storage/set-method>`
|
||||
#. :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:`Goods`, and make sure the :guilabel:`Track Inventory` checkbox is ticked. This is
|
||||
necessary for Odoo to track the product's stock levels and trigger reordering rules.
|
||||
|
||||
.. image:: reordering_rules/product-type.png
|
||||
:alt: Set the Product Type as Storable.
|
||||
:alt: Product Type and Track Inventory configurations.
|
||||
|
||||
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.
|
||||
.. _inventory/warehouses_storage/set-method:
|
||||
|
||||
.. image:: reordering_rules/select-routes.png
|
||||
:alt: Select one or more routes on the Inventory tab.
|
||||
Replenishment method
|
||||
--------------------
|
||||
|
||||
If the product is reordered using the :guilabel:`Buy` route, confirm that the :guilabel:`Can be
|
||||
Purchased` checkbox is enabled under the product name. This makes the :guilabel:`Purchase` tab
|
||||
appear. Click on the :guilabel:`Purchase` tab, and specify at least one vendor, and the price that
|
||||
they sell the product for, so that Odoo knows which company the product should be purchased from.
|
||||
Next, configure the replenishment method (e.g., buy or manufacture) by going to the
|
||||
:guilabel:`Inventory` tab and select one or more routes from the :guilabel:`Routes` section.
|
||||
|
||||
.. image:: reordering_rules/specify-vendor.png
|
||||
:alt: Specify a vendor and price on the Purchase tab.
|
||||
If the product is purchased, :ref:`install <general/install>` the **Purchase** app, and confirm that
|
||||
the :guilabel:`Purchase` checkbox is enabled under the product name. In the :guilabel:`Purchase`
|
||||
tab, add at least one vendor to the :doc:`vendor pricelist <../../../purchase/products/pricelist>`.
|
||||
Odoo uses the vendor at the top of the list to generate |RFQs| when reordering rules are triggered.
|
||||
|
||||
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)`.
|
||||
In the :guilabel:`Inventory` tab's :guilabel:`Routes` field, tick the :guilabel:`Buy` checkbox.
|
||||
|
||||
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)`.
|
||||
.. seealso::
|
||||
- :doc:`Buy route <../../../purchase/manage_deals/rfq>`
|
||||
- :doc:`Vendor pricelist <../../../purchase/products/pricelist>`
|
||||
|
||||
.. image:: reordering_rules/bom-smart-button.png
|
||||
:alt: The Bill of Materials smart button on a product form.
|
||||
If the product is manufactured, :ref:`install <general/install>` the **Manufacturing** app, and in
|
||||
the :guilabel:`Inventory` tab's :guilabel:`Routes` field, tick the :guilabel:`Manufacture` checkbox.
|
||||
|
||||
Next, ensure at least one :doc:`bill of materials
|
||||
<../../../manufacturing/basic_setup/bill_configuration>` (BoM) is displayed in the :guilabel:`Bill
|
||||
of Materials` smart button at the top of the product form. This is necessary because Odoo only
|
||||
creates manufacturing orders for products with a |BoM|.
|
||||
|
||||
If a |BoM| does not already exist for the product, click the :guilabel:`Bill of Materials` smart
|
||||
button, then click :guilabel:`New` to configure a new |BoM|.
|
||||
|
||||
.. seealso::
|
||||
- :doc:`Manufacture route <../../../manufacturing/basic_setup/bill_configuration>`
|
||||
|
||||
.. _inventory/warehouses_storage/rr-fields:
|
||||
|
||||
Create new reordering rules
|
||||
===========================
|
||||
---------------------------
|
||||
|
||||
To create a new reordering rule, navigate to :menuselection:`Inventory app --> Operations -->
|
||||
Replenishment`, then click :guilabel:`New`, and fill out the following fields for the new reordering
|
||||
@ -71,36 +113,36 @@ rule line item:
|
||||
triggered. When forecasted stock falls below this number, a replenishment order for the product is
|
||||
created.
|
||||
- :guilabel:`Max`: The maximum quantity at which the stock is replenished.
|
||||
- :guilabel:`To Order`: The number of units, according to the *UoM*, that should be replenished for
|
||||
this reordering rule (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:`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
|
||||
.. figure:: reordering_rules/reordering-rule-form.png
|
||||
:alt: The form for creating a new reordering rule.
|
||||
|
||||
.. note::
|
||||
Two other fields are automatically populated: :guilabel:`On Hand` (the number of units currently
|
||||
available in inventory) and :guilabel:`Forecast` (the number of units expected to be available in
|
||||
inventory after all orders are taken into account). These numbers will only change when an
|
||||
:doc:`inventory adjustment <../inventory_management/count_products>` is made.
|
||||
|
||||
Also, additional fields can be accessed by clicking the :icon:`oi-settings-adjust`
|
||||
:guilabel:`(additional options slider icon)`. For example, :guilabel:`Multiple Quantity`
|
||||
specifies if the product should be replenished in batches of a certain quantity (e.g., a product
|
||||
could be replenished in batches of 20).
|
||||
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`, and select a product. Then, click the
|
||||
:guilabel:`Reordering Rules` smart button, and click :guilabel:`New` to 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:`Route <inventory/product_management/route>`
|
||||
|
||||
.. note::
|
||||
The fields above are not available by default, and must be enabled by selecting the |adjust| in
|
||||
the far-right corner and selecting the desired column from the drop-down menu.
|
||||
|
||||
.. _inventory/warehouses_storage/zero-zero:
|
||||
|
||||
@ -169,40 +211,43 @@ quantity of the product to fall below the :guilabel:`Min Quantity` of `0.00`, th
|
||||
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*.
|
||||
|
||||
.. seealso::
|
||||
:doc:`../replenishment`
|
||||
|
||||
.. tip::
|
||||
The 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
|
||||
: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`. Then, click the |adjust|, 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, configured by setting the reordering rule's :guilabel:`Trigger` field to
|
||||
:guilabel:`Auto`, generates 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.
|
||||
@ -222,112 +267,47 @@ Automatic reordering rules, configured by setting the reordering rule's :guilabe
|
||||
.. image:: reordering_rules/auto.png
|
||||
: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`, lists 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, but 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.
|
||||
lead times. It displays needs **only** when it is time to reorder items, thanks to the :guilabel:`To
|
||||
Reorder` filter.
|
||||
|
||||
.. 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.
|
||||
|
||||
When a product appears on the replenishment dashboard, clicking the :guilabel:`Order Once` button
|
||||
When a product appears on the replenishment dashboard, clicking the :guilabel:`Order` button
|
||||
generates the purchase or manufacturing order with the specified amounts :guilabel:`To Order`.
|
||||
|
||||
.. image:: reordering_rules/manual.png
|
||||
:alt: Click the Order Once button on the replenishment dashboard to replenish stock.
|
||||
:alt: Click the Order 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 20th, and the *delivery date* on a sales order (in the
|
||||
:guilabel:`Other Info` tab) is March 3rd — twelve days from the current date.
|
||||
|
||||
The :ref:`vendor lead time <inventory/shipping_receiving/purchase-lt>` is four days, and the
|
||||
:ref:`purchase security lead time <inventory/shipping_receiving/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 27th.
|
||||
|
||||
.. image:: reordering_rules/need-dates.png
|
||||
:alt: Graphic representing when the need appears on the replenishment dashboard: Feb 27th.
|
||||
|
||||
To see the product on the replenishment dashboard for the current date, February 20, set the
|
||||
:guilabel:`Visibility Days` to `7.00`.
|
||||
|
||||
To determine the amount 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 20th, and the need for the product
|
||||
appears on February 27th.
|
||||
|
||||
(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
|
||||
:alt: Show the replenishment dashboard with the correct and incorrect visibility days set.
|
||||
|
||||
.. _inventory/product_management/route:
|
||||
.. _inventory/warehouses_storage/route:
|
||||
|
||||
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 to :menuselection:`Inventory app --> Configuration --> Reordering Rules`.
|
||||
Odoo also enables users to set a preferred route for a product's reordering rule. This is the
|
||||
replenishment method (e.g., buying or manufacturing) that the rule defaults to, if multiple are
|
||||
available.
|
||||
|
||||
By default, the :guilabel:`Route` column is hidden on the :guilabel:`Reordering Rules` page.
|
||||
To specify a preferred route, begin by navigating to :menuselection:`Inventory app --> Operations
|
||||
--> Replenishment`.
|
||||
|
||||
Reveal the :guilabel:`Route` column by selecting the :guilabel:`(slider)` icon to the far-right of
|
||||
the column titles, and checking the :guilabel:`Route` option from the drop-down menu that appears.
|
||||
By default, the :guilabel:`Route` column is hidden. To reveal it, select the |adjust| to the
|
||||
far-right of the column titles, and ticking :guilabel:`Route` from the drop-down menu that appears.
|
||||
|
||||
Click inside of the column on the row of a reordering rule, and a drop-down menu shows all available
|
||||
routes for that rule. Select one to set it as the preferred route.
|
||||
@ -337,5 +317,243 @@ routes for that rule. Select one to set it as the preferred route.
|
||||
|
||||
.. 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.
|
||||
rule, the product is reordered using the *Buy* route, then *Manufacture*.
|
||||
|
||||
Advanced uses
|
||||
-------------
|
||||
|
||||
Pairing :guilabel:`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:`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:`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 :doc:`MTO route <mto>`.
|
||||
|
||||
.. 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 *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:`Route` to :guilabel:`Buy` to generate an |RFQ|.
|
||||
#. Click the :guilabel:`Order` 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/warehouses_storage/purchase-lt>` and
|
||||
:ref:`purchasing delays <inventory/warehouses_storage/purchase-security-lt>` for purchases, or
|
||||
:ref:`manufacturing lead times <inventory/warehouses_storage/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:: report/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:: report/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 |adjust| 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/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:: report/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:: report/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.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 15 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.2 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 21 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 31 KiB After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 20 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
@ -0,0 +1,52 @@
|
||||
====================
|
||||
Replenishment report
|
||||
====================
|
||||
|
||||
.. |SO| replace:: :abbr:`SO (Sales Order)`
|
||||
.. |SOs| replace:: :abbr:`SOs (Sales Orders)`
|
||||
|
||||
The *replenishment report* is an interactive dashboard that uses :doc:`manual reordering rules
|
||||
<reordering_rules>`, lead times, and upcoming demands to forecast quantities of products that need
|
||||
restocking.
|
||||
|
||||
Reordering rules used on this dashboard are normal reordering rules, but the user benefits from a
|
||||
monitoring menu with extra options to manage suggestions for replenishment.
|
||||
|
||||
This enables users to anticipate future needs, keep less products on hand without the risk of
|
||||
running out, plan and consolidate orders.
|
||||
|
||||
To access the replenishment report, go to :menuselection:`Inventory app --> Operations -->
|
||||
Replenishment.`
|
||||
|
||||
The fields and features unique to the replenishment dashboard are displayed below. For definitions
|
||||
of the other fields, go to the :ref:`Create reordering rules section
|
||||
<inventory/warehouses_storage/rr-fields>`.
|
||||
|
||||
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 :icon:`fa-truck`
|
||||
:guilabel:`Order Once`.
|
||||
|
||||
Clicking :icon:`fa-bell-slash` :guilabel:`Snooze` temporarily deactivates the reordering rule for
|
||||
the set period, hiding the entry from the replenishment dashboard, when it is supposed to appear.
|
||||
|
||||
.. tip::
|
||||
Defining a :guilabel:`Vendor` allows filtering or grouping demands by the vendor. This simplifies
|
||||
the process of identifying products to order and can reduce shipment costs.
|
||||
|
||||
.. image:: report/replenishment-dashboard.png
|
||||
:alt: Replenishment report that displays recommended quantities to order.
|
||||
|
||||
.. note::
|
||||
Automatic reordering rules appear on this menu, too but are hidden by default.
|
||||
|
||||
Replenishment information
|
||||
=========================
|
||||
|
||||
In each line of the replenishment report, clicking the :icon:`fa-info-circle` :guilabel:`(info)`
|
||||
icon opens the :guilabel:`Replenishment Information` pop-up window, which displays the *lead times*
|
||||
and *forecasted date*.
|
||||
|
||||
For detailed information on how to use this feature for replenishment, go to the :ref:`Just in time
|
||||
logic <inventory/warehouses_storage/just-in-time>` section.
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 26 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.2 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
@ -144,7 +144,7 @@ Below is a list of commonly-used fields when importing vendor pricelists:
|
||||
* - Quantity
|
||||
- The minimum quantity required to receive the product at the specified price.
|
||||
- :guilabel:`Quantity` field in the vendor pricelist. (If not visible, enable it by clicking
|
||||
the :icon:`oi-settings-adjust` :guilabel:`(settings)` icon, and tick the :guilabel:`Quantity`
|
||||
the :icon:`oi-settings-adjust` :guilabel:`(adjust)` icon, and tick the :guilabel:`Quantity`
|
||||
checkbox)
|
||||
- `min_qty`
|
||||
* - Unit Price
|
||||
@ -152,8 +152,8 @@ Below is a list of commonly-used fields when importing vendor pricelists:
|
||||
- :guilabel:`Price` field in the vendor pricelist.
|
||||
- `price`
|
||||
* - Delivery Lead Time
|
||||
- :ref:`Number of days <inventory/shipping_receiving/purchase-lt>` before receiving the
|
||||
product after confirming a purchase order.
|
||||
- :ref:`Number of days <inventory/warehouses_storage/purchase-lt>` before receiving the product
|
||||
after confirming a purchase order.
|
||||
- :guilabel:`Delivery Lead Time` field on the vendor pricelist.
|
||||
- `delay`
|
||||
* - Sequence
|
||||
|
||||
Loading…
Reference in New Issue
Block a user