9.01.12 on premise. This question stems from a previous post I made regarding fields getting overwritten/updated by magic. I've taken Geko's (and other at work) suggestion of starting over and building slowly, block by clock. So far, it's working. I've laid out my components & linked them to the IDO properties. No Component Classes, filters, etc., just basic enter a valid value & save. I'm now at the point where I need to add more data, but I want to make it extensible. Here's the scenario:
Materials Handling has requested a Form that makes a shopping cart for material requests, including how they need to be processed. Quick in English examples:
- "I need 4 Widgests quantity moved to Location ABC"
- "I need 1 Plumbus misc issued to Reason Code 90210"
- "I need 2 Sprockets issued to job 1 suffix 2 operation 1, and 1 Cog misc issued to reason code 11235"
My current IDO for the requests holds only common information across all request types, including a column that identifies the type of transaction needed. Originally, I made all of the information about said requests part of the table, with nullable columns for the unused columns for a given request type. I don't like this approach as I can't easily add additional request types without adding new columns to the table.
My current thought is this: Since I know the type of request, I can create an IDO for each request type and all data about said request are stored in the request table.
On the form, my understanding is I would have the Primary Collection be my Request From Stock. I would add Secondary Collections for each type of request I want the user to make. The collections would have permanent Filters of (ID_OF_REQUEST=REQUEST_ID).
The best I can hope for with the Grid in this situation is a simple text derived field that can display an in English description of the transaction information.
Am I over complicating this, or is this the way things should be working?
