[IMP] inventory: thd batch updates
closes odoo/documentation#2855
X-original-commit: ac3ec17266
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
@ -11,6 +11,7 @@ Warehouse Management
|
||||
management/products
|
||||
management/warehouses
|
||||
management/replenishment_strategies
|
||||
management/inventory_adjustments
|
||||
management/delivery
|
||||
management/incoming
|
||||
management/misc
|
||||
|
@ -0,0 +1,11 @@
|
||||
:nosearch:
|
||||
|
||||
=====================
|
||||
Inventory adjustments
|
||||
=====================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
||||
inventory_adjustments/count_products
|
||||
inventory_adjustments/cycle_counts
|
@ -0,0 +1,100 @@
|
||||
=====================
|
||||
Inventory adjustments
|
||||
=====================
|
||||
|
||||
In any warehouse management system, the recorded inventory counts in the database might not always
|
||||
match the actual inventory counts in the warehouse. The discrepancy between the two counts can be
|
||||
due to theft, damages, human errors, or other factors. As such, inventory adjustments must be made
|
||||
to reconcile the differences, and ensure that the recorded counts in the database match the actual
|
||||
counts in the warehouse.
|
||||
|
||||
In Odoo, inventory adjustments can be accessed through :menuselection:`Inventory --> Operations -->
|
||||
Inventory Adjustments`.
|
||||
|
||||
The :guilabel:`Inventory Adjustments` page shows all products that are currently in stock. Each
|
||||
line contains the following information:
|
||||
|
||||
- :guilabel:`Product`
|
||||
- :guilabel:`Lot/Serial Number`
|
||||
- :guilabel:`On Hand Quantity`
|
||||
|
||||
Add a new line
|
||||
==============
|
||||
|
||||
To add an inventory adjustment line, click :guilabel:`Create` and fill in the :guilabel:`Product`
|
||||
and :guilabel:`Counted Quantity` fields. Then click :guilabel:`Save`.
|
||||
|
||||
At this stage, the count is recorded but not yet *applied*. Meaning the quantity on hand is not yet
|
||||
updated to match the new :guilabel:`Counted Quantity`.
|
||||
|
||||
To apply the new :guilabel:`Counted Quantity`, click :guilabel:`Apply` on the line or the
|
||||
:guilabel:`Apply All` button on the top of the page. If :guilabel:`Apply All` is clicked, a
|
||||
reference or reason can be entered before clicking :guilabel:`Apply`.
|
||||
|
||||
.. image:: count_products/apply-inventory-adjustment.png
|
||||
:scale: 60%
|
||||
:align: center
|
||||
:alt: Apply all option applies the inventory adjustment once a reason is specified.
|
||||
|
||||
Count products
|
||||
==============
|
||||
|
||||
Counting products is a recurring activity in a warehouse. Once a count is complete, go to
|
||||
:menuselection:`Inventory --> Operations --> Inventory Adjustments` to update the
|
||||
:guilabel:`Counted Quantity` column for each product line.
|
||||
|
||||
If a count matches the :guilabel:`On Hand Quantity` recorded in the database, click on
|
||||
:guilabel:`Set`, which will copy the value in the :guilabel:`On Hand Quantity` field and paste it
|
||||
in the :guilabel:`Counted Quantity` field. A move with `0.00` :guilabel:`Quantity Done` will be
|
||||
recorded in the product's inventory adjustment history.
|
||||
|
||||
If a count does *not* match the :guilabel:`On Hand Quantity` recorded in the database, record the
|
||||
count in the :guilabel:`Counted Quantity` field. When :guilabel:`Apply` is clicked, a move with the
|
||||
difference between the :guilabel:`On Hand Quantity` and :guilabel:`Counted Quantity` will be
|
||||
recorded in the product's inventory adjustment history.
|
||||
|
||||
.. image:: count_products/history-inventory-adjustments.png
|
||||
:align: center
|
||||
:alt: Inventory Adjustments History dashboard detailing a list of prior product moves.
|
||||
|
||||
.. note::
|
||||
Sometimes a count occurs, but can not be applied in the database right away. In the time between
|
||||
the actual count and applying the inventory adjustment, product moves can occur. In that case,
|
||||
the :guilabel:`On Hand Quantity` in the database can change and will not be consistent with the
|
||||
counted quantity. As an extra caution measure, Odoo will ask for confirmation before applying
|
||||
the inventory adjustment.
|
||||
|
||||
Plan counts
|
||||
===========
|
||||
|
||||
Each inventory adjustment line contains the following information:
|
||||
|
||||
- :guilabel:`Scheduled Date`: the date at which a count should be made.
|
||||
- :guilabel:`User`: the person in charge of the count.
|
||||
- :guilabel:`Accounting Date`: the date at which the adjustments will be accounted. The column is
|
||||
hidden by default, but can be made visible by opening the column options icon.
|
||||
|
||||
.. important::
|
||||
In the Barcode app, users can only view counts assigned to them that are scheduled for today or
|
||||
earlier.
|
||||
|
||||
To plan big counts, select the desired product lines on the :guilabel:`Inventory Adjustments` page.
|
||||
Then, click :guilabel:`Request a Count` and fill in the following information:
|
||||
|
||||
- :guilabel:`Inventory Date`: the planned date of the count.
|
||||
- :guilabel:`User`: the user responsible for the count.
|
||||
- :guilabel:`Accounting Date`: the date at which the inventory adjustment will be accounted.
|
||||
- :guilabel:`Count`: to leave the :guilabel:`On Hand Quantity` of each product line blank, select
|
||||
:guilabel:`Leave Empty`. To prefill the :guilabel:`On Hand Quantity` of each product line with
|
||||
the current value recorded in the database, select :guilabel:`Set Current Value`.
|
||||
|
||||
Finally, click :guilabel:`Confirm` to request the count.
|
||||
|
||||
By default, after an inventory adjustment is applied, the scheduled date for the next count is the
|
||||
31st of December of the current year. To modify the default scheduled date, go to
|
||||
:menuselection:`Inventory --> Configuration --> Settings --> Operations` and change the date in the
|
||||
:guilabel:`Annual Inventory Day and Month` setting.
|
||||
|
||||
.. image:: count_products/annual-inventory.png
|
||||
:align: center
|
||||
:alt: Adjust the next inventory count date with the Annual Inventory Day and Month setting.
|
After Width: | Height: | Size: 27 KiB |
After Width: | Height: | Size: 19 KiB |
After Width: | Height: | Size: 14 KiB |
@ -0,0 +1,41 @@
|
||||
============
|
||||
Cycle counts
|
||||
============
|
||||
|
||||
In most companies, the stock is only counted once a year. That's why by default, after making an
|
||||
inventory adjustment in Odoo, the scheduled date for the next count is set on the 31st of
|
||||
December. However, for some businesses it's crucial to have an accurate inventory count at all
|
||||
times.
|
||||
|
||||
The goal of cycle counts is to keep critical stock levels accurate by counting more often at key
|
||||
locations.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
In Odoo, cycle counts are location-based. The frequency of the counts is defined by the storage
|
||||
location. To activate storage locations, go to :menuselection:`Inventory --> Configuration -->
|
||||
Settings --> Warehouse` and activate the :guilabel:`Storage Locations` setting. Next, click
|
||||
:guilabel:`Save` to apply the setting.
|
||||
|
||||
.. image:: cycle_counts/storage-locations-setting.png
|
||||
:align: center
|
||||
:alt: Enable Storage Locations in Odoo settings.
|
||||
|
||||
Change the inventory frequency
|
||||
==============================
|
||||
|
||||
To change a location's inventory frequency, first, go to the locations by clicking
|
||||
:menuselection:`Inventory --> Configuration --> Locations`.
|
||||
|
||||
Then, click on a location to open the location settings. Next, click on :guilabel:`Edit`. In the
|
||||
:guilabel:`Inventory Frequency (Days)` field, set the number of days. For example, a location that
|
||||
needs an inventory count every 30 days would set the :guilabel:`Inventory Frequency (Days)` value
|
||||
to `30`. Once the value is entered, click :guilabel:`Save` to apply the setting to the location.
|
||||
Now, once an inventory adjustment is applied to this location, the next scheduled count date will
|
||||
be automatically set based on the number of days in the :guilabel:`Inventory Frequency (Days)`
|
||||
setting.
|
||||
|
||||
.. image:: cycle_counts/inventory-frequency.png
|
||||
:align: center
|
||||
:alt: Edit a location to change the inventory frequency.
|
After Width: | Height: | Size: 16 KiB |
After Width: | Height: | Size: 3.4 KiB |
@ -10,3 +10,4 @@ Miscellaneous Operations
|
||||
|
||||
misc/owned_stock
|
||||
misc/batch_transfers
|
||||
misc/wave_transfers
|
||||
|
@ -0,0 +1,68 @@
|
||||
======================
|
||||
Process wave transfers
|
||||
======================
|
||||
|
||||
While a batch transfer is a group of several pickings, a **wave transfer** only contains some parts
|
||||
of different pickings. Both methods are used to pick orders in a warehouse, and depending on the
|
||||
situation, one method may be a better fit than the other.
|
||||
|
||||
To handle orders of a specific product category, or fetch products that are at the same location,
|
||||
wave transfers are the ideal method.
|
||||
|
||||
In Odoo, wave transfers are actually batch transfers with an extra step: transfers are split before
|
||||
being grouped in a batch.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Before a wave transfer can be created, the :guilabel:`Batch Transfers` and :guilabel:`Wave
|
||||
Transfers` options must be activated.
|
||||
|
||||
First, go to :menuselection:`Inventory --> Configuration --> Settings`. In the
|
||||
:guilabel:`Operations` section, enable :guilabel:`Batch Transfers` and :guilabel:`Wave Transfers`.
|
||||
Then, click :guilabel:`Save` to apply the settings.
|
||||
|
||||
.. image:: wave_transfers/wave-transfers-setting.png
|
||||
:align: center
|
||||
:alt: View of Odoo Inventory app settings to enable the wave transfers option.
|
||||
|
||||
Add products to a wave
|
||||
======================
|
||||
|
||||
Now that the settings are activated, start a wave transfer by adding products to a wave.
|
||||
|
||||
Wave transfers can only contain product lines from transfers of the same operation type. To view
|
||||
all the transfers and product lines in a specific operation, first go to the :guilabel:`Inventory`
|
||||
dashboard and locate the desired operation type's card. Then, open the options menu (the three dots
|
||||
icon in the corner of the operation type's card) and click :guilabel:`Operations`.
|
||||
|
||||
.. image:: wave_transfers/list-of-operations.png
|
||||
:align: center
|
||||
:alt: How to get an operation type's list of operations.
|
||||
|
||||
On the operations page, select the product lines you want to add in a new or existing wave. Then,
|
||||
click :guilabel:`Add to Wave`.
|
||||
|
||||
.. image:: wave_transfers/select-lines.png
|
||||
:align: center
|
||||
:alt: Select lines to add to the wave.
|
||||
|
||||
.. tip::
|
||||
Use the :guilabel:`Filters` in the search bar to group lines with the same product, location,
|
||||
carrier, etc...
|
||||
|
||||
After that, a pop-up box appears.
|
||||
|
||||
To add the selected lines to an existing wave transfer, select the :guilabel:`an existing wave
|
||||
transfer` option and select the existing wave transfer from the drop-down menu.
|
||||
|
||||
To create a new wave transfer, select the :guilabel:`a new wave transfer` option. If creating a new
|
||||
wave transfer, an employee can also be set in the optional :guilabel:`Responsible` field. Once the
|
||||
desired options are selected, click :guilabel:`Confirm` to add the product lines to a wave.
|
||||
|
||||
View wave transfers
|
||||
===================
|
||||
|
||||
To view all wave transfers and their statuses, go to :menuselection:`Inventory --> Operations -->
|
||||
Wave Transfers`. Wave transfers can also be viewed in the :guilabel:`Barcode` app by going to
|
||||
:menuselection:`Barcode --> Batch Transfers`.
|
After Width: | Height: | Size: 8.7 KiB |
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 5.6 KiB |
@ -1,76 +1,138 @@
|
||||
==============================================
|
||||
How to select the right replenishment strategy
|
||||
==============================================
|
||||
===============================
|
||||
Select a replenishment strategy
|
||||
===============================
|
||||
|
||||
Minimum Stock rules and Make to Order have similar consequences but
|
||||
different rules. They should be used depending on your manufacturing and
|
||||
delivery strategies.
|
||||
In Odoo, there are two strategies for 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 purchase or manufacturing order. The choice of
|
||||
which strategy to use depends on the business's manufacturing and delivery processes.
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
Minimum stock rule
|
||||
-------------------
|
||||
Replenishment report and reordering rules
|
||||
-----------------------------------------
|
||||
|
||||
Minimum Stock rules are used to ensure that you always have the minimum
|
||||
amount of a product in stock in order to manufacture your products
|
||||
and/or answer to your customer needs. When the stock level of a product
|
||||
reaches its minimum the system will automatically generate a procurement
|
||||
order with the quantity needed to reach the maximum stock level.
|
||||
The replenishment report is a list of all products that have a negative forecast quantity.
|
||||
|
||||
Reordering rules are used to ensure that 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.
|
||||
|
||||
Reordering rules can be created and managed in the replenishment report or from the product form.
|
||||
|
||||
Make to Order
|
||||
-------------
|
||||
|
||||
The Make to Order function will trigger a Purchase Order of the amount
|
||||
of the Sales Order related to the product. The system will **not** check
|
||||
the current stock. This means that a draft purchase order will be
|
||||
generated regardless of the quantity on hand of the product.
|
||||
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*.
|
||||
|
||||
Unlike products replenished using reordering rules, Odoo automatically links the sales order to the
|
||||
purchase order (PO) or manufacturing order (MO) generated by the MTO route. Another difference
|
||||
between reordering rules and MTO is with MTO, Odoo generates a draft :abbr:`PO (Purchase Order)` or
|
||||
:abbr:`MO (Manufacturing Order)` immediately after the sales order is confirmed. With reordering
|
||||
rules, Odoo generates a draft :abbr:`PO (Purchase Order)` or :abbr:`MO (Manufacturing Order)` when
|
||||
the product's forecasted stock falls below the set minimum quantity. In addition, Odoo will
|
||||
automatically add quantities to the :abbr:`PO (Purchase Order)`/:abbr:`MO (Manufacturing Order)` as
|
||||
the forecast changes, as long as the :abbr:`PO (Purchase Order)`/:abbr:`MO (Manufacturing Order)`
|
||||
is not confirmed.
|
||||
|
||||
The MTO route is the best replenishment strategy for products that are customized and should be
|
||||
used for this purpose only.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
Minimum stock rules
|
||||
-------------------
|
||||
Replenishment report and reordering rules
|
||||
-----------------------------------------
|
||||
|
||||
The Minimum Stock Rules configuration is available through your
|
||||
Inventory module. In the Inventory Control menu select "Reordering Rule"
|
||||
in the drop down menu. There, click on "Create" to set minimum and
|
||||
maximum stock values for a given product.
|
||||
To access the replenishment report, go to :menuselection:`Inventory --> Operations -->
|
||||
Replenishment`. By default, the replenishment report shows every product that needs to be manually
|
||||
reordered. If there is no specific rule for a product, Odoo assumes that the :guilabel:`Minimum
|
||||
Quantity` and :guilabel:`Maximum Quantity` stock are both `0.00`.
|
||||
|
||||
.. image:: strategies/strategies01.png
|
||||
:align: center
|
||||
.. image:: strategies/replenishment-report.png
|
||||
:align: center
|
||||
:alt: The replenishment report shows products that need to be reordered manually.
|
||||
|
||||
.. note::
|
||||
Show tooltips for "minimum quantity", "maximum quantity" and "quantity multiple"
|
||||
fields
|
||||
For products that don't have a set reordering rule, Odoo calculates the forecast as sales orders,
|
||||
deliveries, and receipts are confirmed. 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.
|
||||
|
||||
Then, click on your product to access the related product form and, on
|
||||
the "Inventory submenu", do not forget to select a supplier.
|
||||
Before creating a new reordering rule, make sure the product has a vendor or a bill of materials
|
||||
configured on the product form. Also, make sure the :guilabel:`Product Type` is set to `Storable
|
||||
Product` on the product form. By definition, a consumable product does not have its inventory
|
||||
levels tracked, so Odoo can not account for a consumable product in the stock valuation.
|
||||
|
||||
.. image:: strategies/strategies02.png
|
||||
:align: center
|
||||
To create a new reordering rule from the replenishment report, go to :menuselection:`Inventory -->
|
||||
Operations --> Replenishment`, click :guilabel:`Create`, and set the :guilabel:`Product`. If
|
||||
desired, set a :guilabel:`Min Quantity` and a :guilabel:`Max Quantity`. Finally, click
|
||||
:guilabel:`Save`.
|
||||
|
||||
.. tip::
|
||||
Don't forget to select the right product type. A consumable
|
||||
can not be stocked and will thus not be accounted for in the stock valuation.
|
||||
To create a new reordering rule from the product form, go to :menuselection:`Inventory --> Products
|
||||
--> Products`, select a product to open its product form, click the :guilabel:`Reordering Rules`
|
||||
smart button, and click :guilabel:`Create`. Then, fill out the fields and save the new reordering
|
||||
rule.
|
||||
|
||||
Make to Order
|
||||
--------------
|
||||
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, changing the value, and clicking :guilabel:`Save`. To replenish a product
|
||||
manually, click :guilabel:`Order Once`.
|
||||
|
||||
The Make to Order configuration is available on your product form
|
||||
through your :menuselection:`Inventory --> Inventory control --> Products` (or any
|
||||
other module where products are available).
|
||||
To automate replenishment, click :guilabel:`Automate Orders`. When this button is clicked, Odoo
|
||||
will automatically generate a draft :abbr:`PO (Purchase Order)`/:abbr:`MO (Manufacturing Order)`
|
||||
every time the forecasted stock level falls below the set :guilabel:`Min Quantity` of the
|
||||
reordering rule.
|
||||
|
||||
On the product form, under Inventory, click on "Make To Order".
|
||||
|
||||
.. image:: strategies/strategies03.png
|
||||
:align: center
|
||||
A reordering rule can be temporarily deactivated for a given period by using the :guilabel:`Snooze`
|
||||
button.
|
||||
|
||||
Choice between the two options
|
||||
------------------------------
|
||||
.. image:: strategies/reordering-rule-snooze-settings.png
|
||||
:align: center
|
||||
:alt: Snooze feature to temporarily deactivate reordering rules.
|
||||
|
||||
The choice between the two options is thus dependent of your inventory
|
||||
strategy. If you prefer to have a buffer and always have at least a
|
||||
minimum amount, the minimum stock rule should be used. If you want to
|
||||
reorder your stocks only if your sale is confirmed it is better to use
|
||||
the Make to Order.
|
||||
A :abbr:`PO (Purchase Order)` or :abbr:`MO (Manufacturing Order)` created by a manual replenishment
|
||||
will have `Replenishment Report` as the source document. A :abbr:`PO (Purchase Order)` or
|
||||
:abbr:`MO (Manufacturing Order)` created by an automated reordering rule will have the sales
|
||||
order(s) reference number(s) that triggered the rule as the source document.
|
||||
|
||||
.. image:: strategies/rfq-source-document.png
|
||||
:align: center
|
||||
:alt: Look at the source panel showing where RFQ/MFG orders originated from.
|
||||
|
||||
Make to order
|
||||
-------------
|
||||
|
||||
Since the Make to Order (MTO) route is only recommended for customized products, the route is
|
||||
hidden by default.
|
||||
|
||||
To activate the Make to Order (MTO) route in Odoo:
|
||||
|
||||
#. Go to :menuselection:`Inventory --> Configuration --> Settings --> Warehouse`.
|
||||
#. Activate :guilabel:`Multi-Step Routes` setting and click :guilabel:`Save`.
|
||||
#. Go to :menuselection:`Inventory --> 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`
|
||||
setting. 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 --> Products -->
|
||||
Products`, click on a product to open the product form, and click :guilabel:`Edit`. Then, click on
|
||||
the :guilabel:`Inventory` tab and in the :guilabel:`Routes` 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 MTO route and a vendor is configured in the :guilabel:`Purchase` tab.
|
||||
For products manufactured in-house, make sure the :guilabel:`Manufacture` route is selected in
|
||||
addition to the MTO route and a bill of materials is configured for the product. Finally, click
|
||||
:guilabel:`Save`.
|
||||
|
||||
.. image:: strategies/replenish-on-order-product-setting.png
|
||||
:align: center
|
||||
:alt: Enable the Replenish on Order (MTO) route on the product settings.
|
||||
|
After Width: | Height: | Size: 7.4 KiB |
After Width: | Height: | Size: 23 KiB |
After Width: | Height: | Size: 35 KiB |
After Width: | Height: | Size: 38 KiB |
Before Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 19 KiB |
Before Width: | Height: | Size: 15 KiB |
@ -1,107 +1,112 @@
|
||||
==============================
|
||||
Use Different Units of Measure
|
||||
Use different units of measure
|
||||
==============================
|
||||
|
||||
In some cases, handling products in different units of measure is
|
||||
necessary. For example, if you buy products in a country where the
|
||||
metric system is of application and sell in a country where the imperial
|
||||
system is used, you will need to convert the units. Another common use
|
||||
case is buying products in bigger packs to your supplier and selling
|
||||
them in units to your customers.
|
||||
In some cases, handling products in different units of measure is necessary. For example, a
|
||||
business can buy products from a country that uses the metric system, and then sell those products
|
||||
in a country that uses the imperial system, so the business needs to convert the units. Another
|
||||
case for unit conversion is when a business buys products in a big pack from a supplier and then
|
||||
sells those products in individual units.
|
||||
|
||||
You can set up Odoo to work with different units of measure for one
|
||||
product.
|
||||
Odoo can be set up to use different units of measure for one product.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
In the *Inventory* application, go to :menuselection:`Configuration --> Settings`. In
|
||||
the *Products* section, activate *Units of Measure*, then *Save*.
|
||||
To use different units of measure in Odoo, first go to :menuselection:`Inventory --> Configuration
|
||||
--> Settings --> Products` and activate the :guilabel:`Units of Measure` setting. Then, click
|
||||
:guilabel:`Save`.
|
||||
|
||||
.. image:: uom/uom_01.png
|
||||
:align: center
|
||||
.. image:: uom/uom-enable-setting.png
|
||||
:align: center
|
||||
:alt: Enable Units of Measure in the Inventory settings.
|
||||
|
||||
Create New Units of Measure
|
||||
Units of measure categories
|
||||
===========================
|
||||
|
||||
In the *Inventory* application go to :menuselection:`Configuration --> UoM`. There,
|
||||
hit *Create*. As an example, we will create a Box of 6 units that we
|
||||
will use for the Egg product.
|
||||
After enabling the units of measure setting, view the default units of measure categories in
|
||||
:menuselection:`Inventory --> Configuration --> Units of Measures --> UoM Categories`. The
|
||||
category is important for unit conversion, Odoo can only convert a product's units from one unit to
|
||||
another only if both units belong to the same category.
|
||||
|
||||
.. image:: uom/uom_02.png
|
||||
:align: center
|
||||
.. image:: uom/uom-categories.png
|
||||
:align: center
|
||||
:alt: Set units of measure categories.
|
||||
|
||||
The category is important for unit conversion, you will be able to
|
||||
convert products from one unit to another only if those units belong to
|
||||
the same category. The box of 6 is 6 times bigger than the reference
|
||||
unit of measure for the category which is “Units” here.
|
||||
Each units of measure category has a reference unit. The reference unit is highlighted in blue in
|
||||
the :guilabel:`Uom` column of the :guilabel:`Units of Measure Categories` page. Odoo uses the
|
||||
reference unit as a base for any new units.
|
||||
|
||||
.. image:: uom/uom_03.png
|
||||
:align: center
|
||||
To create a new unit, first select the correct category. For example, to sell a product in a box of
|
||||
six units, click on the :guilabel:`Unit` category line. Next, click :guilabel:`Edit`. After that,
|
||||
click :guilabel:`Add a line`. Then, in the :guilabel:`Unit of Measure` field, title the new unit
|
||||
`Box of 6`. In the :guilabel:`Type` field, select :guilabel:`Bigger than the reference Unit of
|
||||
Measure`. In the :guilabel:`Ratio` field, enter `6.00000` since a box of six is six times bigger
|
||||
than the reference unit (`1.00000`). Finally, click :guilabel:`Save`.
|
||||
|
||||
Specify Units of Measure on your Products
|
||||
=========================================
|
||||
Click on the :guilabel:`Unit` category.
|
||||
|
||||
In the :menuselection:`Inventory application --> Master Data --> Products`, open the
|
||||
product which you would like to change the purchase/sale unit of
|
||||
measure, and click on *Edit*.
|
||||
Click :guilabel:`Add a line`. As an example, we will create a Box of 6 units that we will use for
|
||||
the Egg product. The box of 6 is 6 times bigger than the reference unit of measure for the category
|
||||
which is “Units” here.
|
||||
|
||||
In the *General Information* tab, you can select the *Unit of
|
||||
Measure* in which the product will be sold, which is also the unit in
|
||||
which internal transfers will take place. You can also select the
|
||||
*Purchase Unit of Measure*, which is the unit in which you purchase
|
||||
the product.
|
||||
.. image:: uom/convert-products-by-unit.png
|
||||
:align: center
|
||||
:alt: Convert products from one unit to another as long as they belong to the same category.
|
||||
|
||||
.. image:: uom/uom_04.png
|
||||
:align: center
|
||||
Specify a product's units of measure
|
||||
====================================
|
||||
|
||||
Transfer from One Unit to Another
|
||||
=================================
|
||||
To set units of measure on a product, first go to :menuselection:`Inventory --> Products -->
|
||||
Products` and click on a product to open its settings. Then, click on :guilabel:`Edit`.
|
||||
|
||||
Buy in the Purchase UoM
|
||||
-----------------------
|
||||
In the :guilabel:`General Information` tab, edit the :guilabel:`Unit of Measure` field to specify
|
||||
the unit of measure that the product is sold in. The specified unit will also be the unit used to
|
||||
keep track of the product's inventory and internal transfers. Edit the :guilabel:`Purchase UoM`
|
||||
field to specify the unit of measure that the product is purchased in.
|
||||
|
||||
In the *Purchase* application, *Create* a new request for quotation
|
||||
in which you include the product with the different *Units of Measure*
|
||||
and *Confirm* it.
|
||||
Unit conversion
|
||||
===============
|
||||
|
||||
.. image:: uom/uom_05.png
|
||||
:align: center
|
||||
Buy products in the Purchase UoM
|
||||
--------------------------------
|
||||
|
||||
On the automatically generated purchase orders, the UoM used is the Box
|
||||
of 6, meaning the Purchase UoM. You have of course the possibility to
|
||||
manually modify the UoM if necessary. When you enter the *Receipt*
|
||||
which is linked to the purchase order, you can observe that the 10 boxes
|
||||
of 6 units have been converted in 60 units. Indeed, the stock is managed
|
||||
in units.
|
||||
When creating a new request for quotation (RFQ) in the Purchase app, Odoo automatically uses the
|
||||
product's specified purchase unit of measure. However, if needed, the :guilabel:`UoM` can be
|
||||
manually edited on the RFQ.
|
||||
|
||||
.. image:: uom/uom_06.png
|
||||
:align: center
|
||||
After the RFQ is confirmed into a purchase order (PO), click on the :guilabel:`Receipt` smart
|
||||
button at the top right corner of the PO. Odoo automatically converts the purchase unit of measure
|
||||
into the product's sales/inventory unit of measure, so the :guilabel:`Demand` column of the
|
||||
delivery receipt shows the converted quantity.
|
||||
|
||||
For example, if the product's purchase UoM is `Box of 6` and its sales/inventory unit of measure is
|
||||
`Units`, the PO shows the quantity in boxes of six, and the delivery receipt shows the quantity in
|
||||
units.
|
||||
|
||||
Replenishment
|
||||
-------------
|
||||
|
||||
When doing a replenishment via the *Replenish* button on the product
|
||||
form, you have the possibility to use a different unit of measure.
|
||||
A request for quotation for a product can also be generated directly from the product form using
|
||||
the :guilabel:`Replenish` button. After clicking :guilabel:`Replenish`, a replenish assistant box
|
||||
pops up. The purchase unit of measure can be manually edited here if needed. Then, click
|
||||
:guilabel:`Confirm` to create the RFQ.
|
||||
|
||||
.. image:: uom/uom_07.png
|
||||
:align: center
|
||||
Next, click the :guilabel:`Units Forecasted` smart button on the product form and scroll down to
|
||||
:menuselection:`Forecasted Inventory --> Requests for quotation`. Click on the RFQ reference number
|
||||
to open the draft RFQ. The purchase UoM can also be edited here if needed.
|
||||
|
||||
.. image:: uom/uom_08.png
|
||||
:align: center
|
||||
Sell in a different UoM
|
||||
-----------------------
|
||||
|
||||
Sell in bigger UoM
|
||||
------------------
|
||||
When creating a new quotation in the Sales app, Odoo automatically uses the product's specified
|
||||
unit of measure. However, if needed, the :guilabel:`UoM` can be manually edited on the quotation.
|
||||
|
||||
You can choose the unit of measure on the sale order document and decide
|
||||
to sell the eggs by the dozen. When doing so, the price is automatically
|
||||
computed from Units UoM to adapt to the selected *UoM*.
|
||||
After the quotation is sent to the customer and confirmed into a sales order (SO), click on the
|
||||
:guilabel:`Delivery` smart button at the top right corner of the SO. Odoo automatically converts
|
||||
the unit of measure into the product's inventory unit of measure, so the :guilabel:`Demand` column
|
||||
of the delivery shows the converted quantity.
|
||||
|
||||
.. image:: uom/uom_09.png
|
||||
:align: center
|
||||
|
||||
In the delivery order, the *UoM* used in the sale order is converted
|
||||
to the *UoM* used for stock management, in our use case, the Units.
|
||||
|
||||
.. image:: uom/uom_10.png
|
||||
:align: center
|
||||
For example, if the product's UoM on the SO was changed to `Box of 6`, but its inventory unit of
|
||||
measure is `Units`, the SO shows the quantity in boxes of six, and the delivery shows the quantity
|
||||
in units.
|
||||
|
After Width: | Height: | Size: 73 KiB |
After Width: | Height: | Size: 22 KiB |
After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 8.7 KiB |
Before Width: | Height: | Size: 6.6 KiB |
Before Width: | Height: | Size: 5.0 KiB |
Before Width: | Height: | Size: 21 KiB |
Before Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 12 KiB |
@ -2,71 +2,70 @@
|
||||
When Should you Use Packages, Units of Measure or Special Packaging?
|
||||
====================================================================
|
||||
|
||||
Units of Measure
|
||||
Units of measure
|
||||
================
|
||||
|
||||
Units of measure specify the unit used to handle a product. In Odoo, you
|
||||
have the possibility to specify the unit of measure in which you manage
|
||||
your stock and the one which is used when purchasing the product to your
|
||||
supplier.
|
||||
Units of measure specify the unit used to handle a product. In Odoo, you have the possibility to
|
||||
specify the unit of measure in which you manage your stock and the one which is used when
|
||||
purchasing the product to your supplier.
|
||||
|
||||
.. image:: usage/usage_01.png
|
||||
:align: center
|
||||
.. image:: usage/uom-product-setting.png
|
||||
:align: center
|
||||
:alt: Specify unit of measure for handling a product vs. when it's purchased.
|
||||
|
||||
The *conversion* between the different units of measure is done
|
||||
automatically. The only condition is that all the units have to be in
|
||||
the *same category* (Unit, Weight, Volume, Length,...)
|
||||
Once a product has a :guilabel:`Unit of Measure` and a :guilabel:`Purchase UoM` set on the product
|
||||
form, Odoo can automatically convert the different units in the product's purchase/sales orders and
|
||||
the orders' respective delivery orders/receipts. The only condition is that all the units have to
|
||||
be in the *same category* (Unit, Weight, Volume, Length, etc.).
|
||||
|
||||
For example, if I have the following reordering rule for the egg and I
|
||||
run the scheduler, the quantity added in the automatically generated
|
||||
purchase order will be in dozens but what will enter the stock will be
|
||||
units.
|
||||
|
||||
.. image:: usage/usage_02.png
|
||||
:align: center
|
||||
|
||||
.. image:: usage/usage_03.png
|
||||
:align: center
|
||||
|
||||
.. image:: usage/usage_04.png
|
||||
:align: center
|
||||
For example, a product can have its :guilabel:`Unit of Measure` set to `feet (ft)` and its
|
||||
:guilabel:`Purchase UoM` set to `centimeters (cm)`. When a purchase order (PO) is created for that
|
||||
product, it will list the quantity in centimeters. Then, when the PO is confirmed, Odoo
|
||||
automatically generates a receipt and converts the centimeters to feet. The receipt will list the
|
||||
quantity in feet.
|
||||
|
||||
Packages
|
||||
========
|
||||
|
||||
The package is the physical container in which you put one or several
|
||||
products from a picking. For example, when you deliver a product, you
|
||||
can decide to separate the quantity into two different packages. It then
|
||||
allows you to have a report with the quantity of products for each
|
||||
package.
|
||||
A package refers to the physical container that holds one or several products from a picking. For
|
||||
example, when a product is ready for delivery, its quantities can be separated into two different
|
||||
packages. In Odoo, the quantity of products in each package can be recorded in the database. Make
|
||||
sure the :guilabel:`Packages` option is enabled in :menuselection:`Inventory --> Configuration -->
|
||||
Settings --> Operations`.
|
||||
|
||||
To separate a delivery into different packages you will have to set the
|
||||
done quantity to the desired package quantity then click on "PUT IN
|
||||
PACK", do this for each package.
|
||||
On a delivery order, separate the products into different packages by setting the :guilabel:`Done`
|
||||
quantity to the desired quantity in the first package. Then, click :guilabel:`Put in Pack` to
|
||||
record the first package. Repeat for each package.
|
||||
|
||||
.. image:: usage/usage_05.png
|
||||
:align: center
|
||||
.. image:: usage/separate-delivery-into-different-packages.png
|
||||
:align: center
|
||||
:alt: Separate delivery into different packages
|
||||
|
||||
.. image:: usage/usage_06.png
|
||||
:align: center
|
||||
.. image:: usage/delivery-package-details.png
|
||||
:align: center
|
||||
:alt: Separate delivery package details
|
||||
|
||||
Packaging
|
||||
=========
|
||||
Packagings
|
||||
==========
|
||||
|
||||
The packaging is the physical container that protects your product. If
|
||||
you are selling computers, the packaging contains the computer with the
|
||||
notice and the power plug.
|
||||
Packaging refers to a standard container that holds several unit of a product. For example, cans of
|
||||
soda can be in a 6-pack, 15-pack, or even a pallet for the packaging.
|
||||
|
||||
In Odoo, packagings are used for indicative purposes on sale orders.
|
||||
They can be specified on the product form, in the inventory tab.
|
||||
In Odoo, packagings are used for indicative purposes on sales/purchase orders and inventory
|
||||
transfers. The main difference between packagings and units of measure is that packagings are
|
||||
defined at the product level while UoMs are generic.
|
||||
|
||||
.. image:: usage/usage_07.png
|
||||
:align: center
|
||||
.. image:: usage/product-packaging-examples.png
|
||||
:align: center
|
||||
:alt: Different product packaging examples.
|
||||
|
||||
.. image:: usage/usage_08.png
|
||||
:align: center
|
||||
.. image:: usage/package-field-on-po.png
|
||||
:align: center
|
||||
:alt: Package field on purchase order.
|
||||
|
||||
.. note::
|
||||
Another useful use of the packaging is for product reception. By
|
||||
scanning the barcode of the packaging, Odoo adds the number of units
|
||||
contained in the packing on the picking.
|
||||
Packaging is also useful during product reception. When scanning the barcode of the
|
||||
packaging, Odoo automatically adds the number of units contained in the packing on the picking.
|
||||
|
||||
.. seealso::
|
||||
:doc:`uom`
|
||||
|
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 5.0 KiB After Width: | Height: | Size: 5.0 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 8.4 KiB |
Before Width: | Height: | Size: 15 KiB |
Before Width: | Height: | Size: 11 KiB |
@ -1,8 +1,8 @@
|
||||
:nosearch:
|
||||
|
||||
====================
|
||||
Inventory Adjustment
|
||||
====================
|
||||
========================
|
||||
Replenishment strategies
|
||||
========================
|
||||
|
||||
.. toctree::
|
||||
:titlesonly:
|
||||
|
@ -2,24 +2,19 @@
|
||||
Integrating additional costs to products (landed costs)
|
||||
=======================================================
|
||||
|
||||
The landed cost feature in Odoo allows to include additional costs
|
||||
(shipment, insurance, customs duties, etc.) into the cost of the
|
||||
product.
|
||||
|
||||
.. note::
|
||||
Landed costs can only be applied to products with a FIFO or AVCO costing
|
||||
method and an automated inventory valuation (which requires the
|
||||
accounting application to be installed).
|
||||
The landed cost feature in Odoo allows the user to include additional costs (shipment, insurance,
|
||||
customs duties, etc.) into the cost of the product.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
First, you need to go in :menuselection:`Inventory --> Configuration --> Settings` and
|
||||
activate the landed costs feature. You can also determine the default
|
||||
journal in which the landed cost accounting entries will be recorded.
|
||||
First, go to :menuselection:`Inventory --> Configuration --> Settings --> Valuation` and activate
|
||||
the :guilabel:`Landed Costs` feature. Odoo also gives the option to set a :guilabel:`Default
|
||||
Journal` in which the landed costs accounting entries will be recorded.
|
||||
|
||||
.. image:: integrating_landed_costs/integrating_landed_costs_01.png
|
||||
:align: center
|
||||
.. image:: integrating_landed_costs/landed-costs-setting.png
|
||||
:align: center
|
||||
:alt: Activate the landed cost feature in Inventory settings.
|
||||
|
||||
Add costs to products
|
||||
=====================
|
||||
@ -27,38 +22,58 @@ Add costs to products
|
||||
Receive the vendor bill
|
||||
-----------------------
|
||||
|
||||
Let’s imagine I receive a bill from custom duties for a shipment. I’ll
|
||||
tick the box *Landed Costs* on the vendor bill line.
|
||||
After a vendor fulfills a purchase order and sends a bill, click :guilabel:`Create Bill` on the
|
||||
purchase order to create a vendor bill in Odoo. If the vendor bill includes landed costs, such as
|
||||
custom duties, tick the box in the :guilabel:`Landed Costs` column on the vendor bill invoice line.
|
||||
|
||||
.. image:: integrating_landed_costs/integrating_landed_costs_02.png
|
||||
:align: center
|
||||
.. image:: integrating_landed_costs/landed-costs-field-vendor-bill.png
|
||||
:align: center
|
||||
:alt: Enable Landed Costs option on vendor bill line.
|
||||
|
||||
For charges that are always landed costs, create a landed cost product in Odoo. That way, the
|
||||
landed cost product can be quickly added to the vendor bill as an invoice line instead of manually
|
||||
entering the landed cost information every time a vendor bill comes in.
|
||||
|
||||
First, create a new product in :menuselection:`Inventory --> Products --> Products --> Create`.
|
||||
Next, name the landed cost product. Then, set the :guilabel:`Product Type` to :guilabel:`Service`.
|
||||
A landed cost product must always be a service product type. After that, go to the
|
||||
:guilabel:`Purchase` tab and check the box next to :guilabel:`Is a Landed Cost`. Finally, click
|
||||
:guilabel:`Save` to finish creating the landed cost product.
|
||||
|
||||
If this product is always a landed cost, you can also define it on the product and avoid having to
|
||||
tick the box on each vendor bill.
|
||||
|
||||
.. image:: integrating_landed_costs/product-is-landed-cost.png
|
||||
:align: center
|
||||
:alt: Option to define a product as a landed cost.
|
||||
|
||||
Once the landed cost is added to the vendor bill (either by checking the :guilabel:`Landed Cost`
|
||||
option on the invoice line or adding a landed cost product to the bill), click the
|
||||
:guilabel:`Create Landed Costs` button at the top of the bill. Odoo automatically creates a landed
|
||||
cost record with the set landed cost pre-filled in the :guilabel:`Additional Costs` product lines.
|
||||
From here, decide which picking the additional costs apply to by clicking :guilabel:`Edit` and
|
||||
selecting the picking reference number from the :guilabel:`Transfers` drop-down menu. Finally,
|
||||
click :guilabel:`Save`.
|
||||
|
||||
.. image:: integrating_landed_costs/warehouse-transfer-landed-costs.png
|
||||
:align: center
|
||||
:alt: Use a warehouse transfer to cover a landed cost in the accounting journal.
|
||||
|
||||
After setting the picking, click :guilabel:`Compute` on the landed cost record. Then, go to the
|
||||
:guilabel:`Valuation Adjustments` tab to see the impact of the landed costs. Finally, click
|
||||
:guilabel:`Validate` to post the landed cost entry to the accounting journal.
|
||||
|
||||
The user can access the journal entry that has been created by the landed cost by clicking on the
|
||||
:guilabel:`Journal Entry`.
|
||||
|
||||
.. note::
|
||||
The landed cost product must be of type service.
|
||||
The product that the landed cost is applied to must have a product category set to a :abbr:`FIFO
|
||||
(First In, First Out)` or an :abbr:`AVCO (Average Costing)` method.
|
||||
|
||||
If this product is always a landed cost, you can also define it on the
|
||||
product and avoid having to tick the box on each vendor bill.
|
||||
|
||||
.. image:: integrating_landed_costs/integrating_landed_costs_03.png
|
||||
:align: center
|
||||
|
||||
At the top of my vendor bill, I’ll see a button *create landed costs*.
|
||||
I click on this button and a landed cost is automatically created. I can
|
||||
now decide on which picking those additional costs should apply.
|
||||
|
||||
.. image:: integrating_landed_costs/integrating_landed_costs_04.png
|
||||
:align: center
|
||||
|
||||
I can now click on *Compute* and go in the tab *Valuation
|
||||
Adjustments* to see the impact on my products costs. The last step is
|
||||
to validate the landed cost.
|
||||
|
||||
I can access the journal entry that has been created by the landed cost
|
||||
by clicking on the journal entry.
|
||||
|
||||
.. image:: integrating_landed_costs/integrating_landed_costs_05.png
|
||||
:align: center
|
||||
.. image:: integrating_landed_costs/landed-cost-journal-entry.png
|
||||
:align: center
|
||||
:alt: Landed cost journal entry
|
||||
|
||||
.. note::
|
||||
You are not forced to start from the vendor bill, you can also go in :menuselection:`Inventory
|
||||
--> Operations --> Landed Costs` and directly create the landed cost from there.
|
||||
Landed cost records can also be directly created in :menuselection:`Inventory --> Operations -->
|
||||
Landed Costs`, it is not necessary to create a landed cost record from the vendor bill.
|
||||
|
Before Width: | Height: | Size: 2.5 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 4.3 KiB After Width: | Height: | Size: 4.3 KiB |
After Width: | Height: | Size: 28 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
@ -8,4 +8,5 @@ Warehouses
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
warehouses/difference_warehouse_location
|
||||
warehouses/warehouses_locations
|
||||
warehouses/resupply_warehouses
|
||||
|
@ -1,34 +0,0 @@
|
||||
========================================================
|
||||
What is the difference between warehouses and locations?
|
||||
========================================================
|
||||
|
||||
In Odoo, a **Warehouse** is the actual building/place in which your items
|
||||
are stocked. You can setup multiple warehouses and create moves between
|
||||
warehouses.
|
||||
|
||||
A **Location**, is a specific space within your warehouse. It can be
|
||||
considered as a sublocation of your warehouse, as a shelf, a floor, an
|
||||
aisle, etc. Therefore, a location is part of one warehouse only and it
|
||||
is not possible to link one location to multiple warehouses. You can
|
||||
configure as many locations as you need under one warehouse.
|
||||
|
||||
There are 3 types of locations:
|
||||
|
||||
- The **Physical Locations** are internal locations that are part of the
|
||||
warehouses for which you are the owner. They can be the loading and
|
||||
unloading area of your warehouse, a shelf or a department, etc.
|
||||
|
||||
- The **Partner Locations** are spaces within a customer and/or vendor's
|
||||
warehouse. They work the same way as Physical Locations with the only
|
||||
difference being that you are not the owner of the warehouse.
|
||||
|
||||
- The **Virtual Locations** are places that do not exist, but in which
|
||||
products can be placed when they are not physically in an inventory yet
|
||||
(or anymore). They come in handy when you want to place lost products
|
||||
out of your stock (in the **Inventory loss**), or when you want to take into
|
||||
account products that are on their way to your warehouse (**Procurements**).
|
||||
|
||||
In Odoo, locations are structured hierarchically. You can structure your
|
||||
locations as a tree, dependent on a parent-child relationship. This
|
||||
gives you more detailed levels of analysis of your stock operations and
|
||||
the organization of your warehouses.
|
@ -0,0 +1,70 @@
|
||||
===============================
|
||||
Resupply from another warehouse
|
||||
===============================
|
||||
|
||||
A common use case for multiple warehouses is to have one central warehouse that resupplies multiple
|
||||
shops, and in this case, each shop is considered a local warehouse. When a shop wants to replenish
|
||||
a product, the product is ordered to the central warehouse. Odoo allows the user to easily set
|
||||
which warehouse(s) can resupply another warehouse.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To resupply from another warehouse, first go to :menuselection:`Inventory --> Configuration -->
|
||||
Settings --> Warehouse` and activate :guilabel:`Multi-Step Routes`. Then, click :guilabel:`Save` to
|
||||
apply the setting.
|
||||
|
||||
.. image:: resupply_warehouses/virtual-warehouses-settings.png
|
||||
:align: center
|
||||
:alt: Enable Multi-Step Routes in Inventory settings.
|
||||
|
||||
View all the configured warehouses by going to :menuselection:`Inventory --> Configuration -->
|
||||
Warehouses`.
|
||||
|
||||
Create a new warehouse by clicking :guilabel:`Create`. Then, give the warehouse a name and a
|
||||
:guilabel:`Short Name`. Finally, click :guilabel:`Save` to finish creating the warehouse.
|
||||
|
||||
After that, go back to the :guilabel:`Warehouses` page and open the warehouse that will be
|
||||
resupplied by the second warehouse. Then, click :guilabel:`Edit`. In the :guilabel:`Warehouse
|
||||
Configuration` tab, locate the :guilabel:`Resupply From` field, and check the box next to the
|
||||
second warehouse's name. If the warehouse can be resupplied by more than one warehouse, make sure
|
||||
to check those warehouses' boxes too. Finally, click :guilabel:`Save` to apply the setting. Now,
|
||||
Odoo knows which warehouses can resupply this warehouse.
|
||||
|
||||
.. image:: resupply_warehouses/resupply-from-second-warehouse.png
|
||||
:align: center
|
||||
:alt: Supply one warehouse with another in the Warehouse Configuration tab.
|
||||
|
||||
Set route on a product
|
||||
======================
|
||||
|
||||
After configuring which warehouse(s) to resupply from, a new route is now available on all product
|
||||
forms. The new route appears as :guilabel:`Supply Product from [Warehouse Name]` under the
|
||||
:guilabel:`Inventory` tab on a product form. Use the :guilabel:`Supply Product from [Warehouse
|
||||
Name]` route with a reordering rule or the make to order (MTO) route to replenish stock by moving
|
||||
the product from one warehouse to another.
|
||||
|
||||
.. image:: resupply_warehouses/product-resupply-route-settings.png
|
||||
:align: center
|
||||
:alt: Route setting which enables a product to resupplied from a second warehouse.
|
||||
|
||||
When a product's reordering rule is triggered and the product has the :guilabel:`Supply Product
|
||||
from [Warehouse Name]` route set, Odoo automatically creates two pickings. One picking is a
|
||||
*delivery order* from the second warehouse, which contains all the necessary products, and the
|
||||
second picking is a *receipt* with the same products for the main warehouse. The product move from
|
||||
the second warehouse to the main warehouse is fully tracked in Odoo.
|
||||
|
||||
On the picking/transfer records created by Odoo, the :guilabel:`Source Document` is the product's
|
||||
reordering rule. The location between the delivery order and the receipt is a transit location.
|
||||
|
||||
.. image:: resupply_warehouses/resupply-receipts-from-reordering-rule.png
|
||||
:align: center
|
||||
:alt: A reordering rule automatically creates two receipts for stock between warehouses.
|
||||
|
||||
.. image:: resupply_warehouses/second-warehouse-delivery-order.png
|
||||
:align: center
|
||||
:alt: A warehouse order for resupplying one warehouse's stock with another.
|
||||
|
||||
.. image:: resupply_warehouses/second-warehouse-stock-receipt.png
|
||||
:align: center
|
||||
:alt: A receipt for stock received to one warehouse from another.
|
After Width: | Height: | Size: 26 KiB |
After Width: | Height: | Size: 19 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 18 KiB |
After Width: | Height: | Size: 17 KiB |
After Width: | Height: | Size: 12 KiB |
@ -0,0 +1,93 @@
|
||||
===============================
|
||||
Manage Warehouses and Locations
|
||||
===============================
|
||||
|
||||
Terminology
|
||||
===========
|
||||
|
||||
Warehouse
|
||||
---------
|
||||
|
||||
In Odoo, a **Warehouse** is the actual building/place in which a company's items are stocked.
|
||||
Multiple warehouses can be set up in Odoo and the user can create moves between warehouses.
|
||||
|
||||
Location
|
||||
--------
|
||||
|
||||
A **Location** is a specific space within the warehouse. It can be a sublocation of the warehouse
|
||||
(a shelf, a floor, an aisle, and so on). Therefore, a location is part of one warehouse only and it
|
||||
is not possible to link one location to multiple warehouses. In Odoo, as many locations can be
|
||||
configured as needed under one warehouse.
|
||||
|
||||
There are three types of locations:
|
||||
|
||||
- The **Physical Locations** are internal locations that are part of the warehouses that the
|
||||
company owns. They can be the loading and unloading areas of the warehouse, a shelf, a department,
|
||||
etc.
|
||||
|
||||
- The **Partner Locations** are spaces within a customer and/or vendor's warehouse. They work the
|
||||
same way as physical locations, with the only difference being that they are not owned by the
|
||||
user's company.
|
||||
|
||||
- The **Virtual Locations** are places that do not exist, but in which products can be placed when
|
||||
they are not physically in an inventory yet (or anymore). They come in handy when recording lost
|
||||
products (**Inventory Loss**), or accounting for products that are on their way to the warehouse
|
||||
(**Procurements**).
|
||||
|
||||
In Odoo, locations are structured hierarchically. Locations can be structured as a tree, dependent
|
||||
on a parent-child relationship. This gives more detailed levels of analysis of the stock operations
|
||||
and the organization of the warehouses.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
To activate locations, go to :menuselection:`Configuration --> Settings` and enable
|
||||
:guilabel:`Storage Locations`. Then, click :guilabel:`Save`.
|
||||
|
||||
.. image:: warehouses_locations/storage-location-warehouse-setting.png
|
||||
:align: center
|
||||
:alt: Enable the storage location feature in Odoo Inventory settings.
|
||||
|
||||
.. important::
|
||||
To manage several routes within the warehouses, also enable :guilabel:`Multi-Step Routes` and
|
||||
check :doc:`../../routes/concepts/use_routes`.
|
||||
|
||||
Create a new warehouse
|
||||
======================
|
||||
|
||||
To create a warehouse, go to :menuselection:`Configuration --> Warehouse Management --> Warehouses`
|
||||
and click on :guilabel:`Create`.
|
||||
|
||||
Then, fill out a :guilabel:`Warehouse Name` and a :guilabel:`Short Name`. The short name is five
|
||||
characters maximum.
|
||||
|
||||
.. image:: warehouses_locations/create-new-warehouse.png
|
||||
:align: center
|
||||
:alt: Short name field of a warehouse on Odoo Inventory.
|
||||
|
||||
.. important::
|
||||
The :guilabel:`Short Name` appears on transfer orders and other warehouse documents. Odoo
|
||||
recommends using an understandable one like "WH/[first letters of location]".
|
||||
|
||||
Now, go back to the :guilabel:`Inventory` dashboard. There, new operations related to the newly
|
||||
created warehouse have been automatically generated.
|
||||
|
||||
.. image:: warehouses_locations/new-transfer-types.png
|
||||
:align: center
|
||||
:alt: Inventory app dashboard displaying new transfer types for the recently created warehouse.
|
||||
|
||||
.. note::
|
||||
Adding a second warehouse will automatically activate the :guilabel:`Locations` setting.
|
||||
|
||||
Create a new location
|
||||
=====================
|
||||
|
||||
To create a location, go to :menuselection:`Configuration --> Warehouse Management --> Locations`
|
||||
and click on :guilabel:`Create`.
|
||||
|
||||
Then, fill out a :guilabel:`Location Name` and a :guilabel:`Parent Location` and click
|
||||
:guilabel:`Save`.
|
||||
|
||||
.. image:: warehouses_locations/create-new-location.png
|
||||
:align: center
|
||||
:alt: Create a new warehouse location in Odoo Inventory.
|
After Width: | Height: | Size: 7.5 KiB |
After Width: | Height: | Size: 3.9 KiB |
After Width: | Height: | Size: 12 KiB |
After Width: | Height: | Size: 6.5 KiB |
@ -8,7 +8,7 @@ Concepts
|
||||
:titlesonly:
|
||||
:glob:
|
||||
|
||||
concepts/use-routes
|
||||
concepts/use_routes
|
||||
concepts/inter_warehouse
|
||||
concepts/cross_dock
|
||||
concepts/stock_warehouses
|
@ -2,128 +2,70 @@
|
||||
Inter-warehouse transfers
|
||||
=========================
|
||||
|
||||
When owning several warehouses, you might need to transfer goods from one warehouse to another.
|
||||
Proceeding to such behavior is called *inter-warehouse transfers*. If this action is physically
|
||||
easy to perform, the administrative part can be arduous. Fortunately, Odoo comes with an intuitive
|
||||
flow that helps save time when registering those transfers.
|
||||
|
||||
Configuration
|
||||
=============
|
||||
|
||||
First of all, go to :menuselection:`Configuration --> Settings` and enable **Storage Locations**.
|
||||
Then, hit save.
|
||||
|
||||
.. image:: inter_warehouse/feature-storage-location.png
|
||||
:align: center
|
||||
:alt: Enabling the storage location feature in Odoo Inventory.
|
||||
|
||||
.. important::
|
||||
If you want to manage several routes within your warehouses, then enable **Multi-Step Routes**
|
||||
and check :doc:`use-routes`.
|
||||
|
||||
Creating a new warehouse
|
||||
========================
|
||||
|
||||
The next step is to create your new warehouse. To do so, go to :menuselection:`Configuration -->
|
||||
Warehouse Management --> Warehouses` and click on **Create**.
|
||||
|
||||
Fill out a **Warehouse Name** and a **Short Name**. The short name is five characters maximum.
|
||||
|
||||
.. image:: inter_warehouse/create-new-warehouse.png
|
||||
:align: center
|
||||
:alt: Short name field of a warehouse on Odoo Inventory.
|
||||
|
||||
.. important::
|
||||
The **Short Name** appears on your transfer orders and other warehouse documents. We recommend
|
||||
using an understandable one (e.g.: WH/[first letters of location]).
|
||||
|
||||
Now, go back to your dashboard. There, new operations related to your warehouse have been
|
||||
automatically generated.
|
||||
|
||||
.. image:: inter_warehouse/new-transfer-types.png
|
||||
:align: center
|
||||
:alt: Inventory app dashboard displaying new transfer type for the recently created warehouse.
|
||||
|
||||
Creating a new inventory
|
||||
========================
|
||||
|
||||
If you create a new warehouse, you might already have an existing inventory in it. In that case, you
|
||||
should create an inventory in Odoo. If this is not the case, you can skip this step.
|
||||
|
||||
Into the inventory application, select :menuselection:`Operations --> Inventory Adjustment`.
|
||||
Then, create a new inventory by clicking on **Create**. Fill in the **Inventory Reference**,
|
||||
**Date** and make sure to select the right warehouse and location.
|
||||
|
||||
.. image:: inter_warehouse/annual-inventory.png
|
||||
:align: center
|
||||
:alt: View of the inventory adjustment form before hitting the start button.
|
||||
|
||||
Next, click on **Start Inventory**. You will be able to input your existing products in the new
|
||||
window. Select add an item and indicate the **Real Quantity** available in the warehouse.
|
||||
The theoretical quantity can not be changed as it represents a computed one from purchase and sales
|
||||
orders.
|
||||
|
||||
.. image:: inter_warehouse/in-progress-annual-inventory.png
|
||||
:align: center
|
||||
:alt: View of the actual physical inventory of the new warehouse.
|
||||
|
||||
.. tip::
|
||||
Don't forget to validate your inventory once you have recorded the state of all your products.
|
||||
When owning several warehouses, goods might need to be transferred from one warehouse to another.
|
||||
This type of transfer is called an *inter-warehouse transfer*. While physically performing the
|
||||
inter-warehouse transfer might be simple, the administrative part can be complex. Fortunately, Odoo
|
||||
comes with an intuitive flow that helps save time when registering inter-warehouse transfers.
|
||||
|
||||
Create an internal transfer
|
||||
===========================
|
||||
|
||||
The final step is to create your internal transfer. If you want to transfer eight units of a product
|
||||
from your first warehouse to another one, proceed as follows:
|
||||
The following paragraphs detail a sample inter-warehouse transfer, referred to as an *internal
|
||||
transfer*, use case. The sample use case assumes that the user has already configured their second
|
||||
warehouse.
|
||||
|
||||
From your dashboard, select an internal movement of one of the two warehouses. To do so, click on
|
||||
:menuselection:`Manage --> Planned Transfer`.
|
||||
To transfer eight units of a product from the first warehouse to another one, proceed as follows:
|
||||
|
||||
From the :guilabel:`Inventory` dashboard, select an internal movement operation of one of the two
|
||||
warehouses. To do so, click on the three vertical dots icon on the top right corner of the
|
||||
operation card and select :guilabel:`Planned Transfer`.
|
||||
|
||||
.. image:: inter_warehouse/internal-transfer-choice.png
|
||||
:align: center
|
||||
:alt: View of the choice between planned transfer and immediate transfer.
|
||||
|
||||
On the new window, select the source location zone (in this case, your "old" warehouse) and the
|
||||
destination location zone (in this case, your "new" warehouse).
|
||||
On the new planned transfer form, select the :guilabel:`Source Location` (in this case, the first
|
||||
warehouse) and the :guilabel:`Destination Location` (in this case, the second warehouse).
|
||||
|
||||
Add the products you want to transfer by clicking on **Add an Item**, then click on **Save** and
|
||||
**Mark as TODO** once you are done.
|
||||
Next, add the products that will be transferred by clicking on :guilabel:`Add a line`, then click
|
||||
on :guilabel:`Save` and :guilabel:`Mark as ToDo` once done. After that, Odoo puts the transfer in
|
||||
the :guilabel:`Waiting` status. Then, click on :guilabel:`Reserve` to reserve the number of
|
||||
products in the source warehouse.
|
||||
|
||||
.. image:: inter_warehouse/planned-internal-transfer.png
|
||||
:align: center
|
||||
:alt: View of the internal transfer form.
|
||||
|
||||
If you selected **Immediate Transfer**, Odoo processes the transfer automatically after you clicked
|
||||
on **Validate**.
|
||||
|
||||
If you select **Mark as TODO**, Odoo puts the transfer in **Waiting Availability** status.
|
||||
Click on **Reserve** to reserve the number of products in your source warehouse.
|
||||
.. note::
|
||||
If :guilabel:`Immediate Transfer` was selected instead of :guilabel:`Planned Transfer`, Odoo
|
||||
processes the transfer automatically after the :guilabel:`Validate` button is clicked on the
|
||||
internal transfer form.
|
||||
|
||||
It is also possible to manually transfer each product:
|
||||
|
||||
- Via your dashboard, select the transfer order in the source location.
|
||||
#. On the :guilabel:`Inventory` dashboard, open the souce location's internal transfer operation
|
||||
page.
|
||||
|
||||
.. image:: inter_warehouse/in-progress-internal-transfer.png
|
||||
:align: center
|
||||
:alt: View of the dashboard with a zoom of the pending internal transfer.
|
||||
|
||||
- Select the right transfer order.
|
||||
#. Open the desired transfer order form.
|
||||
|
||||
.. image:: inter_warehouse/internal-transfers-list.png
|
||||
:align: center
|
||||
:alt: View of the pending internal transfers list.
|
||||
|
||||
- Click on the little pencil logo in the lower right corner to open the operation details window.
|
||||
In this new window you can manually indicate how many products you process.
|
||||
#. Click on the pencil icon in the lower right corner to open the operation details window. In this
|
||||
new window, the quantity of products can be manually set.
|
||||
|
||||
.. image:: inter_warehouse/backorder.png
|
||||
:align: center
|
||||
:alt: View of a backorder pop-up window because all products are not moved at the same time.
|
||||
|
||||
.. note::
|
||||
If you decide to process the transfer order partially (e.g., a part of the products can't be
|
||||
shipped yet due to an unexpected event), Odoo automatically asks if you wish to create a
|
||||
**backorder**.
|
||||
To process the transfer order partially (e.g., a part of the products can't be shipped yet due
|
||||
to an unexpected event), Odoo automatically asks if a *backorder* should be created.
|
||||
|
||||
- Create a backorder if you expect to process the remaining products later.
|
||||
- Do not create a backorder if you will not supply/receive the remaining products.
|
||||
- Create a backorder if it is expected that the remaining products will be processed later.
|
||||
- Do not create a backorder if the remaining products will not be supplied/received.
|
||||
|
@ -1,375 +0,0 @@
|
||||
================================
|
||||
Using Routes and Pull/Push Rules
|
||||
================================
|
||||
|
||||
In inventory management, the supply chain strategy determines when
|
||||
products should be fabricated, delivered to distribution centers, and
|
||||
made available in the retail channel.
|
||||
|
||||
This kind of strategic process can be configured using *Routes*,
|
||||
featuring *Pull and Push Rules*. Once everything is properly
|
||||
configured, the inventory app can automatically generate transfers
|
||||
following the instructions given by the rules. Yes, Odoo simplifies your
|
||||
life.
|
||||
|
||||
Inside the warehouse
|
||||
====================
|
||||
|
||||
Let’s imagine a generic warehouse plan, where you can find receiving
|
||||
docks, a quality control area, storage locations, picking and
|
||||
packing areas, and shipping docks. All products go
|
||||
through all these locations, which also trigger all the route's rules.
|
||||
|
||||
.. image:: use-routes/stock-example.png
|
||||
:align: center
|
||||
:alt: view of a generic warehouse with stock and quality control area
|
||||
|
||||
In this example, vendor trucks unload pallets of ordered goods at receiving docks.
|
||||
Operators then scan the products in the receiving area. Some of these products are sent to a
|
||||
quality control area (those devoted to being used during the manufacturing process, for
|
||||
example), while others are directly stored in their respective locations.
|
||||
|
||||
.. image:: use-routes/push-to-rule-example.png
|
||||
:align: center
|
||||
:alt: view of a generic push to rule when receiving products
|
||||
|
||||
Here is an example of a fulfillment route. In the morning, items are picked
|
||||
for all the orders that need to be prepared during the day. These items
|
||||
are picked from storage locations and moved to the picking area, close
|
||||
to where the orders are packed. Then, the orders are packed in their
|
||||
respective boxes and conveyors bring them close to the shipping docks,
|
||||
ready to be delivered to customers.
|
||||
|
||||
.. image:: use-routes/pull-from-rule-example.png
|
||||
:align: center
|
||||
:alt: view of a generic pull from rule when preparing deliveries
|
||||
|
||||
How does it work?
|
||||
=================
|
||||
|
||||
Pull Rules
|
||||
----------
|
||||
|
||||
With *Pull Rules*, a demand for some products triggers procurements,
|
||||
while *Push Rules* are triggered by products arriving in a specific
|
||||
location.
|
||||
|
||||
We can say that *Pull Rules* are used to fulfill a customer
|
||||
order, a sale order. So, Odoo generates a need at the *Customer
|
||||
Location* for each product in the order. Because *Pull Rules*
|
||||
are triggered by a need, Odoo looks for a *Pull Rule* defined on the
|
||||
*Customer Location*. In our case, a delivery order pull rule that
|
||||
transfers products from the *Shipping Area* to the *Customer
|
||||
Location* is found, and a transfer between the two locations is created.
|
||||
|
||||
Then, Odoo finds another pull rule that tries to fulfill the need for
|
||||
the *Shipping Area*: the *Packing Rule* that transfers products from
|
||||
the *Packing Area* to the *Shipping Area*. And, finally, other rules
|
||||
are triggered until a transfer between the *Stock* and the *Picking
|
||||
Area* is created.
|
||||
|
||||
.. note::
|
||||
All these transfers are pre-generated by Odoo, starting from the end and going backwards.
|
||||
While working, the operator process these transfers in the opposite order: first the picking,
|
||||
then the packing, then the delivery order.
|
||||
|
||||
Push Rules
|
||||
----------
|
||||
|
||||
On the other hand, *Push Rules* are much easier to understand. Instead
|
||||
of pre-generating documents based on needs, they are live-triggered when
|
||||
products arrive in a specific location. *Push Rules* basically say: "when a
|
||||
product arrives at a specific location, move it to another location."
|
||||
|
||||
A simple example would be: when a product arrives in the *Receipt
|
||||
Area*, move them to the *Storage Location*. As different rules can be
|
||||
applied to different products, you can assign different storage
|
||||
locations for different products.
|
||||
|
||||
Another rule could be: when products arrive at a location, move them to the
|
||||
*Quality Control Area*. Then, once the quality check is done, move
|
||||
them to their *Storage Location*.
|
||||
|
||||
.. note::
|
||||
*Push Rules* can be triggered only if no *Pull Rule* pre-generated
|
||||
the upstream transfers.
|
||||
|
||||
.. important::
|
||||
Sets of rules like those are called routes. The grouping on the rule
|
||||
defines how products are grouped in the same transfer or not. For
|
||||
example, during the picking operation, all orders are grouped in one
|
||||
transfer, whereas the packing operation respects the grouping per
|
||||
customer order.
|
||||
|
||||
Use Routes and Rules
|
||||
====================
|
||||
|
||||
Since *Routes* are a collection of *Push and Pull Rules*, Odoo
|
||||
helps you manage advanced routes configuration such as:
|
||||
|
||||
- Manage product manufacturing chains;
|
||||
- Manage default locations per product;
|
||||
- Define routes within your warehouse according to business needs, such
|
||||
as quality control, after-sales services, or supplier returns;
|
||||
- Help rental management by generating automated return moves for
|
||||
rented products.
|
||||
|
||||
To configure a route such as one of those above, open the **Inventory
|
||||
Application** and go to :menuselection:`Configuration --> Settings`.
|
||||
Then, enable the *Multi-Step Routes* feature.
|
||||
|
||||
.. image:: use-routes/multi-steps-routes-feature.png
|
||||
:align: center
|
||||
:alt: activation of the multi-steps feature in Odoo Inventory
|
||||
|
||||
.. note::
|
||||
The *Storage Locations* feature is automatically activated with the
|
||||
*Multi-Step Routes*.
|
||||
|
||||
Once this first step is completed, you have the choice between
|
||||
pre-configured routes or custom ones. Both are explained below.
|
||||
|
||||
Pre-configured Routes
|
||||
---------------------
|
||||
|
||||
Odoo’s pre-configured routes are available in the warehouses’ menu. To
|
||||
find it, go to :menuselection:`Inventory --> Configuration -->
|
||||
Warehouses`. There, open your warehouse and edit it to see the
|
||||
pre-configured routes for incoming and outgoing shipments.
|
||||
|
||||
.. image:: use-routes/example-preconfigured-warehouse.png
|
||||
:align: center
|
||||
:alt: preconfigured warehouse in Odoo Inventory
|
||||
|
||||
Some more advanced routes, such as pick-pack-ship, are already
|
||||
configured to make your life easier. Those are based on your choice for
|
||||
shipments. Once you made your choice, head to :menuselection:`Inventory -->
|
||||
Configuration --> Routes` to see the routes Odoo generated for you.
|
||||
|
||||
.. image:: use-routes/preconfigured-routes.png
|
||||
:align: center
|
||||
:alt: view of all the preconfigured routes Odoo offers
|
||||
|
||||
Opening one of those routes allows you to see on what you can apply the route.
|
||||
Here, all the selected product categories in the
|
||||
*YourCompany* warehouse are set up to follow the 3-steps route.
|
||||
|
||||
.. image:: use-routes/routes-example.png
|
||||
:align: center
|
||||
:alt: view of a route example applicable on category and warehouse
|
||||
|
||||
Easier for many businesses, this process might not fit yours. Thus,
|
||||
you can configure custom routes in which you can define your own
|
||||
rules, but also the source and destination location of each action. As
|
||||
an example, here are the rules for the pre-configured route.
|
||||
|
||||
.. image:: use-routes/rules-example.png
|
||||
:align: center
|
||||
:alt: rules example with push & pull actions in Odoo Inventory
|
||||
|
||||
Custom Routes
|
||||
-------------
|
||||
|
||||
To create a custom route, go to :menuselection:`Inventory -->
|
||||
Configuration --> Routes`, click on create, and choose the
|
||||
places where this route can be selected. Of course, combinations are
|
||||
available.
|
||||
|
||||
.. image:: use-routes/advanced-custom-route.png
|
||||
:align: center
|
||||
:alt: view of a pick - pack - ship route as an example
|
||||
|
||||
Each place has a different behavior, so it is important to tick only the
|
||||
useful ones and adapt each route accordingly.
|
||||
|
||||
When applying the route on a product category
|
||||
(:menuselection:`Inventory --> Configuration --> Product Categories`),
|
||||
all the rules configured in the route are applied to **every**
|
||||
product of the category. For example, this can be useful if you use the
|
||||
dropshipping process for all the products from the same category.
|
||||
|
||||
.. image:: use-routes/routes-logistic-tab.png
|
||||
:align: center
|
||||
:alt: view of a route applied to the "all" product category
|
||||
|
||||
The same behavior applies to the warehouses. If you tick *Warehouses*,
|
||||
all the transfers occurring inside the chosen warehouse, and meeting the
|
||||
conditions of the linked rules, then follow that route.
|
||||
|
||||
.. image:: use-routes/applicable-on-warehouse.png
|
||||
:align: center
|
||||
:alt: view of the route menu when selecting applicable on warehouse
|
||||
|
||||
For the *Sales Order Lines*, it is more or less the opposite. You have
|
||||
to choose the route yourself when creating a quotation. This is pretty useful if
|
||||
some products go through different routes.
|
||||
|
||||
.. image:: use-routes/applicable-on-sales-order-lines.png
|
||||
:align: center
|
||||
:alt: view of the route menu when selecting applicable on sales order lines
|
||||
|
||||
If you work with this kind of route, it is important to keep in mind
|
||||
that it must be selected on the sales order, such as below.
|
||||
|
||||
.. image:: use-routes/add-routes-to-sales-lines.png
|
||||
:align: center
|
||||
:alt: view of the menu allowing to add new lines to sales orders
|
||||
|
||||
Then, the route can be chosen on each line of the document.
|
||||
|
||||
.. image:: use-routes/sales-order-lines-routes-application.png
|
||||
:align: center
|
||||
:alt: view of the routes added to the sales orders
|
||||
|
||||
Finally, there are routes that can be applied to products. Those work more or less
|
||||
like the product categories: once selected, you have to
|
||||
manually set on which product it must be applied.
|
||||
|
||||
.. image:: use-routes/applicable-on-products.png
|
||||
:align: center
|
||||
:alt: view of the menu when selecting applicable on products
|
||||
|
||||
To do so, go to :menuselection:`Inventory --> Master Data -->
|
||||
Products` and open the one on which you want to apply the route. Then
|
||||
go to the *Inventory tab* and select the route you’ve created.
|
||||
|
||||
.. image:: use-routes/on-product-route.png
|
||||
:align: center
|
||||
:alt: view of a product form, where the route must be selected
|
||||
|
||||
If, prima facie, the routes’ configuration can appear quite easy, don’t
|
||||
forget that we haven’t set up any rule yet. If not harder to set up, those
|
||||
are vital to have working routings.
|
||||
|
||||
Rules
|
||||
~~~~~
|
||||
|
||||
The rules are to be defined on the routes. To do so, go to
|
||||
:menuselection:`Inventory --> Configuration --> Routes`, then to the *Rules* section,
|
||||
and click on *Add a line* button.
|
||||
|
||||
.. image:: use-routes/add-new-rules.png
|
||||
:align: center
|
||||
:alt: view of the rules menu, where it is possible to add new rules
|
||||
|
||||
The available rules trigger various actions. If Odoo offers *Push* and
|
||||
*Pull* rules, others are also available. Here are some explanations for
|
||||
all of them:
|
||||
|
||||
- **Pull From**: this rule is triggered by a need for the product
|
||||
in a specific location. The need can come from a sale order
|
||||
which has been validated or from a manufacturing order which
|
||||
requires a specific component. When the need appears in the
|
||||
destination location, Odoo generates a picking to fulfill this need.
|
||||
- **Push To**: this rule is triggered by the arrival of some
|
||||
products in the defined source location. In the case you move
|
||||
products to the source location, Odoo generates a picking to move
|
||||
those products to the destination location.
|
||||
- **Pull & Push**: this rule allows generating pickings in the two
|
||||
situations explained above. This means that when products are
|
||||
required at a specific location, a transfer is created from the previous location to fulfill
|
||||
that need. This creates a need in the previous location and a rule is triggered to fulfill
|
||||
it. Once the second need is fulfilled, the products are pushed to the destination location and all the
|
||||
needs are fulfilled.
|
||||
- **Buy**: when products are needed at the destination location, a
|
||||
request for quotation is created to fulfill the need.
|
||||
- **Manufacture**: when products are needed in the source location,
|
||||
a manufacturing order is created to fulfill the need.
|
||||
|
||||
.. image:: use-routes/pull-from-rule-stock-to-packing.png
|
||||
:align: center
|
||||
:alt: overview of a transfer requested between the stock and the packing zone
|
||||
|
||||
You must also define the *Operation Type*. This
|
||||
operation allows defining which kind of picking is created from the
|
||||
rule. With our above screenshot, the created picking is, for example, an
|
||||
internal transfer.
|
||||
|
||||
On the other hand, the *Supply Method*, allows defining what happens at
|
||||
the source location:
|
||||
|
||||
- **Take From Stock**: the products are taken from the available
|
||||
stock of the source location;
|
||||
- **Trigger Another Rule**: the system tries to find a stock rule
|
||||
to bring the products to the source location. The available stock
|
||||
is ignored.
|
||||
- **Take From Stock, if Unavailable, Trigger Another Rule**: the
|
||||
products are taken from the available stock of the source
|
||||
location. If there is no stock available, the system tries to
|
||||
find a rule to bring the products to the source location.
|
||||
|
||||
In the *Scheduling* section, you can determine how Odoo behaves when
|
||||
one of the chain's pickings is rescheduled. In case you decide to
|
||||
**Propagate Rescheduling**, the next move is also to be rescheduled.
|
||||
If you prefer having the choice to reschedule the next move,
|
||||
you can decide to receive an alert in the form of a
|
||||
*next activity*.
|
||||
|
||||
What about a full flow?
|
||||
=======================
|
||||
|
||||
Do you remember our Pick - Pack - Ship custom route? Let’s use it to
|
||||
try a full flow with an advanced custom route.
|
||||
|
||||
First, a quick look at our rules and their supply methods: we have three
|
||||
rules, all **Pull From** rules. The supply methods are the
|
||||
following:
|
||||
|
||||
- **Take From Stock**: When products are needed in WH/Packing Zone,
|
||||
*Picks* (internal transfers from WH/Stock to WH/Packing Zone)
|
||||
are created from WH/Stock to fulfill the need.
|
||||
- **Trigger Another Rule**: When products are needed in WH/Output,
|
||||
*Packs* (internal transfers from WH/Packing Zone to WH/Output)
|
||||
are created from WH/Packing Zone to fulfill the need.
|
||||
- **Trigger Another Rule**: When products are needed in Partner
|
||||
Locations/Customers, Delivery Orders are created from WH/Output
|
||||
to fulfill the need.
|
||||
|
||||
.. image:: use-routes/transfers-overview.png
|
||||
:align: center
|
||||
:alt: overview of all the transfers created by the pick - pack - ship route
|
||||
|
||||
This means that, when a customer orders products, a delivery order is
|
||||
created to fulfill the order.
|
||||
|
||||
.. image:: use-routes/operations-on-transfers.png
|
||||
:align: center
|
||||
:alt: view of the operations created by a pull from transfer
|
||||
|
||||
.. note::
|
||||
If the source document is the same sale order, the status is not the
|
||||
same. In fact, the status is **Waiting Another Operation** if the
|
||||
previous transfer in the list is not done yet.
|
||||
|
||||
.. image:: use-routes/waiting-status.png
|
||||
:align: center
|
||||
:alt: view of the transfers various status at the beginning of the process
|
||||
|
||||
To prepare the order, conveyors need products packed at the output area,
|
||||
so an internal transfer is requested from the packing zone.
|
||||
|
||||
.. image:: use-routes/detailed-operations-2.png
|
||||
:align: center
|
||||
:alt: view of the detailed operations for a transfer between the packing and output zones
|
||||
|
||||
Obviously, the packing zone needs products ready to be packed. So, an
|
||||
internal transfer is requested to the stock and employees can gather the
|
||||
required products from the warehouse.
|
||||
|
||||
.. image:: use-routes/detailed-operations-transfer.png
|
||||
:align: center
|
||||
:alt: view of the detailed operations for a transfer between the stock and packing zones
|
||||
|
||||
As explained in this documentation introduction, the last step in the
|
||||
process (here the delivery order) is the first to be triggered, which
|
||||
then triggers other rules until we reach the first step in the process
|
||||
(here, the internal transfer from to stock to the packing area). Now,
|
||||
everything is ready to be processed so the customer can get the ordered
|
||||
items.
|
||||
|
||||
In our case, the product is delivered to the customer when all the rules
|
||||
have been triggered and the transfers done.
|
||||
|
||||
.. image:: use-routes/transfers-status.png
|
||||
:align: center
|
||||
:alt: view of the transfers' status when all the process is done
|
Before Width: | Height: | Size: 5.3 KiB |
Before Width: | Height: | Size: 5.4 KiB |
Before Width: | Height: | Size: 12 KiB |
@ -0,0 +1,339 @@
|
||||
==========================
|
||||
Routes and Pull/Push Rules
|
||||
==========================
|
||||
|
||||
In inventory management, the supply chain strategy determines when products should be
|
||||
purchased/manufactured, delivered to distribution centers, and made available to the retail
|
||||
channel.
|
||||
|
||||
In Odoo, a product's supply chain strategy can be configured using *Routes*, which feature *Pull
|
||||
and Push Rules*. Once everything is properly configured, the Inventory app can automatically
|
||||
generate transfers following the configured push/pull rules.
|
||||
|
||||
Inside the warehouse
|
||||
====================
|
||||
|
||||
In a generic warehouse, there are receiving docks, a quality control area, storage locations,
|
||||
picking and packing areas, and shipping docks. All products go through all these locations. As the
|
||||
products move through the locations, each location triggers the products' specified route and
|
||||
rules.
|
||||
|
||||
.. image:: use_routes/stock-example.png
|
||||
:align: center
|
||||
:alt: View of a generic warehouse with stock and quality control area.
|
||||
|
||||
In this example, vendor trucks unload pallets of ordered products at the receiving docks. Operators
|
||||
then scan the products in the receiving area. Depending on the product's route and rules, some of
|
||||
these products are sent to a quality control area (for example, products that are components used
|
||||
in the manufacturing process), while others are directly stored in their respective locations.
|
||||
|
||||
.. image:: use_routes/push-to-rule-example.png
|
||||
:align: center
|
||||
:alt: View of a generic push to rule when receiving products.
|
||||
|
||||
Here is an example of a fulfillment route. In the morning, items are picked for all the orders
|
||||
that need to be prepared during the day. These items are picked from storage locations and moved to
|
||||
the picking area, close to where the orders are packed. Then, the orders are packed in their
|
||||
respective boxes and conveyors bring them close to the shipping docks, ready to be delivered to
|
||||
customers.
|
||||
|
||||
.. image:: use_routes/pull-from-rule-example.png
|
||||
:align: center
|
||||
:alt: View of a generic pull from rule when preparing deliveries.
|
||||
|
||||
Pull rules
|
||||
==========
|
||||
|
||||
With *Pull Rules*, a demand for some products triggers procurements, while *Push Rules* are
|
||||
triggered by products arriving in a specific location.
|
||||
|
||||
Pull Rules are used to fulfill a sales order. Odoo generates a need at the *Customer Location* for
|
||||
each product in the order. Because pull rules are triggered by a need, Odoo looks for a pull
|
||||
rule defined on the *Customer Location*.
|
||||
|
||||
In this case, a "delivery order" pull rule that transfers products from the *Shipping Area* to the
|
||||
*Customer Location* is found, and a transfer between the two locations is created.
|
||||
|
||||
Then, Odoo finds another pull rule that tries to fulfill the need for the *Shipping Area*: the
|
||||
"packing" rule that transfers products from the *Packing Area* to the *Shipping Area*. Finally,
|
||||
other pull rules are triggered until a transfer between the *Stock* and the *Picking Area* is
|
||||
created.
|
||||
|
||||
.. note::
|
||||
All these product transfers are automatically generated by Odoo based on the pull rules, starting
|
||||
from the end (the customer location) and going backward (the stock warehouse). While working, the
|
||||
operator processes these transfers in the opposite order: first the picking, then the packing,
|
||||
and finally the delivery order.
|
||||
|
||||
Push rules
|
||||
==========
|
||||
|
||||
On the other hand, *Push Rules* are much easier to understand. Instead of generating documents
|
||||
based on needs, they are triggered in real time when products arrive in a specific location. Push
|
||||
rules basically say: "when a product arrives at a specific location, move it to another location."
|
||||
|
||||
An example of a push rule would be: when a product arrives in the *Receipt Area*, move it to the
|
||||
*Storage Location*. As different push rules can be applied to different products, the user can
|
||||
assign different storage locations for different products.
|
||||
|
||||
Another push rule could be: when products arrive at a location, move them to the *Quality Control
|
||||
Area*. Then, once the quality check is done, move them to their *Storage Location*.
|
||||
|
||||
.. note::
|
||||
Push rules can only be triggered if there are no pull rules that have already generated the
|
||||
product transfers.
|
||||
|
||||
.. important::
|
||||
Sets of push/pull rules like those are called *Routes*. The grouping on the rule decides if
|
||||
products are grouped in the same transfer or not. For example, during the picking operation, all
|
||||
orders and their products are grouped in one transfer, whereas the packing operation respects the
|
||||
grouping per customer order.
|
||||
|
||||
Use routes and rules
|
||||
====================
|
||||
|
||||
Since *Routes* are a collection of *Push and Pull Rules*, Odoo helps you manage advanced route
|
||||
configurations such as:
|
||||
|
||||
- Manage product manufacturing chains.
|
||||
- Manage default locations per product.
|
||||
- Define routes within the stock warehouse according to business needs, such as quality control,
|
||||
after-sales services, or supplier returns.
|
||||
- Help rental management by generating automated return moves for rented products.
|
||||
|
||||
To configure a route for a product, first, open the :guilabel:`Inventory` application and go to
|
||||
:menuselection:`Configuration --> Settings`. Then, in the :guilabel:`Warehouse` section, enable the
|
||||
:guilabel:`Multi-Step Routes` feature and click :guilabel:`Save`.
|
||||
|
||||
.. image:: use_routes/multi-steps-routes-feature.png
|
||||
:align: center
|
||||
:alt: Activate the Multi-Step Routes feature in Odoo Inventory.
|
||||
|
||||
.. note::
|
||||
The :guilabel:`Storage Locations` feature is automatically activated with the
|
||||
:guilabel:`Multi-Step Routes` feature.
|
||||
|
||||
Once this first step is completed, the user can use pre-configured routes that come with Odoo, or
|
||||
they can create custom routes.
|
||||
|
||||
Pre-configured routes
|
||||
---------------------
|
||||
|
||||
To access Odoo's pre-configured routes, go to :menuselection:`Inventory --> Configuration -->
|
||||
Warehouses`. Then, open a warehouse form. In the :guilabel:`Warehouse Configuration` tab, the user
|
||||
can view the warehouse's pre-configured routes for :guilabel:`Incoming Shipments` and
|
||||
:guilabel:`Outgoing Shipments`.
|
||||
|
||||
.. image:: use_routes/example-preconfigured-warehouse.png
|
||||
:align: center
|
||||
:alt: A preconfigured warehouse in Odoo Inventory.
|
||||
|
||||
Some more advanced routes, such as pick-pack-ship, are also available. The user can select the
|
||||
route that best fits their business needs. Once the :guilabel:`Incoming Shipments` and
|
||||
:guilabel:`Outgoing Shipments` routes are set, head to :menuselection:`Inventory --> Configuration
|
||||
--> Routes` to see the specific routes that Odoo generated.
|
||||
|
||||
.. image:: use_routes/preconfigured-routes.png
|
||||
:align: center
|
||||
:alt: View of all the preconfigured routes Odoo offers.
|
||||
|
||||
On the :guilabel:`Routes` page, click on a route to open the route form. In the route form, the
|
||||
user can view which places the route is :guilabel:`Applicable On`. The user can also set the route
|
||||
to only apply on a specific :guilabel:`Company`. This is useful for multi-company environments; for
|
||||
example, a user can have a company and warehouse in Country A and a second company and warehouse in
|
||||
Country B.
|
||||
|
||||
.. image:: use_routes/routes-example.png
|
||||
:align: center
|
||||
:alt: View of a route example applicable on product categories and warehouses.
|
||||
|
||||
At the bottom of the route form, the user can view the specific :guilabel:`Rules` for the route.
|
||||
Each :guilabel:`Rule` has an :guilabel:`Action`, a :guilabel:`Source Location`, and a
|
||||
:guilabel:`Destination Location`.
|
||||
|
||||
.. image:: use_routes/rules-example.png
|
||||
:align: center
|
||||
:alt: An example of rules with push & pull actions in Odoo Inventory.
|
||||
|
||||
Custom Routes
|
||||
-------------
|
||||
|
||||
To create a custom route, go to :menuselection:`Inventory --> Configuration --> Routes`, and click
|
||||
on :guilabel:`Create`. Next, choose the places where this route can be selected. A route can be
|
||||
applicable on a combination of places.
|
||||
|
||||
.. image:: use_routes/advanced-custom-route.png
|
||||
:align: center
|
||||
:alt: View of a pick-pack-ship route.
|
||||
|
||||
Each place has a different behavior, so it is important to tick only the useful ones and adapt each
|
||||
route accordingly. Then, configure the :guilabel:`Rules` of the route.
|
||||
|
||||
If the route is applicable on a product category, the route still needs to be manually set on the
|
||||
product category form by going to :menuselection:`Inventory --> Configuration --> Product
|
||||
Categories`. Then, select the product category and open the form. Next, click :guilabel:`Edit` and
|
||||
under the :guilabel:`Logistics` section, set the :guilabel:`Routes`.
|
||||
|
||||
When applying the route on a product category, all the rules configured in the route are applied to
|
||||
**every** product in the category. This can be helpful if the business uses the dropshipping
|
||||
process for all the products from the same category.
|
||||
|
||||
.. image:: use_routes/routes-logistic-section.png
|
||||
:align: center
|
||||
:alt: View of a route applied to the "all" product category.
|
||||
|
||||
The same behavior applies to the warehouses. If the route can apply to :guilabel:`Warehouses`, all
|
||||
the transfers occurring inside the chosen warehouse that meet the conditions of the route's rules
|
||||
will then follow that route.
|
||||
|
||||
.. image:: use_routes/applicable-on-warehouse.png
|
||||
:align: center
|
||||
:alt: View of the warehouse drop-down menu when selecting applicable on warehouse.
|
||||
|
||||
If the route is applicable on :guilabel:`Sales Order Lines`, it is more or less the opposite. The
|
||||
route must be manually chosen when creating a quotation. This is useful if some products go through
|
||||
different routes.
|
||||
|
||||
Remember to toggle the visibility of the :guilabel:`Route` column on the quotation/sales order.
|
||||
Then, the route can be chosen on each line of the quotation/sales order.
|
||||
|
||||
.. image:: use_routes/add-routes-to-sales-lines.png
|
||||
:align: center
|
||||
:alt: View of the menu allowing to add new lines to sales orders.
|
||||
|
||||
Finally, there are routes that can be applied to products. Those work more or less like the product
|
||||
categories: once selected, the route must be manually set on the product form.
|
||||
|
||||
To set a route on a product, go to :menuselection:`Inventory --> Products --> Products` and select
|
||||
the desired product. Then, go to the :guilabel:`Inventory` tab and under the :guilabel:`Operations`
|
||||
section, select the :guilabel:`Routes`.
|
||||
|
||||
.. image:: use_routes/on-product-route.png
|
||||
:align: center
|
||||
:alt: View of a product form, where the route must be selected.
|
||||
|
||||
.. important::
|
||||
Rules must be set on the route in order for the route to work.
|
||||
|
||||
Rules
|
||||
~~~~~
|
||||
|
||||
The rules are defined on the route form. First, go to :menuselection:`Inventory --> Configuration
|
||||
--> Routes` and open the desired route form. Next, click :guilabel:`Edit` and in the
|
||||
:guilabel:`Rules` section, click on :guilabel:`Add a line`.
|
||||
|
||||
.. image:: use_routes/add-new-rules.png
|
||||
:align: center
|
||||
:alt: View of the rules menu, where it is possible to add new rules.
|
||||
|
||||
The available rules trigger various actions. If Odoo offers *Push* and *Pull* rules, others are
|
||||
also available. Each rule has an :guilabel:`Action`:
|
||||
|
||||
- :guilabel:`Pull From`: this rule is triggered by a need for the product in a specific location.
|
||||
The need can come from a sales order being validated or from a manufacturing order requiring a
|
||||
specific component. When the need appears in the destination location, Odoo generates a picking to
|
||||
fulfill this need.
|
||||
- :guilabel:`Push To`: this rule is triggered by the arrival of some products in the defined source
|
||||
location. In the case of the user moving products to the source location, Odoo generates a picking
|
||||
to move those products to the destination location.
|
||||
- :guilabel:`Pull & Push`: this rule allows the generation of pickings in the two situations
|
||||
explained above. This means that when products are required at a specific location, a transfer is
|
||||
created from the previous location to fulfill that need. This creates a need in the previous
|
||||
location and a rule is triggered to fulfill it. Once the second need is fulfilled, the products
|
||||
are pushed to the destination location and all the needs are fulfilled.
|
||||
- :guilabel:`Buy`: when products are needed at the destination location, a request for quotation is
|
||||
created to fulfill the need.
|
||||
- :guilabel:`Manufacture`: when products are needed in the source location, a manufacturing order
|
||||
is created to fulfill the need.
|
||||
|
||||
.. image:: use_routes/pull-from-rule-stock-to-packing.png
|
||||
:align: center
|
||||
:alt: Overview of a "Pull From" rule that creates a transfer between the stock and the packing
|
||||
zone.
|
||||
|
||||
The :guilabel:`Operation Type` must also be defined on the rule. This defines which kind of picking
|
||||
is created from the rule.
|
||||
|
||||
If the rule's :guilabel:`Action` is set to :guilabel:`Pull From` or :guilabel:`Pull & Push`, a
|
||||
:guilabel:`Supply Method` must be set. The :guilabel:`Supply Method` defines what happens at the
|
||||
source location:
|
||||
|
||||
- :guilabel:`Take From Stock`: the products are taken from the available stock of the source
|
||||
location.
|
||||
- :guilabel:`Trigger Another Rule`: the system tries to find a stock rule to bring the products to
|
||||
the source location. The available stock is ignored.
|
||||
- :guilabel:`Take From Stock, if Unavailable, Trigger Another Rule`: the products are taken from
|
||||
the available stock of the source location. If there is no stock available, the system tries to
|
||||
find a rule to bring the products to the source location.
|
||||
|
||||
In the *Scheduling* section, you can determine how Odoo behaves when one of the chain's pickings is
|
||||
rescheduled. In case you decide to **Propagate Rescheduling**, the next move is also to be
|
||||
rescheduled.
|
||||
|
||||
If you prefer having the choice to reschedule the next move, you can decide to receive an alert in
|
||||
the form of a *next activity*.
|
||||
|
||||
Sample full route flow
|
||||
======================
|
||||
|
||||
In this example, let's use a custom *Pick - Pack - Ship* route to try a full flow with an advanced
|
||||
custom route.
|
||||
|
||||
First, a quick look at the route's rules and their supply methods. There are three rules, all
|
||||
:guilabel:`Pull From` rules. The :guilabel:`Supply Methods` for each rule are the following:
|
||||
|
||||
- :guilabel:`Take From Stock`: When products are needed in the :guilabel:`WH/Packing Zone`, *picks*
|
||||
(internal transfers from :guilabel:`WH/Stock` to :guilabel:`WH/Packing Zone`) are created from
|
||||
:guilabel:`WH/Stock` to fulfill the need.
|
||||
- :guilabel:`Trigger Another Rule`: When products are needed in :guilabel:`WH/Output`, *packs*
|
||||
(internal transfers from :guilabel:`WH/Packing Zone` to :guilabel:`WH/Output`) are created from
|
||||
:guilabel:`WH/Packing Zone` to fulfill the need.
|
||||
- :guilabel:`Trigger Another Rule`: When products are needed in :guilabel:`Partner
|
||||
Locations/Customers`, *delivery orders* are created from :guilabel:`WH/Output` to fulfill the
|
||||
need.
|
||||
|
||||
.. image:: use_routes/transfers-overview.png
|
||||
:align: center
|
||||
:alt: Overview of all the transfers created by the pick - pack - ship route.
|
||||
|
||||
This means that, when a customer orders products that have a *pick - pack - ship* route set on it,
|
||||
a delivery order is created to fulfill the order.
|
||||
|
||||
.. image:: use_routes/operations-on-transfers.png
|
||||
:align: center
|
||||
:alt: View of the operations created by a pull from transfer.
|
||||
|
||||
.. note::
|
||||
If the source document for multiple tranfers is the same sales order, the status is not the same.
|
||||
The status will be :guilabel:`Waiting Another Operation` if the previous transfer in the list is
|
||||
not done yet.
|
||||
|
||||
.. image:: use_routes/waiting-status.png
|
||||
:align: center
|
||||
:alt: View of the transfers' various statuses at the beginning of the process.
|
||||
|
||||
To prepare the delivery order, packed products are needed at the output area, so an internal
|
||||
transfer is requested from the packing zone.
|
||||
|
||||
.. image:: use_routes/detailed-operations-2.png
|
||||
:align: center
|
||||
:alt: View of the detailed operations for a transfer between the packing and output zones.
|
||||
|
||||
Obviously, the packing zone needs products ready to be packed. So, an internal transfer is
|
||||
requested to the stock and employees can gather the required products from the warehouse.
|
||||
|
||||
.. image:: use_routes/detailed-operations-transfer.png
|
||||
:align: center
|
||||
:alt: View of the detailed operations for a transfer between the stock and packing zones.
|
||||
|
||||
As explained in the introduction of the documentation, the last step in the process (for this
|
||||
route, the delivery order) is the first to be triggered, which then triggers other rules until we
|
||||
reach the first step in the process (here, the internal transfer from the stock to the packing
|
||||
area). Now, everything is ready to be processed so the customer can get the ordered items.
|
||||
|
||||
In this example, the product is delivered to the customer when all the rules have been triggered and
|
||||
the transfers are done.
|
||||
|
||||
.. image:: use_routes/transfers-status.png
|
||||
:align: center
|
||||
:alt: View of the transfers' statuses when the route is completed.
|
Before Width: | Height: | Size: 9.0 KiB After Width: | Height: | Size: 9.0 KiB |
Before Width: | Height: | Size: 6.0 KiB After Width: | Height: | Size: 6.0 KiB |
Before Width: | Height: | Size: 11 KiB After Width: | Height: | Size: 11 KiB |
Before Width: | Height: | Size: 6.1 KiB After Width: | Height: | Size: 6.1 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 16 KiB |
Before Width: | Height: | Size: 29 KiB After Width: | Height: | Size: 29 KiB |
Before Width: | Height: | Size: 8.0 KiB After Width: | Height: | Size: 8.0 KiB |
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 17 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 14 KiB After Width: | Height: | Size: 14 KiB |
Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 74 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
Before Width: | Height: | Size: 77 KiB After Width: | Height: | Size: 77 KiB |
Before Width: | Height: | Size: 13 KiB After Width: | Height: | Size: 13 KiB |
Before Width: | Height: | Size: 5.3 KiB After Width: | Height: | Size: 5.3 KiB |
Before Width: | Height: | Size: 6.0 KiB After Width: | Height: | Size: 6.0 KiB |
Before Width: | Height: | Size: 79 KiB After Width: | Height: | Size: 79 KiB |
Before Width: | Height: | Size: 8.5 KiB After Width: | Height: | Size: 8.5 KiB |
Before Width: | Height: | Size: 6.7 KiB After Width: | Height: | Size: 6.7 KiB |
Before Width: | Height: | Size: 5.4 KiB After Width: | Height: | Size: 5.4 KiB |
@ -2,44 +2,131 @@
|
||||
What is a Putaway Rule?
|
||||
========================
|
||||
|
||||
A good warehouse implementation takes care that products automatically move to their appropriate destination location. To make that process easier, Odoo uses *Putaway rules*. But what is a putaway rule? Putaway is the process of taking products off the receiving shipments and directly putting them into the most appropriate location.
|
||||
A good warehouse implementation makes sure that products automatically move to their appropriate
|
||||
destination location. To make that process easier, Odoo uses *Putaway Rules*. Putaway is the
|
||||
process of taking products from the received shipments and putting them into the appropriate
|
||||
location.
|
||||
|
||||
If, for example, a warehouse contains volatile substances, it is important to make sure that certain products are not stored close to each other because of a potential chemical reaction. That’s where putaway rules intervene, to avoid storing products wrongly.
|
||||
If, for example, a warehouse contains volatile substances, it is important to make sure that
|
||||
certain products are not stored close to each other because of a potential chemical reaction.
|
||||
That's where putaway rules intervene, to avoid storing products wrongly.
|
||||
|
||||
Configuration
|
||||
==============
|
||||
|
||||
In the *Inventory* app, go to :menuselection:`Configuration --> Settings` and activate the
|
||||
*Multi-Step Routes*. By doing so, the *Storage Locations* will be automatically activated.
|
||||
In the :guilabel:`Inventory` app, go to :menuselection:`Configuration --> Settings` and activate
|
||||
the :guilabel:`Multi-Step Routes` feature. By doing so, the :guilabel:`Storage Locations` feature
|
||||
is also automatically activated.
|
||||
|
||||
.. image:: putaway/putaw1.png
|
||||
.. image:: putaway/activate-multi-step-routes.png
|
||||
:align: center
|
||||
:alt: Activate Multi-Step Routes in Inventory configuration settings.
|
||||
|
||||
Setting up a Putaway Rule
|
||||
==========================
|
||||
Setting up a putaway rule
|
||||
=========================
|
||||
|
||||
In some cases, like for a retail shop storing vegetables and fruits, we have to store products in different locations to maintain product quality.
|
||||
In some cases, like for a retail shop storing fruits and vegetables, products should be stored in
|
||||
different locations depending on several factors like frequency, size, product category, specific
|
||||
environment needs, and so on.
|
||||
|
||||
Let’s suppose there are one warehouse location *WH/Stock* and two sub-locations *WH/Stock/Vegetables* and *WH/Stock/Fruits*.
|
||||
In this example, suppose there is one warehouse location, **WH/Stock**, with the following
|
||||
sub-locations:
|
||||
|
||||
To manage those locations, we will create putaway rules. To do so, open the *Inventory* app and go
|
||||
to :menuselection:`Configuration --> Putaway Rules`. Then, click on create and configure your first
|
||||
rule indicating the main location the product will enter before being redirected to the right
|
||||
location.
|
||||
- WH/Stock/Pallets
|
||||
|
||||
.. note::
|
||||
The putaway rules can be defined either per product or per product category.
|
||||
- WH/Stock/Pallets/PAL1
|
||||
- WH/Stock/Pallets/PAL2
|
||||
- WH/Stock/Pallets/PAL3
|
||||
|
||||
.. image:: putaway/putaw2.png
|
||||
- WH/Stock/Shelf 1
|
||||
|
||||
- WH/Stock/Shelf 2
|
||||
|
||||
- WH/Stock/Shelf 2/Small Refrigerator
|
||||
|
||||
- WH/Stock/Shelf 3
|
||||
|
||||
Manage those locations with putaway rules. To create a putaway rule, open the :guilabel:`Inventory`
|
||||
app and go to :menuselection:`Configuration --> Putaway Rules`. Then, click on :guilabel:`Create`
|
||||
and configure a putaway rule that indicated the main location the product will enter before being
|
||||
redirected to the right storage location.
|
||||
|
||||
.. important::
|
||||
The putaway rules can be defined either per product/product category and/or package type (the
|
||||
:guilabel:`Packages` setting must be enabled for that). Putaway rules are read sequentially
|
||||
until a match is found.
|
||||
|
||||
Take the following example:
|
||||
|
||||
- If water (category All/drinks) is received, whatever the package, it will be redirected to
|
||||
WH/Stock/Shelf 2/Small Refrigerator.
|
||||
- If orange juice cans, packaged in boxes, are received, they will be redirected to
|
||||
WH/Stock/Shelf 2.
|
||||
- If water or apple juice bottles, packaged in boxes, are received, they will be redirected to
|
||||
WH/Stock/Shelf 3.
|
||||
- If a pallet of lemonade cans are receieved, it will be redirected to WH/Stock/Pallets/PAL1.
|
||||
|
||||
.. image:: putaway/putaway-example.png
|
||||
:align: center
|
||||
:alt: Some examples of putaway rules.
|
||||
|
||||
Now, if I purchase apples and carrots to my supplier, they will be grouped in the same receipt but redirected to the right location automatically, thanks to putaway rules. This information is available from *Inventory Report*, under the reporting menu.
|
||||
========================
|
||||
Using Storage Categories
|
||||
========================
|
||||
|
||||
.. image:: putaway/putaw3.png
|
||||
A *Storage Category* is an extra location attribute. Storage categories allow the user to define
|
||||
the quantity of products that can be stored in the location and how the location will be selected
|
||||
with putaway rules.
|
||||
|
||||
Configuration
|
||||
==============
|
||||
|
||||
In the :guilabel:`Inventory` app, go to :menuselection:`Configuration --> Settings` and activate
|
||||
the :guilabel:`Storage Categories` feature. By doing so, the :guilabel:`Storage Locations` feature
|
||||
is also automatically activated.
|
||||
|
||||
Create a Storage Category
|
||||
=========================
|
||||
|
||||
To create a storage category, go to :menuselection:`Inventory --> Configuration --> Storage
|
||||
Categories` and click :guilabel:`Create`. Then, click :guilabel:`Save` and click :guilabel:`Storage
|
||||
Categories` or go to :menuselection:`Configuration --> Storage Categories` to create a new storage
|
||||
category.
|
||||
|
||||
.. image:: putaway/storage-category.png
|
||||
:align: center
|
||||
:alt: Create Storage Categories inside Odoo Inventory configuration settings.
|
||||
|
||||
.. image:: putaway/putaw4.png
|
||||
:align: center
|
||||
First, click :guilabel:`Create` and type a name for the storage category.
|
||||
|
||||
.. image:: putaway/putaw5.png
|
||||
Then, there are options to limit the capacity by weight, by product, or by package type. The
|
||||
:guilabel:`Allow New Product` field defines when the location is considered available to store a
|
||||
product:
|
||||
|
||||
- :guilabel:`If location is empty`: a product can be added there only if the location is empty.
|
||||
- :guilabel:`If products are the same`: a product can be added there only if the same product is
|
||||
already there.
|
||||
- :guilabel:`Allow mixed products`: several different products can be stored in this location at
|
||||
the same time.
|
||||
|
||||
Once the storage category settings are saved, the storage category can be linked to a location.
|
||||
|
||||
.. image:: putaway/location-storage-category.png
|
||||
:align: center
|
||||
:alt: When a Storage Category is created, it can be linked to a warehouse location.
|
||||
|
||||
Storage categories in putaway rules
|
||||
===================================
|
||||
|
||||
To continue the example from above, apply the "High Frequency Pallets" on the PAL1 and PAL2
|
||||
locations and rework the putaway rules as follows:
|
||||
|
||||
Assume one pallet of lemonade cans is received:
|
||||
|
||||
- If PAL1 and PAL2 are empty, the pallet will be redirected to WH/Stock/Pallets/PAL1.
|
||||
- If PAL1 is full, the pallet will be redirected to WH/Stock/Pallets/PAL2.
|
||||
- If PAL1 and 2 are full, the pallet will be redirected to WH/Stock/Pallets.
|
||||
|
||||
.. image:: putaway/smart-putaways.png
|
||||
:align: center
|
||||
:alt: Storage Categories used in a variety of putaway rules.
|
||||
|
Before Width: | Height: | Size: 6.3 KiB After Width: | Height: | Size: 6.3 KiB |
After Width: | Height: | Size: 8.6 KiB |
Before Width: | Height: | Size: 8.7 KiB |