Move order intake from email attachments to portal, RFQ, and EDI flows with clear fields, testing, exception handling, and monitoring.
Last updated: May 29, 2026
This guide explains how to receive customer orders through Portal, request-for-quote flows, CSV files, or EDI instead of email attachments. Define fields, customer access, validation rules, and exception handling before launch so every customer-submitted request becomes the right Sanka record.Use this as a how-to flow for operations teams. For the feature reference, see Portal overview.
Claude/Codex
Prepare a portal and EDI order intake checklist for this customer. Compare required order fields, item codes, quantities, delivery dates, billing details, files, duplicate rules, RFQ exceptions, and who must review failed rows. Do not create orders yet.
Preparing intake checklistI prepared the order intake checklist. Confirm required fields, duplicate handling, RFQ exceptions, and review owners before turning on customer submissions.
Ask for another intake check...
Choose the intake path
Start by deciding what each customer should use.
Portal cart: customers select approved catalog items, enter quantities and required order fields, and submit an order.
Portal RFQ: customers request pricing or terms for special quantities, custom specifications, or non-standard items. Sales reviews the request and creates a draft estimate.
CSV import: operations receives structured files from customers or partners and imports orders after mapping and validation.
EDI or integration intake: high-volume customers send structured order data through a connected order exchange flow.
Do not turn every path on at once. Start with the smallest path that covers the customer’s real process, then add automation after the required fields and exception rules are stable.
Confirm the required fields
Before launch, agree with each customer or trading partner on the data they must send.
Customer company and contact
Customer purchase order number or external reference
Item code, item name, variant, or customer-specific item mapping
Quantity, unit, currency, price, discount, and tax handling
Requested delivery date, shipping address, delivery method, and notes
Billing information and invoice recipient
Attachments or supporting files, if required
Duplicate detection rule, such as customer purchase order number plus customer company
Exception owner for missing fields, unknown items, invalid quantities, or duplicate orders
If any required field is unclear, keep the intake in review mode. Missing mapping rules create support tickets later because customers may think they placed an order while the operations team sees an incomplete request.
Review with AI before enabling intake
Ask AI to review the field map and test cases before customer submissions begin.
Sample prompt
/sanka Review this portal/EDI order intake setup before launch. Check customer access, required order fields, item code mapping, quantity and price rules, requested delivery date, billing details, attachment requirements, duplicate order rule, exception owner, and test orders. Do not enable the intake yet.
For files or partner mappings, ask for a dry-run review first.
Sample prompt
/sanka Dry-run this order intake file. Map customer, purchase order number, item code, quantity, requested delivery date, billing details, shipping details, and duplicate key. List rows that need manual review. Do not create orders yet.
Test end to end
Run a small test before opening the flow to customers.
Submit one normal order with valid customer, item, quantity, delivery, and billing details.
Submit one duplicate order using the same customer purchase order number.
Submit one incomplete order with a missing required field.
Submit one unknown item or customer-specific item code.
Submit one RFQ-style request that should become a draft estimate instead of an order.
Confirm the created Sanka record, customer association, line items, totals, status, document download, notifications, and audit history.
The test is not complete until the operations owner can explain what happens to accepted orders, rejected rows, incomplete records, duplicate submissions, and RFQs.
Expected behavior
When order intake is configured correctly:
Portal cart submission creates an order after required fields and item selections are valid.
RFQ submission creates a quote request for sales review, not a final order.
CSV or EDI intake creates or updates orders only after customer, item, quantity, and duplicate rules pass validation.
Customer, contact, item lines, order properties, files, totals, currency, delivery details, and source information are preserved where configured.
Failed rows or incomplete submissions remain visible for manual review instead of silently disappearing.
Notifications and dashboards make unprocessed, failed, duplicate, or returned orders visible to the team.
Order intake does not automatically fix unknown item codes, choose a customer company, override item visibility, bypass required fields, create invoices, reserve inventory, or send customer documents unless your workflow is configured for those steps.
Troubleshooting
A customer says they submitted an order, but no order exists
Check whether they submitted the cart or only added items to it, whether required fields were missing, whether the session timed out, whether the order was rejected as a duplicate, or whether the submission became an RFQ instead of an order.
An order was created for the wrong customer
Review contact-company associations, selected portal company, duplicate contacts, customer purchase order number, CSV or EDI customer mapping, and whether the same contact can access multiple companies.
Item lines are missing or mapped incorrectly
Check item code mapping, customer-specific item names, variants, required item options, inactive items, customer visibility filters, and whether the item should have gone through RFQ instead of direct ordering.
Quantity, price, or tax is wrong
Check unit of measure, quantity basis, selected item options, customer price table, currency, discount, tax settings, and whether the submitted value was a requested price rather than an approved selling price.
Duplicate orders were created
Check whether the duplicate key was defined, whether customer purchase order number was included, whether resubmitted files were marked as updates or new orders, and whether portal and EDI submissions overlapped.
AI cannot decide whether this is a bug
Ask AI to compare customer access, source channel, required fields, item mapping, duplicate key, order/RFQ status, related estimate, notifications, and audit history. Treat it as a product bug only after confirming the intake setup and source data are correct.
Checkpoints
Before launch, review customer access, required fields, item mapping, duplicate rules, RFQ routing, failed-row handling, notifications, dashboards, downstream order/invoice/inventory workflows, and audit history.
2Test order submitted2026/05/20 11:00Portal order testCreated test order and confirmed line items, totals, and customer associationSales operations
1RFQ exception checked2026/05/22 09:30Special quantity requestConfirmed request should become a draft estimate, not a final orderSales user
Order intake review should prove that customer submissions become the correct order or RFQ, and that exceptions are visible before customers are affected.
