Expenses date not updating stock adjustments - think this is a bug!

The date of an Expense, that updates stock, is not putting the expense date on the stock adjustment - its taking the current date instead.

In my book this is a bug as you may have a bookkeeper entering payments after a number of products have been sold but before the purchase has been entered. In addition the purchase date now doesn’t match the stock adjustment date.

Apparently this is due to it being considered a log record but it makes stock management pretty much impossible! Can we please please fix this ASAP???

1 Like

I have reported this bug (relating to expenses) well over a year ago, as it is causing us no end of trouble when filing our tax returns (the issue is exactly what you described, an accountant having to enter data). I received an extremely unhelpful reply from Clinko, stating that this was “easy to match up with a quick excel sort”. I have no hope that this bug will be fixed any time soon, and I cannot express enough how unhappy I am about the fact that they are refusing to fix such a significant problem. Starting to look for different providers.

This is worrying news Mia thank you for your reply.
It is definitely a bug as you can’t have an expense that affects stock not matching up by date. I can’t see why this wouldn’t be fixed - its a five minute fix and very important from an audit point of view!

1 Like

I wonder if anyone from Cliniko actually ever reads these threads. It doesn’t appear like it, which makes posting on here pretty pointless as well :frowning:

Hi @Mia & @MOC , our team reads the threads and is currently discussing how we can implement backdating of stock adjustments for Products as that isn’t a feature currently. This includes stock adjustments made via the Products Page.

Currently, if you add a stock adjustment to products, you may have noticed the stock adjustment will be recorded at the current date & time. This is the same for Expenses regardless of the Expense’s date — stock adjustments within Expenses will be made to the current/live stock.

Once we can add a feature to backdate stock adjustments though, we will implement the same into Expenses. At this time, all stock adjustments via expenses and the products page will be recorded at the current date and time. I’ll add an update here if I can offer any additional/immediate workarounds or fixes (including when a backdate feature for stock adjustments can be added).

Hi Rachel,

There is no need to be adding a backdated stock adjustment feature when this can be fixed by correcting the bug on expenses. When an expense is added the date of the expense does need to match the date on the stock adjustment - this is a basic audit correction and would take five minutes to fix.

Please could you explain why this is not going to be fixed?

Kind regards,

Mel

Hi @MOC, sorry for any confusion. I did not mean to imply we weren’t looking into a fix for the issue. The stock adjustment feature I mentioned was referring to adding overall functionality for backdating stock adjustments made in Expenses and Products. Meaning, this will also fix/address the issue with Stock Adjustments and backdated Expenses. We want to give you the ability to backdate future expenses/stock adjustments and make sure the fix we implement does not cause any further confusion or issues with your current stock and generated reports.

Hi Rachel, that is very good news thank you.
Having said that we really do need the fix to the expenses ASAP - can you tell me when this will be fixed?

Kind regards,

Mel

Our team just started discussions but once I have an ETA or know more, I’ll reach out here. Or if preferred, send us a quick message via Help → Chat With Us and that will reach us directly for updates and status on back dating stock adjustments.

Thanks Rachel that would be great as I’m actually waiting for the fix to start my stock management.

Let me also say that I think Cliniko is excellent and your attention to fixes and enhancements is really unparalleled - this one obviously just got missed!

Thanks
Mel

Thanks, Rachel. As Mel said, it really is important to get this issue fixed as soon as possible, especially given how long this has been going on for.