A lot depends on how you've structured your tables and related them. A summary report can certainly be constructed that groups records by common value (such as the week and/or shot rating) so that subtotals can be computed and displayed. A relationship can be used to access an aggregrate value of selected records from the previous week as well.
But all this depends on the structure of your tables.
I do realize that this was a pretty broad request, and surely the database/table design would make all the difference. I know I could get a summary based on week ending expenses if every cost was being coded on a weekly basis. Unfortunately this summary report is completely based on projections, and the totals you see above are derived from approx. 15 different fields each. I didn't associate each field with a weekend date because they are not actuals and they fluxuate as the project wows and flutters.
Right now the reports only gives me a current snapshot, and I was hoping to figure out a way to lock those numbers in, and compare them to another given time. May be something I have to do with Excel.
Unfortunately this summary report is completely based on projections, and the totals you see above are derived from approx. 15 different fields each.
I don't see why that creates a problem for the summary report.
What you want should be possible. I just can't give you any specific recommendations without a better idea as to how you've structured your database.
You'd probably need more information than I can provide here... but I can tell you that all of my Shot Count # fields and Shot Cost $ fields, as well as my Rating field, are in the same table (thus no relationship). I'm not sure if this is a major no-no.
I have updated the image above to give you a snapshot of the financial portion of my layout.
I have one record for every shot (I have 500+ shots), and these two fields are referenced in My Summary Report when sorted by Rating.
Basically, I enter my information into the fields under the Raw Shot Info column,
Count # = Original # + Added # + C/O #
Cost $ = Original $ + Added $ + C/O $
Let me know if this makes sense, and if you have any better design recommendations for my next project.
That is extremely minimal information to go on. It looks like you have either 10 fields or one field with 10 repetitions for recording cost data (Don't see how you use them just from your screen shot.)
Generally speaking, that's an approach that greatly complicates the function of your database when it comes time to set up reports. A related table of cost records displayed in a portal would likely simplify things for you and be much more flexible as well.
What tables have you defined?
How are they related?
I realize that it's very minimal, and just didn't want to complicate the issue by showing extra fields and data that weren't applicable.
Currently all of these fields live in one table, probably about the only thing I did right was give each field a different name so there is no repetition, but I think I see what you're saying about using a portal.
Creating separate tables for Shot Count and Shot Cost and a new record in those tables when a count/cost changes. By adding a date to that change would allow me to narrow down the data on the report based on a given range of dates, and allow me to calculate a variance based on those findings.
I could then create several portals that only show the most current information on the page I am now using to enter information (instead of overwriting my original data).
If I am on the right track, wish me luck, and if I am way off... any logical suggestions you might have for a novice like me would be greatly appreciated.
In addition to portals, you can simply use Finds to pull up subsets of the total records. The results can be displayed in a list view, table view or the summary report I've mentioned previously.