Operational cash flow planning or how to build a cash flow control system. Subsystem "electronic applications" for spending funds Application for spending funds 1c upp
1. Introduction
Cash planning is one of the main tasks of management accounting, as opposed to financial accounting.
Of course, there are other significant differences between management and accounting (different requirements for analytics, for the assessment and revaluation of assets/liabilities, the need to create reserves, etc.), but the need to solve planning problems is the most difficult of them.
The complexity of planning lies not only in preparing the plan (calculating it, forming it according to different scenarios), but it is also necessary:
- Perform rescheduling;
- Update plans, transfer adjustments to subsequent periods;
- Carry out a plan - a factual analysis.
“We should set up accounting...” - this is how many people argue.
Accounting needs to be improved, yes, but not at the expense of planning.
Of course, they still do planning (but not in 1C, but in XLS). And the very first, main task (which they are trying to solve) is cash planning.
- (1) Strategic (budgeting);
- (2) Operational.
The bottom line is that most often a minimum of users (1-2 people) work with budget tables. For most enterprises, the number of budgeting items and other analytics is not so many. That is, everything can be processed manually in XLS.
But as for operational planning of d/s, the situation here is different. That is, there are often a large number of invoices to pay, many regular payments, expected payments for customer orders, etc.
And besides, all this can be “tied up” to a large number of primary documents with which various users of the program work, documents are adjusted, the situation changes, etc.
Another important difference between operational planning and budgeting is that it often comes from the bottom up. That is, from “Requests for d/s expenses”, which are always filled out by department employees.
And these applications, accordingly, need to be processed on time, accepted/rejected, “scheduled” and paid for.
Total: operational planning for d/s is the very first planning task, which should be automated in 1C for any enterprise.
And as a result of planning, the financial department / treasury should “see” in the system:
- When, to whom, from which bank account/cash, for what amount must be paid;
- What will be the cash balance on “such and such” date, taking into account current balances, planned expenses and cash receipts. The so-called must be avoided. "cash gaps"
That is, there is a need to work with the payment calendar.
- What debt with counterparties will be on specified dates, taking into account planned payments, receipts and the current balance of mutual settlements.
That is, there is a need to work with the calculation calendar.
Each of the configurations can be used to solve operational planning problems, but a balanced choice should be made based on the scope and scale of your project.
2. Features of soft starter 1.3
At the moment, 1C has not yet released the long-awaited, new edition of the UPP (revision 2). And for this reason, we will focus on what is available - the corresponding subsystems of SCP 1.3:
It must be noted that the subsystem “Requests for Expenditure of Cash” was updated in the configuration relatively recently (2011). And as a result, in the managed interface mode, the item “Requests for spending d/s/” appeared in the section panel.
If you try in a standard configuration, in file mode, to open the document form “Request for D/s Expenses” (aka, ZRDS), then an error immediately appears for the variable “Global Values” from the general module “Working with General Variables”.
Such errors can be corrected, however, as they say: “the sediment remains.” That is, there are enough “roughnesses” in the UPP ZRDS subsystem.
The ability to draw up a ZRDS document through a WEB browser is useful, but in practice you will have to think carefully about the simplification and ergonomics of the standard form of the document. This will be especially important for mobile devices.
But as for the payment calendar, in thin client mode, remotely via a WEB browser, etc. you won't be able to use it. The reason is that the Cash Management subsystem has not been updated for a long time and, in particular, the Payment Calendar report is not built on a data composition system. Therefore, this report cannot be used in thin clients; there is no possibility to create custom settings for it.
When working with ZRDS, an important place is occupied by the regulations for the coordination and approval of applications. Depending on the organizational structure enterprise and other business features, the internal procedure for approving applications (approval regulations) can be quite complex (multi-stage, variable, etc.). So this is not an easy task for automation.
In UPP, the coordination and approval subsystem is implemented. It provides quite flexible settings.
- Approval is confirmation of the need to pay for the application. Typically, approval must go through the heads of departments, managers and other responsible persons of the company.
- Approval is the final confirmation (by the Treasurer) that the application will be paid. In this case, the payment date and the bank account/cash office from which the payment will be made must be determined. Thus, the payment falls into the operational plan (payment calendar).
I will write about these “moments” later, but for now let’s look at what functionality a typical configuration provides.
- You can enable the use of the application approval mechanism separately for each organization.
- It is possible to configure the sequence of the application through routes and the hierarchy of routes.
- It should be noted that the hierarchy in the department directory is not taken into account in the application routing mechanisms.
- It is also necessary to cancel that coordination and approval were technically constructed without the use of a business process mechanism.
- At each point, you can specify one/several users for whom approval of the application will be available. That is, the application can be approved by any of them (whoever manages to do it first).
- For each department, you can assign a corresponding approval route point. The essence of this is this: when filling out an application (ZRDS), the Central Federal District (division) must be indicated. And depending on the specified division, the UPP “finds” the corresponding approval point and “sends” the application for approval to this point.
It is also possible not to specify a department when setting up the approval route. In this case, such a coordination point will be “applied” to all CFDs for which the corresponding route point is not specifically indicated.
- The approval itself is performed using a special processing “Application approval”
- Analysis of the planned availability of funds, payment schedule and tracking of cash gaps is performed in the “Payment Calendar” report.
In addition to the planned consumption of d/s (ZRDS), you can also take into account the planned receipt of d/s. For these purposes, it is envisaged to draw up a special document “Planned receipt of income”.
It should be noted that although the document “Planned receipt of d/c” has states (prepared, agreed upon, etc.), there is no opportunity to coordinate this document (as well as the ZRDS). That is, changing document statuses is only possible in the “ manual control».
And in the UPP it is possible to take into account the planned receipt of cash from buyers without preparing documents “Planned receipt of cash”.
That is, if “Customer Orders” are issued for a buyer, then in a separate report “Payment calendar taking into account orders” this planned receipt can be seen.
- In addition to the Payment Calendar report, there is a Cash Availability Analysis report.
At the same time, it is possible to reserve d/s (based on applications for expenses) or place applications against planned revenues.
There is also functionality for closing ZRDS and planned income from d/c. For these purposes, in the “regular client” mode, documents “Closing applications for expenditures/receipts” are provided.
However, this functionality is also not supported in thin/web client mode.
Here you need to understand that the “hard reservation” technique is strongly tied to the chronology of document entry, and this makes adjustments and rescheduling difficult.
Therefore, the functionality is left in the UPP rather as a “legacy of the past”, and the payment calendar should be used to analyze the availability of d/s. 
So, we have considered the functionality of the soft starter and now I will list those aspects of the standard configuration that in practice, on projects, have to be modified:
- According to the document “Application for d/s expenditure”:
- In the document, you can indicate “Division” (by the way, in the configuration it is designated as the Central Federal District - center of financial responsibility). But it is quite possible that an application is submitted from one division (CFD), and in this case the costs will need to be further attributed/distributed to another division(s) (CFD - financial management centers).
Ability to specify digital functions, etc. - absent.
There is no possibility to change the route or redirect the application to other routes.
- In the document, you can indicate “Division” (by the way, in the configuration it is designated as the Central Federal District - center of financial responsibility). But it is quite possible that an application is submitted from one division (CFD), and in this case the costs will need to be further attributed/distributed to another division(s) (CFD - financial management centers).
- There is no possibility to plan the transfer of cash between current accounts, from the account to the cash desk, etc.
- Agreement process:
- It is possible to coordinate the ZRDS, but there is no possibility to coordinate the planned receipt of d/s.
- In practice, it becomes necessary to carry out approvals for other employees. At the same time, the system also needs to record information about “who performed the approval and for whom.”
The option of installing several possible executors at one coordination point is often not suitable, so this executor can be indicated at other stages of coordination. As a result, all this will lead to the fact that the employee will simultaneously have both main and indirect approval tasks in the list of requests for approval. Of course, this confuses the user and is not convenient.
To summarize, the ability to coordinate for another performer, the ability to indicate who has the right to coordinate for whom is absent.
- In the process of approving applications, when an application is passed on for approval to the next one along the route, the functionality of automatically informing (by e-mail) the next executor, as well as the author of the application, is in demand.
- If the author of the application is already responsible for coordination/approval (at any stage of the route!), then it is quite logical for the program to automatically “shorten” the route, redirecting the application to the highest available level. However, this is not provided for in the UPP.
- All of the above requirements, although not included in the standard configuration, are nevertheless .
- Reports, access rights.
- There is a demand for the possibility of limiting access to applications only by available authors/performers (co-ordinators); by departments available to the user.
- There is no reporting on monitoring (by days and intervals) of actual and planned debt. This is true for both buyers and suppliers.
- Reporting and some of the functionality are not suitable for working in thin/web client mode.
- Accounting for regular agreements and contracts.
- There are often situations when it is necessary to regularly pay suppliers. For example, rental payments, etc.
UPP does not automatically reflect it in the payment calendar, etc. these upcoming expenses. That is, it is necessary to manually track such payments and fill out payment requests, which is inconvenient and time-consuming.
- Agreements with buyers and suppliers may stipulate conditions for the percentage of advance payment, payment terms, etc.
The UPP does not automatically record all this information and (as a result) automatically reflect it in the payment calendar.
- There are often situations when it is necessary to regularly pay suppliers. For example, rental payments, etc.
With the release of the new configuration “Trade Management Rev.11”, many new, useful features have appeared for the tasks of operational planning and financial control.
Perhaps the most significant thing in this part in UT11 (compared to UPP 1.3) is the mechanism for accounting for the payment schedule. This mechanism “closes” what was sorely lacking - automation of planning/accounting under regular agreements and contracts.
Thus, in UT11 you don’t have to draw up documents at all (if there is no need, of course) for planning expenses and receipts, and at the same time, the payment calendar will be formed normally.
You can cancel that the “standard settings” of the “Payment calendar” report do not really meet expectations (as such, the calendar is not displayed), but in the user mode you can add a grouping by “payment date” and the report will be generated in the usual form.
The functionality of the report has greatly expanded (compared to SCP 1.3) due to the use of a data composition system. Now, the report can be generated in a thin/web client, saved in the database and assigned to different users the settings they need.
In addition to planning the consumption and receipt of household goods, UT11 now has the functionality of planning the movement of household goods. For these purposes, you can draw up documents “Order for the relocation of households.”
Compared to UPP 1.3 for the document “Application for expenditure of cash”, the number of considered types of business transactions has increased:
It is now possible to approve both the documents “Application for the expenditure of funds” and other orders:
To analyze debt by intervals/deadlines, the “Accounts Receivable” report is provided. If necessary, you can also create a debt calendar. To do this, in custom mode you should add a grouping by payment dates.
Unfortunately, UT11 (as before) does not provide the ability to analyze the debt calendar by suppliers. However, UT11 needs to be finalized for this task.
To summarize: new methodological solutions "1C", together with the capabilities of the 8.2 platform, provide a good basis for automating the tasks of operational planning and control of d/c.
But at the same time, you need to understand that the UT11 configuration is not complete, ready-made solution for automation of treasury and financial planning.
- Firstly, UT11 implements in a very simplified form a mechanism for coordinating/approving requests for expenses and other d/c planning documents. That is, there are no routing mechanisms, the process of approving applications is reduced to simply setting statuses.
- Secondly, UT11 does not have a budgeting subsystem and (as a result) there is no functionality for monitoring applications for planned budgets.
Historically, the WA:Financier configuration was developed based on the Treasury Management product.
And at the same time, the new “Financier” solution from WiseAdvice also includes:
- Budget planning subsystem;
- Contract management subsystem;
- Subsystem for the formation and accounting of actual payments;
- Flexible, customizable mechanism for generating/filling out documents based on templates;
- Flexible, customizable client-bank integration subsystem.
- During the application approval process, you can not only approve/reject the document (as is done in UPP), but other functions are also available: for example, send a document for revision, or request additional information. information.
This entire process is automated; accordingly, reporting is provided on the status of document approval processing.
5. Results
 |
 |
 |
