Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have written an application that my clients use to keep inventory. The inventory system includes a purchase order module. Each purchase order has a list of line items including:

  • Description of item
  • Quantity to order
  • Unit of measure
  • Unit price

among others. When asked about the "unit of measure" field, my response is always to use a unit label that reflects the manner in which you consume or resell the items. Here are a couple examples of what I mean:

  • "cc" for liquid medication stored in a bottle
  • "Bar" for a candy bar
  • "Bag" for a bag of dog food

This is clear when the unit of measure being consumed or resold matches the unit of measure on a received invoice. My problem is when it does not match. For example, medication is usually sold by the bottle, but dispensed by the cc or pill, candy bars are purchased by the box or case and sold individually, and dog food can be purchased by the pallet and sold by the bag.

In my experience in the past few months, I have realized that's it's unrealistic for a user to translate boxes into bars or bottles into cc, but I have not yet found a good way to remove the need for the mental translation.

Should I set up a table for equivalencies (1 box = 12 candy bars, 1 bottle = 1000cc, etc) and ask the user which they are ordering? This seems like it would add a lot of complexity behind the scenes when a vendor changes their packaging or offers new options. I'd like to keep the whole process as easy as possible.

Am I thinking about this incorrectly? Is there a simpler more elegant solution?

Update: Here are some line items I'm getting that don't work:

Cephalexin        1     Bottle     $100.00
Snickers         10     Box         $12.97
Dog food          1     Pallet     $122.50

These are almost completely useless to me because the units and quantities aren't useful when updating the inventory. People don't resell dog food by the pallet or antibiotics by the bottle. This is what I need:

Cephalexin      100     Pill         $1.00
Snickers        120     Bar         $1.297
Dog food         20     Bag         $6.125

Those units, quantities, and prices directly correlate to the units that are consumed or resold. The first set are what the OEM vendor expects.

share|improve this question
    
I have this exact same issue, in almost the exact same situation (medicinal units). –  jberger Jan 5 '12 at 17:12
    
Here's something I found (although it doesn't specify any algorithms for actually solving the problem). –  jberger Jan 5 '12 at 17:34
    
@jberger is there a specific page you're referring to? –  Sparafusile Jan 5 '12 at 17:36
    
My initial idea was to store the quantity as a predetermined unit (e.g. mL). The GUI allows a user to enter in a number and a label (e.g. [100] [cases]). "cases" is a multiplier which contains a scalar value to get to the actual amount of the stored value for that particular medicine. The problem with this is how to store it (client or DB). DB design is new to me. –  jberger Jan 5 '12 at 17:40
2  
Expanding on previous post: Labels should include multipliers. "cases" would seem a bad label. A better one would seem "case of 12 @100mL" or "dose of 20mL". –  jberger Jan 5 '12 at 17:47
show 6 more comments

4 Answers

up vote 2 down vote accepted

From my understanding you have an application which thinks of products in terms of:

  1. Inventory (and)
  2. Products

The owner buys a box of chocolate bars, enters the new acquisition into the system.

The system need to be able to know how many bars (units) the new inventory contains in order to update the (customer facing) stock levels.

I don't think you can get away from the fact that the owner will need to provide information about the number of units their new inventory purchase without access to manufacturer supplied line data.

However, even so, I don't think the problem is insurmountable .. maybe you're over-thinking the problem?


This is the way I'd approach the problem:

  • When entering information about a new inventory purchase, the owner needs to provide the number of generic units that each new acquisition of inventory contains.
  • These (customer facing) units can either be fixed / or variable (weight / volume)

FIXED UNIT (can be sold individually)

  • The total number of units contained in the new inventory acquisition needs to be entered.
  • It doesn't matter what these fixed units are - the owner can enter a text string representing them on entry of the inventory (eg. bar, pill, necklace, brush).
  • A simple parser can be developed to deal with singular/plural versions of the string.
  • This label can be used on the customer facing form.

VARIABLE UNIT (sold by measured amount)

  • If the inventory is to be sold as variable units, the owner needs to decide whether they'll be sold using weight or volume.
  • The total weight / volume needs to be defined.
  • The granularity of measurement unit needs to be defined.
  • The cost per variable measurement unit needs to be defined.

Hope this helps.


Re. The unit problem mentioned below

