You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@ofbiz.apache.org by ja...@apache.org on 2006/12/12 09:18:39 UTC
svn commit: r486056 -
/incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
Author: jacopoc
Date: Tue Dec 12 00:18:38 2006
New Revision: 486056
URL: http://svn.apache.org/viewvc?view=rev&rev=486056
Log:
If a Invoice is applied to a BillingAccount, Payment should be applied to Invoice and also set BillingAccountId in PaymentApplication record. So that the total Invoice amount and Payment amount whould balance for a BillingAccount number.
For details, see the interesting discussion here http://www.mail-archive.com/ofbiz-dev@incubator.apache.org/msg00970.html
Modified:
incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
Modified: incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
URL: http://svn.apache.org/viewvc/incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml?view=diff&rev=486056&r1=486055&r2=486056
==============================================================================
--- incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml (original)
+++ incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml Tue Dec 12 00:18:38 2006
@@ -131,6 +131,9 @@
<log level="warning" message="Create Payment Application: Amount to apply [${paymentAppl.amountApplied}] is greater than the outstanding amount [${notApplied}] of the invoice [${invoice.invoiceId}]. Creating Payment Application for outstanding amount [${notApplied}] instead."/>
<set field="paymentAppl.amountApplied" from-field="notApplied"/>
</if-compare-field>
+ <if-not-empty field-name="invoice.billingAccountId">
+ <set field="paymentAppl.billingAccountId" from-field="invoice.billingAccountId"/>
+ </if-not-empty>
</if-not-empty>
<sequenced-id-to-env sequence-name="PaymentApplication" env-name="paymentAppl.paymentApplicationId"/>
Re: Design proposal about Billing Accounts
Posted by Jacopo Cappellato <ti...@sastau.it>.
Ok,
I've committed a similar (slightly improved) patch in rev. 488588
Jacopo
David E Jones wrote:
>
> Jacopo,
>
> I think that patch looks okay as a fix for this problem. It looks like
> it is basically just reordering operations in a way that seems to make
> more sense given the more general scope and so if you've tested this and
> it's working okay, then I'd say go for it (I just reviewed the code, ie
> no testing, and I'm not totally aware of the context).
>
> -David
>
>
> On Dec 18, 2006, at 12:24 AM, Jacopo Cappellato wrote:
>
>> David,
>>
>> I don't really have a strong opinion on this subject right now, I've
>> also read Si's comment
>> https://issues.apache.org/jira/browse/OFBIZ-93#action_12458933
>> and I'm doing some tests right now to see if I can figure out how it
>> works.
>> I did these proposals because I got the impression that the billing
>> account implementation in svn could have some bugs caused by design
>> decisions different from the original design for billing account.
>> In fact the current order entry checkout process (in the backoffice
>> application) is broken (the billingAccountId is not stored in the
>> order etc...) if you select the billing account as payment method; but
>> probably, as suggested by Si, this is just caused by a series of misc
>> bugs (introduced by recent changes); I'll further investigate this (in
>> the meantime, maybe you could have a quick review to the
>> order_billingAccount_co.patch I've attached to OFBIZ-92, that will fix
>> the checkout error, in a quick-and-rather-dirty way).
>>
>> Just to be sure to understand: if I want to associate (part of) the
>> amount of a payment in advance to a billing account I have to 'apply'
>> the amount to the billing account (using a PaymentApplication with
>> empty invoiceId); if I want to use (part of) that amount to pay an
>> invoice (associated to the billing account) I have to create a new
>> payment application (as usual) from the payment to the invoice (using
>> a PaymentApplication with invoiceId and billingAccountId set).
>> Is that correct?
>>
>> Thanks,
>>
>> Jacopo
>>
>>
>>
>> David E Jones wrote:
>>> I'm not so sure about this one Jacopo...
>>> Is the only point to be able to associate a Payment to a
>>> BillingAccount without a corresponding invoice? Right now that is
>>> possible with the PaymentApplication entity, ie we've been using it
>>> for a while this way where there is a Payment in advance on a
>>> BillingAccount, leading to a positive balance on it.
>>> This may not be the best way to do it... is that what you're saying
>>> that structuring it differently would make the processing or figuring
>>> out the status easier somehow?
>>> -David
>>> On Dec 12, 2006, at 7:19 AM, Jacopo Cappellato wrote:
>>>> One last detail I'd like to specify about the following point is:
>>>>
>>>> > c)add the following constraint: a payment and an invoice
>>>> associated to
>>>> > two different billing accounts cannot be matched; the application
>>>> of a
>>>> > payment with null billingAccountId to an invoice associated to a
>>>> > billing account is ok
>>>>
>>>> is that "if a payment has the billing account id set, then it can
>>>> only be applied to invoices associated to the same billing account"
>>>>
>>>> Jacopo
>>>>
>>>> Jacopo Cappellato wrote:
>>>>> David,
>>>>> after some more study about this I think that there are some things
>>>>> that should still be fixed.
>>>>> Right now the billingAccountId is stored in the OrderHeader, then
>>>>> propagated to the Invoice header and finally (with my last patch)
>>>>> to the PaymentApplications applied to the invoice.
>>>>> However, in my opinion we can remove the billingAccountId field
>>>>> from the PaymentApplication entity because it is superfluous. We
>>>>> should instead add it to the Payment entity, in order to implement
>>>>> the ability to accept payments and associate them to a billing
>>>>> account (before the invoices are created, for example).
>>>>> Right now, if we need to store a payment before the invoice is
>>>>> created and we want to associate it to a billing account we do the
>>>>> following:
>>>>> 1) we create a Payment
>>>>> 2) we create a PaymentApplication (for the same amount) and
>>>>> associate it to the billing account
>>>>> In my opinion this is not completely correct, because we are not
>>>>> really applying a payment to something real like an invoice (we
>>>>> just need to associate it to the billing account); in fact, for
>>>>> example, the same payment could be used later to pay two different
>>>>> invoives associated to the billing account and so the original
>>>>> PaymentApplication entry would be wrong.
>>>>> To summarize, here is what I propose:
>>>>> a) remove the field PaymentApplication.billingAccountId
>>>>> b) add the field Payment.billingAccountId
>>>>> c) add the following constraint: a payment and an invoice
>>>>> associated to two different billing accounts cannot be matched; the
>>>>> application of a payment with null billingAccountId to an invoice
>>>>> associated to a billing account is ok
>>>>> d) in the balance of a billing account we should simply consider:
>>>>> d1) all the open amount of the invoices associated to the billing
>>>>> account (-)
>>>>> d2) the unapplied amount of all the payments associated to the
>>>>> billing account
>>>>> Does it make sense?
>>>>> Jacopo
>>>>
>>
Re: Design proposal about Billing Accounts
Posted by David E Jones <jo...@undersunconsulting.com>.
Jacopo,
I think that patch looks okay as a fix for this problem. It looks
like it is basically just reordering operations in a way that seems
to make more sense given the more general scope and so if you've
tested this and it's working okay, then I'd say go for it (I just
reviewed the code, ie no testing, and I'm not totally aware of the
context).
-David
On Dec 18, 2006, at 12:24 AM, Jacopo Cappellato wrote:
> David,
>
> I don't really have a strong opinion on this subject right now,
> I've also read Si's comment https://issues.apache.org/jira/browse/
> OFBIZ-93#action_12458933
> and I'm doing some tests right now to see if I can figure out how
> it works.
> I did these proposals because I got the impression that the billing
> account implementation in svn could have some bugs caused by design
> decisions different from the original design for billing account.
> In fact the current order entry checkout process (in the backoffice
> application) is broken (the billingAccountId is not stored in the
> order etc...) if you select the billing account as payment method;
> but probably, as suggested by Si, this is just caused by a series
> of misc bugs (introduced by recent changes); I'll further
> investigate this (in the meantime, maybe you could have a quick
> review to the order_billingAccount_co.patch I've attached to
> OFBIZ-92, that will fix the checkout error, in a quick-and-rather-
> dirty way).
>
> Just to be sure to understand: if I want to associate (part of) the
> amount of a payment in advance to a billing account I have to
> 'apply' the amount to the billing account (using a
> PaymentApplication with empty invoiceId); if I want to use (part
> of) that amount to pay an invoice (associated to the billing
> account) I have to create a new payment application (as usual) from
> the payment to the invoice (using a PaymentApplication with
> invoiceId and billingAccountId set).
> Is that correct?
>
> Thanks,
>
> Jacopo
>
>
>
> David E Jones wrote:
>> I'm not so sure about this one Jacopo...
>> Is the only point to be able to associate a Payment to a
>> BillingAccount without a corresponding invoice? Right now that is
>> possible with the PaymentApplication entity, ie we've been using
>> it for a while this way where there is a Payment in advance on a
>> BillingAccount, leading to a positive balance on it.
>> This may not be the best way to do it... is that what you're
>> saying that structuring it differently would make the processing
>> or figuring out the status easier somehow?
>> -David
>> On Dec 12, 2006, at 7:19 AM, Jacopo Cappellato wrote:
>>> One last detail I'd like to specify about the following point is:
>>>
>>> > c)add the following constraint: a payment and an invoice
>>> associated to
>>> > two different billing accounts cannot be matched; the
>>> application of a
>>> > payment with null billingAccountId to an invoice associated to a
>>> > billing account is ok
>>>
>>> is that "if a payment has the billing account id set, then it can
>>> only be applied to invoices associated to the same billing account"
>>>
>>> Jacopo
>>>
>>> Jacopo Cappellato wrote:
>>>> David,
>>>> after some more study about this I think that there are some
>>>> things that should still be fixed.
>>>> Right now the billingAccountId is stored in the OrderHeader,
>>>> then propagated to the Invoice header and finally (with my last
>>>> patch) to the PaymentApplications applied to the invoice.
>>>> However, in my opinion we can remove the billingAccountId field
>>>> from the PaymentApplication entity because it is superfluous. We
>>>> should instead add it to the Payment entity, in order to
>>>> implement the ability to accept payments and associate them to
>>>> a billing account (before the invoices are created, for example).
>>>> Right now, if we need to store a payment before the invoice is
>>>> created and we want to associate it to a billing account we do
>>>> the following:
>>>> 1) we create a Payment
>>>> 2) we create a PaymentApplication (for the same amount) and
>>>> associate it to the billing account
>>>> In my opinion this is not completely correct, because we are not
>>>> really applying a payment to something real like an invoice (we
>>>> just need to associate it to the billing account); in fact, for
>>>> example, the same payment could be used later to pay two
>>>> different invoives associated to the billing account and so the
>>>> original PaymentApplication entry would be wrong.
>>>> To summarize, here is what I propose:
>>>> a) remove the field PaymentApplication.billingAccountId
>>>> b) add the field Payment.billingAccountId
>>>> c) add the following constraint: a payment and an invoice
>>>> associated to two different billing accounts cannot be matched;
>>>> the application of a payment with null billingAccountId to an
>>>> invoice associated to a billing account is ok
>>>> d) in the balance of a billing account we should simply consider:
>>>> d1) all the open amount of the invoices associated to the
>>>> billing account (-)
>>>> d2) the unapplied amount of all the payments associated to the
>>>> billing account
>>>> Does it make sense?
>>>> Jacopo
>>>
>
Re: Design proposal about Billing Accounts
Posted by Jacopo Cappellato <ti...@sastau.it>.
David,
I don't really have a strong opinion on this subject right now, I've
also read Si's comment
https://issues.apache.org/jira/browse/OFBIZ-93#action_12458933
and I'm doing some tests right now to see if I can figure out how it works.
I did these proposals because I got the impression that the billing
account implementation in svn could have some bugs caused by design
decisions different from the original design for billing account.
In fact the current order entry checkout process (in the backoffice
application) is broken (the billingAccountId is not stored in the order
etc...) if you select the billing account as payment method; but
probably, as suggested by Si, this is just caused by a series of misc
bugs (introduced by recent changes); I'll further investigate this (in
the meantime, maybe you could have a quick review to the
order_billingAccount_co.patch I've attached to OFBIZ-92, that will fix
the checkout error, in a quick-and-rather-dirty way).
Just to be sure to understand: if I want to associate (part of) the
amount of a payment in advance to a billing account I have to 'apply'
the amount to the billing account (using a PaymentApplication with empty
invoiceId); if I want to use (part of) that amount to pay an invoice
(associated to the billing account) I have to create a new payment
application (as usual) from the payment to the invoice (using a
PaymentApplication with invoiceId and billingAccountId set).
Is that correct?
Thanks,
Jacopo
David E Jones wrote:
>
> I'm not so sure about this one Jacopo...
>
> Is the only point to be able to associate a Payment to a BillingAccount
> without a corresponding invoice? Right now that is possible with the
> PaymentApplication entity, ie we've been using it for a while this way
> where there is a Payment in advance on a BillingAccount, leading to a
> positive balance on it.
>
> This may not be the best way to do it... is that what you're saying that
> structuring it differently would make the processing or figuring out the
> status easier somehow?
>
> -David
>
>
> On Dec 12, 2006, at 7:19 AM, Jacopo Cappellato wrote:
>
>> One last detail I'd like to specify about the following point is:
>>
>> > c)add the following constraint: a payment and an invoice associated to
>> > two different billing accounts cannot be matched; the application of a
>> > payment with null billingAccountId to an invoice associated to a
>> > billing account is ok
>>
>> is that "if a payment has the billing account id set, then it can only
>> be applied to invoices associated to the same billing account"
>>
>> Jacopo
>>
>> Jacopo Cappellato wrote:
>>> David,
>>> after some more study about this I think that there are some things
>>> that should still be fixed.
>>> Right now the billingAccountId is stored in the OrderHeader, then
>>> propagated to the Invoice header and finally (with my last patch) to
>>> the PaymentApplications applied to the invoice.
>>> However, in my opinion we can remove the billingAccountId field from
>>> the PaymentApplication entity because it is superfluous. We should
>>> instead add it to the Payment entity, in order to implement the
>>> ability to accept payments and associate them to a billing account
>>> (before the invoices are created, for example).
>>> Right now, if we need to store a payment before the invoice is
>>> created and we want to associate it to a billing account we do the
>>> following:
>>> 1) we create a Payment
>>> 2) we create a PaymentApplication (for the same amount) and associate
>>> it to the billing account
>>> In my opinion this is not completely correct, because we are not
>>> really applying a payment to something real like an invoice (we just
>>> need to associate it to the billing account); in fact, for example,
>>> the same payment could be used later to pay two different invoives
>>> associated to the billing account and so the original
>>> PaymentApplication entry would be wrong.
>>> To summarize, here is what I propose:
>>> a) remove the field PaymentApplication.billingAccountId
>>> b) add the field Payment.billingAccountId
>>> c) add the following constraint: a payment and an invoice associated
>>> to two different billing accounts cannot be matched; the application
>>> of a payment with null billingAccountId to an invoice associated to a
>>> billing account is ok
>>> d) in the balance of a billing account we should simply consider:
>>> d1) all the open amount of the invoices associated to the billing
>>> account (-)
>>> d2) the unapplied amount of all the payments associated to the
>>> billing account
>>> Does it make sense?
>>> Jacopo
>>
Re: Design proposal about Billing Accounts WAS: [Re: svn commit: r486056 - /incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml]
Posted by David E Jones <jo...@undersunconsulting.com>.
I'm not so sure about this one Jacopo...
Is the only point to be able to associate a Payment to a
BillingAccount without a corresponding invoice? Right now that is
possible with the PaymentApplication entity, ie we've been using it
for a while this way where there is a Payment in advance on a
BillingAccount, leading to a positive balance on it.
This may not be the best way to do it... is that what you're saying
that structuring it differently would make the processing or figuring
out the status easier somehow?
-David
On Dec 12, 2006, at 7:19 AM, Jacopo Cappellato wrote:
> One last detail I'd like to specify about the following point is:
>
> > c)add the following constraint: a payment and an invoice
> associated to
> > two different billing accounts cannot be matched; the application
> of a
> > payment with null billingAccountId to an invoice associated to a
> > billing account is ok
>
> is that "if a payment has the billing account id set, then it can
> only be applied to invoices associated to the same billing account"
>
> Jacopo
>
> Jacopo Cappellato wrote:
>> David,
>> after some more study about this I think that there are some
>> things that should still be fixed.
>> Right now the billingAccountId is stored in the OrderHeader, then
>> propagated to the Invoice header and finally (with my last patch)
>> to the PaymentApplications applied to the invoice.
>> However, in my opinion we can remove the billingAccountId field
>> from the PaymentApplication entity because it is superfluous. We
>> should instead add it to the Payment entity, in order to implement
>> the ability to accept payments and associate them to a billing
>> account (before the invoices are created, for example).
>> Right now, if we need to store a payment before the invoice is
>> created and we want to associate it to a billing account we do the
>> following:
>> 1) we create a Payment
>> 2) we create a PaymentApplication (for the same amount) and
>> associate it to the billing account
>> In my opinion this is not completely correct, because we are not
>> really applying a payment to something real like an invoice (we
>> just need to associate it to the billing account); in fact, for
>> example, the same payment could be used later to pay two different
>> invoives associated to the billing account and so the original
>> PaymentApplication entry would be wrong.
>> To summarize, here is what I propose:
>> a) remove the field PaymentApplication.billingAccountId
>> b) add the field Payment.billingAccountId
>> c) add the following constraint: a payment and an invoice
>> associated to two different billing accounts cannot be matched;
>> the application of a payment with null billingAccountId to an
>> invoice associated to a billing account is ok
>> d) in the balance of a billing account we should simply consider:
>> d1) all the open amount of the invoices associated to the billing
>> account (-)
>> d2) the unapplied amount of all the payments associated to the
>> billing account
>> Does it make sense?
>> Jacopo
>
Design proposal about Billing Accounts WAS: [Re: svn commit: r486056
- /incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml]
Posted by Jacopo Cappellato <ti...@sastau.it>.
One last detail I'd like to specify about the following point is:
> c)add the following constraint: a payment and an invoice associated to
> two different billing accounts cannot be matched; the application of a
> payment with null billingAccountId to an invoice associated to a
> billing account is ok
is that "if a payment has the billing account id set, then it can only
be applied to invoices associated to the same billing account"
Jacopo
Jacopo Cappellato wrote:
> David,
>
> after some more study about this I think that there are some things that
> should still be fixed.
>
> Right now the billingAccountId is stored in the OrderHeader, then
> propagated to the Invoice header and finally (with my last patch) to the
> PaymentApplications applied to the invoice.
> However, in my opinion we can remove the billingAccountId field from the
> PaymentApplication entity because it is superfluous. We should instead
> add it to the Payment entity, in order to implement the ability to
> accept payments and associate them to a billing account (before the
> invoices are created, for example).
> Right now, if we need to store a payment before the invoice is created
> and we want to associate it to a billing account we do the following:
> 1) we create a Payment
> 2) we create a PaymentApplication (for the same amount) and associate it
> to the billing account
> In my opinion this is not completely correct, because we are not really
> applying a payment to something real like an invoice (we just need to
> associate it to the billing account); in fact, for example, the same
> payment could be used later to pay two different invoives associated to
> the billing account and so the original PaymentApplication entry would
> be wrong.
>
> To summarize, here is what I propose:
>
> a) remove the field PaymentApplication.billingAccountId
> b) add the field Payment.billingAccountId
> c) add the following constraint: a payment and an invoice associated to
> two different billing accounts cannot be matched; the application of a
> payment with null billingAccountId to an invoice associated to a billing
> account is ok
> d) in the balance of a billing account we should simply consider:
> d1) all the open amount of the invoices associated to the billing
> account (-)
> d2) the unapplied amount of all the payments associated to the billing
> account
>
> Does it make sense?
>
> Jacopo
>
>
>
Re: svn commit: r486056 - /incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
Posted by Jacopo Cappellato <ti...@sastau.it>.
David,
after some more study about this I think that there are some things that
should still be fixed.
Right now the billingAccountId is stored in the OrderHeader, then
propagated to the Invoice header and finally (with my last patch) to the
PaymentApplications applied to the invoice.
However, in my opinion we can remove the billingAccountId field from the
PaymentApplication entity because it is superfluous. We should instead
add it to the Payment entity, in order to implement the ability to
accept payments and associate them to a billing account (before the
invoices are created, for example).
Right now, if we need to store a payment before the invoice is created
and we want to associate it to a billing account we do the following:
1) we create a Payment
2) we create a PaymentApplication (for the same amount) and associate it
to the billing account
In my opinion this is not completely correct, because we are not really
applying a payment to something real like an invoice (we just need to
associate it to the billing account); in fact, for example, the same
payment could be used later to pay two different invoives associated to
the billing account and so the original PaymentApplication entry would
be wrong.
To summarize, here is what I propose:
a) remove the field PaymentApplication.billingAccountId
b) add the field Payment.billingAccountId
c) add the following constraint: a payment and an invoice associated to
two different billing accounts cannot be matched; the application of a
payment with null billingAccountId to an invoice associated to a billing
account is ok
d) in the balance of a billing account we should simply consider:
d1) all the open amount of the invoices associated to the billing
account (-)
d2) the unapplied amount of all the payments associated to the billing
account
Does it make sense?
Jacopo
David E Jones wrote:
>
> Thanks for taking care of this Jacopo.
>
> -David
>
>
> On Dec 12, 2006, at 1:18 AM, jacopoc@apache.org wrote:
>
>> Author: jacopoc
>> Date: Tue Dec 12 00:18:38 2006
>> New Revision: 486056
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=486056
>> Log:
>> If a Invoice is applied to a BillingAccount, Payment should be applied
>> to Invoice and also set BillingAccountId in PaymentApplication record.
>> So that the total Invoice amount and Payment amount whould balance for
>> a BillingAccount number.
>> For details, see the interesting discussion here
>> http://www.mail-archive.com/ofbiz-dev@incubator.apache.org/msg00970.html
>>
>> Modified:
>>
>> incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
>>
>>
>> Modified:
>> incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml?view=diff&rev=486056&r1=486055&r2=486056
>>
>> ==============================================================================
>>
>> ---
>> incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
>> (original)
>> +++
>> incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
>> Tue Dec 12 00:18:38 2006
>> @@ -131,6 +131,9 @@
>> <log level="warning" message="Create Payment
>> Application: Amount to apply [${paymentAppl.amountApplied}] is greater
>> than the outstanding amount [${notApplied}] of the invoice
>> [${invoice.invoiceId}]. Creating Payment Application for outstanding
>> amount [${notApplied}] instead."/>
>> <set field="paymentAppl.amountApplied"
>> from-field="notApplied"/>
>> </if-compare-field>
>> + <if-not-empty field-name="invoice.billingAccountId">
>> + <set field="paymentAppl.billingAccountId"
>> from-field="invoice.billingAccountId"/>
>> + </if-not-empty>
>> </if-not-empty>
>>
>> <sequenced-id-to-env sequence-name="PaymentApplication"
>> env-name="paymentAppl.paymentApplicationId"/>
>>
>>
Re: svn commit: r486056 - /incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/accounting/payment/PaymentServices.xml
Posted by David E Jones <jo...@undersunconsulting.com>.
Thanks for taking care of this Jacopo.
-David
On Dec 12, 2006, at 1:18 AM, jacopoc@apache.org wrote:
> Author: jacopoc
> Date: Tue Dec 12 00:18:38 2006
> New Revision: 486056
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=486056
> Log:
> If a Invoice is applied to a BillingAccount, Payment should be
> applied to Invoice and also set BillingAccountId in
> PaymentApplication record. So that the total Invoice amount and
> Payment amount whould balance for a BillingAccount number.
> For details, see the interesting discussion here http://www.mail-
> archive.com/ofbiz-dev@incubator.apache.org/msg00970.html
>
> Modified:
> incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/
> accounting/payment/PaymentServices.xml
>
> Modified: incubator/ofbiz/trunk/applications/accounting/script/org/
> ofbiz/accounting/payment/PaymentServices.xml
> URL: http://svn.apache.org/viewvc/incubator/ofbiz/trunk/
> applications/accounting/script/org/ofbiz/accounting/payment/
> PaymentServices.xml?view=diff&rev=486056&r1=486055&r2=486056
> ======================================================================
> ========
> --- incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/
> accounting/payment/PaymentServices.xml (original)
> +++ incubator/ofbiz/trunk/applications/accounting/script/org/ofbiz/
> accounting/payment/PaymentServices.xml Tue Dec 12 00:18:38 2006
> @@ -131,6 +131,9 @@
> <log level="warning" message="Create Payment
> Application: Amount to apply [${paymentAppl.amountApplied}] is
> greater than the outstanding amount [${notApplied}] of the invoice
> [${invoice.invoiceId}]. Creating Payment Application for
> outstanding amount [${notApplied}] instead."/>
> <set field="paymentAppl.amountApplied" from-
> field="notApplied"/>
> </if-compare-field>
> + <if-not-empty field-name="invoice.billingAccountId">
> + <set field="paymentAppl.billingAccountId" from-
> field="invoice.billingAccountId"/>
> + </if-not-empty>
> </if-not-empty>
>
> <sequenced-id-to-env sequence-name="PaymentApplication"
> env-name="paymentAppl.paymentApplicationId"/>
>
>