Orientações técnicas

Melhoria entregue até 09/06/2025

Disponibilizadas novas variáveis de contexto para atualização de críticas de usuários

Com objetivo de obter um maior alcance nas validações de dados, implementamos novas variáveis de contexto para uso em críticas de usuário (menu Utilitários > Gerenciador de scripts). Abaixo, listamos as novas variáveis que fazem parte das liberações:

• Variável usuario.id (já existente) - exemplo:

    Mensagens.info(usuario.id) ;
    // retorno: john.doe

• Variável database.id - exemplo:

    Mensagens.info(database.id);
    // retorno: 10082

• Variável entidade.id - exemplo:

    Mensagens.info(entidade.id);
    // retorno: 9552

• Variável contexto - exemplo:

    Mensagens.info(contexto);
    // retorno: {exercicio=2023}
  
    Mensagens.info(contexto.exercicio);
    // retorno: 2023

Essas novas variáveis deverão ser utilizadas conforme suas especificidades e as críticas de usuários (validações), hoje existentes nos sistemas Contábil (Cloud), Tesouraria (Cloud), Planejamento (Cloud) e Convênios (Cloud) e criados pelos Canais, deverão ser revisados para que as variáveis locais sejam alteradas caso sejam idênticas às liberadas acima.

Essa alteração visa a não utilização das mesmas variáveis liberadas pelo Desenvolvimento para evitar mensagens/bloqueios como:

Assim, as váriáveis locais utilizadas nas críticas de usuários pelos Canais deverão ser alteradas, como por exemplo:

• De: entidade = registro.novo.entidade.id
• Para: entidadeId = registro.novo.entidade.id

Os Canais terão até o dia 10/07/2025 para adequação de suas críticas de usuários. Após essa data, as variáveis acima farão parte do contexto de uso reservado e qualquer validação que não esteja adequada, bloqueará o usuário nos diversos cadastros que possuam críticas com as variáveis já citadas.

Realizamos o levantamento das críticas de usuários que possuem as variáveis de contexto que serão de uso reservado. Assim, basta que os Canais acessem o arquivo abaixo para saber quais validações precisarão de ajustes:

• Críticas variáveis

Agradecemos a compreensão e colaboração dos profissionais para que possamos alcançar maiores benefícios nas validações de dados cadastrais para os usuários

Melhoria entregue até 30/05/2025

Permitido enviar Anexos para o cadastro de Comprovantes via Service Layer​

Informamos aos usuários técnicos que o cadastro de Comprovantes (menu Administrando > Controle > Comprovantes) possibilita que sejam enviados Anexos por meio do Service layer durante o processo de migração de dados. No entanto, para que haja o correto recebimento do arquivo e, a fim de evitar futuros problemas, é necessária a observância de alguns pontos, sendo eles:

1. Estrutura do Service Layer de Anexos

Armazenamento Temporário no S3:

• Arquivos temporários:

  • Quando um arquivo é enviado ao Service layer de Anexos, ele é armazenado em uma pasta temporária no S3. Esses arquivos permanecem na pasta temporária por até 7 dias, sendo excluídos automaticamente após esse período caso não sejam vinculados a nenhum comprovante.
  • Portanto, é fundamental, a vinculação do Anexo ao Comprovante dentro do período máximo de 7 dias após o envio ao Service Layer, caso contrário o arquivo será excluído.

• Arquivos permanentes:

  • Quando o arquivo é vinculado a um comprovante, ele é movido da pasta temporária para uma pasta permanente no S3, garantindo sua persistência.

  2. Regras para Upload de arquivos

• Tamanho máximo permitido: 10 MB para cada arquivo.

  • Arquivos que excederem esse limite serão rejeitados e uma mensagem de erro apropriada será retornada para o usuário.

• Tipos de arquivo permitidos: Somente os formatos abaixo listados poderão ser enviados, qualquer outro formato será rejeitado:

Extensão	Descrição
.doc	Documento Microsoft Word (DOC)
.docx	Documento Microsoft Word (DOCX)
.pdf	Documento PDF (Portable Document Format)
.rtf	Rich Text Format (RTF)
.txt	Documento de texto simples (TXT)
.html	Página HTML (HTML)
.htm	Página HTML (HTM)
.xls	Planilha Microsoft Excel (XLS)
.xlsx	Planilha Microsoft Excel (XLSX)
.jpg	Imagem JPEG (JPG)
.jpeg	Imagem JPEG (JPEG)
.png	Imagem PNG (PNG)

