You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3a36dd3
Browse filesBrowse the repository at this point in the historyBrowse files
buildPaymentLines returned only invoice LinkedTxn entries, and the
unapplyOmittedInvoices path sent that array as the payment's entire Line
collection. Intuit documents Payment Line.LinkedTxn.TxnType as one of
Expense, Check, CreditCardCredit, JournalEntry, CreditMemo or Invoice, and
an update as "send all the Lines that need to be present MINUS the lines
that need to be removed" — so replacing invoice allocations silently
detached every applied credit memo, expense, check and journal entry.
Non-invoice lines are now carried forward first, in the order QuickBooks
returned them, and counted against the payment total.
Also aligned with Intuit's documented model:
- salesreceiptrequest requires only Line, refundreceiptrequest only
DepositToAccountRef and Line; neither lists CustomerRef, so customerId is
optional on both receipt paths and CustomerRef is emitted only when given.
- Line.Amount, SalesItemLineDetail.Qty and UnitPrice carry no positivity or
non-zero constraint, so zero is accepted (finite/2-decimal/safe-range
checks unchanged).
- Enforce the documented maximum lengths locally: DocNumber 21,
MemoRef.value 1000, Line.Description 4000.
- Add void_sales_receipt, the documented
salesreceipt?operation=update&include=void sparse void.
- read_sales_transactions maxResults description now says 1–1000, matching
validateQuickBooksPagination.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RB5M2gk7zZgGomnQqr7WRB
0 commit comments