Added ability to choose between "First in, First out" or "Weighted Average Cost" when revaluating inventory

The latest version (24.12.5) allows to pick between two inventory costing methods:

  • First in, First out
  • Weighted Average Cost

It’s available when you click Recalculate button.

Weighted Average Cost is the method Manager was using before.

Another improvement is reduction of question marks when looking at Inventory Items tab.

Previously, question marks would show for all unit costs where unit cost is unknown but I think it just implies something is missing. If inventory quantity is zero or negative, then unit cost cannot be calculated and even if it’s manually entered, it would still make no difference. So we do not need to indicate that something is missing. This should result in cleaner look.

6 Likes

Did you test if when accidentally or even purposefully selecting any of the two methods alternatively how this will affect the new and historical values?

I ask because it seems that the recent switching between inventory costing methods has shown changes in both historical and new values by redefining how costs are calculated and reported. For historical values, seemed to have recalculated costs retrospectively, restating past reports and affecting financial statements like Cost of Goods Sold (COGS) and gross profit (see reported bug on costs). Manager users would have expected that Manager would lock historical values and apply changes only to future transactions, preserving past reports, i.e. financial data would not retrospectively change.

FIFO (First In, First Out) allocates costs from older stock, while Weighted Average recalculates costs with each purchase. The fear is that repeatedly switching methods can create inconsistencies if Manager does not handle transitions effectively and shows its effects on past method entries.

As for Manager users it is important to always back up your business data before testing. Also first use a small sample to observe changes, and verify that the system keeps an audit trail for method changes.

4 Likes

@lubos i would suggest introduce this option on Item level or Control Account level. This way users can have different types of recalculations for different items and a “Zero Cost” option for items which we do not want to capitalize.
This can apply to Investment Tab too that way different methods can be used Weighted Avg, FIFO, LIFO HCFO and so on.

3 Likes

Maybe a “From and To” Period selection on Recalculate screen would work and during that period an entry for every change in Average price whether FIFO or Weighted Avg is used should be created through Batch Update. That way you can have correct figures on any date during that financial period.
Right now, you can select end date of a period through Balance sheet but no option to select starting date from which you want to calculate costs.

2 Likes

I think you will find you can not mix the two costing scheme without doing a journal entry at change over to correct for the differences.

The issue being if you use either exclusivity it will balance out with time. If you change there will be a persistent residual difference.

1 Like

Hence possibly needing to balance the ease of use pressing such button. I would prefer this to be something in Settings and would support @shahabb that if in Settings part of control accounts may be suitable. I also think that a safety guard needs to be build in that at the time of setting up the business the choice must be made and then locked into.

I still think that periodic evaluations, calculations, etc. do not really fit a perpetual system and as such the former system was superior. I think that a shortcut is being implemented to satisfy expressed needs to implement more costing method options but had hoped for a much more sophisticated system where each method is chosen as part of setting up the business and then can not be changed or changed with knowing the historical effects. The latter could be mitigated by having an option for setting a from date for these recalculations as also suggested by @shahabb.

1 Like

Thats why i suggested a From date option for recalculate screen. Journal entry wont be needed. Qty on hand on Start date of recalculation will act as opening qty. So any method used before this date won’t affect the calculations.

I dont think that is necessary. The choice to change calculation method should always be there.

I also preferred the previous one, but I think the main reason behind this change is that @lubos want that every change for unit price should be authorised by the user (like in recurring transactions). So, in case the algorithm changes in future for calculating the avg price it won’t affect historical figures and even if program suggest some changes for previous figures, you must authorise it.

Thats what i thought initially but Manager is doing the same number of calculations which are needed for Automatic system. So now it doesn’t look like a shortcut to me. Instead, its giving more control to the users.

1 Like

I would argue that revaluation as on a specific date would be more appropriate, this way you introduce the new cost at this starting point and previous transactions would not get affected.

This will also help with closing adjustments of a financial period, which usually takes place somewhere in the following week.

1 Like

I agree. That’s how it should be working which is why there is now periodic revaluation concept. To make it so past historical figures are not affected anymore.

You are right. I didn’t think of this approach. Your idea is more intuitive and also saving user from constantly thinking what calculation method to select. Also gives more flexibility.

Start date is not required for the calculation of unit costs.

Isn’t this just terminology? Historically when you said periodic revaluations, it meant you were manually recalculating costs once a quarter or once a year with a pen and paper. Now with software, you can do it daily if you want to and it will take a few seconds. So it does behave like a perpetual system even though there is a manual trigger (pressing the button) rather than being 100% automated.

It’s not as simple. If inventory costing is 100% automated, then fixing a bug in inventory costing algorithm would affect past figures because past calculations are not saved in the database. They are simply calculated on demand.

This new approach is saving calculations in the database which means fixing a bug or improving costing algorithm in any way would not affect past figures.

Also, nice side-effect of this approach is that the system will get much faster for businesses with a lot of inventory transactions. It’s faster to simply multiply Qty owned by pre-determined Unit cost than to run inventory costing algoritm to calculate Unit cost on demand.

Revaluations as of specific dates can be done through balance sheet or trial balance. In the future, if you are looking at balance sheet as of specific dates and inventory was not revaluated as at that date, it will give you a hint to do it. And it will take a few seconds to do it. Once you set up Lock Date, then system won’t let you edit historical unit prices (just like it won’t let you materially edit transactions) so that your financial statements won’t change.

1 Like

When a calculation method change occurs there is a difference for prior entries. This needs to be accounted for by an adjustment. Who does it and where it appears can be debated.

The simplest method to change cost calculation method maybe to require creating a new item and transferring stock to that (at a price which includes any residual cost adjustment).

1 Like

No it isn’t and in any case jargon and terminology exist to distinguish meaning. I already posted in another topic on the same that a perpetual system as you had would always immediately record and register any transaction. Do you expect users to run the recalculations after each transaction? That would be the only way to have always up-to-date records.

1 Like

I agree, hence my point that it would require a much more sophisticated system. I understand that you use kind if just in time calculations on existing records, but that would still require it is based on existing data (historical) that may hange because of change in method but that is why a date to start such changed calculations is essential. The key concern I still have is that users can severly mess up their historical records and I hope that some system will be put in place to prevent this,

1 Like