jaz-clio 5.46.14 → 5.47.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-api
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill whenever you call, debug, or review code that touches the Jaz
6
6
  REST API. Covers field names, response shapes, 159 production gotchas, error
@@ -115,7 +115,7 @@ The rest of this skill — field names, gotchas, error catalog, dependency order
115
115
  28. **CN refunds use the same Payment shape** as invoice/bill payments — `paymentAmount`, `transactionAmount`, `accountResourceId`, `paymentMethod`, `valueDate`, `reference`. The API also accepts aliases `refundAmount`/`refundMethod` (see Rule 53) but prefer canonical `paymentAmount`/`paymentMethod` for consistency.
116
116
 
117
117
  ### Inventory Items
118
- 29. **Inventory items require**: `unit` (e.g., `"pcs"`), `costingMethod` (`"FIXED"` or `"WAC"`), `cogsResourceId`, `blockInsufficientDeductions`, `inventoryAccountResourceId`. `purchaseAccountResourceId` MUST be Inventory-type CoA.
118
+ 29. **Inventory items** (`POST /inventory-items`, verified live 2026-09-02): required are `itemCode`, `name`, `unit` (e.g. `"pcs"` — a blank unit returns `ITEM_UNIT_EMPTY_ERROR`), `costingMethod` (`"FIXED"` or `"WAC"`), `cogsResourceId` and `blockInsufficientDeductions` (send `false` explicitly — omitting it 422s, it is not defaulted server-side). Send `name`: the endpoint declares no `name` property and marks `internalName` required, but the API populates `internalName` from the `name` you send. The two account links are TYPE-constrained and the errors name the type: `cogsResourceId` must be **Direct Costs** (`INVALID_ACCOUNT_TYPE_DIRECT_COST`), `purchaseAccountResourceId` must be **Inventory** (`INVALID_ACCOUNT_TYPE_INVENTORY`) — an inventory purchase debits the asset, and COGS is recognised on sale. The API reports `purchaseAccountResourceId`, `saleAccountResourceId`, `appliesToSale` and `appliesToPurchase` as "required if [cogsResourceId] is present" — but `cogsResourceId` is itself always required, so all four are unconditional too. `appliesToSale` and `appliesToPurchase` must both be **`true`**, not merely present: `false` returns `APPLIES_TO_SALE_ERROR` / `APPLIES_TO_PURCHASE_ERROR` ("must be true when cogs selected"), so an inventory-tracked item with COGS is necessarily both sale- and purchase-applicable. There is no `inventoryAccountResourceId` — it appears in no request schema and a create succeeds without it.
119
119
  30. **Delete inventory items via `DELETE /items/:id`** — not `/inventory-items/:id`.
120
120
 
121
121
  ### Cash Transfers
@@ -882,7 +882,7 @@ Always wrap in `{ payments: [...] }` even for single payment.
882
882
  **CRITICAL notes from live testing**:
883
883
  - POST uses `name`, GET returns both `customFieldName` and `name`
884
884
  - Valid `type` values: `"TEXT"`, `"DATE"`, `"DROPDOWN"` (UPPERCASE)
885
- - `printOnDocuments` is REQUIRED — omitting it causes 400
885
+ - `printOnDocuments` is REQUIRED and is not defaulted server-side — omitting it returns 422 `printOnDocuments is a required field` (probed 2026-09-02; recorded as a 400 before that). `create_custom_field` sends `false` when you omit it.
886
886
  - Do NOT send `appliesTo` field — causes "Invalid request body"
887
887
  - Only send: `name`, `type`, `printOnDocuments` (and `options` for DROPDOWN)
888
888
  - For DROPDOWN type, `options` array works (without `appliesTo`)
@@ -949,7 +949,7 @@ Returns full custom field definition including `applyToSales`, `applyToPurchase`
949
949
  ```json
950
950
  // Request:
951
951
  {
952
- "internalName": "Widget A",
952
+ "name": "Widget A",
953
953
  "itemCode": "WDG-A",
954
954
  "unit": "pcs",
955
955
  "appliesToSale": true,
@@ -964,8 +964,7 @@ Returns full custom field definition including `applyToSales`, `applyToPurchase`
964
964
  "purchaseTaxProfileResourceId": "uuid-tax",
965
965
  "costingMethod": "WAC",
966
966
  "cogsResourceId": "uuid-direct-costs",
967
- "blockInsufficientDeductions": false,
968
- "inventoryAccountResourceId": "uuid-inventory-account"
967
+ "blockInsufficientDeductions": false
969
968
  }
970
969
 
971
970
  // Response:
@@ -973,10 +972,15 @@ Returns full custom field definition including `applyToSales`, `applyToPurchase`
973
972
  ```
974
973
 
975
974
  **CRITICAL notes from live testing**:
975
+ - Send `name`, not `internalName`. The endpoint declares no `name` property and marks `internalName` required, but the API populates `internalName` from the `name` you send (verified by readback 2026-09-02)
976
976
  - `unit` is REQUIRED (e.g., `"pcs"`, `"box"`, `"kg"`) — omitting causes ITEM_UNIT_EMPTY_ERROR
977
+ - `blockInsufficientDeductions` is REQUIRED and is NOT defaulted server-side — omitting it fails with "blockInsufficientDeductions is a required field"
977
978
  - `costingMethod` must be `"FIXED"` or `"WAC"` (NOT `"FIXED_COST"`)
