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. For more than a few hundred rows use ebms_export instead: without top only 200 rows are shown, and never more than about 150 KB. 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, a POST's EXTERNALID already exists (orders, POs, batches, tasks, customers, vendors, products, workers), or a vendor (APVENDOR) POST has no ID. 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; a create resent by EXTERNALID is refused until a read finds it or confirms it is absent.

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.

Read a whole EBMS collection to a file (CSV, Excel or JSONL) instead of into the conversation, for anything more than a few hundred rows: sales history, every product, all open lines. The server pages through it itself and returns only the file's path, the row count, the columns, five sample rows and min/max/sum of each numeric column — never the rows. Analyse the file with a script (pandas, duckdb) and read back only the aggregates; never write a script that calls EBMS. Count first with ebms_get (top 1). Select only the fields you need. Read-only.

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. Lead times come from EBMS: the product's vendor record (INVENDOR.LEAD_DAYS), else the vendor's (APVENDOR.LEAD_DAYS); 0 means not set. A purchase with a lead time gets an order-by date; one without carries only its needed-by date. Pass leadTimes or leadTimeDays only for figures the user gives. Only stocked products and stocked lines are planned; drop-ship, associated and sync lines belong to their own orders. The planner's worksheet is an Excel workbook saved on this computer (worksheet.savedAt): give the user that path; they approve rows in it. A CSV copy of its rows is attached for reading only.

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 worksheet mrp_plan produced (its Excel workbook, or a CSV), after the planner approved BUY rows on its To order tab (and perhaps changed 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.

Review a CSV or Excel (.xlsx) file of records for one EBMS entity — products, units, vendor records, bills of materials, customers, vendors, workers, folders, tax rates or other configuration — and draft the writes, read-only. Maps each column to a field (from EBMS's live metadata), checks every row (blanks, types, lengths, duplicates, folders, vendors, products and units that do not exist), skips rows already in EBMS or already created by an earlier run of the same import, writes an exceptions workbook holding only the rows that need fixing, and returns the exact ebms_write call for each remaining row. It writes nothing to EBMS. Follow the ebms-import skill: show the mapping, problems and a few drafts, get one clear yes for the file, then call ebms_write for each draft in order. Run it again on the same file (or the corrected exceptions file) to continue: what was created is skipped.

The procedures for working with EBMS through this server: how to build and change sales orders and purchase orders, receive stock, manage products, customers, vendors and tasks, run MRP, import files and set up a new company. 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.