[trunk][6.0] duplicate chained moves when processing incoming pickings

hm.... still no decision about status and importance?

This is a REAL problem, especially if you have a certified manufacturing in automotive ..... how to solve?

Hi Vinay,

why wishlist? could you please be so kind to tell me what to do? Does it mean we can't use chained locations AND production lots?

Hi,

I think this is not a wishlist, maybe bad data or a bug...but not a wishlist IMHO

If this helps for your first point:
you should select "track incoming lots" instead of "track production lots"

about the 2 moves created, what is the source and destination location?

I think bug qualification and assignation policies should be deeply reviewed...

regards

"I think bug qualification and assignation policies should be deeply reviewed..." I agree.....

Carlos: I set my input location 'Stock' as chained location: the chained location 'quality control' is a child of 'Stock'. My request: all incoming goods automatically should moved to 'QC' - with production lot of course....

Carlos: I tried our your suggestion just to enbable 'track incoming lots' (disabled 'track production lots').

Result: the first move created when 'confirm to purchase order' gets in state 'done' as far as I received goods with production lot. My stock level in 'Quality Control' raised up WITHOUT production lot (see action 'stock by location' in product.form)

A second move with production lot is created. Issue: state 'waiting'.......

When I click 'check availability' I get the warning message "not enough stock, unable to reserve the products"

So: still the same problems....

On Sunday 06 March 2011, you wrote:

> I think bug qualification and assignation policies should be deeply
> reviewed...

I think we need more tests (YAML) for the stock module:
 - if your industry needs the QC flow, with incoming, controlled, quarrantine
and rejected locations, we need a series of tests to prove all this sequence
of steps.
 - on the other hand, we will also need corresponding tests for the simple
cases (no production lot, simple "shelf" locations) to ensure that smaller
businesses will still be able to operate.

Please, community, help us formulate your requirements in terms of tests, so
that each release of OpenERP will be proven to follow your procedures.

I imagine a set of tests like (expressed in YAML format) :

 -
   I will test the suitability of stock for automotive/pharmaceutical industry
  # Considering ISO 9000, FDA-xxxx, IEC-xxxx, LP Bug 722538 ...
  # <More comments about the nature of requirements, with references to
  # specifications and known practices >
-
  By specification, I have to create stock locations for incoming lots, to-be-
reviewed items, ....
-
  !record {model: stock.location}:
 ....
-
  I receive a batch of items
-
 ...and so on

In 1 year time, few people may remember that bug 722538 in some proprietary
site had information about these procedures. But if our own "code" contains
solid references to the needed results, we are more likely to follow (and not
break) them in the long run.

When you create a PO (purchase order), all stock moves are created (incoming + chained moves). This is the correct behavior, the virtual stock is updated in the last location.
When you make the reception :
- you must be able to assign the production lot to all previously created moves (if entire reception). -> bug
- you must be able to perform partial reception with a specific production lot and create new moves and put the right states -> partial reception works but please check states of all chained locations are set properly
- you do not have to create new moves when performing the entire reception, the moves are already created during PO -> bug
Note : entire reception means reception of all remaining goods

occure only in v6

< you must be able to assign the production lot to all previously created moves (if entire reception).
> you must be able to assign the production lot to only first move. Push move should not be created a second time
Works properly in trunk but not in 6.0

Note:
The only part to fix in 6.0 is the same that has been fixed in trunk: chaining locations should not create duplicate moves. The rest is ok. Currently in 6.0, if there is a chained location on the location where the products are received, you get duplicate lines when you process the incoming picking.

The production lot/batch number does not have to be copied to the chained moved, as OpenERP does not care about traceability of internal moves. If it is important to have it, the operator can manually input the number in the chained moved (even after the move has been processed, if needed)

Be careful when fixing this, as:
- it should behave properly when you do a partial receipt of the goods
- it should behave correctly if the chaining is automatic-no-step-added (i.e no chained moved at all; the original move is modified)

I haven't looked at which revision this was fixed in trunk, sorry.

Thanks for the detailed explanation Steffi,

We will update you about the bug soon.

Thanks.

Hello Steffi,

It has been fixed over the branch https://code.launchpad.net/~openerp-dev/openobject-addons/6.0-bug-722538-jvo by revision 4519 and has to undergo a review process.

We would be happy if you can have a look at it and notify us about the results of your test.

Thanks.

Hello Jay,

of course we will!

best regards
Steffi

Hello Jay,

we tested and found out: process incoming pickings do not duplicate chained moves anymore! Therefor this bug could get closed.

FYI: I will report 3 more bugs related to chained locations:
- copying production lot in chained moves
- partial delivery in chained moves
- cancelling incoming move

For now: thanks for your commitment!
Steffi

Thank for the feedback steffi,

It has been fixed in stable by revision 4532 <email address hidden>.

For all the bugs you want to get fixed, kindly go through the right channel.

Hope this helps.

Thanks again.