Negative stock values - RECURRING fault with MYOB

[TTO]

Hi @Steven_M 

2 screenshots attached.    Every day during harvest and distillation, we produce tea tree oil.  It will always have a little water left in it.  We let the oil cool in a big tank and remove the water.  This changes the quantity of oil we record as actually yielded from any given paddock - information we need to know.   So I reduce the oil quantity by 0.5litres (say) on any given day but  I typically accumulate all the water over the season and then put it back to zero.  Usually the water quantity doesn't give me any problem but after the last harvest it just wouldn't go back to zero, showing me the corrupted number instead.  I have 3 other stock items remaining in a similar state.  All show zero when I open the stock item or print a report.  Sigh.

TTO

[The_Doc]

Hi @TTO 

As mentioned in a prior post I believe this problem is not easy to fix and that running a script over the inventory to zero items that are not EXACTLY ( double precision) zero - to zero.

Here is the problem that appears to be the root of it - and from your perspective - hard to fix.

And this problem reared its ugly head to confound me with the API - where I was comparing website quantities (for an e-commerce live site) with the backend definitive quantity (a live MYOB perpetual inventory file).

To ensure quantities on the website matched actual available I always checked every 30mins during the day (as there was a built in rounding for cutting) that any order ALWAYS rounded to the next 0.25 length - therefore ensuring there was always a bit over for loss during cutting.

i.e. the web showed 2.5 lengths - and MYOB showed 2.5 lengths - and order came through for 0.4 lengths - the web now shows 2.1 lengths left - the order is rounded to 0.5 - POSTED to MYOB - MYOB now shows 2.0 lenfths in stock - web is updated to available 2.0. (not 2.1)

All well and good EXCEPT - MYOB quantity (in the backend is stored as double precision) however it is displayed as (single precision) - to explain 2.00 shows in the inventory window Quantity on Hand but in reality in the backend 2.00 (single precision) becomes 2.00xxxxxxxxxxxxxxxxxxx rounded in double precision - i.e it is never EXACTLY zero.

The problem with mixing and matching in science and maths with double and single precision - except in the computer - single precision is cheaper to store than double precision - and if you don't need double don't use it.

However, MYOB needs it in allowing up to 6 decimal places in prices - so it comes around and bites them in the rear end.

And by the way - that doesn't work in the API POST of an invoice - there is a bug - and you can only get 1 to 2.

Anyway - that is the explanation - simply - but until I corrected in my code for this - my system constantly thought every web item 1500 was different from MYOB - my API would get the qunatity on hand from MYOB before the comparision (but it was in double precision) - and it just never was right.

Here is the other twist (depending on the CPU and mathematics component) the double precision value can vary.

i.e. quantity of item (NOW) in double precision is slightly different to (NOW) + time a bit!!!!!

So it is almost impossible to get to ZERO.

My cure - very simple - always download Quantity on Hand as Single precision - problem was cured instantly and never went wrong again.

For you - the problem is you cannot do what I have done - the problem is hard wired.

The script just cleans up these errors - today - but they recur.

Sorry for the long winded explanation.

The Doc

[Steven_M]

Hi @TTO 

Certainly sounds like you have got your work cut out for you over that harvest season. I personally knew nothing about the process of tea tree oil, not being a big fan of it (yes blasphemous I know) but it's always good to get a snapshot of what clients' processes are.

Diving back into your AccountRight situation, the scripts should have worked for that company file and situation. The next step that we would be looking at would be to arrange to get the company file in for an investigation and possible repair. Just before we do that if you run the following report does it show nothing to display or is that item listed? Report being the Open Items receipts report - Reports>>Purchases>>Purchase Register>>Purchase Register [Open Item Receipts]. Based on your listed processes I don't imagine there is anything in that report but we do need to check.

[TTO]

thanks for your comments @The_Doc .  It's all a bit above my pay-grade.  I don't care if it's out by tiny little decimal points, but if they could just make me happy and show it as Zero with some sort of instruction that says if there number is in conflict and it's less than X (pick a decimal place) then show it a zero, then they wouldn't get complaints about problems they can't fix.  

I guess it can't be done.  Sigh.  

TTO

[TTO]

Hi @Steven_M .  The problem doesn't arise on purchasing.  It arises on transferring stock/making a stock adjustment.  And there is nothing to report under Purchases Open Items.

If you give me a private message address I can send you a trail showing the transaction sequences.

Otherwise - if you need to fault check the data, let me know what I need to do.

thanks,

Pat Bolster

[Steven_M · Accepted solution]

Hi @TTO 

Thank you for confirming that information

I've sent you a direct email with all the details in regards to getting that file sent in for an investigation and possible repair. All the information required is included in the email but do let us know if you have any questions about the process.

[TTO]

Hello @Steven_M 

I have successfully uploaded the file.  The instructions state, "

• If you have a Multi-currency file you are submitting for investigation/repair please also upload a copy of your AccountRight Classic file used to migrate to AccountRight 2019.2 or later "

I DO use multi-currency but have been with Accountright/online for this particular data file since 2015.  I'm not even sure I can locate my Accountright Classic file from that time!  I assume it isn't actually required?

TTO

[Steven_M]

Hi @TTO 

Generally, we would require the AccountRight Classic company file if you are encountering an error with AccountRight 2020 relating to multi-currency. 

In your case, you are probably all good not to supply that AccountRight Classic file due to the nature of the error, the team will request it if is important to the situation.