AIMS360 Fashion & Consumer ERP

CREATES a new customer (account) in AIMS360. This WRITES, and AIMS360 offers no delete, so a customer created by mistake has to be dealt with by hand. TWO STEPS, ALWAYS. Call it first WITHOUT confirmToken: nothing is written, and it returns the exact record it would create plus a confirmToken. Show that to the user. Only call it again — same values, plus the token — once they have agreed. customerAccount (EXACTLY 5 letters/digits, supplied by the user — never invent one) and customerName are required; status defaults to Active and currency to USD, both disclosed in the preview. Every other documented field can be set: address, contacts, phone and email, terms, ship via, division, sales reps and their commission, credit limit, classification, warehouse, tax, discounts and the shipping flags. Codes, names and GUIDs all resolve against your own tenant; an ambiguous one comes back as a question listing the real options. Anything nobody mentions is left unset and takes AIMS360's own defaults. If the account code is already in use it refuses and shows you the existing customer; choose another code. A similar customer NAME is reported as a warning only and does not block. Use get_customer_details to check an account before creating, and to verify it afterwards.

create_customer

CREATES a sales order in AIMS360 — header, lines and sizes in one go. This WRITES. AIMS360 offers no delete for orders, so one created by mistake has to be dealt with by hand. TWO STEPS, ALWAYS. Call it first WITHOUT confirmToken: nothing is written, and it returns the exact order it would create — every resolved code, every line, the unit and dollar totals — plus a confirmToken. Show that to the user. Only call it again, same values plus the token, once they have agreed. SEND ONLY WHAT THE USER SAID. Needs just customerAccount, season, and at least one line (style, colour, sizes and quantities). Everything else — price, completed date, ship start date, terms, ship via, sales rep, warehouse, division — is optional: AIMS360 fills it from the customer's record or the company's own settings. Never invent a value to fill a field. When a required value is missing it asks with your tenant's REAL options as a NUMBERED LIST — the seasons on file, the divisions on file, that customer's stores, that style's colourways. Present those options to the user as they are given, so they can pick one rather than retype a code. The preview flags rather than blocks: an unpriced line, an InActive customer or style, and a credit limit and balance. The user decides. A customer whose record REQUIRES a PO number is different: AIMS360 refuses that order without one, so the tool asks for the PO first. Sizes are checked against the style's scale and a colour is matched against that style's own colourways, so an ambiguous colour comes back as a question listing the real options. Left alone, AIMS360 creates the order on HOLD. Pass status "Open" only if the user asks for it. NOT supported here: credit cards, prepayments, discounts, bulk and distribution orders. Card details are never accepted by this tool.

create_order

Aggregate / rank / trend / total Customers (read-only). Requires dimensionKey + metricKey. Customers = the CUSTOMER MASTER: who the account is and how it is set up to trade — the shops and businesses that buy from us, one row per account. Use for "how many active customers do we have", "customers by classification / state / sales rep", "which accounts are on NET 30", "who ships freight collect", "look up the account record for SAKF1", "which customers have a credit limit". NOT for anything they BOUGHT: sales, revenue, units, orders, invoices and rankings of customers by any of those are order_analysis or invoice_analysis, which group BY customer. "Top customers by sales / revenue / units / orders" is never this domain; "top customers by balance owed" or "by credit limit" is. IT IS A SNAPSHOT, NOT A LEDGER: a customer record is what is true about the account right now, so there is no time axis and no date bound is required. customerAddedDate is the only business date and it is unusable in this client's data — about 78% of accounts hold a placeholder instead of a real date — so answer "when did we take this account on" with care, and say so. MEASURES ARE LIMITED ON PURPOSE: how many accounts, the sum of their credit limits, and accounts receivable. Everything else on the record is a setting, not a quantity — the percentage columns are rates that cannot be summed, and the three tax columns are zero on every account. ACCOUNTS RECEIVABLE comes straight from the customer record. Use metricKey 'total_ar' for balances owed, who owes us, and aging: every A/R answer returns the whole balance (totalAR) with its aging, currentAR (not yet due), age30 (1–30 days past due), age60 (31–60), age90 (61–90) and age120 (over 90), counted from the invoice due date. A positive balance means the customer owes us; a negative one means we owe them. These figures are read live, never from a cache. TWO TRAPS WORTH KNOWING: `status` is the ACCOUNT's standing (Active / InActive / NoShip), not an order status; and `orderStatus` is a TEMPLATE — the status NEW orders for that account open with — not a statement that anything is currently on hold. TOP-N: "top 10 <dimension> by <metric>" → grouped_summary + that dimensionKey + limit (one row per dimension value). BOTTOM-N ("slowest", "lowest", "fewest", "bottom 5") is the same call with sort='lowest'. There are no line items in Customers: never line_items here. For a specific record, use get_customer_details. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD. The server resolves dimension/metric synonyms automatically. SUPPORTED DIMENSIONS: customer=Customer, customer_status=Customer Status, classification=Classification, sales_rep=Sales Rep, customer_state=Customer State, country=Country, term=Payment Term, ship_via=Carrier, division=Division, preferred_warehouse=Preferred Warehouse, priority=Priority, currency=Currency, customer_city=Customer City, market_region=Market Region, discount_reason=Discount Reason, line_item_discount_type=Discount Type SUPPORTED METRICS: customer_count=Customers, total_ar=Total AR (Balance Owed), current_ar=Not Yet Due, past_due_1_30=1–30 Days Past Due, past_due_31_60=31–60 Days Past Due, past_due_61_90=61–90 Days Past Due, past_due_90_plus=90+ Days Past Due, credit_limit=Credit Limit SUPPORTED BASE PATTERNS: (none)

