OFBiz › OFBiz - User

shipments made for out of stock items

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

111 messages Options

123456

David E Jones

Re: OrderHead and TrackingCode

On Oct 25, 2007, at 2:24 PM, William Perng wrote:

> There is a many to many relationship between OrderHeader table and
> TrackingCode table. I thought many(OrderHeader) to one
> (TrackingCode) should
> be good enough. Could anyone please tell me what's the design idea(or
> business benefit) behind this ?

In general tracking codes are attached to visiting of certain URLs or
other things. There can certainly be more than one in a session,
though usually one per tracking code type attached to orders. All
codes seen during the session are attached to the Visit though.

-David

smime.p7s (3K) Download Attachment

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Jacopo Cappellato

Yeppers

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Thursday, October 25, 2007 9:08 AM
To: [hidden email]
Subject: Re: captureBillingAccountPayments

This seems one of the errors introduced with the last framework
improvements...

I'm sure that others will jump in and help to fix this. Are you running
the latest trunk revision?

Jacopo

skip@theDevers wrote:

> Jacopo
>
> Tried the create a store credit thing and got this error:
>
>
>
> The Following Errors Occurred:
>
> Unknown parameter found: [createTrackingCodeOrderReturns.hasPermission]
>
> Unknown parameter found: [createTrackingCodeOrderReturns.responseMessage]
>
>
>
> when I clicked "Accept Return"
>
> What I did was:
>
> 1. Click "Order" tab, then check "Completed" and click submit.
>
> 2. Picked an existing completed order on DemoCustCust for one WG-1111
>
> 3. Clicked "Create Return" button 2/3rds down toward the right side.
>
> 4. Selected "Store Credit" from the drop down list for the item and two

tax

> entries (0.00 each for the tax entries) then clicked "return selected
> items".
>
> 5. Checked the "Select All" box and clicked "Return Items"
>
> 6. Clicked the "Accept Return" button.
>
>
> Here is the relevant part of the stack trace:
>
> 2007-10-25 08:46:43,361 (http-0.0.0.0-8443-Processor2) [
> ModelService.java:484:ERROR] [ModelService.validate] :
> {createTrackingCodeOrderReturns} : (IN) Required test error:
> org.ofbiz.service.ServiceValidationException: Unknown parameter found:
> [createTrackingCodeOrderReturns.hasPermission]Unknown parameter found:
> [createTrackingCodeOrderReturns.responseMessage]
> 2007-10-25 08:46:43,371 (http-0.0.0.0-8443-Processor2) [
> ServiceDispatcher.java:355:ERROR]
> ---- exception
> report ----------------------------------------------------------
> Incoming context (in runSync : createTrackingCodeOrderReturns) does not
> match expected requirements
> Exception: org.ofbiz.service.ServiceValidationException
> Message: Unknown parameter found:
> [createTrackingCodeOrderReturns.hasPermission]Unknown parameter found:
> [createTrackingCodeOrderReturns.responseMessage]
> ---- stack
> trace ---------------------------------------------------------------
> org.ofbiz.service.ServiceValidationException: Unknown parameter found:
> [createTrackingCodeOrderReturns.hasPermission]Unknown parameter found:
> [createTrackingCodeOrderReturns.responseMessage]
> org.ofbiz.service.ModelService.validate(ModelService.java:552)
>
> -----Original Message-----
> From: Jacopo Cappellato [mailto:[hidden email]]
> Sent: Thursday, October 25, 2007 1:54 AM
> To: [hidden email]
> Subject: Re: captureBillingAccountPayments
>
>
> skip@theDevers wrote:
>> Jacopo
>>
>> Makes perfect sense, in fact, its the almost perfect solution to my

second

>> question. Lets say you sold 4 items on 4 days on 4 invoices. The
> customer
>> pays for all 4 invoices. Then, a week later, item 2 breaks and he sends
> it
>> back for a credit. The following week, he buys something else. Is there
>> some way for the credit to show up on the in sales order payment options?
>> Could the same logic be used?
>>
>
> Yes,
>
> the business logic is the following one (correct me if I am wrong):
>
> 1) a customer return is created for 2 items
> 2) you should select as the return type: "store credit" this will store
> (as a PaymentApplication) the credit to a billing account associated
> to the customer
> 3) the new amount will increase the available balance of the billing
> account (that can be used during order entry)
> This should work, but if you see something wrong please let us know.
>
> Jacopo
>
>
>>
>> Skip
>>
>>
>> -----Original Message-----
>> From: Jacopo Cappellato [mailto:[hidden email]]
>> Sent: Thursday, October 25, 2007 1:23 AM
>> To: [hidden email]
>> Subject: Re: captureBillingAccountPayments
>>
>>
>> skip@theDevers wrote:
>>> I am having a discussion with Si about billing accounts. For me,
>>> captureBillingAccountPayments works and the deprecated
>>> captureBillingAccountPayment does not.
>>>
>>> However, captureBillingAccountPayments essentially does nothing (which

>>> the right thing to do in this case).
>>>
>>> My question is, what was the intent of the logic after the
>>>
>>>
>>> if (UtilValidate.isNotEmpty(paymentApplications)) {
>>>
>>> which for me is always empty and never gets executed.
>>>
>>> Can the author comment? Is there some case where this will contain
>>> paymentApplications?
>>>
>>> Skip
>> Let's say you get a billing account and two not paid invoices associated
>> to it, one for 30$ and one for 50$.
>> You get a payment from your customer for 70$; you associate the whole
>> payment to the billing account: this will create a PaymentApplication
>> record with billingAccountId set, and a null invoiceId.
>> Then, if you go to the billing account's invoices screen and you click
>> on the "capture payments" link near to the 30$ invoice, then the
>> captureBillingAccountPayments service will be called -> the
>> PaymentApplication with null invoiceId (i.e. still not applied) is found
>> --> if (UtilValidate.isNotEmpty(paymentApplications)) is true -->
>> a new PaymentApplication is created for 30$ and applied to the invoice;
>> the original PaymentApplication is updated and the new 'available'
>> amount is 40$ (i.e. 70-30=40); we can now do the same with the otther
>> invoice...
>> At the end the first invoice will be PAID and the second PARTIALLY PAID.
>>
>> Does it make sense?
>>
>> Jacopo
>>
>>
>

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Jacopo Cappellato

Jacopo

As the man with the plan, I wanted to throw this new plan past you. I have
dug pretty deeply into the existing payment/billing account stuff and it
all seems a bit arcane to me and mostly because it looks like payments are
meant to be made from the company to a vendor and from a customer to the
company, all with the same screens.

I want to create a really easy to use AR payment system. The user enters a
payment and can then either apply the payment to individual invoices (and a
store credit if too much is received) or he can apply it to the billing
account, in which case we automatically apply it to the oldest invoices
first and then to a credit if too much is received.

Is this too simplistic for some reason I am missing? Do others have AR
needs outside this that would justify a more complicated transaction set?

Skip

Jacopo Cappellato

Re: captureBillingAccountPayments

skip@theDevers wrote:
> Jacopo
>
> As the man with the plan,

uhm... me? :-)

