Travel - Financial - P12

Visualizar Índice

01. OVERVIEW

An employee (in this scenario, they are called Participant) needs to take a corporate trip, for some reason, whatever it may be (ex: customer service/visit, business meeting, event). So this routine will have as main objective to register the request of this trip, considering relevant information to control the expenses of the trip and its policies.

In the items of the trip, you can select and justify/detail the following services:

• Flight
• Accommodation
• Car
• Road
• Insurance
• Other

When parameterized for approval after the request, a pending approval will be generated for the superior of the participants. Otherwise, it can be sent to the travel department (directly after the request or in a second moment through the sending option) and the trip will be generated automatically.

Example:

The company can decide to go through all the approvals, in this case the flow will be:

Or it may be that only one of the approvals is necessary, in this case we have:

02. EXAMPLE OF USE

Access the routine through: Updates > Travel > Travel Requests

The traveler must inform the basic data of the trip in the header of the request, such as origin and destination, departure and arrival dates, customer for assistance (if any), etc.
For each service, Participants and their respective Cost Entities must be informed.

Also, you can select which participants will receive an advance in the Advances tab.
The calculated value is a forecast and is displayed only when it is parameterized:

03. AUTOMATIC ROUTINE

For the execution of the automatic routine, we illustrated some features such as Inclusion (MyFA666Inc), Edition (MyFA666Alt) and Exclusion (MyFA666Del), in the following examples:

#INCLUDE "PROTHEUS.CH"
#INCLUDE "FWMVCDEF.CH"

//---------- Add travel request ----------//
User Function MyFA666Inc()

Local oModel := Nil
Local oModelFW3 := Nil
Local oModelFW4 := Nil
Local oModelFW5 := Nil
Local oModelFW6 := Nil
Local cFilAtu := ""

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Starts environment with requesting user

oModel := FWLoadModel("FINA666")
oModelFW3 := oModel:GetModel("FW3MASTER") // 
Travel header
oModelFW4 := oModel:GetModel("FW4DETAIL") // Services 
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participants
oModelFW6 := oModel:GetModel("FW6DETAIL") // Cost center
cFilAtu := xFilial("FW3")

