Forum Discussion
BrianSeymour
Qrew Assistant Captain
Don's schema seems pretty solid and scalable, but may be normalized a bit more than your needs, particularly regarding PTO Type and tracking history of Status changes? The many to many with a reverse relationship can be fairly challenging to wrap your head around.
I suggest keeping it simple, at least initially, and create a Summary field on parent table (Employees) that sums the child (PTO Requests) time. Then, subtract that value from the where you are storing the 20 day value on the Employees table. Watch out for your formula data types (duration vs. number), QB will bark at you and guide you to what it is expecting.
------------------------------
Brian
------------------------------
I suggest keeping it simple, at least initially, and create a Summary field on parent table (Employees) that sums the child (PTO Requests) time. Then, subtract that value from the where you are storing the 20 day value on the Employees table. Watch out for your formula data types (duration vs. number), QB will bark at you and guide you to what it is expecting.
------------------------------
Brian
------------------------------
DonLarson
2 years agoQrew Elite
Brian is right. Throw out the PTO Type, it was not part of the question.
The Status Change is only important if the Request is really a Request that has a workflow in QB where is can be approved or disapproved. If they have some other approval process and QB just records time off, then throw out those tables as well.
------------------------------
Don Larson
------------------------------
The Status Change is only important if the Request is really a Request that has a workflow in QB where is can be approved or disapproved. If they have some other approval process and QB just records time off, then throw out those tables as well.
------------------------------
Don Larson
------------------------------