initial commit 2

2 files changed, 96 insertions, 0 deletions

diff --git a/addons/purchase/doc/average.rst b/addons/purchase/doc/average.rst
new file mode 100644
index 00000000..021567f0
--- /dev/null
+++ b/addons/purchase/doc/average.rst
@@ -0,0 +1,46 @@
+Average price
+
+
+Normal case:
+------------
+
+= When the product is purchased by purchase order and leaves towards a customer with a delivery order.  We assume also 
+that accounting entries are generated in real-time.  
+
+- When the products are received, the stock move gets the unit price and UoM of the purchase order in company currency.  The standard price of the product is updated with 
+(qty available * standard price + incoming qty * purchase price) / (qty available + incoming qty)
+- In the stock journal, the accounting items will be generated based on this (price on move is price of purchase order)
+- When a delivery order is made, it is going out at cost price (= average price which was updated during incoming move)
+- When generating outgoing accounting entries, this is the total amount based on this average cost price
+
+
+Case of production: 
+-------------------
+In case of produced goods, the incoming stock move of the finished product and accounting entries can not just invent a cost price like the sum of the cost price of the parts in the BoM, as cost methods tend to be a lot more complicated than this. 
+When the finished good is produced, we will put the cost price from the product.  
+
+In the product form there is a link next to the cost price where the user can update it.  This will also generate accounting entries as the stock will be valued differently.  
+
+
+Case of no purchase order
+-------------------------
+When no purchase order is given, the price on the stock move and generated entries is the cost price on the product
+
+
+Returned Goods / Scrap / ...
+----------------------------
+For returning goods to supplier, the price on the original purchase order is put on the stock and account moves.  That way, this would have the same effect as cancelling the original in move.  
+Scrap is an outgoing move at cost price.   
+
+
+Negative stock
+--------------
+If your stock is negative and you receive, the price of the product becomes the price on the purchase order.  
+
+Extra
+-----
+- standard price, costing method and valuation (real_time or manual) are properties.  This means it is possible to use the same product in different companies with different price, valuation and costing methods. 
+
+- UoMs: On the stock move, the price is in units of the stock move, so this will get converted to the product UoM and reverse
+
+- Currency: On the stock move, the currency is the company currency
diff --git a/addons/purchase/doc/fifolifo.rst b/addons/purchase/doc/fifolifo.rst
new file mode 100644
index 00000000..18cb9371
--- /dev/null
+++ b/addons/purchase/doc/fifolifo.rst
@@ -0,0 +1,50 @@
+FIFO/LIFO
+
+In order to activate FIFO/LIFO, the costing method in the product form should be fifo/lifo.  This is only possible when cost methods are checked under Settings > Purchase
+
+
+
+Normal case:
+------------
+
+= When product is purchased by purchase order and leaves towards a customer with a delivery order.  We assume also 
+that accounting entries are generated in real-time.  
+
+- When product is received, the stock move gets the unit price and UoM of the purchase order
+- In the stock journal, the accounting items will be generated based on this.  
+- When a delivery order is made, the FIFO/LIFO algorithm is used to check which in moves correspond to this out move.  A weighted average is calculated 
+based on the different in moves which would theoretically have gone out according to the FIFO/LIFO algorithm.  This average becomes also the new cost price on the product.  
+Technically, these calculated matchings are saved in stock_move_matching which makes further FIFO/LIFO calculations easier.  
+- When generating accounting entries, the stock.move.matching table is used, to generate 1 account move line per matching.  That way, one stock move will have one account 
+move with multiple account move lines with the amounts from the matchings.   
+
+
+Case of production: 
+-------------------
+In case of produced goods, the incoming stock move of the finished product and accounting entries can not just invent a cost price like the sum of the cost price of the parts in the BoM, as costing methods tend to be a lot more complicated than this. 
+On the stock move, we will put the cost price of the product.  
+
+Case of no purchase order
+-------------------------
+When no purchase order is given, the price on the stock move and generated entries is the standard price on the product.  
+
+
+Returned Goods / Scrap / ...
+----------------------------
+Returned goods to supplier have the same calculations as a normal out, same with scrap.  
+
+
+Negative stocks
+---------------
+When an out move makes the stock (quantity on hand) become negative, the cost price of the product is not updated and stock move matchings will only be created for the moves that can be matched.  (until stock is zero)  If the quantity on hand became negative and afterwards we get an incoming move, the system will try to match the previous outgoing move(s) as much as possible with the incoming move.  These matches will generate also the necessary accounting entries.  
+
+
+Inter-company
+-------------
+cost price, costing method and valuation (real_time or manual_periodic) are properties (are different according to the company) => when you receive/ship goods, it depends on the company of the stock move as what costing method needs to be used. 
+
+Not possible to create a stock move between two locations of different companies.  You need a transit location in between.  This new constraint removes the requirement for a currency or two prices on one stock move.  
+
+UoMs: As quantities need to be matched between outgoing and ingoing stock moves which can have different UoMs, it will take all these conversions into account
+
+Currency: On the stock move, the currency is the company currency