> ## Documentation Index > Fetch the complete documentation index at: https://apidocs.noyax.com/llms.txt > Use this file to discover all available pages before exploring further. # Purchase Invoices > Fields, numbering, warehouse movement and customer ledger rules of 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](/en/v1/purchase-invoices/overview), [Sales](/en/v1/sales-invoices/overview), [Purchase Return](/en/v1/purchase-return-invoices/overview) and [Sales Return](/en/v1/sales-return-invoices/overview) — sharing the same fields, numbering mechanism and result codes, with the differences noted on each page. | Operation | Endpoint | | -------------- | -------------------------------------------------------------------------- | | List | [`GET /purchase-invoices`](/en/v1/purchase-invoices/list) | | Get | [`GET /purchase-invoices/{invoiceId}`](/en/v1/purchase-invoices/get) | | Create | [`POST /purchase-invoices`](/en/v1/purchase-invoices/create) | | Update | [`PUT /purchase-invoices/{invoiceId}`](/en/v1/purchase-invoices/update) | | Partial update | [`PATCH /purchase-invoices/{invoiceId}`](/en/v1/purchase-invoices/patch) | | Delete | [`DELETE /purchase-invoices/{invoiceId}`](/en/v1/purchase-invoices/delete) | **The API does not calculate amounts and does not check that they are consistent.** Line amounts, discount amounts, VAT, additional taxes, invoice totals and the weighted average exchange rate are stored exactly as you send them (the same fields as [despatch lines](/en/v1/despatches/overview)). The exceptions the API does calculate: a line's [main unit quantity](#lines) when it carries a warehouse movement, and the line's withheld VAT amount (`WithheldVatAmount = VatAmount * WithholdingNumerator / WithholdingDenominator`). ## 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. * `Lines`: at least one line, each with its own `CurrencyCode`. `DueDays` (payment term in days) is stored with the invoice. `ShipmentDefinitionCode` (optional) comes from [shipment definitions](/en/v1/definitions/shipment-definitions/list). **The invoice currency and `EInvoiceType` are not accepted in the request; the API determines them**: `CurrencyCode` is sent per line, not on the header; the invoice's currency is derived from the lines (when every line uses the same currency, that is the invoice currency, otherwise the company's default currency) and returned as `CurrencyCode`/`CurrencyId`. `EInvoiceType` is calculated by the API from whether the company uses e-Invoice and is returned in the response; you do not send 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](/en/v1/definitions/line-groups/list). * `WarehouseName` is required on every line whose product's stock type is **not** "not tracked", and must be one of the company's [warehouses](/en/v1/stock/warehouses/list): such a line always carries a warehouse movement (see below). If the product does not track stock, `WarehouseName` may be omitted; the line then generates no warehouse movement at all. * `CurrencyCode` is required on every line. `ExchangeRate` must be `1` when the line's currency is the company's default currency; otherwise it is required and must be greater than 0 (sent by the integrator, not calculated by the API). * `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](/en/v1/despatches/overview#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](/en/v1/despatches/overview#lot-and-serial-number-tracking) (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](/en/v1/despatches/overview#line-identity-on-update): 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`). ## Save-time checks * If a line's `VatRate` is `0`, `VatExemptionCode` must be filled in; this rule only applies to sales and purchase-return invoices. * If any line has a `VatExemptionCode`, the invoice's `InvoiceTypeCode` must be `ISTISNA`, `IHRACKAYITLI` or `SGK`. * When both `ProfileId` and `InvoiceTypeCode` are sent, `InvoiceTypeCode` must be one of the values allowed for that `ProfileId` (see the table below). For a purchase-return or sales-return invoice, `InvoiceTypeCode` can only be `IADE`. * When the company uses e-Invoice, `ProfileId` and `InvoiceTypeCode` are both required; otherwise both are optional. * When the company uses e-Invoice, the selected customer's tax number, invoice title and tax office must be filled in, on a sales or purchase-return invoice. * An invoice that has already been sent to GİB (`EFaturaId` is set) cannot be updated. | `ProfileId` | Allowed `InvoiceTypeCode` values | | ----------------- | ------------------------------------------------------------------ | | `IHRACAT` | `ISTISNA` | | `TEMELFATURA` | anything except `SARJ`, `SARJANLIK`, `IADE`, `TEVKIFATIADE` | | `TICARIFATURA` | anything except `SARJ`, `SARJANLIK`, `IADE`, `SGK`, `TEVKIFATIADE` | | `KAMU` | `SATIS`, `TEVKIFAT`, `ISTISNA` | | `ENERJI` | `SARJ`, `SARJANLIK` | | `HKS` | `SATIS`, `KOMISYONCU` | | `ILAC_TIBBICIHAZ` | `SATIS`, `TEVKIFAT` | | `YATIRIMTESVIK` | `SATIS`, `TEVKIFAT`, `ISTISNA` | | `IDIS` | `SATIS`, `TEVKIFAT`, `ISTISNA`, `IHRACKAYITLI` | ## 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](/en/v1/guides/sharing-codes). Invoices the user cannot see return 404.