There is a feature in ERPNext → Stock Reconciliation that behaves almost like Stock Entry. The goal is for a company to update its stock based on a physical stock taking. The only difference from Stock Entry is that you enter the “actual available” quantity instead of the difference quantity.
A lot of the functionality is duplicated from Stock Entry. What we are proposing is
Kill Stock Reconciliation (move existing ones to Stock Entry)
Create a new Stock Entry type (Stock Adjustment)
Allow removing and adding items in the same Stock Entry (to change valuation rate).
I think this will suffice all use cases. Please let me know if there is some use-case we have missed out.
I think that stock reconciliation should be improved, at least the process behind that.
Then, if ERPNext would put together stock entry or keep it “stand-alone” is secondary in mine opinion.
Nowadays, still many inventories are done by hand and only after, the user fills the form.
The user often wants to see the differences between before and after before submit
So, I base this hypothetical workflow that should follow these steps:
Load the list of all items transacted in the fiscal period with the option to choose all or just some warehouses and an option to hide items there have stock == 0 (give some more filter to user in order to include/exclude something)
User will perform the physical inventory with eyes + paper + pen (or eventually a scanner/RF Terminal, I skip this step)
Coming back to the computer they input for each item the new qty
(optional) they can get/print a report about how will be the situation (including differences) and all differences in details
Its fine to use either, but one thing that really bugs me with Stock Recon is that I have to manually insert the warehouse for each new row of item. That should be placed on the header leaving the user to only update the item on reach row.
Or even a better route would be to set the Warehouse at the top and let it fill automatically on all child rows, allowing the user to update a particular warehouse if needed.
Hi,
This feature is covering a business process required by accounting dep world wide, each company they do physical inventory yearly or more frequently to adjust system onhand qty with real onhand. Adjutment as stock entry is required in case of mistake done by end user during data entry and he wants to do correction.
Internal/external auditors check if physical inventory completed or not.
I strongly recommend to keep reconc stock process.
How you guarantee that physical guarantee completed and company comply with regulation rules.
I hope it’s clear to not kill students ck reconciliation process.
@rmehta I do agree with you in killing the Stock Reconciliation.
One important thing missing in this, is that we can’t reconcile serialized items.
The unique decision I’m not 100% sure about Stock Entry, is why serialized items, dont create one entry in the Stock Ledger per Serial No?.
In terms of auditing it’s really hard to find one specific entry, and there’s other edge cases, that if we by pass a certain limit of entries in the Text field, the information will be cutted off, and we will never be able to audit that.
I believe it is a required feature. We do a stock reconciliation regularly and it is a good starting point. What is required is reconciliation of items with serial numbers and batch numbers.
Killing stock reconciliation is good idea. Simplyfy the system as much as possible. also i think, the items(stock balance, stock summary, stock…etc) under stock reports section can be merged.
Seconded. One of our clients do this so being able to track the adjustments as a stand-alone document (separate from stock entry) is a must. Pen and paper method is also very common for retail stores (especially small/medium ones).
From a developer perspective, it’s easier to maintain the code for Stock Reconciliation if it’s separate from Stock Entry. Also, just as methods/functions should only do one thing, I think it would be better to keep Stock Recon and Stock Entry separate as they do different things. Recon does Adjustments whereas Stock Entry is for moving stock from one warehouse/location to another (generally).
I personally would like to keep them separate rather than going through the whole ordeal of merging two doctypes containing different kinds of logic (and code). But this is just my personal opinion and preference as a programmer.
On a side note, the people with custom apps working with Stock Reconciliation are not going to like this.
It was easy to set Roles and Permissions when Stock Reconciliation is a separate Doctype. Ideally it should only be used on specific dates, therefore permission could be withdrawn and given back again easily, by changing Roles.
Stock Entry however is a Doctype that is used regularly so we cannot revoke permissions for it. We may need to use custom scripts or may be user permission records for allowing other “Stock Entry Type”, for each user using Stock Entry.
Apart from the above I do not see any difference in our operation.
I think it’s not a bad idea to use Stock Entry. However, I think the problem with using both Stock Entry approach and the present Stock Reconciliation is that it only works for those that do not have to manage lots of inventory. If I have say 500 items, I don’t want to have to go through the grueling counting process only for to start another manual process of creating 500 Stock Entries.
I agree with @fromthestone. I am actually in the process of porting an app that improves Stock Reconciliation almost in the way described above.
We have a submittable doctype called Stock Sheet which basically replaces a physical stock count sheet. Apart from the items, it also contains the name of the user who counted, the time counted, location counted, etc. It also allows the user to scan items into the document. The stock sheet is expected to be used during counting days by multiple users across multiple locations. The Stock Sheet is also printable and each Stock Sheet document only contains items from one location.
There is also another doctype which does the actual stock revaluation. It allows users to ‘import’ as many stock sheets as needed (this will typically be all the submitted stock sheets for the count period). The doctype will consolidate all the items counted and do the necessary revaluation.
My submission is, let’s not kill Stock Reconciliation. It should be improved. My solution is already available as a custom app (albeit buggy, tested on v10 only). It takes the physical counting process to the ERP and removes the need for any other manual input. I already made a commitment to some people to propose the improvement (cc: @olamide_shodunke, @wale ). My proposal is to improve Stock Reconciliation and maybe also implement @rmehta solution
Agree, the way Stock Reconciliation behave is very strange and should not be used in production. For example, if you make reconciliation on 31/12, and then make a back-dated Stock Entry before 31/12. The new Stock Entry will not be booked and ignore since Stock Entry reset Valuation and Qty on 31/12, as a result, the balance on Stock Ledger and General Ledger for Stock Account will mismatch.
I[quote=“tundebabzy, post:13, topic:49983”]
If I have say 500 items, I don’t want to have to go through the grueling counting process only for to start another manual process of creating 500 Stock Entries.
[/quote]
you can add multiple line items in Stock Entry
Private app is not useful to the discussion. Seems like another version of Stock Reconciliation
At this point it cannot be the basis of any decision!
Stock Reconciliation (SR) is one of the most used features in stock management. And we surely use it ALOT. The physical process itself and accurately capturing it in the ERP can easily get difficult. I think killing SR is fine if this improves or does not affect the difficulty of the task. I’m sure you’ve put some good thought to this.
Ease of use - the current SR is designed to make the reconciliation process easy. I wonder if the generic Stock Entry would match. SR features such as Add items (from warehouse), Valuation Rate (without expanding a line ), Download and Upload an excel sheet makes the process much easier.
Permissions [solved] - Often in ERPNext it’s easy to restrict a user to specific documents. But restricting a user from a field specific action (e.g changing the Stock Entry from Stock Issue to Stock Transfer) is not straight-forward, I’ve been using ERPNext for more than two years and I’m not confident I can do this within 3 hours, let alone train non-technical users.
If the change doesn’t improve on these, at least it should maintain the current usability. I think all other technicalities can rightly fit on the Stock Entry.
Having thought about it, Stock Entry was a very good name for such an adaptable document.
you can add multiple line items in Stock Entry
), Download and Upload an excel sheet makes the process much easier.