Árvore de páginas

Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.
Notawarning
titleCadastro De/Para Venda
Dica
titleIntegrando Inventario

Abaixo iremos mostrar como configurar o Processo de Venda no Protheus para integra-lo com o sistema Totvs Live. Siga o Passo a Passo.

Dica
titleInutilização

As inutilizações também são integradas através do processo de venda, do assinante LIVE, para mais detalhes: Inutilização NFCE Integrada LIVE

Nota
titleImportante!

Realize este processo para tabela:

SL1 - Orçamento

Nota
titleImportante! FECP
  • Será considerado na alíquota de ICMS o valor de Alíquota de FECP enviado no XML
  • E assim Calculando os novos valores para gravação quando existir o FECP para o ESTADO.
Nota
titleImportante! CAMPO L1_VEND
  • Para gravação do campo L1_VEND, quando o vendedor for identificado na venda irá considerar o vendedor da primeira linha do Item recebido do live (Primeiro registro da tabela SL2.)

Alterando tamanho do campo:

  Para alterar o tamanho do campo L1_UMOV na Tabela SL1 - Orçamento  veja o exemplo abaixo:
  (informação) Importante: O tamanho do campo deve ser igual 36.

Image Removed

Cadastrando o Processo de Venda

Observações
  1. Para vendas NFCE com desconto NO TOTAL, a integração considerará sempre como desconto NO ITEM, pois o xml no NFCE-Sefaz sempre considera o desconto no item , independente da forma como foi praticado o desconto no PDV. Para evitar impactos de base de cálculos nos impostos , não será realizada nenhuma conversão de valores.
  2. Campo: D2_CSOSN Não é gravado em uma venda pelo venda assistida, porem via integração é, após analise identificamos que o campo é utilizado somente no NFESEFAZ para envio de uma mensagem nas observações da nota, portanto não foi encontrado nenhum impacto no processo de venda.
  3. Os campos TOTFED/TOTEST/TOTMUN da SL1/SL2 não são gravados na venda integrada do PDVSync por não existirem estes campos nas tabelas da base do PDV, e conforme verificado e alinhado com o PO, os campos no PROTHEUS não geram impacto nos livros fiscais. 
  4. Na venda PDVOMNI os cálculos para informativo da lei da transparência são arredondados, já no Protheus os campos TOTFED/TOTEST/TOTMUN não são arredondados.
  5. Campos L2_DESC\D2_DESC de percentual de desconto não são gravados na integração, porem não interferem nos cálculos, porque os valores de desconto estão OK.
  6. Campo L2_PICM não grava no registro do PROTHEUS, porem no registro da integração grava o que esta correto. SF2, SD2 e para frente grava corretamente.
  7. Quando algum item estiver com o CST 60 ou CSOSN 500 em venda com SAT, ficou definido que os campos abaixo terão seu conteúdo calculado diretamente pela MATXFIS, porque pelo XML SEFAZ não é possível chegar nestes valores.
    1. F2_VALICM, F2_ICMSRET, F2_BRICMS
    2. D2_VALICM, D2_ICMSRET, D2_BRICMS, D2_ALIQSOL
    3. F3_VALICM, F3_ICMSRET, F3_BASERET
    4. FT_VALICM, FT_ICMSRET, FT_BASERET
    5. Campos da SL1 e SL2 não serão atualizados.
  8. Para retenção de ICMS com base reduzida, alguns cálculos são necessários arredondamento para o valor do ICMS ficar correto nos livros fiscais, com isso os parâmetros abaixo são necessários:
    1. https://centraldeatendimento.totvs.com/hc/pt-br/articles/360023920652-CROSS-Segmentos-TOTVS-Backoffice-Linha-Protheus-FIS-Arredondamento-de-Impostos
    2. https://centraldeatendimento.totvs.com/hc/pt-br/articles/235534847-Como-evitar-diferen%C3%A7a-de-centavos-no-arredondamento-dos-ambientes-SIGALOJA-e-SIGAFRT-
    3. Encontrado diferença de 0,01 centavo na base de calculo de ICMS reduzido entre PDVOMNI e Protheus. Estamos acatando o valor enviado via xml pelo PDVOMNI.
  9. Para PIS COFINS Via Apuração a configuração do cliente deve ser, A1_RECPIS = "N" e A1_RECCOFI = "N". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPS2, L2_BASEPS2, L2_ALIQPS2, L2_VALCF2, L2_BASECF2, L2_ALIQCF2
  10. Para PIS Cofins via Retenção a configuração do cliente deve ser A1_RECPIS = "S" e A1_RECCOFI = "S". Com isso serão gravados os campos abaixo na venda:
    1. L2_VALPIS, L2_BASEPIS, L2_ALIQPIS, L2_ALIQCOF, L2_BASECOF, L2_VALCOFI
  11. Os acréscimos contidos na venda integrada serão informados no campo L2_DESPESA, pois a venda do PDVOmni realiza os acréscimos das vendas destacando os valores de despesa na tag vOutro do XML.
    1. Para soma de acréscimo/despesa na base de calculo acionar o parâmetro MV_FRTBASE e campos na tes usada no produto, conforme documentação do parâmetro: IMP0030_Despesas_acessórias_( seguro_e_frete)_para_base_dos_impostos_PIS/COFINS_(Apuração)
  12. Em caso de reintegração de venda cancelada no Protheus deverá ter intervenção manual, deletando a Tabela (MEP- em caso de venda parcelada) e as tabelas SFT , SF3 para ajuste de livro fiscal.
  13. PDV OMNI não atende ICMS90, mais detalhes:
    Jira
    serverJIRA
    serverId0c783de1-186e-383b-975c-a1acd7d76cb5
    keyDVARLOJ1-7453
  14. MV_PSHMOV - Parâmetro que habilita a geração de NCC movimentação financeira. = .T. - Quando a NCC é online via API, como por exemplo é utilizado no PdvSync o conteúdo do parâmetro deverá ser igual a .F. → Falso. 
  15. A gravação do campo L4_NSUTEF não terá nenhum tipo de tratamento, será exatamente o conteúdo do campo NsuHost (Nsu do host autorizador) retornado pelo PDVOmni. Atualmente o PDVOmni não tem a informação do TEF de Nsu do SiTef e vimos que esta informação só é utilizada pelo Sitef.
    1. Para qualquer alteração no conteudo do campo deve-se fazer via customização utilizando os pontos de entrada no MVC do fonte RetailSales.
  16. Para manter o legado (compatibilidade com TotvsPDV), os campos do cabeçalho: L1_VENDTEF, L1_DATATEF, L1_HORATEF, L1_DOCTEF, L1_AUTORIZ, L1_INSTITU, L1_NSUTEF, L1_TIPCART e L1_PARCTEF, serão salvos com os dados do ultimo pagamento de alguma destas formas de pagamento CC|CD|PD|PX.
  17. Para vendas onde foi utilizado como pagamento NCC (Crédito de Devolução), em caso de cancelamento, o valor na NCC/Crédito não é estornado, deve ser realizado processo manual no ERP para estorno da baixa ou geração de novo crédito. 


