[IMP] inventory: make the structure consistent with the 'Odoo 9 Documentation' spreadsheet
This commit is contained in:
Yannick Tivisse
@@ -0,0 +1,263 @@
|
||||
:code-column:
|
||||
|
||||
=================================
|
||||
Double-Entry Inventory Management
|
||||
=================================
|
||||
|
||||
A double-entry inventory has no stock input, output (disparition of products)
|
||||
or transformation. Instead, all operations are stock moves between locations
|
||||
(possibly virtual).
|
||||
|
||||
.. h:div:: doc-aside chart-of-locations
|
||||
|
||||
.. placeholder
|
||||
|
||||
Operations
|
||||
==========
|
||||
|
||||
Stock moves represent the transit of goods and materials between locations.
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
Production Order
|
||||
Consume:
|
||||
| 2 Wheels: Stock → Production
|
||||
| 1 Bike Frame: Stock → Production
|
||||
Produce:
|
||||
1 Bicycle: Production → Stock
|
||||
Configuration:
|
||||
| Stock: the location the Manufacturing Order is initiated from
|
||||
| Production: on the product form, field "Production Location"
|
||||
|
||||
Drop-shipping
|
||||
1 Bicycle: Supplier → Customer
|
||||
|
||||
Configurarion:
|
||||
| Supplier: on the product form
|
||||
| Customer: on the sale order itself
|
||||
Client Delivery
|
||||
Pick
|
||||
1 Bicycle: Stock → Packing Zone
|
||||
Pack
|
||||
1 Bicycle: Packing Zone → Output
|
||||
Shipping
|
||||
1 Bicycle: Output → Customer
|
||||
Configuration:
|
||||
| on the pick+pack+ship route for the warehouse
|
||||
Inter-Warehouse transfer
|
||||
Transfer:
|
||||
| 1 Bicycle: Warehouse 1 → Transit
|
||||
| 1 Bicycle: Transit → Warehouse 2
|
||||
Configuration:
|
||||
| Warehouse 2: the location the transfer is initiated from
|
||||
| Warehouse 1: on the transit route
|
||||
Broken Product (scrapped)
|
||||
1 Bicycle: Warehouse → Scrap
|
||||
|
||||
Configuration:
|
||||
Scrap: Scrap Location when creating the scrapping
|
||||
Inventory
|
||||
Missing products in inventory
|
||||
1 Bicycle: Warehouse → Inventory Loss
|
||||
Extra products in inventory
|
||||
1 Bicycle: Inventory Loss → Warehouse
|
||||
Configuration:
|
||||
Inventory Loss: "Inventory Location" field on the product
|
||||
Reception
|
||||
| 1 Bicycle: Supplier → Input
|
||||
| 1 Bicycle: Input → Stock
|
||||
|
||||
Configuration:
|
||||
| Supplier: purchase order supplier
|
||||
| Input: "destination" field on the purchase order
|
||||
|
||||
Analysis
|
||||
========
|
||||
|
||||
Inventory analysis can use products count or products value (= number of
|
||||
products * product cost).
|
||||
|
||||
For each inventory location, multiple data points can be analysed:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<ul class="highlighter-list" data-target=".analysis-table">
|
||||
<li data-highlight=".analysis-valuation">inventory valuation</li>
|
||||
<li data-highlight=".analysis-creation">
|
||||
value creation (difference between the value of manufactured products
|
||||
and the cost of raw materials used during manufacturing) (negative)
|
||||
</li>
|
||||
<li data-highlight=".analysis-lost">value of lost/stolen products</li>
|
||||
<li data-highlight=".analysis-scrapped">value of scrapped products</li>
|
||||
<li data-highlight=".analysis-delivered">value of products delivered to clients over a period</li>
|
||||
<li data-highlight=".analysis-received">value of products received from suppliers over a period (negative)</li>
|
||||
<li data-highlight=".analysis-transit">value of products in transit between locations</li>
|
||||
</ul>
|
||||
|
||||
.. h:div:: doc-aside analysis-table
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<table class="table table-condensed highlighter-target">
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Location</th> <th class="text-right">Value</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr class="analysis-valuation">
|
||||
<th>Physical Locations</th> <td class="text-right">$1,000</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th> Warehouse 1</th> <td class="text-right">$600</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th> Warehouse 2</th> <td class="text-right">$400</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Partner Locations</th> <td class="text-right">- $1,500</td>
|
||||
</tr>
|
||||
<tr class="analysis-delivered">
|
||||
<th> Customers</th> <td class="text-right">$2,000</td>
|
||||
</tr>
|
||||
<tr class="analysis-received">
|
||||
<th> Suppliers</th> <td class="text-right">- $3,500</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Virtual Locations</th> <td class="text-right">$500</td>
|
||||
</tr>
|
||||
<tr class="analysis-transit">
|
||||
<th> Transit Location</th> <td class="text-right">$600</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<th> Initial Inventory</th> <td class="text-right">$0</td>
|
||||
</tr>
|
||||
<tr class="analysis-lost">
|
||||
<th> Inventory Loss</th> <td class="text-right">$350</td>
|
||||
</tr>
|
||||
<tr class="analysis-scrapped">
|
||||
<th> Scrapped</th> <td class="text-right">$550</td>
|
||||
</tr>
|
||||
<tr class="analysis-creation">
|
||||
<th> Manufacturing</th> <td class="text-right">- $1,000</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
Procurements & Procurement Rules
|
||||
================================
|
||||
|
||||
A procurement is a request for a specific quantity of products to a specific
|
||||
location. They can be created manually or automatically triggered by:
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
New sale orders
|
||||
Effect
|
||||
A procurement is created at the customer location for every product
|
||||
ordered by the customer (you have to deliver the customer)
|
||||
Configuration
|
||||
Procurement Location: on the customer, field "Customer Location" (property)
|
||||
Minimum Stock Rules
|
||||
Effect
|
||||
A procurement is created at the rule's location.
|
||||
Configuration
|
||||
Procurement location: on the rule, field "Location"
|
||||
Procurement rules
|
||||
Effect
|
||||
A new procurement is created on the rule's source location
|
||||
|
||||
*Procurement rules* describe how procurements on specific locations should be
|
||||
fulfilled e.g.:
|
||||
|
||||
* where the product should come from (source location)
|
||||
* whether the procurement is :abbr:`MTO (Made To Order)` or :abbr:`MTS (Made
|
||||
To Stock)`
|
||||
|
||||
.. h:div:: doc-aside
|
||||
|
||||
.. todo:: needs schema thing from FP
|
||||
|
||||
Routes
|
||||
======
|
||||
|
||||
Procurement rules are grouped in routes. Routes define paths the product must
|
||||
follow. Routes may be applicable or not, depending on the products, sales
|
||||
order lines, warehouse,...
|
||||
|
||||
To fulfill a procurement, the system will search for rules belonging to routes
|
||||
that are defined in (by order of priority):
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
Warehouses
|
||||
Warehouse Route Example: Pick → Pack → Ship
|
||||
|
||||
Picking List:
|
||||
Pick Zone → Pack Zone
|
||||
Pack List:
|
||||
Pack Zone → Gate A
|
||||
Delivery Order:
|
||||
Gate A → Customer
|
||||
|
||||
Routes that describe how you organize your warehouse should be defined on the warehouse.
|
||||
A Product
|
||||
Product Route Example: Quality Control
|
||||
|
||||
Reception:
|
||||
Supplier → Input
|
||||
Confirmation:
|
||||
Input → Quality Control
|
||||
Storage:
|
||||
Quality Control → Stock
|
||||
|
||||
Product Category
|
||||
Product Category Route Example: cross-dock
|
||||
|
||||
Reception:
|
||||
Supplier → Input
|
||||
Cross-Docks:
|
||||
Input → Output
|
||||
Delivery:
|
||||
Output → Customer
|
||||
Sale Order Line
|
||||
Sale Order Line Example: Drop-shipping
|
||||
|
||||
Order:
|
||||
Supplier → Customer
|
||||
|
||||
Push Rules
|
||||
==========
|
||||
|
||||
Push rules trigger when products enter a specific location. They automatically
|
||||
move the product to a new location. Whether a push rule can be used depends on
|
||||
applicable routes.
|
||||
|
||||
.. rst-class:: alternatives doc-aside
|
||||
|
||||
Quality Control
|
||||
* Product lands in Input
|
||||
* Push 1: Input → Quality Control
|
||||
* Push 2: Quality Control → Stock
|
||||
Warehouse Transit
|
||||
* Product lands in Transit
|
||||
* Push: Transit → Warehouse 2
|
||||
|
||||
Procurement Groups
|
||||
==================
|
||||
|
||||
Routes and rules define inventory moves. For every rule, a document type is
|
||||
provided:
|
||||
|
||||
* Picking
|
||||
* Packing
|
||||
* Delivery Order
|
||||
* Purchase Order
|
||||
* ...
|
||||
|
||||
Moves are grouped within the same document type if their procurement group and
|
||||
locations are the same.
|
||||
|
||||
A sale order creates a procurement group so that pickings and delivery orders
|
||||
of the same order are grouped. But you can define specific groups on
|
||||
reordering rules too. (e.g. to group purchases of specific products together)
|
||||
@@ -0,0 +1,105 @@
|
||||
=============
|
||||
Terminologies
|
||||
=============
|
||||
|
||||
- **Warehouse**: A warehouse in Odoo is a location where you store
|
||||
products. It is either a physical or a virtual warehouse. It
|
||||
could be a store or a repository.
|
||||
|
||||
- **Location**: Locations are used to structure storage zones within a
|
||||
warehouse. In addition to internal locations (your warehouse),
|
||||
Odoo has locations for suppliers, customers, inventory loss
|
||||
counter-parts, etc.
|
||||
|
||||
- **Lots**: Lots are a batch of products identified with a unique
|
||||
barcode or serial number. All items of a lot are from the same
|
||||
product. (e.g. a set of 24 bottle) Usually, lots come from
|
||||
manufacturing order batches or procurements.
|
||||
|
||||
- **Serial Number**: A serial number is a unique identifier of a
|
||||
specific product. Technically, serial numbers are similar to
|
||||
having a lot of 1 unique item.
|
||||
|
||||
- **Unit of Measure**: Define how the quantity of products is
|
||||
expressed. Meters, Pounds, Pack of 24, Kilograms,… Unit of
|
||||
measure of the same category (ex: size) can be converted to each
|
||||
others (m, cm, mm) using a fixed ratio.
|
||||
|
||||
- **Consumable**: A product for which you do not want to manage the
|
||||
inventory level (no quantity on hand or forecasted) but that you
|
||||
can receive and deliver. When this product is needed Odoo suppose
|
||||
that you always have enough stock.
|
||||
|
||||
- **Stockable**: A product for which you want to manage the inventory
|
||||
level.
|
||||
|
||||
- **Package:** A package contains several products (identified by their
|
||||
serial number/lots or not). Example: a box containing knives and
|
||||
forks.
|
||||
|
||||
- **Procurement**: A procurement is a request for a specific quantity
|
||||
of products to a specific location. Procurement are automatically
|
||||
triggered by other documents: Sale orders, Minimum Stock Rules,
|
||||
and Procurement rules. You can trigger the procurement manually.
|
||||
When procurements are triggered automatically, you should always
|
||||
pay attention for the exceptions (e.g. a product should be
|
||||
purchased from a vendor, but no supplier is defined).
|
||||
|
||||
- **Routes**: Routes define paths the product must follow. Routes may
|
||||
be applicable or not, depending on the products, sales order
|
||||
lines, warehouse,… To fulfill a procurement, the system will
|
||||
search for rules belonging to routes that are defined in the
|
||||
related product/sale order.
|
||||
|
||||
- **Push Rules**: Push rules trigger when products enter a specific
|
||||
location. They automatically move the product to a new location.
|
||||
Whether a push rule can be used depends on applicable routes.
|
||||
|
||||
- **Procurement Rules** or **Pull Rules**: Procurement rules describe
|
||||
how procurements on specific locations should be fulfilled e.g.:
|
||||
where the product should come from (source location), whether the
|
||||
procurement is MTO or MTS,...
|
||||
|
||||
- **Procurement Group**: Routes and rules define inventory moves. For
|
||||
every rule, a document type is provided: Picking, Packing,
|
||||
Delivery Order, Purchase Order,… Moves are grouped within the
|
||||
same document type if their procurement group and locations are
|
||||
the same.
|
||||
|
||||
- **Stock Moves**: Stock moves represent the transit of goods and
|
||||
materials between locations.
|
||||
|
||||
- **Quantity On Hand**: The quantity of a specific product that is
|
||||
currently in a warehouse or location.
|
||||
|
||||
- **Forecasted Quantity**: The quantity of products you can sell for a
|
||||
specific warehouse or location. It is defined as the Quantity on
|
||||
Hand - Future Delivery Orders + Future incoming shipments +
|
||||
Future manufactured units.
|
||||
|
||||
- **Reordering Rules**: It defines the conditions for Odoo to
|
||||
automatically trigger a request for procurement (buying at a
|
||||
supplier or launching a manufacturing order). It is triggered
|
||||
when the forecasted quantity meets the minimum stock rule.
|
||||
|
||||
- **Cross-Dock**: Cross-docking is a practice in the logistics of
|
||||
unloading materials from an incoming semi-trailer truck or
|
||||
railroad car and loading these materials directly into outbound
|
||||
trucks, trailers, or rail cars, with no storage in between. (does
|
||||
not go to the stock, directly from incoming to packing zone)
|
||||
|
||||
- **Drop-Shipping**: move products from the vendor/manufacturer
|
||||
directly to the customer (could be retailer or consumer) without
|
||||
going through the usual distribution channels. Products are sent
|
||||
directly from the vendor to the customer, without passing through
|
||||
your own warehouse.
|
||||
|
||||
- **Removal Strategies**: the strategy to use to select which product
|
||||
to pick for a specific operation. Example: FIFO, LIFO, FEFO.
|
||||
|
||||
- **Putaway Strategies**: the strategy to use to decide in which
|
||||
location a specific product should be set when arriving
|
||||
somewhere. (example: cables goes in rack 3, storage A)
|
||||
|
||||
- **Scrap**: A product that is broken or outdated. Scrapping a product
|
||||
removes it from the stock.
|
||||
Reference in New Issue
Block a user