Quarterly Reports on Dates - sql

I have a challenge ahead of me. I have looked at this for a couple of days now in a trial and error sense and am getting tired of not getting it… My SQL knowledge is very very basic.
Each quarter I have to report on the questions below (of course the date period changes):
The number of doctors with whom the designated body has a prescribed connection at 31st December.
The number of doctors due to hold an appraisal meeting in the reporting period (from 1st October to 31st December 2017).
The number of those doctors above who held an appraisal meeting in the reporting period.
The number of those doctors above who did not hold an appraisal meeting in the reporting period.
I have three lists:
A list of staff responsible to the designated body. In a linked table- ‘GMC_Main’ Field- GMC Ref No
A list of all appraisals that have ever taken place (historical and ones performed by staff not responsible to us). In a query called-
‘Latest Appraisal’ Fields- ProfNum, MaxOfAppDate
List of emails in a linked table- ‘MARS_Core’ Fields- ProfNum, EmpSurname, EmpFirstName, EmpEmail
Things to consider
ProfNum and GMC Ref No are the Unique identifiers for each member of
staff.
GMC_Main is the list of all staff that need to be considered in the
report. So should have a row regardless of the results from the other
tables.
All appraisals are valid for 365 days. So The date 1 year in the future from that in MaxofAppDate will be needed to calculate expiry in the period.
Due to software limitations I only have available Access 2016.
I need to count all that should have taken place, including ones that
are still overdue from previous quarters.
Count all the ones that actually took place in the period.
Be able to contact all the ones that did not achieve and appraisal.
At year end (31 March) do this for the entire year and not just the
quarter…
Fuff!
Each time I approach this problem I am missing a group of people or feel I am doing it in a very wrong-handed way.
If anyone could help, then that would be amazing. This is a little beyond me.

Related

DAX: Classifying employees based on outcome of measure

I'm trying to classify employees by how many times they've called in sick in a given time period. I already have a measure which calculates the number of times an employee calls in sick in a given context. Below is a rough sketch of what I want the result to look like:
The data set I have has the date of calling in sick as well as the date the employee started working again (given that they have recovered already) for each date that the given employee is employed (so it also shows days that an employee is not sick) example below.
So for the above example I want employee 1 to be classified as "2" if I look at this entire year, however if I drill down to the months I want employee 1 to be classified as "1" in both january and february.
Does anyone know if and how this can be done?
I'm using Visual Studio 2017 SSAS Tabular.
Please tell me if something is not clear :).
I figured out how to do it with the link posted below:
https://www.daxpatterns.com/dynamic-segmentation/

How to Extend the End Date in a SQL Calendar Table?

I have a report that, according to users, started miscalculating dates in one field in November 2015. After some digging around, I found that one of the tables the field referenced seemed to have an end date on 2015-10-31.
The "D" field seems to represent the day of the week, with Sunday being day 1 and Saturday being 7.
Is there a way to extend the calendar so that it ends further into the future, for example 2049-12-31?
Our calendar table, for a variety of reasons, goes the the end of the current year. We have written a query that adds a new year to this table. This query takes care of most of the fields in that table. It does not touch the holiday field. That is updated manually through a web page.
We send ourselves reminders. Starting in March, we send monthly reminders that we should think about adding another year. After ensuring that the database segment has space, and that none of the definitions, such as fiscal periods, have changed, we run the query that adds a year.
Later in the year we start mailing ourselves reminders about the holidays. Then we check to see if HR has declared them, and if so, update the records accordingly.
This meets our business requirements. Yours will be different of course.

How to Query for Due Dates in Access 2007

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.

Table design for payments

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.

Field values that vary over time and querying them

Imagine you have a website which lists available hotel rooms and their prices.
The hotel owners set a price per day for each room - it only needs to be as complicated as "Jan 1st costs $100" not "Jan 1st 1999 costs $50, Jan 1st 2000 costs $100".
The granularity is limited to day-rate.
What would be the most efficient (in terms of load when querying for rooms) way to represent this in a database?
For each room, have a separate table holding a date field and a price field? ie 365 entries per room.
I see ways to solve this, but the problem becomes slightly more complicated when for example a user wishes to do a query such as "7 days in august with a budget of $500". This is a feature I would dearly like to implement.
The UI will allow owners to set room prices as blocks of time rather than individual day rates - eg if a room price was $50 for jan-jun and $100 for jul-dec then that is two price blocks. Obviously if needs be that could be translated into 365 date type fields, but a solution using two daterange type fields instead would be preferable.
Any pointers as to where I could learn techniques for this would be greatly appreciated. I have searched google and found information on Calendar Tables, but any additional tips or info would be appreciated.
Historically I have used MySQL, but anything would be considered.
In the terminology of Ralph Kimball, this is called a slowly changing dimension.
I would suggest that you look at one of this books. The latest edition of "The Data Warehouse Toolkit" should cover this topic quite well.