3. Exemplo de Request para Envio de Arquivos

Abaixo demonstra-se um exemplo de requisição CURL utilizada para enviar arquivos ao Service layer de Anexos:

• Detalhes do Payload:

  • idIntegracao: Identificador único da integração.
  • tipo: Identifica o tipo de arquivo, neste caso, "COMPROVANTES".
  • files: Arquivo enviado como parte da requisição multipart.

  4. Atualização do Service layer de Comprovantes com PATCH

No intuito de simplificar a vinculação entre Comprovantes e Anexos, implementamos o método PATCH no Service layer de Comprovantes, de modo a permitir a atualização apenas dos IDs dos Anexos****, sem necessidade de realizar o envio de todos os dados dos comprovantes novamente.

Veja o exemplo do request abaixo:

Detalhes:

• idGerado: Identificador do comprovante.
• documentos: Lista de IDs dos anexos que devem ser vinculados ao comprovante.

Para facilitar ainda mais, abaixo disponibilizamos um vídeo demonstrando o passo a passo de como realizar envio de Anexos ao Service Layer:

Quanto ao relacionamento dos Anexos com o cadastro de Comprovantes, basta utilizar os parâmetros abaixo:

Importante!

Atualmente é possível realizar o relacionamento apenas com o cadastro de Comprovantes, em breve serão liberados os demais cadastros.

Comunicado realizado em 28/06/2024

Ativação de saldos da despesa de exercícios anteriores e API de ordenação de despesas

Como é de conhecimento, no processo de migração do sistema Contábil (Cloud) não é necessário rodar a API do Service Layer para ativação dos saldos para Empenhos, Anulações de Empenhos, SubEmpenhos, Anulações de Subempenho, Em Liquidação, Anulações de Em Liquidação, Liquidações, Anulações de Liquidação, Pagamentos, Anulações de Pagamentos e Bloqueios e Desbloqueios, referentes aos exercícios anteriores, que não se configuram como restos a pagar no exercício atual.

Anteriormente esse método era necessário para que o sistema pudesse identificar se o Empenho estava totalmente pago em um determinado exercício, de modo a não ser listado como Resto a pagar nos exercícios seguintes.

Atualmente o sistema Contábil (Cloud) identifica automaticamente, com base nas movimentações, se o Empenho será, ou não, demonstrado no ano seguinte como Resto a pagar.

É importante destacar que a migração padrão antiga, possuía o Arqjoblet SaldosDespesasOrdenaJSON, executava a API despesas-movimentacoes, a qual era necessária para ordenação das despesas e para permitir a correta ativação de saldos. Porém, devido às atualizações disponibilizadas na funcionalidade de Controle de saldos da Despesa e Recursos esse processo não é mais necessário.

Dessa forma, lembra-se, que as migrações que não estejam aderentes a estes facilitadores, devem ser adequadas, a fim de proporcionar maior agilidade nas migrações.

Migração dos registros contábeis no Contábil (Cloud)

1. Opções para anos anteriores

1.1. Registros analíticos:

1.1.1 Migrar os registros contábeis diretamente para o cadastro de lançamentos manuais (registros analíticos):

Não havendo possibilidade de realizar o vínculo de cada registro contábil do sistema concorrente/anterior com os Id’s dos documentos de origem, a migração diretamente para os lançamentos manuais se torna mais simples, não havendo necessidade de se realizar as configurações contábeis (Eventos Contábeis, Contas Correntes e Equivalências).

Contudo, é indispensável a conferência detalhada dessas configurações, visto que não haverá vínculo com documento de origem.

Para isso, disponibilizamos as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/estornos-lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-lancamentos-contabeis-itens

1.1.2 - Migrar os registros contábeis para a escrituração contábil (registros analíticos):

Havendo a possibilidade de vínculo dos registros contábeis com os seus respectivos documentos de origem (Id’s) a migração pode ser realizada diretamente para a Escrituração de documentos, não havendo necessidade de se realizar as configurações contábeis (Eventos Contábeis, Contas Correntes e Equivalências).

Porém, é importante ter muito cuidado na conferência, uma vez que essa ação envolve todos os registos analíticos.

Para isso, temos a seguinte API do Service Layer disponível:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/eventos-documentos

