2 Backend System Administration and Configuration

This chapter is intended for administrators who provide support and monitor the running system.

The content in this chapter is not procedural. Instead, it is meant to provide descriptive overviews of the parameters and configurations of the system that come with the Retail Fiscal Management application.

Fiscal Data Management

Fiscal Data Management is the set of features under RFMCS that manages fiscal attribute creation and item/entity fiscal classification. The association of fiscal-related attributes to items and entities is required to support fiscal document generation, tax calculation, and fiscal reporting. Depending on country-specific requirements, a set of pre-defined attributes is made available along with RFMCS.

Note:

The association of any pre-defined attribute to its specific entity (items, locations, suppliers, and so on) will not be delivered as part of the RFMCS installation. This association or “fiscal classification” is part of implementation activities.

For the pre-defined attributes that require a list of values, the list will also be provided as part of the installation. However, some attributes have their list of values provided by governments or external entities. For customers to have the autonomy to keep these lists updated, the Fiscal Attributes List of Values are updated using Merchandising REST services. See Chapter 3, “Integration” for details.

The list of pre-defined attributes available in this release of RFMCS and the entity with which they are associated is described below. This list is not exhaustive, as it does not have all the configuration parameters for each attribute. These details are fetched from the application by calling the Fiscal Attributes Request Service. See Chapter 3, “Integration” for details.

Table 2-1 Pre-defined Fiscal Attributes for Brazil

CODE DESCRIPTION TEMPLATE MANDATORY SYSTEM BEHAVIOR FISCAL DOCUMENT USE TAX CALCULATION FISCAL REPORTING

FABRICACAO

Indicates if the item falls into one of the 2 categories for tax calculation purposes.

ITEM_LOC

N

    

Y

  

ORIG

Origin classification code for items (code defined by fiscal authority).

ITEM_LOC

N

  

Y

Y

Y

UF_FABRICACAO

Indicates the state where the product was manufactured.

ITEM_LOC

N

    

Y

  

N_FCI

FCI process code stored at item/location level for NF creation.

ITEM_LOC

N

  

Y

  

Y

GROUP_ITEMS_ST

This flag will make items be grouped while creating NFs.

ITEM_LOC

N

Y

      

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

ITEM_LOC

N

    

Y

  

CD_CLASSIFICACAO

Classification code for the item.

ITEM_MASTER

Y

    

Y

  

APLICACAO

Application purpose for the item.

ITEM_MASTER

Y

    

Y

  

FABRICACAO

Indicates if the item falls into one of the 2 categories for tax calculation purposes.

ITEM_MASTER

Y

    

Y

  

ORIG

Origin classification code for items (code defined by fiscal authority).

ITEM_MASTER

Y

  

Y

Y

Y

NCM

Item classification code (code defined for Mercosul trading zone).

ITEM_MASTER

Y

  

Y

Y

Y

EXNCM

Sublevel of the NCM code (internal code meant for tax rule conditions).

ITEM_MASTER

N

    

Y

  

CEST

Extension code associated to the NCM code. This code is meant to identify items that are under the ST regime. Used for NF creation and tax calculation.

ITEM_MASTER

N

  

Y

Y

Y

EXTIPI

Tax exception classification applied to IPI tax.

ITEM_MASTER

N

  

Y

Y

Y

UF_FABRICACAO

Indicates the state where the product was manufactured.

ITEM_MASTER

N

    

Y

  

IND_ESCALA

Item Produced at a relevant scale. Attribute required to be stored for NF creation.

ITEM_MASTER

C

  

Y

  

Y

CNPJ_FAB

Associated with attribute Produced at a relevant Scale to store data for NF creation.

ITEM_MASTER

C

  

Y

  

Y

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

ITEM_MASTER

N

    

Y

  

FABRICACAO

Indicates if the item falls into one of the 2 categories for tax calculation purposes.

ITEM_SUPPLIER

N

    

Y

  

ORIG

Origin classification code for items (code defined by fiscal authority).

ITEM_SUPPLIER

N

  

Y

Y

Y

UF_FABRICACAO

Indicates the state where the product was manufactured.

ITEM_SUPPLIER

N

    

Y

  

UN_FISCAL

Fiscal UOM. Used for when the NF UOM is different than RMS SUOM. Conversion created only in RFM.

ITEM_SUPPLIER

N

Y

      

FATOR_UN_FISCAL

Fiscal UOM conversion factor. Used for when the NF UOM is different than RMS SUOM. Conversion created only in RFM.

ITEM_SUPPLIER

N

Y

      

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

ITEM_SUPPLIER

N

    

Y

  

PESSOA_JURIDICA

Corporate taxpayer indicator.

LOCATION

Y

    

Y

Y

CONTROL_FISCAL_LEDGER

Location level definition for fiscal ledger control. If Yes, all NFs will be controled (in and out).

LOCATION

Y

Y

      

IE_ST_AC

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

CNPJ

Taxpayer ID for federal level tax authorities. Exclusive for corporate taxpayers.

LOCATION

C

  

Y

  

Y

DISCR_FISCAL_DOCUMENT

Location level indicator of fiscal or non-fiscal document generation in case of quantity discrepancy post physical receiving of goods. Attribute options are RNF (Return Fiscal Document) and NFD (Non-fiscal document/Credit note)

LOCATION

Y

Y

      

IE_ST_AL

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

CNAE

CNAE code (DB attribute for other entities). Activity identification code for companies.

LOCATION

Y

  

Y

Y

Y

DISCR_RESOLUTION_TYPE

Location level control for discrepancy resolution option.

LOCATION

Y

Y

      

IE_ST_AM

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

IND_IE

Indicates the type of State Inscription for the Recipient.

LOCATION

Y

  

Y

Y

Y

MATCH_LEVEL_COST

Indicates the level of the document that will be compared with the PO in POFDR Flow for Cost.

LOCATION

Y

Y

      

IE_ST_AP

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

IE

Number that represents the registration of the entity in the ICMS register.

LOCATION

C

  

Y

  

Y

MATCH_LEVEL_DISCOUNT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Discount.

LOCATION

Y

Y

      

IE_ST_BA

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

CRT

Define the taxpayer's taxation regime (Normal Regime or National Simples).

LOCATION

Y

  

Y

Y

Y

MATCH_LEVEL_FREIGHT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Freight.

LOCATION

Y

Y

      

IE_ST_CE

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

CRT_SIMPLES_ALIQ

Percentage rate in case the CRT equal SIMPLES Contributor.

LOCATION

C

  

Y

Y

Y

MATCH_LEVEL_INSURANCE

Indicates the level of the document that will be compared with the PO in POFDR Flow for Insurance.

LOCATION

Y

Y

      

IE_ST_DF

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

IM

Taxpayer ID for city level tax authorities.

LOCATION

N

  

Y

  

Y

MATCH_LEVEL_EXPENSES

Indicates the level of the document that will be compared with the PO in POFDR Flow for Expenses.

LOCATION

Y

Y

      

IE_ST_ES

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

I_SUF

Specific free zone taxpayer code for exemption purposes.

LOCATION

N

  

Y

  

Y

ST_BREAK_NF_IND

Indicates if the RTV must have ST tax in a separated NF. RFM behavior flag.

LOCATION

N

Y

      

IE_ST_GO

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

LOCATION

N

    

Y

  

ST_BALANCE_AVG_IND

Indicates the use of weighted average for the ST tax recovery calculation based on the fiscal ledger documents consumed.

LOCATION

N

Y

      

IE_ST_MA

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

LEDGER_BALANCE_METHOD

Ledger balance method (LIFO, FIFO) - Default LIFO.

LOCATION

N

Y

      

IE_ST_MG

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

NFE_MANIFEST_DAYS

Indicates the number of days to Manifest NFe Rejection.

LOCATION

N

Y

      

IE_ST_MS

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_COST

Indicates the percentage rate of tolerance to be applied in the comparison of item cost between NF and system.

LOCATION

N

Y

      

IE_ST_MT

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_COST

Indicates the value of tolerance to be applied in the comparison of item cost between NF and system.

LOCATION

N

Y

      

IE_ST_PA

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_DISCOUNT

Indicates the percentage rate of tolerance to be applied in the comparison of discounts between NF and system.

LOCATION

N

Y

      

IE_ST_PB

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_DISCOUNT

Indicates the value of tolerance to be applied in the comparison of discounts between NF and system.

LOCATION

N

Y

      

IE_ST_PE

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_FREIGHT

Indicates the percentage rate of tolerance to be applied in the comparison of freight cost between NF and system.

LOCATION

N

Y

      

IE_ST_PI

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_FREIGHT

Indicates the value of tolerance to be applied in the comparison of freight cost between NF and system.

LOCATION

N

Y

      

IE_ST_PR

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_INSURANCE

Indicates the percentage rate of tolerance to be applied in the comparison of insurance between NF and system.

LOCATION

N

Y

      

IE_ST_RJ

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_INSURANCE

Indicates the value of tolerance to be applied in the comparison of insurance between NF and system.

LOCATION

N

Y

      

IE_ST_RN

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_EXPENSES

Indicates the percentage rate of tolerance to be applied in the comparison of expenses between NF and system.

LOCATION

N

Y

      

IE_ST_RO

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_EXPENSES

Indicates the value of tolerance to be applied in the comparison of expenses between NF and system.

LOCATION

N

Y

      

IE_ST_RR

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

IE_ST_RS

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_TAX

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system.

LOCATION

N

    

Y

  

IE_ST_SC

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_TAX

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system.

LOCATION

N

    

Y

  

IE_ST_SE

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_RATE_TAX_RET

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

LOCATION

N

    

Y

  

IE_ST_SP

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

TOLERANCE_VALUE_TAX_RET

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

LOCATION

N

    

Y

  

MD_ARRED

Rounding Method for Tax Calculation.

LOCATION

N

    

Y

  

IE_ST_TO

State inscription as ST substitute (can be more than one depending on the state).

LOCATION

N

  

Y

  

Y

DEFAULT_MOD_FRETE

Indicates the Freight Method for NFe information.

LOCATION

N

Y

      

DEFAULT_TRANSP

Indicates the Default Carrier ID used in the NFe issued by Location.

LOCATION

N

Y

      

