Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Addresses #98
pytest-order
dependency before we need itAfter rebasing with staging, 4 other tests failed - this uncovered a few areas we needed to adjust either the test or add checks in the code.
enable_handling_unit
checked (as well asis_stock_item
)Additionally, there was a timing issue on the Stock Entry doc event in hooks. The
validate_items_with_handling_unit
invalidate
was throwing errors for missing handlings units when they weren't created yet (that step is done inbefore_submit
viagenerate_handling_units
). I moved the validate function to run AFTER the handling units are generated, now both in thebefore_submit
hookNet Quantity
For net quantity, the underlying Stock Ledger entries use the
transfer_qty
field (from the Stock Entry Detail item row) when updating the handling unit'sstock_qty
. This field gets set and updated in the UI when theqty
field changes, so in UI tests to transfer part of an HU, the stock ledger correctly shows net totals. Good news, most of the issue here was tied to fields not being set programmatically in the tests (it's done on a field change in the JS, not server-side), so the main "fix" was to explicitly set a few more fields in the tests.The failing test had the following issues:
stock_qty
of 0 and show a negative balance. Separately, the overconsumption code wasn't throwing an error when this happened because it was looking for theactual_qty
field, which was zero (the field doesn't get set programmatically in the tests or on save), so there's no overconsumption when zero units are removed from the HU. I created a 'clean' Material Receipt for Parchment Paper and used its HU for the test to avoid the issuetransfer_qty
field (what the stock ledger entries use to adjust the HU's quantity) also wasn't being set on save/submit programmatically in the test, so the code was 'netting out' zero from the HU. This caused the Assertion Error when the test checks if the HU qty == 95 because the math did 100 - 0 instead of 100 - 5. The test now explicitly sets thetransfer_qty
field, so the calcs have the right value to work withOverconsumption Updates (FOR DISCUSSION):
When the overconsumption code was turned on (uncommented in hooks.py, and tests not skipped),
test_handling_units_overconsumption_in_material_transfer_stock_entry
failed because it didn't raise the known error. The first issue was that theactual_qty
field wasn't being set in the test, which is what the overconsumption check uses to compare to the HUstock_qty
. The second issue was that the calc itself didn't catch when the test tried to use 8 units from a HU of 5 units.Some changes:
actual_qty
field it was using to compare against the HU's quantity. Theactual_qty
field in a Stock Entry Detail item row gets set when an item is added/source WH is set, but doesn't change when theqty
field changes in the UI or when I hit Save. So if I scan an HU, then manually adjust theqty
, theactual_qty
field doesn't update (see screen shot). To avoid mismatched quantity issues and to conform the overconsumption code with how the Stock Ledger Entries calculate net quantity, I changed the calculation to use thetransfer_qty
fieldt_warehouse
, like for finished goods or a Material Receipt), I had a little trouble writing a test because of the sequence of events in that scenario. HUs are generated for those rows inbefore_submit
, so it's tricky to change the qty after that happens to trigger an error in the test. I was wondering why the math was different in this case - maybe this is too simplistic, but when I think of how to define overconsumption, I figure if the quantity we're receiving/issuing/transfering/etc (row qty) less the HU qty is more than precision threshold, then it's overconsumption / throw errorScreen shot shows the values for the key fields we're using - when I changed the
qty
field and re-ran the console, it shows theqty
andtransfer_qty
fields update, theactual_qty
field remains the value that was set once the WH was added for the item. I also checked after adding a HU and after hitting save - same result.