Base de comissão divergente em títulos baixados com multa

 Hoje o cliente alegou que o sistema estava calculando comissão incorreta em alguns títulos que haviam sido baixados com multa.

Ilustrando a situação
Valor da Nota menos o IPI (F2_VALBRUT - F2_VALIPI): 24.300,00
Valor do IPI: 1.215,00
Valor do Título (E1_VALOR): 25.515,00 (valor da nota + IPI)
Base original da comissão no financeiro (E1_BASE1): 24.300,00

Até aqui está tudo certo e entendido, o problema veio ao baixar o título.

Baixa do título
O valor total baixado (E5_VALOR) foi 25.820,55, que equivale à soma do valor do título (25.515,00) e a multa aplicada ao cliente, no valor de 305,55.

Comissão gerada após a baixa do título
Valor da comissão (E3_VALCOM) = 1.475,00
Percentual (E3_PORC) = 6,00
Base (E3_BASE) = 24.591,00  (???)

 A dúvida do cliente foi justamente sobre a base gerada após a baixa do título. Como o sistema chegou ao valor de 24.591,00? Na tentativa de desvendar este mistério, o usuário tentou somar a multa à base inicial de 24.300,00, tentou subtrair o IPI, tentou somar outros impostos que incidiram sobre esta nota, mas nenhuma das tentativas chegou ao valor calculado pelo sistema.

 Desvendando o mistério
  Acontece que o sistema calculou a proporção da multa sobre o valor do título e depois aplicou esta proporção à base original gerando a nova base em SE3.

Como assim?
 Multa: 305,55.
 Valor do título: 25.515,00
 Base original: 24.300,00

Encontrando o proporcional da multa sobre o valor do título: 305,55 / 25.515,00 = 0,0119753
Aplicando este proporcional à base original do título: 0,0119753 * 24.300,00 = 291,00
Encontrando a base misteriosa: 24.300,00 + 291 = 24.591,00  

Mistério esclarecido, resta explicar o porquê
 Esta situação ocorrerá sempre que a base da comissão gerada em SE1 for diferente do valor do título e, ao executar a baixa, houver incidência de decréscimos, acréscimos, descontos, multas ou juros.

 Espero ter conseguido explicar com clareza esta situação. Se você ficou com qualquer dúvida, por favor não deixe de postá-la aqui pra mim.

O Consultor

Atualização de custos / Workflow de validade de Lotes

Sistema: Totvs - Protheus 11
Segmento da Empresa: Indústria Química
Módulo: Contabilidade Gerencial / Estoque e Custos
Rotina: Contabilização OFFLINE

Problema 1 
Usuário relata que uma nota fiscal de entrada teve seu custo contabilizado corretamente, porém no KARDEX ela saiu com quantidade preenchida e custo igual a zero. Segundo o usuário, a TES estava configurada para atualizar estoque.

Solução
 Verifiquei que a TES utilizada estava realmente configurada para gerar estoque. Esta informação seria suficiente para que o sistema levasse o custo para o Kardex. No entanto, ao checar o campo D1_CUSTO, pude confirmar que estava zerado.

 Executei a rotina Refaz Custo de Entrada apenas para a nota em questão. Após executar a rotina, o campo D1_CUSTO recebeu o valor da nota.

Conclusão que cheguei foi que no momento em que o usuário digitou a nota, ele alterou antes a TES para que não atualizasse estoque, e com isso o sistema manteve zerado o campo D1_CUSTO. Após lançar a nota, o usuário alterou novamente a TES para atualizar estoque. Quando eu rodei a rotina de refaz custo de entrada, o sistema considerou a configuração atual da TES (estoque=sim) e atualizou corretamente o custo da nota.

Problema 2
 Cliente solicita uma maneira de visualizar os Lotes de fabricação que estarão vencendo nos próximos 60 dias.

Solução
 Desenvolvido um programa em ADVPL que gera um email no formato HTML para os destinatários contidos num parâmetro também customizado. Os dados são capturados através de uma querie SQL.
 Estes dados foram validados pelo usuário final antes do início do desenvolvimento do workflow, afim de garantir o sucesso do projeto e evitar a perda de tempo no desenvolvimento de um programa que talvez viesse a se tornar obsoleto.

 Dica: É muito importante no nosso trabalho confirmar de maneiras diferentes que o usuário/cliente está realmente pedindo aquilo que ele pensa estar pedindo.

 Depois de validado pelo usuário, o programa foi configurado no schedule do Protheus em produção.

Implantação do SIGALOJA

Um dia de implantação do SIGALOJA é sempre sinônimo de um dia cansativo, mas apesar disso, este foi vitorioso.

 Basicamente tive que solucionar uma séries de pequenos problemas no módulo, testar, treinar o usuário e deixar o ambiente pronto para validação.
 Sim, tudo em um dia.

Lista de problemas/tarefas e as respectivas soluções

Problema 1: Ao digitar o orçamento, não vir preenchido o cliente padrão e nem o vendedor padrão.
Solução: Configurar parâmetros: MV_VENDPAD, MV_CLIPAD e MV_LOJAPAD

Problema 2: Erro ao incluir produto, TABELA DE PREÇO INVÁLIDA.
Solução: Configurar MV_TABPAD como 1 ao invés de 001.

Problema 3: Cliente solicita aumentar casas decimais do preço unitário para que imprima com 4 no cupom fiscal.
Solução: Aproveitei que iria mexer nisso e aumentei o tamanho dos campos de quantidades e valores, pois notei que todos estavam com tamanho de 11 ou menos. Para isso precisei corrigir com atenção não deixando nenhum campo de fora nas tabelas SL1, SL2, SLQ, SLR e SL4.

 Para que o cupom respeitasse a quantidade de casas decimais do preço unitário do orçamento, foi necessário configurar os parâmetros conforme a lista abaixo:
MV_RNDDES com .F.
MV_LJTPDES com 2
MV_LJAJDES com .T.
MV_ARREFAT com N

 Problema 4: Cliente reclama que terá que digitar novamente no SIGALOJA todos os preços já cadastrados nas tabelas de preço do faturamento. Isso é assim porque a estrutura de tabela de preços do faturamento é uma e a do LOJA é outra.
Solução: A fim de facilitar ao máximo a vida do usuário, desenvolvi uma customização simples onde o usuário digita nos parâmetros de 1 à 10 quais tabelas de preço do Faturamento ele quer trazer para o Loja. Ao confirmar, o programa lê as tabelas DA0 e DA1 e faz a gravação nos campos correspondentes em SB0.
Cliente ficou bem satisfeito com a solução.

Problema 5: Cliente alega que possui uma regra de preenchimento de TES que funciona no faturamento e gostaria de personalizar o loja para funcionasse igual. Ele precisa que ao digitar um orçamento de vendas, o sistema preencha a TES correta de acordo com o produto.
Solução: Criar o gatilho. No entanto o problema é que criar gatilho no SIGALOJA não é tão simples. O campo LR_PRODUTO está em um acols e o LR_TES em outro, por isso não basta referenciar o campo de memória na criação do gatilho, simplesmente não funciona assim. Porém como quase nada é impossível no Protheus, eu resolvi da seguinte maneira:
CAMPO: LR_PRODUTO
CONTRA DOMÍNIO: LR_TES (Isso é inútil porque o gatilho do loja não respeita isso)
REGRA: aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]:=SB1->B1_XTES (aqui está o pulo do gato)

Explicando a REGRA: A expressão ”aColsDet[n,aScan(aHeaderDet,{|x|alltrim(x[02])=="LR_TES"})]” é o mesmo que seria escrever M->LR_TES em outros módulos. Porém no SIGALOJA o modo convencional não funciona.

 Eu precisei passar para ao gatilho a posição exata do campo LR_TES no acols, que no caso é o acolsDet. A variável “n” me diz em que linha estou posicionado no acols. Para concluir, eu atribuí a isso o conteúdo do campo customizado B1_XTES.
Validei com o usuário e funcionou perfeitamente.

Treinamentos passados ao usuário
- Treinado na digitação do orçamento no Retaguarda;
- Treinado na importação do orçamento no PDV;
- Treinado na geração e cancelamento do cupom fiscal no PDV;
- Treinado na geração da Nota sobre Cupom;

 Dica: Nos meus treinamentos de implantação eu procuro sempre utilizar um software de gravação de tela para que o próprio usuário possa consultar posteriormente. Utilizar o AutoScreenRecorder que é free e recomendado pelos consultores Totvs.

 Ao final do dia, o sistema ficou pronto para ser validado pelo usuário e, se não surgirem mais problemas, semana que vem estaremos virando o SIGALOJA em produção.