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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >> > >> > >> > >> > >> > > >
