# Infor M3 Master Data: The Core Objects and the Programs That Maintain Them > Source: https://netray.co/erp-help/infor-m3-master-data-objects-and-programs > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## Short answer Infor M3 master data is a small set of linked objects: items (MMS001), item-warehouse records (MMS002), customers (CRS610), suppliers (CRS620), product structures (PDS001) and the operations and work centers that make up routings. Everything transactional, from customer orders to manufacturing orders, reads these records, so load them in dependency order and treat them as governed data. ## Kind how-to ## System infor-m3 ## Erp Infor M3 ## Module Master data (items, customers, suppliers, product structure) ## Query infor m3 master data ## Alternate Queries - M3 master data programs - Infor M3 item customer supplier BOM routing setup - which M3 program maintains product structure ## Applies To Infor M3 Business Engine, on-premise and CloudSuite; program numbers are standard but menus and field sets vary by version and configuration ## Steps ### How to approach M3 master data in the right order **Items:** - Set up the foundation first: company, division, facility, warehouse, currency, units of measure and the CRS settings tables. Master data refers to these and fails to save without them. - Create items in MMS001 (Item. Open). Choose item type, responsible, unit of measure and planning policy, then connect the item to warehouses in MMS002 (Item. Connect Warehouse). - Create suppliers in CRS620 (Supplier. Open) and customers in CRS610 (Customer. Open), including payment terms, currency and delivery terms. - Link purchasing data: supplier-item relationships in the purchase price and supplier item programs, so purchase orders pick up price and lead time. - Build manufacturing data: work centers and operations first, then the product structure in PDS001 and the operation sequence for the same product and facility. - Verify with the display programs and the MI interface before releasing to planners; run MRP on a test item and look for planning errors. - Put change control around it: who may create items, who approves product structure changes, and how loads from other systems are validated. ## Sections ### The objects and where they live **Body:** Items are the center. The general item record sits in the MITMAS table and the item-warehouse record in MITBAL. Planning behavior, order policy and lead times mostly live at the item-warehouse level, which is why an item that looks fine in MMS001 can still produce no planned orders until MMS002 is complete. Customers and suppliers share the business partner structure. Customer basics are in OCUSMA and supplier basics in CIDMAS, with addresses held separately so one partner can have several ship-to or order-from addresses. Product structures are stored as a header (MPDHED) with material lines (MPDMAT) and operation lines (MPDOPE), keyed by facility and product number. **Code:** Typical program map (verify against your version): Item MMS001 / MMS002 Customer CRS610 Supplier CRS620 Product structure PDS001 Operations/work ctr PDS002 / PDS010 family Tables: MITMAS MITBAL OCUSMA CIDMAS MPDHED MPDMAT MPDOPE ### Load order and why it matters **Body:** Master data has dependencies, so loading it in the wrong order is the most common cause of rejected records. A product structure cannot reference an item that does not exist, and an item cannot be connected to a warehouse that has not been created. Plan the load as layers: settings, partners, items, item-warehouse, structures, then prices. For bulk loads, most teams use the M3 API (MI programs such as MMS200MI for items) through the standard interface instead of typing records or writing to tables. The API runs the same validations as the screen, which is slower but protects the integrity of the data. Direct database inserts bypass those checks and are not supported. ### Governing master data after go-live **Body:** Most operational pain in M3 traces back to master data drift: items with the wrong planning policy, duplicated suppliers, product structures that were changed without a date or an approval. Use structure change dates and revision control rather than overwriting live structures, and restrict who can change planning parameters. A periodic data-quality check pays for itself. Look for items without a warehouse connection, structures with no operations, customers without a credit limit and suppliers with no payment terms. These are simple queries on the tables above, ideally run read-only against a reporting copy. ## Pitfalls - Creating the item in MMS001 and forgetting the MMS002 warehouse connection, then wondering why MRP ignores it. - Loading product structures before work centers and operations exist. - Overwriting a live structure instead of using a new effective date. - Writing straight to M3 tables for a bulk load and skipping business validations. - Letting every buyer create suppliers, which leads to duplicates and split spend. ## Ai Angle A grounded assistant can run the data-quality checks above on request: items with no warehouse, structures missing operations, duplicate supplier names. ERPray reads M3 data read-only, shows the query it used and respects M3 roles, so a planner gets a worklist without needing table knowledge. Fixes are still made by people in the M3 programs or through approved API calls. ## Faq ### What are the main master data objects in Infor M3? **Answer:** Items, item-warehouse records, customers, suppliers, product structures, operations and work centers, plus supporting settings such as warehouses, facilities, units of measure and payment terms. Transactions in sales, purchasing, inventory and manufacturing all read these records. ### Which M3 program creates an item? **Answer:** MMS001, Item. Open, creates and maintains the general item record. The item must then be connected to a warehouse in MMS002 before it can be stocked, purchased or planned there. ### How do I bulk load master data into M3? **Answer:** Use the M3 API (MI programs) so the standard validations run, either through a script or an integration tool. Avoid direct table inserts. Load in dependency order and test with a small batch first. ### Why does MRP ignore my new item? **Answer:** The usual cause is a missing or incomplete item-warehouse record, or a planning policy that excludes MRP. Check MMS002 for the facility and warehouse and confirm the order policy and planning fields. ## Search terms infor m3 master data, m3 item master, MMS001, MMS002, CRS610 customer, CRS620 supplier, PDS001 product structure, m3 data load, MITMAS, MITBAL --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json