I have a table of all zip codes (and states) and sales tax rates and a table of merchants. I am trying to store which merchants charge sales taxes in which states. I was planning on adding a table which maps merchants to states they charge taxes in. However, there are a bunch of exemptions for different categories. For example, New York doesn't charge sales tax on clothes if the total is under $110, and Vermont doesn't charge sales tax on clothes at all.
Can I store something like that in a database in a clean way, or should I create a messy helper file that includes these rules?
You're in for a world of hurt if you try to roll out your own billing from scratch. There are also city, county, special purpose district, and transit authority taxes with various exemptions rules depending on where you are buying from.
Recommend using third party billing — for a lot of reasons, mostly outside of the scope of SO. With third party billing, you just need to concentrate on classifying the items correctly.
Is your intent that you will use this database to calculate sales tax, or that it is purely for reference/information?
If you're using it to calculate the tax, then a "messy helper file" would be, well, very messy.
If you're trying to deal with sales taxes from many states, then as Buddy says, this is a huge job. I had a little business in Ohio for a while and I was only selling one product and only had to deal with Ohio taxes, and it was still a complicated mess because of all the different taxing entities and different rates. Worst was the sales tax to support mass transit in Cleveland, as the places where this tax was imposed did not follow any simple geographical boundaries, that is, you couldn't just say "county X, yes or no" or anything like that. The only practical way to tell was to submit an address to their web site and they'd tell you if it was within their boundary. If you have to deal with all 50 states I'd be terrified at all the special cases that are likely to come up. So if you can find some third party software to do this, I'd seriously consider it. Somebody who has the resources to study the tax laws of every state and figure them all out and keep current on them.
Failing that ... I'd say you'd have to go through every state's laws and figure out all the cases that you have to deal with. Many states exempt some categories of products, like food and clothes. Some have different rates for different products, like surtaxes on luxury goods. I hadn't heard of an exemption up to a certain amount before, but apparently that's something else to consider. I'd say you have to find out what all the rules are, what data you need to support each, and build a monster table of all these rules. Presumably the table would include columns for applicable taxing entity, product category, rate for this category (possibly zero), and dollar threshold at which the rate applies. Maybe you'll discover other things.
Related
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.
I am currently working on a web application that stores information of Cooks in the user table. We have a functionality to search the cooks from our web application. If a cook is not available on May 3, 2016, we want to show the Not-Bookable or Not-Available message for that cook if user performs the search for May 3, 2016. The solution we have come up to is to create a table named CooksAvailability with following fields
ID, //Primary key, auto increment
IDCook, //foreign key to user's table
Date, //date he is available on
AvailableForBreakFast, //bool field
AvailableForLunch, //bool field
AvailableForDinner, //book field
BreakFastCookingPrice, //decimal nullable
LunchCookingPrice, //decimal nullable
DinnerCookingPrice //decimal nullable
With this schema, we are able to tell if the user is available for a specific date or not. But the problem with this approach is that it requires a lot of db space i.e if a cook is available for 280 days/year, there has to be 280 rows to reflect just one cook's availability.
This is too much space given the fact that we may have potentially thousands of cooks registered with our application. As you can see the CookingPrice fields for breakfast, lunch and dinner. it means a cook can charge different cooking rates for cooking on different dates and times.
Currently, we are looking for a smart solution that fulfils our requirements and consumes less space than our solution does.
You are storing a record for each day and the main mistake, which led you to this redundant design was that you did not separate the concepts enough.
I do not know whether a cook has an expected rate for a given meal, that is, a price one can assume in general if one has no additional information. If that is the case, then you can store these default prices in the table where you store the cooks.
Let's store the availability and the specific prices in different tables. If the availability does not have to store the prices, then you can store availability intervals. In the other table, where you store the prices, you need to store only the prices which deviate from the expected price. So, you will have defined availability intervals in a table, specific prices when the price differs from the expected one in the oter and default meal price values in the cook table, so, if there is no special price, the default price will be used.
To answer your question I should know more about the structure of the information.
For example if most cooks are available in a certain period, it could be helpful to organize your availability table with
avail_from_date - avail_to_date, instead of a row for each day.
this would reduce the amount of rows.
The different prices for breakfast, lunch and dinner could be stored better in the cooks table, if the prices are not different each day. Same is for the a availability for breakfast, lunch and dinner if this is not different each day.
But if your information structure makes it necessary to keep a record for every cook every day this would be 365 * 280 = 102,200 records for a year, this is not very much for a sql db in my eyes. If you put the indexes at the right place this will have a good performance.
There are a few questions that would help with the overall answer.
How often does availability change?
How often does price change?
Are there general patterns, e.g. cook X is available for breakfast and lunch, Monday - Wednesday each week?
Is there a normal availability / price over a certain period of time,
but with short-term overrides / differences?
If availability and price change at different speeds, I would suggest you model them separately. That way you only need to show what has changed, rather than duplicating data that is constant.
Beyond that, there's a space / complexity trade-off to make.
At one extreme, you could have a hierarchy of configurations that override each other. So, for cook X there's set A that says they can do breakfast Monday - Wednesday between dates 1 and 2. Then also for cook X there's set B that says they can do lunch on Thursday between dates 3 and 4. Assuming that dates go 1 -> 3 -> 4 -> 2, you can define whether set B overrides set A or adds to it. This is the most concise, but has quite a lot of business logic to work through to interpret it.
At the other extreme, you just say for cook X between date 1 and 2 this thing is true (an availability for a service, a price). You find all things that are true for a given date, possibly bringing in several separate records e.g. a lunch availability for Monday, a lunch price for Monday etc.
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?
I want to create an application which allows Users to budget money they already have into various categories for a given month.
I've already modeled and prototyped handling the data which is tangible; e.g. Bank Accounts, Transactions, Transfers. The problem I am running into is with relating this "real" data (the stuff sitting in your bank, or in your pocket, or on your bank statement) with these fake notions of Budgets (or, as I like to consider them, envelopes).
Here's a quick list of requirements that I've thrown together:
User can manage their Financial Accounts
User can manage their Financial Transactions
User can associate each Transaction with a Financial Account
User can transfer money between Accounts
User can assign available money to a given Budget Category, per-month
User can modify existing Monthly Budget Categories (reduce or increase)
User can view the amount of money remaining for a given Monthly Budget Category
User can view amount of money available to Budget (may be negative)
Money remaining from a Budget Category can carry over to the next month
User can view their Financial Account totals (should not be affected by budget)
User can create Budget Categories as goals that could eventually be closed (e.g. Savings for a new car)
(Probably some other Use-Cases I am forgetting)
The use-cases in bold are the ones I am struggling with.
I toyed with the idea of having a "MonthlyBudget" object, which each transaction could be related to; but this seemed overly-complicated to implement in a database because I'd have to implement a date-range instead of a simple date.
I played with the idea of treating these Monthly Budget Categories as Accounts, and one would simply perform Transfers to them; but then there'd be no way for the User to cross-check their bank statement with the data in the system.
I played with the idea of "fake money" in which Budgets would somehow make use of, thereby separating "real money" and "budget money" -- but couldn't think this through logically.
I'm a bit at a loss on finding a clear and concise way of implementing this, specifically using a relational-database for storage. If anyone has any suggestions or idea, I'd be very appreciative.
The reason why people experience frustration with the budget envelope method is that it ties budget allocations to specific money actually present, whereas money is fungible and can count against the budget, whatever the source. Moreover, when you write a check or swipe your credit card, it may be for a purchase that includes multiple budget items.
A typical commercial budget data model sets up budgets in periods (monthly in your definition) and budget items with amounts. When funds are disbursed, the payment is applied to the appropriate budget item(s), partially or in full. To find out what you have left to spend in your budget, subtract all the applied payments.
If this is for personal finance, people are on a cash basis. However, the same principles apply. So you would have a grocery bill of $220. Maybe $150 of that was for regular food we eat all week, and the other $70 was for a Christmas party. When you come home and enter the grocery bill into the computer, you would want options:
Apply the whole $220 to grocery, because it has to be made up somewhere;
Apply the $150 to grocery and apply the $70 to seasonal entertainment;
Apply the $150 to grocery and put the $70 aside, because I haven't set up a seasonal entertainment budget yet. We don't want to make the user stop the whole process to create more budgets in order to enter the grocery bill, or soon s/he won't be entering the grocery bill faithfully any more because it is just too much work.
I need to add per-province/state taxes to my project.
I'm debating whether I should add a many-to-many relationship between Provinces and Taxes, or just add a tax1_name, tax1_rate, tax2_name, tax2_rate to each province. I don't think any place has more than 2 taxes?
I will also need to store the tax rate at the time of purchase with each invoice.
So my options are add 2 many-to-many tables, or add 8 fields. Which would you go with, and why?
Or I could just have 1 combined tax. I don't think it would be too bad if it showed on the invoice as "GST + PST". This would solve the issue with stupid Quebec which charges QST on top of GST (tax on tax!).
Or I could just have 1 many-to-many table and store the start and end date of each tax and then when I generate the invoice I could look it up based on date.
What you really need is something like this:
The problem with combining the total tax into a single field is that while you may or may not get away with showing it that way on the receipt to a customer, the various jurisdictions are going to expect you and your accountants to track the tax collected and payable separately. Blended rates therefore won't do because you need the amounts broken out so you can pay the tax man and satisfy their auditors.
In my suggested solution to your problem, note that the TAX_RATE table includes an intersection between the tax and the jursidiction. This is so the rate can change, not only from jurisdiction to jurisdiction, but so that it can change over time.
Note too that the tax rate table includes a calculation_order value. This can be anything you like which can be sorted and compared. I've used integers before. The idea is that you apply the taxes in order starting with the first one. If you have two taxes that are applied to the same base amount, then these taxes have the same calculation order. If you pay tax two on top of tax one, then tax two has a higher calculation order.
Lastly, I've included a table that allows you to keep track of tax exemptions over time. You can handle this different ways and the way I've drawn it may not be the best or easiest. The point is to include a mechanism for saying "product X does (or doesn't) get tax Y (over a given date range)".
First, you must decide what the controlling dimensions for the taxrate are: state/province (does seller's or buyer's location apply ?), and time (year?) of transaction. These fields must become the keyfields for the tax-table lookup.
Also see the discussion here: How can I properly implement commerce data relationships in a sql database?