Com as evoluções tecnológicas do Protheus recebemos a solicitação de remoção do arquivo de semáforo contábil. Para que isso aconteça, surgiu a necessidade de um estudo detalhado das funcionalidades das funções a serem utilizadas e recebemos orientações da área de Tecnologia da TOTVS.
Hoje, na contabilização de integrações existe a função LockByName para o controle de execução desse processo. Este processo cria um registro de identificação do processo na tabela de semáforo contábil, faz o bloqueio deste registro e já libera o LockByName do processo. O bloqueio do registro da tabela do semáforo Contábil é retirado e excluído dessa tabela pelo processo que o bloqueou ao término do processamento. Existem também o controle das contabilizações on line.
A princípio, como primeira solução, fomos orientados a utilizarmos apenas a função LockByName, sem a criação da tabela de semáforo contábil. Com isto surgiram questões como a ocorrência de um bombardeio dessa função e a preocupação de ocasionar uma lentidão generalizada no sistema e/ou a perda de dados. Outra questão trazida a tona foi a função Ca100Incl ser chamada dentro de transação.
Como segunda solução, a sugestão da Controladoria, pela perspectiva de Produto, era a de criar a tabela do semáforo contábil no dicionário de dados, assim não impactaria no que hoje já existe.
Por fim, após entendimento de todas as questões acima citadas entre as áreas de Controladoria e Tecnologia, fomos orientados a uma terceira solução.
Primeiro, não alterar o local das chamadas da função Ca100Incl dentro do ERP, porém receber o parâmetro aFlagCtb preenchidos com os devidos valores para que os registros contabilizados possam ser marcados como contabilizados nos módulos origem.
Segundo utilizar a função Starjob para pegar o número do documento contábil.
Esta funcionalidade será utilizada em todos os módulos do ERP em que existe contabilização, Mensagem Única e dentro do próprio módulo Contabilidade Gerencial.
Após discussões das questões de performance, concorrência, perda de dados, funções dentro de transações, fomos orientados a adotar a solução abaixo que serão feitos em dois pontos.
Na função de contabilização Ca100Incl, na contabilização de integrações, receber do módulo origem o vetor aFlagCTB preenchidos com as devidas posições, aFlagCTB{ 'campo da tabela a ser marcado', 'string a gravar', 'alias da tabela a marcar', 'recno a ser marcado' } para todos os registros de origem a serem contabilizados. Também não alterar o local da chamada dessa função dentro do ERP, podendo algumas chamadas ficarem dentro de transação.
Outro ponto é na chamada da função que gera o número do próximo documento contábil, ProxDoc. Como esta função pode estar dentro de uma transação, caso ela não consiga pegar um número de documento contábil disponível, utilizar a função Starjob para gerar 5 ( definido em conjunto com time TEC ) números de documento contábil e novamente tentar pegar um número de documento disponível e bloquear e marcar como usado.
a. Ca100Incl e SimpleLock
Na primeira situação em que a função Ca100Incl é chamada recebendo o vetor aFlagCTB, os elementos do vetor devem ser bloqueados para ser no final atualizados. O conteúdo de alguns campos da tabela CTK também deverão ser bloqueados, como o CTK_TABORI e CTK_RECORI, pois nem sempre o conteúdo destes campos da tabela CTK são os mesmos do vetor aFlagCTB. Na grande maioria das vezes será, neste caso, se utilizarmos a função SimpleLock ou uma outra que não utilize o LockByName ocultamente, duas vezes, devemos certificar que não ocorrerá nenhum problema. Também devemos certificar que uma outra conexão não consiga pegar esse registro.
Na segunda situação da chamada da função Ca100Incl, deve ser dada atenção e aprofundar o entendimento dos fontes onde o vetor aFlagCTB não é passado. Isso ocorre em algumas rotinas de contabilização de integração e dentro do próprio módulo Contábil. Também verificar e/ou identificar para qual outra finalidade esse vetor é utilizado. Por exemplo, se pode ser passadas tabelas de usuário e se existe algum tratamento específico nesta situações.
Outro ponto, é onde a função Gravalanc é chamada. Essa função é chamada em alguns pontos em que um procedimento e/ou regra de execução deverá ser definido, estamos falando das rotinas de rateio contábil, consolidação, Apuração de Resultados. Por exemplo, se faz sentido processar ao mesmo tempo os mesmos rateios em períodos diferentes mas subsequentes onde os lançamentos do primeiro influenciam na do segundo.
b. Starjob e RpcSetEnv
A função ProxDoc que verifica qual o número do próximo documento contábil disponível e faz o seu bloqueio pode estar dentro de uma transação. Por isso, caso ela não consiga pegar um número de documento contábil disponível, devemos criar uma função utilizando a função Starjob para gerar 5 ( definido em conjunto com time TEC ) números de documento contábil e voltar para a função ProxDoc até que consiga pegar e bloquear um número de documento disponível.
Neste caso existe alguns quesitos a serem verificados. Primeiro, se a função StarJob pode ser executada sem antes chamar a função RpcSetEnv. Pois essa última faz a abertura de um novo ambiente, o que poderia causar lentidão.
Outra questão, se o job iniciado não termina, qual procedimento deverá ser tomado, já que provavelmente entrar em um 'loop' infinito.
Nessa situação em que o número do documento será gerado por um Job, poderá e provavelmente ocorrerá de o número do documento não ser sequencial. Quais são ou existem restrições em relação a geração de números de documentos não sequenciais?
Coloque o link das tabelas relacionadas
<!-- esconder o menu -->
<style>
div.theme-default .ia-splitter #main {
margin-left: 0px;
}
.ia-fixed-sidebar, .ia-splitter-left {
display: none;
}
#main {
padding-left: 10px;
padding-right: 10px;
overflow-x: hidden;
}
.aui-header-primary .aui-nav, .aui-page-panel {
margin-left: 0px !important;
}
.aui-header-primary .aui-nav {
margin-left: 0px !important;
}
</style>
|