[Erp5-dev] Deeper containers consumption

[Łukasz Nowak]

Hello,

While packing Sale Packing Lists Resources' related to Container on
top level are consumed. But no there is no consumption of Resources'
related to lower level containers.

Eg:

SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C

resource A, resource B - there are movements
resource C - no movements.

Is it wanted behaviour? Is it possible to configure it?

Regards,
Luke

[Yoshinori Okuji]

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container on
top level are consumed. But no there is no consumption of Resources'
related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate Container
handling thouroughly.

YO

[Łukasz Nowak]

Hello,

On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container on
top level are consumed. But no there is no consumption of Resources'
related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Ok. So I'll continue my investigation then.

Thanks,
Luke

[Łukasz Nowak]

Hello,

On 2008-06-06, 14:18:17
Yoshinori Okuji <yo at nexedi.com> wrote:

(...)

Post by Yoshinori Okuji
I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Ok. I wasn't able to find test related to that issue so I wrote one.
Attached. I hope I'd be able to create this test good enough to be
commited.

Where is the place, where containers are added to movement table? I was
trying to figure it out, but without success :( Any tips welcome - I'll
do my best to create upstream acceptable patch (I'm trying to be that
'someone' mentioned by Yo :) ).

Regards,
Luke
--
?ukasz Nowak R&D Ventis http://www.ventis.com.pl/
tel: [phone] fax: [phone]
``Use the Source, Luke...'' I am only craftsman.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testPackingListContainerLevel.py
Type: text/x-python
Size: 8913 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20080611/a94896ae/attachment.py>

[Łukasz Nowak]

Hello,

On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container on
top level are consumed. But no there is no consumption of Resources'
related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Got something.

In movement table there is movement for both resources, which looks
like:

+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+
| uid | explanation_uid | source_uid | destination_uid | resource_uid | quantity | start_date | stop_date |
+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+
| 12901 | 12903 | NULL | NULL | 8395 | 1 | NULL | NULL |
| 12902 | 12903 | 5430 | 6520 | 8396 | 1 | 2008-06-09 00:00:00 | 2008-06-09 00:00:00 |
+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+

resource with uid 8396 is higher level (like resource A), resource with
uid 8396 is on lower level (like resource B).

Am I wrong is it associated with acquisition of categories? Because
invking getSource[Uid] on 8396 returns proper value, and on 8395
returns None.

Trying out more :)

Regards,
Luke

[Łukasz Nowak]

Hello,

On 2008-06-11, 15:58:30

Post by Łukasz Nowak
Hello,
On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container
on top level are consumed. But no there is no consumption of
Resources' related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Got something.
In movement table there is movement for both resources, which looks
+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+
| uid | explanation_uid | source_uid | destination_uid |
resource_uid | quantity | start_date | stop_date |
+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+
| 12901 | 12903 | NULL | NULL |
8395 | 1 | NULL | NULL | | 12902
| 12903 | 5430 | 6520 | 8396
| 1 | 2008-06-09 00:00:00 | 2008-06-09 00:00:00 |
+-------+-----------------+------------+-----------------+--------------+----------+---------------------+---------------------+
resource with uid 8396 is higher level (like resource A), resource
with uid 8396 is on lower level (like resource B).
Am I wrong is it associated with acquisition of categories? Because
invking getSource[Uid] on 8396 returns proper value, and on 8395
returns None.
Trying out more :)

Proposed workaround:
Add portal.getPortalContainerTypeList() to:
* portal_categories/source Acquisition Portal Types
* portal_categories/destination Acquisition Portal Types
* acquisition_portal_type of ERP5/PropertySheet/Task.py start_date
property
* acquisition_portal_type of ERP5/PropertySheet/Task.py stop_date
property

And now all containers are in movement table.

Is it acceptable solution?

Regards,
Luke

[Yoshinori Okuji]

Post by Łukasz Nowak
Hello,
On 2008-06-11, 15:58:30

Post by Łukasz Nowak
Hello,
On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container
on top level are consumed. But no there is no consumption of
Resources' related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Got something.
In movement table there is movement for both resources, which looks
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| uid | explanation_uid | source_uid | destination_uid |
resource_uid | quantity | start_date | stop_date |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| 12901 | 12903 | NULL | NULL |
8395 | 1 | NULL | NULL | | 12902
| 12903 | 5430 | 6520 | 8396
| 1 | 2008-06-09 00:00:00 | 2008-06-09 00:00:00 |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
resource with uid 8396 is higher level (like resource A), resource
with uid 8396 is on lower level (like resource B).
Am I wrong is it associated with acquisition of categories? Because
invking getSource[Uid] on 8396 returns proper value, and on 8395
returns None.
Trying out more :)

