ESPECIFICAÇÕES GERAIS

ANEXO I – Termo de Referência

1.ESPECIFICAÇÕES GERAIS

2.SISTEMA DE TRIBUTAÇÃO MUNICIPAL E ARRECADAÇÃO

3.SISTEMA DE SANEAMENTO BÁSICO

4.SISTEMA DE ATENDIMENTO AO CIDADÃO

5.SISTEMA DE COLETA DE DADOS, IMPRESSÃO E ENTREGA SIMULTÂNEA DE CONTA DE ÁGUA E NOTIFICAÇÕES

6.SISTEMA DE CONTROLE DE PROTOCOLO

7.SISTEMA DE CONTABILIDADE, ORÇAMENTO PÚBLICO E TESOURARIA.

8.SISTEMA DE ADMINISTRAÇÃO DE COMPRAS, LICITAÇÕES E CONTRATOS:

9.SISTEMA DE ADMINISTRAÇÃO DE MATERIAIS (ALMOXARIFADO)

10.STEMA DE ADMINISTRAÇÃO DO PATRIMÔNIO

11.SISTEMA DE ADMINISTRAÇÃO DE PESSOAL

12.SISTEMA DE CONTROLE DE PONTO ELETRÔNICO

13.SISTEMA DE RECURSOS HUMANOS

14.SISTEMA DE GERENCIAMENTO DE DESPESAS

15.SISTEMA DE SERVIÇOS VIA WEB:

16.SISTEMA DE CONTROLE DE FROTA

17.TREINAMENTOS E CERTIFICAÇÃO DE USUÁRIOS

ESPECIFICAÇÕES GERAIS

1. CONSIDERAÇÕES PRELIMINARES

O presente termo de referência tem por objeto dar subsídio à contratação de serviços técnicos especializados para fornecimento de Sistemas Integrados de Informática destinada à Gestão Pública Municipal, acompanhados de assessoria técnica, implantação, capacitação do quadro de pessoal técnico de Tecnologia da Informação, capacitação dos usuários do sistema e conversão de arquivos na Prefeitura Municipal de MOGI MIRIM e no Serviço Autônomo de Água e Esgoto de MOGI MIRIM - SAAE. Os sistemas de informática objeto deste termo de referência deverão ter sido desenvolvidos em linguagem de quarta geração com ambiente visual, utilização de Banco de Dados Relacional ORACLE, possibilitando sua execução através de rede de dados LAN, WAN e TCP-IP, processar em ambiente multi-usuário e com banco de dados único integrado. O objeto deste termo de referência é composto pelos seguintes itens:

Sistema Integrado de Gestão Pública Municipal:

• Acompanhamento da instalação dos sistemas;

• Conversão de dados preexistentes e importação de dados;

• Treinamento e certificação de usuários dos seguintes órgãos e instituições municipais:

1. Gabinete do Prefeito e do Vice Prefeito;

2. Secretaria de Administração e Recursos Humanos;

3. Secretaria de Agricultura;

4. Secretaria de Assistência Social e Cidadania;

5. Secretaria de Captção, Gestão e Controle;

6. Secretaria de Cultura e Turismo;

7. Secretaria de Educação;

8. Secretaria de Esportes, Juventude e Lazer;

9. Secretaria de Finanças; 10.Secretaria de Governo;

11.Secretaria de Suprimentos e Qualidade; 12.Secretaria de Negocios Jurídicos; 13.Secretaria de Obras, Habitação e Serviços;

14.Secretaria de Planejamento e Mobilidade Urbana; 15.Secretaria de Saúde;

16.Secretaria de Segurança Pública; 17.Secretaria de Sustentabilidade Ambiental; 18.Secretaria de Tecnologia da Informação;

19.Serviço Autônomo de Água e Esgoto de MOGI MIRIM – SAAE

• Treinamento e certificação da equipe técnica da Diretoria de Tecnologia da Informação (suporte a usuários) e do Serviço Autônomo de Água e Esgoto de MOGI MIRIM;

• Cessão de Direito de Uso por Tempo Determinado de Sistema Integrado destinado à Gestão Pública Municipal.

2. JUSTIFICATIVA

Este Termo de Referência se insere no contexto da modernização institucional propondo a infraestrutura de serviços baseando-se nas especificações mais atuais de sistemas integrados de gestão.

Os sistemas contemplados abrangem três eixos principais: os instrumentos para consolidação do planejamento e administração do município; a integração de políticas sociais de grande complexidade; além da produção de indicadores e relatórios que contemplem todas as exigências legais do Município, do Estado de São Paulo e do Governo Federal.

A Prefeitura de MOGI MIRIM mantém um ambiente computacional complexo onde estão inseridas consultas a bancos de dados, análises situacionais e produção de informações com vistas à sustentação das tomadas de decisões em todos os campos de atuação do Poder Executivo Municipal, estando tudo interligado através de equipamentos “servidores”, estações de trabalho e rede de dados, acesso à internet e outros equipamentos próprios de telecomunicações, além de todos os programas necessários ao funcionamento integrado.

Torna-se imprescindível à utilização de um sistema de gerenciamento de Banco de DadosRelacional (SGBDR), implementado em um servidor de dados exclusivo, devido ao volume de informações que são tratadas pelo atual sistema de gestão, exigindo em matéria tanto de hardware quanto de software, soluções compatíveis com esta demanda.

Portanto, todas as especificações técnicas contidas neste termo de referência foram estabelecidas em função da disponibilidade e performance, devido à natureza segura e estável que estes sistemas deverão proporcionar.

3. OBJETIVOS

O objetivo geral a ser alcançado com este Termo de Referência é o fortalecimento da capacidade de gestão da Prefeitura Municipal de MOGI MIRIM e do Serviço Autônomo de Agua e Esgoto de MOGI MIRIM - SAAE.

Os objetivos específicos são os seguintes:

• Implantação de um processo de gestão integrada do desenvolvimento econômico, social e ambiental com a consolidação do sistema municipal integrado envolvendo todas as áreas de atuação do Poder Executivo Municipal;

• Capacitação técnica de pessoal para o planejamento, execução, manutenção e expansão do ambiente computacional da Prefeitura Municipal de MOGI MIRIM e do Serviço Autônomo de Água e Esgoto de MOGI MIRIM

- SAAE;

• Otimização no processo de gestão de informações municipais;

• Compartilhamento de dados e informações com a população.

4. CONDIÇÕES DE EXECUÇÃO DO OBJETO

4.1- Nenhum fornecedor poderá apresentar proposta prevendo execução do contrato, em regime de associação e ou consórcio com outras empresas, visto que a Prefeitura Municipal de MOGI MIRIM e o Serviço Autônomo de Água e Esgoto de MOGI MIRIM – SAAE pretendem estabelecer com um único fornecedor uma relação próxima e eficaz para o atendimento completo de todo o projeto;

4.1- A Prefeitura Municipal de MOGI MIRIM e o Serviço Autônomo de Água e Esgoto de MOGI MIRIM – SAAE contratarão uma única empresa que lhe disponibilize o conjunto de sistemas para satisfação de suas necessidades técnicas e administrativas, contemplando minimamente os módulos constantes do RELAÇÃO DOS SISTEMAS OU MÓDULOS OBJETO DESTE TERMO DE REFERÊNCIA

ANEXO I (com suas respectivas funcionalidades principais).

Funda-se ainda na razão econômica de se obter um melhor preço na contratação da integridade do conjunto dos sistemas essenciais, o que não é possível se obter quando se pulveriza a contratação dos mesmos.

4.3 O banco de dados relacional licenciado para a prefeitura Municipal de Mogi Mirim, como o serviço de água e Esgotos SAAE Mogi Mirim, é o Oracle Linux 6.5 - 64Bits

11.2.0.3.0 Standard Edition, sendo que os sistemas de Gestão Integrados deverão ser instalados obrigatoriamente no servidor de banco de dados, com sistema operacional Linux tanto no servidor do SAAE como no Servidor da Prefeitura.

Servidor do SAAE Intel Xeon 2.40GHz, 16Core, 12 Gb Memória, Servidor da Prefeitura: Intel Xeon 3.1Ghz, 8Core, 24 Gb Memória 4Hd SAS hide 5.

4.4 - A base de dados Oracle é de propriedade do contratante.

4.5 - Os sistemas objeto desta licitação deverão utilizar uma base única de dados.

5. CONVERSÃO DOS DADOS

A conversão dos dados dos sistemas atuais para o novo sistema deverá ser realizada pela licitante vencedora. As adaptações das Bases de Dados e Fórmulas, conforme características particulares de cada uma delas, visando o correto funcionamento dos sistemas é de total responsabilidade da licitante vencedora.

5.1 – O prazo para conversão dos dados implantação e treinamento dos sistemas é de até 30 dias da Assinatura do contrato

5.2 – Durante o período de conversão e antes da homologação licitante vencedora xxxxxx xxxxxx as incorreções apontadas pela contratante imediatamente após a constatação

5.3 – Após a conversão, a licitante vencedora deverá elaborar termo circunstanciado para quitação da conversão, contendo toda documentação referente aos dados convertidos. A contratante realizará a conferência das informações dentro do prazo previsto no cronograma previamente aprovado.

5.4 – Quaisquer incorreções no processo de conversão, detectados em até 01 (um) ano a contar do início do contrato, deverão ser sanados pela licitante vencedora, sem ônus adicionais para a contratante, em prazo a ser negociado entre as partes.

6 – Os sistemas de Gestão Pública Integrada deverão constituir um ambiente multiusuário, “integrado”, “on-line”, permitindo o compartilhamento de arquivos de dados e informações de uso comum;

E de responsabilidade da contratada disponibilizar as informações da base de dados em web service, arquivo XML ou outros meios, essa disponibilização deve ocorrer conforme a necessidade da contratante.

7 - Os Sistemas obrigatoriamente deverão disponibilizar em plataforma web, para as seguintes tarefas, comuns a todos os usuários da Prefeitura, requisições e devoluções de materiais ao almoxarifado; solicitações de compras, e acompanhamento das mesmas; encaminhamento de processos e protocolos, Execução de contratos.

7.1 Os sistemas obrigatoriamente deverão disponibilizar em plataforma web, aos munícipes a possibilidade de Emissão de 2º via de carnês de IPTU, do Exercício, Emissão de 2º Via de Dívida Ativa do IPTU, Emissão de 2º Via ISS Anual, do exercício, Emissão de 2º Via de ISS Anual Dívida Ativa, Emissão de 2º Via de Taxas Mobiliárias do Exercício, Emissão de 2º Via de Taxas Mobiliárias da Dívida Ativa, Emissão de Certidão Negativa Débitos, Emissão de certidão Positiva com Efeito de Negativa, Consulta de carnês de IPTU, Consulta de ISS Anual, Consulta de Dívida Ativa, Autenticação das certidões Emitidas.

8 – Os sistemas deverão estar dotados de toda segurança que o ambiente multiusuário exige, como por exemplo o tratamento de transações.

9 – A integração entre todos os sistemas:

9.1 – Não necessitará de arquivos auxiliares ou externos, exceto quando disposto o contrário na descrição do sistema/módulo.

9.2 – O processo de integração entre os sistemas e módulos será organizado de forma que, embora os dados estejam imediatamente disponibilizados na base, estes apenas ficarão disponíveis para uso no módulo/sistema seguinte após confirmação do módulo/sistema anterior de que as tarefas correspondentes foram encerradas e que os dados integrados estão corretos.

9.2.1 – A decisão de integração, ou outra equivalente e a qualidade dos dados integrados constituem situações privativas da contratante, devendo a licitante vencedora apresentar esclarecimentos e orientações relativas caso solicitada.

9.2.2 - A licitante vencedora deverá garantir o correto funcionamento dos processos de integração e orientar tecnicamente a equipe de trabalho disponibilizada pela contratante, no momento da implantação (etapa de parametrização da integração) e sempre que solicitado pela contratante para eventuais ajustes.

9.2.3 – A licitante vencedora deverá parametrizar a integração conjuntamente a equipe designada pela contratante para tal, no momento da implementação da rotina e sempre que solicitado pela contratante.

9.2.4 – A integração deve permitir o estorno de uma operação de integração previamente realizada.

9.2.4.1 - A licitante vencedora deverá orientar tecnicamente os usuários do sistema, em especial os gestores das áreas envolvidas na integração do sistema, quanto à viabilidade técnica e consequências da operação de estorno de uma integração previamente realizada.

9.2.4.2 – A licitante vencedora deverá também orientar todas as atividades decorrentes da integração ou estorno que deverão ser realizadas manualmente pelos profissionais da contratante, visando o cumprimento da integração prevista neste item.

9.3 – Todas as informações deverão pertencer ao mesmo banco de dados, estando imediatamente disponíveis a todos os sistemas, quando do processo de integração, exceto os módulos e sistemas cujo descritivo indique o contrário.

9.4 – Não haverá necessidade de retrabalho ou redigitação, ou seja, a inclusão/alteração de informações no banco de dados será totalmente corporativa e colaborativa, de forma que uma atividade executada por um sistema, após integração, seja totalmente apreciada pelos demais.

9.5 – As tabelas de referência e uso comum do sistema (que poderão participar do processo de integração dos sistemas) e alguns processos específicos aos sistemas integrados, deverão estar disponíveis e serem atualizadas automaticamente e imediatamente, estando disponíveis para uso em outros módulos pelos usuários do sistema com permissão para tal.

9.5.1 – A licitante vencedora deverá auxiliar tecnicamente a alimentação destas tabelas, cujos parâmetros são de criação e controle exclusivos da contratante através de seus técnicos responsáveis.

10 – Os sistemas deverão possuir mecanismos de tratamento de senhas, os quais restrinjam o acesso do usuário em função do perfil administrativo ao qual pertence.

10.1 – A administração das senhas e acessos à aplicação será da contratante, não sendo admitida qualquer ingerência pela licitante vencedora, que deverá realizar treinamento aos prepostos da contratante indicados para gestão das senhas e acessos para que estes possam realizar de forma autônoma o gerenciamento dos perfis e gerenciamento das senhas.

10.2 – Os perfis de uso dos sistemas serão definidos exclusivamente pelo(s) responsável(is) pelo(s) sistema(s), nomeado(s) pela contratante, não sendo permitida nenhuma alteração não autorizada pela licitante vencedora. A licitante vencedora deverá auxiliar a criação dos perfis durante o período de implantação dos sistemas e os sistemas devem manter o perfil definido pelo(s) responsável(is).

11 – Os sistemas deverão possuir mecanismos que possibilitem o registro das transações efetuadas no banco de dados (AUDIT). Através deste procedimento, deverão ser gravadas as alterações efetuadas no banco, assim como seu autor e a data/hora em que o evento ocorreu.

11.1 – Os sistemas deverão disponibilizar, nas aplicações gerenciais, recursos para visualização destes registros de alteração, quando aplicável.

11.2 – A definição da auditagem (quais tabelas e situações devem ser auditadas) será atribuição exclusiva da contratante, não sendo admitido nenhum tipo de ingerência nesta definição.

12 – A licitante vencedora deverá disponibilizar um Gerador de Relatórios para utilização junto aos sistemas. Este recurso terá como maior objetivo auxiliar o usuário final na elaboração de seus próprios documentos e relatórios.

12.1 – A licitante vencedora deverá disponibilizar, sempre que solicitado e sem custos à contratante, Views que possibilitem a alimentação dos relatórios gerados com os dados constantes no banco de dados.

13 - Os sistemas deverão ser multi-exercícios, ou seja, permitir que o usuário acesse as informações de exercícios diferentes.

14 – Os sistemas devem permitir a visualização de relatórios em tela antes de sua impressão.

14.1 – A licitante vencedora deverá justificar tecnicamente os casos onde a visualização prévia não for disponibilizada por ser prejudicial à rotina.

14.2 - Os sistemas devem possibilitar exportação para os padrões pdf, txt, xls e doc, desde que exista viabilidade técnica.

14.3 – A licitante vencedora deverá realizar avaliação técnica prévia visando possibilitar a exportação de dados para arquivos previamente preparados/produzidos por terceiros. Caso a execução seja considerada viável tecnicamente, a exportação deve ser disponibilizada sem ônus à contratante.

14.4 – A exportação de arquivos de padrão xls e doc ocorrerá conforme descrição específica dos sistemas/módulos. As licenças de uso que possibilitem esta integração serão disponibilizadas pela contratante.

14.5 – Os relatórios do sistema devem ter a possibilidade de personalização de layout e impressão de brasões/logotipos da contratante, conforme disponibilizado pela mesma.

14.5.1 – Os relatórios devem ter, quando requeridos, opção de campos para assinatura no final.

14.5.2 – Deverá haver disponibilidade de inclusão do arquivo de imagem referente aos brasões/logotipos em repositório, de forma que os relatórios a serem impressos utilizem esta imagem, sem necessidade de replicação da mesma para cada relatório.

15 – Nenhum dos softwares fornecidos pela licitante vencedora, que sejam instalados e/ou atualizados nos terminais da contratante, deverá impedir o funcionamento de outros programas instalados no terminal.

15.1 – Caso exista qualquer incompatibilidade entre as aplicações objeto deste Termo e outros programas, a Licitante Vencedora deverá apresentar à gestão do contrato parecer técnico e possíveis soluções, que serão implementadas de comum acordo entre as partes.

15.2 – Os sistemas devem ser integralmente compatíveis com as plataformas windows de 32 bits e 64 bits.

16 - Os sistemas deverão possuir mecanismos que permitam fazer a atualização automática dos programas à medida que forem geradas novas versões.

16.1 - A contratante reserva-se ao direito de definir a sua política de segurança para uso dos terminais e, caso estes impeçam a atualização automática dos sistemas, a Licitante Vencedora deverá apresentar solução alternativa, a qual está submetida à aprovação e posterior implementação conjunta entre as partes.

17 – A licitante vencedora deverá providenciar a integração (tais como envio e recebimento de informações, arquivos, entre outros) com sistemas eventualmente contratados para outros fins, mediante solicitação de acordo com os termos do SLA.

18 – A licitante vencedora deverá disponibilizar e implementar rotinas que possibilitem a geração de layout para importação e exportação de arquivos de outros sistemas, mediante solicitação de acordo com os termos do SLA.

19 – Os sistemas devem permitir a geração de arquivos de exportação de informações para uso de terceiros, mediante solicitação (de acordo com os termos do SLA) e obedecendo ao layout fornecido pela contratante.

20 – A licitante vencedora deverá disponibilizar atendimento e suporte técnico através de: telefone, Skype e Internet (chamados técnicos online).

20.1 – Em casos específicos, desde que justificados e em mútuo acordo, o atendimento poderá ocorrer também presencialmente, nas dependências da contratante (ou local por esta indicado) e nas dependências da licitante vencedora sem custos adicionais.

20.2 – A licitante vencedora deverá disponibilizar software com tecnologia web-based, 24 horas por dia, para atendimento de solicitações de manutenção e desenvolvimentos nos sistemas e módulos.

20.2.1 – O software de atendimento web-based deverá contemplar todos os sistemas e serviços disponibilizados pela licitante vencedora e deverá manter registro de todas as solicitações, encaminhamentos, respostas e soluções aos problemas dos usuários durante a vigência do contrato.

20.2.2 – O software web-based deverá disponibilizar total liberdade para a abertura de solicitações de suporte técnico, de qualquer natureza, dentro do escopo do presente Termo de Referência.

20.2.3 – O software de atendimento web-based deverá possibilitar ao gestor do contrato a delegação ao seu critério de um responsável por sistema/módulo e serviços oferecidos, constantes do presente Termo de Referência, possibilitando a estes responsáveis a abertura de chamados técnicos de SLA 1 a 4.

20.2.4 – A estrutura de delegação do software de atendimento web deverá disponibilizar um único acesso especial ao gestor do contrato ou preposto

da contratante para a solicitação de melhorias nos sistemas e serviços e/ou atendimento de novas situações não contempladas pelos sistemas.

20.3 – O atendimento telefônico e por Skype será disponibilizado pela licitante vencedora para pronto atendimento nos casos de solicitação de orientações ou dúvidas simples.

20.4 – A licitante vencedora deverá disponibilizar e orientar a equipe técnica da contratante para utilização de ferramentas de conexão remotas junto aos terminais usuários do sistema, para futuro atendimento. A contratante poderá fornecer licenças de uso de software similares para esse fim, caso julgue conveniente.

20.5 – A licitante vencedora deverá disponibilizar terminal para conexão remota, com acesso liberado pela contratante para que o suporte técnico dos sistemas possa atuar em correções e testes solicitados através dos chamados técnicos eventualmente abertos.

20.6 – Fica estabelecido o seguinte Acordo de Nível de Serviço (Service Level Agreement – SLA), para atendimento das solicitações de suporte realizadas por escrito através do software de atendimento:

Severidade	Motivação	Prazo Resposta	Prazo Solução*
1 CRITÍCA	Parada total de módulo; parada de funcionalidade que atinja número significativo de munícipes/consumidores na sua paralização.	Imediata – 1 (uma) hora útil. Necessária comunicação por telefone com a gerência da licitante vencedora.	Necessário apresentar solução de emergência (se possível). Até 6 (seis) horas úteis.
2 ALTA	Rotina importante do sistema paralisada (entende-se como rotina importante as rotinas essenciais ao funcionamento do módulo, sem a qual a utilização do sistema fica gravemente prejudicada).	Até 3 (três) horas úteis.	Necessário apresentar solução de emergência (se possível). Até 2 (dois) dias úteis.
3 MÉDIA	Funcionalidade com problema que não compromete a operação do sistema, desde que envolva: 1. prazo inadiável (previsto em legislação ou regulamento); ou 2. alguns	Até 6 (seis) horas úteis.	Até de 3 (três) dias úteis ou quando do prazo inadiável (o que for maior).

	munícipes solução adiados.	de	precisem seus	ter a problemas
4 BAIXA	Erro ou mal funcionamento em rotinas adiáveis do sistema (é possível continuidade do trabalho normal).				Até 1 dia útil.	(um)	Até 5 (cinco) dias úteis.
5 NOVAS SOLICITAÇÕ ES²	Ajustes e alterações no sistema visando sua melhoria, ou decorrentes de alteração da rotina interna da contratante, desde que aprovados entre as partes, sujeita a orçamento prévio.				Até 5 (cinco) dias úteis para avaliação e acordo.	Acordado entre as partes (varia conforme complexidade da solicitação).

¹ O período de deslocamento (se necessário) não está incluso no prazo definido no SLA.

² Apenas pode ser solicitado pelo gestor do contrato/preposto da empresa.

20.6.1 – Na hipótese do contratante necessitar do desenvolvimento de novas rotinas nos sistemas ou módulos e/ou funcionalidades não relacionadas no edital e termo de referência, ou mesmo treinamentos adicionais ou outros serviços acessórios não contemplados no presente Termo de Referência e Edital (SLA nível 5 – “novas solicitações”), a licitante vencedora deverá apresentar o orçamento para a prévia aprovação da contratante, com base aos custos incorridos para sua realização.

20.6.2 – A licitante vencedora deverá incluir os desenvolvimentos previstos no item anterior, caso aprovados e efetivados, como parte integral dos sistemas objeto do presente Termo de Referência, e devem garantir que suas funcionalidades estejam cobertas pelo valor do contrato de locação e manutenção, não podendo ser exigido nenhum acréscimo adicional nestes valores.

20.6.3 – É garantida justificativa pela licitante vencedora de atraso aos prazos estabelecidos no SLA em casos específicos, descritos abaixo:

A – Problemas de infraestrutura e configurações no contratante.

B – Má identificação ou qualificação do problema quando da abertura do chamado técnico.

C – Indisponibilidade dos funcionários da contratante quando necessário. D – Atrasos na validação de chamados quando necessário.

E – Situações de força maior que impeçam o atendimento dentro do prazo estipulado.

21 - Nos preços ofertados deverão estar incluídas todas as despesas referentes às etapas de trabalho previstas neste Termo de Referência.

22 – A licitante vencedora deverá disponibilizar script que permita a realização de “Cópias de Segurança” dos dados, com o banco de dados em utilização, mediante solicitação da contratante.

22.1 - A empresa vencedora deverá efetuar semanalmente um backup de toda base de dados e da aplicação utilizada em Mogi Mirim e armazenar em um ambiente seguro. O local de armazenamento será de responsabilidade da licitante vencedora e os critérios deverão ser definidos em conjunto com a contratante, que terá acesso as cópias quando julgar necessário.

22.2 – É de responsabilidade da licitante vencedora a configuração dos ambientes servidores e estações de trabalho, ou seja, toda atualização deve ser dada pela empresa vencedora.

23 - A contratante fornecerá todas as informações e esclarecimentos referentes ao objeto desta licitação, devendo os pedidos serem formulados pela licitante, por escrito e protocolados no órgão competente em até 5 (cinco) dias úteis antes da data fixada para a realização do certame. Após esse prazo subentende-se que as informações e elementos técnicos fornecidos são suficientemente claros e precisos para possibilitar a apresentação dos documentos e a elaboração das propostas, não cabendo à licitante direito a reclamações posteriores.

24 – A licitante vencedora deverá fornecer, no ato da assinatura do contrato, o dicionário de dados, no qual deverão constar os nomes de todas as tabelas que compõem o sistema, e para cada uma delas, os nomes de todos os campos com suas respectivas descrições detalhadas. Também deve ser fornecido o diagrama do modelo entidade relacionamento (conceitual, lógico e físico) contendo todos os relacionamentos (chave primária X chave estrangeira) entre as entidades que compõe a estrutura da base de dados, bem como sua relação de cardinalidade.

25 - Não haverá limite para o numero de usuários dos sistemas e não poderá incidir cobrança sobre o número de usuários ativos que utilizam os produtos objetos deste Termo de Referência.

26 – Será disponibilizado aos interessados a oportunidade de realizar visita técnica aos setores e departamentos, de maneira a possibilitar às licitantes informações de cunho técnico para a realização da implantação, treinamentos e preparação do sistema de forma a possibilitar a quantificação de serviços necessários e auxiliar na elaboração de proposta de preços futuramente apresentada.

26.1 – A realização da visita técnica aos setores e departamentos não será obrigatória para participação do certame licitatório.

27 - Tendo a Comissão de Licitação finalizado o processo de apuração da classificação das empresas participantes fica obrigada, sob pena de desclassificação, a empresa mais bem classificada a executar nas dependências da contratante, demonstração prática de todos os sistemas, com utilização de software e equipamentos próprios simulando o ambiente de trabalho.

27.1 – Esta demonstração fica previamente marcada para o segundo dia útil seguinte à apuração desta classificação.

27.2 - O proponente deverá utilizar software e equipamentos próprios e muni-los com todos os dados e programas, inclusive o Banco de Dados Oracle. Não será permitido reinstalar quaisquer softwares, ou novas versões, ou auxiliares, depois de iniciada a demonstração.

27.3 -Não será permitida nenhuma alteração ou inclusão nos programas após o início da demonstração.

27.4 A demonstração será realizada em local designado e preparado pela contratante e terá início às 09:00 horas, obedecendo a seguinte ordem:

1.SISTEMA DE TRIBUTAÇÃO MUNICIPAL E ARRECADAÇÃO

2.SISTEMA DE CONTROLE DE PROTOCOLO

3.SISTEMA DE CONTABILIDADE, ORÇAMENTO PÚBLICO E TESOURARIA.

4.SISTEMA DE ADMINISTRAÇÃO DE COMPRAS, LICITAÇÕES E CONTRATOS:

5.SISTEMA DE ADMINISTRAÇÃO DE MATERIAIS (ALMOXARIFADO)

6.SISTEMA DE ADMINISTRAÇÃO DO PATRIMÔNIO

7.SISTEMA DE ADMINISTRAÇÃO DE PESSOAL

8.SISTEMA DE CONTROLE DE PONTO ELETRÔNICO

9.SISTEMA DE RECURSOS HUMANOS

10.SISTEMA DE GERENCIAMENTO DE DESPESAS

11.SISTEMA DE SERVIÇOS VIA WEB

12.SISTEMA DE CONTROLE DE FROTA

13.SISTEMA DE SANEAMENTO BÁSICO

14.SISTEMA DE ATENDIMENTO AO CIDADÃO

15.SISTEMA DE COLETA DE DADOS, IMPRESSÃO E ENTREGA SIMULTÂNEA DE CONTA DE ÁGUA E NOTIFICAÇÕES

27.5 A Comissão de Licitação poderá, a seu critério, utilizar profissionais especializados em cada área, como equipe de apoio, para prestar assessoria na avaliação das demonstrações.

27.6 A infraestrutura básica para demonstração dos sistemas (local, energia elétrica, iluminação e climatização) será disponibilizada pela contratante e as demais

estruturas (cabeamento, projetores, extensões, telas, periféricos) devem ser disponibilizados pelo proponente.

27.6.1 – A voltagem disponibilizada na demonstração será 110v.

27.7 – Após a demonstração, a Comissão de Licitações solicitará, a seu critério, ao proponente a execução de funções específicas, visando à comprovação de pleno atendimento ao Termo de Referencia do Edital (Anexo I) .

27.8 – Caso o Proponente deixe de demonstrar o desempenho de qualquer um dos sistemas de acordo com as especificações definidas neste edital, será desclassificado. Neste caso a próxima empresa da lista de classificação será convocada para realizar a mesma demonstração nas mesmas condições no segundo dia útil seguinte a este parecer, e assim sucessivamente.

27.9 - As despesas decorrentes das demonstrações definidas neste item correrão por conta do proponente.

28 – O prazo para operacionalização dos sistemas pela licitante vencedora será no dia 01/12/2015, sendo que somente será permitida a prorrogação desde prazo por necessidade e solicitação expressa da contratante através do gestor do contrato. Nesta data todos os sistemas deverão estar convertidos, testados, implantados e os usuários treinados e aptos a operá-los.

28.1 – A licitante vencedora apresentará para a gestão do contrato e demais interessados, cronograma contendo todas as etapas da implantação dos sistemas e responsáveis pela implantação, visando o atendimento do prazo estipulado.

28.1.1 – As etapas previstas devem estar em consonância com o prazo estipulado para implantação dos sistemas. A contratante determinará equipe técnica para supervisionar, acompanhar e criticar as etapas previstas e a licitante vencedora deverá ajustar as etapas de forma a melhor atender a necessidade da contratante.

28.1.2 – A licitante vencedora deverá informar imediatamente a gestão do contrato caso encontre qualquer situação que possa refletir no não cumprimento adequado das etapas apresentadas no cronograma

28.1.3 – O cronograma respeitará os horários de trabalho da contratante.

28.2 – O cronograma pode ser acordado e alterado no momento da apresentação, contudo, não poderá ultrapassar a data definida para operacionalização dos sistemas.

28.3 – As recomendações técnicas para utilização do sistema, caso não aceitas pela equipe de trabalho da contratante, deverão ser reportadas à gestão do contrato para providências imediatas, uma vez que podem impedir o atendimento do prazo acordado para operacionalização dos sistemas.

28.4 – O acompanhamento da utilização dos sistemas deverá seguir imediatamente a operacionalização dos sistemas e terá duração mínima de 30 dias.

28.4.1 – O acompanhamento deverá suprir os usuários com informações e dúvidas pertinentes.

29 – A proponente vencedora deverá manter versões das aplicações que atendam a legislação vigente, promovendo atualizações em tempo hábil para cumprimento das obrigações legais. Na necessidade de desenvolvimento de novas rotinas e funcionalidades, ou alterações na estrutura dos sistemas objeto desta licitação, treinamentos adicionais ou outros serviços não contemplados neste edital, a licitante vencedora deverá apresentar orçamento para prévia aprovação da contratante.

30 – Todos os equipamentos necessários para atender as especificações do Edital e Termo de Referência, serão fornecidos pela contratante e disponibilizados para configuração caso necessário, sem custos adicionais à contratante.

30.1 – Os equipamentos que vierem a ser adquiridos pela contratante na duração do contrato deverão ser homologados pela licitante vencedora. A homologação ocorrerá antecipadamente à aquisição dos equipamentos. Essa homologação não poderá acarretar ônus à contratante.

31 - RELAÇÃO DOS SISTEMAS OU MÓDULOS OBJETO DESTE TERMO DE REFERÊNCIA

A Prefeitura Municipal de MOGI MIRIM, através do presente termo de referência, apresenta a relação de sistemas ou módulos aplicativos que deverão ser contratados:

PARA USO DA PREFEITURA MUNICIPAL DE MOGI MIRIM

Dotações Orçamentárias: 012202.04123.03202.176.3390.3900 – Ficha 00833

ITEM	SISTEMAS E MÓDULOS
1.	Sistema de Tributação Municipal. Gestão de Cadastro Imobiliário, Gestão de Cadastro Mobiliário, Gestão de Taxas, Gestão do ITBI, Gestão do IPTU, Gestão do ISSQN, Gestão da Dívida Ativa, Gestão de Receitas Diversas, Gestão de Arrecadação, Gestão de Fiscalização, Gestão da Contribuição de Melhoria.
2.	Sistema de administração de compras, licitações, Gestão de contrato, pregão presencial registro de preço.
3.	Sistema de Controle de Almoxarifado Distribuição de Materiais
4.	Sistema De Contabilidade Pública, Orçamento, Tesouraria, Execução Orçamentária, Audesp, PCASP. PPA.
5.	Sistema De Controle De Patrimônio Público
6.	Sistema De Controle De Protocolo e Encaminhamentos WEB
7.	Sistema De Administração de Pessoal Folha de Pagamento, Modulo de Benefício I

	Ficha de registro, controle de autônomos e Pis / Pasep, Vale transporte
8.	Sistema De Recursos Humanos, Estrutura do quadro Funcional, Recrutamento e Seleção, Treinamento e Desenvolvimento, Cargos e Salários, Contencioso Trabalhista Segurança do Trabalho, Medicina do Trabalho Perfil Profissiográfico.
9.	Sistema de Ponto Eletrônico WEB
10.	Sistema de Administração de Custos e Despesas
11.	Sistema de controle da Frota
12.	Sistema para serviços Online.

PARA USO DO SERVIÇO AUTÔNOMO DE ÁGUA E ESGOTO DE MOGI MIRIM

Dotações Orçamentárias:

030201.1751202024.202-3390.3900	FICHA: 00017
030202.1751202034.203-3390.3900	FICHA: 00025
030203.1751202044.204-3390.3900	FICHA: 00032
030204.1751202054.205-3390.3900	FICHA: 00044

ITEM	SISTEMAS E MÓDULOS
1.	Sistema de administração de compras, licitações, Gestão de contrato, pregão presencial registro de preço.
2.	Sistema de Controle de Almoxarifado Distribuição de Materiais
3.	Sistema De Contabilidade Pública, Orçamento, Tesouraria, Execução Orçamentária, Audesp, PCASP. PPA.
4.	Sistema De Controle De Patrimônio Público
5.	Sistema De Controle De Protocolo e Encaminhamentos WEB
6.	Sistema De Administração de Pessoal Folha de Pagamento, Modulo de Benefício I Ficha de registro, controle de autônomos e Pis/Pasep, Vale transporte
7.	Sistema De Recursos Humanos, Estrutura do quadro Funcional, Recrutamento e Seleção, Treinamento e Desenvolvimento, Cargos e Salários, Contencioso Trabalhista Segurança do Trabalho, Medicina do Trabalho Perfil Profissiográfico.
8.	Sistema de Ponto Eletrônico WEB
9.	Sistema de Saneamento Básico Gestão de Faturamento, Gestão de arrecadação e cobrança. Gestão Controle da Dívida Ativa, Gestão Micro–medição (Hidrometria),

	Gestão Contribuição de Melhorias; Gestão de Balcão de Atendimento, Gestão de Controle de Corte; Gestão de Segurança.
10.	Sistema de Atendimento ao Cidadão (0800 Ouvidoria) Registro de atendimento Balcão e Telefônico, Controle e Execução de Ordens de serviços internas e Externas, Execução de Ordem de serviço em coletor de Dados, Controle de serviços por equipe de atendimento e execução para Saneamento
11.	Modulo de Leitura e entrega Simultânea de contas e execução de ordem de serviço vistoria e Corte.
12.	Sistema de Administração de Custos e Despesas
13.	Sistema de controle da Frota
14.	Sistema de Serviços Online com hospedagem do Web Site

2. SISTEMA DE TRIBUTAÇÃO MUNICIPAL E ARRECADAÇÃO Características

1. O Sistema deverá possuir as seguintes características gerais:

• Modular: os módulos de I.P.T.U., ISSQN e receitas diversas poderão operar independentemente.

• Integrado: os módulos poderão ser operados de forma que as pesquisas, baixas, Divida Ativa e etc., comporão um único banco de dados.

• Fonetizado: as consultas cadastrais deverão ser feitas usando pesquisa fonética.

• Simulativo: os cálculos dos tributos deverão ser feitos de forma simulada para verificação prévia da receita, sem limite de simulações diferenciadas.

• Alteração de telas cadastrais: as telas cadastrais poderão ser alteradas em função de novos campos que eventualmente sejam necessários. Este procedimento deverá ser feito através de parametrização do sistema, por um usuário cuja permissão de acesso assim o permita, sem a necessidade de alteração de programas.

2. Deverá possui os seguintes recursos:

• Gerador de relatório.

• Gerador de arquivos.

• Gerador de documentos.

• Gerador de documentos com código de barras para cobrança.

3. O cálculo deverá ser totalmente parametrizável pelo próprio usuário e permitir o atendimento integral do código tributário do Município.

4. Deve haver um único cadastro de pessoas (contribuintes, empresas), independente dos tributos tratados pelo sistema.

5. Todos os módulos devem possuir auditoria das transações realizadas, com identificação do responsável, data, hora e o conteúdo da informação.

6. As telas de aplicação devem ter a opção de impressão do seu conteúdo.

7. Todos os módulos devem possuir meios de registrar históricos diversos.

8. Xxxxx possuir consulta da posição financeira consolidada, por contribuinte e por Grupo econômico.

9. O Sistema deverá possibilitar a emissão de Guias de cobrança de todos os tributos por ele tratados.

10. Deve dispor de meios de seleção de grupos de contribuintes para que possam ser efetuadas simulações de cálculos ou recálculos.

11. Recálculo de todos os tributos, com o registro do responsável, data e hora (auditoria).

12. O sistema deve possuir recurso para a geração de arquivos textos para impressão externa (em gráfica) de documentos tais como:

• Lançamentos anuais.

• Documentos para cobrança amigável e posterior execução fiscal.

13. Emissão de 2. Vias de cobrança de todos os tributos, com o registro da identificação do responsável pela emissão, a data e hora da ocorrência da mesma (auditoria).

14. Manter controle de registro das notificações de documentos expedidos para os contribuintes.

15. Permitir que as auditorias possam ser extraídas e armazenadas em meio magnético externo.

16. Relatórios / consultas de acompanhamento fiscal do ISSQN Mensal, tais como:

• inadimplentes;

• adimplentes

17. Tratamento de valorização e depreciação (terreno e construções) conforme código tributário vigente, segundo fatores armazenados em tabelas próprias.

18. O Sistema deverá possuir tabela que armazene os dados necessários para que efetue a pontuação da construção de acordo com a lei em vigor.

19. Todos os relatórios devem ter opção para serem impressos ou gravados em arquivos.

20. Permitir o cadastro de tipos diferentes de endereços para entrega

21. Permitir determinar o Grupo Econômico

Imobiliário

22. Deverá permitir a criação e manutenção da base de dados imobiliários (arquivos de imóveis, faces de quadras e logradouros).

23. O Sistema deverá calcular os lançamentos anuais de Impostos e taxas anexas, segundo parametrização estabelecida pelo usuário.

24. Deverá permitir a revisão e recálculo de lançamento de forma individualizada.

25. Deverá emitir 2as. vias de carnês com atualização dos valores por atraso, imprimindo opcionalmente apenas as parcelas não pagas.

26. Deverá permitir simulações de cálculos apurando totais e estatísticas de lançamento.

27. O Sistema deverá possuir cadastros de:

• Logradouros: contendo todos os logradouros oficiais e não oficiais do município, com informações de Ceps e Bairros.

• Face de Quadra: contendo informações de equipamentos urbanos, serviços disponíveis, equipamentos mobiliários para valorização dos imóveis. Os

Logradouros correspondentes deverão ser determinados pelo lado da quadra.

• Imóveis: contendo todos os campos que constam no boletim de cadastramento do município.

28. Permitir o cadastramento de mais de um proprietário ou mais de um compromissário para um mesmo imóvel.

29. Registrar todas as testadas de um lote.

30. Registrar a área do terreno do lote assim como a área do terreno das unidades para condomínios.

31. O Sistema deverá efetuar o cálculo automático do coeficiente de fração ideal para condomínios verticais e horizontais.

32. O sistema deverá verificar, ao término do cadastramento das unidades de um determinado condomínio, se a soma das áreas destas unidades coincide com a área total informada para aquele condomínio.

33. O Sistema deverá armazenar as características de terreno e construções.

34. O Sistema deverá armazenar as características para pontuação de cada imóvel. Através desta pontuação, o sistema deverá ser capaz de atribuir, ao imóvel, a categoria correspondente.

35. Possuir procedimento para a realização de desdobramento de lote.

36. Permitir o registro de unificação de lotes; com processo exclusivo para a junção.

37. Permitir o controle de imóveis com isenções.

38. Permitir o tratamento de concessão de benefícios, registrando e efetuando os mesmos nos lançamentos correspondentes.

39. Permitir selecionar endereço para correspondência diferenciada por imóvel.

40. Manter informações cadastrais de vários exercícios para um mesmo imóvel.

41. Fórmula de cálculo, parametrizável de forma compreensiva, com tratamento de todos os fatores de depreciação e valorização citado no código tributário. Deve possibilitar ainda tratamentos especiais para descontos sobre o imposto em função de dados cadastrais ou valor venal.

42. Recálculo dos lançamentos com tratamento de compensação dos valores pagos na substituição da conta, gerando novo lançamento com os valores complementares.

43. Permitir realizar consultas no Cadastro Imobiliário por:

• Fonética pelo Nome de proprietário.

• Fonética pelo Nome do compromissário.

• Inscrição Cadastral

• Inscrição Cadastral anterior

• Endereço do imóvel

• Quadra e Lote

• Face de quadra.

44. O sistema deverá armazenar o histórico de todos os cálculos efetuados.

45. O sistema deverá possibilitar consulta da posição financeira segundo os seguintes filtros:

• Código do contribuinte

• Endereço do imóvel

• Identificação do lançamento

• Identificação do parcelamento

• Inscrição cadastral

• Inscrição da dívida ativa

• Nome do proprietário

• Nome do compromissário

46. Relatórios:

• Relação dos logradouros

• Relação das faces de Quadras

• Ficha cadastral

• Controle de cadastramento, contendo totais de lotes, m2 de área e testadas pelas divisões do município.

• Relação dos Isentos.

• Estatística dos Dados cadastrais.

• Perfil do contribuinte.

• Posição Financeira.

47. Sobre os cálculos e simulações:

• Demonstrativo do cálculo para conferência.

• Análise do calculo.

• Rol de cálculo.

• Estatística de cálculo.

• Rol analítico de contribuintes por endereço.

• Rol de Valores Venais.

• Rol de lançamentos.

• Posição de lançamentos por região.

• Estatística de Lançamento.

48. Emissões de Guias(2.Vias)

49. Emissões de Guias por Grupos de lançamentos.

50. Documentos Diversos/ Certidões.

51. Relatórios ITBI:

• Histórico de transações imobiliárias.

• Relação por Adquirente.

• Relação por Transmitente.

• Relação por Inscrição Cadastral.

Mobiliário

52. Deverá permitir a informação e manutenção da base de dados dos contribuintes mobiliários e seus respectivos sócios;

53. O sistema deverá calcular o lançamento anual do ISS Fixo(anual) e das taxas anexas.

54. Deverá emitir carnês para ISS Mensal.

55. Deverá permitir a correção e recálculo de forma individualizada.

56. O sistema deverá emitir 2as. Vias de carnês com devido cálculo dos encargos por atraso, com opção para impressão apenas das parcelas não pagas.

57. Deverá possibilitar a realização de simulações das formas de lançamentos.

58. O módulo de ISS deverá permitir o cadastramento de contribuintes qualificados segundo a atividade exercida, inclusive com data retroativa para a cobrança de ISS e taxas.

59. O módulo deverá possibilitar a geração de lançamentos retroativos, conforme a data de início da atividade.

60. É necessário a existência de um procedimento que trate a baixa de uma empresa, efetuando os devidos cancelamentos de lançamentos a partir do período da data de encerramento das atividades da mesma.

61. Os lançamentos deverão ser parametrizados pelo próprio usuário. A ele deverá ser permitido registrar as fórmulas de cálculos a serem aplicadas nos respectivos lançamentos.

62. Permitir a emissão de guias para contribuintes que residam fora do município. O sistema deverá armazenar os dados cadastrais do mesmo, assim como o serviço prestado e a alíquota a tributar.

63. Permitir que se registre os valores bases para o recolhimento do ISS. Permitir também que sejam registradas as retenções de ISS.

64. Permitir registrar a forma de recolhimento praticada: por pagamento, comunicação de isenção, sem movimento ou recolhimento em outro município.

65. Emitir guias de recolhimentos para serviços eventuais dos contribuintes do Município e de fora do município.

66. Emitir guias de tomadores dos contribuintes do município e de tomadores de fora do Município.

67. Emitir guias de recolhimentos para pessoa física.

68. Para análise e comparativo fiscal, o sistema deverá emitir relatório composto de valores base e valores arrecadados, mês a mês com opção de escolha de período ou períodos.

69. O Sistema deverá possuir escrituração de notas ficais de contribuintes residentes ou não no município e de tomadores de serviços.

70. Dispor de rotinas exclusivas para tratar contribuintes optantes do Super Simples Nacional.

71. Permitir realizar consultas no Cadastro por:

• Razão Social (pesquisa fonética).

• Endereço do estabelecimento.

• Documento (CPF/CNPJ/CCM).

• Atividade.

• Serviço.

• Sócios.

• INSCRIÇÃO MUNICIPAL.

72. O sistema deverá permitir a realização de cálculos, recálculos e simulações.

73. Posição financeira, localizar o contribuinte por:

• Documento.

• Endereço do estabelecimento.

• Identificação do lançamento.

• Identificação do parcelamento.

• Inscrição Municipal.

• Razão Social / Nome Fantasia.

• Atividade.

74. Emissão de Guias(2.vias).

75. Emissão de Guias por grupo de lançamento.

76. Emissão de guias de Recolhimentos:

• Prestadores e Tomadores Eventuais

• Dos contribuintes de fora do Município

• Das pessoas físicas.

77. O sistema deverá possuir, no mínimo, os seguintes relatórios gerais:

• Cadastro de atividades.

• Cadastro de serviços.

• Tipos de parâmetros.

• Tipos de contribuintes.

• Cadastro de Gráficas.

• Relação dos contribuintes por atividade.

• Relação dos contribuintes por tipo de serviço.

• Declaração cadastral.

• Relação dos contribuintes ativos (sintético e analítico).

• Relação dos contribuintes com isenções.

• Posição Financeira.

• Ficha Cadastral.

• Perfil do cadastro econômico.

• Perfil do contribuinte.

• Extrato dos recolhimentos.

78. O sistema deverá possuir os seguintes relatórios, referentes a cálculos e simulações:

• Rol analítico dos lançamentos por atividade.

• Demonstrativo do cálculo para conferência.

• Análise do calculo.

• Análise dos lançamentos

• Estatística de cálculo.

• Estatística dos lançamentos.

• Rol de cálculo.

• Rol dos lançamentos.

79. Os seguintes documentos deverão ser emitidos pelo sistema:

• Emissão de Alvarás

• Emissão de certidões

• Emissão de documentos para os contribuintes por contador.

Fiscalização

80. Permitir cadastrar os tipos de Autos de infrações previstos no código tributário e leis complementares, assim como cadastrar os autos realizados por Fiscais em diversos departamentos. Deverá também manter o controle de cobrança, notificação, inscrição em dívida ativa e ajuizamento dos autos.

81. Deve possibilitar manter um cadastro dos fiscais de renda.

82. O sistema deverá possuir um cadastro de gráficas autorizadas a imprimir Talões de Notas Fiscais.

83. Registrar as autorizações de:

• Notas Fiscais

• Livros Fiscais

• Equipamentos de Cupons Fiscais.

84. Registrar as comunicações de Notas Fiscais extraviadas.

85. Registrar o período Fiscalizado.

86. Programação para ações Fiscais: deverá possuir rotinas que permitam selecionar empresas para as ações fiscais, por logradouro, contribuintes sem recolhimento, maiores contribuintes, por tipo de atividade, por tipo de prestação de serviço ou período da última fiscalização.

87. O sistema deverá permitir o registro do levantamento Fiscal para posterior análise e lançamento de diferença de recolhimento.

88. Emitir Nota Fiscal Xxxxxx, com geração de guia para recolhimento.

89. Emitir a guia de Auto, com cálculo de todos os encargos.

90. Permitir parcelamento dos Autos de infrações.

91. Permitir atualizar Faturamento, gerando recolhimentos devidos num período de competência.

92. Disponibilizar mecanismo para compor o I.S.S. devido e efetuar parcelamento dos impostos.

93. Permitir realizar consultas:

• Posição financeira dos débitos.

• Posição dos Autos de infrações por Fiscal, por Infrator.

• Posição dos Autos por tipo de Auto.

• Posição das ações Fiscais (Razão social ou inscrição Municipal).

• Alvarás concedidos (Razão social ou inscrição Municipal).

94. Relatórios:

• Relação dos Autos de Infrações, permitir selecionar por: Fiscal, infrator, tipo de Autos, número dos autos e por estágio de cobrança.

• Comparação entre os recolhimentos efetuados e os valores das notas fiscais correspondente, no período.

• Comparativo de recolhimentos entre períodos.

• Nota de débitos por auto.

• Relação dos contribuintes de maior recolhimento.

• Relação de notas fiscais escrituradas

• Relação de Notas fiscais declaradas por tomadores.

• Extrato de Autos.

• Tipos de Infrações apuradas num período.

• Análise de notas fiscais declaradas como extraviadas.

• Estatística dos Autos.

• Estatística de recolhimentos

• Extrato de recolhimentos.

• Relação de notas não declaradas.

• Contribuintes que efetuaram declaração com atraso.

• Contribuintes que nunca efetuaram declaração de Iss.

• Grade de valores mensais arrecadados em um período.

• Posição de empresas fiscalizadas por auditor.

• Emissão de Guias (2.vias).

Contribuição de Melhorias

95. Deverá manter a base de dados de editais e contribuintes. A partir dos dados dos editais: compor o cadastro dos contribuintes beneficiados pela melhoria; calcular os lançamentos e permitir a impressão das guias de cobrança. Deverá possibilitar a geração de várias modalidades de pagamento previstas na lei, controlando o pagamento das contas, conforme opção escolhida pelo contribuinte.

96. Consultas da posição financeira:

• Por identificação.

• Por nome.

97. Relatórios:

• Rol de lançamentos.

• Estatística de cálculo.

Receitas Diversas

98. O sistema deverá ser parametrizado, de modo a permitir o cálculo e lançamento dos vários outros tipos de taxas e preços cobrados pelo município. Deverá

dispor de opções para cadastramento de contribuintes no ato da emissão do respectivo lançamento (atendimento de balcão) ou para formação de base de dados para lançamento periódico (ex.: anual).

99. Permitir realizar consultas no Cadastro Mobiliário por:

• Fonética por nome.

• Identificação.

100. O sistema deverá permitir a realização de cálculos / recálculos e simulações.

101. Posição financeira, localizar o contribuinte por:

• Endereço.

• Identificação do Lançamento.

• Identificação do parcelamento.

• Identificação.

• Fonética por nome.

102. Relatórios: Relação dos contribuintes.

103. Relatório referente aos cálculos e simulações:

• Demonstrativo do cálculo para conferência.

• Rol de lançamentos.

• Estatística de cálculo.

Controle de Arrecadação

104. Permitir manter “Unidades” de moedas diversas.

105. O sistema deve permitir atualização monetária por índices diferenciados a serem definidos a cada tributo.

106. Manter cadastro de: bancos, agências e contas arrecadadoras.

107. Deverá utilizar os recursos de leitura ótica de códigos de barra para maior facilidade e precisão na coleta de dados.

108. Deverá dispor de rotinas para tratamento do retorno de pagamento via meio magnético padrão FEBRABAN.

109. Deverá dispor de rotinas para tratamento do retorno de pagamento via meio magnético de cobrança Bancária, especificamente: Santander, Banco do Brasil e Caixa Econômica Federal.

110. Deverá dispor de rotinas para débito automático em conta corrente segundo o padrão FEBRABAN.

111. Deverá dispor de consultas à posição financeira com atualização dos acréscimos legais aos débitos.

112. Manter uma tabela de feriados.

113. Deverá permitir efetuar o registro das baixas de forma que fique identificado o tipo da baixa efetivamente praticado: pago, cancelado, prescrito, remido...

114. Deverá permitir estornos e devoluções de receitas.

115. Verificar, para lotes de baixas, a igualdade da somatória dos valores dos documentos com o total informado, indicando eventual divergência.

116. Baixas de retorno por meio magnético: deverá disponibilizar tratamento de rejeição de baixas pelo limite de diferença entre o valor devido e o valor autenticado do documento. O movimento rejeitado deverá ser gerado de forma que possa ser corrigido e reprocessado posteriormente. Quanto aos documentos normais, devem ser baixados independe da ocorrência de erros, no fechamento do lote.

117. Deverá manter um cadastro de receitas orçamentárias e extra-orçamentárias.

118. Deverá permitir o acompanhamento e a contabilização diária da arrecadação, emitindo relatório analítico para cada agente arrecadador, com a indicação de divergências de arrecadação.

119. Deverá integrar-se com o sistema de contabilidade pública, gerando todos os lançamentos contábeis resultantes da arrecadação. Deverá possuir rol analítico dos valores recebidos, classificado segundo as receitas envolvidas.

120. Consultas:

• Baixas não processadas

• Posição Financeira Imobiliário.

• Posição Financeira Mobiliário.

• Posição Financeira Receitas Diversas.

• Posição Financeira Pessoa.

• Posição Financeira Processo Judicial

• Posição Financeira Grupo Econômico

121. Relatórios:

• Análise da receita(Detalhada).

• Análise da receita(Total).

• Contas baixadas para análise de arrecadação.

• Contas Quitadas de um período.

• Débitos atualizados por conta.

• Extrato do contribuinte.

• Rol da Posição Financeira.

• Rol de arrecadação.

• Rol dos parcelamentos.

• Rol dos movimentos de baixa.

• Rol de valores recebidos e à receber.

Dívida Ativa

122. Deverá permitir a inscrição de débitos em Dívida Ativa com periodicidade definida pelo usuário.

123. Emitir o livro de inscrição em dívida ativa.

124. Permitir atualização com aplicação dos acréscimos legais aos débitos em inscrição.

125. Dispor de rotinas para parcelamento de débitos inscritos em dívida ativa.

126. Dispor de rotinas para tratamento de anistias.

127. Permitir gerar os avisos de cobrança amigável e judicial, dispor dos mesmos recursos de consulta já citados.

128. Dispor de rotinas de consulta com atualização de débitos que possibilitem informar ao contribuinte, o total de sua dívida consolidada e atualizada.

129. Consultas:

• Certidões de Dívida Ativa emitidas.

• Posição Financeira Imobiliário.

• Posição Financeira Mobiliário.

• Posição Financeira Receitas Diversas.

• Posição Financeira Pessoa.

• Posição Financeira Processo Judicial

• Posição Financeira Grupo Econômico

130. Relatórios:

• Livro de inscrição da Divida Ativa.

• Rol de Inadimplentes.

• Rol dos contribuintes inscritos em Dívida Ativa.

• Rol das contas quitadas de um período.

• Débitos atualizados por conta.

• Extrato do contribuinte.

• Rol dos parcelamentos.

• Sintético da Dívida Ativa por Exercício.

• Síntese dos valores baixados de um período – Dívida Ativa.

• Devedores não inscritos na Dívida Ativa, por grupo de lançamento.

• Estatística sobre cobrança amigável.

• Rol do Montante da dívida ativa.

• Relação dos maiores devedores.

• Posição dos valores inscritos na Dívida Ativa por código orçamentário.

• Rol dos valores recebidos e à receber.

131. O Sistema deverá fornecer:

• Certidão Negativa de débitos.

• Certidão positiva de débitos.

• Certidão positiva com efeito negativo de débitos.

• Certidão de dívida ativa.

• Notificação de débitos - Cobrança amigável.

• Notificação com boleto bancário – cobrança amigável.

• Extrato de débitos.

• Execução Fiscal - contra fé/mandados/citação.

• Petições.

Segurança

132. O Sistema deverá possuir total controle de senhas que permita liberar ou bloquear acesso a um determinado módulo. Em cada um destes módulos, a segurança deverá permitir ou não o acesso a nível de tela, campos e procedimentos.

133. O Sistema deverá registrar todas as transações de manutenções, fornecendo:

• Situação anterior.

• Situação atual.

• Quem executou.

• Data e Hora da alteração.

3. SISTEMA DE SANEAMENTO BÁSICO

A seguir estão enumerados os requisitos necessários que devem fazer parte do sistema proposto:

a. Leitura:

i. O Sistema deverá disponibilizar as duas seguintes formas de trabalho: leitura convencional e leitura com emissão simultânea de conta.

ii. O Sistema deverá gerar arquivos a serem utilizados nas leituras dos hidrômetros, por grupo e rota de leitura. Deverá respeitar a sequência cadastrada ou, no caso de não haver sequência, a classificação estabelecida pelo órgão.

iii. O Sistema deverá registrar, no momento da leitura, eventuais ocorrências referentes às validações efetuadas sobre a mesma. Estas ocorrências serão utilizadas posteriormente, após o retorno das informações ao sistema, para verificações e acertos.

iv. O Sistema deverá registrar as leituras das ligações.

v. O sistema deverá contar com procedimento específico para os casos em que a leitura tenha sido realizada há mais de 30 dias. Deverá calcular o valor do consumo correspondente a 30 dias, posicionando a leitura atual e consumo para o cálculo das contas.

vi. Deverá registrar as divergências encontradas em campo, qualificando-as de acordo com códigos cadastrados.

vii. O sistema deverá possuir relatórios que auxiliem na análise das informações coletadas.

viii. Permitir a descarga das leituras efetuadas por rota, não necessitando aguardar o término de todas as leituras para a importação no sistema.

ix. Registrar as ocorrências e/ou anormalidades identificadas pelos leituristas, em seu trajeto.

x. O Sistema deverá permitir a mudança automática do método de leitura convencional de para o método de leitura e emissão simultânea da conta, onde o cálculo e emissão de contas deverão ser processados no momento da leitura, através de microcomputadores portáteis, de acordo com tipo de cálculo estabelecido pelo órgão.

xi. O sistema deve permitir a inclusão de leituras manualmente, para casos de leituras informadas pelos contribuintes. Esta inclusão somente poderá ser efetuada antes do retorno das leituras da rota e/ou grupo. Para estas ligações, a leitura do leiturista será desprezada.

xii. Permitir o gerenciamento das atividades dos leituristas, através de relatórios gerenciais.

xiii. Permitir que a comunicação entre o coletor de leituras e a unidade central de processamento seja do tipo Wi-Fi,via protocolo TCP/IP, ou utilizando um berço (doca).

xiv. Todos os softwares de suporte e banco de dados adicionais necessários para o funcionamento do sistema deverão ser fornecidos pela contratada com suas respectivas licenças de uso.

xv. Os arquivos trocados entre o coletor de leituras e o Sistema de Saneamento Básico devem obedecer lay-out definido pelo órgão, obrigatoriamente compatível em todos os níveis com o Sistema de Saneamento Básico.

xvi. O Sistema de Saneamento Básico deverá conter procedimento de geração do arquivo para o Módulo de Leitura (convencional ou com emissão simultânea de conta);

xvii. O Sistema deverá conter procedimento de controle de distribuição, para o Módulo de Leitura, dos arquivos preparados na etapa anterior;

xviii. O Sistema deverá conter procedimento para o recebimento dos arquivos após a coleta das leituras;

xix. O Sistema deverá conter relatórios gerenciais que permitam o acompanhamento da atividade de leitura, fornecendo informações tais como: quantidade de leituras realizadas por leiturista; horário de realização das leituras; nome do leiturista; intervalo de tempo entre leituras.

xx. O sistema deve permitir a parametrização de códigos de ocorrência, para os quais, no momento do lançamento, seja exigida a captura da imagem (fotografia comprovando o lançamento do código de ocorrência.)

xxi. O sistema deverá ser capaz de estabelecer o vínculo das fotografias, provenientes dos coletores de dados, ao respectivo CDC (código de cadastro do consumidor).

xxii. O Módulo de Xxxxxxx deverá permitir a mudança de leiturista a qualquer tempo.

xxiii. O Módulo de Leitura deverá validar a informação registrada, em tempo real. As ações a serem estabelecidas para cada tipo de ocorrência, durante o registro da respectiva leitura, deverão ser parametrizadas. Exemplo: supondo uma situação em que o leiturista registrou o fato de ter se deparado com o portão do imóvel fechado, impedindo a realização da leitura (ocorrência = “portão fechado ou hidrômetro inacessível”). Para um caso semelhante a este, o programa não deverá permitir o registro de leitura, de acordo com parametrização realizada para este tipo de ocorrência.

xxiv. Deverá possuir parâmetro que oriente o leiturista na verificação do número do lacre dos hidrômetros.

xxv. Deverá possuir parâmetro para obrigar o registro de leitura ou código de leitura / ocorrência, antes de prosseguir ao próximo imóvel / leitura.

xxvi. Deverá possuir parâmetro que, quando acionado, implique na geração de uma indicação de verificação para a condição de consumo maior ou menor que a média, mostrando o último consumo registrado e a média habitual.

xxvii. O Sistema deverá fornecer informações que possibilitem a análise das leituras com consumos considerados altos ou baixos. Estas informações serão fundamentais para a realização de ajustes necessários nas respectivas contas, com acréscimos e decréscimos de consumo, ou outras situações identificadas pelo sistema.

xxviii. A análise ou crítica de consumo deverá ser efetuada em tela própria ou através de emissão de relatórios, contendo no mínimo filtro por: grupo, referência, rota logradouro, tipo de crítica, consumo. Como resultado da seleção, deverão ser apresentadas, no mínimo, as seguintes informações: CDC, situação da ligação, percentual de variação, identificação, categoria e economia, leitura anterior, leitura atual, ocorrência de leitura, data de leitura, nome do leiturista.

xxix. O Sistema deverá permitir, durante a crítica da leitura em tela, a seleção de ligação para releitura ou vistoria e ainda a inclusão do status da crítica, como por exemplo: analisada, vista. Deverá possibilitar filtragem de seleção de registros através deste mesmo status.

xxx. O Sistema deverá permitir, durante a crítica, alterações da leitura, ocorrência e data da leitura. Deverá atualizar automaticamente o status da crítica, indicando que a mesma já foi verificada. Desta forma evitará que a leitura que seja verificada novamente.

xxxi. O Sistema deverá oferecer opção de impressão, em formulário próprio, das ligações selecionadas para releitura ou vistoria, para que seja dada continuidade ao processo de crítica da leitura.

xxxii. Deverá ainda ter a opção de marcar as ligações desejadas para a geração de ordens de serviço no Sistema de Atendimento ao Cidadão (que passará a acompanhar a execução das mesmas).

xxxiii. Durante a crítica de leitura em tela, deverão haver opções para a visualização do histórico da ligação e para a impressão do relatório contendo as informações da crítica de leitura.

xxxiv. O sistema deverá impedir a liberação do grupo para a continuidade do processo de leitura/cálculo enquanto todas as críticas registradas não tiverem sido verificadas. Deverá demonstrar em tela as quantidades pendentes de cada rota e as respectivas ligações.

b. Xxxxxxx e Emissão

i. O processamento do cálculo será sempre efetuado em microcomputadores instalados nos escritórios do órgão.

ii. As contas de água, esgoto e serviços, deverão ser providas com código de barras no padrão Febraban ou Cnab. Estas informações serão utilizadas para a baixa dos pagamentos, pelo processo de captura via leitura ótica (Scanner).

iii. A leitura, o cálculo, a emissão de contas e as demais rotinas associadas deverão ser executadas de forma assíncrona, por grupo. Porém, para cada grupo, o sistema deve controlar a seqüência lógica de realização de tarefas impedindo a execução de rotinas em desacordo com a mesma. Como exemplo, podemos citar a emissão de contas sem que a verificação das anomalias apontadas no cálculo tenham sido analisadas.

iv. O processamento de leituras de hidrômetros, cálculo e emissão das contas de água, esgoto e serviços deverá estar de acordo com a estrutura tarifária do órgão.

v. O sistema deverá disponibilizar procedimento de cálculo tarifário de consumo de água, resíduo de troca de medidores e lançamento pelo consumo taxado.

vi. Após efetuado o cálculo, o sistema deverá permitir a emissão local das contas de água, esgoto e serviços. Deverá possibilitar também a geração de arquivo com as informações necessárias, a ser encaminhado à empresa capacitada para esta emissão.

vii. A conta de água, esgoto e serviços deverá estar preparada para a inclusão de mensagens de débito de contas anteriores e também a emissão da declaração de quitação anual de débitos conforme determinado na lei 12.007/2009, de acordo com critérios estabelecidos pelo órgão.

viii. Deverá estar disponível após o cálculo a emissão do histograma de consumo.

ix. O Sistema deverá permitir o registro e manutenção dos roteiros e seqüências de leitura de hidrômetros e de entrega de contas; mostrando as informações atuais cadastradas, permitido a alteração para novas rotas e redefinindo a seqüência automaticamente das ligações alteradas, de acordo com os parâmetros estabelecidos pelo órgão.

x. Deverá ainda ser permitido a alteração de rotas por grupo, rota e logradouro sem que a seqüência seja afetada.

xi. O Sistema deverá ter opção de resequenciamento das rotas de leitura ou entrega por logradouro através de parâmetros definidos tais como: intervalo da seqüência, numeração do logradouro, lado da rua.

c. Arrecadação e cobrança

i. O Sistema deverá estar desenvolvido para realizar o controle da Arrecadação e Cobrança de forma regionalizada, utilizando os recursos de transferência dos dados por: meio eletrônico; captura do código de barras via Scanner ou caneta ótica; entrada de pagamentos via digitação em micro. Serão envolvidas contas de água, carnês, guias de recolhimento e outros documentos de recebimentos diversos que compõe a receita do órgão para atualização diária da cobrança.

ii. O processo de leitura do código de barras deverá incluir as contas impressas simultaneamente pelo Microcomputador

portátil e pelo método convencional, utilizando leitores de código de barras, caneta ótica ou outros recursos de leitura.

iii. O software para captura do código de barras deverá ter característica de multitarefa, gerenciando em tempo real as operações simultâneas de vários usuários e seus respectivos arquivos de armazenamento. O software ainda deverá evitar a perda de dados numa eventual falta de energia elétrica.

iv. O Sistema deverá estar preparado para efetuar o controle de arrecadação online, através de caixa autenticadora nas dependências do órgão, efetuando autenticação de documentos em impressora própria, ligada ao sistema e registrando as baixas dos documentos.

v. O Sistema deverá estar preparado para manter registradas e atualizadas as informações referentes aos pagamentos realizados na rede arrecadadora, contendo: a data do pagamento, o estabelecimento em que foi pago, valores recebidos, multas e outros encargos financeiros pertinentes, que dispostos na tela das estações de trabalho, ou em forma de relatórios com opção de vídeo, arquivo ou impressora, servirão de fonte de consulta pelo setor de Atendimento ao Cidadão. Deverá incluir os débitos referentes a contas de água e esgoto assim como a carnês de contribuição de melhorias, inscritos ou não em dívida ativa, identificando cada caso.

vi. O Sistema deverá permitir a recepção de pagamentos efetuados na rede bancaria, eletronicamente, em arquivos de acordo com padrão definido pela FEBRABAN ou Cnab, nas respectivas datas contábeis. Cada arquivo deverá compor um lote, permitindo consultas e geração de relatórios.

vii. A arrecadação deverá integrar-se com o Sistema de Contabilidade registrando automaticamente os valores da receita arrecadada nos módulos de Gestão Orçamentaria, Tesouraria e Contabilidade. Deverá gerar os respectivos relatórios analíticos. Deverá permitir a geração de relatórios referente à arrecadação, de acordo com as contas contábeis cadastradas pelo órgão.

viii. Deverá estar preparado para a geração de arquivos de cobrança das contas de água, esgoto e serviços por débito automático para a rede bancária de acordo com o padrão estabelecido pelo órgão.

ix. O Sistema deverá permitir o cadastro das contas contábeis do órgão, permitindo alterações de acordo com a necessidade. Deverá ainda haver, na composição do analítico da receita, a possibilidade de configuração da receita como normal, dívida ativa ou ambos.

x. O Sistema deverá permitir a identificação, de maneira seletiva, dos clientes inadimplentes para com o órgão, permitindo a emissão de comunicados de débitos, segundo critérios de seleção.

xi. O Sistema deverá permitir a identificação de clientes devedores, através da ligação, grupo, logradouro, categoria, vencimentos, meses pendentes, valores mensais e globais, disponibilizando a informação para as ações de regularização da carteira.

xii. O Sistema deverá estar preparado para a emissão das notificações de débito com código de barras. Deverá também efetuar o agrupamento das contas no momento da emissão das notificações.

xiii. O Sistema deverá permitir a manutenção nas notificações emitidas, permitindo cadastrar o status da entrega das mesmas.

xiv. O Sistema de Arrecadação e Cobrança deverá permitir a consulta de débitos e a Emissão de 2 ª vias de contas utilizando-se de tecnologia “WEB”.

d. Divida Ativa

i. O Sistema deverá permitir a inscrição de débitos vencidos referentes a Contas e Parcelas de Carnês, em Dívida Ativa, de acordo com a periodicidade estabelecida pelo órgão.

ii. A inscrição em dívida ativa dos débitos vencidos e não pagos deverá ser feita automaticamente pelo módulo que os seleciona, conforme os parâmetros estabelecidos pelo órgão. A composição do valor inscrito deverá ser o valor original das contas e parcelas dos carnês no momento da inscrição.

iii. O Sistema deverá ter a opção de inscrição individual de contas e parcelas de carnês em dívida ativa, permitindo para isto a seleção das contas/parcelas desejadas.

iv. Permitir a geração do livro de dívida ativa com as informações das contas/parcelas inscritas, determinando

número de livro, quantidade de páginas por livro, página inicial e demais informações pertinentes ao livro.

v. O sistema deverá permitir a seleção de contribuintes em débito, individual ou coletivamente, para emissão das notificações de dívida ativa.

vi. As notificações de dívida ativa poderão ser geradas com código de barras para pagamento, efetuando para este fim o agrupamento das contas no momento da emissão das notificações.

vii. O sistema deverá permitir a manutenção nas notificações emitidas pelo sistema, permitindo cadastrar o status da entrega das mesmas.

viii. Permitir o parcelamento do débito inscrito em dívida ativa, através de lançamento de serviço em conta ou emissão de carnê. Deverá efetuar a separação de valores para posterior identificação da receita referente à dívida ativa.

ix. Nos Carnês de pagamento deverão constar todas as características do débito, dados do consumidor, o valor inscrito em Dívida Ativa e ainda as atualizações dos valores originais através do cálculo dos juros, multas e correção monetária conforme critérios estabelecidos pelo órgão.

x. O sistema deve permitir a geração de carnês em moeda corrente ou índice, efetuando a atualização dos valores conforme a norma específicada.

xi. Deverá haver opção para atualização das parcelas dos carnês através de índice específico, efetuando a alteração dos valores das parcelas já geradas. Após a atualização deverão ser emitidas as parcelas para entrega aos consumidores.

xii. Deverá ser bloqueado pelo sistema o parcelamento em carnês de contas inscritas e não inscritas. Estes parcelamentos somente poderão ser efetuados separadamente.

xiii. Sistema deverá permitir a inclusão no carnê de serviços de honorários e custas processuais ou outros serviços de acordo com o estabelecido pelo órgão.

xiv. O sistema deverá estar preparado para emissão dos documentos necessários para a execução fiscal: certidão de dívida ativa e petição de acordo com os dados e modelos estabelecidos pelo órgão. Na emissão de certidão, o sistema

deverá automaticamente efetuar o bloqueio das contas. Deverá informar, no ato da consulta da ligação, a existência de contas em execução fiscal.

xv. Deverá ter a opção de geração de arquivo e emissão de relatório com as execuções fiscais, a serem entregues ao Fórum, de acordo com exigências da Prodesp. O sistema deve também estar preparado para recepcionar o arquivo de retorno do Fórum com as informações dos processos abertos.

xvi. O Sistema deverá permitir o acompanhamento mensal do saldo de dívida ativa. Deverá informar a composição dos valores mensais inscritos em dívida ativa, tais como: cancelamentos, inscrições, parcelamentos, reabertura de contas, receita e demais informações referentes à movimentação.

xvii. Para o acompanhamento do saldo da dívida ativa, o sistema deverá controlar automaticamente as datas de fechamento de cada mês. Este procedimento tem a finalidade de evitar a repetição de informações em função do eventual informe incorreto da data de fechamento mensal. Deverá também, apurar o saldo da dívida ativa, comparando-o com o saldo atualmente registrado no sistema, para que possa gerenciar quaisquer diferenças encontradas.

xviii. Os valores que compõem o saldo da dívida ativa deverão estar contidos em relatório analítico, a fim de que seja possível o acompanhamento da movimentação da dívida ativa realizada.

e. Micromedição (Hidrometria)

i. Para o módulo de Micromedição (hidrometria) o Sistema deverá estar preparado para gerenciar, de forma automática, todas as informações e dados históricos dos hidrômetros: instalados, retirados, recuperados e aferidos. Deverá registrar, de forma automática, os dados das ligações em que o hidrômetro está ou esteve instalado.

ii. Deverá ser mantida, através do modulo de Micromedição tabela com os dados dos hidrômetros instalados nas diversas ligações de água e dos mantidos em estoque, no mínimo com as seguintes informações: fabricante, vazão, quantidade de dígitos, diâmetro, fabricante, fornecedor, data e nota fiscal de aquisição.

iii. Deverão ser registradas, de forma automática, as datas de cada instalação/retirada, os cdc’s das instalações, as datas de registro de paralisação de cada hidrômetro assim como as ocorrências verificadas nos procedimentos de leitura para faturamento relativas aos hidrômetros. Esses registros devem estar disponíveis para consulta no cadastro do hidrômetro.

iv. Deverão ser registradas as trocas de hidrômetros efetuadas nas ligações, armazenando os dados da retirada e colocação. Somente poderão ser utilizados hidrômetros previamente cadastrados em tabela específica.

v. Nas trocas de hidrômetro, quando houver resíduo de consumo, o sistema deverá armazenar o resíduo para cobrança na próxima fatura junto com o consumo do novo hidrômetro.

vi. Deverá estar disponível opção de correção do número do hidrômetro, para os casos onde houve erro de cadastro, sem que esta alteração afete o consumo da ligação.

vii. O sistema deve disponibilizar opção de cadastro das aferições efetuadas, mostrando resultado em tela e emitindo o respectivo laudo.

viii. Deverá ainda ter opção de armazenamento de hidrômetros aferidos, indicando local e tempo que devem permanecer guardados.

f. Contribuição de Melhorias

i. O Sistema deverá utilizar, no módulo de Contribuição de Melhorias, o mesmo cadastro utilizado pelos sistemas de Faturamento e Arrecadação relativos a imóveis e terrenos.

ii. Para cada Edital de Contribuição de Melhorias o sistema deverá permitir o registro do ano, numero data e valor do edital, o tipo de rateio a ser adotado, as formas de parcelamento e os contribuintes beneficiados.

iii. O Sistema, a partir dos dados do edital, deverá efetuar para cada contribuinte o cálculo do valor devido, dividindo-o pelo numero de parcelas, estabelecendo assim seu valor e vencimento das parcelas e gerar o respectivo carnê de pagamento.

iv. Deverá ter opção para cancelamento do edital.

v. A rotina de associação de contribuintes a um determinado edital deverá contar com ferramentas que permitam a seleção dos mesmos por logradouro.

vi. O registro de pagamentos das parcelas dos Carnês de Contribuição de Melhorias deverá ser feito pelo sistema de Arrecadação conjuntamente com as Contas de Água e Esgoto e outros documentos de Arrecadação, contabilizando adequadamente as diversas receitas arrecadadas.

vii. Deverá estar disponível tela para consulta dos dados de cada contribuinte informando os dados do edital, do contribuinte, do carnê e dos pagamentos. As informações contidas nos carnês e nos pagamentos deverão estar disponíveis também nas telas de consulta de débitos do módulo de arrecadação.

viii. O Sistema deverá permitir a inscrição de débitos vencidos em Dívida Ativa com periodicidade estabelecida pelo órgão. A inscrição em dívida ativa dos débitos vencidos e não pagos deverão ser feitas automaticamente, através de procedimento que os seleciona conforme os parâmetros estabelecidos pelo órgão. Aos valores originais do débito deverão ser acrescidos juros multas e correção monetária, calculados conforme critérios estabelecidos pelo órgão.

g. Corte / religações

i. O Sistema deverá permitir que sejam identificados, de maneira seletiva, os clientes inadimplentes para com o órgão. Deverá disponibilizar a emissão de comunicados de corte, segundo critérios de seleção estabelecidos.

ii. O Sistema deverá disponibilizar condições para identificar os clientes devedores por: ligação, grupo, logradouro, categoria, vencimentos, meses pendentes, valores mensais e globais, disponibilizando a informação para as ações de regularização da carteira.

iii. O Sistema deverá estar preparado para a emissão das notificações de corte com código de barras. Deverá também possibilitar o agrupamento das contas no momento da emissão das notificações.

iv. O Sistema deverá permitir a manutenção das notificações de corte emitidas, permitindo cadastrar o status da entrega das mesmas.

v. O Sistema deverá controlar, no processo de geração de ordens de serviço de corte, a emissão e entrega das notificações. Para uma ligação não notificada, não poderá ser emitida uma ordem de corte.

vi. Durante a geração das ordens de corte, o sistema deverá criar informação de controle, indicando, para a ligação correspondente, a situação de corte.

vii. Deverá possibilitar o registro das respectivas ordens de serviço de corte no Sistema de Atendimento a Cidadãos (que passará a efetuar o acompanhamento da execução das mesmas).

viii. Nas ordens de corte geradas deverá ser possível registrar o motivo pelo qual a ligação não foi cortada. Esta informação deverá estar disponível para consulta na própria ligação. No caso de ter sido realizado o corte, no mínimo, as seguintes informações deverão ser registradas: tipo de corte, data, leitura e responsável

ix. O Sistema deverá permitir a identificação dos imóveis com o fornecimento de água interrompido por falta de pagamento. Deverá também permitir a seleção dos imóveis a serem reabilitados, agrupando estas informações para: faturamento, geração de ordens de serviço e relatórios de controle de cortes.

x. O Sistema deverá manter histórico de todas as notificações, ordens de corte e religações efetuadas.

h. Cadastro

i. O Sistema deve permitir o registro e manutenção dos dados referentes às ligações de água e esgoto. Deve permitir o armazenamento de informações cadastrais do terreno, do imóvel, da ligação e das contas:

▪ A tabela de terrenos deverá conter informações referentes aos mesmos, tais como: planta, área, testada, lote, quadra e demais informações pertinentes ao terreno do imóvel.

▪ A tabela de imóveis deverá conter informações referentes aos mesmos, tais como: inscrição municipal, endereço do imóvel, endereço de entrega, endereço de correspondência, proprietário e compromissários.

▪ A tabela de ligações deverá conter as informações pertinentes às mesmas , que influenciarão diretamente o cálculo das faturas, tais

como: situação da água, situação do esgoto, tipo de cobrança, hidrômetro, categorias, atividade, beneficio social e outros,

▪ A tabela de contas deverá conter as informações gerais relativas às mesmas, tais como: leituras, ocorrências, valores, serviços, taxas, datas e outros.

ii. O sistema deverá permitir, para cada imóvel, o cadastro de vários proprietários e compromissários com seus respectivos endereços e documentos.

iii. Deverá ainda possuir cadastro de informações complementares à ligação, onde serão armazenadas outras informações pertinentes, tais como: piscina, número de moradores, cônjuge, renda familiar, estado civil e outras. Essas informações serão cadastradas para efeito de análise, não influenciando no cálculo das faturas de água, esgoto e serviços.

iv. A manutenção das informações de cadastro, sejam referentes ao terreno, imóvel ou ligação, deverá ser permitida em seus respectivos módulos e/ou telas de acordo com a configuração de permissões estabelecida pelo órgão.

v. Deverão ser armazenadas, em histórico, todas as alterações efetuadas no cadastro.

vi. O Sistema deverá permitir a localização e identificação dos clientes, por meio do número da conta (CDC), nome do usuário (consulta fonética), código do logradouro, número do hidrômetro, nome da rua (consulta fonética) e pelo número do imóvel, ou número de inscrição (Identificação), CPF, inscrição municipal, bairro.

vii. O Sistema deverá disponibilizar consulta ao cadastro, com, no mínimo, as seguintes informações: terreno, imóvel, contas, leituras, débitos, categorias, serviços, notificações, carnês de parcelamento e histórico.

viii. O Sistema deverá permitir o cadastro das informações necessárias para a concessão de desconto de benefício social ou atividade, conforme norma específica.

ix. O Sistema deverá permitir o bloqueio da ligação, impedindo algumas ações sobre a mesma, de acordo com o parametrizado pelo órgão, tais como: parcelamentos, cortes e notificações.

x. O Sistema deverá permitir o cadastro de condomínios nas ligações, efetuando cálculo diferenciado de acordo com as definições estabelecidas pelo órgão e legislação municipal.

xi. O Sistema deverá permitir, para cada ligação, o cadastramento de data de vencimento especial das contas de água, esgoto e serviços. Estas informações serão utilizadas em casos específicos, a serem analisados pelo órgão.

i. Atendimento ao Cliente

i. Deverão estar disponíveis, para utilização pelos setores de Atendimento Personalizado e Telefônico do órgão, as seguintes rotinas e /ou funções, que permitirão:

▪ Localização e identificação dos clientes, por meio do número da conta (CDC), nome do usuário (consulta fonética), código do logradouro, número do hidrômetro, nome da rua (consulta fonética) e pelo número do imóvel, ou número de inscrição (Identificação), CPF, inscrição municipal e bairro.

▪ Simulação individual do cálculo dos valores de água e esgoto.

▪ Simulação individual do cálculo dos acréscimos por atraso de pagamento das contas.

▪ Histórico de leituras e consumo, no mínimo dos últimos 60 meses.

▪ Histórico de inclusões, exclusões e alterações de qualquer natureza.

▪ Demonstrativo geral de débitos pendentes.

▪ Demonstrativo de pagamentos, no mínimo, dos últimos 60 meses.

▪ Recalculo individual das contas, permitindo a alteração das leituras e ocorrências e inclusão de observações sobre o recalculo no histórico da ligação.

▪ Emissão de segunda via da conta, com opção de cobrança na própria conta ou em conta futura.

▪ Emissão da conta com agrupamento dos débitos por CDC, por CPF ou inscrição municipal.

▪ Desagrupamento de contas.

▪ Desdobramento de contas.

▪ Registro e controle dos serviços comerciais solicitados pelos clientes.

▪ Registro das movimentações efetivadas nas contas de água e esgotos, identificando o responsável pelas operações.

▪ Realização de parcelamento em contas de água, esgoto e serviços, conforme norma específica.

▪ Estorno de parcelamentos efetuados em conta, efetuando baixa de contas quando houver parcelas pagas.

▪ Emissão de certidão negativa de débitos.

▪ Parcelamento de contas ou de serviços em carnês e emissão de parcelas; (1ª e 2ª vias) com código de barras padrão FEBRABAN ou CNAB. Na geração de carnês deverá ser permitido a alteração do nome do responsável pela dívida e/ou o representante e seus respectivos documentos, sem alterar o responsável pela ligação cadastrada. Deverá ser gerado termo de parcelamento conforme determinado pelo órgão.

▪ Localização e identificação dos carnês gerados por número de carnê, exercício, cdc, nome, inscrição municipal, situação e cpf.

▪ Consulta de contas pagas e em aberto, no mínimo dos últimos 60 meses.

▪ Emissão e cancelamento de documento de arrecadação de serviços diversos.

▪ Registro e baixa de solicitações de vistoria.

▪ Registro de instalação e retirada de hidrômetros.

▪ Cancelamento de contas e parcelas de carnês, cadastrando o motivo do cancelamento.

▪ Estorno do cancelamento de contas e parcelas de carnês.

▪ Estorno de carnês, efetuando a baixa de contas quando houver valor de parcelas pagas.

▪ Opção de reativação de carnês cancelados.

▪ Reparcelamento de carnês conforme normas específicas. O sistema deverá ter a opção de controlar a quantidade de vezes que um carnê poderá ser reparcelado.

▪ Parcelamentos em conta e em carnês com descontos concedidos através de legislação específica.

▪ Cálculo e inclusão de acréscimos nas parcelas de carnês quando atrasadas, emitindo 2ª via da parcela para pagamento com valor corrigido.

▪ Cálculo e inclusão de descontos nas parcelas de carnês quando o pagamento for adiantado, emitindo 2ª via da parcela para pagamento.

▪ Opção para inclusão de prazo para pagamento das contas, impedindo que o contribuinte seja cortado por inadimplência.

▪ Consulta de acréscimos gerados pelo pagamento em atraso das contas.

▪ Permitir a retenção/liberação de contas, impedindo alterações, baixas, emissão de notificações ou outras ações de acordo com o estabelecido pelo órgão.

▪ O Sistema deverá armazenar todas as alterações de informações efetuadas, gerando histórico e permitindo consultas.

j. Relatórios Gerenciais

i. O Sistema deverá possuir relatórios de todos os módulos do sistema, disponibilizando geração a qualquer tempo para acompanhamento das movimentações efetuadas e gerenciamento do órgão, conforme as características abaixo:

▪ Relatório histograma de consumo;

▪ Relatório referente ao faturamento por categoria contendo, no mínimo, as informações de: quantidade de ligações de água e de esgoto, quantidade de contas geradas, valor de água, valor de esgoto, valor dos serviços, valor das taxas, consumo real e faturado, quantidade de economias de água e de esgoto, ligações com e sem hidrômetro, quantidade de contas lançadas e não lançadas, quantidade de ligações e economias de água e esgoto ativas, quantidade de ligações cortadas.

▪ Relatório de ligações, economias e volume por categoria e faixa de consumo, podendo determinar as faixas de consumo para o relatório.

▪ Relatório demonstrativo de consumo, mostrando o consumo dos últimos 12 meses, média, categoria e economia de um conjunto de ligações.

▪ Relatório mostrando quantidades e valores das contas em aberto por vencimento, indicando valores de água, esgoto, serviços e taxas.

▪ Relatório mostrando quantidades e valores de faturamento e arrecadação. As informações de arrecadação deverão ser divididas por prazo de pagamento sendo até o vencimento, 30, 60, 90, 120

e com mais de 120 dias. As informações dos valores não arrecadados deverão ser subdivididos por categoria.

▪ Relatório dos maiores consumidores, contendo, no mínimo, as informações de cdc, nome, endereço, leitura anterior e atual, hidrômetro, média, categoria, economia, consumo e valor da conta.

▪ Relatório referente ao faturamento, classificado por atividade, bairro ou por categoria, contendo, no mínimo as informações de: quantidade de ligações de água e esgoto, economias de água e esgoto, volume real e faturado, valor total.

▪ Relatório dos carnês gerados, cancelados, reparcelados, contendo, no mínimo as informações de: cdc, carnê, data e valor.

▪ Relatório de parcelas de carnês pagas e em aberto, contendo, no mínimo as informações de: cdc, carnê, parcela, valor da parcela e valor pago.

▪ Relatório das contas agrupadas que não foram pagas, contendo, no mínimo as informações de: cdc, nome, endereço, data do agrupamento, referencia, valor de água, esgoto, serviços, taxas, multa, juros, correção e total da conta.

▪ Relatório das contas cadastradas em débito automático que não foram pagas, contendo, no mínimo as informações de: cdc, nome, endereço, referência, vencimento e valor.

▪ Relatório de débitos de água e esgoto detalhado, contendo, no mínimo, as informações de: cdc, nome, endereço, hidrômetro, situação da ligação, valor de água, esgoto, serviços e taxas, multa, juros e correção, valor total original, valor total corrigido e data de vencimento. Para este relatório deverão estar disponíveis, no mínimo: filtro por grupo, intervalo de contas, valor mínimo e máximo, vencimento inicial e final, categoria, quantidade de contas em aberto, quantidade máxima de devedores, logradouro e bairro.

▪ Relatório estatístico de notificações emitidas, contendo informações de quantidade e valor das emitidas, entregues, pagas, parceladas, canceladas, cortadas, religadas e outras informações.

▪ Relatório de hidrômetros cadastrados no sistema, com opção de selecionar os que estiverem em uso, parados, por tempo e por data de instalação, no mínimo com as informações de: cdc, nome,

endereço, hidrômetro, número de ponteiros, última leitura, data de leitura e consumo.

▪ Relatório de hidrômetros cadastrados e ainda não utilizados.

▪ Relatório de contas referente a Portaria CAT56.

▪ Relatório de ligações com mais de uma categoria cadastrada.

▪ Relatório com informações sobre o cadastro de ligações, utilizando como filtro, no mínimo as informações de: situação da água, situação do esgoto, grupo, categoria, tipo de cobrança, logradouro, bairro, atividade, rota de leitura, quantidade de economias, tipo de ligação, benefício social, ligações excluídas. Este relatório deverá apresentar os principais dados das ligações selecionadas, podendo ser detalhado ou resumido.

▪ Relatório de logradouros cadastrados.

▪ Relatório de erros durante o cálculo das contas.

▪ Relatório das principais alterações efetuadas no sistema pelos funcionários, tais como: emissão de segunda via de conta, agrupamentos, parcelamentos, alteração de contas, estorno de parcelamentos e emissão de guias.

▪ Relatório dos parcelamentos em conta efetuados, contendo, no mínimo, as informações de cdc, nome, contas parceladas, valor original das contas, valor parcelado.

▪ Relatório dos parcelamentos em conta efetuadas e em atraso.

▪ Relatório de serviços lançados e a lançar em contas contendo, no mínimo informações de: cdc, quantidade de parcelas, valor das parcelas, valor lançado, valor a lançar.

▪ Relatório de volumes alterados, mostrando as alterações efetuadas por contas, no consumo real e/ou faturado das contas.

▪ Relatório analítico e sintético de leituras efetuadas por leiturista e por horário das leituras efetuadas.

▪ Relatório de ocorrências durante a leitura dos hidrômetros.

▪ Relatório contendo rota e seqüência de leituras e entregas, cadastradas.

▪ Relatório estatístico de leituras por código de ocorrência.

▪ Relatório de ligações cortadas que apresentaram consumo durante a leitura dos hidrômetros.

▪ Relatório de baixas efetuadas por data de contabilização, classificados nas contas contábeis do órgão.

▪ Relatório de arrecadação por data de contabilização demonstrando detalhadamente a composição da arrecadação.

▪ Relatório de baixas efetuadas, demonstrando individualmente as contas, parcelas e guias baixadas.

▪ Relatório contendo erros gerados durante a baixa de contas.

▪ Relatório de baixas duplicadas contendo, no mínimo as informações de: cdc, referência, data do pagamento, valor original pago, valor pago em duplicidade, data de contabilização, data de pagamento, lote e agente.

▪ Relatório de ligações que possuem débitos e não estão cortadas.

▪ Relatório de ligações cortadas

▪ Relatório de ligações religadas

▪ Relatório de ligações cortadas que não possuem débitos, podendo ser religadas.

▪ Relatório de débitos de contas inscritas em dívida ativa.

▪ Relatório de contas em aberto inscritas em dívida ativa que possuem certidão emitida.

▪ Relatório de contas em aberto inscritas em dívida ativa que não possuem certidão emitida.

▪ Relatório mensal constando os valores de movimentação da dívida ativa, tais como: parcelamentos, receita, cancelamentos, estornos, alterações e demais valores que afetem o saldo da dívida ativa.

▪ Relatório com os principais dados cadastrais das ligações que possuem cadastro em débito automático.

▪ Relatório de evolução de consumo por cdc com opção de gráfico.

ii. O sistema deverá possuir ferramenta para geração de relatórios eventuais.

▪ Todos os relatórios deverão ter opção de geração em tela, arquivo ou impressora.

k. INTERNET

i. O Sistema deverá permitir os seguinte serviços, utilizando-se de tecnologia “WEB”:

▪ Emissão de 2ª vias de contas e carnês,

▪ Emissão de extrato de débitos,

▪ Auto leitura,

▪ Emissão de certidão negativa de débitos,

▪ Histórico de consumo,

▪ Solicitação de serviços.

4. Sistema de Atendimento ao Cidadão

O sistema deverá apresentar solução completa para o atendimento aos munícipes, registrando as solicitações e/ou atendimentos, as manutenções realizadas e ainda oferecer recursos para o gerenciamento e acompanhamento de todas as operações realizadas.

a. Características

O processo de informatização deverá acompanhar a solicitação do serviço, desde o Atendimento , até a programação, emissão e baixa das ordens de serviços executados e a geração dos relatórios operacionais e gerenciais, conforme característica abaixo:

i. Deverá possuir tabelas de referências para cadastro de informações necessárias à utilização do sistema, tais como: tabelas de ocorrências, equipamentos, serviços, atendimentos, áreas de manutenção, departamentos, funcionários, equipes, perfis de acesso ao sistema, viaturas e outras necessárias. A manutenção de parâmetros e tabelas do sistema deverá ser efetuada pela empresa sem a necessidade de acompanhamento pela contratada.

ii. O sistema deve ter procedimento para administrar o controle de acesso ao sistema, envolvendo os perfis de usuários e senhas.

iii. Deverá ser possível a partir do Sistema de Atendimento ao Cidadão executar consultas diversas às tabelas de imóveis, ligações e contas dos módulos de faturamento e arrecadação. Também, a partir deste Sistema o operador deverá ter possibilidade de acordo com suas permissões de acesso, efetuar agrupamento e desagrupamento de contas, parcelamento e estorno de parcelamento de contas, adiamento de prazo de pagamento, retenção de contas, emissão de 2ª vias de contas, extrato de débitos e de guias de recolhimento para pagamento de serviços e taxas.

b. Abertura de Ordens de Serviço

i. Deverá apresentar condições para o registro das ordens de serviço de qualquer tipo de serviço, de acordo com a necessidade do órgão. O sistema deverá permitir, através de uma tabela de códigos de serviços específicos, registrar o código correspondente ao problema indicado pelo cliente ou por setores internos do departamento.

ii. Deverá ter a opção de registrar informações fornecidas aos clientes, como por exemplo a “situação de débitos”, sem a necessidade de geração de ordem de serviço.

iii. A localização e identificação dos clientes para abertura das ordens de serviço deve ser feita através do CDC, nome ou endereço do imóvel.

iv. Ao selecionar a ligação desejada, o sistema deverá preencher automaticamente os principais dados do imóvel, tais como endereço, categoria, economia, hidrômetro, proprietário, última leitura e outros.

v. O Sistema deverá colocar na tela de abertura das ordens de serviço, mensagem de clara visualização quando a ligação selecionada apresentar débitos vencidos e não pagos, permitindo também, por opção do operador, a visualização em tela dos detalhes dos débitos vencidos e pendentes de pagamento, assim como a informação de corte na ligação.

vi. Deve apresentar o demonstrativo das leituras e consumos e a informação de pagamento das contas de água e esgoto.

vii. Na tela de abertura de ordem de serviço deverão estar contemplados no mínimo: código do serviço, prazo para execução do serviço, valor do serviço – quando cobrado, dados do imóvel; nome e telefone do solicitante; ponto de referência do imóvel, campo para observações.

viii. Na abertura de ordens de serviço, antes de gravar as informações, o sistema deverá verificar a existência de outras ordens abertas no mesmo logradouro, tendo a opção de associar o registro a uma OS já existente ou gravar uma nova OS.

ix. Deverá ser gerado histórico na ligação do sistema comercial referente a abertura das ordens de serviço.

c. Impressão das ordens de Serviço

i. O sistema ofertado pela proponente deverá apresentar condições de registro e emissão das ordens de serviços. No documento impresso deverá constar no mínimo os dados cadastrais do endereço indicado, o código e a descrição da solicitação, as características da equipe executora.

ii. Deverá haver a possibilidade de seleção das ordens de serviços para impressão por período e departamento

responsável a fim de facilitar o controle e execução dos serviços.

iii. Deve haver a possibilidade de transmissão do serviço a uma equipe através de rádio. Neste caso, ao efetuar a transmissão deverá ser registrado no sistema a transmissão e para qual equipe; a OS deverá ser considerada como impressa.

iv. O sistema deverá efetuar o controle de impressão das ordens de serviços impedimento que a OS seja impressa várias vezes erroneamente, assim como o controle de quando e quem efetuou a impressão.

v. Deverá ter opção de controle de data de entrega e retorno da OS à equipe executora.

vi. O Sistema deverá permitir a utilização de layouts de ordens de serviço diferentes de acordo com o tipo de chamado a ser executado.

d. Programação de Serviços

i. O sistema deverá permitir a programação automática de serviços a serem executados pelas equipes de acordo com a parametrização entre serviços, logradouros, equipes e áreas de manutenção da cidade efetuada pelo órgão.

ii. O sistema deverá permitir visualização na tela do computador da programação efetuada pelo sistema, permitindo pela programação, distribuir os serviços em aberto entre as equipes de manutenção disponíveis.

iii. Na tela deverá constar no mínimo filtros por período, departamento e equipe, com opção mínima de visualização das seguintes informações: ordens de serviço em execução, em atraso, programadas, sem programação, carga horária da equipe, tempo para execução dos serviços.

iv. Concluídos os trabalhos de programação, o sistema deverá permitir a impressão das ordens de serviço programadas, para distribuição entre as equipes disponíveis no dia.

e. Execução e Encerramento das Ordens de Serviço

i. Sistema ofertado pela proponente deverá apresentar condições de baixa dos dados dos serviços executados em campo.

ii. A estrutura de funcionamento deste Sistema deverá estabelecer uma integração de forma on-line do centro

operacional do órgão com os serviços de Atendimento a Cidadãos o que possibilitará uma gestão eficiente dos recursos humanos e materiais disponíveis.

iii. O sistema deverá estar preparado para realizar a baixa das solicitações e dos serviços executados, registrando a equipe, o veículo, a quilometragem, o serviço, a data e hora de execução, bem como dados dos serviços executados, tipos e quantitativos de materiais, equipamentos e mão-de-obra aplicados.

iv. Deverá estar preparado para a integração com o sistema comercial, assim ao efetuar o encerramento das ordens de serviços algumas tarefas serão realizadas tais como: cadastro de nova ligação de água e esgoto, corte no fornecimento, reativação do fornecimento, troca de hidrômetro, atualização de dados cadastrais, instalação de hidrômetro, geração de histórico da execução do serviço.

v. Ao encerrar ordens de serviço para controle da execução de novas ligações de água e esgoto deverá ser gerado automaticamente pelo Sistema de Atendimento ao Cidadão, o registro, no Sistema de Faturamento, da ligação recém concluída.

vi. Sistema de Atendimento ao cidadão deverá lançar, quando for o caso, a cobrança de serviços executados e que impliquem em custo para o usuário. O lançamento deverá ser feito automaticamente para inclusão na(s) próxima(s) faturas de água e esgoto.

vii. Sistema deverá permitir a inclusão de várias tarefas a serem executadas na mesma ordem de serviço, a fim de promover o controle para conclusão de um serviço, obtendo assim uma visão clara de todas as etapas necessárias à execução da solicitação efetuada pelo cliente.

viii. Deverá permitir a abertura automática de tarefas a serem executadas para a conclusão da solicitação, efetuando o controle e liberação das tarefas de acordo com a execução da ordem estabelecida.

ix. Deverá permitir o controle de permissão para encerramento das ordens de serviço por departamento responsável.

x. COLETOR DE DADOS : Este Sistema deverá permitir a utilização de coletor de dados para a execução das ordens de serviço em campo.

f. Retorno de Chamados

i. O sistema ofertado deverá ter solução para que seja efetuado o retorno ao cliente por carta ou por telefone da solicitação efetuada.

ii. Quando o retorno for efetuado por telefone, deve ter a opção de registrar uma pesquisa de satisfação efetuada junto ao cliente, indicando comentários e observações efetuadas.

g. Ordem de Serviço interna

i. O Sistema deverá controlar também as manutenções internas, preventivas e corretivas. Estas manutenções referem-se a equipamentos e estruturas prediais pertencentes à autarquia. Deverá, para cada ordem de serviço, indicar os equipamentos e mão de obra a serem utilizados. Em relação às manutenções preventivas, o Sistema deverá ter o recurso de gerar automaticamente, orientado por uma parametrização específica, ordens de serviços periódicas.

h. Telemetria

i. Deverá permitir que o Preparador de serviços registre em tela, todas as interrupções no fornecimento de água, e que estes dados, sirvam de fonte de pesquisa no setor de Atendimento ao Cidadão. Deverão ser registrados:

▪ A Zona de Abastecimento atingida.

▪ A data e hora do registro do fechamento.

▪ Observações sobre a ocorrência e normalização do abastecimento.

i. Relatórios Gerenciais

i. Deverá permitir o armazenamento dos dados de execução dos serviços e a geração de indicadores que medem a performance, produtividade e eficiência do roteiro, devendo estar disponibilizados em tela ou por meio de relatórios em papel impressos diariamente.

ii. Sistema informatizado deverá permitir que todos os dados relativos ao controle e gestão dos serviços possam ser visualizados na tela das estações de trabalho, sendo possível à emissão de no mínimo os seguintes relatórios:

▪ Relação de serviços a executar

▪ Relação mensal de serviços executados

▪ Relação de serviços com prazos de execução vencidos

▪ Estatística de materiais aplicados, por dia, mês e por equipe ou pelo conjunto das equipes

▪ Estatística de mão de obra utilizada por dia, mês e por equipe ou pelo conjunto das equipes

▪ Estatística de equipamentos utilizados, por dia, mês e por equipe ou pelo conjunto das equipes

▪ Relação dos serviços programados para o dia

▪ Relação de serviços previstos para execução pelas equipes de água e esgoto

▪ Relação de chamados por período

▪ Relação de chamados por Tipo de Atendimento

▪ Relação de chamados por Xxxxxx

▪ Relação de chamados internos por departamento

▪ Produtividade das equipes

▪ Tempo de Atendimento ao Usuário

▪ Tempo Médio de Atendimento dos Serviços

▪ Quadro comparativo de serviços por setor

▪ Ordens de serviço em aberto por prioridade

▪ Ordens de serviço em aberto por viatura

▪ Ordens de serviço em aberto por empreiteira

▪ Quadro de reincidência de tipo de chamado

▪ Quadro de Execução mensal de serviços

j. Geração Automática de Ordens de Serviço (Interação com Sistema de Faturamento)

i. O Sistema de Atendimento ao Cidadão deverá dispor de rotinas que permitam, dentro dos critérios de seleção e de acordo com os parâmetros adotados dinamicamente no órgão, a geração automática e o controle de Ordens de Serviço para os seguintes serviços:

▪ Corte de ligações

▪ Troca de Hidrômetro

▪ Manutenção de Hidrômetros

▪ Vistoria

▪ Na conclusão de cada ordem de serviço este Sistema deverá atualizar automaticamente as informações pertinentes ao Sistema de Faturamento alterado pela execução da O.S. (Marcar a ligação como cortada, alterar o N º do Hidrômetro, registrar históricos e outros).

4.11 Sistema embarcado de manutenção de Ordens de Serviço:

4.11.1 A solução deverá ser voltada para Smartphones para serviços em campo, compatível com Android;

4.11.2 Deverá incluir todos os campos de controle de Ordens de Serviço como:

• Tipo do Serviço;

• Gravidade/Intensidade do problema;

• Endereço;

• Data e Hora de Chegada ao local;

• Data e hora de conclusão da tarefa;

• Campo com opções preestabelecidas para solução do Serviço;

• Campo com opções preestabelecidas para não execução do Serviço;

• Campo com opções preestabelecidas para o local (rede, cavalete, etc.) da manutenção;

• Inclusão de serviços complementares como calçada, recapeamento, etc.;

• Controle de materiais utilizados;

• Foto antes, durante e depois da manutenção;

• Número do hidrômetro e lacres no local com opção de leitura pelo código de barras do smartphone;

• Coordenada GPS do local do serviço;

• Visualização do croqui da rede no local com dados capturados do sistema de Geo/GIS da autarquia (MSSQL);

• Definição de campos obrigatórios por tipo de serviço do SEMAE;

• Emissão de notificações, auto de infração e Recibos.

4.11.3 O envio e recebimento de Ordens de Serviço para os smartphones deverão estar disponíveis de forma híbrida, através de comunicação 4G/3G/GPRS, doca USB para transferência de dados em arquivos de texto e WIFI;

4.11.4 Deverá possuir recurso de impressão nas impressoras portáteis de notificações e controles através de layouts definidos pela Autarquia;

4.11.5 Baixas das Ordens de Serviço em tempo real no banco ou por batelada;

4.11.6 Deverá possuir recurso de captura de assinatura do consumidor.

1.12. Interação com Internet

ii. O Sistema de Atendimento ao cidadão deverá permitir consultas de Posições de Chamados utilizando-se de tecnologia “WEB”.

5. Sistema de Coleta de Dados, Impressão e Entrega Simultânea de Conta de Água e Notificações

Possibilitar ao Fiscal Leiturista efetuar os registros das leituras e ocorrências dos medidores de água, o faturamento no campo em tempo real (leitura e impressão da conta de água e esgoto e das notificações no mesmo minuto), a impressão das faturas de água e notificações diversas e possibilitar o envio e recebimento das informações de campo para o Sistema de Faturamento. O Sistema de Coleta de Dados e Impressão Simultânea deverá ser totalmente integrado ao Sistema de Faturamento e conter os recursos descritos a seguir.

a. Características

i. O software deverá possibilitar a operação de forma descentralizada, propiciando o processamento remoto do faturamento em campo e comunicação através do protocolo TCP/IP utilizando-se conexão Wireless (ou uma doca) para troca de informações com o sistema de gestão do Sistema de Faturamento.

ii. O faturamento e emissão convencional de contas de água e esgoto com boleto (in-loco) será mantido como opção de impressão de contas de acordo com as regras estabelecidas pelo órgão.

iii. Deverá conter no mínimo as seguintes funcionalidades:

▪ Procedimento de descarga dos dados coletados e faturados em campo, para o Sistema de Faturamento via Wireless ou doca;

▪ Procedimento de pesquisa e consulta de posicionamento de usuários na rota por endereço, número do hidrômetro, identificação do usuário, identificação de rota e posição relativa do usuário na rota.

▪ Procedimento de rotina de coleta, consistência de leituras e registro de irregularidades, divergências e ocorrências;

▪ Procedimento de captura de imagens (fotos) com vinculação direta ao CDC;

▪ Procedimento de descarregamento das fotos vinculadas ao CDC para o banco de dados automatizado.

▪ Procedimento de cálculo tarifário de consumo de água, resíduo de troca de medidores e lançamento pelo consumo taxado;

▪ Procedimento de impressão de Contas de água com código de barras padrão FEBRABAN, CNAB, em impressora portátil térmica direta sem fio, utilizando a comunicação por Bluetooth;

▪ Ter a capacidade de transmissão das leituras em tempo real, via gprs, protegendo os dados coletados contra a eventuais perdas, devido a travamento do computador móvel ou outros motivos quaisquer.

▪ O Sistema de Coleta de Dados e Emissão Simultânea deverá comportar o cadastro de todos os fiscais leituristas, códigos de ocorrências e ligações pertencentes ao mesmo grupo de rota de leitura, ordenados por seqüência de leitura.

▪ O Sistema de Coleta de Dados e Emissão Simultânea deverá permitir a mudança de fiscal leiturista a qualquer tempo em qualquer rota de leitura.

▪ Criticar em tempo real a leitura informada pelo fiscal leiturista com base nas informações contidas, tais como leitura anterior, média dos últimos consumos, alertando quando houverem divergências quanto ao consumo médio e o medido. Deverão ser cadastrados percentuais de tolerância a maior e a menor em relação a estes consumos informados.

▪ O Sistema deverá possuir, entre outros, parâmetros de ocorrências que indiquem se o campo de leitura deve ou não ser preenchido. Ex: Em uma ocorrência de portão fechado ou hidrômetro inacessível não se pode lançar leituras.

▪ Aviso de ligação ha mais de X (parametrizável) meses sem leitura real efetuada pelo órgão.

▪ Através de parametrização, o Sistema deverá mostrar o último consumo registrado e a média habitual, quando for detetado consumo maior ou menor que a média, durante o registro da respectiva leitura.

▪ O sistema deve permitir a parametrização de códigos de ocorrência, que no momento do lançamento do mesmo, seja exigido a captura da imagem (fotografia comprovando o lançamento do código de ocorrência.)

▪ O Sistema deverá executar na rota cálculos diferenciados para condomínios com leitura não individualizados, cálculos diferenciados para condomínios individualizados (Leitura e emissão de contas para hidrômetro principal e hidrômetros individuais – Ex: CDHU).

▪ No computador móvel, as funções multimídia, acesso à vídeo, som, navegação de internet, jogos, instalações de softwares, modificação de configurações, fundo de tela, proteção de tela e

demais funcionalidades não relacionadas exclusivamente á coleta de leituras, registro de fotos e emissão de contas, devem ser desativadas e/ou estar inacessíveis para os fiscais leituristas.

▪ O sistema deverá contar com procedimento específico para os casos em que a leitura tenha sido realizada há mais de 30 dias. Deverá calcular o valor do consumo correspondente a 30 dias, atualizando os valores de água e esgoto e posicionando a leitura atual.

▪ Deverá permitir a impressão de mensagens de débito nas contas.

▪ Deverá permitir a impressão da quitação anual de débitos, de acordo com os critérios estabelecidos pelo órgão.

▪ O Sistema deverá, a cada leitura registrada, armazenar as coordenadas geográficas (latitude e longitude), provenientes do recurso de GPS contido no coletor de dados. Esta funcionalidade deverá ser parametrizada e, quando houverem, deverão ser enviadas para o sistema central.

6. Sistema de Controle de Protocolo

a. Características

i. O sistema de Controle de Protocolo terá como objetivo básico o registro e acompanhamento de Processos, Protocolos ou Documentos Gerais, dos mais diversos tipos tais como: compras, administrativos.

ii. Deverá permitir que o usuário cadastre as seguintes informações:

▪ Tipos de processos: tabela de qualificação dos processos e protocolos a serem acompanhados.

▪ Departamentos: setores pelos quais podem transitar os diversos processos.

▪ Situação de Processos ou Protocolo: em andamento, encerrado ou quaisquer outras condições definidas pelo usuário.

▪ Motivo de Encerramento: arquivado, falta de documentos ou quaisquer outras condições de encerramento definidas pelo usuário.

▪ Informações referentes a Processos Ajuizados.

▪ Interessados: pessoas que têm alguma relação com processos em andamento.

▪ Roteiros ou cronogramas: não só dos departamentos ou setores pelos quais transitam os processos, mas também a seqüência em que o fazem. Os roteiros terão como objetivo orientar o usuário no encaminhamento dos processos entre os diversos departamentos.

▪ Os processos deverão ser qualificados por Tipo de Processo.

▪ Para cada “fase” (departamento ou setor para o qual o departamento é encaminhado), o sistema ofertado pela proponente deverá permitir que o usuário estabeleça a quantidade de dias (ou horas) máximo de duração da mesma. Esta informação será utilizada para estatísticas de atraso por departamento.

▪ Processos: o sistema ofertado pela proponente deverá permitir que o usuário, ou setor de protocolo, cadastre os diversos processos, contendo no mínimo: numero, ano, data de abertura, origem (interno ou externo), tipo de processo, assunto, interessado e descrição.

▪ Despesas com o processo, tais como honorários advocatícios, taxas de autenticação e outras.

iii. Deverá possuir os seguinte recursos:

▪ Permitir a definição de volumes diferentes para um mesmo processo, registrando a sua numeração de página e seu conteúdo correspondente.

▪ Permitir que, a partir de um protocolo seja gerado um processo.

▪ Permitir o registro de cada uma das fases pelas quais o processo ou o protocolo tramita, informando: departamento; data de início; data de fim; observações gerais.

▪ Possibilitar o recebimento ou encaminhamento de vários processos ou protocolos em um único procedimento.

▪ Permitir o “Apensamento” de processos entre si, a partir de uma etapa qualquer.

▪ Permitir o “Desapensamento” de processos, a partir de uma etapa qualquer.

▪ Possibilitar o encaminhamento do processo para outro departamento ou setor, sob orientação do cronograma correspondente. Este encaminhamento poderá ser realizado para um volume ou todos os volumes do processo em questão.

▪ Possibilitar que usuários autorizados incluam observações nos processos.

▪ Possibilitar que sejam anexados documentos nos processos.

▪ Disponibilizar procedimento de encerramento de processo ou protocolo

▪ Permitir o registro de despesas geradas pelo processo.

▪ Possibilitar o armazenamento de informações fornecidas pelo fórum referentes a processos jurídicos.

▪ Permitir ao usuário a abertura de protocolo/processo/filhotes.

▪ Permitir a criação de filhotes a partir do processo principal.

▪ Possibilita o encaminhamento do processo para outro departamento ou setor, sob orientação do cronograma correspondente. Esse encaminhamento poderá ser realizado para um volume ou todos os volumes do processo em questão/filhotes.

iv. Deverá permitir pesquisa em relatório ou em tela através de:

▪ Número do processo.

▪ Nome do interessado.

▪ Tipo do processo.

▪ CDC.

▪ Endereço ou parte do mesmo.

▪ Assunto.

▪ Localização.

▪ Data de Abertura.

▪ Data de Encerramento.

▪ Rg.

▪ Data de Apensamento.

▪ Origem.

▪ Volume.

▪ Endereço de execução do serviço.

▪ Dados do portador: nome, cpf, Rg.

▪ Número do processo judicial.

▪ Número de Certidão no registro de imóveis.

▪ Outros interessados.

v. Deverá, em suas pesquisas ou relatórios, fornecer informações tais como:

▪ Andamento de um processo: condição atual e histórico.

▪ Processos em atraso geral ou por departamento.

▪ Rol de processos por interessado.

▪ Rol de processo por departamento.

▪ Relatório de processo aberto ou encerrado no período.

▪ Estatísticas de atraso por departamento ou tipo de processo.

▪ Solicitações de aberturas de processo, protocolo ou documentos gerais.

▪ Termos de responsabilidade pessoa física ou jurídica.

▪ Relatório de processos por ordem numérico crescente e sua localidade.

▪ Relatório diário de Protocolo/processo.

▪ Relatório diário de Protocolo/processos encerrados.

vi. O sistema deverá alertar aos usuários quanto aos processos ou protocolos pendentes para recebimento.

vii. O sistema deverá alertar aos usuários quanto aos processos ou protocolos encaminhados e ainda não recebidos pelo departamento.

viii. O sistema deverá alertar os usuários dos processos cujo recebimento foi rejeitado por algum departamento.

ix. Permitir o controle de recebimento e trâmite de documentos diversos.

x. Permitir a geração do processo a partir de um protocolo ou de uma solicitação de abertura emitida pelo próprio sistema.

xi. Permitir anexar vários protocolos a um mesmo processo.

xii. Efetuar o encaminhamento em conjunto de processos anexados juntamente com o processo correspondente automaticamente no envio do processo.

xiii. Permitir criar subprocessos a partir de um processo já existente.

xiv. Deverá emitir etiqueta com a identificação dos processos em código de barras.

xv. Deverá emitir protocolo/recibo da abertura do processo.

xvi. Emitir Guias de Recolhimento quando da solicitação de cópias reprográficas.

b. Integração com SSB e 195

i. Deverá permitir ao usuário a geração de um pedido de ligação de água e esgoto, dando origem à uma ordem de serviço no sistema de atendimento ao cidadão (0800).

ii. Os dados do processo deverão ser atualizados conforme alterações na ordem de serviço do sistema de atendimento ao cidadão (0800).

iii. O sistema deverá permitir a utilização das informações cadastrais armazenadas pelo sistema de saneamento básico, para a geração de processos ou protocolos.

iv. O sistema deverá permitir o acompanhamento dos processos de cobranças judiciais, enviados ao Fórum, gerados pelo sistema de saneamento básico, em seu procedimento de tratamento de dívida ativa.

v. Deverá importar guias do sistema de saneamento básico.

c. Integração com STM

i. Integração com o Sistema Municipal Tributário:

ii. Deverá ser possível a geração de processos através do sistema tributário.

iii. Deverá ser possível a geração de processos, através do sistema de protocolo, utilizando o cadastro do sistema tributário.

iv. Possibilitar que seja indicada a situação de inadimplência, do proprietário do imóvel, constante do processo pesquisado.

7. SISTEMA DE CONTABILIDADE, ORÇAMENTO PÚBLICO E TESOURARIA.

a. Características

i. O Sistema de contabilidade, orçamento público e tesouraria deverá estar integralmente de acordo com a lei 4320 , lei 101 de responsabilidade fiscal , Instrução 02/2008 do TCE e atender as novas determinações do Tribunal de contas de São Paulo relativas aos procedimentos do MCASP ( Manual de contabilidade aplicada ao setor publico - STN ), e os interesses da área técnica contábil, devendo ser constituído dos módulos :

▪ Orçamento Público

▪ Gestão Orçamentária

▪ Tesouraria

▪ Contabilidade

b. ORÇAMENTO PÚBLICO

O módulo de Orçamento Público deverá permitir a elaboração e impressão da peça orçamentária e dos anexos exigidos em lei.

i. O módulo ofertado pela proponente deverá permitir a parametrização dos limites de gastos com pessoal, educação e saúde, podendo o órgão selecionar as despesas, de acordo com o previsto em lei.

ii. O módulo deve disponibilizar consultas e relatórios diversos, baseados em critérios variados de seleção, que ofereçam visão completa das informações a ele pertinentes. Entre elas, deverão constar as referentes aos anexos de abertura do exercício, exigidos em lei.

iii. Deverão estar disponíveis os seguintes Relatórios:

▪ Anexos do orçamento de acordo com a lei 4.320. .

▪ Orçamento Analítico , incluindo o quadro resumido por fonte de recurso

▪ Todos os anexos da PPA, LDO e LOA de acordo com a lei 4.320.

iv. Possibilidade de visualizar, imprimir e exportar dados de exercício anteriores sem a necessidade de mudança de ambiente.

v. Inclusão da funcional programática ( órgãos, unidades orçamentarias, programas de trabalho, tipos de projetos; ação de governo )

vi. Possuir o cadastramento das fontes de recursos e dos códigos de aplicações de acordo com as tabelas de referencia do TCE.

vii. O módulo deverá possuir ferramentas para a criação da PPA e seus exercícios, permitindo:

▪ inserção de correção individual de valores das propostas de dotação;

▪ Permitir a inclusão de novas ações e programas , bem como suas unidades de medidas , metas físicas , indicadores , justificativas e objetivos.

viii. O módulo deverá possuir ferramentas para alteração do PPA , permitindo

▪ Alteração de ações e de programas.

ix. Efetuar a duplicação das Propostas de despesas e receitas para o próximo exercício e permitir que os itens duplicados possam ser editados pelo elaborador do orçamento.

x. Deve manter pré-cadastradas as categorias econômicas das receitas e despesas de acordo com a portaria vigente da STN, podendo incluir novas opções.

xi. Opção de escolher ou não um ordenador da despesa por órgão.

c. GESTÃO ORÇAMENTÁRIA

Este módulo deverá registrar e controlar todo o processo de execução orçamentária, permitindo o acompanhamento da arrecadação mensal e anual, o controle de saldos das dotações mensal e anual, a emissão de empenhos, controle dos fornecedores e o registro contábil de todos os atos e fatos administrativos.

i. O módulo ofertado pela proponente deverá integrar-se com o módulo de compras de forma a permitir, através do mesmo, funções tais como:

▪ a verificação de saldos de dotações, quando informados valores estimados de itens a serem adquiridos;

▪ o registro de reserva de dotações.

ii. Poder efetuar alterações orçamentárias previstas em lei sempre de uma ou mais dotações, como:

▪ Abertura de Credito Especial utilizando os recursos disponíveis em Leis.

▪ Suplementação de credito.

▪ Suplementação de credito por redução de dotações.

▪ Redução de crédito.

▪ Transposição de dotações.

▪ Suplementação de Receitas.

▪ Redução de Receitas.

iii. Poder efetuar suplementações de uma ou todas as receitas e despesas, através de um valor ou índice.

iv. Efetuar o registro e controle da movimentação das dotações, conforme o descrito a seguir:

▪ Reservas de dotações:

- Mediante o saldo da dotação, com a utilização ou não de um processo de compras.

- O usuário poderá prescrever a reserva a qualquer tempo.

- Visualizar os empenhos contidos nas reservas;

- Permitir empenhar, total ou parcialmente, a partir de uma reserva.

- Emitir as devidas notas de reserva e prescrições.

- Permitir que a reserva seja criada também pelo sistema de compras.

▪ Empenhos de despesas:

- Impedir que o valor ultrapasse o saldo da dotação.

- Permitir a elaboração de empenho a partir de uma reserva de dotação, podendo prescrever a reserva no caso de não utilização total.

- Para a elaboração de empenhos a partir de reservas estabelecidas pelo departamento de compras, efetuar automaticamente a inserção dos dados pertinentes ao processo correspondente, tais como: dotação, fornecedor vencedor da licitação, itens objetos da licitação definidos no próprio processo de compras.

- Permitir parametrizar dotações por secretaria.

- Visualizar nos empenhos seus: complementos, anulações, liquidações, devoluções e sumário de saldos de liquidações e pagamentos.

- O sistema deverá permitir o detalhamento de despesa ou categoria econômica.

- Permitir a emissão de uma nota individual ou um grupo de notas de empenhos.

▪ Complemento de empenho:

- Impedir que o valor ultrapasse o saldo da dotação.

- Opção de complementar empenho com o uso ou não de uma reserva de dotação.

- Emitir nota de complemento de empenho.

▪ Anulação de Empenho:

- Total ou parcial, impedindo que a anulação ultrapasse o valor do empenho.

- Verificar se o mesmo já foi liquidado.

- Emitir nota de anulação de empenho.

▪ Liquidação de empenho:

- Permitir liquidação total ou parcial do empenho.

- Impedir que o valor da liquidação ultrapasse o valor do empenho.

- Permitir a inclusão de Notas Fiscais já registradas pelo Sistema de Materiais, com os dados de valores e vencimentos.

- Criar automaticamente a despesa extra referente às retenções, na emissão da liquidação para eventual pagamento, bem como a receita extra ou orçamentária na tesouraria após seu pagamento.

- Emitir nota de ordem de pagamento individual ou em grupo de notas.

▪ Anulação de liquidação:

- Permitir a anulação total ou parcial, de uma liquidação, verificando se a ordem de pagamento já esta paga ou inclusa em cheques;

- Verificar se a mesma possui saldo para anulação.

- Liberar o valor da anulação de liquidação para o empenho.

- Emitir a nota de anulação de liquidação.

▪ Devolução de pagamentos de despesas:

- Permitir que a devolução de pagamento seja total ou parcial.

- O valor da devolução de pagamento deverá, automaticamente: reduzir a despesa empenhada; reduzir a despesa realizada e retornar à sua dotação de origem.

- Emitir nota de devolução de pagamento.

v. Efetuar bloqueios de uma ou várias dotações, com opção de liberações mensais, por valor ou porcentagem.

vi. Visualização em tela das dotações, por mês e anual indicando os valores das despesas:

▪ Suplementada

▪ Reduzida.

▪ Reservada.

▪ Bloqueada.

▪ Empenhada.

▪ Anulada.

▪ Liquidada.

▪ Paga.

▪ Devolvida.

vii. Integrar-se com o Sistema de Folha de Pagamento, que deverá fornecer os valores resultantes do cálculo mensal e do adiantamento (quinzenais) para contabilização e geração automática dos respectivos Empenhos, através dos códigos de proventos e descontos, bem como Ordens de Pagamento e Retenções, inclusive para o 13º salário.

vii.viii. Permitir cópia dos parâmetros de integração da folha de pagamento de um exercício para outro.

viii.ix. Deverá permitir a visualização em tela de saldos de receitas ix.x. Controle de empenho de adiantamentos, visualizando os

adiantamentos em aberto e inclusão de documentos para prestação de contas das despesas de adiantamentos,

xi. Encerrar o empenho de adiantamento automaticamente quando da prestação de contas.

x.xii. Disponibilizar em modulo WEB os pedidos e prestações de contas de adiantamentos.

xi.xiii. Restos a Pagar:

▪ Gerar automaticamente os restos a pagar no procedimento de virada do exercício.

▪ Visualizar suas liquidações e anulações e respectivo saldo.

xii.xiv. Anulação de Restos a Pagar – total ou parcial, verificando se o mesmo não se encontra liquidado, emitindo sua nota de anulação.

xiii.xv. Inclusão dos dados de Precatórios do exercício a ser informado ao TCE.

xiv.xvi. Inclusão dos dados de Remuneração de Agentes Políticos do exercício a ser informado ao TCE.

xv.xvii. Relatórios a serem disponibilizados pela gestão:

RECEITAS

▪ Diário da receita arrecadada com seus códigos orçamentários

▪ Demonstrativo mensal da receita arrecadada

▪ Balancete da receita orçamentária com opções mensal e anual

▪ Demonstrativo da receita extra orçamentária com opções mensal e anual.

▪ Razão de receitas e despesas extras

DESPESAS

▪ Balancete, demonstrativo e analítico da despesa.

▪ Cadastro e diário de empenhos.

▪ Cadastro de empenhos com históricos e parcelas.

▪ Razão por dotação discriminando todas as movimentações.

▪ Análise da despesa empenhada, liquidada e paga, classificados por: órgão, unidade, função, subfunção, tipo de empenho e tipo de licitação. O usuário deverá poder escolher a periodicidade das informações a serem impressas, indicando um intervalo de datas.

▪ Razão por fornecedor ou de todos os fornecedores, indicando o período.

▪ Notas de Empenho por período ou por intervalo de número de empenho.

▪ Notas de anulação de empenho.

▪ Relatórios de controle de adiantamentos (Anexo 9).

▪ Credores em diversas ordens.

▪ Credores em diversas ordens.

▪ Restos a Pagar processado, não processado e saldo de restos não pagos, demonstrando suas dotações de origem e movimentação de pagamentos e cancelamentos.

▪ Listagem de quotas regulares de dotações.

▪ Listagem de notas ou saldo de reservas de dotação.

▪ Balancete de receitas e despesas de acordo com suas fontes de recursos.

▪ Resumo da execução orçamentária com valores e percentagens da execução no exercício.

▪ Saldo de empenhos a pagar, com impressão por empenho, fornecedor ou dotação.

▪ Relatórios de Despesas separadas por Centro de Custos e por detalhamento da despesa.

▪ Relatórios referentes a controles específicos da Educação.

▪ Relatórios referentes a controles específicos da Saúde.

▪ Exportar relatórios em PDF e Excel.

▪ Relatório de calculo do PASEP a recolher mensalmente permitindo a dedução dos valores retidos nas transferências legais.

▪ Relatório de calculo do decendial trimestral, permitindo extrair o relatório por decêndio, ,ensal ou trimestral, inclusive com os valores das transferências para a conta bancária devida.

▪ Relatório com as receitas e despesas, inclusive por função e subfunção, por período para preenchimento da planilha do SIOPS.

d. TESOURARIA

Este módulo do sistema deverá controlar toda a movimentação financeira efetuada através da tesouraria e dos bancos oferecendo os seguintes controles e funções:

i. Deve aceitar lançamentos resumidos de receita orçamentária e extra orçamentária e ainda lançamentos por documento.

