...

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 (

...

• F41).
  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 (

...

• F41) 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:

...

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

...

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.

...

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.

...