NFE_BREAK_ITEMS

Indicates the number of items to break a fiscal document request into multiple documents.

LOCATION

N

Y

      

ENABLE_FCI

Indicates if the tag "orig" for the item will be fetched from the referenced entry document and used in tax calculation integration for fiscal document generation.

LOCATION

N

Y

      

PESSOA_JURIDICA

Corporate taxpayer indicator.

PARTNER

Y

    

Y

Y

MATCH_LEVEL_COST

Indicates the level of the document that will be compared with the PO in POFDR Flow for Cost.

PARTNER

Y

Y

      

MATCH_LEVEL_DISCOUNT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Discount.

PARTNER

Y

Y

      

CNPJ

Taxpayer ID for federal level tax authorities. Exclusive for corporate taxpayers.

PARTNER

C

  

Y

  

Y

CPF

Taxpayer ID for federal level tax authorities. Exclusive for individual taxpayers.

PARTNER

C

  

Y

  

Y

MATCH_LEVEL_FREIGHT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Freight.

PARTNER

Y

Y

      

CNAE

CNAE code (DB attribute for other entities). Activity identification code for companies.

PARTNER

Y

  

Y

Y

Y

MATCH_LEVEL_INSURANCE

Indicates the level of the document that will be compared with the PO in POFDR Flow for Insurance.

PARTNER

Y

Y

      

MATCH_LEVEL_EXPENSES

Indicates the level of the document that will be compared with the PO in POFDR Flow for Expenses.

PARTNER

Y

Y

      

IND_IE

Indicates the type of State Inscription for the Recipient.

PARTNER

Y

  

Y

Y

Y

IE

Number that represents the registration of the entity in the ICMS register.

PARTNER

C

  

Y

  

Y

AUTO_SUBMIT_RECEIPT

Y/N indicator to automatically submit for physical receipt in case no discrepancy is found during NF validation.

PARTNER

N

Y

      

CRT

Define the taxpayer's taxation regime (Normal Regime or National Simples).

PARTNER

Y

  

Y

Y

Y

TOLERANCE_RATE_COST

Indicates the percentage rate of tolerance to be applied in the comparison of item cost between NF and system.

PARTNER

N

Y

      

CRT_SIMPLES_ALIQ

Percentage rate in case the CRT equal SIMPLES Contributor.

PARTNER

C

  

Y

Y

Y

TOLERANCE_VALUE_COST

Indicates the value of tolerance to be applied in the comparison of item cost between NF and system.

PARTNER

N

Y

      

IM

Taxpayer ID for city level tax authorities.

PARTNER

N

  

Y

  

Y

TOLERANCE_RATE_DISCOUNT

Indicates the percentage rate of tolerance to be applied in the comparison of discounts between NF and system.

PARTNER

N

Y

      

I_SUF

Specific free zone taxpayer code for exemption purposes.

PARTNER

N

  

Y

  

Y

TOLERANCE_VALUE_DISCOUNT

Indicates the value of tolerance to be applied in the comparison of discounts between NF and system.

PARTNER

N

Y

      

TOLERANCE_RATE_FREIGHT

Indicates the percentage rate of tolerance to be applied in the comparison of freight cost between NF and system.

PARTNER

N

Y

      

FABRICANTE_DISTRIBUIDOR

Information for special tax regimes.

PARTNER

N

    

Y

  

FAIXA_FATURAMENTO_ANUAL

Is income range eligible.

PARTNER

N

    

Y

  

TOLERANCE_VALUE_FREIGHT

Indicates the value of tolerance to be applied in the comparison of freight cost between NF and system.

PARTNER

N

Y

      

PRODUTOR_RURAL

Rural Producer indicator.

PARTNER

N

  

Y

Y

Y

TOLERANCE_RATE_INSURANCE

Indicates the percentage rate of tolerance to be applied in the comparison of insurance between NF and system.

PARTNER

N

Y

      

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

PARTNER

N

    

Y

  

TOLERANCE_VALUE_INSURANCE

Indicates the value of tolerance to be applied in the comparison of insurance between NF and system.

PARTNER

N

Y

      

TOLERANCE_RATE_EXPENSES

Indicates the percentage rate of tolerance to be applied in the comparison of expenses between NF and system.

PARTNER

N

Y

      

TOLERANCE_VALUE_EXPENSES

Indicates the value of tolerance to be applied in the comparison of expenses between NF and system.

PARTNER

N

Y

      

TOLERANCE_RATE_TAX

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system.

PARTNER

N

Y

      

TOLERANCE_VALUE_TAX

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system.

PARTNER

N

Y

      

TOLERANCE_RATE_TAX_RET

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

PARTNER

N

    

Y

  

TOLERANCE_VALUE_TAX_RET

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

PARTNER

N

    

Y

  
TP_ENTE_GOV Identifies the government entity involved in the purchase of products or services. PARTNER N Y Y

PESSOA_JURIDICA

Corporate taxpayer indicator.

SUPS

Y

    

Y

Y

MATCH_LEVEL_COST

Indicates the level of the document that will be compared with the PO in POFDR Flow for Cost.

SUPS

Y

Y

      

CNPJ

Taxpayer ID for federal level tax authorities. Exclusive for corporate taxpayers.

SUPS

C

  

Y

  

Y

MATCH_LEVEL_DISCOUNT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Discount.

SUPS

Y

Y

      

CPF

Taxpayer ID for federal level tax authorities. Exclusive for individual taxpayers.

SUPS

C

  

Y

  

Y

MATCH_LEVEL_FREIGHT

Indicates the level of the document that will be compared with the PO in POFDR Flow for Freight.

SUPS

Y

Y

      

CNAE

CNAE code (DB attribute for other entities). Activity identification code for companies.

SUPS

Y

  

Y

Y

Y

MATCH_LEVEL_INSURANCE

Indicates the level of the document that will be compared with the PO in POFDR Flow for Insurance.

SUPS

Y

Y

      

MATCH_LEVEL_EXPENSES

Indicates the level of the document that will be compared with the PO in POFDR Flow for Expenses.

SUPS

Y

Y

      

IND_IE

Indicates the type of State Inscription for the Recipient.

SUPS

Y

  

Y

Y

Y

AUTO_SUBMIT_RECEIPT

Y/N indicator to automatically submit for physical receipt in case no discrepancy is found during NF validation.

SUPS

N

Y

      

IE

Number that represents the registration of the entity in the ICMS register.

SUPS

C

  

Y

  

Y

TOLERANCE_RATE_COST

Indicates the percentage rate of tolerance to be applied in the comparison of item cost between NF and system.

SUPS

N

Y

      

CRT

Define the taxpayer's taxation regime (Normal Regime or National Simples).

SUPS

Y

  

Y

Y

Y

TOLERANCE_VALUE_COST

Indicates the value of tolerance to be applied in the comparison of item cost between NF and system.

SUPS

N

Y

      

CRT_SIMPLES_ALIQ

Percentage rate in case the CRT equal SIMPLES Contributor.

SUPS

C

  

Y

Y

Y

IM

Taxpayer ID for city level tax authorities.

SUPS

N

  

Y

  

Y

TOLERANCE_RATE_DISCOUNT

Indicates the percentage rate of tolerance to be applied in the comparison of discounts between NF and system.

SUPS

N

Y

      

TOLERANCE_VALUE_DISCOUNT

Indicates the value of tolerance to be applied in the comparison of discounts between NF and system.

SUPS

N

Y

      

I_SUF

Specific free zone taxpayer code for exemption purposes.

SUPS

N

  

Y

  

Y

TOLERANCE_RATE_FREIGHT

Indicates the percentage rate of tolerance to be applied in the comparison of freight cost between NF and system.

SUPS

N

Y

      

FABRICANTE_DISTRIBUIDOR

Information for special tax regimes.

SUPS

N

    

Y

  

TOLERANCE_VALUE_FREIGHT

Indicates the value of tolerance to be applied in the comparison of freight cost between NF and system.

SUPS

N

Y

      

FAIXA_FATURAMENTO_ANUAL

Is income range eligible.

SUPS

N

    

Y

  

TOLERANCE_RATE_INSURANCE

Indicates the percentage rate of tolerance to be applied in the comparison of insurance between NF and system.

SUPS

N

Y

      

PRODUTOR_RURAL

Rural Producer indicator.

SUPS

N

  

Y

Y

Y

TOLERANCE_VALUE_INSURANCE

Indicates the value of tolerance to be applied in the comparison of insurance between NF and system.

SUPS

N

Y

      

REGIME_DIF

Internal tax regime code kept in FDM_ATTRIB for tax calculation only.

SUPS

N

    

Y

  

CONTRIBUINTE_IPI

IPI Contributor indicator.

SUPS

N

    

Y

  

TOLERANCE_RATE_EXPENSES

Indicates the percentage rate of tolerance to be applied in the comparison of expenses between NF and system.

SUPS

N

Y

      

TOLERANCE_VALUE_EXPENSES

Indicates the value of tolerance to be applied in the comparison of expenses between NF and system.

SUPS

N

Y

      

TOLERANCE_RATE_TAX

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system.

SUPS

N

    

Y

  

TOLERANCE_VALUE_TAX

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system.

SUPS

N

    

Y

  

TOLERANCE_RATE_TAX_RET

Indicates the percentage rate of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

SUPS

N

    

Y

  

TOLERANCE_VALUE_TAX_RET

Indicates the value of tolerance to be applied in the comparison of taxes between NF and system for retained taxes.

SUPS

N

    

Y

  

DEFAULT_MOD_FRETE

Indicates the Freight Method for NFe information.

SUPS

N

Y

      
TP_ENTE_GOV Identifies the government entity involved in the purchase of products or services. SUPS N Y Y

Fiscal Documents Management

In RFMCS, the main objective is the management of fiscal documents and the support of fiscal document receiving and generation.

RFMCS and its fiscal document management capabilities introduces the concept of workflow-based development for which the processing of a transaction is based on a sequence of events configured for each country/transaction/document type combination. With this approach, the business rules applied to the transactions are kept separated from the workflow processing components. Each step executed returns the output of the execution, the messages generated, validations and errors. All of it is visible on the screen, which gives the user a complete view of what happens in the process flow.

