Partner Order Intake → ERP

Stop retyping the orders your partners send over chat and phone. Partners place orders through a single link, like a conversation, the agent asks back for anything missing, and then logs the order into your ERP as a sales order.

What you get

• One order link to hand to your partners. They don’t need an UpServe account.
• A partner writes freely — “3 boxes of 10kg rice, deliver tomorrow” — and the agent confirms the item, quantity, and delivery date.
• Confirmed orders land in an order ledger and get pushed into eCount ERP as sales-order slips on a schedule.
• Nobody retypes anything.

What you need

• An eCount ERP account with a master ID that can issue API certification keys. Only the ERP owner can open that screen.
• Two agents running at once in UpServe — there is no headcount limit, so the Free plan works as-is (you only draw down SU as they work).

The shape: why two agents

This recipe runs on two agents with split roles. There’s a hard reason they can’t be merged.

 [Partner]                  [Order taker]              [ERP handler]
 chats via link  ─order─▶  public shared agent  ──▶   agent in your account
 no signup                 no ERP credentials         holds eCount keys
                           only takes orders          owns the order ledger
                                                      logs slips into the ERP

• The order taker is published externally. Partners talk to it directly, so it never holds ERP credentials.
• The ERP handler only ever runs inside your account. It keeps the eCount key and does the actual logging.

UpServe resolves stored credentials only in an agent’s own main conversation. In a published-snapshot session they are never resolved — so an order taker calling the ERP directly simply would not work. The split is a safety property, not a design preference.

Step 1: Hire the ERP handler

1. Hit + at the top of the left sidebar and choose Hire. Confirm, and your new employee starts immediately — they ask what the job is first, so one line is enough: “log sales orders into eCount ERP and keep an eye on inventory.”
2. Open the new agent’s Settings tab and turn on these three skills in the skill picker.

Step 2: Connect eCount — let the agent walk you through it

Type this in the chat:

Start the eCount onboarding.

The agent guides you step by step. You don’t need to read any API docs.

1. Issue a test certification key — log in to eCount and go to Self-Customizing > 정보관리 > API인증키발급. A test key is valid for 2 weeks and renewable up to 3 times.
2. Register the egress IP — use [IP등록] on the same screen. The agent looks up its own outbound IP and tells you, so you don’t have to find it. eCount rejects calls from unregistered IPs (login error 205).
3. Add web-upload fields — in the 주문서입력 and 판매입력 menus, the fields the API sends must be added first. Fields that aren’t configured there are silently ignored — no error, the value just vanishes. The agent finds the missing ones during test-server validation.
4. Hand over credentials — company code, user ID, and cert key go through the secure input card, never plain chat. The agent brings the card up.
5. Approve the first call — the first call that uses a stored credential raises an approval card once. Do this while you’re at your desk. After that one approval, autonomous runs to the same place don’t ask again.
6. Validate on the test server, then switch to production — eCount requires every API to succeed at least once on the test server before it issues a production key. Once validation passes, issue the production key (1 year, master ID only) and replace the stored value.

Step 3: Align the product and customer master

Pull the product and customer lists from eCount and set up the ledger.

This maps what partners call things (“10kg rice”) to eCount product codes. Without it, free-text orders won’t resolve to the right item.

This is also where you set safety buffers. If you also sell the same products through other channels (your own store, marketplaces, walk-ins), agree a per-product buffer so displayed stock is reduced accordingly.

⚠️ Stock numbers are advisory. eCount has no change webhooks, so the agent can only poll. Stock sold through other channels isn’t reflected until the next read. That’s why taking an order means “got it,” not “stock reserved.” Real stock is checked again right before the sale is confirmed.

Step 4: Publish the Order API

Publish the order API.

The Webapp Publish skill stands up a small API that receives orders — the order taker posts to it. Publishing is hard to undo, so an approval card appears once.

Step 5: Create the order taker and issue the link

1. Create a second agent. “An order taker that receives and organizes partner orders” is enough. Do not turn on the eCount skill.
2. Give it the Order API address from step 4 and tell it to forward orders there.
3. From the agent screen, create a public snapshot under Share externally and issue a link. A review assistant checks for anything that shouldn’t go out before publishing.
4. Send the link to your partners.

Usage on a public link is billed to your SU. You can cap per-session and daily SU per link — set those caps before handing the link out. See Sharing an agent.

Step 6: Schedule the sync

Tell the ERP handler:

Every 30 minutes, push new orders into eCount and write the slip numbers back to the ledger.

The agent registers its own schedule. Tap the approval card once when it appears.

What you’ll see in operation

• Orders missing details — the order taker asks back. If the partner doesn’t answer, the order stays on hold.
• Orders short on stock — if the check right before logging finds a shortfall, it isn’t an error: the order moves to a stock-pending state and you get notified.
• Unknown partners or products — items that don’t exist in eCount are registered only after you confirm the details.

Next steps

• Sharing an agent — links, SU caps, updating a published snapshot
• Connections — how stored keys are protected
• Booking Intake → Calendar — handling channels with no dedicated integration

Advanced

You don’t need any of this to build the recipe. Come back when something breaks or you want to understand the shape.

The inventory truth model

eCount is the source of truth; the agent’s ledger is a cache. Three rules follow.

1. Displayed stock = ERP balance − safety buffer, and it always carries an “as of” timestamp.
2. Taking an order is not a stock promise. Sales are never confirmed against intake-time stock.
3. The only trustworthy stock check is the one right before confirming the sale — which is also the call that actually deducts inventory.

The faster an item moves, the bigger its buffer should be. The buffer absorbs whatever other channels take between polls.

Why credentials don’t resolve in a published snapshot

A stored-key reference is turned into its real value only in that agent’s own main conversation. It is not resolved in published-snapshot sessions or in sub-scopes — because you must never hand ERP keys to an agent that strangers are talking to. That rule is what forces the two-agent shape.

eCount-side gotchas

• Unconfigured web-upload fields vanish silently. No error is raised, so the slip is created but the value is blank. The required set differs per company, which is why test-server validation matters.
• Login rate limit — production allows one login per 10 minutes. The agent caches and reuses the session.
• No API for electronic tax invoices. That part stays manual.
• Error 205 (unregistered IP) — happens if the outbound IP changes. eCount allows up to 5 registered IPs, so pre-registering spares in the free slots turns an outage into a non-event.

Cost notes

• The shorter the sync interval, the more autonomous runs, and SU scale with it. Start at 30–60 minutes.
• Start both the order taker and the ERP handler on the default Standard tier. If the ERP handler keeps getting item matching wrong, move just that agent to Ultra.
• A public link spends your SU whenever someone uses it. Always set a daily cap per link.