Thats part of the bug Scott. This is set at sale time. However, if you do not do a quick ship (use the Facilities shipping) and you add freight charges later, these are not accounted for in the OrderPaymentPreferences.
I have been arguing that while convenient, OrderPaymentPreferences is not the data underlying billing account. Skip -----Original Message----- From: Scott Gray [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 11:48 PM To: dev@ofbiz.apache.org Subject: Re: Accounts Receivable 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 > >>> > > >
