Concept proposals for Packing Lists.

Registered by Grzegorz Grzelak (OpenGLOBE.pl)

According to polish law I have to ask for new approach to packing list and moves. Polish accounting law states that all postings have to arise from accounting documents. Among various accounting documents we have stock documents. Which are almost like Packing Lists in OpenERP. But they should have some other properties:

1.Sequence separation.
Packing lists should have separate sequences for different kind of stock documents. In Poland we have following kinds: Picking in, Shipping out, Warehouse move, Material usage (Production), Material usage (Inventory loss), Product income (Production), Product income (from Inventory). OpenERP has good functionality to define sequences. OpenERP also differentiates kinds of packing lists. So it would be appreciated to allow users to define more kinds of packing lists and allow them to assign different sequences to kinds of packing lists.

2. Packing list as moves header.
As you can assume from point 1 we need packing lists from Periodical Inventory (2 kinds) and from Production (2 kinds). Currently OpenERP in Inventory and Production creates just moves which has no sequence numbers. Can you consider to collect all moves into packing lists? And always treat moves as packing list positions/lines? I think it would be more consistence when moves have mandatory relation field to packing list. So account moves concerning stock moves will always have packing list numbers as reference. In Poland Inventory and Manufacturing order are not account documents. In our case account moves have to reference to packing list numbers arising from Inventory or Manufacturing order. I don't want to drop current functionality so I suggest to concatenate Packing list numbers with other document references or add separate fields for packing list numbers. Separate fields could have relation to Packing list. And separate field with relation would be better for opening stock document directly from accounting document.

3.Coherent moves.
In Poland all stock documents (packing lists) contains “coherent” positions (moves). I mean all moves are from the same location “A” to the same location “B”. Technically polish ERP systems contain source and destination location in header records which in OpenERP are packing list records. However to simplify development in OpenERP moves could contain locations like now and locations (source and destination) could be added to packing lists. Then it would be one general configuration check box changing functionality that all locations in moves have to be consistent with packing list header. And when someone try to save packing list with mixed locations error message arise.

4.Warehouse move.
Small remark for point 1. In Poland “Warehouse move” means move between warehouses (in OpenERP language move between locations from different warehouses). Such moves need separate sequences other than sequences for internal moves inside warehouse. Reason for such remark is that only moves BETWEEN warehouses should be reflected in accounting (in Poland). I know in OpenERP we can assign different Inventory accounts to locations from the same Warehouse and OpenERP will generate account move for stock move between these location. But such problem we can avoid during implementation of OpenERP. To simplify it can be one sequence for Warehouse moves and another for Inside warehouse moves.

Accepting these concepts we could change terminology:
Packing list to Move
Move to Move line.

By this blueprint I want to ask you, colleagues from other countries: which of these points could be needed for you so we can ask Tiny to improve some functionality. I believe no of concepts above is conflicting with current functionality. Probably you don't need all of these functionality. In such case please treat these 4 points as separate concepts and write which of them would improve OpenERP for your country. Then we will know which of them are just polish and we will think about them internally.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.