Avalados por :
Olá,
Estou enfrentando a seguinte situação: Preciso liquidar custos para COPA e preciso ter o funcionário de vendas como receptor, mas não há um campo de seleção disponível em KEU1/2 (existe uma etiqueta de campo de funcionário de vendas, mas não há um código de correspondência disponível, está em cinza). Então, tentei o seguinte: criei uma característica personalizada WWANG, a incluí na área de COPA e criei uma regra de "MOVER" em KEDR, da característica padrão VRTNR para a nova, WWANG.
Agora, quando tento fazer a faturação, recebo a mensagem de erro: " O valor da característica 00100000 não existe para a característica WWANG ()".
Se eu criar o valor mencionado para a característica em KES1, funciona bem.
Minha pergunta é: Este comportamento é padrão em caso de uma regra de "mover"? Eu não esperaria ter que recriar o funcionário de vendas em KES1. Ou talvez eu tenha feito algo errado?
Agradeceria qualquer comentário. Existe alguma outra solução para poder liquidar custos para COPA na característica receptora de funcionário de vendas?
Cumprimentos cordiais!
Lavinia Zara
Olá Mukthar,
Obrigado por responder. Mantive os valores corretos em KES1 e está funcionando bem ao manter os valores. Minha pergunta era se havia alguma possibilidade de fazer isso sem manter o funcionário de vendas na COPA.
Lavinia
Olá Zara,
Se você criar uma característica personalizada com manutenção de valores próprios, então deve manter os valores em KES1. Acredito que você a criou com manutenção de valores próprios. Por isso, o sistema está solicitando que seja mantido em KES1.
Saudações,
Mukthar
Olá Robin!
Obrigado pela sua resposta. Li a nota 74399 e tenho uma pergunta, que na verdade também se relaciona com a sua resposta: você entende por 'Estrutura de Derivação' uma regra de derivação em KEDR?
Estou tentando evitar manter funcionários de vendas em COPA porque nosso cliente tem um fluxo dinâmico de funcionários de vendas e seria um desafio manter duplicatas dos funcionários de vendas.
O único problema com a solução que estava testando, muito semelhante ao que você sugeriu, era na verdade manter duplicatas dos funcionários de vendas. Você acha que é possível conseguir isso?
Lavinia
Olá Lavinia ,
As características para avaliação devem ter uma tabela de verificação.
Como campos como VRTNR têm um domínio PERNR sem uma tabela de verificação, não podem ser utilizados ao definir um ciclo. A nota 74399 descreve esse problema e oferece uma solução alternativa ao definir uma característica adicional para o funcionário de vendas que tenha uma tabela de verificação.
Esta é a sugestão de desenvolvimento para resolver esse problema. Por favor, teste os seguintes passos primeiro em seu sistema de desenvolvimento/testes:
1. Crie uma característica definida pelo usuário WWxxx em sua área de operação.
2. Mantenha os valores para essa característica (dados mestres de CO-PA - valores de características - alteração - tr. KEP6).
3. Derive o valor para essa característica usando 'Estrutura de Derivação' (provavelmente uma relação um para um será necessária - pode ser bastante custoso em termos de manutenção) ou (melhor) User-Exit (apenas preencha a característica WWxxx se NÃO estiver inicializada - para garantir que não seja redeterminada, por exemplo, durante a avaliação).
Esse passo é necessário para garantir a consistência dos dados, por exemplo, o novo campo deve ser preenchido durante a faturação para que possa ser utilizado em relatórios (para evitar que, às vezes, as informações se refiram à antiga característica de funcionário de vendas e, às vezes, à nova característica WWxxx).
Isso não significa que você precise derivar essa característica durante a avaliação do centro de custos.
Agora você pode utilizar a característica WWxxx durante a avaliação. Se precisar alterar segmentos de rentabilidade existentes para incluir a nova característica, pode utilizar a função de realinhamento.
Obrigado,
Robin
contacto@primeinstitute.com
(+51) 1641 9379
(+57) 1489 6964
© 2024 Copyright. Todos los derechos reservados.
Desarrollado por Prime Institute
