Use Case and review or Order Entities

[cjhowe]

We have a use case that has forced us to review the order entities.  As
it will take a fairly large rewrite to support our use case, we went
ahead and reviewed all of the order entities to see if it would be
advantages for a more thorough rewrite.  The summary can be found in my
docs.ofbiz.org space at http://docs.ofbiz.org/x/GQk

Use Case:
We rent equipment that is paid for by multiple third party payers
(insurance companies).  A couple things conflict with the current data
model.

1.  Multiple payers - For a single billing cycle, there can be as many
as four payers that need to receive invoices.  An invoice needs to be
generate for each one. (one insurance company pays 60%, another 20%
another ins. company 15% and finally the end user 5%)

2.  Recurring invoicing. - There is a single order and every 30 days a
new invoice needs to be recorded and sent out (because of #1, 4
invoices need to be sent out)

3.  Price changes - Over the course of the recurring invoices, the
price for the rental may change as well as adjusments may change.

I believe the review in the docs.ofbiz.org page would allow for this
use case as well as all that are currently handled to be addressed in
the more generic model. Again, there are several non related issues
pointed out as well that anticipate use cases to the various hooks.  I
would appreciate any feedback that the community can offer before I
dive into this.  Thanks

-Chris

[Jacopo Cappellato]

Hi Chris,

wow, it seems you did a lot of work.
Just out of curiosity: instead of following the approach of
reviewing/refactoring the whole order data model, did you try the
opposite approach? I mean, to try to minimize the changes and add
support for what you need, in a flexible way. It would be interesting to
compare the effort needed by the two approaches.

I'm asking you this because I've often had to find a solution for
special use cases in the past, and I've always managed them with minimal
(or no) changes to the existing structures.

My main concern is that you have focused your attention (at least in the
document) only in the review of the data model and not in the existing
processes and user interface; are you planning to do this as a second phase?

Jacopo

Chris Howe wrote:

> We have a use case that has forced us to review the order entities.  As
> it will take a fairly large rewrite to support our use case, we went
> ahead and reviewed all of the order entities to see if it would be
> advantages for a more thorough rewrite.  The summary can be found in my
> docs.ofbiz.org space at http://docs.ofbiz.org/x/GQk
>
> Use Case:
> We rent equipment that is paid for by multiple third party payers
> (insurance companies).  A couple things conflict with the current data
> model.
>
> 1.  Multiple payers - For a single billing cycle, there can be as many
> as four payers that need to receive invoices.  An invoice needs to be
> generate for each one. (one insurance company pays 60%, another 20%
> another ins. company 15% and finally the end user 5%)
>
> 2.  Recurring invoicing. - There is a single order and every 30 days a
> new invoice needs to be recorded and sent out (because of #1, 4
> invoices need to be sent out)
>
> 3.  Price changes - Over the course of the recurring invoices, the
> price for the rental may change as well as adjusments may change.
>
> I believe the review in the docs.ofbiz.org page would allow for this
> use case as well as all that are currently handled to be addressed in
> the more generic model. Again, there are several non related issues
> pointed out as well that anticipate use cases to the various hooks.  I
> would appreciate any feedback that the community can offer before I
> dive into this.  Thanks
>
> -Chris

[cjhowe]

I've been adding incrementally, as you suggested, over the last two and
a half years as new use cases have popped their head.  With each
increment we've gotten farther and farther away from the community code
and farther and farther away from a generic approach.  As this happens,
we become isolated from the community.  Our improvements are
meaningless to the community and the community's improvements become
meaningless to us.  We end up being a software company, and that is not
where we want to be.

I certainly understand that the process would require quite a bit of
work as well.  There just isn't really a way around it though.  Many of
the points in the document look at where OFBiz is to handle the use
case of one, where we're needing a use case of many (prices to order
item and invoices to order items. I tried to untangle the shopping cart
to order services and just drove myself crazy.  A rewrite almost from
scratch with modularity the focus looks like a shorter path. After
that, a review to ensure functionality isn't lost seems appropriate.

With being post 4.0 branch, it seems like as good a time as any to put
out some blue prints and get as much guidance, feedback and suggestions
as possible. Since most of the document is referring to going from a
one use case to many, an upgrade path should be pretty straight
forward.

