Vale a pena relembrar

API

O que fazer quando a API NCM retorna a mensagem “Não contratado ou expirado”.

Por Rafael Sena
 

Na API NCM, é possível realizar consultas de NCM no modo geral, trazendo por premissa as vigentes ou no modo busca específica, utilizando filtros, como: Vigencia em, NCM  e ou Ex Tipi. Todas as informações retornadas são de acordo com a tabela TIPI.

Geralmente, utiliza-se essa solução para validação de cadastros ou compliance nos dados cadastrais.

Quando é visualizada a mensagem de erro de contratação ou expiração, refere-se a um tipo de serviço exibido no site que permite a inclusão de uma data para liberação.

Como solucionar o problema abaixo de contratação ou expiração?

Passo a Passo

1. Acesse o site https://www.systax.com.br/ e filtre por "Cadastro de Usuários > Empresas e usuários" e utilize os filtros para buscar a empresa.



2. Na coluna "Serviços", clique em "Inclui/Editar".



3. Na tela “Serviços da Empresa”, estão localizados os principais serviços que estão diretamente relacionados as soluções. Dentre os serviços disponibilizados, encontre pelo “ID/Nome Serviço” (47) API NCM, indique a data de expiração e clique em “Salvar”, automaticamente será liberado acesso ao serviço.

Antes

Depois


Teste API NCM


A importância deste tópico é demonstrar, de forma prática, o que fazer quando a API NCM retorna a mensagem “Não contratado ou expirado”.
 

API

Aprovação de regras rejeitadas ou rejeição de regras aprovadas através de API – Nova funcionalidade

Por Carlos Cornejo

 

A API de Aprovação e Rejeição de regras tem o objetivo de buscar regras pendentes no Cockpit, utilizando como busca os parâmetros informados na chamada, e com isso realizar a ação desejada pelo usuário (aprovar ou rejeitar as regras encontradas).

Com a nova funcionalidade que implementamos na API, agora também é possível aprovar regras rejeitadas e rejeitar regras aprovadas.

Acessos para a API

URL: https://wscockpit.systax.com.br/api/api/regras/validar
Método: POST

Autenticação

Para utilizar a API é necessário fazer a autenticação via Bearer Token, utilizando o seguinte acesso:

URL: https://app.systax.com.br/auth/access-token
Método: GET

Na API informar o token gerado



 

Chamada

Como dito anteriormente a API utiliza os parâmetros informados na chamada para realizar a busca de regras com base nessas informações: São elas:

id: Não tem validação de informação indicada, deve ser retornado como indicação do item no response (campo não é obrigatório)

acao: Indica qual ação será executada pela API, sendo: (campo obrigatório)

            A: Aprovar regras pendentes ou rejeitadas

            R: Rejeitar regras pendentes ou aprovadas

cenario: Aprova ou rejeita regras relacionadas ao cenário indicado (campo não é obrigatório)

natureza: Aprova ou rejeita regras relacionadas a natureza informada (campo não é obrigatório)

ufOrigem: Aprova ou rejeita regras relacionadas a UF Origem informada (campo não é obrigatório)

ufDestino: Aprova ou rejeita regras relacionadas a UF Destino informada (campo não é obrigatório)

perfilOrigem: Aprova ou rejeita regras relacionadas ao Perfil Origem informado (campo não é obrigatório)

perfilDestino: Aprova ou rejeita regras relacionadas ao Perfil Destino informado (campo não é obrigatório)

munOrigem: Aprova ou rejeita regras relacionadas ao Município de Origem informado (campo não é obrigatório)

munDestino: Aprova ou rejeita regras relacionadas ao Município de Destino informado (campo não é obrigatório)

finalidade: Aprova ou rejeita regras relacionadas a Finalidade informada (campo não é obrigatório)

codProduto: Aprova ou rejeita regras relacionadas ao Código do Produto Informado (campo não é obrigatório)

origemProduto: Aprova ou rejeita regras relacionadas a Origem do Produto informada (campo não é obrigatório)

ncm: Aprova ou rejeita regras relacionadas a ncm informada (campo não é obrigatório)

extipi: Aprova ou rejeita regras relacionadas a extipi informada (campo não é obrigatório)

ean: Aprova ou rejeita regras relacionadas ao ean informado (campo não é obrigatório)

período: Aprova ou rejeita regras dentro do período informado. É indicado no formato dd/mm/aaaa a dd/mm/aaaa (campo não é obrigatório)

Dentre todos os campos o único que é obrigatório ser preenchido é o “acao”, pois é ele que determina o que a API deverá fazer com as regras encontradas.

Importante: caso apenas o campo “acao” seja preenchido, a API irá aprovar ou rejeitar todas as regras no Cockpit, de acordo com a ação indicada. Então é sempre muito importante ficar atento se realmente a chamada será feita sem nenhum parâmetro informado.

Modelo de chamada

