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 of Smart TIO file can be accessed through the Smart TIO Routine (MATA089.PRW), in the menu 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:

Field	Description
FM_CLIENTE	Customer Code
FM_LOJACLI	Customer Store
FM_FORNECE	Supplier Code
FM_LOJAFOR	Supplier Store
FM_EST	State
FM_GRTRIB	Taxation Group
FM_PRODUTO	Product Code
FM_GRPROD	Product Taxation Group
FM_POSIPI	Product NCM
FM_REFGRD	Grid Reference Code
FM_TIPOMOV	Sales Order Type
FM_GRPTI	Smart TIO Group
FM_TIPOCLI	Customer Type
FM_GRPCST	IPI Framing Code
FM_CFO_O	Tax transaction outflow code
FM_CFO_I	Tax transaction inflow code
FM_TPCTO	Contract Type
FM_ID	Identification of the rule
FM_ORIGEM	Product Source

Tip!

For Smart TIO registrations that do not have defined rules, the system will consider the record of a generic Smart TIO. In other words, it will use the record where only the fields Operation Type and Inflow/Outflow TIO are filled in.If you have more than one generic record for the same type of operation, the system will return the first record within the type of operation entered according to the order: FM_FILIAL + FM_TIPO + FM_PRODUTO + FM_CLIENTE + FM_LOJACLI + FM_ID
The FM_REFGRD field has Product Grid Reference information, and the FM_DESREF field will have the description of the reference selected in the FM_ REFGRD field.
The FM_GRPTI field has the code of the Smart TIO Group, which can be entered in the Product record using the B1_ GRPTI field.
The FM_ORIGEM field ("Product Source") is only enabled if the MV_A410OPE parameter is set to T. and for products that have bound Batch and Sub-Batch.
The FM_TIPOMOV field will be applied only in the outgoing operation taking into account the type of transaction reported in the Sales Order (C6_TIPO).

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:

Via configurator, check the creation of the generic table "ZV - Smart TIO Group";
This table already has a default group (0001). If necessary, add one or more;
In the products file, link the registered group to a product;
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);
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.
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.
Important!
To use this feature, the sharing of tables SF4 and SFM must be the same (exclusive or shared mode), so, when setting the TIO code that will be presented according to the rules met by the document included, it is identified within the branch defined in the two routines when exclusive, or in all files if shared. In cases where sharing between these two tables is different, it will not be possible to evaluate the rules already registered correctly, and a TIO code may be set up incorrectly.
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:

Type of Transaction	Outflow TIO	State	Customer Type
01	500	SP	F-Final Cons.

When there is a tax document bookkeeping with type of transaction 1 for the State of Sao Paulo using 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:

Type of Transaction	Outflow TIO	Product Code
01	501	AAAA

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.
Additional Information
The Customer Type field will be checked only for operations linked to a customer. If the invoice is linked to a Supplier, the Customer Type field will not be considered to frame the rule. To frame the participant, the FM_CLIENTE+FM_LOJACLI fields will only be checked if operations are linked to a Customer. If the operation is linked to a Supplier, then the FM_FORNECE+ FM_LOJAFOR fields are considered to frame the participant.

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:

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 the Customer 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.
Important!
The combination of the CLIENTE+LOJA fields will be considered only as framed information, as well as the combination of FORNECEDOR+LOJA fields.

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

Type of Transaction	TIO	Product
02	502	BBBB

Rule number 4

Type of Transaction	TIO	Customer
02	503	CCCC

In an operation of simple shipment of material to 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, and 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

Field	Description	Identification code
FM_PRODUTO	Product Code	1
FM_GRPROD	Product Taxation Group	2
FM_POSIPI	NCM	3
FM_CLIENTE+FM_LOJACLI	Customer+Customer Store	4
FM_GRTRIB	Taxation Group	5
FM_EST	State	6
FM_REFGRD	Grid Reference Code	7
FM_GRPTI	Smart TIO Group	8
FM_TIPOCLI	Customer Type	9
FM_GRPCST	IPI Framing Code	10
FM_TIPOMOV	Type of transaction of the sales order	11
FM_ORIGEM	Product Source	12

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

Field	Description	Identification code
FM_PRODUTO	Product Code	1
FM_GRPROD	Product Taxation Group	2
FM_POSIPI	NCM	3
FM_FORNECE+FM_LOJAFOR	Supplier+Supplier Store	4
FM_GRTRIB	Taxation Group	5
FM_EST	State	6
FM_REFGRD	Grid Reference Code	7
FM_GRPTI	Smart TIO Group	8
FM_GRPCST	IPI Framing Code	9
FM_ORIGEM	Product Source	10

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 contents 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:

Table	Table Title	Trigger Field	Parameters
SC6	Sales Order Items	C6_OPER	C5_CLIENT, C5_LOJAENT, C6_PRODUTO, C6_TES
SC7	Purchase Req. / Delivery Aut.	C7_OPER	C7_OPER, C7_FORNECE, C7_LOJA, C7_PRODUTO, C7_TES
SCK	Quotation Items	CK_OPER	CK_OPER, CJ_CLIENTE, CJ_LOJA, CK_PRODUTO, CK_TES, CJ_TIPOCLI
SCY	Purchase Order History	CY_OPER	CY_OPER, C7_FORNECE, C7_LOJA, CY_PRODUTO, CY_TES
SD1	Incoming Invoice Items	D1_OPER	D1_OPER, C7_FORNECE, C7_LOJA, D1_COD, D1_TES, F1_EST
SUB	Telesales Budget Items	UB_OPER	UA_CLIENTE, UA_LOJA, UB_PRODUTO, UB_TES, UA_TIPOCLI
VVA	Vehicle Departure Items	VVA_OPER	VVA_OPER, VV0_CODCLI, VV0_LOJA, (VVA_CHAINT or VV1_CHAINT)
VVG	Vehicle Arrival Items	VVG_OPER	VVG_OPER, VVF_CODFOR, VVF_LOJA, (VVG_CHAINT or VV1_CHASSI)
DBJ	Purchase Center Parameters	DBJ_TPOPER	DBJ_TPOPER

Important!
All fields that participate in the desired rule (fields that are in the "Parameters" column in the table above) must be filled in before the field that triggers the rule (Field found in the "Trigger Field " column of the table above), so that the rule is loaded correctly.
If it is necessary to change any field that is a parameter with the intention that another rule is selected, it is also necessary to delete and populate the Trigger field again so that the rule is loaded correctly.

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.

If entry point MT089CD exists in the environment, the system tie-breaker rules will not be applied, and the return of the entry point will define which TIO will be suggested considering the existing customizations.