[Erp5-dev] Problems with customization of portal deliveries

[Łukasz Nowak]

Hello,

I want to have Sale Packing List (SPL) with multi-causality from Sale
Order (SO). So in portal_deliveries/sale_packing_list_builder I
modified:

* Delivery Collect Order Groups from
OrderMovementGroup
DateMovementGroup
PathMovementGroup
SectionPathMovementGroup
to
DateMovementGroup
PathMovementGroup
SectionPathMovementGroup

Rest of builder is untouched.

I've also modified system (as it's seen in attached files) for scripts
to be able to use CausalityList of SPLs instead of one causality.

With such configured builder and such modification I supposed, that
system will be running fine with SPLs with many Causalities. Well - in
99,9% of my tests all was running fine. Only one situation is
little...weird:

When there are two SO with same Resource in line (with same price), and
I'm invkoing Confirm (and builder is invoked of course) one-after-one
generated SPL is in state diverge, and it has lines with amount of
resources from first confirmed order. So I've deleted that SPL and than
when I have that two orders in state confirmed and invoked builder by
hand for them SPL is build great - quantity of resources is added, SPL
is in state - solved.

I'm so sorry that I cannot support community with my own
patch/guide/anything for such situation, because for now my knowledge of
simulation & deliveries (& many other things) is not good enough. I'd
like to know if my path of resolving this problem is good, what is
reason of different builder behaviour and how to have builder working
well for such situation. I was looking in wiki for more information
about builders, but there's only disscussion page, which is not enough
explanatory for me, sorry. I also wasn't able to find any builders in
BTses which do resolves same situation to use them as a reference.

Bye,
Luke
--
?ukasz Nowak R&D Ventis http://www.ventis.com.pl/
tel: [phone] int 37 fax: [phone]
https://ssl.ventis.com.pl/keys/lukasz.nowak.pub.asc
``Use the Source, Luke...''
-------------- next part --------------
packing_list = state_change.object

stop_date = state_change.kwargs['stop_date']
start_date = state_change.kwargs['start_date']

# Create Delivery Applied Rule (if required)
packing_list.updateAppliedRule()
# Make sure applied rule is 100% indexed
# Here, applied rule must be already cleanly created

# We do not use DeliverySolver, because, by default, we keep delivery_ratio
# untouch
tag = packing_list.getPath() + '_split'
packing_list.portal_simulation.solveDelivery(packing_list, None,
"SplitAndDefer",
start_date=start_date,
stop_date=stop_date,
activate_kw={'tag':tag})

# Automatic workflow
packing_list.activate().updateCausalityState()

# Create delivery
orders = packing_list.getCausalityValueList()
order = orders[0]
applied_rule = order.getCausalityRelatedValue(portal_type="Applied Rule")
# reindex simulation movement as quick as possible
#applied_rule.recursiveImmediateReindexObject()

order_portal_type = order.getPortalType()
if order_portal_type == 'Sale Order':
delivery_builder = order.portal_deliveries.sale_packing_list_builder
elif order_portal_type == 'Purchase Order':
delivery_builder = order.portal_deliveries.purchase_packing_list_builder

explanation_uid_list = [packing_list.getUid()]
for o in orders:
explanation_uid_list.append(o.getUid())

delivery_builder.activate(activity='SQLQueue',after_tag=tag).build(explanation_uid=explanation_uid_list)
-------------- next part --------------
packing_list = context

# First, copy Order properties
#packing_list.PackingList_copyOrderProperties()

packing_list.SalePackingList_setCausalityListBySimulation()
related_order = packing_list.getCausalityValue()

packing_list_state = packing_list.getSimulationState()
if packing_list_state == "draft":
packing_list.edit(
comment = related_order.getComment(),
delivery_mode = related_order.getDeliveryMode(),
incoterm = related_order.getIncoterm(),
source_administration_value = related_order.getSourceAdministrationValue(),
title = related_order.getTitle()
)
packing_list.portal_workflow.doActionFor(
packing_list,
'confirm_action',
wf_id='packing_list_workflow',
comment="Initialized by Delivery Builder")



