🧾 Sales realization

The sales realization is the accounting boundary of the sales contour: it releases the reservation, writes stock out, recognises revenue and receivable, and accrues tax. The workspace object is SalesRealization; the menu shows Sales realizations.

← Business process wiki

User path: issue a sales realization. Wider contour: sales and purchasing.

How the process works#

A confirmed order creates a SalesRealization in Reserved. A POS sale can also create a draft sales realization directly. The realization state is moved by commands:

The UI caption of the final state is Released; the machine subtype is Issued. Existing scripts and tests still use Issued.

Settings#

Default tax setup#

Where: tax packages and TaxSettings, installed by the organisation setup. The sales realization asks ITaxService for the default output tax code.

The rate is stored as a fraction: 0.15 means 15%.

Payment term fallback#

Where: Sales → Settings → Sales settings, field Default payment term. The selected PaymentTerm contains Days. The old numeric field Default payment term (days) is hidden and used only as a fallback when no term is selected.

A sales realization recalculates Due date while it is editable: document date plus the selected term's days. A sales order has no due date.

Example with numbers#

Invoice lines: 10 pieces at 100, header Discount, % = 10. Tax rate = 15%.

The debt is 1035 because tax is part of the amount the customer owes. The revenue layout remains 900 because it shows the line amount without tax.

Barcode delivery note#

The Delivery note with barcodes print form is a read-only view of the SalesRealization; it does not create another document or post additional movements. Each line shows the barcode image and separate text value, item photo, article, Ukrainian commodity code, quantity, unit, unit price, and discounted line amount. Both barcode controls are blank when the item has no barcode value. The header shows the buyer's address and phone beside the right-aligned Okrasheno logo. The footer includes a Viber community QR and an outlet-coordinate map QR.

The totals use the same line pricing and tax rate as the sales realization. In the example above, the printout shows 900 net, 135 tax, and 1035 total. Gross weight is the item's WeightGross multiplied by BaseQuantity (or line quantity when base quantity is zero); for a 0.25 kg item sold as 10 base units, the weight is 2.5 kg. The required-payment row appears only when the source order has a positive Required payment value.

The debt panel reads the customer's Receivable balance across active sales contracts and renders separate green, blue, and red status rows. It is green when the post-issue balance is zero or the balance before this realization was a credit, blue when this realization alone creates the balance, and red when a prior debit remains in addition to this realization. For example, the 1035 realization above changes a prior 200 receivable to 1235 and shows red. This panel is informational; it does not replace the realization's posted balance.

Boundaries and edge cases#

• The sales realization is read-only in Released. Editing quantities after stock and revenue were written would corrupt both.
• Paid exists on SalesRealization only for old rows and is locked. A customer payment is a separate CustomerPayment document.
• The stock check uses free stock for this document: it excludes other reservations but does not block itself or the picking already made for this order.
• With store discipline on, sales issue must happen from a picking cell.
• An unconfigured GL profile does not block the sales realization; it only means no journal entry is created.

What is posted#

On Released (Issued in metadata):

• SalesStockTx: Stock quantity minus, and removal of any picking reservation that was not held by the invoice itself.
• SalesRevenueTx: Revenue plus by item, customer, and contract.
• SalesReceivableTx: Receivable plus by customer and contract, gross when TaxRateApplied is set.
• Localization scripts: for Saudi Arabia, VatPayable plus by customer, outlet, and contract; universal tax creates TaxCalculation and TaxLedger.
• GL integration: Dr receivables / Cr revenue; and, when cost layers exist, Dr cost of sales / Cr inventory.

What's not there yet#

• E-invoice is country-specific (envelope); issuing a sales realization does not by itself send an authority envelope.
• There is no customer statement, ageing report, or sales ledger report for invoices. Open debt is Receivable by customer and contract.
• There is no money-account reconciliation; payments only reduce receivable.
• The barcode delivery note has no amount-in-words and no attached geolocation picture. It uses an outlet-coordinate map QR. ZuloReport paginates by layout height.

Same topic for other readers: User

Where next#

• Issue a sales realization
• Receive customer payment
• Handle a return or note