AutoCount

Use this skill to create or test AutoCount documents through the AutoCount Web API.

Supported document work in this skill:

• sales invoice
• sales order / delivery order / credit note
• purchase invoice
• goods received note
• purchase order inspection/listing
• master-data lookup for debtors, creditors, items, locations, and currencies

Workflow

1. Confirm the base URL, API name, and API key.
2. Use the headers:
• X-API-NAME: 9999
• X-API-KEY: 9999
• Content-Type: application/json
3. Prefer SaveAsDraft: true unless the user explicitly wants final posting.
4. For transfer chains, the source document must be final (SaveAsDraft: false). Draft purchase documents cannot be used as transfer sources.
5. Prefer AutoCount defaults (<<>>) over guessed business values.
6. Do not hardcode tax codes. Use defaults or system-derived values only.
7. After each create call, fetch the created record and report the actual document number.

Known API pattern

Base URL example:

• http://your-autocount-host:9999

Headers example:

X-API-NAME: <your-api-name>
X-API-KEY: <your-api-key>
Content-Type: application/json

Endpoints verified

Sales

• POST {{localURL}}/api/SalesOrder/CreateRecord
• GET {{localURL}}/api/SalesOrder/GetRecord?docKey=...
• POST {{localURL}}/api/DeliveryOrder/CreateRecord
• GET {{localURL}}/api/DeliveryOrder/GetRecord?docKey=...
• POST {{localURL}}/api/Invoice/CreateRecord
• GET {{localURL}}/api/Invoice/GetRecord?docKey=...
• POST {{localURL}}/api/CreditNote/CreateRecord
• GET {{localURL}}/api/CreditNote/GetRecord?docKey=...
• POST {{localURL}}/api/CreditNote/UpdateRecord?docKey=...
• POST {{localURL}}/api/CreditNote/CancelRecord?docKey=...
• POST {{localURL}}/api/CreditNote/DeleteRecord?docKey=...

Purchase

• POST {{localURL}}/api/PurchaseOrder/CreateRecord
• POST {{localURL}}/api/PurchaseOrder/UpdateRecord?docKey=...
• POST {{localURL}}/api/PurchaseInvoice/CreateRecord
• POST {{localURL}}/api/GoodsReceivedNote/CreateRecord
• GET {{localURL}}/api/PurchaseOrder/GetRecord?docKey=...
• POST {{localURL}}/api/PurchaseOrder/GetRecordList
• GET {{localURL}}/api/GoodsReceivedNote/GetRecord?docKey=...
• POST {{localURL}}/api/GoodsReceivedNote/GetRecordList
• GET {{localURL}}/api/PurchaseInvoice/GetRecord?docKey=...

Master data

• GET {{localURL}}/api/Debtor/GetRecordList
• GET {{localURL}}/api/Creditor/GetRecordList
• GET {{localURL}}/api/Item/GetRecordList
• GET {{localURL}}/api/Location/GetRecordList
• GET {{localURL}}/api/Currency/GetRecordList

Core rules

Defaults

Use AutoCount defaults where supported:

• DocNo: "<<>>"
• DocNoFormatName: "<<>>"
• DebtorName: "<<>>" when not enriching from master data
• DisplayTerm: "<<>>"
• CurrencyCode: "<<>>"
• address/phone/attention fields may also accept <<>>
• TaxCode: "<<>>" is preferred over manually forcing a tax code

Draft option

"Options": {
  "DocNoFormatName": "<<<Default>>>",
  "SaveAsDraft": true
}

Reporting rule

After a successful create:

1. capture the returned docKey
2. call the matching GetRecord endpoint
3. report back at least:
• DocNo
• DocKey
• party code/name
• total/final total

Sales invoice pattern

Minimal stable sales invoice template

{
  "Master": {
    "DocNo": "<<<Default>>>",
    "DocDate": "2026-03-27",
    "DebtorCode": "SS29",
    "DebtorName": "<<<Default>>>",
    "SalesLocation": "HQ",
    "DisplayTerm": "<<<Default>>>",
    "CurrencyCode": "<<<Default>>>"
  },
  "Details": [
    {
      "ItemCode": "00001",
      "UOM": "METER",
      "UserUOM": "<<<Default>>>",
      "Location": "HQ",
      "Description": "<<<Default>>>",
      "Qty": 2,
      "UnitPrice": 22.22,
      "TaxCode": "<<<Default>>>",
      "Classification": "010",
      "OriginCountryCode": "MYS"
    }
  ],
  "Options": {
    "DocNoFormatName": "<<<Default>>>",
    "SaveAsDraft": true
  }
}

Purchase-side pattern

Purchase documents use a similar body shape to sales invoices, but with purchase-side party/location fields.

Purchase invoice template

{
  "Master": {
    "DocNo": "<<<Default>>>",
    "CreditorCode": "400-S001",
    "CreditorName": "SUPPLIER",
    "PurchaseLocation": "HQ",
    "DocDate": "2026-03-27",
    "Description": "PURCHASE INVOICE",
    "DisplayTerm": "C.O.D.",
    "CurrencyCode": "MYR",
    "CurrencyRate": 1
  },
  "Details": [
    {
      "DeliveryDate": "2026-03-27",
      "ItemCode": "00002",
      "UOM": "SET",
      "UserUOM": "SET",
      "Location": "HQ",
      "Description": "SOFA 沙发",
      "Qty": 10,
      "FOCQty": 0,
      "UnitPrice": 1000,
      "Discount": "",
      "TaxCode": "<<<Default>>>"
    }
  ],
  "Options": {
    "DocNoFormatName": "<<<Default>>>",
    "SaveAsDraft": true
  }
}

Goods received note template

{
  "Master": {
    "DocNo": "<<<Default>>>",
    "SupplierDONo": "AUTO-GRN-20260327-01",
    "CreditorCode": "400-S001",
    "CreditorName": "SUPPLIER",
    "PurchaseLocation": "HQ",
    "DocDate": "2026-03-27",
    "Description": "GOODS RECEIVED NOTE",
    "DisplayTerm": "C.O.D.",
    "CurrencyCode": "MYR",
    "CurrencyRate": 1
  },
  "Details": [
    {
      "DeliveryDate": "2026-03-27",
      "ItemCode": "00002",
      "UOM": "SET",
      "UserUOM": "SET",
      "Location": "HQ",
      "Description": "SOFA 沙发",
      "Qty": 10,
      "FOCQty": 0,
      "UnitPrice": 1000,
      "Discount": "",
      "TaxCode": "<<<Default>>>"
    }
  ],
  "Options": {
    "DocNoFormatName": "<<<Default>>>",
    "SaveAsDraft": true
  }
}

SO → DO → Invoice guidance

Use this when the user wants sales document progression.

1. Create or inspect a final Sales Order first.
2. For transfer source documents, ensure the source is final, not draft.
3. For transfer creates, use transfer-only payloads:
• set Details: []
• populate TransferDetails[]
• do not include a matching manual detail row
4. SO → DO transfer:
• POST /api/DeliveryOrder/CreateRecord
• TransferDetails[].DocType = "SO"
5. DO → Invoice transfer:
• POST /api/Invoice/CreateRecord
• TransferDetails[].DocType = "DO"
6. Use SalesLocation on invoice payloads and sales-side master payloads where appropriate.
7. Set DocNo: "<<>>" and DocNoFormatName: "<<>>".
8. Use TaxCode: "<<>>" unless the system proves a specific value.
9. Fetch created records and report the final document numbers.

Proven live sales chain

A full sales chain was live-tested successfully:

• Sales Order → Delivery Order using DocType: "SO"
• Delivery Order → Invoice using DocType: "DO"

PO → GRN → PI guidance

Use this when the user wants purchase document progression.

1. List purchase orders with:
• POST /api/PurchaseOrder/GetRecordList and body {}
2. Inspect a specific PO with:
• GET /api/PurchaseOrder/GetRecord?docKey=...
3. For transfer source documents, ensure the source is final, not draft.
4. For transfer creates, use transfer-only payloads:
• set Details: []
• populate TransferDetails[]
• do not include a matching manual detail row, or AutoCount may create an extra unlinked line
5. PO → GRN transfer:
• POST /api/GoodsReceivedNote/CreateRecord
• TransferDetails[].DocType = "PO"
6. GRN → PI transfer:
• POST /api/PurchaseInvoice/CreateRecord
• TransferDetails[].DocType = "GR"
7. Direct PO → PI transfer is also supported on a fresh final PO:
• TransferDetails[].DocType = "PO"
8. Add GRN-specific SupplierDONo when creating GRNs.
9. Set DocNo: "<<>>" and DocNoFormatName: "<<>>".
10. Use TaxCode: "<<>>" unless the system proves a specific value.
11. Fetch created records and report the final document numbers.

Transfer payload rule

Use this pattern for transfer documents:

{
  "Master": {
    "DocNo": "<<<Default>>>",
    "DocDate": "2026-04-09",
    "CreditorCode": "400-S001",
    "CreditorName": "<<<Default>>>",
    "PurchaseLocation": "HQ",
    "DisplayTerm": "<<<Default>>>",
    "CurrencyCode": "<<<Default>>>",
    "CurrencyRate": "<<<Default>>>"
  },
  "Details": [],
  "TransferDetails": [
    {
      "DocType": "PO",
      "DocNo": "PO-000038",
      "ItemCode": "00002",
      "UOM": "SET",
      "TransferQty": 5,
      "TransferFOCQty": 0
    }
  ],
  "Options": {
    "DocNoFormatName": "<<<Default>>>",
    "SaveAsDraft": false
  }
}

