Purchasing Buyer, from Quote Requests to Orders and ERP Records

Every time a part is needed, someone mails each vendor, opens the quotes, retypes them into a spreadsheet, writes the purchase order, and keys it into the ERP again. The AI employee Purchasing Buyer prepares all of that. A person decides which vendor wins. The employee never picks.

What you get

Your vendor list becomes a vendor table.
For each part you need, a separate quote request mail goes to every vendor. No vendor can see who else was asked.
Replies and quote files (PDF or Excel) are read into a quote table, line by line, with the original file attached to the line.
The vendors are compared side by side on one screen, one line per vendor at the quantity you need.
Once a person selects, the order mail and the ERP record follow. Both go ahead only when they match what the person approved.

Who does what

Step	The employee	A person
Vendor list	Reads the file and proposes the table	Approves creating the table on a card
Quote requests	Prepares one mail per vendor and shows it	Checks recipients and content, approves sending
Replies	Reads replies and quotes into the table	Decides what to do when a revised quote arrives
Compare and select	Lines vendors up at the needed quantity	Selects the vendor
Order mail	Prepares the mail to the selected vendor	Approves
ERP record	Posts the first record, reads back what was stored	Approves the write, checks the result

Some things the employee never does: it does not choose a vendor, convert currencies, issue tax documents, pay vendors, or accept contract terms. A vendor’s internal quality score and quality note are changed only by people or by sync.

What you prepare

A vendor list file: Excel (xlsx) or csv. Vendor code or name, quote mail address, contact and payment terms are useful. If a mail address is blank, the employee does not guess one. It tells you it is missing.
An ERP connection: eCount has a dedicated integration. For any other ERP or CRM there is a general connection procedure. Credentials are stored in the secure vault only, never in chat or memory. The eCount preparation is covered the same way in Partner Order Intake → ERP. The ERP is a later step, so it does not block the first conversation.
Drawings or spec files (if any): they can ride along with the quote request mail.

Walkthrough

Step 1: Hire the employee and hand over the vendor list

Open the Templates menu, go to the Employee templates tab, find the official template Purchasing Buyer, press Use and confirm to create the employee, then attach your vendor list. In a personal space it may also show up as an “experienced hire” card in the + Hire window (top 3 by popularity), but it does not always, so the Templates menu is the reliable route. Use on a template creates the employee in your personal space. In an organization space, describe the purchasing work in team hire, and the Purchasing Buyer can be proposed as a team member (you decide which members to keep from the proposal). In the first conversation the employee reads the list right away and summarizes it: number of vendors, vendors without a mail address, duplicate names or codes, and rows that look like headers or totals. If you have not attached a file yet, that file is the only thing it asks for.

It then proposes the vendor table on an approval card. Nothing is created until you approve. A proposal carries at most 30 vendor rows. The rest are loaded from the next run once the table exists.

In an organization space the employee may start with read-only access to data, and a “write access request” card can appear. Only the space owner can approve this card, and once approved, rows can be written from the next run. Until then the employee says it cannot write yet and does not keep retrying in the same run.

No mail goes out and nothing is written to the ERP in this step.

Step 2: Connect the ERP

The employee walks you through the connection for your ERP. The order never changes.

Until the connection is complete, it makes read-only calls.
The first write is exactly one record. The employee first shows what it will post, field by field.
After posting, it reads back what the ERP actually stored and compares it with what it meant to send, field by field.
Only after a person checks does it move on to the next record.

A person declares the write addresses, and from then on every write call needs approval. The approval card shows the target server and path, not the content being sent. That is why the employee says what it is posting in the message right before the call. If a system cannot be reached, the employee says so, and it does not call file exchange or screen automation an integration.

Step 3: Create the need and send quote requests

Tell the employee the part, quantity and date needed. It creates a need and one quote request per active vendor, then prepares an individual mail for each vendor.