> I wanted to throw this new plan past you. I have
> dug pretty deeply into the existing payment/billing account stuff and it
> all seems a bit arcane to me and mostly because it looks like payments are
> meant to be made from the company to a vendor and from a customer to the
> company, all with the same screens.
>
> I want to create a really easy to use AR payment system. The user enters a
> payment and can then either apply the payment to individual invoices (and a
> store credit if too much is received) or he can apply it to the billing
> account, in which case we automatically apply it to the oldest invoices
> first and then to a credit if too much is received.
>

I'd suggest the following subtasks:

a) implement a new service to automatically apply the payments
associated to a billing account to the older open invoices associated to
the same account; the new service will have one mandatory parameter
"billingAccountId" (and maybe one optional parameter "paymentId") and it
will:
- select the open invoices associated to the billing account and sort
them by date (older first)
- iterate on the list and for each of them call the service
capturePaymentsByInvoice passing in the invoice id and billingAccountId
(this is the service that is invoked when you click on the "capture"
link near the invoice in the billingaccoun-invoices screen)

b) the new service can be invoked by a new link ("apply payments to
invoices") at the top of the billing account->invoices screen or (maybe
in your custom application) triggered every time you associate a payment
to a billing account.

This should cover your requirements but it is also generic enough to be
a good fit for OFBiz.

What do you think?

Jacopo

> Is this too simplistic for some reason I am missing? Do others have AR
> needs outside this that would justify a more complicated transaction set?
>
> Skip

Scott Gray

Re: captureBillingAccountPayments

Hi Jacopo

Our customers generally make payments for a specific invoice or group
of invoices so this wouldn't work for us. In our current system (non
web UI) we log a payment and then use a screen with a list of open
invoices to allocate the payment with the payment balance reducing as
each invoice is selected.

Regards
Scott

On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:

> skip@theDevers wrote:
> > Jacopo
> >
> > As the man with the plan,
>
> uhm... me? :-)
>
> > I wanted to throw this new plan past you. I have
> > dug pretty deeply into the existing payment/billing account stuff and it
> > all seems a bit arcane to me and mostly because it looks like payments are
> > meant to be made from the company to a vendor and from a customer to the
> > company, all with the same screens.
> >
> > I want to create a really easy to use AR payment system. The user enters a
> > payment and can then either apply the payment to individual invoices (and a
> > store credit if too much is received) or he can apply it to the billing
> > account, in which case we automatically apply it to the oldest invoices
> > first and then to a credit if too much is received.
> >
>
> I'd suggest the following subtasks:
>
> a) implement a new service to automatically apply the payments
> associated to a billing account to the older open invoices associated to
> the same account; the new service will have one mandatory parameter
> "billingAccountId" (and maybe one optional parameter "paymentId") and it
> will:
> - select the open invoices associated to the billing account and sort
> them by date (older first)
> - iterate on the list and for each of them call the service
> capturePaymentsByInvoice passing in the invoice id and billingAccountId
> (this is the service that is invoked when you click on the "capture"
> link near the invoice in the billingaccoun-invoices screen)
>
> b) the new service can be invoked by a new link ("apply payments to
> invoices") at the top of the billing account->invoices screen or (maybe
> in your custom application) triggered every time you associate a payment
> to a billing account.
>
> This should cover your requirements but it is also generic enough to be
> a good fit for OFBiz.
>
> What do you think?
>
> Jacopo
>
> > Is this too simplistic for some reason I am missing? Do others have AR
> > needs outside this that would justify a more complicated transaction set?
> >
> > Skip
>
>
>

Jacopo Cappellato

Re: captureBillingAccountPayments

Hi Scott,

Scott Gray wrote:
> Hi Jacopo
>
> Our customers generally make payments for a specific invoice or group
> of invoices so this wouldn't work for us. In our current system (non
> web UI) we log a payment and then use a screen with a list of open
> invoices to allocate the payment with the payment balance reducing as
> each invoice is selected.
>

I think that you have perfectly described what is currently implemented
in OFbiz :-)
Maybe I'm not been very clear on this: I was not suggesting to modify
the existing payment/payment application screens; instead I was
suggesting to add a new option, for billing accounts, to apply billing
account payments to billing account invoices by date; of course you can
continue, also in the billing account, to apply payments to specific
invoices.

