How to automate email to DELMIAworks (IQMS) orders and transactions
Short answer
Monitor the shared mailboxes where customer POs, RFQs and supplier confirmations arrive, extract the structured data with a model, match it to DELMIAworks customers, items and orders, and stage the result for human review before entry. Entry then goes through a supported import or API path.
In many DELMIAworks plants, the real order entry system is an inbox. Customers email PDF purchase orders to a sales@ address, suppliers reply to buyers with dates and prices, and CSRs retype it all into sales orders, releases and purchase order lines.
That retyping is where wrong part numbers, missed revisions and late entries come from, particularly with customers who send a different PO layout each time. EDI covers the large customers; the long tail of email covers the rest.
Automation here is not about removing people. It is about getting a draft transaction in front of a CSR with the extracted fields, the matched ERP records and the doubts flagged, so review takes a minute instead of ten.
What teams use it for
Customer PO to sales order draft
Extract PO number, bill-to, ship-to, lines, quantities, prices and requested dates from the PDF, match items and customer, and stage a draft sales order for the CSR.
RFQ capture
Detect RFQs, extract part numbers and quantities, check them against the item master and existing quotes, and create a quote request with attachments filed.
Supplier acknowledgements
Parse reply emails with confirmation of PO lines and revised dates, match to the open PO, and propose promise date updates for the buyer.
Order change and cancellation requests
Recognise language such as push out, pull in or cancel, link it to the right release, and queue it with the quoted text for review.
Shipping and certificate requests
Route emails requesting CoCs or packing lists to the right queue and attach the generated document, with the reply drafted for approval.
DELMIAworks (IQMS) integration surface
- Vendor import tools and templates for sales orders, purchase orders and items (naming varies by version), usable as a supported staged entry path.
- The REST API, if licensed, for creating or updating orders and quotes with validation applied by the ERP.
- Reference tables for matching: customers (ARCUSTO style), item master (ARINVT style), customer part number cross references, and open order and PO tables. Exact names vary by release.
- EDI module and its staging tables, where the same inbound document might otherwise arrive; avoid double entry between email and EDI customers.
- Document attachment features in the ERP to store the original email and PDF against the order.
How it works
- 1
Connect to the mailbox
Use Microsoft Graph or IMAP with a service account on a dedicated shared mailbox. Process messages idempotently using the message id.
- 2
Classify the message
Decide: new PO, change, RFQ, supplier reply, invoice, or other. Route unknowns to a human queue rather than guessing.
- 3
Extract fields
Parse the body and attachments. Use OCR for scanned PDFs, then a model to produce structured JSON against a schema, with a confidence per field.
- 4
Match to ERP master data
Resolve customer by sender domain and ship-to, items by customer part number cross reference, and open orders by PO number. Flag fuzzy matches.
- 5
Validate business rules
Check price against the price list or last order, lead time against capacity, and duplicate PO numbers before anything is staged.
- 6
Stage for review and post
Show the CSR a side-by-side of the source PDF and the draft. On approval, post via the import tool or API and attach the source.
Example flows
New PO from a repeat customer
Trigger: An email with a PDF PO arrives at the orders mailbox.
- Classifier marks it as a new PO and ties the sender to the customer.
- Extraction yields lines; two part numbers match via cross reference, one does not.
- Draft order is staged with the unmatched line highlighted.
- CSR fixes the item and approves.
- Order posts and the email is filed against it.
Result: Entry time falls to a short review, and the unmatched part is caught before it ships wrong.
Supplier date change
Trigger: A supplier replies that two lines will ship a week late.
- Reply is matched to the PO via the subject or PO number in the body.
- Line-level new dates are extracted.
- A proposed promise date change appears in the buyer queue with the quoted sentence.
Result: Buyers see the impact on jobs sooner and update the schedule on purpose, not by accident.
Keeping data on-prem
Email content and PDFs often contain customer pricing and technical data, so keep extraction local. Run OCR and the language model on servers in your network, using an open-weight model sized for structured extraction, and have the mailbox connector read via Graph or IMAP with a scoped service account. Staging tables and review UI live inside your network, and posting happens through the ERP's import tool or API from an internal host. This also fits export-controlled work: attachments never leave your boundary, and the model is not trained on them. If you still want a cloud model for hard cases, route only non-sensitive messages, decided by a rule rather than a person's memory.
Security checklist
- Treat emails as hostile input; scan attachments and never let message text drive an action without validation.
- Defend against prompt injection in email bodies by constraining the model to extraction with a fixed schema.
- Use a service account limited to the shared mailbox and a posting identity limited to staged entry.
- Keep the original email and PDF attached to the transaction for audit.
- Require human approval for any financial or date-impacting change.
Ways to get it done
Vendor EDI or portal for large customers
Effort: Per trading partner, weeks each.
Best for high-volume, stable customers; does not help long-tail email.
Generic intelligent document processing tool
Effort: Weeks to configure per document type.
Works if it can post through the ERP import or API and your volume justifies licensing.
Custom or partner-built pipeline, such as Netray
Effort: A pilot on one mailbox and document type first.
When data must stay on-prem and you want matching tuned to your item cross references.
Pitfalls
- !Auto-posting without review, which turns one extraction error into a shipped wrong order.
- !Ignoring customer part number cross references, so every match is fuzzy.
- !Treating revisions and blanket releases as new orders.
- !Double-entering for customers who also send EDI.
- !No feedback loop, so recurring corrections never improve matching.
Frequently asked questions
Can this write directly into DELMIAworks?
It should post through a supported path such as the import tools or the API, after human review. Direct database inserts skip validation and are risky across upgrades.
How accurate is extraction?
It depends on document quality and format variety. Clean digital PDFs from repeat customers are typically reliable; scans and unusual layouts need review. Confidence thresholds route doubtful ones to a person.
Does it replace EDI?
No. EDI is better for high-volume partners. Email automation covers customers and suppliers who will never set up EDI.
Can we run it without any cloud AI?
Yes. OCR and extraction both work with local open-weight models, which suits plants with customer NDAs or export controls.
What happens with emails it cannot classify?
They go to a human queue with the original message untouched. Over time, recurring patterns can be added as new document types.
Want Email automation working on your DELMIAworks (IQMS)?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment