James Bradshaw's dashboard

I think that's where we differ here as I think in terms of 'the Project is based on my contract agreed with my client, which states X days terms'. So when I create a project it will be from a contract, if there is a change to the payment terms then an amended contract is signed, so changing the terms for the relating project is fine. As is don't create projects that often it doesn't seem needed to me hold a value at the contact level. It also suggests to me business practice that is less than ideal, I assumed that outside of this invoices would be issued by standard payment terms.

I do see the point your making though as there are those that would have different payment terms agreed for a client ongoing (and I assume without a contract!) that would need to be catered for. Whether its best practice or strictly correct it another discussion ;) – James Bradshaw, on February 11, 2010 18:50

That’s very definitive and offers the most flexibility to cover all scenarios but I could see the chain of inheritance having the potential to cause some confusion. Having lots of repeat default values scattered in the system would do this. These are only auto fill values for high frequency repetitive tasks and I don’t see projects falling into this category.

I would suggest creating a new project would have its default contract terms values copied from the previous project for that particular contact, maybe have a "Use previous contract details". If it’s the first for this contact leave it empty or the use the “My Account” level.

I can see having default values at the ”My Account” level would serve those who maybe have may clients that do not repeat projects but I’m not sure this would be the case or really used that much.