[Erp5-dev] Purchase path of system - from order to invoice - some questions

[Łukasz Nowak]

Hello,

As you know I'm working on purchase path from order to invoice.

I'd like to know how shall I define

With only Sale this was quite easy - I've created some predicates (on
region in our case), then selected proper regions and expand on Orders
was great.

With only Purchase - it is similar (after patching with
InvoiceTransactionRule_asCellRange-source_region_patch.diff, which
allows me to select source_region on Predicates) I was able to create
good purchase invoices.

Questions:

1. Is my path correct and upstream acceptable?
2. How shall be default_invoice_transaction_rule, which will be able to
support Purchase and Sale invoices? I've seen that putting together
destination_ and source_ region do not work. Shall I them put into same
matrix? What would be "the Nexedi way"?

When I'll now how to mix auto generation of Purchase and Sale Invoice
Transaction objects and lines in "the Nexedi way", then I'll be able to
write unit tests for such configuration and (maybe) put such extension
upstream.

Well, I'm going back to experiments, thanks for any clues and suggestions,
Luke

[Jérôme Perrin]

Post by Łukasz Nowak
Hello,
As you know I'm working on purchase path from order to invoice.
I'd like to know how shall I define
With only Sale this was quite easy - I've created some predicates (on
region in our case), then selected proper regions and expand on Orders
was great.
With only Purchase - it is similar (after patching with
InvoiceTransactionRule_asCellRange-source_region_patch.diff, which
allows me to select source_region on Predicates) I was able to create
good purchase invoices.
1. Is my path correct and upstream acceptable?

In theory it is not needed, InvoiceTransactionRule_asCellRange contains:

dimension_list.extend([ pred.getStringIndex()
for pred in context.objectValues(portal_type='Predicate')
if pred.getStringIndex() not in dimension_list ])

I saw a bug in Predicate_getMembershipCriterionCategoryList, it only supported
destination_region, and this has been broken recently, so it maybe the reason
of your problem. I repaired it and added support for source_region in r13723
(and more cleanly in r13724). And also source_region was not cleanly
configured (r13729).

Post by Łukasz Nowak
2. How shall be default_invoice_transaction_rule, which will be able to
support Purchase and Sale invoices? I've seen that putting together
destination_ and source_ region do not work. Shall I them put into same
matrix? What would be "the Nexedi way"?

Yes, put all together in the same matrix and make a dimension with some
predicates with method id ( a script Movement_explanationPortalTypeIsSale
exists for this) to make this dimension only for sale or purchase.

Post by Łukasz Nowak
When I'll now how to mix auto generation of Purchase and Sale Invoice
Transaction objects and lines in "the Nexedi way", then I'll be able to
write unit tests for such configuration and (maybe) put such extension
upstream.

In my understanding, simulation related tests are here to test integration of
all parts of the simulation together, and test that configurable parts can be
configured for specific needs, not to test this configuration itself. But
more testing in this area would probably have detected problems I just have
seen. Anyway you should write tests specifics to your configuration, this
will help you a lot in the development process.

J?rome

[Łukasz Nowak]

Hello,

J?r?me Perrin napisa?(a):
(...)

Post by Jérôme Perrin

Post by Łukasz Nowak
1. Is my path correct and upstream acceptable?

dimension_list.extend([ pred.getStringIndex()
for pred in context.objectValues(portal_type='Predicate')
if pred.getStringIndex() not in dimension_list ])
I saw a bug in Predicate_getMembershipCriterionCategoryList, it only supported
destination_region, and this has been broken recently, so it maybe the reason
of your problem. I repaired it and added support for source_region in r13723
(and more cleanly in r13724). And also source_region was not cleanly
configured (r13729).

Ok. I've merged my implementation with that fixes. Thanks.

Post by Jérôme Perrin

Post by Łukasz Nowak
2. How shall be default_invoice_transaction_rule, which will be able to
support Purchase and Sale invoices? I've seen that putting together
destination_ and source_ region do not work. Shall I them put into same
matrix? What would be "the Nexedi way"?

Yes, put all together in the same matrix and make a dimension with some
predicates with method id ( a script Movement_explanationPortalTypeIsSale
exists for this) to make this dimension only for sale or purchase.

Wow! That's what I was looking for. Right now all simulations are
creating well, and I'm able to set proper rules for accounting.

As soon as I test it I'll try to write some text about it.

Thank you very much!
Luke