TERMO DE REFERÊNCIA – SISTEMA COMERCIAL
TERMO DE REFERÊNCIA – SISTEMA COMERCIAL
Contratação de empresa especializada para fornecimento de solução, com as respectivas cessões de direitos e licenças de uso, sem exclusividade, instalação, migração/conversão da base de dados, configuração, alteração, atualização, customização, manutenção, suporte, monitoramento, treinamento e operação assistida, fornecimento e gerenciamento de softwares, do banco de dados/base de dados, com hospedagem (“hosting”), solução esta dedicada para esta autarquia conforme características e especificações constantes neste Termo de Referência.
SUMÁRIO
1.4 OBRIGAÇÕES DA LICITANTE VENCEDORA 18
1.6 CONTATO E/OU ABERTURA DE CHAMADOS (PEDIDOS) 20
1.7 ADEQUAÇÕES E MODELOS EVOLUTIVOS 23
1.8 DESCONTO POR INTERRUPÇÕES 24
1.9.2 AVALIAÇÕES E ACEITAÇÕES/HOMOLOGAÇÕES DE RESULTADOS 28
1.9.3 OPERAÇÃO ASSISTIDA/“MENTORING” 28
2.2 COMPATIBILIDADE COM NAVEGADORES 35
2.3 BANCO DE DADOS E FILE SYSTEM: LICENÇAS E ESPAÇO DE ARMAZENAMENTO 36
2.4 GERENCIAMENTO DO SISTEMA OPERACIONAL 36
2.5 GERENCIAMENTO DO BANCO DE DADOS: DESEMPENHO E OUTRAS TAREFAS 36
2.7 SENHAS DE ADMINISTRADORES 38
2.9 REGISTROS DE ACESSO E DE OPERAÇÕES 38
2.11 LINGUAGENS DE PROGRAMAÇÃO 39
2.12 “FRAMEWORKS”, MÁQUINAS VIRTUAIS E COMPONENTES 39
2.14 CONSISTÊNCIAS E TRATAMENTO DE ERROS 40
3.7 SITUAÇÃO DE ACESSO DO USUÁRIO 44
3.8 CRIAÇÃO E VALIDAÇÃO DE SENHAS 44
6.2 TAREFAS EXECUTADAS POR USUÁRIO 51
7.2 ENTRADA DE VALORES PARA VERIFICAÇÃO 53
7.3 EXECUÇÃO DE COMPARAÇÃO ENTRE FAIXAS DE TARIFAS 53
7.4 CATEGORIZAÇÃO E ESTATÍSTICAS DAS TARIFAS 54
7.6 HISTOGRAMA POR CATEGORIA, FAIXAS, GRUPOS, TIPOS DE CONSUMO 55
8 LIGAÇÕES DE ÁGUA E ESGOTO 56
8.1 DADOS CADASTRAIS NECESSÁRIOS 56
8.2 PAGAMENTO DE BOLETOS E LIBERAÇÃO DE INSTALAÇÃO 56
8.4 GERAÇÃO DAS ORDENS DE SERVIÇO 57
8.5 CONTROLE DA ATIVAÇÃO DAS NOVAS LIGAÇÕES 58
8.6 TIPOS DE LIGAÇÃO: HIDROMETRADAS E CONSUMO FIXO 59
8.7 TIPOS DE FATURAMENTO ESPECIAIS 59
8.8 REDES DE ÁGUA INDIVIDUALIZADA: CADASTRAMENTO DE HIDRÔMETRO MASTER E DEPENDENTE 60
9.1 CADASTRO DE HIDRÔMETROS 62
9.2 LEGADO DOS DADOS EXISTENTES: HIDRÔMETROS, LOCALIZAÇÃO, ESTADO, FABRICANTES, MODELOS 62
9.3 DADOS CADASTRAIS: LIGAÇÃO, SITUAÇÃO 63
9.4 CONTROLE DE SITUAÇÃO DE INSTALAÇÃO 63
9.6 INFORMAÇÕES DE AFERIÇÃO: DADOS E FOTOS 64
9.7 INSTALAÇÃO DE HIDRÔMETROS E ATIVAÇÃO DE LIGAÇÃO 64
9.8 VALIDAÇÕES COM O CRONOGRAMA DE LEITURA 65
9.9 POSSIBILIDADE DE ENTRADA DE DADOS XXX XXXXXX XX XXXXXX XX XXXXXX 00
9.10 TRATAMENTO DE ERROS DE INSTALAÇÃO DE LIGAÇÕES 65
9.11 ALERTA DE HIDRÔMETROS FORA DA VALIDADE 66
10.1 FLUXO DE ATENDIMENTO: PRÉ-ATENDIMENTO E ATENDIMENTO PRESENCIAL 67
10.2 ATENDIMENTO TELEFÔNICO – 0800 68
10.3 INFORMAÇÕES A MUNÍCIPES 69
10.4 ACESSO A INFORMAÇÕES CADASTRAIS 70
10.5 HISTÓRICO DE LIGAÇÕES/MUNÍCIPES 70
10.7 RESUMO DE LEITURAS E FATURAMENTO 71
10.8 RELIGAÇÃO PELOS ATENDENTES 71
10.9 OPERAÇÕES COM DOCUMENTOS ELETRÔNICOS: FOTOS E DIGITALIZAÇÕES 72
10.10 IMPRESSÃO DE TELAS E DOCUMENTOS COMPROBATÓRIOS 73
10.11 ACOMPANHAMENTO DE DÉBITOS 73
10.12 IMPRESSÃO DE SEGUNDA VIA E GUIAS DE QUITAÇÃO 74
10.13 TRAVAS DE SEGURANÇA: EXCEÇÕES, EXECUÇÕES E PROCESSOS 75
10.14 VALORES INCORPORADOS EM CONTA 75
11.1 QUITAÇÃO ANUAL DE DÉBITOS 77
11.4 CERTIDÃO POSITIVA COM EFEITO DE NEGATIVA 79
12.1 CRONOGRAMA AUTOMÁTICO DE LEITURA 80
12.2 CADASTRO DE FERIADOS E DIAS ÚTEIS 80
12.3 GERAÇÃO DO ARQUIVO DE ENVIO 80
12.5 ACOMPANHAMENTO DOS LEITURISTAS 82
12.6 INTERFACE COM O SISTEMA DAS TERCEIRIZADAS 82
12.7 RECEBIMENTO DOS LOTES DE LEITURA 82
12.8 OCORRÊNCIAS DE LEITURA 83
12.9 GRÁFICOS DE LEITURA E PERDAS 83
13.1 RECEBIMENTO DE FATURAS 85
13.2 DOCUMENTOS DE ARRECADAÇÃO 85
13.3 INTERFACE COM AS “VANS” 86
13.5 SERVIÇOS DIVERSOS – BOLETOS 87
13.7 ATUALIZAÇÃO DE DATAS DE VENCIMENTOS 88
13.9 ATUALIZAÇÃO MONETÁRIA E MULTAS 89
13.10 BOLETOS AVULSOS E DE PREJUÍZO 90
14.1 REGRAS DE GERAÇÃO DE FATURAS 92
14.2 RUBRICAS DE FATURAMENTO E OCORRÊNCIAS 95
14.3 GRÁFICOS DE FATURAMENTO 96
14.7 FATURAMENTO POR ECONOMIAS 97
15 PARCELAMENTO 100
15.1 REGRAS LEGAIS DE PARCELAMENTO – XXXXXXXX 000
15.2 TRAVAS DE SEGURANÇA EM PARCELAMENTO 100
15.3 PARÂMETROS DE PARCELAMENTO 101
15.4 TERMO DE PARCELAMENTO 101
15.5 TRATATIVA DE DÉBITOS EM DÍVIDA ATIVA 102
15.6 TRATATIVA DE DÉBITOS EM EXECUÇÃO FISCAL 103
15.7 INCLUSÃO EM CONTAS FUTURAS/BOLETOS 104
15.8 IMPRESSÃO DE FATURAS E TERMOS 104
15.9 DADOS NECESSÁRIOS PARA EFETIVAÇÃO 105
15.10 ACOMPANHAMENTO DE PARCELAMENTO 105
15.11 PARCELAMENTO ÚNICO 106
15.12 ESTORNOS E REPARCELAMENTO 106
15.13 VENCIMENTO DE PARCELAS 107
15.14 USO DE CRÉDITOS EM PARCELAMENTOS 108
16 SUPRESSÃO E FISCALIZAÇÃO 109
16.1 INCORPORAÇÃO PARA CORTE 109
16.2 NOTIFICAÇÃO DE DÉBITOS 110
16.3 GERAÇÃO DE ORDENS DE SERVIÇO DE CORTE MANUAIS/AUTOMÁTICAS 111
16.4 PARÂMETROS DE CORTE 112
16.5 OCORRÊNCIAS DE CORTE 112
16.6 GRÁFICOS E RELATÓRIOS DE ACOMPANHAMENTO 113
16.7 RELIGAÇÃO 113
16.8 CADASTRO DE VISTORIAS 114
17 ORDENS DE SERVIÇO 115
17.1 TIPOS DE ORDEM DE SERVIÇO 115
17.2 PARÂMETROS DE ORDEM DE SERVIÇO 115
17.3 CRIAÇÃO DE NOVOS TIPOS DE ORDEM DE SERVIÇO 116
17.4 DADOS NECESSÁRIOS PARA INSTANCIAÇÃO DE ORDEM DE SERVIÇO 116
17.5 CARGA DAS ORDENS DE SERVIÇO ATUAIS 116
17.6 PROGRAMAÇÃO DE ORDENS DE SERVIÇO 117
17.7 CONCEITO DE ORDENS DE SERVIÇO DEPENDENTES 118
17.8 OCORRÊNCIAS DE ORDENS DE SERVIÇO 118
17.9 ORDENS DE SERVIÇO AUTOMÁTICAS 118
17.9.1 LIGAÇÕES – ÁGUA E ESGOTO 118
17.9.2 MANUTENÇÃO – REDES E LIGAÇÕES 120
17.10 ACOMPANHAMENTO DAS ORDENS DE SERVIÇO 121
17.11 CADASTRO DE EQUIPES E RESPONSÁVEIS 122
17.12 TRAMITAÇÃO ENTRE ÁREAS E ENTRE EQUIPES 122
17.13 “STATUS” DE ORDENS DE SERVIÇO 122
17.14 ENCERRAMENTOS 123
17.15 ALERTAS 124
17.16 COBRANÇA DE TAXAS E MATERIAIS 124
18 DÍVIDA ATIVA 125
18.1 INCORPORAÇÃO 125
18.1.1 NOTIFICAÇÃO DOS POSSÍVEIS INCORPORADOS 125
18.1.2 PARÂMETROS E REGRAS 125
18.2 GERAÇÃO DO LIVRO DA DÍVIDA ATIVA 126
18.3 MANIPULAÇÃO DOS DÉBITOS INSCRITOS 127
18.4 CONTROLE DA DÍVIDA ATIVA 128
18.5 RESUMOS DE VALOR INSTANTÂNEO 129
18.6 RELATÓRIOS DE PRESTAÇÃO DE CONTAS 129
18.7 RELATÓRIOS CONTÁBEIS 130
18.8 RELATÓRIOS DE ARRECADAÇÃO 130
19 INTEGRAÇÃO COM SISTEMA CONTÁBIL 132
19.1 INFORMAÇÕES ESPELHADAS 132
19.2 BATIMENTO DE RESULTADOS 132
19.3 FORMA DE TROCA DE ARQUIVOS 133
19.4 RELATÓRIOS DE ACOMPANHAMENTO 133
19.5 OPERAÇÃO 134
20 PROCESSOS JURÍDICOS 135
20.1 ABERTURA DE PROCESSOS 135
20.2 EXECUÇÃO FISCAL 136
20.3 CONTROLE DE HONORÁRIOS ADVOCATÍCIOS 138
20.4 PARCELAMENTO DE DÉBITOS EXECUTADOS 142
20.5 QUITAÇÃO DE DÉBITOS 149
20.6 GERAÇÃO DE ARQUIVOS PARA DISTRIBUIÇÃO DE PROCESSO 150
20.7 ENVIO DE SUPRESSÃO 150
20.8 HISTÓRICO DE EXECUÇÕES/LEGADOS 151
20.9 ASSINATURA ELETRÔNICA 152
20.10 RELATÓRIOS DE ACOMPANHAMENTO 153
21 ITENS ADICIONAIS 155
21.1 AGENDAMENTO DE TAREFAS 155
21.2 LEGADO (CREDTAC) 155
21.3 EMISSÃO DE SEGUNDA VIA PELA INTERNET (WEB) 156
22 LISTA DE ACRÔNIMOS 159
23 APÊNDICE 160
23.1 MODELO DE PETIÇÃO DE CERTIDÃO DE DÍVIDA ATIVA 160
23.2 MODELO DE CERTIDÃO DE DÍVIDA ATIVA 161
23.2 MODELO DE CERTIDÃO DE DÍVIDA ATIVA 162
23.3 MODELO DE PETIÇÃO DE SUSPENSÃO DO PROCESSO PADRÃO 163
23.4 MODELO DE TERMO DE PARCELAMENTO BASE 164
23.4 MODELO DE TERMO DE PARCELAMENTO BASE 165
LISTA DE ILUSTRAÇÕES
ILUSTRAÇÃO 21.1 – EXEMPLO DE APRESENTAÇÃO DE DÉBITOS COM LINKS PARA EMISSÃO DE SEGUNDA VIA 157
LISTA DE TABELAS
TABELA 1.1 – NÍVEIS DE PRIORIDADE DE ATENDIMENTO CONFORME A CRITICIDADE 21
TABELA 1.2 – PRAZOS DE SOLUÇÃO ESPERADOS CONFORME A PRIORIDADE 22
TABELA 1.3 – CRONOGRAMA DO PROJETO 25
TABELA 13.1 – EXEMPLO DE CÁLCULO DE ATUALIZAÇÃO MONETÁRIA E MULTAS 90
TABELA 14.1 – EXEMPLO DE FATURAMENTO POR ECONOMIAS 98
TABELA 14.2 – EXEMPLO DE FATURAMENTO POR ECONOMIAS 99
TABELA 15.1 – EXEMPLO DE PARCELAMENTO 103
TABELA 20.1 – EXEMPLO DO CÁLCULO DOS HONORÁRIOS DE UM PARCELAMENTO COM VALOR DE ENTRADA IGUAL AO VALOR DOS HONORÁRIOS 139
TABELA 20.2 – EXEMPLO DO CÁLCULO DOS HONORÁRIOS DE UM PARCELAMENTO COM VALOR DE ENTRADA MAIOR DO QUE O VALOR DOS HONORÁRIOS 140
TABELA 20.3 – EXEMPLO DO CÁLCULO DOS HONORÁRIOS DE UM PARCELAMENTO SEM VALOR DE ENTRADA E HONORÁRIOS DIVIDIDOS EM PARCELAS 141
TABELA 20.4 – TIPOS DE TERMO DE PARCELAMENTO 144
TABELA 20.5 – USO DE NOMES PARA PETIÇÃO E TERMO DE PARCELAMENTO 147
1 INTRODUÇÃO
1.1 OBJETO
Contratação de empresa especializada para fornecimento de solução, com as respectivas cessões de direitos e licenças de uso, sem exclusividade, instalação, migração/conversão da base de dados, configuração, alteração, atualização, customização, manutenção, suporte, monitoramento, treinamento e operação assistida, fornecimento e gerenciamento de softwares, do banco de dados/base de dados, com hospedagem (“hosting”), solução esta dedicada para esta autarquia conforme características e especificações constantes neste Termo de Referência.
1.2 JUSTIFICATIVA
O Saae Sorocaba possui a maioria de seus sistemas de computação terceirizados, incluindo o atual Sistema Comercial, o qual é utilizado, em linhas gerais, para gerenciamento e controles administrativos:
I. De serviços relacionados ao fornecimento de água tratada, coleta, afastamento e tratamento de esgoto, ligações e manutenções de água e esgoto, dentre outros serviços;
II. Sobre faturamento, arrecadação, cobrança, recebimento destes serviços.
Visando garantir a continuidade da prestação destes serviços e mencionada gestão administrativa, faz-se necessária a contratação especificada no objeto deste Termo de Referência. Adicionalmente, as seguintes melhorias serão proporcionadas para o Saae Sorocaba:
• Atualização da tecnologia utilizada para equipamentos mais modernos, seguros e rápidos, incluindo versões de softwares atualizadas, oferecendo mais segurança e eficiência para diversas tarefas;
• Pela solução/sistema solicitado(a) trabalhar em ambiente web, será possível acessá-lo(la) de diversas localidades de Sorocaba, bastando existir conexão internet compatível, mitigando problemas de infraestrutura (ou falta de) nos atuais pontos de atendimento ao cidadão distantes da Unidade Central da autarquia, e também de eventuais instalações de novos pontos de atendimento, como por exemplo, a criação de novas Casas do Cidadão;
• Serão mitigados os problemas com quedas do “backbone” via rádio da Prefeitura, visto que o Saae Sorocaba faz uso desta rede para conectar as Casas do Cidadão à Unidade Central. Pelo proposto, a autarquia terá sua própria conexão (via web) com as referidas Casas, utilizando o “backbone” da Prefeitura como alternativa de contingência em caso de falhas de conexão internet;
• Na mesma linha de raciocínio, atualmente, caso haja problemas com o “backbone” da Prefeitura, a autarquia perderá conexão com todas as Casas simultaneamente. Como o proposto baseia-se em uma solução/sistema via web, por estarem as Casas em locais distantes, os problemas poderão ocorrer em uma ou outra Casa isoladamente, diminuindo muito a chance de todas perderem conexão ao mesmo tempo com a Unidade Central;
• A transferência da gestão dos bancos de dados, dos procedimentos de backup e também as atualizações de “hardware” (equipamentos) e “software” (licenças de uso) tendem a tornar estas operações mais efetivas, pois serão realizadas por empresa(s) dedicada(s) para o assunto. Consequentemente, os atuais servidores que trabalham atualmente nestas atividades poderão ser alocados em outras que resultem em melhor aproveitamento para a autarquia.
1.3 DISPOSIÇÕES GERAIS
A licitante vencedora deverá manter equipe dedicada, independente da fase deste contrato/projeto, sem custos adicionais ao Saae Sorocaba, para quaisquer atendimentos (presenciais ou não), programações, implementações, implantações, além de adequações,
alterações, atualizações, customizações, manutenções e evoluções da solução/sistema objeto deste Termo de Referência. Os prazos de atendimento estão especificados no subitem 1.6 abaixo. A equipe dedicada mencionada deverá, minimamente, ser composta por: um Gerente/Coordenador técnico; um Analista para levantamento de requisitos ou suporte; um Analista para fornecer treinamentos; um Administrador de Banco de Dados (“Database Administrator” – DBA); um Programador. Estes profissionais não poderão acumular funções, ou seja, a equipe deverá, minimamente, ser composta por cinco profissionais. A licitante vencedora deverá informar, trimestralmente ao Saae Sorocaba, os nomes dos funcionários/colaboradores componentes da equipe dedicada mencionada, respectivas formas de contratação (vínculo), e também os nomes dos funcionários/colaboradores participantes de atividades de atendimento.
As licitantes deverão apresentar atestado(s) de capacidade técnica, fornecido(s) por pessoas jurídicas de direito público ou privado, cujo objeto seja pertinente e compatível em características e prazos com o objeto da licitação, comprovando a execução de serviços similares, equivalentes ou superiores a 50% (cinquenta por cento) sobre 180.000 (cento e oitenta mil) ligações ativas, e ainda comprovando que a empresa prestou/presta serviços de tecnologia da informação (TI) em: fornecimento de solução, com as respectivas cessões de direitos e licenças de uso, sem exclusividade, instalação, migração/conversão da base de dados, configuração, alteração, atualização, customização, manutenção, suporte, monitoramento, treinamento e operação assistida, fornecimento e gerenciamento de softwares, do banco de dados/base de dados, com hospedagem (“hosting”).
O Saae Sorocaba utiliza-se de sistemas terceirizados – por meio de licenças de uso de software, ou seja, desenvolvidos por terceiros que possuem a propriedade, códigos-fonte, dicionário de dados, diagramas, enfim, documentações pertinentes – que, apesar de possuírem ligações com o atual Sistema Comercial, não são integrados com este. Caso necessário, a licitante vencedora será a única responsável pelo fornecimento/obtenção de dados/informações diretamente para/com as fornecedoras destes sistemas terceirizados
(incluindo a fornecedora do atual Sistema Comercial), não cabendo ao Saae Sorocaba responsabilidades e/ou custos relativos ao fornecimento/obtenção de dados/informações.
Todos os custos adicionais ou restantes, independente do fato/causa gerador(a), deverão estar inclusos na proposta da licitante vencedora, não sendo aceitas apresentações/imposições de novos custos/ônus ao Saae Sorocaba.
1.4 OBRIGAÇÕES DA LICITANTE VENCEDORA
A licitante vencedora será responsável por/pelo(a):
• Solução/sistema objeto deste Termo de Referência, bem como os bancos de dados/base de dados e todo “software” (sistemas operacionais – exceto aqueles que rodarão nas estações de trabalho/microcomputadores componentes do patrimônio da autarquia –, linguagens de programação, bibliotecas, componentes, ferramental tecnológico, enfim, tudo o que for necessário para a programação, implementação, implantação, utilização, além de adequações, alterações, atualizações, customizações, manutenções e evoluções da solução/sistema ofertado(a)) e/ou “hardware” e/ou terceiros/serviços/produtos que forem escolhidos, negociados, adquiridos/contratados pela licitante vencedora, os quais não terão custos adicionais para o Saae Sorocaba. Observação: os dados armazenados nos bancos de dados – ou seja, a base de dados – serão, em qualquer tempo, de propriedade exclusiva do Saae Sorocaba;
• Contratar, treinar e manter funcionários/colaboradores (devidamente uniformizados e identificados) em quantidade e qualificação compatíveis para a execução do disposto neste Termo de Referência, sendo considerada neste particular, como única empregadora;
• Manter sigilo absoluto os dados e/ou informações obtidos;
• Fazer cumprir as normas disciplinares e de segurança. Cumprir as exigências das leis civis, criminais, tributárias, comerciais, trabalhistas, previdenciárias, sindicais,
securitárias etc. relativamente a tudo e todos diretamente e/ou indiretamente ligados à licitante vencedora e envolvidos no disposto neste Termo de Referência, inclusive as determinações emanadas do Saae Sorocaba, fazendo prova dos recolhimentos devidos, responsabilizando-se perante o Saae Sorocaba, Poder Público, entidades/repartições competentes e terceiros, com total isenção do Saae Sorocaba e sem nenhum tipo de ônus para a autarquia;
• Responder por danos ou prejuízos comprovadamente causados ao Saae Sorocaba, seus funcionários/servidores e/ou terceiros, obrigando-se a indenizá- los;
• Desenvolver boas relações com os funcionários/servidores e/ou terceiros do Saae Sorocaba, acatando quaisquer instruções e o que mais emanar da fiscalização;
• Responder perante o Saae Sorocaba, Poder Público, entidades/repartições competentes e terceiros, com total isenção do Saae Sorocaba e sem nenhum tipo de ônus para a autarquia, pelos recursos, produtos, serviços por ela escolhidos, negociados, adquiridos, contratados e/ou executados;
• Executar os serviços necessários para a realização do disposto neste Termo de Referência, devendo, obrigatoriamente, obedecer às normas técnicas vigentes neste país, responsabilizando-se perante o Saae Sorocaba, Poder Público, entidades/repartições competentes e terceiros, com total isenção do Saae Sorocaba e sem nenhum tipo de ônus para a autarquia. Os padrões de qualidade assegurados por estas normas devem ser atendidos, sendo que, quando as definições deste contrato/projeto assim determinarem, deverá ser obedecida a exigência superior, e em todos os casos dever-se-á aplicar a regra da boa arte;
• Comunicar ao Saae Sorocaba, preferencialmente à área de TI, imediatamente, qualquer ocorrência ou anormalidade que venha interferir na execução de trabalhos, produtos ou serviços relativos ao disposto neste Termo de Referência.
1.5 MANUTENÇÕES
As manutenções (preventivas e corretivas) e atualizações referem-se a todo o “hardware” e/ou “software” e/ou serviços/produtos escolhidos, negociados, adquiridos/contratados pela licitante vencedora, de acordo com o subitem 1.4 acima. Todas as manutenções e atualizações serão executadas pela licitante vencedora durante toda a vigência deste contrato/projeto, e esta terá total responsabilidade por estas manutenções/atualizações, as quais não serão passíveis de cobranças e/ou custos adicionais para a autarquia.
A licitante vencedora deverá realizar a manutenção preventiva conforme seus ciclos de vida, incluindo adaptações com novos sistemas operacionais lançados e versões do banco de dados utilizados. Não serão aceitos contatos/chamados encerrados em caso de problemas indicando incompatibilidades com sistemas operacionais, banco de dados ou outro componente da solução/sistema que seja de versão superior à versão vigente na época de implantação.
A licitante vencedora deverá apresentar o plano de manutenção preventiva – vedadas atuações concorrentes com o horário de produção que possam impactar no uso pelos usuários – a fim de garantir desempenho e confiabilidade.
1.6 CONTATO E/OU ABERTURA DE CHAMADOS (PEDIDOS)
A licitante vencedora deverá dispor ao Saae Sorocaba formas de contato e/ou abertura de chamados para o suporte aos usuários e/ou aos profissionais da área de TI, sendo obrigatório o atendimento por e-mail, telefone, fax e/ou qualquer outra forma de contato possível. Caso a licitante vencedora disponha de um portal ou sistema de contatos/chamados, a autarquia não ficará obrigada a abrir contatos/chamados por esta ferramenta e nem utilizá-la como meio principal de comunicação.
A licitante vencedora deverá fornecer e manter atualizada com o Saae Sorocaba a documentação completa sobre manutenções, procedimentos de atendimento, chamados e
contatos técnicos realizados com os diversos níveis (“service desk”, coordenação, gerência, dentre outros).
O tempo de atendimento de um contato/chamado, o qual deverá ter imediata geração de número de protocolo (independentemente da forma de abertura), será de até 15 minutos e o prazo para solução/resolução, o qual incluirá o tempo de atendimento – independentemente se o problema foi gerado por usuário (interno ou externo), pelos profissionais da área de TI, por erro de sistema/solução, pela licitante vencedora, por terceiros/produtos/serviços por ela contratados etc. (exceção se fará somente para erros/problemas com os links/pontos de Internet mencionados no subitem 2.1 abaixo) – variará de acordo com a prioridade/criticidade, que será definida/diagnosticada pelo Saae Sorocaba e informada à licitante vencedora na abertura do contato/chamado, de acordo – salvo exceções determinadas exclusivamente pela autarquia – com as duas tabelas seguintes:
PRIORIDADE | CRITICIDADE DO PROBLEMA |
0 – Inoperante | Ambiente inacessível com queda completa da solução/sistema. |
1 – Crítica | Problema crítico que impacte na operação normal da solução/sistema. |
2 – Alta | Baixa performance/desempenho do ambiente, mas grande parte da solução/sistema encontra-se em funcionamento. |
3 – Relatórios | Relatórios operacionais do ambiente, não acessíveis via gerador de relatórios ou ferramentas semelhantes. |
4 – Média | Resolução de incidentes sem impacto na operação da solução/sistema. |
5 – Requisições de Serviços | Serviços de operação mínima do ambiente. |
6 – Baixa | Serviço agendado e/ou sem necessidade de atendimento urgente. |
PRIORIDADE | PRAZO PARA SOLUÇÃO (EM HORAS CORRIDAS) |
6 – Baixa | Conforme agendamento |
5 – Requisições de Serviços | 96 horas |
4 – Média | 72 horas |
3 – Relatórios | 48 horas |
2 – Alta | 12 horas |
1 – Crítica | 03 horas |
0 – Inoperante | 01 hora |
O suporte aos usuários e/ou aos profissionais da área de TI também incluirá atendimento a dúvidas e demais assuntos, inclusive sobre regras de negócio, que deverão ser solucionadas/respondidas em, no máximo, três horas (ou seja, deverão ter tratamento de prioridade 1 – Crítica), incluindo o tempo de atendimento e o tempo de solução/resposta.
A licitante vencedora deverá disponibilizar, pelo menos, um Gerente/Coordenador técnico para a autarquia ter livre acesso/contato com este profissional. Não é permitido à licitante vencedora utilizar-se de estruturas de atendimento que impeçam o acesso/contato com seus funcionários/colaboradores de nível hierárquico mais elevado.
Os atendimentos, independente do nível, deverão seguir as melhores práticas descritas por ITIL, incluindo os ciclos de incidente e problema, sendo necessário, para o encerramento efetivo do contato/chamado, o envio da documentação completa (incluindo as causas raízes) e a concordância da autarquia, ou seja, o encerramento efetivo do contato/chamado não poderá ser feito somente pela licitante vencedora.
Atendimentos de primeiro nível não serão considerados como atendimento de contatos/chamados para efeitos de “Service-Level Agreement” (SLA) e/ou dos prazos mencionados anteriormente neste subitem.
1.7 ADEQUAÇÕES E MODELOS EVOLUTIVOS
Quaisquer modificações da solução/sistema incluindo regras de negócio, formas de trabalho, módulos etc., caso necessárias por exigências legais (independente da esfera) e/ou judiciais (independente da esfera) e/ou do Tribunal de Contas e/ou do Ministério Público, não deverão ensejar a cobrança de valores adicionais para o Saae Sorocaba, independente da fase deste contrato/projeto.
Consideram-se customizações e/ou melhorias as inclusões/alterações de funcionalidades e/ou modificações na forma de operação para agilizar ou tornar mais fáceis operações sistêmicas/organizacionais/procedimentais. As customizações e/ou melhorias não serão passíveis de cobranças e/ou custos adicionais para a autarquia, independente da fase deste contrato/projeto.
Em caso de necessidade de adequações, alterações, atualizações etc. – seja para atendimento a manutenções, exigências (legais – independente da esfera – e/ou judiciais – independente da esfera – e/ou do Tribunal de Contas e/ou do Ministério Público), customizações e/ou melhorias etc. – da solução/sistema, deverá haver uma forma de distribuição que seja transparente para o Saae Sorocaba. Não serão aceitas soluções que obriguem a adequações, alterações, atualizações etc. máquina por máquina, e estas adequações, alterações, atualizações etc. (automáticas ou não) deverão funcionar com o nível de segurança atual das estações de trabalho/microcomputadores e servidores da autarquia, vedada terminantemente a necessidade de usuários administradores de rede ou locais para a execução de procedimentos/tarefas.
A licitante vencedora deverá deslocar equipe multifuncional para o levantamento de requisitos, cronograma de projeto e todas as medidas necessárias para a implantação das adequações, alterações, atualizações etc.
A licitante vencedora deverá apresentar projeto ao Saae Sorocaba, demonstrando, através de métodos reconhecidos de mercado, o levantamento de horas de trabalho para cada fase/tarefa/atividade componente do projeto, incluindo o valor de homem-hora praticado para cada classe/especialização de profissional envolvido em cada
fase/tarefa/atividade componente do projeto. Exemplos de metodologias aceitáveis: pontos de função, PMI (PMBOK), dentre outras.
A autarquia reserva-se o direito de negar cronogramas e prazos, exigindo maior celeridade no processo de implementação/implantação em caso de urgência ou de cumprimento de exigências (legais – independente da esfera – e/ou judiciais – independente da esfera – e/ou do Tribunal de Contas e/ou do Ministério Público).
O ciclo de vida da solução/sistema será de total responsabilidade da licitante vencedora, ficando obrigada a manter bases de dados de versão de componentes, bem como regras de negócio e histórico de modificações acessíveis ao Saae Sorocaba.
1.8 DESCONTO POR INTERRUPÇÕES
Em caso de interrupções dos serviços estabelecidos neste Termo de Referência, a licitante vencedora concederá um desconto proporcional ao período interrompido, o qual deverá ser incluso imediatamente após a interrupção do serviço no documento de cobrança.
O valor a ser descontado deverá ser calculado conforme fórmula a seguir:
𝐷𝑒𝑠𝑐𝑜𝑛𝑡𝑜 𝑑𝑜 𝑚ê𝑠 (𝑅$) = 𝑉𝑀𝑆 ÷ 𝑇𝑇𝑆𝑃 ∗ 𝑇𝑇𝐼
𝑉𝑀𝑆 = 𝑣𝑎𝑙𝑜𝑟 𝑚𝑒𝑛𝑠𝑎𝑙 𝑑𝑜 𝑠𝑒𝑟𝑣𝑖ç𝑜 (𝑅$)
𝑇𝑇𝐼 = 𝑡𝑒𝑚𝑝𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑒 𝑖𝑛𝑑𝑖𝑠𝑝𝑜𝑛𝑖𝑏𝑖𝑙𝑖𝑑𝑎𝑑𝑒 (ℎ𝑜𝑟𝑎𝑠)
𝑇𝑇𝑆𝑃 = 𝑡𝑒𝑚𝑝𝑜 𝑡𝑜𝑡𝑎𝑙 𝑑𝑜 𝑠𝑒𝑟𝑣𝑖ç𝑜 𝑝𝑟𝑒𝑠𝑡𝑎𝑑𝑜 (1 𝑚ê𝑠 = 720 ℎ𝑜𝑟𝑎𝑠)
Por exemplo, se o valor mensal do serviço custasse R$ 10.000,00 (dez mil reais), e este serviço ficasse indisponível por quatro horas em um mês, o valor do desconto seria:
𝑉𝑀𝑆 = 10.000
𝑇𝑇𝐼 = 4
𝐷𝑒𝑠𝑐𝑜𝑛𝑡𝑜 𝑑𝑜 𝑚ê𝑠 (𝑅$) = 10000 ÷ 720 ∗ 4 = 55,56
1.9 CRONOGRAMA DO PROJETO
Este Termo de Referência contém, a priori, as necessidades básicas para o Saae Sorocaba, de modo que maiores detalhes deverão ser levantados e analisados pela licitante vencedora, incluindo “modus operandi”, regras de negócio, consistências, “layouts” de telas e relatórios. Assim sendo, este Termo de Referência é enumerativo e não taxativo.
Todas as funcionalidades e/ou características requisitadas e/ou desejadas e/ou mencionadas nos itens e subitens deste Termo de Referência deverão ser atendidas pela licitante vencedora e estar disponíveis para utilização/operação até o final da fase de “Transição/Implantação” (semana 13), incluindo todas as alterações, atualizações e customizações necessárias/requeridas pelo Saae Sorocaba.
Quaisquer despesas ocorridas durante as fases deste contrato/projeto, como por exemplo, confecção de materiais didáticos, despesas com deslocamento, hospedagem e alimentação do corpo técnico da licitante vencedora (ou contratado pela), dentre outras, serão exclusivamente de responsabilidade da licitante vencedora, sem qualquer tipo de ônus para o Saae Sorocaba.
Tabela 1.3 – Cronograma do projeto
Fonte: Serviço Autônomo de Água e Esgoto de Xxxxxxxx (0000)
FASE | RECURSOS | INÍCIO | TÉRMINO | TOTAL DE SEMANAS | OBSERVAÇÕES |
Transição/ Implantação | Licitante Vencedora; Profissionais da área de TI; Todas as áreas envolvidas. | Semana 1 (Segunda- feira) | Semana 13 (Sexta- feira) | 13 | Exportação/migração da base de dados do Sistema Comercial para a nova solução/sistema; Alterações, atualizações, customizações, manutenções preventivas e corretivas, suporte e monitoramento; Avaliação e aceitação/homologação de resultados. |
FASE | RECURSOS | INÍCIO | TÉRMINO | TOTAL DE SEMANAS | OBSERVAÇÕES |
Treinamento de usuários | Licitante Vencedora; Profissionais da área de TI; Todas as áreas envolvidas. | Semana 10 (Segunda- feira) | Semana 13 (Sexta- feira) | 4 | Específico para cada usuário e para os profissionais da área de TI. |
Operação assistida/ "Mentoring" | Licitante Vencedora; Profissionais da área de TI; Todas as áreas envolvidas. | Semana 14 (Segunda- feira) | Semana 26 (Sexta- feira) | 13 | Treinamento dos profissionais da área de TI na solução/sistema, ferramentas, metodologias etc.; Alterações, atualizações, customizações, manutenções preventivas e corretivas, suporte e monitoramento; Avaliação e aceitação/homologação de resultados. |
Adequações e modelos evolutivos/ "Mentoring" | Licitante Vencedora; Profissionais da área de TI; Todas as áreas envolvidas. | Semana 27 (Segunda- feira) | Semana 104 (Sexta- feira) | 78 | Treinamento dos profissionais da área de TI na solução/sistema, ferramentas, metodologias etc.; Alterações, atualizações, customizações, manutenções preventivas e corretivas, suporte e monitoramento; Avaliação e aceitação/homologação de resultados. |
O treinamento deverá ser realizado nas dependências do Saae Sorocaba, portanto, local e presencial, ministrado por corpo técnico da licitante vencedora formado por um ou mais especialistas na solução/sistema ofertado(a), apresentar conteúdo programático adequado às necessidades específicas de cada usuário, de acordo com suas funções/atribuições no Saae Sorocaba e segundo as responsabilidades que deverão assumir
quanto ao uso da solução/sistema ofertado(a). Com base nos usuários a serem treinados (máximo de 200), informados pela autarquia à licitante vencedora, esta deverá efetuar levantamento por área e funções/atribuições, objetivando diagnosticar o grau de conhecimento em relação ao sistema operacional e à operação de microcomputadores, bem como direcionar o treinamento de forma a adequá-lo a cada função/atribuição do usuário.
Deverá ser ministrado treinamento específico e detalhado aos atendentes do Saae Sorocaba, especialmente sobre as funções de atendimento ao público, de acordo com suas respectivas funções/atribuições no contexto da solução/sistema, de forma que se tornem aptos a desempenhá-las auto suficientemente.
Para os profissionais da área de TI (máximo de dez), além do treinamento na completa operação/utilização da solução/sistema ofertado(a), a licitante vencedora deverá fornecer treinamento no ferramental tecnológico, metodologias, técnicas, características, métodos de construção da referida solução/sistema, enfim, tudo o que for necessário para abertura/acompanhamento/encerramento de solicitações – junto à licitante vencedora, visto que esta é proprietária da solução/sistema ofertado(a) – de adequações, alterações, atualizações, customizações, manutenções e evoluções sistêmicas.
Os treinamentos dos usuários operadores e administradores poderão ser realizados fora do horário de expediente, bem como aos finais de semana. Já os treinamentos dos profissionais da área de TI deverão ser realizados durante o expediente.
No início da fase de “Transição/Implantação”, a licitante vencedora deverá fornecer, no mínimo, cinco manuais sobre a solução/sistema ofertado(a), os quais conterão suas funcionalidades e características, descritas de forma detalhada.
No início de cada treinamento deverão ser fornecidas, também pela licitante vencedora, apostilas com o conteúdo programático a ser trabalhado, em número igual ou maior ao de pessoas a serem treinadas.
1.9.2 AVALIAÇÕES E ACEITAÇÕES/HOMOLOGAÇÕES DE RESULTADOS
As avaliações e aceitações/homologações de resultados e/ou da solução/sistema ofertado(a), bem como as avaliações e aceitações/homologações de atendimentos, adequações, alterações, atualizações, customizações, manutenções, evoluções etc. serão feitas pelos usuários-chave, não pelos profissionais da área de TI, os quais atuarão exclusivamente como facilitadores. Para tanto, por meio de amostragem estatística, ocorrerão vários ciclos de:
I. Exportação de dados e/ou informações do atual Sistema Comercial (ou da situação atual, em caso de atendimentos, adequações, alterações, atualizações, customizações, manutenções, evoluções etc.);
II. Importação, pela nova solução/sistema (ou da nova situação, em caso de atendimentos, adequações, alterações, atualizações, customizações, manutenções, evoluções etc.), do que foi exportado anteriormente;
III. Análise/comparativo de produtos/resultados entre o Sistema Comercial (ou da situação atual, em caso de atendimentos, adequações, alterações, atualizações, customizações, manutenções, evoluções etc.) e a nova solução/sistema (ou da nova situação, em caso de atendimentos, adequações, alterações, atualizações, customizações, manutenções, evoluções etc.);
IV. Produção de relatório de correções (se existirem);
V. Execução de correções (se existirem);
1.9.3 OPERAÇÃO ASSISTIDA/“MENTORING”
Assim como na “Transição/Implantação” e durante os treinamentos, também nesta fase um corpo técnico da licitante vencedora formado por um ou mais especialistas na solução ofertada deverá ser designado para atuar localmente/presencialmente nas unidades
do Saae Sorocaba, com o objetivo de prestar de todo o suporte necessário, orientação sistemática, acompanhamento e esclarecimento de dúvidas para os usuários/profissionais da área de TI sobre operacionalidade da solução ofertada, bem como a complementação dos conhecimentos dos profissionais da área de TI quanto ao ferramental tecnológico, metodologias, técnicas, características, métodos de construção da solução ofertada, enfim, tudo o que for necessário para abertura/acompanhamento/encerramento de contatos/chamados, pedidos, solicitações etc. – junto à licitante vencedora.
2 ASPECTOS TECNOLÓGICOS
2.1 DISPOSIÇÕES GERAIS
A solução/sistema ofertado(a), objeto deste Termo de Referência, deverá estar disponível no ambiente “web”, sendo hospedado (“hosting”). Para tanto, a licitante vencedora deverá escolher, negociar e contratar “Data Center”, sem custos adicionais e sem imposições de responsabilidades para o Saae Sorocaba, além de escolher, negociar e adquirir/contratar outros produtos/serviços que julgar necessários para atender o solicitado neste Termo de Referência, conquanto que não haja custos adicionais e nem imposições de responsabilidades para o Saae Sorocaba.
O “Data Center” que for escolhido/negociado/contratado pela licitante vencedora como componente para o atendimento deste Termo de Referência, deverá:
• Ser construído baseado na norma ANSI/TIA/EIA-942 (“Telecommunications Infrastructure Standard for Data Centers”);
• Possuir classificação Tier III com certificado ISAE3402, cuja comprovação, por documento(s), deverá ser apresentada no ato de assinatura do contrato;
• Utilizar equipamentos que permitam expansão do armazenamento de dados e aumento de desempenho, conforme for necessário para a autarquia;
• Oferecer solução na modalidade 24x7x365, com equipe compatível com a demanda deste Termo de Referência, através de gerenciamento e manutenção que contemple rotinas de “backup/restore” tanto das aplicações, quanto dos bancos de dados/base de dados. Em situações que demandem ações de “restore”, será aberto contato/chamado (vide subitem 1.6 acima), que será tratado como prioridade “0 – Inoperante” com prazo máximo de 30 minutos para atendimento e solução (“downtime” máximo de 30 minutos). Observação: ficará a cargo da licitante vencedora a utilização de redundância dos bancos de
dados/base de dados para minimizar/eliminar o tempo de restauração (“restore”) do estado de atividade destes bancos de dados/base de dados.
• Possuir indicador de disponibilidade dos serviços prestados, o qual deverá ser monitorado pela licitante vencedora e deverá atingir, no mínimo, 99,982% de disponibilidade com “downtime” anual máximo permitido de 1,6 hora (95 minutos). A licitante vencedora e/ou o “Data Center” contratado apresentarão ao Saae Sorocaba, sempre que solicitados, relatórios sobre este indicador de disponibilidade;
• Possuir vigilância eletrônica, modalidade 24x7x365, com câmeras, alarmes e controles de acessos, permitindo a identificação exata de todos os acessos físicos ao ambiente, incluindo o local de armazenamento de dados (bancos de dados/base de dados). Todos os dados e imagens gerados pelos sistemas de segurança devem estar disponíveis e arquivados historicamente, por um período de, no mínimo, 45 dias;
• Possuir, além da vigilância eletrônica, vigilância patrimonial na modalidade 24x7x365. Somente a entrada de pessoas autorizadas e devidamente identificadas e cadastradas deverá ser permitida no ambiente. Todos os dados/informações de segurança devem estar disponíveis e arquivados historicamente, por um período de, no mínimo, 45 dias;
• Ser equipado com sistema de climatização/refrigeração adequado e redundante;
• Possuir sistema e solução de combate a incêndio com sensores de fumaça e extintores de incêndio;
• Possuir infraestrutura de entrada de energia redundante com, pelo menos, dois ramais alimentadores. O “Data Center” deverá possuir, como contingência à infraestrutura de energia elétrica, grupo gerador e “nobreak”. Na falta de energia da companhia energética, o “nobreak” deverá assumir a alimentação dos
equipamentos do “Data Center” até que o grupo gerador entre em operação, garantindo o suprimento contínuo e ininterrupto de energia elétrica;
• Possuir sistema de energia totalmente gerenciado, com proteção contra qualquer anomalia de rede, além de aterramento;
• Rede elétrica estabilizada.
A licitante vencedora será responsável pelo “Data Center” escolhido/negociado/contratado por ela, bem como pelos outros produtos/serviços escolhidos/negociados/adquiridos/contratados por ela, os quais julgar necessários para atender o solicitado neste Termo de Referência. Consequentemente, também será responsável por:
• Manutenção/atualização do “Data Center”, de forma a cumprir os níveis de disponibilidade e desempenho exigidos neste Termos de Referência;
• Total segurança dos dados (base de dados) que serão armazenados no “Data Center”;
• Supervisionar o “Data Center”. Todas as anomalias ou incidentes deverão ser imediatamente informados ao Saae Sorocaba, especialmente à área de Tecnologia da Informação. O controle de acesso físico/lógico ao ambiente do “Data Center” será de responsabilidade da licitante vencedora, levando sempre em consideração que os dados/base de dados armazenados são confidenciais e de propriedade da autarquia a qualquer tempo;
• Realizar todos os esforços necessários visando proteger a integridade, confidencialidade e disponibilidade dos dados trafegados, desde que não impactem na solução/sistema e nem em seu desempenho (vide subitem 2.6 abaixo), e não conflitem com os bancos de dados/base de dados, “hardware”, “software” inerentes a esta solução/sistema;
• Realizar o controle e monitoramento de todos os acessos, solicitações, permissões e bloqueios, independente de onde foram emanados, enviando
relatórios ao Saae Sorocaba sobre estas operações, sempre que solicitados, incluindo endereço IP e “MAC Address” e em que data/hora as operações foram realizadas. Casos solicitados, os relatórios deverão estar disponíveis para a autarquia em, no máximo, 24h.
Toda a infraestrutura de servidores, sistemas de rede, armazenamento e todo o ambiente necessário para o funcionamento do solicitado neste Termo de Referência serão escolhidos, negociados, adquiridos/contratados e mantidos pela licitante vencedora, e serão utilizados pelo Saae Sorocaba durante toda a vigência deste contrato/projeto, sem nenhum custo para a autarquia, sendo estes recursos/produtos/serviços disponibilizados para uso pela autarquia conforme a demanda.
O Saae Sorocaba fornecerá exclusivamente estações de trabalho/microcomputadores (pertencentes ao patrimônio da autarquia), além de sistemas operacionais/“software” antivírus e conexão internet para estas estações/microcomputadores.
Nos locais onde estas estações de trabalho/microcomputadores (pertencentes ao patrimônio da autarquia) acessarão a solução/sistema ofertado(a), o Saae Sorocaba disponibilizará link/ponto de Internet com mínimo de 10 Mbps, sempre de acordo com a disponibilidade de serviços de internet ou cobertura de área.
O “Data Center” contratado deverá possibilitar o acesso dos usuários (internos e externos) e dos profissionais da área de TI, via Internet, a todas as funcionalidades da solução/sistema, de acordo com a permissão parametrizada de cada usuário, com toda a segurança necessária, de forma semelhante aos serviços ofertados pelos bancos na modalidade “internet banking”.
A licitante vencedora deverá garantir que a solução comporte todos os usuários (internos e externos) logados, além de todos profissionais da área de TI também logados, simultaneamente, além de cumprir os requisitos de desempenho estabelecidos no subitem
2.6 abaixo.
A solução ofertada não poderá conter conexões/transmissões sem fio (wireless) e/ou por satélite, salvo em situações excepcionais, as quais deverão ser conhecidas e autorizadas pelo Saae Sorocaba antes de ser utilizadas/aplicadas.
Todo o restante para o atendimento do solicitado neste Termo de Referência, incluindo “hardware” e/ou “software”, deverá estar incluso na proposta da licitante vencedora, isto é, deverá ser escolhido, negociado, adquirido/contratado por esta licitante, podendo tudo ser utilizado pelo Saae Sorocaba durante toda a vigência deste contrato/projeto, sem custos adicionais para a autarquia, em volumes, quantidades, números suficientes para atender a quatrocentos usuários operadores e/ou administradores, ou seja, internos do próprio Saae Sorocaba, os profissionais da área de TI e
𝑛 usuários externos, visto que não há condições de determinar quantas pessoas (munícipes)
acessarão os serviços disponíveis, via “web”, para a população, tais como a emissão de segundas vias, dentre outros ofertados atualmente ou que poderão vir a ser oferecidos pela autarquia. A escolha, negociações e forma de aquisição/contratação de “hardware” e licenças de uso de “software” – ou seja, se por usuário, por estação de trabalho/microcomputador, por servidor, por processador, por núcleo etc. –, bem como as versões e formas/programas de atualizações necessários (do “hardware” e do “software”), serão de inteira responsabilidade da licitante vencedora, sem custos adicionais para o Saae Sorocaba.
A solução/sistema deverá:
• Ser construído(a) para ser executado(a) em ambiente “web”, possibilitando ser utilizado(a) em estações de trabalho/microcomputadores em ambientes Windows (MS Windows 7 e 8), Linux e Mac;
• Estar preparado(a) para ambiente multiusuário, dotados de toda segurança que este ambiente exige (tratamento de transações);
• Possuir mecanismos de tratamento de senhas, os quais liberem ou restrinjam o acesso do usuário/profissional da área de TI em função do perfil administrativo ao qual pertence;
• Possuir mecanismos que permitam fazer atualizações (de responsabilidade exclusiva da licitante vencedora, por seu pessoal técnico) à medida que forem geradas novas versões/atualizações;
• Possuir um ambiente de homologação totalmente separado do ambiente de produção. Este ambiente será utilizado para a avaliação e aceitação/homologação de adequações, alterações, atualizações, customizações, manutenções, evoluções da solução/sistema ofertado(a), restaurações de backups (“restore” – simulações e/ou situações reais), e, somente após esta avaliação e aceitação/homologação, serão colocadas em produção. O ambiente buscará refletir a posição atual da base de dados real, de forma a maximizar a confiabilidade das homologações.
2.2 COMPATIBILIDADE COM NAVEGADORES
A solução/sistema deverá ser compatível com os navegadores Internet Explorer 8.0 e superiores, Google Chrome 20.0 e superiores, Mozilla Firefox 18.0 e superiores, além de navegadores usados em ambiente Linux e Mac.
Caso a licitante vencedora faça atualizações na solução/sistema e que eventualmente usem máquinas virtuais, interpretadores de qualquer espécie ou outros componentes, será necessário manter a compatibilidade com as versões anteriores ainda instaladas nas estações de trabalho/microcomputadores que façam uso da solução/sistema objeto deste Termo de Referência.
Caso estas estações de trabalho/microcomputadores recebam atualizações automáticas de máquinas virtuais, interpretadores de qualquer espécie, componentes, etc. e a referida solução/sistema não passar por essas mesmas atualizações, não poderá haver prejuízo nem na compatibilidade, nem no desempenho.
2.3 BANCO DE DADOS E FILE SYSTEM: LICENÇAS E ESPAÇO DE ARMAZENAMENTO
O(s) banco(s) de dados utilizado(s) deverá(ão) ser Oracle ou SQL Server (escolhido(s), negociado(s), adquirido(s)/contratado(s) pela licitante vencedora e sob sua inteira responsabilidade), com capacidade de armazenamento superior a 4 GBs (ou seja, não serão permitidas versões “express”), em sua(s) versão(ões) mais atual(is), devendo permitir atualizações (“upgrade”) para versão(ões) superior(es) sem perda de integridade, segurança, desempenho e disponibilidade.
2.4 GERENCIAMENTO DO SISTEMA OPERACIONAL
A gestão e manutenção do sistema operacional – que porventura for escolhido, negociado, adquirido/contratado pela licitante vencedora – serão de inteira responsabilidade da licitante vencedora e deverá contemplar:
• Controle de espaço em disco;
• Execução das rotinas de “backup/restore” do sistema operacional;
• Atualizações de segurança, de versão e demais patches que forem indicados pelo fabricante;
• Demais tarefas que sejam necessárias.
2.5 GERENCIAMENTO DO BANCO DE DADOS: DESEMPENHO E OUTRAS TAREFAS
Durante toda a vigência deste contrato/projeto, a licitante vencedora será responsável por todas as atualizações, manutenções e melhorias dos bancos de dados, os quais a solução/sistema objeto deste Termo fizer uso. Isto incluirá:
• Projetar e documentar a arquitetura da base de dados, realizar a modelagem de dados, o “data warehousing” e a plataforma de “business intelligence”;
• Criar e gerenciar os bancos de dados, controlar seus desempenhos (“analyse” e “tuning”), a alocação de espaços ocupados nos discos (“data sharing” e particionamento), bem como a demanda de recursos das estações de
trabalho/microcomputadores e servidores, sempre buscando o melhor desempenho;
• Criar e gerenciar tabelas, “procedures”, “views”, permissões, “triggers”, “scripts” para automação de tarefas, índices e outras particularidades inerentes a bancos de dados, sempre buscando o melhor desempenho;
• Ser responsável pelas operações de “backup/restore”, “clustering”, espelhamento e replicação de dados, bem como o registro de todas as operações (“log”) inerentes à solução/sistema objeto deste Termo de Referência;
• Elaborar, atualizar e manter a documentação técnica necessária para a operação e manutenção dos bancos de dados;
• Implementar segurança e criptografia nos bancos de dados;
• Atualizações de segurança, de versão e demais patches que forem indicados pelo fabricante;
• Política de arquivo morto:
a. A solução/sistema deverá permitir a geração de “arquivo morto”, que é a criação de tabelas que conterão os dados obsoletos de certo período, retirando-os das tabelas ativas e de uso contínuo, visando a melhorias de desempenho da solução/sistema como um todo;
b. Os dados destas tabelas de “arquivo morto” poderão ser acessados através do recurso de gerador de relatórios da solução/sistema.
• Avaliar e recomendar novas tecnologias de bancos de dados;
• Demais tarefas que sejam necessárias.
2.6 DESEMPENHO ESPERADO
A execução das tarefas da solução/sistema deverá seguir os seguintes tempos de resposta:
• Consultas e cadastros: 3 segundos ou menos em, pelo menos, 95% das operações;
• Relatórios: 10 segundos ou menos;
• Processamento de arquivos e geração de relatórios massivos: 10 minutos ou menos.
2.7 SENHAS DE ADMINISTRADORES
Usuários administradores e profissionais da área de TI deverão ter senha que permita acesso completo à solução/sistema.
2.8 CRIPTOGRAFIA
A comunicação entre o “Data Center” e as estações de trabalho/microcomputadores que acessarão a solução/sistema ofertado(a) deverá ser criptografada com o algoritmo mais seguro e irreversível quanto possível, de forma semelhante aos serviços ofertados pelos bancos na modalidade “Internet Banking”.
2.9 REGISTROS DE ACESSO E DE OPERAÇÕES
A solução/sistema deverá manter registros (“logs”) de acessos/operações de todos os usuários (internos e externos), profissionais da área de TI, indicando datas/horários de acessos, mudanças de senha, modificações de perfil, etc., além de outros dados e/ou informações relevantes para auditorias, administração de usuários/profissionais da área de TI e segurança da informação, como, por exemplo, o endereço IP e “MAC Address” da estação de trabalho/microcomputador que realizou o acesso/operação.
2.10 DOCUMENTAÇÃO
Toda a documentação da solução/sistema – incluindo regras de negócio implantadas, sejam as já existentes na solução/sistema ofertado(a) e as implantadas especificamente para o Saae Sorocaba – deverá ser entregue à autarquia como item integrante de:
• Avaliações e aceitações/homologações de resultados e/ou da solução/sistema ofertado(a) (vide subitem 1.9.2);
A forma de apresentação e padrão de documentação deverão seguir padrão de mercado.
A documentação deverá conter regras de negócio, indicações de atores, fluxo de dados, consistências, cálculos e todas as demais informações e diagramas que a autarquia julgar necessários para verificação de situações de uso padrão e anômalas da solução/sistema.
2.11 LINGUAGENS DE PROGRAMAÇÃO
As linguagens de programação da solução/sistema deverão ser Java e/ou Microsoft
.Net e/ou Delphi e/ou Oracle Forms/Reports, todas de extenso uso no mercado. Não serão permitidas outras linguagens diferentes das citadas. A solução/sistema deverá ser o(a) mais homogêneo(a) possível, evitando/minimizando o uso de diferentes linguagens de programação para a execução dos módulos/funcionalidades.
2.12 “FRAMEWORKS”, MÁQUINAS VIRTUAIS E COMPONENTES
Caso a solução/sistema necessite de “frameworks” e/ou máquinas virtuais e/ou componentes como Microsoft .Net, Java JRE ou outros, tudo deverá ser compatível com o
restante da solução/sistema, ou seja, deverá haver garantias plenas de operação/funcionamento com o que já estiver implantado.
2.13 EXECUTÁVEIS
A licitante vencedora deverá entregar todos os executáveis da solução/sistema no ato de assinatura do contrato, ficando excluída do processo licitatório a licitante que não assinar documento declarando conhecimento desta regra e comprometendo-se a fazê-la. Todas as aplicações que fazem parte do escopo deste Termo de Referência deverão ser documentadas e seguir melhores práticas de programação, a fim de facilitar futura manutenção. Os executáveis deverão ter alguma forma de controle de versão de fácil verificação.
2.14 CONSISTÊNCIAS E TRATAMENTO DE ERROS
A solução/sistema deverá ter consistências de entradas de dados que impeçam o usuário/profissional da área de TI de cadastrar dados inválidos, como, por exemplo, números em campos alfabéticos. As mensagens de erro deverão ser em português, sendo proibido o uso de mensagens de erros de bancos de dados ou sistemas operacionais sem tratamento prévio. Todas as situações de erro ou aviso da solução/sistema deverão ser amigáveis aos usuários finais e permitir a correta indicação de possível modo de resolução.
2.15 BACKUPS
A licitante vencedora será responsável pela realização, no Data Center, das operações de cópias de segurança (“backups”) de arquivos, bancos de dados/base de dados, softwares (sistemas operacionais – exceto aqueles que rodarão nas estações de trabalho/microcomputadores componentes do patrimônio da autarquia –, linguagens de programação, bibliotecas, componentes, ferramentas de construção/ferramental tecnológico, enfim, tudo o que for necessário para construção, programação, implementação, transição/implantação, utilização, além de adequações, alterações,
atualizações, customizações, manutenções e evoluções da solução/sistema ofertado(a)) inerentes à solução/sistema objeto deste Termo de Referência, mantendo sob sua responsabilidade a guarda destes “backups”.
De forma redundante, os “backups” serão realizados no Saae Sorocaba, sendo que a disponibilização e a manutenção do “software/hardware” de “backup” serão totalmente de responsabilidade da licitante vencedora durante toda a vigência deste contrato/projeto. Ao final deste, serão disponibilizados/repassados (licenças de uso de “software” e equipamentos/“hardware” utilizados para o “backup”) para esta autarquia sem custos adicionais.
A integridade, consistência e restauração (“restore” – simulações e/ou situações reais) dos dados armazenados deverão ser aferidas pela licitante vencedora, no máximo, a cada 30 dias, sendo obrigatório o envio imediato, para o Saae Sorocaba, de relatório das aferições/testes executados(as).
Quanto aos backups executados nesta autarquia, estes deverão ser realizados em horários pré-determinados pela área de TI, preferencialmente no período noturno e aos finais de semana, a fim de minimizar o impacto na conectividade.
As operações de cópias de segurança (“backups”) deverão atender à seguinte política:
• “Backups” diários: de segunda-feira à sexta-feira, com retenção de 6 dias;
• “Backups” semanais: aos domingos, excluindo-se o primeiro domingo do mês, com retenção de 15 dias;
• “Backups” mensais: no primeiro domingo do mês, com retenção de 30 dias.
3 CONTROLE DE ACESSO
3.1 USUÁRIO OPERADOR
Para acessar o sistema, o usuário operador necessitará ter seu cadastro previamente gerado por outro usuário com direitos administrativos (administrador). O usuário administrador criará o usuário operador, atribuindo-lhe permissões e funcionalidades do sistema, de acordo com o perfil da função que o usuário operador exercerá. O sistema deverá ofertar opções para diferenciar o usuário operador quanto a perfil e acessos (inclusão/alteração/consulta/exclusão – Crud).
3.2 USUÁRIO ADMINISTRADOR
Tipo de usuário que permitirá executar alterações que reflitam em outros usuários (administradores ou operadores). Possuirá como recursos: criação de acesso, criação de modelos de perfil, cópia de usuários (administradores ou operadores), atribuição do perfil de consulta ao usuário operador, definição da validade de senha de usuários (administradores ou operadores), definição dos parâmetros de formação de senha, dentre outros.
3.3 LOGIN
3.4 ACESSOS DOS USUÁRIOS
Para cada usuário operador, o sistema deverá permitir atribuir ou retirar acesso às funcionalidades (opções de menu), as quais estarão dispostas em grupos de trabalho. Adicionalmente, poderão ser estabelecidas ou revogadas permissões para trabalhar com Ordens de Serviço (OS) em departamentos, localidades ou setores especificados. Por exemplo, para os departamentos “A”, “B” e “C”, o usuário operador “U” terá permissão de emitir a OS; para a localidade “L”, este usuário terá as seguintes permissões: alteração de cadastro, alteração de fatura, dívida ativa, análise de leitura, isentar cobrança na emissão, autorização de religação e autorização de execução; já para os setores “D”, “E” e “F”, este usuário terá permissão para emitir certidão negativa de débitos.
Demais opções de acesso deverão ser elencadas, pela licitante vencedora, junto às diversas áreas do Saae Sorocaba, durante a fase de “Transição/Implantação” (vide subitem
1.9 acima), incluindo a parametrização de quais dias da semana e horários cada usuário poderá acessar o sistema.
3.5 PERFIS DE USUÁRIOS
Para agilizar a criação do usuário operador, o sistema deverá permitir a criação de perfis. Estes perfis conterão os acessos às funcionalidades e direitos do sistema definidos pelo usuário administrador.
Um perfil poderá ser criado com direitos apenas de consulta de registro no sistema, para que as funcionalidades atribuídas ao usuário operador deem acesso apenas à consulta.
3.6 CÓPIA DE USUÁRIOS
A partir de um usuário (administrador ou operador) já criado, o sistema deverá permitir a criação de um novo, solicitando dados básicos de cadastro para o novo usuário.
3.7 SITUAÇÃO DE ACESSO DO USUÁRIO
Determina o estado (ativo/inativo) do usuário (administrador ou operador) para dar acesso ou não ao sistema. Para facilitar o gerenciamento do sistema deverá existir uma opção com a lista de usuários e situações de acesso, a qual possibilitará ao usuário administrador habilitar ou desabilitar usuários de uma única vez.
3.8 CRIAÇÃO E VALIDAÇÃO DE SENHAS
O sistema deverá trabalhar o nível de segurança de acesso através de regras para senhas. Tais regras deverão abranger, no mínimo, as seguintes características: não permitir que o usuário operador mantenha a mesma senha atribuída pelo usuário administrador; permitir que o usuário administrador limite a quantidade mínima de caracteres; permitir que o usuário administrador solicite ao usuário, na criação da senha, misturar letras maiúsculas, minúsculas, números e caracteres especiais; permitir que o usuário administrador force a troca da senha pelo usuário operador após um determinado período (dias ou meses); exibir nível da senha à medida que está sendo digitada (fraca, normal, forte, muito forte).
Adicionalmente, o sistema deverá permitir que o próprio usuário (administrador ou operador) possa alterar a senha. Deverá existir opção para determinação de regras periódicas e de definição de senhas já utilizadas.
4 CADASTROS
4.1 LIGAÇÕES
O cadastro de ligações será o registro das ligações no sistema que identificarão o usuário responsável pela ocupação ou utilização de imóvel servido pelas redes públicas de água e/ou esgoto e/ou drenagem pluvial. Desta forma, o sistema deverá permitir criar uma nova ligação ou alterar a já existente.
Deverão ser permitidas alterações dos dados da ligação em determinados campos, necessitando ser fornecida permissão de acordo com o tipo de acesso do usuário, por exemplo:
• Usuários (administradores) do Setor de Atendimento: alterações de nome do munícipe, logradouro (roteiro), número e complemento de entrega;
• Usuários (administradores) do Setor de Receita: alterações da situação da ligação, tipo de faturamento, forma de cobrança, contato da ligação, tipo de categoria, número de economias e roteirização (leitura/entrega).
Através do número da ligação, o usuário (administrador ou operador) poderá registrar/consultar o histórico do atendimento, permitindo localizar dados, tais como quem foi o responsável pelo registro e quando ocorreu.
Deverá ser possível consultar as exceções atribuídas à ligação, o histórico das solicitações, o histórico de leituras, as faturas geradas e os acordos de parcelamento, cada um com o seu detalhamento necessário para o usuário (administrador ou operador) prestar o atendimento a determinado questionamento feito pelo cliente (munícipe).
4.2 LOCALIDADES (ZONA)
Permitirá o controle e acesso por localidade de todos os registros do sistema comercial. Cada localidade terá seu código e nome. Para todas as funcionalidades, o sistema
terá que identificar a localidade da ligação. Atualmente a autarquia utiliza apenas uma localidade – Sorocaba.
Dentro do cadastro de localidade haverá o cadastro de bairros, o qual permitirá fazer modificações (código e descrição do bairro) dos bairros dos logradouros das ligações (água/esgoto) associados à localidade.
Também no cadastro de localidade serão permitidas modificações dos logradouros das ligações, através do cadastro de logradouros. Alterando a descrição do logradouro no cadastro de localidades, esta descrição, no cadastro de ligações e roteiros, será automaticamente alterada.
4.3 CONTATOS
Funcionalidade que será utilizada para facilitar a pesquisa de uma determinada ligação através dos dados (documento ou nome) de seu requerente (contato). Identificará quais ligações um determinado contato possui. Ao gerar uma OS de ligação, deverá ser informado o nome do requerente, através do qual o sistema gerará um registro no cadastro de contatos.
4.4 CONTRATOS
Fará o controle de contratos entre a autarquia e o contratante (repartições públicas, imobiliárias, condomínios e outros), permitindo a emissão de uma conta única (agrupada) dos CDCs (Código de Consumidor), referentes às ligações de água e esgoto, vinculadas ao contrato.
Esse recurso permitirá ao contratante centralizar os vencimentos, a entrega e arrecadação das contas sob sua responsabilidade. Será necessário que o contratante determine um dia específico para o vencimento das contas (vencimento da conta única).
Para geração da conta única, devem-se levar em consideração as contas normais processadas e faturadas no mês de referência da conta única. A emissão da conta única
deverá ser realizada ao final do ciclo de faturamento, evitando que contas vinculadas ao contrato não sejam agregadas a conta única.
No cadastro do contrato será obrigatório o preenchimento dos dados de identificação (nome/razão social, tipo de documento, nº do documento), endereço de entrega das contas, condição do contrato, situação do contrato (ativo/inativo), dia do vencimento, retenção (rubrica e alíquota), além de permitir, através do nº da ligação, vincular a conta do munícipe ao cadastro do contratante.
4.5 MATERIAIS
O cadastro de materiais deverá armazenar os produtos utilizados na realização de um determinado serviço. Cada material terá um código, descrição, unidade de medida e valor unitário.
Para cada serviço realizado, deverá existir opção no sistema para que, antes da finalização do serviço, seja possível o lançamento de todos os materiais utilizados, os quais deverão ser registrados pelo usuário operador responsável pelo controle das Ordens de Serviço, durante a baixa de execução.
4.6 EQUIPES
O cadastro de equipes deverá armazenar os registros de quem executará um determinado serviço. Cada equipe terá um código, descrição, tipo (leiturista, cobrança, solicitação, fiscal), quantos servidores por equipe e carga horária diária máxima de trabalho por servidor.
Ao gerar uma nova programação de serviço, deverão ser informados os colaboradores que executarão as Ordens de Serviço disponibilizadas na programação gerada. Para tanto, deve-se indicar, em cada programação, uma equipe de servidores para realizar os serviços desta nova programação.
4.7 EXCEÇÕES
Funcionalidade que deverá permitir a criação de exceções em relação aos processos de faturamento da água/esgoto, cada exceção com critérios específicos quanto ao vencimento da fatura, ao volume a ser faturado e isenção de um determinado serviço. Deverão ser possíveis exceções de vencimento, de faturamento, esgoto especial, multa, percentual de esgoto, exceções de conversão e correção, e, como critérios, o tipo normal, isento de água e esgoto, isento de esgoto, faturar por até o limite, faturar apenas o excesso, faturar o volume limite, dentre outros. Todas as exceções pertencentes ao atual Sistema Comercial deverão ser importadas para o novo sistema.
Cada exceção conjugada ao critério produzirá efeitos para cada ligação, em relação ao que o sistema deverá fazer quanto ao faturamento da ligação de água/esgoto. Deverá tratar casos que permitirão, por exemplo: a alteração do vencimento determinado no cronograma para um vencimento escolhido pelo munícipe; que o volume a ser cobrado seja, no máximo, um valor a ser especificado na regra para o período determinado; que o munícipe obtenha a isenção de água e esgoto ou apenas esgoto, dentre outras situações.
As exceções poderão ser aplicadas em casos que houver um acordo, ajuste ou correção na leitura.
5 PROCESSOS
5.1 ROTEIROS
Para cada logradouro haverá um ou mais roteiros (leitura/entrega) de faturamento. O roteiro será informado no cadastro da ligação de água/esgoto, permitirá a definição de frequências de leituras (mensal/bimestral/trimestral), e será composto por setores subdivididos em grupo e rota. A rota, por sua vez, subdivide-se em quadra (trecho), face, e estará atrelada a um bairro e logradouro. Alterada a descrição do logradouro na localidade, a descrição do logradouro no roteiro deverá ser alterada automaticamente. É através dessa funcionalidade que será realizada a manutenção (incluir/alterar/excluir) dos roteiros.
5.2 SETORES
Permitirá o controle das ligações por região. Atribuído na identificação de cada serviço gerado (ligação de água, esgoto, dentre outros), o setor será criado associado à localidade, sendo de grande importância durante o estabelecimento dos roteiros de faturamento de cada ligação.
5.3 CATEGORIAS
No cadastro da ligação deverá ser informada uma categoria, ou seja, através do tipo de estabelecimento existente/a ser construído no logradouro da ligação, será determinada a classificação do tipo de consumo a ser utilizado. Haverá cinco categorias: residencial, comercial, industrial, pública e associações. Para cada tipo haverá uma tabela diferente de valores por metro cúbico, a qual será utilizada para efetuar o cálculo do valor a ser cobrado pelo que foi consumido (água/esgoto).
Para cada categoria deverá existir um código e respectiva descrição no cadastro, e a esse código poderão ser associados planos de utilização. Cada plano de utilização possuirá um tipo (tarifário, vazão e utilização, através do qual será possível o cálculo da fatura),
volume por economia mínimo e inicial, forma de cobrança de imposto (calculado/isento/tarifário), além de determinar se o plano a ser utilizado deverá dividir o montante de volume faturado por economia, cobrar pela economia principal, cobrar tudo por uma economia com tarifas diferenciadas, ou seja, o sistema deverá prover possibilidades de parametrização para o trato de situações em que haja economias múltiplas.
5.4 DEPARTAMENTOS
Funcionalidade a ser utilizada para a criação e manutenção de registros dos departamentos com seus respectivos códigos e descrições. No cadastro de departamentos poderão ser armazenadas observações, número do telefone e tipos de Ordens de Serviço que o departamento poderá emitir. Adicionalmente, o sistema deverá registrar/controlar as programações e trâmites das execuções de todas as Ordens de Serviço.
5.5 COLABORADORES
O cadastro de colaboradores deverá armazenar os nomes das pessoas que realizarão os trabalhos. Cada colaborador terá um código, nome completo, nome resumido, tipo da jornada de trabalho (normal ou plantão), tipo de equipe que estará vinculado (leitura, cobrança, fiscal ou solicitação), além do status de ativo ou inativo. Antes da finalização de um serviço, o sistema deverá permitir lançar o responsável pela equipe (colaborador/monitor), registrando a data da execução, horário inicial e final da realização do serviço.
6 AUDITORIA
6.1 REGISTROS DE USUÁRIOS
O sistema deverá manter registros (“logs”) de acessos/operações de todos os usuários, indicando datas de último acesso (“logon”), mudanças de senha, modificações de perfil e outras informações relevantes para a administração de usuários e segurança de informação, como, por exemplo, o endereço IP e “MAC Address” da máquina acessada (logada).
6.2 TAREFAS EXECUTADAS POR USUÁRIO
Todas as tarefas executadas pelo usuário (administrador ou operador), consideradas sensíveis, como, por exemplo, recálculo de contas, estorno de pagamentos, pedidos de ligação, deverão ser mantidas em “logs” e passíveis de verificação e auditoria. Para cada operação, será necessário registrar a hora em que ocorreu, usuário (administrador ou operador) logado, endereço IP e “MAC Address” da estação de trabalho/microcomputador, atividades executadas, informações sobre a ligação, fatura ou OS manipulada. Todos dados componentes do “log” do atual Sistema Comercial deverão ser importados, e o projeto de “log” do novo sistema deverá conter, pelo menos, estes os dados componentes atualmente. Durante a fase de “Transição/Implantação” (vide subitem 1.9 acima), a licitante vencedora deverá analisar estes dados e discutir com os usuários do sistema as reais necessidades de “log”, a fim de manter, inclusive, a saúde do banco de dados e o desempenho das verificações.
6.3 CAÇA FRAUDE
O sistema deverá ter uma forma de verificação de ações suspeitas executadas pelos usuários (administradores ou operadores), como, por exemplo, um mesmo usuário (administrador ou operador) recalculando sempre a mesma ligação, nomes de responsáveis
por ligações similares aos dos usuários (administradores ou operadores), excesso de permissões, como, por exemplo, um mesmo usuário (administrador ou operador) podendo gerar faturas e estorná-las). A licitante vencedora deverá indicar todas as funcionalidades de seu sistema proposto quanto a verificações de acessos de usuário e operações críticas.
7 PROJEÇÕES GERENCIAIS
7.1 LEGADO
As projeções gerenciais servirão para verificar, através de dados históricos de leitura e faturamento, qual o impacto no faturamento decorrente de variações dos custos das tarifas (simulação de cenários). O atual Sistema Comercial contém projeções dos anos anteriores, que serviram para estudos de redistribuição de tarifas, e, desta forma, o sistema deverá manter os resultados das projeções anteriores, em banco de dados, para futura referência.
7.2 ENTRADA DE VALORES PARA VERIFICAÇÃO
O sistema deverá permitir a comparação entre tarifas já existentes, utilizadas em outros exercícios pela Autarquia, bem como a entrada de conjunto de tarifas simuladas para comparação. Os valores simulados deverão ser guardados para reutilização, caso necessário.
O cadastro deverá ser feito de forma intuitiva, diretamente por interface pelo sistema, e através de modelo de planilha e arquivo texto, a ser escolhido pelo usuário (administrador ou operador). Todos os dados necessários para a simulação de faturamento devem ser cadastrados, como tarifa mínima, faixa de consumo, porcentagem de esgoto, bem como quaisquer outros dados necessários para simular com precisão o faturamento mensal.
7.3 EXECUÇÃO DE COMPARAÇÃO ENTRE FAIXAS DE TARIFAS
Após a entrada dos dados, o sistema deverá permitir de forma intuitiva o começo da simulação, possibilitando a escolha de um mês de referência como base da comparação, o conjunto de valores iniciais de referência e o conjunto de valores simulados, categoria desejada e forma de cálculo (a qual será a mesma da fatura final, com todas suas regras de economias e distribuição). O sistema deverá permitir a escolha da forma de cálculo para
comparação, seja cascata ou linear, mas sempre a partir do volume medido real, transformando em faturado da mesma maneira que o sistema de geração de faturas faz.
Os resultados da simulação deverão ser apresentados de forma gráfica e textual/tabular (analítica), demostrando todos os enquadramentos nas faixas de valor, divididos pelas categorias das ligações e enquadramentos. Após a execução da simulação, a qual não deverá durar mais do que dez minutos, os resultados deverão ser mantidos para futuro uso, através de interface própria.
Maiores detalhes sobre o modo de operação, bem como exemplos dos resultados esperados, além de “layouts” de telas e relatórios, deverão ser analisados pela licitante vencedora durante a fase de “Transição/Implantação” (vide subitem 1.9 acima) do sistema proposto.
7.4 CATEGORIZAÇÃO E ESTATÍSTICAS DAS TARIFAS
Os resultados das projeções deverão estar disponíveis em formas agregadas (sintéticas) ou analíticas. Formas de verificação financeiras de situações específicas deverão ser permitidas, como, por exemplo, as seguintes, mas não limitadas a:
• Ligações faturadas pelo mínimo;
• Quantidade de ligações enquadradas em cada faixa de consumo;
• Quantidade de ligações categorizadas como industriais, residenciais, prédios públicos, ou qualquer outra categoria cadastrada no sistema.
O sistema deverá apresentar cálculos de variação dos resultados, tomando por base os parâmetros decididos pelo usuário (administrador ou operador) antes da execução.
7.5 PROJEÇÕES TARIFÁRIAS
As projeções tarifárias deverão ficar armazenadas como histórico, e permitir verificações a qualquer momento sem a necessidade de novo processamento de faturamento. As tarifas utilizadas deverão estar explícitas, e, caso haja a necessidade de
pequenas alterações para ajuste fino, o sistema deverá processar apenas as faixas impactadas.
As regras para cálculo deverão ser idênticas às regras de faturamento, inclusive verificando possíveis erros de leitura e ocorrências. Caso haja a simulação de uma tarifa real, o sistema deverá prover o mesmo resultado do módulo de faturamento daquele mês. As tarifas de esgoto também deverão ser calculadas conforme o cadastro (existência ou não de ligação de esgoto) e deverão permitir análise em separado, caso necessário.
7.6 HISTOGRAMA POR CATEGORIA, FAIXAS, GRUPOS, TIPOS DE CONSUMO
Os resultados deverão ser apresentados na forma de relatório, em diversos níveis de granularidade, e passíveis de exportação para os formatos comerciais mais utilizados, como planilhas eletrônicas (XLS e/ou XLSX) e arquivos texto (TXT), facilitando a manipulação das informações fora do sistema.
De forma gráfica, o sistema deverá comportar um histograma das leituras e valores, parametrizável pelos usuários. O histograma deverá apresentar as faixas de valores (classes estatísticas) e respectivas quantidades de ligações, além de quaisquer outras informações pertinentes ao relatório, as quais deverão ser detalhadas durante a fase de “Transição/Implantação” (vide subitem 1.9 acima). Da mesma similar à anterior, os gráficos gerados deverão ser exportáveis para os formatos comerciais mais utilizados, como imagens (BMP e/ou JPG), planilhas eletrônicas (XLS e/ou XLSX) e arquivos texto (TXT).
8 LIGAÇÕES DE ÁGUA E ESGOTO
8.1 DADOS CADASTRAIS NECESSÁRIOS
No momento em que o munícipe fizer a solicitação de uma ligação (água/esgoto), deverá ser garantido que o sistema conterá dados necessários, visando a facilitar a execução de serviços para qualquer tipo de ligação a ser realizada. Por exemplo, dentre outros dados, tem-se: nome do munícipe, identidade e/ou CPF, telefone de contato, local de execução da ligação, nome do requerente e inscrição municipal.
O nome do munícipe será a identificação da ligação na maioria das funcionalidades do sistema. O telefone de contato poderá ser o telefone do munícipe ou do requerente. O local de execução da ligação será composto por logradouro, número, complemento, bairro, setor e localidade. Ao informar o logradouro, o sistema permitirá a busca por sua descrição, pois deverá estar previamente associado a um setor. O nome do requerente deverá ser preenchido inicialmente com o mesmo nome do munícipe.
Toda ligação conterá dados que, ao longo da realização do serviço, serão modificados, tais como: situação (ativa, cortada, inativa, provisória), tipo da ligação (consumo fixo, hidrometrado), faturamento (água, água e esgoto, Tarifa de Esgoto Especial – TEE), forma de cobrança (normal, débito em conta corrente, enviada ao banco) e utilização (residencial, comercial, conjunto residencial, conjunto comercial, prédio público, conjunto prisional).
8.2 PAGAMENTO DE BOLETOS E LIBERAÇÃO DE INSTALAÇÃO
Na solicitação da ligação, o sistema deverá fornecer informações suficientes para que o usuário operador possa esclarecer ao munícipe, de acordo com cada tipo de ligação, quais os serviços a serem envolvidos e cobrados para a realização da instalação. Nesse momento, o sistema permitirá registrar serviços a serem executados, e emitirá boletos bancários.
Mediante a realização do pagamento, e posterior comprovação, pelo sistema, da quitação dos boletos, o sistema fará a liberação para a instalação da ligação solicitada pelo munícipe.
8.3 ROTEIRIZAÇÃO
O Setor de Controle e Receita realizará o processo de roteirização, isto é, associará à ligação um roteiro previamente cadastrado no sistema, e deixará a ligação pronta para leitura e faturamento.
Na roteirização, o usuário operador, responsável pela inclusão do roteiro, determinará uma sequência de leitura no cadastro de ligação por meio de um código, o qual será baseado em roteirizações anteriormente associadas a logradouros próximos à ligação, assim como pela quadra e lote do local da ligação. Também será informado na roteirização o complemento, de forma a diferenciar o roteiro de ligações do mesmo logradouro.
A roteirização determinará o número de inscrição cadastral da ligação, composto pelos campos da roteirização e dígito verificador, determinado por cálculo através do uso dos módulos 10 e 11 (módulo 10 para o primeiro dígito e módulo 11 para o segundo).
8.4 GERAÇÃO DAS ORDENS DE SERVIÇO
O sistema deverá permitir registrar e controlar as solicitações de serviços relacionadas à água e esgoto, tanto de ligação como manutenção. Para cada Ordem de Serviço, deverá estar associado um tipo de solicitação de serviço.
Toda solicitação de serviço será registrada no sistema a partir da confirmação dada pelo munícipe ou representante legal. Somente mediante a apresentação de documentos que comprovem a solicitação é que será confirmado pelo Setor de Atendimento o cadastro da Ordem de Serviço.
A OS deverá ser alimentada com os dados cadastrais necessários do munícipe e o tipo de solicitação de serviço. Assim, será possível saber para qual área (água ou esgoto) será atribuída a OS, informação que deverá ser exibida na tela de geração da Ordem de Serviço.
Para gerar a OS de ligação, à mesma deverá ser vinculado um Cadastro de Consumidor (CDC); a esse CDC serão associados os tipos de serviço: água, água e esgoto, TEE, água e TEE, água e esgoto e TEE. Para ligação de água, a OS somente poderá ser gerada e registrada no sistema, após confirmar autorização por usuário operador com direitos para liberar a geração do cadastro de ligação provisória, o qual fará uso dos mesmos dados da OS de ligação. Em casos específicos (exclusivamente de ligação de esgoto, como por exemplo, uma ligação de esgoto independente, que não terá a geração de CDC pela ligação de água; também poderá ocorrer no caso de poço e TEE), poderá ser feito primeiramente o cadastro manual da ligação, a geração da OS e, posteriormente, a vinculação da OS com o CDC.
Para evitar a geração de mais de uma OS, com o mesmo tipo de solicitação (por exemplo, vazamento), para o mesmo local (mesma inscrição municipal ou mesmo CDC), será necessária a consistência desse tipo de situação, onde o sistema deverá informar que existe OS pendente aguardando a finalização de execução, e em que ponto do processo a OS se encontra.
8.5 CONTROLE DA ATIVAÇÃO DAS NOVAS LIGAÇÕES
Efetuada a execução do serviço de ligação de água pela equipe de campo, serão feitas anotações na Ordem de Serviço sobre todos os dados da ligação. A equipe responsável pelo lançamento fará o registro no sistema do número do hidrômetro e de demais dados constantes na OS. Portanto, o sistema deverá permitir a parametrização do “workflow” da OS por usuário (administrador ou operador) com autorização específica (perfil/direitos de acesso) para tal, possibilitando o cadastro e a manutenção de quais áreas a Ordem de Serviço percorrerá, bem como quais dados/informações deverão ser apresentados/preenchidos em cada área.
Finalizados todos os trabalhos em campo, incluindo reparos e pavimentos, casos necessários, a Ordem de Serviço deverá ser encerrada no sistema por meio da alteração de sua situação para “executada”.
O sistema deverá, através de relatórios ou consultas em telas, apresentar a situação das ordens de serviço por área e equipe, de maneira a acompanhá-las para detectar atrasos e anomalias nas execuções dos trabalhos, permitindo controlar efetivamente cada Ordem de Serviço.
A ativação da ligação será realizada pela área que encerrou a OS. Esta funcionalidade deverá ser parametrizada dentro do “workflow” de ligação de água, obedecendo às autorizações específicas (perfil/direitos de acesso) de cada usuário (administrador ou operador), o qual modificará a ligação de “provisória” para “ativa”. O tipo de utilização deverá ser confirmado, assim como o tipo de faturamento, a quantidade de economias, e o tipo de ligação será transformado de “consumo fixo” para “hidrometrado”.
8.6 TIPOS DE LIGAÇÃO: HIDROMETRADAS E CONSUMO FIXO
Confirmada a instalação do hidrômetro, deverá ser alterado o campo número de medidor na OS de ligação de água. Na sequência, deverá ser modificado o tipo de ligação de “consumo fixo” para “hidrometrada”. Sendo assim, quando o usuário operador necessitar alterar dados de uma Ordem de Serviço de esgoto, e já houver uma ligação de água para o mesmo CDC, o tipo desta última deverá estar como “hidrometrada”.
8.7 TIPOS DE FATURAMENTO ESPECIAIS
Atualmente, a autarquia possui cinco tipos de categoria. Se uma ligação é servida apenas de água, o faturamento será sobre o volume medido. Em casos onde há água e esgoto, o Sistema Comercial atual realiza cálculo referente à porcentagem do esgoto. Há casos onde há apenas esgoto, com tarifa fixa, que é a TEE. Desta maneira, cada tipo de categoria de faturamento implica numa regra diferente para o cálculo do valor final da conta mensal.
O sistema deverá manter as categorias existentes no atual regulamento do Saae Sorocaba, ser compatível com as regras de negócio sobre o assunto, e permitir a parametrização das categorias de faturamento em casos de mudanças de regulamento.
Maiores detalhes sobre o modo de operação deverão ser analisados pela licitante vencedora durante a fase de “Transição/Implantação” (vide subitem 1.9 acima) do sistema proposto.
8.8 REDES DE ÁGUA INDIVIDUALIZADA: CADASTRAMENTO DE HIDRÔMETRO MASTER E DEPENDENTE
8.9 ECONOMIAS
De acordo com regulamento do Saae Sorocaba, economia é toda subdivisão de um imóvel ou condomínio, isto é, uma forma de rateio de volume faturado. Pelo mesmo regulamento, quando o imóvel for constituído de várias economias, abastecido por uma única ligação de água e servido por uma única ligação de esgoto, o consumo mensal apurado será rateado pelo número de economias componentes do imóvel, para, dentro da faixa de consumo e da classificação em que as economias se enquadrarem, permitir o cálculo da tarifa devida, que será lançada através de conta única.
O Sistema Comercial atual indica quando há modificações no número de economias. Desta forma, o sistema deverá controlar alterações cadastrais do número de economias, já
que isto impacta diretamente no resultado do faturamento final, além possibilitar fraudes. Trata-se de operação cuja execução somente será permitida por usuário (administrador ou operador) com autorização específica para tal. Adicionalmente, o sistema deverá registrar (“log”) todos os dados necessários para efeitos de auditoria.
Maiores detalhes sobre o cálculo de faturas envolvendo economias são descritos no subitem 14.7 abaixo.
9 HIDROMETRIA
9.1 CADASTRO DE HIDRÔMETROS
O sistema deverá manter cadastro de todos os hidrômetros atuais e já retirados, permitindo a parametrização de códigos diferenciados de hidrômetro por tipo de hidrômetro, classe, quantidade de ponteiros, vazão mínima e máxima, unijato ou multijato, mecânico ou magnético, classe de vazão, data de fabricação, data de aferição, data de aquisição e quaisquer outros dados que o Saae Sorocaba necessitar para a diferenciação e planejamento do ciclo de vida dos hidrômetros.
9.2 LEGADO DOS DADOS EXISTENTES: HIDRÔMETROS, LOCALIZAÇÃO, ESTADO, FABRICANTES, MODELOS
Todos os dados existentes no banco da autarquia, a respeito dos hidrômetros, deverão ser importados para a base do sistema ofertado. Estes dados compreendem todo o ciclo de vida do hidrômetro, tais como as ligações (CDCs) a que pertenceu, se houve alguma manutenção, os cadastros de todos os códigos de fabricantes e modelos existentes atualmente, cadastro de lote de aquisição, dentre outros. A partir de qualquer ligação deverá ser possível verificar todos os dados dos hidrômetros da referida ligação, incluindo eventuais ocorrências de leitura (hidrômetro parado, por exemplo).
9.3 DADOS CADASTRAIS: LIGAÇÃO, SITUAÇÃO
As telas de dados dos hidrômetros deverão conter, ao menos, a situação de instalação (instalado, manutenção, estoque, descartado). Se instalado, deverá ter o número da ligação e acesso direto aos dados de instalação do referido hidrômetro; se em manutenção, o histórico de qual ligação foi retirado, a data de retirada, por qual servidor/terceiro, a empresa responsável pela manutenção e campos digitáveis para observações; se em estoque, deverá ficar disponível para a instalação em uma nova ligação ou para substituição em uma ligação já existente (hidrômetro anteriormente instalado); se descartado, deverá ficar indisponível para qualquer operação.
O histórico de manutenção deverá se manter independentemente do status atual. Um hidrômetro instalado, em manutenção ou em estoque poderá ir para qualquer um dos outros status, mas um descartado não poderá ser recolocado em uso.
9.4 CONTROLE DE SITUAÇÃO DE INSTALAÇÃO
9.5 CADASTRO EM LOTE
O sistema deverá permitir o cadastro de lotes de hidrômetros, com entrada de faixa de códigos a ser utilizados. No momento do cadastro, deverão ser preenchidos dados referentes ao tipo, modelo, data de aquisição, número de nota fiscal, data de aferição, empresa aferidora, bem como demais dados relevantes. O sistema controlará de forma
9.6 INFORMAÇÕES DE AFERIÇÃO: DADOS E FOTOS
Quando houver pedido de aferição do hidrômetro, tanto por parte da autarquia quanto de munícipe, o sistema deverá manter e apresentar, em tela apartada, o histórico das aferições, incluindo resultados, em formato parametrizável, seguindo as normas ABNT, datas de aferições, resultados e quaisquer informações relevantes para possíveis processos administrativos. O sistema deverá conter, em base de arquivos ou banco de dados próprios, repositório de fotos das aferições e ocorrências, tais como: hidrômetro quebrado, embaçado, dentre outras. As fotos serão anexadas pelo sistema, que deverá processá- las/tratá-las para manter boa qualidade, mas de tamanho compatível com o repositório.
9.7 INSTALAÇÃO DE HIDRÔMETROS E ATIVAÇÃO DE LIGAÇÃO
A ativação de uma ligação poderá ocorrer tanto com consumo fixo ou hidrometrado. No caso de hidrometrado, o usuário (administrador ou operador), antes de ativar a ligação, deverá procurar o número do hidrômetro instalado fisicamente na ligação numa relação de hidrômetros em estoque.
Em caso de troca de hidrômetro, o anterior poderá ir para estoque, manutenção ou descarte. O sistema possibilitará a escolha do status.
Uma vez instalado o hidrômetro, a ligação ficará disponível para o próximo ciclo de leitura. O sistema deverá, durante a instalação do hidrômetro, verificar se a ligação está ativa e, caso negativo, perguntar ao usuário (administrador ou operador) se deseja ativá-la.
9.8 VALIDAÇÕES COM O CRONOGRAMA DE LEITURA
A instalação dos hidrômetros, em caso de ligações já existentes, deverá ter uma série de sincronizações com o cronograma de leitura/faturamento, de forma a evitar erros de faturamento para mais ou para menos, como, por exemplo, causados por leitura de hidrômetro antigo considerado como novo.
A licitante vencedora deverá explicitar em documentação sua forma de tratamento, pelo menos, para os seguintes casos:
• Cadastro de hidrômetro antes do começo do ciclo de leitura;
• Durante o ciclo com o leiturista verificando o hidrômetro antes da troca;
• Durante o ciclo com o leiturista verificando o hidrômetro após a troca;
• Após o término da leitura, mas antes do faturamento.
O Saae Sorocaba avaliará durante a fase de “Transição/Implantação” (vide subitem
1.9 acima) a forma de trabalho do sistema proposto e pedirá adequações caso necessário.
O rol de situações apresentados é apenas enumerativo e não taxativo, estando livre o Saae Sorocaba para elencar ou abordar outros cenários.
9.9 POSSIBILIDADE DE ENTRADA DE DADOS VIA LEITOR DE CÓDIGO DE BARRAS
Quando da instalação do hidrômetro em uma ligação, por praxe, o instalador cola o código de barras com número do hidrômetro na Ordem de Serviço. Assim, o sistema deverá ser capaz de reconhecer, através de um leitor de código de barras padrão, o número de chassis do hidrômetro, ativar a tela de informações e permitir o cadastro na ligação deste número.
9.10 TRATAMENTO DE ERROS DE INSTALAÇÃO DE LIGAÇÕES
O sistema deverá possibilitar que os erros humanos de operação possam ser corrigidos sem intervenções em banco de dados e ainda sem necessitar de alterações de
software, ou seja, programação, compilação etc.; também não deverá ser necessário aguardar ciclos de leitura adicionais ou manter-se a ligação em consumo fixo. Como exemplo de erro de operação tem-se o cadastro de hidrômetro equivocado em uma ligação, ou ainda, a troca cruzada de hidrômetros, ou seja, quando se cadastra o hidrômetro de uma casa em outra, e vice-versa, tipicamente em casas vizinhas. Outros tipos de erro de operação a serem tratados poderão ser especificados pelo Saae Sorocaba durante a fase de “Transição/Implantação” (vide subitem 1.9 acima), e a licitante vencedora deverá explicitar como o sistema proposto gerenciará/controlará todas as situações (tanto as levantadas pela autarquia como as citadas pela licitante vencedora), ainda durante a referida fase, incluindo como estes casos serão tratados em termos de procedimentos e possíveis consequências.
9.11 ALERTA DE HIDRÔMETROS FORA DA VALIDADE
Por determinação do Inmetro, a validade de aferição de um hidrômetro é de cinco anos. O sistema deverá prover alerta na iminência de final de validades de hidrômetros instalados, gerando Ordens de Serviço automaticamente para o grupo responsável pela troca dos hidrômetros. O sistema apresentará, em forma gráfica, de maneira clara, a quantidade de trocas necessárias em períodos futuros, para planejamento de aquisição de material, bem como indicadores claros de acompanhamento das ordens de serviço de trocas já emitidas.
10 ATENDIMENTO
10.1 FLUXO DE ATENDIMENTO: PRÉ-ATENDIMENTO E ATENDIMENTO PRESENCIAL
O sistema deverá permitir registros de atendimento, a partir do primeiro contato do munícipe no balcão de pré-atendimento, até a finalização do atendimento por um atendente.
Os atendimentos presenciais ocorrem na Unidade Central e nas Casas do Cidadão, que deverão ter acesso ao mesmo sistema e com as mesmas informações, através de conexão Internet. O sistema deverá possuir um módulo de controle/emissão/chamada de senhas, levando em conta cada Unidade/Casa do Cidadão como uma fila em separado, com controle individual de cada uma delas. Adicionalmente, o sistema deverá apresentar o controle/emissão/chamada de senhas em TV/monitor (VGA ou HDMI) e sistema de áudio com caixas acústicas, permitindo a apresentação simultânea, nos mesmos equipamentos (TV/monitor e sistema de áudio com caixas acústicas), de vídeos institucionais, notícias gerais, mensagens de texto, bem como qualquer outro conteúdo e/ou programa que a autarquia julgar necessário. A disposição/tamanho/forma do conteúdo apresentado dependerá de avaliação e aceite por parte da autarquia. Para maiores esclarecimentos, o atual sistema de controle/emissão/chamada de senhas está disponível como base ou exemplo do que é necessário para o Saae Sorocaba.
O balcão de pré-atendimento servirá como triagem, tentando resolver a questão do munícipe sem a necessidade de se pegar uma senha. A partir do momento em que o munícipe se dirigir ao balcão de atendimento, o sistema deverá abrir uma ficha de atendimento eletrônica, que constará dados básicos, como: número da ligação (se o munícipe a possuir), identificação do munícipe, assunto a ser tratado e demais dados relevantes para o atendimento. Cada atendimento deverá ter um número identificador único, e o sistema deverá contar o tempo de atendimento para efeitos de indicadores.
Durante o pré-atendimento, o atendente (usuário operador) fará consultas ao sistema e verificará a possibilidade de resolver a questão do munícipe em balcão. Se não for possível, o atendente (usuário operador) fará uma descrição sucinta da necessidade do munícipe em campo próprio, gerará uma senha para o munícipe e cadastrará essa senha no sistema, passando a mesma para uma fila, visualizável em forma gráfica, com todos os atendimentos a serem realizados. Após, o atendente das mesas (usuário operador) deverá clicar no ícone de fila da senha, chamando o munícipe que fora pré-atendido no balcão. Desta forma, o sistema deverá reconhecer três períodos distintos de tempo para indicadores: o pré-atendimento no balcão; o período que o munícipe ficará sentado aguardando até ser atendido na mesa; e o período de atendimento propriamente dito.
O sistema deverá manter registro de todos os assuntos tratados durante uma mesma sessão de atendimento. Por exemplo, para uma solicitação de ligação de água em conjunto com um pedido de revisão de conta, o sistema deverá permitir a indicação de que houve mais de uma ocorrência, durante o mesmo atendimento, em campo próprio, e não em um campo de texto ou “memo”, pois deverá ser possível gerar relatório de tempo de atendimento por assunto.
10.2 ATENDIMENTO TELEFÔNICO – 0800
O Saae Sorocaba dispõe de atendimento aos munícipes em formato 0800. Em geral, esse atendimento é utilizado para a abertura de chamados de emergência, como por exemplo: vazamentos de água e esgoto e falta de água. Apesar disso, o atendimento telefônico é considerado forma diversa, mas atuante do atendimento normal.
O sistema proposto deverá ter uma forma de controle e registro dessas ligações. Os tempos, para efeito de indicadores, deverão ser tratados da mesma forma que o atendimento presencial, com a ressalva de que pertencerão ao atendimento telefônico. As informações acessadas pelos atendentes deverão ser as mesmas, excetuando-se o fato de que não haverá controle/emissão/chamada de senhas.
As informações passadas pelos atendentes aos munícipes deverão ser registradas em campos próprios, e, caso necessário, o atendente poderá interromper a ligação para verificar alguma informação e retornar ao munícipe. O tempo dessa operação deverá ser indicado como tempo de retorno.
A chave primária para o atendimento será o número da ligação (CDC), mas o sistema deverá indicar, por meio de outras informações como nome de quem está ligando, número de CPF ou RG, endereço do local ou telefone de contato, se houve contatos anteriores, histórico de chamadas e atendimentos presenciais.
10.3 INFORMAÇÕES A MUNÍCIPES
O sistema deverá dispor de um catálogo de informações sobre procedimentos referentes a atendimento aos munícipes. Por exemplo, caso um munícipe venha a pedir uma ligação de água, o sistema deverá prover um “checklist” ao atendente com todos os documentos e informações necessários. Esse “checklist” deverá ser marcável, indicando a apresentação, ou não, de documentos e/ou requisitos para o desdobramento da solicitação do munícipe. O sistema deverá manter em “log” o avanço, ou não, do passo a passo do atendimento, bem como todos seus dados componentes, para fins de futura auditoria. Assim, o sistema também deverá registrar a razão da não conclusão do pedido, caso esta situação ocorra.
Todos os “checklists” deverão ser construídos durante a fase de “Transição/Implantação” (vide subitem 1.9 acima), bem como o catálogo de informações sobre procedimentos. Este último, disponível ao atendente para orientação ao munícipe, deverá ser editável e parametrizável pelo próprio usuário (administrador ou operador), não necessitando, em caso de adequações ou modificações, de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc.
10.4 ACESSO A INFORMAÇÕES CADASTRAIS
Todos os atendentes deverão ter acesso aos dados cadastrais dos munícipes, os dados das ligações, débitos, parcelamentos e todas as informações necessárias para o efetivo atendimento. O acesso às informações deverá ser feito através de tela de consulta, que possuirá resumos das informações, além da possibilidade de acesso a maiores detalhes sem a necessidade de navegação entre menus de consulta, apenas com o auxílio de ícones para facilitar o acesso das informações mais utilizadas.
As telas de atendimento, em especial as de cadastros/manutenções de informações, deverão ter perfis específicos de consulta, que não permitiram nenhum tipo de mudança, seja nos dados cadastrais ou nos débitos da ligação.
Mesmo para aqueles que tenham acesso às modificações, todas as alterações deverão ser guardadas em “log” e facilmente auditáveis, a fim de facilitar a verificação de fraudes e erros de manipulação.
10.5 HISTÓRICO DE LIGAÇÕES/MUNÍCIPES
Todo o histórico da ligação, incluindo Ordens de Serviço e ocorrências, deverá ser acessível através da tela de consulta. Caso haja modificação da posição do hidrômetro, que implique em nova roteirização, o sistema não poderá gerar um novo número de ligação, mas moverá a ligação para o novo logradouro, mantendo o histórico das ações.
Da mesma forma, registros que impliquem em modificações do status da ligação, tais como troca de hidrômetro, multas por tentativa de fraude, requisições, contratos de locação, deverão ser facilmente verificáveis para conferência (batimento) com o munícipe, visando à tomada de decisão em determinadas situações. Esse histórico deverá abranger o que será tratado nos próximos itens deste Termo de Referência, incluindo, mas não se limitando a: processos jurídicos cadastrados, histórico de cortes e religações, acordos de parcelamento, contatos telefônicos, dentre outros. A amplitude total de registros deverá ser planejada pela licitante vencedora, levando em consideração o desempenho do sistema e
também espaço em disco, durante a fase de “Transição/Implantação” (vide subitem 1.9 acima) e com anuência do Saae Sorocaba.
10.6 COMENTÁRIOS
Através da tela de consulta, o atendente poderá inserir alguns comentários, que ficarão gravados para referência futura, utilizando campos de texto livre. Esses comentários serão editáveis apenas pela senha que os incluiu, e deverão ter registros tanto da data/hora de inclusão, quanto de alterações, a fim de se evitar fraudes. A licitante vencedora poderá sugerir formato diverso e mais adequado à entrada de comentários, contanto que não impeça a entrada de dados e/ou informações diversos em campo livre. Dentro da tela de comentários, deverá ser disponibilizado um link para documentos da autarquia, os quais conterão regras sobre padronização e formatação de comentários. A administração dos documentos e de seus repositórios deverá ser livre e parametrizável pelos usuários administradores do sistema.
10.7 RESUMO DE LEITURAS E FATURAMENTO
Da tela de consulta, após a entrada do número de ligação (CDC) do munícipe, o atendente poderá verificar um resumo de leituras dos últimos meses que compõe a média de faturamento, incluindo, para cada mês, valor de leitura do hidrômetro, valor de metros cúbicos medidos, valores faturados, composição das contas, dias de consumo até leitura, ocorrências de leitura, médias utilizadas, trocas de medidores, dentre outras informações. No caso específico de faturamento, o atendente deverá ser capaz de verificar se houve recálculo, crítica ou ação que tenha influenciado no valor final de determinada fatura.
10.8 RELIGAÇÃO PELOS ATENDENTES
O Saae Sorocaba possui hoje um módulo de pedido de religação pelos atendentes (usuários administradores ou operadores), que é utilizado quando o munícipe, com a ligação cortada e com a fase de corte correta no sistema, apresenta o comprovante de pagamento
ao atendente, a fim de acelerar a religação antes da baixa bancária. O sistema deverá prover a mesma funcionalidade, permitindo que atendentes, com o perfil necessário, possam, com uma operação simples na tela de atendimento principal, emitir uma ordem de religação. O sistema deverá entender, mesmo durante o procedimento de “baixa”, que a OS de religação já foi emitida, ou seja, não poderá emitir outra OS.
Toda esta ação deve ficar registrada em log e permitir a verificação de qual usuário e senha foram utilizados, em qual estação de trabalho/microcomputador (incluindo endereço IP e “MAC Address”), e em que data/hora a operação foi feita.
A fase do corte deverá então ser sincronizada, e seguir as regras de religação expostas no item 16 abaixo.
10.9 OPERAÇÕES COM DOCUMENTOS ELETRÔNICOS: FOTOS E DIGITALIZAÇÕES
O sistema deverá permitir incluir, consultar e excluir documentos eletrônicos, como fotos e arquivos específicos de ligações (CDCs) e/ou de contatos.
Dentro do cadastro de um contato, ligação ou pela tela principal de atendimento, o atendente (usuário administrador ou operador) deverá ter acesso a um ícone que, ao ser clicado, indicará todos os arquivos relacionados com o objeto (contato e/ou ligação). De modo geral, as fotos serão utilizadas para demonstrar ao munícipe o ocorrido durante fiscalizações, para embasar mudanças de categoria ou multas por fraudes e violação, dentre outras situações. Da mesma forma, digitalizações de documentos comprobatórios, como contratos de aluguel, recibos de pagamentos, dentre outros, deverão ser incluídas no sistema a partir da estação de trabalho/microcomputador do atendente (usuário administrador ou operador). Para tanto, o atendente (usuário administrador ou operador), através do documento digitalizado e salvo em sua área de trabalho, ao solicitar a anexação de documentos no sistema, deverá poder navegar até o arquivo e anexá-lo.
Quanto à segurança, as operações de inclusão, consultar e exclusão dos documentos eletrônicos, pertencentes ao módulo (funcionalidade), deverão ser registradas (“log”) com todos os dados necessários para efeitos de auditoria. O formato de arquivos válidos será
parametrizável, permitindo os formatos comerciais mais utilizados, tais como: documentos eletrônicos (PDF e/ou DOC), imagens (BMP e/ou JPG), planilhas eletrônicas (XLS e/ou XLSX) e arquivos texto (TXT), mas não se limitando a estes formatos.
10.10 IMPRESSÃO DE TELAS E DOCUMENTOS COMPROBATÓRIOS
O sistema deverá possibilitar “fotografar” o que for apresentado em tela (“Print Screen”), sem a necessidade de operações de copiar e colar, de preferência através de apenas um ícone. Da mesma forma, todas as operações de impressão de documentos, como certidões, segunda via, dentre outros, devem possibilitar a busca em qual impressora o usuário (administrativo ou operador) executará a impressão. É proibida qualquer impressão que não possibilite ao menos a opção de busca e não indique qual impressora executará o trabalho. Deverá ter o sistema também a possibilidade de visualização em tela dos relatórios e documentos antes de sua impressão, a fim de evitar desperdício de papel.
10.11 ACOMPANHAMENTO DE DÉBITOS
O sistema deverá prover ao atendente a visualização, de forma rápida e inequívoca, da situação de todos os débitos de uma determinada ligação, incluindo faturas mensais, notas fiscais avulsas, parcelas e qualquer outro tipo de débito que uma ligação ou contato possa ter. O atendente (usuário administrador ou operador) deverá poderá, por meio de filtros, as contas quitadas, parceladas, canceladas, vencidas, a vencer, recalculadas e outras existentes na base ou propostas pelo sistema. As informações de cada fatura devem incluir data de vencimento, data de pagamento, status da fatura, valor original, valor corrigido, se em débito automático, se em dívida ativa, se em execução, fase do cronograma de entrega, dentre outras informações.
O sistema também deverá prover perfis de acesso que permitam a visualização de débitos dependendo do status. Por exemplo, o Sistema Comercial utilizado atualmente pelo Saae Sorocaba permite impedir a visualização e a manipulação de débitos em Dívida Ativa, e em Execução fiscal, para quem não possui o perfil necessário.
Para fins de instrução aos munícipes, todas as faturas deverão ter claramente descritos todos os seus componentes, inclusive com as referências de que se tratam. Por exemplo, se houver a incorporação de juros e/ou multas por não pagamento de faturas anteriores, o sistema deverá apresentar separadamente o total de juros e/ou multas, e indicar as faturas que os valores se referem.
Será proibido ao sistema utilizar datas fictícias, mesmo que, no momento da geração sistêmica, não se saiba a data real de vencimento. Somente a título de exemplo, situações assim poderão ocorrer em parcelamentos inclusos em conta. Adicionalmente, os débitos não poderão ser mostrados como vencidos.
10.12 IMPRESSÃO DE SEGUNDA VIA E GUIAS DE QUITAÇÃO
O atendente (usuário administrador ou operador) poderá imprimir segundas vias de contas e de outras faturas, ou então, gerar uma guia de quitação referente a débitos. Essas operações deverão cobrar uma taxa parametrizável pelo sistema, já inclusa na guia ou em contas futuras (em caso de segunda via de conta de consumo). O sistema deverá permitir a opção de não cobrança da taxa, mas apenas por perfis autorizados.
Em caso de guia de quitação, o sistema deverá permitir a visualização da guia gerada (por exemplo, em caso de perda), e também a verificação/alteração da linha digitável gerada. Essa função é necessária, pois há casos de pagamento com dados equivocados na linha digitável, tornando-se impossível, sem os dados da linha digitável correta, a transferência de valores apropriados para a quitação.
As faturas geradas deverão prover códigos de barra, sem a necessidade de instalação de fontes especiais nas estações de trabalho/microcomputadores. O código de barras gerado deverá ser legível para máquinas de pagamento comuns de mercado, como caixas eletrônicos, dentre outras.
No caso específico de ligações com execuções fiscais cadastradas, a impressão da segunda via apenas poderá ser efetuada por usuário com privilégios especiais para tanto.
Para o perfil de atendimento padrão, apenas a última conta gerada poderá ser impressa, em geral, a da referência atual.
Todas as operações deverão ser registradas (“log”) com todos os dados necessários para posterior recuperação e auditoria.
10.13 TRAVAS DE SEGURANÇA: EXCEÇÕES, EXECUÇÕES E PROCESSOS
O Saae Sorocaba trabalha atualmente com algumas exceções que impedem a geração de faturas, cobrança de multa e geração de ordens de corte. Maiores detalhes sobre estas situações estão no item 20 abaixo. Da mesma forma, em caso de processos judiciais impedindo o corte por revisão de contas específicas, ocorrerá o impedimento de ações como corte e recálculo.
O sistema deverá permitir o cadastro dessas exceções, execuções e processos, mas os atendentes (usuários operadores) poderão apenas ter acesso a consultar os processos e exceções, para fins de fornecimento de informações aos munícipes. As execuções deverão ser informadas, mas não permitirão a manipulação/geração de segunda via e de termos de quitação, conforme tratado no subitem 15.6 abaixo.
De modo geral, usuários sem o acesso especial não poderão emitir segunda via, quitações e fazer o parcelamento de qualquer débito de uma ligação que tenha uma Execução ativa ou a emissão de segunda via de faturas devidamente inscritas em dívida ativa. Apenas da conta do mês atual, até a geração da próxima, poderá um atendente (usuário operador) emitir a segunda via.
10.14 VALORES INCORPORADOS EM CONTA
O atendente (usuário administrador ou operador) poderá, através da tela de atendimento, verificar todos os componentes de uma determinada fatura, como por exemplo, valores de água, esgoto, eventuais multas, lançamentos (por exemplo, custo de hidrômetro, dentre outros), juros, correção monetária, custos de serviços, emissão de segunda via, ou seja, qualquer valor individual que entre na formação da fatura.
A título de informativo, esses mesmos valores deverão constar na descrição de valores da fatura mensal, inclusive os legados como o CREDTAC, descrito no subitem 21.2 abaixo.
10.15 CONTRATOS DE ALUGUEL
Por força de lei, o Saae Sorocaba deve manter cadastro de todos os imóveis alugados, com a data de vigência do contrato e nome do responsável durante essa vigência. A partir da tela de atendimento ou de cadastro, quando o proprietário ou responsável traz até a autarquia o contrato de locação do imóvel, o atendente (usuário administrador ou operador) poderá, após realizar o “checklist” da operação, cadastrar o contrato por seu período de validade. Assim, o sistema deverá entender que, durante aquele período, apesar do proprietário ser, em geral, o responsável pela ligação, o inquilino contratante deverá ser efetivamente tratado como responsável, gerando-se as faturas, multas e correspondências todas em seu nome. Da mesma forma, caso o inquilino queira fazer um parcelamento ou outra ação, poderá apenas realizar ações sobre débitos de seu período de contratação.
Após o final da vigência do contrato, o sistema deverá transferir, automaticamente, a responsabilidade para o proprietário. A prorrogação de contrato, caso haja, deverá ser informada por vias oficiais pelo proprietário e com novo contrato de xxxxxxx.
O histórico de responsáveis e de contratos de uma determinada ligação deverá ser mantido, de forma a possibilitar a verificação de propriedade/responsabilidade da ligação em determinado período de tempo.
11 CERTIDÕES
11.1 QUITAÇÃO ANUAL DE DÉBITOS
Conforme legislação atual, o sistema deverá prover a possibilidade de se emitir uma certidão de quitação anual de débitos, declarando que determinada ligação quitou todos os seus débitos com o Saae Sorocaba referente a determinado ano. Deverá haver uma tela de declaração em lote, que elencará todas as ligações que não tenham débitos atrasados em determinado período, parametrizável pelo usuário (administrador ou operador). O resultado da geração em lote será um arquivo contendo os dados necessários para envio das notificações para impressão em gráfica ou em um arquivo indicado pelo usuário (administrador ou operador), em formato PDF, com a notificação completa, incluindo o texto legal. Além das opções acima, o sistema deverá permitir o aviso de quitação na própria conta de faturamento mensal.
Além da forma de emissão em lote, o sistema deverá prover, a partir da tela de atendimento, ícone para a emissão individual da certidão, que poderá ocorrer em dois casos:
• Uma segunda via de termo já emitido, em caso de perda;
• Se porventura o munícipe quitar seus débitos de determinado período. Porém, o sistema deverá ter consistências para evitar a geração de termo de quitação com qualquer dívida não paga até seu vencimento.
O texto da certidão será parametrizável e poderá ser modificado a qualquer momento por usuário (administrador), não necessitando, em caso de adequações ou modificações, de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc., apenas substituindo-se o arquivo de modelo, sendo aceitável a edição pelo próprio sistema, para guarda em banco de dados.
Todas as operações deverão ser controladas por contas de acesso e registros (“logs”)
de uso.
11.2 CERTIDÃO NEGATIVA
O sistema deverá permitir a emissão de certidão negativa de débito, com os dados de determinada ligação, declarando por termo oficial que a ligação não possui débitos de qualquer natureza com a autarquia. Para esta emissão, o sistema deverá verificar todos os tipos de débitos e faturas da ligação, e permitir a emissão apenas se não houver débitos vencidos.
O termo emitido deverá ser parametrizável com as informações necessárias, e deve permitir a modificação do texto padrão, não necessitando, em caso de adequações ou modificações, de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc., permitindo a um usuário (administrador) que faça os ajustes necessários pelo próprio sistema, para guarda em banco de dados.
Todas as operações deverão ser controladas por contas de acesso e registros (“logs”)
de uso.
11.3 CERTIDÃO POSITIVA
O sistema deverá permitir a emissão de uma declaração que uma determinada ligação possui débitos, elencando todos esses débitos e totalizando-os, inclusive com os valores originais e corrigidos.
O termo emitido deverá ser parametrizável com as informações necessárias, e deve permitir a modificação do texto padrão, não necessitando, em caso de adequações ou modificações, de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc., permitindo a um usuário (administrador) que faça os ajustes necessários pelo próprio sistema, para guarda em banco de dados.
Todas as operações deverão ser controladas por contas de acesso e registros (“logs”)
de uso.
11.4 CERTIDÃO POSITIVA COM EFEITO DE NEGATIVA
Certidão similar à certidão negativa, indicando que uma ligação em específico não possui débitos vencidos, mas tem acordos de parcelamentos não concluídos, ou seja, houve uma negociação de dívida anterior ainda sendo paga, mesmo que em dia.
O termo emitido deverá ser parametrizável com as informações necessárias, e deve permitir a modificação do texto padrão, não necessitando, em caso de adequações ou modificações, de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc., permitindo a um usuário (administrador) que faça os ajustes necessários pelo próprio sistema, para guarda em banco de dados.
Todas as operações deverão ser controladas por contas de acesso e registros (“logs”)
de uso.
12 LEITURA
12.1 CRONOGRAMA AUTOMÁTICO DE LEITURA
Para cada grupo, o sistema deverá manter um modo de verificação de datas de leitura, geração de contas, débito automático, a fim de permitir a sincronização das operações de leitura, faturamento, geração de contas, troca de hidrômetros e qualquer outra operação em que haja a necessidade de linearização de tarefas, como por exemplo, a troca de hidrômetro e leitura posterior, ou geração de parcelas em conta com geração da fatura do mês.
O cronograma de leitura deverá ser gerado de forma automática, respeitando parâmetros de dias úteis, finais de semana e outros impeditivos de leitura e entrega. Deverá levar em consideração uma margem de dias estipulada pela autarquia, permitindo uma pequena flutuação na data de leitura de determinado grupo. Deverá ser possível a definição de pelo menos um ano de datas de cronograma, com possibilidade de pequenos ajustes durante o ano.
12.2 CADASTRO DE FERIADOS E DIAS ÚTEIS
O sistema deverá permitir o cadastro de feriados por tela e por importação de arquivos. O cadastro deverá ser manual, com controle de acesso próprio e alerta de necessidade de operação a partir das últimas datas cadastradas.
12.3 GERAÇÃO DO ARQUIVO DE ENVIO
O sistema deverá ser capaz de gerar todos os arquivos necessários para passar as informações aos coletores que vão a campo. Os coletores utilizados pelo Saae Sorocaba são padrão de mercado e poderão ser disponibilizados durante a “Transição/Implantação” (vide subitem 1.9 acima). Toda a troca de dados e informações entre os coletores e o sistema
deverá ser registrada para acompanhamento posterior. Da mesma forma, o sistema deverá ser capaz de receber os dados e informações de retorno dos coletores.
12.4 LEITURA SIMULTÂNEA
O sistema deverá estar preparado para a leitura simultânea, com a geração da fatura no momento da leitura, pelos coletores utilizados pelo Saae Sorocaba. Deverá ser garantido que todas as regras de negócio serão carregadas nos coletores para a geração das faturas conforme estipulado, bem como deverá haver salvaguardas em caso de problemas de leitura, geração pela média e críticas de leitura automáticas.
Todos os dados e/ou informações gerados em campo deverão ser carregados no sistema, inclusive permitindo a auditoria de nome do leiturista, posição geográfica (coordenadas GPS), data e hora de geração, entre outros que a autarquia achar necessário.
O Saae Sorocaba não faz a leitura simultânea atualmente. Entretanto, isto deverá estar no escopo do projeto de transição/implantação do sistema, incluindo todas as alterações necessárias para o começo da operação.
12.5 ACOMPANHAMENTO DOS LEITURISTAS
Todas as operações durante a leitura deverão ser registradas (“log”) e transferidas para o sistema durante a sincronização com os coletores. O sistema permitirá o cadastro de dados do leiturista, como nome, matrícula e tipo de atividade permitida. Deverá também possibilitar o controle de rotas, a fim de evitar habitualidade de um leiturista numa rota específica. Também deverá ser possível verificar a produtividade por leiturista, por meio de relatórios, tanto textuais quanto gráficos.
12.6 INTERFACE COM O SISTEMA DAS TERCEIRIZADAS
12.7 RECEBIMENTO DOS LOTES DE LEITURA
O sistema deverá ser capaz de receber os lotes de leitura e processá-los, independente de se a carga dos coletores for local, diretamente pelo sistema, ou se houver a necessidade de troca de arquivos com um sistema terceiro para a operação.
Será sempre de inteira responsabilidade de a licitante vencedora contatar e negociar com a(s) empresa(s) prestadora(s) de serviços de leitura para o Saae Sorocaba, de modo a obter todos os dados e/ou informações (por exemplo, protocolos de troca e “layouts” de arquivo, dentre outros) necessários sobre os coletores e/ou arquivos trocados entre o sistema objeto deste Termo de Referência e a(s) referida(s) empresa(s) prestadora(s) de
12.8 OCORRÊNCIAS DE LEITURA
O Saae Sorocaba utiliza atualmente uma série de ocorrências de leitura que indicam o real “status” da leitura. Todo o histórico dessas ocorrências de leitura deverá ser carregado, bem como os parâmetros atuais de utilização. Dependendo do código, o sistema deverá ser capaz de entender uma série de parâmetros que indiquem faturamento normal, por média, envio para crítica e uma série de operações básicas já utilizadas, como verificação de possível vazamento, problemas com o hidrômetro que indiquem possível fraude ou necessidade de troca, modificação do perfil de consumo da ligação, dentre outros.
Todas as informações e parâmetros pertinentes estão cadastrados no atual Sistema Comercial do Saae Sorocaba. A licitante vencedora deverá levantar os dados existentes e fazer o DE/PARA o sistema proposto.
12.9 GRÁFICOS DE LEITURA E PERDAS
O sistema deverá possuir um gerador de relatórios que permita, de modo gráfico e sem necessidade de conhecimento de tabelas ou programação específica, a visualização dos volumes medidos, total de ocorrências, ocorrências por leiturista e todos os dados e/ou informações necessários para o acompanhamento de ciclos de leitura. Os parâmetros de filtro também deverão ser de fácil configuração, permitindo visualizar informações de rotas, tipos de ligação, período, referência específica ou quaisquer outros dados existentes no banco de dados relacionado com a leitura.
Todos os relatórios deverão permitir ser exportados para arquivos. O formato de arquivos válidos será parametrizável, permitindo os formatos comerciais mais utilizados, tais
como: documentos eletrônicos (PDF e/ou DOC), imagens (BMP e/ou JPG), planilhas eletrônicas (XLS e/ou XLSX) e arquivos texto (TXT), mas não se limitando a estes formatos.
13 ARRECADAÇÃO
13.1 RECEBIMENTO DE FATURAS
A licitante vencedora importará do Sistema Comercial atual todos os cadastros de bancos e históricos de pagamentos e arrecadações. O sistema deverá prover forma de consistência dos arquivos de recebimento e atuar da mesma forma que o Sistema Comercial atual para geração de código de barras e cadastro dos bancos conveniados. As normas seguidas pelo Saae Sorocaba são as da Febraban, atribuindo para a geração dos dígitos de controle dos códigos de barras os sistemas de módulos 10 e 11.
O sistema deverá possuir consistências de arquivos e contas, de modo a gerenciar eventuais casos de não correspondência de boletos, permitindo, em caso de demonstração de pagamento pelo munícipe, associar um pagamento a determinada fatura.
Deverá também contemplar uma tela para conferência, onde os arquivos recebidos poderão ser analisados, incluindo resumos e informações componentes, tais como: a quantidade de contas, o valor total recebido, além de outros elementos relevantes para o acompanhamento da baixa das faturas.
13.2 DOCUMENTOS DE ARRECADAÇÃO
Os documentos de arrecadação seguirão o padrão Febraban, e deverão ser gerados em conformidade com as regras de trocas de arquivos com os bancos cadastrados. Para a
atualização do sistema, será permitido o uso de arquivos-texto, geralmente enviados pelos bancos, incluindo a procura automática de arquivos em pasta pré-cadastrada, ou então a procura do arquivo no “file system”, tanto localmente na estação de trabalho/microcomputador, quanto em ambiente de rede. A operação de captação destes arquivos deverá ser transparente. Após a utilização do arquivo, o sistema deverá transferi-lo para outro local do “file system”, como, por exemplo, uma pasta “processados”. Deverá ser gerado um registro (“log”) para cada arquivo processado, contendo eventuais erros e avisos.
13.3 INTERFACE COM AS “VANS”
O Saae Sorocaba possui convênios com as empresas conhecidas como “Vans”, as quais servem como mensageiro e repositório de arquivos para todos os bancos. Apesar de, atualmente, a autarquia baixar da “webpage”/site da “Van” contratada os arquivos, o sistema deverá ter a opção de baixa automática do site, inclusive com tempo parametrizável de verificação, no caso do Saae Sorocaba eventualmente contratar o serviço de pagamento em tempo real.
13.4 DÉBITO AUTOMÁTICO
O sistema deverá estar preparado para a geração de débitos automáticos de contas conforme o manual de débito automático disponibilizado pela Febraban. O gerenciamento de datas de débito automático será transparente ao munícipe, cabendo à autarquia a possibilidade de escolher critérios de datas a partir da geração das faturas e envio aos bancos.
A licitante vencedora importará todos os dados de débitos automáticos existentes no Sistema Comercial atual, inclusive os registros históricos de faturas pagas em débito automático. Além disso, no gerenciamento de contas, o sistema deverá permitir manipulação de débitos em caso de erro, como por exemplo, em casos em que haja mais de uma fatura para pagamento e o munícipe só tenha valores para o pagamento de uma.
O cadastro e retirada do débito automático seguirá as regras estipuladas pela Febraban, mas o gerenciamento de contas deverá permitir que se congele o envio de determinadas faturas em débito automático ou se force o envio para determinado banco cadastrado, a fim de evitar demoras típicas de retornos de registros dos bancos e erros de sincronismo entre o descadastramento de uma conta e o cadastramento de outra.
Tudo o que fora mencionado neste subitem acerca do gerenciamento de contas envolverá operações cuja execução somente será permitida por usuário (administrador ou operador) com autorização específica para tal. Adicionalmente, o sistema deverá registrar (“log”) todos os dados necessários para efeitos de auditoria.
13.5 SERVIÇOS DIVERSOS – BOLETOS
O sistema permitirá a geração de boletos avulsos, chamados de notas fiscais avulsas, para o pagamento de taxas e serviços. Todo o histórico existente no Sistema Comercial atual deverá ser importado para o novo sistema. As notas poderão estar vinculadas a um número de ligação, mas isso não é obrigatório, pois um munícipe poderá pedir uma certidão ou então um serviço sem haver uma ligação (CDC) correspondente. Nesses casos, o sistema deverá solicitar o cadastramento de um ou mais documentos do requerente, visando à futura cobrança.
Os boletos avulsos deverão ser tratados com todas as regras de pagamento das outras faturas, inclusive com trâmite de arquivos para os bancos, apenas não sendo passível o pagamento por débito automático. Esses boletos avulsos, caso não pagos, farão parte da dívida ativa, a menos que sejam cancelados.
A licitante vencedora deverá indicar uma forma de evitar o pagamento desses boletos avulsos em caso de vencimento. Por exemplo, se um munícipe pedir uma ligação de água, haverá a geração do boleto de taxa de serviço e do boleto para pagamento do hidrômetro. Apenas após o recebimento destes débitos, por parte da autarquia, a execução do serviço será liberada. Entretanto, caso o munícipe demore muito para pagar (o sistema deverá permitir a parametrização deste prazo), o boleto perderá a validade. Se houver, de
qualquer forma, o pagamento após a data de vencimento, o sistema deverá indicar pagamento de boleto fora da validade e não liberar a execução da ligação de água.
13.6 PREJUÍZOS
Em casos de fraude ou pagamento a menos, o Saae Sorocaba utiliza o conceito de prejuízo. Se um hidrômetro foi violado e manteve a média de zero de consumo, o sistema possuirá uma maneira de gerar uma Nota Fiscal Avulsa (NFA) com os valores que o munícipe deveria ter pagado, através de um valor de consumo médio (ou outro critério estatístico) determinado pelo Saae Sorocaba, descontando-se o que o munícipe efetivamente pagou.
A tela de geração deste valor deverá estar disponível para todos os atendentes (usuários administradores ou operadores) mediante acesso autorizado e controlado, com registro (“log”) de utilização – contendo todos os dados necessários para futuras auditorias – e geração do boleto. Para todos os efeitos, o boleto de prejuízo será tratado como uma fatura normal.
13.7 ATUALIZAÇÃO DE DATAS DE VENCIMENTOS
O sistema incluirá, por meio de acesso autorizado e controlado, com registro (“log”) de utilização contendo todos os dados necessários para futuras auditorias, uma forma de atualização das datas de vencimento de uma fatura única ou de um grupo de faturas, como por exemplo, todas as faturas de um ou mais grupos, de um ou mais logradouros, de uma ou mais rotas, de uma ou mais datas de vencimento, dentre outros critérios de grupamento. As faturas com o vencimento atualizado deverão ser elegíveis para reenvio ao munícipe, e será recebido um novo aviso de crédito para pagamento. Caso a fatura tenha sido paga antes da atualização, inclusive multa e/ou juros por atraso, o valor desta multa e/ou juros será abatido de contas futuras ou estornado.
13.8 ESTORNO DE PAGAMENTOS
Em tela própria, por meio de acesso autorizado e controlado, com registro (“log”) de utilização contendo todos os dados necessários para futuras auditorias, um pagamento poderá ser estornado. A fatura cujo pagamento for estornado deverá ser tratada como se nunca houvesse sido paga, ou seja, contará juros e/ou multa a partir de seu vencimento original.
De maneira semelhante, o sistema cuidará das situações em dívida ativa, não se esquecendo de que, em caso de estorno de pagamento de fatura em dívida ativa, deverá informar sobre os valores para recomposição numérica para o Setor de Contabilidade. A integração entre os sistemas comercial e contábil deverá suprir essa necessidade. O estorno de pagamento em dívida ativa, além de ser controlado por permissão específica e registros (“logs”) de execução, deverá ser limitado por parametrizações de prazo e valor, conforme necessidade da autarquia.
13.9 ATUALIZAÇÃO MONETÁRIA E MULTAS
O sistema deverá prever formas de cobrança de multas e atualizações monetárias dependendo do tipo da fatura. Em regra, o Saae Sorocaba cobra 2% de multa, mais correção monetária, atualmente usando a taxa referencial do Sistema Especial de Liquidação e de Custódia (Selic). O sistema possuirá telas de parametrização que permitirão o correto cadastramento de multas e correções monetárias, e, para controle/gerenciamento destas, telas adicionais (se necessárias), as quais apresentarão todos os valores acrescidos período após período. Todos os valores de multas e de correções monetárias deverão ser mostrados nas faturas com rubricas próprias, isto é, de forma clara e separada.
A forma de cálculo começará com a incidência dos 2%, depois incidirá a taxa Selic cadastrada no mês de referência. Se o pagamento for feito nos meses seguintes, a regra será a aplicação de 1% de correção até a inclusão da Selic, e após a taxa inclusa.
Vencimento | Valor Original | Multa | J. Selic 1º mês | J. Selic 2º mês | Valor Corrigido |
01/06/2013 | 52,00 | 1,04 | 0,0 | 0,0 | 53,04 |
01/05/2013 | 69,69 | 1,3938 | 0,710838 | 0,0 | 71,79 |
01/04/2013 | 20,59 | 0,4118 | 0,210018 | 0,127271 | 21,33 |
O Saae Sorocaba adotou a correção da Selic a partir de novembro de 2009, antes disso cobrando apenas a multa. Este marco deverá ser respeitado em casos de recálculos de contas.
O sistema deverá permitir, de forma parametrizável e sem necessitar de alterações de software, ou seja, programação, compilação etc., que seja aplicada correção monetária em parcelas com vencimento futuro. Assim, quando houver a incorporação de uma parcela em uma conta, o sistema deverá aplicar um índice de correção monetária cadastrado para a referência. Deve-se prever também, em caso de parcelamento em boleto avulso, que na geração do título seja aplicado um valor de correção futuro, por índice também parametrizável.
Todas as faturas vencidas que forem importadas para o novo sistema deverão manter os valores corrigidos a fim de evitar inconsistências, bem como o histórico de multas e juros.
13.10 BOLETOS AVULSOS E DE PREJUÍZO
Nesta funcionalidade, o sistema gerará uma NFA (boleto avulso) para cobrança de diversos serviços existentes na autarquia, a qual poderá ser composta por vários itens. Não necessariamente a NFA estará relacionada a uma ligação (CDC) cadastrada no sistema. Nesta situação, o sistema deverá solicitar o cadastramento de um ou mais documentos do requerente, visando à futura cobrança.
A tela de geração da NFA valor deverá estar disponível para todos os atendentes (usuários administradores ou operadores) mediante acesso autorizado e controlado, com registro (“log”) de utilização – contendo todos os dados necessários para futuras auditorias – e geração do boleto avulso. Para todos os efeitos, este boleto será tratado como uma fatura normal, ou seja, quando associada a uma ligação, a inclusão de uma NFA gerada com número de aviso será automaticamente classificada como fatura com a situação “em débito”, a qual deverá ser visualizada juntamente com os outros débitos relativos ao CDC. Ao emitir a NFA para pagamento, o sistema gerará o número da nota fiscal referente àquele débito.
14 FATURAMENTO
14.1 REGRAS DE GERAÇÃO DE FATURAS
O principal parâmetro de geração das faturas será o Ato Administrativo que indica as faixas e o valor de faturamento. Todos os Atos anteriores, num total de vinte e um, deverão ser importados do Sistema Comercial em uso para futura referência e recálculos, se necessário.
O regulamento atual do Saae Sorocaba indica que o faturamento é composto pela metragem cúbica faturada de consumo de água, decomposta em faixas de consumo, sendo então cada componente desta decomposição multiplicado pelos valores (em moeda corrente) destas faixas de consumo, levando em conta para cada faixa de consumo um valor diferente. É o que se conhece comumente como sistema de faturamento em cascata.
O sistema deverá entender as diferentes categorias de utilização, atualmente compostas por: Residencial, Comercial, Industrial, Pública, Associação, Associação Beneficente e Associação Especial. Caso necessário, o sistema permitirá o cadastro de novas categorias de forma transparente pelo próprio usuário (administrador ou operador), não necessitando de intervenções em banco de dados e ainda sem necessitar de alterações de software, ou seja, programação, compilação etc. Cada categoria principal pode ser dividida em subcategorias, com suas próprias regras de faturamento. A função principal das subcategorias é a classificação em subtipos, permitindo, por meio de relatórios, a verificação com maior granularidade de casos específicos. Por exemplo, nos casos comerciais, quantos tipos de comércios – tais como açougues, lojas de calçados, bancas de jornal etc. – compõem a base de clientes da autarquia.
Cada categoria terá valores de faixas de consumo, como por exemplo, 0 a 10m3, 11 a 15m3, e assim por diante, e cada faixa terá seu preço (em moeda corrente) por metro cúbico. Além disso, a ligação indicará um tipo de faturamento, isto é, se apenas água, se
água e esgoto, ou outros tipos especiais (como a Tarifa de Esgoto Especial (TEE), utilizada para ligações que utilizam poços), dentre os cinco tipos utilizados pela autarquia.
Assim sendo, para se gerar uma fatura de uma ligação, verificar-se-á sua categoria, seu volume faturado e se fará o cálculo de custo baseado em seu consumo.
Por exemplo, uma ligação residencial que tenha consumido efetivamente 16m3 de água. Neste exemplo, a ligação não tem esgoto faturado. Levando em consideração uma faixa de valores hipotética de:
• 0 a 10m3: 𝑅$ 2,00;
• 11 a 15m3: 𝑅$ 3,00;
• 16 a 20m3: 𝑅$ 4,00.
O valor faturado desta ligação no referido mês seria 10 ∗ 𝑅$ 2,00 + 5 ∗ 𝑅$ 3,00 + 1 ∗ 𝑅$ 4,00 = 𝑅$ 39,00. Uma vez gerada a fatura, a sua data de vencimento deverá se espelhar na data prevista no cronograma de leitura.
Cada fatura terá um número de aviso próprio, linha digitável para pagamento (sequência grande de números que fornecem as informações necessárias para o pagamento e a compensação da fatura) e nota fiscal. Essas informações serão utilizadas na fase de arrecadação para baixa dos pagamentos das faturas.
Se possível, as faturas deverão ter, a critério das regras da Federação Brasileira de Bancos (Febraban), validade para pagamento. Assim, após determinado tempo, parametrizável no momento da geração da fatura, a linha digitável ficaria inválida. Nesta situação, caso ocorra pagamento, o valor pago deverá ficar vinculado ao CDC como crédito, a ser utilizado em negociações futuras. Mesmo cuidado deverá ser tomado para pagamento de serviços, cujos custos estejam atrelados ao aumento de tarifa como, por exemplo, fatura avulsa referente à taxa de ligação de água.
14.2 RUBRICAS DE FATURAMENTO E OCORRÊNCIAS
O sistema utilizado pela autarquia apresenta uma série de rubricas de faturamento e códigos de ocorrência que deverão ser levados em conta no momento da migração, para base histórica e manutenção da maneira de trabalho (“modus operandi”). Essas rubricas classificam os componentes de água, esgoto, serviços diversos, multas, juros, dívida ativa e outros componentes do custo total da fatura.
As ocorrências apontam problemas de faturamento, indicando se há alguma divergência no padrão de consumo da ligação. Exemplos de utilização atual são os indicadores de consumo maiores de 70% ou menores de 30% em relação à média de consumo medido nos últimos doze meses. Todos os tipos de tributos, rubricas e ocorrências do Sistema Comercial atual deverão ser carregados para futura referência e guarda de histórico.
14.3 GRÁFICOS DE FATURAMENTO
14.4 CRÍTICA DE FATURAS
Após a geração da fatura inicial, o sistema deverá permitir uma fase de crítica de faturas. O atual Sistema Comercial possui uma série de parâmetros para críticas automáticas, que determinam se algumas faturas saíram da faixa de consumo padrão, levando à suspeita de vazamento ou de erro de leitura.
O sistema deverá possuir um mecanismo que permita a verificação destes casos anômalos, sem a necessidade de verificação de todas as contas. Ao se gerar as faturas de determinado grupo, um relatório de crítica deverá ser gerado, seguindo parâmetros como aumento ou diminuição excessiva de consumo, valor maior que o normal sem variação de consumo e outros casos que deverão ser detalhados durante a fase de “Transição/Implantação” (vide subitem 1.9 acima). A fase de crítica é uma fase formal do processo, ou seja, sem a validação eletrônica de um responsável (registrada em “log” com todos os dados necessários para fins de auditoria), não se passará para a próxima fase de processamento.
Para todos os efeitos, até a finalização da crítica e liberação final para entrega, a fatura não pode ser considerada válida para nenhum caso, não podendo ser parcelada, quitada, cancelada, nem sofrer nenhuma operação normal às faturas.
14.5 COBRANÇA DE ESGOTO
A cobrança de esgoto, pelo regulamento do Saae Sorocaba, é baseada em uma porcentagem do valor total da água. O sistema deverá permitir a parametrização deste total,
e verificar se o tipo de ligação indica a necessidade de cobrança de esgoto, lembrando que há casos de ligação apenas de água, água e esgoto, e os casos de TEE.
O valor do esgoto levará em consideração o valor do cálculo relativo à água, ao cabo do cálculo em cascata. Levando-se em conta o exemplo apresentado no subitem 14.1 acima e o percentual aplicado atualmente pela autarquia (92,5%), seria obtido o seguinte valor:
𝑅$ 39,00 ∗ 0,925 = 𝑅$ 36,075
Pelas regras de arredondamento vigentes, os valores após a segunda casa decimal são desprezados, sendo assim, o valor final de água e esgoto será: 𝑅$ 39,00 + 𝑅$ 36,07 =
𝑅$ 75,07.
14.6 FATURAMENTO POR MÉDIA
Em casos específicos, como impossibilidade de leitura, crítica, atrasos de leitura, por decisão estratégica, dentre outros, o sistema possibilitará a geração de faturas pela média das últimas leituras, a qual será parametrizável de acordo com a quantidade de meses informados. O sistema deverá ter formas alternativas de parametrização estatística (além da média das últimas leituras) sobre o valor de volume medido, permitindo uma melhor tratativa caso a caso.
Para os casos de ocorrências de impossibilidade de leitura ou crítica, a geração pela média deverá ser automática. Nas outras situações, o sistema deverá prover uma tela em que um usuário (administrador ou operador) com permissão específica poderá gerar todas as faturas de uma seleção particular pela média, sempre mediante validação eletrônica, a qual será registrada em “log” com todos os dados necessários para fins de auditoria.
14.7 FATURAMENTO POR ECONOMIAS
O regulamento do Saae Sorocaba indica que os valores de fatura de uma ligação dependerão da quantidade de economias cadastradas em uma ligação. Isso indica que nos casos de imóveis com mais de uma economia, mas mesmo hidrômetro, geralmente
condomínios de apartamentos, será entendido que há 𝑥 unidades autônomas e que o consumo para cada faixa será ajustado conforme essas unidades.
Tomando-se como exemplo um condomínio com oito economias residenciais que apresentou um consumo de 94m3, e levando-se em consideração que os valores cobrados por faixa de consumo são hipotéticos, tem-se:
Consumo total | 94 m3 | |
Qtde de economias | 8 | |
Faixa (m3) | Valor | Consumo máximo (m3) para a faixa | Consumo adequado (m3) para a faixa | Valor Água | Valor Esgoto | |
0 -> 10 | $ 1,07 | 80 | 80 | $ 85,60 | $ 79,18 | |
11 -> 15 | $ 1,61 | 40 | 14 | $ 22,54 | $ 20,84 | |
$ 108,14 | $ 100,02 | $ 208,16 | ||||
Já para um condomínio com doze economias residenciais que apresentou um consumo de 268m3, tem-se (os valores cobrados por faixa de consumo são hipotéticos):
Consumo total | 268 m3 | |
Qtde de economias | 12 | |
Faixa (m3) | Valor | Consumo máximo (m3) para a faixa | Consumo adequado (m3) para a faixa | Valor Água | Valor Esgoto | |
0 -> 10 | $ 1,07 | 120 | 120 | $ 128,40 | $ 118,77 | |
11 -> 15 | $ 1,61 | 60 | 60 | $ 96,60 | $ 89,35 | |
16 -> 20 | $ 2,33 | 60 | 60 | $ 139,80 | $ 129,31 | |
21 -> 25 | $ 3,37 | 60 | 28 | $ 94,36 | $ 87,28 | |
$ 459,16 | $ 424,71 | $ 883,87 | ||||
14.8 CASOS ESPECIAIS
O município de Sorocaba possui alguns condomínios em que a leitura de água é individualizada. Cada unidade habitacional tem seu hidrômetro próprio, e a entrada do condomínio inclui um hidrômetro de grande capacidade. O sistema deverá permitir o cadastro dos hidrômetros de cada unidade, chamados de dependentes, ligados ao hidrômetro principal, chamado de “master”. O sistema deverá entender que a somatória de todas as leituras dos hidrômetros dependentes será subtraída do “master" para geração de uma fatura de área comum do condomínio. Ficará a cargo da licitante vencedora o levantamento de regras de negócio e consistências para tal atividade, isto é, formas de gerenciamento das ligações dependentes, regras de cálculo, possíveis exceções e problemas, como por exemplo, se o resultado final de volume do “master” for negativo, caso possível por questões de sincronismo entre os hidrômetros dependentes e o “master”, uso de caixas de água, dentre outras situações.