TESINT - Smart TIO - Tax Management - P12

01. OVERVIEW

The Smart TIO registration is available with the goal of facilitating and speeding up the filling of the TIO code (Type of Inflow and Outflow) in the tax documents considering rules previously registered. The advantage of using this routine is that we can configure which TIO codes will be used in certain tax documents.

02. EXAMPLE OF USE

The registration of Smart TIO can be accessed through the Smart TIO Routine (MATA089.PRW), in the menu Files Updates\Files\Smart TIO of the SIGAFIS module.

The registration of TIO code completion rules is linked to a transaction type code (FM_TYPE), for example: 01 - Sale of goods,02 - Simple shipment of material, 03 - Sale for final consumer etc.
Transaction type codes are registered in the DJ table of SX5, in generic tables. Each rule defined may have an outflow TIO code (FM_TS) and/or an inflow TIO code (FM_TE).

Once the type of transaction and TIO to be used is set in the rule, you will need to fill in the other fields listed below: 

In order to be able to register more specific rules, the Smart TIO Group (FM_GRPTI) and Customer Type (FM_TIPOCLI) fields are available. To use them, follow these steps:

1. Via configurator, check the creation of the generic table "ZV - Smart TIO Group";
2. This table already has a default group (0001). If necessary, add one or more;
3. In the products file, link the registered group to a product;
4. In the registration of Smart TIO rules, include one or more rules by filling in the fields of "Group-TI" (FM_GRPTI) and/or "Customer Type" (FM_TIPOCLI);
5. In the Billing module, add a sale order and use the product, the customer, and the type of transaction registered in the rule(s) above.
6. Verify that the TIO will be filled in the item according to the registered rule.

All or some fields of the rule can be filled in, varying according to the customer's need. The TIO of the rule that has information that fits with the tax document will always be suggested. If any information of the rule does not fit with the tax document, this rule will be discarded. A rule having empty fields will not be discarded, provided that the other fields entered fit with the tax document.

To exemplify the filling in, let's assume the creation of a rule to suggest the TIO code 500 in sale of goods to Final Consumer in the State of Sao Paulo. We must fill in the Smart TIO rule as follows:

Rule number 1:

When there is a tax document bookkeeping with type of transaction 1 for the State of Sao Paulousing customer classified as Final Consumer, TIO 500 will be suggested in the bookkeeping of the tax document.

Let's look at another example,Sale of Goods of the "AAAA" product, suggesting the TIO code 501.

Rule number 2:

With this rule, when a Sale of Goods of Product"AAAA" is booked, TIO 501 will be suggested when entering the invoice.

The rules will be registered according to the segment and the need of each customer, and can create more specific or more generic rules.

03. TIO SUGGESTION CRITERIA

 Specific x Generic

As the rules are registered, it is possible that there are more generic rules which may conflict with some more specific rule, as in the examples mentioned in item 02. We will consider the following scenario: 

1. Tax document for Sale of Goods for Final Consumer in the State of Sao Paulo, selling the product code "AAAA".

At first, the two rules would fit this situation, because both rules meet and fit in the information of the tax document in question, but the routine can suggest only one TIO. To solve this conflict, the criterion adopted will be to consider the rule that has more information framed according to the tax document.

In the example of item 02 of this document, Rule 1 has two framed information, the State and theCustomer Type, whereas Rule 2 has only one framed information, which is the Product Code. In this case, rule 1 has more information framed than rule 2, so TIO 500 will be suggested, as it is the most specific in the context of this tax document.

In this type of conflict, the suggested TIO will always be the one that belongs to the most specific rule, that is, the rule that has more information framed. 

Different rules with the same amount of information framed

There may also be conflict of different rules registered with different fields, but with the same amount of information framed with the tax document. Below is an example of this situation:

Rule number 3

Rule number 4 

