Programa:

estq_f015

Problema:

MOVIMENTO DE ESTOQUE - AO REALIZAR A CONSULTA DE SALDO DO ESTOQUE DO ITEM (EX: 9.03531.085.000329) NO DEPÓSITO 715 NAS TELA ESTQ_F305 MAS AO CONSULTAR AS MOVIMENTAÇÕES DE ESTOQUE TEM SALDO ATRAVÉS DO ESTQ_F305 E O Divergencias entre Estoques X Volumes X Cardex - ESTQ_F370 POSSUE SALDO.
PORQUE NÃO ESTA ATUALIZANDO A TABELA DE SALDO ESSES ITENS MESMO APÓS OUTRAS MOVIMENTAÇÕES APÓS A DATA DO CARDEX?

Solução:

Identificamos que o problema estava no programa estq_f015, onde o sistema estava cancelando uma movimentação de entrada no estoque sem considerar se o saldo final ficaria negativo ou não. Como solução para o problema, implantamos o controle de estoque negativo na trigger responsável pelo cancelamento de movimentações.

Programa:

cpag_f610

Problema:

Contabilização adiantamento - criamos o adiantamento de cliente empresa 6, porém esse adiantamento contabilizou na empresa 1 o número contábil é da empresa 1.
O lançamento contábil aparece na empresa 6. no conta corrente aparece na conta da empresa 6, mas quando eu tiro o razão ele aparece na empresa 1.

Solução:

Identificamos que o sistema estava fazendo a contabilização na empresa matriz da empresa logada, o que é incorreto, o sistema deve sempre considerar a matriz da empresa do adiantamento que está sendo transformado. Realizamos os devidos ajustes no processo para fazer a contabilização corretamente.

Programa:

tmrp_041

Problema:

Painel de Planejamento dos Produtos - na tela do Painel de Planejamento do Produtos ainda constam ‘Reservas' para as Ordens de Beneficiamento 18989 e 19045 sendo que os rolos de malha crua necessários para estas ordens já foram bipados nas mesmas. Esta informação é possível visualizar através das telas ‘Consulta Individual de Rolos’ e 'Consulta dos Rolos Preparados’. Solicitamos verificar e corrigir esta informação, pois está sinalizando necessidade de programação de forma incorreta.

Solução:

Analisamos esta situação na aplicação oficial do cliente e constatamos que o problema estava nos próprios rolos relacionados as duas OB's deixadas aqui na SS, ajustamos as informações na base para ficarem de acordo com o cenário real do cliente. Além disso, alteramos o programa pcpb_f662 para identificação do problema.

Programa:

estq_f520

Problema:

campo faltante estq_f520 - está faltando o campo da série da NF

Solução:

Após verificar o problema relatado na SS, verificamos que o campo de série da NF já existia, porém, estava atrás do campo do número da mesma. Então, corrigimos a posição do campo ( à direita do campo do número).

Programa:

e_basi_e030

Problema:

Cadastro de itens produtos confeccionado - Qualquer alteração na descrição (string 30) de um produto dá erro anexo. Aparentemente só nessa referencia. Os campos da linha 142 acusados na trigger, estão como os de outras referencias. Tentando alterar por sql dá erro na linha 149.

Solução:

Havia um campo na tabela e_basi_030 que estava com o tipo diferente da basi_030, ao fazer o update na tabela, o sistema deu o erro. Fizemos a alteração desse campo na base para o cliente poder utilizar e liberamos o SQL para distribuição via SUM para os outros clientes.

Programa:

INTER_TR_FATU_060_PARTILHA

Problema:

nota fiscal parada - novamente problemas de fundo de pobreza

Solução:

Na SS inicial fizemos apenas uma solução de contorno para o cliente, achamos que seria um problema pontual, porém como aconteceu novamente analisamos mais a fundo. Identificamos que o problema estava na trigger que fazia o calculo da partilha, lá o valor do FCP sempre saia zerado pois a base de icms ainda estava zerada no momento que insere o registro. Alteramos a trigger para usar a base do pis/cofins, dessa forma começou a jogar corretamente o valor de FCP.

Programa:

pedi_f140

Problema:

Itens do pedido de vendas - O sistema permite cancelar item completamente faturado. deve cancelar somente item com saldo. Item sem saldo não deve cancelar.

Solução:

O programa estava permitindo ir da pedi_f140 para pedi_f149 quando o item estava completamente faturado. Existia um erro na variável que era testada para não permitir ir para pedi_f149, fizemos a correção da variável e nos momentos que o item estiver 100% faturado, não será possível rodar o cancelamento via pedi_f149.

Programa:

inte_f375

Problema:

Importação Edi - mesmo problema já relatado e ainda não esta funcionando

Solução:

O processo havia sido alterado mas funcionava quando ia importar apenas um conhecimento, agora fizemos algumas alterações para rateio de valor que deixa o programa apto para criar um item para cada registro 354 do arquivo EDI. Lembrando que na supr_f035 da transportadora sempre deve estar com o campo: Agrupar notas no conhecimento desmarcado, do contrario vai agrupar os 354 em um item só.