I want to have a table that will track all the commissions we are due from our wireless sales. Each plan pays a different Commission, not a problem. We do our reconciliation as sometimes the carriers don't pay (they may miss a line or 2).
The problem occurs when the carriers change how much they pay for the commissions. We want to be able to go back and see that there was 4 lines not paid for in January at commission rate x. but Feb the same types of plans were sold but their commission rates were x-10.
If I change the rate in the commission table for the plan, when i go back to pull the data from the January report I will get incorrect commission rates.
I have a table for sales set up with a date stamp so I was thinking i can cross reference that somehow.
Hope someone followed this.
I am looking for the best way to structure this.
You should "STAMP" the record with the commission rate. You could either stamp the actual rate into every record... or you could keep a commission ID and put that into each record.
Related
I am working with a table containing the purchase history for a shop. There is a purchase id, a date column and a customer id. I am trying (without much success so far) to do two things:
Add a column which for each purchase tells how many purchases the customer made before this (in the last month). I started by joining the table on itself but haven't got much further. I know I'll need to somehow filter the date so it only counts purchases before this date and not more than a month ago. Any suggestions on a simple way to tackle this?
The second thing I would like to see is what the weekly rate of returning customer transactions is. That is, what proportion of the purchases are by someone who purchased recently (in the last month). Ideally I would be able to graph this so from my sql queries I would like to end up with a date, weekly total (the 7 days up to the date) and weekly rate. I have been reading up on rolling windows and to be honest am having a bit of trouble getting my head around it. My SQL level is still quite low unfortunately. Any tips on a relatively simple way to do this would be much appreciated.
Thanks
I would need to see your data structure for the table(s) to better answer your question. But right off the top of my head is seems like you just need a simple SELECT COUNT.
So something like this would return all transactions from a single customer made in the past month:
SELECT COUNT(purchase_id)
FROM purchases
WHERE customer_id='some_customer_id'
AND date >= DATEADD(m, -1, GETDATE());
As for your second question you would probably want to setup a job (jenkins, ect..) that would run a query every month. The results of which you would plot. Checkout https://oss.oetiker.ch/rrdtool/ for graphing
I am designing a database for an app to sell parking spot use. Customer can order n number of uses of parking spot uses or pay a flat rate and use it for monthly/weekly or yearly. They can do mix of those also. Like they can buy 9 parking spot uses and later decide they will pay for the whole month - in which case their charges are kind of pro-rated.
For this, I have a Customer table, an Order Table and then an order type table. However, I am having a slightly hard time with the order-type table.
Can some one please shed light on how to model the rate and get available spot-uses for a customer?
I have a 2 access 2007 tables with the following fields:
Table 1: Loan Release Table
ReleaseDate as Date
Maturity as Date
MemberName as Text
MemberNo as Text
Term (in months) as Number
Mode (M/Q/Semi-Monthly) as Text
LoanType as Text
LoanAmount as Currency
LoanCode as Text
Table 2: Payments Table
ReceiptNo as Text
DatePaid as Date
MemberName as Text
MemberNo as Text
LoanCode as Text
LoanReceivable as Currency
InterestPaid as Currency
I would like to ask on how to use Query to create a temporary table that will display Members that should pay on current date or a specified date base on their Term, Mode of Payment and Loan Type (Regular Loans every 30 days to pay, Special Loans every 45 days to pay) and their remaining balance.
Here's my First Attempted Query: I tried to subtract 30 days from Current Date and it obviously gave me just the transactions last month. I would like it to list all transactions including those for example Member with Regular Loan 12 month term on their 3rd monthly payment, Member with Special Loan that is due today.
I am thinking of creating another table that contains the schedule of payments of every Loan released and then go from there.
Is there another way than this? Like a Query that can be run everyday without the need for a bulky ScheduleOfPayments table?
I'm an office clerk who 'graduated' from Excel and a novice using Access at worst and I'm not afraid of VBA codes if that is necessary.
If you know of a better way of doing this, please do tell me or point me in the right direction. I'm all for learning new things and having read and learned a lot from stackoverflow before, I am sure that with your help, my question is as good as solved.
Thank you guys for reading my inquiry.
You have here two solutions:
You can write a procedure that will, when needed, calculate\generate a matrix containing payment schedule for each loan and compare it to payment done.
You can write a procedure that will, when a loan is created, generate corresponding records in a payment schedule table. further comparison will be done between the ScheduledPayment table and the Payment table.
So basically you have to manage a similar set of data, either as a calculated/on the fly matrix or as a permanent set of data kept in a table.
The second version is by very very far the most effective one. You think of it as bulky but it is exactly the opposite, and indeed what is done every time you get a loan from a bank, where your banker will let you sign the reimbursement schedule.
The table solution will allow you to make use of all querying facilities, while the calculated solution will force you to write specific procedures each time you'll want to do some data mining. Just think about a question like "What are the expected reimbursements for the month of April 2014?". Answering this question with the ScheduledPayment table will be as easy as getting a cafe out of your nespresso machine. The same answer without the ScheduledPayment table will be like having to do the whole coffee production process before getting your cup ready.
I have a table that holds data for a person who is on a project. The table has a Start date field a nullable End date field. So, a person is on a project from Start to End.
At the moment, they are always billable to the project. But I now have a new requirement that, for a period, they can be non-billable, yet, still working on the project. So, they have been assigned to the project, and are working, but for some reason, the client isn't billed for part of the period they are assigned, or maybe billed at a lower rate.
My idea is to have an exclusion type table, linked to the person assignment table which would have a start date, and end date, and a Rate column, which could be set to zero for no-charge, or else, works as an override value for a period.
Does this seem like valid design? As the person is billed 95% of the time, and probably will never had any exclusion, it makes more sense to me to have an exclusion table.
If anyone has an idea of how to do this better, it would be great.
At the moment, I also have a 'calendar' table, which I join to based on the start/end date of the person's schedule to get the daily rate. So, I could then join to the exclusion date as well, to see if there is an override of the rate?
Issues I might find with my design, are a lot of the joins are based on:
ON DateValue BETWEEN Start AND End
And I am not sure they're the most efficient joins.
If the exception could be one or more period of times (one-to-many) for one project then your design using an exclusion table is the best design.
Example:
June 1, 2013 to June 30, 2013
Exclusion:
June 9, 2013 - 0 Rate
June 25 to 27 - 30% of Original Rate
However, if the exclusion is possible and can only be a maximum of ONE single period (or one-to-one type of relationship) then you might instead put it on the same fields as other fields on project table.
Example:
June 1, 2013 to June 30, 2013
Exclusion:
June 9, 2013 - 0 Rate
I would use this "exclusion" table as single storage for person-project occupation data. In case when person is assigned to project one time without changes in rate, you will have one record in this table. In other cases you will have a history of rate changes in this table.
It looks like your are allowing discount on standard rate to the customer for specific period. for such case, you can set the rate to be negative eg.-$100/hours for the duration to set resource rate for free in your discount/exclusion table. you can find the final rate for that resource for particular period by adding your discount amount and standard amount to get net amount. In your design, you have already mentioned the relation will be made between exclusion and person assignment table. your design will allow to show what discount has been given to the customer. This approach is ok when your are adjusting the billing for exception cases.
In case, your are trying to do correction in project billing, IMO, you should have separate entries in person assignment table for each rate with the duration.
While generating Invoice to the customer, you can show adjusted discounted rate or new revised billing based on the correction.
I have searched and searched but to no avail... has anybody created a payroll module for a U.S. based company? It seems that most of what I've seen is that companies are using payroll companies to process their payroll, but I haven't found anybody using OpenERP 7 for hourly employees with the U.S. tax system (it's not a flat tax rate).
It seems like what I may have to do, is create tax table in PostgresQL for federal, state, and local taxes, then reference those tables in the deduction calculation. I read one article on using the vendors/ or suppliers module and implementing a tax structure from that, but then again, those are still flat rates. I have to believe someone else has done this for the U.S. payroll system, and probably done it better than I could as I am fairly new to OpenERP.
I am in the process of doing something similar for LedgerSMB. The thing is that doing this on an open source model is extremely painful business-model-wise. I am working on solutions to that part but that's outside the scope of your question.
In general many US taxes are set up in marginal rates with certain minimums and maximums. For example income tax withholding is a set of marginal rates within tax brackets. Same with FICA and FUMA, but FICA taxes are capped at a certain level, so a simple tax table with rates, minimums, maximums, etc. and then a way of handling deductions to determine the correct line may be sufficient.
But users of most open source ERP's use third party services for payroll.
I have worked in an ERP. How we did is just calculate the FIT in yearly for all the employee and subtract the withholding amount with multiples.
FIT => Taxable Wages Yearly - (No.of withholding(Exemption))
Do the process as per the revision based on single or married only for annually. No need to update all the tables.
Then,
Divided it based on the frequency from the employee table information
EX:
for monthly : FIT/12
for daily : FIT/365
For SIT you have to use based on the document in the state usine case function.