Purchase Invoices

A purchase invoice has a header and one or more lines. The invoice type is never a field in the request: it is fixed by the endpoint you call. There are four invoice endpoint groups — Purchase, Sales, Purchase Return and Sales Return — sharing the same fields, numbering mechanism and result codes, with the differences noted on each page.

​

Required fields

• InvoiceNumber: unique within the company for this invoice type, at most 20 characters. Send "Next" on create to generate it automatically from the ALFATNO number series. "Next" cannot be sent on update.
• Date: the invoice date. If you send a time it is stored as the invoice time, otherwise the current time is used.
• CustomerCode: a customer the user can see.
• CurrencyCode: the invoice currency.
• Lines: at least one line.

DueDays (payment term in days) is stored with the invoice. ShipmentDefinitionCode (optional) comes from shipment definitions. EInvoiceType (0-5: not an e-document, e-Invoice, e-Archive, e-Archive internet, incoming e-Invoice, e-Producer-receipt) is provided by you and stored as sent — the API only range-checks it.

​

Customer snapshot

The invoice’s address, title, tax number and tax office are not accepted in the request. They are copied from the customer at the moment the invoice is saved (the invoice address when the customer has one, otherwise the first address) and stay fixed afterward even if the customer changes later — this is why they only appear in responses (Address, CustomerTitle, TaxNumber, TaxOffice). On update, they are only recomputed when CustomerCode changes; otherwise the existing values are kept.

​

Lines

• ProductCode and UnitCode are required. The unit must be one of the product’s own units (its main unit, or its second/third unit).
• Quantity must be greater than 0; UnitPrice cannot be negative.
• Discounts is the list of the line’s discount rates, applied one after another in list order.
• LineGroupName is optional, from line groups.
• WarehouseName is required and must be one of the company’s warehouses: every line always carries a warehouse movement (see below).
• WithholdingNumerator/WithholdingDenominator describe the withholding (tevkifat) share; the API calculates WithheldVatAmount from them and VatAmount.
• AdditionalTaxCode1-3/AdditionalTaxRate1-3/AdditionalTaxAmount1-3/AdditionalTaxBase1-3 are stored as sent, in three independent slots.

MainUnitQuantity in responses is Quantity converted to the product’s main unit, the same calculation as despatch lines: the quantity itself when UnitCode is the main unit, otherwise divided by the unit’s multiplier.

​

Warehouse movement, Lot and serial number tracking

Unlike a despatch, an invoice is not itself a warehouse document, but every line always carries one: the API automatically creates a warehouse document behind the invoice (an inbound movement for a purchase invoice) and, depending on the product’s stock type, the same Lot or serial number entries a despatch would need — Lots or SerialNumbers on the line, following exactly the despatch rules (a Lot-tracked product requires LotNo/Quantity/UnitCode, a FIFO/LIFO/FEFO product’s inbound entries create new lots, a serial-tracked product’s entries register new serial numbers). This warehouse document is an internal implementation detail: it is not returned in the response and does not consume the despatch number series.

​

Line identity on update

Like a despatch line, an invoice line’s generated warehouse movement, Lot/serial number entries and linked-order record all reference the line’s own ID, so a blind “replace all lines” would break those references. Instead, the order in which you send lines determines their identity on update, exactly as for despatches: the line at position i in the request is treated as the same line as the one currently at position i, and its generated records move with it. Sending fewer lines than before removes the trailing ones; sending more adds new ones at the end.

​

Linked orders and despatches

An invoice line’s generated warehouse movement can carry a link to an order line, the same way a despatch line can; the API checks that the line’s quantity does not exceed the linked order line’s remaining quantity. An invoice line created in the Noyax application by transferring an existing despatch (rather than generating its own warehouse movement) keeps that link instead: this API does not create such a transfer, but if you update an invoice that already has one, its quantity is checked against the linked despatch line instead.

​

Customer ledger

Every purchase invoice always records a customer ledger entry (a credit, since a purchase invoice increases what the company owes the supplier) — unlike an order’s optional CreateCustomerMovement, there is no toggle. If that ledger entry has already been closed by a collection/payment, the invoice’s customer, amount and currency can no longer be changed, and the invoice cannot be deleted (3015).

​

Extra structured fields

The invoice accepts a set of additional, entirely optional fields for less common scenarios (export, public sector, SGK, pharmaceutical/medical device, Hal). None of them are validated by the API or tied to ProfileId/InvoiceTypeCode in any way: whatever you send is stored and returned as-is, and it is your responsibility to send the ones relevant to your own ProfileId. Header: DeliveryInfo (export delivery address and terms), PaymentMeans (payment methods), ReferencedDespatches (despatches this invoice references), CustomerIdentitySchemes (additional customer identity numbers, e.g. MUSTERINO, TICARETSICILNO), PublicSectorSpendingUnit (the public-sector unit that will make the payment) and SgkInfo (social security invoice details). Line: ExportInfo (export delivery/packaging details for the line), MedicineDeviceInfo (pharmaceutical/medical device tracking rows), HalInfo (wholesale produce market receipt information) and ProductInfo (model, brand, origin country and other identifiers).

​

Sharing

SharingCode limits who can see the invoice: empty means visible to everyone, otherwise it must be one of the user’s sharing codes. Invoices the user cannot see return 404.