DOMPE 11/09/2026 - Diario Oficial dos Municipios de Pernambuco

TEXTO OFICIAL · ÍNTEGRA

Pernambuco , 11 de Setembro de 2026 • Diário Oficial dos Municípios do Estado de Pernambuco • ANO XVII | Nº 4180

bloqueado ou liberado pelo administrador da prefeitura sem a necessidade de intervenção da contratada;

2.32.3. A geração de senhas dos usuários deverá ser gerada aleatoriamente e criptografadas, sendo enviadas exclusivamente por meio eletrônico.

2.33. GESTÃO DA CARTA DE CRÉDITO

2.33.1. Módulo deve controlar o crédito do contribuinte e disponibilizar dos seguintes campos:

2.33.2. CGM, Número do Processo, Valor do Crédito, Data de abertura (automática, à partir da inserção do cadastro), Se foi finalizado ou não (Fechar apenas para consulta após acabar os créditos), Data da Finalização, OBS. - Motivo da Finalização, Se foi cancelado ou não (Pode ser cancelado caso queira o município, após 5 anos da abertura), Data do cancelamento, OBS - Motivo do cancelamento;

2.33.3. O Módulo deve ter as seguintes regras de funcionamento:No momento da inclusão do crédito, o Processo administrativo tem que estar com o status deferido;

2.33.4. Os campos CGM, número do processo, valor do crédito, data de abertura, não poderão sofrer intervenção após o início do lançamento dos créditos;

2.33.5. Se a concessão do crédito estiver finalizada ou cancelada, o crédito não poderá ser utilizado, fica parado, esses campos (status finalizado ou cancelado) podem ser editados pelo usuário mediante permissão especial no módulo de gerenciamento dos usuários;

2.33.6. Cada processo terá um crédito, onde um CGM poderá ter mais de 1 crédito simultâneo, com mais de um processo;

2.33.7. Para fins de segurança, o CGM do titular do processo deverá ser o mesmo do CGM do cadastro de créditos;

2.33.8. Toda baixa efetuada terá que ser atrelada ao crédito, ficando uma lista de todos os débitos que foram feitos através da baixa;

2.33.9. Quando for utilizado todo o crédito de uma determinada carta, automaticamente será finalizada aquela carta de créditos;

2.33.10. Poderá ter baixa parcial, onde o restante do débito ficará em aberto;

2.33.11. O nome da baixa manual será Compensação, na descrição da baixa deve informar o processo do cadastro do crédito utilizado; 2.33.12. Poderá ser realizada baixa manual em um determinado débito por mais de um crédito;

2.33.13. O crédito será reajustado anualmente pelo IPCA, apenas do saldo não utilizado ;

2.33.14. Se marcar mais de um débito, e a carta de crédito não der para pagar, o sistema terá que informar crédito insuficiente;

2.33.15. Se marcar apenas um débito, e a carta não pagar o débito inteiro, será dado a baixa parcial;

2.33.16. Módulo deve disponibilizar emissão de documento em cada fase da carta de crédito informando o valor utilizado e o valor do saldo

2.34. INTEGRAÇÃO AUTOMÁTICA DOS PAGAMENTOS POR PIX VIA WEB HOOK

2.34.1. Essa integração possibilitará mais rapidez aos recebimentos bancários. Por tanto, para tal funcionalidade será necessário convênio específico entre a contratante a e Instituição financeira.

2.34.2. Essa função deverá oferecer a integração PIX via Webhook com o sistema bancário. Com isso após a realização de pagamento do contribuinte, essa baixa bancária será automática, e em tempo real. Facilitando a possibilidade de entrega das certidões, alvarás etc. Dando mais agilidade ao atendimento.

2.35. GESTÃO DO CEMITÉRIO

2.35.1. Módulo deve possuir cadastro para gestão dos cemitérios com os seguintes campos:

2.35.2. Imóvel - Próprio ou Alugado (Próprio terá lançamento anual)

2.35.3. Tipo de Mausoléu - Cova Rasa, Cova Profunda, Gaveta

2.35.4. Localização do mausoléu:

2.35.4.1. Rua

2.35.4.2. Quadra

2.35.4.3. Setor

2.35.4.4. Lote

2.35.5. Nome do Proprietário

2.35.6. Responsável Financeiro (Poderá ter dois)

