> 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:
[hidden email]]
> Sent: Thursday, November 01, 2007 11:48 PM
> To:
[hidden email]
> 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 <
[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
> > >>>
> >
> >
> >
>
>