Credit Note — entity reference

A credit document that reduces what a party owes, and the merged home of three different documents discriminated by TransactionType: null/empty is a pure financial AR credit note (Dr Sales / Cr AR, party = AccountId); "SaleReturn" is a customer goods return (the mirror of an Invoice, revenue and AR reversal, lines carry items and post to inventory); "BillReturn" is a purchase return to a supplier (Dr AP / Cr GR-IR plus input-tax reversal, party = SupplierAccountId). CreditNoteHandler gates almost all return behaviour on this discriminator, so the same entity behaves as three documents and a query that ignores TransactionType mixes sales and purchase traffic. Children are CreditNoteLine; it can point at the Invoice, DeliveryOrder, GoodsReceipt or PurchaseOrder it reverses, and at the Claim that generated it. Settlement against open invoices is recorded as PaymentAdjustment rows (legacy) or SettlementAllocation against an OpenTransaction (the current open-item engine).

Fields

Field	Label	Type	Required	What it does
`AccountId`	Account	Lookup → Account		The customer the note is issued to, and the party the ledger posts against for the financial CreditNote and SaleReturn purposes. A BillReturn credit note does NOT use this field — its party is SupplierAccountId — so party analysis over credit notes must branch on TransactionType.
`AdjustedAmount`	Adjusted Amount	Currency		How much of the note's value has already been consumed settling other documents. It is maintained by the settlement code (the claim-engine credit application and the payment-adjustment service), not by the user, and OpenAmount is kept as Amount minus this value.
`Amount`	Amount	Calculated (calculated)		Calculated field: the sum of CreditNoteLine.Amount over the note's lines. It is the note's face value and the base of OpenAmount (OpenAmount = Amount - AdjustedAmount when a settlement is applied), not a user-entered figure.
`BranchId`	Branch	Lookup → Branch
`ClaimId`	Claim	Lookup → Claim
`CreatedById`	Created By	Lookup → UserAccount	Yes
`CreatedDateTime`	Created Date	DateAndTime	Yes
`Currency`	Currency	PickList		Values: INR, GBP.
`DeliveryOrderId`	Delivery Order	Lookup → DeliveryOrder		The outbound delivery the returned goods came out on, for sale-return notes; return quantities are written back to its lines. Purchase-return notes instead RELEASE a delivery order for the goods going back to the vendor, via the PerformReleaseDelivery / SelectiveDeliveryOrder actions.
`DeliveryOrderLineId`	Delivery Order Line	Lookup → DeliveryOrderLine
`Description`	Description	Text
`DiscountGroupId`	Discount Group	Lookup → DiscountGroup
`DocumentDate`	Document Date	Date	Yes	The note's accounting date — the date every posting purpose for this entity uses to date its journal, so it decides which fiscal period the credit lands in. Defaulted to the current date when a sale-return note is created.
`DueDate`	Due Date	Date
`ExternalId`	External	Text
`GeneralLedgerId`	General Ledger	Lookup → GeneralLedger		Legacy pointer to the decommissioned GeneralLedger entity, retained on the row and guarded as a system field. The current ledger links the other way: Journal.SourceEntityName + Journal.SourceRecordId identify the document that produced the journal.
`GLAccountId`	GL Account	Lookup → GLAccount		An explicit header (control) GL account for the note. Where a posting purpose opts into it, this beats PostingDefinition and chart-of-accounts resolution, which is how a charge lands in the same subledger as the document it relates to instead of whichever account resolution by type would pick.
`GLAmount`	GL Amount	Calculated (calculated)		Calculated as a copy of Amount, and the header-side amount the financial CreditNote posting purpose uses when the note has no lines to post. Note the asymmetry: the CreditNote purpose reads GLAmount on the lines too, while the SaleReturn (Return) and BillReturn purposes read CreditNoteLine.Amount instead.
`GoodsReceiptId`	Goods Receipt	Lookup → GoodsReceipt
`Id`	Id	Guid	Yes
`InvoiceId`	Invoice	Lookup → Invoice		The customer invoice this note credits or returns against. It is the audit link to the original supply — GST credit/debit-note reporting quotes the original invoice — but it does NOT itself settle the invoice: settlement is a separate PaymentAdjustment or SettlementAllocation row.
`IsGLPosted`	Is GL Posted	Boolean	Yes	A legacy posting marker guarded as a system field (a client attempting to change it is rejected). No first-party code sets it on a credit note under the journal-based ledger, so it stays false even on fully posted notes — do not use it to test whether a note has posted. The reliable test is the existence of a Journal whose SourceEntityName is "CreditNote" and SourceRecordId is this row, or the note's OpenTransaction.
`IsGLPostingApproved`	Is GL Posting Approved	Boolean	Yes	The flag that actually triggers ledger posting. When it is true as the note is saved, the handler posts the note through DocumentJournalPostingService under the purpose chosen by TransactionType and captures the GST tax transactions.
`IsInJobQueue`	In Job Queue	Boolean
`IsReturned`	Returned	Boolean		Set true by the handler when PerformReturn is approved on a purchase-return (BillReturn) note; it marks the return as executed. Not maintained on financial or sale-return notes.
`ItemId`	Item	Lookup → Item
`JobInterfaceQueueId`	Job Queue	Lookup → InterfaceQueue
`LineSubTotal`	Line Sub Total	Calculated
`ModifiedById`	Modified By	Lookup → UserAccount
`Name`	Name	Text	Yes
`Notes`	Notes	LongMultiLineText
`OpenAmount`	Open Amount	Calculated		The unconsumed balance of the credit note — a STORED column recomputed as Amount minus AdjustedAmount whenever a settlement is applied, not a live formula. Zero means the credit is fully consumed; the credit-application pass skips notes with nothing left. For an authoritative party balance prefer the matching OpenTransaction row, which the ledger maintains.
`OwnerId`	Owner	Lookup → UserAccount	Yes
`PartnerAccountId`	Partner Account	Lookup → Account		The trading partner (dealer/distributor) the note belongs to, used for branch validation on sale returns and as the key the credit-application pass uses to find that partner's open invoices. Distinct from AccountId (the customer) and SupplierAccountId (the vendor).
`PerformGLPosting`	Perform GL Posting	Boolean	Yes
`PerformInventoryPosting`	Perform Inventory Posting	Boolean		Request flag for posting the note's lines to the inventory ledger. The PerformInventoryPosting action is what performs it, and it validates first: if every CreditNoteLine already carries an InventoryLedgerId the invoke fails with "No Credit Note Lines found for Inventory Posting".
`PerformReturn`	Perform Return	Boolean		Two distinct meanings by TransactionType. On a SaleReturn note it drives the PerformReturn action, which builds return lines from the invoice lines the user picked. On a BillReturn note, setting it true during a save makes the handler flip IsReturned to true and reset this flag back to false — so it behaves as a one-shot trigger, not a state.
`PlaceOfSupply`	Place of Supply	PickList
`PriceAsOnDate`	Price As On Date	Date
`PriceListId`	Price List	Lookup → PriceList
`PriceListRuleId`	Price List Rule	Lookup → PriceListRule
`PurchaseOrderId`	Purchase Order	Lookup → PurchaseOrder
`RecordTypeId`	Record Type	Guid, hidden
`Remarks`	Remarks	Text
`ResourceId`	Executive	Lookup → Resource
`RoundOff`	Round Off	Currency
`SourceOfSupply`	Source of Supply	PickList
`Status`	Status	PickList
`SupplierAccountId`	Supplier Account	Lookup → Account		The vendor a purchase-return (TransactionType "BillReturn") credit note is raised on, and the party its Dr Accounts Payable posting hits. Validated to be an account flagged as a supplier on insert and update. Null on financial and sale-return notes.
`SupplierInvoiceAmount`	Supplier Invoice Amount	Currency
`SupplierInvoiceDate`	Supplier Invoice Date	Date
`SupplierInvoiceNumber`	Supplier Invoice Number	Text		The vendor's own document number for the purchase being returned, carried on a BillReturn note for reconciliation against the supplier's books and for GST credit-note reporting on the inward side. Free text supplied by the user, not a link.
`TaxSupplyType`	Tax Supply Type	PickList
`TotalAmount`	Total Amount	Calculated (calculated)		A calculated total whose stored formula sums a "ReturnLines" collection — the child navigation of the pre-merge Return document. The merged CreditNote type exposes its children as CreditNoteLines only, so do not rely on this column: sum CreditNoteLine directly (GrossAmount for the gross figure) when the number matters. The same caveat applies to the other Total* columns on this entity.
`TotalDiscountAmount`	Total Discount Amount	Calculated (calculated)		Calculated total of line net discount, summing the pre-merge "ReturnLines" collection rather than CreditNoteLines — unreliable; sum CreditNoteLine.NetDiscount directly.
`TotalLineAmount`	Total Line Amount	Calculated (calculated)		Calculated total of the line amounts, but its stored formula sums the pre-merge "ReturnLines" collection rather than CreditNoteLines — treat the value as unreliable and sum CreditNoteLine.Amount directly.
`TotalLineBaseAmount`	Total Line Base Amount	Calculated (calculated)		Calculated total of line base (pre-discount, pre-tax) amounts, summing the pre-merge "ReturnLines" collection rather than CreditNoteLines — unreliable; sum CreditNoteLine.BaseAmount directly.
`TotalLineGrossAmount`	Total Line Gross Amount	Calculated (calculated)		Header amount the BillReturn (purchase-return) posting purpose reads when posting the note, calculated over the pre-merge "BillReturnLines" collection — the same stale-navigation caveat as the other Total* columns applies, so verify against CreditNoteLine.GrossAmount.
`TotalLineTaxAmount`	Total Line Tax Amount	Calculated (calculated)		Calculated total of line tax, summing the pre-merge "ReturnLines" collection rather than CreditNoteLines — unreliable on merged credit notes; sum CreditNoteLine.TaxAmount directly.
`TotalSchemeDiscountAmount`	Total Scheme Amount	Calculated (calculated)		Calculated total of scheme discount on the lines (labelled "Total Scheme Amount"), summing the pre-merge "ReturnLines" collection rather than CreditNoteLines — unreliable; sum CreditNoteLine.NetSchemeDiscount directly.
`TotalTaxAmount`	Total Tax Posting Amount	Currency		A stored (non-calculated) decimal labelled "Total Tax Posting Amount". Easy to confuse with TotalTaxAmount2, which is labelled "Total Tax Amount" and IS calculated — the two names and the two labels are crossed, so check which column a screen or query actually means. Neither is the note's true total tax; sum CreditNoteLine.TaxAmount for that.
`TotalTaxAmount2`	Total Tax Amount	Calculated (calculated)		Despite its label "Total Tax Amount" this is a calculated sum of a single tax slot only — Tax2 across the lines — and it sums the pre-merge "ReturnLines" collection at that. It is not the note's total tax. Use CreditNoteLine.TaxAmount for the real figure.
`TransactionType`	Transaction Type	PickList		The discriminator that decides which of three documents this row is, and therefore how it posts: null or empty = financial AR credit note (CreditNote posting purpose, party AccountId), "SaleReturn" = customer goods return (Return purpose, revenue/AR reversal), "BillReturn" = purchase return to a supplier (BillReturn purpose, party SupplierAccountId). Validation, defaults, inventory posting and the delivery-release actions are all gated on it. Filter on it before aggregating credit notes — otherwise sales and purchase traffic land in the same total. Values: SaleReturn, BillReturn, Claim Settlement.
`UIProps`	UI Props	Text
`UpdatedDateTime`	Modified Date	DateAndTime	Yes

