OpenERP Addons (modules)

error with planed date on purchase order for product MTS

Reported by Mecatis on 2009-09-11
46
This bug affects 8 people
Affects Status Importance Assigned to Milestone
OpenERP Addons
Wishlist
OpenERP R&D Addons Team 2

Bug Description

Hi,

There is a problem with generated planed date on purchase order when a manufacturing order want a product "make to stock" with 0 in stock.

(0 security days for this exemple)

When I sale today (september 11) a velo with delivery in 30 days to customer (oktober 11), 3 days for manufacturing and I have 0 handelbars (MTS) in stock, this handelbar have 5 days from supplier to me, OpenERP should generate a purchase order for this handelbar for planed date 30-3 days = in 27 days (oktober 8), but the system generates a planed date for today-5 days = there 5 days (september 6) -> in the past !!!

It unusable for calculating supply in a production !!

- version 5.0.3 with JIT module -

Hi,

After my investigation, this bug is still present.

Version : 5.0.6
Profile : Manufacturing with demo data
Extra modules : Jit

Procedure:

1. Start with new DB, profile manufacturing + JIT

2. Change the Basic PC component into make to stock (Keyboard, mouse,regular processor config, processor,mainboard,fan,ram) insted of make to order.

3. Add a stock rule with minimal quantity 0 for each of us

4. Add a supplier on each of us

5. Create a sale order in 28 days for exemple, confirm it and run the scheduler

Here you can see the generated PO with a date that is equal to "Present date" - 1 day in my case... This means in the past !

I expect that the planned date for the PO line to be : 28 - Customer lead time - Delivery supplier time

Please, have a look on this... We cannot handle the PO correctly in a production context with those erroneous dates.

Thanks in advance,

Regards,

Joël

affects: openobject-client → openobject-addons
Changed in openobject-addons:
status: New → Confirmed
Changed in openobject-addons:
importance: Undecided → Critical
milestone: none → 5.0.7
assignee: nobody → OpenERP Quality Team (openerp)
importance: Critical → Medium
importance: Medium → High
Changed in openobject-addons:
status: Confirmed → In Progress
Changed in openobject-addons:
milestone: 5.0.7 → 5.0.8

After checking carefully the bug description and the comments, it seems that what you describe is the expected behavior in this particular configuration.

