[Erp5-dev] Sale Invoice Transaction - different behavoiur

[Łukasz Nowak]

Hello,

Here's my scenario:

SIT-1 generated by by SPL-1, which has SPLL with resource R, price 10,
quantity 20

SIT-2 made by hand, which has SIT-IL with resource R, price 10,
quantity 20

SIT-1 and SIT-2 is in planned state.

I've got properly configured Invoice Transaction Rule - so after
expanding SIT-1 and SIT-2 I've got nice simulations related to accounts
- to generate ATL after confirming invoice.

1) Changing quantity/price on SIT1-IL do not change related simulation
movements, which applied rule is Invoice Transaction Rule.

2) Changing quantity/price on SIT2-IL (those w/o causality) change
related simulation movements, which applied rule is Invoice Transaction
Rule.

So in 1) after confirming I've got "improper" values of ATL, in case 2)
everything is ok.

I thought that in both scenarios behaviour of system will be the same.
Before digging more into it I'd like to know, what is wrong? Is it bug,
feature, it comes from idea, or something? I'll try to find out "where"
above difference in code has a place, but tip about it would be great.

Legend:
ATL - Accounting Transaction Line
SIT - Sale Invoice Transaction
SIT[n]-IL - Invoice [n] Line
SPL - Sale Packing List
SPLL - Sale Packing List Line

Best regards,
Luke

[Łukasz Nowak]

Hello,

On 2007-09-13, 14:28:45

Post by Łukasz Nowak
Hello,
SIT-1 generated by by SPL-1, which has SPLL with resource R, price 10,
quantity 20
SIT-2 made by hand, which has SIT-IL with resource R, price 10,
quantity 20
SIT-1 and SIT-2 is in planned state.
I've got properly configured Invoice Transaction Rule - so after
expanding SIT-1 and SIT-2 I've got nice simulations related to
accounts
- to generate ATL after confirming invoice.
1) Changing quantity/price on SIT1-IL do not change related simulation
movements, which applied rule is Invoice Transaction Rule.
2) Changing quantity/price on SIT2-IL (those w/o causality) change
related simulation movements, which applied rule is Invoice
Transaction Rule.
So in 1) after confirming I've got "improper" values of ATL, in case
2) everything is ok.
I thought that in both scenarios behaviour of system will be the same.
Before digging more into it I'd like to know, what is wrong? Is it
bug, feature, it comes from idea, or something? I'll try to find out
"where" above difference in code has a place, but tip about it would
be great.
ATL - Accounting Transaction Line
SIT - Sale Invoice Transaction
SIT[n]-IL - Invoice [n] Line
SPL - Sale Packing List
SPLL - Sale Packing List Line

Small addition - I've played more with this issue, and what I've
observed that no simulations are updated when Purchase/Sale Invoice
Transaction are based on Purchase/Sale Packing Lists.

properties used: start/stop date of invoice, quantity, price of invoice
lines.

I'll try to figure out more and share with experience.

Regards,
Luke

[Łukasz Nowak]

Hello,

On 2007-09-21, 11:11:26
?ukasz Nowak <lukasz.nowak at ventis.com.pl> wrote:
(...)

Post by Łukasz Nowak
Small addition - I've played more with this issue, and what I've
observed that no simulations are updated when Purchase/Sale Invoice
Transaction are based on Purchase/Sale Packing Lists.
properties used: start/stop date of invoice, quantity, price of
invoice lines.
I'll try to figure out more and share with experience.

I'm pretty shocked right now...

When Sale Invoice Transaction is created by hand its applied rule is
'portal_rules/default_invoice_rule', but when it is created by starting
Sale Packing List its applied rule is
'portal_rules/default_invoicing_rule'.

Why it is done so? I'm able to find out why in one case is one Rule
chosen and why another, but _why_ Sale Invoice Transaction has
different rules applied?

Regards,
Luke

[Jean-Paul Smets]

Hi,

I ask someone to study this with you and fix it. I know it is currently
broken.

Regards,

JPS.

Post by Łukasz Nowak
Hello,
On 2007-09-21, 11:11:26
(...)

Post by Łukasz Nowak
Small addition - I've played more with this issue, and what I've
observed that no simulations are updated when Purchase/Sale Invoice
Transaction are based on Purchase/Sale Packing Lists.
properties used: start/stop date of invoice, quantity, price of
invoice lines.
I'll try to figure out more and share with experience.

I'm pretty shocked right now...
When Sale Invoice Transaction is created by hand its applied rule is
'portal_rules/default_invoice_rule', but when it is created by starting
Sale Packing List its applied rule is
'portal_rules/default_invoicing_rule'.
Why it is done so? I'm able to find out why in one case is one Rule
chosen and why another, but _why_ Sale Invoice Transaction has
different rules applied?
Regards,
Luke

[Łukasz Nowak]

Hello,

On 2007-09-24, 10:38:35

Post by Jean-Paul Smets
Hi,
I ask someone to study this with you and fix it. I know it is
currently broken.

That ok. Shall I provide "higher" level unit test, which will simulate
my scenario? It would be based on document level, not simulation level
- as simulations are broken - am I right? - and I do not have any idea
how should they work - and I hope I know how documents shall be
generated.

Regards,
Luke

[Łukasz Nowak]

On 2007-10-01, 10:12:49

Post by Łukasz Nowak

Post by Jean-Paul Smets
Hi,
I ask someone to study this with you and fix it. I know it is
currently broken.

That ok. Shall I provide "higher" level unit test, which will simulate
my scenario? It would be based on document level, not simulation level
- as simulations are broken - am I right? - and I do not have any idea
how should they work - and I hope I know how documents shall be
generated.

Well. I've made such test - it is good for my experience. I hope that
something like this is not already in original unit test list :)

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