Data de postagem: Sep 20, 2012 12:18:46 PM
Foi criado o Limite de Aprovação de Pedido que poderá ser determinado limites de aprovação das operações. Por exemplo, cadastrado que o usuário X possui um limite de aprovação de R$ 1000,00 mensalmente. Caso o primeiro pedido do mês do usuário possua um valor de R$ 2000,00, este não poderá aprovar o pedido. Caso o pedido seja no valor de R$ 200,00, o usuário realizará a aprovação deste normalmente. Caso seja realizada configuração de limite de aprovação de pedido e seja utilizada a interface do caixa, não será possível realizar pedidos no caixa. Maiores detalhes no manual em http://www.unum.com.br/o-que-fazemos/modulos/compra/manuais/guia-de-estudo-do-modulo-de-compras/limite-de-aprovacao-de-pedido?pli=1 (por Cinthia Aguiar Arruda, #4024087)
[-1897035723,LimiteDeAprovacaoDePedido.ijs]
[-1897148283,/Dados/Cadastrais/Recursos/0100 INTEQerp infrastructure.ic]
[-1897035729,0100 INTEQerp infrastructure.ic]
[-1897131437,/Dados/Sistema/Classes/0300 INTEQerp infrastructure.ic]
[-1897035717,Limite de Aprovacao do Pedido.it]
[-1894443592,OrderError.ijs]
[-1897052500,0100 INTEQerp infrastructure.ic]
[-1897035721,Migrar Limite de Aprovacao Mensal das classes de Recurso para o Cadastro de Limite de Aprovacao do Pedido.imt]
[-1898188604,/products/INTEQerp infrastructure/library/pedido/objects/OperacaoPedido.ijs]
[-1897035624,Migrar Limite de Aprovação Mensal das classes de Pedidos ou Provisões para o Cadastro de Limite de Aprovação do Pedido.i]
[-1897035717,/products/INTEQerp infrastructure/tests/Operacoes/Operacao Pedido/Limite de Aprovacao do Pedido.it]
[-1897035718,INTEQerp infrastructure - Migrar Limite de Aprovação Mensal das classes de Recurso para o Cadastro de Limite de Aprovaç]
[-1897050457,/Dados/Sistema/Permissoes/0200 INTEQerp infrastructure.ic]
[-1897035623,INTEQerp infrastructure - Migrar Limite de Aprovação Mensal das classes de Pedidos ou Provisões para o Cadastro de Limit]
[-1898188604,OperacaoPedido.ijs]
[-1897035722,Migrar limite de aprovacao mensal do processo de Permissao para o Cadastro de Limite de Aprovacao de Pedido.imt]
[-1897035720,INTEQerp infrastructure - Migrar limite de aprovação mensal do processo de Permissão para o Cadastro de Limite de Aprov]
[-1897035725,0100 INTEQerp infrastructure.ic]
[-1897035727,CadastroLimiteDeAprovacaoDePedido.ijs]
Foi criado novo campo na rotina pós-upgrade de Compatibilização de baixas de pedido e devolução o campo classe de operação. Este campo tem como objetivo possibilitar que o usuário realize a compatibilização das operações de uma determinada classe de operação. O processo pode ser acessado pelo caminho: UNUM/Venda/Ferramentas Administrativas/Manutenções/Manutenções. Maiores detalhes no manual emhttp://www.unum.com.br/o-que-fazemos/modulos/venda/manuais-tecnicos/rotinas-pos-upgrade-de-compatibilizacao?pli=1 (por Cinthia Aguiar Arruda, #10381830)
[-1897035844,Scheduler Compatibilizar baixas de pedidos e de devoluções.ijs]
[-1897035867,Compatibilizar baixas de pedidos e de devoluções.imt]
Foi criado teste unitário Limite de Aprovação de Pedido com a finalidade testar a pesquisa combinatória para a nova classe Limite de Aprovação de Pedido por Classe, com a criação da nova classe agora é possível saber se existe pelo menos uma regra cadastrada por classe de operação. (por Roberto Klayton Magalhães Barros, #10276515)
[-1897035532,Limite de Aprovação de Pedido por Classe.it]
[-1897035725,0100 INTEQerp infrastructure.ic]
[-1897035532,Limite de Aprovação de Pedido.it]
[-1897035534,0100 INTEQerp infrastructure.ic]
[-1897035534,0100 UNUMerp infrastructure.ic]
Foi alterado o método pegaPrecoUnitarioPedido do objeto PrecoFacade com a finalidade disparar o evento noPegaPrecoUnitario passando os parâmetros pedido, pedidoCab, data e hora nesta ordem. Maiores detalhes em http://l.unum.com.br/jsdoc/symbols/PrecoFacade.html. (por Hugo Freitas Carneiro, #10424131)
[-1897035679,PrecoFacade.ijs]
Ao realizar um baixa de um pedido e aumentar a quantidade para um valor que está dentro da tolerância de divergência cadastrada, o sistema estava criando uma divergência. (por Cinthia Aguiar Arruda, #10353478)
[-1898188604,OperacaoPedido.ijs]
Ao tentar realizar a baixa de dois pedidos de devolução ocorria que o sistema não conseguir montar a negociação da baixa. (por Sâmia Rocha Lima, #10375044)
[-1894442893,NegociacaoModel.ijs]
Ao cadastrar uma pessoa com o mesmo CNPJ/ CPF, o sistema não realizava a validação de duplicidade. (por Cinthia Aguiar Arruda, #10363781)
[-1897036537,Explorer com Filtro.ip]
Ao alterar cadastro com classe filha de Estabelecimento com mesmo Cpf/Cnpj de cadastro com classe filha de Local de Escrituração ocorria validação de Cpf/Cnpj duplicado. (por Hugo Freitas Carneiro, #10394098)
[-1897148400,0100 INTEQerp infrastructure.ic]
Ao desaprovar um pedido que teve a comissão gerada, o sistema não estava excluindo os eventos de comissão. (por Cinthia Aguiar Arruda, #10352960)
[-1897035513,VerificaEventoDeComissao.it]
[-1894333888,ComissaoVerificaSeEfetivaComissao.it]
[-1894333862,Comissao.ijs]
[-1898188604,OperacaoPedido.ijs]
[-1897036086,OperacaoEscalaComissaoMetaFacade.ijs]
[-1894333776,Comissao.it]
Ao realizar a baixa de pedido, no qual teve uma parcela paga no pedido e outra não, os dados do documento da parcela informados na baixa do pedido, não eram gravados. (por Cinthia Aguiar Arruda, #10383168)
[-1894442896,NegociacaoBaixaDoPedido.ijs]
[-1898188310,OperacaoPedidoBaixaPedido.ijs]
[-1894442892,NegociacaoBaixaModel.ijs]
Ao realizar um operação onde o total possui mais de 2 casas decimais ocorria validação indevida Não é possível negociar um valor com mais de duas casas decimais. (por Flávio Antônio de Freitas Mendes, #10388738)
[-1898188604,OperacaoPedido.ijs]
Ao emitir NFe de acompanhamento a partir de uma baixa de pedido com item cancelado ocorria que o campo CFOP não estava sendo recalculado corretamente. (por Hugo Freitas Carneiro, #10346924)
[-1894443045,NotaFiscalVinculada.ijs]
A regra do campo DATALANCAMENTOEXTEMPORANEO foi reformulada para contemplar os seguintes pontos antes não coerentes:
-A validação subia mesmo que o usuário não estivesse alterando a data, impactando a emissão da NF.
-Não estava sendo validado a operação quando o usuário que não tem permissão apagava ou editava o campo.
-O campo era validado somente na baixa e não no pedido.
Os pontos foram corrigidos, resultando no perfeito funcionamento da regra do campo, onde somente os usuários com permissão podem editar o campo, que é validado tanto no pedido como na baixa.
Caminho: UNUM/Compra/Venda/Pedidos/Pedidos de Entrada/Saída (por Samuel de Lima Magalhães, #10221098)
[-1898188604,OperacaoPedido.ijs]
[-1898188315,OperacaoPedidoDevolucao.ijs]
[-1898188424,OperacaoPedidoBaixaAutomatica.ijs]
[-1897035656,Lancamento extemporaneo.it]
No caso do desconto ter sido concedido após o primeiro item do dataset ter sido cancelado teremos a situação onde o item não vai ter o controle de informado e assim o cabeçalho não ficará com o controle de informado, o efeito disso no caso do desconto é abrir a operação que tinha desconto, não alterar nada e ao calcular o desconto será limpo. (por Flávio Antônio de Freitas Mendes, #10393987)
[-1898188604,OperacaoPedido.ijs]
Ao realizar a devolução de uma baixa de pedido ocorria que o representante não estava sendo copiado da baixa e sim da entidade do usuário logado, com isso foi necessário realizar ajustes no objeto de devolução assim como no objeto de baixa de pedido. (por Roberto Klayton Magalhães Barros, #10355457)
[-1898188315,OperacaoPedidoDevolucao.ijs]
[-1898188310,OperacaoPedidoBaixaPedido.ijs]
Identificado que o objeto ReciboServico de chave -1894442719, possui declarações de propriedades fora do escopo do prototype, possibilitando que propriedade ou variáveis de mesmo em outros objetos ou scripts fossem alterados. (por Flávio Antônio de Freitas Mendes, #10371690)
[-1894442719,ReciboServico.ijs]
Ao conceder um desconto na venda (cabeçalho) com cupom, o controle de campos informados não eram replicados para sua baixa, consequentemente, ao gerar nota de acompanhamento o desconto não era considerado. (por Flávio Antônio de Freitas Mendes, #10393283)
[-1898188310,OperacaoPedidoBaixaPedido.ijs]
Ao emitir uma nota fiscal de acompanhamento a partir de um cupom onde foi concedido desconto, tal desconto não estava sendo considerado na nota gerada. (por Flávio Antônio de Freitas Mendes, #10345460)
[-1894443045,NotaFiscalVinculada.ijs]
[-1898188310,OperacaoPedidoBaixaPedido.ijs]
[-1897052500,/Dados/Transacionais/Operacoes/Pedidos ou Provisoes/0100 UNUMerp infrastructure.ic]
Ao criar uma operação onde nenhuma regra de observação se aplica ocorria a criação de uma observação com vírgulas (de acordo com a quantidade de item na operação) e espaços entre elas. Foi realizado tratamento para acumular somente observações não vazias. (por Flávio Antônio de Freitas Mendes, #10371926)
[-1894443575,SugestaoPedido.ijs]
Ao realizar uma transferência entre empresas diferentes, o sistema exibia a seguinte mensagem: " Error: Não é permitida a transferência de produtos entre empresas diferentes. Solution: É necessário que o estabelecimento e a pessoa utilizada nesta operação pertençam a uma mesma empresa". Foi alterada a mensagem para: "Error: Não é permitida a transferência de produtos entre empresas diferentes. Solution: É necessário que o estabelecimento e a pessoa utilizada nesta operação pertençam a uma mesma empresa: Error: Não é permitida a transferência de produtos entre empresas diferentes. Solution: É necessário que o estabelecimento e a pessoa utilizada nesta operação pertençam a uma mesma empresa" (por Cinthia Aguiar Arruda, #10346734)
[-1898188604,OperacaoPedido.ijs]
Ao realizar a pesquisa de preço via objeto de gestão de forma custom ocorria erro de não conhecimento dos campos de cabeçalho da operação. (por Hugo Freitas Carneiro, #10424131)
[-1897035679,PrecoFacade.ijs]
Ao negociar o pedido, o sistema possibilitava informar um valor negociado com mais de duas casas decimais. (por Cinthia Aguiar Arruda, #10368973)
[-1894443012,ItemDaNegociacao.ijs]
Ao realizar uma baixa que gera pedido associado, onde a classe de operação da baixa permite negociação e a classe de operação do pedido associado não permite negociação, ocorria a seguinte não conformidade: "Soma das negociações ultrapassa valor total do Item selecionado". Isso porque o sistema tentava negociar automaticamente o pedido associado de acordo com a negociação existente na baixa que o originou. O sistema passa a se comportar da seguinte forma:
1-) Se a baixa original tiver negociação e o pedido associado não negociar: pedido associado deverá ser gerado sem negociação.
2-) Se a baixa original não tiver negociação e o pedido associado negociar: pedido associado deverá ser gerado com a negociação de acordo com o que está cadastrado na classe de operação. Porém, se a classe de operação indicar que deve negociar, mas não informar a sugestão de negociação a ser utilizada, o sistema subirá um erro dizendo que tem um valor pra ser negociado e não houve negociação. (por Sâmia Rocha Lima, #10335490)
[-1894443576,PedidoAssociado.ijs]
Ao realizar uma baixa de pedido que gerará um pedido associado, o sistema exibia a seguinte mensagem: "Ao clicarr, é apresentado a mensagem de erro: Error: compare is not a function" (por Cinthia Aguiar Arruda, #10366500)
[-1894443576,PedidoAssociado.ijs]
Ao executar a rotina pós-upgrade de compatibilização de baixas de pedidos, o sistema exibia a seguinte mensagem: " Error: Erro: JavaScript Throw Exception Detalhes: As operações abaixo não foram compatibilizadas: Chave de criação: XXXXXXX - Motivo: Soma das negociações ultrapassa valor total do Item selecionado. Total Negociado: 811030.2 Total do Item: 811030.2" (por Cinthia Aguiar Arruda, #10366218)
[-1894443012,ItemDaNegociacao.ijs]
Ao incluir um fator de preço estava sendo validado o uso do registros em operações de forma indevida, pois a validação só deveria ocorrer na edição do registro. (por Sheila Gabriela Borges Rodrigues, #10342481)
[-1897048653,0100 UNUMerp infrastructure.ic]