Skip to main content
Issues a Purchase Order into Tally against a vendor. Display name “Tally Create Purchase Order”. Off by default. Unlike the other Tally voucher tools, a Purchase Order is an inventory/order voucher: each line orders a stock item by quantity and rate, the line value is allocated to a purchase ledger, and the vendor’s party ledger is credited with the order total. Optional GST tax ledgers are added as voucher-level entries. A Purchase Order has no accounting effect in Tally. It creates no ledger entry and no bill reference. Post the supplier invoice separately with tally_create_purchase_voucher when it arrives.

​
Authentication and enablement

Requires a workspace Tally integration pointing at the TallyPrime HTTP-XML gateway. base_url, company, and the optional reverse-proxy basic-auth credentials are injected from the integration record. Enable the tool and bind the integration. The Tally company must be “Maintain Accounts with Inventory”, and the Purchase Order voucher type must be active — in TallyPrime that is a per-voucher-type setting (Alter → Voucher Type → Purchase Order → Activate this Voucher Type), not an F11 company feature. When it is inactive, Tally accepts the import and reports no errors but silently discards every inventory line, leaving an item-less order. The allocation ledger must also affect stock (AFFECTSSTOCK = Yes, i.e. a Purchase Accounts ledger). Allocating to a Fixed Assets ledger produces the same silent item-less order.

​
Inputs

  • party_ledger_name (required): vendor’s party ledger, exactly as it exists in Tally. Resolve with tally_lookup_vendor_by_gstin.
  • order_date (required): YYYY-MM-DD.
  • order_number (required): written to the voucher reference and every line’s order number, so a later Receipt Note or purchase can be tracked against it. Max 64 characters. It is not written to the Tally voucher number — voucher types default to automatic numbering, under which Tally discards a supplied number and assigns its own sequence. This matches tally_create_purchase_voucher, where the supplier invoice number lives in the reference.
  • voucher_number (optional): explicit Tally voucher number. Omit to let Tally auto-number. Tally honours it only when the Purchase Order voucher type is set to manual numbering.
  • purchase_ledger_name (required): purchase ledger the ordered value is allocated to.
  • lines (required, at least one): each line takes
    • stock_item_name (required): exact Tally stock item name. Resolve with tally_list_stock_items.
    • quantity (required) and rate (required): both must be greater than zero.
    • unit: Tally unit symbol (Nos, Kgs). Omit only if unknown — Tally then applies the item’s base unit and derives the rate, and a warning is returned. The symbol must contain no spaces or /.
    • amount: defaults to quantity × rate. Supply it only for a negotiated line total; a value that disagrees with quantity × rate is used as given and reported as a warning.
    • ledger_name, due_date, godown_name: per-line overrides of purchase_ledger_name, order_due_date, and Tally’s Main Location.
  • order_due_date (effectively required): delivery due date for the whole order, YYYY-MM-DD. Individual lines can override it with their own due_date. Tally rejects an order voucher whose lines carry no <ORDERDUEDATE> — silently, with created=0 errors=0 and no message — so validation fails locally unless either this or every line’s due_date is set.
  • tax_entries: GST tax ledger entries (ledger_name, amount) — CGST/SGST intra-state, IGST inter-state.
  • narration: free-text note.
There is no total input: the order total is derived as sum(line amounts) + sum(tax amounts).

​
Output

{order_number, voucher_number, party_ledger_name, order_date, order_due_date, last_vch_id, line_count, sub_total, tax_total, order_total, lines[], created, warnings[], issued_at}. voucher_number is the number Tally assigned, resolved by reading the order back after it is issued — Tally’s import response does not report it. It is omitted when the read-back cannot identify the order, which does not mean the order failed. order_number is the PO number you supplied, stored as the voucher reference. Each entry in lines[] echoes the resolved values, including which purchase ledger and due date the line actually received after defaults were applied. The field is issued_at, not posted_at — an order is not an accounted document.

​
Limits and side effects

  • Writes to Tally. The import is sent once and never retried: Tally’s Import Data is not idempotent, so a request that times out client-side may still have created the order, and a retry would issue it twice. A failed write surfaces for explicit reconciliation instead.
  • Stock items, the party ledger, the purchase ledger, any tax ledgers, and the godown must already exist in Tally. This tool creates no masters.
  • No draft/optional mode is offered. An order has no accounting effect to protect, and Tally excludes optional vouchers from its order-outstanding reports, so a draft order would not be visible where orders are tracked. Use a review step ahead of the tool call for maker-checker.
  • The party entry carries no bill allocation, because an order creates no bill reference.

​
Expected errors

  • Missing Tally credentials.
  • Validation: missing party or purchase ledger, missing or over-long order number, unparseable date, no lines, non-positive quantity or rate, or a unit symbol containing a space or /.
  • Tally rejected the purchase order: Stock Item 'X' does not exist! — the item name did not match a master exactly. Re-resolve it with tally_list_stock_items. Tally’s message is surfaced verbatim.
  • Similar rejections for an unknown ledger, godown, or voucher type.
  • An order created with no item lines is not an error and is not reported as one. It means either the Purchase Order voucher type is inactive or the allocation ledger does not affect stock. Verify with tally_get_purchase_orders: an order whose lines[] is empty was discarded in this way.
  • Gateway unreachable or an HTTP error from the Tally gateway.