← Back to team overview

openerp-india team mailing list archive

[Bug 1192525] Re: [7.0] Duplicated moves generating wrong Virtual Stock when using chained locations

 

*** This bug is a duplicate of bug 1051906 ***
    https://bugs.launchpad.net/bugs/1051906

** This bug has been marked a duplicate of bug 1051906
   Minimum stock rule + Compute Schedulers + Chained Locations creatings two stock moves

-- 
You received this bug notification because you are a member of OpenERP
Indian Team, which is subscribed to OpenERP Addons.
https://bugs.launchpad.net/bugs/1192525

Title:
  [7.0] Duplicated moves generating wrong Virtual Stock when using
  chained locations

Status in OpenERP Addons (modules):
  New

Bug description:
  We have found a strange behavior related with stock movements which is
  causing a stock imbalance (wrong virtual stock) when chained locations
  are used. Please find below the steps to explain and reproduce the
  problem. These first  steps show a case NOT using chained locations.

  Step 1) Select a product -> Orderpoint (crete if it does not exist) ->
  Set a minimum quantity higher than your current stock, so that the
  scheduler will create a purchase order (i.e. a purchase order of 5
  units).

  Step 2) Check as well that the orderpoint location is set to "Stock"

  Step 3) Run the scheduler

  Step 4) At this point, the Virtual Stock should have been increased by
  5 units and a stock movement (Virtual Locations /Procurements ->Stock)
  should be visible in the "Future Stock Moves". Everything OK by now.

  Step 5) Confirm the Purchase Quotation. At this moment is when the problem occurs. After the confirmation, the system shows 2 movements:
          + Partner Locations / Supplier -> Stock (Seems correct)
          + Stock -> Stock (This one is the movement causing trouble as we'll see later)

  Step 6) When the product is received, these two moves are executed and the stock balance is correct:
         + Partner Locations / Supplier (-5) -> Stock (+5)
         + Stock (-5) -> Stock (+5)

  Although the process so far works ok, we believe that it is not
  completely correct: This is why:

     - If the Incoming Shipment is cancelled (Button "Cancel Transfer"), only one of the aforementioned moves is cancelled:
          + Partner Locations / Supplier -> Stock (Cancelled)
          + Stock -> Stock (Not cancelled). The status is set to "Waiting Availability".

     - Let's consider now the use of chained locations  (Supplier -> Incoming location -> Stock). In this case, if we replicate the
       process explained above:

       Step 1) Same as before

       Step 2) Check as well that the orderpoint location is set to
  "Incoming location"

       Step 3) Same as before

       Step 4) At this point, the Virtual Stock should have been increased by 5 units and the following stock movements should be
       visible in the "Future Stock Moves":

          +  Virtual Locations /Procurements -> Incoming location
          +  Incoming location -> Stock

       Step 5) Confirm the purchase quotation. At this point the virtual stock is wrong (the input has been duplicated and an amount
       of 10 units is shown!). The moves now are as follows:

       + Move #1: Incoming location -> Incoming location (Wrong)
       + Move #2: Suppliers -> Incoming location (Right)
       + Move #3: Incoming location -> Stock (Right)   -Move chained to move #1-
       + Move #4: Incoming location -> Stock (Duplicated)   -Move chained to move #2-

       As it is shown, moves #3 and #4, cause an imbalance in the
  Virtual Stock (we'll have the amount duplicated, 10 units).

      Step 6) When the product is received, the 4 moves are executed and this is the outcome:
          + Incoming location (-5 units)
          + Stock (+10)

  Could anyone confirm and replicate this behavior?. Is this a bug or
  are we missing something?

  Thank you in advance for your time.
  Regards,

  Javier Fuentes
  Codeback Software (www.codeback.es)

To manage notifications about this bug go to:
https://bugs.launchpad.net/openobject-addons/+bug/1192525/+subscriptions