A slight variation on some other questions I've seen posted where people are trying to calculate a renewal date. I'm trying to create a formula that counts transactions that are up for renewal in a given time period based on a 'TO DATE' I already have on each transaction. Just a little stuck coming up with something that takes a 'distinct transaction' and a 'to date' date column and yields a measure that counts the transactions up for renewal based on that date.
Happy to provide more information if need be.
Related
Good day everybody, we are making a spreadsheets for incoming cash monitoring, and I feel like the method I used to achieve the monthly sum is possibly the worst.
So I was wondering if some of you guys have a shorter solution
=SUM(FILTER('Dashboard'!D2:D;'Dashboard'!E2:E="Incoming";'Dashboard'!C2:C>=DATE(text(today()-text(today();"dd");"yyyy");(text(today()-text(today();"dd");"mm"));(text(today()-text(today();"dd");"dd")));'Dashboard'!C2:C<=DATE(text(today();"yyyy");(text(today();"mm"));(text(today();"dd")))))
So since this looks like a cluster**** of code, i will try to annotate it:
=SUM(FILTER('Dashboard'!D2:D;'Dashboard'!E2:E="Incoming"
Sort by only the incoming cash and not outgoing
;Dashboard'!C2:C>=DATE(text(today()-text(today();"dd");"yyyy");(text(today()-text(today();"dd");"mm"));(text(today()-text(today();"dd");"dd")));'Dashboard'!C2:C<=DATE(text(today();"yyyy");(text(today();"mm"));(text(today();"dd")))
The range is from 1'st day of the month to todays date.
Method: Get todays date, and subtract todays date, to get the first day of the month.
Which isn't even a true monthly sum, rather than up to current day sum.
I'm really sorry but due to company policy I cant link the file itself, but the sheet is rather simple
The columns are:
Date, Sum, "Incoming/Outgoing", "Cash/Credit"
I also have a weekly sum, but I feel like that formula is somewhat decent
=query(filter('Dashboard'!C2:D;'Dashboard'!E2:E="Incoming";weeknum('Dashboard'!C2:C;1)=weeknum(today();1));"Select Sum (Col2) label Sum(Col2)''";-1)
There's no need to format the date to 'yyyy-mm-dd'. You can use EndOfMONTH to get the last day of last month.
=SUM(FILTER('Dashboard'!D2:D;'Dashboard'!E2:E="Incoming";'Dashboard'!C2:C>EOMONTH(TODAY(),-1);'Dashboard'!C2:C<=TODAY())
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've to schedule few resource for booking. Below is my logic
Sample:
I've to schedule Delux(2) and Classic(1) room for a year. So I'm inserting 1095 records(730+365-a row for every day each resource).
Database:
table(SID,SDATE,ROOMID,STATUS)
For the particular day, I'm checking the schedule count which has status as 'available' and allowing to book.
Is the logic correct one? or any other logic which reduce number of record insertion?(Note:resource count per day may vary)
Why can't you use START_DATE and END_DATE instead of the SDATE to store intervals?
For the particular day you can ask the same status for intervals where the day between the interval's START_DATE and END_DATE.
Even better to track only booked intervals all the rest are free. So all rooms are free except defined intervals for already booked ones.
If I understand the problem correctly you have a variable resource pool that you receive somehow. Assuming this is in the form of room X of type T from date A to date B.
I would store this into a table "availability", so at any time you can have a view on overall availability per day. If you couple this with StanislavL answer you would have two tables one for available rooms and one for bookings:
availability(availability_id,room_id,date_from,date_to)
booking(booking_id,room_id,date_from,date_to)
room(room_id,type,name,address,..)
Number of available rooms per day is obtained by subtracting via NOT IN clause the booked rooms from the available ones. Also, when you need to book a room you can check in the availability table if this is actually possible.
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.
First some background: I have the typical Date dimension (similar to the one in the Adventure Works cube) and an Account dimension. In my fact table I have daily transaction amounts for the accounts.
I need to calculate cumulative transaction amounts for different accounts for different periods of time. The catch is that whatever is the first period shown on the resulting report should get its transaction amount as-is from the fact table and all the following periods in the report should have cumulative amounts.
For example, I might have a single account on rows and on columns I could have [Date].[Calendar].[Calendar Year].[&2005]:[Date].[Calendar].[Calendar Year].[&2010]. The transaction amount for 2005 should have the sum of transaction amounts that took place in 2005 for that specific account. For the following year, 2006, the transaction amount should be TransactionAmountsIn2005 + TransactionAmountsIn2006. Same goes for the remaining of the years.
My problem is that I don't really know how to specify this kind of calculated member in the cube because the end-user who is responsible for writing the actual MDX queries that produce the reports could use any range of periods on any hierarchy level of the Date dimension.
Hope this made some sense.
Teeri,
I would avoid letting the end-user actually write MDX queries and just force them to use ranges you defined. To clarify, just give them a start and end date, or a range if you will, to select and then go from there. I've worked with accounting and finance developing cubes (General Ledger, etc) for years and this is usually what they were ultimately looking for.
Good luck!