{
    "itens": [
            {
                "id": 0,
                "acao": "",
                "cenario": "",
                "natureza": "",
                "ufOrigem": "",
                "ufDestino": "",
                "perfilOrigem": "",
                "perfilDestino": "",
                "munOrigem": "",
                "munDestino": "",
                "finalidade": "",
                "codProduto": "",
                "origemProduto": "",
                "ncm": "",
                "extipi": "",
                "ean": "",
                "periodo": ""
            }
        ]
}

Dados do retorno

id: Retorna de acordo com o valor indicado na chamada

protocolo: Protocolo gerado pela API no retorno da chamada

data: Informa a data em que a ação foi executada

cod: Informa o código de retorno, que indica se ação foi executada com sucesso ou não

message: Mensagem de retorno, de acordo com o código acima

Após realizar a chamada existem 4 retornos possíveis. São eles:
 

Parâmetros incorretos

Alguma informação foi preenchida de forma incorreta nos campos da chamada. Nesse caso é necessário analisar novamente todos os campos que estão sendo enviados e verificar se as informações neles estão corretas.

Deve ser indicada “acao”

Como dito anteriormente o campo “acao” é o único obrigatório no preenchimento da chamada, de forma que se ele não for enviado a API retornará com erro.

Retornado com sucesso

A API buscou e identificou todas as regras, de acordo com os parâmetros que foram informados e realizou a ação indicada na chamada. Sendo aprovação ou rejeição.

Não existem regras com os parâmetros informados

A API não identificou nenhuma regra, de acordo com os parâmetros que foram informados na chamada.

Exemplo de retorno

{
    "itens": [
       {
            "id": 0,
            "protocolo": 35,
            "data": "18/09/2023 16:06:14",
            "cod": 2,
            "message": "Retornado com sucesso"
        }
    ]
}


 

Conclusão

A API de Aprovação e Rejeição de Regras serve para otimizar o processo de busca e realização da ação desejada nas regras do Cockpit.

Através dela o cliente consegue informar quais os parâmetros o sistema deve considerar para buscar regras e aprovar ou rejeitar, dependendo da necessidade do cliente.

API

Autenticação Bearer Token

Por Pedro

Autenticação Bearer Token

Cockpit

Procedimento para aprovação ou rejeição de regras não pendentes

Por Fernanda Almeida
 

Na rotina de conferência de regras, os usuários ou clientes podem fazer aprovações ou rejeições em lote diretamente no cockpit, por meio da rotina de “Aprovação de Regras em lote”.

Essa rotina funciona normalmente para regras que estão com status “pendente de aprovação”, porém, a mesma rotina permite que regras aprovadas ou rejeitadas anteriormente sejam aprovadas ou rejeitadas, sem a necessidade de voltar para o status de “pendente”.

Para fazer a rejeição de regras aprovadas, basta selecionar as regras que passarão por esse processo:



Acessar a rotina “Aprovação de Regras em lote” e expandir o item “Arquivo”:



Subir o arquivo CSV de acordo com o template informado:

ID_cenario | cod_produto | origem_produtos



Marcar a ação “Rejeitar” e fazer o upload do arquivo:


Abrirá a tela de pop-up para informar o motivo, a justificativa e o resultado esperado, assim como já ocorre no processo de rejeição de regras pendentes ou aprovadas na tela de consulta.

O pop-up para inserir os motivos da rejeição, também demonstrará a quantidade de regras que serão rejeitadas nesse lote. Depois clicar em “Confirmar” e reconfirmar a ação:



O cockpit criará um lote de processamento para o usuário acompanhar a ação:



O processamento de lote foi concluído e as regras ficam com status de “rejeitadas”:





O processo inverso também ocorre da mesma forma, se a regra está rejeitada, o usuário pode fazer o upload do arquivo CSV e selecionar a ação de aprovar a regra.

Worth remembering

API

What to do when the NCM API returns the message "Not contracted or expired".

By Rafael Sena
 

In the NCM API, it is possible to carry out NCM queries in general, based on those currently in effect, or in specific search mode, using filters such as: Start Date of Effect, NCM and/or Ex Tipi. All the information returned is in accordance with the TIPI table.

This solution is generally used to validate registrations or for compliance with registration data.

When the contracting or expiry error message is displayed, it refers to a type of service displayed on the site that allows the inclusion of a release date.

How can I solve the contracting or expiry problem below?

Step by step

1. Go to https://www.systax.com.br/ and filter by "User Registration > Companies and users" and use the filters to search for the company.

2. In the "Services" column, click on "Add/Edit".

3. The "Company Services" screen contains the main services that are directly related to the solutions. Among the services available, find the "Service ID/Name" (47) NCM API, indicate the expiration date and click on "Save", and access to the service will automatically be granted.

Before

After

Test NCM API

The importance of this topic is to demonstrate, in a practical way, what to do when the NCM API returns the message "Not contracted or expired".
 

API

Approval of rejected rules or rejection of approved rules through API – New functionality

By Carlos Cornejo

 

The Rules Approval and Rejection API aims to search for pending rules in the Cockpit, using as search the parameters informed in the call, and thereby perform the action desired by the user (to approve or reject the rules found).

With the new functionality we implemented in the API, it is now also possible to approve rejected rules and reject approved rules.

 

API Accesses