# First set the packing_list in the building state
packing_list.startBuilding()
# Then an activity should put the causality state in diverged or solved
# XXX after_method_id is not good, it should be after_group_id, but not yet implemented
packing_list.activate(after_method_id=('immediateReindexObject','recursiveImmediateReindexObject','Delivery_confirm')).updateCausalityState(fast=1)
-------------- next part --------------
ml = context.getMovementList() # all movements for this SPL
mu = [m.getRelativeUrl() for m in ml] # get thier URLs...

# now get all SM related for ML for this SPL
sm = [r.getObject() for r in context.portal_catalog(portal_type='Simulation Movement',)]
selm = []
for s in sm:
if s.getDelivery() in mu:
selm.append(s)

calist = []
for s in selm:
q = s.getOrderValue().getParentValue()
if q not in calist:
calist.append(q)

context.setCausalityValueList(calist)

[Yoshinori Okuji]

Post by Łukasz Nowak
When there are two SO with same Resource in line (with same price), and
I'm invkoing Confirm (and builder is invoked of course) one-after-one
generated SPL is in state diverge, and it has lines with amount of
resources from first confirmed order. So I've deleted that SPL and than
when I have that two orders in state confirmed and invoked builder by
hand for them SPL is build great - quantity of resources is added, SPL
is in state - solved.

I don't think SplitAndDefer can deal with this condition. It succeeds when you
have no packing list yet, only because the solver is not really used. If you
want to merge multiple orders, there are two ways:

- Manually merge multiple packing lists generated from orders into one. I
implemented this action a long, long time ago, but I don't know if it still
works.

- Write a solver which merges orders automatically, as you are trying now.
This can be annoying, if the user sometimes does not want to merge packing
lists.

YO

[Łukasz Nowak]

Hello,

Dnia 30-11-2006, czw o godzinie 13:59 +0100, Yoshinori Okuji napisa?(a):
(...)

Post by Yoshinori Okuji
- Write a solver which merges orders automatically, as you are trying now.
This can be annoying, if the user sometimes does not want to merge packing
lists.

Well, I want to have SPLs generated automatically. For now, I've
modified sale_packing_list_builder to generate SPLs in 'draft' state,
and before generation I'm removing all SPLs which are in 'draft' and
regenerate them. And SPL-manager will confirm SPL to make it
"untouchable" in such situation.

Well - there's little problem with manage_delObjects() running in
activities - but I hope that I'll manage to make it myself.

Bye,
Luke

[Łukasz Nowak]

Hello,

Dnia 30-11-2006, czw o godzinie 13:59 +0100, Yoshinori Okuji napisa?(a):
(...)

Post by Yoshinori Okuji
- Write a solver which merges orders automatically, as you are trying now.
This can be annoying, if the user sometimes does not want to merge packing
lists.

Well, I'm going to write such solver and use it with SPL. I've seen,
that SPLs are moved to confirmed state automagically; so for now I'll
left them in draft state and only such will be updated. So if user would
like to have SPL "untouchable" by builder he will move it to confirm
state. I hope that there are not so many consequences with using SPLs in
draft state - well for now I'm more worried about writing solver.

And I think that such solver could be invoked by user by hand, just as
split&defer action, and in such situation he will know, that SPL will be
updated.

Bye,
Wish me luck,
Luke ;)

[Yoshinori Okuji]

BTW, your SalePackingList_setCausalityListBySimulation is not good:

# now get all SM related for ML for this SPL
sm = [r.getObject() for r in context.portal_catalog(portal_type='Simulation
Movement',)]
selm = []
for s in sm:
if s.getDelivery() in mu:
selm.append(s)

This requires that Zope reads all Simulation Movements in the system, and it
will crash some day when the number of such movements exceeds a limit. What
you should do here is to ask portal_catalog to obtain only relevant
simulation movements by specifying, for example, delivery uids.

YO