Título(*): Geração das tabelas CAPAUT/ITEMAUT

Causas(*):

1. Como essas são tabelas geradas em tempo de execução, ao clicar na tela “Gerar Autorização de Compras”, às vezes acontece de elas não serem geradas, mais frequentemente acontece com a ITEMAUT que são os itens.

Consequências(*):

1. Ao não gerar uma dessas tabelas, o sistema não consegue identificar determinados itens no pedido de compras, causando diversos problemas e isso geralmente é descoberto quando já estão gerados os pedidos, muitas vezes os pedidos já foram inclusive empenhados.

Sugestões de solução:

1. A primeira coisa a se tentar geralmente, seria rodar um delete na tabela HOMOLOGACAO_ITEM passando o NR_COTACAO como parâmetro, essa tabela existe para homologação parcial de itens que funciona da seguinte forma, se houve homologação parcial ao salvar essa homologação o sistema gera essa tabela para o item específico e para os demais itens ao homologar o processo todo o sistema gera essa tabela para todos eles e pode ser que não gere para todos, como na função de gerar os itens na ITEMAUT tem um INNER JOIN com essa tabela os itens que não estiverem presentes na HOMOLOGACAO_ITEM consequentemente não vão para a tabela final de itens gerados. Ao rodar o delete da forma descrita no início e carregar novamente a tela, geralmente o problema é resolvido pois a HOMOLOGACAO_ITEM fica completa e todos os itens são enviados para a ITEMAUT.
2. Caso a primeira solução não tenha efeito, outra solução seria verificar todos os NR_SEQ dos itens do processo de compras nas tabelas PRECOS e ITENSCOT, comparando com um campo chamado NR_SEQ_COTACAO na tabela de itens da requisição ARQ901, muito provavelente os itens não gerados na ITEMAUT estarão divergentes, nesse caso acertamos esse campo e carregamos novamente a tela do “Gera Autorização de Compras” para que todos os itens sejam inseridos novamente.

Falar com:

Título(*): Pagamento de produtos/serviços com múltiplas fontes de recursos

Causas(*):

1. Como o sistema não permite configurar, durante o cadastro de nova requisição, um produto/serviço para ser pago por várias fontes de recursos distintas, o usuário é obrigado a criar 2 requisições de compra e, em cada uma delas, informar qual a fonte de recurso será utilizada para realizar o pagamento.

Consequências(*):

1. Ao finalizar todo o processo de aquisição do bem/serviço e, durante ao fechamento da EMS, como foi realizado 2 requisições de compra informando o mesmo item, o sistema entende que está “entrando” 2 unidades do bem adquirido.

Sugestões de solução:

Falar com:

Título(*): Informar campo: “Local de Estoque” para Processo de Compras de Serviços

Causas(*):

1. Sempre que é realizado a geração de um Pedido (Gera Autorização de Compras/Empenho) é obrigatório informar o campo: Local de Estoque.

Consequências(*):

1. Processos de compras de Serviços não precisam ser encaminhados para um Local de Estocagem, porém essa prática e utilizada para “contabilizar” os serviços licitados.
2. Pode ocorrer do Serviço estar marcado com a opção: “Produto p/ Estoque” é no momento de Gerar o Pedido e/ou  Gerar a E.M.S o Sistema realizar “E.M.S – ENTRADA” de Serviços no Almoxarifado.

Sugestões de solução:

1. (Paliativa) A configuração correta para Serviços é o mesmo esta com a opção: “Produto p/Estoque” desmarcada no Cadastro de Produto e no Cadastro de Local (Almoxarifado)
2. (Definitiva) Na modelagem do novo sistema de Compras, não sera exigido informar o campo “Local” para gerar pedidos de processos igual a Serviços.

Falar com:

Título(*): Validação de Limite de Dispensa de Licitação

Causas(*):

1. Sempre que é realizado a geração de um Pedido (Gera Autorização de Compras/Empenho) o sistema deve validar o limite de licitação de acordo com a modalidade selecionada.

Consequências(*):

1. As consequências da não observância dos limites legais para dispensa de licitação podem variar e vão desde multas e até improbidade administrativa, daí a importância da correta parametrização, orientação do cliente sobre este controle e mais importante é que o sistema esteja fazendo da maneira correta.
2. Diversas notificações já foram feitas à Prodata para sanar o problema.
3. Atribuição de responsabilidade e pagamento de multas pela Prodata.

Sugestões de solução:

1. Travar o cadastro de modalidade pelo Tipo, não permitindo criar mais de uma modalidade com o mesmo Tipo para todas as modalidades;
2. Travar o cadastro de Sub Grupo de Produtos pela NATUREZA e SUB NATUREZA, não permitindo criar mais de um Sub Grupo de Produtos com as mesmas NATUREZA e SUB NATUREZA para todos os Sub Grupo de Produtos;
3. Como as bases dos clientes são antigas, já existem estes registros duplicados que por sua vez devem ser inativados.
4. Todas as consistências devem ser verificadas e alteradas caso necessário, vez ou outras temos reclamações de clientes quanto a esta:
   1. para buscar o TIPO da modalidade DISPENSA e não o código da modalidade;
   2. para buscar a NATUREZA e SUB NATUREZA e não o código do Sub Grupo de Produtos;
   3. estender a validação também para o módulo Orçamento no momento do empenho, pois, nem todas as aquisições passam pelo módulo Compras, o usuário sempre irá tentar fazer o que ele precisa;
   4. desconsiderar os valores referentes a empenhos que foram anulados;
   5. desconsiderar os valores referentes a pedidos que foram anulados;

Falar com: