3 Replies Latest reply on May 26, 2017 2:53 PM by Shawn Gerlock

    Best way to represent fractions or threaded Mxx values?

    Shawn Gerlock Seasoned Veteran

      We have many products whose attributes need to be represented as fractions, e.g. 1/2", 3/4". While logically I would prefer to store these as decimals in P360, this is going to make it a challenge to represent visually when the content is pushed to a channel like a web site, as nobody refers to a 1/2" screw as a 0.5" screw.


      I can set up the attribute to be a character string with preset values ordered by a logical sequence number, but this is both tedious to set up and also doesn't work well if an attribute might sometimes have decimal and sometimes fractional values (e.g. Diameter could be 3/4" for one product and 0.93 for another).


      Metric threaded values such as M6, M8, M10 present a similar challenge. The data guy in me says these should be numbers, but then you don't get the "M" prefix. Currently I'm storing these as strings with preset values.


      Any best practices out there?




        • 1. Re: Best way to represent fractions or threaded Mxx values?
          Greg Clark Seasoned Veteran

          Hello Shawn.


          I would be interested in hearing best practices as well. 


          We have the similar situations as the one you describe.   We work with plumbing fixtures and pipe threads.   1-1/8" and 0.75"  pipe thread is an example.  We also work with water flow for standard and metric measurements. Gallons per minute and Liters per minute.


          Our business decision was to create 2 attributes to display both metric and standard values.  1 to hold the standard value and 1 to hold the metric value.  Water Flow(Gpm), Water Flow(Lpm). 


          As far as threads go, we did what you explained.  We set preset values and have both the fraction and decimal representation.  The attribute data type is defined as a character string.


          I wrestled with the same thing you did...is this a number or string.  I justified the business decision because an attribute describes the item.  If it is an accurate description then the data is stored properly.  M6 is the proper description for a metric srew.  1/2" is the proper description for a standard screw size.


          Hoping to help,


          • 2. Re: Best way to represent fractions or threaded Mxx values?
            Dave Nacy Active Member



            I've done a bunch of large scale industrial catalog work that were PIM driven. We ended up creating sequence numbers for Items based on the "key" attribute and created sequence numbers on the attributes themselves so that one can change the column order they appear in a table. All the metric and imperial fractional values were stored as strings with units. We stripped off any double quote marks on import.


            Excel has some okay sorting function for fractions as strings, but nothing beats the human eye when suppliers send stuff like "1 1/2" or "1-1/2". It's pretty easy to sequence them in Excel or in the item list view.



            • 3. Re: Best way to represent fractions or threaded Mxx values?
              Shawn Gerlock Seasoned Veteran

              Thanks guys for your responses. I originally modeled the data as strings, then changed to decimals, then after reading both of your responses went back to strings. Greg's point is that 1/2" is the proper designation for a screw and accurately describes the item. After thinking about that argument I completely agree.


              Fortunately P360 is relatively easy to configure in this way, so we are going to write this into our spec for threaded items. I also set a standard of value x 1000 for sequence numbers, e.g. a 1/2" value will be 500, 3/4 750. This way adding other values after the fact won't be a chore to sequence.


              We had some other loose standards where we used fractions where we didn't necessarily need to, so on the flip side I'm going to require these be decimals. So our SOP will be that we will use decimals unless there is a specific use case for strings (e.g. threads). We've also uncovered some ratty data where we had things in our old system like a numeric value of 8.1 for something intended to be an Mx value, so the presets will help in that manner as well.