[gnue-sb-discuss] The Skinny on item_maint.gfd

[Mike Vincent]

This pretty well just rehashing what's already been discussed, but I was
pondering earlier and somewhat inspired by Jason's AP/GL posting to create
a cleaner clearer objective to finishing the Item/Product mgmt module.

Key features I expect to get out of the Item Mainagement Form, which is
the big kahuna of the product/item mgmt module.

* I want to be able to sit down with a vendor's catalog in front of me
  and  bring up this form to add the vendor's product to my system. With
  that in mind, I believe this is what would be required to accomplish
  it. 

      1) Select the product family
      2) Select the product mfg
      3) Enter mfg model#, and generate a reference# to it if it's new**
      4) Enter a brief description of the product
      5) Enter a detailed description of the product
      6) Enter the possible color options for this product
      7) Enter the possible size options for this product
      8) Enter the price
      
      1 will probably just be a dropdown entry possibly with a button to
        launch it's maintenance form.
      2-5 are already present with the lu_item_mfg_model_maint form, so
        it's possible that the information that form maintains can be
        retrieved in the form of a dropdown or some such, maybe 
        "mfg - model#", and a button be provided to launch the form in
        the event that we need to add or change the data. 
        
        ** It's not automatically generating the ref# like it should,
        but other than that I think it's a "Go!". To recap what is
        needed with regard to the ref#:
        Each Mfg's model#'s need a sequence of reference numbers which
        start over with each Mfg. So for example, if Nike, has models,
        a, b, and c the reference#'s are 1, 2, and 3, and if Hanes has
        models j and k, the reference#'s are 1 and 2, not 4 and 5. I
        believe we decided we needed to add another field to the mfg's
        table to hold this counter per mfg. 
      6 and 7 to me, are what complicate this form. Because what we're 
        ultimately doing is creating a SKU, you need both in combination
        with the prior information to formulate a complete sku. From a
        user standpoint, I would *really* like a way to do this in
        batch. Just key in or select all the possible options and hit a
        button to automagically generate all the appropriate SKUs. But,
        I understand that might not be feasible at this time.
      8 is another one I have issues with. I believe that as far as
        pricing goes, I will find myself maintaining it outside the
        GNUe-SB framework, at least to begin with. 
        
        I think the workable solution for how to handle pricing, and
        multiple pricing in particular, is to put it in it's own table,
        I guess it would still belong to the item_mgmt module:
          item_price table
          id
          label -- user defined description, "Base", "Special", "Tier1"
          sku   -- the item this price is for
          qty   -- volume of items are needed before this price applies
          price -- the price
       So for folks who dont need or care about multiple prices per
       products and such, they just set one price, for a qty of 1. But,
       for folks who do need to setup multiple prices, they can set as
       many volume levels and prices as they desire per product. And
       when price calculations need to be made a check on the volume
       could be used to determine which price to use. As discussed
       before, there may also be a desire to give some customers
       preferential pricing regardless of the volume of their order. 
       My suggestion is to have a field in the customer record with
       points to the label field above to indicate that regardless what
       the qty might be, this customer gets at least the pricing set for
       that label, or in the event that the qty warrants a better price,
       then the better price would apply.
          
With this form done, It should then be possible to work on reports to
generate catalogs and price lists. Also, I've only mentioned my basic
needs here, there are other things which could be included on the form
that I and others will need or find desirable such as UPC and REF SKU
(re: OLD SKU on old form). Things like case sizes, fill qtys, etc. I'm
thinking should be left to the inventory module whenever it manifests. 

--- 
Mike Vincent
Tops Embroidery Works
Keller, Texas
http://www.topsew.com