But so far you did not provide any proof of that. You seem to confuse business practices with the application. No application, will correct poor operational practices. It is the Garbage in, Garbage out (gigo) principle that applies here. So if someone does not manage their business well then not any software will rescue them. Especially in case of small businesses there are few essential parameters with or without software that need managing and inventory for any small business that is selling is crucial. If anything many small businesses go bankrupt simply because they can not keep these basic practices, Cost control (inventory and supplier negotiations, credit, etc) and Revenue (sales prices, credit, etc.) in check. Manager in its most simplest implementation helps anyone serious enough to check and enter the related data and thus supports analysis that can make them more profitable. No accounting application that I came across is a substitute for good basic cost and revenue control. They help if you keep data up to date but will never replace the operational practices. It is too easy to blame a piece of software for what in essence is just poor business practice.
I disagree. That’s completely besides the point.
-
I can accept this if the only mistake carried over was the initial misstatement of stock quantities but it didn’t stay that way, it blew up to multiple misstatements.
-
If the user made production order after the invoice there might be a discussion on whether it’s GIGO or not. But the production order was made before the sale and there was no previous transactions or balances to mask the flaw.
This topic is almost impossible to follow. Can we find some common ground first?
@Ealfardan If you sell inventory item for which the cost is not yet known, Inventory - sales account will show sale amount. Inventory - cost account will show zero.
Do you think it’s wrong? And if so, what do you suggest as an alternative?
Yes, because the cost should be known since the production order was made on 1-Jul, the same day the sale was made.
The production order was only held up because manager refuses to process production orders when stock quantities are not 100% correct. This caused manager to sell 25 units out of thin air.
But @lubos my question is this, what purpose does delaying production orders serve?
-
It’s not based on users observation of actual production
-
It doesn’t do anything to correct quantity misstatements so a write-on/off has to be done anyway
-
It only gives the appearance of proper matching but when you take away previous balances that mask the true behavior, it doesn’t really do any matching
My alternative is this, since even after supposed “correction” took place there’s still the original mistake plus some more and 4 mistakes are blamed on user error; why not keep the original error and blame it on the user since we’re going to blame it on the user anyway without introducing new mistakes?
How do we know the cost of output item if cost of one of the input items is not known?
X had an opening average cost of 15 and a quantity of 3. But since product A has already been produced and sold the quantity in the system must be wrong and the true quantity is at least 10.
The average cost could be approximated by what we have since the average cost is just an approximation anyway.
So that should give us 10 × 15 = 150 of cost from item X.
After the production order is processed we should have -7 of stock @ 15 which gives a credit balance of 105, which is the original variance we started with but it’s carried over to the future where it can easily be corrected by simply writing-on 7 units at the current average cost.
Until then, the BS is equally as wrong as when we changed the date of the production order – but that’s unavoidable if there’s stock quantity variances – but at least now, profit and loss should be more faithful to the true activities of the business.
I do have a problem with this because:
- What if you have 0 qty and can’t do approximation? What if this item has never been purchased so the cost could really be anything.
- And even if you can estimate the cost, what if actual cost is going to be different than estimated cost? What is going to happen to the difference?
- But the biggest issue I have with this approach is that you are putting into profit & loss expenses which didn’t happen. Yes - for management purposes, you get better idea of your profit. But for tax purposes, this is wrong because these are pretty much made up inventory costs at this point.
I have said everything that I could say, if that’s an assumption you’re going to base the costing on then it’s your call. But all I know is this: if you keep everything else equal, the resulting figures will be wrong.
I’ll make one last suggestion. Why not split production into:
-
Production runs which documents actual production made and observed by the user.
-
Production orders which are just that – orders. Orders are copied to production runs to take effect. You can delay orders but when user wants to force production, they can.
I trust my suggestion is going to be picked apart as always 
but to me that’s a good solution right there.
As an accountant, what is more important to you? Having financial statements accurate for tax purposes? Or having financial statements accurate for management purposes?
Accountants rely on Inventory - cost account to be objective value of costs which is tax deductible. Once we start mixing in there costs which are estimated, then I think that’s a problem.
That depends on the situation, really. But even tax authorities give plenty of leeway when it comes to inventory valuation so I wouldn’t be too concerned about that. But if that’s the case somewhere in this world then I can’t really object.
What do you think of the alternative I proposed about production orders and runs?
Which post is proposing the alternative? Can’t find it.
Edited
At the risk of putting my oar into the water again and having it bitten off by a crocodile, I have to disagree with this. In my experience, tax authorities are very concerned with inventory valuation. I know of at least one example where people went to jail for fraud related to inventory valuation.
@Ealfardan, you keep insisting the program should be able to attribute costs to production for materials that have not been purchased. And you keep asserting that the program propagates “errors.” The only errors that are propagated are due to inaccurate inventory counts. These could be from wastage, theft, spoilage, or earlier miscounts. But if the program doesn’t know about them, it cannot compensate. So that pushes things back on management to institute procedures that will discover miscounts on a basis that is timely enough.
You also keep overlooking the fact that Manager keeps accurate track of the pending production orders and completes the accounting for them as soon as acquisition of insufficient material permits. And don’t forget, as I have already stressed and as the Guide says, production orders do not control or limit production if material is actually available. It only leaves the accounting pending until numbers are known. In that sense, Manager is not a production management tool; it’s still an accounting tool.
Fraud and error are legally two different things. Fraud has intent behind it but errors don’t. It all depends on how tax lawyers or panels establish intent.
And I wouldn’t worry about having my ears bitten off. In this forum every idea is picked apart to the bone to see if it passes the screening, and that’s a big part why Manager is a great software.
Why do you assume that? They could’ve have been purchased, but missed for some reason. Maybe they were in transit during stock take, maybe they were miscounted, maybe they were mistaken for another item, etc. The WCGWs here are countless.
But it completely left out the entire cost of sales in my example. That’s a completely forgone tax deduction not only for the involved item (X) but also for the other items Y and Z. That’s a bit wasteful.
You can of course go with my first “aggressive” method and then write-on the entire negative stock quantity and that should remove the tax discrepancy of item X entirely but still deduct the cost of Y and Z.
Or if there’s a law somewhere that prohibits this then I already conceded after @lubos mentioned that there might be some tax concerns here. So I have made another suggestion.
Now my ear’s in the water. You’re welcome to pick my idea apart.
Because for record-keeping purposes, they have not been entered.
That would not happen. First, your example was a write-on, not a write-off. Second, if it had been a write-off, the cost would have been posted to a suitable expense account.
You lost me right there.
@Ealfardan, my apologies. When I read your post #34, I read “write-off,” while you had correctly written “write-on.” So please ignore that comment.
This is how it actually worked previously. The cost of output item was calculated based on what was known at the time. But this created new set of problems. For example, profit margin report was not giving correct figures for sold products, customer returns were not adding back to inventory on hand correct COGS amounts and more… And it was impossible to read into what is going on. This is why I came up with the concept of production orders and special balance sheet account called Production in Progress. This is all to handle negative inventory scenarios.
There is quite a bit of history behind the current implementation. I’m confident inventory module is bug free at this point no matter how much complexity you throw at it.
But this all comes at some compromises. One of them is that COGS is very strict. It won’t show entries until they are known which can be some period of time after the sale.
For management purposes, I think Cash Flow Statement - Indirect Method is better report to judge health of the business. It tells you your profit but also how it all reconciles to cash. If your profit is due to having big increase in production orders - then this report will make it obvious. I mean this is why Cash Flow Statement report was concieved in the first place. Profit & Loss Statement on its own can’t give you proper picture on health of your business.
My proposal is a tiny bit different. I’ll jump to the end here and I hope my words don’t betray me.
-
Production orderstab name changes toProduction runsand restrictions on dates are lifted. This shouldn’t have any impact on historical transactions. -
A new tab called
Production ordersis created. These transactions have absolutely no effect on the general ledger, but the availability dates are enforced here. -
If the users wants to go through with production at system suggested dates, they simply copy the production order to a production run.
-
If the user doesn’t accept the system suggested dates, they can copy to a production run and change the dates.
-
If the user wishes to forgo enforcing availability dates altogether and they don’t need production planning, they simply deactivate production orders tab.
And since production orders have no impact on the GL, there’s not going to be any inconsistencies due to user override of availability dates.
But I don’t quite understand what this proposal is actually solving.