Cheers,

Jacopo

> Regards
> Scott
>
> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
>> skip@theDevers wrote:
>>> Jacopo
>>>
>>> As the man with the plan,
>> uhm... me? :-)
>>
>>> I wanted to throw this new plan past you. I have
>>> dug pretty deeply into the existing payment/billing account stuff and it
>>> all seems a bit arcane to me and mostly because it looks like payments are
>>> meant to be made from the company to a vendor and from a customer to the
>>> company, all with the same screens.
>>>
>>> I want to create a really easy to use AR payment system. The user enters a
>>> payment and can then either apply the payment to individual invoices (and a
>>> store credit if too much is received) or he can apply it to the billing
>>> account, in which case we automatically apply it to the oldest invoices
>>> first and then to a credit if too much is received.
>>>
>> I'd suggest the following subtasks:
>>
>> a) implement a new service to automatically apply the payments
>> associated to a billing account to the older open invoices associated to
>> the same account; the new service will have one mandatory parameter
>> "billingAccountId" (and maybe one optional parameter "paymentId") and it
>> will:
>> - select the open invoices associated to the billing account and sort
>> them by date (older first)
>> - iterate on the list and for each of them call the service
>> capturePaymentsByInvoice passing in the invoice id and billingAccountId
>> (this is the service that is invoked when you click on the "capture"
>> link near the invoice in the billingaccoun-invoices screen)
>>
>> b) the new service can be invoked by a new link ("apply payments to
>> invoices") at the top of the billing account->invoices screen or (maybe
>> in your custom application) triggered every time you associate a payment
>> to a billing account.
>>
>> This should cover your requirements but it is also generic enough to be
>> a good fit for OFBiz.
>>
>> What do you think?
>>
>> Jacopo
>>
>>> Is this too simplistic for some reason I am missing? Do others have AR
>>> needs outside this that would justify a more complicated transaction set?
>>>
>>> Skip
>>
>>

Scott Gray

Re: captureBillingAccountPayments

Lol ok sorry, I've never actually worked on the billing account stuff
so I have no idea whats currently in place. Nice work whoever did it
:-)

Scott

On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:

> Hi Scott,
>
> Scott Gray wrote:
> > Hi Jacopo
> >
> > Our customers generally make payments for a specific invoice or group
> > of invoices so this wouldn't work for us. In our current system (non
> > web UI) we log a payment and then use a screen with a list of open
> > invoices to allocate the payment with the payment balance reducing as
> > each invoice is selected.
> >
>
> I think that you have perfectly described what is currently implemented
> in OFbiz :-)
> Maybe I'm not been very clear on this: I was not suggesting to modify
> the existing payment/payment application screens; instead I was
> suggesting to add a new option, for billing accounts, to apply billing
> account payments to billing account invoices by date; of course you can
> continue, also in the billing account, to apply payments to specific
> invoices.
>
> Cheers,
>
> Jacopo
>
>
> > Regards
> > Scott
> >
> > On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> >> skip@theDevers wrote:
> >>> Jacopo
> >>>
> >>> As the man with the plan,
> >> uhm... me? :-)
> >>
> >>> I wanted to throw this new plan past you. I have
> >>> dug pretty deeply into the existing payment/billing account stuff and it
> >>> all seems a bit arcane to me and mostly because it looks like payments are
> >>> meant to be made from the company to a vendor and from a customer to the
> >>> company, all with the same screens.
> >>>
> >>> I want to create a really easy to use AR payment system. The user enters a
> >>> payment and can then either apply the payment to individual invoices (and a
> >>> store credit if too much is received) or he can apply it to the billing
> >>> account, in which case we automatically apply it to the oldest invoices
> >>> first and then to a credit if too much is received.
> >>>
> >> I'd suggest the following subtasks:
> >>
> >> a) implement a new service to automatically apply the payments
> >> associated to a billing account to the older open invoices associated to
> >> the same account; the new service will have one mandatory parameter
> >> "billingAccountId" (and maybe one optional parameter "paymentId") and it
> >> will:
> >> - select the open invoices associated to the billing account and sort
> >> them by date (older first)
> >> - iterate on the list and for each of them call the service
> >> capturePaymentsByInvoice passing in the invoice id and billingAccountId
> >> (this is the service that is invoked when you click on the "capture"
> >> link near the invoice in the billingaccoun-invoices screen)
> >>
> >> b) the new service can be invoked by a new link ("apply payments to
> >> invoices") at the top of the billing account->invoices screen or (maybe
> >> in your custom application) triggered every time you associate a payment
> >> to a billing account.
> >>
> >> This should cover your requirements but it is also generic enough to be
> >> a good fit for OFBiz.
> >>
> >> What do you think?
> >>
> >> Jacopo
> >>
> >>> Is this too simplistic for some reason I am missing? Do others have AR
> >>> needs outside this that would justify a more complicated transaction set?
> >>>
> >>> Skip
> >>
> >>
>
>
>

Jacques Le Roux

Re: captureBillingAccountPayments

Administrator

In reply to this post by Jacopo Cappellato

Hi Skip, Jacopo, Scott,

IMHO this kind of threads should better be in dev ML

Thanks

Jacques

PS : thanks Jacopo for the fix on ShippingEvents.java

De : "Jacopo Cappellato" <[hidden email]>

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Jacopo Cappellato

Like I said, the man with the plan

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Monday, October 29, 2007 12:15 AM
To: [hidden email]
Subject: Re: captureBillingAccountPayments

