Hi LindaKhoo
Sorry, my reply must have been confusing. You are familiar with your items and I am not. As you use ItemNames rather than ItemNumbers, the MYOB message ' may not be less that zero' referred to ItemNumber
MUV-UV1200sCHASS+INTR and your Autobuild screen did not show this ItemNumber. So I assumed you highlighted the affected Item ( Speed Controller - MSeries/LV with -3 and -$26.55) - this is what my paragraphs 3 and 4 were referring to.
I have again examined the images. I now see the Item triggering the 'may not be zero' message is the first Item on the list. So please ignore my paragraphs 3 and 4, and check the things raised in paragraph 1 and 2 only. The MYOB message is wrong, MYOB should be allowing this transaction.
In terms of the 'rules' in MYOB:
- you can only use an item in a Build (as a component) or a Sale if you have sufficient quantity on hand at the time you process the transaction (irrespective of transaction dates) - see Item Profile screen for current on hand and value
- if an item have zero on hand, the value must also be zero
- neither on hand count nor value should ever be negative
- there is no restriction on an original Purchase or when building the finished Item. The restriction however does apply when editing/deleting/reversing either
- you cannot autobuild if that build will cause a component to have a negative on hand count or negative value - you must purchase or adjust first
When dealing with inventory, the order transactions appear on the screens or reports can be misleading. In your second image (UV-1200s Printer), the build shows after the Sale. This is a display issue as the Build would need to be processed before the Sale.
Likewise with the UV1200s CHASSIS + INTR. The purchase dated 4 Aug 2023 would have been entered before the Build dated 30 June 2023 because you would not have been able to Build and use the 7 units as a component until the 7 units were 'in stock'.
With MYOB and Inventory 'integrity' I use that word loosely with AR2023, the transaction date can be misleading. MYOB uses the on hand count and value 'at the time the transaction is being processed'. This is why editing/deleting/reversing item transactions leads to so many 'errors' and inconsistencies in AR2023.The system tries to enforce the 'if on hand is zero, value must be zero' rule however when coding edits/deletes/reversals these rules seems to have been inconsistently applied or skipped entirely. I have seem literally hundreds of files with negative on hand counts and or negative values - which technically should not be possible.
My guess would be that the issue you are having is somehow affected by the long decimal issue. For example there might be a previous transaction affecting Item MUV-UV1200sCHASS+INTR which left the on hand count at zero and a value like -3.7632918242E-15. So while the Item Profile and screens after your purchase PO8240 should value of $23588.46, the on hand value might actually be $23588.45999999999999999999999.
The autobuild tries to deduct $23588.46 and this creates a very tiny negative amount, so MYOB will not allow. As with your original request, you may need to get MYOB to run the long decimal script again.
Or a getter idea, get the MYOB developers to fix the code so this does not keep occurring.
Regards
Gavin
.png){kind=link}
.png){kind=link}
.png){kind=link}