Payment confirmation or not

Routine called by the application to close the transactional cycle. It must be activated at the moment the Tax receipt is closed and receives as parameters an indicator of whether the transaction was completed or whether must be reversed. It also receives the fields that allow you to identify the transaction that is being completed.

This function should also be used to undo a transaction interrupted by a power outage or any other problem in the application.

This routine confirms or cancels ALL payments linked to the same Tax Coupon Number and the same Tax Date passed as a parameter.

void FinalizaFuncaoSiTefInterativo (Confirm, TaxCoupon, TaxDate,
TaxTime, ParamAdic);

ASCII interface#

void FinalizaFuncaoSiTefInterativoA (Confirm, TaxCoupon, TaxDate,
TaxTime, ParamAdic);
ParameterTypeStandard interfaceASCII InterfaceDescription
ResultOutput, by valueNot usedFixed 6Contains the result of the response to the routine call.
ConfirmEntry, by valueshortFixed 1Indicates whether the transaction should be confirmed (1) or reversed (0)
Tax CouponEntry, by valuechar *Max 20Tax Coupon number corresponding to the sale
Tax DateEntry, by valuechar *Fixed 8Tax Date in the format YYYMMDD
TaxTimeInput, by valuechar *Fixed 6Fiscal Time in the format HHMMSS 6*

Example: A sale made using the IniciaFuncaoSiTefInterativo function, passing Function 0 as parameters, Value 10.00, Tax Coupon 12345, Tax Date 20150101, Tax Time 121500. When confirming the transaction, the function FinalizaFuncaoSiTefInterativo must be called using the following parameters: Confirm 1*, Tax Coupon 12345, Fiscal Date 20150101, Fiscal Time 121500**, ParamAdic as empty/NULL, as there is no additional data.

The ParamAdic parameter can be used in the following situations:


6 The TaxTime parameter is not used as a “key” for a tax document.


4.1 Completion of individual payments on the same tax coupon#

For each payment, CliSiTef returns in TypeField 161 (Payment number in the coupon) a index/counter corresponding to the payment.

To (non-)confirm a specific payment within a tax coupon, the automation must inform this value to the FinalizaFuncaoSiTefInterativo routine as an additional parameter:

{NumeroPagamentoCupom=XXX}

where XXX is the payment number, previously returned in FieldType 161.

4.2 Completion of payments from a given network in the same tax coupon#

To (non) confirm payments relating to a specific authorizing network, you must go through in the routine FinalizaFuncaoSiTefInterativo the following additional parameter:

{RedeConfirmacao=XXX}

where XXX is the authorizing network number.

4.3 Attach data regarding payment methods for a transaction (NFPAG)#

To attach data relating to payment methods for a transaction, the following fields must be captured: 161 (Payment number on the coupon), 730 (Maximum number of payment methods), 731 (Payment types enabled) and 732 (Data to be collected for the payment type), returned in the transaction flow, and pass it to the routine FinalizaFuncaoSiTefInterativo through the additional parameters NumeroPagamentoNFPAG and NFPAG.

{NumeroPagamentoNFPAG=X}{NFPAG=Y}

Where:

X = Payment number in the coupon (Field 161)

Y = Data relating to payment methods (See description below)

Note: In this case, all payments on the same tax coupon will all be confirmed or not confirmed.

NFPAG parameter description:

{NFPAG=FPAG1;FPAG2; FPAG3;...;FPAGn;}

Where FPAGn has the following content:

If there is data to be collected
TipoN:ValorN:IDColetaN1:DadoColetaN1-IDColetaN2:DadoColetaN2-...-IDColetaNn:DadoColetaNn
If there is no data to collect
TipoN:ValorN

=> TypeN: indicates the payment method used (Field 731, as per the table below)

=> ValueN: indicates the value used with this payment method, with two decimal places, without the comma

=> IDCollectionNn: indicates the ID of the field that was collected by the POS (Field 732, as per the table below)

=> DataCollectionNn: indicates the content collected by the POS for this field Note: The consistency of the values ​​(sum of the various payment methods used, totaling the value of the transaction carried out) must be done by the POS.

Example:

At the end of a transaction worth R$50.00, returning field 730 equal to 2 and fields 731 and 732 indicating that you accept the following forms of payment: Cash (no data to be collected); TEF Debit (need to send the Destination Network, Host NSU, Host Date and TEF transaction Origin Code) and TEF Credit. The field 730 equal to 2, indicates that in the NFPAG parameter a maximum of 2 forms of information can be sent. payment.