skip@theDevers wrote:
> Jacopo
>
> As the man with the plan,

uhm... me? :-)

> I wanted to throw this new plan past you. I have
> dug pretty deeply into the existing payment/billing account stuff and it
> all seems a bit arcane to me and mostly because it looks like payments are
> meant to be made from the company to a vendor and from a customer to the
> company, all with the same screens.
>
> I want to create a really easy to use AR payment system. The user enters
a
> payment and can then either apply the payment to individual invoices (and
a
> store credit if too much is received) or he can apply it to the billing
> account, in which case we automatically apply it to the oldest invoices
> first and then to a credit if too much is received.
>

I'd suggest the following subtasks:

a) implement a new service to automatically apply the payments
associated to a billing account to the older open invoices associated to
the same account; the new service will have one mandatory parameter
"billingAccountId" (and maybe one optional parameter "paymentId") and it
will:
- select the open invoices associated to the billing account and sort
them by date (older first)
- iterate on the list and for each of them call the service
capturePaymentsByInvoice passing in the invoice id and billingAccountId
(this is the service that is invoked when you click on the "capture"
link near the invoice in the billingaccoun-invoices screen)

b) the new service can be invoked by a new link ("apply payments to
invoices") at the top of the billing account->invoices screen or (maybe
in your custom application) triggered every time you associate a payment
to a billing account.

This should cover your requirements but it is also generic enough to be
a good fit for OFBiz.

What do you think?

Jacopo

> Is this too simplistic for some reason I am missing? Do others have AR
> needs outside this that would justify a more complicated transaction set?
>
> Skip

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Scott Gray

Scott

I need the same services as you. This is for the case where the customer
pays without specifying any invoices. If invoices are specified, you apply
the payment to individual invoices the way you do now.

Your existing non-web based screen will not change (unless you want it to).
There will just be another service to call to apply the payment as if you
had selected the invoices beginning with the oldest first.

Also, what do you do now if the customer overpays?

Skip

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: Monday, October 29, 2007 12:23 AM
To: [hidden email]
Subject: Re: captureBillingAccountPayments

Hi Jacopo

Our customers generally make payments for a specific invoice or group
of invoices so this wouldn't work for us. In our current system (non
web UI) we log a payment and then use a screen with a list of open
invoices to allocate the payment with the payment balance reducing as
each invoice is selected.

Regards
Scott

On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> skip@theDevers wrote:
> > Jacopo
> >
> > As the man with the plan,
>
> uhm... me? :-)
>
> > I wanted to throw this new plan past you. I have
> > dug pretty deeply into the existing payment/billing account stuff and
it
> > all seems a bit arcane to me and mostly because it looks like payments
are
> > meant to be made from the company to a vendor and from a customer to the
> > company, all with the same screens.
> >
> > I want to create a really easy to use AR payment system. The user
enters a
> > payment and can then either apply the payment to individual invoices
(and a

> > store credit if too much is received) or he can apply it to the billing
> > account, in which case we automatically apply it to the oldest invoices
> > first and then to a credit if too much is received.
> >
>
> I'd suggest the following subtasks:
>
> a) implement a new service to automatically apply the payments
> associated to a billing account to the older open invoices associated to
> the same account; the new service will have one mandatory parameter
> "billingAccountId" (and maybe one optional parameter "paymentId") and it
> will:
> - select the open invoices associated to the billing account and sort
> them by date (older first)
> - iterate on the list and for each of them call the service
> capturePaymentsByInvoice passing in the invoice id and billingAccountId
> (this is the service that is invoked when you click on the "capture"
> link near the invoice in the billingaccoun-invoices screen)
>
> b) the new service can be invoked by a new link ("apply payments to
> invoices") at the top of the billing account->invoices screen or (maybe
> in your custom application) triggered every time you associate a payment
> to a billing account.
>
> This should cover your requirements but it is also generic enough to be
> a good fit for OFBiz.
>
> What do you think?
>
> Jacopo
>
> > Is this too simplistic for some reason I am missing? Do others have AR
> > needs outside this that would justify a more complicated transaction

set?
> >
> > Skip
>
>
>

SkipDever

Reading html template files question

In reply to this post by Jacopo Cappellato

I am writing a service to email billing account statements. I want to read
a template and generate an email from it. This is in the context of a
scheduled service. I have to believe there is already code doing something
similiar (sending mass emails generated from a template).

Can someone point me to some sample code?

Skip

Scott Gray

Re: captureBillingAccountPayments

In reply to this post by SkipDever

Sorry I should have mentioned that it's a non-OFBiz system.

Regards
Scott

On 30/10/2007, skip@theDevers <[hidden email]> wrote:

> Scott
>
> I need the same services as you. This is for the case where the customer
> pays without specifying any invoices. If invoices are specified, you apply
> the payment to individual invoices the way you do now.
>
> Your existing non-web based screen will not change (unless you want it to).
> There will just be another service to call to apply the payment as if you
> had selected the invoices beginning with the oldest first.
>
> Also, what do you do now if the customer overpays?
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Monday, October 29, 2007 12:23 AM
> To: [hidden email]
> Subject: Re: captureBillingAccountPayments
>
>
> Hi Jacopo
>
> Our customers generally make payments for a specific invoice or group
> of invoices so this wouldn't work for us. In our current system (non
> web UI) we log a payment and then use a screen with a list of open
> invoices to allocate the payment with the payment balance reducing as
> each invoice is selected.
>
> Regards
> Scott
>
> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> > skip@theDevers wrote:
> > > Jacopo
> > >
> > > As the man with the plan,
> >
> > uhm... me? :-)
> >
> > > I wanted to throw this new plan past you. I have
> > > dug pretty deeply into the existing payment/billing account stuff and
> it
> > > all seems a bit arcane to me and mostly because it looks like payments
> are
> > > meant to be made from the company to a vendor and from a customer to the
> > > company, all with the same screens.
> > >
> > > I want to create a really easy to use AR payment system. The user
> enters a
> > > payment and can then either apply the payment to individual invoices
> (and a
> > > store credit if too much is received) or he can apply it to the billing
> > > account, in which case we automatically apply it to the oldest invoices
> > > first and then to a credit if too much is received.
> > >
> >
> > I'd suggest the following subtasks:
> >
> > a) implement a new service to automatically apply the payments
> > associated to a billing account to the older open invoices associated to
> > the same account; the new service will have one mandatory parameter
> > "billingAccountId" (and maybe one optional parameter "paymentId") and it
> > will:
> > - select the open invoices associated to the billing account and sort
> > them by date (older first)
> > - iterate on the list and for each of them call the service
> > capturePaymentsByInvoice passing in the invoice id and billingAccountId
> > (this is the service that is invoked when you click on the "capture"
> > link near the invoice in the billingaccoun-invoices screen)
> >
> > b) the new service can be invoked by a new link ("apply payments to
> > invoices") at the top of the billing account->invoices screen or (maybe
> > in your custom application) triggered every time you associate a payment
> > to a billing account.
> >
> > This should cover your requirements but it is also generic enough to be
> > a good fit for OFBiz.
> >
> > What do you think?
> >
> > Jacopo
> >
> > > Is this too simplistic for some reason I am missing? Do others have AR
> > > needs outside this that would justify a more complicated transaction
> set?
> > >
> > > Skip
> >
> >
> >
>
>

SkipDever

Billing Accounts

In reply to this post by Scott Gray

Hi Jacopo

I have two questions concerning billing accounts. Account balances are
computed in BillingAccountWorker.getBillingAccountBalance(). This routine
uses an algorithm that subtracts the sum of OrderPaymentPreference.maxAmount
where the statusId is "PAYMENT_NOT_RECEIVED" (and a few others).

What I am wondering is why this entity was chosen over the sum of Invoices
outstanding which to me makes more sense. Maybe this way is faster?

Second, in the same file is getBillingAccountNetBalance() which returns the
sum of PaymentApplication. The comment sez this "Calculates the net balance
of a billing account, which is sum of all amounts applied to invoices minus
sum of all amounts applied from payments". If you write an order against a
BillingAccount, PaymentApplication is empty after an invoice is created, so
I don't see the value of this function. Maybe I am misinterpreting the name
"getBillingAccountNetBalance". However, getBillingAccountAvailableBalance
returns the billing account limit - getBillingAccountNetBalance, so I would
have thought that getBillingAccountBalance() would =
getBillingAccountAvailableBalance if there are no uninvoiced Orders.

Note that I see that getBillingAccountAvailableBalance is commented out in
the one place it is used in favor of getBillingAccountBalance().

I am thinking of re-writing the getBillingAccountNetBalance() to use
Invoice because that, along with Payment is the basis for statements sent to
customers and it makes sense to me from a data consistancy standpoint.

Am I barking up the wrong tree?

Skip

Jacopo Cappellato

Re: Billing Accounts

Hi Skip,

skip@theDevers wrote:

> Hi Jacopo
>
> I have two questions concerning billing accounts. Account balances are
> computed in BillingAccountWorker.getBillingAccountBalance(). This routine
> uses an algorithm that subtracts the sum of OrderPaymentPreference.maxAmount
> where the statusId is "PAYMENT_NOT_RECEIVED" (and a few others).
>
> What I am wondering is why this entity was chosen over the sum of Invoices
> outstanding which to me makes more sense. Maybe this way is faster?
>

Actually, that was the initial plan. Unfortunately, when you create an
order, and the customer asks to 'pay' it with a billing account we have
to consider this and adjust the billing account balance immediately (if
not, the customer could enter a lot of orders exceeding the billing
account credit/limit) ... but there is still no invoice for the order
(that is created when the order is shipped).

>
> Second, in the same file is getBillingAccountNetBalance() which returns the
> sum of PaymentApplication. The comment sez this "Calculates the net balance
> of a billing account, which is sum of all amounts applied to invoices minus
> sum of all amounts applied from payments". If you write an order against a
> BillingAccount, PaymentApplication is empty after an invoice is created, so
> I don't see the value of this function. Maybe I am misinterpreting the name
> "getBillingAccountNetBalance". However, getBillingAccountAvailableBalance
> returns the billing account limit - getBillingAccountNetBalance, so I would
> have thought that getBillingAccountBalance() would =
> getBillingAccountAvailableBalance if there are no uninvoiced Orders.

Many of the methods in that class were created before the last
refactoring of the billing accounts and they will be removed soon: sorry
for the confusion. If I well remember there is only one balance method
that is still valid, all the other ones are deprecated.

Jacopo

>
> Note that I see that getBillingAccountAvailableBalance is commented out in
> the one place it is used in favor of getBillingAccountBalance().
>
> I am thinking of re-writing the getBillingAccountNetBalance() to use
> Invoice because that, along with Payment is the basis for statements sent to
> customers and it makes sense to me from a data consistancy standpoint.
>
> Am I barking up the wrong tree?
>
> Skip
>

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Scott Gray

BTW Scott, I am about a month away from writing a "Collections Agent" for
use by AR people for collecting past due invoices and making notes about
contacts and the like. Because of the complexity of this application, I'll
likely be doing it as a java application.