Let me explain:

 1. The purchase order for which you see a planned date you do not expect is created by the order point/min stock rule. The purpose of the minimum stock rule is to replenish the stock asap when the virtual stock is below the minimum (this can lead to a PO date in the past due to the company' security 'purchase lead time' - we could improve that and include it in the planning, but that would only move the PO to today).
If you do not want it to trigger yet, then you should make sure that the virtual stock does not drop yet.

 2. The virtual stock level has dropped because the production order has been confirmed, and thus has created a corresponding procurement for the raw material it needs. If you do not want this happen yet, then make sure that the production order is not created yet.

 3. The production order has been created and confirmed because the original procurement order coming from the sale order has been confirmed already. This happens by default if JIT is installed (that's the point of JIT obviously) or if you run the schedulers and the procurement is within the 'scheduler range' set on the company (80 days by default)

So it seems to me that every part of the system is doing what it should. If you do not want step 3 to occur then do not install mrp-jit *and* ensure that the 'scheduler range' on the company is sufficiently small (less than 28-30 days in your examples) so it does not trigger your procurement yet.

I will close this bug as invalid, so you have 2 options:
 - if I misunderstood your report, please reopen this bug and add more info or a more detailed testcase, such as an XML test
 - if you think you would like the system to behave differently, feel free to open another bug (wishlist) or a blueprint to describe it (but please keep in mind the above rules and the separate roles of each part of the system)

Changed in openobject-addons:
status: In Progress → Invalid
importance: High → Undecided
assignee: OpenERP Core Team (openerp) → nobody
milestone: 5.0.8 → none

Hi Olivier,

First, thanks for reviewing the bugs report ! I spoke with my customer (Mecatis) which use OpenERP for several year now. I ask him to explain more about his issue, and he give me the attached .pdf.

It's in french, so, ok for you I hope ;) If really needed (or someone else wanted it) I can traduce it.

Basically, the point is : regarding the OpenERP logic, everything is fine, but this is not the way industry need to deal with that problematic.

If I understood this well, everything is perfectly handled by OpenERP expect the suggested date into the PO, which should be calculated with :

PO Date : Delivery date - Manufacturing lead time - delivery delay

And not with :

PO Date = Today - Delivery dealy

I must say I agree with my customer, which says you cannot suggest a date in the past. OpenERP should help companies to low their stock with a good scheduling, which is not the case yet.

Would you please read the attached doc and give me your feed-back on this ?

Thanks for your time,

Regards,

Changed in openobject-addons:
status: Invalid → Confirmed
importance: Undecided → High
milestone: none → 5.0.8
assignee: nobody → OpenERP Core Team (openerp)

I totally agree with Joel.

OpenERP has a curious and not real way to calculate expected receiving and sending date. Normally, system works based on delivery date you put on product form wich is not very usefull. System should calculate expected date depending on several parameters.

If you has got stock enough--> Delivery time could be inmediate
If you has not stock enough --> Delivery would depend on time your supplier expends on sending goods to you or time you expend on producing product. This production time should be calculated depending on time expended on each production process and time for each operation and again, the time your supplier expends on sending goods.

Additionally, the supplier expended time depends on him for EACH purchase order.

So.. the way today OpenERP calculates expected sending date is not usefull. We use to set it by hand on each outgoing and incoming pack.

Thank you:

Ana

Changed in openobject-addons:
milestone: 5.0.8 → 5.0.9

Just a remark: do you think we can change the meaning of that field in
version 5.0 with the risk to impact everyone or every module using that
field?
May be it should be changed on trunk only, no?

On Wed, Mar 31, 2010 at 2:33 PM, Stephane (Open ERP) <email address hidden>wrote:

> ** Changed in: openobject-addons
> Milestone: 5.0.8 => 5.0.9
>
> --
> error with planed date on purchase order for product MTS
> https://bugs.launchpad.net/bugs/427733
> You received this bug notification because you are subscribed to
> OpenObject Addons.
>
> Status in OpenObject Addons Modules: Confirmed
>
> Bug description:
> Hi,
>
> There is a problem with generated planed date on purchase order when a
> manufacturing order want a product "make to stock" with 0 in stock.
>
> (0 security days for this exemple)
>
> When I sale today (september 11) a velo with delivery in 30 days to
> customer (oktober 11), 3 days for manufacturing and I have 0 handelbars
> (MTS) in stock, this handelbar have 5 days from supplier to me, OpenERP
> should generate a purchase order for this handelbar for planed date 30-3
> days = in 27 days (oktober 8), but the system generates a planed date for
> today-5 days = there 5 days (september 6) -> in the past !!!
>
> It unusable for calculating supply in a production !!
>
> - version 5.0.3 with JIT module -
>
>
>

Please guys, do not set stable milestones on whislist/unclear bugs!
I had removed it on purpose.
If you don't understand the distinction, then at least don't revert changes done by others.

Changed in openobject-addons:
importance: High → Wishlist
milestone: 5.0.9 → 6.0

(yes I know I asked you to reopen the bug if you had more info, but that only means removing the 'Invalid' status)

On 30/03/10 14:16, Joël Grand-Guillaume @ CampToCamp wrote:
> Basically, the point is : regarding the OpenERP logic, everything is
> fine, but this is not the way industry need to deal with that
> problematic.

Thanks for the detailed explanation, it confirms the original
description of your bug:
- you don't like the way it works currently in OpenERP if you combine
order points, mrp_jit and the default OpenERP procurement workflow.
- (and I'm not sure you understand fully the current logic in OpenERP)

Several issues here:
1) Yes it can happen in the current OpenERP logic that you have a draft
Purchase Order in the past, in some case. It means you have your delays
wrong somewhere. Example: setup a very short customer lead time on a
MTO+buy product with a long supplier delivery delay, and if you sell it
today obviously the PO will be put in the past.
-> Again, if you have a proposition to change this why don't you write a
blueprint and a proposed patch? (but be sure to analyze the full
procurement workflow before doing that)

2) When you use minimum stock rules/order points, the Purchase Orders
that are created are not related to any specific procurement! They are
simply triggered because the virtual stock has dropped too low due to
all orders that are currently confirmed.
Imagine you create 3 different SO for a MTS product with 0 stock, with
different planned dates? Do you want the system to create 3 different
PO's for the same product to the same supplier with different dates? No.
If you want that, use MTO, not MTS. Order points are used to maintain a
minimum stock depending on the combined needs of the system, not per-order!

3) Now, it's true that when a PO is created by an *automatic* order
point, the planned dates on the PO should not be in the past, but based
on *today* (but certainly not to the planned date of another specific
order).
And BTW, you should not use automatic order points. If you want minimum
stock rules, create them explicitly. The configuration of minimum stock
rules is a critical task in warehouse management.