Swap DocType as follows:

• PO for PO → GRN
• PO for PO → PI
• GR for GRN → PI
• SO for SO → DO
• DO for DO → Invoice

Proven live chain

A full purchase chain was live-tested successfully:

• Purchase Order → GRN using DocType: "PO"
• GRN → Purchase Invoice using DocType: "GR"

Balance and over-transfer notes

AutoCount tracks transfer quantity at table level even when the normal PO API does not expose it.

Observed relevant DB fields include:

• PODTL.Qty
• PODTL.TransferedQty
• PODTL.Transferable
• PIDTL.FromDocType
• PIDTL.FromDocNo

Working balance formula:

• remaining transferable qty = Qty - TransferedQty

Important: the standard PurchaseOrder/GetRecord API response did not expose TransferedQty, so automation should not assume the API will prevent over-transfer. Validate quantities before transfer when possible.

Update / cancel / delete safety

Treat these as real mutations.

1. Prefer testing update/cancel/delete only on fresh test documents unless the user clearly requests mutation on a real document.
2. UpdateRecord expects a clean create-style payload more often than a raw GetRecord echo.
3. CancelRecord and DeleteRecord are destructive.
4. After cancel/delete, a later GetRecord may return record-not-found.
5. Always report the exact affected DocNo and DocKey back to the user.

Confirmed live mutation routes

For Credit Note, the following worked in live testing:

• POST /api/CreditNote/UpdateRecord?docKey=...
• POST /api/CreditNote/CancelRecord?docKey=...
• POST /api/CreditNote/DeleteRecord?docKey=...

Observed behavior:

• update changed quantity and total successfully
• cancel returned true
• after cancel/delete testing, GetRecord returned record-not-found for the test document

Enrichment guidance

Before document creation, optionally fetch master data and copy display fields into the payload.

Sales enrichment

• DebtorName
• InvAddr1..4
• Phone1
• Attention
• DisplayTerm
• CurrencyCode

Purchase enrichment

• CreditorName
• supplier-related address/contact fields if available
• DisplayTerm
• CurrencyCode

Item enrichment

• Description
• valid UOM
• location-aware stock hints

This makes the final document more complete in the AutoCount UI.

Known findings from testing

• AutoCount Web API was reachable on port 9999 over HTTP in the tested environment.
• Root URL returned 404, which is normal for the service.
• Authentication uses headers, not curl basic auth:
• X-API-NAME
• X-API-KEY
• Sales order create/get worked.
• Delivery order create/get worked.
• Sales invoice create/get worked repeatedly.
• Credit note create/get worked.
• Credit note update worked.
• Credit note cancel worked.
• Credit note delete route worked and the test document became non-retrievable afterward.
• Purchase invoice create worked.
• GRN create worked.
• Purchase order create worked.
• Purchase order update worked when using a clean create-style payload against UpdateRecord?docKey=....
• PO list requires POST {} instead of GET.
• PO get worked with valid doc keys.
• Updating a draft PO with SaveAsDraft: false did not reliably convert it into a final transferable PO in UI testing; creating a fresh final PO was reliable.
• Transfer source docs must be final, not draft.
• For transfer documents, Details: [] plus TransferDetails[] worked; mixing Details[] with TransferDetails[] created an extra unlinked manual line.
• TransferDetails[].DocType values confirmed in live testing:
• PO for PO → GRN
• PO for PO → PI
• GR for GRN → PI
• GRN as a purchase invoice transfer doc type failed with Invalid transfer document.
• A full live chain succeeded: PO → GRN → PI.
• A full live chain succeeded: SO → DO → Invoice.
• Lean payloads can create documents, but UI-visible debtor/item display fields may remain blank unless explicitly enriched.
• Item 00001 worked repeatedly in sales invoices with:
• description: FABRIC
• UOM: METER
• origin country: MYS
• Item list response does not necessarily expose tax code fields.
• Do not manually force tax codes unless explicitly instructed or proven from system data.
• Using TaxCode: "<<>>" worked and is preferred.
• GRN create initially failed when DocNo was missing; adding DocNo: "<<>>" fixed it.
• Sales invoice route is /api/Invoice/CreateRecord, not /api/SalesInvoice/CreateRecord.
• Sales transfer doc types confirmed in live testing:
• SO for SO → DO
• DO for DO → Invoice

References

Read references/test-notes.md for the observed behavior and payload patterns discovered during live testing.