Documentação Geral

Vale a pena relembrar


     

    Vale a pena relembrar

     

    Cockpit

     

    Bloqueio de regras na aprovação em lote

    Por Fernanda Almeida
     

    No processo de aprovação de regras em lote, muitas vezes as regras ficam retidas na coluna “Bloqueadas” de validação do Arquivo:

    Quando as regras caem nessa coluna, quer dizer que o usuário precisa dar um “double check” nos resultados que estão sendo aprovados.

    As regras de bloqueio são as seguintes:

    1ª Condição de bloqueio:

    Regra que entrou com ST e depois saiu da ST considerando o CST do ICMS da regra anterior igual a 10 ou 30 ou 60 ou 70.


    2ª Condição de bloqueio:

    Validação da operação de entrada com ICMS ST e saída sem ICMS ST

    Se o tipo entrada/saída for igual 1 e a Natureza de Operação for igual a 120 ou 121 ou 108 e o CST do ICMS for igual a 10 ou 30 ou 60 ou 70 ou tipo de antecipação for diferente de zero e indicador de crédito for igual a zero;

    então, cruzar com regras mais recentes do mesmo produto em outros cenários, mesmo que não aprovadas ainda, considerando:

    Tipo de entrada/saída igual a 3 e a Natureza de Operação for igual a 120 ou 121 ou 108 e UF origem for igual a UF destino, considerando a UF de destino da regra de entrada e o código do produto for igual e CST do ICMS diferente de 60

     

    3ª Condição de bloqueio

    Validação da operação de saída com ICMS ST e entrada sem ICMS ST

    Se o tipo entrada/saída for igual a 3 e Natureza de Operação for igual a 120 ou 121 ou 108 e CST do ICMS igual a 60;

    então, cruzar com regras mais recentes do mesmo produto em outros cenários, mesmo que não aprovadas ainda, considerando:

    Tipo de entrada/saída igual a 1 e Natureza de Operação for igual a 120 ou 121 ou 108 e condição for a UF de Origem da operação de saída e código de produto e CST do ICMS diferente de 10 ou 30 ou 60 ou 70 ou tipo antecipação diferente de zero e indicador de crédito igual a zero

     

    4ª Condição de bloqueio

    Validação da operação de entrada sem ICMS ST e saída com ICMS ST

    Se o tipo entrada/saída for igual a 1 e a Natureza de Operação for igual a 120 ou 121 ou 108 e CST do ICMS for diferente de 10 ou 30 ou 60 ou 70 ou tipo antecipação diferente de zero e indicador de crédito for igual a zero;

    então, cruzar com regras mais recentes do mesmo produto em outros cenários, mesmo que não aprovadas ainda, considerando:

    Tipo de entrada/saída igual a 120 ou 121 ou 108 e UF destino da operação de entrada e código do produto e CST igual a 10 ou 30 ou 60 ou 70 ou tipo antecipação diferente de zero e indicador de crédito igual a zero.

     

    5ª Condição de bloqueio

    Validação da operação de saída sem ICMS ST e entrada com ICMS ST

    Se o tipo de entrada/saída for igual a 3 e UF origem for igual a UF destino e Natureza de Operação for igual a 120 ou 121 ou 108 e CST ICMS diferente de 60;

    então, cruzar com regras mais recentes do mesmo produto em outros cenários, mesmo que não aprovadas ainda, considerando:

    Tipo de entrada/saída igual a 120 ou 121 ou 108 e UF de destino igual a UF de origem e código de produto igual ao da operação de entrada e CST ICMS igual a 10 ou 30 ou 60 ou 70 ou tipo antecipação diferente de zero e indicador de crédito igual a zero.

     

    Dessa forma, quando as regras são bloqueadas o usuário deverá analisar o fluxo operação do produto, pois pode haver algum resultado tributário que não esteja aderente à regra que está em situação de aprovação.

    Se o usuário analisou e entendeu que o resultado está correto, basta clicar no volume de regras bloqueadas:

     

     

    Listar as regras e seguir com a aprovação ou rejeição das regras normalmente:

     

     

    Conclusão: As regras de bloqueio são importantes para dar visibilidade ao usuário ou as equipes que estão realizando a aprovação que há algum problema no fluxo operacional daquele resultado tributário.

     

     

    Exclusão de regras

    Por Carlos Cornejo
     

    Atualmente existem algumas formas de inviabilizar a utilização das regras disponibilizadas no Cockpit. Entre elas, a exclusão de cenário pelo próprio Cockpit.

    Para realizar esse procedimento, é necessário que o usuário Systax acesse o ambiente manager do Cockpit e execute a exclusão de regras de determinado cenário.

    O caminho para a funcionalidade é o seguinte:



    Após isso filtrar o cliente desejado.

     

    Após selecionar o cliente desejado, acessar a opção “Config”.

     

    Na tela seguinte é necessário acessar a opção “Exclusão de regras”.

     

    Em seguida o usuário deve fazer o upload do arquivo (CSV), que contém os registros que serão excluídos. Esse arquivo deve seguir um layout específico, para que o sistema consiga realizar a leitura da forma correta.
    Para isso estão disponíveis 2 modelos de arquivo:

    - Modelo arquivo regra de produto
    - Modelo arquivo regra de serviço

    É possível baixa-los da seguinte forma:



    Layout para regras de produtos:



    Layout para regras de serviço:

    Com o arquivo pronto basta selecioná-lo e enviar.



    Após o envio, as informações referente a exclusão irão aparecer no Grid abaixo.

     

    A partir do momento da exclusão das regras, por essa rotina, os registros serão excluídos do Cockpit do cliente em questão.

    Essa ação de exclusão de regras pelo Cockpit, deve ser feita em conjunto com a ação de exclusão ou desativação de cenários no ERP Configurações, no Admin. Caso contrário, quando houver um novo processamento do cenário, as regras serão criadas e enviadas novamente para o Cockpit.

    Caso houver regras em trânsito no webservice, serão entregues no Cockpit e desativadas no processamento seguinte.

     

     

    Webservice

     

    Como importar o WSDL dos manuais de Web Service no aplicativo SoapUI

    Por Rafael Sena

     

    Um WSDL de Web Service no SoapUI é um arquivo XML que descreve a funcionalidade de um serviço web baseado em SOAP. O SoapUI é uma ferramenta de mercado de código aberto que usa os arquivos WSDL para gerar solicitações de testes. Este recurso é utilizado para apoiar os parceiros, clientes e desenvolvedores a serem mais eficientes, tanto nas análises com relação aos testes de execução quanto ao mapeamento dos campos de chamada e retorno.

     
    O que é WSDL?

     

    É a Linguagem de Descrição de Serviços Web (Web Service Description Language) e é usado para descrever a atividade de um serviço web, como onde ele começa e termina.

    A vantagem dos exemplos de chamadas é o ganho de ter fácil acesso as chamadas para execução.

     

    Como importar um WSDL?

     

    1. Nas documentações de Web Service, você encontra o WSDL no tópico “Webservice”, com isso, clique no tópico “Webservice”.

     

     

    1. Selecione e copie o link indicado na “URL do WSDL“.

     

    1. No aplicativo de mercado SoapUI, existe 2 formas de importar o WSDL, via “File > New SOAP Project”, localizado na barra de ferramentas ou clicando no ícone “SOAP” (Creates a New Project) abaixo da barra de ferramentas.

     

    1. Clique em “Project Name” e insira um título para a coleção de chamadas que será importada e cole o link copiado da URL do WSDL no campo “Initial WSDL”.

     

     

    Exemplo:

     

     

    1. Após importar o WSDL, clique 2x em “Request 1”, insira os dados conforme explicação do manual para executar a chamada de sua escolha.

     


    A importância deste tópico é demonstrar, de forma prática, como importar o WSDL dos manuais de Web Service no aplicativo SoapUI.

     

     

    Site

     

    Atualização dos manuais de ferramentas disponibilizados no site

    Por Carlos Dupim Jr.

     

    No site Systax, foi atualizada a área onde disponibilizados acesso aos manuais de ferramentas.

    Anteriormente, essa área era denominada “Outros Downloads”, acessível através do No Site Systax > Outras Opções > Outros Downloads.

    Agora, para melhor refletir o conteúdo presente na tela, foi renomeada para “Manuais Site”, conforme segue:

     

    O conteúdo dessa tela foi atualizado, removendo os arquivos PDF obsoletos, e fornecendo agora links diretos às pastas do Glider com os manuais apresentados, garantindo assim que todos tenham acesso às versões mais recentes da documentação.

     

     

    Além disso, foi criada tabela no Admin, chamada “manuais_site”, onde são alimentadas as informações refletidas no site.

    Com ela, não é necessário a ação da equipe de desenvolvimento sempre que for necessário incluir novo manual no site, podendo usuário ou equipe com permissão de edição nessa tabela: incluir, alterar ou excluir registro de manual a ser apresentado. Atualmente, somente a equipe de Produtos possui permissão para tais alterações.

    Esse conjunto de melhorias agiliza o processo de inclusão e atualização dos manuais fornecidos para usuários e clientes no site, garantindo precisão e atualidade nas informações fornecidas.

     


     

    Worth remembering

     

    Cockpit

     

    Rule blocking in batch approval

    By Fernanda Almeida

     

    In the process of approving batch rules, rules often get stuck in the "Blocked" column of the validation file:

    When the rules fall in this column, it means that the user needs to do a "double check" on the results that are being approved.

    The blocking rules work as follows:

    1st Blocking Condition:

    Rules that came out of the ST.

    Rule that entered with ICMS ST and then exited from ST considering the ICMS CST of the previous rule equal to 10 or 30 or 60 or 70.


    2nd Blocking Condition:

    Validation of the entry operation with ICMS ST and exit without ICMS ST.

    If the entry/exit type is equal to 1 and the Nature of Operation is equal to 120 or 121 or 108, and the ICMS CST is equal to 10 or 30 or 60 or 70, or the type of anticipation is different than zero and the credit indicator is equal to zero;

    So, crossing with more recent rules of the same product in other scenarios, even if not yet approved, considering:

    Type of entry/exit equal to 3 and the Nature of Operation equal to 120 or 121 or 108 and the origin state equal to the destination state, considering the destination state of the entry rule and the product code being equal and the ICMS CST different than 60.

     

    3rd Blocking Condition:

    Validation of the exit operation with ICMS ST and entry without ICMS ST.

    If the entry/exit type is equal to 3 and the Nature of Operation is equal to 120 or 121 or 108 and the ICMS CST is equal to 60;

    So, crossing with more recent rules of the same product in other scenarios, even if not yet approved, considering:

    Type of entry/exit equal to 1 and Nature of Operation equal to 120 or 121 or 108 and condition for the State of Origin of the exit operation and product code and ICMS CST different than 10 or 30 or 60 or 70 or anticipation type different from zero and credit indicator equal to zero.

     

    4th Blocking Condition:

    Validation of the entry operation without ICMS ST and exit with ICMS ST.

    If the entry/exit type is equal to 1 and the Nature of Operation is equal to 120 or 121 or 108, and the ICMS CST is different than 10 or 30 or 60 or 70, or the anticipation type is different than zero and the credit indicator is equal to zero;

    So, crossing with more recent rules of the same product in other scenarios, even if not yet approved, considering:

    Type of entry/exit equal to 120 or 121 or 108 and destination UF of the entry operation and product code and CST equal to 10 or 30 or 60 or 70 or anticipation type different than zero and credit indicator equal to zero.

     

    5th Blocking Condition

    Validation of the exit operation without ICMS ST and entry with ICMS ST.

    If the type of entry/exit is equal to 3 and the origin state is equal to the destination state and the Nature of Operation is equal to 120 or 121 or 108 and the ICMS CST is different than 60;

    So, crossing with more recent rules of the same product in other scenarios, even if not yet approved, considering:

    Type of entry/exit equal to 120 or 121 or 108 and destination state equal to origin state and product code equal to that of the entry operation and ICMS CST equal to 10 or 30 or 60 or 70 or advance type different than zero and credit indicator equal to zero.

     

    In this way, when the rules are blocked, the user should analyze the product's operational flow, as there may be some tax result that does not adhere to the rule that is in the approval stage.

    If the user has analyzed and understood that the result is correct, just click on the volume of blocked rules:

     

     

    List the rules and proceed with the approval or rejection of the rules as usual:

     

     

    Conclusion: The blocking rules are important to provide visibility to the user or the teams that are approving that there is a problem in the operational flow of that tax result.

     

     

    Exclusion of rules

    By Carlos Cornejo



    Currently, there are some ways to render the use of the rules provided in the Cockpit unfeasible. Among them, the exclusion of the scenario by the Cockpit itself.

    To carry out this procedure, it is necessary for the Systax user to access the manager environment of the Cockpit and execute the deletion of rules for a specific scenario.

    The path to functionality is as follows:



    After that, filter the desired customer.



    After selecting the desired client, access the "Config" option.



    On the next screen, it is necessary to access the option "Rule Deletion."



    Next, the user must upload the file (CSV) that contains the records to be deleted. This file must follow a specific layout so that the system can read it correctly.
    For this, two file models are available:

    - Product rule file model
    - Service rule file template

    It is possible to download them as follows:



    Layout for product rules:



    Layout for service rules:



    With the file ready, just select it and send it.



    After submission, the information regarding the deletion will appear in the grid below.




    From the moment the rules are removed by this routine, the records will be deleted from the client's Cockpit in question.

    This action of deleting rules through the Cockpit should be done in conjunction with the action of deleting or deactivating scenarios in the ERP Settings, in the Admin. Otherwise, when there is a new processing of the scenario, the rules will be created and sent again to the Cockpit.

    If there are rules in transit in the web service, they will be delivered in the Cockpit and deactivated in the next processing.

     

     

    Webservice

     

    How to import WSDL from Web Service manuals into the SoapUI application

    By Rafael Sena

     

    A Web Service WSDL in SoapUI is an XML file that describes the functionality of a SOAP-based web service.

    SoapUI is an open-source market tool that uses WSDL files to generate test requests.

    This resource is used to help partners, clients and developers to be more efficient, both in their analysis of test runs and in the mapping of call and return fields.

    What is WSDL?

    It is the Web Service Description Language and is used to describe the activity of a web service, such as where it starts and ends.

    The advantage of call examples is that you gain easy access to the calls for execution.

    How do I import a WSDL?

    1. In the Web Service documentation, you can find the WSDL in the “Webservice” topic, so click on the “Webservice” topic.

     

     

    1. Select and copy the url indicated in the “WSDL URL”.

     

     

    1. In the SoapUI marketplace application, there are 2 ways to import the WSDL, via “File > New SOAP Project”, located in the toolbar, or by clicking on the “SOAP” icon (Creates a New Project) below the toolbar.

     

     

    1. Click on “Project Name” and enter a title for the collection of calls that will be imported and paste the link copied from the WSDL URL into the “Initial WSDL” field.

     

     

    Example:

     

     

    1. After importing the WSDL, click 2x on “Request 1”, enter the data as explained in the manual to execute the call of your choice.

     

     

    The importance of this topic is to demonstrate, in a practical way, how to import the WSDL from the Web Service manuals into the SoapUI application.

     

     

    Website

     

    Update of tool manuals available on the website

    By Carlos Dupim Jr.

     

    On the Systax website, the area where access to tool manuals is provided has been updated.

    Previously, this area was called "other downloads", accessible through the Systax website > other options > other downloads. Now, to better reflect the content on the screen, it has been renamed to "website manuals", as follows:

    The content of this screen has been updated, removing obsolete PDF files, and now providing direct links to the Glider folders with the manuals presented, thus ensuring that everyone has access to the latest versions of the documentation.

     

     

    In addition, a table was created in the admin, called "manuals_site", where the information reflected on the website is fed.

    With it, there is no need for the development team's action whenever it is necessary to include a new manual on the website, allowing the user or team with editing permission in this table: to include, change or delete a manual record to be presented.

    Currently, only the Products Team has permission for such changes.

    This set of improvements streamlines the process of including and updating the manuals provided for users and customers on the website, ensuring accuracy and timeliness in the information provided.

    Voltar


Versão do documento: 74 Publicação: 9/20/2024