cancel
Showing results for 
Search instead for 
Did you mean: 

YAXBRA versus TAXBRA

Former Member
0 Kudos

Alguém saberia dizer quais os problemas encontrados se instalado o YAXBRA ao invés de TAXBRA, uma vez que para utilizar o esquema TAXBRA é necessário recriar algumas informações standards deletadas durante a instalação do Baseline v3.607, exemplo os IVAS da J1BTAX? É uma opção, recriar o dado standard e utilizar o TAXBRA, já que uma nota contra o YAXBRA é a 1975305, que afirma a possibilidade de o esquema ficar obsoleto? Alguém já passou por este problema? Obrigado pela atenção.

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Oi Eduardo !

Confesso que inicialmente achei um papo de doido! Mas realmente é verdade! A SAP criou a YAXBRA!

O mais legal é que isso não foi divulgado ou comentado nas reuniões da asug ou qualquer outro evento! E, o que assusta é a forma como está descrito na nota os motivos! kkkk

Enfim... o motivo de não utilizar é o que vc comentou! Ficar obsoleto! Se mudar alguma regra fiscal relevante vc vai ter que tratar por conta. E, no Brasil isso nem pode acontecer! rsrsrsrs

Pode ser o caminho mais fácil mas eu não recomendaria! A documentação que precisa está na nota... vai em frente.

Abraço

Eduardo Chagas

Answers (3)

Answers (3)

Former Member
0 Kudos

Meus dois centavos...

Entregar algo que não vai ser suportado é péssimo. Melhor criar um guia claro (EM PORTUGUES) indicando os impactos que podem ocorrer e de como proceder para fazer as configurações de forma manual.

Acho também que este tipo de alteração deveria ser melhor divulgado e não deixar os clientes e consultores descobrirem por conta! E, gerar essa dúvida agora... qual adotar?

Me parece que o caminho mais fácil é adotar a YAXBRA mas se não vai ter suporte do que adianta? O governo está planejando diversas mudanças pra um futuro próximo! Ou seja... melhor partir para os ajustes manuais.

Abraço

Eduardo Chagas

Former Member
0 Kudos

Olá Eduardo Chagas,

Ao que parece YAXBRA é novidade para todos. O papo é de maluco mesmo mas está evoluindo.

Abri um chamado na SAP e estes se posicionaram que a recomendação é recriar o TAXBRA seguindo os configurations guides 100, 102, 104, 105 após a instalação desta versão do base line. Estou em contato com eles e de fato somente existe esta solução imediata.

O recado que eu conclui neste caso é: se instalar esta versão do base line, atente em reconfigurar o TAXBRA no final para que tenha todas as atualizações e suportes futuros da SP.

Estou indo por este caminho, vou manter a TAXBRA, garantir que as informações dos configurations guides estejam lá e matar os IVA´s da YAXBRA recriando-os com a mesma nomenclatura na TAXBRA.

Os primeiros testes funcionaram bem, estimei em 32 horas a tarefa adicional de reconfiguração e até o momento o prazo foi cumprido.

Obrigado pela sua contribuição.

former_member209197
Active Participant
0 Kudos

Olá Eduardo.

Eu diria que sim essa é a melhor opção para a grande maioria dos casos.

Usar pricings próprias também pode dificultar o suporte, já que umas das primeiras suspeitas de resultados estranhos é imaginar que o problema está no fato do uso de uma pricing Z.

Então, essa sugestão não vai se aplicar a todos casos.

Esse ano já trabalhei em 2 casos de performance com mais de 900 chamadas de cálculo, nas 2 uma das medidas é não usar mais a TAXBRA.

Mas esses são casos específicos, com certeza a primeira decisão, a decisão padrão, deve ir na direção de utilizar a TAXBRA.

Abraço

André

former_member209197
Active Participant
0 Kudos

Olá Eduardo.

Sempre vão haver prós e contras.

A TAXBRA recebe atualizações via SP. Porém isso pode ser um pró ou contra, dependendo do seu cenário.

Quando novas condições são criadas, mesmo que não relevantes para o seu cenário, elas são processadas na pricing.

Isso pode afetar a performance das transações.

Então, se você trabalha com pedidos de 900 itens, ou de igual problema, pedidos com 10 itens mas com Split contábil em 90 centro de custos, a pricing será chamada 900 vezes em praticamente qualquer iteração com a tela.

Nesse cenário receber, por exemplo, todas as condições de CT-e e não usar pode se tornar crítico já que a performance será afetada.

Agora, talvez você tenha interesse nas condições de CT-e, nesse caso você deixa de executar vários passos manuais, desde que a empresa esteja aberta à aplicar um SP.

Todas essas alterações de pricing são entregues em Notas, os mesmos passos podem ser executados na pricing oficial ou em um Z/Y.

Te confesso que hoje, com o tamanho que se encontra a pricing atual, pode se tomar a direção de se entregar mais configuração por passos manuais do que na pricing em si (pelo motivo da performance que mencionei).

Então, não existe um melhor ou pior, vai depender do cenário e variáveis de cada empresa.

Abs

André

Former Member
0 Kudos

Olá André Muller,

Concordo com todos os pontos abordados por ti, mas o que me deixou mais resistente na utilização do YAXBRA foi, além dos pontos colocados, o fato de ser uma novidade desconhecida, ou seja, temos pouco ou nenhuma documentação de cases de sucesso, perguntei para meio mundo de consultores (um dos motivos de abrir um scn foi este), quem conhecia ou tenha implantado com sucesso o YAXBRA e simplesmente ninguém havia escutado falar do assunto.

Os raros casos que escutei não tiveram a implantação concluída. Resumindo, um grande motivo de não implantação foi devido a inexperiência do mercado neste tipo de implantação, um risco grande se levarmos em consideração ainda o que diz a própria SAP sobre suporte e o fato de ficar obsoleto.

Obrigado pela sua contribuição.