> Scott
>
> Can you tell me what files were affected? I want to move this fix into my
> production code, but not the whole 591434 svn download.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:
[hidden email]]
> Sent: Friday, November 02, 2007 2:47 AM
> To:
[hidden email]
> Subject: Re: Accounts Receivable
>
>
> 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 <
[hidden email]> 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 <
[hidden email]> 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
> > >
> > >
> > > skip@theDevers 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:
[hidden email]]
> > > > Sent: Thursday, November 01, 2007 3:43 AM
> > > > To:
[hidden email]
> > > > 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 <
[hidden email]> 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
> > > >>>
> > >
> > >
> > >
> >
>
>