* portal_categories/source Acquisition Portal Types
* portal_categories/destination Acquisition Portal Types
* acquisition_portal_type of ERP5/PropertySheet/Task.py start_date
property
* acquisition_portal_type of ERP5/PropertySheet/Task.py stop_date
property
And now all containers are in movement table.
Is it acceptable solution?

Thank you for your effort. However, I don't know if this works well. Are all
values indexed correctly (especially for the inventory)? IIRC, the
computation of the amounts of resources with deep container trees was quite
complicated, so I am not sure if it is working appropriately.

For example, suppose this:

- A packing list contains two containers 1 and 2.

- Container1 delivers 5 units of Resource A.

- Container2 delivers 1 unit of Resource B, and another container Container3.

- Container3 delivers 2 units of Resource C, 3 units of Resource A, and other
containers Container4 and Container5.

- Container4 delivers 1 unit of Resource D, and 4 units of Resource A.

- Container5 delivers 3 units of Resource B, and 1 unit of Resource C.

Then, even think of packing multiple units of the same containers.

Does the Inventory API still work perfectly for all resources? I think it was
working more or less in the past, but I don't know if it is currently, as we
lack tests with complicated containers.

Regards,
YO

[Jean-Paul Smets]

Hi,

Let me clarify.

Luke: are talking about the resource of the container (ex. parcel, box,
bag, etc.) or the resource contained in the container (ex. book, pen, meat).

Regards,

JPS.

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
On 2008-06-11, 15:58:30

Post by Łukasz Nowak
Hello,
On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container
on top level are consumed. But no there is no consumption of
Resources' related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Got something.
In movement table there is movement for both resources, which looks
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| uid | explanation_uid | source_uid | destination_uid |
resource_uid | quantity | start_date | stop_date |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| 12901 | 12903 | NULL | NULL |
8395 | 1 | NULL | NULL | | 12902
| 12903 | 5430 | 6520 | 8396
| 1 | 2008-06-09 00:00:00 | 2008-06-09 00:00:00 |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
resource with uid 8396 is higher level (like resource A), resource
with uid 8396 is on lower level (like resource B).
Am I wrong is it associated with acquisition of categories? Because
invking getSource[Uid] on 8396 returns proper value, and on 8395
returns None.
Trying out more :)

* portal_categories/source Acquisition Portal Types
* portal_categories/destination Acquisition Portal Types
* acquisition_portal_type of ERP5/PropertySheet/Task.py start_date
property
* acquisition_portal_type of ERP5/PropertySheet/Task.py stop_date
property
And now all containers are in movement table.
Is it acceptable solution?

Thank you for your effort. However, I don't know if this works well. Are all
values indexed correctly (especially for the inventory)? IIRC, the
computation of the amounts of resources with deep container trees was quite
complicated, so I am not sure if it is working appropriately.
- A packing list contains two containers 1 and 2.
- Container1 delivers 5 units of Resource A.
- Container2 delivers 1 unit of Resource B, and another container Container3.
- Container3 delivers 2 units of Resource C, 3 units of Resource A, and other
containers Container4 and Container5.
- Container4 delivers 1 unit of Resource D, and 4 units of Resource A.
- Container5 delivers 3 units of Resource B, and 1 unit of Resource C.
Then, even think of packing multiple units of the same containers.
Does the Inventory API still work perfectly for all resources? I think it was
working more or less in the past, but I don't know if it is currently, as we
lack tests with complicated containers.
Regards,
YO

[Łukasz Nowak]

Hello,

On 2008-06-12, 15:22:19

Post by Jean-Paul Smets
Hi,
Let me clarify.
Luke: are talking about the resource of the container (ex. parcel,
box, bag, etc.) or the resource contained in the container (ex. book,
pen, meat).

I was talking about resource of the Container, not resource of
Container Line. To be not misunderstood I've send this test.

I haven't run into any problems with resources related with Container
Line, as (AFAIK) Container Line is not movement, is it?

Regards,
Luke

[Jean-Paul Smets]

Post by Łukasz Nowak
Hello,
On 2008-06-12, 15:22:19

Post by Jean-Paul Smets
Hi,
Let me clarify.
Luke: are talking about the resource of the container (ex. parcel,
box, bag, etc.) or the resource contained in the container (ex. book,
pen, meat).

