Posted by
Carl Sopchak on
URL: http://ofbiz.116.s1.nabble.com/Dev-Ordering-Units-of-Measure-tp167406p167421.html
On Thursday, April 06, 2006 21:10, David E. Jones wrote:
> > 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.
Just to be clear - I don't consider my client cheap. In fact, this client is
one of, if the THE, best client I have ever had as far as not continually
pounding me to get things done for less money. But I feel they should be
getting value for the buck. If it will take me 10 hours to do a mod to meet
their needs, and 50 to do a "complete" mod that satisfies all, I don't expect
the client to pay for the extra 40 hours. (Nor will I ask them to.) If the
difference is 10 vs 15 hours, I'd probably do the complete mod, and only
charge for 10.
>
> 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.
I guess I'm a good consultant, then :-)... Generally, I find adding a feature
in a flexible manner is usually actually easier than more rigid solutions.
Plus, it has the added benefit that when the client says "well, now I want to
do Y", you get to say "due to my superior design, you can already do that
with the mod I made for X". The client then (hopefully) thinks "Good, it's
free!", and, hope against hope, "Maybe this guy isn't as expensive as I
thought..." ;->
>
> > 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.
I'll move them. As far as the JIRA goes, the two files that belong in the
product component were separate from the .patch file, so the commiter can put
them where they belong. I'll need to change the reference within
service_uom.xml, which I'll re-post when I have it done.
>
> 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.
Understandable. Is there a hierarchy described somewhere? I'm sure most of
it is common sense, but there could be some components that may blur as to
which is "higher" or "lower" than others...
>
> 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.
That's fine. I was just wondering if there was any kind of "usual" time
frame. It actually makes NO difference to me, as we're not even close to
getting to a production environment yet. But, I must admit, I do get some
satisfaction out of seeing my changes committed to a project.
>
> 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.
No one ever told me patience was something I lacked... Hope I didn't come
across that way, and I'm sorry if I did...
>
> 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.
I appreciate the control required, particularly with a project of such
complexity. In fact, I would have to seriously reconsider OFBiz viability if
it wasn't there.
And, I must say I *DO* appreciate the efforts that you, Si, and Jacopo put
into the project. All three of you have already been a great help in our
implementation, and we've barely started.
>
> > 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.
I'm thinking this switch would be an "order entry level" type of switch -
either UoMs are displayed and enterable during customer order entry, or they
are not. If not, OFBiz works as it does today. If so, all products would
have the ability to enter UoMs. If there are some products where only one
UoM applies, then it would be the default UoM for the product, and you
wouldn't have to enter anything.
I don't see this working very well as a per-product setting. This is mainly
due to the fact that the product ID and quantity - and UoM for the quantity
when I put that in - would be entered on the same screen. By making it
per-product, I think the order entry flow (multiple screens?), or the screens
(showing UoM when unnecessary), or both, could be a bit confusing or awkward.
====
Again, thanks for all of your help.
Carl
>
> -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_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev