***ATENÇÃO: Este POST está em desenvolvimento e atualização, com o objetivo de divulgar conhecimentos, regras e dicas sobre esta ferramenta. Portanto, não deve ser compartilhado com clientes. As informações aqui presentes podem ser utilizadas para criar manuais, vídeos e outras apresentações direcionadas aos clientes.***
Orientar e nortear a equipe de consultoria quanto ao conceito, parametrização e implantação do módulo de cobrança integrada ao ERP Mega.
A missão do módulo consiste em espelhar no CRM os títulos inadimplentes dos clientes da carteira (Pós-Venda); e a partir desta integração, executar a régua de cobrança da empresa, incluindo atividades de cobranças manuais e envio de notificações automáticas com base na data de vencimento dos títulos.
Assim como nos demais módulos do CRM, o módulo gira em torno de uma ocorrência no CRM, e tem as suas principais entidades:
Algumas regras são imutáveis no módulo:
a) Toda a regra de cobrança é definida com base na data de vencimento do título.b) Não existe cobrança preventiva, os títulos apenas são integrados após estarem vencidos. c) Ocorrência de contrato será utilizada para cobrança manual do cliente pelo operador. d) Sub chamados de parcelas do contrato, serão utilizados para efetuar as comunicações automáticas aos clientes (Fluxo automático linear sem necessidade de operador). e) O Fluxos da Cobrança sempre dever ser em fluxo linear. f) Para que o sistema abra todas as ocorrências, é necessário que esteja habilitado a Client_vars de novo gerar_todos_tp_parcelas. ***Importante: As Fases de Inadimplência no Mega devem ser configuradas apenas no final das parametrizações conforme veremos a seguir no item 4.***
Como requisitos para clientes que passaram a utilizar a cobrança é necessário solicitar o desenvolvimento rodar o script vira_inadimplencia.php
A implantação do módulo de cobrança tem diversas particularidades e por este motivo, ela não segue o contexto normal de treinamento de cadastros e operacionais assim como acontece nos módulos de pré e pós-venda.
Será entregue pronto para o cliente um processo padrão com base nas boas práticas já identificadas em outras implantações. Neste processo, será entregue pronto:
1. Base de dados integrada e fiel relacionada aos contratos e status de contratos. 2. Todas as solicitações necessárias criadas e integradas a. Solicitação de Cobrança Ativa b. Solicitação de Contrato Inadimplentes c. Solicitação de Parcelas Inadimplentes 3. Campos adicionais integrados. 4. Fluxo de contrato (Cobrança manual) criado. 5. Fluxo de parcelas (Régua automática de cobrança) criado. 6. Gráfico de controle gestão e operacional padrão criados (Dashboard).
São necessários a abertura de alguns chamados em nosso suporte para as configurações de pontos primordiais para o funcionando do módulo.
Inicialmente precisa-se confirmar se o módulo de cobrança está ativo no ambiente do cliente.
Para confirmar se está habilitado, uma das alternativas é acessar:
CRM > Parametrizações > Listas e verificar se é possível visualizar o campo “Dias em atraso”.
Caso não esteja, deve-se abrir um chamado solicitação a ativação do módulo.
Alguns agendadores são necessários para o pleno funcionamento do módulo. Por este motivo, em um único chamado, solicite as seguintes configurações:
Se tiver em dúvida de como criar este chamado, clique aqui para ver um exemplo.
Abra um chamado em nosso suporte solicitando que seja habilitado o extrato financeiro do Mega no ambiente do cliente. O suporte se incumbirá de entrar em contato com o Mega se for necessário.
As ocorrências básicas de integração devem estar criadas e integradas com seu par no Mega.
Como geralmente o módulo de cobrança é o último a ser implantado, geralmente estas ocorrências já foram criadas e integradas no módulo de pós-vendas. Porém é importante confirmar se estão sendo criadas corretamente.
No CRM deve ser criado uma solicitação para cada linha abaixo, com um nome de fácil identificação pelo cliente e correlacionado com as seguintes ocorrências do Mega:
Caso o cliente tenha dúvidas de como executar tal configuração, poderá consultar a documentação de apoio do Mega.
Caso o cliente tenha seguido todos os passos acima e mesmo assim as ocorrências não estejam sendo integradas no CRM, será necessário abrir um chamado no suporte Multidados para verificar o motivo do incidente.
É necessário criar no CRM um usuário para integração da cobrança, parecido com o que é efetuado no pós-venda.
Por favor acesse: CRM>Cadastro>Usuário> adicionar> e crie o usuário com as seguintes informações:
Nome: integra. cobrança Usuário: integra. cobrança Código: integra. cobrança Senha: integra. cobrança
O Diagnóstico executado é um pré-requisito para a continuidade na configuração do módulo de cobrança.
Ele é importante para confirmarmos se os ambientes (Mega e Multidados) estão iguais.
Após executado o diagnóstico de base, o resultado deve ser informado ao cliente por e-mail e solicitado que ele ajuste qualquer divergência identificada, como por exemplo, clientes com CPF duplicados.
Somente após o retorno do cliente, deve ser dado continuidade aos demais passos.
Como executar o diagnóstico de base?
É possível executar o diagnostico pelo próprio CRM em:
CRM >Integração de Dados >Diagnóstico de base, como na imagem abaixo.
Execute cada diagnóstico da listagem. Cada diagnostico gerará um arquivo que deverá ser enviado ao cliente.
Caso não seja possível efetuar o diagnostico pelo caminho acima, será necessário abrir um chamado para que o suporte providencie o diagnóstico de base.
Deve ser criado a árvore de serviços conforme quadro abaixo.
A Macro Divisão deve ser utilizada apenas em clientes que utilizam macro sua estrutura já existente no sistema.
É necessário também criar os status abaixo na categoria ENCERRADO:
a) Status de baixa/encerramento das ocorrências de contrato (Código: COD_BAIXA_CTR). b) Status de baixa/encerramento das ocorrências de parcelas (Código: COD_STATUS_BAIXA). c) Status processo de distrato de contrato (Código: BAIXA_DISTRATO). d) Status processo de distrato de parcelas (Código: BX_DISTRATO_PARCELA).e) Status de baixa transferência (Código: BAIXA_TRANSF).f) Status de baixa transferência de parcela (Código: BAIXA_TRANSF_PARCELA).g) Status de baixa cessão (Código: BAIXA_CESSAO).h) Status de baixa cessão de parcela (Código: BX_CESSAO_PARCELA).i) Status de baixa inativação (Código: BAIXA_INATIVACAO).j) Status de baixa inativação de parcela (Código: BX_INATIVACAO_PARCELA).Obs.: Os status BAIXA_INATIVACAO e BX_INATIVACAO_PARCELA devem ser cadastrados pois são utilizados para baixar as OCs de inadimplência vinculadas a contratos inadimplentes que foram inativados.
Tanto na ocorrência de contrato, como nas ocorrências de parcelas, temos diversos campos adicionais com valores ou informações do extrato financeiro.
Estes campos adicionais, além de facilitar a consulta de informações do extrato financeiro, serão utilizados para montar gráficos e comunicações de cobrança.
Devem ser criados TODOS os campos abaixo exatamente conforme descrito:
É necessário a criação de um relatório para validar se está tudo OK com a integração, principalmente a “Data de atualização” das ocorrências.
Por este motivo, é necessário deixar um relatório criado e visível apenas para o perfil de acesso Multidados.
O relatório deve ser criar com os seguintes dados:
Abaixo segue um exemplo do retorno da API no qual atualizamos os dados de valores das ocorrências.
Algumas parametrizações são definições que precisam ser configuradas pela equipe de consultoria.
Para isso acesso: CRM >Parametrizações>Mega CRM>Inadimplências de projeto Solicitação de inadimplência.
Neste local deve ser configurado a “Solicitação de ocorrência de integração ativa (Código: COBREL)” que foi criado no passo 5.
Essa configuração encerra as ocorrências de contrato automaticamente, obedecendo as regras da cobrança.
Exemplo: Se o cliente tiver 5 parcelas em aberto e pagar as 5, quando o pagamento foi identificado no Mega, o mesmo enviará comando ao CRM para dar baixa nas 5 ocorrências de parcelas.
Porém só encerrará automaticamente a ocorrência de contrato se essa flag estiver marcada.
Obs. Por padrão a regra vem desabilitada, se assim estiver, as ocorrências de contrato devem ser encerradas manualmente.
*Importante: Os campos abaixo são campos em desuso e que serão retirados em breve deste local de configuração. Enquanto estes itens não forem totalmente retirados, configurar com o valor: 0 (zero)*
**Importante: Quando existirem ocorrências sem sub-ocorrências, significa que o Cron de inadimplência foi executado após a quitação de todas as parcelas em atraso nos contratos. Consequentemente, o sistema não gera novas ocorrências e elas não são baixadas automaticamente, devido à falta de configuração para baixa automática nas parametrizações do MEGA.**
Serão criados no mínimo dois fluxos para atender o módulo de cobrança.
É o fluxo manual de cobrança do contrato e deverá ser vinculada a solicitação “Solicitação de ocorrência de integração de contrato (Código: COD_COBRANCA)” criada no passo 5.
É o fluxo que fará o processo automático de envio de notificações de cobrança ao cliente e deve ser vinculada a solicitação “Solicitação de ocorrência de integração de parcelas (Código: COD_SOL_PARCELAS” criada no passo 5.
Para a entrega ao cliente, vamos criar ambos os fluxos de acordo com as boas práticas e ficará sob responsabilidade do cliente adequar o fluxo a sua necessidade pontual de utilização.
Todos os fluxos de atendimento precisam serem ou estarem lineares, independente se for manual ou automático.
Motivo: No fluxo de cobrança linear, a informação mais relevante é a “Data do vencimento do título”; e a ocorrência ao ser integrada, poderá ficar em status diferente dependendo da quantidade de dias em atraso, e para que a ocorrência seja criada no status correto da régua, é necessário que o fluxo esteja em modo linear.
No processo de implantação padrão, condicionamos que as MOVIMENTAÇÕES AUTOMÁTICAS, ocorrerão apenas nos fluxos de PARCELAS. E o fluxo de CONTRATO, será o fluxo de cobrança manual, ou seja, o cliente altera os status de acordo com a regra operacional da cobrança.
Porém, mesmo no fluxo de CONTRATO, é possível ter mudanças automáticas de status, para isso, o status que tiver movimentação automática, deverá ser carimbado como um “status linear” e ter seu tempo de mudança devidamente configurado. Ou seja, apenas tem movimentação automática, status que está configurado como “LINEAR” e com tempo configurado para envio ao próximo passo.
Exemplo de fluxo de contrato.
Deve ser criado o status inicial do fluxo conforme o exemplo abaixo, este status NÃO deve ser configurado como status linear:
Obs.: Na regra de cobrança, O início de todos os fluxos deve ter três etapas, independente se o fluxo for manual ou não. São estas:
O primeiro status é de integração e não pode ser usado como linear:
Ele também não deve ser visível em tela de mudar status;
O “X” significa que o status não é linear para indica-lo como linear basta clicar encima do “X”.
O status de integração é direcionado para o status que inicia o fluxo, e também o processo linear.
O status “INTERMERDIÁRIO” com um minuto é direcionado para o segundo status do fluxo no qual vai ser visualizado pelo analista como o status inicial do fluxo (AGUARDANDO ATENDIMENTO).
O status inicial de operador (AGUARDANDO ATENDIMENTO), deve estar como fluxo linear e deve ser direcionado ao terceiro status do Fluxo em 9999 dias (ETAPA FINAL DO FLUXO LINEAR).
Essa regra deverá ser utilizada tanto para o fluxo de CONTRATOS, como para o fluxo de PARCELAS.
***Os demais Status não estão marcado como Fluxo Linear***
Seguir algumas regras:
**O “X” significa que o status não é linear, para indica-lo como linear basta clicar em cima do “X”.
O “Status Intermediário” deverá ser linear, com 1 minuto e direcionado para o Status Aguardando Atendimento.
O status inicial do operador: AGUARDANDO ATENDIMENTO, deve estar como fluxo linear, com 9999 dias e ser direcionado para o próximo status Etapa Final do Fluxo Linear.
Como informado anteriormente, vamos entregar um fluxo padrão de contrato ao cliente e ele fará as mudanças que achar necessário.
Por favor clique aqui ou acesse o link abaixo para cria o fluxo de contrato semelhante a este https://tarraf.multidadosti.com.br/servicedesk/?m=admin&a=hd_fluxos&IDHD_FLUXOS=56
Importante: No fluxo de contrato deve estar previsto os status de baixa em todas as etapas do fluxo conforme exemplo abaixo:
Da mesma forma que entregamos o fluxo de contrato, também criaremos um fluxo automático de parcelas e o cliente apenas incluirá ou removera status de acordo com a sua régua de cobrança automática.
Por favor clique aqui ou acesse o link abaixo para cria o fluxo de contrato semelhante a este https://tarraf.multidadosti.com.br/servicedesk/?m=admin&a=hd_fluxos&IDHD_FLUXOS=55URL_DO_CLIENTE
Importante: No fluxo de parcelas deve estar previsto os status de baixa em todas as etapas do fluxo conforme exemplo abaixo:
Após a criação dos fluxos, os mesmos devem ser apresentados ao cliente para que o faça as modificações e crie os templates de notificações nos status.
Importante: Ao criar os templates, sugira que o destinatário dos templates seja inicialmente um e-mail ou telefone de um usuário e específico, o mesmo será utilizado para testes, o e-mail do cliente será incluído nos templates somente após todo fluxo de notificação estiver devidamente validado.
Exemplo de fluxo de parcelas: https://tarraf.multidadosti.com.br/servicedesk/?m=admin&a=hd_fluxos&IDHD_FLUXOS=55URL_DO_CLIENTE
Para acompanhar as fases de inadimplência, foi customizado nas configurações do Dashboard a inclusão dos campos “dias em atraso”, neste é possível configurar por painel os clientes que estão dentro do range configurado, correspondente a fase de inadimplente.
Por exemplo: régua de inadimplência: 1-20/ 20-34/ 34-45…
Os status de baixa não precisam estar parametrizado no fluxo, o sistema força o direcionamento, ignorando o fluxo de operação.
As baixas são realizadas apenas uma vez ao dia, em D – 1.
Neste modelo de implantação, além de apresentar ao cliente as possibilidades do item 10, entregaremos um Dashboard padrão criado no ambiente do cliente.
Segue um exemplo de Dashboard que pode ser entregue como padrão.
Os Dash de exemplos poderão ser visualizados em:
É uma característica do Módulo de cobrança receber todo e qualquer tipo de título que venha do Mega, e precisamos que seja desta forma, pois é com base nestas ocorrências que efetuamos a validação de títulos e valores entre as bases do CRM e do Mega.
Porém é comum que a empresa não queria que um determinado cliente ou tipo de contrato, não entre na régua padrão de cobrança, por exemplo: Contratos com pendências jurídicas.
Para isso, o CRM te uma configuração chamada “REGRA DE FLUXO DE COBRANÇA”.
Este item serve para direcionar os clientes ou contratos com classificações especificada para uma outra solicitação, retirando assim da régua padrão de contratos e parcelas.
Ou seja, o CRM não bloqueia recebimento de títulos, apenas redireciona para outros fluxos que não comunicação com o cliente configurado.
Importante: Este item deve ser obrigatoriamente configurado antes de integrar as fases de inadimplência do Mega.
Motivo: Se ligarmos as fases antes de efetuar os bloqueios, clientes que não deveriam receber notificações serão impactados.
No cadastro do cliente também existe um campo chamado “Status de Cobrança”.
Podemos classificar um cliente com um determinado status e com base nesta classificação, criar regras de direcionamento das ocorrências de contratos e parcelas do cliente.
Será possível efetuar a regra de bloqueio por duas informações específicas do contrato:
a) Categoria. b) Status de cobrança.
Classificação que recebemos da integração Mega, todo contrato que é integrado já vem com esta classificação:
Informação adicional ao contrato, esta informação é uma classificação que fica gravado apenas no CRM.
Após identificado o tipo de classificação que será efetuado, precisamos cadastrar as regras no CRM.
Vamos usar como exemplo, uma empresa que gostaria que, todo cliente com categoria “JURIDICO”, não entre na regra padrão de cobrança.
Primeiro, é necessário criar as solicitações para receber o contrato e as parcelas que serão direcionados estes contratos.
Importante: Mesmo que não seja efetuada nenhuma ação nas ocorrências que estiverem nestas solicitações novas, mesmo assim é necessário que exista um fluxo cadastrado para estas ocorrências e que também esteja como fluxo linear e com os status de baixa. Caso contrário, esses contratos nunca serão baixados do CRM.
Após criados as solicitações e os fluxos, vá em CRM>Parametrizações>Regra de fluxo de cobrança>adicionar novo.
Selecione CATEGORIA ou STATUS COBRANÇA: Vamos usar para nosso caso, CATEGORIA.
Agora com a regra criada, assim que recebemos um contrato classificado como “Jurídico”, ele irá automaticamente paras solicitações direcionada.
Também é possível, ao operar uma ocorrência, configurar status e campos adicionais para alterar automaticamente a categoria ou o status de cobrança de um cliente ou contrato, fazendo com que o mesmo passe a fazer parte das regras de fluxo de cobrança já cadastradas.
O Cliente pode selecionar o tipo de bloqueia na abertura da ocorrência, relacionando a um status.Para que essa regra funcione a integração externa do status deve estar relacionada a um campo adicional.
Por exemplo:
Configurei um status para bloqueio geral (telefone, e-mail, sms…etc.), no código desse status insiro a seguinte sigla: TBG.
Também é cadastrado um campo adicional tipo lista de valor, para os casos de clientes que usam mais de um bloqueio. Cada bloqueio da lista tem o seu código especifico, relacionado no próximo slide.
Para os casos de clientes inadimplentes que devem ser direcionados para outro fluxo, por exemplo:
CLIENTES NO JURIDICO CLIENTES COM TUTELA CLIENTES EM FINANCIAMENTO CLIENTES EM PROCESSO DE DISTRATO
Para estes casos no processo do fluxo manual, que geralmente é o de contrato, deve-se configurar uma integração externa no status para que o status da cobrança seja alterado automaticamente no contrato e cadastro do cliente.
Também é necessário configurar solicitações com os códigos correspondentes a cada ação, estas solicitações serão vinculadas ao fluxo de parcelas.
O fluxo de parcelas não deve ter o mesmo status inicial que está configurado a integração externa, se não o sistema ficará analisando as parcelas gerando narrativas, e um looping infinito. Neste caso, deve ser utilizado um status comum.
Deste modo o sistema entenderá que todas as ocorrências tanto de contrato quando parcela deve ser direcionadas para fluxos diferentes.
Ou seja, ao clicar no status do Jurídico, na próxima rotina do agendador, o status da cobrança no contrato será indicada para JURIDICO.
Fazendo com que as parcelas atuais e novas sejam direcionadas para o fluxo do Jurídico – parcelas, com primeiro status sem integração. E o contrato permanecerá no status de integração, até que uma ação humana seja realizada.
A ação de enviar alterar o status da cobrança deve ser realizado através de uma nova ocorrência e não no fluxo de atendimento.
O processo de retirada do Jurídico, e retornar para a régua também é através de status. Na integração externa de status do método “Status da Cobrança”, informar no valor fixo a palavra “limpar”.
Geralmente é utilizado no status de BAIXA CONTRATO além da opção de abrir Oc, assim toda vez que inadimplente paga limpa o status da cobrança.
Em CRM>Cadastro>Status (Novo Layout).
Status Em Jurídico:
Código da Solicitação: COD_SOL_JURIDICO
Código do Status: J
Configurações na aba Integração externar do status: Sigla J
Status Em Tutela:
Código da Solicitação: COD_SOL_TUTELA
Código do Status: T
Configurações na aba Integração externar do status: Sigla T
Status Em Financiamento:
Código da Solicitação: COD_SOL_FINANCIAMENTO
Código do Status: F
Configurações na aba Integração externar do status: Sigla F
Status em Distrato:
Código da Solicitação: COD_SOL_DISTRATO
Código do Status: D
Configurações na aba Integração externar do status: Sigla D
Após a conclusão das configurações do Item 5, serão efetuadas todas as configurações no Mega. Ao final do processo o módulo estará integrado, recebendo e atualizando todas as ocorrências de contrato e parcelas.
***Importante: A ocorrência de fases de inadimplência nas opções de validade, no campo “Prazo Fecham”, deve estar configurada como ZERADA ou (0), e a “opção de fechar automaticamente a ocorrência após a data de vencimento” precisa estar DESMARCADA.***
Como na imagem abaixo.
A Régua do sistema Mega, possui algumas fases, em cada uma dessa é aberta e encerrada uma ocorrência de inadimplência.
Por isso, antes de habilitar o Integra Mega, é importante entender com quanto dias o cliente deseja iniciar a régua no CRM, afim de entender, em qual fase a integração será ativada.
O módulo de cobrança do CRM integração essencialmente nas fases de inadimplência configuradas no Mega. Ou seja, é obrigatório que esta configuração seja executada no Mega.
Não apoiamos o cliente na configuração das fases de inadimplência do Mega, o cliente deve ser direcionado ao Mega para que obtenha todas as configurações necessárias.
Quando o cliente estiver configurando a fase de inadimplência, ele também poderá definir os tipos de parcelas e os parâmetros para ser considerado inadimplente conforme imagem abaixo.
Importante: O item em verde também precisa estar marcado em todos os empreendimentos que precisam ser integrados com o módulo de cobrança no CRM.
Exemplo de fase de inadimplência configurada:
Com a fase de inadimplência configurada, será necessário integrar essas fases de inadimplência ao CRM.
Importante: Ao ligar essa configuração, a integração começará a enviar as ocorrências de títulos para o CRM, por este motivo, apenas integra as fases ao CRM quando tiver encerrado todos os tópicos deste documento e efetuado todas as validações do módulo com o cliente.
Ao integrar a fase de inadimplência ao CRM, todas as fases de inadimplência devem ser vinculadas apenas a “Solicitação de ocorrência de integração ativa (Código: COBREL)” e devem estar como “FECHADA”.
Ao receber uma ocorrência de distrato do Mega, e essa informação for carimbada no contrato do cliente.
Ao rodar o agendador o sistema verificar o contrato do cliente, e direciona a ocorrência para um status de distrato que deve possuir o seguinte código:
BAIXA_DISTRATO – para Oc de contrato BX_DISTRATO_PARCELA – para Oc de Parcelas
O retorno dos e-mails enviados através das parcelas (sub chamado) e respondidos pelos devedores, são associados a ocorrência de contrato, no qual é tratada pelo operador.
É partir desse retorno é possível enviar novos e-mails.
Isto foi possível, configurando o número da ocorrência pai no assunto da ocorrência de sub chamado:
Variável: %idocorrencia_parent%
Para garantirmos que a integração está funcional e que não erros no espelhamento de bases de títulos entre CRM e Mega, foi criado um log que é possível verificar a quantidade de títulos e valores em cada base e comparar para ver se os valores estão iguais:
CRM>Parametrizações>Dados de integração>Importação>Log
Importante: Durante todo o dia são efetuadas a inclusão e baixa de títulos no CRM, por este motivo, dependendo do horário do dia, o log apresentará divergências. O mais indicado é executar o processo de atualização e validação do log após o expediente útil (Após as 18 horas).
Para abertura de ocorrências com falha na atualização das ocorrências:
1. Compare os valores disponíveis na ocorrência com extrato do Mega.
Insira a URL do extrato Mega (Disponível em: configurações Mega) e insira o número do contrato.
Exemplo: megaopf.NOMEDOCLIENTE.com.br/api/extrato/Número do contrato
Ao rodar o extrato, analise se os valores das parcelas, estão de acordo a informação disponível no CRM:
Antes de registrar ocorrências no nosso suporte informando que as ocorrências de contrato e parcelas estão reabrindo:
1. Analisar se o código de baixa do contrato e parcelas, estão configurados corretamente.
2. Se sim, direcionar para o desenvolvimento.
3. Antes de registrar ocorrências no nosso suporte informando que as parcelas não estão sendo direcionada para um dos itens da lista do status da cobrança.
4. Analisar se a integração externa está configurada corretamente.
5. Se sim, analisar se foi alterado o status da cobrança no contrato do cliente (pode ser problema no agendados).
6. Se sim, direcionar com desenvolvimento.
Para facilitar o processo de checagem, foi criado um Check list, com alguns itens que devem ser verificados. Caso seja necessário abrir uma Oc no Suporte, este documento deve ser anexado (planilha CHECK LIST COBRANÇA – Oc 69176).
Obs.: Dentro da Oc 69176 temos um link do treinamento de Integração Mega e Multidados.
https://drive.google.com/drive/folders/15gg6cX9kqFE__wi4mRmDJqpIGfhMN9YD
Se for identificado que os valores estão divergentes entre os dados gravados no CRM e o Extrato financeiro do Mega. Verificar inicialmente se o flag abaixo está habilitado. Se tiver, desabilite, atualize a inadimplência e teste novamente.
Deve ser verificado se todas as ocorrências estão com data de atualização recentes. Elas devem estar todas atualizadas no mesmo dia.
Para verificar se está ok, por favor utilize o relatório de “(Cob)” – Relatório de conferência de cobrança.
Ao gerar este relatório, deve-se mostrar apenas as ocorrências de contrato (sem cobrança ativa ou ocorrência de parcelas).
Filtro deve constar todo tipo de ocorrência de contrato que o cliente tenha, exemplo:
Exemplo do relatório gerado:
Ao analisar o relatório, se verificar que a data de atualização não está sendo atualizada, a primeira checagem deverá ser se os agendadores contidos no tópico 4.01 estão corretos.
Testes feitos utilizando o programa SoapUI.
Para realizar os testes, será preciso resgatar a URL do wsdl do cliente que será configurado em CRM > Parametrizações > Mega CRM.
A URL que iremos utilizar está no campo: URL da API SOAP do Portal de Clientes Mega
No SoapUI é preciso clicar no botao “SOAP”, após isso colar a URL no campo “initial WSDL”
Após isso clicar em OK.
No menu esquerdo serão listados todos os endpoints da API e todas as possíveis operações fornecidas pelo MEGA.
Escolha um desses e preencha os parâmetros de acordo com o que está configurado no CRM.
Após preencher, basta clicar no botão de submit destacado na imagem e na janela a direita, será apresentado o retorno da consulta.
O módulo de cobrança surgiu em um processo para uma empresa de call center. Utilizando as ferramentas que já existiam dentro do CRM foi montada a solução de cobrança, que funcionava utilizando as funcionalidades de importação de ocorrências e o fluxo de operações para fazer o atendimento.
Essa solução foi oferecida para os nossos clientes de construção civil e a ferramenta foi evoluindo para não usar mais o mecanismo de importação e realizar uma integração com o parceiro ERP Mega.
Como funciona o módulo de cobrança integrado ao Mega?
Um outro processo começa! O sistema da Multidados contém uma rotina diária de atualização dessas ocorrências de contrato utilizando a API de Extrato do Mega, nesta ação o CRM registra as parcelas atrasadas e informações de valores, tipo de receita, data de vencimento, quantidade de dias em atraso entre outras, com isso os usuários que irão trabalhar na negociação com esses clientes tenham a informação de maneira rápida e a mesma possa ser usada para avisos por e-mail, SMS e WhatsApp.
98818 – Criar um detalhes de ocorrência exclusivo para cobrança, sendo também exclusivas as listas de oque, quando, onde, como, quem e aba de parcelas, novas abas também foram criadas como aba de parcelas e boletos emitidos.
104275 – Possibilidade de enviar um e-mail de uma ocorrência movimentada pelo cron de inadimplências com as campos adicionais atualizados.
104689 – Melhoria na atualização das ocorrências que houveram renegociações.
Exemplo do Cliente MPD:
https://integracaocrm.mpd.com.br/megacrm_sync.mpd/logs/integra_mega_baixas_rodou.txt
O Manual de Pré-Venda com Integração Mega, faz parte do conjunto de manuais chamado Integrações Mega x CRM. Seu objetivo é orientar e fornecer orientações à equipe de consultoria sobre o conceito, parametrização e implementação do módulo de Pré-Vendas integrado ao ERP Mega.A missão do módulo é gerenciar todo o processo do funil de vendas, desde a geração dos leads, passando pela prospecção e negociação, até chegar ao encerramento, que resultará em descarte ou conclusão da venda.
O Manual Serasa Pefin, faz parte do conjunto de manuais denominado Integrações Mega x CRM. Seu objetivo é orientar e fornecer diretrizes à equipe de consultoria sobre o conceito, parametrização e implementação do envio de arquivos de remessa ao Serasa. Em particular, o manual aborda o processo de inclusão ou exclusão de negativação de devedores no cadastro do Serasa.
Além dos manuais mencionados acima, temos muitos outros disponíveis neste link abaixo:
https://multidadosti.com.br/docs.
Em relação à segurança, recomendamos também a leitura do documento sobre Segurança/LGPD para compreender a Lei 13.709/2018, clicando no link abaixo:
https://multidadosti.com.br/docs/arquivos/8756.
Este documento destaca a importância do planejamento de ações manuais e automáticas para o contato com o cliente, levando em consideração a legislação vigente e as boas práticas do Código de Defesa do Consumidor, no contexto das atividades de cobrança dentro do CRM.
O objetivo do sistema da MultidadosTI – Módulo de Cobrança é auxiliar as empresas no gerenciamento de contratos inadimplentes e nos respectivos contatos com os clientes. Ele oferece diversas ferramentas, como gestão da equipe, etapas da cobrança, gerenciamento de informações, indicadores de progresso e processos.
Nesse contexto, é fundamental observar as boas práticas para estar em conformidade com a legislação atual. De acordo com o artigo 42 da Lei Federal nº 8.078, de 11 de setembro de 1990, do Código de Defesa do Consumidor, é estabelecido que “Na cobrança de débitos, o consumidor inadimplente não será exposto a ridículo, nem será submetido a qualquer tipo de constrangimento ou ameaça”. Portanto, é essencial preservar a dignidade do consumidor.
Em nível estadual, existem legislações específicas para os contatos telefônicos, que devem ser levadas em consideração. Por exemplo, em São Paulo, o artigo 2º da Lei Estadual nº 15426, de 22 de maio de 2014, estabelece que “Os telefonemas de cobrança de débitos devem ser realizados de segunda a sexta-feira, das 8h às 20h, e aos sábados, das 8h às 14h, excetuando-se os feriados, nos quais essas ligações são proibidas”.
Além disso, há leis específicas em pelo menos outros quatro estados brasileiros relacionadas aos contatos telefônicos, que também devem ser consideradas.
A legislação atual não define regras e limites de dia/horário para o envio de comunicações ao cliente por outros meios, como SMS, e-mail e chat ativo. Sugerimos prestar atenção no conteúdo das mensagens e na quantidade de notificações, sempre levando em consideração que o cliente é protegido por lei contra cobranças indevidas e/ou notificações que violem sua dignidade.
A seguir, apresentamos uma compilação de sugestões para adequação às boas práticas obtidas em sites e publicações relacionadas a esse assunto:
Incluir uma mensagem de rodapé em todas as notificações com orientações sobre atrasos e atualizações. Exemplo:
Considerar a possibilidade de usar uma variável com a informação da última atualização das informações. É importante utilizá-la junto com o valor da dívida, caso deseje fornecer essa informação ao cliente.
Evitar notificações com termos ameaçadores ou explícitos sobre valores.
Descrever as mensagens de forma imparcial, buscando um atendimento pessoal e esclarecedor. Exemplo:
Essas sugestões visam garantir a adequação às boas práticas e ajudar a promover um contato respeitoso e efetivo com os clientes inadimplentes, evitando ações que possam violar a legislação e prejudicar a imagem da empresa.