If you want to collaborate by giving me your AR app as a base, I'll roll
them together and give you back a single AR app that does both functions. I
would particularly like this if you have the freedom to contribute your work
to Jira, not that I would expect the Ofbiz management to take java apps, but
then again, maybe other would like it.

Skip

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: Monday, October 29, 2007 9:47 PM
To: [hidden email]
Subject: Re: captureBillingAccountPayments

Sorry I should have mentioned that it's a non-OFBiz system.

Regards
Scott

On 30/10/2007, skip@theDevers <[hidden email]> wrote:
> Scott
>
> I need the same services as you. This is for the case where the customer
> pays without specifying any invoices. If invoices are specified, you
apply
> the payment to individual invoices the way you do now.
>
> Your existing non-web based screen will not change (unless you want it
to).

> There will just be another service to call to apply the payment as if you
> had selected the invoices beginning with the oldest first.
>
> Also, what do you do now if the customer overpays?
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Monday, October 29, 2007 12:23 AM
> To: [hidden email]
> Subject: Re: captureBillingAccountPayments
>
>
> Hi Jacopo
>
> Our customers generally make payments for a specific invoice or group
> of invoices so this wouldn't work for us. In our current system (non
> web UI) we log a payment and then use a screen with a list of open
> invoices to allocate the payment with the payment balance reducing as
> each invoice is selected.
>
> Regards
> Scott
>
> On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> > skip@theDevers wrote:
> > > Jacopo
> > >
> > > As the man with the plan,
> >
> > uhm... me? :-)
> >
> > > I wanted to throw this new plan past you. I have
> > > dug pretty deeply into the existing payment/billing account stuff and
> it
> > > all seems a bit arcane to me and mostly because it looks like payments
> are
> > > meant to be made from the company to a vendor and from a customer to

the
> > > company, all with the same screens.
> > >
> > > I want to create a really easy to use AR payment system. The user
> enters a
> > > payment and can then either apply the payment to individual invoices
> (and a
> > > store credit if too much is received) or he can apply it to the
billing
> > > account, in which case we automatically apply it to the oldest
invoices

> > > first and then to a credit if too much is received.
> > >
> >
> > I'd suggest the following subtasks:
> >
> > a) implement a new service to automatically apply the payments
> > associated to a billing account to the older open invoices associated to
> > the same account; the new service will have one mandatory parameter
> > "billingAccountId" (and maybe one optional parameter "paymentId") and it
> > will:
> > - select the open invoices associated to the billing account and sort
> > them by date (older first)
> > - iterate on the list and for each of them call the service
> > capturePaymentsByInvoice passing in the invoice id and billingAccountId
> > (this is the service that is invoked when you click on the "capture"
> > link near the invoice in the billingaccoun-invoices screen)
> >
> > b) the new service can be invoked by a new link ("apply payments to
> > invoices") at the top of the billing account->invoices screen or (maybe
> > in your custom application) triggered every time you associate a payment
> > to a billing account.
> >
> > This should cover your requirements but it is also generic enough to be
> > a good fit for OFBiz.
> >
> > What do you think?
> >
> > Jacopo
> >
> > > Is this too simplistic for some reason I am missing? Do others have

AR
> > > needs outside this that would justify a more complicated transaction
> set?
> > >
> > > Skip
> >
> >
> >
>
>

Jacopo Cappellato

Re: Billing Accounts

In reply to this post by SkipDever

Sorry,

I've missed the following statement:

skip@theDevers wrote:
>
> I am thinking of re-writing the getBillingAccountNetBalance() to use
> Invoice because that, along with Payment is the basis for statements sent to
> customers and it makes sense to me from a data consistancy standpoint.
>

Wouldn't be better to provide a report to the customer about the balance
of a billing account with the following information:

==== billing account id (and other info) ====
account limit

* list of open invoices associated to the account with outstanding amount

* total outstanding amount

* difference between account limit and total outstanding amount

(optionally you could also include the list of unapplied payments, if any).

Of course you can create a new helper method in the BillingAccountWorker
class to help you to run the total, but it is important to use this only
for reporting purposes (and maybe it is easier to run the total directly
in your report); the reasons are in my last email.

Jacopo

Scott Gray

Re: captureBillingAccountPayments

In reply to this post by SkipDever

Ok sorry I'll clarify further it's legacy and I have no access to the
code, I'm no more than a user unfortunately.

Regards
Scott

On 30/10/2007, skip@theDevers <[hidden email]> wrote:

