Ticket: 77202 – Ajuste no SPLIT para vendedores #
Ajustamos a hierarquia que o sistema seguia para calcular o valor de split de cada entidade.
Agora com o mesmo exemplo do pedido o sistema faz, primeiro contabilidade, depois vendedor, e por último o ponto de atendimento.
Sendo assim, de R$220,00:
Contabilidade = R$100,00 (220,00 – 120 da tabela de aquisição)
Vendedor = R$24,00 (20% dos 120,00 que sobrou)
Unidade = R$ 38,80 ((96,00 que sobrou – 55,00 da tabela de aquisição) – 2,20 de taxa do boleto Safe2pay)
E o restante da AR = R$ 57,20

Ticket: 76523 – Inclusão e Validação do Campo “Motivo do Estorno” #
Na tela de solicitação de reembolso foi adicionado o campo “motivo de estorno” com as opções solicitadas.

Caso o “outros” seja selecionado aparecerá o novo campo “observações estorno”

Essas informações ficaram salvas no contas a pagar que se criará pela solicitação de estorno.

O campo “observações estorno” só exibirá se o “motivo estorno” for “OUTROS”
O campo “Motivo estorno” só será exibido se a categoria for a mesma que no campo “Categoria padrão para devolução” dos parâmetros do sistema

Também foi adicionado o filtro na listagem de contas a pagar o filtro “motivo estorno” com as mesmas opções.

E também adicionado as colunas “motivo do estorno”, “observação estorno” no excel.

Ticket: 76583 – Validação de Disparos Duplicados nas Mensagens de Renovação de Certificados #
Foi feita a alteração para quando a flag “envio somente em dias úteis” estiver desmarcada, o sistema enviará apenas mensagem de cliente que o certificado expirará exatamente no dia preenchido no campo adicional.

Sendo assim, um certificado que irá expirar dia 25, mensagem será enviada apenas no dia 20, sendo assim desconsiderando nos dias anteriores(…,17,18,19) a possibilidade de ser feriado/fim de semana dia 20(o dia que completará 5 dias para o certificado expirar conforme o campo adicional preenchido na configuração da mensagem) e não adiantando a mensagem para os dias anteriores.
Ticket: 76559 – Incluir Coluna “Criador do Pedido” no Relatório de Pedidos de Venda #
Foi criada a coluna no excel “Criador do pedido” baseando pelo usuário responsável pelo histórico com a ação “CRIADO”, por tanto há casos que esse responsável estará vazio

GFSIS – Realizar ajuste de renovações retroativas para correção de situações de renovações equivocados. #
Script de atualização em todas as bases de dados.
Syngular – Criar campos para traqueamento do GTM no novo checkout #
Criado os campos título da página e o código do GTM para trakeamento do chekout nos eventos de compra de certificado.

Ticket: 75951 – Inclusão de Filtro por Data de Aceite do Termo de Acerto de Pontuação no Contas a Pagar #
Foi criado o filtro “Período de aceite do termo de acerto de pontuação” na tela de Contas a pagar, assim filtrando pela Data de aceite do termo

Ticket: 75990 – Análise e correção de erro ao tentar salvar o cadastro de conta (Erro Null) #
Foi corrigido o erro de não ser possivel salvar conta por erro de nullPointer
Ticket: 76111 – Criação de filtro com checkbox, uma nova flag na forma de pagamento e filtro por data de protocolo #
Conforme solicitado, foi criado o filtro de data de geração do protocolo nas telas de pedido venda , pedidos por unidade , pedidos por indicação parceiro:



Além disso, na tela de criação de pedido venda foi adicionado um novo campo, condicionado ao parâmetro “Obrigar informar NSU no pedido venda“, uma vez que ao criar o pedido for selecionada uma forma de pagamento que contenha essa marcação o campo “Dados cv“ será exibido:

Quando habilitado o sistema obriga o usuário em questão à preenche-lo:

Ao salvar o pedido, a informação do campo será salva diretamente no documento do contas a receber:

OBS: O campo adicionado na tela de pedido venda, não salva o dado em si no banco , este campo é um espelho do que está armazenado no contas a receber. Portanto, um pedido já criado, não será possível de editar os dados do cv diretamente na tela de criação do pedido, caso necessário deverá ser editado pelo ícone na listagem de pedido venda ou do contas a receber:


