Posted by
SkipDever on
Nov 02, 2007; 8:51pm
URL: http://ofbiz.116.s1.nabble.com/Accounts-Receivable-tp184969p184991.html
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
> > >>>
> >
> >
> >
>