> > Topic

Some thoughts on accounting

Jan 23, 2009 / pixtur
Apr 22, 2012 / pixtur
 

Attached files

No files uploaded
 

Some thoughts on accountingπ

  • Sooner or later we want to hide money things from employees.
  • Turning booked efforts into invoice items should be done by project managers only. But this process must not be too complecated for feelancers.
  • We could add a new user-right called "accounting" or something alike. This would include creating and editing invoices, seeing and hourly rates and stuff like this.
  • to keep things simple, we should keep the computation at the javascript level an always provide a valid state of data in the effort items. (we could solve computational tasks with accessor- functions but I highly doubt we'll get these under control).
So there would be several phases:
  1. Assign rate and unit to person (e.g. 40€/hour or 250$/day)
  2. Possibly overwriting the rate for a project
  3. Person books efforts and expenses without needing to know something about money. For each effort we calculate the amount.
  4. P.M. reviews the booked efforts
  5. P.M. books the efforts into an invoice.

Potentential pitfallsπ

changing type in formπ

  • team member changes effort type from work-hours into expense. This would reveal the amount stored in the effort object.
Solution: the type should only be changable when creating a new effort. Changing the type later is useless in most cases anyway, except maybe for hiding too much personal information about your work-hours and changing from "Workhours (start-end times)" to "Workhours (duration)". But this should be a job of the pm, anyways.

Changing rates laterπ

If all effort-objects are valid in their own, they are not allowed to have dependencies on other objects like "PersonProject". So when changing the rate of a team member who has booked lots of efforts, these items won't be updated. This results in two tasks:
  1. Make the hourly rate and visible when assembling an invoice.
  2. Make it easy to change the rate of several efforts later on. This is especially difficult, because we can't be sure if the amount should be updated automatically or if it has initially been overwritten.\n this somehow sounds like, if we solve some magic with javascript when editing one effort, we have to implement the same trick when editting multiple items.

Implementation detailsπ

To keep up compatibility and code readability we might completely reimplement the whole effort class and replace it with something like "expense". Although this would be a lot of work, it would have several pros:
  1. The code stays readable. Nobody understood effort anyway and there is no way, that we code refactor effort into expense because all the dependencies (e.g. Edit history).
  2. We could implement a working beta to get the UI right. Later we could add some kind of upgrade function to convert effort into expense.

Expenseπ

Common attributes:
  • expense_type - workhours, workduration, expenditure, product, discount
  • amount
  • amount_billable
  • task
  • person
  • invoice
  • name
  • description
  • status
  • identifier (?) - reciet number, booking number, item-number, etc.
Additional attributes:
  • rate
  • value (?) - hours, item-count,
  • start_time
  • end_time
I really wonder about compatibilty though. Testing all the. Upgrade functionality might take a huge amount if time.

2 Comments

julio.coelho:

5 years ago

This feature is a must have for me, do you need help to develop it and how can I help?

Regards

guest:

4 years ago - visible as suggested -

We could implement a working beta to get the UI right. Later we could add some kind of upgrade function to convert effort into expense.