fix: update demand when sales or work orders are updated

[Alchez]

Closes #143

---

Demand (not allocation) should be added when:

• [x] a new Work Order is submitted
• [x] a new Sales Order is submitted

Demand (not allocation) should be removed when:

• [ ] a Work Order is completed
• [x] a Work Order is manually closed
• [ ] a Sales Order is satisfied via Delivery Note
• [ ] a Sales Order is satisfied via Sales Invoice
• [x] a Sales Order is manually closed

Todo:

• [ ] Timestamp priority: delivery_date / expected_delivery_date, creation, name

[Alchez]

@agritheory Currently the approach I've used is very brute-force, in which I completely rebuild the demand and allocation tables. I think, but I'm not sure, that this may be destructive in case user actions later change allocations manually.

If that is true, should this instead be incremental changes? And should we discourage ever truncating the tables in any operation?

[agritheory]

@Alchez Yes, we want this to be incremental and in the future to allow for manual allocation.

[Alchez]

@agritheory This one is ready for a review, and I'll need your help with the tests.

[agritheory]

@agritheory This one is ready for a review, and I'll need your help with the tests.

Sure, can you describe how you were testing it manually? These tests are tricky because we want to test for changes in the demand db in parallel to testing for correct net quantities for handling units, so it does end up being adding to existing tests rather than writing new ones.

[Alchez]

@agritheory I was using the following cases to test, but it's probably not an exhaustive list:

• Submit Sales Order/Work Order (expected = actual = demand increases)
• Cancel Sales Order/Work Order (expected = actual = demand decreases)
• Submit Delivery Note (expected = actual = demand decreases + stock allocated)
• Cancel Delivery Note (expected = actual = demand re-created + allocated stock removed)

[agritheory]

Submit Sales Order/Work Order (expected = actual = demand increases)

I think this is covered in the existing demand tests.

Cancel Sales Order/Work Order (expected = actual = demand decreases) Cancel Delivery Note (expected = actual = demand re-created + allocated stock removed)

This needs a new test that should instantiate a Sales Order and then cancel it. Copying the one that is there is fine. Asserts should be on the increased qty and then the reduced qty after cancelling. Adding the satisfying inventory via "Material Receipt" and then testing the DN submit / cancel as part of the same test or a subsequently ordered test would be good.

Submit Delivery Note (expected = actual = demand decreases + stock allocated)

I think this can use the existing test and assert on the demand side effect here: https://github.com/agritheory/beam/blob/demand/beam/tests/test_handling_unit.py#L324

[Alchez]

@agritheory I've updated and added some tests (that atleast seem to be passing in the CI), but I'm not sure about the output of the DN-cancel test. Let's discuss the expected values there today.

[github-actions[bot]]

Coverage Report

File	Stmts	Miss	Cover	Missing
__init__.py	1	0	100%
customize.py	24	24	0%	4–5, 7, 10–19, 24–32, 44–45
hooks.py	16	0	100%
install.py	32	32	0%	4, 6–7, 9–11, 14–26, 29–30, 33, 36–37, 39–40, 42, 44–45, 47, 51–52
beam
__init__.py	0	0	100%
barcodes.py	31	19	38%	17–19, 27–29, 31–33, 37, 43–44, 46–47, 52–54, 58–59
boot.py	3	3	0%	4, 7–8
handling_unit.py	81	38	53%	25, 28, 31, 63–65, 83, 94–95, 101–102, 104–105, 107–108, 110–111, 113, 115–118, 120–122, 124, 126, 128–129, 134, 136, 140, 142–143, 146, 148–149, 157
printing.py	61	61	0%	4–6, 8, 11–12, 15–16, 18–21, 24–25, 34–45, 47–54, 58–59, 61–62, 71–75, 78–79, 85–87, 90–91, 94–95, 97–99, 101–102, 104, 109, 111–112
beam/demand
demand.py	301	73	75%	20, 22–23, 26–37, 45, 60, 69, 82, 102, 133, 151, 164, 196–197, 199–200, 204, 206–208, 230, 249–252, 256–259, 263–264, 268–269, 271–273, 276–278, 422–423, 436–438, 441, 443, 445–447, 449, 496, 513–514, 516–518, 568, 572, 612, 619, 647, 651
sqlite.py	43	0	100%
utils.py	42	1	97%	47
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%	12–14
handling_unit.py	14	0	100%
test_handling_unit.py	3	0	100%
beam/doctype/warehouse_types
__init__.py	0	0	100%
warehouse_types.py	3	0	100%
beam/overrides
stock_entry.py	64	16	75%	61–62, 67–74, 80–81, 97, 125, 128–129
work_order.py	10	2	80%	14, 16
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/demand_map
__init__.py	0	0	100%
demand_map.py	34	34	0%	4–5, 7–8, 11–12, 15–16, 103–110, 126, 128–142, 145–146
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	124	19	84%	20, 24–25, 30, 38, 70, 117–118, 128, 130–131, 135, 139–140, 143, 173, 202, 204, 222
config.py	26	26	0%	4, 6, 9–17, 19–21, 23–26, 28–30, 32–35, 37
tests
conftest.py	26	0	100%
fixtures.py	6	0	100%
test_demand.py	244	36	85%	260–263, 272–273, 275–276, 278–279, 281–282, 305–309, 311–314, 316–318, 321–322, 324–328, 340–344
test_handling_unit.py	365	59	83%	18–19, 21–22, 482, 502, 543, 553, 580, 583–584, 587–596, 603–606, 615–617, 619–620, 622–624, 632, 639, 641–647, 649, 659–662, 671–674, 676–678, 686, 693–695, 697
test_hooks_override.py	40	0	100%
test_scan.py	24	0	100%
www
__init__.py	0	0	100%
demand.py	6	6	0%	4, 6, 9–12
TOTAL	1690	500	70%

[agritheory]

Root cause on the determinism issue we were seeing came from the production plan returning the items from the Sales Order sorted by name, which was regenerated every time. I added a sort to this after that and then every thing worked.