Hello Georg,
I have saved many of my articles as bundles and added an additional barcode indicating quantities greater than one.
I looked into the code and believe I have found the issue.
Root cause:
In ConsumeProductView.swift, resetForm() correctly prefills amount from barcode?.amount at line 186, but the .onChange(of: productID) closure at lines 287–290 immediately overwrites it with either the quick-consume amount or the default consume amount. That’s why a barcode configured with amount 3 still shows 1.
PurchaseProductView.swift does not have this problem because its ProductField.onChange does not touch amount.
Possible Solutions:
- In ConsumeProductView.swift lines 287–290, change the .onChange(of: productID) logic so that when a barcode with an amount exists and the selected product is the barcode’s product, the amount is preserved from barcode?.amount instead of being reset.
- Keep the existing fallback to product.quickConsumeAmount / stockDefaultConsumeAmount when there is no barcode amount.
One trade-off: PurchaseProductView also uses barcode?.quID for the quantity unit. For consume, the current code always uses the product’s stock unit. Should the consume view also respect a barcode-specific quantity unit, or is the amount-only fix? In my eyes, it should always take the amount, which is preserved. Maybe add another check if there are enough items in stock, but just as a nice-to-have.
Thanks for your great work.
Hello Georg,
I have saved many of my articles as bundles and added an additional barcode indicating quantities greater than one.
I looked into the code and believe I have found the issue.
Root cause:
In ConsumeProductView.swift, resetForm() correctly prefills amount from barcode?.amount at line 186, but the .onChange(of: productID) closure at lines 287–290 immediately overwrites it with either the quick-consume amount or the default consume amount. That’s why a barcode configured with amount 3 still shows 1.
PurchaseProductView.swift does not have this problem because its ProductField.onChange does not touch amount.
Possible Solutions:
One trade-off: PurchaseProductView also uses barcode?.quID for the quantity unit. For consume, the current code always uses the product’s stock unit. Should the consume view also respect a barcode-specific quantity unit, or is the amount-only fix? In my eyes, it should always take the amount, which is preserved. Maybe add another check if there are enough items in stock, but just as a nice-to-have.
Thanks for your great work.