[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[gnue-sb-discuss] The Skinny on item_maint.gfd
From: |
Mike Vincent |
Subject: |
[gnue-sb-discuss] The Skinny on item_maint.gfd |
Date: |
Thu, 27 Mar 2003 17:59:15 -0600 |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [gnue-sb-discuss] The Skinny on item_maint.gfd,
Mike Vincent <=