Workflows are not configurable to users and are made available as part of the product. A workflow is defined by country, transaction, and document type.

POFDR: Purchase Order Fiscal Document Receive

  • Country: Brazil

  • Document Type: Brazilian NFe – Model 55

  • Overview: This workflow is meant to support the fiscal receiving of purchase orders that are associated with the Brazilian fiscal document “NFE”.

Table 2-2 POFDR Workflow Steps

Step Name Step Summary

Purchase Order Fiscal Document Receive

Initial step where the fiscal document is uploaded into the system.

Validate Document Unicity

The purpose of the step is to assure the same document is not being received twice. It will perform a check in the FDR repository looking for the document ID (tag:chNfe). If the same document is found, this validation will return an error directly to the REST service and the document will be rolled back.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Nfe Status Verification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to confirm with tax authority, if the fiscal document is approved and still valid.

Nfe Status Verification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Foundation Data

Deduction of item and PO data. This step will use the PO number in the document, along with the supplier and location IDs already identified, to associate the items in the document with the PO available in Merchandising. The data produced in this step will be available in the fiscal document screen under “deducedData/orderData” at item level. The PO number, order status and quantity ordered are some of the data to be deduced.

Validate Foundation Data

Validation of the deduced data. This step will perform 3 validations: Validation 1: based on the result of the deduceFoundationData step, the mandatory fields will be checked. If any of them is null, the validation will return ERROR. Validation 2: the status of the PO must be APPROVED, so this validation will verify the deduced tag deducedData/orderData/orderStatus and anything different than APPROVED will put the document in ERROR status. Validation 3: Compare the quantity of the item in the fiscal document (tag:qCom) with the quantity available for the item in the PO deduced. Quantity available will be: (qtyOrdered / SUPPPACKSIZE) >= (qtyOrdered / SUPPPACKSIZE) - (qtyReceived / SUPPPACKSIZE) – qtyBeingReceived. If the item quantity in the fiscal document is greater that the available quantity, the item will be put in error status.Note: The qtyBeingReceived refers to the quantity of the same item/po being received by other fiscal documents at the same time. It will be deduced based on the fiscal document PO number tag:xPed + tag:cProd/cEAN/cEANTrib in fiscal documents present in FDR working repository which means documents in progress.

Deduce Commercial Data

Deduction of PO costs, discounts and expenses.Deduction Rules:orderCost: based on the itemCode and orderNo, fetch: (ORDLOC.UNIT_COST_INI * ORDSKU.SUPP_PACK_SIZE) = orderCostorderFreight, orderInsurance, orderExpenses : Check ORDLOC_EXP if the item in the order has any expenses. The expense amount will be in ORDLOC_EXP.EST_EXP_VALUE. The value in this column will be related to the item SUOM (unit) so in order to match with NF values, it is necessary to consider the purchase UOM, hence: (ORDLOC_EXP.EST_EXP_VALUE * ORDSKU.SUPP_PACK_SIZE) If any expense is found, check from ELC_COMP.EXP_CATEGORY = ("F","I","M"): for "F": update orderFreight for "I": update orderInsurance for "M": update orderExpensesorderDiscount: based on the itemCode and orderNo, fetch: (ORDLOC_DISCOUNT.DISCOUNT_AMT_PER_UNIT * ORDSKU.SUPP_PACK_SIZE)

Validate Commercial Data

Validation of the deduced data. This step will only check if all items had the “orderCost” deduced which is the mandatory tag.

Match Document with PO

Match costs and expenses including tolerances. There will be two levels of matching between the NFE and the PO. The values of cost, discounts, expenses, and freight can be compared at item level and for the document total.To make this a configurable behavior, the fiscal attributes “matchLevel” that can be created at location and/or supplier level will be used. Note: If the same attribute is configured for the location AND supplier, the supplier level attribute will be considered for the system behavior.Depending on the content of these attributes, system will perform the matching accordingly:matchLevelCost = 'D' - Matching will be performed at Detail level only.matchLevelCost = 'T' - Matching will be performed at Total level only.matchLevelCost = 'B' - Matching will be performed at Detail AND Total levels.matchLevelCost = 'N' - Matching will not be performed.Item level comparison:NFe data item level path: /nfeProc/Nfe/infNFe /det/prod/PO data item level path: /nfeProc/Nfe/infNFe/ det/prod/deducedData/orderDatavProd: ROUND(orderCost * qCom);2vDesc: ROUND (orderDiscount * qCom);2vFrete: ROUND (orderFreight * qCom);2vSeg: ROUND (orderInsurance * qCom);2vOutro: ROUND (orderExpenses * qCom);2Total level comparison:NFe data total level path:/nfeProc/Nfe/infNFe/ICMSTot/PO data total level path:/nfeProc/Nfe/infNFe/det/prod/deducedData/orderDatavProd ROUND sum(orderCost * qCom);2vDesc ROUND sum(orderDiscount * qCom);2vFrete ROUND sum(orderFreight * qCom);2vSeg ROUND sum(orderInsurance * qCom);2vOutro ROUND sum(orderExpenses * qCom);2Tolerance applicationAfter comparing the value of the NF with the value of the PO as per the above formulas, system must calculate the difference between these values (NF - PO). In case this subtraction is <> 0.00, the value calculated must have the tolerance calculation applied, accordingly to the tolerance type present in the deduced fiscal attributes, example: toleranceRateCost, toleranceValueCost, toleranceRateFreight, etc. The tolerance attributes are deduced in the “deduceKeyData” step for location and / or supplier.In case the difference between NF and PO is <= the tolerance value fetched from the tolerance function; the validation will return SUCCESS. In case the difference > tolerance value, the validation will return FAIL.

The PO currency will always be converted into BRL (Brazil´s currency) in order to perform the comparisons. The currency date to be used will vary depending on the availability of information. In case of importation, the import document date will be used, otherwise the document issue date.

Tax Validate Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to return a report with the comparison between taxes in the fiscal document and the taxes in the tax content setup. This comparison will be returned with details in case of any discrepancy. The comparison also considers tolerances that are sent based on the location and supplier fiscal attributes.

Tax Validate Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Verify Auto Submit Setup

Check system behavior fiscal attribute “autoSubmitReceipt” deduced for the supplier in the “deduceKeyData” step. The attribute would be placed in the following path:/nfeProc/Nfe/infNFe/emit/deducedData/setupData/autoSubmitReceiptIf the attribute is present, it means the document will be submitted to the physical receiving system (WMS or SIOCS) automatically. If the attribute is not present, the workflow will be waiting for a screen action to be executed.

Nfe Status Verification Request

In case no auto-submit setup is present, a screen action can be used to call the 3rd party API for NFe status verification again. (Optional to user). This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to confirm with tax authority, if the fiscal document is approved and still valid.

Nfe Status Verification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Generate ASNIN Message

This step will generate the ASN-IN payload that will be used to send the items in the fiscal document to the inventory systems. The payload generated has the same layout of the ASNInDesc payload.

Update Merchandise ASNIn Data

Update MFCS with ASNIN data. This step will call the Merch ASNiN consume process to update shipment tables with the purchase order being received.

Verify Location Type

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Submit to Physical Receipt Store

Push ASNIN to SIOCS if the location is a store.

Submit to Physical Receipt Warehouse

In this step the ASNIN payload generated will be published in the RFMCS integration tables for external WMS systems to pull via REST service.

Consume Receipt Message

Consume RECEIPT message from SIOCS/WMS through MFCS. The Integration from WMS or SIOCS with MFCS for the Receipt messages will not be changed. In MFCS, for the scenario where RFMCS is present, the message will be directed to RFMCS otherwise it will follow the regular integration flow.

Process Receipt Message

Match receipt quantities. This step will perform several validations and comparisons and will end up generating a payload with the quantities received and any discrepancy quantity found:1: Verify the “reject receiving” scenario: If all items have the tag ReceiptDesc/Receipt/ReceiptDtl/unit_qty = 0 (zero), the validation will be finished, the tag receivedQt will be recorded with 0 for all items and the process will return this scenario to the workflow to be resumed from here.If at least one item has the unit_qty > zero, the process will move to the second validation.2: Validate if there is any discrepancy: a) Compare the shipped_qty and the unit_qty tags for all items. If all items have these quantities matching, this validation will pass.- ReceiptDesc/Receipt/ReceiptDtl/shipped_qty (quantity sent to be received based on the NF)- ReceiptDesc/Receipt/ReceiptDtl/unit_qty (quantity received)b) Verify the group ReceiptOverage. If any item is returned in this group, validation will indicate an overage discrepancy exists for the receipt. In that case a specific tag will be generated:- /nfeProc/NFe/infNFe/det/prod/deducedData/receiptData/overageQtThe overage will be calculated based on the below logic: If shipped_qty > (unit_qty + ReceiptOverageDtl/qty_received) then 0, else (unit_qty + ReceiptOverageDtl/qty_received) - shipped_qty = overageQt3: Verify the attribute DISCR_FISCAL_DOCUMENT for the receiving location.The attribute is created by "deduceKeyData" at "nfeProc/NFe/infNFe/dest/deducedData/setupData/discrFiscalDocument".Possible values returned are: NFD (Non-Fiscal Document) or RNF (Return Nota Fiscal). These values will determine the tags where the discrepancy quantity will be posted:- if NFD, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/creditNoteQt- if RNF, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/rnfQt4: Generate the tags for quantity received and discrepancies if any.

Verify Overage Report Data

Verify if the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/OverageQt was created for any of the items in the document. If at least one item has this tag, generate a payload with the data. This payload data can be used to support reporting requirements.

Verify Return Discrepancy Document Type

This step will verify if the discrepancy document type used in the “processReceiptMessage” was RNF or CRN and the result of this verification will indicate the next step in the workflow.

Generate Credit Note Data

If the discrepancy document identified is a credit note, this step will generate credit note data payload that later will be sent to FDG for the generation of the document.

Generate Rnf Data

If the discrepancy document identified is a Return NF, this step will generate Return NF data payload that later will be sent to FDG for the generation of the document.

Tax Account Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to return the tax accounting data and tax credit data that will be used later in the process to calculate the receipt cost and to generate transaction codes that are base for financial postings.

Tax Account Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Tax Account Data

This step will format the tax account response into the document payload to be used by the following steps.

