skip how does this fit with GL and transactions.
[EMAIL PROTECTED] sent the following on 11/2/2007 12:58 PM: > Scott > > In my view, this is kinda the hard way of doing things. > > Easy way: > > billing account amount = SUM(unpaid invoice amounts) > billing account available balance = billing acount limit - (billing account > amount + uninvoiced orders) > > Because customer returns and credits also generate an invoice, this all > works. > > Simple as long as you can determine which invoices are unpaid. Of course, > If you are gonna do a proper customer billing statement, you have to know > this anyway. > > I have no idea why you guys feel the need to cling to this > OrderPaymentPreferences entity for computing billing accounts. > > Skip > > -----Original Message----- > From: Scott Gray [mailto:[EMAIL PROTECTED] > Sent: Friday, November 02, 2007 1:02 PM > To: dev@ofbiz.apache.org > Subject: Re: Accounts Receivable > > > Hrmm that is a bit of problem, perhaps instead of using maxAmount we > should do this: > billing account amount = order grand total - > SUM(otherPaymentPrefs.maxAmount) > We could probably still use maxAmount for storing the calculated > value, but put a seca on resetGrandTotal to recalculate it each time > the order changes? > > That way whatever isn't being paid for with other means goes on to the > billing account. > > Does anyone know what the use case is for letting a user set the > amount to be billed to the billing account? > > Scott > > On 03/11/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> 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 >>>>>> >>> >>> >> > > > >
