Ticket: 74554 – Tornar obrigatório o campo Tipo Voucher #
Foi adicionado nos “parâmetros do sistema” uma nova opção “Obrigar informar tipo do voucher” em “Pedido de Venda” → “Outros”.
Quando marcada, essa opção obrigará informar o tipo do voucher na criação de um novo voucher.
Sendo assim, se a flag estiver marcada e ao cadastrar um novo voucher estiver vazio o campo “Tipo de voucher” o sistema não irá permitir o salvamento e será exibida a mensagem de erro na tela.
Assim que o “Tipo de voucher” for informado o salvamento ocorrerá como antes.
Ticket: 74886 – Direcionamento de atendimento ao Lyve para pedidos criados com o documento anexado. #
Conforme alinhado presencialmente com o Carlos, para que no sistema da própria ELO o sistema puxe o protocolo automaticamente ao criar um pedido com anexo, é necessário que nos parâmetros do sistema o campo “Url de integração para videoconferência unificada“ não esteja preenchido.
Quando preenchido o sistema tenta atualizar o pedido na “ac” a partir do identificadorExterno, como o pedido foi criado no mesmo sistema a qual a url direciona, o identificador externo fica null, o que faz com que não seja atualizado.
Ao remover a url o sistema subentende que não é necessário atualizar o pedido na “ac”. Fazendo com que o fluxo siga normalmente. Portanto não foi necessário realizar nenhum ajuste técnico.
Ticket: 74562 – Novo Campo no Cadastro de Unidade – Motivo Data Ativação #
Foi criado um novo CRUD “Motivo data de ativação” em “Faturamento” → “Outros” → “Motivo Data de Ativação“.
Para o cadastro de um novo ‘Motivo data de ativação’ foi adicionados os campos “Descrição” e “Ativo”, sendo obrigatório o preenchimento da descrição.
Na listagem é possível filtrar tanto pela situação(ativo ou não ativo), tanto pela descrição.
Já nos cadastros de “Unidade”, foi adicionado o novo campo “Motivo Data de Ativação”, em “Credenciamento/Auditoria” -> “Credenciamento”. Importante lembrar que só é possível adicionar um “Motivo data de ativação” se houver uma “Data de ativação”.
Também foi adicionado o filtro “Motivo data de ativação” na tela de listagem das “Unidades”, dentro dos filtros avançados.
Além também de apresentar no histórico as alterações desse campo no cadastro de uma unidade.
Ticket: 74681 – Erro na integração Syngular para emissão online ao utilizar da triagem #
Anteriormente, ao criar ou editar um pedido com documentos anexados, o sistema enviava automaticamente o pedido para a AC, mesmo nos casos de emissão online, para que o protocolo fosse gerado por lá. No entanto, isso não faz sentido, já que na emissão online é o próprio cliente quem realiza a emissão do certificado.
Por isso, foi feito um ajuste: agora, nos pedidos de emissão online, o protocolo não será mais gerado automaticamente na AC. Ele deverá ser gerado manual e diretamente pela AR, logo o atributo renewalserá true.
Ticket: 74812 – Perda de dados ref. a API de consulta de CPF ao salvar os parâmetros do sistema #
Foi feita a correção para mesmo em casos que o usuário não é GFSIS, ou seja, os campos não aparecem para ele, mesmo assim as informações preenchidas anteriormente nos campos (Consumer Key e Consumer Secret) não serão perdidas como estava ocorrendo.
Ticket: 74262 – Bloqueio de cancelamento do pedido com protocolo Syngular gerado #
Descrição da Atividade Realizada
Foi realizado ajuste na lógica de validação de cancelamento de pedidos, considerando o cenário reportado.
Cenário Anterior:
Para pedidos com status ENVIADO (ou seja, com protocolo gerado), a validação de permissão de cancelamento não considerava adequadamente o modelo de empresas que operam com múltiplas ACs. Isso fazia com que o sistema impedisse o cancelamento mesmo quando deveria permitir, conforme o caso.
Ajustes Realizados:
A regra foi segmentada de acordo com o modelo da empresa:
- Empresas com AC única:
Mantém-se o comportamento anterior. O sistema verifica se o pedido está ENVIADO e se não foi CANCELADO ou REVOGADO no CRM. Caso essas condições sejam atendidas e a AC não pertença ao grupo [SERPRO, CERTIPE, SAFEWEB, AC Digital], o sistema exibe mensagem impedindo o cancelamento. Logo, servia apenas para empresas de AC’s como Soluti, Bry e afins. - Empresas com múltiplas ACs:
Além das validações acima (ENVIADO, não cancelado, não revogado), o sistema verifica se a AC associada ao pedido pertence ao grupo [SERPRO, CERTIPE, SAFEWEB, AC Digital]. Caso não pertença, também exibe a mensagem de impedimento de cancelamento. Logo, serve para pedidos de AC’s como Soluti, Bry e afins.
(Esse foi o caso relatado no ticket.)
Observações Complementares:
- A análise junto ao setor de suporte identificou que, em alguns casos de replicação de protocolo entre AR e AC, o campo ENVIADO não estava sendo corretamente sincronizado. A lógica foi ajustada para garantir a replicação para todas as ACs disponíveis no sistema.
- Ressalta-se que o campo ENVIADO pode permanecer como
falseounullcaso o pedido tenha sido objeto de revogação ou rejeição, o que é o comportamento esperado. Nestes casos, o cancelamento ocorre corretamente, já que o protocolo não está mais em vigor (não está enviado e teve cancelamento/rejeição).
Ticket: 74315 – Processo de troca não está puxando o protocolo de forma automática #
Foi implementada a automatização da geração do protocolo Syngular no processo de troca de pedidos, além do envio automático do link do Lyve, desde que atendidas condições específicas relacionadas ao tipo de atendimento, forma de pagamento e parametrização da unidade.
Cenário Anterior #
No fluxo anterior, mesmo quando todas as condições para envio automático do link do Lyve e geração do protocolo eram corretamente atendidas (como pedidos pagos com voucher ou com contas a receber já baixadas), o novo pedido gerado por meio de uma troca não executava automaticamente a emissão do protocolo Syngular nem o envio do link do Lyve.
Ajustes Realizados #
A regra de validação considera:
- A unidade está configurada para enviar o link do Lyve após a confirmação do pagamento (parametrização no ponto de atendimento);
- O pedido é do tipo videoconferência;
- E ao menos um dos seguintes critérios de pagamento é atendido:
- A forma de pagamento não gera contas a receber;
- A forma de pagamento gera contas a receber já baixadas;
- O pedido foi realizado com voucher 100%;
Nos pedidos de troca, além das validações acima:
- A geração automática só ocorrerá quando o novo pedido estiver sendo criado no sistema for pedido Syngular e não tiver protocolo amarrado.
- É verificado também se o contas a receber transferido do pedido anterior já foi baixado.
Dessa forma, mesmo que o novo pedido tecnicamente não cumpra uma das condições padrão de pagamento (ex: sem voucher), o sistema reconhece que houve uma troca com baixa e prossegue com a emissão do protocolo automaticamente.
Ticket: 74107 – Adicionar tag de link de agendamento no campo “Texto exibido após a confirmação do pedido no site” #
Foi adicionado 2 novas tags na campo da Configuração loja: “Texto exibido após a confirmação do pedido no site”. As tags são [LinkAgendamento] e [LinkAgendamentoTriagem].
(Quando o checkbox “Módulo de videoconferência unificada” estiver marcado e o campo “Url de agendamento para videoconferência unificada” estiver preenchido, as duas tags irão colocar a url preenchida no campo)
(Caso contrario, será urls “fixas”)
Ticket: 75197 – Analisar e corrigir o erro ao enviar documentos para o SYNC #
Foi identificado que o erro em questão ocorria para as tentativas de envio de documento que são realizadas por algum job.
Foi realizado uma correção no sistema para que o envio seja feito de forma correta quando realizado por algum job, para que o procedimento funcione corretamente será necessário preencher o campo URL do GFSIS nos parâmetros do sistema na aba módulos.
Ticket: 75187 – Ajustar os pedidos realizado pelo checkout para criarem o registro na aba videoconferência #
Havia um erro, que quando a compra era realizada por cartáo de crédito o sistema não estava gerado o protocolo automaticamente e consequentemente não era gerado o registro na aba de videoconferência.
Tal erro foi ajustado e agora o sistema se comporta da forma esperada.
Ticket: 75294 – Falha no Retorno de protocolos da AC Gerencial para a AR origem #
Foi feito um ajuste para geração do protocolo para pedidos feitos por cartão de crédito no checkout da Certifica e ocasionou um efeito colateral que impactou na replicação dos protocolos para as AR’s.
Realizado a correção e agora os protocolos estáão sendo replicados da forma devida
Pedido na AR
Pedido na AC
Ticket: 74943 – Ajuste na opção de incluir logomarca em telas públicas #
Foi feito a correção para quando adicionado um ícone para tela públicas, aplica-la nas telas do sistema também.
Após adicionado será atualizado em todas as telas do sistema.
Ticket: 73921 – Validação do porquê não foi gerado crédito para a unidade nos pedidos exemplos #
Após fazer vários testes e tentar reproduzir as ações do usuário, não foi possível reproduzir o erro assinalado, de todas as maneiras eram criadas as operações corretamente.
Há uma recomendação que em casos de edição do pedido por motivo de algum erro no cadastro, recomendamos cancelar o pedido e criar um novo, para evitar possíveis erros.
Ticket: 70822 – Inclusão de filtro por AC #
Foi criado o filtro de Ac para as telas de Recusa e Análise
Ticket: 74792 – Perda de dados ao alterar parâmetros no sistema #
Foi feita a correção da perda de dados dos campos “Unidade padrão para atendimentos Lyve” e “Utiliza URL própria para a solicitação de garantia”, agora mesmo que aconteça uma alteração em outro campo por um usuário que não é GFSIS não haverá alteração em campos que não são carregados por conta do nível de acesso. Além disso, no histórico as alterações de “Unidade padrão para atendimentos Lyve” ficaram registradas em id.
Ticket: 74959 – Ajuste na rota ‘Situação de um pedido’ da API #
Existe uma limitação nos navegadores que não aceitam requisições get com bodyJSON, mas em uso prático ou também no postman essa requisição funcionará como o exemplo abaixo:
Vale salientar que essa requisição passada do “ConsultaPedidoVendaLTS” busca apenas pedidos via site:
Não será possível fazer a alteração pois já é usado em produção e funciona, em âmbito de teste pode usar o postman como nos prints.
Ticket: 75207 – Criar nível de acesso para bloquear de gerar protocolo #
Foi criado um nova opção de ação ”Bloquear geração de protocolo” em “Nível de Acesso” → “Outras ações” → “Protocolo”, quando essa opção estiver marcada as opções de gerar protocolo no sistema serão desativadas para o usuário
Pode se perceber nos exemplos abaixo que os protocolos já gerados ainda aparecerão, mas os que ainda devem ser gerados não terão essa opção.
Quando desmarcado o procedimento segue o mesmo.
Ticket: 75380 – Criar botão de ativar/desativar empresa no e-notas #
Na tela de Empresa na aba Módulos, na configuração do Enotas foi incluido o botão para Habilitar e Desabilitar a empresa no Enotas, caso a empresa deixe de emitir NF ou antes de finalizar uma instância é necessário desabilitar a empresa no Enotas.