oModel:SetOperation(MODEL_OPERATION_INSERT)
oModel:Activate()
// Fill in the travel request header
oModelFW3:SetValue("FW3_FILIAL",cFilAtu)
oModelFW3:SetValue("FW3_NACION","1")
oModelFW3:SetValue("FW3_CODORI","SP")
oModelFW3:SetValue("FW3_CODDES","RJ")
oModelFW3:SetValue("FW3_DTINI",StoD("20190702"))
oModelFW3:SetValue("FW3_DTFIM",StoD("20190705"))
oModelFW3:SetValue("FW3_CLIENT","001 ")
oModelFW3:SetValue("FW3_LOJA","01")
oModelFW3:SetValue("FW3_STATUS","0") // Open, initial status
// Fill in the service grid included in the travel request
oModelFW4:SetValue("FW4_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW4:SetValue("FW4_TIPO","1") // Aereo
oModelFW4:SetValue("FW4_OBS", “Customer visit")
// Fills grid of traveling participants
oModelFW5:SetValue("FW5_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000001")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Add advance to participant
oModelFW5:AddLine() // Add line for a second traveler
oModelFW5:SetValue("FW5_ITEM",StrZero(2,TamSX3("FW4_ITEM")[1]))
oModelFW5:SetValue("FW5_PARTIC","000002")
oModelFW5:SetValue("FW5_ADIANT",.T.) // Add advance to participant
// Fill in cost center grid
oModelFW6:SetValue("FW6_ITEM",StrZero(1,TamSX3("FW4_ITEM")[1]))
oModelFW6:SetValue("FW6_CC","002 ")
oModelFW6:SetValue("FW6_PORCEN",100)
oModelFW5:GoLine(1)
// Validation and recording of data, if consistent
If oModel:VldData() 
     oModel:CommitData()
     Conout("Travel request included successfully.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Validation error, travel request not included.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


//---------- Travel Request change ----------//
User Function MyFA666Alt()

Local aKeyFW4 := {}
Local oModel := Nil
Local oModelFW5 := Nil
Local oModelFW6 := Nil
Local cSolic := "0000000010"

RpcSetEnv("T1","D MG 01 ","richard.santos","1") // Initialize environment with requesting user

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Load data model with travel request positioned
oModel := FWLoadModel("FINA666")
oModelFW5 := oModel:GetModel("FW5DETAIL") // Participants
oModelFW6 := oModel:GetModel("FW6DETAIL") // Cost center
// Participant search key within the travel request
aKeyFW4 := { {"FW5_FILIAL",xFilial("FW5")},{"FW5_SOLICI",cSolic},{"FW5_ITEM","01"},{"FW5_PARTIC","000002"} }

oModel:SetOperation(MODEL_OPERATION_UPDATE)
oModel:Activate()
// Remove one of the travelers, in this case, participant 000002
If oModelFW5:SeekLine(aKeyFLE)
     oModelFW5:DeleteLine()
Else
     Conout("Traveler not found in this travel request.")
EndIf
// Change the cost center (automatically positioned on the first grid)
oModelFW6:SetValue("FW6_CC","003 ")

// Validation and recording of data, if consistent
If oModel:VldData() 
     oModel:CommitData()
     Conout("Travel request edited successfully.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Validation error, travel request not edited.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return


//---------- Delete travel request ----------//
User Function MyFA666Del()

Local oModel := Nil
Local cSolic := "0000000010"

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Starts environment with requesting user

dbSelectArea("FW3")
dbSetOrder(1)
dbSeek(xFilial("FW3")+cSolic)
// Load data model with travel request positioned
oModel:= FWLoadModel("FINA666")
oModel:SetOperation(MODEL_OPERATION_DELETE)
oModel:Activate()

// Validating and saving deletion
If oModel:VldData() 
     oModel:CommitData()
     Conout("Travel request deleted successfully.")
Else 
     VarInfo("",oModel:GetErrorMessage())
     Conout("Validation error, travel request not deleted.")
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return

04. TABLES USED

• FW3 - Request Header
• FW4 - Services (items)
• FW5 - Employees
• FW6 - Cost Entities

The Travel routine (FINA665) has all the information related to trips already issued via agency or requests for individual travel.

A trip is composed of:

Travel header, which has the start and end dates, origin and destination, customer to be served (when applicable), etc.

The advances tab lists the participants and the advances requested for each one.

In the tab of the trip itself, you will see the list of all orders placed.

When selecting a travel order item, a context per service is enabled with specific data for each one, such as: For a flight, there is Airline, Locator, Class, etc.; in the case of a hotel, there is the Hotel Name, check-in and check-out dates, etc. Possible services are:

• Flight
• Accommodation
• Car
• Road
• Insurance
• Other

Participants and related Cost Entities are also displayed.

A trip made on Reserve is integrated only when it is issued, that is, it is not possible to change its services in Protheus (dates, values, etc.). The only editable data are the Cost Entities. For more details, see the TOTVS X Reserve integration manual.

A trip generated by a Travel Request from Protheus, on the other hand, must have its service details informed by the travel department through the Verification option, since the request is an order for the purchase of the trip. If approval is enabled after the verification, a pending approval will be generated for the superior of the participants.

A trip with all its services and expenses properly paid and accounted for is eligible for billing. This process displays the travel costs that can be passed on to the customer, in whole or in part, and generates a sales order for the customer. If it is not applicable for the company segment, this step is not required.

Visualizar Índice

01. OVERVIEW

Advances (FINA667) are the amounts credited to employees to cover the costs of a trip, such as food, transportation, communication, etc.

These values are calculated through the configuration of the company's travel policy, which can be:

1. Fixed Amount: This is the fixed amount granted, usually for the transfer fee.
2. Amount with or without Overnight Stay: When the trip has a period within the same day, the amount of the advance without an overnight stay is calculated; if it exceeds a daily rate, it will be calculated with the amount with overnight stay.
3. Other currencies: Amounts in other currencies are usually granted by credit on traveler checks or currency purchase. For this case, Protheus does not make the calculation, but the credit amount of this advance must be informed. The conversion rates for the purchase of this currency into strong currency can be informed before or after the generation of the bill by configuring it in the Configuration Wizard.

In the Travel routine (FINA665), it is still possible to request advance complements. If an employee needs more money on a trip, this request can be made by selecting the trip and the option Individual Advance Payment. In this case, an additional advance linked to the trip is generated.

The bill generation rules, such as Prefix, Class, Due Date for regular and urgent advances (those requested outside the advance policy rule) are in the Configuration Wizard.

Advances requested either via Reserve, Travel Request or individually are not approved together with the trip and generate a pending issue for the superior of the traveler, if configured.

Example:

If the superior's approval and financial evaluation is necessary, we have:

Or, we will have the following scenarios if a step can be performed automatically:

02. EXAMPLE OF USE

The advance can be generated from the travel request (FINA666) by selecting this option on the Advances tab:

Or after the Trip has already been sent to the travel department (FINA665) by clicking on the "Request Advance” and selecting the participants that will received the advance:

Then, through the routine FINA667, the advance can be viewed, and follow its flow of actions:

03. AUTOMATIC ROUTINE

To execute the automatic routine, we illustrate the request for the advance after the trip is completed (MyFA667A), in the following example:

#INCLUDE "PROTHEUS.CH"
#INCLUDE "FWMVCDEF.CH"

//---------- Travel advance request ----------//
User Function MyFA667A()

Local aKeyFLC := {}
Local aUser := {}
Local oModel := Nil
Local oModelFLC := Nil
Local oModelFLD := Nil
Local cViagem := "0000000001"
Local cPartic := "000002"

RpcSetEnv("T1","D MG 01 ","claudio.ribeiro","1") // Starts environment with requesting user

dbSelectArea("FL5")
dbSetOrder(1)
dbSeek(xFilial("FL5")+cViagem) // Travel already requested

// Load data model with travel request positioned
oModel := FWLoadModel("FINA667A")
oModelFLC := oModel:GetModel("FLCDETAIL") // Participants
oModelFLD := oModel:GetModel("FLDDETAIL") // Advances
// Participant search key within the travel
aKeyFLC := { {"FLC_FILIAL",xFilial("FLC")},{"FLC_VIAGEM",cViagem},{"FLC_PARTIC",cPartic} }

oModel:SetOperation(MODEL_OPERATION_UPDATE)
oModel:Activate()
If FINXUser(RetCodUsr(),aUser,.T.)
     // Participant that will receive the advance
     If oModelFLC:SeekLine(aKeyFLC)
          oModelFLC:SetValue("OK",.T.)
          oModelFLD:LoadValue("FLD_DTSOLI",dDatabase)
          oModelFLD:LoadValue("FLD_DTPREV",DataValida(dDatabase+3))
          oModelFLD:LoadValue("FLD_SOLIC" ,aUser[1])
          oModelFLD:LoadValue("FLD_NOMESO",PadR(aUser[2],TamSx3("FLD_NOMESO")[1]))
          oModelFLD:SetValue("FLD_VALOR",400)
          oModelFLD:SetValue("FLD_MOEDA","1")
          oModelFLD:SetValue("FLD_JUSTIF","Advance for traveller")
          // Validation and recording of data, if consistent
          If oModel:VldData()
               oModel:CommitData()
               Conout("Advance requested successfully.")
          Else 
               VarInfo("",oModel:GetErrorMessage())
               Conout("Validation error, advance not requested.")
         EndIf
     Else
          Conout("Traveler not found in this trip.")
     EndIf
EndIf

oModel:DeActivate()
oModel:Destroy()
RpcClearEnv()

Return

04. TABLES USED

• FL5 - Travel
• FLC - Passengers
• FLD - Advances

With a trip in progress or after its completion, the traveler must account for expenses to the company.

Every trip, regardless of whether or not there is an advance, automatically generates a record in the Accountability routine (FINA677) linked to it.

A rendering of accounts has the basic data of a trip, such as its number, start and end dates, location, the customer that was served (if applicable), in addition to the cost entities and percentage of billing against the customer (if applicable), etc.

The employee may inform their expenses item by item, informing: expense, location, amount (in local currency or other and its conversion rate), quantity, cost entities, etc.

In addition, advances are listed on accountability and deducted from the total amount at the bottom of accountability.

The amounts spent, refundable, and the balance are also shown at the bottom, in the 3 currencies used by Protheus: local, dollar and euro.

Once finalized and forwarded to the travel department (after its inclusion or at a later time by the option to send to be checked), the travel department will check the accountability. Although the system already calculates the reimbursable amounts of expenses using the expense limit rule, if the verifier identifies an item in the statements that are outside the travel policy, they can post the discounts at this time and the amount to be returned/refunded is updated.

If the approval and/or release steps for financial are active, pending issues will be generated for the superior of the traveler and for the financial/travel department, respectively.

Example:

In the event that the whole process must pass through approval or verification, we have:

If any step can be performed automatically, we have:

Finally, in addition to the trips, the routine also allows individual rendering of accounts.

Service Verification is nothing more than a mirror of the invoice of a travel agency or of the direct suppliers themselves (airlines, hotels, car rental companies, etc.).

In this routine, you can select travel items, either by service or considering all types, for selecting and editing the payment sent on the invoice. With the orders duly selected and the amounts edited when necessary, a purchase order, an invoice, or a bill will be generated.

When there is an agreement between supplier and customer regarding the payment of travel expenses, Protheus allows you to bill both the complete trip and separate accountability.

The billing of a trip includes the costs of the contracted services (flight, hotel, car rental, insurance, and road) and the expenses of the employees involved. When all services are paid and the accountability is finalized and approved, the trip will be able to be invoiced against the customer, either partially or totally. However, it is possible to parameterize the travel rules and allow the advanced billing of a trip, as long as at least the rendering of accounts is finalized, since this is a variable cost, unlike the services that have a forecast in their hiring.

Individual accountability can be billed as soon as it is finalized.

For further information, see the integration manuals TOTVS X Reserve and PCO X Reserve.

The My Accountability app allows quick and easy control for corporate travelers to keep their rendering of accounts up to date while traveling.

With this app you can:

• Synchronize the travel accountability;
• Add individual accountability;
• Generate/manage expenses;
• Monitor the balance of accountability;
• Forward accountability for checking and approval;
• Monitor accountabilities already closed;
• Correct refused accountability.

The minimum of this process that needs to be configured for the application to work is:

• Registers
• Expenses (with or without binding by location and group)
• Access Group
• Participants
• Accountability (individual)

A complete travel process for the App includes:

• Registers
• Configuration Wizard
• Employee
• Access Group
• Expense
• Expense Group
• Travel Request (Via Reserve or Protheus integration)
• Travel
• Advance

• Accountability (the focus of the app)

For more information, access TOTVS My Accountability in the Applications area.

Access Google Play to download the app.