Dear @lubos. Please have a look at this. I have approx. 20 SKUs out of 500 SKUs where I have this issue. Inventory qty is nil but there is a cost. Upon drill down, I noted that sales invoice value is not properly captured in the inventory movement due to insufficient quantity. Subsequently, production orders were created to fix this. I have attached the screenshots of inventory and related sales invoices for your reference.
Sure, refer below the screen shots of productions orders.
There no balance in production in progress asset account i.e. it doesn’t show up on the balance sheet because it has nil balance.
I assume that if you drill down through Production in progress all the way to production order #14986, you will see something similar to what you saw for production order #8475, and that the final credit to zero that subaccount will be 29,040.32. That will mean that all of your current balance for inventory item #2770 was transferred from Production in progress.
So there are two “insufficient quantity” numbers to look at. One was the insufficient quantity shown for the two sales invoices in the drill-down of your second screen shot. But that is apparently not, as I thought originally, the source of your problem.
The other insufficient quantity (or quantities) was the one that resulted in the entries into the Production in progress account. That type stems not from insufficient quantities to fulfill a sales invoice, but from insufficient inventory items in a bill of materials to complete a production order. This type of insufficient quantity is not resolved by producing more finished items, but by purchasing more of the missing items on the bill of materials. See the Guide: Understand insufficient quantity on a production order | Manager.
So you will need to trace all the items on the bills of material for both production orders from original acquisition through consumption by production. I am puzzled by the fact that the two production orders for the same finished item (2770) have two different bills of material. But perhaps you have two different methods for producing the same finished item. Nevertheless, that will complicate your tracing actions.
The thing to remember is that no production order can be completed and its costs properly transferred until the average cost of all items on the bill of materials can be determined. So when you have overlapping purchases and production orders, especially including production via different methods, things are going to get complex.
Eventually, however, I believe you will find that you have a mistake on the purchasing side that left you with residual costs despite having no inventory left in stock.
Thanks @Tut for your time on this subject. I’ll drill this down to the bills of material as you suggested and see if I can resolve this. I’ll share the results with you in a few days. Thanks.
Hi @Tut. I explored this further in the backup business and noted that once I changed the dates of the production order to be before the sales invoice date (i.e. 2 May 2018), it fixed the issue. Refer to the screenshot below. Compare this with the screenshot in post #1. Is this not a bug?
Let me explain this further. I decided to sell a particular inventory item (say item # 123) knowing that I do not have this in stock, however, I have the required materials to produce that stock and later, say after a month, I create a production order to produce the stock (item #123) that was sold. Manager should take this back-order into account once I have created the production order but it doesn’t.
@applet, I disagree with your assessment. Your experiment hid your problem rather than solving it. When you sold these inventory items, you did not own them. But the fact that your production orders ended up in Production in progress shows that, when you created production orders to resolve that issue, you also did not own the necessary items on the bills of materials, despite your belief that you did. The multiple debits to Production in progress shows that events occurred in stages, some of which you have not shown. Possibly, these inventory items were involved in other transactions. I cannot tell, based on what you have shared.
So I reiterate my advice to trace the purchasing history of all items in the bills of materials for the two inventory items. Be aware that by experimenting in your backup file, you are looking at a different set of circumstances than what exists in your real data file. Some of the transactions will disappear. Therefore, you cannot necessarily draw conclusions from your tests that are applicable to your actual records. Find the problem before trying to fix it.
I create a finished product (Penneys) using two inventory items (Marks & Spencer).
1 November: I purchased both, Marks & Spencer.
2 November: I sold Penneys having sufficient qty of BOM to create Penneys at the date of sale
3 November: I created a production order equivalent to the units I had sold on 2 November.
It results in the same error as I had mentioned earlier i.e. nil quantity with value. Should Manager not consider the same as back-order and adjust as it does with entering purchase invoices subsequent to the sale?
Actually, your screen shots do not demonstrate this. Your final screen shot shows only transactions contributing to the total cost of the Penneys inventory item. To show what you claim to be happening, you would need to show the Inventory Items tab listing.
I duplicated your experiment exactly in a test company devoid of all other transactions. The result is the following:
Notice two key differences from your final screen shot:
The final balance is zero.
The sales invoice, which was entered on 2 November as in your example, was not posted until 3 November, the date Penneys became available to fulfill it because of the production order. This causes me to believe you are using an outdated version of Manager. What version number are you using?
Going back to your original problem in your real business, I realize you never reported whether you had traced all the items on the bills of materials for production orders related to item 2770. Instead, you tinkered with production order dates. Then you experimented with a different situation in a test company and misinterpreted the results of your experiment. And that takes me back to my original recommendations.
Update your software, then trace all the input items on all production orders related to 2770.
This seems to the key difference between your test and my test. My version of manager 20.10.65 doesn’t HOLD the posting until the stock is backfilled which in our case is 3 November. If it does, then it will resolve the issue under discussion.
I am using the same version. Edition (cloud versus desktop) is irrelevant.
Exactly. It cannot be posted because the average cost is not known, so the transfer of cost from Inventory on hand to Inventory - cost cannot take place. This was the subject of some improvements a couple months ago. The program holds the post until average cost is known. If necessary, the posting occurs in stages, such as if you purchased or produced smaller lots than you had sold on the sales invoice.
That may be true. But what counts is whether they were available on the date of the production order. The presence of the transactions in Production in progress tells me they were not.
The problem is with your sales invoices. Looking back at your initial posts, I now realize this is probably true for your real business, too. Regardless of when they are posting, they are posting at zero quantity and cost. I got sidetracked by the other issues.
Are you absolutely certain you have restarted your cloud server recently so you are on 20.10.65? Double-check here: https://cloud.manager.io. I doubt that will make a difference, but it is worth a try, to make sure you have picked up the posting-date improvements.
I should have asked you about production stages. When I did my test to replicate your example, I automatically set it up so Penneys was production stage 2. I suppose I thought, since you had been using production orders, you would have mentioned seeing the warning banner about elevating production stages. I’m glad everything is sorted out.
