Hi, I would love to have manager.io help me with planning ahead while also doing a great job at looking back.
When creating a recurring transaction, being able to create those X days before they happen would be more then enough I think
Then just change the next issue date to X days earlier. Be aware, though, that income is recognized on the date of creation. Manager is an accounting program, not a personal planner.
Agree that would be a useful enhancement as it allows time for my staff to actually do their work prior to the documents being issued. The same applies to recurrent pay slips.
I don´t understand where being able to see planned transaction in advance is an disadvantage for an accounting program. Especially considering you´ve created a forecast tool.
So I am able to set up forecasts. But those forecasts can´t take into account what I already know will happen? I don´t understand where forecasts are fine with an accounting program but being able to see plannable transactions in advance doesn´t @Tut.
Given this statement I am not sure why issuing and invoice would not suffice as in accrual accounting that will forecast what will happen to a purchase or sales but accounts for it at the time of issuing as @Tut explained. The actual payment of an invoice will still need to be recorded when received (sales) or paid (expense).
It is a staff work time issue.
- Invoice or payslip is scheduled to go out on day x.
- Staff need time to review the invoice or payslip to ensure all data is correct.
- The facility to produce the invoice or payslip a few days earlier would significantly help scheduling my staff’s time.
- The time my staff allow to schedule this work should not effect the customer facing documentation sent out (both timing and content).
Is that not what a Sales Order is for?
Not sure why an accounting application such as Manager would need to built in a work scheduler. There are many applications that will be much better suited for this or have add-ons for it.
That is what the recurrent transaction do. They create a transactions at a future dates.
The suggestion is the date Manager prompts to create the transaction is before the date written on the transaction.
An accounting system records historical information not future forecasts
Issuing an sales invoice in advance of the date of delivery of the goods or services would not be legal in most jurisdictions
If your staff do their work in zero time then clearly you would not need this facility.
I find it efficient if my staff can do their work at a time which is convenient for them. It minimises my staff costs.
Btw, I’m not suggesting sending out post dated invoices, I’m suggesting my staff generate the invoices at a convenient time before they need to be sent out.
I understand - but this still means that if they prepare the invoices in advance, that your accounting records will contain future dated transactions which is a bit weird
@Patch, your reason for supporting this request is to allow staff time to review sales invoices before they are issued. Why cannot the exact same amount of time be expended reviewing the recurring sales invoice form, on the same schedule, before the scheduled issue date? In fact, this seems preferable, since the recurring invoice form contains information not visible on the completed form.
I wholeheartedly endorse @Joe91’s comment that accounting systems record what has happened, not what will happen. And I support @eko’s comments about Manager not being a work planning/scheduling tool. (I made that point in post #2 above.)
As for @Thomas_Hacker’s statement that “forecasts [by which I assume he means budgets] can’t take into account what I already know will happen,” that simply is erroneous. There is no reason a budgeted profit and loss statement cannot include forecasted sales. In fact, a budget normally should and would. And that is especially simple when sales are so foreseeable you can create a recurring sales invoice for them. You don’t need days to ponder a transaction you already knew was going to happen.
Because then Manager’s recurring transaction will not have triggered so it would have to be generated manually ie not using the recurring transaction facility at all.
Another example.
A business with an ongoing service. Sends out invoices due on a particular day each month. The invoice needs to be sent a couple of weeks before it’s due.
The point being
- the data work starts on a document in practice is often different from
- the date intended to be shown on the document which is sent out.
Yes they are both dates and typically not that far apart but in many businesses they are not the same.
is value in being able to separate the date on a document sent out
The recurring invoices may not have been triggered, but since you know the date you want them to go out, you should know the date you want to start reviewing them. So you can start reviewing them under the recurring invoices list on that date. If any changes need to be made, the forms can be edited before the invoices come due. When the issue date arrives, you can confidently send out the invoices. In other words, don’t review them after they’ve been created, review them before they’ve been created.
For a service with regular scheduled payment dates (such as payslips, membership fees, ongoing service while scheduled fees are paid in advance)
For a recurring document this is the date Manager triggers generation of the recurring document
This is fixed by contractural arrangement with the customer or employee it is important the schedule is adhered to so a fixed computer generated date is appropriate.
Recurring transactions in Manager are a good way to achieve compliance with these type of contractual arrangements. Consistent components can be entered in the recurring document and used as a template to which period specific information is added after each recurring document is generated by Manager.
The problem with the current implementation is Manager forces the above two dates to be the same. Which is a problem when a business needs to start adding information to a payslip or invoice prior to the period end for that document ie the required Manager document generation data is before the date to be shown on the document.
This limitation could be addressed by adding an option below the recurring date…
Allow generation [ 0 ] days before this date.
You have got to be joking.
The design of recurring documents is the constant information is entered in the recurring entry. Period specific variable information is then added to individual payslip or invoice.
If I wanted to edit the last then that’s the clone function.
No, I am not joking. But I guess you and I have different outlooks on when recurring sales invoices are appropriate. In the situation you described, I would not use a recurring sales invoice. I would just start with a clone.
I use recurrent transactions for
-
A full current list of transactions currently required to be generated
-
Accurately maintained contracted date of each outgoing document
-
Accurately maintained constant information specific to each recurrent transaction. By which I mean errors on an individual transaction are not carried forward.
No thanks, that is a step backwards.
I’ll stick to my current work around, temporary changing the system date on the computer running Manager. Clearly not a viable solution for most other users, so I have failed to help them this time.