Yesterday we talked about this isDirty, but now a thought came to my mind.

In this case, when we type anything into the "Receiving now" input but come back to the original value before saving, and then we click the "Save & Exit" button, this value still goes to the backend to update. This happens because we never clear the isDirty boolean, even when the value comes back to the original one, it stays true (we only clear it after a save)

I'm fine with this, but maybe a better option would be in the buildLineItem method, add for example a lastSavedQuantityReceiving field that copies the initial quantityReceived value from the backend:
lastSavedQuantityReceiving: currentReceiptItem?.quantityReceived ?? null,

and in buildReceiptItemsBatchPayload do:
.filter((item) => item.quantityReceiving !== item.lastSavedQuantityReceiving)
This way the row is only sent when the quantity is really different from the last saved value

I had the same solution in mind to address that problem, but in the end I thought it was a bit "over-optimization" for the initial part of the save, but I can add that now if you feel this should be a must-have.

I think this solution is fine. I just wanted to point out the potential problem so we're aware of it. In my opinion the current solution shouldn't be an issue, because I think it's rare for someone to type something and then come back to the initial value.

But if we decide to go the way I showed, we'll need to remember to do the same for the autofill location, because in future tickets the location will also be editable.

I included that change now, when working on another code review fix.

What do you think about packing it into a useReceivingSaveAction to group the code by purpose in that hook?

sure, can do it