Tools and Actions

Tools and Actions

Overview

iVendNext Copilot's ability to act — not just answer — comes from a library of 40+ pre-built tools. Each tool is a named function that maps directly to a specific iVendNext operation. When you ask Copilot to do something, it identifies which tool applies, assembles the required inputs from your message and context, calls the tool, and returns the result.


This article explains how tools are organised, what they can do, how Copilot resolves ambiguous names, and what Natural Language SQL adds beyond the tool library.




How Tools Are Organised

The tool library is grouped by functional domain, mirroring iVendNext's module structure:


  • Stock — check bin quantities, review stock ledger entries, look up item details, query movement history

  • Sales — retrieve customer records, look up Sales Orders and invoices, check outstanding balances

  • Purchasing — retrieve supplier records, look up Purchase Orders and receipts

  • CRM — access lead and opportunity records, retrieve contact information

  • Accounting — query GL entries, check account balances, retrieve journal entries and payment records

  • Core CRUD — create, read, update, and delete operations on standard DocTypes across iVendNext



Info
Each tool accepts a defined set of inputs. Copilot's job is to extract those inputs from what you write and pass them correctly to the tool. You do not write code or fill in forms — you describe what you want, and Copilot maps that description to the tool parameters.




What a Tool Call Looks Like

When you send a message, Copilot runs through several steps before returning a response:


  1. It reads your message together with the injected live context (company, top customers, key items, overdue alerts).

  2. It selects the most appropriate tool from the library.

  3. It resolves any names or references in your message to actual iVendNext records (see Fuzzy Matching below).

  4. It checks that the resolved tool call is within your iVendNext permissions.

  5. It executes the tool and formats the result as a readable response.



Info
Every step is logged. The audit trail records the tool selected, the inputs assembled, the output returned, the execution status, and the time taken. This log is always available for review.




Fuzzy Item and Customer Matching

One of the practical challenges with natural language interfaces is name resolution: you might type "Nescafe" but the item master says "Nescafé Gold 200g Jar". Copilot uses a multi-stage fuzzy matching process to find the right record.


The matching stages run in sequence:


  1. Exact match — looks for a record where the name, code, or ID matches precisely

  2. Partial match — looks for records where the input appears as a substring

  3. Word-by-word match — splits the input into words and searches for records matching any combination



Info
If a single confident match is found, Copilot proceeds. If multiple plausible matches are found, it surfaces them and asks you to confirm which one you meant before executing. This prevents silent mis-matches where the wrong customer or item is used in an action.


Fuzzy matching applies to both item lookups and customer lookups. It does not apply to DocType names or field values — those are resolved against the whitelist exactly.




Natural Language SQL

Beyond the pre-built tool library, Copilot can handle questions that require retrieving data from multiple tables in ways that no single tool covers. This is done through Natural Language SQL — Copilot constructs a SQL query from your plain-language question and executes it against your iVendNext database.


Examples of what this enables:


  • "Which customers have outstanding invoices older than 60 days?" — requires joining Sales Invoice with customer data and filtering by due date

  • "What are the top 10 items by sales value this month?" — requires aggregating Sales Invoice Item lines, grouping by item, and ordering by sum

  • "Show me all Purchase Orders raised in the last 30 days for supplier X" — requires filtering by date range and supplier across the Purchase Order table



Notes
Copilot generates the SQL, executes it, and returns the result in a readable format. You do not see the SQL unless you ask for it.


Important constraints on Natural Language SQL:


  • It reads data only. It cannot modify records via a SQL query.

  • It operates within the same field whitelist as the tool library. Fields that are not whitelisted for a DocType cannot be queried, even via SQL.

  • Blocked DocTypes (User, Role, System Settings) cannot be queried.

  • The query is constructed and executed in real time against your live database — results reflect the current state of your data at the moment you ask.




Creating Draft Documents

Several tools in the library create iVendNext documents — Sales Orders, Purchase Orders, and similar transactional records. When Copilot creates a document, it always creates it as a draft. The document is never submitted or posted automatically.


The intended workflow is:


  1. You ask Copilot to create a document (for example, "Create a Sales Order for customer ABC for 10 units of item XYZ")

  2. Copilot assembles the document from the resolved inputs and creates the draft

  3. You navigate to the draft, review it, make any adjustments, and submit it yourself


This keeps human review in the loop for every transactional action. Copilot handles the assembly; your team handles the authorisation.




What Tools Cannot Do

The tool library is broad but has deliberate limits:


  • No access to User, Role, or System Settings DocTypes. These are blocked entirely — Copilot cannot read, create, or modify system configuration or access control records.

  • No access to blocked fields. Password fields, API key fields, and other sensitive columns are excluded from every tool regardless of DocType.

  • No actions outside your permissions. Every tool call is checked against your iVendNext role before execution. If your account cannot perform an action in the normal iVendNext interface, Copilot cannot perform it either.

  • No background or scheduled actions. Tools execute in response to what you ask, in the current conversation. There is no way to schedule a tool to run later or trigger tools automatically.




    • Related Articles

    • Post-Submission Actions: Purchase Receipts, Invoices, and Payments

      Overview This article outlines the key post-submission actions in iVendNext, including how to create Purchase Receipts, generate Purchase Invoices, and manage Payment Entries. 1. Understanding Post-Submission Actions 1.1 Purchase Receipts A Purchase ...
    • Comparing Auto Lookup Profiles with Other POS Interface Tools

      Overview This article gives you an overview of using iVendNext’s Auto Lookup Profiles to streamline data retrieval during checkout. It compares this feature with other POS tools and offers use cases and setup tips to help you choose the best option ...
    • Working with Client Scripts for Enhanced UI

      Overview Client Scripts in iVendNext allow users to customize and extend the functionality of forms dynamically. These JavaScript-based snippets enable real-time modifications—such as hiding buttons, validating fields, or triggering actions—without ...
    • Adding and Customizing Buttons in Forms

      Overview Buttons in iVendNext forms provide quick access to actions like submissions, approvals, or navigation. With Client Scripts, users can customize these buttons—adding new ones, renaming existing options, or hiding irrelevant actions—to better ...
    • Budgeting

      Overview Budgeting in iVendNext helps control costs, allocate resources, and support financial stability. You can set budgets by Cost Center, Project, or custom dimensions. Whether planning yearly or monthly, these tools help prevent overspending and ...