Hi,
I am up to implement "my version" of uc_stock, but I am wondering if there isn't anything like this already written.
Motivation:
For accounting and managing my warehouse I need to remember what I bought stuff for and what I sold it for - the suppliers change their prices from time to time so...
Here is the idea:
Instead of remembering the qty of a given SKU i need more:
- I need to know when (date/time) each item was stored in stock and what the price I bought it for was.
- Later I need to remember what I sold it for and when that happened.
- Also I'd like to remember the order_id of the order that sold the item.
Is there anything like this done already?
If not, I already browsed the code and it seems to be not so difficult. Here's the plan:
- I'll keep the "uc_product_stock" table, just will remove the "stock" column.
- I will add another table which will be something like "stock_units", which will have just the information mentioned above: mandatory buying price, date and the SKU of course, voluntary selling price, date and the order_id.
- The amount in stock is the count of units that don't have the last three set. Sold units are also kept in the table.
- When a unit is sold, instead of decreasing the qty, the given amount of free-for-sale items is picked from the table and the selling price, date and order_id is set.
So this implies some changes. As far as I know the "Stock form" for each product has to be altered so that the qty can not be changed (does not make sense anymore)
- The amount in stock is read-only and the number itself could lead the sore administrator to a view of the table described above for the SKU (for the product).
- A new form for store administrators is needed: one that does what the previous form can't do anymore: get stuff into stock. One has to enter what the buying price was.
So, if you sell something, the catalog tells you the selling price. When something is sold and later the catalog price changes, the selling price for the item sold before is kept - all this is needed for accounting stuff, like I bought 4 guitars this month for $x, sold 3 guitars for $y and thus I should have $(y-x) in my pocket... And my suppliers can change the price twice a month if they want.
I hope this is understandable enough. I will be very grateful for any suggestions, tips and questions AND I will reply to them (if on-topic). And if I will have to do this by myself, I will make all changes public and well documented of course.
Richard G. Bayer
EDIT: Changes to this proposal are lower. That is:
- Some data would overlap with information in the respective order (table uc_order_products) so that can be removed.
- This approach enables us to remember each items location (like which warehouse it is in).
.