Ticket: 68561 – Integração pagamento em lote com ITAU #
Conforme solicitação, foi realizada a integração com o Itaú para o processo de pagamentos em lote a partir do sistema GFSIS.
Uma vez com o módulo devidamente configurado, (Paramêtros do sistema → Módulos / Forma de pagamento → Pagamento automático), e com os cadastros da ENTIDADE RECEBEDORA (Fornecedor, Vendedor, Contador e afins) devidamente preenchidos, é possível utilizar do banco Itaú para realizar pagamentos.
Importante ressaltar que a CONTA do cliente deve estar autorizada junto ao Itaú (necessário falar com o gerente da conta), possuir um certificado digital PFX (processo para geração desse certificado já foi mapeado nos canais de Documentação) bem como o Client Id e Client Secret (obtidos com o gerente ou nas configurações da própria conta).
ATENÇÃO: importante ressaltar com o cliente que esse processo somente cria o registro no SISPAG (portal de pagamentos do Itau), sendo que é necessário autorizar a transação via aplicativo ou internet banking. Essa limitação se deve por restrição do próprio banco Itaú e NÃO é possível de ser feito de outra forma (entramos em contato com o gerente de TI e foi comunicado que é uma medida de segurança).
Ao clicar em “Realizar pagamento” na tela de pagamento lote, o documento de contas a pagar já sofre a baixa e todo o processo, mas ainda é necessário confirmar no SISPAG.
Ticket: 71129 – Ajustar o erro ao enviar os documentos do pedido ao SYNC #
Realizamos diversos testes em ambiente de homologação mas não obtivemos sucesso em replicar o cenário onde o arquivo não era encontrado no S3.
Mas, para ajudar na identificação do erro, adicionamos o nome do arquivo a qual gerou erro, junto ao registro de status do disparo de todos os anexos, e não apenas o do erro, como forma de confirmar que cada um foi disparado corretamente ou qual teve erro:
Ticket: 67313 – Linhas duplicadas no Excel gerado pelo ambiente de videoconferência #
Foi realizado um ajuste na listagem da videoconferência, pois o problema em questão era que ao filtrar por um período de aprovação alguns registros vinham duplicados na própria listagem e consequentemente no excel.
Ticket: 70347 – Erro na hora de realizar o pagamento pelo E-commerce, avaliar possibilidade de mudar a exibição de instrução #
Foi alterada a descrição do campo de validade para “Validade MM/AAAA”, e também é obrigatório colocar 6 dígitos no campo
Ticket: 71378 – Ajuste necessário para preenchimento das informações de nota fiscal de serviço presentes no pedido de venda + Adição de outra ação para permissão de visualização dessas informações #
Ajuste realizado para carregar corretamente as informações de nota fiscal dentro do pedido venda, sendo uma ou várias.
Criado um nível de acesso que irá permitir acessar essa aba mesmo não sendo administrador.
Ticket: 71442 – Falha ao enviar resposta para e-mail do AGR ao concluir atendimento do suporte #
Testes realizados em ambiente de homologação, sem sucesso em identificar o erro do disparo.
Para mitigar os erros, foi criado o modelo de e-mail referente a conclusão do atendimento, que é disparo para o AGR:
Esse modelo será incluído em todas as instâncias a partir da próxima publicação, e é o modelo padrão que já era enviado.
Com isso, o processo foi testado novamente e o disparo chega corretamente ao e-mail do AGR:
Por fim, adicionamos também um controle de histórico melhor para identificar se o e-mail foi ou não enviado com sucesso para o AGR, ambos as duas situações serão registradas:
Ticket: 69354 – Ajuste no envio Link Lyve – Forma de pagamento que gera baixada #
Ajuste no processo de criação de pedidos para caso estiver no escopo do envio de link do Lyve, caso a forma de pagamento esteja com a marcação de “Gerar o contas a receber baixado“, faça o envio corretamente:
Ticket: 68253 – Ajuste no relatório “resumo mensal do faturamento” para puxar 30 dias quando usado do filtro diário #
Conforme solicitado, foi ajustado para que o relatório de resumo mensal de faturamento comporte o filtro por até no máximo 30 dias:
Para melhor responsividade, foi adicionado um scroll à tabela para que o cliente possa visualizar os demais dados e evite a quebra da página
Além disso, pdf e excel também foram ajustados para corresponderem ao novo formato:
Ticket: 68325 – Ajustar hyperlink na listagem de agendamentos #
Conforme solicitado, foi adicionado o hiperlink para redirecionar ao cadastro do pedido na AR quando a opção “Utilizar dados do pedido da AC” estiver habilitada:
Ticket: 71422 – Integração Asaas em nível de conta #
Adicionamos a integração por cada conta para Asaas:
Caso não informado, ai sim, pegará do cadastro da Empresa.
Ticket: 70700 – Criar marcação no cadastro de produto para que o mesmo não seja exibido no relatório de resumo mensal de faturamento #
Foi criado um campo no cadastro do produto, que ao marcar irá ocultar esse produto dos relatórios de resumo mensal de faturamento.
Ticket: 53060 – Sugestão para exibição de ação para revogar manualmente em pedidos aprovados manualmente #
Agora, caso o pedido seja aprovado manualmente, aparecerá a opção de revogar o pedido
Ticket: 70824 – Cadastro de cliente #
Foi realizado um ajuste para que caso o usuário logado não seja administrador, nem gestor, nem tenha permissão de ver todas as unidades, ele consiga selecionar apenas seu próprio ponto de Atendimento
Caso o usuário seja um gestor, ficará disponível para selecionar as unidades que ele gere além da sua própria vinculada ao seu usuário:
Ticket: 70513 – Validação de agendamento #
Foi realizado um ajuste para que caso no sistema tenha apenas um horário de funcionamento com a marcação de “visualização geral de vendedores” e o ponto de atendimento deste horário seja o mesmo que do usuário logado , o sistema set este ponto de atendimento nos filtros e traga na listagem apenas os resultados deste.
Ticket: 70681 – inclusão de campo de Forma de pagamento e conta no cadastro da unidade para solicitar créditos #
Foram criados os campos de forma de pagamento e conta padrão para solicitação de crédito no cadastro de unidade, na aba Financeiro
Ao gerar uma solicitação de crédito, caso a unidade esteja com esses campos configurados o sistema irá criar o contas a receber com essas informações, do contrário irá usar as configurações dos parâmetros do sistema.
Ticket: 71575 – Envio de mensagens de certificado expirando sendo disparadas aos finais de semana #
Realizado a tratativa nessa rotina para que as mensagens não sejam enviadas somente nos dias úteis.
Ticket: 71120 – Ajuste para que os modelos de mensagem do financeiro sejam disparadas ao contato da unidade marcado como “Acerto financeiro” #
Conforme alinhado, foi ajustado para que mensagens de WHATSAPP e E-MAILS que sejam de FINANCEIRO sigam a seguinte regra ao enviar para PONTOS DE ATENDIMENTO:
1) Se o PONTO DE ATENDIMENTO tiver um contato (Outros contatos) com o campo “Acerto financeiro” marcado, será enviado e-mail/whatsapp apenas para ele (se tiver e-mail e telefone), ignorando os campos “Telefone principal” e “E-mail principal”.
2) Se NÃO tiver qualquer contato (Outros contatos) com o campo “Acerto financeiro” marcado, será enviado e-mail/whatsapp apenas para “Telefone principal” e “E-mail principal”.
3) Se tiver contato (Outros contatos) mas nenhum possui a marcação de “Acerto financeiro”, será enviado, ainda, para os campos “Telefone principal” e “E-mail principal”.
Observação: Orientar o cliente quanto a isso pois, anteriormente, mensagens de financeiro eram enviadas TANTO para o contato principal QUANTO para os demais contatos cadastrados. Agora somente enviará ou para contato principal ou contato financeiro.
Ticket: 71536 – Validação de o porquê o certificado consta como renovado #
Foi identificado que o pedido que fez com que o pedido 2027 fosse considerado como renovado foi o seguinte:
O pedido 2027 foi aprovado 02/04/2024 15:10 já o seguinte foi aprovado manualmente 08/05/2024 11:27 . Porém, foi identificada uma falha no processo de atualização da renovação do pedido anterior, onde quando um produto como o “Delivery” está cadastrado como serviço e sem configuração de prazo de validade, o sistema pegava o pedido anterior (2027) para marca-lo como renovado.
Tendo isso em mente, foi realizada uma tratativa para que casos semelhantes não ocorram novamente.
Ticket: 71678 – Tratativa na duplicidade de disparo de mensagem #
Analisando o histórico do exemplo relatado, podemos observar que no mesmo minuto foi realizada a ação de “forçar consulta” e o JOB de conciliação também foi executado. Para que cenários semelhantes não ocorram novamente, foi realizada uma tratativa interna a fim de que seja validado se a data da baixa já não está preenchida antes de atualiza-la:
Dessa forma a mensagem não será mais disparada em duplicidade.
Ticket: 71664 – Falha no disparo da rotina “Lembrete de videoconferência com o agendamento não realizado”. #
Foi realizado um ajuste na rotina de disparo de mensagens “Lembrete de videoconferência com o agendamento não realizado“ para que quando no sistema em que o JOB está sendo executado contenha algum ponto atendimento com a marcação “Utilizar o identificador do pedido na API de videoconferência“ ativa, seja feita a consulta do pagamento do pedido em questão na AR.
Caso no sistema em questão não contenha nenhum ponto atendimento com essa marcação segue o fluxo normalmente.
Vale salientar que para a busca dos registros que serão feitos os disparos da mensagem, o sistema considerada os seguintes pontos sobre a videoconferencia:
1-) Não tenha agendamento cadastrado.
2-) A situação da videoconferencia não esteja como “Concluído”.
3-) O pedido esteja aguardando aprovação.
4-) A data da baixa do documento seja superior ou igual os últimos 30 dias.
E no caso do ajuste realizado também considera-se:
5-) Se no pontoAtendimento do pedido está marcado : “Utilizar o identificador do pedido na API de videoconferência“.
Ticket: 71593 – Somatório na tela de nota fiscal de produto #
Foi realizado um ajuste para que os totalizadores sejam exibidos corretamente:
Ticket: 70450 – Feriados com as datas faltando 1 dia #
Ajustado para que o JOB importe os feriados com a data correta. E também realizado uma atualização no banco de dados para ajustar as datas que foram criadas de forma incorreta.