Return Document Request

In this step, if any discrepancy document was created, a request to specific FDG workflow will be made to either RNFDG or CRNDG workflows.

Calculate Receiving Cost

Calculate the receiving cost considering the document and tax accounting data. The receipt cost will be used to update Merchandising transaction data and average cost.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Create Fiscal Ledger Data

This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.

Update Fiscal Ledger In

This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.

Update Inventory

Update MFCS inventory. In this step, the “Receipt” message published by the inventory systems will be posted to Merchandising with the addition of the Receipt Cost calculated in RFMCS.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Update Manifest Data

Generate recipient-manifest-related data confirming the receiving of the document. This is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document

Update Reject Manifest Data

If the receiving of the fiscal document was rejected in any of the steps that allow this action, this is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document was not completed.

Nfe Reject Manifest

This step will be used to put the document in a “waiting” status in case the location is configured to manifest the receiving of a fiscal document in a later time. The manifestation can occur up to 30 days of the receiving of the document.

Nfe Manifest Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to inform the tax authority, that the fiscal document was received, accepted or rejected.

Nfe Manifest Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.

CRNDG: Credit Note Document Generation

  • Country: Brazil

  • Document Type: Non-fiscal Document

  • Overview: This workflow is meant to support the generation of a credit note in case of discrepancies identified in the POFDR workflow.

Table 2-3 CRNDG Workflow Steps

Pre-Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules.The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow:Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Reference Document Data

In this return specific step, the referenced document data will be fetched in order to generate the return document. The data fetched in this step will determine the reference costs and taxes to be considered while generating the return document.

Validate Referenced Document Data

This step will validate if the minimal mandatory data was deduced from the reference document payload.

Tax Return Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload along with the reference document tax details, and have all taxes and fiscal codes applied by the third party tax system.

Tax Return Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Deduce Reference Document Tax Account Data

In this step the tax account data from the reference document will be deduced and proportionally recalculated based on the quantity returned for each item. This is a return workflow scenario where the reference entry document will be used to have tax account data fetched for financial postings purposes.

Validate Reference Document Tax Account Data

This step will validate if there was any content deduced. In case the entry referenced document doesn´t have the tax account data, this step will return FAIL to the workflow.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

RNFDG: Return NF Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the generation of a return fiscal document in case of discrepancies identified in the POFDR workflow.

Table 2-4 RNFDG Workflow Steps

Step Name Step Summary

Pre-Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Reference Document Data

In this return specific step, the referenced document data will be fetched in order to generate the return document. The data fetched in this step will determine the reference costs and taxes to be considered while generating the return document.

Validate Referenced Document Data

This step will validate if the minimal mandatory data was deduced from the reference document payload.

Tax Return Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload along with the reference document tax details, and have all taxes and fiscal codes applied by the third party tax system.

Tax Return Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Reference Document Tax Account Data

In this step the tax account data from the reference document will be deduced and proportionally recalculated based on the quantity returned for each item. This is a return workflow scenario where the reference entry document will be used to have tax account data fetched for financial postings purposes.

Validate Reference Document Tax Account Data

This step will validate if there was any content deduced. In case the entry referenced document doesn´t have the tax account data, this step will return FAIL to the workflow.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Archive Document

This step will move the document to archive repository.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

RTVDG: Return to Vendor Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the generation of a return to vendor fiscal document based on the request from inventory systems.

Table 2-5 RTVDG Workflow Steps

Step Name Step Summary

Pre Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow:Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Pack Data

This step will add pack related information for the components in case there were complex packs in the document request. These tags are required for the next steps of the workflow. The tags to be deduced are: item (component code), packNo (pack number), packItemQty (quantity of component in the pack) and in case of simple pack, the simplePackInd.

Deduce Base Document Payload

This step will take the document request and will create the initial NFE fiscal document payload. This step will format the request into the NFE layout in order for the workflow to process and have it integrated and approved. Foundation data for entities, fiscal attributes and item details are in the scope of this initial document creation.

Validate Base Document Payload

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Update Fiscal Ledger Out

This step will call the Fiscal Ledger feature to consume the ledger balance quantities. This is the step that will have the balance control applied.

Validate Fiscal Ledger Data

This step will check if all items in the document had a fiscal ledger type "outbound" created.

Deduce Reference Document Data

In this return specific step, the referenced document data will be fetched in order to generate the return document. The data fetched in this step will determine the reference costs and taxes to be considered while generating the return document.

Validate Referenced Document Data

This step will validate if the minimal mandatory data was deduced from the reference document payload.

Deduce Item Cost

This step will define the cost to be applied in the transaction. This step is executed in multiples workflows and each one will have a specific rule. TSFDG - The general rule for transfers is to use the last received cost, however in case the information is not available for the item in the transaction the second source of this information can be the request payload itself. In the request, the tag "unitAmt" can be used to pass on the cost to be applied. If any of these two options are available for the item, then the "net cost" will be used. This is the cost calculated based on the source average cost for the item. RTVDG -The rule for all returns is to use the reference document cost as the cost for the transaction. In an exception scenario where there is no reference document, the unit cost of the item for the supplier will be used. DNODG and DNIDG - The rule for standalone workflows is to have the cost informed in the request payload. An option that can be used is to leverage the fiscal ledger and use the last received cost as well. In case none of these costs are found, the process will try to use the net cost calculated based on the source average cost for the item.

Validate Item Cost

This step will verify if the cost information was deduced for all items in the transaction.

Tax Return Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload along with the reference document tax details, and have all taxes and fiscal codes applied by the third party tax system.

Tax Return Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Reference Document Tax Account Data

In this step the tax account data from the reference document will be deduced and proportionally recalculated based on the quantity returned for each item. This is a return workflow scenario where the reference entry document will be used to have tax account data fetched for financial postings purposes.

Validate Reference Document Tax Account Data

This step will validate if there was any content deduced. In case the entry referenced document doesn´t have the tax account data, this step will return FAIL to the workflow.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Verify Document Breakup

This step will verify if the document has the tag: requestBreakup = Y. If this tag is present as Y, a second verification will be made for the tag: requestBreakupMaindoc = Y. In case BOTH tags exist as "Y" OR NONE of them are present the workflow will proceed to the next step. If only the tag requestBreakup is present, the workflow will skip the step for update the request systems about the document approval.

Verify Location Type

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

Note:

The below steps with a * are only applied in case of a document cancelation request.
Step Name Step Summary

Document Cancelation Request *

If the processDocCancel API is called to cancel a document being processed or already processed, RFMCS will initiate the cancelation sequence, starting with this initial step that will have the request ID for the document to be canceled. In order to accept a cancelation request, RFMCS will verify if the document is yet in progress for its generation or if it was already approved. In case the document is yet being processed, the request for cancelation will be accepted only in case the document is in Error or Failed statuses.

Validate Document Group Status *

This step will indicate to the workflow if the document is yet being processed and in a valid status to be canceled or if the document is already in the HIST repository so the next steps can execute accordingly.

Validate Nfe Integration *

This step will indicate to the workflow if there was an attempt to have the document communicated to the Government systems. This indication will drive the workflow to the necessary actions.

Validate Document Nullified *

This step will indicate to the workflow if there was an attempt to nullify the document with the Government systems. This indication will drive the workflow to the necessary actions.

Nfe Nullification Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit a request to nullify the Nfe number in the Government system.

Nfe Nullification Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Cancelation Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit a request to cancel the Nfe in the Government system.

Nfe Cancelation Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Update Fiscal Report Data *

This step will be executed in case the fiscal document being canceled is in the HIST repository, otherwise it will be skipped. This step will fetch the createFiscaslReportData scenario from HIST and will merge with the nfeCancelationRequest.

Validate Fiscal Report *

This step will verify in FDG repository if the scenario "createFiscalReportData" exists. In case the scenario exists the workflow will be redirected accordingly.

Create Fiscal Report Data *

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document *

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Validate Financial Postings *

This step will verify if the document being canceled has transaction data generated in RFMCS.

Cancel Financial Postings *

This step will be called in case there are transaction data previously created for the document. In this case this step will run the updateFinancialPostings process again, but will multiply all transaction data results by -1. The result will be a new scenario 'cancelFinancialPostings' created with the same content of the 'updateFinancialPostings', but with a negative value which should result in the "cancelation" of the trandata postings for the document.

Rollback Ledger Updates *

This step will be called in case the action Reject or Nullify are executed or in case of document cancelation. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Verify Location Type *

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores *

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH *

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Archive Document *

This step will move the document to archive repository.

Verify Workflow Exceptions *

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Terminated with Exception *

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

TSFDG: Transfer Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the generation of a stock order transfer fiscal document based on the request from inventory systems.

Table 2-6 TSFDG Workflow Steps

Step Name Step Summary

Pre Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Pack Data

This step will add pack related information for the components in case there were complex packs in the document request. These tags are required for the next steps of the workflow. The tags to be deduced are: item (component code), packNo (pack number), packItemQty (quantity of component in the pack) and in case of simple pack, the simplePackInd.

Deduce Base Document Payload

This step will take the document request and will create the initial NFE fiscal document payload. This step will format the request into the NFE layout in order for the workflow to process and have it integrated and approved. Foundation data for entities, fiscal attributes and item details are in the scope of this initial document creation.

Validate Base Document Payload

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Update Fiscal Ledger Out

This step will call the Fiscal Ledger feature to consume the ledger balance quantities. This is the step that will have the balance control applied.

Validate Fiscal Ledger Data

This step will check if all items in the document had a fiscal ledger type "outbound" created.

Deduce Reference Transaction Data

This step applied to transfer scenarios, will fetch cost related information that will be required for the process of the transfer shipment and receiving. The data to be deduced in this step is:- Last received Cost: this is based on the data from the update fiscal ledger step where the last receiving of the item is used to fetch the last received gross cost from the fiscal document- Last received cost reference document: this is the document id from which the last received cost is fetched- Source average cost: from the item location stock on hand table, the average cost of the item in the source location- Transfer number: the transfer number being processed for the item- Transfer price: in case a transfer price was informed in the transfer- Total Recovered taxes: in the update of the fiscal ledger, recoverable taxes may return and in that case the value to be recovered will be deduced- Net cost: this is the cost calculated based on the source average cost and considering any potential tax to be recovered- Transfer type: if the transfer is regular or intercompany.