Each recipient gets a separate mail. Other vendors’ addresses are never visible.
A reference code goes in the subject so a reply can be tied back to its request.
If you set a reply deadline, the server does the waiting. The employee does not need to keep the chat open.
The employee first shows the recipient list, subject, body and attachments. The approval card lists every recipient. Nothing goes out until a person approves.
A mail that is not approved does not go out.
If a recipient comes back as UNKNOWN (outcome not known), it is not resent, and the employee tells you.
A reminder can go only to vendors who have not replied, and it needs its own approval.

Step 4: Read replies and quote files

When replies arrive or the deadline passes, the server wakes the employee. It reads the reply text, not only the attachment, because the reply may be a question, a request for the drawing, or a refusal.

If a quote file (PDF or Excel) is attached, the employee reads item, unit price, currency, quantity, minimum order, delivery, validity and terms into lines, checking each value against its source cell. Each vendor’s quote layout is remembered for the next quote. If your organization has turned that memory off, the layout is built for this run only.
A quote received again is skipped, not written twice.
A revised quote with the same number but different values is never written over the old one. The employee shows what changed and asks a person. If the stored quote was already selected, it says the approval must be given again.
Each quote line also gets the need number and the vendor’s internal quality score copied in.
A quote that came by phone or another mail thread is still recorded, and that vendor’s wait is closed with a note about how it arrived.
Once every vendor is settled or the deadline passes, the comparison starts. It does not start earlier.

Step 5: Compare on one screen and let a person select

The comparison is one line per vendor at the quantity you need. A vendor with price breaks contributes only the line matching your need. The vendor’s quality score is copied in again at comparison time so you never compare on a stale value.

No currency conversion. If currencies are mixed, they are shown in separate groups and marked as not comparable. A person decides. The available currencies are KRW, USD, EUR, JPY and CNY.
A quote whose minimum order is above your need is not hidden or silently dropped. It is noted in the notes and in the employee’s message.
Only a person records the selection. The employee cannot write the selection field. After a person records it, the employee reads it and updates the need and quote statuses.
If the workflow is published to the portal, the comparison appears on the confirming person’s review screen. If the values of that item change after the screen was opened, the pass is refused (“This item changed after you opened it”) and the person must review the new values and pass again.

Step 6: Order mail and ERP record

When a person sets the selection on the portal’s review screen and passes it (or edits and passes it when a value needs fixing), that pass is recorded as the approval, and the employee sends the order mail using it. The server re-reads the approved lines right before sending. After a person checks the order once more and passes it, the employee registers the order in the ERP with that approval. The first record is read back and the stored values are shown to you. The ERP document number and registration date go into the order table from the read-back values. There is one order per need.

If something changed after approval

If the vendor, quantity, price, currency, delivery or validity changed after approval, or the quote’s validity ran out (the validity date is before today; a blank validity is not treated as expired), or a line disappeared, nothing is sent. Neither the order mail nor the ERP record goes out. The employee tells you what changed or expired and asks for a fresh approval. It never retries with the old approval and never sends without one.

If the ERP answers with an unknown outcome, the employee stops, reads the record to see whether it actually landed, and then settles it or hands it to a person. The employee reuses the same registration key for the same order so one order is not posted twice.

Saving it as a repeatable workflow

Once you have run it end to end, ask the employee to “save this so it can be repeated.” It drafts a 6-step workflow (register the need, send quote requests, collect replies, compare and select, send the order mail, record in the ERP) and asks you to approve the settings such as who confirms and freezing, one card at a time. For the general flow see Save your first task as a workflow and Workflows.

The selection step and the order check before the ERP write are always confirmed by a person. A check looks at what a step produced before the next step starts, so the check before the ERP write sits on the order step. Lowering that to spot checks is not recommended.
The employee asks which role confirms before sending the card. It does not invent a role your business does not have.
In the workflow form, the need number is typed, not picked from a list.
Comparison and selection work only in a workflow published to the portal. Publishing needs the work portal to be set up and an organization owner to do it. In a personal space or a space without a portal, the workflow is saved only, and selection is recorded by opening the record in the quote table on the Data screen and using Edit on the selection field (members who can edit data can do this, and a person can edit a field that is protected from the employee). In that case there is no pass on the portal review screen to record, so the “only when it matches what was approved” check does not apply.
Before freezing, the employee checks that the quote reading skill writes a line key on every row. If that skill changes later, freeze again.
Freezing is best done after a person has watched one full run.

Limits and cautions

No currency conversion. Amounts in different currencies are not converted to a common basis.
The need number is typed (see above).
Publishing to the portal needs an organization owner.
If the comparison settings or the approval-check settings are wrong (for example a misspelled field name), the comparison or the check can be missing. After publishing, check on the first real run that the comparison screen appears.
If a vendor’s mail address is wrong, tell the employee. It remembers the correction for next time.
Each successfully sent mail costs SU and counts toward a daily sending limit. A batch larger than what is left of today’s limit is refused at the preparation step.

Next steps

Partner Order Intake → ERP: preparing the eCount connection and how ERP integration works
Approvals: when approval cards appear
Data: viewing and editing tables
Workflows: saved workflows and publishing

Advanced

You do not need this for everyday use. Read it only if you adjust the tables yourself, or if the comparison or approval check does not behave as you expect.

The five tables and their record keys

Table	One row means	Record key
Need	One part need	Need number
Vendor	One vendor	Vendor code
Quote request	One request from one need to one vendor (the number is the need number joined with the vendor code)	Request number
Quote	One quote line	Request, vendor, quote number, revision, line key
Purchase order	One order per need	Need number

Without the quote’s line key, a quote with more than one line (for example price breaks by quantity) overwrites itself or is rejected as a duplicate. The quote reading skill fills the line key on every row.
The vendor table’s internal quality score and quality note, and the quote table’s selection field, are protected. People write them and the employee only reads.
A quote line’s revision is text, and “0” when none is printed.
These tables are not created straight from the preset. They are created through approval cards. The bundle is only a starting point and the record key is not inherited, so check that a new organization’s quote table did not lose the line key.

What the selection step carries

The selection step of a saved workflow carries two settings next to the confirming person (the gate).

Comparison setting: takes the quote table’s unit price as the value, groups by need number and currency, and shows vendor, delivery date and quality score as extra columns. It judges lowest and highest only within the same need and the same currency, and never converts. It shows the delivery date instead of the number of days.
Approval check setting: names the fields that must not change after approval (vendor, quantity, unit, unit price, currency, minimum order, amount, lead time, delivery date, validity) and the expiry field (validity). Status, selection, notes and quality score are left out so later steps can update status without breaking the check.
If a name does not match the table definition, the approval snapshot may not be created and the next step then runs without a check. After publishing, confirm on the first run that the comparison table shows and that the next step’s input carries the approval information.

Tying a send to the approval (`--approval-binding-id`)

When the selection is approved, the employee is given one approval id. The order mail goes out with a single send --approval-binding-id <id>, or prepare_batch --approval-binding-id <id> for several recipients. The ERP write puts the id from the order check in erp_write.approval_binding_id (the selection id covers the quote line, the order check id covers the order line). One id per call. Right before sending, the server re-reads the approved lines and refuses with APPROVAL_BINDING_* if they changed, expired or vanished. Nothing goes out, and the response names which attributes differ (names only).

Reply-wait states

On a quote request row, the progress (not sent, requested, replied, closed) and the reply result (quote ready, inquiry or needs completion, declined, no response) are recorded separately. The employee writes the reply result and the mail wait state in the same turn.

Reply result	Wait state	When
Quote ready	READY	Quote lines are in and linked, a matched reply is required
Inquiry, needs completion	NOT_READY	A matched reply is required
Declined, no response	CLOSED	Can be closed without a reply

The deadline is set between 10 minutes and 60 days ahead, with up to 3 reminder times. After the deadline passes, that batch and its reminders can no longer be sent, and a new batch with a new deadline is needed.