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
