Skip to main content
Glama
PNPC-MCP-Tally-Prime

PNPC-MCP-Tally-Prime

create_sales_invoice

Creates an item-invoice Sales voucher in TallyPrime with stock item lines, quantities, rates, and per-line sales ledgers. Supports optional VAT and buyer details for real invoice posting.

Instructions

Create an item-invoice Sales voucher in TallyPrime — a real invoice with stock item lines (quantity, rate), each posted to its own Sales ledger, plus one optional VAT/tax line on the total. Distinct from create_voucher, which only supports plain ledger-to-ledger entries with no stock items. WARNING (confirmed live): if the same party ledger or stock item is used in BOTH a Sales and a Purchase item-invoice, it can become undeletable via the API afterward (returns 'Cannot be deleted!' even with zero balance) — using it in only one of the two is fine and stays deletable. If it does happen, running Company Data → Rewrite in Tally itself clears it (confirmed live) — this is not a permanent lock.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "date": "<date>",
      "partyLedger": "<partyLedger>",
      "items": "<items>"
    },
    "name": "create_sales_invoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
dateYesInvoice date in DD-MM-YYYY format
itemsYesOne entry per invoice line.
billNameNoBill reference name for bill-wise tracking (requires the party ledger's maintainBillWise to be on). Omit if not using bill-wise tracking.
billTypeNoDefaults to 'New Ref'.
buyerTrnNoThe buyer's Tax Registration Number as it should appear on THIS invoice — a per-voucher snapshot (Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields), separate from and not inherited from the party ledger's own trn (create_ledger). Reverse-engineered from a real Tax Invoice export: leaving this unset is exactly what leaves the invoice's Party Details showing a blank TRN even when the party ledger has one set — always pass this explicitly for a UAE VAT tax invoice.
buyerNameNoName to print in this voucher's Buyer (Bill to) box, when it should differ from the customer ledger's own name — Tally's per-voucher Party Details mailing name. The ledger itself is not changed. Useful when many sales are posted against one shared ledger (e.g. cash or card sales) but each invoice needs its own readable buyer name.
narrationNoNarration / description for the invoice
referenceNoFree-text reference for this invoice (Tally's voucher-level REFERENCE field), e.g. a purchase order or bill number the customer quoted.
vatLedgerNoDefault VAT/tax ledger applied to any item that doesn't set its own vatLedger (optional — omit for a fully non-taxable invoice).
buyerStateNoThe buyer's Emirate/state as it should appear on THIS invoice's Party Details (voucher-level STATENAME) — not inherited from the party ledger master. Match the company's existing convention (check get_company_info or an existing invoice).
partyLedgerYesCustomer ledger name (the party being invoiced)
voucherTypeNoVoucher type to post as, for a company that uses its own Sales-class type in Item Invoice mode (e.g. 'Tax Invoice', 'Export Invoice'). Defaults to 'Sales'.
buyerCountryNoThe buyer's country as it should appear on THIS invoice's Party Details (voucher-level COUNTRYOFRESIDENCE). Plain free text, e.g. 'UAE'.
referenceDateNoDate for the reference above, in DD-MM-YYYY format. Independent of the invoice's own date.
voucherNumberNoExplicit voucher number. Normally omit this and let Tally auto-number — but some Tally configurations (confirmed live: after a Company Data → Rewrite in at least one case) stop auto-numbering item-invoice vouchers via the XML gateway and fail with a blank EXCEPTIONS:1/no error text unless a number is given explicitly. If a create call fails with no error text, check get_vouchers for the highest existing number of this voucher type and retry with voucherNumber set to the next one.
vatRatePercentNoDefault VAT rate as a percentage, e.g. 5. Required if vatLedger is set. Items with mixed rates can override this per-line.
placeOfSupplyCountryNoUAE VAT Place of Supply Country (Tally's PLACEOFSUPPLYCOUNTRY field), e.g. 'UAE'.
placeOfSupplyEmirateNoUAE VAT Place of Supply Emirate for this invoice (Tally's EMIRATEPOS field) — for a standard domestic B2B supply of services this is normally the SUPPLIER's own Emirate (check get_company_info), not the buyer's. Required for a compliant UAE tax invoice; omitting it is what left this blank on a real invoice this was reverse-engineered from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.1
    • addedInput schema / properties / buyerName
      Added value: +{
      +  "description": "Name to print in this voucher's Buyer (Bill to) box, when it should differ from the customer ledger's own name — Tally's per-voucher Party Details mailing name. The ledger itself is not changed. Useful when many sales are posted against one shared ledger (e.g. cash or card sales) but each invoice needs its own readable buyer name.",
      +  "type": "string"
      +}
  2. Changed2 schema fields changedv1.14.0
    • addedInput schema / properties / items / items / properties / description
      Added value: +{
      +  "description": "Description lines shown under this stock line on the invoice, one array entry per line (e.g. a size, colour or service period). Optional.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / voucherType
      Added value: +{
      +  "description": "Voucher type to post as, for a company that uses its own Sales-class type in Item Invoice mode (e.g. 'Tax Invoice', 'Export Invoice'). Defaults to 'Sales'.",
      +  "type": "string"
      +}
  3. Changed14 schema fields changedv1.11.2
    • addedInput schema / properties / buyerCountry
      Added value: +{
      +  "description": "The buyer's country as it should appear on THIS invoice's Party Details (voucher-level COUNTRYOFRESIDENCE). Plain free text, e.g. 'UAE'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerState
      Added value: +{
      +  "description": "The buyer's Emirate/state as it should appear on THIS invoice's Party Details (voucher-level STATENAME) — not inherited from the party ledger master. Match the company's existing convention (check get_company_info or an existing invoice).",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerTrn
      Added value: +{
      +  "description": "The buyer's Tax Registration Number as it should appear on THIS invoice — a per-voucher snapshot (Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields), separate from and not inherited from the party ledger's own trn (create_ledger). Reverse-engineered from a real Tax Invoice export: leaving this unset is exactly what leaves the invoice's Party Details showing a blank TRN even when the party ledger has one set — always pass this explicitly for a UAE VAT tax invoice.",
      +  "type": "string"
      +}
    • addedInput schema / properties / items / items / properties / batchName
      Added value: +{
      +  "description": "Real batch/lot number for this line, if the item has batch tracking. Defaults to 'Primary Batch'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / items / items / properties / discountPercent
      Added value: +{
      +  "description": "Discount percentage applied to this line's amount (e.g. 10 for 10% off). Optional.",
      +  "type": "number"
      +}
    • addedInput schema / properties / items / items / properties / vatLedger
      Added value: +{
      +  "description": "Per-item VAT ledger override, if this line has a different tax rate than the invoice default. Requires vatRatePercent.",
      +  "type": "string"
      +}
    • addedInput schema / properties / items / items / properties / vatRatePercent
      Added value: +{
      +  "description": "Per-item VAT rate override, e.g. 5. Required if this item's vatLedger is set.",
      +  "type": "number"
      +}
    • addedInput schema / properties / placeOfSupplyCountry
      Added value: +{
      +  "description": "UAE VAT Place of Supply Country (Tally's PLACEOFSUPPLYCOUNTRY field), e.g. 'UAE'.",
      +  "type": "string"
      +}
    • addedInput schema / properties / placeOfSupplyEmirate
      Added value: +{
      +  "description": "UAE VAT Place of Supply Emirate for this invoice (Tally's EMIRATEPOS field) — for a standard domestic B2B supply of services this is normally the SUPPLIER's own Emirate (check get_company_info), not the buyer's. Required for a compliant UAE tax invoice; omitting it is what left this blank on a real invoice this was reverse-engineered from.",
      +  "type": "string"
      +}
    • addedInput schema / properties / reference
      Added value: +{
      +  "description": "Free-text reference for this invoice (Tally's voucher-level REFERENCE field), e.g. a purchase order or bill number the customer quoted.",
      +  "type": "string"
      +}
    • addedInput schema / properties / referenceDate
      Added value: +{
      +  "description": "Date for the reference above, in DD-MM-YYYY format. Independent of the invoice's own date.",
      +  "type": "string"
      +}
    • changedInput schema / properties / vatLedger / description
      Previous value: -"VAT/tax ledger to apply against the invoice total (optional — omit for a non-taxable invoice)."New value: +"Default VAT/tax ledger applied to any item that doesn't set its own vatLedger (optional — omit for a fully non-taxable invoice)."
    • changedInput schema / properties / vatRatePercent / description
      Previous value: -"VAT rate as a percentage, e.g. 5. Required if vatLedger is set."New value: +"Default VAT rate as a percentage, e.g. 5. Required if vatLedger is set. Items with mixed rates can override this per-line."
    • addedInput schema / properties / voucherNumber
      Added value: +{
      +  "description": "Explicit voucher number. Normally omit this and let Tally auto-number — but some Tally configurations (confirmed live: after a Company Data → Rewrite in at least one case) stop auto-numbering item-invoice vouchers via the XML gateway and fail with a blank EXCEPTIONS:1/no error text unless a number is given explicitly. If a create call fails with no error text, check get_vouchers for the highest existing number of this voucher type and retry with voucherNumber set to the next one.",
      +  "type": "string"
      +}
  4. Addedv1.0.4

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare the basic safety profile (not read-only, not idempotent, not destructive), and the description goes well beyond them: it discloses a confirmed live side effect where a party/stock item used in both Sales and Purchase item-invoices can become undeletable, plus the Company Data → Rewrite recovery path. That is exactly the kind of non-obvious behavioral context annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and sibling differentiation are front-loaded in the first sentence, with the operational warning following. The warning is somewhat long and parenthetical-heavy, but every clause carries actionable information (symptom, cause, recovery), so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 18-parameter mutation tool with no output schema, the description covers the highest-risk failure modes (undeletable records, silent godown omission, blank voucher numbering) that the schema alone would bury. It stops short of describing the preview_write/confirm_write pattern or return shape, which would round it out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 18 parameters in detail, including the godown silent-failure and voucherNumber auto-numbering caveats. The description adds only a high-level summary of the line structure and the optional VAT line, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create an item-invoice Sales voucher in TallyPrime') and immediately characterizes the payload ('stock item lines (quantity, rate), each posted to its own Sales ledger, plus one optional VAT/tax line'). It explicitly contrasts with the sibling create_voucher, so an agent can distinguish the two without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear when-to-use signal by naming create_voucher as the alternative for plain ledger-to-ledger entries with no stock items. It does not address other plausible siblings such as create_sales_order, create_delivery_note, or the preview_write/confirm_write workflow, so routing guidance is strong but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools