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

[Jérôme Perrin]

Le Mardi 27 Mars 2007 16:12, Łukasz Nowak a écrit :
> 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?

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).

> 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.

> 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