Actions

Action	Label	Type	What it does
`BulkDelete`	Delete	Delete	Delete the selected records.
`Clone`	Clone	ServerAction (`Clone`)	Create a copy of this record
`Delete`	Delete	Delete	Delete
`DeleteInList`	Delete	Delete	Delete in a list page
`Edit`	Edit	Edit	Edit
`EditInLine`	Edit	Edit	Edit in page.
`EditInLine1`	Edit	EditInline	Edit
`EditListRow`	Edit	Edit, inactive	EditListRow
`New`	New	New	New
`PerformReturn`	Perform Return	ServerAction (`PerformReturn`)	On a sale-return credit note, creates CreditNoteLine rows from the invoice lines passed in the action payload (an "InvoiceLines" array). The quantity write-backs to the Invoice, DeliveryOrder and Order lines are NOT done here — inserting the lines runs the line handler, which owns those aggregates and recomputes them as a SUM, so they stay correct when a line is later edited or removed.
`PostAdjustments`	Post Adjustments	ServerAction (`PostAdjustments`)	Advertised as a supported action on this entity, but the credit-note handler has no dispatch branch for it: invoking it reaches the handler and falls through to a NotSupportedException, and the seeded action row asks for no confirmation, so the user sees a raw error. Do not describe it as posting anything. Credit-note settlement is actually recorded by creating PaymentAdjustment rows (the claim-settlement path nets a note against the partner's open invoices oldest-first) or, on the current open-item engine, SettlementAllocation rows against the note's OpenTransaction.
`PostGeneralLedger`	Post General Ledger	ServerAction (`PostGeneralLedger`)	Sets IsGLPostingApproved on the note and saves it; the save pipeline is what posts. The handler then posts through DocumentJournalPostingService under the purpose chosen by TransactionType — CreditNote (Dr Sales / Cr AR) for a financial note, Return (revenue and AR reversal) for a sale return, BillReturn (Dr AP / Cr GR-IR plus input-tax reversal, party SupplierAccountId) for a purchase return — creating one balanced journal plus the note's OpenTransaction, and captures GST tax transactions afterwards (outward for sales notes, inward for purchase returns). Posting is append-only: re-posting an already-posted document produces reversal journals rather than editing the ledger. A GST capture failure is swallowed and never blocks the ledger posting.

Lookup filters

Filter	Lookup field	Notes
Branch For Partner Account	`BranchId`
Customer Account Filter	`AccountId`
Partner Account Filter	`PartnerAccountId`

UserAccount — looks up via CreatedById
PurchaseOrder — looks up via PurchaseOrderId
Branch — looks up via BranchId
DeliveryOrderLine — looks up via DeliveryOrderLineId
InterfaceQueue — looks up via JobInterfaceQueueId
PriceListRule — looks up via PriceListRuleId
Invoice — looks up via InvoiceId
Claim — looks up via ClaimId
GoodsReceipt — looks up via GoodsReceiptId
Account — looks up via AccountId
Account — looks up via SupplierAccountId
Item — looks up via ItemId
DeliveryOrder — looks up via DeliveryOrderId
GeneralLedger — looks up via GeneralLedgerId
DiscountGroup — looks up via DiscountGroupId
UserAccount — looks up via OwnerId
UserAccount — looks up via ModifiedById
Account — looks up via PartnerAccountId
PriceList — looks up via PriceListId
GLAccount — looks up via GLAccountId
Resource — looks up via ResourceId
PaymentAdjustment — referenced by via CreditNoteId
OpenTransaction — referenced by via SourceRecordId
Journal — referenced by via SourceRecordId
Payment — referenced by via CreditNoteId
CreditNoteLine — referenced by via CreditNoteId
InterestCharge — referenced by via SourceRecordId

Credit Note — entity reference

Fields

Actions

Lookup filters

Related entities

Related topics