Re: Billing Accounts

[David E Jones]

The PMNT_RECEIVED status is the final status for payments received.



-David



http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams


On Nov 25, 2007, at 3:58 PM, [EMAIL PROTECTED] wrote:

I can see how this might be confusing. The status has nothing to do with how much of the payment is applied. The PMNT_CONFIRMED is the final status for payments sent (if a confirmation is received, otherwise it is just the sent status; depends on the company and supplier processes). For more info on these statuses and transitions between them see the AccountingTypeData.xml file. This pattern is followed throughout OFBiz for other status sets (one for each type basically). P.S. It's great to see your involvement and commentary and thoughts Skip. You might have a better experience if you invested in a little more study before trying to follow OFBiz... it really can be very large and confusing if you don't have at least a basic grasp of some of the patterns (this one is a good example). The best place to get started, as I've mentioned in other emails, is these free videos and supporting artifacts:

David


the payment is fully applied, and once set to PMNT_CONFIRMED, payment



point.


unnecessary code.

An Invoice remains unpaid (not INVOICE_PAID) until it has a

providing audit trails.


a payment to a billing account and why I agree with your statement "A
BillingAccount is essentially nothing. Just forget that it exists in
relation to regular Invoice and Payment processes."


a payment to Invoices one at a time, I have a service that will
automatically apply a Payment to the oldest Invoice(s).

Skip

-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 25, 2007 2:03 PM
To: dev@ofbiz.apache.org
Subject: Re: Billing Accounts



A Payment applied to a BillingAccount does not mean the payment is
closed, in fact I'm not even sure what it means to say a payment is
closed... did you have something in mind? Whatever it means to you, a
payment is either not, partially, or fully applied.

-David


On Nov 25, 2007, at 11:54 AM, [EMAIL PROTECTED] wrote:

This "closed" is more of a programming construct than anything real, to me at least. The status is PMNT_CONFIRMED. PMNT_CONFIRMED cannot be set until applications cannot be removed. So to me, closed means PMNT_CONFIRMED. In Ofbiz, you cannot set the status to PMNT_CONFIRMED until the payment is fully applied. This means that if you apply some or all of it to a billing account, that part of the payment applied to the billing account goes out into space somewhere, i.e. cannot be applied to a real invoice at some later My new code has a service triggered by the creation of an invoice that goes out looking for unapplied payments (and these include credits from returns etc). If a payment has been applied to a billing account, it will not be found, so the customer ends up forever having paid some money that cannot be applied to an invoice, at least not without a lot of what would have been paymentapplication(s) to fully cover it. So the issue here is not so much with the Payment status, but with Invoice status and accounting for it and It is for these reasons that I do not think it should be permitted to apply Customer payments should remain PMNT_RECEIVED (or something less) until fully applied to Invoices. For those users who don't want to manually apply

Jacapo

https://localhost:8443/accounting/control/editPaymentApplications

and one of them involves applying it to the billing account.

I don't see the point in applying a payment to a billing account.
Otherwise, how to you know when an invoice is paid?  What happens
later, do
you take the money out of the billing account and apply it to an
invoice?

There may be some european need that I am not aware of to apply a
customer
payment to a Tax Authority, but that is not the case in the U.S, so
I don't
see the point in the Tax Auth Geo ID.

The main one for me is applying a payment to a billing account.  If
there
are no invoices to apply to, the Payment should stay open.  It makes
everything else then so easy.


Skip



-----Original Message-----
From: Jacopo Cappellato [mailto:[EMAIL PROTECTED]
Sent: Saturday, November 24, 2007 11:45 PM
To: dev@ofbiz.apache.org
Subject: Re: Billing Accounts


Skip,

I very well remember that valuable message from David: it helped me a
lot when I've recently refactored the billing accounts.
Where is the current implementation not following David's notes?

Thanks,

Jacopo

[EMAIL PROTECTED] wrote:

I just ran across this in the Wiki from David concerning Billing
Accounts
from back in July.

http://docs.ofbiz.org/display/OFBIZ/Billing+Account

The current Ofbiz implementation does not operate as described in
this
document.  The "addon" I partially provided here:

https://issues.apache.org/jira/browse/OFBIZ-1421

follows it exactly or nearly so.  Furthermore, the logic is so
simple.  It
is a shame that billingAccountId ended up in so many entities.

I think these paragraphs bear repeating because he says it so much
better
than me:

"A BillingAccount is essentially nothing. Just forget that it
exists in
relation to regular Invoice and Payment processes. With or without a
BillingAccount those operate and flow the same.

A BillingAccount simply allows for more organization of Invoices and
Payments related to things like the following (which is not an
exhaustive
list by any means):"



Skip

smime.p7s
Description: S/MIME cryptographic signature