in the docs it was said, that the item state should be set to DISCREPANCY_ACCEPTED - we don't have such status for an item, so I assumed it's equivalent to APPROVED?

I think both this if condition and the previous one should have status READY_TO_REVIEW.

When I was originally designing this I was imagining that we wanted a status that meant "there's a discrepancy, but we don't care". But it looks like we don't need to be able to distinguish that case so if !requireRecountOnDiscrepancy, then the item should always get status READY_TO_REVIEW because counting is completed.

the same case as above - it was meant to be set as DISCREPANCY_TO_RESOLVE, but again - we don't have such a status, so is it equivalent to INVESTIGATING?

I think we want COUNTED. We use COUNTED to mean there is a discrepancy but recounting hasn't been started yet (once the recount starts, the status will be INVESTIGATING).

I'm not the hugest fan of this because to me the word "counted" doesn't imply a discrepancy, but that's what we have currently

quote from docs:

If Cycle Count is not in status ready to count, counting, investigating, or counted, error

1. is READY_TO_COUNT equivalent to REQUESTED?
2. should the COUNTED be there? If so, I can spam the requests for the same cycle count and eventually create X transactions for the same cycle count, not really mutating anything (duplicates would be created)

I wrote those statuses before I really knew which ones we were using. Given that if you've started the count you'll be in status COUNTING, and given that we're going to split count and recount into their own APIs, I think we only need COUNTING here actually.

this will always be false if refreshQuantityOnHand is true. You'll want to check if currentQuantityOnHand != to cycleCountItem.quantityOnHand BEFORE you've updated it (ie if the old value has changed).

the idea is that if the QoH is changing for the product we want the user to review it again to make sure everything looks as they expected. (This will only technically be true for recounts for us because all our regular counts are blind counts and so don't need to be reviewed, but I chose to be able to support it for regular counts as well.)

This isn't quite right. We want to have multiple transactions here because we want to do two things: take a "snapshot" of the QoH at the moment of submitting the count (that's what the product inventory is for), and then specifically

1. the product inventory transaction: for every item, quantity == cycleCountItem.quantityOnHand. So it actually doesn't use the counted value at all.
2. credit transaction: for every item, quantity == cycleCountItem.quantityCounted - cycleCountItem.quantityOnHand if this calculation is positive
3. debit transaction: for every item, quantity == cycleCountItem.quantityCounted - cycleCountItem.quantityOnHand if this calculation is negative

So 2 and 3 transactions only get created if there's a discrepancy for the item and they represent the quantity difference/adjustment. 1 represents the "quantity at the time of the count".

and they're all connected because they have the same cycle count id.

@ewaterman I am a bit confused. In the docs it was said that:

if all the Cycle Count Items have the COUNTED or DISCREPANCY_ACCEPTED state:
Cycle Count state = COUNTED (aka TO_REVIEW)
save a new “Cycle Count Product Inventory“ transaction using the quantityCounted value as outlined in solution 3 of the inventory transaction design.

and regarding the credit/debit transaction types it was said:

(13 and 14 aren’t relevant now, but will be used once we add the ability to submit the count with discrepancies as a part of the resolve count step so we might as well include them now.)

So I would assume this should be the resolving API responsibility, not perform count.

I was just following docs for the transaction part, so let me know if I misunderstood something or?

yeah the docs aren't especially clear. Until we implement the resolve API, if we reach this point then we know quantityCounted == quantityOnHand. And so we could use quantityCounted and it'd be fine. But once the resolve API is implemented, if there's any sort of discrepancy when we go to create the transactions, they won't be equal, and so since we're going to be inserting adjustment transactions that represent the quantity changes, we want the product inventory transaction to be the quantity at the time of the count, so it would be quantityOnHand. And since the recount and count flows will probably share this logic, it's probably simplest to just always use quantityOnHand for the product inventory transaction here.

And as for credit/debit transactions, yes you're totally right. I was getting ahead of myself. We can worry about that when we do the resolve API.

So long story short is that we postpone any change in that code until we work on the resolve API?

yeah that's fine with me

I think both this if condition and the previous one should have status READY_TO_REVIEW.

When I was originally designing this I was imagining that we wanted a status that meant "there's a discrepancy, but we don't care". But it looks like we don't need to be able to distinguish that case so if !requireRecountOnDiscrepancy, then the item should always get status READY_TO_REVIEW because counting is completed.

I think we want COUNTED. We use COUNTED to mean there is a discrepancy but recounting hasn't been started yet (once the recount starts, the status will be INVESTIGATING).

I'm not the hugest fan of this because to me the word "counted" doesn't imply a discrepancy, but that's what we have currently

I think we want READY_TO_REVIEW here, not COUNTED. We use COUNTED to indicate that there is a discrepancy but we haven't started recounting yet.

Why? This will force the count to always be accurate

🙈 thanks for catching that. I hardcoded that for testing purposes and forgot to remove it - I had to somehow mimic that we are after the update count, and since we don't have the update count API yet ready, it was the only way to mimic that.