135 preserve complete hu

[robproject]

Description

Adds setting to allow preservation of complete Handling Units for those transactions where they are complete quantities. (mat xfer, Send to Subcontractor, ~~mat xfer for mfg~~)

Existing behavior with generation for every transaction is default (unchecked) for this setting.

Modifies get_handling_unit method since Handling Units are no longer implicitly grouped by Warehouse due to being shared via full qty transfers, the query was rewritten to include the Warehouse groupby. The newest created SLE is returned (this needs to be ordered by posting date as well) for a warehouse with a qty, since there will only ever be one warehouse with any qty for a HU.

Testing

Observe HU is preserved between source and target in the above cases when 'Always Generate for Transfer' is unchecked in BEAM Settings.

~~note: pytest was not created~~

[agritheory]

@robproject This will require tests, let me know if you want some suggestions about it.

[robproject]

Yes, I was thinking verifying HU is preserved or not based on those three SE types and the setting would satisfy the requirement, should there be others?

[agritheory]

In a case where anything less than the full amount is transferred you end up with new HUs, which I think makes the most sense. I would want this to be under test as well.

[robproject]

if the HUs have any change in qty, would it be a repack or non-transfer SE type?

[agritheory]

Any type of transfer should follow this rule.

[robproject]

Since the preservation is confined to those three SE types, it can have an additional condition added for preservation that verifies the HU is the complete qty. What if it 1. fetched the SLE for adding that qty comparison to the condition for preservation, or 2. fetched it to compare qty and throw an error in validate_items_with_handling_unit ?

[agritheory]

0. Transfer of 20Eac from HU of 20Ea to another warehouse - re-use the HU. I believe this should apply to "Material Transfer", "Send to Subcontractor" and "Subcontracting Receipt". "Material Consumption for Manufacture" / process manufacturing generally is not under test in BEAM.

1. Transfer of 15Eac from HU of 20Ea to another warehouse - new HU; Transfer of remaining 5Eac from HU of 20Ea to another warehouse - new HU. I believe this should apply to "Material Transfer", "Send to Subcontractor" and "Subcontracting Receipt". "Material Consumption for Manufacture" / process manufacturing is not under test in BEAM.

2. Manufacture SE with only one input item (like painting) should be eligible to re-use, but this should be configured at the BOM, since it won't always be correct. This seems like a special case and could be considered out of scope. We don't have a BOM or story for this case, but could create one by having a "formed" pie crust Item that only requires baking.

3. Repack cannot reuse the HU since it is by definition split into new HUs or it is literally repacked, so the intrinsic definition of a HU has changed.

4. Packing Slip, Delivery Notes and Sales Invoices can only consume HU and if they consume all of it, its gone. Partial consumption will allow for net quantities.

[robproject]

 1. Transfer of 15Eac from HU of 20Ea to another warehouse - new HU; Transfer of remaining 5Eac from HU of 20Ea to 
 another warehouse - new HU. I believe this should apply to "Material Transfer", "Send to Subcontractor" and
 "Subcontracting Receipt". "Material Consumption for Manufacture" / process manufacturing is not under test in BEAM.

Would the second action of xfer remaining 5Eac be equal to an xfer of that HU? Scanning after the xfer of 15Eac would mean that HU would populate as 5Eac?

[agritheory]

 1. Transfer of 15Eac from HU of 20Ea to another warehouse - new HU; Transfer of remaining 5Eac from HU of 20Ea to 
 another warehouse - new HU. I believe this should apply to "Material Transfer", "Send to Subcontractor" and
 "Subcontracting Receipt". "Material Consumption for Manufacture" / process manufacturing is not under test in BEAM.

Would the second action of xfer remaining qty 5 be equal to an xfr of that HU?

Potentially, yes. The "and its packaging " part of the definition of Handling Unit complicates this. A "Sack of Flour" item - sure, the sack and remaining flour are consumed. If it's a six-pack of Corona Light, I think there's an argument that you discard the paper holder at some point. This might be an argument for configuring "always split" at the item level as well as a global fallback.

Scanning after the xfer of qty 15 would mean that HU would populate as qty 5?

That's how net quantities should behave, yes. But this currently doesn't preserve the HU of those final five items into the new location. I am inclined to think that it should not.

[github-actions[bot]]

Coverage Report

File	Stmts	Miss	Cover	Missing
__init__.py	1	0	100%
customize.py	24	24	0%	1–2, 4, 7–16, 21–29, 41–42
hooks.py	15	0	100%
install.py	26	26	0%	1, 3–4, 7–16, 19–20, 23, 26–27, 29–30, 32, 34–35, 37, 41–42
beam
__init__.py	0	0	100%
barcodes.py	31	19	38%	14–16, 24–26, 28–30, 34, 40–41, 43–44, 49–51, 55–56
boot.py	4	4	0%	1, 3, 6–7
handling_unit.py	79	38	51%	24, 27, 30, 54–56, 74, 85–86, 92–93, 95–96, 98–99, 101–102, 104, 106–109, 111–113, 115, 117, 119–120, 125, 127, 131, 133–134, 137, 139–140, 148
printing.py	61	61	0%	1–3, 5, 8–9, 12–13, 15–18, 21–22, 31–42, 44–51, 55–56, 58–59, 68–72, 75–76, 82–84, 87–88, 91–92, 94–96, 98–99, 101, 106, 108–109
beam/doctype
__init__.py	0	0	100%
beam/doctype/beam_settings
__init__.py	0	0	100%
beam_settings.py	10	4	60%	14–17
test_beam_settings.py	3	0	100%
beam/doctype/handling_unit
__init__.py	9	3	66%	9–11
handling_unit.py	15	0	100%
test_handling_unit.py	3	0	100%
beam/overrides
stock_entry.py	65	15	76%	62–63, 68–75, 81–82, 98, 126, 128
beam/print_format
__init__.py	0	0	100%
beam/print_format/handling_unit_label
__init__.py	0	0	100%
beam/print_format/item_barcode
__init__.py	0	0	100%
beam/report
__init__.py	0	0	100%
beam/report/handling_unit_traceability
__init__.py	0	0	100%
handling_unit_traceability.py	44	44	0%	4–6, 9–11, 30–32, 34–35, 37–38, 41–42, 45–46, 48–49, 51–52, 54–55, 57, 63–65, 67–69, 71, 74–77, 79–81, 83–86, 89–90
beam/scan
__init__.py	128	19	85%	17, 21–22, 27, 35, 76, 123–124, 134, 136–137, 141, 145–146, 149, 179, 208, 210, 228
config.py	26	26	0%	1, 3, 6–14, 16–18, 20–23, 25–27, 29–32, 34
tests
conftest.py	24	0	100%
test_handling_unit.py	419	61	85%	16–17, 19–20, 493, 514, 560, 570, 597, 600–601, 604–613, 620–623, 634–636, 638–639, 641–643, 651, 658, 660–666, 668, 678–681, 692–695, 697–699, 707, 714–716, 718, 773, 802
test_hooks_override.py	40	0	100%
test_scan.py	25	0	100%
www
__init__.py	0	0	100%
TOTAL	1052	344	67%