I am trying to create a timesheet entry tool for a consulting business and need to create an input form for the capture of daily entries by consultants.  Attached is the data structure, but in summary the following tables should be the sources for combo boxes: 10_Customers;  12_Projects; 13_Workorders; 21_Consultants; 31_TimeSheetDays

The form should allow the user to select the consultant name from 21_Consultants then the Customer from 10_Customers, the Project from 12_Projects (only those linked to the selected Customer), the work-order from 13_Workorders (only those linked to the selected Project), and finally the week ending date.  They would then have a grid to select the day of the week from 31_TimeSheetDays and then enter start/finish times along with comments on the work completed - there could be multiple entries per day in the grid.

On completion they would select an update button that would save the selected values from the input tables along with the time/day details to a a table called 32_TimesheetDetail. Other linked tables with fee structures could then be used to generate invoices.
  • 180 KB
  • Table structures and mock up of the desired form

    asked 10/30/2011 09:20

    RoreConsulting's gravatar image

    RoreConsulting ♦♦

    3 Answers:
    I can't find a question in your post.


    peter57r's gravatar image


    Access is certainly up to that task. There are several templates you could use to get started - check on the MS Office site:

    In fact, there is a Time Tracking utility:|

    That would be a good one to review to get some ideas. Once you get the basics in place, you can post back here with specific issues you need help with.

    I would encourage you to review your table strucutres a bit more carefully. For example, your 1000_WorkOrder Detail table contains details much more relevant to the Project (like Project.StartDate and Project.EndDate). When determining what data to include in a table, remember that a specific table should deal with a specific Object/Entity, and should only contain attributes that are relevant to that specific object/entity. As an example, if you had a database storing information about Cars and their Drivers, it wouldn't make any sense to store the color of the Car in the Drivers table, and it would also not make much sense to store the Name of the Driver in the Cars table.

    Same concepts apply with your 4010_Timesheet Elements table. As an example there, you're storing the ProjectName value in that table. You should instead "relate" the Projects table to the TimeSheet table by storing the PrimaryKey value of the Project in the Timesheet table. You then don't need to store the ProjectName, StartDate, EndDate, etc in the Timesheet table, since you can then easily get that data through a Join or Subquery.


    answered 2011-10-31 at 07:21:47

    LSMConsulting's gravatar image


    I'll go through the examples and then post some more specific questions regarding how to create the form(s) to accomplish this task - that remains the key challenge.

    LSMC, thank you for your guidance.  I will review the table structures again, although perhaps I created some confusion by including screenshots of the queries that pull the data together (eg the examples you noted are queries rather than tables) - I was hoping these would help create visibility of the intended data relationships

    answered 2011-10-31 at 07:29:39

    RoreConsulting's gravatar image


    Your answer
    [hide preview]

    Follow this question

    By Email:

    Once you sign in you will be able to subscribe for any updates here

    By RSS:


    Answers and Comments



    Asked: 10/30/2011 09:20

    Seen: 364 times

    Last updated: 12/15/2011 06:11