Bom dia,
O comportamento de só acontecer num posto em particular indica quase sempre um problema de ambiente/local (Visions, collation, utilizador, ou configuração desse POS) e não um bug geral da base de dados.
Há alguns pontos que deve validar nesse posto onde o FCX está a ser criado com o campo fcxstamp vazio:
- Visions desse posto
- Em situações semelhantes em que o problema só ocorre num posto, ficou resolvido quando as Visions foram criadas com o utilizador SA, ou seja, no primeiro acesso ao Cegid PHC nesse posto os VISION terem sido criados como SA.
- Passos sugeridos:- Fechar o Cegid PHC nesse posto.
- Apagar as Visions locais desse posto (pasta VISION / ficheiros de Visions, conforme a instalação).
- Entrar no Cegid PHC com o utilizador SA nesse posto, para que as Visions sejam recriadas com SA.
- Testar novamente a abertura/fecho de caixa e confirmar se o fcxstamp passa a ser preenchido.
- Collation da instância SQL
- Quando há comportamentos estranhos em apenas alguns postos, é importante garantir que a instância SQL está com a collation recomendada:
SQL_Latin1_General_CP1_CI_AI
Se a instância não estiver com esta collation, podem ocorrer comportamentos inesperados em cursores/tabelas como FCX.
Procedimento recomendado (a validar com cuidado):- Garantir que existem FULL BACKUPS recentes e que não há utilizadores a trabalhar.
- Instalar uma nova instância SQL com collation SQL_Latin1_General_CP1_CI_AI.
- Fazer Detach da base de dados na instância antiga e Attach na nova instância.
- Testar novamente o POS e a criação de registos FCX.
- Utilizador e permissões no posto
- Confirme se o utilizador que abre o POS nesse posto tem exatamente as mesmas permissões que nos outros postos onde o problema não ocorre.
- Se estiver a usar login único ou utilizadores com permissões específicas na base de dados, valide se não há diferenças de permissões (datareader/datawriter) que possam afetar a escrita do fcxstamp. - Recriação de Visions por cópia de outro posto
- Se ao copiar as Visions de uma máquina onde tudo funciona para este posto o problema fica resolvido, mas volta a aparecer quando as Visions são apagadas e recriadas, isso reforça que o problema está na forma como as Visions são criadas nesse posto.
- Por isso é importante garantir que a primeira criação de Visions é feita com SA, conforme indicado acima. - Validação adicional no ecrã de caixa (SCX/FCX)
- Recorde que as grelhas de alguns ecrãs de caixa não estão diretamente ligadas à tabela FCX; são criados cursores (por exemplo fcxS para Sangrias) com base na tabela FCX e só contemplam os campos base da aplicação.
- Se tiver campos de utilizador ou personalizações, estes não são passados para o cursor que alimenta a grelha, pelo que qualquer desenvolvimento que dependa de campos adicionais pode interferir com o preenchimento do fcxstamp.
- Desative temporariamente desenvolvimentos (visions, triggers, Xbase) nesse posto e teste se o fcxstamp passa a ser preenchido.
Em resumo, para este caso concreto em que só um posto apresenta FCX com fcxstamp vazio após a atualização para Evolution, os passos prioritários são:
- Apagar e recriar Visions nesse posto com login SA.
- Confirmar collation da instância SQL (SQL_Latin1_General_CP1_CI_AI).
- Validar permissões do utilizador e desativar desenvolvimentos nesse posto para teste.
Se após estas validações o comportamento se mantiver, será útil recolher um cenário reproduzível (passos exatos de abertura/fecho de caixa nesse posto) e comparar com um posto onde funciona, para permitir uma análise mais aprofundada.
Esta resposta foi gerada pelo Cegid Pulse, com base na base na informação disponível em histórico.
Ajude-nos a melhorar esta funcionalidade:
• Se a resposta corresponde à sua questão, assinale-a com "Mark as best answer",
• Se a resposta estiver incorreta, dê-lhe um voto negativo e aguarde a resposta da comunidade.
