Mensagens de vendas varejo podem ser representadas por Cupom Fiscal (quando tratar-se de mercadorias) e RPS – Recibo Provisório de Serviços (quando tratar-se de serviços), serão originadas no sistema Bematech, Bematech PDV para cupons fiscais e Bematech VHFpara RPS. O sistema Protheus receberá as informações e gerará as informações de backoffice, como as informações fiscais devem refletir exatamente o que consta no cupom fiscal, não será realizado nenhum cáluculo de imposto, serão mantidas as informações integradas.
Ao receber a venda, o sistema Protheus irá gravar os dados de cabeçalho, itens (produtos e serviços) e parcelas para a gravação dos arquivos SL1, SL2 e SL4, respectivamente, na sequencia, os dados no backoffice (Fiscal, Estoque e Financeiro) serão gerados através da rotina LJGRVBATCH, previamente configurada conforme a seção Demais Configurações.
Uma mesma mensagem de vendas conterá apenas informações de serviços (RPS) ou produtos (Cupom Fiscal), nunca deverá trafegar um XML com informações de ambos os tipos.
A única alteração que será possível efetuar em uma venda já integrada é o código de reserva do hóspede, outras alterações não serão permitidas. Se isto for necessário, deve-se efetuar o cancelamento da mesma no sistema Bematech e após, reenviar a venda, isto se deve ao processo de geração de informações do backoffice através do LjGrvBatch, uma vez gerado, não pode ser revertido, somente cancelando-se e reenviando a venda, então o processo será todo refeito.
Se for utilizado o tipo de venda NFCe (Nota Fiscal de Consumidor Eletrônica), deve-se configurar a estação de trabalho para esta modalidade, neste caso, não é utilizado impressora fiscal (ECF), o envio do cupom para a Sefaz será efetuado pelo sistema Bematch e a chave de transmissão será eas a recebernviada para armazenamento no sistema Protheus, o processo de geração do backoffice através do LjGrvBatch permance o mesmo.
No momento que a venda for integrada ao Protheus, estará com o status em aberto (L1_SITUA = RX), após o processamento do LjGrvBatch, se a geração dos arquivos BackOffice deram certos, o status da venda mudará para finalizada (L1_SITUA = OK), se houverem erros, o status será alterado para erro (L1_SITUA = ER). Neste último caso, deve-se verificar o motivo do erro pelos logs gerados pelo Protheus e efetuar a correção, após alterar manualmente o campo L1_SITUA para o valor RX, desta forma, será reprocessada.
Deve-se preencher o parâmetro MV_LJFORHT para que sejam adicionados as formas de pagamento que não irão gerar financeiro. Por padrão, este parâmetro vem alimentado com as informações CQ|AF. As Formas de Pagamento deverão constar na tabela SX5-24 do sistema Protheus e deverão ser adicionas separadas pelo caractere “|”, exemplo:
Se desejar que a Forma de Pagamento BOL (Boleto) não gere títulos financeiros, o parâmetro MV_LJFORHT ficará CQ|AF|BOL. Deve-se também adicionar a forma de pagamamento CI (consumo interno) nesse parâmetro.
Para que as informações fiscais (ICMS e ISS) sejam geradas, será necessário configurar geração de Livros Fiscais no cadastro de TES (F4_LFICM e F4_LFISS).
Não será necessário envio de valores relacionados a troco, devem ser informados os valores reais a serem recebido.
Cupom Fiscal
Hóspede com Reserva
A inclusão das Vendas referentes ao consumo de quarto do hóspede com reserva, será um cupom fiscal com a forma de pagamento Crédito ao Quarto (novo código CQ na tabela 24 – SX5), movimentarão estoque (configurar no cadastro da TES do sistem Protheus), mas não gerarão títulos no financeiro pois o acerto será efetuado no fechamento da reserva (check-out). Caso cliente opte em pagar o consumo com outra forma de pagamento, estes cupons fiscais gerados também serão enviados ao sistema Protheus com suas devidas formas de pagamento, movimentarão estoque e gerarão financeiro.
Passante
Caracteriza-se como passante o cliente que não possui reserva e fará consumos no hotel. A integração das vendas referentes a esses consumos deverão ser enviadas ao Protheus cupom a cupom, indicando um cliente padrão, que por sua vez deve já ter sido previamente configurado nos parâmetros MV_CLIPAD e MV_LOJAPAD do backoffice e configurado tais valores no Bematech. Esses movimentos deverão gerar títulos no financeiro do Protheus.
Se o cliente passante desejar Cpf na nota, a informação deverá ser enviada na integração e será armazenada no sistema Protheus.
Para integrações de Cupom Fiscal será obrigatório o envio da informação do PDV que efetuou a venda.
RPS
Check-out
Após a realização do check-out no sistema Bematech (VHF), este enviará ao sistema Protheus a integração do Recibo Provisório de Serviços (RPS), o XML dessa integração será no mesmo layout do cupom fiscal, diferenciando apenas os produtos, que agora serão serviços.
Nesta integração, produtos são caracterizados como serviços através de seu tipo (B1_TIPO), sendo eles: (SV, MO, GE, GG).
A transmissão ao SEFAZ de um RPS integrado será realizada pelo Protheus, manualmente, após a integração do mesmo ou automaticamente através do AutoNFSE. Para maiores informações sobre o AutoNFSE, ver o link que segue: http://tdn.totvs.com.br/display/PROT/TUODTH_DT_Auto_NFS-e.
A série do RPS deve estar configurada para ter o mesmo tamanho em ambos os sistemas envolvidos, conforme necessidade do cliente.
Quando houver adiantamento na conta do cliente que está realizando o check-out, serão informadas na integração do RPS, uma forma de pagamento do tipo RA (novo código na tabela 24 – SX5) para cada movimento de adiantamento que será utilizado no pagamento da fatura em questão, em cada forma de pagamento RA, deverá obrigatoriamente ser informado o código do adiantamento integrado para compensação no Protheus.
Ao receber uma forma de pagamento do tipo RA, o Protheus irá gerar um título do tipo R$ e compensará o RA com esse título, atualizando assim o saldo do adiantamento.
Os acréscimos relacionados a RPS deverão ser enviados ao sistema Protheus pela tag IncreaseValue, desta forma, os valores serão acrescentados ao valor total da venda.
Para integrações de RPS será obrigatório enviar a Série do Documento que será gerado.
Caso sejam necessários o envio de informações adicionais de hotelaria, como hóspede principal, demais hóspedes, grupo etc, esses deverão ser informados pelo sistema CMNet na integração e serão gravados na tabela MH3 do Protheus.
Se forem necessários o envio de informações de pensões, como tipo de pensão, valor de pensão, café da manhã etc, deverão ser informados pelo sistema CMNet na integração e serão gravados na tabela MH4 do Protheus.
Vendas com cartão
As vendas realizadas com cartão (débito ou crédito) podem ocorrer de duas formas diferentes: Através de TEF ou através de uma transação manual.
Quando a venda é ffeita com TEF, serão informados no RPS, obrigatoriamente, os campos característicos do TEF, que são: NSU, , Data, Hora. Além desses campos, também haverá na mensagem o código da administradora financeira relacionada ao cartão em questão. Com essas informações, o Protheus irá gerar um título financeiro do tipo CC ou CD (crédito ou débito), em nome da administradora informada.
Para definição do valor cobrado pela administradora do cartão, o Protheus irá utilizar a taxa de cobrança configurada no cadastro de administradora financeira do backoffice. Essa taxa será deduzida do valor líquido do título gerado no financeiro, ficando o valor real (E1_VLREAL) o valor total com a taxa. Para isso, é necessário que antes seja configurado o parâmetro MV_LJGERTX para não gerar contas a pagar com a taxa gerada, conforme especificado na seção Parâmetros Gerais.
A data de vencimento do título será definida pelo Bematech e já enviada corretamente ao Protheus.
Caso seja uma venda parcelada com cartão, será enviada cada parcela sendo uma forma de pagamento separada na mensagem de vendas. Cada uma dessas formas terá uma data de vencimento distinta, definida pelo Bematech.
Para as vendas com cartão manual, sem TEF, se aplicam as mesmas regras acima com exceção dos campos característicos do TEF (NSU, Data, Hora). Para esse caso, haverá no Bematech um campo para inserção manual da NSU, pois essa informação é obrigatória para posterior conciliação dos movimentos do cartão.
Importante: Para a correta transmissão dos RPS para geração de NFS-e, deve-se atentar as regras de cada prefeitura no que diz respeito a aglutinação de serviços similires na nota e utilizar o parâmetro MV_ITEMAG configurado corretamente.
Importante: Para personalização da descrição de serviço que sairá na nota a ser transmitida para a prefeitura, pode-se utilizar a rotina de personalização de descrição de serviços no módulo de faturamento do Protheus (SigaFAT > Atualizações > NFS-e e NF-e > NFS-e > Personalização > Descrição NFS-e, FATA910). Através dela, pode-se inserir informações especificas de hotelaria na descrição do serviço, como numero da reserva, nome dos hóspedes, nome do grupo de reserva, etc. Para isso, deve utilizar a tabela MH3 do Protheus, que contem os dados de reserva do RPS.
Informações da integração com mensagem única
Identificador da Mensagem: RetailSales
Versão: 1.001
Módulo Protheus: SigaLoja – Controle de Lojas
Módulo Bematech: PDV/VHF
Tipo de Envio: Assíncrono
Tags utilizadas | Protheus | Bematech | ||||||
Tabela | Campo | Tabela | Campo | |||||
BusinessContent | ||||||||
CompanyId | cEmpAnt |
|
| |||||
BranchId | SL1 | L1_FILIAL |
|
| ||||
InternalId | XXF | XXF_INTVAL |
|
| ||||
ComissionPercent | SL1 | L1_COMIS |
|
| ||||
CustomerInternalId | XXF | XXF_INTVAL |
|
| ||||
TotalPrice | SL1 | L1_VLRTOT |
|
| ||||
DiscountValue | SL1 | L1_DESCONT |
|
| ||||
NetPrice | SL1 | L1_VLRLIQ |
|
| ||||
CashValue | SL1 | L1_DINHEIR |
|
| ||||
ChecksValue | SL1 | L1_CHEQUES |
|
| ||||
CardsValue | SL1 | L1_CARTAO |
|
| ||||
DebitValue | SL1 | L1_VLRDEBI |
|
| ||||
CovenantValue | SL1 | L1_CONVENI |
|
| ||||
VouchersValue | SL1 | L1_VALES |
|
| ||||
FinancedValue | SL1 | L1_FINANC |
|
| ||||
OthersValue | SL1 | L1_OUTROS |
|
| ||||
InputValue | SL1 | L1_ENTRADA |
|
| ||||
IssueDataDocument | SL1 | L1_EMISSAO |
|
| ||||
IssueTime | SL1 | L1_HORA |
|
| ||||
DocumentId | SL1 | L1_DOC |
|
| ||||
SerieId | SL1 | L1_SERIE |
|
| ||||
GrossPrice | SL1 | L1_VALBRUT |
|
| ||||
CommodityPrice | SL1 | L1_VALMERC |
|
| ||||
DiscountPercent | SL1 | L1_DESCNF |
|
| ||||
OperatorInternalId | XXF | XXF_INTVAL |
|
| ||||
OperatorId | SL1 | L1_OPERADO |
|
| ||||
IcmsValue | SL1 | L1_VALICM |
|
| ||||
IssValue | SL1 | L1_VALISS |
|
| ||||
CurrencyRate | SL1 | L1_TXMOEDA |
|
| ||||
Change | SL1 | L1_TROCO1 |
|
| ||||
StationInternalId | XXF | XXF_INTVAL |
|
| ||||
StationId |
|
|
|
| ||||
DiscountPaymentTerm | SL1 | L1_DESCFIN |
|
| ||||
IcmsRetained | SL1 | L1_ICMSRET |
|
| ||||
CreditValue | SL1 | L1_CREDITO |
|
| ||||
KindOfDocument | SL1 | L1_ESPECIE |
|
| ||||
Md5 |
|
|
|
| ||||
PisValue | SL1 | L1_VALPIS |
|
| ||||
CofinsValue | SL1 | L1_VALCOFI |
|
| ||||
EletronicInvoiceComplement |
|
|
|
| ||||
PersonalIdentification | SL1 | L1_CGCCLI |
|
| ||||
KeyAcessNfe | SL1 | L1_KEYNFCE |
|
| ||||
IncreaseValue | SL1 | L1_DESPESA |
|
| ||||
ListOfSaleItem | ||||||||
ItemCode | SL2 | L2_PRODUTO |
|
| ||||
ItemOrder | SL2 | L2_ITEM |
|
| ||||
Quantity | SL2 | L2_QUANT |
|
| ||||
UnitPrice | SL2 | L2_VRUNIT |
|
| ||||
ItemPrice | SL2 | L2_VLRITEM |
|
| ||||
DiscountPercentage | SL2 | L2_DESC |
|
| ||||
DiscountAmout | SL2 | L2_VALDESC |
|
| ||||
OperationCode | SL2 | L2_CF |
|
| ||||
ItemIcms | SL2 | L2_VALICM |
|
| ||||
ItemIss | SL2 | L2_VALISS |
|
| ||||
IcmsBase | SL2 | L2_BASEICM |
|
| ||||
Increase | SL2 | L2_VALACRS |
|
| ||||
ItemAliquot | SB1 | B1_PICM |
|
| ||||
ItemAliquotPis | SB1 | B1_PPIS |
|
| ||||
ItemAliquotCofins | SB1 | B1_PCOFINS |
|
| ||||
ItemPis | SL2 | L2_VALPIS |
|
| ||||
ItemCofins | SL2 | L2_VALCOFI |
|
| ||||
Lodging |
|
|
|
| ||||
|
| ListOfSaleCondition |
|
| ||||
CurrentAccount | SL4 | L4_CONTAHT |
|
| ||||
DateOfPayment | SL4 | L4_DATA |
|
| ||||
PaymentValue | SL4 | L4_VALOR |
|
| ||||
PaymentMethodInternalId | XXF | XXF_INTVAL |
|
| ||||
PaymentMethodId | SL4 | L4_FORMA |
|
| ||||
FinancialManagerInternalId | XXF | XXF_INTVAL |
|
| ||||
FinancialManagerId | SL4 | L4_ADMINIS |
|
| ||||
CardNumber | SL4 | L4_NUMCART |
|
| ||||
SerieCheck | SL4 | L4_SERCHQ |
|
| ||||
AgencyCheck | SL4 | L4_AGENCIA |
|
| ||||
AccountCheck | SL4 | L4_CONTA |
|
| ||||
DocumentOfIdentification | SL4 | L4_RG |
|
| ||||
PhoneNumber | SL4 | L4_TELEFON |
|
| ||||
EftDate | SL4 | L4_DATATEF |
|
| ||||
EftTime | SL4 | L4_HORATEF |
|
| ||||
EftDocument | SL4 | L4_DOCTEF |
|
| ||||
EftAutorization | SL4 | L4_AUTORIZ |
|
| ||||
EftCancellationDate | SL4 | L4_DTCANC |
|
| ||||
EftCancellationTime | SL4 | L4_HORCANC |
|
| ||||
EftCancellationDocument | SL4 | L4_DOCCANC |
|
| ||||
EftInstitute | SL4 | L4_INSTITU |
|
| ||||
UniqueSerialNumber | SL4 | L4_NSUTEF |
|
| ||||
EftParcel | SL4 | L4_PARCTEF |
|
| ||||
ReturnContent \ ListOfInternalId \ InternalId | ||||||||
Name | - | - |
|
| ||||
Origin | XXF | XXF_EXTVAL |
|
| ||||
Destination | XXF | XXF_INTVAL |
|
|