Para a utilização da referida API, é necessário apenas a existência de Evento Contábil configurado com documento igual a Todos, conforme exemplo abaixo:

1.1.3 Regerar todos os registros contábeis na escrituração, de forma nativa e integral:

Esta opção necessita migrar toda parte cadastral sem necessidade de migrar os registros contábeis para a escrituração, pois estes serão criados com a regeração de todos os registros contábeis. Para isso, será necessário que a configuração contábil esteja completa (Eventos Contábeis, Equivalências e Contas Correntes).

Esta opção, que não é a mais recomendável, irá criar um alto volume de processamento, exigindo muito zelo na conferência dos dados, para que estes estejam íntegros com a base migrada.

Para isso, temos as API's do Service Layer que são atualmente utilizadas na migração padrão.

1.2. Saldos acumulados:

1.2.1 Implantar os movimentos acumulados de forma diária/mensal/anual diretamente nos lançamentos manuais (saldos acumulados):

É possível implantar manualmente os movimentos acumulados de forma anual (1 lançamento por ano), mensal (12 lançamentos por ano) ou diária (até 365 lançamentos por ano), baseando-se no balancete de verificação (ou similar) do sistema concorrente/anterior e realizando lançamentos únicos com os acumulados (débitos e créditos).

Neste caso não se terá o detalhamento para emissão de razão analítico e outras conferências do tipo. Importante, neste caso, fazer a implantação de cada mês e sua imediata conferência.

Para isso, temos as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/estornos-lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-lancamentos-contabeis-itens

1.2.2 Migrar os registros contábeis acumulados anualmente diretamente para o cadastro de saldos:

É possível implantar manualmente os movimentos acumulados diretamente para o cadastro de saldos, baseando-se no balancete de verificação (ou similar) do sistema concorrente/anterior e realizando lançamentos únicos com os acumulados (débitos e créditos), existirá 1 lançamento por ano.

Neste caso não se terá o detalhamento para emissão de razão analítico e outras conferências do tipo. Importante, neste caso, fazer a implantação de cada mês e sua imediata conferência.

Para isso, temos as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/saldos-iniciais
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/saldos-iniciais-itens
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-saldos-iniciais-itens

1.3. Não implantar os registros contábeis dos anos anteriores:

Considerando que todas as prestações de contas dos anos anteriores foram realizadas nos sistemas ativos na respectiva época, esta possibilidade, se adotada, restringirá a emissão de alguns relatórios de conferências, como o balancete de verificação, razão analítico contábil, entre outros.

2. Opções para o ano corrente:

2.1. Registros analíticos:

2.1.1 - Migrar os registros contábeis diretamente para o cadastro de lançamentos manuais (registros analíticos) até o mês necessário:

Não havendo possibilidade de realizar o vínculo de cada registro contábil do sistema concorrente/anterior com os Id’s dos documentos de origem, a migração, se realizada diretamente para os lançamentos manuais, se torna mais simples, uma vez que não há necessidade de ter as configurações contábeis (Eventos Contábeis, Contas Correntes e Equivalências).

No entanto, vale ressaltar que é necessário realizar uma conferência mais detalhada das configurações, tendo em vista que não haverá vínculo com documento de origem.

Nessa situação é importante fazer a implantação de cada mês e sua imediata conferência.

Para isso, temos disponíveis as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/estornos-lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-lancamentos-contabeis-itens

2.1.2 - Migrar os registros contábeis para a escrituração contábil (registros analíticos) até o mês necessário:

Havendo a possibilidade de vínculo dos registros contábeis com os seus respectivos documentos de origem (Id’s) a migração pode ser realizada diretamente para a escrituração de documentos, não havendo necessidade de ter as configurações contábeis (Eventos Contábeis, Contas Correntes e Equivalências), apenas a existência de Evento Contábil configurado com documento igual a Todos, conforme já exemplificado anteriormente.

É importante ter muito cuidado na conferência, haja vista que o procedimento envolve todos os registos analíticos.

Para isso, disponibilizamos a seguinte API do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/eventos-documentos

2.1.3 - Regerar todos os registros contábeis na escrituração, de forma nativa e integral até o mês necessário:

Esta opção necessita migrar toda parte cadastral sem necessidade de migrar os registros contábeis para a escrituração, pois estes serão criados com a regeração de todos os registros contábeis. Para isso, será necessário que a configuração contábil esteja completa (Eventos Contábeis, Equivalências e Contas Correntes).

