feat: add buildCreateDocumentPayload + normalizeCreateDocumentResponse#13
Conversation
Adds support for POST /accounting/documents/create/ so consumers can issue SUMIT accounting documents (חשבון עסקה / Transaction Invoice, חשבונית מס, etc.) without going through a card charge. Useful for proposal/quote → invoice flows where the document is generated up front and payment is collected separately. - buildCreateDocumentPayload(params): assembles the request body. Items default TotalPrice to UnitPrice * Quantity; Customer.SearchMode defaults to 0 (this endpoint differs from the charge endpoints where SearchMode=2 is the typical upsert). - normalizeCreateDocumentResponse(response): surfaces success as eventType="document.created" with documentId, documentNumber, and documentDownloadUrl. Failures normalize to "document.failed" with redacted error messages. - SUMIT_DOCUMENT_TYPE.TransactionInvoice = 1. Other SUMIT document type codes are accepted as plain numbers. - currencyToSumitString helper — the documents endpoint takes literal "ILS"/"USD"/"EUR" strings, unlike the charge endpoints' numeric codes. - NormalizedSumitEvent gains documentNumber and documentDownloadUrl. Zero new runtime dependencies. 9 new tests; 23 total passing. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: af6456efa0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| Credentials: { CompanyID: params.companyId, APIKey: params.apiKey }, | ||
| Details: details, | ||
| Items: items, | ||
| Payments: [] as never[], |
There was a problem hiding this comment.
When callers follow the new API docs and pass a receipt or tax-invoice-receipt documentType, this builder still always sends Payments: [] and the public params type has no way to provide payment rows. SUMIT paid-document types need populated payments to represent the collected amount, so those calls will either fail validation or create an unusable document despite the helper claiming arbitrary document type codes are supported.
Useful? React with 👍 / 👎.
1 participant
Summary
buildCreateDocumentPayload+normalizeCreateDocumentResponseforPOST /accounting/documents/create/, so consumers can issue SUMIT accounting documents (חשבון עסקה / Transaction Invoice, חשבונית מס, etc.) without going through a card charge.SUMIT_DOCUMENT_TYPE(currentlyTransactionInvoice = 1) andcurrencyToSumitString(the documents endpoint takes literal"ILS"/"USD"/"EUR"strings, unlike the charge endpoints' numeric codes).NormalizedSumitEventwithdocumentNumberanddocumentDownloadUrl, and adds"document.created"/"document.failed"toSumitNormalizedEventType.Why
This unlocks Quoty's "convert accepted proposal → חשבון עסקה in SUMIT" integration. Without a builder for
/accounting/documents/create/, consumers had to fall back to hand-rolled payloads (with all the redaction/typing risks).Test plan
pnpm test— 23 passing (9 new)pnpm typecheckpnpm build🤖 Generated with Claude Code