fix: correct DocumentType enum, numeric Language, drop empty Payments#14
Conversation
Real-world smoke-test against SUMIT's /accounting/documents/create/
surfaced four divergences between 0.3.0 and what SUMIT actually accepts:
1. DocumentType=1 created a חשבונית מס-קבלה (Tax Invoice-Receipt), not
the pre-payment "חשבון עסקה" we claimed. The correct value for
ProformaInvoice is 3, per SUMIT's Accounting_Typed_DocumentType enum.
SUMIT_DOCUMENT_TYPE is now expanded to cover the full enum; the
incorrect TransactionInvoice=1 constant is retained as a deprecated
alias for backwards compatibility.
2. Details.Language as a string ("he"/"en") was rejected with:
"Details.Language: Error converting value \"he\""
SUMIT's Accounting_Typed_Language is a numeric enum
(0=Hebrew, 1=English, 2=Arabic, 3=Spanish). The helper now accepts
either a numeric code or the shorthand strings and converts. New
SUMIT_LANGUAGE constant exposes the enum.
3. Empty Payments arrays were rejected on document creation. The
payload now omits the Payments key entirely.
4. Customer.SearchMode was hardcoded to 0, which prevented upserts.
It's now derived: SUMIT id -> 1, ExternalIdentifier -> 2, else 0.
Explicit caller value still wins.
Also strips whitespace-only optional fields (emailAddress, phone, taxId,
item description, sku, etc.) — SUMIT rejects empty strings on several
optional fields rather than treating them as absent.
9 new tests; 27 total passing. Zero new runtime dependencies.
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: 534438e2ad
ℹ️ 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".
| // supplied, and 0 (create new) otherwise. Matches SUMIT's documented modes. | ||
| const derivedSearchMode: SumitCustomerSearchMode = | ||
| params.customer.searchMode ?? | ||
| (params.customer.id ? 1 : params.customer.externalIdentifier ? 2 : 0); |
There was a problem hiding this comment.
When customer.id is a whitespace-only value and externalIdentifier is also present, this truthiness check selects SearchMode: 1, but the later blankToUndefined(params.customer.id) omits ID from the payload. That leaves a request that asks SUMIT to search by ID without sending an ID, so the valid ExternalIdentifier path is not used; this can happen with optional form fields that arrive as spaces, which this change otherwise tries to strip.
Useful? React with 👍 / 👎.
1 participant
Summary
Smoke-testing 0.3.0 against the live SUMIT API surfaced four divergences between the helper and what SUMIT actually accepts.
SUMIT_DOCUMENT_TYPE.TransactionInvoice = 1was wrong — code1is InvoiceAndReceipt (חשבונית מס-קבלה). The correct value for the pre-payment "חשבון עסקה" isProformaInvoice = 3. Expanded the constant to cover the fullAccounting_Typed_DocumentTypeenum; keptTransactionInvoiceas a deprecated alias.Details.Language: "he"withError converting value "he". It's actuallyAccounting_Typed_Language— a numeric enum (Hebrew=0,English=1, …). The helper now accepts both numeric codes and the shorthand strings"he"/"en"/"ar"/"es"and converts. NewSUMIT_LANGUAGEconstant.Payments: []on document creation. The payload now omits thePaymentskey.Customer.SearchModewas hardcoded to0, preventing upserts. Now derived —id⇒1,externalIdentifier⇒2, else0. Explicit caller value still wins.Also strips whitespace-only optional fields (
emailAddress,phone,taxId, itemdescription,sku, etc.) — SUMIT rejects empty strings on several optional fields.Test plan
pnpm test— 27 passing (9 new for the new behaviors)pnpm typecheckpnpm builddocumentType: 3,language: "he"(auto-converted), andexternalIdentifier(auto SearchMode=2).Breaking changes
None for code that passes numeric
documentTypedirectly. Code usingSUMIT_DOCUMENT_TYPE.TransactionInvoicewill keep compiling (alias) but produces the wrong document type — release notes call this out explicitly so consumers update to.ProformaInvoice.🤖 Generated with Claude Code