[Erp5-dev] Price change on delivery, TargetSolver and rule property divergence tester

[Łukasz Nowak]

Hello,

Originally Sale Invoice Transaction, which causality is delivered Sale
Packing List is not diverged, when Invoice Line's price is changed.

I've made it divergent, by modifying
default_invoicing_rule/default_property_tester and adding property
price, so it looks like:

start_date | Start Date
stop_date | Stop Date
price | Price

And now changing price on Invoice Line is setting Sale Invoice
Transaction into diverged state. Great :)

But it is not possible to invoke Accept Decision on such Sale Invoice
Transaction, as CopyToTarget target solver has hardcoded values and not
updating simulation movement's price property.

So I added it, diff is in CopyToTarget.py.diff.

Questions.

1) Is there any guide to do such modification more Nexedish way (there
is such need in our case)?
2) What other tools such I use to achieve same goal?
3) If not (1) and and len(2) == 0 is my modification (assuming full
implementation related test coverage) safe enough?
4) Any comments, tips, trick, point-outs welcome :)

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: CopyToTarget.py.diff
Type: text/x-patch
Size: 2450 bytes
Desc: not available
URL: <http://mail.tiolive.com/pipermail/erp5-dev/attachments/20080116/5a6449ec/attachment.bin>

[Alexandre Boeglin]

Post by Łukasz Nowak
Hello,

Hi,

Post by Łukasz Nowak
1) Is there any guide to do such modification more Nexedish way (there
is such need in our case)?

Currently, the available documentation is at:

http://www.erp5.org/Discussion/SimulationRules
http://www.erp5.org/Discussion/SimulationRules/DivergenceSolvers

Post by Łukasz Nowak
2) What other tools such I use to achieve same goal?

Currently in the default business template configuration, the list of
solvers is hardcoded (in causality workflows and
PackingList_viewSolveActionsDialog).
This is ok as long as you use only a few solvers.
But if you start to add more and more solvers, you might want to link
for instance a price related solver with a price related divergence
tester, and when solving a delivery, apply the solver(s) returned by the
getDivergenceList() method.

Post by Łukasz Nowak
3) If not (1) and and len(2) == 0 is my modification (assuming full
implementation related test coverage) safe enough?

What you did was good, you could also have created a new Target Solver
to handle your pricing issue (inheriting from CopyToTarget)

To make a new Solver effective from a different Product, you have to
import it like this:

8< - - - -
from Products.ERP5 import TargetSolver
import sys
import MyNewSolver

TargetSolver.MyNewSolver = MyNewSolver
sys.modules['Products.ERP5.TargetSolver.MyNewSolver'] \
= MyNewSolver
8< - - - -


Regards,
Alex

[Łukasz Nowak]

Hello,

On 2008-01-17, 11:02:23

Post by Alexandre Boeglin

Post by Łukasz Nowak
Hello,

Hi,

Post by Łukasz Nowak
1) Is there any guide to do such modification more Nexedish way
(there is such need in our case)?

http://www.erp5.org/Discussion/SimulationRules
http://www.erp5.org/Discussion/SimulationRules/DivergenceSolvers

Well known to me (not always understood ;) ).

Post by Alexandre Boeglin

Post by Łukasz Nowak
2) What other tools such I use to achieve same goal?

Currently in the default business template configuration, the list of
solvers is hardcoded (in causality workflows and
PackingList_viewSolveActionsDialog).
This is ok as long as you use only a few solvers.
But if you start to add more and more solvers, you might want to link
for instance a price related solver with a price related divergence
tester, and when solving a delivery, apply the solver(s) returned by
the getDivergenceList() method.

Hm. For now I'm minimalistic with playing with Simulations - they are
still to cryptic for me, and available documentation is not covering
many aspects - maybe some day I'll provide our users nicer interface.

Post by Alexandre Boeglin

Post by Łukasz Nowak
3) If not (1) and and len(2) == 0 is my modification (assuming full
implementation related test coverage) safe enough?

What you did was good, you could also have created a new Target Solver
to handle your pricing issue (inheriting from CopyToTarget)
To make a new Solver effective from a different Product, you have to
8< - - - -
from Products.ERP5 import TargetSolver
import sys
import MyNewSolver
TargetSolver.MyNewSolver = MyNewSolver
sys.modules['Products.ERP5.TargetSolver.MyNewSolver'] \
= MyNewSolver
8< - - - -

Good to know, that I done something right (it is very important
psychological issue for me ;) ).

Thanks for great importing tip (less patch-o-matic in system).

Post by Alexandre Boeglin
Regards,
Alex

Regards,
Luke