In a simple operation of material shipping to the Customer "CCCC" moving product "BBBB", rules 3 and 4 fall within the tax document, rule 3 framed the Product Code, and Rule 4 framed the Customer Code. Both have the same amount of information, both TIO 502 and 503 could be suggested. To solve this conflict, the system adopts the criterion of the order of more relevant/priority fields of the Smart TIO record. If the Product Code has greater relevance, then TIO 502 will be suggested; or, if the Customer Code has greater relevance, then TIO 503 will be suggested. The system has a default order of priorities, which can be changed by the customer if necessary.

To understand this order, each SFM field (excluding transaction type, inflow TIO, and outflow TIO) will have a fixed identifier, as follows:

SFM Field Identifiers - Operations with Customer

For Client-bound operations, the default system order is 1,2,3,4,5,6,7,8,9,10,11,12, where each number represents a field in the SFM table, i.e. the order of priority fields is:

FM_PRODUTO, FM_GRPROD, FM_POSIPI, FM_CLIENTE+FM_LOJACLI, FM_GRTRIB, FM_EST, FM_REFGRD, FM_GRPTI, FM_TIPOCLI, FM_GRPCST,FM_TIPOMOV.

Where the field with the highest priority/relevance is the first from left to right, and the field with the lowest priority/relevance is the last on the right.

SFM Field Identifiers - Operations with Supplier

For operations linked with Supplier, the default system order is 1,2,3,4,5,6,7,8,9,10, where each number represents a field in the SFM table, i.e. the order of priority fields is:

FM_PRODUTO, FM_GRPROD, FM_POSIPI, FM_FORNECE+FM_LOJAFOR, FM_GRTRIB, FM_EST, FM_REFGRD, FM_GRPTI, FM_GRPCST.

Where the field with the highest priority/relevance is the first from left to right, and the field with the lowest priority/relevance is the last on the right.

Returning to the example of rules 3 and 4 presented in this item, considering the standard order of the system, the suggested TIO would be the 502, because the Product (identification 1) has greater relevance/priority than the Customer + Store (identification 4): 1,2,3,4,5,6,7,8,9,10,11,12.

If it is necessary to change this order of fields, simply change the content of the MV_OTICLI parameter for operations with customers, and parameter MV_OTIFOR for operations with suppliers.

Also in this example, if we want to change the default priority order of the system, giving higher priority to the Customer instead of the product, we must fill in the MV_OTICLI parameter as follows: {4,1,2,3,5,6,7,8,9,10,11,12}.

Note that the Customer +Store Identifier(4) is the first of the order. In this case, the suggested TIO would be 503, as the Customer has greater relevance than the Product. The same procedure is valid for the MV_OTIFOR parameter for the operations linked to the supplier.

If, for any reason, the priority order of the fields defined by the customer does not break this rule conflict, the tie will be made in the default order of the system.

04. TRIGGERS FOR TIO DEFINITION

The TIO will be returned after filling in a given field depending on the operation being performed, such as issue of sale order, issue of purchase order, incoming invoice, etc. These fields can be viewed in the list below, as well as the fields that are used as parameters for defining the Smart TIO rule:

05. OTHER INFORMATION

Guidelines for completing rules

• The guidance in the Smart TIO file is to avoid creating duplicate rules, because these rules will not be met, and not TIO will be suggested in these situations;
• Analyze the priority and relevance of the Smart TIO file fields according to need, checking the parameters MV_OTICLI and MV_OTIFOR, because the order of the fields defined in these parameters will be considered to resolve possible rule conflicts (rules not duplicated);
• Note that the TIO will be suggested in the bookkeeping of the tax document by first considering the most specific Smart TIO rule criterion, and, in the event of a conflict of generic rules, the tiebreaker criterion will be in the order of the most priority fields;
• Whenever possible, register rules with more information, thus avoiding conflicts. Smart TIO records without defined rules will not be considered for application in the document. For example, if only fields FM_TIPO and FM_TS and/or FM_TE are entered, because the purpose of the routine is to filter the TIO file to meet specific rules, not just trigger a TIO code, which may cause negative impacts if no proper binding occurs.
• If a certain registered rule exists and the TIO is not suggested in the bookkeeping of the tax document, it may be because it is a duplicate rule, or because some information has not been framed with the tax document information.
• Duplicate rules will always be disregarded.