Validate Reference Transaction Data

This step will validate if the mandatory tags from the deduce reference transaction data step was deduced for all items

Deduce Item Cost

This step will define the cost to be applied in the transaction. This step is executed in multiples workflows and each one will have a specific rule. TSFDG - The general rule for transfers is to use the last received cost, however in case the information is not available for the item in the transaction the second source of this information can be the request payload itself. In the request, the tag "unitAmt" can be used to pass on the cost to be applied. If any of these two options are available for the item, then the "net cost" will be used. This is the cost calculated based on the source average cost for the item. RTVDG -The rule for all returns is to use the reference document cost as the cost for the transaction. In an exception scenario where there is no reference document, the unit cost of the item for the supplier will be used. DNODG and DNIDG - The rule for standalone workflows is to have the cost informed in the request payload. An option that can be used is to leverage the fiscal ledger and use the last received cost as well. In case none of these costs are found, the process will try to use the net cost calculated based on the source average cost for the item.

Validate Item Cost

This step will verify if the cost information was deduced for all items in the transaction.

Tax Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload and have all taxes and fiscal codes applied by the third party tax system.

Tax Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Verify Document Breakup

This step will verify if the document has the tag: requestBreakup = Y. If this tag is present as Y, a second verification will be made for the tag: requestBreakupMaindoc = Y. In case BOTH tags exist as "Y" OR NONE of them are present the workflow will proceed to the next step. If only the tag requestBreakup is present, the workflow will skip the step for update the request systems about the document approval.

Verify Location Type

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

Note:

The below steps with a * are only applied in case of a document cancelation request.
Step Name Step Summary

Document Cancelation Request *

If the processDocCancel API is called to cancel a document being processed or already processed, RFMCS will initiate the cancelation sequence, starting with this initial step that will have the request ID for the document to be canceled. In order to accept a cancelation request, RFMCS will verify if the document is yet in progress for its generation or if it was already approved. In case the document is yet being processed, the request for cancelation will be accepted only in case the document is in Error or Failed statuses.

Validate Document Group Status *

This step will indicate to the workflow if the document is yet being processed and in a valid status to be canceled or if the document is already in the HIST repository so the next steps can execute accordingly.

Validate Nfe Integration *

This step will indicate to the workflow if there was an attempt to have the document communicated to the Government systems. This indication will drive the workflow to the necessary actions.

Validate Document Nullified *

This step will indicate to the workflow if there was an attempt to nullify the document with the Government systems. This indication will drive the workflow to the necessary actions.

Nfe Nullification Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit a request to nullify the Nfe number in the Government system.

Nfe Nullification Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Cancelation Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit a request to cancel the Nfe in the Government system.

Nfe Cancelation Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Update Fiscal Report Data *

This step will be executed in case the fiscal document being canceled is in the HIST repository, otherwise it will be skipped. This step will fetch the createFiscaslReportData scenario from HIST and will merge with the nfeCancelationRequest.

Validate Fiscal Report *

This step will verify in FDG repository if the scenario "createFiscalReportData" exists. In case the scenario exists, the workflow will be redicrected accordingly.

Create Fiscal Report Data *

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document *

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Validate Financial Postings *

This step will verify if the document being canceled has transaction data generated in RFMCS.

Cancel Financial Postings *

This step will be called in case there are transaction data previously created for the document. In this case this step will run the updateFinancialPostings process again but will multiply all transaction data results by -1. The result will be a new scenario 'cancelFinancialPostings' created with the same content of the 'updateFinancialPostings', but with a negative value which should result in the "cancelation" of the trandata postings for the document.

Rollback Ledger Updates *

This step will be called in case the action Reject or Nullify are executed or in case of document cancelation. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Verify Location Type *

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores *

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH *

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Archive Document *

This step will move the document to archive repository.

Verify Workflow Exceptions *

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Terminated with Exception *

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

TSFDR: Transfer Fiscal Document Receiving

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the receiving of stock order transfers with the creation of an entry fiscal document based on the physical receipt submitted by inventory systems.

Table 2-7 TSFDR Workflow Steps

Step Name Step Summary

Consume Receipt Message

Consume RECEIPT message from SIOCS/WMS through MFCS. The Integration from WMS or SIOCS with MFCS for the Receipt messages will not be changed. In MFCS, for the scenario where RFMCS is present, the message will be directed to RFMCS otherwise it will follow the regular integration flow.

Deduce Reference Request Data

In this step, the transfer outbound document will be used as reference to create the transfer inbound document.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Receipt Items

This step will associate the items in the fiscal document with the items in the receipt message.

Validate Receipt Items

In this step, the validation will make sure all items in the document are associated to either the consume receipt message or to the shipment tables.

Tax Account Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to return the tax accounting data and tax credit data that will be used later in the process to calculate the receipt cost and to generate transaction codes that are base for financial postings.

Tax Account Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Tax Account Data

This step will format the tax account response into the document payload to be used by the following steps.

Verify Upcharges

In this step, any upcharges applicable to the transfer / allocation will be fetched. The process will look at the TSFDETAIL_CHRG table based on the transfer number and will check if there are upcharges for the items. If there are records in this table for the transfer/item, it will use its details to call the UP_CHARGE_SQL.CALC_COMP function and will return the applicable charges for the item in the document.

Calculate Receiving Cost

Calculate the receiving cost considering the document and tax accounting data. The receipt cost will be used to update Merchandising transaction data and average cost.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Create Fiscal Ledger Data

This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.

Update Fiscal Ledger In

This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.

Update Receipt Data

This step will generate a payload for the consume receipt process in Merchandising. The payload will be generated with the items in the document. In case of packs, and because RFMCS will explode complex packs into components for the fiscal document, this step will consolidate the pack before calling Merchandising update inventory step.

Update Inventory

Update MFCS inventory. In this step, the “Receipt” message published by the inventory systems will be posted to Merchandising with the addition of the Receipt Cost calculated in RFMCS.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Update Manifest Data

Generate recipient-manifest-related data confirming the receiving of the document. This is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document

Nfe Manifest Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to inform the tax authority, that the fiscal document was received, accepted or rejected.

Nfe Manifest Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

DIFDG: Direct Import Fiscal Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the issuance of a direct import fiscal document based on the request from third party specialist systems.

Table 2-8 DIFDG Workflow Steps

Step Name Step Summary

Direct Import Fiscal Document Generation

This is the initial step of the workflow DIFDG. The assumption for this step is that the fiscal document will be submitted already calculated and with the NFe structure accordingly to the definitions made for the NFE Integration. In this scenario the document will be issued in RFMCS that will be in charge of assigning an official sequence and submit to the NFE Integration.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Receipt Document

This step will call the FDR process for the receipt of the Direct Import Fiscal Document generated.

Update Integration layer

In this step the integration tables will be populated with the status of the processing of the workflow, being either Approved, Rejected, or Nullified. The request systems will fetch this data.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.
Step Name Step Summary

Consume Receipt Message

Consume RECEIPT message from SIOCS/WMS through MFCS. The Integration from WMS or SIOCS with MFCS for the Receipt messages will not be changed. In MFCS, for the scenario where RFMCS is present, the message will be directed to RFMCS otherwise it will follow the regular integration flow.

Deduce Reference Request Data

In this step, the transfer outbound document will be used as reference to create the transfer inbound document.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Receipt Items

This step will associate the items in the fiscal document with the items in the receipt message.

Validate Receipt Items

In this step, the validation will make sure all items in the document are associated to either the consume receipt message or to the shipment tables.

Tax Account Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to return the tax accounting data and tax credit data that will be used later in the process to calculate the receipt cost and to generate transaction codes that are base for financial postings.

Tax Account Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Tax Account Data

This step will format the tax account response into the document payload to be used by the following steps.

Verify Upcharges

In this step, any upcharges applicable to the transfer / allocation will be fetched. The process will look at the TSFDETAIL_CHRG table based on the transfer number and will check if there are upcharges for the items. If there are records in this table for the transfer/item, it will use its details to call the UP_CHARGE_SQL.CALC_COMP function and will return the applicable charges for the item in the document.

Calculate Receiving Cost

Calculate the receiving cost considering the document and tax accounting data. The receipt cost will be used to update Merchandising transaction data and average cost.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Create Fiscal Ledger Data

This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.

Update Fiscal Ledger In

This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.

Update Receipt Data

This step will generate a payload for the consume receipt process in Merchandising. The payload will be generated with the items in the document. In case of packs, and because RFMCS will explode complex packs into components for the fiscal document, this step will consolidate the pack before calling Merchandising update inventory step.

Update Inventory

Update MFCS inventory. In this step, the “Receipt” message published by the inventory systems will be posted to Merchandising with the addition of the Receipt Cost calculated in RFMCS.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Update Manifest Data

Generate recipient-manifest-related data confirming the receiving of the document. This is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document

Nfe Manifest Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to inform the tax authority, that the fiscal document was received, accepted or rejected.

Nfe Manifest Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

DIFDR: Direct Import Fiscal Document Receiving

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the receiving of a direct import fiscal document based on the request from third party specialist systems.

Table 2-9 DIFDR Workflow Steps

Step Name Step Summary

Direct Import Fiscal Document Receiving

This is the initial step of the workflow DIFDR. The assumption for this step is that the fiscal document will be submitted already calculated and with the NFe structure accordingly to the definitions made for the NFE Integration. In this scenario the document already issued externally, will be received in RFMCS.

Validate Document Unicity

The purpose of the step is to assure the same document is not being received twice. It will perform a check in the FDR repository looking for the document ID (tag:chNfe). If the same document is found, this validation will return an error directly to the REST service and the document will be rolled back.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Nfe Status Verification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to confirm with tax authority, if the fiscal document is approved and still valid.

Nfe Status Verification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Foundation Data

Deduction of item and PO data. This step will use the PO number in the document, along with the supplier and location IDs already identified, to associate the items in the document with the PO available in Merchandising. The data produced in this step will be available in the fiscal document screen under “deducedData/orderData” at item level. The PO number, order status and quantity ordered are some of the data to be deduced.

Validate Foundation Data

