Vale a pena relembrar

Cockpit

Acessos dos usuários

Por Carlos Cornejo

No Cockpit dos clientes existe a tela de “Acessos dos usuários”, que serve para consultar os logs de acesso ao Cockpit.

O principal objetivo é consultar a data e horário de acesso de cada usuário. Para os usuários internos, as informações de acesso estão consolidadas no cockpit Manager.

A funcionalidade fica no seguinte caminho: Cockpit > Mais Opções > Acesso

Ao acessar a tela o usuário terá a opção de realizar consultas utilizando os parâmetros disponíveis (Usuário, Data Login) ou realizar buscas sem preenchimento dos filtros.

O retorno de informações traz os seguintes dados: Usuário, E-mail e Data Login

Consolidação do Log de acesso

Essas informações são centralizadas no Cockpit Manager, onde é possível visualizar além da data e hora, a quantidade de acessos dentro do período solicitado e a possibilidade de filtrar por cliente.

A tela está no seguinte caminho: Cockpit Manager > Acessos dos usuários

 


Nela é possível realizar consultas utilizando os parâmetros disponíveis (Cliente, Usuários, Data Login) ou fazer a busca de forma geral, sem o preenchimento do filtro.

Diferente do Cockpit do Cliente, a tela de acessos do Manager traz as seguintes informações no retorno: Cliente, Usuário, E-mail, Total de Acessos e Detalhes (esse último campo possui uma lupa de acesso, que abre um pop-up com as informações detalhadas de todos os acessos do usuário em questão (Cliente, Usuário, E-mail e Data Login).

Na tela de Detalhes existe a opção de exportar o resultado em CSV:

O período para guarda dessas informações é de 365 dias, isto é 1 ano.

Desativação de Regras no Cockpit

Por Fernanda Almeida
 

O Cockpit é uma plataforma de gestão de regras tributárias que oferece uma experiência interativa para seus usuários e clientes. Entre suas diversas funcionalidades, destaca-se a capacidade de facilitar a visualização e o gerenciamento das regras tributárias, permitindo que os usuários aprovem, rejeitem e exportem essas regras e exportações dos registros em formato *.csv.

Como já é de conhecimento geral, o cockpit recepciona as regras decorrentes da combinação dos produtos tratados internamente na Systax juntamente com os cenários, isto é, operações praticadas pelo cliente. Essa base de dados é viva e assim como pode receber novas regras com novos resultados tributários, também pode ter regras obsoletas ou não monitoradas devido à exclusão de produtos do sortimento, manutenção dos produtos nos grupos do cenário, exclusão de operações etc.

Para manter a base de dados sempre atualizada o cockpit recebe periodicamente a carga de “Desativação Produtos”:

A carga de desativação ocorre no cockpit quando ocorre as seguintes situações:

• exclusão do produto da base de dados da Systax;
• exclusão ou desativação do cenário da base de dados da Systax;
• exclusão do produto do grupo de produtos vinculado ao cenário;
• retirada do grupo de produtos do cenário.

A incompatibilidade de origem de produtos no grupo de produtos no cenário também aciona a retirada do produto do grupo do cenário.

O tempo de desativação de regras varia de acordo com o processamento do cenário.

Se houver regras em trânsito no webservice, elas serão entregues no cockpit e desativadas no processamento seguinte da base de cenários.

O processamento dos cenários é cíclico, portanto, uma regra de um determinado produto pode ser desativada em um cenário e ainda estar ativo em outro, então, a desativação total de regras só é finalizada após o processamento total dos cenários.

As regras continuam na base de dados do cockpit como desativadas:

Caso a situação anterior à desativação seja restabelecida, ou seja, o produto seja realocado no grupo do cenário ou recriado nos sistemas internos da Systax, na primeira carga de regras que o cockpit receber com a regra, todas as demais regras desativadas para o produto serão reativadas, isto é, perderão o status de desativação e estarão disponíveis para consulta e consumo.

O processo de desativação de regras onde a origem do processo se deu através da verificação dos produtos no grupo dos cenários é feita somente para regras monitoradas. Nos casos de base intermediária ou regra on demand, onde não foi realizada essa manutenção (inserção do produto no grupo do cenário), a desativação de regras somente será feita nos casos em que o produto não existir mais na base de dados da Systax.

Conclusão: O processo de desativação de regras é importante para manter o cockpit sempre atualizado, evitando a visualização de regras desativadas e não consumíveis.

DF-e/DOCs

Controle de usuários e Logs Sistema

Por Jéssica Barreto Parzanese

Uma das coisas mais importantes para os nossos clientes é a segurança e possibilidade de gestão das ações que os usuários executam no sistema, portanto, temos disponível duas funcionalidades aplicáveis e de acesso para o usuário Administrador.

Controle de Usuários

Disponível no menu lateral esquerdo em Administração >>> Controle de Usuários

O usuário de perfil Administrador poderá realizar o controle de acesso por CNPJ para cada usuário com os demais perfis, restringindo a visualização aos dados dos estabelecimentos da empresa. Além disso essa nessa interface também é possível realizar a ativação do acesso MFA (acesos restrito para Consultores e usuários Administradores). Essa opção está disponível para o Systax DF-e.

Logs Sistema

Disponível no menu lateral esquerdo em Administração >>> Logs Sistema

Em Logs Sistema o usuário Administrador consegue visualizar as ações realizadas por um usuário para documentos específicos, telas, chaves ou ID Documento, por período, bem como quem as realizou. Há também a possibilidade de extrair as informações filtradas para um relatório em Excel ou CSV. Opção disponível para o Systax DF-e e DOCs.

Em resumo, as funcionalidades de Controle de Usuários e Logs Sistema dos sistemas Systax DF-e e Systax DOCs garantem aos administradores maior segurança e controle das ações realizadas, permitindo a gestão personalizada de acessos e o acompanhamento detalhado de atividades, com opções práticas de extração de relatórios.

Motor de cálculo

Retorno do crédito presumido com base na tabela “Gestão de crédito presumido na saída”

Por Henrique Moreira

Implementamos no motor de cálculo, para atender o retorno de operações com crédito presumido na saída, um novo cálculo que buscará na tabela do cockpit “Gestão de crédito presumido na saída”, regras cabíveis para aplicação de crédito presumido nas operações de saída.

Sendo assim, nas chamadas do motor com “TPNF=1” (saída) e a configuração “tblCredPresumido” estando ativa no cockpit, o motor irá comparar os dados da operação para verificar se há registros de regras cabíveis nessa tabela e havendo irá calcular o bloco do crédito presumido.

Segue exemplo de retorno abaixo:

Configuração ativa no cockpit:

Chamada do motor de cálculo retornando o bloco do crédito presumido:

Nessa situação, a regra de saída (TPNF=1) encontrou o registro da tabela do cockpit e calculou o bloco do crédito presumido:

Importante observar que nessas situações em que a configuração está ativa e encontrou registro na tabela, o cálculo NÃO considera (se houver) os dados da regra do bloco “ICMS Cred”, mas sim o do registro da tabela.

Nos casos em que a configuração está inativa, o motor segue com os cálculos gerais do bloco do crédito presumido (considerando o que há no bloco do “ICMS Cred”), ou seja, nas hipóteses dos indicadores de crédito 23,24,25 ou 26.

Essa foi uma implementação feita para atendimento de questionamento de cliente, mas pode ser estendida para todos.

Worth remembering

Cockpit

User Access

By Carlos Cornejo

In the clients' Cockpit, there is a screen for "User Access," which is used to consult the access logs to the Cockpit.

The main objective is to check the date and time of access for each user. For internal users, the access information is consolidated in the Manager cockpit.

The functionality is located at the following path: Cockpit > More Options > Access

Upon accessing the screen, the user will have the option to perform queries using the available parameters (User, Login Date) or to conduct searches without filling in the filters.

The return of information brings the following data: User, Email, and Login Date

Consolidation of Access Log

This information is centralized in the Cockpit Manager, where it is possible to view, in addition to the date and time, the number of accesses within the requested period and the ability to filter by client.

The screen is located at the following path: Cockpit Manager > User Access

In it, you can perform queries using the available parameters (Client, Users, Login Date) or conduct a general search without filling in the filter.

Unlike the Client Cockpit, the Manager access screen provides the following information in the return: Client, User, Email, Total Accesses, and Details (the last field has an access magnifying glass, which opens a pop-up with detailed information of all the accesses of the user in question (Client, User, Email, and Login Date).

 

On the Details screen, there is an option to export the result in CSV:




The period for retaining this information is 365 days, that is, 1 year.

Deactivation of Rules in the Cockpit

By Fernanda Almeida

Cockpit is a tax rule management platform that offers an interactive experience for its users and clients. Among its various features, it stands out for its ability to facilitate the visualization and management of tax rules, allowing users to approve, reject, and export these rules and export records in *.csv format.

As is already widely known, the cockpit receives the rules resulting from the combination of products processed internally at Systax along with the scenarios, that is, operations carried out by the client. This database is dynamic and, just as it can receive new rules with new tax results, it can also have obsolete or unmonitored rules due to the exclusion of products from the assortment, maintenance of products in scenario groups, exclusion of operations, etc.

To keep the database always updated, the cockpit periodically receives the "Product Deactivation" load:

The deactivation load occurs in the cockpit when the following situations occur:

• exclusion of the product from the Systax database;
• exclusion or deactivation of the Systax database scenario;
• exclusion of the product from the group of products linked to the scenario;
• removal of the product group from the scene. The incompatibility of product origin in the product group in the scenario also triggers the removal of the product from the group in the scenario.

The incompatibility of product origin in the product group in the scenario also triggers the removal of the product from the group in the scenario.

The time to deactivate rules varies according to the processing of the scenario. If there are rules in transit in the web service, they will be delivered to the cockpit and deactivated in the next processing of the scenario base. The processing of scenarios is cyclical, therefore, a rule for a specific product can be deactivated in one scenario and still be active in another, so the total deactivation of rules is only completed after the full processing of the scenarios.

The rules remain in the cockpit database as deactivated:

If the situation prior to deactivation is restored, that is, the product is reallocated to the scenario group or recreated in Systax's internal systems, in the first rule load that the cockpit receives with the rule, all other rules deactivated for the product will be reactivated, that is, they will lose the deactivation status and will be available for consultation and consumption.

The process of deactivating rules where the origin of the process was through the verification of products in the scenario group is done only for monitored rules. In the cases of intermediate base or on-demand rule, where this maintenance (insertion of the product into the scenario group) has not been performed, the deactivation of rules will only be done in cases where the product no longer exists in the Systax database.

Conclusion: The process of deactivating rules is important to keep the cockpit always updated, avoiding the display of deactivated and non-consumable rules.

DF-e/DOCs

User Control and System Logs

By Jéssica Barreto Parzanese

One of the most important aspects for our clients is the security and ability to manage the actions performed by users in the system. Therefore, we offer two functionalities available for Administrator access.

User Control

Available in the left side menu under Administration >>> User Control

An Administrator user can manage access by CNPJ for each user with other profiles, restricting visibility to the data of the company's establishments. Additionally, in this interface, it is also possible to activate MFA access (restricted to Consultants and Administrator users). This feature is available for Systax DF-e.

System Logs

Available in the left side menu under Administration >>> System Logs

In System Logs, the Administrator user can view the actions performed by a user for specific documents, screens, keys, or Document IDs, within a selected period, as well as who performed them. It is also possible to export filtered information into Excel or CSV reports. This feature is available for Systax DF-e and DOCs.

In summary, the User Control and System Logs features of the Systax DF-e and Systax DOCs systems provide administrators with enhanced security and control over actions performed, enabling personalized access management and detailed activity monitoring, with practical options for report extraction.

Systax engine

Return of presumed credit based on the "Presumed Credit Management on Exit" table

By Henrique Moreira

We have implemented in the Systax engine, to handle the return of operations with presumed credit on exit, a new calculation that will search in the cockpit table "Presumed Credit Management on Exit" for applicable rules for the application of presumed credit on exit operations.

Thus, in the Systax engine calls with “TPNF=1” (exit) and the configuration “tblCredPresumido” being active in the cockpit, the engine will compare the operation data to check if there are applicable rule records in this table. If such records exist, it will calculate the presumed credit block.

Below is an example of the return:

Configuration active in the cockpit:

Calculation engine call returning the presumed credit block:

In this situation, the exit rule (TPNF=1) found the record in the cockpit table and calculated the presumed credit block:

It is important to note that in situations where the configuration is active and a record is found in the table, the calculation does NOT consider (if any) the data from the "ICMS Cred" block rule, but rather the data from the table record.

In cases where the configuration is inactive, the engine follows the general calculations for the presumed credit block (considering the data in the "ICMS Cred" block), that is, in the cases of credit indicators 23, 24, 25, or 26.

This implementation was made to address a customer inquiry, but it can be extended to all.

Voltar