Ticket: 76936 – Ajuste na visualização do identificador do pedido do próprio sistema quando usa do identificador vermelho da AC. #
Foi realizado um ajuste interno para que seja exibido o identificador / identificadorExterno:
Inclusão da Flag “Exibir Pendência Financeira da Unidade” no Cadastro de Usuário para Vendedor #
Foi realizado um ajuste interno para que o campo “Exibir pendência financeira da unidade“ seja exibido na criação do usuário através da tela de criação de vendedor.
A exibição do campo segue as mesmas condições já existentes na tela de criação de usuário: Usuário administrador e usuários que em seu nível de acesso está habilitado “Exibir opção para visualizar pendências financeiras“
Ticket: 77221 – Flag de permitir importar pedido em outra unidade quando marcado na Primazia não replica no sistema da Savez #
Realizei um ajuste no processo de integração entre AR / AC, na criação de pedidos, para enviar junto o campo Permitir importar pedido em outra unidade
Ticket: 76466 – Análise e Correção no Cálculo de Alíquota na Emissão de Nota Fiscal #
Identificado que o cliente não estava configurado como substituto tributário no envio da nota fiscal, não foi necessário um ajuste de código, apenas orientação ai cliente.
Ticket: 75636 – Ajuste na integração com PIPEFY para não mover os cards, e sim informar uma etiqueta #
Adicionamos agora uma aba “Etiquetas“ no cadastro da integração Pipefy, onde será possível configurar para o sistema enviar as “tags“ ao Card.
Essa configuração contém uma seleção de status do pedido, que no momento foi implementado 3 status para responder as demandas do cliente, sendo eles:
Pagamento do documentoConciliação do documentoLiberação de pedido
E com eles você poderá configurar qual o identificador do campo da etiqueta que você quer alimentar, e qual será o identificador da etiqueta em si que quer utilizar para esse evento:
OBS 1: Necessário realizar uma busca pelos IDS, tanto do campo de “Etiquetas“ quanto dos valores que nele serão informados.
OBS 2: Agente de suporte responsável, favor fornecer a relação de IDs das tags ao cliente solicitante, e apenas a ele, para alimentar as configurações.
Configurando essas novas informações, o sistema fará o disparo dessas informações, sendo a “Liberação do pedido“, enviada no cadastro do pedido, junto da criação do CARD.
OBS 2: Para identificar se um pedido é de liberação, foi criado um campo no cadastro da forma de pagamento, por favor configurar em seu sistema para as formas de pagamento que usa com o intuito de liberação.
Ticket: 75480 – Ajuste na troca de pedido para carregar os anexos do pedido de origem #
Foi feita a correção para carregar os anexos na troca de um pedido.
O protocolo foi gerar automaticamente na troca e o envio do CEI aconteceu.
A triagem também foi feita corretamente.
Ticket: 74440 – Ajuste nos modelos de mensagem de agendamento não realizado e pedido não pago, protocolo no log de mensagens e ajuste no disparo indevido do lembrete de agendamento #
Teste realizado para disparos em dias alternados.
Testado protocolo no log
Ticket: 77607 – Criação de novo Webhook para Notificações Filtradas por Parceiro Específico #
Foi adicionado o campo url webhook no cadastro da contabilidade, quando preenchido é enviado a notificação para essa url.
Ticket: 75930 – Notificação via WhatsApp para Solicitação de Venda de Produtos Consignados e Solicitação de Venda de Produtos #
Foi adicionado um parâmetro “Telefones para envio de notificação de solicitação de mídias“ em Parâmetros do sistema -> Outros → Estoque.
Sendo assim quando é feito uma nova solicitação de mídia é notificado a estes telefones cadastrados.
E no histórico da solicitação, fica registrado o envio das mensagens.
Adequação da Integração GFSIS ↔ Pipefy à Nova Autenticação via Contas de Serviço. #
Ajustamos o processo de autenticação das requisições da API da Pipefy devido ao fato do formato antigo que será descontinuado futuramente.
Para realizar a configuração do novo formato, deve seguir um processo de criação de uma “Conta de serviço“ dentro da plataforma da Pipefy, para coletar os dados de integração.
1º Em um acesso de “Super Administrador” na Pipefy, vá até “Painel administrativo“ e depois em
”Contas de serviço”
2º Crie uma conta para o GFSIS, se possível com a função de Super Admin para acesso a todas as opções de integração.
3º Após configurar, será possível coletar os dados de integração, o Client ID e o Client Secret para informar no sistema do GFSIS.
3.1 – Importante – Após cadastrar, faça o vinculo do quadro que está integrando, através da opção Pipes, para garantir que a integração esteja apta a manipular os Cards desse quadro.
3º Agora já dentro da plataforma do GFSIS, você deve ir até Sistema – Configurações Pipefy, informe os campos coletados:
E pronto, com isso sua integração Pipefy seguirá funcionando corretamente e agora, mais segura.
Ticket: 77371 – Ajuste na rotina Lembrete de videoconferência com o agendamento não realizado #
Foi feita a correção para manter o mesmo horário programado para todos os bancos.
Ticket: 77314 – Erro na validação de “Quantidade de atendimento simultâneo para videoconferência” em agendamento pelo site. #
Foi feita a correção para evitar erros de agendamentos no mesmo horário
Podemos perceber que o horário de agendamento 14:40 para o dia 17/07/2025 não aparece pois já tem um agendamento marcado para este horário.
Ticket: 77590 – Relatório de comissões com duplicidade #
Foi feita a correção dos left outer join que causava duplicação ao gerar excel.
Anteriormente a correção:
Ticket: 77663 – Correção da Exibição do Botão de Ação na Nota Fiscal de Serviço a partir do parâmetro “Permitir vincular várias notas fiscais a um pedido” desabilitado #
Quando houver permissão:
Quando não houver permissão:
Ticket: 75075 – Ajustar método de gerar protocolo bry emissão online para atualizar protocolo na AC quando “Replicar notificação de atualização do pedido para a AC” está marcado #
Ticket: 76789 – Incluir informações no Excel de agendamentos #
Foram criadas, 2 novas colunas no excel de agendamento: “Reagendamento” e “Data de criação”
Ticket: 61660 – Implementação de Boleto e Boleto PIX pela nova API Sicredi Cobrança #
Foi realizada a integração Sicredi V2 para boletos conforme solicitado.
Serviços implementados:
1-) Criação de boleto simples e boleto PIX. À Depender da configuração do tipo de pagamento da forma de pagamento:
2-) Processo de alteração de data de vencimento do boleto, seguindo o mesmo padrão já estabelecido no sistema para que quando um documento estiver vencido, através do hiperlink (link clicavel azul) na data de vencimento seja possível alterar a data de vencimento do boleto.
3-) Processo de consulta via forçar através da listagem de contas a receber e via JOB diário, assim como já acontece para as demais integrações.
4-) Possibilidade de criar, ativar e inativar webHook para recebimento de notificações de pagamento.
Atualmente a integração com o Sicredi não permite a exclusão do id do contrato do webHook, logo uma vez que este está criado, é possível apenas inativa-lo para que não sejam enviadas mais notificações ou ativa-lo novamente caso necessário.
- Os novos campos da integração V2 aparecerão no cadastro da conta deste que na conta seja informado o ambiente sicredi V2 ou no cadastro da empresa.
Configurações:
Para que seja realizada a integração com a nova versão de boletos sicredi, basta seguir a cartilha enviada por eles. Porém segue um passo a passo simplificado.
1-) No Sicredi Developers (https://developer.sicredi.com.br/api-portal/pt-br/myapps/1) é necessário criar uma nova APP (minha conta → minhas APPS). Seguir cadastro conforme cartilha, importante ressaltar que deve selecionar o ambiente de produção e não de sandbox.
2-) Logo após serão gerados o clienteId e Secret, estes deve sem usados para criar a x-api-key (token). Para isto basta ir em suporte → “abra um chamado” e criar um chamado solicitando a criação do access token. (Seguir conforme explicado na cartilha).
3-) Dentro de alguns minutos o Sicredi responderá o chamado, sendo possível visualizar a x-api-key na listagem de minhas apps, clicando em “detalhes”.
4-) Essa x-api-key deverá ser informada no cadastro da conta, além dela se faz necessário informar o username e a password. O username é formado através do código beneficiário + agência. Exemplo:
Agencia: 0228
Cod beneficiário: 33333
Username: 333330228
A password deverá ser gerada no internet banking, conforme informado na cartilha.
OBS: Os campos de Access Token e refresh Token não devem ser preenchidos, uma vez que são de uso interno e gerados automaticamente a cada requisição
Ticket: 76119 – Mensagem disparando com bloqueio no cadastro do cliente #
Já foi corrigido no dia que foi chamado o ajuda-suporte.
Ticket: 75381 – Permitir ativação da flag de “Emissão Synples” na edição de pedidos que não foi gerado o protocolo #
Foi feita a correção para permitir a alteração de pedido para “Emissão Synples” mesmo o pedido já estando criado se não houver protocolo ainda.
Quando gerado o protocolo a opção é desabilitada.
Ticket: 76367 – Validar e ajustar Job de Verificação de operações diário #
Foi feita a correção para conciliação das operações conforme solicitado, seja buscado todos pedido venda criado ou situação alterada no dia que o job está rodando, incluindo casos de pedidos criados ontem e alterados em outros dias.
Também incluído a lógica de cancelamento de operações no job, levando em considerações as regras de negócios estabelecidas.
Ticket: 76321 – Correção da Consulta de Pedidos Renovados no Controle de Renovação (Exportação CSV) #
Foi corrigido o erro informado criando uma validação para caso o pedido seja aprovado
Ticket: 76371 – Integração com API VALID #
Realizada a integração com a nova API da Valid, a VCert. Com ela, agora o sistema conta com os seguintes campos de configuração:
Em Configurações de sistema → Empresa → Aba Valid
Essas informações devem ser solicitadas a Valid e ao retornadas devem ser alimentadas aqui, sendo a primeira solicitação a API Key e o Customer Code
E posteriormente solicitar a configuração da loja, que terá o Código da loja.
Depois de configurar essas informações, é interessante também ativar nos Parâmetros do sistema a rotina que consulta o status do ticket Valid.
Com isso agora o sistema irá parar de usar o processo de “Ticket Valid” da aba Faturamento – Cadastro – Ticket Valid, e passará a ter uma conexão direta com a Valid, gerando o pedido de ticket e também consultando sua situação, tanto de maneira manual, quanto recebendo retornos da própria Valid.
Esses retornos da Valid automáticos serão apenas se solicitar a configuração de webhook com a URL: https://suaempresa.gfsis.com.br/gestaofacil/rest/NotificacaoTicketValid
Por fim, fica abaixo alguns fluxos que foram implementados:
* Replicação do status ticket Valid na AC
* Criação de analise ao receber o retorno Valid
* Criação de recusa ao receber o retorno Valid
Ticket: 78070 – Otimização do Filtro por Data de Geração do Protocolo na Tela “Meus Pedidos” #
Foi adicionado os campos “usuarioCriador”, “dataGeracaoProtocolo” no pedido venda, sendo assim otimizando a geração do excel e o no filtro dos pedidos venda.
Ticket: 78046 – Ajuste de validação em alterações de cadastro de conta para evitar erros em pedidos. #
Foi feita a correção permitindo um usuário sem permissão a abas integrações salvar o cadastro da conta sem a perda dos dados do certificado, sendo assim, mantendo o funcionamento normal do sistema.
Ticket: 78023 – Correção de duplicidade visual no Relatório de Conferência Split #
Houve a correção do left outer join que causava essa duplicidade.
Anteriormente:
Após a correção
importante ressaltar que o pedido em questão possui 2 contas a receber, sendo assim mantemos os 2 registros, um para cada documento
Ticket: 77983 – Correção na substituição de TAG’s no disparo do e-mail “Compra no site (Validação videoconferência)” #
Foi feita a correção da substituição das informações “telefone”, ”celular” no envio de algumas mensagens, que poderiam causar null pointer.
Ticket: 77886 – Erro ao exportar relatório Excel no Safari (Contas a Receber) #
Foi feita a correção do excel do contas a receber no safari.
Papel de administrador sendo exibido na criação de vendedor #
Foi corrigido para não exibir o nível de acesso de administrador ao criar um usuário pela tela de vendedores
Criação do registro da videoconferência no checkout #
Conforme solicitação no ticket, foram feitos os seguintes ajustes:
1) Criados as rotinas de envio de mensagem para cada etapa do checkout. Tal como funciona no envio de e-mail, se a rotina for devidamente configurada e preenchida com as TAG’s, é disparado um modelo de mensagem para o telefone do cliente via WhatsApp.
2) Na etapa de validação, uma vez que se tenha anexado o documento, além de gerar protocolo e enviar a documentação ao Sync, é criado também um registro de videoconferência amarrado ao pedido.
Ticket: 78367 – Ajuste na notificação de cancelamento de pedidos via webservice para casos de haver multi AC e não utilizar de CRM próprio #
No contexto relatado, o identificador externo era sempre gerado (mesmo que não estivesse marcado “Utiliza CRM próprio“)pois, ao processar o retorno do envio do pedido para a “AC”, a variável nivelAC era preenchida, visto que o sistema é multiAc.
Foi realizada uma correção na lógica de obtenção do identificador do pedido no cancelamento. Agora, quando a AR não utiliza CRM próprio (marcação em Parâmetros do Sistema → aba Webservice):
- Se NÃO houver identificador externo: será utilizado o identificador do próprio pedido para o cancelamento na AC.
- Se houver identificador externo: será utilizado o identificador externo do pedido para o cancelamento na AC.
Anteriormente, o cenário em que a AR não possuía CRM próprio mas tinha identificador externo não era considerado, fazendo sempre o sistema utilizar o identificador do próprio pedido. Isso ocasionava o cancelamento indevido de outros pedidos na AC que continham o mesmo identificador que na AR.
Com o ajuste, cada situação é corretamente tratada, prevenindo cancelamentos indevidos.
