| Card |
|---|
| default | true |
|---|
| id | 1 |
|---|
| label | Financial Concepts |
|---|
| Buyer It is a financing agreement for payment of inputs or services purchased by the customer from their suppliers. It is aimed at companies that seek to buy in cash from their suppliers, however, with a longer term and better rates, as well as negotiating payment with the bank under conditions appropriate to their cash flow. Guarantees: trade notes, checks, collateral and debtor liable. Advantages for the buyer/borrower: - Enables the replacement of supplier financing for banking financing when the bank offers more attractive interest rates.
- Possibility of negotiating with the seller the benefits they obtain; similar to those of the seller.
- Flexibility for cash flow planning.
- Improved operational results: reduced interest at purchase price.
- Competitive Advantage compared to its players that do not use the product.
Vendor It is a sales financing agreement based on credit assignment, which allows a company to sell its product in installments to legal entities and receive in cash. The Vendor assumes the buyer company is a regular customer of the seller, since the seller takes the risk of the business with the bank. Possibility of using electronic means to contract operations. Guarantees: Supplier and seller guarantee. Advantages for the supplier/seller: - Cash advance: payment up front.
- Tax charge reduction, as sales are effected in cash.
- More flexible financing terms.
- Interest Rate Flexibility
- More competition and better financial efficiency.
- Longer payment term for the purchaser.
- Faster turnover of goods.
|
| Card |
|---|
| default | true |
|---|
| id | 2 |
|---|
| label | Financial Processes |
|---|
| | Accounts Payable |
|---|
Control of bills payable. Budget control by class, in up to 5 different currencies. Posting of bills payable - Manual.
- By Lot.
- Automatically.
Ease and speed in dealings between the company and the bank: - Automatic payment by bank.
- Check issuance and control in continuous or single form
- Banking communication (CNAB standard).
- Control of bank balances.
- Issue of bank statements.
- Issue of payment bordereau.
Follow-up of Supplier history: - Highest balance due.
- Average arrears period.
- Maximum arrears period.
- Current Account Ledger.
Control of balance payable: - Total amount due.
- Total amount falling due.
- Number of outstanding bills.
- Number of bills overdue.
- Ledger.
Accounting of transactions: on-line and off-line. Control of company cash (balance). |
| Accounts Receivable |
|---|
Includes the following criteria: Control of bills receivable. Advances. Provisional bills. Budget control by class, in up to 5 different currencies Investment control Financial agreement control. Ease and speed in dealings between the company and the bank: Automatic bordereau. Bank instructions Banking communication (CNAB standard): - From company to Bank.
- From Bank to company.
Bank balances. Issue of statements. Bank reconciliation. Bank bills. CNAB checking reports. Commission Control: - Commissions by issue of bills.
- Commissions by positing bills (with different percentages)
Monitoring of customer history: - Highest balance due.
- Average arrears period.
- Maximum arrears period.
- Bills protested.
- Payments made.
- Current Account Ledger.
Control of customer balance: - Overdue.
- Falling due.
- Orders without credit.
- Orders with credit.
Control of balances receivable: - Total amount due.
- Total amount falling due.
- Number of outstanding bills.
- Number of bills overdue.
- Auxiliary ledger.
- Collection summary.
- Accounting of transactions: on-line and off-line.
Financial projection in 4 currencies: - By reference (in days).
- By inflationary trend.
- Control of availability (by cash)
|
| Cash Flow |
|---|
It is a very efficient management tool that includes the set of income and disbursements of financial resources by the company in a given period. The analysis and control of information facilitates decision making according to the following criteria: - Survey of the funds required for executing the company's action plans.
- Use, in the best possible way, the available or exceeding resources, preventing them from being idle and being directed to the best applications.
- Planning and control resulting from sales, production and operating expenses projections, as well as data related to activity indexes, average period of inventory rotation, amounts receivable and payable.
- Settle the company's liabilities on the due date.
- Analyze the credit sources that offer less burdensome loans, if the company needs funds.
- Enable coordination among the resources that will be allocated in current assets, sales, investments and debts.
- Consolidation of accounts payable and receivable
- Control in 5 currencies
- Financial simulation considering hypothetical entry of loans, advances or deferrals
- Consideration, in addition to bills, of purchase and sales orders in portfolio, future investments/redemptions, commissions, bills in arrears and interim bills;
- Graphical representation of cash flow.
- Daily segregation of bills.
| Informações |
|---|
| Petty Cash It allows the control of the amounts available for immediate and small expenses in order to manage the flow of money in and out in an agile, simple and less bureaucratic way. This control is made according to the following options: - Maintenance.
- Transactions.
- Recalculation.
|
APV - Adjustment at Present Value The AVP makes the adjustment to demonstrate the present value of a future cash flow that may be represented by inflows or outflows of funds (or an equivalent amount; for example, credits that decrease future outflows would be equivalent to inflows of funds). To determine the present value of cash flow, the following information is required: value of the future flow (considering all terms and conditions of the contract), date of the financial flow, and discount rate applicable to the transaction. To make the determination of CPC 12 (Accounting Pronouncements Committee) feasible, the Financial module has the following features: - Only offline calculation of APV concerning bills of portfolio payable and receivable.
- Processing wizard to help parameterization and application of discount rates in selected bills.
- Parameterization of calculation and respective accounting through multiple thread processes.
- Multiple calculations in the same period, differentiated by portfolio and selection criteria.
- Execution for retroactive periods, considering posting events and the respective accomplishments.
- Definition of the reversal of adjustment processing made by the process selection.
- Definition of the adjustment value of a bill through a formula previously registered in the Formula register of ERP (SM4).
- Simulation of the constitution of bill adjustment, enabling evaluation to start or not the process of portfolio allocation.
The following routines comprise the process of APV calculation: - Financial Indexes.
- Index Update.
- APV Accounts Receivable Calculation.
- APV Accounts Payable Calculation.
- APV Accounts Receivable Check.
- APV Accounts Receivable Bills.
- APV Accounts Payable Check.
- APV Accounts Payable Bills.
|
| Bank Balance in Multiple Currencies |
|---|
This resource controls checking accounts in currencies other than the current one (BRL). Thus, if the company has checking accounts abroad, transactions can be controlled in other currencies (for example: USD, EUR). To use this functionality, it is necessary to register the information in the Banks routine and fill in the Currency field, consequently, the bank balance in multiple currencies is enabled to be used in the following routines: - Accounts Receivable.
- Accounts Payable.
- Transfers.
- Posts Receivable.
- Posts Payable.
- Bank Transaction.
- Automatic Posts Receivable.
- Payment Bordereau.
|
|
| Card |
|---|
| The Microsiga Protheus® system has the bookkeeping feature for the Financial module that allows the exchange of standardized and pre-established information by Banks through electronic files. This process guarantees more reliability, speed in data processing and elimination of manual controls. CNAB (National Council for Bank Automation) establishes the rules to format files through specific guidelines. First, the system administrator must configure the remittance and return files for the bills in the Configurator module: | Model 1 | Remittance | Return |
|---|
| CNAB Receivable | In the Configurator module, access the CNAB Receivable option, and configure the remittance file of Accounts Receivable according to the provisions and rules described in the Bank guideline. In the Financial module, access the Bank Parameters option and register the information. Note: In the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the bank. The system default is Table 17 of the Configurator environment. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters Register). If it is Table 17, check the bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01.
| In the Configurator module, access the CNAB Receivable option and set the return file of Accounts Receivable according to the provisions and rules described in the Bank guideline. The system generates a standard layout of the return file while adding this routine. The file rows must not be changed. You only need to enter the columns of Initial and Final Positions. In the Financial module, access the Bank Parameters option and register the information. Note: In the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the Bank. The system default is Table 17 of the Configurator environment. However, it is possible to generate new tables to perform the same treatment. If the Bank Parameter register is already configured, you do not have to add a record again, except if you need to work with two tables of type identification in the system, send/receive. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters Register). If it is Table 17, check the bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, access the CNAB Occurrences option and register the Bank occurrences for the return of Accounts Receivable. Accounting of posts of accounts receivable uses the standard entry from 521 to 526 for posting, 527 for cancellation, and 562 for bank expenses accounting. In the Financial module, access the CNAB Return Report option and check whether bills are received correctly, because a list of divergences between the bank return text file and the system bill file is displayed in it. In the Financial module, access the CNAB Receivable Return option and receive the bank return text file, according to the parameters defined. | | CNAB Payable | In the Configurator module, access the CNAB Payable option and configure the return file of Accounts Payable according to the provisions and rules described in the Bank guideline. In the Financial module, access the Bank Parameters option and register the information. Note: in the E5_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the Bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. You do not need to register occurrence for Submission of CNAB Payable. In the Financial module, access the Bordereau option and generate the payment bordereaux with the bills to be sent to the Bank. In the Financial module, access the Generate File Payable option and generate the text file to be sent to the Bank. | In the Configurator module, access the CNAB Payable option and configure the return file of Accounts Payable according to the provisions and rules described in the Bank guideline. The system generates a standard layout of the return file while adding this routine. The file rows must not be changed. You only need to enter the columns of Initial and Final Positions. In the Financial module, access the Bank Parameters option and register the information. Note: in the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the Bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. If the Bank Parameter register is already configured, you do not have to add a record again, except if you need to work with two tables of type identification in the system, send/receive. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills the Bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, access the CNAB Occurrences option and register the Bank occurrences for the return of Accounts Receivable. Accounting of posting accounts payable uses the standard entry 530 for Posting and 531 for Cancellation. In the Financial module, access the CNAB Return Report option and check whether bills are received correctly, because a list of divergences between the bank return text file and the system bill file is displayed in it. In the Financial module, access the CNAB Receivable Return option and receive the bank return text file, according to the parameters defined.
|
| Model 2 | Remittance | Return |
|---|
| CNAB Receivable | In the Configurator module, access the CNAB Model 2 option and configure the remittance file. In the Financial module, access the Bank Parameters option and register the information. Note: In the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, go to the CNAB Occurrences option and register the Bank occurrences to submit Accounts Receivable. In the Financial module, access the Bordereau option and generate the bordereaux with the bills to be sent to the Bank. In the Financial module, access the Generate File Receivable option and generate the text file to be sent to the Bank.
| In the Configurator module, access the CNAB Model 2 option and configure the return file. In the Financial module, access the Bank Parameters option and register the information. Note: In the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the Bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the Bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, access the CNAB Occurrences option, register the Bank occurrences for the return of Accounts Receivable. Accounting of posts of accounts receivable uses the standard entry from 521 to 526 for posting, 527 for cancellation, and 562 for bank expenses accounting. In the Financial module, access the CNAB Return Report option and check whether bills are received correctly, because a list of divergences between the bank return text file and the system bill file is displayed in it. In the Financial module, access the CNAB Receivable Return option and receive the bank return text file, according to the parameters defined.
| | CNAB Payable | In the Configurator module, access the CNAB Model 2 option and configure the remittance file. In the Financial module, access the Bank Parameters option and register the information. Note: in the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the Bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the Bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, access the Payment Bordereau option and generate the bordereaux with the bills to be sent to the Bank. In the Financial module, access the Generate File Payable option and generate the text file to be sent to the Bank.
| In the Configurator module, access the CNAB Model 2 option and configure the return file. In the Financial module, access the Bank Parameters option and register the information. Note: In the EE_Tabela field, enter the code of the relationship table between the bill type in Financial and the bill type in the Bank. The system default is Table 17 of the Configurator module. However, it is possible to generate new tables to perform the same treatment. In the Configurator module, access the Tables option and check which table is used for this Bank (through the Bank Parameters register). If it is Table 17, check the Bank return standard regarding the bill type and update the table in the Configurator module. Example: Considering that, for NF type bills, the bank identifies as 01, Table 17 is as follows: Thus, the System identifies the NF type bills of the System as equivalent to the bills that the bank identifies as 01. In the Financial module, go to the CNAB Occurrences option and register the Bank occurrences to submit Accounts Receivable. Accounting of posting accounts payable uses the standard entry 530 for Posting and 531 for Cancellation. In the Financial module, access the CNAB Return Report option and check whether bills are received correctly, because a list of divergences between the bank return text file and the system bill file is displayed in it. In the Financial module, access the CNAB Receivable Return option and receive the bank return text file, according to the parameters defined.
|
|
| Card |
|---|
| default | true |
|---|
| id | 4 |
|---|
| label | Interest |
|---|
| It is the payment of an invested or loaned capital or, even, the ‘rent’ that is paid or charged for the use of the money. It is also the difference between the amount redeemed in a financial investment and its initial value. In any monetarist economy, the cost of lending or borrowing any amount must be measured by means of an index between the price of this credit and its value over a given period of time. This is called the interest rate, which, in turn, is used as a measure to assess both the rate of return on capital from those who have resources and those who do not (loan). In the first case, it is necessary to consider the risk factors, expenses, inflation and a gain one hopes to obtain when applying that rate (so, the higher the better). For the other context, the lower the better. Amount is the term used to classify the initial capital added to the interest of the period. | Simple Interest |
|---|
It occurs when the interest rate always affects the initial capital. The rate, therefore, is called proportional, since it varies linearly over time. In this case, 1% per day reaches 30% per month, which represents 360% per year and so on. Consider the initial capital P applied at simple interest of rate i per period, for n periods. Take into account that simple interest refers to initial capital, so we have the following formula: J = P*i*n J = Interest after nperiods of capital P applied at an interest rate per period equal to i. At the end of n periods, it is clear that the capital is equal to the initial capital added to the interest earned in the period. The initial capital added to interest from the period is called amount (M). Therefore, the formula would be represented as follows: M = P + J J = P + P * i * n M = P + P * i * n So, M = P(1 + i * n)
Example: In the amount of $3,000.00, an interest rate of 5% is applied every month, for five years. Calculate the amount and interest by the end of the period. P = 3,000.00, i = 5% = 5/100 = 0.05 and n = 5 years = 5,12 = 60 months. J = 3,000.00 * 0.05 * 60 = 9,000.00. M = 3000(1 + 0.05*60) = 3,000(1+3) = 12,000.00. |
| Compound Interest |
|---|
Occurs when the interest rate is levied on the initial capital, plus accrued interest up to the previous period. The rate varies exponentially over time and, in this case, 1% per day is not equal to 30% per month, which in turn, will not be 360% per year. The use of compound interest is very common in the financial system and, therefore, more useful for calculating everyday problems. The interest generated for each period is added to the main to calculate interest for the following period. Capitalization is when interest is incorporated into the main, so, after three months of capitalization, for example, it is possible to notice the following scenario: First month: M =P.(1 + i) Second month: the main is equivalent to the previous month: M = P x (1 + i) x (1 + i). Third month: the main is equivalent to the previous month: M = P x (1 + i) x (1 + i) x (1 + i). This context results in the formula: M = P(1 + i)n The rate i must be expressed in the same time measurement of n, which means that both must be in the same unit, that is, interest rate per year for n years. In the system, the rate entered is processed as annual rate. Thus, n must be converted into years, that is, 1 month is equal to 1/12 or 30/360, so time is in the same unit as the interest rate. To calculate interest, decrease the main from the amount at the end of the period: J = M – P Example: In the amount of $6,000.00, an interest rate of 3.5% is applied every month, for one year. P = BRL 6,000.00 n = 1 year = 12 months i = 3.5 % per month = 0.035 M = ? Applying the formula: M = P (1 + i) n M = 6,000 (1 + 0.035)12 M = 6,000 x 1.511 = 9,066.41 |
| Relation between interest and progression |
|---|
In capitalization of simple interest, balance grows in arithmetic progression. In capitalization of compound interest, balance grows in geometric progression. Consider the initial balance of $1,000.00 and an interest rate of 50% in the period. Simple interest: | Period | Balance |
|---|
| 1 | 1,500.00 | | 2 | 2,000.00 | | 3 | 2,500.00 | | 4 | 3,000.00 | | 5 | 3,500.00 | | 6 | 4,000.00 | | 7 | 4,500.00 | | 8 | 5,000.00 | | 9 | 5,500.00 | | 10 | 6,000.00 |
Compound interest: | Period | Balance |
|---|
| 1 | 1,500.00 | | 2 | 2,250.00 | | 3 | 3,375.00 | | 4 | 5,062.50 | | 5 | 7,593.75 | | 6 | 11,390.63 | | 7 | 17,085.94 | | 8 | 25,628.91 | | 9 | 38,443.36 | | 10 | 57,665.04 |
When calculating compound interest, as it is a geometric progression, interest is charged on interest and it is not possible to divide an annual rate to obtain the daily rate. In this case, use the equivalent rate: i q = (1 + i t)q/t-1 i q = rate for the intended period. i t = rate for the given period. q = intended period. t = given period. p.a. = per annum p.d. = per day.
Example: 9.7% p.a. equivalent to: i q = (1 + 0.097) 1/360 - 1 = 0.000257197 iq= 0.02572% (with 5 significant digits) which means: 9.7% p.a. equivalent to 0.02572% per day For compound interest: FV= Future Value PV = Current Value I = Rate (*) n = Period (*) | Informações |
|---|
| (*) both variables must be in the same time period. |
So: FV = 14,500 (1 + 0.097) 1/360 = 14,503.73 J = 14,503.73 – 14,500.00 = 3.73 Note: 1/360 = 1day in one year. Or using the daily equivalent rate: FV = 14,500 (1 + 0.000257197) 1 = 14,503.73 J = 14,503.73 – 14,500.00 = 3.73 |
| Informações |
|---|
| The calculation of interest for bills receivable (which have not yet been paid) is performed according to the parameter MV_JURTIPOS and to the following criteria: Simple Interest (parameter MV_JURTIPOS = S) Interest = Bill balance * (1 + (days overdue * (interest rate / 100))) Compound Interest (parameter MV_JURTIPOS = C) Interest = Bill balance * ((1 + (interest rate / 100)) * (days overdue) Mixed interest (Parameter MV_JURTIPOS = M) It is the combination of simple and compound interests, where: Up to 30 days, simple interest calculation is considered. Interest = Bill balance * (1 + (days overdue * (interest rate / 100))) Above 30 days, compound interest calculation is considered. Simple interest = Bill balance * (1 + (30 * (interest rate / 100))) Interest = simple interest * ((1 + (interest rate / 100)) * (days overdue - 30) Note When there is no interest percentage indicated in the bill, interest is calculated by delinquency fee: Interest = Delinquency Fee Amount * days in arrears |
|
| Card |
|---|
| default | true |
|---|
| id | 5 |
|---|
| label | Investments |
|---|
| The financial investment by quotas or investment funds has some important characteristics so that the income on the investments made can be calculated. The majority of existing funds present daily liquidity, but IOF is levied on redemptions effected up to the 29th consecutive day as of the date of each investment: | Number of days | Income Limit % |
|---|
| 1 | 96 | | 2 | 93 | | 3 | 90 | | 4 | 86 | | 5 | 83 | | 6 | 80 | | 7 | 76 | | 8 | 73 | | 9 | 70 | | 10 | 66 | | 11 | 63 | | 12 | 60 | | 13 | 56 | | 14 | 53 | | 15 | 50 | | 16 | 46 | | 17 | 53 | | 18 | 40 | | 19 | 36 | | 20 | 33 | | 21 | 30 | | 22 | 26 | | 23 | 23 | | 24 | 20 | | 25 | 16 | | 26 | 13 | | 27 | 10 | | 28 | 6 | | 29 | 3 | | 30 | 0 |
As of the 30th day, each investment is exempted from IOF.
Investment fund income To calculate the income, know the number of quotas into which the capital invested was transformed, that is, how many quotas comprise the capital.
| Informações |
|---|
| The value of this quota is published in the economy section of the main newspapers every day. |
First, divide the value of the investment by the value of the quota on the date of the investment. The value of quotas is usually reported with 6 decimal places. BRL 10,000.00/BRL1.263745 = 7,912.988775 quotas. Example: BRL 10,000.00/BRL1.263745 = 7,912.988775 quotas The system uses the quota registered in the contract to make this conversion while adding an investment. Investments are controlled in quotas from the moment an investment is added. Once you know the number of quotas, multiply it by the value of the quota of the day to know its balance. The system uses the quota registered in the contract to make this conversion while adding an investment. Investments are controlled in quotas from the moment an investment is added. Once you know the number of quotas, multiply it by the value of the quota of the day to know its balance. Suppose that, after twenty five consecutive days, the quota has increased in value and now corresponds to $1.283459. The multiplication result is the updated investment, that is: 7,912.988775 x BRL 1.283459 = BRL 10,156.00. This quota must be registered in the Update Quotation option of the Bank Contract routine.
Calculation of total gross yield in the period. To calculate the total gross income obtained in the period, consider the following calculations: Assuming a balance in quotas of 7,912.988775 multiplied by the quota of the last working day of the previous month, or the quota on the date of investment: 7,912.988775 x 1.263745 = 10,000.00 Consider a balance in quotas of 7,912.988775 multiplied by the quota on the day of redemption or allocation minus the balance in item 1. Gross Income: 7,912.988775 x 1.283459 – 10,000.00 = BRL 156.00. To calculate the income proportional to the redemption, first obtain the redemption value in quotas and divide by the redemption value by the quota of the day. Example: 1,000.00 / 1.283459 = 779.144484 (considering the redemption of BRL 1,000.00) The value in quotas obtained in item 1 is multiplied by the quota of the last working day of the previous month or by the quota on the investment date: 779,144484 x 1.263745 = 984.64. The value obtained in item 2 must be deducted from the redemption value to get the income value proportional to 1,000.00: 1,000.00 – 984.64 = 15.36 For better understanding, in partial redemption, the income is calculated by using cross-multiplication. If 156.00 is the income on the updated 10,000.00, the income on 1,000.00 is: X = ( 156.00 x 1,000.00 ) / 10,156.00 = 15.36 Where X = Income on partial redemption. | Income | Redemption |
|---|
| 156.00 | 10,156,00 | | x | 10,000.00 |
Note that, since calculation was made after twenty-five consecutive days and, hence, is NOT exempt from IOF, the value concerning IOF payable must be calculated if there is redemption or allocation. By the tax collection table, if there is a redemption on the 25th day after investment, the amount payable as IOF will be equivalent to 16% of the income (see in the IOF table that 25 days correspond to 16% of IOF on the income). Amount of IOF to be paid: 16% = 0.16 x BRL 156.00 = BRL 24.96 If redemption is made from the 30th day of the investment, IOF is exempted on the income.
Calculation of Income Tax on Gross Income While calculating Income Tax on gross income, the tax is collected by the manager of the investment fund. Collecting always occurs on the last working day of the current month or at redemption, whichever is first. If redemption is not made on the last working day of the month, the manager automatically debits its balance in quotas, equivalent to the tax amount due in the current month. In case of a fixed income fund, the tax rate is 20% on gross income, which must be paid to the Internal Revenue Service. The IOF due is already deducted from the gross income if the redemption is effected within 30 consecutive days period. Thus, the IR amount to be collected without IOF levy (redemption period starting from the 30th day after the investment) is: $ 156.00 x 20% = 0.20 = $ 31.20 If there is no redemption till the end of the month, the balance of quotas on the last working day of the month is reduced as follows: $ 31.20 divided by $ 1.283459 (quota of the last working day of the month) = 24.309308 quotas.
IOF Levy Consider a redemption on the 25th day shall levy IOF of $ 24.96 and, in addition, IRF: IRF = (156.00 - 24.96) = $ 131.04 multiplied by 20% = $ 26.21 To demonstrate the calculation method of final income and the net profitability of applicable taxes, redemption on the 25th day after investment is considered, with levy of IOF and IR. Note: If the calculated IOF is during allocation (Virtual IOF), its value is added to the income of the following month because it was only used not to calculate IR on IOF in the first month and not to calculate a lower income and a lower IR in the following month.
Profitability Calculation a) Net Income Gross Income – IOF – IR = BRL 156.00 – BRL 24.96 – BRL 26.21 = BRL 104.83 b) Net Profitability Net income divided by the initial amount invested x 100 = BRL 104.83 / BRL 10,000.00 = 1.05%, in a period of 25 consecutive days. In the following month, the investment will be calculated using the quota of the last working day of the previous month and the quota of the allocation date. | Informações |
|---|
| The quota amount on the last working day of the previous month must be entered in the Banking Contracts file, option Update Quotation. Quota amounts are updated after running the Monthly Allocation routine. However, if you have deleted the quota amount, then enter it manually through this option. During redemption, as well as in monthly allocation, this file is updated with the amount of the quota entered during redemption or allocation. |
CDI Investments The calculation of the variation in CDI accrued between periods is performed according to the following formula: 
C = result of the rates DI-CETIP Over using the percentage from the initial date (inclusive) up to the end date (exclusive), calculated with the rounding of 8 (eight) decimal places. n = total number of rates DI-CETIP Over, where n is an integer number. p = percentage for payment, with 4 (four) decimal places. TDIk = Rate DI-CETIP Over, expressed in days, calculated with the rounding of 8 (eight) decimal places. For CDI rates published up to 12/31/97, the formula DI-CETIP Over must be used: k = 1, 2, ..., n Example: Percentage for payment: 97.5000. | K | DI | TDI (DI/3000) | TDI * (P/100) | (1+TDI * (P/100)) * k-1 = Factor k |
|---|
| 1 | 16.62 | 0.00554000 | 0.00540150 | 1.00540150 | | 2 | 16.63 | 0.00554333 | 0,00540475 | 1.01083544 | | 3 | 16.74 | 0.00558000 | 0.00544050 | 1.01633489 | | 4 | 16.70 | 0.00556667 | 0.00542750 | 1.02185105 |
k-1 = (1+TDI * (p/100) of k -1, except when k=1, once the multiplier is 1. | Informações |
|---|
| This formula was used to calculate the variation because the DI-CETIP Over rate was published until 12/31/1997 on a monthly basis, however, if even after that date the rate continues to be registered with SM2 on a monthly basis, it is necessary to use the MV_BASECDI parameter so that the system calculates the income properly. |
For the CDI rates published after 1/1/98, the formula must be: 
k = 1, 2, ..., n Example: Percentage for payment: 97.5000. | K | DI | TDI (DI/3000) | TDI (DI/3000) | (1+TDI * (P/100)) * k-1 = Factor k |
|---|
| 1 | 16.62 | 0.00061031 | 0.00059505 | 1.000580174 | | 2 | 16.63 | 0.00061065 | 0.00059538 | 1.001161008 | | 3 | 16.74 | 0.00061439 | 0.00059903 | 1.001745742 | | 4 | 16.70 | 0.00061303 | 0.00059770 | 1.002329521 |
When multiplying k by CDI balance, the updated value is presented (includes interests). The interest is due to the subtraction of the updated value balance. |
| Card |
|---|
| default | true |
|---|
| id | 6 |
|---|
| label | Printers |
|---|
| The Financial module uses two different mechanisms to print checks: SIGALOJA.DLL: developed by the Commercial Automation team, this mechanism is responsible for the communication between the system and the check printer.
| Informações |
|---|
| DLL facilitates the communication between the system and the equipment, and requires internal technology development. To print checks using these options, keep the Store Control \Smart Client DLL up to date, as well as the manufacturer's drivers. The system does not automatically install the DLL when Active X is in use, therefore, you cannot use the printers. |
Print direct in port: Financial sends all commands to the serial port (COM?) or the parallel port (LPT?) without going through the DLL in the Store Control module. To test printing in the ports, use the Check Printing routine of the Financial module. By using the system to print, a list is displayed containing similar printer names. Each printer uses different communication methods. In most cases, check printers use the communication via serial port (COM?). Some printers allow the computer to use a parallel port (LPT?), and there are also those that accept both types of connection (one cable for each port). The system sends basic check data to the printer, such as: - Code of bank.
- Name of beneficiary.
- Value of check.
- Issuing Municipality.
- Check issue date.
The printer already has settings for the check models from the different banks (recorded in an integrated circuit in the memory). For further information on adding/editing such configurations, check the printer manual. | Informações |
|---|
| For printers that receive direct command on the serial port (COM?) of the Financial module, note that: to print checks through these options, neither specific configuration nor intermediate files, such as DLL and drivers, is required. |
Some hardware have both fiscal printer and check printer. These printers can either use the printing mechanism with the Store Control DLL or print directly on the port. The printers table is updated whenever new approvals occur and/or the technology changes. All check printers that use the printing mechanism supported by the Store Control DLL must have their functionality activated in the Financial module, thus, some specific Financial parameters are configured. The system standard considers the printing mechanism directly on the port, however, there are exceptions for the Bematech and Olivetti PR-45 printers, as they have specific documentation that contains the operation description. For XTP and DATAREGIS printers, printing routines are available only in the operating system DOS 2.06 and 2.07. To print the year with four digits on check printers, the MV_CHEQ4DG parameter indicates whether the system should send the four digits to the printer, the default being N (sends only 2 digits). |
| Card |
|---|
| The Financial module has some functions for integration with the Excel spreadsheet: Extenso() Extenso(nNumToExt,lQuantid,nMoeda,cPrefixo,cIdioma,lCent,lFrac) It generates the numeric value written in full. | Informações |
|---|
| Parameters: nNumToExt: Value to be generated in words. lQuantid: It determines whether the full written mode will be in value or quantity (default = .F.). nMoeda: It identifies the description of the currency obtained in the MV_MOEDAx parameter. cPrefixo: Alternative prefix. If specified, it prefixes the return of the value in words, so the currency unit is not returned (default = ""). cIdioma: It specifies the language in which the value in words must be returned (1=Port,2=Spa,3=Eng). The default is the System language. lCent: It specifies whether the function must return the cents; .T. is default. lFrac: It specifies if the cents must be returned in fraction mode (it is executed only when cIdioma=English). |
FinNatOrc() FinNatOrc(cNatureza,cMes,nMoeda,nAno) It returns the quoted value of the class. | Informações |
|---|
| Parameters: cNatureza: Class to be searched. cMes: Month for calculation. nMoeda: Outflow currency. nAno: Year for calculation. |
FinNatPrv() FinNatPrv(cNatureza,dDataIni,dDataFim,nMoeda,nTipoData,lConsDtBas,lConsProvis) Returns the estimated value of the class within the desired period. | Informações |
|---|
| Parameters: cNatureza: Desired class. dDataIni: Start date for issuing or actual due date of bills, according to parameter nTipoData. dDataFim: End date for issuing or actual due date of bills. nMoeda: In which currency the values are returned. nTipoData: Type of date used to search bills: 1=Issue Date; 2=Actual Due Date. lConsDtBas: it indicates whether the balance is returned in the system database, disregarding posts made after this date, or whether the balance is returned regardless of the database. lConsProvis: it indicates whether the values of the provisional bills should be considered. |
FinNatRea() FinNatRea(cNatureza,dDataIni,dDataFim,nMoeda,lMovBco,cTipoDat) Returns the class accomplished value. | Informações |
|---|
| Parameters: cNatureza: Desired class. dDataIni: start date of input or posting movement, according to parameter cDatType. dDataFim: end date of input or posting movement, according to parameter cDatType. nMoeda: it indicates the currency in which the values are returned. lMovBco: 0=indicates that posts that do not move bank balance must not be consolidated; 1=indicates that posts that do not move the bank balance must be consolidated. cTipoDat: date to be used within the period entered in dDataIni and dDataFim: DG = input date and DT = transaction date. |
RecMoeda() RecMoeda(dData,cMoeda) It returns the exchange rate of a currency on a given date. | Informações |
|---|
| Parameters: dData: Desired date for quotation. cMoeda: Code of the desidered currency. |
SldBco() SldBco(cBanco,cAgencia,cConta,dData,nMoeda,lLimite) Returns bank balance as on a date. | Informações |
|---|
| Parameters: cBanco: Bank code (blank; all). cAgencia: Branch code (blank; all). cConta: Checking account code (blank; all). dData: Balance date. nMoeda: Code of the currency for the balance. lLimite: it defines whether the check overdraft limit is considered to compose the balance (.T. = Consider; .F. = Do not consider). |
SldReceber() SldReceber(dData,nMoeda,lDtAnterior,lMovSE5) It returns the balance receivable on a given date. | Informações |
|---|
| Parameters: dData: Balance date. nMoeda: Code of the currency for the balance. lDtAnterior: it indicates whether to report the balance up to the date entered, or only the balance on the date entered in dData. lMovSE5: it indicates whether to consider only pending balance or posted balances as well (.T. = Consider posted balance; .F. = Do not consider posted balance). |
SldPagar() SldPagar(dData,nMoeda,lDtAnterior,lMovSe5) It returns the balance payable on a given date. | Informações |
|---|
| Parameters: dData: Balance date. nMoeda: Code of the currency for the balance. lDtAnterior: it indicates whether to report the balance up to the date entered, or only the balance on the date entered in dData. lMovSE5: it indicates whether to consider only pending balance or posted balances as well (.T. = Consider posted balance; .F. = Do not consider posted balance). |
VlrCliente VlrCliente(cCliLoja,dDtIni,dDtFin,nMoeda,lConsAbat,lConsAcresc,lConsDecresc) Returns the value of the customer's bills during a period. | Informações |
|---|
| Parameters: cCliLoja: Customer code, including the store. dDtIni: Start date for issuing the customer's bills. dDtFin: End date for issuing the customer's bills. nMoeda: Currency intended for the values. lConsAbat: It indicates whether discount bills should be considered for composing the bill amounts. lConsAcresc: It indicates whether the increments in the customer's bills should be considered. lConsDecresc: It indicates whether the deductions in the customer's bills should be considered. |
VlrFornece VlrFornece(cForLoja,dDtIni,dDtFin,nMoeda,lConsAbat,lConsAcresc,lConsDecresc) Returns the value of the supplier's bills during a period. | Informações |
|---|
| Parameters: cForLoja: Supplier code, including the store. dDtIni: Start date for issuing the supplier's bills. dDtFin: End date for issuing the supplier's bills. nMoeda: Currency intended for the values. lConsAbat: It indicates whether discount bills should be considered for composing the bill amounts. lConsAcresc: It indicates whether the increments in the supplier's bills should be considered. lConsDecresc: It indicates whether the deductions in the supplier's bills should be considered. |
SldCliente() SldCliente(cCliLoja,dData,nMoeda,lMovSE5) It returns the balance receivable from the customer on a given date. | Informações |
|---|
| Parameters: cCliLoja: Customer code, including the store. dData: Balance date. nMoeda: Code of the currency for the balance. lMovSE5: it indicates whether to consider only pending balance or posted balances as well (.T. = Consider posted balance; .F. = Do not consider posted balance). |
SldFornece() SldFornece(cForLoja,dData,nMoeda,lMovSE5) It returns the balance payable to the supplier on a given date. | Informações |
|---|
| Parameters: cCliLoja: Customer code, including store. dData: Balance date. nMoeda: Code of currency for the balance. lMovSE5: it indicates whether to consider only pending balance or posted balances as well (.T. = Consider posted balance; .F. = Do not consider posted balance). |
Media() Media(nMoeda, nMes, nAno) It returns the average rate of a currency in a given month/year. | Informações |
|---|
| Parameters: nMoeda: Currency code. nMes: Desired month. nAno: Desired year. |
xMoeda xMoeda(nValor,nMoedp,nMoedd,dData,nDecimal,nTaxap,nTaxad) Converts the amounts between currencies. | Informações |
|---|
| Parameters: nValor: Value to convert. nMoedp: Source currency. nMoedd: Target currency. dData: Date of target currency rate. nDecimal: Number of decimal places. nTaxap: Source currency rate. nTaxad: Target currency rate. |
|
| Card |
|---|
| default | true |
|---|
| id | 8 |
|---|
| label | Integrations |
|---|
| | Integration between Material and Financial modules |
|---|
While implementing the Material module, set the work model of the Financial module. The main criteria are: - Method of accessing to tables (shared or exclusive).
- Financial class.
- Bill prefixes.
- Bill installments.
For this, it is important to observe how the integrations are carried out between them and, as an example, input and output documents are used, because they are integrated into the Financial module through the generation of receivable and payable bills. In this case, the following parameters are used: - MV_1DUPPREF: Bill prefix for outbound document.
- MV_2DUPPREF: Bill prefix for inbound document.
- MV_1DUPNAT: Bill class for outbound document.
- MV_2DUPNAT: Bill class for inbound document.
- MV_1DUP: Number of the first installment of the financial bill.
Accounts Payable The primary key of the accounts payable bill is composed of the following fields: PREFIX + NUMBER + INSTALLMENT + TYPE + SUPPLIER + STORE They must be completed as follows: - Prefix: as defined in parameter MV_2DUPPREF.
- Number: is established by the number of the inbound document.
- Installment: is established by the parameter MV_1DUP for installment purchases. For cash purchases, the installment is not filled in.
- Type: is determined by the Bill Types Table (SES), and in the initial configuration of the system, it is defined as NF. It is worth mentioning that only one type of bill is allowed for the generation of these documents and, once defined, it cannot be changed by the Bill Type Maintenance routine, nor be used for manual inclusion of bills in the Financial module, that is, this type of bill should only be used for integration.
Supplier/Store: are filled in with the supplier/store data of the inbound document. | Informações |
|---|
| The Financial Class is not part of the primary key of the accounts payable bill, but since it is required information, it must always be filled out. |
Accounts Receivable The primary key of the accounts receivable bill is composed of fields: PREFIX + NUMBER + INSTALLMENT + TYPE They must be completed as follows: - Prefix: as defined by parameter MV_1DUPPREF.
- Number: is determined by the number of the outbound document.
- Installment: is established by the parameter MV_1DUP for installment purchases. For cash purchases, the installment is not filled in.
- Type: is determined by the Bill Types Table (SES), and in the initial configuration of the system, it is defined as NF. It is worth mentioning that only one type of bill is allowed for the generation of these documents and, once defined, it cannot be changed by the Bill Type Maintenance routine, nor be used for manual inclusion of bills in the Financial module, that is, this type of bill should only be used for integration.
| Informações |
|---|
| The Financial Class is not part of the primary key of the accounts payable bill, but since it is required information, it must always be filled out. |
This way, it is possible to perceive the importance of defining the MV_1DUP parameter for the perfect completion of bill terms and of the MV_1DUPNAT and MV_2DUPNAT parameters for entering and using the Financial Classes. The parameters MV_1DUPPREF and MV_2DUPPREF are equally important in relation to the others mentioned, because they make it possible to change the primary key of financial bills after saving. Example: Assuming that the tables in the Financial module are shared and the Materials tables are exclusive. As the prefix can be changed after the table is saved, you cannot be sure the financial bills are not duplicated if you do not change these parameters when you define the access method to the tables of the Financial module. Thus, if the method of sharing of the Financial module is changed, it is necessary to ensure, through parameters MV_1DUPPREF and MV_2DUPPREF, that there is no duplication of the primary key of their tables. Parameter MV_1DUPPREF filled out with: ExecBlock('1DUPPREF',.F.,.F.). User Function creation: User Function 1DupPref() Local aArea : GetArea() Local aAreaSE1: SE1->(GetArea()) Local cPrefixo : SubStr(AllTrim(xFilial('SF2')+SE1->E1_SERIE),1,3) dbSelectArea('SE1') dbSetOrder(1) While MsSeek(xFilial('SE1')+cPrefixo+SE1->E1_NUM+SE1->E1_PARCELA+SE1->E1_TIPO) .And. aAreaSE1[3] <> SE1->(RecNo()) cPrefixo : Soma1(cPrefixo) EndDo RestArea(aAreaSE1) RestArea(aArea) Return(cPrefixo) | Informações |
|---|
| If the access method defined by TOTVS® is used, there is no need to change the parameters MV_1DUPPREF and MV_2DUPPREF. |
|
| Integration between HR and Financial modules |
|---|
When the totalizer is generated for HR, concerning data of block F100 of SPED PIS/COFINS, a file is generated to check data in the SYSTEM folder. File name: FIN + Branch Code (if the table is exclusive) + DES + Reference Month and Year + .DBF Layout: BRANCH + PREFIX + NUMBER + INSTALLMENT + TYPE + CUSTOMER + STORE + DATE + CLASS + VALUE + TABLE Example: Example of name of the file generated for August, 2015 from branch 01: FIN01DES082015.DBF |
| Integration between Purchase and Financial modules |
|---|
This integration includes meeting the legislation dedicated to ISSQN Withholding in the municipality of São Bernardo do Campo. The system calculates withholding on bills when the entry of service inbound documents is carried out through the Purchase module. - Recipients: companies that acquire services in the city of São Bernardo do Campo - SP.
- Goal: it refers to the responsibility of service takers, settled in the city of São Bernardo do Campo/ SP, except for individuals, by the payment of withheld ISS on services hired.
- Reference: Municipal – São Bernardo do Campo – São Paulo.
- Legislation contemplated: Municipal Law no. 1802, dated December 26, 1969 (and subsequent amendments).
- Other information: City of São Bernardo do Campo.
In this case, the following criteria must be considered: - The MV_VBASISS parameter indicates the base value not to withhold taxes, which according to the current legislation is BRL 5,620.50. Bills priced over this value will withhold taxes.
- The MV_MODRISS parameter controls the method of ISS withholding, which may be per bill, per month (regular) or per base.
- The field E2_VRETISS stores the value of tax withholding.
- The field E2_VBASISS presents the accrued ISS value withheld on bills in the month.
- The field F4_RETISS determines whether the transaction should withhold ISS.
Configuration of specific fields of table SE4: - Table: SE2
- Field: E2_VRETISS
- Type: numeric
- Description: ISS value withheld
- Size: 15
- Decimal: 2
- Format: @E 999,999,999,999.99
- Context: Real
- Property: view
- Table: SE2
- Field: E2_VBASISS
- Type: numeric
- Description: value of services accrued in the month
- Size: 15
- Decimal: 2
- Format: @E 999,999,999,999.99
- Context: Real
Property: view
| Informações |
|---|
| Fields E2_VRETISS and E2_VBASISS are for system control and should not be edited. |
- Table: SE2
- Field: E2_MDRTISS
- Type: character
- Description: ISS withholding mode
- Size: 1
- Decimal: 0
- Format: @!
- Options: 1 - Regular (always apportioning the ISS value; regardless of the bill value) / 2 - Per base (only withholds the ISS value when the value exceeds that contained in the MV_VBASISS parameter, according to legislation).
| Informações |
|---|
| This field meets the same systematics implemented in the addition of Service Invoices of the Purchase module (pursuant to legislation). If this field is already part of the dictionary/database, you must only enable it. |
Configuration of Specific Fields of Table SE4: - Table: SE4
- Field: F4_RETISS
- Type: character
- Description: withhold ISS
- Size: 1
- Decimal: 0
- Format: @!
- Options: 1 - Yes (system default) / 2 - No.
| Informações |
|---|
| When this field is blank, the default is considered, that is, Yes. |
|
|
|