Is everything clear? If not, please read the source code carefully to
understand how procurement.orders and minimum stock rules work, I can't
explain everything on a LP bug. This is a complicated workflow, because
the reality is complicated.

SUMMARY
=======
So, concerning this bug, item 3) is the only real 'bug' I can see in
stable. Please update your bug description to explain that you want
*automatic* order points to create Purchase Orders with a 'scheduled
date' set to today and not in the past.

And please take the discussion about the rest of the procurement
planning into a blueprint or another wishlist bug, so we can re-target
this bug for stable.

Thanks!

Changed in openobject-addons:
milestone: 6.0 → none
assignee: OpenERP Core Team (openerp) → OpenERP R&D Addons Team 2 (openerp-dev-addons2)
Régis C. (reg53fr) wrote :

Hello,

The problem is “I want to keep a small security stock, but the scheduler tells me to buy now the units of all future sale orders of the year”. MTS is unusable because of this behavior.
It seems that OpenERP bases its MRP computation on a wrong virtual stock value. I explain :

The virtual stock changes over the time and we can compute its value for each day (see Stock Level Forecast report). An order point must be triggered on date D according to the virtual stock of date D (e.g. computed with the stock moves where date_expected <= D).
Currently, OpenERP’s scheduler seems to use only the virtual stock on "infinite" date (e.g. no limit in stock moves selection) like displayed in product form, thus all the future requirements are fulfilled at once !

Using MRP “standard” vocabulary, Virtual Stock or Projected Available should be computed like this:
Projected_avaible(D)=real_stock + scheduled_receipt + planned_order_receipt – gross requirement

Scheduled_receipt : stock moves [Supplier=>Stock] where date_expected <= D and state not in [‘done’, ‘cancel’]
Planned_order_receipt : stock moves [Procurement=>Stock] where date_expected <= D and state not in [‘done’, ‘cancel’]
Gross requirement : stock moves [Stock=>Client] where state = ‘assigned’ or (date_expected <= D and state = ‘confirmed’)

Olivier Dony wrote : "Imagine you create 3 different SO for a MTS product with 0 stock, with different planned dates? Do you want the system to create 3 different PO's for the same product to the same supplier with different dates?"
Yes I do, especially if there is a huge delay between SO planned dates. I want to purchase WHEN the min stock rule matches (- supplier lead time of course).

Do you agree ?

Régis

Régis C. (reg53fr) wrote :

I forgot to mention manufacturing order related moves but this is the same method.

Hello

I encounter the same problem with date calculation in openERP 6.0.3
I agree with The description of Regis wrote on 2011-11-08

Gilles

seven_sens (duhong-debril) wrote :

I agree with Régis and Mécatis. It is the big problem when you have thousands of orders in your ERP. I have worked with Movex 3 and SAP. These systems have the state of POA (purchase order proposal) and POF (fabrication order proposal) by the system. These orders are changed automatically when the needs change. The unuseful non-confirmed orders disappear automatically.

 The lead time of these orders is calculated as :
Lead time of a sell order = sell administrative lead time + (fabrication lead time +its security lead time+planning lead time ) + (procurement lead time + its security lead time+planning lead time )+(delivery lead time+planning lead time ).

Planning lead time defines an earliest time to order and a latest time to order. If it is to late to order, you can find it by the state of alert message in the "purchase order" menu or "manufacturing order" menu and so on.

Dear all,

I would like to follow-up on the requirement stated by Régis just above : "I want to purchase WHEN the min stock rule matches (- supplier lead time of course)."
Would you have any news on this topic ? Was this feature already implemented ? If not, is it planned to be implemented ?

Thanking you in advance,
Best regards,
Alexis

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers