Compras e Licitação 1.96.192.0

Desenvolvida rotina para aprovação em níveis da Solicitação de Despesa

• Desenvolvida rotina para que seja possível por entidade a definição de aprovação da Solicitação de Despesa em níveis, com usuários vinculados a cada nível de aprovação, com tipos de Status definidos, com aprovação de acordo com valores, possibilidade de utilização somente em unidades orçamentárias específicas, em que somente após solicitação devidamente aprovada, sendo possível a geração da NAD respectiva. O fluxo é definido por entidade, não sendo possível fluxo por unidade orçamentária por exemplo, o que caracterizaria em despadronização e principalmente por não permitir os controles da etapa de cada solicitação, na tela de Consulta de Despesas reformulada para tal.
• Telas alteradas e implementadas para a rotina:

Cadastros -> Parametrização -> Status da Solicitação

• Desenvolvido cadastro para definição dos níveis para aprovação. Em cada nível criado, definição da Situação em que quando solicitação aprovada pelo nível, a solicitação é aprovada apenas quando aprovada a solicitação em nível que seja de Situação Aprovada;
• Possibilidade de inclusão de valores de faixa para que seja possível por exemplo que solicitações aprovadas por secretário com valor até R$ 100.000,00, sejam definidas como aprovada, estando liberadas para NAD e solicitações com valor acima deste (novo status), sejam encaminhadas para aprovação pelo Prefeito por exemplo;
• Opção para vinculação dos usuários a cada Status, em que de acordo com o usuário é apresentada a possibilidade de aprovar a solicitação apenas quando estiver aprovada por status anterior da qual é dependente;
• Opção para definição de fluxo, com identificação da dependência entre Status, ou seja:

Se entidade possuir 3 níveis de aprovação:

• 1 – Geração da Solicitação;
• 2 – Aprovação por Conferente;
• 3 – Aprovação por Secretário;

No cadastro do status inicial não é necessário vincular nenhum usuário com permissão, pois toda solicitação terá um status inicial gerado com o status definido em parâmetro;

No nível 2 – Aprovação por Conferente, indica-se que o nível 2 é dependente do nível 1. É possível que um status seja dependente de dois níveis, quando situação de opção de Rejeição;

No nível 3 – Aprovação por Secretário, indica-se que o nível 3 é dependente do nível 2. Dessa maneira, apenas é possível que o secretário faça a aprovação da solicitação no seu nível, se esta estiver aprovada pelo nível 2 e assim por diante;

Nos casos de regras por valor, necessidade de dois status, em que um é do valor X ao Y e o outro do Y até o valor máximo definido;

As situações dos status devem ser utilizadas da seguinte maneira:

• Situação Pendente: Para o Status Inicial, que é criado quando gerada a solicitação de despesa e para quando o Status for de não Aprovação, para que se rejeitada a solicitação, volte ao início dos níveis de aprovação, voltando ao status inicial para que comece a tramitar novamente;
• Situação Análise: Para os Status em que forem de aprovação intermediária, ou seja níveis que não aprovam definitivamente a solicitação. Quando uma solicitação estiver em nível que a situação for de Análise é bloqueada a sua edição para evitar alterações posteriormente a aprovações realizadas;
• Situação Aprovado: Para os Status em que forem de aprovação final da solicitação. Pode existir mais de um Status assim em casos de regras de valor, em que um status pode aprovar até determinado valor e caso não, outro nível que realiza a aprovação;
• Situação Rejeitado: Para esta situação será implementado posteriormente para que seja possível indicar qual o tipo de rejeição/inconsistência na solicitação, que terá um cadastro específico para posterior levantamento de deficiências no preenchimento para instruções aos usuários;

Opções -> Configurações -> Permissões de Acesso

• Inclusão de opção de Filtro Status Padrão no cadastro do usuário. Este filtro definido será utilizado para abertura da tela Central de Solicitações com o filtro em que o usuário tem responsabilidade por efetuar as aprovações. Para tanto, se o usuário for do nível 2, no filtro padrão deve ser colocado o nível anterior de aprovação, para que ao carregar a tela, sejam demonstradas as solicitações aprovadas do nível anterior ao usuário e que estão sob sua responsabilidade de análise. O usuário poderá verificar solicitações de qualquer Status, com o filtro aberto para tal;

Cadastros -> Consultas -> Despesa para Aprovação

Tela anterior redesenhada com novos filtros, legenda e opções:

• Filtro por usuário, para pesquisar as solicitações geradas por usuário;
  Filtro por unidade orçamentária;
  Filtro por data inicial e final, carregando por padrão do início do exercício até a data atual;
  Filtro de Status, carregando por padrão aquela definida no cadastro de usuário;
  Opção previamente marcada não demonstrar solicitações que estejam já com NAD gerada;
• Na tela foi ajustada a questão de demonstrar apenas as solicitações das unidades orçamentárias as quais o usuário possui acesso;
• Incluído acesso rápido ao entrar no sistema com atalho CTRL + G;
• Incluído acesso rápido com clique com botão direito na tela inicial do sistema e opção Despesas para Aprovação;
• A partir da tela, efetuando duplo clique na solicitação desejada, carregando a tela de Solicitação com os dados da solicitação em que efetuou o duplo clique;

Opções -> Parâmetros -> Solicitações

Novos parâmetros sendo:

• Status padrão: (Para indicação do status padrão para a Solicitação de Despesa, que será o status inicial quando efetuada a geração da solicitação);
• Unidades que utilizam status: (inclusão das unidades orçamentárias que estarão utilizando a aprovação em níveis). Podem ser incluídas diversas unidades orçamentárias, compostas de órgão e unidade (exemplo: 02001). Se deixado em branco, todas as unidades orçamentárias estarão utilizando a rotina de Aprovação de Níveis;
• Informação importante: Não é necessário marcar o parâmetro [ ] Utiliza aprovação de Solicitação, pois para o sistema identificar que é utilizada a aprovação em níveis é utilizado o parâmetro de Status padrão. As entidades que já utilizam a aprovação simples, continua da mesma maneira, mas o ideal seria modificarem para utilização desta forma que é mais transparente e definida, relacionando usuário a status e registrando de forma clara as informações de aprovação;

Movimento -> Processo Licitatório -> Solicitação de Despesa

• Inclusão de nova aba Acompanhamento Status, em que são demonstrados e inseridos todos os status de Aprovação, geração e devolução da Solicitação de Despesa. Esta aba apenas estará demonstrada em solicitações das unidades orçamentárias indicadas em parâmetro, ou para todas se nenhuma unidade estiver designada nos parâmetros;
• Para que o usuário possua acesso a apenas realizar as aprovações não é necessário que o mesmo tenha acesso as funções de Alterar e novo da tela de Solicitação por exemplo. Basta que o mesmo possua acesso a tela de Solicitação, com permissão a unidade orçamentária e relacionado nos status com a permissão.
• Para a indicação da aprovação na solicitação, o usuário realiza a abertura da solicitação, acessa a Aba Acompanhamento Status, selecionando o Status desejado (somente serão definidos os status de acordo com a permissão do usuário e caso a solicitação esteja em status que permita que o usuário de acordo com sua permissão esteja efetuando a aprovação ou rejeição;
• Todo o controle da opção que é demonstrada para o usuário é definido na tela Cadastral de Status de Solicitação, com relação a vinculação do usuário no Status, com indicação de qual Status é dependente do Status ao qual o usuário esteja vinculado, de acordo com os valores e tipo, em que se solicitação estiver em status que não seja antecessor ao status de permissão do usuário, nada é demonstrado, habilitando a opção de aprovação apenas se a solicitação tiver sido aprovada em status anterior ao do vínculo do usuário;
• Bloqueio da alteração da Solicitação de Despesa que se encontrar em Status que seja do tipo Análise ou Aprovado;
• Desenvolvido novo modelo de impressão da Solicitação de Despesa, que será utilizado pela Prefeitura de Maringá. O rpt é o Requisição Maringá2018, que teve toda uma reestruturação com demonstração de diversas novas informações e detalhamentos, inclusive com subreport para nova questão de assinaturas quando utilizada a Aprovação em Status, em que serão demonstradas as etapas em que a Solicitação passou, com a definição de data e usuário que realizou, eliminando a necessidade de solicitar todas as assinaturas como era feito anteriormente, gerando grande deslocamento de pessoas e dispêndio de recursos para tal atividade;
• Na demonstração dos Status de Acompanhamento na solicitação, demonstrado além da data e hora, Status e usuário, o nome do computador e IP em que foi gerado o Status, que posteriormente poderá ser utilizado para identificar usuários que por exemplo estão gerando a solicitação e aprovando, utilizando o usuário da pessoa responsável pela aprovação;
• Verificação de Certidões Vencidas – utilização de módulo Único completo
• Adequada a validação dos parâmetros para demonstrar que existem certidões vencidas nas telas de Solicitação de Despesa, NAD, Contrato, Aditivos e Homologação, em bases que utilizam o cadastro único total, não existindo a opção anterior de digitação das certidões. Para tal, a validação será efetuada, demonstrando lista para o usuário das certidões vencidas, possibilitando a abertura da tela de Certidões do módulo Único, com o preenchimento mais assertivo, não necessitando da consulta certidão a certidão para identificar qual está vencida para preenchimento, com a exibição da lista facilitando a usabilidade;

Opções -> Parâmetros->Solicitações ->

• Status Padrão: Para indicar o tipo de Status Padrão para a geração das solicitações de despesa, quando utilizada rotina de aprovação em níveis;
• Unidades que utilizam Status: Para indicar quais unidades orçamentárias irão utilizar aprovação em níveis na solicitação;

Contrato ->

• Forma de Validação para abertura de Solicitações e Nads: Para definir qual a validação de data utilizada para as Solicitações e NADs com vínculo de contratos ou atas;

Anexo ->

• Cria lote exclusivo para itens não desmembrados conforme a lei 147/2014, para que seja criado um terceiro lote no desmembramento, com itens que não foram desmembrados;

Movimento -> Processo Licitatório -> Anexo I

• Disponibilizada nova forma de desmembramento dos itens referentes a Lei 147/2014. Nesta nova forma, funciona da seguinte maneira:
• São incluídos os itens no Lote 1, com valores atribuídos. Executa-se a rotina de desmembramento.

Se existirem itens com valor máximo acima de R$ 80.000,00 e forem divisíveis, o sistema procederá da seguinte maneira:

• Lote 1: Itens que foram desmembrados com percentual de 75%;
  Lote 2: Itens que foram desmembrados com percentual de 25%;
  Lote 3: Itens que não foram desmembrados;

Na maneira inicial:

• Lote 1: Itens que foram desmembrados com percentual de 75% e itens não desmembrados;
• Lote 2: Itens que foram desmembrados com percentual de 25;

Para utilizada esta nova opção disponibilizado parâmetro para não interferir na maneira utilizada anteriormente pelos usuários:

Opções -> Parâmetros -> Anexo ([ ] Cria lote exclusivo para itens não desmembrados conforme a lei 147/2014)

Movimento -> Processo Licitatório -> Termo de Referência

• Adequação no carregamento das informações da descrição do item no Termo de Referência e impressão via Crystal, para demonstração de acordo com o parâmetro quanto a inclusão da Descrição ou Especificação advinda do módulo de Almoxarifado, quando utilizado item no Anexo;

Movimento -> Processo Licitatório -> Solicitação de Despesa

• Desenvolvido novo rpt de Solicitação de Despesa para a Prefeitura de Maringá, com detalhamento de informações e inclusão de outras, inclusive já abrangendo questão da aprovação de Solicitação em níveis, podendo ser utilizado para personalização de modelos para outras entidades. Rpt Requisição MARINGÁ2018;
• Alteração na demonstração do saldo quantitativo de itens dos processos, para considerar os quantitativos dos itens de aditivos efetuados em contratos gerados em entidade distinta a do processo licitatório;
• Alteração de validação quanto a data da Solicitação utilizar data de início de vigência ou data de assinatura do contrato, considerando parâmetro:
  Opções -> Parâmetros -> Contrato -> Forma de Validação para abertura de Solicitações e Nads (opções: Considerar a Data de Assinatura do Contrato ou Considerar o Início de vigência do Contrato);

Movimento -> Processo Licitatório -> Cotação

• Adequação no cálculo do valor total dos itens (considerando arredondamento com 4 casas decimais) e demonstração de apenas duas no campo valor total;

Movimento -> Conclusão de Processo -> NAD

• Alteração de validação quanto a data da NAD utilizar data de início de vigência ou data de assinatura do contrato, considerando parâmetro:
  Opções -> Parâmetros -> Contrato -> Forma de Validação para abertura de Solicitações e Nads (opções: Considerar a Data de Assinatura do Contrato ou Considerar o Início de vigência do Contrato);

Movimento -> Contratos -> Contratos

• Inclusão do campo Lote na tag Vencedor_Com_ItensVencidos_RegistroPreco_Maringa utilizada apenas no Open Office;

Relatórios -> 2. Movimentação -> 2.1 Solicitações -> 2.1.3 Relação de Itens Solicitado

• Inclusão da demonstração de dados da Licitação caso utilizado filtro de Itens com Licitação;

Propostas.exe

• Liberação do preenchimento de informações antes bloqueadas na aplicação Propostas.exe, sendo Razão Social e Inscrição Municipal. O único campo que será mantido o bloqueio é o CPF/CNPJ, em que uma vez preenchido e gravado no xml, não podendo ser alterado;

Exclusivo Estado do Mato Grosso

• Adequação em parâmetros de XMLs do Aplic, quanto ao cabeçalho dos arquivos em campos relacionados a valor unitário e total;

Movimento -> Processo Licitatório -> Licitação

• Inclusão de nova flag [ ] BID/BIRD para que se marcada, considerando os demais tipos de marcação no processo, gerem o código da modalidade de maneira referente a tal opção.
• Informação importante: O módulo de Compras na geração do tipo de modalidade dos processos licitatórios utiliza todas as informações possíveis do cadastro para indicar qual o código da modalidade de acordo com o Layout do Aplic, considerando campos para marcação, Tipo de Licitação, Forma de Apuração, Critério do Julgamento e Natureza. Dessa maneira não é prudente, legal nem lógico criar novas modalidades de processo licitatório para que fiquem iguais as descrições do Aplic, pois por exemplo, a Modalidade Pregão é uma só, em que para determinados códigos outras situações são utilizadas para geração do código da modalidade.