Esta opção cria um alto volume de processamento e também exige muito zelo na conferência dos dados, para que os dados fiquem íntegros com a base migrada.

Para isso, temos as API's do Service Layer que são atualmente utilizadas na migração padrão.

2.2. Saldos acumulados:

2.2.1 Implantar os movimentos acumulados de formal diária/mensal/anual diretamente nos lançamentos manuais (saldos acumulados) até o mês necessário:

É possível implantar manualmente os movimentos acumulados de forma anual (1 lançamento por ano), mensal (12 lançamentos por ano) ou diária (até 365 lançamentos por ano) até o mês necessário, baseando-se no balancete de verificação (ou similar) do sistema concorrente/anterior e realizando lançamentos únicos com os acumulados (débitos e créditos).

Neste caso não se terá o detalhamento para emissão de razão analítico e outras conferências do tipo.

É importante fazer a implantação de cada mês e sua imediata conferência.

Para isso, temos disponíveis as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/estornos-lancamentos-contabeis
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-lancamentos-contabeis-itens

2.2.2 Migrar os registros contábeis acumulados anualmente diretamente para o cadastro de saldos até o mês necessário:

É possível implantar manualmente os movimentos acumulados diretamente para o cadastro de saldos, baseando-se no balancete de verificação (ou similar) do sistema concorrente/anterior e realizando lançamentos únicos com os acumulados (débitos e créditos), existindo 1 lançamento por ano.

Neste caso não se terá o detalhamento para emissão de razão analítico e outras conferências do tipo.

Assim, sugere-se fazer a implantação de cada mês e sua imediata conferência.

Para isso, disponibilizamos as seguintes API's do Service Layer:

• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/saldos-iniciais
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/saldos-iniciais-itens
• https://con-sl-rest.betha.cloud/contabil/service-layer/v2/api/contas-correntes-saldos-iniciais-itens

Comunicado realizado em 04/03/2024

Atenção para o processo de migração com envios de lotes!

Como você, técnico, está realizando os envios dos lotes durante o processo de migração ou implantação?

Por meio deste comunicado, o Desenvolvimento traz em pauta a questão da quantidade de itens por lotes enviados durante o processo de migração e implantação.

É importante que o envio seja realizado com 50 itens por lote, ou seja, ao montar um array, você poderá informar 50 itens e enviá-lo para processamento.

Estamos verificando e constatando que os profissionais técnicos estão enviando um item por lote, causando enfileiramento de lotes a serem processamos e uma sobrecarga altíssima no Service Layer.

Então fique atento! Todas as APIs de migração do Contábil, Planejamento e Tesouraria já estão preparadas para receber 50 itens por lote. Por isso, utilizem essa boa prática durante o processo de migração/implantação.

Utilizando como exemplo a API "deducoes-receitas", observe como está sendo realizado o envio hoje:

      {
           "idIntegracao": "1",
            "content": {
             "descricao": "Dedução A",
             "tipo": "OUTRAS_DEDUCOES",
             "camposAdicionais": [
                {
                  "variavel": "xxx",
                   "valor": "yyy"
                 }
             ]
       }
 }

Agora observe um exemplo de como deveria ocorrer o envio:

 [{
     "idIntegracao": "1",
     "content": {
         "descricao": "Dedução A",
         tipo": "OUTRAS_DEDUCOES",
         "camposAdicionais": [
         {
           "variavel": "detalhamento",
            "valor": "Cadastrado para ajuste"
         }
     ]
  }
 },
 {
       "idIntegracao": "1",
        "content": {
           "descricao": "Dedução B",
           "tipo": "OUTRAS_DEDUCOES",
            "camposAdicionais": [
            {
              "variavel": "xxx",
              "valor": "yyy"
          }
     ]
  }
 },
 {
          "idIntegracao": "1",
           "content": {
              "descricao": "Dedução C",
              "tipo": "OUTRAS_DEDUCOES",
              "camposAdicionais": [
               {
                 "variavel": "xxx",
                 "valor": "yyy"
            }
      ]
  }
 },
 {
            "idIntegracao": "1",
            "content": {
               "descricao": "Dedução D",
                "tipo": "OUTRAS_DEDUCOES",
                "camposAdicionais": [
                  {
                     "variavel": "xxx",
                      "valor": "yyy"
             }
       ]
  }
}]

Comunicado realizado em 23/01/2024

Possibilitada a personalização das mensagens de críticas de usuários dos tipos Avisos e Erros

A partir desta liberação é possível personalizar o tempo de exibição e o botão de fechar nas mensagens de validações (críticas) de usuários dos tipos Aviso e Erro.

Para fazer uso desta personalização é necessário cadastrar variáveis de ambiente. Acesse F4 > Gerenciador de extensões > Variáveis de ambiente ou diretamente o menu Utilitários > Gerenciador de scripts > Configurando > Variáveis de ambiente.

Chave	Valor	Definição
X_BTH_MESSAGES_TIME	10000	Refere-se ao tempo (milisegundos) que a mensagem permancerá em tela para o usuário
X_BTH_MESSAGES_CLOSE	ENTENDI	Refere-se ao texto do botão de fechar da mensagem, no qual o usuário poderá clicar para fechar. Exemplos: OK, ENTENDI etc.

Após a personalização, veja como ficará em tela na alidação cadastral do tipo Aviso:

Comunicado realizado em 28/12/2023

Orquestração de configurações contábeis

Comunicamos às revendas e filiais que uma nova ferramenta denominada Orquestração de configurações contábeis, foi disponibilizada no sistema Contábil.

Por meio dela será possível realizar as orquestrações sem a necessidade de ser realizado o tratamento de dados pela equipe de desenvolvimento da Betha Sistemas.

Clique aqui e saiba como utilizar essa nova ferramenta.

Comunicado realizado em 06/11/2023

Comunicado aos técnicos do PR

Prezados técnicos do estado do Paraná,

Com o intuito de aprimorar a emissão de dados consolidados em relatórios legais e para cumprir as exigências do SIAFIC, especificamente no que diz respeito ao sistema Contábil (Cloud), é fundamental que as liberações das entidades sob gestão dos poderes executivos e legislativos municipais sejam licenciadas no mesmo database.

Este é um assunto já extremamente conhecido por todos os canais técnicos, e gostaríamos de reiterar a importância dessa prática. Além disso, fornecemos o link para nossa Central de Ajuda, que contém informações de grande relevância sobre o sistema Contábil versus SIAFIC. Para acessar, clique aqui.

Agradecemos a atenção de todos e contamos com a colaboração de cada um para manter nossos processos eficientes e em conformidade com as regulamentações em vigor.

Orientação realizada em 06/10/2023

Mapeamento das APIs públicas

Prezados,

Disponibilizamos por meio deste link o mapeamento das APIs públicas que podem ser acessadas por terceiros, revendas e parceiros, via API Gateway (esses endpoints são os mesmos utilizados pelas fontes de dados do sistema).

Importante!

Manteremos essa planilha sempre atualizada, incluindo todas as novas APIs que forem disponibilizadas.

Também é possível acessar por meio deste link, utilizando a chave pública do parceiro.

Agradecemos pela parceria contínua e estamos à disposição para esclarecer qualquer dúvida que possa surgir.

Orientação realizada em 25/07/2023

Adequação no Assistente (F4) - Relatórios

Prezados,

Comunicamos que a tag Anexos Mensais foi removida do Assistente (F4) - Relatórios.

Todos os relatórios padrões que estavam vinculados a essa tag foram migrados para a tag Gerenciais.

Orientação realizada em 30/06/2023

Nova fonte de dados do campo Organograma da conta bancária

Atenção técnicos,

Gostaríamos de informar uma atualização importante relacionada à novidade Organogramas nas contas bancárias, divulgada anteriormente em 28/06/2023. Conforme mencionado, o campo Organograma agora é de múltipla escolha. Além disso, destacamos a criação de uma nova fonte de dados chamada contaBancariaEntidadeExercicioOrganograma.

Se o seu canal, revenda ou filial, possui algum artefato (script e/ou relatório) que busca informações do antigo campo, recomendamos fortemente que você atualize o artefato para buscar informações da nova fonte de dados:

De: contasBancariasEntidadeExercicio.organograma.
Para: contaBancariaEntidadeExercicioOrganograma.

É importante ressaltar que o antigo campo deixou de ser exibido na tela, razão pela qual foi realizada a conversão para migrar os organogramas informados no antigo campo Organograma para o novo campo múltiplo.