How to automate email in Macola
Short answer
Monitor a shared mailbox, classify each message, extract customer, part numbers, quantities and dates, validate them against Macola master data, and stage a draft order or PO change for a person to approve. Never auto-post without review until accuracy is proven on your own mail.
In a typical Macola order desk, customer purchase orders arrive as PDFs and email bodies in a shared inbox, and someone re-keys them into order entry. Vendor acknowledgements and shipping notices arrive the same way and rarely make it into the PO promise dates. This is the oldest and most expensive form of integration: a person reading and typing.
Email automation targets that gap. The goal is not a robot that enters orders blindly. It is a pipeline that reads the message, proposes the transaction with the source attached, and lets a clerk confirm in seconds rather than minutes.
Macola's strength here is clean master data in SQL Server: item numbers, customer part cross-references and price lists. That makes validation of extracted lines practical, which is where most of the accuracy comes from.
What teams use it for
Customer PO to draft order
Extract ship-to, PO number, lines and requested dates from an emailed purchase order and create a draft order entry record for review.
RFQ intake and quote draft
Identify RFQs, match requested parts to items or customer part numbers, and prepare a quote with price list lookups.
Vendor acknowledgement parsing
Read order acknowledgements and update proposed promise dates on PO lines for buyer approval.
Shipping notice matching
Match ASNs and carrier emails to open POs so receiving expects the right goods.
Change request detection
Flag emails like 'please push the date to the 20th' and attach them to the order as a pending change.
Invoice and statement routing
Route vendor invoices to the AP team or the OCR pipeline and associate them with the open PO.
Macola integration surface
- Master data in SQL Server: customers, items, customer cross-references, vendors, price lists. Use views to read them, and verify table names against your version.
- Order entry and PO maintenance are the transactions you want to feed. Depending on version and licensing there may be web services or batch import routines; ask Exact or your reseller.
- Direct inserts into order or PO tables are risky; they skip application logic such as pricing, credit and allocation.
- Mail access is separate from Macola: IMAP, Exchange Web Services or Microsoft Graph for the shared mailbox.
- A staging table in an integration-owned schema holds extracted fields, confidence, source email ID and review status.
How it works
- 1
Connect to the mailbox
Use Graph or IMAP with a service account restricted to the shared inbox, and move processed mail to a folder.
- 2
Classify the message
Separate POs, RFQs, acknowledgements, invoices and everything else using rules plus a small model.
- 3
Extract fields
Pull text from the body and attachments (OCR for scans), then extract header and line fields into a structured record.
- 4
Validate against Macola
Check customer, item or cross-reference, unit of measure, price and delivery date against master data and flag mismatches.
- 5
Stage for review
Show a side-by-side view of the original email and the proposed order lines with confidence per field.
- 6
Post through a supported path
After approval, create the order or PO change using the licensed interface or an approved import, and link the email ID.
Example flows
Customer PO arrives as PDF
Trigger: An email with a PO attachment lands in the orders mailbox.
- The classifier tags it as a customer PO.
- OCR and extraction produce header and lines.
- Item numbers are matched through the customer cross-reference.
- A clerk reviews a draft order, fixes one unit of measure and approves.
Result: Order entry takes a short review instead of full re-keying, and the original PDF stays linked to the order.
Vendor pushes a date
Trigger: A supplier emails that a PO line will ship a week late.
- The message is matched to the PO number in the subject or body.
- The new date is extracted and compared to the current promise date.
- A task asks the buyer to accept or contact the vendor.
Result: Promise dates stay current, so MRP and sales promising work from realistic data.
Keeping data on-prem
Email content often includes pricing, drawings and customer information, so many manufacturers want extraction to run in-house. Run mail polling, OCR and the extraction model on a server inside your network, with an open-weight model served locally. The integration then needs only read access to Macola master data and a controlled write path for approved transactions. If your mail is Microsoft 365, the connector makes an outbound call to Graph, but attachments and extracted data can be processed and stored on-premises. Keep the staging database and attachments in your own storage with retention rules, and do not send documents to a third-party model API unless your policy allows it.
Security checklist
- Use a dedicated mailbox service account with least privilege and no access to personal mail.
- Scan attachments for malware before OCR or extraction and treat email content as untrusted input.
- Guard against prompt injection: extraction output is data to validate, never instructions to execute.
- Restrict the integration database login to staging and read-only master data views.
- Keep an audit trail linking each ERP transaction to the source email and the reviewer.
Ways to get it done
Off-the-shelf EDI or order capture service
Effort: Weeks per trading partner, plus mapping.
Fits large customers who can send structured EDI instead of free-form email.
Build in-house with mail API and a local model
Effort: Roughly four to eight weeks for one document type with review UI.
Fits teams with development capacity who want to control accuracy and data location.
Partner build with Netray
Effort: A pilot on one mailbox typically takes a few weeks.
Fits shops with several email types, cross-reference complexity and a requirement to stay on-prem.
Pitfalls
- !Auto-posting orders without human review while accuracy on your real mail is unknown.
- !Skipping customer part cross-references, which leads to wrong item matches.
- !Parsing the entire thread including quoted history and picking up old quantities.
- !Not deduplicating when a customer resends the same PO.
- !Ignoring unit-of-measure conversions between customer and Macola.
Frequently asked questions
Can Macola read emails by itself?
Not as a native feature that I would rely on. You add a separate service that reads the mailbox, extracts data and hands off proposed transactions, using whatever import or service interface your Macola version supports.
Is it safe to auto-create orders from email?
Only after measuring accuracy. Start with draft creation and human approval, track correction rates by customer, and consider auto-posting only for well-behaved senders with consistent formats and passing validation.
How does it handle PDF purchase orders?
Digital PDFs can be read directly, while scans need OCR. Extracted lines are validated against item masters and cross-references and shown with confidence scores for a clerk to confirm.
Will this work with Microsoft 365 or Gmail?
Yes. Use Microsoft Graph or IMAP with a restricted service account on a shared mailbox. The processing and storage can still be on-premises even though the mailbox is hosted in the cloud.
Does EDI make this unnecessary?
For partners that can send EDI, yes, structured data is better. Email automation covers the long tail of customers and vendors who will never adopt EDI, which is common for smaller Macola customers.
Want Email automation working on your Macola?
A free 30 minute assessment: we map the integration path for your version and setup, and where it should run.
Get a free assessment