On 10/18/2010 05:42 PM, Phillip Heller wrote:
This is a very cool development. Do you plan to publish once you're
finished?
Sure, why not!
git://git.subdir.eu/paul/trytond_contract
(check: http://hg-git.github.com/ if you want to clone git repos using hg)
A "Contracts" tab within the Party view. This tab would list all of
the party's contracts, with a column "Remaining Contract Value",
which would be computed based on the billing amount and remaining
contract length.
Adding a contracts tab on the party is easy, and indeed a good idea.
For me I don't see the value of such an added remaining value column.
Once a client is invoiced for a new period, the invoice stands. But then
I'm talking about short-term contracts myself: currently I'm invoicing
every 3 month, or once a year for very small fees like domain
registrations. If clients want to terminate, they need to do so at least
a week before I send out a new batch. I (currently) don't do or need
half-way termination + credit-notes.
That may change once I get tryton fully integrated and it becomes easier
to do. However, once a client has paid their hosting fee for a new year,
I don't feel much inclination for supporting early termination if they
decide to switch providers. They simply forfeit the remaining contract.
Also, it would be useful to represent an Early Termination Fee, which
is perhaps sometimes as simple as a flat rate, or a percentage of the
remaining contract value, or the greater of the two, or some
combination.
Maybe that will be added in the future, but like I said: I don't see any
business value in supporting this at the moment. Of course, once it
becomes easy and cheap to support it, that may offer a competitive
advantage. It may, maybe!
It might be nice to represent Contracts where the enterprise is the
customer (i.e., like "supplier invoices", but for these contracts),
though this is perhaps beyond the scope of what you're currently
working on.
Indeed. Since I don't do repetitive purchase orders and don't hold
stock, I don't have a clear understanding of the issues involved.
All of these things would be useful to eventually figure into a
"Guidance Report", which would help with projected revenue.
Nice idea. But for now I want to keeps things simple and clean. I've
struggled with the account_invoicing module for openerp by kndati for
quite some time last year through to last spring, and found it way too
complex for my needs. And of course, openerp turned out to be far too
unstable to deal with :-( which made me look at tryton, and now I'm
happy again :-)
Btw, Sharoon's approach in his subscription module would provide a more
generic approach, and I'm eyeing his code for lesson's learned. But this
is my first serious module slated to go into production, so bear with me.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
--
[email protected] mailing list
