...

1. Visão Geral
2. Exemplo de utilização
3. Tela XXX
   1. Outras Ações / Ações relacionadas
      
4. Tela XXX
   1. Principais Campos e Parâmetros
      
5. Tabelas utilizadas
6. Fontes envolvidos

01. VISÃO GERAL

...

• Login do usuário
  Deverá haver uma tela para o usuário preencher com o usuário e senha Systax. Esse processo deve gerar um Token e um Refresh Token que deve ser gravado em tabelas locais (XXX).
  Nessa tabela, deverá ser gravado o código do usuário protheus, login systax, token e refresh token.
  Atualmente as requisições a API são feitas por meio de usuário e senha. Isso deverá ser alterado e a autenticação ser feita por meio de validação do Token.
  Seguindo o conceito de continuous integration, ao realizar uma requisição com o Token e o mesmo não for mais válido, deve ser realizada uma requisição em uma rotina enviando o Refresh Token. Nesse momento, caso o Refresh Token seja válido, deveremos esperar no retorno um novo Token e um novo Refresh Token.
  Esse retorno deve ser atualizado na tabela local (XXX) para o respectivo usuário.
  Caso o Refreh Token também seja inválido, deve ser aberta a tela para o usuário se autenticar novamente e a partir desse momento voltarmos nesse ciclo.

• Carga de Produto
  Cadastro - Perfil de Produto (F20 e F24)
  F20 - Perfil de Produtos (F20_TIPO == "04")
  F24 - Produtos
  Realizado envio dos protheus existentes no sistema para a Systax (/api/carga_produto).
  Ao enviar o produto, deve ser gravado o código de retorno criado pela API para aquele produto (cpr_codi -> F24_APICOD).
  Sempre que houver alteração em algum campo fundamental para a Systax (os produtos que temo campo F24_APICOD preenchido), deve ser consumido a regra de carga do produto(/api/carga_produto) enviado a operação para excluir o cadastro na Systax. Ou seja, ao consumir a API enviar "acao" como "2".
  Campos: NCM e CEAN (B1_POSIPI, B1_ORIGEM e B1_CODBAR);
  Deve ser implementado validação de erro, caso seja retornado qualquer código que não seja 200 - Ok.

• Carga de Cenários
  Os cenários devem ser definidos pelo cliente, e com base nesse cenários a Systax irá enviar as possíveis regras.
  Esses cenários serão gerados e gravados localmente em tabela.
  Para cada cenário enviado será gerado um código Systax que deve ser gravado localmente.
  Atualmente o que é utilizado pela Systax para gerar um cenário é UF Origem, UF Destino, Origem, Destinação e Código da Natureza da Operação.
  Deve ser implementado validação de erro, caso seja retornado qualquer código que não seja 200 - Ok.
  • Destinação
    • VENDA (F22_TPPART == "2")
      Cadastro - Perfil Participante (F20 e F22)
      F20 - Destinação (F20_TIPO == "02") - https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26924
      F22 - Participante (F22_TPPART == "1" ou "2")
      No cadastro Perfil Participante, haverá cadastrado de forma automática todos possíveis tipos de Destinatários.
      Dessa forma, fica a cargo do cliente preencher em cada Perfil os respectivos participantes conforme o destinatário.
      O cadastro Perfil Participante não deverá ser permitido alteração ou exclusão, apenas realizar essas operações para os participantes.
      Os cadastros de Perfis de Participantes que não tiverem nenhum participante vinculado será desconsiderado no momento do envio das cargas para a Systax.
    • COMPRA (F22_TPPART == "1")
      Cadastro - Perfil Origem (F20 e F22)
      F20 - Origem (F20_TIPO == "2") - https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26923
      F22 - Participante (F22_TPPART == "3")
      No cadastro Perfil Origem, haverá cadastrado de forma automática todos os possíveis tipos de Origem.
      Dessa forma, fica a cargo do cliente preencher em cada Perfil as respectivas empresa/filial conforme origem.
      O cadastro Perfil Origem não deverá ser permitido alteração ou exclusão, apenas realizar essas operações para as empresas.
      Os cadastro de Perfis de Origem que não tiverem nenhuma empresa vinculada será desconsiderado no momento do envio das cargas para a Systax.
  • Origem
    • VENDA (F22_TPPART == "2")
      Cadastro - Perfil Origem (F20 e F22)
      F20 - Origem (F20_TIPO == "2") - https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26923
      F22 - Participante (F22_TPPART == "3")
      No cadastro Perfil Origem, haverá cadastrado de forma automática todos os possíveis tipos de Origem.
      Dessa forma, fica a cargo do cliente preencher em cada Perfil as respectivas empresa/filial conforme origem.
      O cadastro Perfil Origem não deverá ser permitido alteração ou exclusão, apenas realizar essas operações para as empresas.
      Os cadastro de Perfis de Origem que não tiverem nenhuma empresa vinculada será desconsiderado no momento do envio das cargas para a Systax.
    • COMPRA (F22_TPPART == "1")
      Cadastro - Perfil Participante (F20 e F22)
      F20 - Destinação (F20_TIPO == "02") - https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26924
      F22 - Participante (F22_TPPART == "1" ou "2")
      No cadastro Perfil Participante, haverá cadastrado de forma automática todos possíveis tipos de Destinatários.
      Dessa forma, fica a cargo do cliente preencher em cada Perfil os respectivos participantes conforme o destinatário.
      O cadastro Perfil Participante não deverá ser permitido alteração ou exclusão, apenas realizar essas operações para os participantes.
      Os cadastros de Perfis de Participantes que não tiverem nenhum participante vinculado será desconsiderado no momento do envio das cargas para a Systax.
  • Natureza da Operação
    Cadastro - Perfil Operação (F20, F23 e F26)
    F20 - Operação (F20_TIPO == "03") - https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26925
    F23 - CFOPs
    F26 - Tipo de Operação
    No cadastro Perfil Operação, haverá cadastrado de forma automática todas as possíveis operações.
    Dessa forma, fica a cargo do cliente preencher em cada Perfil as respectivas CFOPs pertencentes a cada operação.
    O cadastro Perfil Operação não deverá ser permitido alteração ou exclusão, apenas realizar essa operação para as CFOPs.
    As CFOPs será consideradas somente no comento de consumir as regras geradas pelas Systax, onde devemos verificar se o CFOP gerado para aquela Regra x Operação está vinculado ao Perfil Operação. Caso não seja ele deve ser desconsiderado.
  • UF Origem
    Enviar a UF conforme SM0_ESTENT conforme registro enviado na Origem (F22_TPPART + F22_CLIFOR+F22_LOJA -> A1_EST ou A2_EST - M0_ESTENT);
  • UF Destino
    Retornar as UFs conforme participantes enviado na Destinação (F22_TPPART + F22_CLIFOR+F22_LOJA -> A1_EST ou A2_EST - M0_ESTENT);

