How to Build a Grid Mapping in M3 Enterprise Collaborator (MEC)

Build a new MEC grid mapping

1. 1Confirm the M3 API transaction the mapping will ultimately call (for example OIS100MI.Add for a sales order line) and pull its full field list before starting the mapping, since the grid's target side is defined by that transaction's input fields.
2. 2Define the collection step for the source document - the file type, EDI standard/version (X12, EDIFACT) or XML schema, and where MEC will pick it up from (folder, AS2, queue).
3. 3Create the grid mapping object and load or define the source structure so MEC knows each source field's name, position, and data type.
4. 4Map each required M3 API field to its source counterpart in the grid, applying any transformation (date format, code translation, concatenation) at the field level rather than pre-processing the source file.
5. 5Build code/value translation tables for anything that does not map one-to-one, such as an external customer or item code that needs to resolve to the internal M3 key.
6. 6Set default or derived values for M3 API fields the source document does not supply but the transaction requires, so the API call is not rejected for a missing mandatory field.
7. 7Configure the delivery step to call the mapped MI transaction and define what MEC should do with the M3 API response - log success, route errors to a review queue, or trigger a notification.
8. 8Test with several representative real source documents, including at least one that is missing an optional field and one that should legitimately fail, before promoting the mapping to production.
9. 9Turn on MEC's process/transaction logging for the first production runs so you can see exactly what was collected, how the grid transformed it, and what M3 API returned.

Grid mapping mechanics

Grid row example:
Target field: OIS100MI.Add / ITNO
Source: EDI850 / LIN03 (buyer item number)
Transform: lookup via XREF table (partner item -> M3 ITNO)
Default: none (mandatory field, fail if lookup misses)

Common pitfalls

• !Doing data transformation in the collection step instead of the grid, which makes the mapping hard to reuse and hard to test in isolation.
• !Hardcoding partner-specific value translations directly in the grid logic instead of a maintainable translation table.
• !Not defining defaults for M3 API mandatory fields the source document never sends, causing every document to fail delivery on the same missing field.
• !Testing only with clean sample documents and skipping edge cases like a missing optional segment or an unrecognized partner code.
• !Sending every delivery failure to a single generic log without attaching the source document, making failed transactions hard to correct and resubmit.
• !Changing a shared grid mapping for one trading partner's quirk without checking which other partners or processes reuse the same grid.