أنا لا أستطيع التحدث بالإنجليزية بشكل جيد، فقمت بالترجمة عن طريق جوجل
وأرسلت الترجمة للمسؤولين لكن لم يفهموني
صادفني هذا الخطأ في البرنامج فأردت إرساله لكم لتعملوا على إصلاحه
خطأ. عند تعديل أمر الإنتاج من ٢-٨ إلى ٢-٧-٢٠٢١
كنت صنعت أمر إنتاج بتاريخ ٢-٨-٢٠٢١ عن طريق الخطأ
ثم اتضح لي أنه يجب أن يكون في الشهر ٧، فقمت بتعديله
فوجدت أن البرنامج قام بترحيل جميع أوامر الإنتاج السابقة واللاحقة، وبالتالي ترتب عليه خطأ في حساب الأرباح في كل شهر، إذ صار أمر الإنتاج بعد تاريخ فاتورة البيع
فتم حساب تكلفة الإنتاج كلها أرباحا
فلما حذفت التعديل من الهيستوري (2-7) وحذفت أمر الإنتاج كذلك الذي كان قبل التعديل(2-8) ثم أنشأته من جديد بدون تعديل (2-7) تم تصليح الأمر
مرفق فيديو يبين الخطأ
لو استطاع أحدكم شرحه للمسؤولين فليفعل مشكورا
شكرا لكم
Although this forum is in English, but the user have clearly stated his inability to communicate in English so I’m going to translate it.
The user is objecting to the behavior of Production Orders being automatically delayed and it’s effects distorting the Profit and Loss statement.
The user states that when he tries to enter a production order dated 2 Jul it gets automatically changed to 2 Aug which causes the month of July to show Zero cost and a 100% margin.
I agree with the objection since why does the software allows sales when you don’t have enough quantities but disallows use in production.
It’s inconsistent and distorts profit and loss and is very poor matching of revenue and expenses.
One solution to ensure proper expense matching is to disable sales when quantities are unavailable but this creates an even bigger problem with the software rejecting sales opportunities which is counterproductive.
The other solution is to lift this excessive middling in user operations and inputs and simply warn the user of discrepancy.
The method of artificially changing the production order date from the actual day it was done in based on to a theoretical date based on incorrect quantities of inventories isn’t all that great as it forces the user to either:
Link all process at once creating bottle necks in real life just to accommodate the systems inability to tolerate some fault. For example if the purchasing department messed up their invoices then this mess up is carried over to production because they can’t accurately enter their production which will transfer the panic to the warehouse department who will have to create an urgent stock take. Not good.
The alternative is to create an inventory write-on in the meantime just to force the production order which will create overstatement of inventory further down the line once the purchasing department enters their missed bill.
This doesn’t seem like an efficient method to do business. Instead of the error being contained within the purchasing department who will have to correct for the mistake according to their processes. The current method blows this small inaccuracy way out of proportion and makes it a problem for everyone: purchasing, operations, warehousing, sales and even financial reporting.
I strongly recommend @lubos to reconsider this. And I urge the mods @Tut@Abeiku@Brucanna to look into this problem seriously.
Here the user states that they tried google translation and that they sent the translation to those in charge [idk, maybe mods or lubos] and they couldn’t follow.
Anyway, it’s a valid problem and good material for discussion and it would be a shame to pass on discussing it based on a technicality – which is the forum language.
Because many businesses follow just-in-time purchasing practices or drop-ship from suppliers to ultimate customers. It is perfectly possible to sell something and be paid for it before you have it in hand. But you cannot produce something without having input materials. Even so, the program handles this already by allowing production to proceed and accounting for the shortage in the Production in progress account and/or completing the necessary transactions when more material is acquired. See the Guide: https://www.manager.io/guides/29016.
Actually, no. Allowing production order accounting to move forward with zero-cost items in the bill of materials would distort profit and loss. Delaying until material is acquired improves matching of revenue and expenses.
As explained in the Guide, nothing in Manager prevents production. The program only takes necessary steps for proper accounting of costs.
The date is not theoretical. It is the actual date when sufficient quantities become available.
Not true.
Again, not true. The purchasing department of our example should be alerted by the presence of a balance in Production in progress and investigate why. No one else would be prevented from entering their normal transactions.
I am sorry, I meant to say false. Stock is notorious for being misstated and maintaining stock in manager is no different than maintaining it elsewhere.
Let’s start with a scenario where we have understated the quantity of 1 raw material item (X) like so:
Item
Qty in Manager
Physical Qty
X
3
10
No physical stock is taken because it’s being done quarterly and that’s in Sep.
An additional purchase of 10 of X was later made in Aug
No big deal, right? Stock quantity discrepancies are to be expected.
Now a production run was completed with the available 10 units of X on 2-Jul, that’s a fact: it happened on that date. The system creates a false scenario that it’s produced on 2-Aug just to keep in denial about the fact that it has wrong quantities.
The profit and loss in overstated in July due to poor matching of expenses.
The equity is permanently overstated because the cost of selling product (A) never adjusts in August when the purchase of (X) was entered.
Problem no 1 hasn’t been solved but instead three other problems were created.
Now that is a big deal. Misstatements are never to be expected.
Let’s take a look now at who’s affected:
Purchasing department (for missing the invoice)
Production department (Now have their records falsified, a production order that has been completed in July is now recorded in August)
Warehousing department (showing zero stock of a product that could be solved but now they’re unaware of its existence)
The poor accountant has to stand in front of the owners and be yelled at for the system giving wrong figures.
One analogy that comes to mind is that you have a tiny spec of coffee stain on your white shirt, instead of simply ignoring it for being the tiny problem that it is; you start scrubbing at it until the entire shirt is brown. And that’s exactly how I feel about the situation we have here.
To workaround this serious shortcoming of Manager and force it to produce correct results, a stock count and a supplier reconciliation has to be done before each and every production order. That’s not realistic; nobody can do that.
Instead if we stop tinkering with things and accept the basic fact of business that stock quantities is most probably inaccurate, Manager could be fault tolerant and we can live with stock (X) being understated for a while (until a stock take or a supplier reco is carried out) without introducing a myriad of all sorts of problems.
I think the case is now crystal clear and that is that Manager currently gives wrong reports and that’s based on fact. You can reproduce the issue yourself.
The guy doing production doesn’t have access to inventory.
Also, posting a stock adjustment without full investigation could result in overstatement of inventory if the missed purchase invoice was later found. And I’ll end up chasing my tail since the quantities will be wrong anyway until a full stock take and supplier reco is made.
Manager cannot be expected to be up to date or give correct results if you are keeping up with transactions.
I have no idea what you are writing about here. Saying the program is in denial makes no sense. The program operates on the basis of what you have entered. It has no mind of its own.
Only because you have not corrected the quantity based on a physical count. You are delinquent in entering a write-on. Again, you cannot expect the program to know this.
No it is not. Your example starts with zero on July 1. You sold 25 in July. You produced 2500 in August. At the end of August, your balance is 2475 units. How is that an understatement of the quantity on hand?
No, it is not. It is overstated because of your slow purchasing. The fact is, you have not yet incurred the purchase expense for X. Yet you claim to have sold items you cannot have produced according to your records.
Not true. An asset is carried in Production in progress until the insufficiency is resolved. At that point, the debit is transferred to Inventory - cost. Retained earnings is reduced accordingly, and the accounting equation remains properly balanced.
I have. I was very concerned about the temporary inaccuracies in financial statements before the current process was introduced. Things eventually worked themselves out, even before the improvement. But if inventory moved slowly, you might carry inaccurate reports for months or years. The thing to remember is that everything is not revealed by the P&L alone. You need to consider the balance sheet as well.
small businesses have inadequate levels of staffing to carry out every control on inventory.
Medium and large businesses have ridiculously high stock levels with qtys in 100s of thousands and even in millions so a 100% stock take is impossible.
All the planets needs to be aligned right for a business to be in a position where they can have accurate stock 24/7/365.
It seems to have. I’m telling it 2500 of A were made on 2-Jul but it keeps insisting on having that made in 2-Aug on the assumption that system quantities are correct.
If it assumes things, then it has a mind of its own.
That assumption caused the cost of sales to disappear even after an additional 10 units of (X) were bought on August.
Also delaying production order didn’t do anything about item (X) misstatement. Could you please explain what did it achieve?
Both large and small businesses need procedures in place to verify physical inventory counts on a schedule that coincides with production of financial statements meaningful to management. If quarterly statements are satisfactory, quarterly inventory counts may be appropriate. Large businesses also introduce spot check procedures to verify counts on a system-wide basis. No one expects to verify inventory before every transaction. But if experience shows frequent inaccuracies, physical counts should occur more frequently. If counts usually match well, annual counts might be justified.
My point remains. It is not a flaw in the program if a company’s inventory management allows temporary inaccuracies to accrue.
The program has made no assumption. You have denied it correct data. It delays entry of the production cost until the cost is known, because the cost was presumably not zero, yet you have recorded no purchase of X until August.
You have not illustrated that. Let’s see the Edit screen of the transaction for the August purchase.
Form my 10 years of experience as an auditor and another 10 years doing outsourced accounts for a total of 200+ businesses of all sizes, I can assure you that anybody who has more than 50,000 units of anything and they think that their stock is 100% correct is just singing themselves a lullaby.
I though you’d never ask
I’ll happily do that in a second but for now I need to get us back on point here because we strayed to far off what we were discussing. My point are these:
Delaying production order did not solve the inventory misstatement.
Three other problems were introduced
The expenses was not matched to revenue as you stated earlier.
Now since it’s obvious that delaying production orders doesn’t correct stock levels and doesn’t produce correct matching of expenses, what exactly does it achieve other than messing up dates and creating new problems that weren’t there to begin with?
Sorry but poor practice. I work with and support a lot of very small businesses and a core element of any business is to know what you have in stock as that is what determines your cost and your revenue. So it is really poor practice for small businesses not to focus on the inventory that generates their revenue. I do not know where this poor practice of not being able to have correct stock much more frequently is done, but I fear for any of these businesses.
@eko I agree with what you say. It’s definitely the users fault in any case. The problem is this, we live in the real world and mistakes happen all the time:
Humans make mistakes
Software is buggy
Hardware fails
Machinery fails
Now you can have a robust and reliable system that will keep calm and not go into a chain of unfortunate events everytime it faces a mistake or it could blow up in your face just like what happens in my example.
Software needs to be robust, reliable and consistent and Manager isn’t in the case of production orders it just spat out nonsense profit and loss which isn’t justifiable no matter how many mistakes the user did and no matter how undisciplined that business might be.
Just to focus on the issue, what we are discussing here is Manager systematically processing data the wrong way.
Sorry but I disagree, this is not a technicality. If we all communicate in our native languages this forum and the peer support would suffer and this forum would just not be functional any more. So should we now accept Nederlands, Deutsch, Español, Italiano, Polacy, فارسی, 日本, 中國人, русский, ਪੰਜਾਬੀ, etc.
Stock is notorious for being misstated and maintaining stock in manager is no different than maintaining it elsewhere.
