\r \r

TallyPrime (CA) Skill\r

\r Connect to a locally running TallyPrime instance via its XML-over-HTTP interface. All requests are HTTP POST to $TALLY_URL (commonly http://localhost:9000) with an XML body.\r \r

• No cloud API: TallyPrime must be open/running on the user’s machine.\r
• Multi-company: Always use the correct SVCURRENTCOMPANY (exact spelling).\r \r

Hero Use Case: Bridge JSON → Tally entry\r

\r This skill receives pre-extracted invoice data as a canonical JSON payload from the bridge service (see reference/bridge-input.md for schema). PDF/image extraction is handled by a separate tally-extractor-skill running on Instance A.\r \r Goal: zero manual entry for CAs handling many clients.\r \r

1. Receive validated JSON payload from bridge (company, party, GSTIN, date, invoice no, items, taxes, total).\r
2. Ensure masters exist: party ledger, purchase/sales ledger, GST ledger(s), bank/cash ledger (if needed).\r
3. Post voucher with a unique GUID (the idempotency_key from the JSON).\r
4. Return structured result to the bridge for relay to the user.\r \r Important: This skill does not parse PDFs or images. All document extraction happens on Instance A (tally-extractor-skill). This skill only processes structured JSON input via the bridge HTTP endpoint.\r \r

PDF Generation from Text (Invoice / Receipt)\r

\r When the user asks to generate a PDF from invoice data or any text message, use the tallyca CLI. This converts raw WhatsApp/Telegram text directly into a professional GST-compliant PDF.\r \r Important: Always produce the file only via tallyca. Do not invent HTML/PDF with the model when tallyca fails — fix the environment (below) or set TALLYCA_PDF_BACKEND=pdfmake and retry.\r \r

One-time setup (run once per environment)\r

\r

npm install -g tallyca\r
```\r
\r
### Minimum `tallyca` CLI version (OpenClaw must stay current)\r
\r
OpenClaw **does not** auto-discover new npm releases. Whatever was installed with `npm install -g tallyca` stays until someone runs an upgrade command.\r
\r
**Required for this skill’s PDF flows:** `tallyca` **>= 1.0.1** (semver). Features such as Playwright + pdfmake fallback and `TALLYCA_PDF_BACKEND` assume this baseline.\r
\r
When you publish a newer **breaking** or **must-have** CLI release, **edit this line** in `SKILL.md` to the new minimum and redeploy the skill so agents reinstall if needed.\r
\r
**Preflight (before generating a PDF):**\r
\r
1. Run `tallyca --version` (output looks like `tallyca/1.0.1 …`). Compare the numeric version to the minimum above.\r
2. If `tallyca` is missing or older than the minimum, run:\r
\r
   ```bash\r
   npm install -g tallyca@latest\r
   ```\r
\r
   Or pin exactly: `npm install -g [email protected]`.\r
\r
3. **Optional** (only if npm registry is reachable): compare registry vs installed:\r
\r
   ```bash\r
   npm view tallyca version\r
   ```\r
\r
   If the registry version is newer **and** you want the latest fixes, run `npm install -g tallyca@latest`, then re-check `tallyca --version`.\r
\r
**Note:** The `version:` field at the top of this file is the **skill document** version, not the `tallyca` package version.\r
\r
### PDF rendering on servers (AWS / Linux / minimal images)\r
\r
`tallyca` tries **Playwright + Chromium** first (matches the HTML templates). If Chromium cannot start (common errors: missing `libatk-1.0.so.0`, “failed to launch browser”, missing GTK/GBM libs), it **automatically falls back** to **pdfmake** (pure JavaScript, no browser). You can control this with **`TALLYCA_PDF_BACKEND`**:\r
\r
| Value | Behavior |\r
|-------|----------|\r
| `auto` (default) | Playwright first; on typical Chromium failures, use pdfmake |\r
| `playwright` | Playwright only — fails if Chromium/libs missing |\r
| `pdfmake` | Skip Chromium — always pdfmake (best on locked-down serverless/AWS without apt/yum) |\r
\r
**Recommended on AWS when Playwright errors appear:**\r
\r
```bash\r
export TALLYCA_PDF_BACKEND=pdfmake\r
```\r
\r
Then run the same `tallyca from-text` / `generate:invoice` commands as usual.\r
\r
**If you can install OS packages** (full EC2/container with sudo), install Chromium dependencies and browsers so Playwright works:\r
\r
**Amazon Linux 2 / AL2023**\r
\r
```bash\r
sudo yum install -y \\r
  alsa-lib atk at-spi2-atk cups-libs libdrm libXcomposite \\r
  libXdamage libXrandr mesa-libgbm pango gtk3\r
npx playwright install chromium\r
npx playwright install-deps chromium\r
```\r
\r
**Ubuntu / Debian**\r
\r
```bash\r
sudo apt-get update\r
sudo apt-get install -y \\r
  libatk1.0-0 libatk-bridge2.0-0 libcups2 libdrm2 \\r
  libxcomposite1 libxdamage1 libxrandr2 libgbm1 \\r
  libpango-1.0-0 libcairo2 libasound2 libatspi2.0-0\r
npx playwright install chromium\r
npx playwright install-deps chromium\r
```\r
\r
### Generate invoice PDF from raw WhatsApp text\r
\r
Pass the user's message directly to `tallyca from-text`:\r
\r
```bash\r
tallyca from-text \\r
  --company "ABC Company" \\r
  --text "Party Name: XYZ Party\r
Invoice No.: 186\r
Date: 2/1/2026\r
Item: PQR Item 2523 @ 18 %\r
Qty: 140 Bag\r
Rate: 279.66/Bag\r
HSN Code: 25322210\r
Amount: 39152.40\r
Make sure to use voucher class Sales @ 18 %" \\r
  --output invoice_186.pdf\r
```\r
\r
The parser auto-extracts: party name, invoice number, date, item details, HSN, quantity, rate, tax rate, amount, and voucher class.\r
\r
### Generate invoice PDF with structured flags\r
\r
When you have already extracted the fields:\r
\r
```bash\r
tallyca generate:invoice \\r
  --company "ABC Company" \\r
  --party "XYZ Party" \\r
  --invoice-no 186 \\r
  --date "2/1/2026" \\r
  --item "PQR Item|140 Bag|279.66|18%|25322210" \\r
  --voucher-class "Sales @ 18 %" \\r
  --output invoice_186.pdf\r
```\r
\r
Item format: `Description|Qty Unit|Rate|Tax%|HSN` (pipe-separated). Use `--item` multiple times for multiple line items.\r
\r
### Generate generic PDF (receipts, notes)\r
\r
```bash\r
tallyca generate:generic \\r
  --title "Payment Receipt" \\r
  --body "Payment of ₹39152.40 received from XYZ Party against Invoice 186." \\r
  --output receipt.pdf\r
```\r
\r
### Commands summary\r
\r
| Command | Use case |\r
|---|---|\r
| `tallyca from-text --text "..." --output x.pdf` | Auto-detect type from raw text |\r
| `tallyca generate:invoice --party "..." --item "..." --output x.pdf` | Structured invoice data |\r
| `tallyca generate:generic --title "..." --body "..." --output x.pdf` | Receipts, notes, any text |\r
\r
### Workflow: User asks for PDF\r
\r
1. User sends invoice details via WhatsApp/Telegram\r
2. Check if `tallyca` is installed: `which tallyca` / `where tallyca` (Windows) or `tallyca --version`\r
3. Run **`tallyca --version`** and confirm it meets **Minimum `tallyca` CLI version** above. If missing or too old: `npm install -g tallyca@latest` (or the pinned version), then verify again.\r
4. **Optional:** Run `npm view tallyca version` if you need to confirm whether a newer CLI exists on npm before upgrading.\r
5. Run `tallyca from-text` with the user's message as `--text` (and `--company` / `--output` as needed)\r
6. If the command fails with Chromium/browser/library errors on Linux/AWS: set `TALLYCA_PDF_BACKEND=pdfmake` for that shell session (or install OS + Playwright deps above), then **retry the same `tallyca` command**. Do not substitute a hand-built PDF from the model.\r
7. Return the generated PDF file from `tallyca` to the user\r
\r
### Maintainer / release discipline (`tallyca` npm package)\r
\r
When you ship a **new `tallyca` version** that this skill depends on (new flags, breaking PDF behavior, or required bugfixes):\r
\r
1. Publish **`tallyca`** to npm (`tally-pdf-cli` package).\r
2. Update **Minimum `tallyca` CLI version** in this section if the skill requires that release (especially majors or breaking flags).\r
3. Bump this **`SKILL.md` frontmatter `version`** when you redistribute the skill bundle so teams know the doc changed.\r
\r
That way OpenClaw instructions and the installed CLI stay aligned; the agent only “knows” about new versions through **this documented minimum + upgrade commands**, not automatically.\r
\r
\r
## When to use this skill\r
\r
**Scope note:** This skill is for **Instance B** (Tally Poster). It does **not** parse PDFs or images — that responsibility belongs to `tally-extractor-skill` on Instance A. This skill receives structured JSON from the bridge and posts to TallyPrime.\r
\r
Use when:\r
\r
- Receiving JSON payloads from the bridge (`/v1/post-voucher`) — validate and post to Tally\r
- **Generate PDF**: create invoice PDF, receipt PDF, or any document from text/data (use `tallyca` CLI)\r
- Post entries: purchase, sales, receipt, payment, journal, contra, credit note, debit note\r
- Check reports: day book, trial balance, balance sheet, profit & loss, ledger statement, outstandings, GST\r
- Manage masters: create/alter ledgers, groups, stock items/UOM (inventory clients)\r
- Fix data: alter or cancel a voucher\r
\r
For any Tally/accounting task, **always follow this skill and its `reference/` templates**. Do not create XML payloads from scratch for known flows; use the documented template that matches the task and only replace the required placeholders. If the required task is not documented, first read `SKILL.md` and all relevant files in `reference/` thoroughly; if no documented template/workflow exists, clearly tell the user that this skill cannot perform that task yet and do not attempt it.\r
\r
Responses to users must be written for accountants, not developers. After Tally calls, do **not** mention XML, payloads, HTTP, server responses, status codes, raw API output, or integration internals unless the user explicitly asks for technical details. Say “Tally is connected” instead of “server is running”; say “Entry posted” or “Entry updated” instead of “XML import succeeded”; then summarize the company name, voucher type, date, party/ledger names, amount, tax split, narration, and any masters created or missing.\r
\r
## Critical rules (must follow)\r
\r
1. **Never assume company**: if not explicit, ask which company to use before posting.\r
2. **Never guess ledgers**: verify ledgers exist before voucher import; create missing masters first.\r
3. **Dates are `YYYYMMDD`** (no separators).\r
4. **Idempotency**: always set a stable unique `GUID` per voucher to prevent duplicates on retries.\r
5. **Balance vouchers**: total debits must equal total credits (Tally error: “Voucher totals do not match!”).\r
6. **Escape XML**: narration/party names may contain `&` → use `&` in XML.\r
7. **Posting is write operation**: confirm intent (and company) before any create/alter/cancel.\r
8. **Prefer bill-wise allocations** for party ledgers to keep outstandings correct (see `reference/vouchers.md`).\r
9. **Accounting-only vouchers (no inventory items)**: set `\x3CISINVOICE>No\x3C/ISINVOICE>` and place the **party ledger entry first** in the `ALLLEDGERENTRIES.LIST` sequence. This makes the Day Book "Particulars" column show the party name (not the expense/purchase ledger) and defaults the voucher to the clean "As Voucher" view. Only use `ISINVOICE=Yes` for item invoices that go through `reference/inventory.md`.\r
10. **Accounting Invoice Mode — always use `LEDGERENTRIES.LIST`**: when `OBJVIEW="Invoice Voucher View"` is set (Modes 1 and 2 in `reference/vouchers.md`), every ledger block **must** use `\x3CLEDGERENTRIES.LIST>`, not `\x3CALLLEDGERENTRIES.LIST>`. Tally silently ignores `ALLLEDGERENTRIES` in this view, causing the voucher to be saved with no entries and the error "No accounting or inventory entries are available."\r
11. **Voucher class decision — confirm before posting**: before posting any Purchase or Sales voucher, check whether the company's voucher type uses a class for GST splitting. Run the preflight checklist in the "Preflight checklist before posting" section below. If class mode is confirmed, set `\x3CCLASSNAME>EXACT_CLASS_NAME\x3C/CLASSNAME>` in the voucher header and include all four GST header fields (`CMPGSTIN`, `PARTYGSTIN`, `GSTREGISTRATIONTYPE`, `PLACEOFSUPPLY`). **If class existence is unconfirmed, stop and ask — do not post without it.** Full decision rules and templates are in the "Voucher class — decision rules" section of `reference/vouchers.md`.\r
\r
## Preflight checklist before posting\r
\r
Run through every item before sending any Create/Alter/Delete request. **Stop at the first unresolved item and ask the user.**\r
\r
| # | Check | How to verify | Block if… |\r
|---|---|---|---|\r
| 1 | **Company confirmed** | User stated it explicitly | Name not given — ask |\r
| 2 | **Server reachable** | `curl -s --max-time 5 "$TALLY_URL"` | No response / wrong port |\r
| 3 | **Voucher type uses a class?** | Export voucher type masters or ask user | Unknown — ask before posting |\r
| 4 | **Class name confirmed** (if class mode) | List voucher type via masters export; match exact class name in Tally | Class not found — ask, never guess |\r
| 5 | **Party ledger exists** | Ledger existence check (`reference/masters.md`) | Missing — create first |\r
| 6 | **Purchase/Sales/GST ledgers exist** | Same as above | Missing — create first |\r
| 7 | **GST header fields available** (if class mode) | `CMPGSTIN`, `PARTYGSTIN`, `GSTREGISTRATIONTYPE`, `PLACEOFSUPPLY` | Any missing — ask user |\r
| 8 | **Voucher totals balance** | Sum all `AMOUNT` values = 0 | Mismatch — fix before posting |\r
\r
## Step 0: Check TallyPrime server\r
\r
```bash\r
curl -s --max-time 5 "$TALLY_URL"\r
```\r
\r
Expected (example):\r
\r
```xml\r
\x3CRESPONSE>TallyPrime Server is Running\x3C/RESPONSE>\r
```\r
\r
If not running, stop and ask user to open TallyPrime and enable integrations for the port.\r
\r
## Step 1: Company context\r
\r
If the user did not specify company, ask. If they did, use **exact** name in `SVCURRENTCOMPANY`.\r
\r
To list companies, use the template in `reference/reports.md` (“Company list”).\r
\r
## Step 2: Verify/create required ledgers (masters)\r
\r
Ledger existence checks and master creation templates are in `reference/masters.md` (includes ledgers, groups, GST/address fields, and party ledger creation with required field prompts).\r
\r
**New company?** Run the "New Company Setup — Standard GST Ledgers" block in `reference/masters.md` first. It creates the seven minimum ledgers every GST-registered company needs:\r
\r
| # | Ledger | Type |\r
|---|---|---|\r
| 1 | `Input Sgst @ 9 %` | Input GST |\r
| 2 | `Input Cgst @ 9 %` | Input GST |\r
| 3 | `Input IGST @ 18 %` | Input GST |\r
| 4 | `Purchase @ 18 %` | Purchase ledger |\r
| 5 | `Round Off` | Rounding |\r
| 6 | `Output Sgst @ 9 %` | Output GST |\r
| 7 | `Output Cgst @ 9 %` | Output GST |\r
\r
Quick group defaults (common CA mapping):\r
\r
| Ledger type | Parent group |\r
|---|---|\r
| Customer | `Sundry Debtors` |\r
| Vendor | `Sundry Creditors` |\r
| Sales | `Sales Accounts` |\r
| Purchases/Expenses | `Purchase Accounts` / `Direct Expenses` / `Indirect Expenses` |\r
| Bank | `Bank Accounts` |\r
| Cash | `Cash-in-Hand` |\r
| GST | `Duties & Taxes` |\r
\r
## Step 3: Post vouchers (core)\r
\r
Use `REPORTNAME=Vouchers` and always include `GUID`, `DATE`, and `VOUCHERTYPENAME`. Full templates (including bill-wise allocations, returns, contra) are in `reference/vouchers.md`.\r
\r
Supported voucher types in this skill:\r
\r
- Purchase, Sales, Payment, Receipt, Journal\r
- Credit Note, Debit Note\r
- Contra\r
- Voucher Alteration + Cancellation\r
\r
## Read reports (core)\r
\r
Use `TALLYREQUEST=Export` / `REPORTNAME=...` with `SVEXPORTFORMAT=$$SysName:XML`. Full templates are in `reference/reports.md`.\r
\r
Common CA reports:\r
\r
- **Voucher Register** — fetch all vouchers or filter by type (Payment/Receipt/Contra/etc.) for a date range — use for banking transaction extracts\r
- Day Book (period)\r
- Trial Balance (period)\r
- Balance Sheet\r
- Profit and Loss\r
- Ledger Names — fetch all ledger names before mapping/posting entries\r
- Ledger Vouchers (ledger statement)\r
- Bills Receivable / Bills Payable (outstandings)\r
- Ledger Outstandings / Group Outstandings\r
- GST: GSTR-1 and related summaries (plus GSTR-3B where available)\r
- Stock Summary (inventory clients)\r
\r
## Suggested GUID pattern\r
\r
Use a deterministic pattern when invoice number exists:\r
\r
```\r
{companyShort}-{voucherType}-{voucherNumber}-{date}\r
```\r
\r
Examples:\r
\r
- `abc-purchase-ril2026-00123-20260115`\r
- `abc-creditnote-cn09-20260302`\r
\r
## Multi-company CA workflow (recommended)\r
\r
1. Capture company name early (and confirm spelling).\r
2. Validate connectivity.\r
3. Fetch required ledgers/masters or create them.\r
4. Only then post the voucher.\r
5. Reply with: company, voucher type, voucher number, date, amount breakdown, and whether any masters were created.\r
\r
## Bank Statement Import\r
\r
When importing bank statement transactions (PDF/Excel from bank), use the mapping guide and templates in `reference/vouchers.md` → "Bank Statement Import Workflow". Covers:\r
\r
- Mapping bank entries to Receipt/Payment/Contra vouchers\r
- Ledger selection rules (debits, credits, expenses)\r
- Before posting, fetch all ledger names using `reference/reports.md` → "Ledger Names (all ledgers)" and confirm once with the user: “These are the ledgers I will use for the bank entries: ...”. Do not post until the user confirms the ledger mapping.\r
- Full XML templates for common bank transactions (NEFT, RTGS, UPI, charges)\r
\r
## Bridge input contract\r
\r
When receiving JSON from the bridge service (`/v1/post-voucher`), this skill expects a canonical JSON payload. Full schema and per-voucher-type required fields are documented in `reference/bridge-input.md`.\r
\r
Key mapping rules (JSON → Tally XML):\r
\r
| JSON field | Tally XML element | Notes |\r
|---|---|---|\r
| `voucher.date` (`YYYY-MM-DD`) | `DATE` (`YYYYMMDD`) | Remove dashes |\r
| `voucher.type` | `VOUCHERTYPENAME` | Exact enum match |\r
| `voucher.is_invoice_mode=true` | `OBJVIEW="Invoice Voucher View"` | Use `LEDGERENTRIES.LIST` (rule 10) |\r
| `voucher.voucher_class` | `CLASSNAME` | Exact spelling from Tally |\r
| `voucher.bill_allocations[]` | `BILLALLOCATIONS.LIST` | Nested under party ledger entry |\r
| `idempotency_key` | `GUID` | Used for deduplication |\r
\r
When processing bridge input:\r
\r
1. Validate JSON against schema in `reference/bridge-input.md`\r
2. Run the preflight checklist (section above)\r
3. Create missing masters if needed\r
4. Build XML using templates in `reference/vouchers.md`\r
5. Return result: `{status, guid, voucher_number, summary, masters_created[]}`\r
\r
If any required field is missing or invalid, return `needs_clarification` with the missing field names — do not invent data.\r
\r
## Deployment topology\r
\r
Instance B is the **Tally Poster**. It does not expose Telegram or WhatsApp. All user chat happens on Instance A; B only receives JSON via `bridge-service`.\r
\r
```mermaid\r
flowchart LR\r
  User["Telegram user"] --> A["Instance A\
Codex Plus + extractor skill"]\r
  A -->|"POST /v1/post-voucher"| Bridge["bridge-service :8787"]\r
  Bridge --> B["Instance B\
OpenAI API + tally-skill"]\r
  B --> Tally["TallyPrime :9000"]\r
```\r
\r
| Environment | Where B runs | Tally URL | Bridge exposure |\r
|---|---|---|---|\r
| **Production** | Client mini-PC with TallyPrime | `http://localhost:9000` | `ngrok http 8787` (or Cloudflare Tunnel) |\r
| **Dev** | Same EC2 as A (second OpenClaw) | ngrok URL to dev Tally | `localhost:8787` or ngrok |\r
\r
**Production:** No ngrok needed for Tally — only the bridge port is tunneled inbound for A.\r
\r
**Dev:** Both OpenClaws on one Ubuntu EC2; B uses your existing Tally ngrok URL in `TALLY_URL`.\r
\r
## Instance B configuration checklist\r
\r
| Step | Setting | Value |\r
|---|---|---|\r
| 1 | Host | Client mini-PC (prod) or same EC2 (dev) |\r
| 2 | Install | Node.js, OpenClaw, `npm install -g tallyca`, Tally OS deps (see PDF section) |\r
| 3 | LLM | OpenAI **API key** (per-client billing) |\r
| 4 | Skill loaded | `tally-skill/` only — **do not** load `tally-extractor-skill/` |\r
| 5 | `TALLY_URL` | `http://localhost:9000` (prod) or dev ngrok Tally URL |\r
| 6 | `TALLYCA_PDF_BACKEND` | `auto` or `pdfmake` on headless Linux |\r
| 7 | Bridge | `cd bridge-service && npm i && node server.js` on port 8787 |\r
| 8 | Tunnel | `ngrok http 8787` — give URL + bearer + HMAC secret to Instance A team |\r
| 9 | **Do not set** | `BRIDGE_URL` on Instance B (bridge is the server, not a client) |\r
| 10 | OpenClaw adapter | `OPENCLAW_MODE=cli` or `http` per your install |\r
| 11 | Health | From A: `GET $BRIDGE_URL/v1/health` must return `tally: ok` before posting |\r
\r
## Advanced reference\r
\r
- **Bridge input schema**: `reference/bridge-input.md`\r
- Reports and data export: `reference/reports.md`\r
- Voucher templates (including Debit/Credit Note, Contra, bill-wise allocations, alter/cancel): `reference/vouchers.md`\r
- Masters (ledgers/groups + GST/address, alteration): `reference/masters.md`\r
- Inventory (stock groups/items/UOM, item invoices): `reference/inventory.md`\r
- Error handling and troubleshooting: `reference/errors.md`