Forum Discussion
JustinTorrence
6 years agoQrew Cadet
It sounds like you're headed in the right direction.
1. Why can't you capture the "parts and material" fields in the "snapshot table".
2. Do you need this information purely for logging purposes, or do you plan on doing some type of calculation with the data, like # of changes in a given time frame etc.?
1. Why can't you capture the "parts and material" fields in the "snapshot table".
2. Do you need this information purely for logging purposes, or do you plan on doing some type of calculation with the data, like # of changes in a given time frame etc.?
ChrisSipes
6 years agoQrew Cadet
Justin,
The project has one main table, where parts, equipment, and materials are all child tables. The project may use zero to dozens of pieces of equipment to install one to hundreds of different parts, requiring some types and amounts of material. It is logical to have a main Project table and children for all of the many-to-one relationships.
As you expect with any complex project, there will be changes along the way. If we add or remove parts, we will bill for those in the end. While I don't want to keep track of every change, when the project changes phase, I need a snapshot of what the scope was at that time. Knowing what we first quoted, what the scope was at kickoff, and how it changed to billing are all vital. I will look for number of things that change, which items change, along with the dollars that change, and the time frame between phases, among other things. This will help improve our company processes.
This is not a project management system - it has nothing to do with people planning, but it is the database of the parts that we sell to feed into accounting, so knowing these things is important.
The project has one main table, where parts, equipment, and materials are all child tables. The project may use zero to dozens of pieces of equipment to install one to hundreds of different parts, requiring some types and amounts of material. It is logical to have a main Project table and children for all of the many-to-one relationships.
As you expect with any complex project, there will be changes along the way. If we add or remove parts, we will bill for those in the end. While I don't want to keep track of every change, when the project changes phase, I need a snapshot of what the scope was at that time. Knowing what we first quoted, what the scope was at kickoff, and how it changed to billing are all vital. I will look for number of things that change, which items change, along with the dollars that change, and the time frame between phases, among other things. This will help improve our company processes.
This is not a project management system - it has nothing to do with people planning, but it is the database of the parts that we sell to feed into accounting, so knowing these things is important.