GL has a defualt all in one number for non GL accounting however if the granularity gets down to individual GL for each customer account I can see that you would need to do transactions to keep them uptodated. and in a GL it has to be a transaction for audit trail.
[EMAIL PROTECTED] sent the following on 11/2/2007 6:15 PM: > Should not be related. What goes into the GL is separate from AR issues. > You should be able to run Ofbiz without a GL if you want. > > On the other hand, each of these transactions is a GL candidate. > > Si Chen has in fact created a way to report on customer accounts by reading > the transactions out of one of the Acctxxx entities (I forget which one) and > it works. However, it does not and could never provide the detail normally > required for adequate reporting to the customer. > > Skip > > -----Original Message----- > From: BJ Freeman [mailto:[EMAIL PROTECTED] > Sent: Friday, November 02, 2007 7:27 PM > To: [email protected] > Subject: Re: Accounts Receivable > > > 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: [email protected] >> 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: [email protected] >>> 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: [email protected] >>>>> 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 >>>>>>> >>>> >> >> >> > > > >
