Histórico da Página

Informações Gerais

Objetivo

Ajustar e criar novas mensagens únicas, relacionadas a controladoria, em prol de atender as necessidades na integração do backoffice Protheus com o software de gestão de hotelaria da Bematech, CMNet.

Definição da Regra de Negócio

O backoffice Protheus será responsável pelo controle financeiro, fiscal e contábil das operações de hotelaria realizadas através do software CMNet.

Para tais fins, os seguintes processos serão integrados com o uso de mensagem única:

• Cadastro de cliente (pessoa física e jurídica, nacional e internacional).
• Cadastro de fornecedor (para empresa comissionada, nacional e internacional)
• Cadastro de vendedor (para empresa comissionada)
• Inclusão de recebimento antecipado (RA)
• Inclusão de provisionamento de reserva (PR a receber)
• Inclusão de adiantamento com cartão (CC / CD + NCC)
• Cancelamento de adiantamento
• Devolução de adiantamento
• Cancelamento de devolução de adiantamentos
• Alteração de valores provisionados em prol da reserva (alteração de PR a receber)
• Análise de crédito de empresas (cliente pessoa jurídica)
• Inclusão de bloco F100
• Cadastro de Produtos
• Inclusão de cupom fiscal
• Cancelamento de cupom fiscal
• Inclusão de recibo provisório de serviço (RPS)
• Cancelamento de RPS
• Redução Z
• Geração de Danfe sobre cupom
• Sincronização de RPS transmitida (envio dos números eletrônicos após transmissão ao SEFAZ)
• Cadastro de Comissões
• Faturas de Hotelaria
  
  

Os itens marcados em negrito são processos do loja e não serão tratados nessa especificação.

Para que todos esses processos sejam adequadamente integrados, serão necessárias algumas melhorias nas rotinas de Controladoria e Loja. Esta especificação tratará apenas as alterações necessárias voltadas a controladoria.

Nesta integração o detentor da regra de negócio para cálculo de comissões é o CMNet, que atende as regras especificas para a hotelaria. Portanto, o Protheus precisará estar preparado para receber essas comissões já calculadas. Para isso, será criada uma nova mensagem única: SalesCharge. 

A rotina de Atualização de Comissões (MATA490) deverá ser alterada para trabalhar com mensagem única, ou seja, passará a ter um IntegDef e será necessário criar o Adapter dessa rotina (MATI490). O Protheus irá apenas receber essa mensagem, portanto, no adapter não haverá tratamentos para envio.

Ao receber as informações, o Protheus irá gravar a comissão (SE3) através da Execauto da rotina MATA490. Caso grave com sucesso, deverá também gravar o de/para na XXF, relacionando as chaves dos registros dos dois sistemas e deverá retornar um ListOfInternalId padrão de mensagens do tipo Event (cadastro). Para gravação da tabela XXF, deve-se utilizar a seguinte função de Framework: CFGA070Mnt.

Exemplo de retorno de ListOfInternalId:

<ListOfInternalId>
    <InternalId>
        <Name>SalesChargeInternalId</Name>  <- Nome do InternalId
        <Origin>000000001</Origin> <- Chave do registro gerado na origem da mensagem
        <Destination>99|01|COM|TIT001|01|001|VEND01</Destination> <- Chave gerada no Protheus após gravação do registro
    </InternalId>
</ListOfInternalId>

Exemplo de gravação de de/para na XXF:

CFGA070Mnt( "BEMATECH", "SE3", "E3_NUM", "000000001", "99|01|COM|TIT001|01|001|VEND01", .F. )

Após gravadas as informações da SE3, o processo de pagamento das comissões (geração do contas a pagar e baixa do mesmo) seguirá o fluxo padrão do backoffice, de forma manual conforme melhor determinado pelo cliente que utilizará a integração.

Visto que quem possuí a regra de cálculo é o sistema de hotelaria, não será possível fazer o recálculo dos registro de comissão gerados por essa integração. Logo, deverá haver uma trava na rotina de Récalculo de Comissão (FINA440) para não permitir tal processo caso a origem da comissão seja integração (E3_ORIGEM = I).

Detalhes técnicos:

• Toda comissão deve estar associada à um contas a receber. Porém, na hotelaria, a comissão pode nascer de um processo de fatura e não estará associado à um título a receber, mas sim à fatura em questão. Nesses casos, o número da fatura deverá trafegar na tag onde normalmente trafegaria o número do título a receber. Com essa informação, o adapter deverá buscar a fatura no Protheus e ver qual título foi gerado para a mesma. Então a chave do título encontrado será utilizado no registro de comissão. Caso a fatura tenha mais de um título gerado (fatura parcelada), associar a comissão ao primeiro título dessa fatura (título com a menor data de vencimento).

• Para toda comissão gravada através de mensagem única, gravar o campo E3_ORIGEM com o novo valor I, indicando integração (rotina MATI490).

IMPORTANTE: Esse novo valor deverá ser documentado na página do TDN:

http://tdn.totvs.com/pages/releaseview.action?pageId=184781116

• Codificar o adapter de forma atualizada, utilizando a classe tXmlManager ao invés de XmlParser.
  
  
• O Adapter deverá tratar os eventos de Inclusão, Alteração e Exclusão. Na inclusão e alteração, deverá retornar o ListOfinternalId na resposta. Na exclusão, deverá apagar o de/para na XXF e não deve retornar ListOfInternalId na resposta. Para saber se é 
  
  
• Adicionar um tratamento para considerar a rotina MATI490 na função FA440Origem, no fonte FINA440. Para esse caso o retorno deverá ser "I".
  
  
• Criar uma função no adapter (MATI490) para encontrar a chave do registro de comissão no Protheus, à partir da chave externa recebida na mensagem.
  
  
• Criar uma função no adapter (MATI490) para criar o valor de InternalId com a chave da comissão no Protheus.

Detalhes da Mensagem (XSD):

Nome da Mensagem: SalesCharge

Versão: 1.000

Tipo: Event

Estrutura:

Anexos:

XSD - SalesCharge_1_000

XML - SalesCharge_1_000

Tabelas Utilizadas

• SA1 – Clientes
• SA2 – Fornecedores
• SA3 – Vendedores
• SE1 – Títulos a receber
• SE3 – Comissão de Vendas
• AI0 – Complementos de Clientes
• FLY – RPS x NFe
• SF3 – Livros Fiscais
• SFT – Livro Fiscal por Item de NF
• CF8 – Demais Docs. Pis Cofins

Opcional

Protótipo de Tela

<Caso necessário inclua protótipos de telas com o objetivo de facilitar o entendimento do requisito, apresentar conceitos e funcionalidades do software>.

Protótipo 01