Validation of the deduced data. This step will perform 3 validations: Validation 1: based on the result of the deduceFoundationData step, the mandatory fields will be checked. If any of them is null, the validation will return ERROR. Validation 2: the status of the PO must be APPROVED, so this validation will verify the deduced tag deducedData/orderData/orderStatus and anything different than APPROVED will put the document in ERROR status. Validation 3: Compare the quantity of the item in the fiscal document (tag:qCom) with the quantity available for the item in the PO deduced. Quantity available will be: (qtyOrdered / SUPPPACKSIZE) >= (qtyOrdered / SUPPPACKSIZE) - (qtyReceived / SUPPPACKSIZE) – qtyBeingReceived. If the item quantity in the fiscal document is greater that the available quantity, the item will be put in error status.

Note: The qtyBeingReceived refers to the quantity of the same item/po being received by other fiscal documents at the same time. It will be deduced based on the fiscal document PO number tag:xPed + tag:cProd/cEAN/cEANTrib in fiscal documents present in FDR working repository which means documents in progress.

Deduce Commercial Data

Deduction of PO costs, discounts and expenses. Deduction Rules: orderCost: based on the itemCode and orderNo, fetch: (ORDLOC.UNIT_COST_INI * ORDSKU.SUPP_PACK_SIZE) = orderCostorderFreight, orderInsurance, orderExpenses : Check ORDLOC_EXP if the item in the order has any expenses. The expense amount will be in ORDLOC_EXP.EST_EXP_VALUE. The value in this column will be related to the item SUOM (unit) so in order to match with NF values, it is necessary to consider the purchase UOM, hence: (ORDLOC_EXP.EST_EXP_VALUE * ORDSKU.SUPP_PACK_SIZE) If any expense is found, check from ELC_COMP.EXP_CATEGORY = ("F","I","M"): for "F": update orderFreight for "I": update orderInsurance for "M": update orderExpensesorderDiscount: based on the itemCode and orderNo, fetch: (ORDLOC_DISCOUNT.DISCOUNT_AMT_PER_UNIT * ORDSKU.SUPP_PACK_SIZE)

Validate Commercial Data

Validation of the deduced data. This step will only check if all items had the “orderCost” deduced which is the mandatory tag.

Match Document with PO

Match costs and expenses including tolerances. There will be two levels of matching between the NFE and the PO. The values of cost, discounts, expenses, and freight can be compared at item level and for the document total. To make this a configurable behavior, the fiscal attributes “matchLevel” that can be created at location and/or supplier level will be used. Note: If the same attribute is configured for the location AND supplier, the supplier level attribute will be considered for the system behavior. Depending on the content of these attributes, system will perform the matching accordingly:matchLevelCost = 'D' - Matching will be performed at Detail level only.matchLevelCost = 'T' - Matching will be performed at Total level only.matchLevelCost = 'B' - Matching will be performed at Detail AND Total levels.matchLevelCost = 'N' - Matching will not be performed. Item level comparison: NFe data item level path: /nfeProc/Nfe/infNFe /det/prod/PO data item level path: /nfeProc/Nfe/infNFe/ det/prod/deducedData/orderDatavProd: ROUND(orderCost * qCom);2vDesc: ROUND (orderDiscount * qCom);2vFrete: ROUND (orderFreight * qCom);2vSeg: ROUND (orderInsurance * qCom);2vOutro: ROUND (orderExpenses * qCom);2Total level comparison:NFe data total level path:/nfeProc/Nfe/infNFe/ICMSTot/PO data total level path:/nfeProc/Nfe/infNFe/det/prod/deducedData/orderDatavProd ROUND sum(orderCost * qCom);2vDesc ROUND sum(orderDiscount * qCom);2vFrete ROUND sum(orderFreight * qCom);2vSeg ROUND sum(orderInsurance * qCom);2vOutro ROUND sum(orderExpenses * qCom);2Tolerance applicationAfter comparing the value of the NF with the value of the PO as per the above formulas, system must calculate the difference between these values (NF - PO). In case this subtraction is <> 0.00, the value calculated must have the tolerance calculation applied, accordingly to the tolerance type present in the deduced fiscal attributes, example: toleranceRateCost, toleranceValueCost, toleranceRateFreight, etc. The tolerance attributes are deduced in the “deduceKeyData” step for location and / or supplier. In case the difference between NF and PO is <= the tolerance value fetched from the tolerance function; the validation will return SUCCESS. In case the difference > tolerance value, the validation will return FAIL.

The PO currency will always be converted into BRL (Brazil´s currency) in order to perform the comparisons. The currency date to be used will vary depending on the availability of information. In case of importation, the import document date will be used, otherwise the document issue date.

Verify Auto Submit Setup

Check system behavior fiscal attribute “autoSubmitReceipt” deduced for the supplier in the “deduceKeyData” step. The attribute would be placed in the following path:/nfeProc/Nfe/infNFe/emit/deducedData/setupData/autoSubmitReceiptIf the attribute is present, it means the document will be submitted to the physical receiving system (WMS or SIOCS) automatically. If the attribute is not present, the workflow will be waiting for a screen action to be executed.

Nfe Status Verification Request

In case no auto-submit setup is present, a screen action can be used to call the 3rd party API for NFe status verification again. (Optional to user). This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to confirm with tax authority, if the fiscal document is approved and still valid.

Nfe Status Verification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Generate ASNIN Message

This step will generate the ASN-IN payload that will be used to send the items in the fiscal document to the inventory systems. The payload generated has the same layout of the ASNInDesc payload.

Update Merchandise ASNIn Data

Update MFCS with ASNIN data. This step will call the Merch ASNiN consume process to update shipment tables with the purchase order being received.

Verify Location Type

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Submit to Physical Receipt Store

Push ASNIN to SIOCS if the location is a store.

Submit to Physical Receipt Warehouse

In this step the ASNIN payload generated will be published in the RFMCS integration tables for external WMS systems to pull via REST service.

Consume Receipt Message

Consume RECEIPT message from SIOCS/WMS through MFCS. The Integration from WMS or SIOCS with MFCS for the Receipt messages will not be changed. In MFCS, for the scenario where RFMCS is present, the message will be directed to RFMCS otherwise it will follow the regular integration flow.

Process Receipt Message

Match receipt quantities. This step will perform several validations and comparisons and will end up generating a payload with the quantities received and any discrepancy quantity found:1: Verify the “reject receiving” scenario: If all items have the tag ReceiptDesc/Receipt/ReceiptDtl/unit_qty = 0 (zero), the validation will be finished, the tag receivedQt will be recorded with 0 for all items and the process will return this scenario to the workflow to be resumed from here.If at least one item has the unit_qty > zero, the process will move to the second validation.2: Validate if there is any discrepancy: a) Compare the shipped_qty and the unit_qty tags for all items. If all items have these quantities matching, this validation will pass.- ReceiptDesc/Receipt/ReceiptDtl/shipped_qty (quantity sent to be received based on the NF)- ReceiptDesc/Receipt/ReceiptDtl/unit_qty (quantity received)b) Verify the group ReceiptOverage. If any item is returned in this group, validation will indicate an overage discrepancy exists for the receipt. In that case a specific tag will be generated:- /nfeProc/NFe/infNFe/det/prod/deducedData/receiptData/overageQtThe overage will be calculated based on the below logic: If shipped_qty > (unit_qty + ReceiptOverageDtl/qty_received) then 0, else (unit_qty + ReceiptOverageDtl/qty_received) - shipped_qty = overageQt3: Verify the attribute DISCR_FISCAL_DOCUMENT for the receiving location.The attribute is created by "deduceKeyData" at "nfeProc/NFe/infNFe/dest/deducedData/setupData/discrFiscalDocument".Possible values returned are: NFD (Non-Fiscal Document) or RNF (Return Nota Fiscal). These values will determine the tags where the discrepancy quantity will be posted:- if NFD, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/creditNoteQt- if RNF, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/rnfQt4: Generate the tags for quantity received and discrepancies if any.

Verify Overage Report Data

Verify if the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/OverageQt was created for any of the items in the document. If at least one item has this tag, generate a payload with the data. This payload data can be used to support reporting requirements.

Verify Shortage Report Data

Verify if the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/shortageQt was created for any of the items in the document. If at least one item has this tag, generate a payload with the data. This payload data can be used to support reporting requirements.

Tax Account Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to return the tax accounting data and tax credit data that will be used later in the process to calculate the receipt cost and to generate transaction codes that are base for financial postings.

Tax Account Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Tax Account Data

This step will format the tax account response into the document payload to be used by the following steps.

Calculate Receiving Cost

Calculate the receiving cost considering the document and tax accounting data. The receipt cost will be used to update Merchandising transaction data and average cost.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Create Fiscal Ledger Data

This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.

Update Fiscal Ledger In

This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.

Update Inventory

Update MFCS inventory. In this step, the “Receipt” message published by the inventory systems will be posted to Merchandising with the addition of the Receipt Cost calculated in RFMCS.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Update Manifest Data

Generate recipient-manifest-related data confirming the receiving of the document. This is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document

Update Reject Manifest Data

If the receiving of the fiscal document was rejected in any of the steps that allow this action, this is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document was not completed.

Nfe Reject Manifest

This step will be used to put the document in a “waiting” status in case the location is configured to manifest the receiving of a fiscal document in a later time. The manifestation can occur up to 30 days of the receiving of the document.

Nfe Manifest Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to inform the tax authority, that the fiscal document was received, accepted or rejected.

Nfe Manifest Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Integration layer

In this step the integration tables will be populated with the status of the processing of the workflow, being either Approved, Rejected, or Nullified. The request systems will fetch this data.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

DNODG: Direct Note Outbound Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the generation of a standalone fiscal document based on the request posted via RFMCS processPreDoc API.

Table 2-10 DNODG Workflow Steps

Step Name Step Summary

Pre Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Pack Data

This step will add pack related information for the components in case there were complex packs in the document request. These tags are required for the next steps of the workflow. The tags to be deduced are: item (component code), packNo (pack number), packItemQty (quantity of component in the pack) and in case of simple pack, the simplePackInd.

Deduce Base Document Payload

This step will take the document request and will create the initial NFE fiscal document payload. This step will format the request into the NFE layout in order for the workflow to process and have it integrated and approved. Foundation data for entities, fiscal attributes and item details are in the scope of this initial document creation.

