Found and fixed the problem in rev. 591283, quick checkout wasn't recalculating shipping and taxes before loading the payment info.
Regards Scott On 02/11/2007, Scott Gray <[EMAIL PROTECTED]> 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 > > >>> > > > > > > >