customer_analysis

Who this connection is signed in to AIMS360 as: the account code, company name, database, the user's login name, first and last name, role and zone. Use for: "which company am I connected to", "who am I logged in as", "what is my AIMS360 account", "what role do I have". Takes no input. The access token, its type and its expiry date are never returned.

get_connection_details

Fetch Customers RECORDS (read-only): one specific customer by customer account code, or a filtered list where each row IS a customer. Use for: "show customer 12345", "customers on NET 30 terms", "accounts that ship freight collect". Add selectFields/filters/sortSpec as needed — the server resolves field synonyms (e.g. "account status" → status) automatically; on a miss it suggests the right name. Looking up a specific customer by customer account code is a single_record call with ONLY filters.customerAccount. A dateRange is not applied to such a lookup (the answer says so) — the record's own date answers any date question. For totals, rankings, breakdowns, trends, or per-style/size aggregation, use customer_analysis instead. queryKind: single_record (requires filters.customerAccount) or raw_list. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD.

get_customer_details

Fetch Invoices RECORDS (read-only): one specific invoice by invoice number, or a filtered list where each row IS an invoice. Use for: "show invoice 12345", "invoices for customer ABC01 last month", "invoices due next week". Add selectFields/filters/sortSpec as needed — the server resolves field synonyms (e.g. "customer account" → customerAccount) automatically; on a miss it suggests the right name. LINE-ITEM detail of a specific invoice: single_record + expand (lineItems for orders, invoiceLines for invoices) — one row per line item, in ONE call; don't retry with different expands. (Orders return per-line rows; for a per-SIZE breakdown use invoice_analysis with a size dimension.) Looking up a specific invoice by invoice number is a single_record call with ONLY filters.orderNumber. A dateRange is not applied to such a lookup (the answer says so) — the record's own date answers any date question. For totals, rankings, breakdowns, trends, or per-style/size aggregation, use invoice_analysis instead. queryKind: single_record (requires filters.orderNumber) or raw_list. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD.

get_invoice_details

Fetch Orders RECORDS (read-only): one specific order by order number, or a filtered list where each row IS an order. Use for: "show order 12345", "list open orders", "orders on hold last month". Add selectFields/filters/sortSpec as needed — the server resolves field synonyms (e.g. "hold reason" → orderStatusReasonDescription) automatically; on a miss it suggests the right name. LINE-ITEM detail of a specific order: single_record + expand (lineItems for orders, invoiceLines for invoices) — one row per line item, in ONE call; don't retry with different expands. (Orders return per-line rows; for a per-SIZE breakdown use order_analysis with a size dimension.) Looking up a specific order by order number is a single_record call with ONLY filters.orderNumber. A dateRange is not applied to such a lookup (the answer says so) — the record's own date answers any date question. For totals, rankings, breakdowns, trends, or per-style/size aggregation, use order_analysis instead. queryKind: single_record (requires filters.orderNumber) or raw_list. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD.

get_order_details

Fetch Purchase Orders RECORDS (read-only): one specific purchase order by purchase order number, or a filtered list where each row IS a purchase order. Use for: "show purchase order 12345", "purchase orders issued to vendor ACME this month", "purchase orders landing in November". Add selectFields/filters/sortSpec as needed — the server resolves field synonyms (e.g. "receiving warehouse" → warehouseCode) automatically; on a miss it suggests the right name. Looking up a specific purchase_order by purchase order number is a single_record call with ONLY filters.orderNumber. A dateRange is not applied to such a lookup (the answer says so) — the record's own date answers any date question. For totals, rankings, breakdowns, trends, or per-style/size aggregation, use purchase_order_analysis instead. queryKind: single_record (requires filters.orderNumber) or raw_list. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD.