I was talking about resource of the Container, not resource of
Container Line. To be not misunderstood I've send this test.

I my opinion, base categories need to be configured so that acquisition
works in the situation you described. (ie. include container portal
types in the list of acquirable types for source / destination)

Post by Łukasz Nowak
I haven't run into any problems with resources related with Container
Line, as (AFAIK) Container Line is not movement, is it?

Right

Post by Łukasz Nowak
Regards,
Luke

[Łukasz Nowak]

Hello,

On 2008-06-12, 22:59:41

Post by Jean-Paul Smets

Post by Łukasz Nowak
Hello,
On 2008-06-12, 15:22:19

Post by Jean-Paul Smets
Hi,
Let me clarify.
Luke: are talking about the resource of the container (ex. parcel,
box, bag, etc.) or the resource contained in the container (ex.
book, pen, meat).

I was talking about resource of the Container, not resource of
Container Line. To be not misunderstood I've send this test.

I my opinion, base categories need to be configured so that
acquisition works in the situation you described. (ie. include
container portal types in the list of acquirable types for source /
destination)

That's what I proposed
http://mail.nexedi.com/pipermail/erp5-dev/2008-June/001956.html

Additionaly start/stop date shall be acquired.

Is test attached in
http://mail.nexedi.com/pipermail/erp5-dev/2008-June/001954.html
acceptable to be added to test suite?

Regards,
Luke

Post by Jean-Paul Smets

Post by Łukasz Nowak
I haven't run into any problems with resources related with
Container Line, as (AFAIK) Container Line is not movement, is it?

Right

Post by Łukasz Nowak
Regards,
Luke

[Jean-Paul Smets]

Hi,

Let me clarify.

Luke: are talking about the resource of the container (ex. parcel, box,
bag, etc.) or the resource contained in the container (ex. book, pen, meat).

Regards,

JPS.

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
On 2008-06-11, 15:58:30

Post by Łukasz Nowak
Hello,
On 2008-06-06, 14:18:17

Post by Yoshinori Okuji

Post by Łukasz Nowak
Hello,
While packing Sale Packing Lists Resources' related to Container
on top level are consumed. But no there is no consumption of
Resources' related to lower level containers.
SPL-1
Container 1 resource: A
Container 2 resource: B
Container 1 in 2 resource: C
resource A, resource B - there are movements
resource C - no movements.
Is it wanted behaviour? Is it possible to configure it?

I hardly believe that this is desired. Someone must investigate
Container handling thouroughly.

Got something.
In movement table there is movement for both resources, which looks
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| uid | explanation_uid | source_uid | destination_uid |
resource_uid | quantity | start_date | stop_date |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
| 12901 | 12903 | NULL | NULL |
8395 | 1 | NULL | NULL | | 12902
| 12903 | 5430 | 6520 | 8396
| 1 | 2008-06-09 00:00:00 | 2008-06-09 00:00:00 |
+-------+-----------------+------------+-----------------+--------------+
----------+---------------------+---------------------+
resource with uid 8396 is higher level (like resource A), resource
with uid 8396 is on lower level (like resource B).
Am I wrong is it associated with acquisition of categories? Because
invking getSource[Uid] on 8396 returns proper value, and on 8395
returns None.
Trying out more :)

* portal_categories/source Acquisition Portal Types
* portal_categories/destination Acquisition Portal Types
* acquisition_portal_type of ERP5/PropertySheet/Task.py start_date
property
* acquisition_portal_type of ERP5/PropertySheet/Task.py stop_date
property
And now all containers are in movement table.
Is it acceptable solution?

Thank you for your effort. However, I don't know if this works well. Are all
values indexed correctly (especially for the inventory)? IIRC, the
computation of the amounts of resources with deep container trees was quite
complicated, so I am not sure if it is working appropriately.
- A packing list contains two containers 1 and 2.
- Container1 delivers 5 units of Resource A.
- Container2 delivers 1 unit of Resource B, and another container Container3.
- Container3 delivers 2 units of Resource C, 3 units of Resource A, and other
containers Container4 and Container5.
- Container4 delivers 1 unit of Resource D, and 4 units of Resource A.
- Container5 delivers 3 units of Resource B, and 1 unit of Resource C.
Then, even think of packing multiple units of the same containers.
Does the Inventory API still work perfectly for all resources? I think it was
working more or less in the past, but I don't know if it is currently, as we
lack tests with complicated containers.
Regards,
YO