Validate Base Document Payload

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Update Fiscal Ledger Out

This step will call the Fiscal Ledger feature to consume the ledger balance quantities. This is the step that will have the balance control applied.

Validate Fiscal Ledger Data

This step will check if all items in the document had a fiscal ledger type "outbound" created.

Deduce Item Cost

This step will define the cost to be applied in the transaction. This step is executed in multiples workflows and each one will have a specific rule. TSFDG - The general rule for transfers is to use the last received cost, however in case the information is not available for the item in the transaction the second source of this information can be the request payload itself. In the request, the tag "unitAmt" can be used to pass on the cost to be applied. If any of these two options are available for the item, then the "net cost" will be used. This is the cost calculated based on the source average cost for the item. RTVDG -The rule for all returns is to use the reference document cost as the cost for the transaction. In an exception scenario where there is no reference document, the unit cost of the item for the supplier will be used. DNODG and DNIDG - The rule for standalone workflows is to have the cost informed in the request payload. An option that can be used is to leverage the fiscal ledger and use the last received cost as well. In case none of these costs are found, the process will try to use the net cost calculated based on the source average cost for the item.

Validate Item Cost

This step will verify if the cost information was deduced for all items in the transaction.

Tax Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload and have all taxes and fiscal codes applied by the third party tax system.

Tax Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

DNIDG: Direct Note Inbound Document Generation

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the generation of a standalone fiscal document based on the request posted via RFMCS processPreDoc API.

Table 2-11 DNIDG Workflow Steps

Step Name Step Summary

Pre Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null.In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Pack Data

This step will add pack-related information for the componentes in case there were complex packs in the document request. These tags are required for the next steps of the workflow. The tags to be deduced are: item (component code), packNo (pack number), packItemQty (quantity of component in the pack) and in case of simple pack, the simplePackInd.

Deduce Base Document Payload

This step will take the document request and will create the initial NFE fiscal document payload. This step will format the request into the NFE layout in order for the workflow to process and have it integrated and approved. Foundation data for entities, fiscal attributes and item details are in the scope of this initial document creation.

Validate Base Document Payload

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Deduce Item Cost

This step will define the cost to be applied in the transaction. This step is executed in multiples workflows and each one will have a specific rule. TSFDG - The general rule for transfers is to use the last received cost, however in case the information is not available for the item in the transaction the second source of this information can be the request payload itself. In the request, the tag "unitAmt" can be used to pass on the cost to be applied. If any of these two options are available for the item, then the "net cost" will be used. This is the cost calculated based on the source average cost for the item. RTVDG -The rule for all returns is to use the reference document cost as the cost for the transaction. In an exception scenario where there is no reference document, the unit cost of the item for the supplier will be used. DNODG and DNIDG - The rule for standalone workflows is to have the cost informed in the request payload. An option that can be used is to leverage the fiscal ledger and use the last received cost as well. In case none of these costs are found, the process will try to use the net cost calcualted based on the source average cost for the item.

Validate Item Cost

This step will verify if the cost information was deduced for all items in the transaction.

Tax Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload and have all taxes and fiscal codes applied by the third party tax system.

Tax Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submited for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolledback. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Create Fiscal Ledger Data

This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.

Update Fiscal Ledger In

This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finished as expected or in case of document rejection or cancelation.

COFDG: Customer Orders Fiscal Document Generation

 Country: Brazil

 Document Type: Brazilian NFE model 55

 Overview: This workflow is meant to support the generation of a customer order transfer fiscal document based on the request from inventory systems.

Table 2-12 COFDG Workflow Steps

Step Name Step Summary

Pre Document Generation Request

This is the initial step of workflows that are generated from the processPreDoc API. Before starting this type of workflow, RFMCS will apply the document break up rules. The first rule is related to the number of items on the document generation request. Based on the location level attribute "NFE_BREAK_ITEMS", the request will be broken in multiple fiscal documents. If a request is broken into more than one fiscal document, the initial preDocumentGeneartionRequest payload will have a tag requestBreakup included. In the first document generated the tag requestBreakupMainDoc will also be included. These tags will be used in the next steps of the workflow to group these documents for processing and to identify which document will be used as reference for the communication with the request system. The second rule is related to complex packs in the request. All complex packs will be broken into components for the fiscal document generation. In case a complex pack is broken down in components, the initial payload will have tags identified the pack number, pack composition. Simple packs will not be broken down into components, but an additional tag indicating the item is a simple pack will also be added to the initial payload.

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Pack Data

This step will add pack related information for the components in case there were complex packs in the document request. These tags are required for the next steps of the workflow. The tags to be deduced are: item (component code), packNo (pack number), packItemQty (quantity of component in the pack) and in case of simple pack, the simplePackInd.

Customer Order Data Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to provide customer data that is kept and maintained by OMS solutions. The transaction related data will also be provided in order to have the fiscal document requirements fulfilled accordingly.

Customer Order Data Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Verify Fiscal Ledger Control

This step will verify if the location has the fiscal ledger control enabled.

Update Fiscal Ledger Out

This step will call the Fiscal Ledger feature to consume the ledger balance quantities. This is the step that will have the balance control applied.

Validate Fiscal Ledger Data

This step will check if all items in the document had a fiscal ledger type "outbound" created.

Tax Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload and have all taxes and fiscal codes applied by the third party tax system.

Tax Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Request Updated Data

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Verify Document Breakup

This step will verify if the document has the tag: requestBreakup = Y. If this tag is present as Y, a second verification will be made for the tag: requestBreakupMaindoc = Y. In case BOTH tags exist as "Y" OR NONE of them are present the workflow will proceed to the next step. If only the tag requestBreakup is present, the workflow will skip the step for update the request systems about the document approval.

Verify Location Type

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.
 

Note:

The below steps with a * are only applied in case of a document cancelation request.

Document Cancelation Request *

If the processDocCancel API is called to cancel a document being processed or already processed, RFMCS will initiate the cancelation sequence, starting with this initial step that will have the request ID for the document to be canceled. In order to accept a cancelation request, RFMCS will verify if the document is yet in progress for its generation or if it was already approved. In case the document is yet being processed, the request for cancelation will be accepted only in case the document is in Error or Failed statuses.

Validate Document Group Status *

This step will indicate to the workflow if the document is yet being processed and in a valid status to be canceled or if the document is already in the HIST repository so the next steps can execute accordingly.

Validate Nfe Integration *

This step will indicate to the workflow if there was an attempt to have the document communicated to the Government systems. This indication will drive the workflow to the necessary actions.

Validate Document Nullified *

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Nfe Nullification Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Cancelation Request *

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit a request to cancel the Nfe in the Government system.

Nfe Cancelation Response *

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Update Fiscal Report Data *

This step will be executed in case the fiscal document being canceled is in the HIST repository, otherwise it will be skipped. This step will fetch the createFiscaslReportData scenario from HIST and will merge with the nfeCancelationRequest.

Validate Fiscal Report *

This step will verify in FDG repository if the scenario "createFiscalReportData" exists. In case the scenario exists the workflow will be redirected accordingly.

Create Fiscal Report Data *

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document *

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Validate Financial Postings *

This step will verify if the document being canceled has transaction data generated in RFMCS.

Cancel Financial Postings *

This step will be called in case there are transaction data previously created for the document. In this case this step will run the updateFinancialPostings process again, but will multiply all transaction data results by -1. The result will be a new scenario 'cancelFinancialPostings' created with the same content of the 'updateFinancialPostings', but with a negative value which should result in the "cancelation" of the trandata postings for the document.

Rollback Ledger Updates *

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Verify Location Type *

This step will verify the location type before the workflow proceeds. The location type will result in different directions for the workflow, including different integration methods with inventory systems (WMS and SIOCS)

Update Document Status Detail to Stores *

This step the system that requested the document to be generated will be updated. In case the location type is "store", SIOCS integration will be updated.

Update Document Status Detail to WH *

This step the system that requested the document to be generated will be updated. In case the location type is "warehouse", the respective integration will be updated.

Archive Document *

This step will move the document to archive repository.

Verify Workflow Exceptions *

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Terminated with Exception *

Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.

RMADG: Return Merchandise Authorization Fiscal Document Generation

  •  Country: Brazil

  •  Document Type: Brazilian NFE model 55

  •  Overview: This workflow is meant to support the issuance of a fiscal document to support a customer order return (RMA) based on the request from third party specialist systems.

Table 2-13 RMADG Workflow Steps

Step Name Step Summary

Customer Order RMA Document Request

This is the initial step for the RMADG workflow. It will be based on external integration service from OMS solutions.

Validate Request Data

This step will validate mandatory data in the customerOrderRmaDocumentRequest payload

Deduce Key Data

Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.

Validate Key Data

This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.

Deduce Reference Document Data

In this return specific step, the referenced document data will be fetched in order to generate the return document. The data fetched in this step will determine the reference costs and taxes to be considered while generating the return document.

Validate Referenced Document Data

This step will validate if the minimal mandatory data was deduced from the reference document payload.

Deduce Base Document Specifics

This step will add tags in the NFE payload that can vary depending on the transaction such as transfers or returns. Mainly tags associated with item costs and specific tags that will be different for each transaction will be deduced.

Validate Base Document Specifics

This step will verify if all mandatory tags of the NFE fiscal document were properly generated.

Tax Return Issue Request

This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload along with the reference document tax details, and have all taxes and fiscal codes applied by the third party tax system.

Tax Return Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Deduce Nfe Additional Data

This step will add tags to the Nfe payload that were not possibly added by the deduce base document nor by the tax calculation

Validate Nfe Rules

This step will perform basic validations to the Nfe payload. Sum of detail tags into total tags.

Validate Nfe Structure

This step will submit the Nfe payload to the latest Nfe xsd structure.

Deduce Document Sequence

This step will add the official document number, model, issue date to the Nfe payload before submitting it to the NFE integration.

Validate Document Sequence

This step will validate if the sequence was properly added to the document, along with the other mandatory tags related.

Nfe Issue Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Request Updated Data

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to submit the Nfe document to the Government system for approval.

Nfe Issue Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Nfe Nullification Request

This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to request nullification of a fiscal document that was previously submitted for approval but wasn´t approved or had any problem after being communicated to the Government systems.