If the site owner is having a problem understanding to concept of a saleable unit, maybe the answer is to add the unit input fields into part of a natural language sentence, and to use the answer to provide an example of how the unit label would be used.

VARIABLE UNIT

The customer can purchase this product by the [_variable_unit_selectbox_input_].

Ajax feedback -> "Example: Joe Bloggs bought 5 [_variable_unit_selectbox_input_] of [_product_type_]"

FIXED UNIT

The customer can purchase this product by the [_unit_label_text_input_].

Ajax feedback -> "Example: Joe Bloggs bought 5 [_variable_unit_input_]s of [_product_type_]"

share|improve this answer
    
I think this is an excellent answer. My one hang up is how to explain this in a coherent way to somebody that has never been exposed to a system like this. My most common question is "what do I put for units here?" which I can't personally answer, but only provide a guideline. Even after explaining how it works, I still have people that do the complete opposite because they're not use to thinking in that way and get confused. If you can add a solution to that in your answer I will happily accept it. –  Sparafusile Jan 6 '12 at 14:28
    
I would provide some explanatory text asking your site owner to think about what the customer will be purchasing (unit) - and provide a few examples that are relevant to your customer's retail domain. –  codeinthehole Jan 6 '12 at 14:43
    
This is exactly what I've done, to no avail. Despite on-screen instructions and explanations, they still do it backwards on occasion. I'm beginning to think some fault lies with my explanations and I should be more verbose. –  Sparafusile Jan 6 '12 at 15:21
    
@Spara: Why the users don't understand: I'm a programmer and I have to read through the answer again to understand it. Now, think of first-time users who didn't design the system and who don't know it inside-out... I'd stick with a mix of templates/multipliers that Aaron and I have been discussing. –  jberger Jan 6 '12 at 17:28
    
@codeinthehole: I'm not understanding your usage of "fixed" and "variable" units. The question has to deal with the differences between ingoing and outgoing quantities and how to handle different units. Also, I don't understand your example in relation to the question. Please include a template of the feedback as well as an example (the example is mixed). –  jberger Jan 6 '12 at 17:37
add comment

You should be selling in the unit that your customers expect, and then interpret that appropriately. Or in the unit you sell in - do you really sell BOTH boxes of bars and individual ones? If so, you might want to consider having them as separate products or variants.

When your customer has ordered 2 bar boxes, you indicate that 2 boxes of 12 each = 24 bars. Or if they order 2 bars - a separate item - you indicate 2 bars.

So start from the point that your customer expects to see, and clarify exactly what this means, where appropriate.

share|improve this answer
    
That part I'm clear on. What I'm having trouble is when my client orders the items to resell. The units my clients uses to purchase don't match the units used to resell so I need to reconcile that in the inventory when items are received. –  Sparafusile Jan 5 '12 at 17:32
    
@Sparafusile Back to my answer, you state to label the unit of measurement as you would consumer or resell, not purchase. I'm confused as it sounds like they are violating this principle. –  Aaron McIver Jan 5 '12 at 17:41
    
They just can't wrap their head around the concept. They enter 1 box because that's what they want to buy, but don't realize it has to be in a until that will be resold. –  Sparafusile Jan 5 '12 at 17:49
    
I think you need to start by clarifying with the customers what they understand, and what they want to do. Let them do that, and then organise and inform around that. –  Schroedingers Cat Jan 5 '12 at 19:07
    
@Sparafusile: yes, the inventory guy only does enter "1 box", because that's all he deals with. However, the multiplier to the base unit is needed; hence, "1 [box of 12]" or "1 [box of 48]". This would not be a hard concept to grasp for the inventory guy. –  jberger Jan 6 '12 at 17:54
show 6 more comments

As far as I can see, the problem is with the inventory system rather than the software since you did if based on your clients' requirements. The standard of warehouse management is to assign SKUs (stock-keeping units) to every variation of an item carried, which includes colors, packaging, and storage sizes. Your software is suffering because there's no way to connect 1 candy bar sold in retail to the pallet of cases of boxes of candy bars that the warehouse receives from the supplier.

What you should do is go back to the drawing board with your clients and design SKU systems that work for them. SKUs are custom, occasionally long and descriptive internal identifiers. They should be tied to UPCs (universal product codes) to allow fast look-up in the warehouse & at the check-out. The complexity & detail level of an SKU system is entirely up to the inventory managers. Some people prefer them long and descriptive and others like them short.

