Ticket: 67419 – Emissão Synples #
Conforme especificação, criado o fluxo para emissão de pedidos por Emissão Synples. Funcionando da seguinte forma:
Em Sistema → Configurações do Sistema → Parâmetros do sistema, na aba “Pedido de Venda”, foram criados os seguintes campos: “Habilitar emissão Synples“ e “Produto emissão Synples“. Ambos devem ser preenchidos devidamente para que o processo ocorra devidamente.
Além dos campos nos parâmetros do sistema, a nível de ponto de atendimento, foi criado o campo para validar se os respectivos vendedores da unidade podem trabalhar com esse modelo de emissão: “Permite emissão Synples (Syngular)“
Uma vez configurados esses campos, os vendedores atrelados à essas unidades podem realizar emissões pelo modelo Emissão Synples, desde que cumpram as regras de negócios discriminadas pelo solicitante: cliente PJ e emissão online
Foram adicionadas diversas validações à tela para que, caso o pedido esteja marcado como “Emissão Synples” mas esteja em desacordo com as regras de negócios especificadas (pedido PJ e emissão online), o campo seja DESMARCADO. Essas regras garantem que pedidos de emissão Synples respeitem às regras.
Feito o pedido corretamente e clicado em “Salvar”, o pedido com o certificado desejado é criado e uma THREAD para criação do pedido Synples é executada. Dentro de alguns instantes o pedido com emissão Synples também é gerado.
O pedido que ORIGINOU a solicitação de emissão synples ganhará um ícone, utilizado para direcionar para o pedido emissão synples
O pedido emissão Synples que foi CRIADO, terá em seu histórico o pedido que o originou
Fluxograma de geração de protocolos:
1º Caso: Se nas configurações da EMPRESA, na aba “Syngular” esteja marcado para “Gerar protocolo de emissão/renovação online automaticamente“, tanto o pedido do certificado quanto o pedido com o produto Synples serão criados, automaticamente, já com o protocolo, restando ao usuário apenas aguardar a realização do processo.
2º Caso: Se NÃO estiver marcado “Gerar protocolo de emissão/renovação online automaticamente“, a criação de protocolo se dará das demais formas configuradas, inclusive manual. Detalhe: deve-se gerar, primeiramente, o protocolo do pedido ORIGINAL e depois o protocolo do pedido com produto SYNPLES. Caso o fluxo seja feito de forma contrária, será avisado em tela:
Se gerar, primeiramente, o protocolo do pedido original, é executada uma THREAD para criação do protocolo do pedido Synples.
Ticket: 72378 – Campo na unidade para e-mail padrão na emissão de NF #
Criado o campo “E-mail para envio de NF“ a nível de Unidade (Ponto de Atendimento).
Uma vez que esse campo for preenchido, caso a NFe/NFSe seja originada de pedido venda, quem receberá o e-mail é o próprio PONTO ATENDIMENTO, não o cliente final.
Detalhe: O modelo de negócios de Nota fiscal por valor de aquisição permanece inalterado, sendo ele → Pedido venda com o campo “Considerar no valor da NF” atribuído como “Aquisição” e no cadastro de EMPRESA o campo “E-mail para envio das NF's geradas no valor de aquisição” estiver preenchido.
Ticket: 66836 – Ajustar para que o Bird Id Trial gerado pelos parâmetros do sistema não seja considerado no controle de renovações #
Foi realizado um ajuste interno para que caso o produto do pedido aprovado seja um BIRD ID TRIAL, o sistema desconsidere-o na busca pelos pedidos que serão marcados como “renovado” ou “renovação”.
Ticket: 46207 – Sugestão de Melhoria – Gravar a resposta da consulta PSBIO no LOG do Pedido. #
Adicionado no histórico do pedido venda o resultado da consulta e o cpf consultado no PSBIO
Ticket: 71648 – Ajuste na integração com o ClienteChat para que possa ser informado a API Key de cada conta no cadastro da mensagem #
Conforme solicitação, foi criado o campo “Token ClienteChat” a nível de Configuração Mensagem WhatsApp. Dessa forma, será respeitada a hierarquia de configuração mensagem e empresa: se tiver token na configuração, usa o token da configuração senão, usa o token da empresa.
Observação: Ainda é necessário informar um token na empresa para que a integração funcione.
Ticket: 71096 – Ajustar para considerar unidade do tipo “sede” na criação do processo administrativo e retornar os filtros de CPF e nome no AGR #
Ao escolher unidade do tipo SEDE os campos são exibidos corretamente. Antes, somente eram exibidos se unidade fosse do tipo AR.
Ticket: 70325 – Ajuste para quando um pedido que usou de voucher trocado por pontuação for cancelado, cancele o voucher e retorne a pontuação ao parceiro automaticamente #
Conforme solicitado, foi implementado para que quando um pedido que contenha um voucher gerado a partir da troca de pontuação seja cancelado, o sistema inative o voucher e delete a pontuação do parceiro.
OBS: Pontuação atualmente não é possível de ser cancelada, apenas deletada.
Ticket: 71893 – Ajuste na visualização no resumo de certificados a vencer #
Conforme alinhado presencialmente com o Breno, a diferença entre as telas “Certificados a Vencer” e “Controle de Renovações” ocorre devido à forma como cada uma trata a contabilidade vinculada.
Na tela Certificados a Vencer, o sistema considera os pedidos que vencem no período filtrado e verifica se a contabilidade está vinculada ao pedido ou ao cadastro do cliente.
Já no relatório de Controle de Renovações, são exibidos apenas os pedidos em que a contabilidade está vinculada diretamente ao pedido.
No exemplo analisado, a diferença aconteceu porque o pedido da cliente “ERIKA MARINA DA SILVA“ não possui contabilidade vinculada, mas no cadastro da cliente a contabilidade está preenchida. Por isso, o pedido aparece em “Certificados a Vencer”, mas não no “Controle de Renovações”.
Dessa forma, conforme combinado, não será necessário nenhum ajuste técnico, apenas uma orientação ao cliente sobre o funcionamento de cada relatório.
Ticket: 72001 – Process ImportarBaseDados – Tabela de Unidade – Erro de propriedade #
Corrigido a consulta afim de evitar o erro informado.