Nfe Nullification Response

This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)

Validate Document Nullified

This step will verify in the document if there was a screen action nullify or workflow step of 'nfeNullificationRequest'. In that case the workflow will be directed to the nullification related steps sequence.

Update Financial Postings

This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.

Create Fiscal Report Data

This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.

Pre Archive Document

This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.

Rollback Ledger Updates

This step will be called in case the action Reject or Nullify are executed. In this case, the updates performed in the step updateFiscalLedgerOut will be rolled back. In this process the balance component will be called again, and the ledger IDs type OUT created for the document will be canceled. The cancelation process in this case will also restore the quantities consumed for the BALANCE column in the reference document IDs. This is part of the Balance Control process.

Update Integration layer

In this step the integration tables will be populated with the status of the processing of the workflow, being either Approved, Rejected or Nullified. The request systems will fetch this data.

Update Financial Integration

This step will generate financial integration related data and will post the document to be processed in the integration layer.

Archive Document

This step will move the document to archive repository.

Verify Workflow Exceptions

After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.

Workflow Completed

Update document to final workflow step as success in case the workflow finished as expected.

Workflow Terminated with Exception

Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.

DNIDR: Direct Note Inbound Document Receiving

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the receiving of a standalone fiscal document based on the request posted through RFMCS REST services.

Table 2-14 DNIDR Workflow Steps

Step Name Step Summary
Direct NF Inbound Document Receiving This is the initial step of the workflow DNIDR that allows the receiving of fiscal documents issued by third parties to be received in RFMCS without any link to transactions. It is part of the standalone fiscal document processing capacity.
Validate Document Unicity The purpose of the step is to assure the same document is not being received twice. It will perform a check in the FDR repository looking for the document ID (tag:chNfe). If the same document is found, this validation will return an error directly to the REST service and the document will be rolled back.
Deduce Key Data Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.
Validate Key Data This step will perform up to 2 validations depending on the type of the workflow: Validation 1: based on the result of the deduceKeyData step, the mandatory fields will be check. If any of them is null, the validation will return ERROR. Validation 2: specifically for documents being received that were generated by external systems, this step will look for that the tag 'mod' with the value mod=55. In case of any difference validation will fail. Also the tag 'finNfe' of the fiscal document will be verified for the values finNfe=1. In case of any difference, the validation will fail.
Nfe Status Verification Request This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to confirm with tax authority, if the fiscal document is approved and still valid.
Nfe Status Verification Response This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)
Tax Account Request This is an integration step that will call the 3rd party API for this scenario. This API is meant to return the tax accounting data and tax credit data that will be used later in the process to calculate the receipt cost and to generate transaction codes that are base for financial postings.
Tax Account Response This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)
Create Tax Account Data This step will format the tax account response into the document payload to be used by the following steps.
Calculate Receiving Cost Calculate the receiving cost considering the document and tax accounting data. The receipt cost will be used to update Merchandising transaction data and average cost.
Verify Fiscal Ledger Control This step will verify if the location has the fiscal ledger control enabled.
Create Fiscal Ledger Data This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.
Update Fiscal Ledger In This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.
Update Financial Postings This step will apply transaction codes setup for the workflow and generate transaction codes data for the document. This data will be used in financial postings integration process.
Update Manifest Data Generate recipient-manifest-related data confirming the receiving of the document. This is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document
Update Reject Manifest Data If the receiving of the fiscal document was rejected in any of the steps that allow this action, this is meant to provide the necessary data for the integration with tax authority to communicate the receipt of the fiscal document was not completed.
Nfe Reject Manifest This step will be used to put the document in a “waiting” status in case the location is configured to manifest the receiving of a fiscal document in a later time. The manifestation can occur up to 30 days of the receiving of the document.
Nfe Manifest Request This is an integration step that will call the 3rd party API for this scenario. The purpose of this step is to inform the tax authority, that the fiscal document was received, accepted or rejected.
Nfe Manifest Response This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)
Create Fiscal Report Data This step will prepare a payload with data from the fiscal document that can be sent to fiscal reporting systems. This payload will be made available via RDS or via a specific GET type web-service for that purpose.
Pre Archive Document This step will convert the payload generated in the “create fiscal report data” into a supported format for RDS.
Update Financial Integration This step will generate financial integration related data and will post the document to be processed in the integration layer.
Update Financial Integration This step will generate financial integration related data and will post the document to be processed in the integration layer.
Archive Document This step will move the document to archive repository.
Verify Workflow Exceptions After archiving the document, this step will verify if the document was completed successfully or if it was rejected in order to direct the workflow to the proper final status for the document.
Workflow Completed Update document to final workflow step as success in case the workflow finished as expected.
Workflow Terminated with Exception Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.

PODMD: Purchase Order Document Migration Data

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the migration of legacy documents into RFMCS through REST API.

Table 2-15 PODMD Workflow Steps

Step Name Step Summary
Purchase Order Document Migration Data This is the initial step for the data migration workflow for Purchase Order related documents. It will be based on external integration service requests.
Validate Document Migration Data This step is part of the data migration workflow and will validate the basic mandatory data that must be provided as part of the request payload.
Split Document Migration Data This step is part of the data migration workflow and will split the document payload into separated files within the database, in order to fulfill the required structure of a regular document issued or received in RFMCS.
Purchase Order Fiscal Document Receive Initial step where the fiscal document is uploaded into the system.
Deduce Key Data Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.
Deduce Foundation Data Deduction of item and PO data. This step will use the PO number in the document, along with the supplier and location IDs already identified, to associate the items in the document with the PO available in Merchandising. The data produced in this step will be available in the fiscal document screen under “deducedData/orderData” at item level. The PO number, order status and quantity ordered are some of the data to be deduced.
Process Receipt Message Match receipt quantities. This step will perform several validations and comparisons and will end up generating a payload with the quantities received and any discrepancy quantity found:1: Verify the “reject receiving” scenario: If all items have the tag ReceiptDesc/Receipt/ReceiptDtl/unit_qty = 0 (zero), the validation will be finished, the tag receivedQt will be recorded with 0 for all items and the process will return this scenario to the workflow to be resumed from here.If at least one item has the unit_qty > zero, the process will move to the second validation.2: Validate if there is any discrepancy: a) Compare the shipped_qty and the unit_qty tags for all items. If all items have these quantities matching, this validation will pass.- ReceiptDesc/Receipt/ReceiptDtl/shipped_qty (quantity sent to be received based on the NF)- ReceiptDesc/Receipt/ReceiptDtl/unit_qty (quantity received)b) Verify the group ReceiptOverage. If any item is returned in this group, validation will indicate an overage discrepancy exists for the receipt. In that case a specific tag will be generated:- /nfeProc/NFe/infNFe/det/prod/deducedData/receiptData/overageQtThe overage will be calculated based on the below logic: If shipped_qty > (unit_qty + ReceiptOverageDtl/qty_received) then 0, else (unit_qty + ReceiptOverageDtl/qty_received) - shipped_qty = overageQt3: Verify the attribute DISCR_FISCAL_DOCUMENT for the receiving location.The attribute is created by "deduceKeyData" at "nfeProc/NFe/infNFe/dest/deducedData/setupData/discrFiscalDocument".Possible values returned are: NFD (Non-Fiscal Document) or RNF (Return Nota Fiscal). These values will determine the tags where the discrepancy quantity will be posted:- if NFD, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/creditNoteQt- if RNF, the discrepancy quantity will be recorded in the tag /nfeProc/NFe/infNFe/det/deducedData/receiptData/rnfQt4: Generate the tags for quantity received and discrepancies if any.
Create Tax Account Data This step will format the tax account response into the document payload to be used by the following steps.
Create Fiscal Ledger Data This step will generate a payload based on the fiscal document data to be used to update the fiscal ledger table.
Update Fiscal Ledger In This step will take the payload generated in Create Fiscal Ledger Data step and call the fiscal ledger update process. All fiscal ledger IDs created for the document will be returned as output for this step.
Archive Document This step will move the document to archive repository.
Delete Document Migration Data This step will remove the document migration data in case the workflow encouters errors that prevent the document to be successfully uploaded. The document data is removed although the workflow logs are kept.
Workflow Completed Update document to final workflow step as success in case the workflow finished as expected.
Workflow Terminated with Exception Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.

CODMD: Customer Order Document Migration Data

  • Country: Brazil

  • Document Type: Brazilian NFE model 55

  • Overview: This workflow is meant to support the migration of legacy documents into RFMCS through REST API.

Table 2-16 CODMD Workflow Steps

Step Name Step Summary
Customer Order Document Migration Data This is the initial step for the data migration workflow for Customer Order related documents. It will be based on external integration service requests.
Validate Document Migration Data This step is part of the data migration workflow and will validate the basic mandatory data that must be provided as part of the request payload.
Split Document Migration Data This step is part of the data migration workflow and will split the document payload into separated files within the database, in order to fulfill the required structure of a regular document issued or received in RFMCS.
Deduce Key Data Fiscal document issuer and destination entities must exist in Merchandising foundation data. This step is meant to deduce the Merchandising Foundation codes for the entities present in the fiscal document, either the entities in a document being received or a document being generated. For documents being received, the system will try to match the tax codes in the document payload with the fiscal attributes in order to identify the entity. For documents being generated this step will fetch the internal code for the entities from the request. If they are not found, this step will return null. In addition to the IDs, any “system behavior” attribute associated to either the location or the supplier will be deduced as part of this step. These attributes can be used in the next steps of the workflow to drive behavior.
Tax Issue Request This is an integration step that will call the 3rd party API for this scenario. This API is meant to submit the base document payload and have all taxes and fiscal codes applied by the third party tax system.
Tax Issue Response This is a validation of the 3rd party response. In this validation, the status of the response will redirect the workflow (SUCCESS, FAIL or ERROR)
Archive Document This step will move the document to archive repository.
Delete Document Migration Data This step will remove the document migration data in case the workflow encouters errors that prevent the document to be successfully uploaded. The document data is removed although the workflow logs are kept.
Workflow Completed Update document to final workflow step as success in case the workflow finished as expected.
Workflow Terminated with Exception Update document to final workflow step as exception in case the workflow didn´t finish as expected or in case of document rejection or cancelation.