In the database, one retail SKU can belong to multiple display, storage, and ordering units so that whenever the bulk container size changes inventory managers can easily order the right quantities.

For example, candy bars are sold individually and assigned a retail SKU of 12345. It is placed on the store shelf in a box that contains 36 of them, so the display unit (box) SKU is 12345-D36. In the warehouse, the boxes are stored in cases of 12, so the storage unit (case) is assigned SKU 12345-D36-S12. The cases are shipped & ordered in pallets of 50, so the ordering SKU will be 12345-D36-S12-O50.

For another example, let's consider a TV that is sold, displayed, and store individually but is shipped & ordered in pallets of 10. The base SKU in my system will be 54321 but since it's the same unit across multiple stages it'll be 54321-RDS1 and the pallet's SKU will be 54321-RDS1-O10.

share|improve this answer
    
This is a good answer, you obviously know what you're talking about. Unfortunately, it just wont work with my clients who are mostly very small business owners (1-5 employees) and who don't really want to put the effort into creating SKUs for every item. Inventory control is not the goal of my clients and they could never hire a full time inventory manager. I think, in my specific case, your solution requires too much overhead. –  Sparafusile Jan 6 '12 at 15:25
    
If they don't have the resources to implement a full-blown SKU system, you can at least implement container/packaging nesting in the software to make their lives easier. Your current system of unique identifiers is far from optimal even in terms of DB management but it's a start. –  dnbrv Jan 6 '12 at 15:31
add comment

It seems like the translation is surfacing due to a violation of your first principle...

...use a unit label that reflects the manner in which you consume or resell the items.

It appears the issue is how they purchase the goods to then resell, am I correct in this assumption or am I missing something?

  • The bottle is the container, the pills are the product.

  • The box is the container, the candy bar is the product.

Stay away from defining the container as the unit of measurement since that is nothing more than an abstraction. The abstraction can change, the product most likely won't. While dog food comes in a bag, the unit of measurement is lbs, since you can have varying bag sizes (abstraction) which contain different amounts.

This may be a simple case of tight coupling throughout the product and your application needs to provide varying levels of abstraction to deal with this. Raw units of measure (lbs, count, etc...) up to abstracted units of measure (bag sizes, bottle sizes, etc...).

share|improve this answer
    
Yes, but you don't sell dog food by the pound, you sell it by the bag. If you sell medication by the pill, I need to know the quantity of pills when you buy a bottle. What I expect is the number of pills you've purchased, not the number of bottles. I will update my question to reflect the difference. –  Sparafusile Jan 5 '12 at 17:22
1  
No, I buy dog food by the lb. You pick up a 40lb bag, a 30lb bag, etc... I don't just purchase a bag of dog food. Same with pills. I need 50, 100, etc... The container doesn't matter to me. It could be a milk carton of pills for all I care. I really think you might be looking at this in a somewhat narrow view due to your applications architecture. –  Aaron McIver Jan 5 '12 at 17:23
    
A 40lb bag and a 30lb bag are two separate items. If that were not the case, a 40lb bad would always be 33% more than a 30lb bag. You also can't ask for 5lbs out of a 30lb bag. The "bag" is the unit you buy, the weight is just a feature. –  Sparafusile Jan 5 '12 at 17:29
    
@Sparafusile I have to disagree. I respect your approach but that bag size can change on a whim. It's not product, it's packaging. When I look at a screen for my allotment it will be based on weight (distinguishing factor). I'm not implying that abstraction doesn't need to exist (unit size, bundle packaging, etc...), it just sounds like certain architectural decisions within your application are prohibiting you from moving forward in a more fluid manner. –  Aaron McIver Jan 5 '12 at 17:40
1  
@Sparafusile If the purchasing unit of measure does not equate to the selling unit of measure, someone has to do the translation. Either the application or a user. If the unit of measure is 1 bottle from the manufacturer, is this auto-populating within your application? Does the user say I purchased 1 bottle manually? Allow the user to set up mappings, templates if you will. Make them easy to edit and maintain. You can leverage the users intimate knowledge of a vendor to do the translation for them. MyTemplate1 (1 btl = 1000 cc) or something similar. –  Aaron McIver Jan 5 '12 at 17:53
show 11 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.