Bom dia Pessoal,

Gostaria de saber se alguém já implementou a solução AFS com GRC Inbound 10.0 para o cenário de compras normais.

Obrigada,

Carina

Caros Colegas,

É minha primeira implantação de CT-e, e aqui no Projeto necessito apenas da entrada de fatura de Conhecimentos de Transporte Eletrônico Modelo 57, porém, pelo que entendi na Documentação das Notas do SAP para esse Processo, Muda-se o tipo de Pedido de Compras que pasaa a ser um Processo de Compra de Serviços, o qual é normal até o ponto de Entrada de Folha de Serviço, no entanto, algumas coisas não ficaram claras e não funcionaram no meu processo, as quais são:

• Na documentação da SAP não fica claro como ativar a Condition CONH, e quais são os parâmetros da mesma, ela entra na TAXBRA ou no Esquema de Preços que estou utilizando?, já que o mesmo considera a Condition PB00 ou PBXX;

     - Segundo ponto, criei as Conditions que ele orienta, no entanto no Modelo 57 não aparecem todas no Documento Fiscal criado e nem na Simulação na MIRO, ao passo que se eu usar um NF Type com o Modelo 55, as mesmas aparecem sem problemas.

Alguém que já implementou isso conesgue me ajudar com essas questões por favor, já que a documentação que a SAP prove na  sua documentação além de ser fraca e controversa, ainda vem com trechos em Alemão, o que é impossivel para a minha compreensão.

Um abraço e obrigado a todos.

Olá Pessoal,

A SAP lançou hoje a SAP Note 2145930 - LC Announcement Note SPED ECD: Ato Declaratório Executivo COFIS 17/2015. Essa nota de anúncio tem as informações sobre os campos/registros a serem alterados e a previsão de entrega da solução, que é 30.04.2015.

Qualquer alteração na data ou na solução será atualizada na própria nota. Assim que tivermos mais novidades sobre a solução do ponto de vista técnico ( campos de seleção, BAdI's ou alterações no mapeamento ) irei atualizar com um blog post.

att,

Renan Correa

Pessoal estou com uma dificuldade aqui no cliente pra conseguir aprovar uma NFe de Devolução de entrou com IPI creditável.

Sei que na devolução o SAP envia a base de IPI para "outras bases" e existe nota SAP falando disso, inclusive ela trata também do texto automático para NF em casos de devolução.

Acontece que quando a base está em "outras" a NFe não integra pois os campos de Alíquota e Valor são preenchidos no mapeamento do XML, mas a Base não.

Procurei várias notas SAP, mas na maioria já estão aplicadas. Alguém sabe se isso pode ser nota ou algo que temos que fazer diferente?

Lembrando que a nota sai com IPI e se trocarmos o CST para não tributado tb não funciona.

Att,

Rodrigo

Bom Dia !

Quando faço o assign da XML x Delivery, ao fazer o Simulate Purchase Order Items, os valores NÃO fecham, dá uma diferença no valor total muito grande, fora da margem de 5% pra mais ou pra menos.

Se a funcional faz a MIRO pelo processo manual utilizando a delivery, os valores fecham corretamente, o problema é só na simulação via monitor GRC ( não temos Z* no processo ).

Eu coloquei um break-point na função /XNFE/CALL_NFE_SIMULATION no GRC , um break na RFC que chama o ECC  J_1BNFE_INVOICE_CREATE_2 e estou degugando, mas ainda não consegui encontrar a regra que diferencia o Pedido da Delivery para entender porque com o pedido está ok e com a delivery não.

O erro que retorna no monitor é: Saldo não é igual a zero: 7.571,37- Débito: 67.119,33 Crédito: 59.547,96  

Alguém já passou por isso ou tem alguma idéia do que pode estar acontecendo ?

Agradeço desde já !!

Eduardo Abrell

Pessoal, boa tarde

Ao gerar o arquivo de um determinado mês, como exemplo janeiro/2014, marcando a opção abaixo, o arquivo não deveria gerar sem o registro I350?

Grato,

Leandro

Boa tarde colegas, Estou com um problema aqui:na compra de Ativo onde os créditos de ICMS/PIS/COFINS são devidos, porém no livro fiscal o ICMS deveria estar em "outras bases" Não existe crédito de IPI na aquisição de ativo imobilizado entao deveria somar ao valor do bem, e no livro fiscal destacar em "outras bases". Alguém já passou por situação semelhante ? Obrigado! André.

Oi Pessoal,

Conforme já havia antecipado no SIT SL 2015, além da sessão de NF-e marcada para hoje, estamos disponibilizando um guia para analisar incidentes relacionados com a nota fiscal eletrônica tanto no ERP como no SAP NF-e ( vulgo GRC).

De acordo com a votação realizada aqui no SCN os primeiros cenários a serem explorados estão abaixo. Por enquanto apenas o primeiro cenário foi disponibilizado, o "Cancelamento por evento não finalizado no ERP".

Cenários:

•Cancelamento por evento não finalizado no ERP

•Tag não mapeada corretamente para o XML

•NF-e está com status incorreto no ERP e atualização do SAP NF-e não é finalizada ( Em breve )

•NF-e/evento/lote esperando por resposta no SAP NF-e ( Em breve )

•Status incorreto e continuar processo desabilitado ( Em breve )

•NF-e está em status que não permite nenhuma ação no ERP nem no GRC ( Em breve ) 

A idéia é que até o fim do mês de Abril tenhamos todos esses cenários acima explicados com detalhes aqui no SCN.

Caso vocês tenham mais idéias e/ou sugestões de cenários sintam-se livres para adicionar/modificar este material ( tanto o tópico como o conteúdo ) pois este é um  documento que permite colaboração de toda a comunidade.

Mesmo nos cenários já descritos se vocês tiverem mais sugestões/métodos de analisar ou resolver os problemas sintam-se a vontade para editá-los.

Cancelamento por evento não finalizado no ERP

Como começar a análise?

Eu sempre sugiro começar da própria transação J1BNFE, monitor de NFe no ERP.

O que analisar?

Recomendo começar pelos campos "Etapa do Processo", "status do documento", status de comunicação do sistema e status do sistema de mensageria. Além disso, é necessário clicar no na flag de eventos para poder visualizar o status do evento.

Os status necessários para cada etapa de qualquer processo (autorização, cancelamento, inutilização) podem ser vistos no help do ERP:

Statuses in NF-e/CT-e Monitor

Para entender um pouco mais do processo do cancelamento basta seguir a descrição abaixo. Uma recomendação adicional é sempre procurar por SAP Notes utilizando os objetos relacionados com o processo ( funções, tabelas, estruturas ) e/ou utilizando ferramentas automatizadas da SAP como o ANST  (Automated Note Search Tool ).

1- NF-e com inconsistência entre J_1BNFE_EVENT and J_1BNFE_ACTIVE:

No caso abaixo, por exemplo, há uma inconsistência  no documento, pois o status do evento é "autorizado" e o status da NF-e é "esperando resposta da mensageria".

A causa mais comum desse erro é a falta da SAP Note 2029305.

A solução desse problema seria manual, executar a função J_1B_NFE_XML_IN simulando a autorização do cancelamento (DOCNUM, AUTHCODE = Protocolo da SEFAZ, AUTHDATE = Data de autorização na SEFAZ, AUTHTIME = Hora da autorização na SEFAZ, CODE = 101 para cancelamento e MSGTYP = 4 autorização para cancelamento )

2- NF-e (sem inconsistência) esperando resposta do GRC para cancelamento

Esse procedimento acima resolve o problema no caso da tabela de eventos do ERP estar fora de sincronia com a tabela J_1BNFE_ACTIVE.

Porém existem outros cenários de erro em que a tabela de eventos e a tabela active estão em sincronia ( ambas esperando resposta do SAP NF-e / GRC )

Neste caso a recomendação é verificar como estão os status dos documentos no SAP NF-e / GRC. Se o status do "Cancelamento" for OK ( 01 / Verde ) então bastaria executar a funcionalidade "Repetir etapa process" assim como na imagem abaixo:

Essa funcionalidade está disponível a partir do SP20

Se o status do "Cancelamento" fosse "135 - Autorizado" e o passo do "update para o ERP" estivesse com Erro ( 02 / Vermelho ) então bastaria executar a funcionalidade "Continuar processo" assim como na imagem abaixo:

No caso de você não possuir o SP20 e precisar trazer o update de volta pro ERP é possível executar a função /XNFE/PROCSTEP_EV_ERPUPDAT no SAP NF-e para reenviar o status de OK para o ERP.

Porém há casos em que esses procedimentos de disparar a atualização do SAP NF-e ( GRC ) para o ERP podem não funcionar por "n" motivos ( falta de SAP Notes, modificação de funções core, validações incorretas ou commit work dentro de BAdI, problema de conexão ou RFC entre os dois ambientes, etc... )

3- NF-e (sem inconsistência) esperando resposta do GRC para cancelamento porém update do GRC não funcionou

Se esse procedimentos acima não estiverem funcionando, então a última opção para analisar/resolver o problema seria executar a função J_1BNFE_EVENT_IN do lado do ERP para simular o processamento e depurar o programa para identificar a causa da atualização não ser realizada.

Os parâmetros abaixo são necessários para a execução manual da função. Uma dica interessante caso você não saiba como preenchê-los é botar um breakpoint no SAP NF-e ( GRC ) antes da chamada da J_1BNFE_EVENT_IN e executar a função /XNFE/PROCSTEP_EV_ERPUPDAT. Desta forma seria possível ver quais os parâmetros passados pelo SAP NF-e para o ERP.

Já do lado do ERP o começo do processamento da J_1BNFE_EVENT_IN tem o FORM process_nfe_for_cancel_event que verifica se o cancelamento foi autorizado, se todas as informações necessárias foram recebidas do SAP NF-e e após isso o programa irá chamar a função J_1B_NFE_XML_IN.

A função J_1B_NFE_XML_IN por sua vez tem algumas validações dos status da tabela active e também do método check_subsequent_documents da BAdI CL_NFE_PRINT e do período contábil.

Nesse ponto é possível adicionar regras de negócio para verificar/estornar outros documentos que normalmente não fazem parte do fluxo da NF-e.

Além disso vale ressaltar que o programa também faz a verificação se o período contábil associado com a empresa ( company code ) está aberto. A lógica do cancelamento da nota fiscal no ERP não permite o estorno se o período contábil está fechado. É necessário, antes de realizar o fechamento, fazer uma varredura dos status das notas fiscais a fim de identificar documentos que estão em processo de cancelamento porém não estão cancelado, a fim de evitar problemas futuros para o fiscal ( nota cancelada na SEFAZ porém não pode mais ser cancelada no ERP ).

4- NF-e já cancelada na J_1BNFE_ACTIVE porém parada na etapa "2 - Cancelar documento de origem"

Em muitos casos o ERP irá passar pelas validações acima, porém pode não finalizar o cancelamento com sucesso e parar com o status abaixo:

Nesse caso o processo de cancelamento/atualização da tabela J_1BNFE_ACTIVE foi realizado com sucesso, porém o documento de origem da NF ( fatura, documento de material, remessa, etc... ) não pode ser estornado por alguma razão.

Para verificar essa razão você pode clicar no log da J1BNFE ( bandeirinha vermelha ). Caso o erro não seja claro ( como por exemplo "No Batch input data for screen XXXX XXXX ) é possível também solicitar o estorno do documento de origem ( conforme imagem abaixo ) e depurar esse processo de cancelamento.

O código abaixo mostra uma parte da função J_1B_NFE_CANCEL, que identifica qual o tipo de documento de origem e realiza um "call transaction" para a respectiva transação de estorno conforme as imagens abaixo:

Uma dica para depurar o processo é alterar a variável lv_mode de P para A, desta forma a transação de cancelamento será executada na tela e caso exista algum erro ele será mostrado diretamente na tela.

,

Tag do XML não é mapeada corretamente

Como começar a análise?

É sugerido começar pela função J_1B_NF_MAP_TO_XML que é onde basicamente começa o mapeamento das informações para a estruturas que serão enviadas para a mensageria ( SAP NF-e ).

O que analisar?

Dentro da função J_1B_NF_MAP_TO_XML as informações das tabelas do ERP serão lidas e será feito um mapeamento preliminar onde serão populados os dados das estruturas xml* (xmlh de header e xmli de item).

A dica para verificar um problema é criar um breakpoint at statement "RFC”. Ao executar o programa com esse breakpoint isso irá levar até a função /XNFE/OUTNFE_CREATE.

Neste ponto é necessário verificar se as tabelas/estruturas GT_RFC* e GS_RFC* estão com a informação necessária ou não. No caso da informação estar correta nesse ponto então o problema é no mapeamento dos dados no SAP NF-e. No caso da informação não estar preenchida ou estar com uma informação incorreta então o problema é no mapeamento dos dados no SAP ERP.

Para o layout 3.10 especificamente o mapeamento final dos dados ocorre dentro do perform call_message_system_comm onde os dados das estruturas xml* serão mapeados para as GT_RFC* e GS_RFC* que serão realmente enviadas para a mensageria.

No final do perfom call_message_system_comm há a chamada do SAP NF-e, na função /XNFE/OUTNFE_CREATE.

A dica para identificar onde um campo é preenchido no ERP é utilizar a busca "in main program" utilizando no nome da tag do XML ( ou campo/estrutura do SAP ERP) e assim visualizar a linda do código onde a informação é preenchida.

Existem basicamente três jeitos de preencher uma informação nas estruturas do SAP ERP:

1 - A partir das tabelas j1bnf* e dados mestre.

2 - Cálculos em tempo de execucao a partir de tabelas

3 - Badi's

Nas imagens abaixo voces podem ver respectivamente os pontos do codigo onde sao chamados os métodos de header e item:

No final do processamento do programa ele irá realizar uma chamada para o GRC usando a função /xnfe/outnfe_create de acordo com a imagem abaixo:

No GRC o programa irá receber os dados do ERP e irá passar pela validação técnica na função /xnfe/outvalidation e se tudo estiver tecnicamente correto então o programa passará para a função /xnfe/outnfe_transform onde as estruturas da proxy serão preenchidas conforme imagens abaixo:

No form fill_proxy_structure o programa irá verificar o que foi enviado pelo ERP e mapear os campos relevantes de acordo com a hierarquia de informações do XML e isto será transformado para o formato XML pela proxy no passo seguinte:

Bom dia pessoal,

Estou com uma demanda aqui na empresa para configurar o CTe apenas para entrada.

Criei a categoria de nota usando o modelo 57.

É a primeira vez que trabalho com esse assunto e decidi começar tentando emitir um conhecimento via J1B1N.

Só que está me mostrando o erro : Funções de parceiro NF não atribuídas a parceiros CT-e no customizing

A partir dessa mensagem eu cheguei na customização que fica em :

SPRO->Componentes válidos para várias aplicações ->Funções Gerais de Aplicação-> Nota Fiscal ->Documentos Fiscais Eletrônicos->Dados específicos da CTe-> CTe de saída -> Atribuir parceiros CTe a funções de parceiro NF.

Bom...não estou entendendo essa relação e o que tenho que configurar aqui. De início eu configurei:

Parceiro CT-e: 1 Expedidor da carga

NF função parc: SP Transportadora

Agora a mensagem na J1B1N mudou a mensagem: Falta parceiro CT-e Recebedor da carga obrigatório correspondente

Alguém poderia dar uma orientação?

Obrigado.

Bom dia a todos,

Apos implantação do novo layout 3.10, estamos enfrentando uma diferença (arredondamento) dos valores de ICMS em algumas notas de transferência entre centros, saída de mercadoria gerando a rejeição 528 Valor do ICMS difere do produto BC e Alíquota.

Apos analise da thread abaixo, conforme informado pela analista Vera Lucia a SAP disponibilizou a nota "2066469", que foi aplicada no nosso ambiente, porem algumas notas ainda continuam com o problema.

Rejeição 528 Rejeição: Valor do ICMS difere do produto BC e Alíquota

Estamos utilizando TAXBRJ.

Em anexo tenho um exemplo do valor calculado no SAP, calculando no Excel o resultado do valor do ICMS da uma diferença de 0,03.

Alguém teve problema mesmo apos a aplicação da nota, e tem alguma sugestão?

Obrigado,

Alessandro Ávila

Olá pessoal,

Fizemos o update do SP19 no GRC e agora estamos com alguns problemas para realizar a manifestação do destinatário após listar as notas emitidas para meus CNPJ.

O que fizemos:

Atualizamos o SP de 18 para 19;

Configuramos os cenários: NFEDI_AEX_WebAS_Outbound_NFeDist e NFEDL_AEX_WebAS_Outbound_NFeDownloadRequest_SYNC

Aplicamos a nota: 2109999

Após rodar o job /XNFE/COLLECT_DOCUMENTS foram listadas todos os XML para os CNPJ do cliente no Monitor Fiscal.

Porém elas ficam com o seguinte status:

Na aba Eventos>Status evento temos a seguinte mensagem:

Na moni do GRC não encontro nenhuma mensagem esperando resposta ou com erro. Acredito que seja algum erro de configuração daquelas etapas do processo na SPRO, mas não consegui encontrar.

Além deste erro ainda tenho as seguintes dúvidas:

- Existe um novo monitor de eventos para manifesto do destinatário?

- Como realizo o download das notas neste Monitor Fiscal, pois segundo a nota da SAP o Monitor de Lista e Download não será mais utilizado.

Se eu falei alguma besteira por favor me corrijam......:)

Desde já agradeço a atenção.

OIá Amigos.

O programa J_1BECD_MAIN não faz a extração dos blocos J100 e J150.

Minha empresa deseja que isso seja extraído diretamente do programa e sei que existe o código no programa para estes blocos mas não são usados.

Por favor,

Vocês sabem se é possível fazer a extração deste blocos diretamente pelo programa?

Se alguma nota sobre isso foi lançada?

Muito Obrigado por qualquer ajuda.

Um abraço.

Bom dia!

Estou com uma dúvida, sobre devolução de IPI de indústria após a versão 3.10.

Na versão 2.0 da NFe, quando era necessário fazer uma devolução para fornecedor à partir de uma revenda, destacávamos o valor do IPI em "outras despesas acessórias" e o informávamos nos dados adicionais. Quando era necessário fazer uma devolução para fornecedor à partir da indústria, destacávamos o IPI nos campos apropriados ao IPI do XML. A partir da versão 3.10, com a criação do campo FINNFE, todas as devoluções foram travadas pela emissão de NFe em "outras despesas acessórias", portanto recebi uma solicitação do departamento fiscal para voltar as devoluções de indústria à forma que era antes.

Então minha dúvida é: Para indústria existe alguma nota que permite destacar o IPI de devolução (FINNFE = 4) nos campos de IPI? Ou algo mudou no RIPI de forma que esta forma implementada pela SAP é a única correta?

Obrigado!

Caros

Estou com problema na TCode VL02N para o processo de Transferência entre Centros, este erro ocorreu depois que informei a categoria da NF na J1BTAX e o erro ocorre somente no ambiente de qualidade, em sandbox o processo está correto.

No ambiente de qualidade retorna a mensagem abaixo:

Account determination for entry 1000 TXO not possible

Message No. M8147

Mas não tem conta associada a esta chave na OBYC no ambiente de Sandbox (que funciona)

Na OBYC (Sandbox)

OBYC (Ambiente com erro)

Simulei o lançamento na OMWB e encontrei uma diferença no Valuation Grouping Code e Valuation Class, esses campos estão preenchidos no ambiente que está com erro

Como não tenho vivência com a determinação de contas e com a OBYC não estou conseguindo resolver esta questão

Abaixo a OMWB do ambiente que funciona

OMWB ambiente com erro

Imagino que no ambiente de qualidade esteja obrigatório o preenchimento das contas para chave TXO, por isso o erro, mas com não entendo o conceito não consigo avaliar.

Agradeço antecipadamente a ajuda.

Boa noite,

Como faço para informar o valor do frete (destacado na nota fiscal de compra do material) no pedido de compra (aba condições) e este valor ser utilizado na base de calculo do ICMS e do IPI?

Informei nas condições FRB1 e FRB2 e não funcionou, não foram consideradas nas bases do icms e do ipi.

Tem alguma diferença entra a condição FRB1 e FRB2 ?

É preciso criar alguma condição no esquema de calculo M0000 ?

É preciso criar alguma formula?

Att:.

Bruno Viol

Pessoal,

Por favor, vocês poderiam confirmar se podemos usar o GRC NFe com PI de outros processos. Por exemplo, se o cliente já possuir o PI ele pode implementar o GRC NFe e conectar com este PI, ou deve ser um especifico para o GRC NFe? Ou se fazer uma nova implementação de GRC NFe + PI, podemos usar o PI para outras comunicações?

Muito obrigado!

Boa tarde!

   Foi criado 2 Nfes acima de 3 Megas

   Abri chamado na SAP e foi retornado como mostra abaixo.

" I was able to check the your PI and GRC system, indeed the issue

lays in the batch size, please create an entry in the customizing

view /XNFE/V_BATCHPAR, setting the parameter "Max batch size" for

500.000 and "Max. Number" to 1, the other parameters are up to your

company needs.

After adjusted the customizing, follow the bellow instructions:

- go to the batch monitor

- hit the finish batch process

- go to the NF-e monitor

- press the "continue process" "

Então altermos no PI/GRC cmo abaixo . Mas não está funcionando. Alguém sabe o que está errado?

Já fechamos o chamado na SAP e preciso um retorno hoje.

Grato.

Caros,

Temos uma situação muito peculiar que eu gostaria da opinião de vocês.

Estamos efetuando uma implementação em um cliente onde transferências entre plantas são feitas utilizando o pedido de transferências (STO).

Entretanto, a área fiscal nos colocou a seguinte situação:

"Após geração do pedido de transferência, remessa e SM, é detectado algum problema que impede a saída do transporte e a NF esteja incorreta. Caso excedam as 24 horas a SEFAZ já não permitirá o estorno da NF. Além disso, fazer a entrada no centro destino para depois devolver não está correto, uma vez que a NF estará errada e a mercadoria não transitou."

Desta forma, faz-se necessário um processo de retorno de transferência com os CFOPs 1.208/2.208 ou 1.209/2.209. Neste processo deve ser baixado o estoque em trânsito e realizada a entrada com NF Própria. Localizei então, a nota "1512390 - Stock Transfer: Full/Partial Return of Transit Stock (new)" que desenvolve exatamente esta funcionalidade.

Entretanto, após a migração para versão 3.10 da Nfe, a NF está sendo rejeitada indicando que o tipo de NF não corresponde a devolução/retorno. Realmente, estava como Nota Fiscal normal. Efetuei a configuração para tipo 6 (Restit.). No entanto, não há como preencher o docref dentro da NF para que ela referencie o XML da saída, o que faz com que ela também seja rejeitada.

Debuguei o programa que gera a NF a partir do doc. material para STO e não estou certo que o sistema tenha alguma configuração para ajustar esta situação.

Alguém já se deparou com este problema?

Obrigado

abs   

Gian

Olá a todos

Eu tenho uma pergunta relacionada a j1btax para a tributação com base condição. Quando criamos um PO , e usar um código de imposto em MM onde temos habilitado ICMS -ex indicador, no qual o sistema base determina quando base de tributação será na "excluídos " e quando em "Outros" .

Como eu sei, este é preenchido em condições MM BX11 e BX12 , respectivamente, em procedimento fiscal.

Por favor, responda se alguém sabe a base quando as mudanças de base.

obrigado

Debasmita

Boa tarde ! Estou analisando um problema onde a contabilização de Impostos na Miro está correta, bem como as colunas na aba Taxes, porém o Livro Fiscal nao está correto. No Livro fiscal esses impostos deveriam estra em Outras Bases. Alguém já teve esse problema ? Obrigado. André.