@jeffbangquil Transaction authorisation will be a very cool feature to have. But the user permission system in Manager is currently not ready for this feature . There is a lot of work to be done to improve the user permission before further advancements (including authorisation) could be made.
See this thread for example
I have been waiting since 2014 to have the system’s user permission workflow improved so that I could go commercial with it here in my country (issue proposals to get organisations to buy and and I get something from installing and setup) but I have waited in vain, price, user permission and occasionally authorisation is what they all ask about first. No organisation will deploy the system in their server here in my country currently with the nature of user permission workflow Manager currently has, the risk is too high (my only disappointment with manager.io)
Authorisation to post and strong user permission is very much a very basic requirement in accounting software these days but to my surprise it totally ignored here. Looks like the Manager.io team is focused on perfecting the desktop version for now and maybe in the future they may consider enhancing user permission and perhaps include authorisation to post.
I would be very surprised if supporting a particular deployment platform was a major focus of Managers feature release plans (particularly the one which produces no financial return). Looking a what software development is actually achieving, the reverse appears to be the case, ie supporting a broad range of deployment platforms.
I do however agree any product can not be everything to everyone. It is sensible to for Manager to be optimised for a particular market segment. Both in terms of:
Product function:- Accounting program, Material management system, Budget forecasting, Personnel management, etc). As well as
Business size:- personal records, sole trader, small business, Large business / corporation.
What is a “basic requirement” is very dependant on what market segment the software targets. As the target business size increases, authorisation requirements become more complex. However so does program complexity and cost to support the program.
Hence product focus is important. Clearly I have zero input in any of this other than to observe specifying a “basic requirement” really does depend on what each user perceives Managers main market to be.
Before I add a comment again let me put this down first. Manual way of checking unauthorised entry in the system is also very good option, and we must consider that too as we wait. A stamp and signature of an approving officer on source documents to be entered in the system is an example of manual authorisation. All entries without this signature and stamp will be considered as a unauthorised. I admit a control mechanism in the software itself will always be better.
I also have this idea that this can be limited to important modules in the meantime if the programmer is interested in adding the feature and setting it up requires doing it for every module. For example starting with the payment and receipt, journal entries and purchase invoice modules.
My suggestion for initial basic multi level authorization is to consider introducing Payment Voucher which can be copied to create a payment by the authorising officer. The payment vouchet should be a mere record without any financial effect just like the purchase order. Junior officers without authority to post payments is given the payment voucher without access to the payment tab.
I have been using the purchase order and purchase invoice feature for this purpose. Procurement officers have access to purchase quotes and purchase orders but have no access to purchase invoice. The Finance Officer has view access to purchase orders and can copy to create purchase invoice. The developers can consider a similar flow on payment to start with as they think about a comprehensive approval system.
If the Payment Voucher tab is availanle then Juniors could not have access to the payment tab. They could be given access to only the Payment voucher tab to prepare the payment voucher which their superior with payment access can copy to create the payment after review and approval. Just like the current purchase order and purchase invoice feature, the status of the Payment Voucher will change from pending to posted or approved once it is copied by the superior to create the payment
The best thing about this idea is that (especially for those who think multi-level authorization isn’t necessary) a choice will be there to enable or hide Payment Voucher tab (or whatever name it might be called if introduced).
I understand that the below suggestion may not work in all scenarios (depending on company size and structure etc), but I still believe it may be a great help for many.
Basically to allow the “payer” of an expense to make an expense claim as a “expense claim request” directly in Manager. He/she list the items and attached the receipts as attachments.
Thereafter, the person responsible for the accounts may post each item to the correct account The “account responsible person” could also “tick” a box verifying that “approval” has been given (Approval may follow whatever process the company have in place - in its simplest form it may be that a printed version of the “claim” has been signed off by the “approver”). Only after this is done are the expense claim entries “posted” into the account ledgers.
This could be a simple “expense claim procedure” that may be sufficient for many smaller organisations.
an expense claim does not record any movement of company funds. it just records a purchase made by the expense claim payer on behalf of the company.
so a payment transaction to the expense claim payer acts like an approval process after verifying the expense claim entered.
your suggestion would only add an additional task to the process which in my opinion would be unncessary.