New dwyler invoicing app / process

[rub1e]

The current invoicing app is a yuge time-saver. Yuge.

But there are some bugs 🐞 associated both with the dwyler-facing form, and with the add-on used to generate pdf invoices (autocrat 👮) :

• 468 - emails come from generic no-reply address

• 450 - invoice numbers aren't universally unique

• 423 - multiple emails sometimes sent when invoice submitted

• https://github.com/dwyl/process-handbook/issues/97 - form "leaks" personal data

For my money, these are minor to medium niggles and don't justify a redesign or new app

But if anyone disagrees or if we identify more bugs / issues, let's bump the priority up and start thinking about version 2

[nelsonic]

Hi @rub1e thank you for opening this issue to capture the "issues" with invoicing. Invoicing was always intended to be a "feature" of our "Time Tracking" app; not a separate "App".

So the "workflow" should be:

• Product Owner creates "Stories" based on feature request from People Using Product ("Users")

• Stories are broken down into "Tasks" (during Sprint Planning) by Dev Team (Tasks should never take longer than a Day and ideally should be one "pomodoro")

• Each Task gets Estimated before work starts

  • The System should not allow "assignment" of a task before it has been estimated.
  • When Estimating the Time required to Build the Feature, Documentation should always be factored into the estimate; Our Workflow should Systematically Eliminate Tacit Knowledge
  • Features that are Not Documented are Not "Done".

• Dev assigns task to themself which tracks their time against "Task" while they are working.

• Dev Logs their progress in the Task while they are working so learning is captured for posterity on everything that we do.

  Not to "pick on" anyone in particular, but we have way too many instances of people invoicing us before their work is complete i.e. fully documented & tested ... 😢 this would never happen if the "workflow" was structured correctly. i.e. no separate "Invoicing App".

• At the end of each day, Dev reviews how much time they spent on a Task vs. original Time Estimate - writes a note in the Task indicating why something took longer than expected/predicted.

  • Different Dev must confirm "unpredicted obstacles/complexity" note has been logged on Task before a time-overrun can be "confirmed", otherwise PO has zero visibility over why Tasks take longer than expected and the whole "workflow" breaks down into chaos! 🔥

• Once Task is dev-complete it is reviewed by QA then, if PR approved, deployed to "Staging"

• PO tests a Feature (Story) on the Staging Environment and approves if acceptance criteria are met.

• When the Task is deemed "done" it is deployed automatically to Production.

• The Task is now "Awaiting Payment" and no further "action" is required from the Dev.

• The System automatically:

  • Calculates how much Time Spent on Task(s) for the Sprint.
  • Prepares the "invoice" and sends a PDF to the Dev for their own records (with links to Tasks).
  • Adds the invoice to the Payment Run.

• Financial Controller Approves Payment Run once per week with a single click (because all checks on "Time Spent" were done at a prior stage in the "workflow". Since Time logging has rules we cannot "over-log" so there should never be "invoice errors")

That's how it should work. 😉 The Dev should never have to manually enter data for an Invoice.

[iteles]

Agreed, I think we're all very aware of this. But this won't be done until 'Time' is prioritised.

Thanks for capturing the wider issue (root cause) @nelsonic 👍