> BTW Scott, I am about a month away from writing a "Collections Agent" for
> use by AR people for collecting past due invoices and making notes about
> contacts and the like. Because of the complexity of this application, I'll
> likely be doing it as a java application.
>
> If you want to collaborate by giving me your AR app as a base, I'll roll
> them together and give you back a single AR app that does both functions. I
> would particularly like this if you have the freedom to contribute your work
> to Jira, not that I would expect the Ofbiz management to take java apps, but
> then again, maybe other would like it.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Monday, October 29, 2007 9:47 PM
> To: [hidden email]
> Subject: Re: captureBillingAccountPayments
>
>
> Sorry I should have mentioned that it's a non-OFBiz system.
>
> Regards
> Scott
>
> On 30/10/2007, skip@theDevers <[hidden email]> wrote:
> > Scott
> >
> > I need the same services as you. This is for the case where the customer
> > pays without specifying any invoices. If invoices are specified, you
> apply
> > the payment to individual invoices the way you do now.
> >
> > Your existing non-web based screen will not change (unless you want it
> to).
> > There will just be another service to call to apply the payment as if you
> > had selected the invoices beginning with the oldest first.
> >
> > Also, what do you do now if the customer overpays?
> >
> > Skip
> >
> > -----Original Message-----
> > From: Scott Gray [mailto:[hidden email]]
> > Sent: Monday, October 29, 2007 12:23 AM
> > To: [hidden email]
> > Subject: Re: captureBillingAccountPayments
> >
> >
> > Hi Jacopo
> >
> > Our customers generally make payments for a specific invoice or group
> > of invoices so this wouldn't work for us. In our current system (non
> > web UI) we log a payment and then use a screen with a list of open
> > invoices to allocate the payment with the payment balance reducing as
> > each invoice is selected.
> >
> > Regards
> > Scott
> >
> > On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> > > skip@theDevers wrote:
> > > > Jacopo
> > > >
> > > > As the man with the plan,
> > >
> > > uhm... me? :-)
> > >
> > > > I wanted to throw this new plan past you. I have
> > > > dug pretty deeply into the existing payment/billing account stuff and
> > it
> > > > all seems a bit arcane to me and mostly because it looks like payments
> > are
> > > > meant to be made from the company to a vendor and from a customer to
> the
> > > > company, all with the same screens.
> > > >
> > > > I want to create a really easy to use AR payment system. The user
> > enters a
> > > > payment and can then either apply the payment to individual invoices
> > (and a
> > > > store credit if too much is received) or he can apply it to the
> billing
> > > > account, in which case we automatically apply it to the oldest
> invoices
> > > > first and then to a credit if too much is received.
> > > >
> > >
> > > I'd suggest the following subtasks:
> > >
> > > a) implement a new service to automatically apply the payments
> > > associated to a billing account to the older open invoices associated to
> > > the same account; the new service will have one mandatory parameter
> > > "billingAccountId" (and maybe one optional parameter "paymentId") and it
> > > will:
> > > - select the open invoices associated to the billing account and sort
> > > them by date (older first)
> > > - iterate on the list and for each of them call the service
> > > capturePaymentsByInvoice passing in the invoice id and billingAccountId
> > > (this is the service that is invoked when you click on the "capture"
> > > link near the invoice in the billingaccoun-invoices screen)
> > >
> > > b) the new service can be invoked by a new link ("apply payments to
> > > invoices") at the top of the billing account->invoices screen or (maybe
> > > in your custom application) triggered every time you associate a payment
> > > to a billing account.
> > >
> > > This should cover your requirements but it is also generic enough to be
> > > a good fit for OFBiz.
> > >
> > > What do you think?
> > >
> > > Jacopo
> > >
> > > > Is this too simplistic for some reason I am missing? Do others have
> AR
> > > > needs outside this that would justify a more complicated transaction
> > set?
> > > >
> > > > Skip
> > >
> > >
> > >
> >
> >
>
>

SkipDever

RE: Billing Accounts

In reply to this post by Jacopo Cappellato

Hmmm, now I am beginning to understand why Si wants to make a
PaymentApplication when an invoice is created. Both are "messy", but I
guess I like your way better.

I was just thinking of using the delta of OrderItem and OrderItemBilling,
but, because this value is only used in an advisory capacity, maybe getting
too clever isn't justified. But I am gonna think on it some more.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Monday, October 29, 2007 10:17 PM
To: [hidden email]
Subject: Re: Billing Accounts

Hi Skip,

skip@theDevers wrote:
> Hi Jacopo
>
> I have two questions concerning billing accounts. Account balances are
> computed in BillingAccountWorker.getBillingAccountBalance(). This routine
> uses an algorithm that subtracts the sum of
OrderPaymentPreference.maxAmount
> where the statusId is "PAYMENT_NOT_RECEIVED" (and a few others).
>
> What I am wondering is why this entity was chosen over the sum of Invoices
> outstanding which to me makes more sense. Maybe this way is faster?
>

Actually, that was the initial plan. Unfortunately, when you create an
order, and the customer asks to 'pay' it with a billing account we have
to consider this and adjust the billing account balance immediately (if
not, the customer could enter a lot of orders exceeding the billing
account credit/limit) ... but there is still no invoice for the order
(that is created when the order is shipped).

>
> Second, in the same file is getBillingAccountNetBalance() which returns
the
> sum of PaymentApplication. The comment sez this "Calculates the net
balance
> of a billing account, which is sum of all amounts applied to invoices
minus
> sum of all amounts applied from payments". If you write an order against
a
> BillingAccount, PaymentApplication is empty after an invoice is created,
so
> I don't see the value of this function. Maybe I am misinterpreting the
name
> "getBillingAccountNetBalance". However, getBillingAccountAvailableBalance
> returns the billing account limit - getBillingAccountNetBalance, so I
would
> have thought that getBillingAccountBalance() would =
> getBillingAccountAvailableBalance if there are no uninvoiced Orders.

Many of the methods in that class were created before the last
refactoring of the billing accounts and they will be removed soon: sorry
for the confusion. If I well remember there is only one balance method
that is still valid, all the other ones are deprecated.

Jacopo

>
> Note that I see that getBillingAccountAvailableBalance is commented out
in
> the one place it is used in favor of getBillingAccountBalance().
>
> I am thinking of re-writing the getBillingAccountNetBalance() to use
> Invoice because that, along with Payment is the basis for statements sent
to
> customers and it makes sense to me from a data consistancy standpoint.
>
> Am I barking up the wrong tree?
>
> Skip
>

SkipDever

RE: Billing Accounts

In reply to this post by Jacopo Cappellato

Yep, already got this done, except that it also provides a list of payments
in the statement period. Just gotta check this all out with a few returns
and stuff to make sure it all works.

Thanks for all your help BTW in case I forgot to say it before.

Skip

