From order email to ERP draft: fields and states
A completed mapping follows the message through to a saved draft, approval and handling of duplicate receipt.
Follow the message through to the target state
A language model can suggest information from an order email. Transfer into an ERP also needs defined sources, checks and visible states. Describe when a message is captured, when clarification is needed and when a draft has actually been saved. Later internal approval of the order has its own step.
Define fields with their source and result
For the fictional incoming message EM-84, the customer account and authority to order have already been checked. The table defines the mapping for this case.
Field | From the email | From approved business data | Result in the draft |
|---|---|---|---|
Customer | Customer reference | Checked customer account and authority | Link to |
Item | Code | Unambiguous matching active item | Link to the existing item |
Quantity and unit | 4 cartons | 5 pieces per carton | 20 pieces; original unit remains documented |
Price | No amount stated | Valid customer pricing rule | Current value with traceable price source |
Case reference | Incoming message | Stable incoming-message identifier | Link to the original and the associated draft |
The conversion here is 4 × 5 = 20. It relies on the approved packaging definition. If that mapping is unresolved, the case goes for clarification. The model does not fill in the factor from similar product names or earlier answers. Changes to quantity, item or pricing rule are checked again before transfer.
Treat saved and approved as separate states
After transfer, the example counts the draft as created only when the ERP confirms the saved record D-84 and the expected values. Sending a write request is insufficient. The responsible person can view the original, mapping and open review status together. The agreed approval step moves the case into an internally approved order. Subsequent order confirmation or reservation is defined in the relevant follow-on process.
Plan for repeats and uncertain outcomes
If EM-84 arrives again, its incoming-message identifier should lead to the existing draft. An amended order is assessed as a new version. If a response is missing after transfer, the process first establishes the state in the target system. Another write attempt needs a rule that prevents creating the same case twice.
Before use, check an unknown item, different packaging, a missing pricing basis and an uncertain write outcome. For missing required information, define where the case awaits clarification and who takes it on. For an uncertain outcome, an already created draft must also be findable again. Assessment then covers the complete path to the correct record and approval state.
Sources
Read more
All articles
AI & Automation with ASES
AI assistants and automated workflows