• Recepção das regras
  Será retornado N regras conforme os cenários que enviamos.
  No momento da recepção das regras, deve ocorrer a gravação do JSON que foi retornado pela Systax com o objetivo de que caso ocorra alguma não conformidade na regra se ela veio dessa forma da Systax ou se foi originada no momento do parse do sistema.
  Nesse logo, deve ser gerado um ID que deve ser levado até na gravação da regra no configurador (F2B - Regra Tributária) facilitando o rastreio.
  Devemos validar os campos "uf_origem" e "uf_destino" retornado com o que existe cadastrado hoje no "Perfil de Origem/Destino" (F20 - F20_TIPO == "01" e SF1), pois esse cadastro é fundamental para gerar a Regra Tributária (F2B).
  No retorno também existe o campo "cfop" que deve ser verificado conforme o que temos no cadastro "Perfil de Operação" para que somente seja gerada as regras para os CFOPs existentes.
  Além disso, deve existir um de/para com "Perfil de Base de Cálculo" e "bc_composicao" (https://documentacao.systax.com.br/PublicView2/Index/c14f5c52f0b52073cdf05eb75/26445/26922/26928).
  Com base na regra retornada, deve ser realizado o cadastro de "Regra de Alíquota" caso ela não exista (F28) - Este processo ocorre hoje no FISA306C;
  Deve ser implementado validação de erro, caso seja retornado qualquer código que não seja 200 - Ok.

• Validar regras
  Durante o processo de recepção das regras, o usuário terá a possibilidade de definir se quer que as regras sejam geradas de forma automática ou se quer validar se o cenário deve ou não ser integrado no sistema.
  Com isso, deve ser desenvolvido uma forma que permita ao usuário definir os possíveis cenários que ele quer aprovar de forma manual. Por exemplo, quero aprovar de forma manual todas as regras para o produto XPTO, ou aprovar todo e qualquer tipo de regra, ou somente regras para remessa de mercadoria em consignação industrial (operação 549).
  Além disso, nesse processo de aprovação o usuário poderá alterar a regra recepcionada. Caso isso ocorra, a nova regra deve ser gerado mas como se fosse uma inclusão manual e não um retorno automático da API.

• Recepção de regras atualizadas
  Há casos onde ocorre a alteração de uma regra, nesses casos será disponibilizado uma rotina pela Systax onde é retornado exclusivamente as regras que sofreram alguma alteração.
  As regras aplicadas nesse processo são as mesmas que foram descritas em "Recepção das regras".
  Pode ser estudado desse processo ser aplicado em um JOB ou algo nesse sentido, mas deve ser avaliada a questão dos casos que o cliente deseja aprovar de forma manual.
  Verificar se uma vez consultado as regras atualizadas se a Systax irá excluí-las ou se aguarda uma confirmação nossa de que realizamos a atualização e ela possa ser excluída.

02. EXEMPLO DE UTILIZAÇÃO

...

05. TABELAS UTILIZADAS

06. FONTES ENVOLVIDOS

O classificador foi desenvolvido a partir dos seguintes fontes:

FISA306

...

Rotina principal utilizada via Protheus. É recomendo criar um item no menu chamando essa rotina.
Nela é criada a interface para integração de dados com a Systax e consumo das APIs de retorno.

FISA306A

- Tela do classificador fiscal

Objetivo desta rotina é de criar uma interface nos moldes do "Configurador de Tributos" onde o usuário poderá realizar o envido dos produtos para a API da Systax.
Além disso, poderá recepcionar as regras geradas pela Systax e realizar a aprovação das mesmas.
Será necessário exibir uma tela para que seja informado o usuário e senha da empresa no cadastro da Systax.
Essa informação é necessária no envio de todas as requisições.

Obs: Essa tela poderá entrar em desuso com a criação da interface em PO-UI.

Image Added

Image Added

Image Added

Image Added

FISA306A - Classe de integração com API

Objetivo dessa rotina é conter todos os métodos necessários para integração com a API.Esse foi cria a classe de comunicação com o Cockpit da Systax, centralizando toda a comunicação com o ambiente. 

Para informações mais detalhadas sobre as APIs a API disponibilizadas pela Systax, consultar a documentação do Cockpit API da Systax.

Até o momento foram criados os métodosMétodos desenvolvidos:

• New: Construtor da classe.
• Login: Método construído com o intuito de realizar o login do usuário no Cockpit da Systax. Ele foi pensado para receber um Token e um Refresh Token para implementar uma integração contínua. Porém até o momento a Systax ainda não disponibilizou uma API para isso.
• ValidToken: Método para validar o token cadastrado, quando este estiver disponível pela Systax.
• ValidRefreshToken: Método para validar o Refresh Token caso ele tenha expirado, quando este mecanismo for disponibilizado pela Systax.
• GetCargaProduto: Método para consultar se o produto passado por parâmetro existe no ambiente do Cockpit da Systax.
• PostCargaProduto: Método responsável por cadastrar produtos no Cockpit da Systax. Está estruturado para consumir a API de cadastro de produtos em lote.
• PostRegras: Método que retorna as regras aprovadas no Cockpit da Systax.

FISA306B

...

- Envio automático de produto alterado

Objetivo dessa função é identificar informações essenciais referente ao cadastro de produtos que foram atualizados e realizar o envio, de forma automática e transparente, para a Systax referente a essa atualização.
Essa função realiza dois envios:

• O primeiro é para informar a API que o produto atual cadastrado na Systax sofreu alteração e deve ser inutilizado. A identificação desse produto é com base no código contido no campo F24_APICOD e após a inutilização este campo ficará em branco.
• Após a inutilização do produto na Systax, é realiza um envio do produto com os dados atualizados. Com isso, é gravado o novo código gerado pela Systax no campo F24_APICOD.

A Systax não trabalha com alteração de cadastros, sempre é necessário excluir o antigo e enviar o novo produto.

Obs: Os testes foram realizados utilizando o Ponto de Entrada MT010CAN.

FISA306C - Geração de perfis com base no retorno da API

Tem o objetivo de converter as Esta rotina realiza o tratamento das informações recebidas da Systax para compor as possíveis regras para a criação dos cadastros no conforme devem ser criadas no cadastro do classificador.
Atualmente este processo é necessário pois só enviamos o cadastro de produto, quando ocorre o retorno das regras é necessário que o usuário faça o relacionamento manual entre os cadastros. (UF x Cliente x Produto x Operação).Como a ideia passou a ser "aceitar tudo como verdade" e futuramente criar um "filtro" para que o usuário defina o que deseja aprovar ou não, essa rotina deverá sofrer alterações.

O sistema deverá ser capaz de fazer as amarrações de forma automática, ou seja, ao receber um retorno da Systax, é a partir desse fonte que o sistema deverá fazer o de/para com os parâmetros do Configurador de Tributos, para identificar a necessidade de cadastrar novas regras.

Com o desenvolvimento do processo de geração das regras, essa rotina poderá deixar de ser utilizada ou ser responsável apenas por exibir as regras para aprovação do usuário conforme as definições de regra de aprovação.

Image Added

FISA306D - Grava regra no Configurador de Tributos

...

Esta rotina realiza a gravação das regras nas tabelas na tabela do Configurador de Tributos Tributo (F2B);

FISA306E - Log de cenário

Essa rotina está responsável por gravar as informações recebidas da Systax, com a finalidade de manter um histórico dos dados que foram recebidos.
O intuito desse histórico é facilitar a identificação de possíveis erros de integração, tornando a análise técnica mais simplificada.

F42 - Cenarios Systax

FISA300F - Tela de envio dos perfis

Rotina tem como finalidade listar os perfis de Operação, Participantes, Empresa e Produtos.
Ao selecionar os perfis desejado, é realizada a criação de fora automática dos cenários que devem ser enviado a Systax para que que eles (Systax) possam gerar as devidas regras.

Obs: Essa tela poderá entrar em desuso com a criação da interface em PO-UI.

Image Added

FISA300W - Métodos REST do classificador

Essa rotina é responsável por criar todos os métodos REST que deverão ser consumidos pelo PO-UI.

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Fontes que sofreram alterações:

FISA164 - Cadastro de perfil tributário de participantes

Será carregado previamente alguns perfis com base nos dados utilizados pela API da Systax.
Os cadastros importados de forma automática terão o campo "Cod.Referenc" (F20_APIREF) preenchido com o código daquele perfil utilizado pela Systax.
Com isso, o responsável por atualizar esse cadastro deverá realizar o vinculo dos Clientes e/ou Fornecedores nos respectivos perfis.

Esses cadastros não poderão sofrer nenhum tipo de alteração de sua descrição ou exclusão do perfil em si.
A única opção que deverá estar disponível para o usuário realizar é a inclusão, alteração ou exclusão dos participantes vinculados ao perfil.

Os perfis utilizados encontram-se no link: Perfil de Origem e Destino
Hoje (09.09.2021) os valores estão fixos no fonte, deve ser desenvolvido um processo dinâmico onde será consumido o que existe na API da Systax.

FISA165 - Cadastro de perfil tributário de operação

Será carregado previamente alguns perfis com base nos dados utilizados pela API da Systax.
Os cadastros importados de forma automática terão o campo "Cod.Referenc" (F20_APIREF) preenchido com o código daquele perfil utilizado pela Systax.

Com isso, o responsável por atualizar esse cadastro deverá realizar o vinculo dos Clientes e/ou Fornecedores nos respectivos perfis.

Esses cadastros não poderão sofrer nenhum tipo de alteração de sua descrição ou exclusão do perfil em si.
Ao recepcionar as regras geradas pela Systax, haverá uma inteligência que identificará o cadastro do perfil de operação, ao qual se refere aquela regra, e vincular o CFOP retornado na regra.

Os perfis utilizados encontram-se no link: Perfil de Operação (Natureza da Operação)
Hoje (09.09.2021) os valores estão fixos no fonte, deve ser desenvolvido um processo dinâmico onde será consumido o que existe na API da Systax.

FISA170 - Rotina principal do configurador de tributos

Realizada uma alteração apenas para adicionar a opção de "Perfil de Empresas" na árvore de opções.

FISA179 - Cadastro de perfil tributário de empresas

Será carregado previamente alguns perfis com base nos dados utilizados pela API da Systax.
Os cadastros importados de forma automática terão o campo "Cod.Referenc" (F20_APIREF) preenchido com o código daquele perfil utilizado pela Systax.
Com isso, o responsável por atualizar esse cadastro deverá realizar o vinculo dos Clientes e/ou Fornecedores nos respectivos perfis.

Esses cadastros não poderão sofrer nenhum tipo de alteração de sua descrição ou exclusão do perfil em si.
A única opção que deverá estar disponível para o usuário realizar é a inclusão, alteração ou exclusão dos participantes vinculados ao perfil.

Este cadastro utiliza as tabelas F43 - Perfil Trib. da Empresa e F44 - Perfil de Empresas.

Houve a necessidade de criar essas tabelas pois esse cadastro é compartilhado por grupo/empresa/filial.

Os perfis utilizados encontram-se no link: Perfil de Origem e Destino
Hoje (09.09.2021) os valores estão fixos no fonte, deve ser desenvolvido um processo dinâmico onde será consumido o que existe na API da Systax.