Timezone conversion error when scheduling delivery/procurement based on SO/PO date
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Addons (MOVED TO GITHUB) |
Fix Released
|
Medium
|
OpenERP Publisher's Warranty Team |
Bug Description
The following is the result of an internal investigation in September 2012, at a time v6.1 was latest stable and v7 was in development. Therefore, "trunk" refers to v7 when it was in development. However, there has been recent reports of this issue (eg. http://
Independently of all this, there is most probably usability improvements needed around lead times especially to have them accessible more clearly (instead of spread out in so many places) and to display them to the user at the time of going from one workflow step to the next (eg. the salesperson should see when the product he is aboutto sell will be at the customer's door; same for purchaser, manufacturer,
Here is the analysis (courtesy of awu):
Version: Web client 6.1.
Suspicion that all the following still remains in v7.
General context
1. Lead times can be defined at company level (Settings > Companies > Configuration):
a. Manufacturing lead time
b. Purchase lead time
c. Security days (= customer delivery lead time)
2. Lead times can be defined at product level:
a. Customer lead time (Product > Procurement & Locations)
b. Manufacturing lead time (Product > Procurement & Locations)
c. Supplier lead time (Product > Supplier > Delivery lead time)
3. SO = Sales order; MO = Manufacturing order; PO = Purchase order; DO = Delivery order; IS = Incoming shipment
4. All products are Made-to-order.
CASE 1: All lead times at zero (company lead times & product lead times at zero)
Case 1.1:
Creating a SO, looking at the related DO
Problem: Order date on DO = order date on SO - 1 day
(Therefore: wrong order date on DO, wrong expected date on DO, wrong date on stock move, wrong scheduled date on stock move. )
Solution: Order date on DO = order date on SO
Problem: Picking policy 'Deliver all at once' as no impact on the expected date of the DO.
Solution: If 'Deliver at once' is chosen the expected date on DO should take the max scheduled date of related stock moves, not the min. (By the way, it is possible to partially deliver a DO even when picking policy is 'Deliver all at once' on related SO. If picking policy is not only for information, this should be considered as a bug).
Case 1.2:
Creating a PO, looking at the related PO lines & IS
Problem: Scheduled date on PO lines = order date on PO - 1 day
Solution: Scheduled date on PO lines = order date on PO
Problem: Order date on IS = order date on PO - 1 day
Solution: Order date on IS = order date on PO
Case 1.3:
With scheduler - Product is to be produced - Creating a SO, looking at the related MO
Problem: Scheduled date on MO = order date on SO - 1 day
Solution: Scheduled date on MO = order date on SO
Problem: date on stock moves for MO (for component and finished product) = order date on SO - 1 day
Solution: date on stock moves for MO = order date on SO
Problem: Scheduled date on stock moves for MO = order creation date (server time stamp)
Solution: Scheduled date on stock moves for MO = order date on SO
Case 1.4:
With scheduler - Product is to be bought - Creating a SO, looking at the related PO
Problem: Order date on PO = order date on SO - 1 day
Solution: Order date on PO = order date on SO
Problem: Scheduled date on PO lines = order date on PO + 1 day
Solution: Scheduled date on PO lines = order date on PO
CASE 2: Working with company lead times (all product lead times at zero)
Case 2.1:
Security days <> 0
Creating a SO, looking at the related DO
Problem:
Expected date on DO = order date on DO - security days
Date on stock moves = order date on DO - security days
Scheduled date on stock moves = order date on DO - security days
(We need to work with negative lead times on company?)
Solution:
Expected date on DO = order date on DO + security days
Date on stock moves = order date on DO + security days
Scheduled date on stock moves = order date on DO + security days
Case 2.2:
Purchase lead time <> 0
Creating a PO, looking at related IS
Problem:
Expected date on IS = order date on IS
Date on stock moves = order date on IS
Scheduled date on stock moves = order date on IS
Solution:
Expected date on IS = order date on IS + purchase lead time
Date on stock moves = order date on IS + purchase lead time
Scheduled date on stock moves = order date on IS + purchase lead time
Case 2.3:
Manufacturing lead time <> 0
Creating a MO, looking at the related stock moves
Problem:
Date for finished product stock move (MO > Finished product > Product to finish) = MO scheduled date
Scheduled date for finished product stock move = MO creation date (server time stamp)
Solution:
Date for finished product stock move = MO scheduled date + manufacturing lead time
Scheduled date for finished product stock move = MO scheduled date + manufacturing lead time
Case 2.4:
Manufacturing lead time <> 0
With scheduler - Product is to be produced - Creating a SO, looking at the related MO
Problem: Scheduled date on MO = order date on SO - 1 day - Manufacturing lead time
Solution:
Scheduled date on MO = order date on SO
Date for finished product stock move = MO scheduled date + manufacturing lead time
Scheduled date for finished product stock move = MO scheduled date + manufacturing lead time
Expected date on DO = order date on SO + Manufacturing lead time + customer lead time
Date on stock moves on DO = order date on SO + Manufacturing lead time + customer lead time
Scheduled date on stock moves on DO = order date on SO + Manufacturing lead time + customer lead time
(If the sales person sells at day D and the product is made-to-order, the delivery can only be done after the product is manufactured and ready, i.e. D + Manufacturing lead time + customer lead time. Currently, MO is scheduled on D - Manufacturing lead time to make sure the product is available on D. This only works if Manufacturing lead time <= D - today. )
Case 2.5:
Purchase lead time <> 0
With scheduler - Product is to be bought - Creating a SO, looking at the related PO
Problem: order date on PO = order date on SO - 1 day - purchase lead time
Solution:
order date on PO = order date on SO
scheduled date on PO line = order date on SO + purchase lead time
Expected date on DO = order date on SO + purchase lead time + customer lead time
Date on stock moves on DO = order date on SO + purchase lead time + customer lead time
Scheduled date on stock moves on DO = order date on SO + purchase lead time + customer lead time
(Same remark as above)
CASE 3: Product lead times (all company lead times at zero)
Case 3.1:
Manufacturing lead time <> 0 (product > procurements and locations > manufacturing lead time)
Creating a MO, looking at related stock moves (component and finished product on MO)
Problem:
Date for finished product stock move (MO > Finished product > Product to finish) = MO scheduled date
Scheduled date for finished product stock move = MO creation date (server time stamp)
Solution:
Date for finished product stock move = MO scheduled date + manufacturing lead time
Scheduled date for finished product stock move = MO scheduled date + manufacturing lead time
Case 3.2:
Purchase lead time <> 0 (product > supplier > lead time)
Creating a PO, looking at related PO lines/IS
Problem:
Scheduled date on PO line = order date on PO - 1 day + purchase lead time
(same as mentioned before)
Solution:
Scheduled date on PO line = order date on PO + purchase lead time
Case 3.3:
Manufacturing lead time <> 0 (product > procurements and locations > manufacturing lead time)
With scheduler - Product is to be produced - Creating a SO, looking at the related MO
Problem: Scheduled date on MO = order date on SO - 1 day
Solution:
Scheduled date on MO = order date on SO
Date for finished product stock move = MO scheduled date + manufacturing lead time
Scheduled date for finished product stock move = MO scheduled date + manufacturing lead time
Case 3.4:
Purchase lead time <> 0 (product > supplier > lead time)
With scheduler - Product is to be bought - Creating a SO, looking at the related PO
Problem: Scheduled date on PO line = order date on SO + 2 days
Solution: Scheduled date on PO line = order date on SO + purchase lead time
===
INCONSISTENCIES
based on http://
Context: The first date is the date mentioned in the book [vs.] the second date is the date we get in reality.
Dates are in the format DD/MM.
SO order date = 1/1 vs 1/1
order date on DO = 1/1 vs 31/12
expected date on DO = 31/1 vs 30/1
scheduled date on 1st MO = 26/1 vs 25/1
date on 1st MO stock moves = 26/1 vs 25/1
scheduled date on 1st MO stock moves = 26/1 vs 27/9 (creation date)
scheduled date on 2d MO = 16/1 vs 15/1
date on 2d MO stock moves = 16/1 vs 15/1
scheduled date on 1st MO stock moves = 16/1 vs 27/9 (creation date)
order date on 1st PO = 21/1 vs 21/1
scheduled date on 1st PO = 21/1 vs 26/1
order date on related inc. ship. = 21/1 vs 20/1
date & scheduled date on inc. ship. stock moves = 21/1 vs 25/1
order date on 2d PO = 11/1 vs 11/1
scheduled date on 1st PO = 11/1 vs 16/1
order date on related inc. ship. = 11/1 vs 10/1
date & scheduled date on inc. ship. stock moves = 11/1 vs 15/1
We get the same inconsistent gaps when we do the same as what is explained in the book. From there, we can identify a couple bugs:
1. order date on DO/inc. ship. = SO/PO order date -1
2. scheduled date on MO stock move = order creation date
3. various date gaps in the dates of POs.
Finally, something strange: in 6.1, the user logs (which, for example, appears at the top of the SO to indicate that the DO is planned, show the correct date (the one in the book), but if we go to the DO itself, the date is not the same as in the user log. The user log could show "DO scheduled for 31/1", but the expected date in the DO itself would show 30/1.
Related branches
- Naresh(OpenERP) (community): Needs Fixing
- Olivier Dony (Odoo): Pending requested
-
Diff: 195 lines (+71/-13)6 files modifiedproject_mrp/test/project_task_procurement.yml (+1/-1)
purchase/company.py (+6/-2)
purchase/purchase.py (+27/-3)
sale_stock/company.py (+6/-3)
sale_stock/sale_stock.py (+27/-2)
sale_stock/test/picking_order_policy.yml (+4/-2)
Changed in openobject-addons: | |
assignee: | nobody → OpenERP Publisher's Warranty Team (openerp-opw) |
tags: | added: maintenance |
After further analysis, the main problem that was detected (in case 1.1) is in fact a timezone issue: when converting the "order date" of Sales Orders or Purchase Orders into the "reference date" for scheduling delivery and procurement, the "order date" is taken as if it was in UTC like all datetime values. In reality it is a fields.date and therefore expressed in the user's timezone.
This needs to be fixed by properly converting the "order date" into a UTC timestamp. During the conversion we don't have any time (hour of day) for the "order date", but we can arbitrarily use noon instead, it does not matter much as long as we treat that value in the correct timezone.