Jonathon I would have to defer to your massive Ofbiz knowledge regarding "maxAmount". I personally do not believe the entity should be used at all for billing accounts.
What I want to comment on is your statement "Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its limits now)." My response? YAAAAAAAAAAA Skip -----Original Message----- From: Jonathon -- Improov [mailto:[EMAIL PROTECTED] Sent: Friday, November 02, 2007 1:18 AM To: dev@ofbiz.apache.org Subject: Re: Accounts Receivable A quick question here. Isn't maxAmount *not* supposed to tally with the order amounts? I always thought that maxAmount is simply a "billing instruction", which means "do not charge more than X amount on this credit card". Based on that understanding, I would expect the totalled maxAmount(s) from several payment methods stacked on a single order to be way higher than the order grand total. Say I might have 4-5 credit cards with a combined "maxAmount" of $30K, but my order grand total could be just $50. Is my understanding correct in terms of payment methods and payment gateway concepts? I know that OFBiz doesn't quite handle maxAmount in that way. Yes, I believe there's a bug with the maxAmount whenever it is "assumed" from the "order's total outstanding amount" (amount not addressed by any planned payments). A common way to reproduce this bug is by using a mixture of offline payments and credit card payments for a single order. Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its limits now). Jonathon Scott Gray wrote: > Hi Skip, Jacopo > > >> There are flaws >> and complications in the latter in that tax and shipping are not taken into >> account and shipping charges added later seem to be ignored. >> > > I'm just noticing this too, I've got a few orders showing up that have > maxAmount set less than the order grand total, that's a bug right? > > Thanks > Scott > > On 02/11/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > >> Hi Skip, >> >> this looks interesting. >> However, from your message, it is not completely clear to me when you >> speak about existing features/issues or new features (and issues?) in >> your upcoming contribution. >> >> It would be great if you could split the message into two parts: >> 1) one that describes the current situation with focus on possible issues >> 2) one with your proposal and suggested changes; (and also with new >> issues, if there are any) >> >> This would help a lot to simplify the discussion. >> >> Thanks, >> >> Jacopo >> >> >> [EMAIL PROTECTED] wrote: >> >>> I have this mostly working now and I want to run this past you guys to be >>> sure there are no objections or thoughts on the methods used. I would be >>> especially interested in hereing about any testing in out-of=the=way areas I >>> need to do. >>> >>> 1. First, billing accounts are based entirely on the existance of Payments >>> and Invoices against the billing account (we also take into account unbilled >>> Orders for available balance computations). We do not use >>> PaymentApplication alone or OrderPaymentPreference at all. There are flaws >>> and complications in the latter in that tax and shipping are not taken into >>> account and shipping charges added later seem to be ignored. >>> >>> 2. A customer can have multiple billing accounts. >>> >>> 3. Billing account net balance is the sum of the unpaid portion of all >>> Invoices against the billing account (including any credits). >>> >>> 3. Billing account available balance is the billing account limit - ((sum >>> of unpaid porting of invoices) + (unbilled Orders)) >>> This has a flaw TODO (I think) in that if an Order is created with back >>> orders on it and part has been shipped and an invoice created for that part, >>> the whole Order will still subtract from the available balance. >>> >>> 4. When payments are made, they are never applied to just the billing >>> account. They are applied to an invoice belonging to the billing account. >>> If there is an unapplied balance, a new credit Invoice is created to hold >>> the unapplied balance. >>> >>> This all works with Ofbiz code if I manually apply the payments to invoices. >>> There are many other possible ways to create a billing account >>> payment/application and I would have to remove them all except for one which >>> calls my new receiveBillingAccountPayment() service and automatically >>> applies the payment to the oldest invoice(s). >>> >>> This also works with opentaps code if I comment out Si's >>> captureBillingAccountPayments and let the Ofbiz service run. There is one >>> screen to change in Opentaps code in viewCustomerBillAcct."Customer Billing >>> Account Transactions" where outstanding invoices are not being displayed. I >>> also had to modify the Opentaps ftl calls to com.openstragegies.xxx to call >>> the same named (and modified) Ofbiz routines. >>> >>> TODO is a SECA to automatically apply any available credits when a new >>> billing account invoice is created. >>> >>> Can anyone see any holes in this or have any comments? >>> >>> Skip >>> >>> >>> >>> -----Original Message----- >>> From: Scott Gray [mailto:[EMAIL PROTECTED] >>> Sent: Thursday, November 01, 2007 3:43 AM >>> To: dev@ofbiz.apache.org >>> Subject: Re: Accounts Receivable >>> >>> >>> Yeah I guess it would help with that, although you still could still >>> pay an invoice directly with it (no billingAccountId on the Invoice), >>> but you couldn't associate the Payment with more than one billing >>> account unless you went for a many to many relationship. But that's >>> fine, I just thought I'd ask as it was the first thing I saw that >>> didn't make sense to me. >>> >>> Thanks >>> Scott >>> >>> On 01/11/2007, Jacopo Cappellato <[EMAIL PROTECTED]> wrote: >>> >>>> Hi Scott, >>>> >>>> Scott Gray wrote: >>>> >>>>> Hi Jacopo >>>>> >>>>> I decided to have a look at this stuff and it doesn't make sense to me >>>>> why we have the billingAccountId on PaymentApplication rather than on >>>>> Payment itself? >>>>> >>>> I agree with you that having the billingAccountId in the Payment entity >>>> would have made things simpler. I did not design this, it was already >>>> there when I've refactored/fixed the billing account processes. >>>> However, having the billingAccountId in the PaymentApplication improve >>>> the flexibility: I could receive a Payment and use one part of it to pay >>>> an invoice (not associated to a billing account) and use the remaining >>>> to 'fill' a billing account. >>>> >>>> Jacopo >>>> >>>> >>>>> It seems like the logic is pretty much the same >>>>> except we're doing it in a roundabout sort of way by creating a >>>>> PaymentApplication with null invoiceId just to maintain the link. >>>>> >>>>> Thanks >>>>> Scott >>>>> >>>>> >> >> > > >