978
- - `purchaseAccountResourceId` MUST point to an Inventory-type CoA account (NOT Direct Costs) — wrong type causes INVALID_ACCOUNT_TYPE_INVENTORY
979
- - `inventoryAccountResourceId` also must be Inventory-type
979
+ - `cogsResourceId` is required, and MUST point to a Direct Costs account — wrong type causes INVALID_ACCOUNT_TYPE_DIRECT_COST
980
+ - `purchaseAccountResourceId` MUST point to an Inventory-type CoA account (NOT Direct Costs) — wrong type causes INVALID_ACCOUNT_TYPE_INVENTORY. An inventory purchase debits the asset; COGS is recognised on sale
981
+ - Because `cogsResourceId` is always required, so are `purchaseAccountResourceId`, `saleAccountResourceId`, `appliesToSale` and `appliesToPurchase` — the API reports them as "required if [cogsResourceId] is present", but that condition always holds
982
+ - `appliesToSale` and `appliesToPurchase` must both be `true`, not merely present: `false` returns APPLIES_TO_SALE_ERROR / APPLIES_TO_PURCHASE_ERROR, "must be true when cogs selected". An inventory-tracked item with COGS is necessarily both sale- and purchase-applicable
983
+ - There is no `inventoryAccountResourceId` — it appears in no request schema and a create succeeds without it
980
984
  - Delete inventory items via `DELETE /items/:id` (NOT `/inventory-items/:id`)
981
985
  - `GET /inventory-item-balance/:id` returns balance per item
982
986
  - `GET /inventory-balances/:status` currently returns 500 (known bug)
@@ -90,9 +90,10 @@ Or call `list_account_classifications` — authoritative for that organisation.
90
90
 
91
91
  ## Custom Field Errors
92
92
 
93
- ### "Invalid request body" (400) — missing printOnDocuments
94
- **Cause**: Missing the required `printOnDocuments` field.
95
- **Fix**: Always include `printOnDocuments: false` (or `true`) in POST body.
93
+ ### "printOnDocuments is a required field" (422) — missing printOnDocuments
94
+ **Cause**: Missing the required `printOnDocuments` field. It is not defaulted server-side.
95
+ **Fix**: Always include `printOnDocuments: false` (or `true`) in POST body. `create_custom_field` now sends `false` when you omit it, so this only bites a direct API caller.
96
+ **Note**: recorded here as a 400 "Invalid request body" until 2026-09-02, when a live probe returned `422 validation_error` with the field named. Either the API tightened or the original entry generalised from a different malformed body; the 422 is what it returns today.
96
97
  ```json
97
98
  { "name": "PO Number", "type": "TEXT", "printOnDocuments": false }
98
99
  ```
@@ -259,7 +259,7 @@ Body for all three: `{ items: [{btResourceId: "<uuid>", btType: "SALE|PURCHASE|S
259
259
  | DELETE | `/items/:resourceId` | Delete item |
260
260
  | POST | `/items/search` | Advanced search with filters |
261
261
  | POST | `/items/bulk-upsert` | Bulk create/update items (max 500) |
262
- | POST | `/inventory-items` | Create inventory item (needs `unit`, `costingMethod`, `cogsResourceId`, `blockInsufficientDeductions`, `inventoryAccountResourceId`) |
262
+ | POST | `/inventory-items` | Create inventory item (needs `name`, `itemCode`, `unit`, `costingMethod`, `cogsResourceId` (Direct Costs), `purchaseAccountResourceId` (Inventory), `saleAccountResourceId`, `blockInsufficientDeductions`) |
263
263
  | GET | `/inventory-items` | List inventory items |
264
264
  | GET | `/inventory-item-balance/:resourceId` | Get inventory balance |
265
265
  | GET | `/inventory-balances/:balanceStatus` | List by status (**known 500 bug**) |
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-cli
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill when running Clio CLI commands, building shell scripts with
6
6
  Clio, debugging auth issues, understanding --json output, paginating results,
@@ -362,6 +362,9 @@ Body shape (all 3): `{ items: [{ btResourceId, btType }] }` with `btType ∈ {SA
362
362
  |------------|-----------|
363
363
  | `items` | `--limit`, `--offset`, `--all`, `--format`, `--json` |
364
364
  | `balance <itemId>` | `--json` |
365
+ | `create` | `--item-code`, `--name`, `--unit`, `--costing-method`, `--cogs-account`, `--purchase-account`, `--sale-account`, `--block-insufficient`, `--input` |
366
+
367
+ All seven of `--item-code`, `--name`, `--unit`, `--costing-method`, `--cogs-account`, `--purchase-account` and `--sale-account` are required. `--cogs-account` must be a Direct Costs account and `--purchase-account` an Inventory account. There are no `--sale`/`--purchase` flags: the API rejects either as false once COGS is set, so both are always sent as `true`.
365
368
 
366
369
  ---
367
370
 
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-conversion
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill when migrating accounting data into Jaz — importing from Xero,
6
6
  QuickBooks, Sage, MYOB, or Excel exports. Covers the full conversion pipeline:
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-kit
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill when an accountant, bookkeeper, or owner is running real books
6
6
  in Jaz across one or more organizations from the terminal — setting up a
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-pseudo-sql
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill when answering ad-hoc data questions that aren't covered by
6
6
  download_export (canonical reports — anomaly, audit, aging, P&L, BS, GL,
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-jobs
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill for recurring accounting workflows — month/quarter/year-end
6
6
  close, bank reconciliation, GST/VAT filing, payment runs, credit control,
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: jaz-recipes
3
- version: 5.46.14
3
+ version: 5.47.1
4
4
  description: >-
5
5
  Use this skill when modeling complex multi-step accounting transactions —
6
6
  anything that spans multiple periods, involves changing amounts, or requires