Picking list sequence number repeated in automatic moves

[Grzegorz Grzelak (OpenGLOBE.pl)]

I see it still in 5.0.5.
When automatic move is performed Picking list gets the same number like the original Picking list triggering automatic move. So it is situation that two different documents have the same number.

Why it is wrong:
1. According to our polish law all references in accounting moves have to point to one source document with unique number.

2. It would make some problem in identifying Picking lists by warehouse worker.

Anyway purpose of sequences in ERP systems is to give the documents unique numbers.

By the way I want to thank you for improvement in Picking list that sequence numbers are assigned after confirmation of Picking list what avoids sequence holes.

[gpa(OpenERP) (gpa-openerp)]

Hello,

I can not reproduce the bug.
So can you explain me more detail with steps.

Thank you

[Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl)]

Hello:
On fresh Database you have locations: Stock and Output. Create another location CheckLocation.

In new location make Chained Location Type: Fixed location.
Chained Location if fixed: Output.
Automatic move: Manual operation or Automatic Move.

And create internal move: Stock management -> Internal Moves. Choose "New". Shipping Type - Internal.
Create move (Packing line), From: Stock, To: CheckLocation. Any existing product.
Make "Process Now".
Check the list of internal moves: "Stock Management - Internal Moves". You should see 2 Packing lists. First should contain move from Stock to CheckLocation and second should contain move from CheckLocation to output. But both Packing lists will have the same number. For example "PACK3". But you can see that they are separate records in system. In my opinion they should be in different records but they should have separate consequent numbers.
All the best

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Grzegorz,

Sorry for any inconvenience.

As far as the chained locations issue is concerned, Same Packing moves from one location to another location.It would be difficult to track that packing moved from where to where.

Example:

Packing of a Complete Computer set was packed at stock,was moved to location X(chained one) and then to location Customers.
So, It has to be assigned same reference/Name to keep a track of its journey from Root Location to destination.

You wrote:
Why it is wrong:
1. According to our polish law all references in accounting moves have to point to one source document with unique number.
>>>> It isnt an accounting move. If you want to keep different number in Pack reference, you need to develop a module for your own sake of simplicity.
2. It would make some problem in identifying Picking lists by warehouse worker.
>>>> It would be quite easy to know the journey of a pack,from root to final.

You are welcome for the solutions.

Hope it will help.

Go for a blueprint if you are not satisfied, but functional point of view,its not scalable.

[Grzegorz Grzelak (OpenGLOBE.pl) (grzegorz-og.pl)]

Just to comment:
Thank you Jay for investigation. I really thought that double number is bug made by mistake. Now I understand it is intentional feature.

Problem for me is that it is simply forbidden in Poland to have two different documents with the same number. In some configurations two chained moves can create two account moves which will reference the same document. Company can pay penalty during government audit. I am surprised that in other countries you can use such feature which looks like breaking formal rules. I cannot believe it is in Poland only but have no information.

I understand that the same number for two consequent moves can simplify to track moves. But I don't think people would have problem with tracking when two consequent moves have two CONSEQUENT numbers. Anyway OpenERP has real good tracking functionality in stock module to not use "same number" trick.

I understand that I cannot force international community for issues looking like one country only problem.

There are a lot of unsatisfied things in OpenERP which I already described in Blueprint
https://blueprints.launchpad.net/openobject-addons/+spec/packing-lists-improvement
I am still waiting for any alliance for that. I believe alliance is possible because I saw that other OpenSourceERP systems base functionality is closer to Polish needs and this Blueprint. It means that it is not Polish only requirement.

[Jay Vora (Serpent Consulting Services) (jayvora)]

Hello Grzegorz,

We appreciate your feedback.

We will plannify the development/feasibility checking of your blueprint.

Thank you.