Method:Classic General Q&A

Re: Table Structure for Items

jnoneiliv1 — Fri, 02 Jul 2010 20:28:39 GMT

Ryan,

Thanks, that helps a bunch and I think I understand. I only need to work with NonInventory and Service Items, so I think I'm going to be safe in my interpretation of the views into the master Items table and the associated Screen definitions.

I suppose these various views into the master Items table greatly improves performance and management of this large list particularly when used as drop downs or other relational links.

I have about 3,000 items I'll need to import so I just wanted to make sure I really understand the structure before attempting to move around a bunch of data and your explanation helps tremendously. I guess it would have all worked just fine without understanding the views into the master table, but at least I'm a bit more confident.

Cheers,

James

Re: Table Structure for Items

Anonymous — Fri, 02 Jul 2010 19:14:37 GMT

Hey James,

We have a table for each Item Type, that’s why you see "InventoryItem" and "NonInventoryItem". This is because each type of item needs to track different information. On a Assembly Item, we need to have a Bill of Materials(BOM). When you create a Inventory Item, you don’t need to capture the BOM information.

The Items table acts as a master table that stores all the data, the other tables (ItemNonInventory, ItemInventoryssembly..) are pre filtered tables. The Items table's main goal is to show you all of the item information. The other tables break down based on the Item Type.

If you add a field to any of the Item's table, it is added to the rest of the Items tables by default. Add your custom fields to the Items table, and you will see this is done. Once you have the fields on the table, you will need to customize each Items screen in order to add your new field.

If you want to add fields for Assembly Items, then edit the ItemInventoryAssembly table and add the field. Then go into the ItemInventoryAssembly screen and add the field to the screen.

To help you understand what these tables do, try looking at the different screens that are built based off these tables.

Re: Table Structure for Items

jnoneiliv1 — Thu, 01 Jul 2010 23:16:55 GMT

Anybody want to take a crack at this?

I'm planning on building a lot of new tables this upcoming long weekend and it would be a great help to have some overall conceptual understanding of the Item table(s) structure.

Cheers,

James

Table Structure for Items

jnoneiliv1 — Wed, 30 Jun 2010 16:25:18 GMT

I am trying to understand how the Items tables are used in Full Blown Method.

There are several tables for Items including Item, ItemInventory, ItemNonInventory, and more. All of these Items tables appear to have the same fields including custom fields imported from QB. All of these tables also appear to have the same number for records as synched from QB. All of these tables also have a field called "Item Type" which would presumably be limited to the QB item types of Inventory, NonInventory, Service, etc.

As I would like to add a bunch of new fields to Items in Method for use in Sales Order, Invoices, etc., I am trying to understand which table(s) need to be updated with new fields in preparation for Screen customization.

Why are there several Item tables with the same fields and record count? What is the role of the generic Item table? If there is a field [Item Type], why are there several different Item tables, one for each Item Type? How can I determine which Item tables need to be updated with new fields to correspond with various screens?

I suspect these tables are required to support some aspect of QB synch only and the Item table somehow controls the others. Is there a "Master" Item table that cascades changes to the others?

Best Regards,

James