Conclusions:
- To automate the work of financial departments, treasuries, organizations with complex organizational structures. structure the most suitable solution is "WA: Financier".
This solution has been developing and evolving for a long time, accordingly accumulating the specifics and requirements of different financial institutions. departments and treasuries. The total labor costs for developing the solution amounted to more than 5,000 person/hours.
The advantage of the WA: Financier solution is its advanced functionality and a large number of program settings mechanisms. Thus, the implementation of this solution is possible in short time(so-called “out-of-the-box implementation”), without additional. development, programming, etc.
Since the solution contains mechanisms for two-way exchange with all the main standard configurations, integration into the existing structure (data exchange with UT, UPP, Kompleksnaya, Bukh databases) will not be difficult.
- To automate the financial department / treasury within the framework of a comprehensive automation project the best solution is based on UPP.
At the same time, you need to understand that the functionality of the soft starter will require improvements.
Specifics, financial requirements. departments and treasuries are not embedded in the UPP as deeply as is done in separate, specialized solutions.
Thus, the implementation of SCP for these tasks should only be carried out as part of an automation project.
- For large organizations, for automation of the treasury department UT11 doesn't fit.
In this decision, firstly, there are no mechanisms for coordination/approval of planning documents.
Secondly, there is no budgeting subsystem and control over the implementation of budgets during operational planning.
However, UT11 perfect for automation (including operational planning d/c) small financial company departments.
The document “Request for expenditure of funds” is intended for planning and coordination of payments.
The document “Request for spending DS” can be created by going to the section “Treasury” - “Planning and control of funds” - “Requests for spending DS” - Create.
The document “Request for expenditure of DS” has several types of operations that are selected during creation. Each type of application is intended to reflect a variety of business transactions, each of which will be described in this instruction.
The created documents “Application for spending DS” are collected and agreed upon using the “Register of Payments” document. After approval, based on the applications, “Write-off of non-cash DS” documents are automatically created, which are uploaded to the client bank for payment by the bank.
The following are examples of the execution of documents “Application for the expenditure of DS” for each type of operation.
Payment to the supplier
To process payment transactions to a supplier, the transaction type of the document “Request for expenditure of DS” is intended - “Payment to the supplier”.
In the new document “Application for spending DS”, the fields that are required to be filled in to process the document are marked in red. The document is created in the status “Not approved”; the status changes automatically during the approval of the payment register. The priority of the application upon creation is automatically set to “Medium”.
Figure 1. Document form “Application for expenditure of DS”, type of operation “Payment to supplier” (not filled out)
The details of the document “Application for spending DS” must be filled out as follows:
Basic tab
Number– is generated automatically during execution, cannot be set manually.
date– when created, the current date is set.
Organization– you must select from the proposed list of organizations using the button, or by entering the name in the field, the required value will be offered for selection.
Subdivision– from the “Enterprise Structure” directory, you must select the division for which the payment should occur.
Applicant– by default, the current system user creating the application is indicated.
Planning– the default setting is “In payment currency” and cannot be changed.
Sum– indicates the amount of the required payment.
Currency– indicate the currency of the required payment.
Operation– the type of transaction of the document “Application for expenditure of DS” selected during creation is reflected
payment date– indicates the date on which the payment to the supplier must be scheduled.
Form of payment– the default setting is “In any form” and cannot be changed.
Recipient– indicates the supplier from the “Counterparties” directory to whom payment must be made.
Recipient's account– when selecting “Recipient”, the recipient’s account is automatically set; if necessary, if a different account is indicated on the “Invoice for payment” provided by the supplier, you must select the required one from the “Bank Accounts” directory.
Over limit– if the system maintains a system for limiting cash expenditures in the context of branches and cash flow items, respectively, if the amount of the payment being made was not previously included in the limit, when posting the document the user will receive an error message and the application will not be processed.
Figure 2. An example of an error when placing an order for which a limit was not planned.
To place an order over the limit, you must set the “Over Limit” flag
Transfer to the budget– this flag is set if the payment is a transfer to the budget. Setting the flag allows you to enter the values of KBK, OKTMO, etc. required for payments to the budget.
Figure 3. Example of setting the “Transfer to the budget” flag.
UIP– a unique payment identifier, indicated only if this is provided for in the agreement with the payee.
Purpose of payment- the program provides several options for auto-filling the payment purpose using the "Insert" button.
Figure 4. Options for auto-filling the “Payment purpose” field.
List of documents, incl. VAT- will display information about settlement objects from the “payment decryption” tab
Incl. VAT (18%) (for the entire amount), incl. VAT (10%) (for the entire amount), Excluding tax (VAT)- VAT information will be added to the entered text.
Text from the recipient's bank account- inserts the text specified in the "Payment purpose text" field from the counterparty's account card.
Figure 5. Example of filling out the “Basic” tab.
Payment Details tab
The “Payment Decoding” tab provides detailed information about the payment and mutual settlements with the payee.
Payment can be entered as a list, i.e. distribute over several calculation objects, or without splitting, it is possible to select only one calculation object.
Payment from state defense funds– the flag is set only if the payment occurs within the framework of a defense government order, in other cases the flag is not set.
Calculation object– as the settlement object, you can specify “Agreement with the counterparty” (for this type of operation of the application document, when selected, agreements with the type of relationship “With supplier/performer” are available) or the agreed document “Order to supplier”.
Provider
Amount of mutual settlements– is set automatically when posting a document.
Currency– is set automatically when selecting a calculation object.
DDS article– indicate the cash flow item corresponding to the type of payment.
A comment– if necessary, indicate a comment on the payment decryption.
Figure 6. Example of filling out the “Payment Decoding” tab.
Account distribution tab
On the “Distribution to Accounts” tab, the bank account of the organization from which funds should be debited is indicated. The amount and date of payment are set automatically according to the data specified on the “Basic” tab.
Figure 7. Example of filling out the “Distribution by Accounts” tab.
Figure 8. An example of an automatically created document “Write-off of non-cash DS” for an application with the type of transaction “Payment to supplier”.
Return of payment to the client
To process refund transactions to clients, the type of transaction in the document “Application for spending DS” is intended - “Return of payment to the client”.
The composition of the details of the document “Application for expenditure of DS” with this type of operation is identical to the composition of the details when paying the supplier, the only difference is in the type of counterparty and the object of settlement.
Figure 9. Form of the document “Application for spending DS”, type of operation “Return of payment to the client”
Recipient– indicates the client from the “Counterparties” directory who needs to make payment.
Calculation object– as the settlement object, you can specify “Agreement with the counterparty” (for this type of operation of the application document, when selecting, agreements with the type of relationship “With the buyer/customer” are available) or the agreed document “Customer Order”.
Buyer– the field is filled in automatically when selecting a calculation object. The “Partners” directory element specified in the corresponding field of the calculation object is installed.
Figure 10. Example of filling out the “Payment Decoding” tab.
After passing all stages of approval, the document “Application for spending DS” will be assigned the status “For payment” and the document “Write-off of non-cash DS” will be automatically created.
Figure 11. An example of an automatically created document “Write-off of non-cash DS” based on an application with the type of operation “Return of payment to the client.”
Issuance to the accountable
To formalize transactions for issuing funds to a bank account of an accountable person, the transaction type of the document “Application for spending DS” - “Issue to the accountable person” is intended.
Figure 12. Form of the document “Application for spending DS”, type of operation “Issue to the accountable”
Accountable person– the employee is indicated from the directory “ Individuals”, to whom it is necessary to transfer the money.
Report– from the proposed list of periods, it is necessary to indicate the period until which the accountant needs to report on the amount received.
Figure 13. Example of filling out the “Payment Decoding” tab.
After passing all stages of approval, the document “Application for spending DS” will be assigned the status “For payment” and the document “Write-off of non-cash DS” will be automatically created.
Figure 14. An example of an automatically created document “Write-off of non-cash DS” based on an application with the type of operation “Issue to the accountable”.
An essential condition for the effective existence of an enterprise in a modern competitive environment is the creation of an effective management mechanism cash flows ensuring the generation of prompt and reliable information, regulation of mutual settlements, increasing payment discipline and, ultimately, accelerating cash turnover.
The configuration contains tools for automated enterprise cash management, which performs two main functions:
- operational accounting of the actual movement of funds of the enterprise on settlement accounts and cash desks;
- operational planning of cash receipts and expenditures of the enterprise.
General planning of the expenditure and receipt of funds of an enterprise is carried out within the framework of budgeting. The financial plan being drawn up - the budget - acts as a set of guidelines and constraints for the cash management subsystem.
But within the framework of cash management functionality, an operational financial plan is maintained - a payment calendar. It makes sense to create a payment calendar several days in advance.
The payment calendar is a collection of requests for spending funds and planned cash receipts. The payment calendar is compiled with details down to the places where funds are stored - bank accounts and cash desks of the enterprise. When compiling a payment calendar, its feasibility is automatically checked - the sufficiency of cash reserves in the places where they are stored.
The division of the financial planning function into two configuration subsystems - the budgeting subsystem and the cash management subsystem - corresponds to the division of financial management functions between various departments and employees of the enterprise. If the budget is drawn up by financial services, then requests for spending funds are generated by employees and departments that directly interact with the company’s counterparties.
In the configuration, monetary documents are generated (payment orders, cash receipts and debit orders, etc.), interaction with specialized banking programs such as “Bank Client” is ensured, financial flows are controlled, and the availability of funds in storage areas is monitored. The possibility of cash payments in foreign currencies is provided.
The document “Request for spending funds” is intended to record the decision to make a cash or non-cash payment (group of payments) or move funds. The document details and the procedure for their use are basically similar to the documents “Payment order (outgoing)” and “Cash expenditure order”.
Reservation and placement parameters can be filled in automatically. For this purpose, the document provides flags and "Automatic placement".
If these flags are set, then the “Placement” column can be filled in automatically when you click the button "Fill and Post".
The automatic and manual placement scheme can be combined. When the flags are set "Automatic reservation" And "Automatic placement" You can manually specify the placement option for part of the application amount. Then when you press the button "Fill and Post" There will be an automatic placement only for the remaining amount.
When the operation type is set to " Payment to the supplier" or " Refund to the buyer" changes are made to operational settlements with counterparties.
Based on the document “Application for spending funds”, bank and cash payment documents can be entered. Such documents provide the requisite “ Application", which is filled in as you type based on it, or can be filled in manually. When posting payment documents with a specified application for spending funds, the compliance of the document amount with the current balance of outstanding payments for this application is checked.
When setting up additional rights, it is possible to prohibit the user from processing payment documents without indicating an application for spending funds.
The document “Request for expenditure of funds” can also serve as a link between the cash management subsystem and the budgeting subsystem. For this purpose, the application provides a block of details similar to the “Budget Operation” document (planning scenario, turnover item, central financial district, project, etc.). Using the specified details, when submitting an application, the compliance of the total amount of funds approved for expenditure with the previously established limiting values is monitored.
Features of working with applications when using the application approval mechanism
The application approval mechanism is used optionally: for a list of organizations.
When using the application matching mechanism, the following features arise:
The user whose application is currently being approved
Users approving an application at higher stages of approval
Other users cannot change the application.status is displayed in a separate column
Grouping by order status is used
applications are highlighted with background color
rejected - pink
If the application does not indicate an organization, this application does not participate in the approval
The route for approving the application is determined in accordance with the settings depending on the Division specified in the application.
If the application has not passed the approval route (the application status is not “Approved”), a payment document cannot be issued on its basis
If the application begins to go through the approval route, the application can be changed
If the order is in the "Approved" state, it cannot be changed
If the application enters the "Rejected" state, the application is canceled
The current status of applications is in the list of applications
In the second part of the article, we will consider the principle of creating “Requests for spending funds”, passing it along the approval route and issuing funds according to the created application.
Let's look at an example:
- The procurement accountant forms a request for the expenditure of funds in order to make an advance payment to the supplier of IP Dobronravov for the supply of materials;
- The CFO must review and approve the application;
- Based on the approved application, the procurement accountant generates a cash receipt order (without the “Paid” mark, but with the “Reflect in operational accounting” mark);
- The senior cashier, having checked the cash receipt order, issues funds (and marks the document as “Paid”);
- The cash transactions accountant checks the cash receipt order (checks the box for reflection in accounting and tax accounting records so that accounting and tax accounting entries are generated).
To make it easier to reflect transactions, let’s switch the interface to “Cash Management”.
Before you start working with applications for spending funds, you must enter all background information. The first thing you need to fill out is the information register “Settings for approving applications for spending funds.” In “Setting up the approval of applications”, the organizations for which this mechanism is used and the start date of using the approval mechanism are indicated. This setting is needed so that the program can determine that the organization StroyTorg LLC will use a mechanism for approving requests for spending funds from 01/01/2013.
It is also necessary to configure coordination routes (Fig. 2). This setting is indicated in the information register “Settings for the start of approval routes”: the correspondence of approval routes to departments is determined. The approval route (the “Approval Routes” directory) indicates the stage and the list of approving persons at this stage. In our example, the created application will first have to go through one stage of approval by the financial director.
You also need to set up the information register “Setting up the approval of applications for spending funds” (Fig. 1) and determine the stages (route) of approving applications (Fig. 2)
Rice. 1
Rice. 2
Coordination route The application is determined in accordance with the settings and depending on the department specified in the application.
note that one division must correspond to only one coordination route. An approval route must be specified for each division, otherwise the approval process for all applications created for this division will not take effect.
1. The purchasing accountant creates the document “Request for expenditure of funds”.
In the “Cash Management” interface we have chosen, go to the menu item “Planning” - “Requests” - “Request for spending funds” (Fig. 3). Let’s create an “Application for spending funds” with the status type “Prepared” (Fig. 5)
The Application has several types of operations that repeat the types of operations “Cash outgoing order” and “Outgoing payment order” (Fig. 4)
In the “Request for spending funds” on the “Settlements with counterparties” tab, basic information is indicated: the counterparty for payment to whom funds are required to be issued, as well as the agreement, amount, organization, division and status.
On the “Description” tab you can specify Additional information in any form.
The “Allocation” tab provides the possibility of reserving and placing funds (Fig. 6). This means that in our example, the purchasing accountant can reserve funds in order to pay an advance to the supplier, and indicate from which cash desk the funds will be issued. Reservation and placement parameters can be filled in automatically. There are flags for this purpose in the document. "Automatic reservation" And "Automatic placement". If these flags are set, then the “Placement” column can be filled in automatically when you click the button "Fill and Post". The automatic and manual placement scheme can be combined.
The data on the “Budgeting” tab can be used as a link between the budgeting subsystem and the cash management subsystem. The information displayed on this tab serves to control the amount of funds planned for disbursement in accordance with the planned budget (Fig. 7).
Since the procurement accountant has limited access rights, he can only set the status “Prepared” in the “Request for expenditure of funds” document, and such statuses as: “Approved”, “Postponed”, “Agreed”, “Rejected” are set by users, responsible for approving the application.
2. The financial director reviews and approves the application for the expenditure of funds in the amount of 120,000 rubles.
The financial director can analyze the list of applications requiring consideration using the “Application Approval Status” processing (Fig. 8).
When you start processing “Application Approval Status”, it displays a list of all applications grouped by certain statuses (states), such as: “Prepared”, “Approved”, “Postponed”, “Agreed”, “Rejected”. For convenience, you can make a selection “Setting the period” using the button, for example, for a day, a week, a month, a decade, a quarter, a half-year, a year, etc., and then, of all applications, only those that fall within a given period will remain.
In order to change the status of applications for spending funds, for example, from “Prepared” to “Approved,” you need to use another processing (“Application Status”).
In this processing, you can select from general list applications, for example, applications with the status “Awaiting approval”, “Postponed”, “Awaiting approval at previous stages”, “Processing” (Fig. 9).
Processing displays a list of uncoordinated applications and you can change the status of the application (Fig. 10). You can go to this processing through the menu item “Planning” - “Requests” - “Coordination of applications”.
The Financial Director can “Approve” the Request for spending funds, “Postpone” or “Reject” it. When you select “Change status” - “Agree”, the checkboxes mark those applications that need to be approved. The remaining applications that were in the queue can be viewed in the document log “Approval of applications”.
If the application has not passed the approval route (the application status is not “Approved”), then a payment document cannot be issued on its basis.
If the application begins to go through the approval route, then the application can be changed:
The user whose application is currently being approved;
Users who approve the application at higher stages of approval.
Other users cannot change the application.
If the application is in the “Approved” state, then it is not available for change (becomes inactive for editing), so the fields in the application become gray for the purchasing accountant and cannot be changed.
3. Based on the approved application, the purchasing accountant draws up a cash receipt with the transaction type “Payment to supplier” without the mark “Paid” for the issuance of an advance to the supplier of IP Dobronravov (Fig. 11)
note, that in the cash receipt order created by the purchasing accountant, only the “Reflect in management accounting” and “Reflect in operational accounting” checkboxes are checked. The “Paid” checkbox must be checked by the senior cashier after checking the correct formation of the cash receipt order. We also indicate in the cash receipt order on the basis of which application we are generating it.
If in the cash receipt order there are checkboxes only for management accounting, then such a document does not generate postings (accounting records). But he makes entries in the accumulation registers: “Cash for write-off” and “Settlements with counterparties” (Fig. 12). This information goes into the “Payment calendar” report in the “Unpaid outgoing documents” section (Fig. 13).
4. The senior cashier checks the cash receipt order, checks the “Paid” checkbox and issues cash.
After the cash receipt order is paid, the fields in the document become gray and cannot be edited by the purchasing accountant and other participants in our example. Depending on what access rights are configured for a particular user, certain documents, fields in documents, etc. may be available for editing.
Note: If there are a lot of cash registers and you need to check the “Paid” box in each one, you can use group processing of directories and documents (menu item “Service”). You can go to this processing by going to the full interface, menu item “Service” (Fig. 14).
To change the details, click on the “Settings” button and select the “Allow changing object details” flag. For ease of analysis, let’s set the “Show all columns” flag (Fig. 15).
Using group processing, we want to put the “Paid” flag in the cash receipt order. To do this, in the “Selection” section of group processing, we indicate the organization StroyTorg LLC; We select only processed documents for the period from 01/01/2013 to 01/21/2013 with the option “Paid” - “No”.
When you click the “Select” button on the “Processing” tab, documents will appear in which you need to mark “Paid” (Fig. 16). In the “Action” line, select “Change details[Link.Paid] - Install. And "Run".
After changing the value of the details, you need to re-post the changed documents: in the “Action” field, select “Change: [Post documents] – Set - “Run” (see Fig. 17).
5. The cash accountant checks the cash receipt order (checks the box for reflection in accounting and tax accounting records so that accounting and tax accounting entries are generated).
Further, for example, at the end of the working day, a cash transactions accountant checks all cash outgoing orders that are marked “Paid” and ticks the BU and NU boxes in the document so that the document generates accounting and tax accounting entries. (Fig. 18)
Note: if there are a lot of cash receipts orders in which you need to check the BU and NU boxes, then you can use the “Group processing of reference books and documents” (Fig. 19).
In the group processing of directories and documents, we select the documents “Cash expenditure order [TC: Payment Decoding]”, in the tabular part of which you need to check the “Reflect in accounting” checkbox.
In the “Selection” field we indicate for which organization we need to select documents, we indicate that we are only interested in documents processed for the interval from 01/01/2013 to 01/21/2013 (as well as cash receipts in which the “Reflect in accounting” checkbox is not checked) accounting"). After filling out all the parameters, click the “Select” button: documents that meet the specified conditions will be selected. In the lower part of the processing window, select “Change attributes” - “Reflect in accounting" - "Install" and click the "Run" button. After the documents are processed, they need to be re-posted (Fig. 16). Then you need to repeat the same thing, but to check the box “Reflect in tax accounting”
When posting the document “Cash expenditure order”, not only movements are generated in accounting accounts, but also in registers (Fig. 20, 21)