-----Original Message-----
From: Jacopo Cappellato [mailto:[hidden email]]
Sent: Monday, October 29, 2007 10:26 PM
To: [hidden email]
Subject: Re: Billing Accounts

Sorry,

I've missed the following statement:

skip@theDevers wrote:
>
> I am thinking of re-writing the getBillingAccountNetBalance() to use
> Invoice because that, along with Payment is the basis for statements sent
to
> customers and it makes sense to me from a data consistancy standpoint.
>

Wouldn't be better to provide a report to the customer about the balance
of a billing account with the following information:

==== billing account id (and other info) ====
account limit

* list of open invoices associated to the account with outstanding amount

* total outstanding amount

* difference between account limit and total outstanding amount

(optionally you could also include the list of unapplied payments, if any).

Of course you can create a new helper method in the BillingAccountWorker
class to help you to run the total, but it is important to use this only
for reporting purposes (and maybe it is easier to run the total directly
in your report); the reasons are in my last email.

Jacopo

SkipDever

RE: captureBillingAccountPayments

In reply to this post by Scott Gray

No worries dude, you can still have it when I put it in Jira.

Skip

-----Original Message-----
From: Scott Gray [mailto:[hidden email]]
Sent: Monday, October 29, 2007 10:31 PM
To: [hidden email]
Subject: Re: captureBillingAccountPayments

Ok sorry I'll clarify further it's legacy and I have no access to the
code, I'm no more than a user unfortunately.

Regards
Scott

On 30/10/2007, skip@theDevers <[hidden email]> wrote:
> BTW Scott, I am about a month away from writing a "Collections Agent" for
> use by AR people for collecting past due invoices and making notes about
> contacts and the like. Because of the complexity of this application,
I'll
> likely be doing it as a java application.
>
> If you want to collaborate by giving me your AR app as a base, I'll roll
> them together and give you back a single AR app that does both functions.
I
> would particularly like this if you have the freedom to contribute your
work
> to Jira, not that I would expect the Ofbiz management to take java apps,
but

> then again, maybe other would like it.
>
> Skip
>
> -----Original Message-----
> From: Scott Gray [mailto:[hidden email]]
> Sent: Monday, October 29, 2007 9:47 PM
> To: [hidden email]
> Subject: Re: captureBillingAccountPayments
>
>
> Sorry I should have mentioned that it's a non-OFBiz system.
>
> Regards
> Scott
>
> On 30/10/2007, skip@theDevers <[hidden email]> wrote:
> > Scott
> >
> > I need the same services as you. This is for the case where the

customer
> > pays without specifying any invoices. If invoices are specified, you
> apply
> > the payment to individual invoices the way you do now.
> >
> > Your existing non-web based screen will not change (unless you want it
> to).
> > There will just be another service to call to apply the payment as if
you

> > had selected the invoices beginning with the oldest first.
> >
> > Also, what do you do now if the customer overpays?
> >
> > Skip
> >
> > -----Original Message-----
> > From: Scott Gray [mailto:[hidden email]]
> > Sent: Monday, October 29, 2007 12:23 AM
> > To: [hidden email]
> > Subject: Re: captureBillingAccountPayments
> >
> >
> > Hi Jacopo
> >
> > Our customers generally make payments for a specific invoice or group
> > of invoices so this wouldn't work for us. In our current system (non
> > web UI) we log a payment and then use a screen with a list of open
> > invoices to allocate the payment with the payment balance reducing as
> > each invoice is selected.
> >
> > Regards
> > Scott
> >
> > On 29/10/2007, Jacopo Cappellato <[hidden email]> wrote:
> > > skip@theDevers wrote:
> > > > Jacopo
> > > >
> > > > As the man with the plan,
> > >
> > > uhm... me? :-)
> > >
> > > > I wanted to throw this new plan past you. I have
> > > > dug pretty deeply into the existing payment/billing account stuff

and
> > it
> > > > all seems a bit arcane to me and mostly because it looks like
payments

> > are
> > > > meant to be made from the company to a vendor and from a customer to
> the
> > > > company, all with the same screens.
> > > >
> > > > I want to create a really easy to use AR payment system. The user
> > enters a
> > > > payment and can then either apply the payment to individual invoices
> > (and a
> > > > store credit if too much is received) or he can apply it to the
> billing
> > > > account, in which case we automatically apply it to the oldest
> invoices
> > > > first and then to a credit if too much is received.
> > > >
> > >
> > > I'd suggest the following subtasks:
> > >
> > > a) implement a new service to automatically apply the payments
> > > associated to a billing account to the older open invoices associated

to
> > > the same account; the new service will have one mandatory parameter
> > > "billingAccountId" (and maybe one optional parameter "paymentId") and
it
> > > will:
> > > - select the open invoices associated to the billing account and sort
> > > them by date (older first)
> > > - iterate on the list and for each of them call the service
> > > capturePaymentsByInvoice passing in the invoice id and
billingAccountId
> > > (this is the service that is invoked when you click on the "capture"
> > > link near the invoice in the billingaccoun-invoices screen)
> > >
> > > b) the new service can be invoked by a new link ("apply payments to
> > > invoices") at the top of the billing account->invoices screen or
(maybe
> > > in your custom application) triggered every time you associate a
payment
> > > to a billing account.
> > >
> > > This should cover your requirements but it is also generic enough to
be

> > > a good fit for OFBiz.
> > >
> > > What do you think?
> > >
> > > Jacopo
> > >
> > > > Is this too simplistic for some reason I am missing? Do others have
> AR
> > > > needs outside this that would justify a more complicated transaction
> > set?
> > > >
> > > > Skip
> > >
> > >
> > >
> >
> >
>
>

123456