Skip to content

Recalculate FIFO

A housekeeping operation for invoices issued against a sales order: it links the invoice rows to the rows of the sales order and of posted shipments, and carries the cost (FIFO) from the shipment into the invoice. It does not recalculate stock batches or the item history: the cost is taken as the posted shipment already computed it.

Where to find it: Modules → Database Maintenance → Maintenances → Recalculate FIFO

A worked example

Recalculate FIFO

No parameters — the service goes through every invoice of the current company and takes those linked to a sales order.

When it is needed

When goods leave stock by a shipment and the invoice is issued against the same sales order, the cost of sale in the invoice should match the shipment's cost. If they have drifted apart, the invoice's profit is computed from the wrong cost — the service carries the shipment's cost over again.

The service does not guess: it matches an invoice row to a shipment only through the link already stored in the row — to a sales order row or to the shipment itself. If the link is lost entirely (for example, the documents were migrated from another system or created bypassing the windows, and the row points neither to a sales order row nor to a shipment), the service does not restore it by item or by position — such a row stays as it was.

The service changes invoice rows directly, without recalculating documents or postings. So it is run deliberately, never "just in case".

Typical situations

The invoice's cost does not match the shipment. This is what the service is for: after the run, the invoice row carries the cost of its own posted shipment. Its own is the one the row points to: an invoice created from shipments stores that link in every row, so a sales order row shipped by two documents is not mixed up — each invoice row gets the cost of its own document. A row without such a link takes the cost of the shipment of the same sales order row, if that row has exactly one posted shipment.

The invoice took only part of a shipment row (the rest was invoiced by another invoice or returned). «FIFO by Line» is the cost of that part: quantity × unit cost. A row invoiced in full gets the whole cost of the shipment row.

The row took the stock off the warehouse itself (an invoice with "Update warehouse", a row that did not come from a shipment). The service skips it: the row has its own cost and no other shipment is linked to it. The same goes for an old row that has a shipment reference but, by its history, took the stock itself. A row whose own shipment is currently unposted is not moved to another one, and a row with its own serial number does not take another number's cost.

The summary shows a warning row "row …: 2 posted shipments of one order row — cost not transferred". The sales order row was shipped by several documents, and the invoice row does not say which of them is its own. The service does not choose for you: the cost of that row stays as it was. Check it by hand against the shipments of that sales order.

The summary shows a warning row "sales order … not found — the invoice is skipped". The sales order the invoice refers to has been deleted; that invoice keeps its old cost.

A refusal about a register shared from another company. If your company uses invoices, sales orders, shipments or document links shared from another company, the service refuses and names the register: the cost in shared invoices is recalculated only by the company that owns them.

The cost of the stock batches themselves is wrong (an old receipt was posted retroactively, a price was corrected on an old document). This service does not fix that: it only carries over the cost of shipments already posted. Look for the cause in the item history and the cost price difference report.

Where to look next