Cadastrando o Processo de VENDA

Para integrarmos o processo VENDA com o PdvSync Para integrarmos o Venda com o Totvs Live primeiramente é necessário acessar o cadastro do Processo para verificar se Venda o processo VENDA foi criado automaticamente no Protheus.

...

2- Aguarde a criação automática do cadastro de processo referente ao Vendaa VENDA.  

3- Verifique se foi criado as Informações abaixo:

Processo: Venda VENDA

Tabela: SL1

Chave: L1_FILIAL+L1_NUM

Vinculando o Processo de

...

VENDA ao Assinante

...

PdvSync

1- No módulo 12 (Controle de Lojas), acesse Atualizações/ RMI/ Cadastros/ Assinantes.

2- Com o assinante Live  PdvSync previamente cadastrado, posicione no assinante Live PdvSync e clique em alterar.

3- Na guia Assinantes x Processos, preencha os seguintes campos:

Processo: VendaVENDA

Ativo: Sim

Tipo Process: Busca

Filiais Proc: Informe o código das filiais que deseja Buscar o Processo

Configuração: Preencha esta campo de acordo com a sua URL da API  Venda Preencha este campo com as configurações do processo de VENDA. A URL deve ser preenchida com o caminho da API de VENDA, como mostra o exemplo abaixo:

Avisocode
titleAviso!

A tag ValeTroca deve ser preenchida com o código da forma de pagamento Vale Troca, é necessário verificar no Live qual o código correto.

