Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

create_voucher

Create payment, receipt, sales, purchase, or journal vouchers in TallyPrime using simple two-ledger entries or multi-line splits. Force custom voucher numbers when auto-numbering fails.

Instructions

Create a new voucher (e.g. Payment, Receipt, Sales, Purchase, Journal) in TallyPrime. Either pass debitLedger/creditLedger/amount for a simple 2-leg voucher, or pass 'entries' for a voucher with 3+ lines (e.g. one payment split across several expense ledgers). Normally omit voucherNumber and let Tally auto-number — but if Tally's numbering series doesn't pick up correctly (confirmed live: a company on a 'PNPC/2026/...' series silently restarted from '1' instead of continuing it), pass voucherNumber explicitly to force the value you want; check get_vouchers for the correct next number first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesVoucher date in DD-MM-YYYY format
amountNoAmount of the transaction (simple 2-leg mode; omit if using 'entries')
entriesNoFor a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory?, description? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely.
buyerTrnNoThe buyer's TRN as it should appear on THIS voucher, when voucherType is a Sales-side accounting document (e.g. a custom 'Tax Invoice' voucher type entered in Accounting Invoice mode — plain ledger entries, no stock items) — Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields, reverse-engineered from a real such voucher. Only correct when the party ledger IS the buyer (Sales-class); for a Purchase-class voucher the buyer is your own company instead, which this generic field does not distinguish — use create_purchase_invoice's separate buyerTrn/supplierTrn for that case.
narrationNoNarration / description for the voucher
referenceNoFree-text reference for this voucher, backed by Tally's voucher-level REFERENCE field (the same field the 'Order no.' UI field on Order-class vouchers uses) — e.g. a supplier's bill/invoice number like 'PI-061538' on a Payment or Journal settling that bill. Independent of voucherNumber and of any per-leg bill reference name (debitBillName/creditBillName/entries[].billName), which is Tally's separate bill-wise settlement mechanism, not this field.
buyerStateNoThe buyer's Emirate/state on this voucher's Party Details (voucher-level STATENAME) — same Sales-class caveat as buyerTrn.
debitLedgerNoLedger name to debit (simple 2-leg mode; omit if using 'entries')
voucherTypeYesVoucher type, e.g. 'Payment', 'Receipt', 'Sales', 'Purchase', 'Journal'
buyerCountryNoThe buyer's country on this voucher's Party Details (voucher-level COUNTRYOFRESIDENCE) — same Sales-class caveat as buyerTrn.
costCategoryNoCost category the cost centre belongs to. Defaults to 'Primary Cost Category'.
creditLedgerNoLedger name to credit (simple 2-leg mode; omit if using 'entries')
debitBillNameNoBill reference name to allocate the debit leg against, e.g. for a Payment settling a Purchase bill. Omit for vouchers with no bill-wise tracking.
debitBillTypeNo'New Ref' to open a new bill (e.g. a Purchase/Sales invoice), or 'Agst Ref' to settle an existing one by its exact bill reference name (e.g. a Payment/Receipt against a prior invoice). Also accepts 'Advance' or 'On Account'. Defaults to 'New Ref' if debitBillName is set.
referenceDateNoDate for the reference above, in DD-MM-YYYY format (Tally's REFERENCEDATE field). Independent of the voucher's own date. Only meaningful if reference is also set.
voucherNumberNoExplicit voucher number, overriding Tally's automatic numbering. Optional — omit to let Tally assign the next number in its series.
creditBillNameNoSame as debitBillName, for the credit leg.
creditBillTypeNoSame as debitBillType, for the credit leg.
debitCostCentreNoCost centre to allocate the debit leg to (optional).
creditCostCentreNoCost centre to allocate the credit leg to (optional).
debitDescriptionNoAdditional description lines for the debit leg — Tally's built-in 'Provide Additional Descriptions for Ledgers' text shown in italics under that ledger line (one array entry per line, e.g. ['For KK Trading and', 'Manis Trading']). Optional.
creditDescriptionNoSame as debitDescription, for the credit leg.
placeOfSupplyCountryNoUAE VAT Place of Supply Country (Tally's PLACEOFSUPPLYCOUNTRY field), e.g. 'UAE'.
placeOfSupplyEmirateNoUAE VAT Place of Supply Emirate for this voucher (Tally's EMIRATEPOS field) — for a standard domestic supply this is normally your own company's Emirate (check get_company_info).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.13.1
    • addedInput schema / properties / creditDescription
      Added value: +{
      +  "description": "Same as debitDescription, for the credit leg.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / debitDescription
      Added value: +{
      +  "description": "Additional description lines for the debit leg — Tally's built-in 'Provide Additional Descriptions for Ledgers' text shown in italics under that ledger line (one array entry per line, e.g. ['For KK Trading and', 'Manis Trading']). Optional.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / entries / description
      Previous value: -"For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely."New value: +"For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory?, description? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely."
    • addedInput schema / properties / entries / items / properties / description
      Added value: +{
      +  "description": "Additional description lines for this ledger line, one array entry per line.",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  2. Changed8 schema fields changedv1.11.2
    • addedInput schema / properties / buyerCountry
      Added value: +{
      +  "description": "The buyer's country on this voucher's Party Details (voucher-level COUNTRYOFRESIDENCE) — same Sales-class caveat as buyerTrn.",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerState
      Added value: +{
      +  "description": "The buyer's Emirate/state on this voucher's Party Details (voucher-level STATENAME) — same Sales-class caveat as buyerTrn.",
      +  "type": "string"
      +}
    • addedInput schema / properties / buyerTrn
      Added value: +{
      +  "description": "The buyer's TRN as it should appear on THIS voucher, when voucherType is a Sales-side accounting document (e.g. a custom 'Tax Invoice' voucher type entered in Accounting Invoice mode — plain ledger entries, no stock items) — Tally's TRADERCONSVATTINNO/BASICBUYERSSALESTAXNO fields, reverse-engineered from a real such voucher. Only correct when the party ledger IS the buyer (Sales-class); for a Purchase-class voucher the buyer is your own company instead, which this generic field does not distinguish — use create_purchase_invoice's separate buyerTrn/supplierTrn for that case.",
      +  "type": "string"
      +}
    • 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 voucher (Tally's EMIRATEPOS field) — for a standard domestic supply this is normally your own company's Emirate (check get_company_info).",
      +  "type": "string"
      +}
    • addedInput schema / properties / reference
      Added value: +{
      +  "description": "Free-text reference for this voucher, backed by Tally's voucher-level REFERENCE field (the same field the 'Order no.' UI field on Order-class vouchers uses) — e.g. a supplier's bill/invoice number like 'PI-061538' on a Payment or Journal settling that bill. Independent of voucherNumber and of any per-leg bill reference name (debitBillName/creditBillName/entries[].billName), which is Tally's separate bill-wise settlement mechanism, not this field.",
      +  "type": "string"
      +}
    • addedInput schema / properties / referenceDate
      Added value: +{
      +  "description": "Date for the reference above, in DD-MM-YYYY format (Tally's REFERENCEDATE field). Independent of the voucher's own date. Only meaningful if reference is also set.",
      +  "type": "string"
      +}
    • addedInput schema / properties / voucherNumber
      Added value: +{
      +  "description": "Explicit voucher number, overriding Tally's automatic numbering. Optional — omit to let Tally assign the next number in its series.",
      +  "type": "string"
      +}
  3. Changed5 schema fields changedv1.0.4
    • changedInput schema / properties / amount / description
      Previous value: -"Amount of the transaction"New value: +"Amount of the transaction (simple 2-leg mode; omit if using 'entries')"
    • changedInput schema / properties / creditLedger / description
      Previous value: -"Ledger name to credit"New value: +"Ledger name to credit (simple 2-leg mode; omit if using 'entries')"
    • changedInput schema / properties / debitLedger / description
      Previous value: -"Ledger name to debit"New value: +"Ledger name to debit (simple 2-leg mode; omit if using 'entries')"
    • addedInput schema / properties / entries
      Added value: +{
      +  "description": "For a voucher with more than 2 lines (e.g. one payment covering three expense ledgers): an array of { ledgerName, amount, type: 'debit'|'credit', billName?, billType?, costCentre?, costCategory? }. Debit and credit amounts must sum to the same total (Tally's double-entry rule) or the call fails with a clear error before reaching Tally. When provided, this replaces debitLedger/creditLedger/amount entirely.",
      +  "items": {
      +    "properties": {
      +      "amount": {
      +        "type": "number"
      +      },
      +      "billName": {
      +        "type": "string"
      +      },
      +      "billType": {
      +        "type": "string"
      +      },
      +      "costCategory": {
      +        "type": "string"
      +      },
      +      "costCentre": {
      +        "type": "string"
      +      },
      +      "ledgerName": {
      +        "type": "string"
      +      },
      +      "type": {
      +        "enum": [
      +          "debit",
      +          "credit"
      +        ],
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "ledgerName",
      +      "amount",
      +      "type"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "voucherType",
      -  "date",
      -  "debitLedger",
      -  "creditLedger",
      -  "amount"
      -]New value: +[
      +  "voucherType",
      +  "date"
      +]
  4. First observedv1.0.3

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare this is a non-idempotent, non-destructive write (readOnlyHint=false, idempotentHint=false), so the safety profile is covered. The description adds real operational behavior beyond that: the double-entry sum rule and its pre-Tally failure mode, and the live-observed auto-numbering bug where a company series silently restarted at '1'.

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

Conciseness5/5

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

The mode-selection guidance is front-loaded in the first sentence and each subsequent sentence covers a distinct decision the caller must make (mode, numbering, buyer fields). The voucherNumber sentence is long but every clause is load-bearing, citing a concrete failure case rather than padding.

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 a 24-parameter write with no output schema, the description covers the decisions that actually gate a correct call (mode, numbering, double-entry balance, buyer-field caveats). It does not describe the response shape or whether the created voucher's number is returned, which an agent would need to chain a confirmation step.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully adds mode selection (which fields apply in which mode) and cross-parameter relationships that the per-field schema text does not frame: entries superseding debit/credit/amount, reference being independent of voucherNumber and per-leg billName, and the Sales-class caveat that limits buyerTrn/buyerState.

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 (create) and resource (voucher) in a named system (TallyPrime) and enumerates the voucher types covered. It is clearly distinguishable from the many specialized siblings (create_sales_invoice, create_purchase_invoice, create_credit_note) by being the generic accounting-voucher writer.

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

Usage Guidelines5/5

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

Explicitly lays out two mutually exclusive modes — 2-leg via debitLedger/creditLedger/amount, or multi-line via entries — and states that entries replaces the simple fields. It also gives when-not guidance for voucherNumber and points to get_vouchers to obtain the correct next number, and defers buyerTrn to create_purchase_invoice for Purchase-class vouchers.

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