Authorization comes together with audit trail and user permission level I Imagined. As long lubos yet to made later both flexible and reliable. Authorization have to wait. This is complex feature.
A post was split to a new topic: Location permission control
Hi, Looking at the communication on the topic, what Tut says is right in view of program integration. But surely this requirement is a thing which every company having a hierarchy will want for.
To simplify this idea to work, lets look at this way: why we need levels of authorization is to maintain a work flow and to avoid duplicates, errors and doubtful transaction and also the fact that to excercise the authority by the senior officer in the line.
So, lets solve this all, by introducing a work flow in Manager : System should allow in setting to create a workflow from quotation to invoice.( quote - sales order - PO - PI - GR - SI -DO ) each company can set its own way, → So,this will avoid duplication, errors and confusion.
the server and cloud system allows muti user, and allows to assigning Tab (function) to user. So System only need to print automatically the user name. → So, this solves the problem to show the ownership of document/transaction.
i think its worth realizing that the Manager or its use is been put to much advanced now than merely being an accounting software. i believe the developers and most active members in this forum can realize that. so these requirements are no surprise and it only shows the growth of satisfied customers.
This features requires some other functionalities to be added and it will make manager more close to ERP. I worked with Oracle E-Business Suite and provided consultancy as well. It has such a big engine for this purpose you can’t take complete hold of it.
For this function you requires an automation process most likely workflow, notifications, hierarchy on each process in company and authorization control. Complete user features which are defined with employees and software users together. Forms status and auto status change upon approval or rejection and you can’t delete any record after it has been sent to approval engine. Thus it will just increase your database size and load to your software.
I am not against this functionality but @Tut has asked questions, are first to consider before asking such features. BTW manager is for small business. Consider your business scale before over loading your employees with such huge responsibilities.
In some smaller accounting systems, the posting (or as you call it authorization) is made with below reasons:
- To have the accounting head some control on what is entered or not in financial reports.
- To restrict modification of entries after posting without knowledge of the accounting head.
Normally, posting is just a way of controlling. No changes should be made on logic and rules, especially on costing, etc. No matter how many levels of authorization will there be, the final step is posting, and that is where the accounting entry is made in the ledgers.
Generating of financial reports should have the ability to incude unposted transactions or not.
@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.
You gonna have to wait for long.
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.
Authorisation to post maybe too much to ask for for now. But an enhanced user permission workflow is due.
It would be great addition because there are many faults exist when making journal entries due to the lack of time, pressure from upper level etc.
The Hierarchy should be like this.
Prepared By Checked By Approved By
Accountant Accounts Manager Director CEO
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.
I support your idea
I support this
I already read all post/reply of this topic.
And Finally, I support this Idea.
we need it.
I support the idea as well
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.
A form of approval is long overdue in manager.
Good idea in a way. But how can this avoid an unauthorized payment specially when junior prepares the voucher?
Nothing in Manager can prevent payments from being made. Manager only records actions (whether real or imaginary). Manager has no actual payment facility.
Relying on multi-level authorizations imparts a false sense of security. You must control access to the actual bank or cash account, not to the record of transactions posted to it.
Until this comes available facilities are sufficient. However, if there is 2 options as Approve and View + Approve, then most of the recording level security would be met.
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