Stock that moves during a count

Stock should stay put while a stocktake runs, but orders still ship and production still uses material. Completing posts each row's count minus its in_stock_quantity, the stock when counting started. When stock moved before the shelf was counted, the count already includes the movement, and posting the full difference would count it twice. So Katana rechecks the stock and asks you to look at those rows first.

This guide continues Running a stocktake: stocktake 7202001, IN_PROGRESS, with the brake pads in A-02 started at 60 pcs (row 8830001).

A row that moved during the count

Before the brake pads are counted, a sales order ships 12 of them from A-02. The counter finds 48 and enters it. When the stocktake moves to COUNTED, the row shows the movement:

{
  "id": 8830001,
  "variant_id": 24890201,
  "bin_location_id": 512002,
  "in_stock_quantity": "60.00000000000000000000",
  "counted_quantity": 48,
  "discrepancy_quantity": "-12.00000000000000000000",
  "rechecked_in_stock_quantity": "48.00000000000000000000"
}

A row needs review when it has a count and its rechecked_in_stock_quantity differs from its in_stock_quantity. Its −12 is not a loss: the shipment already took the 12 pcs.

Complete, and what happens to moved rows

Request COMPLETED as usual. If any counted row needs review, the stocktake goes back to COUNTED instead, with nothing posted and rechecked_in_stock_quantity refreshed. Check status once status_update_in_progress is false. For each row that needs review, decide when it was counted:

• Counted before it moved: the count is out of date. Count the shelf again and enter the new count.
• Counted after it moved, or the movement was recorded late: the count is right. Complete with use_counts_for_changed_rows.

Recount a row

Entering a different count while the stocktake is COUNTED restarts the row from the stock at that moment: in_stock_quantity and rechecked_in_stock_quantity both become the current stock, and the discrepancy is worked out again.

curl -X PATCH https://api.katanamrp.com/v1/stocktake_rows/8830001 \
  -H "Authorization: Bearer $KATANA_API_KEY" -H "Content-Type: application/json" \
  -d '{"counted_quantity": 47}'

{
  "id": 8830001,
  "in_stock_quantity": "48.00000000000000000000",
  "counted_quantity": 47,
  "discrepancy_quantity": "-1.00000000000000000000",
  "rechecked_in_stock_quantity": "48.00000000000000000000"
}

The row no longer needs review: one piece really is missing. Sending the same count again changes nothing.

Complete with your counts

Instead of recounting, when the counts already include the movements (here, the 48 was counted after the shipment), complete in one request:

curl -X PATCH https://api.katanamrp.com/v1/stocktakes/7202001 \
  -H "Authorization: Bearer $KATANA_API_KEY" -H "Content-Type: application/json" \
  -d '{"status": "COMPLETED", "use_counts_for_changed_rows": true}'

Each row that needs review restarts from its rechecked_in_stock_quantity before posting, so the brake pads post 48 − 48 = 0 and stock stays at 48.

This only covers movements you have seen. If a row's stock moved again after its last recheck, its stock is no longer the rechecked_in_stock_quantity you read, and completing leaves the stocktake COUNTED once more with that row refreshed. Read the rows again and decide for that row.