[thelist] database to create/maintain form, and record submissions

[Luther, Ron]

Joel D Canfield asked:

>>I need to create an order form (marketing supplies for inhouse sales
>>reps) which can be edited by end users (it's all inhouse, and I'll be
>>able to train them.) 

Congrats! 

>>The form currently has about a dozen sections, with less than dozen items 
>>in each section. They need to be able to sort the items in whatever order 
>>strikes Marketing's fancy.

I was going to make a some suggestions based on a prior life managing 
in-house 'delivery' collateral inventory (and liberally interspersed 
with disparaging comments on Marketing's inability to grasp the concept 
of "data quality") ... but then it struck me that you might be asking 
about being able to resort and recategorize the 'items in the catalog' 
rather than the fields on the form.

I don't do shopping carts ... but I would think you would be able to 
reskin one that would allow folks to resort and reclassify the catalog.


HTH,

RonL.


Other notes:

* Yup - internal purchase orders should have unique IDs. They should also 
allow multiple lines.  (Possible decision point on whether to allow 
one user to edit an order placed by another - if not, then User_ID 
might be another element of the key.)  [Very large systems where POs 
are entered on 

* With only a dozen items per section, LoV drop-downs would probably 
be a better choice than letting users mistype part numbers.

* Assuming master data exists, (ha!), giving people placing orders 
an indication as to "In Stock / Out of Stock", "Current Item / 
Discontinued Item", and "In Stock usually delivered in 3 days. Out 
of Stock usually delivered on February 31st" might be nice.



SupplyOrders table based on the WO_NUM field. For each field in the
Sections/Items cross, if a matching 'Item' was found in 'SupplyOrders'
the
value would be written. That way, going forward, if new fields are
added,
they'll just be blank for old orders. 


>>If a field is disabled, they'd have to decide if that affected only 
>>the 'new orders' form, or would be retro to the 'updates' form, 
>>effectively deleting those items from availibility.

Or you could have a 'meta' table flagging individual table fields as 
"disabled" that could be used to suppress those from the application.

OTOH, if you are talking about disabling/deleting an item in the catalog, 
you might be able to prevent that with a referential integrity constraint 
against the open orders table, or maybe a sproc that cancels those 
order lines and emails the request initiator to let them know they were 
cancelled.