The POS, in turn, upon confirmation of the transaction, will send the payment methods that were effectively used: R$30.00 was paid in cash and R$20.00 was paid with a Redecard debit card (Rede Destination = 5; Host NSU = 123456789; Host Date = 12/15/2008; Origin Code = 000000000000001).

{NFPAG=00:3000;02:2000:03:5-07:123456789-08:15122008-09:000000000000001;}

Note: All payment methods must be separated by ; (semicolon), including the last one must be terminated by ;

|730| Maximum number of payment methods to be sent through the NFPAG parameter. 0 for no limit.| | 731 | Payment Type Enabled, repeats “n” times, where “n” is the number of payment methods enabled:

- 00: Cash
- 01: Check
- 02: TEF Debit
- 03: TEF Credit
- 04: Carrefour Gift Card (Prepaid)
- 05: Carrefour Bonus Card
- 06: Carrefour Card
- 07: Withdrawal for payment
- 08: Withdrawal
- 09: DCC Carrefour
- 10: Electronic Ticket
- 11: Paper Ticket
- 12: Digital Wallet
- 13: Pix
- 50: TEF Card
- 77: Reserved Field
- 98: No Payment
- 99: Other Forms | | 732 | Data to be sent for the Payment Type (Field 731) previously returned, repeats “n” times, where “n” is the number of data to be sent for the respective Payment Type:

< br/> - 00: Reserved Field
- 01: Check Entry Type
. ‘0’: CMC-7 reading
. ‘1’: typing the first line of the check
. ‘2’: typing CMC-7
- 02: Check Data
. CMC-7 read or typed, or
. Typing the first line of the check, with the following format: Clearing (3), Bank (3), Agency (4), C1 (1), Current Account (10), C2 (1), Check Number (6) and C3 (1), in this order.
- 03: Destination Network (Field 131)
. Identification of the authorizer of the TEF transaction.
- 04: SiTef NSU of the TEF transaction (Field 133)
. Identification of the TEF transaction in SiTef.
- 05: SiTef date of the TEF transaction
. Not used (Future use).
- 06: Company Code for the TEF transaction SiTef code for the Company used in the TEF transaction.
- 07: NSU of the TEF transaction Host (Field 134) Identification of the TEF transaction on the Host.
- 08: Host Date of the TEF transaction (Field 105) Date of the TEF transaction on the Host, in DDMYYY format.
- 09: Origin Code of the TEF transaction (Field 157) Establishment Code of the TEF transaction.
- 10: Service Z of the TEF transaction (Field 1) Value of service Z returned by the Sit module responsible for the TEF transaction.
* Pass only the confirmation data, removing the SiTef index data and SiTef address if any, follow the format of this field: ConfirmationData;SiTefIndex;SiTefAddress

Another option would be to use the following configuration in the CliSiTef.ini file:
[General]
DevolveConfirmacaoExtendida=0

Using this configuration, even in the case of multiple SiTef only Service Z will be returned in field 1 of the CliSiTef, this way it is also not necessary to change the field value when adding the NFPAG prefix.
- 11: Authorization Code for the TEF transaction (Field 135)
Host Authorization Code for the TEF transaction.
- 12: Check Value Total Check Value. The same check can be used to pay more than one bill
- 13: Destination Network – Complement ID 03 Complement (see description below)
- 14: Card Flag
Flag of the Card used in the TEF transaction
15: Payment Type
'00' – cash
'01' – Post-dated
'02' - Installed in installments by the establishment
'03' - Installed in installments by the administrator
16: Digital Wallet ID
(returns in field 106 of Sale with Digital Wallet)

The ID 13 field, unlike the others, does not indicate a field that must be collected, it only works as a a complement to the ID 03 field, sending the list of permitted Destination Networks, in the following format:

IDColetaNn(Network1, Network2,..., NetworkN)

In other words, if only the ID field 03 is present, the Destination Network must be collected, without any restriction on the Networks that can pay the Recharge. However, if the ID 03 and 13, the first indicates that the Destination Network must be collected, while the second indicates which Destination Networks must be collected. are allowed for the payment of the Recharge.

Furthermore, as the collection was indicated by ID 03, the POS must send the Destination Network to the Sit also through of this ID (and not ID 13).