URL: https://wscockpit.systax.com.br/pi/api/rules/validate
Method: POST

Authentication
To use the API you need to authenticate via Bearer Token using the following access:

URL: https://app.systax.com.br/auth/access-token
Method: GET



An API report or token generated


 

Request

As mentioned earlier, the API uses the parameters informed in the call to perform the search for rules based on this information:

id: has no information validation specified, must be returned as an indication of the item in the response (field is not required)

action: Specifies which action will be executed by the API, being: (required field)
              A: Adopt outstanding or rejected rules
              R: Reject outstanding or approved rules

scenario: Approves or rejects rules related to the specified scenario (field is not required)

Nature: Approves or rejects rules related to informed nature (field is not mandatory)

ufOrigin: Approves or rejects rules related to UF Informed Origin (the field is not mandatory)

ufDestination: Approves or rejects rules related to UF Informed Destination (field is not mandatory)

ProfileOrigin: Approves or rejects rules related to Profile Informed Source (the field is optional)

ProfileDestination: Approves or rejects rules related to Profile Informed Destination (the field is not mandatory)

munOrigem: Approves or rejects rules related to the informed Municipality of Origin (the field is not mandatory)

munDestino: Approves or rejects rules related to the informed Destination Municipality (field is not mandatory)

Purpose: Approves or rejects rules related to Informed Purpose (the field is not mandatory)

codProduct: Approves or rejects rules related to the Informed Product Code (the field is optional)

OriginProduct: Approves or rejects rules related to Informed Product Origin (the field is optional)

ncm: Approves or rejects rules related to informed ncm (field is not mandatory)

extipi: Approves or rejects rules related to informed extypi (the field is not mandatory)

ean: Approves or rejects rules related to the informed ean (the field is not mandatory)

period: Approves or rejects rules within the period. It is indicated in the format dd/mm/aaaa to dd/ mm/aaaa (field is not required)

Of all the fields, the only one that is mandatory to be filled in is the “achao”, as it is it that determines what the API should do with the rules found.

Important: If only the “Acao” field is filled, the API will approve or reject all rules in the Cockpit, according to the specified action. So it is always very important to be careful if the call will actually be made without any informed parameters.

Request Example
 

{
    "itens": [
            {
                "id": 0,
                "acao": "",
                "cenario": "",
                "natureza": "",
                "ufOrigem": "",
                "ufDestino": "",
                "perfilOrigem": "",
                "perfilDestino": "",
                "munOrigem": "",
                "munDestino": "",
                "finalidade": "",
                "codProduto": "",
                "origemProduto": "",
                "ncm": "",
                "extipi": "",
                "ean": "",
                "periodo": ""
            }
        ]
}

Return Data

id: Returns according to the value specified in the call

protocol: Protocol generated by the API on call return

date: Gives the date when the action was executed

cod: Informs the return code, which indicates whether the action was executed successfully or not

message: Return message, according to the code above

After making the call there are 4 possible returns. They are:
 

Incorrect parameters

Some information was incorrectly filled in in the call fields. In this case, it is necessary to re-examine all the fields that are being submitted and check whether the information in them is correct.

Should be indicated “Acao”

As mentioned earlier, the field “Acao” is the only required when filling the request call, so that if it is not sent to the API it will return as an error.

Successfully returned

The API searched and identified all the rules according to the parameters that were informed and performed the action indicated in the call. Being approval or rejection.

No rules with informed parameters

The API did not identify any rules, according to the parameters that were informed in the call.

Return Example

{
    "itens": [
       {
            "id": 0,
            "protocolo": 35,
            "data": "18/09/2023 16:06:14",
            "cod": 2,
            "message": "Retornado com sucesso"
        }
    ]
}

Conclusion

The Rules Approval and Rejection API serves to optimize the process of searching and performing the desired action in the Cockpit rules.
Through it the customer can inform which parameters the system should consider to seek rules and approve or reject, depending on the customer's need.
 

API

Bearer Token Authentication

By Pedro

Bearer Token Authentication

Cockpit

Procedure for approving or rejecting outstanding rules

By Fernanda Almeida
 

In the rule conference routine, users or customers can make batch approvals or rejections directly in the cockpit, through the batch rule approval routine.

This routine normally works for rules that are in “approval pending” status, however, the same routine allows previously approved or rejected rules to be endorsed or dismissed, without the need to go back to the “expected” status.

To reject approved rules, simply select the rules that will go through this process:

Go to the “Approval of Rules in Batch” routine and expand the “File” item:

Upload the CSV file according to the informed template:

Scenario ID | product code | product_source

Check the “Reject” action and upload the file:


 

It opens the pop-up screen to inform the reason, justification and expected result, as already occurs in the process of rejecting outstanding or approved rules on the query screen.

The pop-up to enter the reasons for rejection will also show the number of rules that will be rejected in that batch. Then click on “Confirm” and re-confirm the action:



The cockpit will create a processing batch for the user to track the action:



The batch processing has been completed and the rules are in "rejected" status.




The reverse process also occurs in the same way, if the rule is rejected, the user can upload the CSV file and select the action to approve the rules.

Voltar