Para visualizar a Configuração acesse o link abaixo:
https://github.com/totvs/protheus-smart-hub-layouts/blob/39e02620bcaebc22bcae754a2f2dd08476fa1d06/pdvsync/configuracao/busca_venda.json
Bloco de código
{
    "url": "http://XXXXXXXX/XXXXXXX/LiveConnector/FacadeIntegracao.svc?wsdl",
    "operacao":"RecuperarCupomFiscalLC_Integracao_Xml",
    "tagretorno":"<LC_TicketCupomFiscal>",
    "SL2":"self:oRegistro:_Itens:_Lc_ItemCupomfiscal",
    "SL4":"self:oRegistro:_FormasPagamento:_Lc_FormaPagamento",
    "ValeTroca":""
}


Layout Envio: Preencha este campo de acordo com o exemplo abaixo: Lembrando que é permitido utilizar macro execuções no Layout abaixo, após o &. 

Bloco de código
&"<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/' xmlns:liv='http://LiveConnector/'>
   <soapenv:Header />
   <soapenv:Body>
      <liv:RecuperarCupomFiscalLC_Integracao_Xml>
         <liv:codigoSistemaSatelite>" + self:oConfAssin['sistemasatelite'] + "</liv:codigoSistemaSatelite>
         <liv:xmlIdentificacao><![CDATA[<?xml version='1.0' encoding='utf-8'?><LC_Identificacao><Chave>" + self:cToken + "</Chave><CodigoSistemaSatelite>" + self:oConfAssin['sistemasatelite'] + "</CodigoSistemaSatelite><Data/><Hora/></LC_Identificacao>]]></liv:xmlIdentificacao>
      </liv:RecuperarCupomFiscalLC_Integracao_Xml>
   </soapenv:Body>
</soapenv:Envelope>"
titlePara visualizar o Layout Envio acesso o link abaixo:
https://github.com/totvs/protheus-smart-hub-layouts/blob/39e02620bcaebc22bcae754a2f2dd08476fa1d06/pdvsync/envio/busca_venda.json


Layout Publicação: Layout Layout Publicação:  Layout que será utilizado para gerar a Publicação (tabela MHQ), especificamente o campo MHQ_MENSAGObs: Os campos abaixo L1_CLIENTEL1_LOJA são configuráveis conforme a sua necessidade após o &. No exemplo abaixo está configurado

para quando o Cliente for não identificado no Live-Conector no Protheus não vai existir De/Para gravado então será utilizado o Cliente Padrão

configurado no parâmetro MV_CLIPADMV_LOJPAD.

Bloco de códigotip
titleInstrução De/Para

Caso seus códigos de Produto sejam iguais entre Live x Protheus não usar a função "DePara" na tag L2_PRODUTO. 

Exemplificando o uso da tag:  "L2_PRODUTO": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_CodigoProduto:Text"

Dica
titleInstrução L1_DOC

O tamanho e o preenchimento com zeros ( "0" ) a direita nesse campos respeita o tipo de documento, a partir da sigla do modelo

