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?
Related
Below is the current design of school fees and payment I have created.
I'm just a little stuck right now because I can't model the payment/transaction table. Also, I would like to know your thoughts and comments with my current design. This is the first time I'll create a database for fees and payments.
Main tables of my concern are schoolyearfee_lt , student_fee_lt and Payment
I'm thinking of using the Payment table to store the sum of all fees on which will be divided to whatever payment term was chosen (monthly,quarterly,annual,cash).
Let's say for instance, Monthly was chosen as payment plan.
amountToPayPerMonth = (sumOfAllAssignedFees / paymentterm) - downpayment
Where 11 inserts of the amountToPayPerMonth to payment table will be executed and 1 downpayment. 11+1 = 12 months
How do I mark it as paid? Should I use another Transaction table?
Is this a good design? Any thoughts or advice?
Thank you.
some (personal) thoughts about your design and question.
1- schoolyearfee_lt. It seems 1-to-n with fee_mt. If i well understand the same fee can be applied for several shoolyears, category etc, but the amount for a fee does not change. It means, for example, that every year in which fee amounts change i should create -at least- a new fee and some shoolyearfee. I believe something can be reviewed here. I could from example move some of its fields (schoolyear?) to the fee_mt table, and/or i could move the amount from fee_mt to schoolyearfee_lt. There are also some more possibilities, i.e. making a table fee_years_lt, where storing year and amount (and maybe other factors which change the fees) and so on. Maybe you could make some of these changes, maybe none, depends on your design and requirements. The questions may be: is the amount changing by year (i believe yes), gradelevel, feetype, feecategory or not ? You want a master fee that you want applicable forever or your fees are recreated each year from scratch ?
2- Payment. I would call it exactly with its meaning: payment_plan. I would add a field paid, a field payment_date and a field schoolyear (in current design).
3- Student_fee_lt and schoolyear. In the current design you better add the year too. Depending on the mode the fee_mt is managed (see above) i would put it in the PK too. Moving the year to the fee_mt, you don't need. Is student_fee_lt really needed (it seems the result of a query + the field date_effective) ?
4- Payment Formula. The downpayment and consequently the formula is a little nclear to me. Is it a kind of discount for every payment you do or is it a fixed amount ? In the latter you should review your formula. Why 11 payments ?
5- Choosen Payment Plan storage. I would have a table where storing the chosen payment plan by the student (and some other data), this should not be student_fee_lt, because it stores the single fees assigned for each student.
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 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.
Let's consider I have the following not normalized table
1) warehouse
id
item_id
residual
purchase cost
sale cost
Currency
I tried to normalize this and I obtained this tables:
1) warehouse table
id
product_id
residual
cost_id
2) costs table
id
purchase cost
sale cost
Currency
Does that comply with database normal forms?
Thanks much in advance!!!
This should be a comment, but it's too verbose.
There's not enough information to provide an answer - we have to infer structure from context - and the context is confusing. Your initial record looks like a description of a product to be bought and sold - but you've named it as warehouse - which is a place for storing products. I've no idea what you mean by residual. Do you have multiple purchase costs for a specific product? If so how are they differentiated. Similar for sale cost. If ther are multiple costs involved why is the selling price tied to the purchase cost?
I don't know what "residual" means in this context. But just ignoring that ...
I doubt that there's anything to be gained by breaking cost out into a separate table. Let's say we have two products, "toaster model 14" and "men's shirt style X7". Both have a cost of $12. So you create a cost record for $12, and point both records to this. Then you realize that you made a mistake and the toaster really cost $13. So you update the cost record. But that will then update the cost for the shirt also, which is almost surely wrong. Having a separate cost table would mean that you would always create a new cost record every time you created a stock record. Nothing is gained.
The fields you have listed look to me like they all belong in one table. You'd also need an item table that would have data like the description, maybe manufacturer, product specs, etc.
Your warehouse table appears to really be a stocked item table, as it lists items and not warehouses, but whatever. I suspect it also needs some sort of serial number, or how will you link a given physical item in the warehouse to the corresponding record?
If by "sale cost" you mean the price that you will charge to the customer when you sell it, I doubt this belongs in the warehouse table. When a customer buys a product, do you tell him, "I can sell you the one that's in bin 40 in the warehouse for $20 or the one that's in bin 42 for $22. Which do you want?" Probably not. I suspect you charge the same price regardless of which particular unit the customer gets. The fact that the price you have to pay to your supplier went up between when you bought the first one and when you bought the second one normally does not mean that you will charge your customer a different price. You may raise the price, but you will have one price regardless of which unit is sold. Therefore, the selling price goes in the item table, not the warehouse table. If "sale cost" is something else, maybe this whole paragraph is irrelevant.
I am in a situation similar to the one below:
Think for instance we need to store customer sales in a fact table (under a data warehouse built with dimensional modelling). I have sales, discounts related to the sale, sales returns and cancellations to be stored.
Do you think it would be advisable to store sales for a day to a customer in a particular product (when the day is the grain) as a positive value while the returns and discounts are stored as minuses?
Also if a discount is enforced to a customer at a level other than the product (for instance brand), do you think it is alright to persist it with a key particularly assigned to the brand (product is the grain) while the product column being given an N/A, for the particular record?
Thanks in advance.
If your sales are considered a good thing (I'm assuming they are) then recording sales as positive numbers makes perfect sense. Any transaction that reduces sales (i.e. discounts and returns) should therefore be recorded as negative numbers. This will make reporting your sales very natural.
If you have diffent dimensions that might account for a record, you should populate the dimensions that make sense. So yes, attribute a discount to a brand rather than a product if that is what happened in your business transaction. This way your reporting will be able to look at all discounts, at discounts for particular products and discounts for entire brands. If your fact table shows the most direct "cause" of the discount (product or brand) then your reports will be more useful than if you link the fact to brand through a relationship to product.