Ticket: 68020 – Aumento no Número de Anexos – Contas a Pagar/Receber #
Foi adicionado os novos campos anexo 3 e anexo 4, eles funcionam da mesma forma dos anexos já existentes.
Ticket: 64449 – Reformulação de protocolo Syngular e criação Campo CEI no Pedido de Venda #
O processo de geração do protocolo Syngular foi atualizado internamente no código para que seja possível o envio de maiores informações do GFSIS ao Sync.
Agora no cadastro do cliente o campo CEI, também estará visível para integração Syngular, essa informação também é atualizada na integração entre AR e AC para contemplar a geração de protocolos para AR Única
Abaixo evidências do envio do campo CEI, conforme solicitado pelo cliente, diretamente no Sync
Ticket: 74608 – Falha na Conciliação por Erro de Notificação Webhook #
Foi ajustado o campo data de vencimento no retorno das notificações via Webhook da Pagar.me
Ticket: 73727 – Campos de representante legal no novo e-commerce #
Ajustado para exibir os campos do representante legal, caso tenha integração com a Serpro
Ticket: 72588 – Tratativa na rotina “Lembrete de videoconferência com o agendamento não realizado” #
Foi feito uma nova tratativa no job “Lembrete de videoconferência com o agendamento não realizado” alterando o tópico 4)A data da baixa do documento seja superior ou igual os últimos 30 dias, que agora além desse caso, abrange casos também que a forma de pagamento foi voucher ou não gerou contas a receber, sendo assim haverá envio de mensagens também nestes casos.
Ticket: 74482 – Ajuste na configuração de envio de notificações #
Já foi feito a correção em outro ticket(GFSIS – 4317)
Alteração do cliente para não receber notificações às 09:28.
Histórico de aprovação de um pedido, após as 09:28 do mesmo dia, do mesmo cliente sem tentativa de envio de email.
Log de envio de emails, último email enviado ao mesmo cliente as 09:25, anteriormente a alteração no cadastro do cliente.
Ticket: 73347 – Ajuste na validação da marcação “Permitir videoconferência sem pagamento” para geração de protocolo #
Conforme solicitado, a lógica da flag “Permitir videoconferência sem pagamento” foi ajustada.
Agora, quando essa opção estiver marcada no cadastro do indicador, o sistema permitirá puxar o protocolo mesmo que o pedido não tenha forma de pagamento e a unidade esteja configurada para bloquear.
Obs: Demais casos como pedido sem forma de pagamento ou voucher seguem conforme ajustado anteriormente, não restringindo o indicador, quando a opção estiver marcada em seu cadastro.
Ticket: 74561 – Alterar nome do campo videoconferência na tela de Controle de Reanálise e Perícias #
Foi feita a alteração do campo “videoconferência” para “Tipo de atendimento”, com as opções: Emissão online, videoconferência e presencial.
Essa alteração foi feita na entrada.
Feita na listagem.
E também no excel.
Também foi montado o script fazendo as atualizações como pedido no ticket.
Caso estivesse marcado “videoconferência” como sim, o campo Tipo de atendimento foi para “Videoconferência”.
Caso estivesse marcado “videoconferência” como não, o campo Tipo de atendimento foi para “Presencial”.
Caso “videoconferência” estivesse como nulo e a reanalise foi após 01/01/2025, o campo Tipo de atendimento foi para “Emissão online”.
Ticket: 70812 – Formas de pagamento no cadastro do parceiro inseridas internamente #
Foi realizado um ajuste interno para garantir a consistência entre as formas de pagamento cadastradas na unidade e aquelas vinculadas às contabilidades associadas.
A partir de agora, sempre que uma forma de pagamento for removida da unidade, o sistema:
- Removerá automaticamente os vínculos das formas de pagamento nas contabilidades relacionadas, garantindo que elas não estejam mais disponíveis na geração de pedidos.
- Essa remoção será feita via thread, logo pode ser que demore alguns minutos para remover, dependendo da quantidade.
- Um registro será salvo no histórico de cada contabilidade afetada, indicando quais formas de pagamento foram removidas. Caso ocorra algum erro durante a remoção, será registrado no histórico da unidade.
Com isso, o comportamento esperado será atendido: ao remover formas de pagamento na unidade, elas deixarão de aparecer e de serem válidas também nas contabilidades, tanto visualmente quanto no banco de dados.
Ticket: 74528 – Erro na tag [linkEmissaoProtocolo] nas rotinas de mensagem Aprovar pedido PJ, Aprovar pedido PF #
Para envio correto da mensagem com link para emissão do protocolo, o campo “Url emissão Syngular” em Parâmetros do Sistema → Pedido de Venda, deve estar preenchido com a url correta, e no caso ela não se encontrava preenchida.
Ticket: 74557 – Incluir filtro de ativo/inativo nas telas de acerto de pontuação e apurar comissão #
Foi criado o filtro de Contabilidade / Parceiro ativo nas rotinas de acerto de pontuação e acerto de comissão
Ticket: 74545 – Incluir no relatório de resumo de renovações um totalizador #
Foi adicionado ao final da tabela um totalizador da soma de todos as linhas a cima, este totalizador foi adicionado para todos os tipos de relatório e também no excel e excel mensal
Ticket: 70524 – Erro Processos Administrativos #
Erro já corrigido no ticket GFSIS-4294: SYNGULAR – Ajustar a criação dos processos administrativos ao usar um motivo que não possua marcação de conferênciaConcluído.
Sem motivo os campos não aparecem.
Quando o motivo é preenchido com “Conferência de equipamentos dos AGRs”, os campos aparecem corretamente.
Ticket: 74576 – Ajustar modelo de e-mail “E-mail com link para videoconferência (Enviado após gerar protocolo SingularID)” para ser enviado o link do Lyve #
O erro foi corrigido em outra demanda, ticket GFSIS-4311: EFETIVA – Mensagem com rotina “Envio do link videoconferência/Lyve ao gerar protocolo” não disparaConcluído, atualmente o modelo de email já é enviado de forma correta.
Link acessado pelo email com “Lyve” na url.
Ticket: 74255 – Escolher AC no momento da criação do pedido por API #
Conforme solicitado foram adicionados os dois novos campos no endpoint de criação de pedido:
Segue relação do enum das Ac’s e Tipo emissão Serpro:
(0, “Soluti”)
(1, “Serasa”)
(2, “Serpro”)
(3, “Certisign”)
(4, “Safeweb”)
(5, “Valid”)
(6, “Syngular”)
(7, “AC Digital”)
(8, “Multi AC”)
(9, “Certipe”)
(10, “AC CCN”)
(11, “Consulti”)
(12, “Mult”)
(0, “SERPRO AC”) (1, “SERPRO RFB”) (2, “Própria AR/AC”)
Caso o cliente não informe os devidos campos o sistema seguirá da seguinte forma:
1-) Se o campo “ac” não for informado, o sistema irá verificar primeiro se aba site da unidade o campo “AC padrão para pedidos realizados no site“ está preenchido, caso não esteja irá verificar ainda no cadastro da unidade na aba integração o campo “AC padrão para os pedidos da unidade“ e ainda assim se não encontrar, utilizará da ac padrão nos parâmetros do sistema.
2-) Caso o campo “tipoEmissaoSerpro“ não esteja preenchido o sistema irá verificar se na unidade , mais precisamente na aba site, o campo “Tipo de emissão SERPRO padrão para pedidos realizados no site“ está devidamente preenchido. Caso não esteja ficaria vazio.
{
"pedido": {
"id": 2428,
"data": "2025-05-14",
"pontoAtendimento": 0,
"pago": false,
"tipoValidacao": 0,
"ac": 2,
"tipoEmissaoSerpro": 0
},
"cliente": {
"contato": {
"nome": "guilherme gfsis",
"cpf": "",
"email": "teste@teste.com",
"telefone": "",
"dataNascimento": "2001-09-18"
},
"nome": "testion",
"email": "teste@teste.com",
"dataNascimento": "2001-09-18",
"logradouro": "rua dr teixeira soares",
"numero": "75",
"bairro": "centro",
"uf": "MG",
"municipio": "FORMIGA",
"cep": "",
"cnpj": "",
"naoReceberNotificacaoCertificadoExpirando": true,
"naoReceberNotificacaoEmailWhatsapp": false
},
"certificado": {
"id": 1,
"valor": "100"
}
}Ticket: 74526 – Ajustar a flag “Contabilidade apenas videoconferência” quando marcada para fazer pedidos apenas por video. #
Foi criada uma validação para casos que no cadastro da contabilidade o campo “Contabilidade apenas videoconferência” em “Pedido Venda” esteja marcado.
Quando esta contabilidade estiver criando ou editando um pedido venda a opção “validação por videoconferência” não poderá ser editado e estará marcado como “sim”.
Nos demais casos, o funcionamento do sistema se manteve o mesmo.
Ticket: 74734 – Pedido com produto do tipo “Produto” não pode ser editado por conta da ausência do identificador #
Foi adicionado uma nova condição de mesmo que o pedido seja de tipo “Produto” e nos “Parâmetros do Sistema” o campo “Realizar integração de pedidos com apenas mídias” não esteja marcado, o pedido será criado com identificador automático.
Cadastro do produto:
Campo nos Parâmetros do sistema → Módulos
Ticket: 74163 – Ajuste no processo ao remover e colocar outra forma de pagamento, onde o sistema registra no banco como null a forma de pagamento #
Contexto técnico:
Para garantir a visualização correta dos ícones de Boleto/Cartão e PIX durante o cancelamento e os demais cálculos do sistema, o contas a receber sempre busca o documentoOrigem associado ao ser cancelado. Dessa forma, o vínculo entre o documentoOrigem e os campos protocolo_id, pedidovendaformapagamento_id e protocoloformapagamento_id é intencionalmente desfeito (definido como null).
Essa desvinculação é necessária para evitar que ícones incorretos continuem sendo exibidos na interface — por exemplo, caso a forma de pagamento tenha sido trocada de Cartão para Boleto e o Cartão tenha sido cancelado, a presença do vínculo antigo faria com que ambos os ícones fossem exibidos.
Sempre que é alterada a forma de pagamento de um pedido, a antiga é cancelada e a tabela documentoOrigem tem o valor da nova forma de pagamento inserido (baseando no número de contas a receber gerados, caso seja cartão, por exemplo).
No cenário relatado no ticket, o cliente realizou o cancelamento do contas a receber e, posteriormente, alterou a data de baixa (ou seja, voltou para conciliado). A lógica de cancelamento foi corretamente aplicada, o que explica o rompimento do vínculo.
Portanto, o ícone de “pago” não apareceu devido ao fato que o documento estava pago, fora cancelado e depois “pago” novamente. Recomenda-se utilizar o processo de troca para esses casos, com o intuito de não burlar/invalidar quaisquer lógicas do sistema.
