To keep track of inventory on-hand at different retail branches, we model each individual Stock Item ever purchased and its current location as a field on each entity. This makes it easy to trace faulty stock and where a unit has been inventorised over time.
Problem is, how to model the location of an individual stock item when it can reside in either a Stock Room or some Box in transit that is en route to another location, without muddling the data types of Stock Rooms and Shipments, and potentially other types of locations?
The only solutions our team can think of is to consider that a Shipment is a Location where a stock item can reside, which unfortunately has a source and destination location as well (yuck), or we need to write logic to exclude packaged up stock units when we conduct stock counts, which makes the current location field untrustworthy.
Both solutions seem messy to me. Alternatively, we may need to consider some generic stock accounting design.
Has anyone implemented this kind of stock tracking and is there existing literature about this with accompanying complexities and pitfalls?
I have no experience or literature, but it would seem to me that modeling a Shipment as being on a particular Truck at a given point in time would constitute a meaningful location.
You wouldn't have to track the source or destination location for a Truck entity; a VIN or some other unique ID would do.
I can imagine that a Shipment might change hands several times: first on a Truck, then in a Plane, onto a Train, then another Truck. Perhaps the abstraction is MovingLocation. A unique ID for each would tell you exactly where the Shipment was at a given moment in time.
Each MovingLocation could beacon out there instantaneous lat/lon location as a time series. You don't say if keeping track of that is part of your calculus. I'm spitballing here.
Related
I have Stock table.
sku
quantity
quantity_sold
price
seller
I have StockExtra table for products that has date/time property (you can think of event tickets)
stock # references stock
quantity
quantity_sold
price
date_at
time_at
datetime_rule # foreign key to another table, it is a rule that describes when events occur
For event tickets, I use stock and seller from the Stock table, but use quantity from StockExtra table. Because a ticket at different date can have different quantity and price.
I've divided the tables but not so sure if it is the best practice.
Now I need to create another table to hold stock data for separate market stores.
(I'm making a system where seller can manage his inventory when he sells products over multiple stores)
One could sell event tickets in amazon.com and in ebay.com for instance.
And the price, quantity in each store might be different.
So there will be one to many relations from Stock to StoreStock.
Stock will hold default price and aggregated quantity/quantity_sold for all stores. StoreStock will hold data for an individual store.
And I'll also need one to many relations from StockExtra to StoreStock due to the same reason, i.e price/quantity might be different for each date/time for event tickets.
So with my current setup,
there will be Stock StockExtra and StoreStock.
Would it be better to have just Stock and StoreStock even though date/time related fields will be empty for non-ticket products?
You should think about reducing the complexity of your system by keeping everything in a consistent way. Keep complex scenarios in the same tables as simple scenarios.
By keeping the same information in different places (e.g. Stock vs StockExtra, or Stock vs StoreStock) you are creating a situation in which your code has to have extra branching to find the data depending on the situation.
When you're going after the data for a single transaction, branching isn't the end of the world, although it is more code to have to write, debug and maintain. However, when you go after data in aggregate, having it spread across multiple potential locations makes your data retrieval much more complicated.
I would recommend keeping everything at the most detailed level. Therefore everything goes in StoreStock even if there is only one store applicable to a particular situation. Then, unless you have a demonstrable performance issue, don't split off StockExtra from Stock - Just use nullable columns in Stock.
It's OK to keep default prices in Stock, but use a more descriptive name for the sake of the next guy that has to maintain your code. I'd advise against tracking sales quantity in the Stock table. Keep this in StoreStock only. Don't keep a pre-calculated quantity on hand value. This will inevitably be out of whack. Instead, track quantities added (receipts) and quantities removed (sales) and calculate quantity on hand dynamically. This will avoid inventory reconciliation problems.
I have been given the following scenario :
HyperAV is a retailer of home cinema equipment. They sell a variety of products including televisions, speakers, amplifiers, Blu-ray/DVD players and cables. The company has its head office in Stockport and 5 retail branches around the UK (in London, York, Cardiff, Manchester and Newcastle) and a large warehouse in Birmingham.
Due to the specialised nature of the products most sales are made in the shops which also have demonstration facilities allowing staff to show off the products to customers before they buy. However, the shops can also take orders over the telephone. The company deals with a number of suppliers who deliver items to both the shops and the warehouse. Limited space is available in the shops, so large numbers of items are stored at the warehouse and sent to the shops when their stock runs low.
The company’s buyer and stock controller are based in Stockport and work together to ensure that each branch has an adequate stock level of fast-selling items. If a shop takes an order for a product that it does not hold in stock, payment is taken and the item is sent to the shop from the warehouse. If the warehouse does not have a product in stock, it is ordered from the supplier by the buyer.
From this scenario I have been asked to draw a use case diagram.
I have received feedback but only to an extent where I have been told it is slightly incorrect. I would like to know if anyone can see what is wrong with it or how i can improve it in anyway?
I will not go and analyze what is right/wrong with your business case, but here are a few remarks:
Do not use Generalization with UCs. Each UC shall be a unique added value the system under consideration (SUC) delivers to the actor. If you have Generalization this means your UC is not unique. E.g. Deliver product: these are two absolutely separate UCs. They use a delivery service. But that's a UC for another SUC (namely the delivery service).
Avoid the use of <<include>>/<<extend>> as they indicate the use of functional analysis. UCs are about synthesis which is the opposite of that.
Use verb-substantive to name your UC. Order for example is not a UC.
Think about the "use" in UC. What is the added value it returns to its actor? If that is not of a real use, it's not UC. Process payment is an administrative task, not a UC. So what is the use behind this?
Having a few issues with my database design. I have designed my system like the following image
As you can see it is a pretty basic system to a point. A user can create a supplier by adding supplier details. A user can then add a product and link it to a supplier. Thats the pretty straight forward bit (I hope!). Now I will attach my database design which should hopefully cover what I have mentioned.
So a supplier can have one contact (person within the suppliers company the user of my system will contact) and a supplier can have one to many products.
He is the part I can't figure out. Twice a week, the user of my system will receive stock from all their suppliers. When they receive this stock, they should go into the update stock screen within the application and input the amount of stock they have received for a certain product. I have added a products_stock table which should hopefully put me on my way to cover this aspect (I think it is missing a lot though).
The last screen however is a display of predicted stock. Lets say for instance on the day my products are delivered, I receive 10 units for Product One. I will then manually count the number of units I have left from the last order for Product One (say 2) and update the stock count for Product One to 12.
This means, that really, I only needed 8 units between the two deliveries for product one. The predicted stock screen is supposed to show the predicted stock levels I should place an order for, for a particular product, over a specified time period. So if 8 units was the average stock sold for product one per week, if I wanted to see how many units I should order for product one for a month, it should display about 32 units.
This is not supposed to be a complex system, it should have this manual aspect to it. I have designed the database up until a point, I was hoping I could get some suggestions regarding the products_stock table and how I can handle stock predictions for a specific period of time (if I maybe need additional tables).
Any advice appreciated.
Thanks
Inventory is more like a view and not a table. Inventory is really a series of movements of goods between locations, as well as periodic counts / adjustments.
Inventory is complex. You should play with some inventory software and read some data modeling books.
Use the concepts of Locations (real and virtual) and Movements (a movement should be its own entity).
Item smashes? Move it from its inventory location to the "damaged" location
Item went missing? Move it from inventory to the "ether" location
Found a random Item? Move it from "ether" to inventory
Sold an Item? Move it from inventory to "sold"
Bought an Item? Move it from purchased to inventory
Some other things to keep in mind:
You could sell something, and it's returned, and you put it back in
inventory
You could buy something, but it ain't right, so you send it
back to the seller
You could sell something that you don't own (on
consignment, or not in inventory yet)
You might have something in
inventory that is not currently for sale.
I won't get into the accounting aspects of inventory :)
One possible approach:
Have a separate "stock item" record for each unit received. When it is sold, record the date of sale in this record.
Then if you want to know how many items were sold in a given time range, just count the records with sold dates in that range, like select count(*) from stock_item where product_id=#product and sold_date between #from and #thru. If you need to keep track of items lost to spoilage, theft, whatever, then you might have a status flag of some kind that says whether it's in stock, sold, destroyed, whatever, and also the date of that status.
If the number of units that pass through is large and there's no other reason to keep individual stock records, you could just have "daily sales" records instead, with a date and number sold that day. Same idea.
I know this seems silly but I'm having a really hard time with this structure.
My data model is for a computer store (strictly academical only), so I have a generate product table for things like, title (i7 4790) description, unit price and specifications. Then it links to suppler and Category.
Category will have all the parent Category's like motherboard, CPU, power supply etc.
But now I'm not sure if I should then go and have a table for each of, referring to the category table, so motherboard would have things like, chip set and socket, CPU could have a chip set as well, and maybe clock speed, power supply could have capacity.
But then I could have a sub category table That referring to itself, but I'm not fully sure how to structure that.
Please could you help me with the right design decision and why it's the best decision, also what are the pros and cons per solution.
EDIT
Here is a quick Model that i wiped up of my thinking so far. The product table will hold the general details of all products, such as Name of the product, Unit price, Description and Specifications and they will then link to the catagory table that will then link to the different tables, like motherboard, CPU, Memory etc.
The reason im thinking like this is because each catagory, Motherboard, CPU Case etc, is an entity on its own, an object on its own, so it deserves a table of its specific attributes.
Am i on the right track ?
I just answered a question along these lines. You can have a Product table with all the data that is common to all products (SKU, shipping weight, mfg, mfg order num, retail price, etc.) and then, using the Categories value, place category-specific data in separate tables, using the category value to enforce the integrity of the whole system.
I'm trying to make the database system point of sale, however I am confused between the entity and product inventory entity. What are the differences between product and inventory?
I know that the inventory should control the amount of product available .... but i have all that in products.
product code
name
description
cost
unit price
Subcategory code
brand code
amount available
Minimum quantity for rehearing
state
tax code
weight
amount wholesales
wholesales price
perishable
due date
creation date
upgrade date
what i should have in inventory? I have researched and according to what I read I need to have the product, the description, the quantity, purchase price, sale price, profit or gain and date of the transactions. But almost everything is in the Products table, what should I do?
A Product is an abstract Good or Service. A Good is the specification of an Asset.
Example "2014 Mazda 3" is a good. A "2014 Mazda 3 with VIN 12345" is an Asset.
A Catalog is the list of products that you want to sell. They don't need to exist yet, or you could be selling them for someone else.
Items Held For Sale are assets that you keep around to sell. These could be consigned (owned by someone else).
Inventory is an accounting concept. It is the dollar value of the items held for sale that you own, plus inbound and outbound goods that you're responsible for, plus any costs associated with holding that inventory.
You can track the value of inventory in a variety of ways such as FIFO and LIFO
I think you can store the inventory in the products table. There will certainly be transaction tables for purchases for the products and sales and even adjusting records (when items get count and the number differs from what's stored in the database), but you can easily work with the stock stored in the production table itself, thus not having to scan the whole database and sum up all purchases and sales and corrections every time (and never being able to delete old transaction data from the database, as that would invalidate the calculations).
However there are reasons to have stock stored in an inventory table instead. For instance if you want to store different statusses, e.g. you have 100 pieces in store plus twenty just arrived and still unchecked. Or you have a store with goods plus a warehouse housing additional stock. Or you have charges (different model numbers for example for a slightly altered product) which you offer as the same product, but still want to know how many old and how many new ones are in stock. And so on.
So make your mind up, if you want to store additional data with product stock, which would result in an 1:n relation instead of 1:1 which you have now.