(campo self:oRegistro:_SiglaModelo:Text recebido pela integração.

Bloco de código
{
    "L1_FILIAL": "&self:DePara('SM0', self:oRegistro:_CodigoLoja:Text, 1, 0)",
    "L1_CLIENTE": "&IIF( Empty(self:oRegistro:_IdentificacaoCliente:Text), SuperGetMv('MV_CLIPAD', .F., '000001'), self:DePara('SA1', self:oRegistro:_IdentificacaoCliente:Text, 2,0) )",
    "L1_LOJA": "&IIF( Empty(self:oRegistro:_IdentificacaoCliente:Text), SuperGetMv('MV_LOJAPAD', .F., '01',self:DePara('SM0', self:oRegistro:_CodigoLoja:Text, 1, 0)), self:DePara('SA1', self:oRegistro:_IdentificacaoCliente:Text, 3,0) )",
    "L1_OPERADO": "&self:DePara('SA6',self:oRegistro:_Operador:Text, 2,0)",
    "L1_EMISSAO": "&DtoS( CtoD( SubStr(self:oRegistro:_DataHora:Text, 1, 10) ) )",
    "L1_NUMCFIS": "&self:oRegistro:_Numero:Text",
    "L1_DOC": "&IIF(self:oRegistro:_SiglaModelo:Text == '59',StrZero(Val(self:oRegistro:_Numero:Text),6),IIF(self:oRegistro:_SiglaModelo:Text == '65',StrZero(Val(self:oRegistro:_Numero:Text),9),cValToChar(self:oRegistro:_Numero:Text)))",
    "L1_SERIE": "&self:LayEstAuto('LG_SERIE')",
    "L1_KEYNFCE": "&IIF(self:oRegistro:_SiglaModelo:Text <> '2D', self:oRegistro:_ChaveNFCe:Text, '')",
    "L1_SERSAT": "&IIF(self:oRegistro:_SiglaModelo:Text == '59', self:oRegistro:_NumeroImpressora:Text, '')",
    "L1_SERPDV": "&IIF(self:oRegistro:_SiglaModelo:Text == '2D', self:oRegistro:_NumeroImpressora:Text, '')",
    "L1_COMIS": 0,
    "L1_VLRTOT": "&self:oRegistro:_ValorLiquido:Text",
    "L1_VALBRUT": "&self:oRegistro:_ValorLiquido:Text",
    "L1_VLRLIQ": "&self:oRegistro:_ValorLiquido:Text",
    "L1_VALMERC": "&self:oRegistro:_ValorBruto:Text",
    "L1_DESCONT": "&self:oRegistro:_ValorDesconto:Text",
    "L1_CGCCLI": "&self:oRegistro:_CPFCliente:Text",
    "L1_MSEXP": "&DtoS(Date())",
    "L1_CONDPG": "CN",
    "L1_TIPO": "V",
    "L1_TIPOCLI": "F",
    "L1_ESPECIE": "&IIF(self:oRegistro:_SiglaModelo:Text == '59','SATCE',IIF(self:oRegistro:_SiglaModelo:Text == '65','NFCE',self:oRegistro:_SiglaModelo:Text))",
    "L1_PDV": "&self:LayEstAuto('LG_PDV')",
    "L1_ORIGEM": "N",
    "SL2": [
        {
            "L2_FILIAL": "&self:DePara('SM0', self:oRegistro:_CodigoLoja:Text, 1, 0)",
            "L2_PRODUTO": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_CodigoProduto:Text",
            "L2_ITEM": "&Right( AllTrim(self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_NumeroItem:Text), TamSx3('L2_ITEM')[1])",
            "L2_VEND": "&IIF( Empty(self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_IdentificacaoVendedor:Text), SuperGetMv('MV_VENDPAD', .F., '000001'), self:DePara('SA3',self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_IdentificacaoVendedor:Text, 2,0) )",
            "L2_QUANT": "&Val(self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_Quantidade:Text)",
            "L2_VRUNIT": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_ValorUnitarioLiquido:Text",
            "L2_VLRITEM": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_ValorTotalLiquido:Text",
			"L2_PRCTAB": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_ValorTotalBruto:Text",
            "L2_DESCPRO": "&self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_ValorDescontoItem:Text",
            "L2_LOCAL": "&SuperGetMv('MV_LOCPAD', .F., '01')",
            "L2_UM": "&self:DePara('SAH', self:oRegistro:_Itens:_Lc_ItemCupomfiscal[nItem]:_UnidadeMedida:Text, 2,0)",
            "L2_TES": "&SuperGetMv('MV_TESSAI', .F., '501',self:DePara('SM0', self:oRegistro:_CodigoLoja:Text, 1, 0))",
            "L2_CF": "",
            "L2_EMISSAO": "&DtoS( CtoD( SubStr(self:oRegistro:_DataHora:Text, 1, 10) ) )"
        }
    ],
    "SL4": [
        {
            "L4_FILIAL": "&self:DePara('SM0', self:oRegistro:_CodigoLoja:Text, 1, 0)",
            "L4_DATA": "&DtoS( CtoD( SubStr(self:oRegistro:_DataHora:Text, 1, 10) ) )",
            "L4_VALOR": "&self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_ValorPagamento:Text",
            "L4_FORMA": "&IIF(!Empty(self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_FormaPagamento:Text),self:DePara('SX5', self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_FormaPagamento:Text, 3),'')",
            "L4_ADMINIS": "&IIF( Empty(self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_ProdutoEletronico:Text), '', self:DePara('SAE', self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_ProdutoEletronico:Text, 2,0) )",
            "L4_AUTORIZ": "&AllTrim(self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_Autorizacao:Text)",
            "L4_NSUTEF": "&self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_NSU:Text",
            "L4_PARCTEF": "&self:oRegistro:_FormasPagamento:_Lc_FormaPagamento[nItem]:_Parcela:Text"
        }
    ]
}

...

titleRegras para controle de Serie e PDV
  • Regras para venda com SAT
    • Deverá ser gerado um novo registro na tabela SLG para cada equipamento fiscal SAT que enviar venda, onde deverá conter o número de série do equipamento (LG_SERSAT)
    • O número do PDV enviado na venda, não será considerado para gravação do campo LG_PDV, pois na SLG não permite duplicidade de PDV e o Live permite que um mesmo PDV utilize dois equipamentos SAT diferentes. O campo LG_PDV deverá ser sequencial a partir do 999, ou seja, como o campo possui 3 posições, será a sequencia padrão Protheus com letras. Exemplo: "A01".."Z99". O motivo é para não conflitar com um possível PDV de um ECF. que nos registros C400 do Sped, são obrigatórios para identificar o ECF e possuem 3 posições.
    • o campo LG_SERIE deverá ser gerado de forma automática, o SAT não possui série de documento, apenas o número serial do equipamento. O LG_SERIE, deverá ser sequencial a partir do número 999, ou seja, como o campo possui 3 posições, será a sequencia padrão Protheus com letras. Exemplo: "A01".."Z99". O motivo é para não conflitar com número de série de NF-e/NFC-e (000-999)
    • A busca da estação SLG da venda, sempre será com base no número de série do equipamento.
  • Regras para venda com NFC-e
    • A numeração de série da NFC-e, deverá ser o mesmo valor recebido na venda (tag SerieNFCE)
    • Caso já exista a série na SLG para uma estação que não seja NFC-e (para um SAT ou ECF), deverá ser gerado erro com mensagem clara do motivo (não pode ser utilizado uma série que foi utilizada para uma venda com SAT ou ECF)
    • O número do PDV enviado na venda, não será considerado para gravação do campo LG_PDV, pois na SLG não permite duplicidade de PDV e o Live permite que um mesmo PDV utilize dois equipamentos SAT diferentes. O campo LG_PDV deverá ser sequencial a partir do 999, ou seja, como o campo possui 3 posições, será a sequencia padrão Protheus com letras. Exemplo: "A01".."Z99". O motivo é para não conflitar com um possível PDV de um ECF. que nos registros C400 do Sped, são obrigatórios para identificar o ECF e possuem 3 posições.
  • Regras para venda com ECF
    • Deverá ser gerado um novo registro na tabela SLG para cada equipamento fiscal ECF que enviar venda, onde deverá conter o número de série do equipamento (LG_SERPDV)
    • Não é recebido valor nas tags SiglaModelo e SerieNFCE, assim quando recebermos apenas a tag numeroImpressora o tipo de equipamento sera ECF.
    • O número do PDV enviado na venda, não será considerado para gravação do campo LG_PDV, pois na SLG não permite duplicidade de PDV e o Live permite que um mesmo PDV utilize dois equipamentos ECF diferentes. O campo LG_PDV deverá ser sequencial a partir do 001, ou seja, como o campo possui 3 posições, será a sequencia padrão Protheus.
    • o campo LG_SERIE deverá ser gerado de forma automática, o ECF não possui série de documento, apenas o número serial do equipamento. O LG_SERIE, deverá ser sequencial a partir do número 001, ou seja, como o campo possui 3 posições, será a sequencia padrão Protheus.
    • A busca da estação SLG da venda, sempre será com base no número de série do equipamento.
Para visualizar o Layout Publicação acesse o link abaixo:
https://github.com/totvs/protheus-smart-hub-layouts/blob/main/pdvsync/publicacao/busca_venda.json

Exemplo da configuração do Processo Venda no assinante Live:

Image Removed

Dica
titleFluxo de integração

Após ter realizado as configurações acima a integração do Venda seguirá o seguinte fluxo:

Serviço RMIBUSCA: Neste serviço o Protheus irá realizar a busca das vendas no sistema Totvs LIVE, e grava-las na tabela MHQ - Mensagens Publicadas.  

O Campo MHQ_CHVUNI será a chave do registro publicado e será composto pelas TAGs abaixo:

LC_TicketCupomFiscal:Numero|SerieNFCe|NumeroImpressora|SiglaModelo|Numero

Serviço RMIDISTRIB: Após as mensagens serem publicadas na tabela MHQ, o serviço RMIDISTRIB se encarregará de distribuir as vendas para seus assinantes, neste caso as mensagens serão distribuídas para o assinante Protheus, neste processo será gravado as distribuições na tabela MHR - Mensagens Distribuição  

Serviço RMIENVIA: Com as mensagens distribuídas para o assinante Protheus o serviço RMIENVIA é responsável por gerar a venda de cada mensagem distribuída. Neste momento é gravado as tabelas SL1, SL2 e SL4(Tabelas responsáveis pela venda) e caso a venda seja gerada com sucesso será gravado o numero da mesma no campo MHR_RETORN. Caso o seja encontrado algum erro no momento da geração da venda no Protheus, no campo MHR_ENVIO é gravado os dados que foram passados para gerar a venda e no campo MHR_RETORN é gravado o motivo da inconsistência na geração da venda.

Serviço RMICONTROL: Com as vendas geradas nas tabelas SL1, SL2 e SL4,  o campo L1_SITUA deve estar com o conteúdo IP (Integração Pendente), para que o serviço RMICONTROL realize as validações da venda. Caso seja encontrado alguma inconsistência na venda o campo L1_SITUA sera atualizado para IR (Integração com erro) e será gravado um log do motivo desta inconsistência na tabela MHL - Logs de Integração. Caso a venda seja validada com sucesso o campo L1_SITUA é atualizado para RX (Recebido pelo Server).

Serviço do GravaBacth:  Para as vendas que estejam campo L1_SITUA = RX, este serviço tem como objetivo: Gerar financeiro, Baixa de estoque, Livros fiscais etc. Caso seja encontrado alguma inconsistência no processamento deste serviço o campo L1_SITUA é atualizado para ER. Caso o processamento da venda seja finalizado com sucesso o campo L1_SITUA é atualizado para OK.

Nota
titleImportante!

Vendas do tipo troca seguirá o mesmo fluxo da venda como mencionado acima porém com um diferencial, Ao integrar venda do Live ao Protheus com a forma de pagamento Vale Troca, o valor do Vale Troca será gravado no campo L1_CREDITO e a forma de pagamento será desconsiderada da gravação na tabela SL4, assim como já funciona no Venda Assistida com uma venda com pagamento em NCC. Após o processamento da venda pelo serviço GRAVABATCH será gerado um titulo a receber já baixado do tipo NCC. 

Caso seja integrado uma troca cancelada no Protheus, será gerado um registro na tabela SL4 com a forma de pagamento R$, o titulo a receber gerado no Financeiro também é gerado com o tipo de pagamento em Dinheiro. Após isso a venda seguira os mesmos passos de uma venda cancelada. 

Nota
titleCancelamento de venda.

O Cancelamento de Venda  tem como pré requisito que a venda a ser cancelada esteja integrada no Protheus e processada pelo serviço GravaBatch (L1_SITUA = OK), como informado na Dica de Fluxo de Integração feito isso o cancelamento seguirá o seguinte fluxo:

Serviço RMIBUSCA: Neste serviço é realizado a busca das vendas no Totvs LIVE, o serviço identifica se a tag <Situacao> (Xml integrado do Live) é igual a C, Caso seja significa que se trata de um cancelamento, com isso é gravado um registro na tabela MHQ - Mensagens Publicadas com o campo MHQ_EVENTO = 2 (Cancelamento).

Serviço RMIDISTRIB: Após a Publicação do cancelamento o serviço RMIDISTRIB se encarregará de distribuir o cancelamento da venda  para o assinante Protheus, gerando um registro na tabela MHR - Mensagens Distribuição.

Serviço RMIENVIA: Realizado a distribuição, o serviço RMIENVIA inclui as informações do cancelamento da venda na tabela SLX - Log Cancelamento x Devolução.

Serviço RMICONTROL: Com as informações do cancelamento inseridos na tabela SLX - Log Cancelamento x Devolução este serviço realiza a leitura das informações e em seguida é executado a rotina padrão de cancelamento LOJA140, com isso realizando o cancelamento da venda no Protheus.