ii. Deve estar integrado com o módulo de arrecadação, gerando lançamento único para cada receita orçamentária e extra orçamentária, permitindo a exclusão do lote integral. O

sistema deverá também, emitir relatório que demonstre os valores que estão sendo integrados, por receitas e por bancos.

iii. Deve permitir devolução e estorno da receita arrecadada.

iv. Deve permitir a Emissão e Anulação de Ordens de Pagamento referentes à:

▪ Empenhos.

▪ Despesas extras.

▪ Restos a Pagar.

▪ Devoluções de Arrecadações.

v. Indicar na ordem de pagamento a nota fiscal vinculada.

vi. Apresentar na tela referente à OP, seus pagamentos e resumo da própria OP, com: total liquidado, total anulado, total pago.

vii. Permitir que o pagamento de OP possa ser efetuado através de cheques, borderôs e avisos bancários (tipos de pagamento).

viii. A emissão de borderô poderá ser realizada via documento ou meio magnético, com inclusão automática de ordens de pagamentos, com vencimento na data do borderô. Deverá permitir a inclusão ou exclusão de itens no borderô.

ix. Deve permitir transferências bancarias, controle de aplicações financeiras, registrando as aplicações e resgates.

x. Permitir efetuar a conciliação Bancária, comparando os valores do sistema com os extratos bancários, gerando arquivo xml para envio a AUDESP.

xi. Deverão estar disponíveis os seguintes Relatórios, na Tesouraria.

▪ Boletim caixa e bancos

▪ Listagem de conferencia de pagamentos e recebimentos: Diária e mensal.

▪ Extratos bancários.

▪ Notas de Ordem de pagamento ou anulações de ordem de pagamento.

▪ Livro Diário de tesouraria

▪ Relação de Notas fiscais do mês.

▪ Relação de despesas a pagar.

▪ Impressão de cheques e documentos de transferência bancária (Docs).

▪ Impressão de cheques de transferência entre contas do mesmo órgão.

▪ Impressão de guias de recolhimento.

▪ Notas de despesas extras.

▪ Recebimentos de receitas orçamentárias

▪ Recebimentos de Receitas extra orçamentárias

e. CONTABILIDADE

Este módulo de contabilidade obrigatoriamente deverá registrar e controlar todos os atos e fatos dos módulos: orçamento, gestão orçamentária, tesouraria, divida ativa, compras e patrimônio. O módulo de contabilidade deverá oferecer os seguintes controles e funções:

i. Estar de acordo com o PCASP e as devidas atualizações do TCE-SP.

ii. Tabela de operações contábeis para todos os níveis de planos contábeis.

iii. Integração com:

▪ Elaboração e Gestão Orçamentária.

▪ Tesouraria.

▪ Controle de Materiais.

▪ Compras e Patrimônio.

▪ Controle de Divida Ativa

▪ Lançamentos Manuais.

▪ Encerramento do Exercício.

iv. A rotina de encerramento anual deverá efetuar:

▪ Encerrar, automaticamente, todos os empenhos estimativos.

▪ Transferência automática dos empenhos com saldo a pagar para restos a pagar.

▪ Apurar o resultado do exercício, gerando, automaticamente, seus lançamentos.

▪ Emitir os relatórios de encerramento previstos em lei.

▪ Efetuar a transferência dos saldos de contas bancárias e contábeis para o novo exercício, com seus saldos iniciais.

v. Deverão estar disponíveis os seguintes relatórios:

▪ Listagem de conferência de lançamentos.

▪ Diário e razão contábeis.

▪ Balancetes e balanços.

▪ Anexos de encerramentos conforme lei 4320.

f. GERAL

Dentre as principais características do sistema devem constar as seguintes:

i. Os relatórios deverão ter opção de impressão em tela e papel. Além disso, poderão ser exportados em diversos formatos, tais como: txt, Word, planilha de Excel e pdf.

ii. O Cadastro de fornecedores deverá ser único no sistema com utilização pelos módulos de contabilidade e compras, checando digito de CNPJ e CPF.

iii. Todos os movimentos deverão ser mantidos de forma a permitir consultas ao orçamento e a toda movimentação de exercícios anteriores e do exercício atual, devendo permitir também a apuração das informações previstas na lei de responsabilidade fiscal.

iv. Deverá gerenciar o acesso às suas várias telas através de Níveis de segurança estabelecidos por perfil do usuário.

v. Deverá ainda registrar todas as transações efetuadas no banco de dados indicando responsável, dados e data e hora da transação.

vi. Deverá dispor de Gerador de relatórios com capacidade para impressão de relatórios ou visualização dos mesmos em tela. Deverá ainda ter capacidade para exportação de registros.

vii. Todos os relatórios deverão oferecer opção de impressão em tela e com logotipo do órgão e várias formas de classificação.

viii. As rotinas diárias independerão do fechamento mensal, permitindo lançamentos em novo mês sem que o anterior seja fechado.

ix. Operação orientada por menu, propiciando fácil interação com o módulo

x. Cadastro de históricos previamente definidos, complementados livremente no ato da digitação do empenho, ordem de pagamento ou outros serviços.

xi. Opção de pré determinar as assinaturas para composição nos relatórios.

xii. Opção de determinar os feriados bancários anuais.

xiii. Opção de não aceitar lançamentos em finais de semana e feriados.

xiv. Opção de predeterminar os tipos de licitação, de acordo com as regras AUDESP.

xv. Exportação de dados para sistemas do TCESP, ou Receita Federal e Secretaria do Tesouro Nacional:

▪ Lei de Responsabilidade Fiscal.

▪ Planilha da Educação.

▪ Informações para a DIRF.

▪ Transferência via WEB de tabelas de lançamentos conforme lay- out definido pelo TCESP – Audesp.

▪ Gerar os arquivos da “ ESCRITURAÇÃO FISCAL DIGITAL – EFD “ em formato compatível com o programa validador do SPED – Sistema Publico de Escrituração Digital.

▪ Gerar planilhas do Siconfi (STN)

xvi. O sistema deverá estar adaptado à utilização do Plano de Contas estabelecido pelo PCASP.

xvii. O sistema deverá atender à legislação vigente de ICMS, IPI, ISS, IRRF (sobre serviços), INSS, PIS, COFINS e CSLL.

xviii. O sistema deverá disponibilizar informações de débitos e créditos de impostos a recolher ou creditar, por período de apuração.

8. SISTEMA DE ADMINISTRAÇÃO DE COMPRAS, LICITAÇÕES E CONTRATOS:

a. Características

O Sistema de Administração de Compras, Licitações e Contratos, deverá possuir os seguintes recursos:

i. Cadastros únicos de Centro de Custos integrados aos demais módulos do sistema;

ii. Permitir o cadastramento das modalidades de licitações para compras de materiais e serviços ou obras e serviços de engenharia com os correspondentes limites de valores;

iii. Permitir o cadastramento da relação de certidões exigidos por lei para a habilitação dos fornecedores;

iv. Permitir o cadastro de Tipos de Contratação, exigido por lei para cadastramento dos contratos;

v. Permitir o cadastramento dos endereços dos locais de entrega de materiais;

vi. Permitir o cadastramento das possíveis Comissões de Licitação;

vii. O cadastro do fornecedor será único e deverá ser integrado com os demais módulos do sistema. Deverá ter, no mínimo, as seguintes informações: Tipo de identificação (pessoa física ou jurídica) CNPJ, CPF, Razão Social/Nome Fantasia, endereço e_mail, contato, capital social, sócios, dados bancários, ramo de atividade, documentos obrigatórios com controle de validade para emissão do CRC;

viii. Emitir o CRC Certificado de Registro Cadastral;

ix. O sistema deverá alertar os usuário quanto ao vencimento das certidões relacionadas no cadastro de cada fornecedor.

x. Permitir o usuário relacionar materiais ou grupos de materiais com as empresas fornecedoras dos mesmos.

xi. Deverá permitir a inclusão automática de um material para um determinado fornecedor, (material x fornecedor) desde que o mesmo participe de algum processo de compras;

xii. Permitir incluir ocorrências de anomalia de fornecimentos nas fichas dos respectivos fornecedores;

xiii. Permitir atribuir ou alterar a situação do fornecedor (suspenso, inativo, cancelado, ativo);

xiv. Identificar empresas como ME e EPP para cumprimento à Lei 123/2006;

xv. Emitir relatório analítico dos dados cadastrais do fornecedor;

xvi. Emitir Relatório de Validade do CRC e Vencidos.

xvii. Permitir a configuração de acesso por item de menu e ou objeto, através de grupos de usuários.

xviii. Possuir procedimento de Geração de Solicitações de Compras, integrada com Sistema de Materiais. Ou seja, a solicitação se utilizará do cadastro de Materiais, o qual armazenará qualquer item a ser licitado;

xix. Permitir a elaboração de Solicitações de Compras pelos diversos departamentos, através de tecnologia Web.

xx. O Sistema deverá estabelecer controle de quais materiais podem ser solicitados por um determinado Centro de Custo.

xxi. O sistema deverá estabelecer controle de dotações por materiais e centros de custos. Ou seja, o usuário poderá registrar previamente em tabela específica, qual será a dotação a ser onerada por um determinado centro de custo na aquisição de um material ou grupo de materiais. Deste modo o sistema deverá:

▪ impedir que a solicitação de compras de materiais seja gerada sem dotação correspondente.

▪ trazer automaticamente a dotação correspondente para cada item da solicitação de compras;

▪ possibilitar, via tela de itens da solicitação de compras, consultar o saldo da dotação.

▪ não deverá permitir a solicitação de itens acima do saldo da dotação, levando em consideração todos os Empenhos anteriores realizados na dotação, bem como todas as Reservas e solicitações de compras elaboradas.

▪ Registrar, em cada uma das solicitações de compras: o Centro de Custo requisitante; a aplicação do item; o Local de Entrega do Mesmo; a Obra ou Veículo para o qual o material se destina e um texto de Observações.

xxii. Possuir o conceito de hierarquia de Centros de Custos. Estabelecer para os Centros de Custos subordinados, as mesmas definições de dotações a serem oneradas em

licitações definidas para seu respectivo Centro de Custo principal.

xxiii. A cada item incluso na solicitação, utilizando a tecnologia WEB, demonstrar as compras pendentes e os dados da ultima compra, tais como: fornecedores, valor e data de aquisição;

xxiv. Possibilitar o registro de estimativas de preços nas Solicitações de Compras;

xxv. Permitir o cancelamento das Solicitações de Xxxxxxx;

xxvi. O sistema deverá permitir realizar solicitações plurianuais comprometendo apenas o saldo da dotação no exercício corrente.

xxvii. Possuir procedimento para efetuar aprovações das Solicitações, através da própria tela do sistema;

xxviii. O sistema deverá permitir aos usuários acompanhar via WEB o andamento das solicitações (autorizada, inserida no processo de compras, entregue no almoxarifado).

xxix. O Sistema deverá, a partir das Solicitações de Compras, gerar opcionalmente, Cotações de Preço, sem a necessidade de haver um Processo de Compras correspondente.

xxx. Permitir agrupar materiais iguais de solicitações diferentes, somando as quantidades.

xxxi. O sistema deverá filtrar automaticamente os fornecedores que fornecem os grupos de materiais vinculados na cotação de preços.

xxxii. Deverá emitir relatório que indique, para um determinado processo licitatório ou cotação de preços, possíveis empresas que atendam total ou parcialmente os itens relacionados.

xxxiii. O sistema deverá possuir as seguintes consultas de Materiais X Fornecedores:

▪ Quais fornecedores já forneceram determinados materiais,

▪ Quais foram os participantes de licitações, nas quais constavam determinados materiais;

▪ Quais últimos valores de compras destes materiais;

xxxiv. O sistema deverá gerar, para uma cotação de preços, uma Planilha Eletrônica a ser enviada aos fornecedores selecionados. Esta mesma Planilha deverá ser lida pelo sistema, atualizando a base de dados com as informações

referentes aos orçamentos preenchidos pelos respectivos fornecedores, sem a necessidade de digitação das mesmas.

xxxv. No “Quadro de Preços” comparativo, permitir:

▪ digitar valor, marca, IPI, desconto, garantia, prazos de validade, condição de pagamento, prazo de entrega e valor para faturamento.

▪ julgamento (menor preço total ou individual, maior desconto e menor taxa)

▪ emitir relatório de classificação de acordo com o julgamento dos valores;

▪ emissão do Mapa Comparativo de Preços, permitindo a importação para o processo de compra pelo preço médio ou menor preço cotado.

xxxvi. O Sistema deverá gerar Processos de Compra a partir de Cotações de Preço ou do agrupamento de várias Solicitações de Compras. Estes Processos deverão ser objetos dos seguintes controles e procedimentos:

▪ Relatórios para pesquisa de preços.

▪ Registrar os processos Licitatórios contendo no mínimo: numero do processo, objeto, modalidade de licitação, numero da modalidade, datas de abertura do processo, da licitação e da proposta técnica.

▪ Controle dos limites por Modalidade de Licitação.

▪ Controlar a inclusão dos fornecedores em um processo de compras, emitindo avisos quando a data de validade do Certificado de Registro Cadastral (CRC) estiver vencida ou a situação do fornecedor não permitir a sua participação na licitação (Exemplo: Suspenso).

▪ Conter recursos para controle da documentação do fornecedor participante por Processo de Compra, levando-se em consideração a modalidade em questão.

▪ Reserva automática de dotação .

▪ Relatório de licitações programadas;

▪ Armazenar todo o trâmite de Abertura e Julgamento da licitação, registrando a proposta comercial e emitindo o mapa comparativo de preços;

▪ Emitir resumo dos ganhadores;

▪ O sistema deverá emitir a Autorização de Empenho, notificando a contabilidade, via sistema, sobre existência desta autorização;

▪ Visualizar e imprimir Notas de Empenho;

▪ Permitir anexar vários tipos de documentos;

▪ Emitir Termo de Homologação;

▪ Geração de relatório ao Tribunal de Contas de todas as modalidades de licitação, por exercício, contendo no mínimo: numero da licitação, objeto, empresas ganhadoras, valores homologados por empresa e numero do contrato

xxxvii. Deverá possuir mecanismos para registrar dados do Edital, tais como: datas de entrega e abertura de envelopes, data de formulação, valor e comissão de licitação.

xxxviii. Deverá permitir o registro dos fornecedores que retiraram o Edital no órgão e emitir recibo de retirada.

xxxix. Permitir informar no processo de compras, quais editais fazem referência ao mesmo;

xl. Emitir relatório de Anexo do Edital com a descrição técnica dos materiais;

xli. Deverá controlar as Empresas que manifestaram interesse de participar de um processo de compras, registrando dados da empresa, representante na manifestação e data da mesma, permitindo a emissão de um comprovante com esses dados.

xlii. O sistema deverá permitir o tratamento da modalidade de “chamada pública” possibilitando classificar para o mesmo material, vários fornecedores como vencedores e valores diferenciados.

xliii. O sistema deverá conter todos os recursos necessários para o registro e realização de Pregão Eletrônico Presencial, indicados a seguir:

▪ Cadastro do processo por lote de itens ou itens individualizados; cadastro de redução mínima dos valores e tipo de julgamento (menor preço unitário ou total, maior desconto e menor taxa);

▪ Registro de fornecedores participantes com diferenciação de ME e EPP para aplicação da Lei 123/2006.

▪ Credenciamento dos respectivos representantes;

▪ Registrar o motivo do não credenciamento;

▪ Registrar a proposta inicial pelo valor total do lote ou individual por item e utilizar a tecnologia de Planilha Eletrônica;

▪ Início do Pregão, a partir do registro e classificação automática das melhores ofertas de acordo com os critérios estabelecidos na Lei do Pregão;

▪ Possibilitar a desclassificação do fornecedor por lote ou inabilitação em todo o processo.

▪ O sistema deverá sugerir, para cada item (ou lote), o próximo preço das ofertas, em função da redução mínima definida para cada lote;

▪ O sistema deverá registrar todas as seqüências de lances (sucessivos, de valores distintos e decrescentes) de cada um dos participantes;

▪ Deverá permitir negociações com os próximos fornecedores participantes, quando a melhor oferta não for aceitável;

▪ Possibilitar a exclusão de lance ou alterar o valor da proposta e declinação devido a erro de digitação;

▪ O sistema deverá registrar o(s) fornecedor(es) ganhador(es);

▪ Registrar ocorrências por lote/item ou da sessão;

▪ Registrar recurso por lote/item;

▪ Permitir a Suspensão e Reativação do lote/item.

▪ O sistema deverá emitir Ata do Pregão, com todos os detalhes da reunião licitatória;

▪ O sistema deverá gerar a partir do Pregão, quando já consolidado, quadro de preços com o resumo do resultado;

▪ Emitir relatório de diferenças econômicas obtidas no pregão, baseado na pesquisa de mercado ou menor valor da proposta inicial com o valor homologado.

▪ Possibilidade de emitir uma ATA quando o pregão for Deserto;

▪ Impressão de relatórios dos itens desertos e dos fracassados.

xliv. Deve estar disponível, no Sistema ofertado pela proponente, a Geração de Xxxxxx, Carta ou Contrato de Compras e Registro de Preços para o fornecedor ganhador de cada licitação.

xlv. O sistema deverá impedir a emissão de pedidos sem a existência de um empenho correspondente e a emissão de autorização de empenho sem a prévia reserva de dotação.

xlvi. Registrar os contratos informando no mínimo: numero do contrato, processo, fornecedor, tipo de contratação, valor do contrato, data de assinatura e termino;

xlvii. O sistema deverá permitir às áreas correspondentes, a execução dos Contratos e Registros de Preços, com emissão de pedidos de fornecimento parciais;

xlviii. O sistema deverá permitir a elaboração de programação de entrega dos materiais nos contratos e pedidos.

xlix. Proporcionar o registro automático, na ficha do fornecedor, de condições de anomalias de fornecimento, em relação à programação de entrega estabelecida, através do sistema de administração de materiais, quando do lançamento da entrada.

l. Possibilitar a exibição e execução do contratos por gestores ou centro de custo autorizados.

li. Não permitir que gestores executem ou visualizem saldos de quantidades dos materiais de outros gestores no mesmo contrato. Com exceção do gestor padrão, este responsável por todos os contratos.

lii. O sistema deverá vincular automaticamente no contrato ou pedido, o empenho e informações correspondentes tais como: dotação e ordem de pagamento;

liii. Realizar o controle financeiro do contrato/pedido e registro de preços (Valores: executado, aditado, empenhado, liquidado e saldos: a empenhar, liquidar e efetivo).

liv. Realizar o controle quantitativo do contrato/pedido e registro de preços (Quantidades: executada, aditada e recebida efetivamente em estoque, saldos: a executar e a receber em estoque)

lv. Permitir controlar a execução dos contratos e registros de preços baseando-se no saldo financeiro do empenho e do contrato, impedindo execuções que ultrapassem o saldo existente.

lvi. Controlar a execução dos contratos e registros de preços impedindo execuções que ultrapassam o saldo quantitativo inicialmente solicitado para cada material.

lvii. Controlar a data de termino do contrato e registro de preços, impedindo sua execução quando vencido.

lviii. O sistema deverá emitir, em tela, um alerta de vencimento do contrato e registro de preços, tendo sua periodicidade parametrizada.

lix. Possuir mecanismos de análise do consumo previsto x consumo realizado no próprio Contrato/Pedido, alertando da necessidade de aditamento ou de redução do mesmo. Emitir relatório de Alerta de vencimento e condições de consumo do contrato (abaixo ou acima da média);

lx. Permitir o aditamento de prazo, quantidade e valor de um Contrato/ Pedido e Registro de Preços;

lxi. Deverá possuir rotina de rescisão total/parcial de itens de um contrato/pedido, para uso posterior em outro contrato/pedido.

lxii. Deverá possuir rotina de reajuste de preços para os itens de um contrato/pedido e registro de preços. Os pedidos parciais emitidos após esta operação dever conter os novos valores.

lxiii. Permitir consulta ao cadastro de notas fiscais emitidas pelos fornecedores.

lxiv. Possuir ferramenta para registro dos pedidos de Empenho e Anulações para Contratos/Pedidos plurianuais, emitindo relatório para envio ao Setor Financeiro.

lxv. Possuir mecanismo de registro e emissão de termos de recebimento dos Pedidos/Contratos e registro de preços, com dados do material analisado e seus resultados.

lxvi. Emitir extrato financeiro e por material do contrato e registro de preços;

lxvii. Emitir relação de contratos por centro de custo gestores; lxviii. Emitir relatório de saldo para execução do contrato e registro

de preços;

lxix. Emitir relatório por data de assinatura do contrato e registro de preços;

lxix.lxx. Possibilitar a confecção dos contratos, incluindo automaticamente os dados da empresa assim como o valor unitário e total contratado.

lxx.lxxi. Emitir relatório que demonstre o recebimento de materiais, por contrato, pedido ou registro de preços, apontando o atraso na entrega ou dias para recebimento.

lxxii. Disponibilizar as informações necessárias para integração dos contratos com a AUDESP, através do sistema da contabilidade.

lxxi.lxxiii. Transferência via WEB de tabelas de lançamentos conforme lay-out definido pelo TCESP-AUDESP.

lxxii.lxxiv. Relatório de Contratos Plurianuais

lxxiii.lxxv. Deverá possuir mecanismos de classificação do material para integração com o sistema de custos.

lxxiv.lxxvi. Deverão estar disponíveis os seguintes Relatórios com opção de impressão em tela , papel e exportação no mínimo para PDF, Excel e Word:

▪ Solicitação de Compras.

▪ Pedido ao Fornecedor.

▪ Quadro de Preços.

▪ Resumo do Quadro de Preços.

▪ Reserva de dotações.

▪ Autorização para empenho.

▪ Pesquisa de compras.

▪ Livros para o Tribunal de Contas.

▪ Controle de Prazos do Processo

▪ Condições gerais das programações de entrega.

▪ Ficha de fornecedores, contendo ocorrências de anomalias de entrega.

▪ Rol de fornecedores de um grupo, subgrupo ou material específico.

▪ Rol de fornecedores de materiais contidos em um processo de compra, para finalidade de cotação de preços.

▪ Rol de fornecedores em ordem alfabética.

▪ Rol de materiais entregues, contrato, pedido ou carta.

▪ Rol de materiais entregues, referentes a um fornecedor

▪ Rol de solicitações de compras não aprovadas e canceladas.

▪ Rol de solicitações de Abertas (já aprovadas – liberadas para ingressar em um processo de compras).

▪ Rol de solicitações em Andamento.

▪ Rol de solicitações por dotação.

▪ Solicitação de Orçamento ao Fornecedor.

▪ Emitir relação de solicitações de compras pendentes (emitidas e não reservadas/empenhadas) em determinada dotação.

▪ Comparativo dos valores estimados e realizados.

▪ Estatística de Licitação, relatório no qual, para cada tipo de modalidade de compra, seja possível verificar qual foi a despesa realizada, para cada uma, e para cada tipo de material (objeto da licitação).

▪ Emitir relatório de relação de compras no período.

▪ Licitações concluídas e emitidas

▪ Processo de compras efetivados

▪ Relatório de gastos por secretaria e por objeto

▪ Permitir consulta de solicitações pelo número da reserva

▪ Permitir o estorno de solicitações geradas como ATA para solicitação “normal”

▪ Possibilitar a visualização do valor total da solicitação na 1ª tela

▪ Impedir que solicitação de compra seja gerada sem conta bancária e sem dotação

▪ Possibilitar a visualização do status de andamento da solicitação (em tramite; aguardando reserva; aguardando empenho)

▪ Possibilitar o recebimento da SC pelo comprador responsável, com a inclusão de seu nome.

9. SISTEMA DE ADMINISTRAÇÃO DE MATERIAIS (ALMOXARIFADO)

a. Características

O Sistema de Administração de Materiais, deverá possuir os seguintes recursos:

i. Cadastro de Almoxarifados;

ii. Cadastros únicos de Centro de Custos e Órgãos, integrados aos demais módulos do sistema;

iii. Cadastro de Obras;

iv. Cadastro de Viaturas;

v. Cadastro de Unidades de Medidas;

vi. Cadastro de Rateios;

vii. Cadastro de CFOP (Código Fiscal de Operação e Prestação).

viii. Cadastro de grupos e subgrupos de materiais;

ix. Cadastro único de materiais, qualificados em grupos e subgrupos.

x. Ferramenta para definir os departamentos que podem acessar determinados almoxarifados, realizando movimentações nos materiais neles armazenados.

xi. O Sistema deverá estabelecer controle de quais materiais podem ser requisitados por um determinado Centro de Custo.

xii. Permitir que a criação e alteração de quaisquer tipos de movimentações, referentes aos materiais estocáveis e não estocáveis: entradas, saídas, transferências, requisições, doações..., seja realizada pelo próprio usuário, sem a necessidade de que sejam solicitadas alterações de programa para tal finalidade.

xiii. Permitir estabelecer quais usuários poderão efetuar cada uma das movimentações parametrizadas (entradas, saídas, transferências, doações, entre outras)

xiv. Definir os materiais pertencentes a um determinado Grupo como sendo de uso pessoal.

xv. O sistema deverá permitir ou não, através de parâmetro, a geração da requisição de materiais cujo saldo seja zero. Quando não permitido o sistema deverá impedir a requisição de materiais além do seu saldo disponível. Este saldo disponível deverá levar em consideração as quantidades já solicitadas, das requisições ainda não atendidas.

xvi. Possuir recurso que indique a quantidade mínima para a requisição de um determinado material. Assim sendo, só deverá permitir, para este material, a requisição de uma quantidade igual à parametrizada ou igual a um múltiplo da mesma.

xvii. O sistema deverá, além do código específico atribuído pelo sistema a cada item do cadastro de materiais, em função do grupo subgrupo ao qual pertence, permitir a busca destes itens através: da descrição, ou parte da descrição dos itens; de código exclusivo do fabricante.

xviii. O sistema deverá possibilitar a consulta de materiais a serem utilizados nas viaturas da frota nos catálogos de autopeças fornecidos pelo fornecedores. Para isso, deverá importar para o banco de dados as informações do catalogo de forma legível e organizada, contendo, código da peça do fabricante, descrição e valor.

xix. Registro e controle físico e financeiro dos materiais estocáveis individualizado por Almoxarifado e Sub Almoxarifado;

xx. Consulta do preço médio, data, valor unitário e fornecedor da ultima compra, dos materiais ou serviços cadastrados;

xxi. Consulta de saldos e datas de validade, de lotes de materiais;

xxii. Consulta de requisições, devoluções e solicitações pendentes por material;

xxiii. Consulta, em tela, do consumo do material por almoxarifado ou geral, exibindo a media dos últimos 12 meses.

xxiv. O sistema deverá incluir, automaticamente, histórico no cadastro de materiais quando quaisquer alterações forem realizadas no mesmo.

xxv. O sistema deverá permitir, a nível individual de material, o armazenamento de informações a serem utilizadas em licitações, tais como: requisição de amostras, requisição de laudos técnicos, etc.. Estas “exigências” deverão ser tabeladas, podendo ser atribuídas a outros materiais.

xxvi. O sistema deverá emitir etiquetas para os materiais que deram entrada através de uma determinada nota fiscal. Deverá ser emitida uma etiqueta para cada um destes materiais. Nesta etiqueta, além do código e descrição do material deverá ser impressa a sua localização física dentro do almoxarifado (corredor, prateleira e box).

xxvii. O sistema deverá disponibilizar aos diversos departamentos, através de tecnologia Web, recurso que permita a elaboração de requisições e devoluções de materiais, consulta ao saldo e localização dos mesmos.

xxviii. O sistema deverá possuir dois tipos de requisições: um para materiais de uso pessoal e outro para os demais materiais. Desta forma, deverá possuir controle para não permitir que um material de uso pessoal seja requisitado através de uma requisição que não a específica para este tipo de material.

xxix. O sistema deverá efetuar o controle de materiais de utilização pessoal. É necessário que ele registre as requisições ou devoluções deste tipo de material, assim como o atendimento das mesmas em “fichas” dos funcionários solicitantes.

xxx. Exibir em tela e relatório os materiais pessoais utilizados por cada funcionário.

xxxi. Possibilidade de utilizar a rotina de “pré requisições”, com a finalidade de criar modelos de requisições de materiais utilizadas freqüentemente e, a partir da mesma, gerar requisições automaticamente com os itens e quantidade predefinidos.

xxxii. O sistema deverá possuir recursos nas requisições e devoluções de materiais para: a emissão, controle e movimentação total ou parcial no estoque, dando condições ao usuário de informar a quantidade que cada item será atendido.

xxxiii. Deverá permitir a emissão de requisições/devoluções de materiais ao estoque com seu atendimento imediato, sem a necessidade de efetuar novos lançamentos.

xxxiv. O sistema deverá possuir controle para armazenamento do mesmo material, no mesmo almoxarifado e localização, mas as quantidades separadas por órgão.

xxxv. O sistema deverá conter recursos que impeçam um centro de custo, classificado em um determinado órgão, de utilizar a quantidade de material disponível para outro órgão no mesmo almoxarifado. Somente poderá requisitar a quantidade de material disponível, registrada para o órgão correspondente.

xxxvi. O sistema deverá efetuar o controle de materiais em estoque e de sua movimentação diária, alertando quando forem

atingidos os níveis de estoque máximo, mínimo e de ressuprimento.

xxxvii. O sistema deverá permitir o armazenamento de materiais em lotes, cada qual com sua data de validade. É necessário também que o sistema tenha recursos para indicar lotes com data de validade vencida ou a vencer em um determinado período.

xxxviii. Deverá indicar quais lotes serão utilizados para o atendimento de uma requisição, priorizando os de data de validade mais próxima.

xxxix. O sistema deverá registrar os materiais e a mão de obra utilizados na manutenção das viaturas existentes no órgão, gerando em relatório de consumo de materiais /serviço por viatura.

xl. Permitir a importação de tabelas de serviços insumos (exemplo: PINI), para o controle de andamento de Obras.

xli. O sistema deverá possuir ferramentas para o acompanhamento de Obras, desde seu cadastramento até o encerramento de cada uma das fases constituintes, parametrizadas pelo usuário. Deverá possibilitar também o registro das medições de cada fase.

xlii. O sistema deverá registrar os materiais e a mão de obra utilizados nas obras realizadas, gerando em relatório o consumo de materiais / serviços por obra.

xliii. Permitir o recebimento de Notas fiscais pelo almoxarifado gerando automaticamente dados para a Contabilidade (Nota Fiscal), Patrimônio (caso de material patrimoniável), Compras (Controle de execução do contratos/pedidos) e Frota (caso de materiais para conserto/conservação de veículos).

xliv. O sistema deverá permitir, em sua integração com o sistema de compras, a baixa total ou parcial de Solicitações de Compras, contidas em pedidos ou contratos. Isto deverá ser realizado através dos lançamentos do almoxarifado durante o recebimento dos materiais.

xlv. Deverá permitir, no registro das entradas de materiais e serviços (NF e outros), informar o CFOP, apurando as bases de cálculo e valores do ICMS e IPI conforme parametrizado.

xlvi. Emitir automaticamente, na digitação dos lançamentos de entradas, uma nota de recebimento com todas as informações do lançamento.

xlvii. O sistema deverá possuir recurso, durante a digitação dos lançamentos de entradas diretas (aquelas referentes a materiais que não são armazenados em almoxarifados, tais como bens patrimoniais), que possibilite a criação e emissão automática de uma requisição de material.

xlviii. Deverá permitir a utilização de rateios para lançamento de entradas/saídas. Desta forma, quando for digitado um lançamento referente a um rateio, deverá ser gerado um lançamento para cada um dos centros de custo que compõem o rateio, na proporção estabelecida pela definição do rateio (percentagem para cada um dos centros de custos do rateio em questão).

xlix. Permitir a consulta ao Cadastro de Notas Fiscais emitidas pelos fornecedores.

l. Deverá possuir ferramenta para estorno de lançamentos individuais ou por Nota Fiscal.

li. Possibilitar a alteração de informações armazenadas nos movimentos de estoque sem necessidade do estorno, como por exemplo: centro de custo, numero da nota fiscal, viatura, obra, entre outros que não interfiram em valores ou quantidades.

lii. Controle de saldos do mesmo material em mais de um almoxarifado, permitindo o lançamento de transferência de quantidade entre eles.

liii. Possuir ferramenta que realize a transferência de quantidades de um determinado material, de uma localização para outra, em um mesmo almoxarifado (corredor, prateleira, box), sem a necessidade da geração de um lançamento.

liv. Possuir ferramenta para transferência de saldo entre lotes de um mesmo material, sem a necessidade de geração de um lançamento.

lv. Possuir rotinas de cálculo automático de: estoque máximo, mínimo e nível de ressuprimento, a partir do consumo efetivo dos materiais selecionados, durante um período de tempo estabelecido pelo usuário.

lvi. O sistema deverá ser provido de ferramentas que auxiliem o administrador na obtenção de informações de materiais a serem comprados, em função de parâmetros tais como:

▪ Média de consumo nos últimos x meses.

▪ Quantidade de meses a serem providos pela compra.

▪ Saldo no estoque.

▪ Solicitações de compra em andamento.

▪ Nível de ressuprimento.

lvii. Deverá possuir recurso para “Planejamento de Compras”. Isto deverá ser realizado a partir do consumo real dos materiais em um período estabelecido pelo usuário. Deverá indicar a quantidade a ser comprada para prover o estoque para um determinado número de meses, também determinado pelo usuário. Após a análise feita pelo sistema, deve possuir mecanismo de alteração dos valores gerados.

lviii. O sistema deverá possuir recursos que demonstrem a convergência ou não para uma meta pré estabelecida de “falta de materiais estratégicos”, ao longo do tempo. Esta análise deverá ser gráfica.

lix. A Integração com o Sistema de Contabilidade Pública deverá ser realizada através da geração de lançamentos mensais na própria base de dados do mesmo, sem a geração de arquivos intermediários (textos).

lx. O Sistema de Administração de Materiais (Almoxarifado) deverá integrar-se ao Sistema de Contabilidade e estar adaptado ao módulo AUDESP.

lxi. O Sistema deverá estar provido de procedimento destinado ao registro e controle de inspeções de materiais. Deverá emitir documento que registre o laudo deste procedimento. Caso o resultado da inspeção não seja satisfatório, deverá ser registrada uma ocorrência no cadastro do fornecedor correspondente.

lxii. O sistema deverá prever a devolução de materiais estocáveis para o fornecedor, emitindo comprovante e atualizando o saldo do estoque e pedido/contrato.

lxiii. O sistema deverá possuir recurso para o agrupamento de determinados almoxarifados (indicados pelo usuário), para a emissão de balancetes.

lxiv. O sistema ofertado pela proponente deverá possuir rotinas de inventário de materiais que disponibilizem os seguintes recursos:

▪ Permitir a seleção de grupos de materiais para inventário.

▪ Manter bloqueados para movimentações, todos os materiais que foram selecionados para contagem.

▪ Dispor de interface que possibilite a utilização de coletor de dados para a contagem dos materiais.

▪ Possibilitar inventários parciais do estoque, a partir de faixas de localizações físicas: corredor, prateleira e box.

▪ Permitir inventariar um ou mais almoxarifados, bloqueando somente os materiais neles selecionados. Desta forma deverá possibilitar, durante o procedimento de inventário, a movimentação dos demais materiais e almoxarifados não bloqueados.

▪ Efetuar o lançamento de acerto de inventário automaticamente após um determinado número de contagens, parametrizado, quando a contagem realizada expressar um valor diferente de quantidade registrada no cadastro do material.

lxv. O Sistema deverá registrar, por material e centro de custo, todas as requisições que não foram atendidas devido à falta de saldo no estoque. Tal registro deverá permitir a elaboração de estatísticas que terão por objetivo auxiliar o planejamento de compras.

lxvi. No mínimo deverão, estar disponíveis os seguintes relatórios impressos em tela, papel e exportado no mínimo para formato PDF, Word e Excel:

▪ Rol de inventário, por ordem de localização física de materiais.

▪ Rol de movimentação.

▪ Posição Financeira (por material e conta contábil).

▪ Requisitantes por itens e itens por requisitantes sintético e analítico.

▪ Controle de EPI’s por funcionários.

▪ Últimos fornecedores do material.

▪ Rol de Planejamento de Compras.

▪ Rol de grupos, subgrupos e materiais cadastrados.

▪ Rol de requisições de materiais de utilização pessoal, pendentes.

▪ Rol de Centros de Custos.

▪ Ficha de Funcionários, contendo os materiais já requisitados pelos mesmos.

▪ Lotes de materiais com data de validade vencida.

▪ Materiais com estoque: Acima do máximo; Abaixo do mínimo; Abaixo do nível de ressuprimento.

▪ Rol de materiais em ordem alfabética.

▪ Relatório de materiais por viaturas.

▪ Relatório de materiais por obras.

▪ Mapa de consumo de materiais por centros de custo, demonstrando consumo mensal e média de consumo mensal.

▪ Balancete mensal unificado e por Almoxarifado.

▪ Consumos: Por Material Por Funcionário, Material sem Consumo.

▪ Notas Fiscais por Período.

▪ Obras: Planilha de Medição, Execução Orçamentária e Itens por Obra

▪ Deverá emitir os relatórios de Registro de Entrada – Modelo 1 ou 1-A, Registro de Saída – Modelo 2 ou 2-A e o Registro de Apuração do ICMS – Modelo 9, conforme legislação vigente.

▪ Emitir relatórios de estatísticas de consumo por Grupo de Material

10. Sistema de Administração do Patrimônio

Características

O Sistema de Administração do Patrimônio deverá estabelecer o total controle sobre os Bens Patrimoniais, contando com os seguintes recursos:

i. Tratamento das Aquisições: o Sistema deverá possuir tela na qual os itens poderão ser inclusos individualmente. Nela, as informações contidas na Nota Fiscal ou documento de outro tipo de entrada do Bem, como por exemplo doação, poderão ser digitadas. Através de integração com o Sistema de Administração de Materiais e Compras, o movimento de aquisição do Patrimônio também deverá poder ser gerado automaticamente quando da entrada do material no Almoxarifado.

ii. Tratamento de Baixas, totais ou parciais, permitindo a emissão de documento correspondente (Termo de Baixa).

iii. Tratamento de Transferências, totais ou parciais, permitindo a emissão de documento correspondente (Termo de Transferência).

iv. Controle de empréstimos de Bens a funcionários outros que o responsável pelo mesmo.

v. Controle de envio para reparos, com emissão de documento que identifique o item, o motivo do reparo, data, responsável pelo envio e empresa para a qual foi enviado o bem.

vi. Capacidade de obter o valor do bem, assim como o de sua depreciação acumulada, corrigidos e convertidos para a moeda atualmente vigente, a partir do valor de compra constante da nota fiscal.

vii. Permitir o cálculo mensal de depreciação de um ou todos os itens cadastrados.

viii. Permitir o cadastro e controle de vencimentos de Apólice de Seguros dos bens cadastrados.

ix. Classificação dos itens patrimoniais em contas, em função das suas características e diferentes taxas de depreciação.

x. Qualificação dos itens em função de suas características, através de tabela definida pelo próprio usuário, independente do Plano de Contas. Esta qualificação deverá ser utilizada nas seleções de bens nos relatórios ou pesquisas.

xi. Possuir mecanismos para a exportação de informações referentes às depreciações mensais dos itens, acumuladas nos centros de custos correspondentes, para o módulo de Custos.

xii. Possibilidade de realização de inventário dos bens patrimoniais com a utilização de equipamentos coletores de dados ou Palmtops.

xiii. O Sistema deverá possuir Integração com o Sistema de Contabilidade Pública. Através desta integração, o Sistema de Administração de Patrimônio deverá transmitir à Contabilidade as informações a serem enviadas à Audesp.

xiv. O sistema de Administração do Ativo Imobilizado deverá disponibilizar, no mínimo, os relatórios a seguir. O Sistema deverá possibilitar que estes relatórios sejam: impressos; apresentados em tela; convertidos para arquivos PDF ou Planilha Excel:

▪ Termo de Responsabilidade: identificando a lista de bens sob a tutela de determinados funcionários.

▪ Termo de Transferência.

▪ Termo de Baixas.

▪ Itens por Ordem de Chapa.

▪ Aquisições, dentro de uma faixa de datas.

▪ Movimentos: Aquisições, Transferências e Baixas.

▪ Emissão de Rol de Baixas.

▪ Itens baixados em um intervalo qualquer de datas.

▪ Emissão de ficha demonstrativa de baixa, individual por item do Patrimônio.

▪ Relação de bens patrimoniais, agrupados por:

- Contas e Subcontas do Patrimônio.

- Locais.

- Centros de Custos.

- Processos de compra, adquiridos em um intervalo de datas.

▪ Para a emissão destes relatórios, os bens poderão estar filtrados por "qualificadores".

▪ Relação do valor residual de bens do Patrimônio, por Centro de Custos e Locais.

▪ Resumo por Ano de Aquisição

▪ Totais por Contas do Patrimônio

▪ Relações diversas de:

- Qualificadores.

- Plano de Contas do Patrimônio.

- Centros de Custos e Locais.

- Itens Patrimoniais, por funcionário responsável.

- Itens por ordem de chapa.

- Itens por ordem alfabética

▪ Emissão de materiais por funcionários responsáveis ou aos quais foi emprestado o item;

▪ Balancete, constando:

- Saldo do mês anterior.

- Totais de movimentos de aquisição.

- Totais de movimentos de baixas e transferências.

- Saldo atual do mês.

▪ Demonstrativo dos bens totalmente depreciados, que precisam de reavaliação, de acordo com as normas internacionais de contabilidade.

▪ Relatório de Integração Contábil

▪ Relatórios de Apólices de Seguros a Vencer

▪ Relatório de Depreciação por Centros de Custos

xv. O Sistema de Controle de Patrimônio deverá integrar-se ao Sistema de Contabilidade, e estar adaptado ao módulo AUDESP.

xvi. O sistema deverá possuir recurso que permita a criação, pelo próprio usuário, de campos específicos de detalhamento dos bens, em seu cadastro.

xvii. O Sistema deverá disponibilizar ferramenta que permita a renumeração dos itens, de acordo com a necessidade do usuário.

xviii. O Sistema deverá possuir recurso para o preenchimento das informações comuns a um grupo de itens a serem incorporados.

xix. O Sistema deverá possibilitar a transferência simultânea de vários itens pertencentes a um local, para outro local, em uma única operação.

xx. O Sistema deverá possuir "Mecanismo de Segurança" a fim de estabelecer quais recursos do sistema ficarão disponíveis a cada usuário, ou tipo de usuário.

xxi. O Sistema deverá possibilitar a transferência simultânea de vários itens pertencentes a uma classificação, para outra classificação, em uma única operação.

xxii. O Sistema deverá possibilitar a baixa de diversos bens ou de todos os bens de um determinado local, em uma única operação.