Skip to main content
Glama
lokesh-sparrow

PNPC-MCP-Tally-Prime

create_stock_journal

Create inventory-only Stock Journal vouchers in TallyPrime to transfer stock or convert raw materials into finished goods, with multiple sources, destinations, and optional production costs.

Instructions

Create a Stock Journal voucher in TallyPrime, moving inventory from one or more source stock items to one or more destination stock items (transfer, manufacturing-style conversion with multiple raw materials consumed and/or multiple finished/by-products produced, etc). Inventory-only — no ledger entries. Every source/destination line's godown is auto-filled only when this company has exactly one godown; if it has more than one (e.g. Dubai/Sharjah/Ajman), godown is required on each line and the call fails naming the available godowns rather than guessing (previously an omitted godown was silently dropped — blank EXCEPTIONS:1, no error text — this is now caught explicitly instead of guessing wrong).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateYesVoucher date in DD-MM-YYYY format
sourcesYesOne or more stock items being consumed/issued.
narrationNoNarration / description for the voucher
voucherTypeNoVoucher type to post against. Defaults to 'Stock Journal'. Pass the name of a voucher type created via create_voucher_type with useAsManufacturingJournal to post as a real Manufacturing Journal instead — same underlying voucher shape either way.
destinationsYesOne or more stock items being produced/received.
voucherNumberNoExplicit voucher number. Normally omit and let Tally auto-number — but some Tally configurations stop auto-numbering certain voucher types via the XML gateway (confirmed live for item-invoice types; unconfirmed either way for Stock Journal). If creation fails with a blank EXCEPTIONS:1, check get_vouchers for the highest existing number of this voucher type and retry with voucherNumber set to the next one.
additionalCostsNoOptional additional costs (labour, freight, overhead, etc) incurred in production, posted through an expense ledger and folded into the value of the destination item(s) rather than left as a separate P&L line.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed14 schema fields changedv1.11.2
    • addedInput schema / properties / additionalCosts
      Added value: +{
      +  "description": "Optional additional costs (labour, freight, overhead, etc) incurred in production, posted through an expense ledger and folded into the value of the destination item(s) rather than left as a separate P&L line.",
      +  "items": {
      +    "properties": {
      +      "allocationType": {
      +        "description": "How to apportion this cost across multiple destination items. Default: 'Appropriate by Value'.",
      +        "enum": [
      +          "Appropriate by Value",
      +          "Appropriate by Quantity",
      +          "Not Applicable"
      +        ],
      +        "type": "string"
      +      },
      +      "amount": {
      +        "description": "Cost amount",
      +        "type": "number"
      +      },
      +      "ledgerName": {
      +        "description": "Exact name of the expense ledger to post this cost to",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "ledgerName",
      +      "amount"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / destItem
      Removed value: -{
      -  "description": "Exact name of the stock item being produced/received",
      -  "type": "string"
      -}
    • removedInput schema / properties / destQty
      Removed value: -{
      -  "description": "Quantity of destItem produced",
      -  "type": "number"
      -}
    • removedInput schema / properties / destRate
      Removed value: -{
      -  "description": "Rate per unit of destItem",
      -  "type": "number"
      -}
    • addedInput schema / properties / destinations
      Added value: +{
      +  "description": "One or more stock items being produced/received.",
      +  "items": {
      +    "properties": {
      +      "batchName": {
      +        "description": "Batch name (optional, defaults to 'Primary Batch')",
      +        "type": "string"
      +      },
      +      "godown": {
      +        "description": "Godown this line is received into. Auto-fills only if this company has exactly one godown; required if it has more than one.",
      +        "type": "string"
      +      },
      +      "qty": {
      +        "description": "Quantity produced",
      +        "type": "number"
      +      },
      +      "rate": {
      +        "description": "Rate per unit",
      +        "type": "number"
      +      },
      +      "stockItem": {
      +        "description": "Exact name of the stock item being produced",
      +        "type": "string"
      +      },
      +      "unit": {
      +        "description": "Unit of measure, e.g. 'Nos'",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "stockItem",
      +      "qty",
      +      "rate",
      +      "unit"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / godown
      Removed value: -{
      -  "description": "Godown for both legs (optional — only needed if the items have godown/location tracking enabled).",
      -  "type": "string"
      -}
    • removedInput schema / properties / sourceItem
      Removed value: -{
      -  "description": "Exact name of the stock item being consumed/issued",
      -  "type": "string"
      -}
    • removedInput schema / properties / sourceQty
      Removed value: -{
      -  "description": "Quantity of sourceItem consumed",
      -  "type": "number"
      -}
    • removedInput schema / properties / sourceRate
      Removed value: -{
      -  "description": "Rate per unit of sourceItem",
      -  "type": "number"
      -}
    • addedInput schema / properties / sources
      Added value: +{
      +  "description": "One or more stock items being consumed/issued.",
      +  "items": {
      +    "properties": {
      +      "batchName": {
      +        "description": "Batch name (optional, defaults to 'Primary Batch')",
      +        "type": "string"
      +      },
      +      "godown": {
      +        "description": "Godown this line is issued from. Auto-fills only if this company has exactly one godown; required if it has more than one.",
      +        "type": "string"
      +      },
      +      "qty": {
      +        "description": "Quantity consumed",
      +        "type": "number"
      +      },
      +      "rate": {
      +        "description": "Rate per unit",
      +        "type": "number"
      +      },
      +      "stockItem": {
      +        "description": "Exact name of the stock item being consumed",
      +        "type": "string"
      +      },
      +      "unit": {
      +        "description": "Unit of measure, e.g. 'Nos'",
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "stockItem",
      +      "qty",
      +      "rate",
      +      "unit"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • removedInput schema / properties / unit
      Removed value: -{
      -  "description": "Unit of measure shared by both items, e.g. 'Nos'",
      -  "type": "string"
      -}
    • addedInput schema / properties / voucherNumber
      Added value: +{
      +  "description": "Explicit voucher number. Normally omit and let Tally auto-number — but some Tally configurations stop auto-numbering certain voucher types via the XML gateway (confirmed live for item-invoice types; unconfirmed either way for Stock Journal). If creation fails with a blank EXCEPTIONS:1, check get_vouchers for the highest existing number of this voucher type and retry with voucherNumber set to the next one.",
      +  "type": "string"
      +}
    • addedInput schema / properties / voucherType
      Added value: +{
      +  "description": "Voucher type to post against. Defaults to 'Stock Journal'. Pass the name of a voucher type created via create_voucher_type with useAsManufacturingJournal to post as a real Manufacturing Journal instead — same underlying voucher shape either way.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "date",
      -  "sourceItem",
      -  "sourceQty",
      -  "sourceRate",
      -  "destItem",
      -  "destQty",
      -  "destRate",
      -  "unit"
      -]New value: +[
      +  "date",
      +  "sources",
      +  "destinations"
      +]
  2. First observedv1.0.3

TDQS

A5/5.0
Behavior5/5

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

Discloses key behaviors: inventory-only (no ledger entries), auto-fill logic for godowns, auto-numbering pitfalls, and how additional costs are allocated. This transparency is especially valuable given the write nature of the operation.

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 description is detailed but well-organized, with the main paragraph providing an overview and parameter-level details following. No fluff; every sentence carries relevant operational information.

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

Completeness5/5

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

Covers all relevant operational contexts: creation behavior, multi-godown requirements, auto-numbering pitfalls, and cost allocation. Even without an output schema, it addresses potential error scenarios, making it sufficiently complete for an agent to use correctly.

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

Parameters5/5

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

Every parameter is explained beyond the schema, such as 'consumed' vs 'produced' for sources/destinations, defaults for batchName, allocationType for costs, and the distinction between voucherType and voucherNumber. This adds significant meaning beyond the JSON schema.

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?

The description clearly states the tool creates a Stock Journal voucher for inventory transfers or manufacturing conversions, explicitly distinguishing it from other inventory voucher types and noting it is inventory-only with no ledger entries.

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?

Provides explicit guidance on when to use (transfer or manufacturing), how to use the voucherType for manufacturing journals, and detailed notes on auto-numbering and godown handling, including failure scenarios and retry advice.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lokesh-sparrow/PNPC-MCP-Tally-Prime'

If you have feedback or need assistance with the MCP directory API, please join our Discord server