List the companies (datasets) this server can reach on its EBMS serial number, with name, ID, version and whether writes are allowed. Needs no credentials. Call it when the user names a company you haven't seen, or before the first write of a session, so the company is confirmed by name. Nothing marks a company as live or a test copy; ask if unsure.

Read from EBMS OData: a collection (path 'ARINV') or one record (path "ARINV('')"). Always pass select — an unselected read returns every field, many computed, and large ones hit the 2-minute limit. For a collection, count is on by default and the result says whether rows were truncated. Query syntax and the install's quirks are in the ebms-api skill.

Write to EBMS: POST creates a record (documents take their lines nested as Details), PATCH updates one by quoted AUTOID (lines via a Details@delta array), DELETE removes one. Refused for a company that is not configured (or not the sandbox, while testing), and refused if the body carries PROCESS anywhere or a POST's EXTERNALID already exists. A 2xx is not proof — EBMS silently ignores unknown @ids and unwritable fields — so the server reads back the fields you sent and returns a verification: ok, mismatches (sent vs stored), problems (a row that never appeared or was not removed), notes (rows EBMS added itself) and the stored rows. Treat ok:false as a partly failed write and tell the user. If the result says uncertain, read back before resending — a resent create or add duplicates.

Run a bound action on one record: POST /ENTITY('')/Model.Entities.. Omit body for a command with no dialog (MarkAllAsShipped, RecalculateAllPrices) — EBMS rejects even {}. Pass the dialog's fields for one that has a dialog (ChangeCustomer). Refused for a company that is not configured (or not the sandbox, while testing), and for any action that is not on the server's short allow-list — nothing that posts, processes, pays or sends. Commands return little; read the record back afterwards.

Material requirements plan for one company, read-only: nets open sales and job demand, open manufacturing batches and open purchase orders against stock, day by day, through the bill of materials, and returns what to buy and make, by when, and why. ALWAYS ask the user two things first and never assume either: the time frame (through, or days) — 'buy and make what is needed to cover everything due by this date' — and the scope: everything, particular vendors, or particular products. EBMS does not publish vendor lead times, so orders carry a needed-by date; pass leadTimeDays only if the user gives one. Only stocked products and stocked lines are planned; drop-ship, associated and sync lines belong to their own orders. The planner's worksheet comes back attached as CSV: give it to the user as a file in the conversation, unchanged.

The total view of one finished good, read-only: everything needed to build a quantity of it, down every level of its bill of materials, against what is available (on hand + incoming − on order). Stock of a sub-assembly covers its branch before anything is exploded further, and a part used in two branches is only counted once. Returns an indented tree, what to make, what to buy, and canBuildWithoutBuying: true when every purchased part is available, even if sub-assemblies still have to be made from them.

Turn an approved MRP worksheet into purchase-order drafts, read-only. Reads the CSV mrp_plan produced, after the planner set Approve to Y on BUY rows (and perhaps changed Order Qty or Vendor); checks every vendor and product against EBMS; and returns one draft per vendor with the exact body to POST to APINV with ebms_write. It creates nothing. A worksheet handed in twice cannot order twice: ebms_write refuses the duplicate EXTERNALID. Show the drafts and get a clear yes per purchase order before writing.

Turn approved MAKE rows of an MRP worksheet into manufacturing-batch drafts, read-only. For each it checks EBMS will accept the product as a finished good (it must be classified Track Count), lists every component from the bill of materials with its quantity per one finished good (EBMS does NOT add consumed materials itself when a batch arrives through the API), picks the warehouse (the one given, else where the product was last made), and returns the exact body to POST to INMFG with ebms_write. It creates nothing. Drafts mark nothing as made or consumed and never carry PROCESS: finishing and processing a batch is done by a person in EBMS. Show each draft and get a clear yes before writing it.

The procedures for working with EBMS through this server: how to build and change sales orders and purchase orders, receive stock, manage products and tasks, and run MRP. Call it before any task beyond a single read, unless the matching skill is already loaded in this app. With no arguments it lists the skills; with skill it returns that skill; with file it returns one of the skill's reference files. Read-only.