get_purchase_order_details

Aggregate / rank / trend / total Inventory (read-only). Requires dimensionKey + metricKey. Inventory = STOCK AS IT STANDS RIGHT NOW, by warehouse / bin / style / color / size — a point-in-time snapshot, never a period of activity. Use for "what do we have", "available to sell", "stock by warehouse", "which bins hold style X", "how much is allocated / picked / packed". NOT for anything that HAPPENED over a period: booked / ordered / open-order units and allocation against orders → order_analysis; sold / shipped / revenue / margin / units shipped → invoice_analysis. NO TIME FRAME APPLIES: the only date column, lastCountedOn, is a cycle-count audit stamp that is null on ~99.9% of rows, so it does not bound a stock question. METRICS: available_units (openStockQuantity) = what can actually be promised = on-hand less picked, in-transfer and allocated; on_hand_units (stockQuantity) = the physical figure before those reservations; packed_units is a SUBSET of picked_units, so never add the two together; transfer_out_units is stock reserved to move OUT to another warehouse and is still inside on-hand — it is not inbound in-transit stock. EVERYTHING IS INCLUDED, NOTHING FILTERED: every warehouse, bin and size counts whatever its status, and uncounted bins count too. When part of a figure sits in an inactive warehouse, bin or size, that split is part of the figure ("1,204 units; 87 in 2 inactive bins"), in each warehouse breakdown as well. STOCK VS DEMAND is not available here: there is no join between inventory and orders/invoices. For ONE order or ONE style it is legitimate to answer in two calls — read the order or the style's demand first, then this tool filtered to those styles — stating that the two figures come from different queries. A BULK question ("which of our open orders can we fill") cannot be answered with this tool: previewRows is a sample, never a basis for a coverage answer. TOP-N: "top 10 <dimension> by <metric>" → grouped_summary + that dimensionKey + limit (one row per dimension value). BOTTOM-N ("slowest", "lowest", "fewest", "bottom 5") is the same call with sort='lowest'. There are no line items in Inventory: never line_items here. To list individual records, use search_inventory. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD. The server resolves dimension/metric synonyms automatically. SUPPORTED DIMENSIONS: warehouse=Warehouse, bin=Bin Location, bin_category=Bin Category, style=Style, color=Color, style_color=Style + Color, size=Size, sku=SKU (Style + Color + Size), warehouse_status=Warehouse Status, size_status=Size Status SUPPORTED METRICS: available_units=Available Units, on_hand_units=On-Hand Units, allocated_units=Allocated Units, picked_units=Picked Units, packed_units=Packed Units, transfer_out_units=Outbound Transfer Units, bin_records=Bin Records SUPPORTED BASE PATTERNS: (none)

inventory_analysis

Aggregate / rank / trend / total Invoices (read-only). Requires dimensionKey + metricKey. Invoices = SALES / SOLD / REVENUE (shipped & invoiced), units shipped, margin. Use for "total sales", "top sold styles", "revenue by month", "margin by customer". TOP-N: "top customers by $" → grouped_summary + dimensionKey=customer (one row per customer); "top styles/sizes by units" → line_items + dimensionKey=style/size. Pick queryKind by what the user wants ONE ROW PER, not the word "top". BOTTOM-N ("slowest", "lowest", "fewest", "bottom 5") is the same call with sort='lowest'. "by month / quarter / year" → grouped_summary + a date dimension + timeGrain. For a specific record, use get_invoice_details. Line-item-only metrics (ship_quantity, back_order_quantity) MUST use line_items. Always pass the user's wording in userQuery and clientDate as YYYY-MM-DD. The server resolves dimension/metric synonyms automatically. SUPPORTED DIMENSIONS: customer=Customer, invoice_status=Invoice Status, order_source=Order Source, retail_invoice=Retail / DTC, shopify_store=Shopify Store, division=Division, season=Season, sales_rep=Sales Rep, bill_to_state=Bill-to State, ship_to_state=Ship-to State, term=Payment Term, ship_via=Carrier, invoice_date=Invoice Date, due_date=Due Date, style=Style, color=Color, style_color=Style + Color, size=Size, style_size=Style + Size, style_color_size=Style + Color + Size SUPPORTED METRICS: total_amount=Total Amount, merchandise=Merchandise, balance=Balance, invoice_count=Invoice Count, ship_quantity=Units Shipped, back_order_quantity=Units Back-Ordered, margin_pct=Margin %, aur=Avg Unit Retail, net_sales=Net Sales, gross_margin=Gross Margin SUPPORTED BASE PATTERNS: overdue=Overdue invoices — Open invoices where dueDate has passed, outstanding_balance=Outstanding balance — Open invoices with a remaining balance

invoice_analysis