Páginas filhas
  • Integration with Material (Financial Process Script - SIGAFIN)

Integration between Material and Financials

While deploying the Material module, the work model of Financials module must be defined. The main points to be observed are:

  • Mode of accessing the tables (shared or exclusive);
  • Financial class
  • Bill prefixes
  • Bill installments

The definition of these points is very important for the successful deployment of Material module integrated with Financials.

To better understand these points, it is important to note how the integration between these modules is accomplished. Inbound and outbound documents are used as examples.

These documents are integrated with Financials through generation of Bills Receivable and Payable.

To generate these bills, the following parameters are used:

  • MV_1DUPPREF - Bill prefix for the outbound document.
  • MV_2DUPPREF - Bill prefix for the inbound document.
  • MV_1DUPNAT - Bill class for the outbound document.
  • MV_2DUPNAT - Bill class for the inbound document.
  • MV_1DUP - Number of the first installment of the financial bill.



ACCOUNTS PAYABLE

The primary key of the accounts payable bill is made up by:

PREFIX + NUMBER + INSTALLMENT + TYPE + SUPPLIER + STORE

Note how these primary key fields of the table are filled out:

  • Prefix - as defined in parameter MV_2DUPPREF.
  • Number - Established by the number of the inbound document.
  • Installment - Established by the MV_1DUP parameter for installment purchases. For cash purchases, the installment is not filled out.
  • Type - Determined by the Types of Bills (SES) table. During the initial system configuration, it is defined as NF. It must be highlighted that only one type of bill is allowed for generating these documents and, once defined, it cannot be changed by the Types of Bills Maintenance routine and cannot be used to manually add bills in the Financials module; that is, this type of bill can be used only for integration.
  • Supplier/Store - are filled out with the supplier/store data of the inbound document.

Tip:

Note that 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:

PREFIX + NUMBER + INSTALLMENT + TYPE

Note how these primary key fields of the table are filled out:

  • Prefix - as defined in parameter MV_1DUPPREF.
  • Number - Established by the number of the outbound document.
  • Installment - Established by the MV_1DUP parameter for installment purchases. For cash purchases, the installment is not filled out.
  • Type - Determined by the Types of Bills (SES) table. During the initial system configuration, it is defined as NF. It must be highlighted that only one type of bill is allowed for generating these documents and, once it is defined, it cannot be changed by the maintenance routine of Types of Bills, and cannot be used for manual addition of bills in the Financial environment, which means, this type of bill can be used only for integration.


Tip:

Note that 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.


Thus, you can understand the importance of defining the MV_1DUP parameter for correctly filling out term bills and of parameters MV_1DUPNAT and MV_2DUPNAT, for filling out and using Financial Classes.

Parameters MV_1DUPPREF and MV_2DUPPREF are extremely important for the integrity of the Financial module, which allows you to change the primary key of financial bills after saving.



Practical Application

For example, suppose that the tables in Financials are shared and those of Material 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 Financials module.


In short, if you change the method of sharing the Financials module, make sure that, through parameters MV_1DUPPREF/MV_2DUPPREF, no duplication of the primary key occurs in its tables, as shown in the example:

  1. The MV_1DUPPREF parameter is filled out as: ExecBlock('1DUPPREF',.F.,.F.).
  2. The following User Function is created:

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)


Note:


If you use the access method defined by TOTVS®, you do not need to change parameters MV_1DUPPREF and MV_2DUPPREF.