2.35.7. Nome dos Mortos, onde terá o CGM, na mesma estrutura dos sócios do cadastro mercantil, Opção para dar entrada e poder dar saída, os alugados todos terão que dar logo a saída (Sem limite de mortos). Quando for dado a saída do corpo, colocar uma linha em

cima do nome. Deixar para poder liberar um anexo ao lado do CGM do falecido, para caso queira colocar a algum documento;

• 2.35.8. Campo de observação para poder informar o que quiser

2.35.9. Anexos, onde poderá colocar qualquer documentação 2.35.10. Sistema deve possuir tabela para parametrizar os seguintes campos:

2.35.10.1. Nome do campo (exemplo: jazigo, mausoléu, cova rasa, túmulo)

2.35.10.2. Tipo de cobrança, onde poderá ser anual, ser múltiplo de anos ou ser eventual;

• 2.35.10.3. Valor da cobrança

2.35.11. Módulo deve possuir opção de lançamento de débito com as seguintes definições: 2.35.11.1. Caso seja proprietário, todo ano deverá ser gerado as cobranças anuais; 2.35.11.2. Caso seja alugado, na hora do cálculo irá informar quantos anos o corpo permanecerá no mausoléu;

• 2.35.11.3. Cada cliente poderá ter quantos mausoléus quiser;

2.35.11.4. O boleto deverá ser emitido no nome do Responsável financeiro;

2.35.11.5. O responsável financeiro poderá estar ligado à vários mausoléus;

2.36. BUSINESS INTELLIGENCE (BI)

2.36.1. Sistema deve contar com módulo para visualização de dashboards de B.I.;

2.36.2. Os Dashboards de B.I. poderão ser acessados mediante link disponibilizado pela contratante sem a necessidade de login no Sistema Tributário

2.36.3. Os dashboards do B.I. serão acessados apenas como consulta;

2.36.4. Os relatórios de BI permitem uma análise mais detalhada da Gestão Tributária.

2.36.5. A contratante solicitará os dashboards, conforme sua necessidade, como exemplo: dos lançamentos e receitas tributárias, com comparações de lançamento x arrecadação, evolução da arrecadação comparada com o ano anterior, dívida ativa do município, maiores devedores do imobiliário, maiores devedores do mobiliário (mercantil);

2.36.6. A Contratada terá que atualizar os dados do B.I com o mínimo de dia útil a contar da última atualização;.

2.36.7. Os dashboards solicitados de acordo com a necessidade da contratante deverão ser configurados com o prazo máximo de 05 (cinco) dias úteis a contar da data da solicitação

2.37. GERAÇÃO DE GRÁFICOS EM TELA

2.37.1. Possibilitar a geração de gráficos de barras, linhas e pizza com dados de lançamentos, baixas manuais e baixas automáticas, utilizando informações de todos os módulos do sistema de acordo com a necessidade do usuário.

2.38. MÓDULO DE ALERTA DE DÉBITOS POR E-MAIL

2.38.1. O sistema deverá possuir um módulo específico para envio de alertas de débitos por e-mail, observando os seguintes requisitos mínimos:

2.38.1.1. O módulo deverá ter como objetivo comunicar proativamente os contribuintes sobre pendências tributárias, vencimentos futuros e oportunidades de regularização. 2.38.1.2. O recurso deverá contribuir para a redução da inadimplência, otimização da arrecadação municipal e fortalecimento da comunicação entre a Prefeitura e os contribuintes.

2.38.2. Funcionalidades Obrigatórias

2.38.2.1. Deverá permitir o envio automático de notificações por e- mail a partir de regras previamente configuradas pelo gestor municipal.

2.38.2.2. Deverá possibilitar a personalização do conteúdo das mensagens, incluindo dados do contribuinte, tipo de débito, valores e prazos.

2.38.2.3. Deverá disponibilizar histórico de notificações enviadas, contendo data, horário e status de entrega.

2.38.2.4. Deverá permitir o envio de alertas em diferentes cenários: débito vencido, débito a vencer, acordos pendentes e campanhas de regularização.

2.38.2.5. Integração com Base de Dados

2.38.2.6. O módulo deverá integrar-se, de forma automática e contínua, com o cadastro tributário municipal.

www.diariomunicipal.com.br/amupe 237