CONTEÚDO
- Visão Geral
- Exemplo de utilização
- Tela XXX
- Outras Ações / Ações relacionadas
- Tela XXX
- Principais Campos e Parâmetros
- Tabelas utilizadas
- 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
Use esse espaço para colocar exemplos de utilização.
03. TELA XXXXX
Outras Ações / Ações relacionadas
| Ação | Descrição |
|---|
| Inclua a ação | Inclua a descrição relacionada |
| Inclua a ação | Inclua a descrição relacionada |
| Inclua a ação | Inclua a descrição relacionada |
04. TELA XXXXX
Principais Campos e Parâmetros
| Campo | Descrição |
|---|
| Inclua o campo | Inclua a descrição relacionada |
| Inclua o campo | Inclua a descrição relacionada |
| Inclua o campo | Inclua a descrição relacionada |
05. TABELAS UTILIZADAS
| X2_CHAVE | X2_NOME | X2_MODO | X2_MODOUN | X2_MODOEMP |
| F41 | Token Usuario Systax | E | E | E |
| F42 | Cenarios Systax | E | E | E |
| F43 | Perfil Trib. da Empresa | C | C | C |
| F44 | Perfil Trib. de Empresas | C | C | C |
| X3_ARQUIVO | X3_CAMPO | X3_TIPO | X3_TAMANHO | X3_DECIMAL | X3_TITULO | X3_DESCRIC | X3_PICTURE | X3_BROWSE | X3_VISUAL | X3_CONTEXT | X3_OBRIGAT |
| F20 | F20_APIREF | C | 6 | 0 | Cod.Referenc | Codigo de Referencia API | | N | V | R | |
| F24 | F24_APICOD | C | 10 | 0 | Cod. API | Codigo da API | | N | V | R | |
| F41 | F41_FILIAL | C | 8 | 0 | Filial | Filial do Sistema | @! | N |
|
| |
| F41 | F41_ID | C | 36 | 0 | ID | ID do registro | | S | A | R | x |
| F41 | F41_SISUSR | C | 50 | 0 | Usuario Prot | Usuario Protheus | | S | A | R | x |
| F41 | F41_USER | C | 250 | 0 | Usuario | Usuario Systax | | S | A | R | x |
| F41 | F41_TOKEN | C | 250 | 0 | Token | Token de acesso a Systax | | S | A | R | x |
| F41 | F41_RTOKEN | C | 250 | 0 | Refresh Tk. | Refresh Token Systax | | N | A | R | |
| F42 | F42_FILIAL | C | 8 | 0 | Filial | Filial do Sistema | @! | N |
|
| |
| F42 | F42_ID | C | 36 | 0 | ID | ID unico | | S | A | R | x |
| F42 | F42_DTCENA | C | 14 | 0 | Dt. Cenario | Data Atualizacao Cenario | | S | A | R | x |
| F42 | F42_USER | C | 100 | 0 | Usuario | Usuario acesso Systax | | S | A | R | x |
| F42 | F42_DTREQ | C | 14 | 0 | Data Req. | Data da Requisicao | | S | A | R | x |
| F42 | F42_JSON | M | 10 | 0 | JSON Cenario | JSON Cenario Systax | | N | A | R | x |
| F43 | F43_FILIAL | C | 8 | 0 | Filial | Filial do Sistema | @! | N |
|
| |
| F43 | F43_CODIGO | C | 6 | 0 | Cod. Perfil | Codigo do Perfil | | S | A | R | x |
| F43 | F43_DESC | C | 200 | 0 | Descricao | Descricao do Perfil | | S | A | R | x |
| F43 | F43_APIREF | C | 6 | 0 | Cod.Referenc | Codigo de Referencia API | | N | V | R | |
| F44 | F44_FILIAL | C | 8 | 0 | Filial | Filial do Sistema | @! | N |
|
| |
| F44 | F44_CODIGO | C | 6 | 0 | Cod. Perfil | Codigo do Perfil | | N | A | R | |
| F44 | F44_CODGRP | C | 2 | 0 | Grp. Empresa | Grupo de Empresa | | N | A | R | x |
| F44 | F44_CODFIL | C | 12 | 0 | Cod. Filial | Codigo da Filial | | N | A | R | x |
06. FONTES ENVOLVIDOS
O classificador foi desenvolvido a partir dos seguintes fontes:
FISA306 - 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.
FISA306A - Classe de integração com API
Objetivo dessa rotina é conter todos os métodos necessários para integração com a API.
Para informações mais detalhadas sobre a API disponibilizadas pela Systax, consultar a documentação do Cockpit API.
Mé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 informações recebidas da Systax para compor as possíveis regras 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).
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.
FISA306D - Grava regra no Configurador de Tributos
Esta rotina realiza a gravação das regras na tabela do Configurador de 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
| X3_CAMPO | X3_TIPO | X3_TAMANHO | X3_DECIMAL | X3_TITULO |
|---|
| F42_FILIAL | C | 8 | 0 | Filial |
| F42_ID | C | 36 | 0 | ID |
| F42_DTCENA | C | 14 | 0 | Dt. Cenario |
| F42_USER | C | 100 | 0 | Usuário |
| F42_DTREQ | C | 14 | 0 | Data Req. |
| F42_JSON | M | 10 | 0 | JSON Cenario |
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.
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.
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.
| X3_ARQUIVO | X3_CAMPO | X3_TIPO | X3_TAMANHO | X3_TITULO |
|---|
| F20 | F20_APIREF | C | 6 | Cod.Referenc |
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.
| X2_CHAVE | X2_NOME | X2_MODO | X2_MODOUN | X2_MODOEMP |
|---|
| F43 | Perfil Trib. da Empresa | C | C | C |
| F44 | Perfil de Empresa | C | C | C |
| X3_ARQUIVO | X3_CAMPO | X3_TIPO | X3_TAMANHO | X3_TITULO |
|---|
| F43 | F43_FILIAL | C | 8 | Filial |
| F43 | F43_CODIGO | C | 6 | Cod. Perfil |
| F43 | F43_DESC | C | 200 | Descricao |
| F43 | F43_APIREF | C | 6 | Cod.Referenc |
|
|
|
|
|
| F44 | F44_FILIAL | C | 8 | Filial |
| F44 | F44_CODIGO | C | 6 | Cod. Perfil |
| F44 | F44_CODGRP | C | 2 | Grp. Empresa |
| F44 | F44_CODFIL | C | 12 | Cod. Filial |
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.