As far as the UI, there shouldn't be much to worry about there.  Both
the order and ecommerce webapp populate the shoppingCart and not the
order database until the final step (I don't know about POS).  There
may be some light changes and a couple additions for some of the order
processing pages.

If you can think of some potential potholes I need to be on the look
out for, I would be very grateful.
Thanks!



--- Jacopo Cappellato <[hidden email]> wrote:

> Hi Chris,
>
> wow, it seems you did a lot of work.
> Just out of curiosity: instead of following the approach of
> reviewing/refactoring the whole order data model, did you try the
> opposite approach? I mean, to try to minimize the changes and add
> support for what you need, in a flexible way. It would be interesting
> to
> compare the effort needed by the two approaches.
>
> I'm asking you this because I've often had to find a solution for
> special use cases in the past, and I've always managed them with
> minimal
> (or no) changes to the existing structures.
>
> My main concern is that you have focused your attention (at least in
> the
> document) only in the review of the data model and not in the
> existing
> processes and user interface; are you planning to do this as a second
> phase?
>
> Jacopo
>
> Chris Howe wrote:
> > We have a use case that has forced us to review the order entities.
>  As
> > it will take a fairly large rewrite to support our use case, we
> went
> > ahead and reviewed all of the order entities to see if it would be
> > advantages for a more thorough rewrite.  The summary can be found
> in my
> > docs.ofbiz.org space at http://docs.ofbiz.org/x/GQk
> >
> > Use Case:
> > We rent equipment that is paid for by multiple third party payers
> > (insurance companies).  A couple things conflict with the current
> data
> > model.
> >
> > 1.  Multiple payers - For a single billing cycle, there can be as
> many
> > as four payers that need to receive invoices.  An invoice needs to
> be
> > generate for each one. (one insurance company pays 60%, another 20%
> > another ins. company 15% and finally the end user 5%)
> >
> > 2.  Recurring invoicing. - There is a single order and every 30
> days a
> > new invoice needs to be recorded and sent out (because of #1, 4
> > invoices need to be sent out)
> >
> > 3.  Price changes - Over the course of the recurring invoices, the
> > price for the rental may change as well as adjusments may change.
> >
> > I believe the review in the docs.ofbiz.org page would allow for
> this
> > use case as well as all that are currently handled to be addressed
> in
> > the more generic model. Again, there are several non related issues
> > pointed out as well that anticipate use cases to the various hooks.
>  I
> > would appreciate any feedback that the community can offer before I
> > dive into this.  Thanks
> >
> > -Chris
>
>
>

[Pankaj Lall]

Hi

When ever I'm typing http://localhost:8080/ecommerce/control/main I'm
getting this error "

(Sourced file:
component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
: Method Invocation ProductPromoWorker.getStoreProductPromos)))) (Error
rendering screen [component://ecommerce/widget/CommonScreens.xml#rightbar]:
*org.ofbiz.base.util.GeneralException*: Error rendering screen
[component://ecommerce/widget/CartScreens.xml#minipromotext]: *
org.ofbiz.base.util.GeneralException*: Error running BSH script at location
[component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh]:
*org.ofbiz.base.util.GeneralException*: Error running BSH script at
[component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh],
line [30]: Sourced file:
component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
: Method Invocation ProductPromoWorker.getStoreProductPromos : at Line: 30 :
in file:
component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
: ProductPromoWorker .getStoreProductPromos ( delegator , dispatcher ,
request )
"
What should I do to get rid of this error message.

With Regards
Pankaj Lall

On 6/1/07, Jacopo Cappellato <[hidden email]> wrote:

>
> Hi Chris,
>
> wow, it seems you did a lot of work.
> Just out of curiosity: instead of following the approach of
> reviewing/refactoring the whole order data model, did you try the
> opposite approach? I mean, to try to minimize the changes and add
> support for what you need, in a flexible way. It would be interesting to
> compare the effort needed by the two approaches.
>
> I'm asking you this because I've often had to find a solution for
> special use cases in the past, and I've always managed them with minimal
> (or no) changes to the existing structures.
>
> My main concern is that you have focused your attention (at least in the
> document) only in the review of the data model and not in the existing
> processes and user interface; are you planning to do this as a second
> phase?
>
> Jacopo
>
> Chris Howe wrote:
> > We have a use case that has forced us to review the order entities.  As
> > it will take a fairly large rewrite to support our use case, we went
> > ahead and reviewed all of the order entities to see if it would be
> > advantages for a more thorough rewrite.  The summary can be found in my
> > docs.ofbiz.org space at http://docs.ofbiz.org/x/GQk
> >
> > Use Case:
> > We rent equipment that is paid for by multiple third party payers
> > (insurance companies).  A couple things conflict with the current data
> > model.
> >
> > 1.  Multiple payers - For a single billing cycle, there can be as many
> > as four payers that need to receive invoices.  An invoice needs to be
> > generate for each one. (one insurance company pays 60%, another 20%
> > another ins. company 15% and finally the end user 5%)
> >
> > 2.  Recurring invoicing. - There is a single order and every 30 days a
> > new invoice needs to be recorded and sent out (because of #1, 4
> > invoices need to be sent out)
> >
> > 3.  Price changes - Over the course of the recurring invoices, the
> > price for the rental may change as well as adjusments may change.
> >
> > I believe the review in the docs.ofbiz.org page would allow for this
> > use case as well as all that are currently handled to be addressed in
> > the more generic model. Again, there are several non related issues
> > pointed out as well that anticipate use cases to the various hooks.  I
> > would appreciate any feedback that the community can offer before I
> > dive into this.  Thanks
> >
> > -Chris
>
>
>

[Jacopo Cappellato]

Chris,

Chris Howe wrote:
> I've been adding incrementally, as you suggested, over the last two and
> a half years as new use cases have popped their head.  With each
> increment we've gotten farther and farther away from the community code
> and farther and farther away from a generic approach.  ...

I'd like to clarify what I've written in my previous message: I was not
suggesting to keep your incremental changes outside of the project (this
of course will move your codebase far very soon); instead I was
suggesting to propose/discuss/contribute small incremental changes to
the existing data model *and* processes, instead of a big refactoring
effort.

Jacopo

[cjhowe]

Hi Jacopo,

I've been thinking about how to accomplish it as small incremental
patches to the data model _and processes without running into a
backwards compatibility fight with each change.  

I think Apache Xindice may be a good candidate to handle upgrade paths.
 

A simple xml file can define what group of services need to be run to:
1)migrate data to a new data model structure
2)drop fields that are no longer supported

for instance
<upgrade-paths>
 <upgrade svn-revision="1324532">
  <service service-name="migratePriceData"/>
  <service service-name="dropOrderPriceFields"/>
 </upgrade>
 <upgrade>
 [...]
 </upgrade>
</upgrade-paths>

Xindice can read this file into it's "upgrade" collection on an ant-run
build and a service can be run at startup to make sure all upgrade
instances have been run.  Upon running the upgrade group an attribute
can be added to the upgrade element denoting that it has ran.

This way processes don't need to provide dual support which is more
prone to error.

Any feedback and should we start a discussion on adding Apache Xindice
support to OFBiz?

--- Jacopo Cappellato <[hidden email]> wrote:

> Chris,
>
> Chris Howe wrote:
> > I've been adding incrementally, as you suggested, over the last two
> and
> > a half years as new use cases have popped their head.  With each
> > increment we've gotten farther and farther away from the community
> code
> > and farther and farther away from a generic approach.  ...
>
> I'd like to clarify what I've written in my previous message: I was
> not
> suggesting to keep your incremental changes outside of the project
> (this
> of course will move your codebase far very soon); instead I was
> suggesting to propose/discuss/contribute small incremental changes to
>
> the existing data model *and* processes, instead of a big refactoring
>
> effort.
>
> Jacopo
>
>
>
>
>

[David E Jones]

What does this have to do with the "Use Case and review or Order Entities" thread?

If you'd like to ask about it, please do so in a new thread with a its own subject.

Also, this sort of question is more appropriate on the OFBiz user mailing list rather than the dev mailing list. You are asking about using OFBiz and not extending or working on the main OFBiz code base, which is what the dev mailing list is for.

Also PLEASE provide more details! Which version/revision of OFBiz are you doing? How did you get it and what have you done with it or changed in it?

-David


Pankaj Lall wrote:

> Hi
>
> When ever I'm typing http://localhost:8080/ecommerce/control/main I'm
> getting this error "
>
> (Sourced file:
> component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
>
> : Method Invocation ProductPromoWorker.getStoreProductPromos)))) (Error
> rendering screen [component://ecommerce/widget/CommonScreens.xml#rightbar]:
> *org.ofbiz.base.util.GeneralException*: Error rendering screen
> [component://ecommerce/widget/CartScreens.xml#minipromotext]: *
> org.ofbiz.base.util.GeneralException*: Error running BSH script at location
> [component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh]:
>
> *org.ofbiz.base.util.GeneralException*: Error running BSH script at
> [component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh],
>
> line [30]: Sourced file:
> component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
>
> : Method Invocation ProductPromoWorker.getStoreProductPromos : at Line:
> 30 :
> in file:
> component://ecommerce/webapp/ecommerce/WEB-INF/actions/cart/showpromotext.bsh
>
> : ProductPromoWorker .getStoreProductPromos ( delegator , dispatcher ,
> request )
> "
> What should I do to get rid of this error message.
>
> With Regards
> Pankaj Lall
>
> On 6/1/07, Jacopo Cappellato <[hidden email]> wrote:
>>
>> Hi Chris,
>>
>> wow, it seems you did a lot of work.
>> Just out of curiosity: instead of following the approach of
>> reviewing/refactoring the whole order data model, did you try the
>> opposite approach? I mean, to try to minimize the changes and add
>> support for what you need, in a flexible way. It would be interesting to
>> compare the effort needed by the two approaches.
>>
>> I'm asking you this because I've often had to find a solution for
>> special use cases in the past, and I've always managed them with minimal
>> (or no) changes to the existing structures.
>>
>> My main concern is that you have focused your attention (at least in the
>> document) only in the review of the data model and not in the existing
>> processes and user interface; are you planning to do this as a second
>> phase?
>>
>> Jacopo
>>
>> Chris Howe wrote:
>> > We have a use case that has forced us to review the order entities.  As
>> > it will take a fairly large rewrite to support our use case, we went
>> > ahead and reviewed all of the order entities to see if it would be
>> > advantages for a more thorough rewrite.  The summary can be found in my
>> > docs.ofbiz.org space at http://docs.ofbiz.org/x/GQk
>> >
>> > Use Case:
>> > We rent equipment that is paid for by multiple third party payers
>> > (insurance companies).  A couple things conflict with the current data
>> > model.
>> >
>> > 1.  Multiple payers - For a single billing cycle, there can be as many
>> > as four payers that need to receive invoices.  An invoice needs to be
>> > generate for each one. (one insurance company pays 60%, another 20%
>> > another ins. company 15% and finally the end user 5%)
>> >
>> > 2.  Recurring invoicing. - There is a single order and every 30 days a
>> > new invoice needs to be recorded and sent out (because of #1, 4
>> > invoices need to be sent out)
>> >
>> > 3.  Price changes - Over the course of the recurring invoices, the
>> > price for the rental may change as well as adjusments may change.
>> >
>> > I believe the review in the docs.ofbiz.org page would allow for this
>> > use case as well as all that are currently handled to be addressed in
>> > the more generic model. Again, there are several non related issues
>> > pointed out as well that anticipate use cases to the various hooks.  I
>> > would appreciate any feedback that the community can offer before I
>> > dive into this.  Thanks
>> >
>> > -Chris
>>
>>
>>
>

[David E Jones]

Chris,

For all of this stuff, why don't we step WAY back? What is it (number of very specific things) you need to do?

My impression on reading over much of this, including the data model extensions and the extension mechanisms is the we ALREADY have things in place to handle these things.

When talking about how to implement things the ONLY way to start is with requirements. What is it you are trying to do (specifically) that OFBiz doesn't seem to support. Once we know that, we can start discussing and looking for a solution with minimal impact (ie effort, cost, maintenance and upgrade problems) that satisfies the requirements.

This is what many people in the OFBiz community do on a daily basis and is the primary means of improvement and progress in the project.

The problem I see with your http://docs.ofbiz.org/x/GQk page is that it doesn't really have requirements. It is a review of the data model with no specific needs in mind.

So some specific things you mentioned:

> 1.  Multiple payers - For a single billing cycle, there can be as many
> as four payers that need to receive invoices.  An invoice needs to be
> generate for each one. (one insurance company pays 60%, another 20%
> another ins. company 15% and finally the end user 5%)

This has been discussed recently and Jacopo (I believe) has actually been looking at changing the data model to support multiple BillingAccounts by putting the billingAccountId on the OrderPaymentPreference instead of the OrderHeader. This will require refactoring and extending quite a bit of code because there are so many business processes and UI elements that touch the BillingAccount and order payment stuff, so I don't know when this will be done.

> 2.  Recurring invoicing. - There is a single order and every 30 days a
> new invoice needs to be recorded and sent out (because of #1, 4
> invoices need to be sent out)

This is another extension that can be modeled with an easy extension to the OrderPaymentPreference or BillingAccount (depending on the details of your requirement, what is written here isn't specific enough), but will require some code to support (though it should be fairly minimal impact on existing code).

> 3.  Price changes - Over the course of the recurring invoices, the
> price for the rental may change as well as adjusments may change.

Perhaps the best solution is to use an auto-order shopping list instead of an order with recurring payments, unless you know that the price will change in advance of the order placement (or at the time). In that case, just do what most hotels do and just have an order line for each day of the rental.

-David


Chris Howe wrote:

> Hi Jacopo,
>
> I've been thinking about how to accomplish it as small incremental
> patches to the data model _and processes without running into a
> backwards compatibility fight with each change.  
>
> I think Apache Xindice may be a good candidate to handle upgrade paths.
>  
>
> A simple xml file can define what group of services need to be run to:
> 1)migrate data to a new data model structure
> 2)drop fields that are no longer supported
>
> for instance
> <upgrade-paths>
>  <upgrade svn-revision="1324532">
>   <service service-name="migratePriceData"/>
>   <service service-name="dropOrderPriceFields"/>
>  </upgrade>
>  <upgrade>
>  [...]
>  </upgrade>
> </upgrade-paths>
>
> Xindice can read this file into it's "upgrade" collection on an ant-run
> build and a service can be run at startup to make sure all upgrade
> instances have been run.  Upon running the upgrade group an attribute
> can be added to the upgrade element denoting that it has ran.
>
> This way processes don't need to provide dual support which is more
> prone to error.
>
> Any feedback and should we start a discussion on adding Apache Xindice
> support to OFBiz?
>
> --- Jacopo Cappellato <[hidden email]> wrote:
>
>> Chris,
>>
>> Chris Howe wrote:
>>> I've been adding incrementally, as you suggested, over the last two
>> and
>>> a half years as new use cases have popped their head.  With each
>>> increment we've gotten farther and farther away from the community
>> code
>>> and farther and farther away from a generic approach.  ...
>> I'd like to clarify what I've written in my previous message: I was
>> not
>> suggesting to keep your incremental changes outside of the project
>> (this
>> of course will move your codebase far very soon); instead I was
>> suggesting to propose/discuss/contribute small incremental changes to
>>
>> the existing data model *and* processes, instead of a big refactoring
>>
>> effort.
>>
>> Jacopo
>>
>>
>>
>>
>>
>

[Jacopo Cappellato]

David E Jones wrote:

>
> ...
>> 1.  Multiple payers - For a single billing cycle, there can be as many
>> as four payers that need to receive invoices.  An invoice needs to be
>> generate for each one. (one insurance company pays 60%, another 20%
>> another ins. company 15% and finally the end user 5%)
>
> This has been discussed recently and Jacopo (I believe) has actually
> been looking at changing the data model to support multiple
> BillingAccounts by putting the billingAccountId on the
> OrderPaymentPreference instead of the OrderHeader. This will require
> refactoring and extending quite a bit of code because there are so many
> business processes and UI elements that touch the BillingAccount and
> order payment stuff, so I don't know when this will be done.
>

It is a two-steps process: I'm currently working (in my spare time) at
completing the current billing account implementation without changing
the existing data model; I will soon commit some work that will finally
resolve all the issues that are affecting billing accounts.
Then we will discuss about the possibility of changing the data model as
David mentions.
However the "Multiple payers" features could be possibly achieved by
using one billing account and one agreement and by extending some of the
stuff there.

Jacopo

[David E Jones]

Jacopo Cappellato wrote:

> David E Jones wrote:
>>
>> ...
>>> 1.  Multiple payers - For a single billing cycle, there can be as many
>>> as four payers that need to receive invoices.  An invoice needs to be
>>> generate for each one. (one insurance company pays 60%, another 20%
>>> another ins. company 15% and finally the end user 5%)
>>
>> This has been discussed recently and Jacopo (I believe) has actually
>> been looking at changing the data model to support multiple
>> BillingAccounts by putting the billingAccountId on the
>> OrderPaymentPreference instead of the OrderHeader. This will require
>> refactoring and extending quite a bit of code because there are so
>> many business processes and UI elements that touch the BillingAccount
>> and order payment stuff, so I don't know when this will be done.
>>
>
> It is a two-steps process: I'm currently working (in my spare time) at
> completing the current billing account implementation without changing
> the existing data model; I will soon commit some work that will finally
> resolve all the issues that are affecting billing accounts.
> Then we will discuss about the possibility of changing the data model as
> David mentions.
> However the "Multiple payers" features could be possibly achieved by
> using one billing account and one agreement and by extending some of the
> stuff there.

Yes... good point! Depending on requirements and the business process that may indeed be easier...

-David

[Pankaj Lall]

Hi

I'm getting java.lang.Error: Unresolved compilation problem:
 The method getCombinedMap(HttpServletRequest, Set) is undefined for the
type UtilHttp error

what is the solution for this problem or error

With Regards
Pankaj Lall

[Jacques Le Roux]

Pankaj,

Chris has already told you that it's better to create a new thread for a
new question or what not. He also told you not to use this Mailing List
which is used for development in OFBIz not *using* OFBiz. So please, ask
your questions on OFBiz user ML : [hidden email].

Also for your particular problems you should better send us a snippet of
the log around your problem than only one line for this error. Context
means a lot ...

BTW there is no getCombinedMap method anywhere in the OOTB code and
notably not in UtilHttp

Thanks for your attention

Jacques

De : "Pankaj Lall" <[hidden email]>
> Hi
>
> I'm getting java.lang.Error: Unresolved compilation problem:
>  The method getCombinedMap(HttpServletRequest, Set) is undefined for
the
> type UtilHttp error
>
> what is the solution for this problem or error
>
> With Regards
> Pankaj Lall
>

[cjhowe]

David,

I've already stepped _way back and detailed what I saw in
docs.ofbiz.org. This is essentially the same discussion we've been
having for about a year.  If the community's solution to my use case is
dealing with billing accounts and shopping lists, then I'm not sure I'm
comfortable with (what in my view I would call) mis-modelling the data
that way.  I'm fine with developing what I've suggested in
docs.ofbiz.org on my own and working to converge the two camps rather
than evolve to it.

In either case, there is a need for a mechanism to upgrade the data and
model as things change (in this instance or any other) so that we don't
have to provide ongoing dual support in our services.

--- David E Jones <[hidden email]> wrote:

>
> Chris,
>
> For all of this stuff, why don't we step WAY back? What is it (number
> of very specific things) you need to do?
>
> My impression on reading over much of this, including the data model
> extensions and the extension mechanisms is the we ALREADY have things
> in place to handle these things.
>
> When talking about how to implement things the ONLY way to start is
> with requirements. What is it you are trying to do (specifically)
> that OFBiz doesn't seem to support. Once we know that, we can start
> discussing and looking for a solution with minimal impact (ie effort,
> cost, maintenance and upgrade problems) that satisfies the
> requirements.
>
> This is what many people in the OFBiz community do on a daily basis
> and is the primary means of improvement and progress in the project.
>
> The problem I see with your http://docs.ofbiz.org/x/GQk page is that
> it doesn't really have requirements. It is a review of the data model
> with no specific needs in mind.
>
> So some specific things you mentioned:
>
> > 1.  Multiple payers - For a single billing cycle, there can be as
> many
> > as four payers that need to receive invoices.  An invoice needs to
> be
> > generate for each one. (one insurance company pays 60%, another 20%
> > another ins. company 15% and finally the end user 5%)
>
> This has been discussed recently and Jacopo (I believe) has actually
> been looking at changing the data model to support multiple
> BillingAccounts by putting the billingAccountId on the
> OrderPaymentPreference instead of the OrderHeader. This will require
> refactoring and extending quite a bit of code because there are so
> many business processes and UI elements that touch the BillingAccount
> and order payment stuff, so I don't know when this will be done.
>
> > 2.  Recurring invoicing. - There is a single order and every 30
> days a
> > new invoice needs to be recorded and sent out (because of #1, 4
> > invoices need to be sent out)
>
> This is another extension that can be modeled with an easy extension
> to the OrderPaymentPreference or BillingAccount (depending on the
> details of your requirement, what is written here isn't specific
> enough), but will require some code to support (though it should be
> fairly minimal impact on existing code).
>
> > 3.  Price changes - Over the course of the recurring invoices, the
> > price for the rental may change as well as adjusments may change.
>
> Perhaps the best solution is to use an auto-order shopping list
> instead of an order with recurring payments, unless you know that the
> price will change in advance of the order placement (or at the time).
> In that case, just do what most hotels do and just have an order line
> for each day of the rental.
>
> -David
>
>
> Chris Howe wrote:
> > Hi Jacopo,
> >
> > I've been thinking about how to accomplish it as small incremental
> > patches to the data model _and processes without running into a
> > backwards compatibility fight with each change.  
> >
> > I think Apache Xindice may be a good candidate to handle upgrade
> paths.
> >  
> >
> > A simple xml file can define what group of services need to be run
> to:
> > 1)migrate data to a new data model structure
> > 2)drop fields that are no longer supported
> >
> > for instance
> > <upgrade-paths>
> >  <upgrade svn-revision="1324532">
> >   <service service-name="migratePriceData"/>
> >   <service service-name="dropOrderPriceFields"/>
> >  </upgrade>
> >  <upgrade>
> >  [...]
> >  </upgrade>
> > </upgrade-paths>
> >
> > Xindice can read this file into it's "upgrade" collection on an
> ant-run
> > build and a service can be run at startup to make sure all upgrade
> > instances have been run.  Upon running the upgrade group an
> attribute
> > can be added to the upgrade element denoting that it has ran.
> >
> > This way processes don't need to provide dual support which is more
> > prone to error.
> >
> > Any feedback and should we start a discussion on adding Apache
> Xindice
> > support to OFBiz?
> >
> > --- Jacopo Cappellato <[hidden email]> wrote:
> >
> >> Chris,
> >>
> >> Chris Howe wrote:
> >>> I've been adding incrementally, as you suggested, over the last
> two
> >> and
> >>> a half years as new use cases have popped their head.  With each
> >>> increment we've gotten farther and farther away from the
> community
> >> code
> >>> and farther and farther away from a generic approach.  ...
> >> I'd like to clarify what I've written in my previous message: I
> was
> >> not
> >> suggesting to keep your incremental changes outside of the project
> >> (this
> >> of course will move your codebase far very soon); instead I was
> >> suggesting to propose/discuss/contribute small incremental changes
> to
> >>
> >> the existing data model *and* processes, instead of a big
> refactoring
> >>
> >> effort.
> >>
> >> Jacopo
> >>
> >>
> >>
> >>
> >>
> >
>

[cjhowe]

Jacopo, David, others,

I've continued looking into the least intrusive way of allowing for the
use case.  Here's what I've come up with.  Your thoughts would be
appreciated.

http://docs.ofbiz.org/display/~cjhowe/Rental+Improvement

Thanks!
Chris

[Dale E. Moore]

Hi cjhowe;

I've read of your ofBiz work on health care insurance billing with great interest and hope that some reasonable approach already exists within ofBiz.

This conversation seems to have gone somewhere else, or just died here. Have you heard any more about your plans?

I am unable to get to http://docs.ofbiz.org/display/~cjhowe/Rental+Improvement. http://docs.ofbiz.org seems to have been dead since about August 2009. Do you have another copy of your Rental+Improvement work or know where it can be found?

I look forward to hearing from you,
[e-mail]