Introduction

FrontAccounting Approval System Module is a compact module to handle the transactions held for approval from created roles, Which will be maintained to perform multi level approvals in one place. It's an effective and tested module for listed types. It's works as independent module, never hurt the core. You can update the core like whatever the FrontAccounting versions get released. 



Demo Credentails 

User Top 

username : firstuser
password : password

Second User

username: seconduser
password: password


Third User
username: thirduser
password: password

With these above credentails you can test the Sales invoice transaction with approval process. 


Approval is a process of organizational hierarchy to operate based on the right or permission given to an employee in the company. It's like lower level people can create and do some entries, which will be approved by the above authorities. So we provide multi-level approval from our module. 

FrontAccounting is well known application for ERP to provide maximum features at less than 5mb programs. We offer several modules to help FA users to use the system effectively. This approval module was designed to work based on several customers request and it was tested with few customers. And they are very happy about its usage towards the approval.

Let me explain about the system functionality along with my example flow. We will consider a company along with Purchase officer, Purchase  manager and an Administrator, who has ultimate right on all operations.

So here we have 3 levels of hierarchy, which actually helps to get it.  So lets start with Purchase officer, He is a lower level roled person. so he will create Purchase orders. but it wont be directly placed in the system. It will be put in an approval queue, Which actually gives approval flow to the Purchase manager. not the administrator. The Purchase manager checks the entries and order details. if any entry has problem, or information is incorrect, either he can able to edit and approve it. or he can able to reject the Purchase order. 

Which will actually shown to the purchase officer again to allow him to correct and submit it for re-approval. than he will approve it. and than it wont be place directly inside the system. it will again goes to  next level approval under Administrator.

when he approves, this entry will be pushed to core system and made entry with it. And This one process starts with lower level to top level.

Suppose if the purchase manager directly makes the PO, which will wait for the approval of Administrator.

If the Administrator makes the PO, it wont wait in the queue, He is a top level person. so his entry will be pushed to live directly.

This hierarchy definition will be set by yourself and it will work based on document type.  you can define it independently on each document type. Currently we have list of some transaction types. May be in future we will update to other transaction types too. Here is the list of covered transaction types.

• Journal Entry
• Bank Payment
• Bank Deposit
• Funds Transfer
• Sales Invoice
• Customer Payment
• Customer Credit Note
• Delivery Note
• Location Transfer
• Inventory Adjustment
• Purchase Order
• Supplier Invoice
• Supplier Payment
• Supplier Credit Note
• Purchase Order Delivery
• Sales Order
• Sales Quotation