Closed maxolasersquad closed 14 years ago
I'll fix this soon.
Fixed in commit 5490479832c363f278a42308451d5235551427b9.
Whoa, whoa, whoa, this is a major feature for stores that use their own barcodes. Looking through the post (http://is4c.coop/bb/viewtopic.php?t=72) discussion also suggests that the cause of this problem was mis-entered product information.
We ran into this bug at our store. Our barcodes where entered by scanning them in with a barcode reader. From the thread it looked like this was a Wedge specific thing, not something intended for general use. We have our own UPC's for local items, we just use numbers that cannot possibly conflict with other "real" UPC's.
Hmm, according to the oracle of wikipedia, concerning UPC prefixes - "2: Reserved for local use (store/warehouse), for items sold by variable weight. Variable-weight items, such as meats and fresh fruits and vegetables, are assigned a UPC by the store, if they are packaged there. In this case, the LLLLL is the item number, and the RRRRR is either the weight or the price, with the first R determining which." (http://en.wikipedia.org/wiki/Universal_Product_Code) Do you have an example handy of a product that has a conflicting code? And that product's information in the products table? Most of our items from our Deli and Meat departments are sold using labels printed on the spot using the existing technique. It'd be nice to figure out how to keep this feature alive, and how to make it play nice in different situations.
I guess I misunderstood what was being said in the thread. I thought this configuration was specific to the Wedge, and since it seemed to cause problems to others (including us) it wasn't really a general release feature. I didn't mean to "correct" it so hastily. I'll research what's in the thread, what's in the Wikipedia article, and how our bar-code scanned items are getting rung up wrong.
Closed per commit SHA: d03003d45939547637b7a36b8bb5b92b08fdc5d9
See http://is4c.coop/bb/viewtopic.php?t=72 for more information.