Histórico da Página
...
- Visão Geral
- Exemplo de utilização
- Tela XXX
- Outras Ações / Ações relacionadas
- Outras Ações / Ações relacionadas
- Tela XXX
- Principais Campos e Parâmetros
- 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.
- VENDA (F22_TPPART == "2")
- 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.
- VENDA (F22_TPPART == "2")
- 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);
- Destinação
- 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
...
Campo | Descrição |
---|---|
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:
...
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
...
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.
...
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.
...