Histórico da Página

Informações Gerais

(Obrigatório)

Objetivo

<Nesta etapa informar o objetivo da especificação do requisito, ou seja, o que a funcionalidade deve fazer. Exemplo: Permitir que o usuário defina o percentual mínimo em espécie (dinheiro), a referência mínima para calculo dos débitos do aluno e o período de validade do parâmetro de negociação>.

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

<Regra de negócio é o que define a forma de fazer o negócio, o processo definido e/ou as regras que devem ser contempladas. Devem ser descritas restrições, validações, condições e exceções do processo. Caso necessário, incluir neste capítulo também regras de integridade que devem ser observadas no momento do desenvolvimento>.

<Na tabela abaixo informe quais são as rotinas envolvidas, o tipo de operação, a opção de menu e se necessário uma breve descrição das regras de negócio relacionadas a rotina>.

Exemplo de Aplicação:

• Criar o campo “% Mínimo Espécie” (AAA_PERESP) onde o usuário informará o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação.
• Criar o campo “Referência Mínima para Cálculo” (AAA_REFCAL) onde o usuário informará um dos 4 valores disponíveis para pagamento das mensalidades  como a referência mínima para calcular o débito total do aluno.
• Criar o parâmetro MV_ACPARNE que definirá se as informações de “% Mínimo Espécie” e “Referência Mínima para Cálculo” serão obrigatórias.
• O parâmetro MV_ACPARNE deve ter as seguintes opções: 1=Obrigatório e 2=Opcional. Deve ser inicializado como opcional>.

Tabelas Utilizadas

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.

Será necessário realizar as seguintes alterações relacionadas ao cadastro de clientes:

• Adicionar novas tags na mensagem única de cliente (CUSTOMERVENDOR), para que seja possível trafegar todas as informações fiscais necessárias no momento de integrar os registros. Para isso será necessário criar uma nova versão do XSD dessa mensagem (CustomerVendor_2.006) e deverá haver um tratamento no adapter (MATI030) para considerar essas tags apenas à partir dessa versão da mensagem. As novas tags serão definidas conforme abaixo:

Será necessário realizar as seguintes alterações relacionadas ao cadastro de contas a receber:

• Remover o campo de conta hoteleira (E1_CONHTL), pois o mesmo se tornou obsoleto na integração com hotelaria.

Será necessário realizar as seguintes alterações relacionadas ao cadastro de Produtos:

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 e deverá retornar um ListOfInternalId padrão de mensagens do tipo Event (cadastro).

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áluclo 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.

Detalhes da Mensagem (XSD):

Nome da Mensagem: SalesCharge

Versão: 1.000

Tipo: Event

Estrutura:

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
• SE2 – Cadastro de Contas a Pagar
• FI9 – Controle de Emissão de DARF>.

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

Opcional

Fluxo do Processo

<Nesta etapa incluir representações gráficas que descrevam o problema a ser resolvido e o sistema a ser desenvolvido. Exemplo: Diagrama - Caso de Uso, Diagrama de Atividades, Diagrama de Classes, Diagrama de Entidade e Relacionamento e Diagrama de Sequência>. 

Opcional

Dicionário de Dados

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

(Opcional)

Grupo de Perguntas

<Informações utilizadas na linha Protheus>.

Nome: FINSRF2

(Opcional)

Consulta Padrão

<Informações utilizadas na linha Protheus>

Consulta: AMB

(Opcional)

Estrutura de Menu

<Informações utilizadas na linha Datasul>.

Procedimentos

Programas

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.