Ticket: 76858 – Voucher para produto PJ está sendo possivel utilizar em pedidos de outro produto #
Foi feita a correção da validação de voucher com restrição de produtos.


Ticket: 76897 – Criação da aba solicitação SOLUTI no pedido incorreto(Erro ocorreu devido ao id externo ser igual ao de um pedido da DIGIYOU) #
Validando, o cadastro da unidade “Digiyou” no sistema da nahoradigital que ta ocasionando o erro, ela ta cadastrada como tipo ITS, precisa alterar para AR e marcar o checkbox “Permite importar o pedido da AR na AC”
Cadastro da unidade da AR na AC integração:



Ticket: 77102 – Relatório de pedidos por indicação/parceiro trazendo o gestor comercial errado #
Foi feita a alteração da nomenclatura do campo para “Gestor comercial da contabilidade” e feita a correção para sempre apresentar o valor do gestor comercial da contabilidade.
Ticket: 76942 – Protocolos sendo gerados em duplicidade #
Após verificações foi possível observar que a geração de protocolo duplicado viria de recarregamentos de agendamentos lyve, enviando a requisição de geração mais de uma vez para o sistema, foi possível perceber isso pela geração de múltiplos agendamentos pela mesma triagem

Sendo assim, tiramos a opção de apertar F5 na tela de atendimento lyve, para evitar o envio da solicitação mais de uma vez para o sistema além de acrescentar a lógica para evitar mais de uma geração de protocolo.
Ticket: 77070 – Incluir informações do SPLIT no Excel do contas a receber #
Ajustado para exportar os campos de split no excel completos, com Contabilidade, Vendedor, Unidade. AC e AR.
No excel:

E No excel do centro de custo

Foi ajustado também para esses campos aparecerem caso seja split Asaas, o que antes não aparecem.
Ticket: 77179 – Ajuste na data de conciliação do contas a pagar de acerto de saldo – Tratado no ticket 76232 #
Foi feita a correção para operações de débito levarem em consideração a data de conciliação do documento de referência para fazer a data de aprovação da operação(caso esteja configurado na forma de pagamento).



Ticket: 77212 – Ajuste na notificação de certificado emitido via webhook #
Foi feita implementação da notificação de certificado emitido em toda emissão de certificado feita no sistema caso o sistema tenha a url de envio de notificação do webhook preenchida.

Importante lembrar que a dataValidadeCertificadoCliente já é enviado na notificação, mas essa informação deve ser preenchida no cadastro do cliente manualmente.
Ticket: 76739 – Duplicação do número do cliente para pedidos criados via site #
Foi feita a correção para evitar a duplicação do número de telefone por pedido via site.

Ticket: 77474 – Ajuste na integração API Pix pagamentos do Sicoob #
Adicionamos um filtro na tela de contas a pagar, chamado “Contém pagamento pix Sicoob em aberto“.

Esse filtro irá exibir todos os pagamentos em lote feitos para o Sicoob.
E caso esse pagamento ainda esteja em aberto (foi aberta a transação, mas não foi efetivada), adicionamos uma forma de efetivar aquele pagamento:

Desta forma, caso as transações fiquem em aberto e o limite de transações chegue, será possível liberar os registros indo até um pagamento em aberto e efetivando o pagamento.
Virá no e-mail de notificação um link para visualizar os documentos com vinculo com o Pagamento Sicoob:

Desta forma ele pode executar o ajuste de todas de uma vez só:

Foi adicionado também o mapeamento de erros ao processar o pagamento em lote via arquivo:

SYNGULAR – Correção no novo checkout para não exibir garantia quando não tiver o produto garantia na tabela de preço #
Foi realizado um ajuste no novo checkout para não exibir a aba de garantia, quando a unidade não tiver o produto garantia em sua tabela de preço
Ticket: 77784 – Tratativa de Erros no Processo de Pagamento em Lote via Arquivo #
Ajuste realizado no ticket 4489 do Jira e 77474 do Movidesk, o problema encontrado foi devido a um erro na organização das colunas do arquivo processado.
Em conversa com o Breno Felipe, foi informado que as contabilidades tem de 4 a 5 formatos próprios para os arquivos de pagamento.
Sendo assim não realizamos mudanças no processo, Mas adicionamos um mapeamento dos erros e retornaremos em tela caso ocorra falhas:
