Posted by
David E. Jones on
URL: http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167411.html
Carl Sopchak wrote:
> As for too much feedback - no such thing! I'll listen to all of the ideas (in
> fact the UoM change employed Jacopo Cappellato's implementation suggestion),
> but when it comes time to implement, my client doesn't want me solving the
> world's problems on his dime. ;-> I will always make the change extensible
> in those situations, though...
There are some nice arguments for making things more flexible. If a client is really cheap then you should do what you can a move on. Some clients are just not good to work for and there is no way to avoid certain sorts of losses. There are a lot of reasons for this that I've seen over the years, but having a short range vision or assuming they have all the answers they need for right now and don't want to even consider other things are some common ones.
Anyway... considering flexibility and adaptability during analysis is always a good idea. If the client doesn't like it then it is more difficult for you, but no less necessary. A good consultant, in my opinion, should always do such things and discuss them with the client and in essence acknowledge that not everything is known at the moment and that there is a 100% chance (+/- 0%) that things will change in the company in the future, and they can avoid a lot of pain by considering the possibility now.
> As for where to put the code, maybe I goofed up on that in the UoM change. I
> kept it all in "common", because it was all UoM related, which I figured was
> a "common" function. Are you saying that the product-based portion of the
> change (in files services_uom.xml and UomFormulas.xml) should be under
> applications/product, not framework/common? I guess that shouldn't be too
> big of a change (but please let me know if it's required/desirable)... BTW,
> how long might it take to get a JIRA patch into the SVN? Is there anything I
> can do to speed it along (like post test results)? No real time requirement,
> I suppose. Just wonderin'.
Yes, this should be split out into changes for the common component and separate ones that can depend on the common component ones but that go in the product component.
As I mentioned before the common component and lower level components in general should never know anything about stuff in higher level components. So yes, that split is important.
As for time to get them in... there are no guarantees and little consistency in this. Si, Jacopo, and I are all trying our best to keep up with Jira issues in addition to reviewing bigger issues that come up and pursue what we have to in order to survive financially.
In other words, there is no funded organization behind OFBiz so things happen when they can. If someone wants things to go faster and has the resources to get that done then it will get done. If not then the only choice is to wait for someone else to pay for what you can't or don't want to pay for. There are certainly many who are investing in OFBiz in this way, but if you want to take advantage of that it does require patience.
For Jira issues there is a LOT of room for help with these by whoever wants to help. This doesn't mean we'll give commit access to just anyone or just anywhere, we do need to have some control over what goes into OFBiz to help keep it stable and such, but there are literally thousands of hours of review of issues and finding or improving solutions that needs to be done. If people want to contribute time that's a great place to do it. Just try the patches and comment on them, or even just vote for issues that are more important to you. This is an opportunity for everyone using OFBiz to express what is important to them. Without that all I can do each week with the hours I set aside for the project is guess at what might be the highest priorities, or just pick the ones I like the best or think I can get done most quickly.
> Lastly, it's not certain that we will need to make this change (although I
> think, long term, it's probably the best way to go), but if we do, I was
> thinking of making the functionality based on a "configuration
> switch" (customer ordering UoMs? Yes/No). Is there a place within OFBiz
> (database or config file) to store such things?
It depends on what the setting will affect. This may be best as a per-product setting to change what is presented in the customer (or CSR) facing UI. There are various examples of this already on the Product and related entities.
-David
>
> Thanks again for the comments, and help.
>
> Carl
>
> On Wednesday, April 05, 2006 19:43, David E. Jones wrote:
>> Carl,
>>
>> On the do it separately versus a part of OFBiz: there are a lot of benefits
>> for you as well as others to doing it as part of the main project. The
>> downside is that you may get more feedback and review that you want.
>> Sometimes this brings up issues that need to be resolved but that you don't
>> care about, though what often happens is that it turns out that they are
>> issues you really do need to work over.
>>
>> Whenever doing something based on OFBiz, and especially something that will
>> go back into the project, the most important part is basically what you are
>> doing now: reviewing what exists and deciding how to meet your requirements
>> with existing and/or new features. If it's going back into the project then
>> the duplicated functionality issue is an even bigger one.
>>
>> =============
>>
>> For this particular issue I agree that they shouldn't be different products
>> for different UOMs. The general approach is to configure the size in one
>> UOM (preferably consistent across similar products) and convert it in the
>> user interface layer (and perhaps higher level services) to/from what to
>> user prefers.
>>
>> The UOM stuff you are talking about should, as I mentioned before, be split
>> into 2 sets. The core UOM stuff that does not deal with products (including
>> conversion between varying dimensions, extended UOMs that are industry
>> specific, etc) would go in the "common" component. The extensions to those
>> for dealing with Product specific stuff should go in the "product"
>> component.
>>
>> In general as much as can be shared should go into lower level components
>> like common, but those can't depend on higher level things in other
>> components like product.
>>
>> -David
>>
>> Carl Sopchak wrote:
>>> OK, I finally got my Data Model Resource Books on Saturday, and I see
>>> that the author suggests that different ordering UoM's are either
>>> different features, or even different products. I'm not sure I agree
>>> with the different products view, but I was wondering if anyone has tried
>>> implementing multiple ordering UoM's as product features. If so, I was
>>> wondering how well it worked for you, and how, specifically, they would
>>> get set up. (Admittedly, I haven't spent a LOT of time on trying to
>>> figure this out yet, but I'd rather spend my time changing the order
>>> entry screens if needed...)
>>>
>>> The product my client sells is wood: 2x4's, 4x8's, plywood, etc. You
>>> know, the stuff you build houses with. In our view, a 2x4x8, is a 2x4x8,
>>> is a 2x4x8! We'll be shipping the same pieces, whether they order 200
>>> pieces, 1600 lineal feet, 1067 board feet, or 1 "unit" (those huge
>>> "packages" you see stacked in your local home improvement store).
>>> Further, if they order 1000 board feet, we may very well ship the 1067 BF
>>> in a unit. (Other rounding-type issues may apply as well.) If we have
>>> only one full unit, and a customer orders 100 pieces, we break the unit.
>>> In other words, there's nothing special with the UoM's, except
>>> convenience (or habit of the customer) in ordering.
>>>
>>> So, for us, different UoM's are DEFINITELY NOT different products. (Even
>>> the ream of paper example in the book doesn't fly well with me - thinking
>>> about boxes and pallets of reams of paper, but I'll let that slide for
>>> now...) I'm not too sure how well ordering will work (particularly
>>> during the busy summer months) with UoM as a feature.
>>>
>>> One last question: If we decide to do the order entry mod described in
>>> the original email, should we do it as part of OFBiz and submit a patch,
>>> or should we keep it as a local mod (since it seems against the data
>>> model apparently employed by OFBiz)?
>>>
>>> Any comments or suggestions would be most welcome.
>>>
>>> Thanks,
>>>
>>> Carl
>>>
>>> On Saturday, March 25, 2006 15:55, Carl Sopchak wrote:
>>>> Much to my surprise, OFBiz does not seem to "do" order quantities in
>>>> units of measure other than the stock keeping unit. (I.e., you can't
>>>> order a "Box" of something when stock is kept in "Eaches".) Someone,
>>>> please let me know if I'm wrong here! Or, if anyone has made the mod on
>>>> a "custom" basis, please contact me off-list.
>>>>
>>>> Assuming I need to make this change, here is what I propose:
>>>>
>>>> 1) Add attributes to the Product entity: skuUom (stock keeping unit
>>>> UoM), and customerOrderUom (default customer order quantity UoM; I
>>>> forsee a supplierOrderUom in my future, too, but I'm not sure yet).
>>>> 2) Add the above fields to the Product Entry screen. Validate that
>>>> either the two UoM's are equal, or that there are UomConversion records
>>>> to go between the two.
>>>> 3) Add attributes to the OrderItem entity: quantityAsOrdered and
>>>> quantityAsOrderedUom.
>>>> 4) Change the entry of order line items so that the quantity that is
>>>> entered on the screen is saved in the quantityAsOrdered attribute, and
>>>> add a drop-down of units of measure, showing only those units of measure
>>>> which have a UomConversion record on file where the uomIdTo =
>>>> product.skuUom, with the default value being the
>>>> product.customerOrderUom, and the selection being saved in
>>>> quantityAsOrderedUom. The quantityAsOrdered would be converted from the
>>>> quantityAsOrderedUom to the product.skuUom, and the result stored in
>>>> OrderItem.quantity. (There may be a rounding issue here that convertUom
>>>> will have to address...)
>>>> 5) Change the display of order lines to show the quantityAsOrdered and
>>>> quantityAsOrderedUom instead of (or in addition to?) quantity and
>>>> skuUom.
>>>>
>>>> Here are my questions:
>>>>
>>>> - Overall, does this make sense? Comments / suggestions / etc.
>>>> welcome... - I haven't received my Data Modeling Resource Books yet (on
>>>> order...), so I'm assuming the entities mentioned above are the right
>>>> place to put the additional attributes. Please correct me if I'm wrong.
>>>> - As for the "drop-down of UoMs" based on the product entered, this may
>>>> be a bit difficult on a web page due to the way web browsing works
>>>> (although I've seen "dynamic" pages that do similar things). Is there a
>>>> standard way to handle such things in OFBiz? Should I just display the
>>>> customerOrderUom, and supply a pop-up to pick from (based on the
>>>> productId)? This does seems a bit awkward though, particularly for
>>>> "high volume" order entry.
>>>> - Although I'm sure I could find where everything needs to go, if anyone
>>>> would like to point me to specific things that would need changing
>>>> (particularly if I missed something), it would be most appreciated.
>>>>
>>>> Thanks in advance for the help and comments.
>>>>
>>>> Carl
>>>>
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev