Possible to disable editing invoiced tasks?

We frequently change client task rates (raising them over time, for example) and have noticed that editing tasks that have already been invoiced causes the task to recalculate based on the current project rate when no task rate was explicitly set. This makes sense except that it creates an accounting discrepancy at the end of the year since the amount billed no longer matches the amount listed on task views in InvoiceNinja.

This feels like a bug to me, but maybe there’s some reason for it that I am not aware of, so I’ve looked through the settings, and I can’t find a way to disable editing of invoiced tasks. Is this possible to disable? Should I report this behavior as a bug?

Hi,

Thanks for the feedback!

@david what do you think?

@hillel,

Feels like we need to lock invoices at some point here?

I wonder if this would also apply to editing (not that you normally would) tasks that have been deleted?

It may not help @LukeGraybill since he may make good use of the task menu beforehand, but I would love a way to add tasks to an invoice without having to create a task first - this also would effectively decouple invoices from actual tasks (I have a TON of deleted tasks that I “start” just to invoice so I can get the invoice into the task mode (and then I delete them afterward) - I didn’t think about them still being coupled in any way to the invoice, was just kind of creating them as a means to an end, so I could bill hourly for things…maybe I should be be doing this another way, like customizing the product fields or something)

However, just my two cents - I kind of think that once an invoice is either “sent” or “marked as sent” the values are expected not to change, so something like recalculations could be locked, but that also gets tricky as far as a global lock because what if you really do need to recalculate something (say, you catch an error) and send an updated version before the client pays it? Or something really common, such as update the due date or the invoice number, etc.

@david @hillel What about this? Maybe an answer could be to work backward - if setting the task rate effectively mitigates the issue, then pull in the task rate from the invoice into the task when it was not explicitly set before (maybe at the time of sending or marking as sent), and don’t update it anymore after that? …This could be a little tricky, because I think that the client task rate auto-populates in a task when nothing is set, but, maybe this behavior could be overridden by whatever was billed at time of sending/marking as sent an invoice (it makes sense in my head, anyway)

@bdiggs

One workaround here is to show the task table by default in the invoice, In Settings > Task Settings >

Enable Show Tasks Table.

This way you don’t have to create a task, to get the invoice screen into the task/service mode.

There’s also an option to lock sent or paid invoices on Settings > Workflow Settings

Just wanted to clarify, my issue is with the tasks themselves, not the invoices created from those tasks. Locking invoices is great, but unless I’m missing something I don’t think that would address the problem where viewing the list of tasks later allows editing those already-invoiced tasks and changes how the tasks (not the invoices) are calculated.

For some increased context, we are a worker-owned cooperative, and so we track task data not only for billing purposes, but also for equity payouts. (e.g., each owner receives equity increases based partly on the task hours contributed regardless of whether those tasks were billed) This means that we frequently look at the list of all tasks and sometimes annotate individual tasks to show that they were accounted for as equity or other reasons. Editing these tasks in December when we go through our financials can sometimes have the unintended side-effect of changing the “value” of a task logged in May if the project rate has changed in the interim.

For now, we’ve decided to try to remember to always manually enter the task rate on each task as we do them, but it would be handy if that weren’t needed to remember. Having the tasks automatically frozen or locked in some way to preserve their calculated data at time of invoicing would help avoid confusion and data complications (although we’d still like to be able to annotate them, so I dunno if fully locking them is ideal either, but we’d figure something out.)

Thank you for the consideration!

It was there the whole time, I’m sorry I missed that @david , thank you.

Wow, I didn’t fully understand. I was thinking that it was the invoice that was getting recalculated based on changing the task rate, but really it is the tasks (if a rate is not manually set). I wonder if the invoices change as well?

EDIT: Can answer my own question…the task rate is properly filled out on the invoice once the task is moved to the invoice so I don’t think it has a way to recalculate there. (not that it matters for the @LukeGraybill , just was curious.

I think I see what you mean…the global task rate in Settings>Default Task Rate, or the overriding Client task rate in Client>“Client Name”>Edit>Task Rate sort of auto-populates in the task as a default by showing that, but it isn’t really “set in stone” unless a number is manually set and saved there, and then when the rate changes in either of those other places it changes the “default rate” listed for that task…maybe there could be an optional slider setting in tasks to actually pull in and populate the current rate at the time of task creation…or, like you mentioned, maybe at the time of creating an invoice from said task

So we would need a global lock_tasks_when_invoiced option

@hillel thoughts?

1 Like

That sounds good to me

1 Like

That sounds like it’d do the trick, if that meant the task would “snapshot” itself at that time (particularly the
rate, and probably durations). Is that what would be implied by locking?

Thanks everyone for the discussion and flexibility!

@LukeGraybill

my understanding of this functionality would be that after the task is invoiced, the task could never be updated again.