Posted by
SkipDever on
Nov 02, 2007; 7:54pm
URL: http://ofbiz.116.s1.nabble.com/Accounts-Receivable-tp184969p184995.html
Jonathon
I would have to defer to your massive Ofbiz knowledge regarding "maxAmount".
I personally do not believe the entity should be used at all for billing
accounts.
What I want to comment on is your statement "Tested with OFBiz 4.0 (yeah,
I'm aggressively pushing that branch to its
limits now)."
My response? YAAAAAAAAAAA
Skip
-----Original Message-----
From: Jonathon -- Improov [mailto:
[hidden email]]
Sent: Friday, November 02, 2007 1:18 AM
To:
[hidden email]
Subject: Re: Accounts Receivable
A quick question here. Isn't maxAmount *not* supposed to tally with the
order amounts? I always thought that maxAmount is simply a "billing
instruction", which means "do not charge more than X amount on this
credit card". Based on that understanding, I would expect the totalled
maxAmount(s) from several payment methods stacked on a single order to
be way higher than the order grand total. Say I might have 4-5 credit
cards with a combined "maxAmount" of $30K, but my order grand total
could be just $50.
Is my understanding correct in terms of payment methods and payment
gateway concepts?
I know that OFBiz doesn't quite handle maxAmount in that way.
Yes, I believe there's a bug with the maxAmount whenever it is "assumed"
from the "order's total outstanding amount" (amount not addressed by any
planned payments). A common way to reproduce this bug is by using a
mixture of offline payments and credit card payments for a single order.
Tested with OFBiz 4.0 (yeah, I'm aggressively pushing that branch to its
limits now).
Jonathon
Scott Gray 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
>>>>>
>>>>>
>>
>>
>
>
>