Olá,

Estou enfrentando problemas no recebimento de xmls no GRC que ao efetuar a consulta de status as funções standard validam se o lv_modus é igual aos processos de outbound O1, O2 ou OB, no caso que tenho o lv_modus é I1, sei que estes modus são devido ao GRC10, mas não se porque o payload do xml determina i1 e como deveria ser realziada a consulta.

No monitor do grc indica erro para o guid de mensagem do pi e o XML não integra na tabela /xnfe/innfehd

Acreditamos que o xml recebido não seja um xml completo e sim somente a autorização, pois ao baixar o xml direto do sefaz é possivel a integração do mesmo.

Bom dia,

Ao usarmos o processo de recebimento de CT-e via folha de serviço, ativamos as condições de ICMS sem credito e IPI sem calculo (IPI0) no IVA e marcamos o mesmo como serviço.

Ao gerar a Nota fiscal (57) na MIRO a condição IPI0 (previamente ativada no IVA) não é levada para a aba de impostos, e consequentemente a escrituração do CT-e contem apenas a linha ICMS em outras bases.

De acordo com a area fiscal, é requisito legal que a linha do IPI também vá para o livro na coluna outras bases com o total da NF.

Abri chamado na SAP, mas ainda nao recebi retorno.

Alguem usando este processo poderia me dar um help?

Obrigada

Greice

A partir de 01/05 não haverá mais pauta de pis e cofins para empresas que vendem latas. Desta forma o comercial está querendo saber se existe alguma forma de redeterminar o imposto para que as ordens antigas passam a operar com alíquota novamente sem ter que criar as ordens novamente. Pois ordens até 30/04 puxaram o iva de pauta e mtas destas ordens estariam em aberto após 01/05. Como vocês procederiam?

Olá pessoal,

Estou com um erro no processamento da entrada de mercadoria no fornecimento futuro (FUTDELGR) na execução da etapa de validação (FDELVALD) que retorna o erro "Exactly one reference NF-e must be assigned" sem nenhum detalhamento.

O processo de entrada da fatura (FUTDELIV) já foi realizado com sucesso, já revi as parametrizações necessárias mas até agora não consegui identificar a causa do problema, parece que a etapa não encontra a referência da fatura.

Alguém já passou por isso e poderia ajudar?

Obrigado,

Gustavo Maia

Bom dia,

Tenho um cenário de escrituração do XML de CTe versão 2.0 para fretes Outbound CT-e para saídas de NF-e com LES (CTEOUTLE), onde geramos um Pedido de Compra por dia para cada fornecedor de transportes e todos os custos de fretes gerados naquele dia são entrados neste pedido; Quando recebemos o CTe que está atribuído a este Pedido de Compra o sistema não consegue identificar qual é o custo de frete referente a este CTe devido existirem vários custos neste Pedido. No processo tenho que gerar um Pedido de Compra por dia para cada parceiro de transporte.

Mensagem GRC: Existem vários documentos de custos; automatização não é possível Nº da declaração J1B_NFE565

Nº mensagem /XNFE/APPB2BSTEPS011

Alguém sabe como atribuir corretamente o custo para funcionar a automação?

Outro ponto que tenho neste processo de Simular Fatura, é se consigo determinar automaticamente o Código Imposto e CFOP automaticamente?

Pessoal,

Estamos testando contingência SVC-AN para SP e as notas normais estão sendo aprovadas, porém quando é uma nota de importação está dando erro "225 - Rejeicao: Falha no Esquema XML do lote de NF-e". Peguei o XML e joguei no validador RS e aparece os seguintes erros (anexo tb):

• 297 - [Simulacao] Rejeição: Assinatura difere do calculado
• 570 - [Simulacao] Rejeição: Tipo de Emissão 3, 6 ou 7 só é válido nas contingências SCAN/SVC
• 245 - [Simulacao] Rejeicao: CNPJ Emitente nao cadastrado

Alguém já passou por isso?

Obrigado,

Danilo

Pessoal boa tarde,

Estou fazendo a implementação do CT-e incoming para o processo CTEOUTLE.

Fiquei com uma dúvida nesse processo: Como o sistema consegue encontrar a PO de fretes e a folha de serviços para o CT-e que será escriturado, visto que no XML não há a informação do PO?

Percebi que antes do SP14, só era possível fazer a automação da entrada de fatura via desenvolvimento, usando as BADIS disponibilizadas no processo CTEFLXBL para os métodos: STEP_BEFORE_DACTE e STEP_AFTER_DACTE. Portanto via uma lógica, era possível saber para cada nota referenciada no XML, qual era o documento de transporte e dele conseguir recuperar as informações do PO e da folha de serviços. O processo CTEOUTLE segue mais ou menos a mesma idéia?

Acredito que em algum momento o sistema compara o XML com o PO.

Obrigado pela ajuda,

Assis

Caros, bom dia!

Estamos com um problema em um cliente onde 3 dos eventos do MD-e não funcionam, apenas a Ciência da Operação está sendo autorizada corretamente. Estamos com o SP19 e até onde consegui apurar/testar, temos o seguinte resultado:

Para os 3 eventos ccom erro, o status no monitor de eventos fica assim:

No monitor de lote de eventos:

E o retorno do PI (erro no Acknowledgment):

Estou achando que o problema é com a interface usada para os 3 com erro (EVENT_nfeRecepcaoEvento_OB), verifiquei a documentação (SAP Nota Fiscal Eletrônica (SAP Electronic Invoicing for Brazil) - SAP Library) onde menciona as interfaces (também consultei diversos threads, entre eles Cenarios no PI para Manifestação Destinatário e Monitor Portaria

e NFe Mainifesto - Confirmação da operação - onde menciona que o EVENT_OPPRG não deveria ser usado, porém também consta que o cenário do MD-e não foi alterado (não tem correspondente no namespace 008).

No programa que cria os lotes de evento (/XNFE/EVENT_BATCH_SEND) é chamada a FM /XNFE/EV_BAT_BATCH_SEND, que testa se for versão 2.00, envia para interface 006 (chamada opco_batch_send):

E se for versão 3.10 envia para 008:

Procurei notas para o programa, includes e FMs envolvidos, não encontrei nada que pareceu relevante.

No cenário que estamos testando, buscamos a lista dos documentos do webservice de distribuição, em seguida é feita a ciência (automaticamente) e depois tentamos emitir os demais eventos, porém sem sucesso.

Tenho a impressão de a diferença de interfaces está relacionada com o campo /XNFE/EVENTS-XMLVERSION_RDOC não estar preenchido na emissão da Ciência da Operação, enquanto para os demais eventos este campo está preenchido com 3.10.

Alguém tem alguma indicação, seja se estamos com erro de configuração ou de programas?

Se tiverem exemplo de MD-e funcionando no SP19, poderiam compartilhar também se está funcionando com o webservice de DF-e?

Obrigado!

Abraços,

Eduardo Hartmann

Alguém sabe me informar o motivo do erro abaixo,

Quando estou na etapa da entrada da Danfe, esta aparecendo uma mensage de erro no momento de exibir a imagem da Danfe.7

Erro ADS2

Etapa: Entrada da Danfe

PessoALL,

Alguém já teve esse erro 8B 166? na hora de fazer a Miro (entrada da fatura) , com fornecedor parceiro , ocorre este erro , parceiro já existe.

Percebi que acontece quando colocamos a cat. de NFe , este erro só ocorre para fornecedor parceiro.

Obrigado

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

•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 ) 

•Tag não mapeada corretamente para o XML ( 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.

,

Bom dia,

Após aplicar algumas notas referente à NFe 3.10 as alíquotas de ICMS e IPI nas minhas ordens de vendas ficaram incorretas na tela e na tabela KONV, porém o resultado do valor calculado ficou certo.

Isso ocorre também no documento de faturamento.

Nas notas fiscais todos os valores ficaram corretos, inclusive as alíquotas.

A alíquota apresentada é 50,00% para IPI e 180,00% para ICMS, onde o correto deveria ser 5,00% e 18,00% respectivamente.

Abri um incidente na SAP mas ainda não tive nenhuma resposta.

Se alguém passou por esse problema e puder me ajudar.

Muito obrigado,

Luis Andre Vilela

Boa tarde,

     Estamos tendo problemas em efetuar o cancelamento extemporâneo de NF-e(s) emitidas em SVC do estado de MG. Todas são rejeitadas com o código 220 (Rejeição: Prazo de Cancelamento Superior ao Previsto na Legislação).

     Alguem já passou por este problemas? Se sim, qual foi a solução aplicada no GRC NF-e?

Obs.:

     Entramos em contato com o pessoal da Receita Estadual de MG, e segue abaixo a resposta deles:

O cancelamento extemporâneo da nota emitida via SCAN ainda não é possível para quem utiliza o emissor gratuito.

Só pode ser feito via aplicativo do contribuinte (programa próprio) utilizando o WebService

“*NfeRecepcaoEvento: https://nfe.fazenda.mg.gov.br/nfe2/services/RecepcaoEvento“.

Este endereço não é para acesso direto e sim para ser acessado via aplicativo emissor.

Caso ele use emissor próprio:
Favor orientar o contribuinte a verificar para onde está sendo endereçado o cancelamento pois no caso de cancelamento extemporâneo de NFe emitida no SCAN  a solicitação de cancelamento deve ser encaminhada para os webservices da SEF-MG e não para o ambiente nacional. O ambiente nacional NÃO autoriza cancelamento extemporâneo.

Se ele usa emissor gratuito deverá fazer denúncia espontânea pois não é possível transmitir o cancelamento extemporâneo de nota emitida via SCAN.

Equipe SPED -
SEF/MG

DED/ DIEF/ SAIF

__________________________________

Abraços

Márcio Marusco

Boa tarde,

Temos uma nota que deu um erro devido a uma RFC que está sendo desenvolvida e por engano apontaram para a produção usar, e gerou a seguinte mensagem: "Problema no sistema ERP chamado: Function module "ZNFE_READ_XML_310" not found", com isso a nota foi autorizada e atualizada no ECC, mas no GRC ficou status de erro. Fizemos algumas tentativas de continuar o processo no monitor, mas aí exibe a mensagem de erro: "Erro na transferência do código de status 100 do documento XXXXXXXXXX para ERP", e não conseguimos atualizar o status no GRC. Alguém sabe alguma maneira de corrigir isso?

Seguem os prints:

Obrigada,

Jamile.

Bom dia,

Para imprimir a cópia da DANFE no CRM estou utilizando o mesmo programa que imprimi a cópia no ECC, o layout está correto no ECC, mas no CRM ocorre uma alteração na escala de texto, ocorre uma ampliação no espaço entre as palavras, consequentemente ocorre uma quebra de linha no título em alguns campos da DANFE quebrando e ocultando a linha que imprimi o valor do campo. Não posso alterar a posição da impressão do valor (subir ou baixar uma lina), pois isso afeta a impressão no ECC.

Tem como realizar alguma alteração de configuração quando for imprimir a DANFE no CRM?

Grato.

Bom dia a todos!

Gostaria de pedir, por favor, se alguém já precisou atualizar a identificação do transporte (LIKP-TRAID) na criação da remessa a partir do GRC Inbound utilizando a tag <placa> do xml de entrada (layout 3.10), se sim, há alguma BADi que permite isso?

Eu implementei a BADi 'Determination of Custom UI for Logistics Workplace for Inbound NF-es' conforme SAP note 2038967. No entanto, nesse momento a ordem de fornecimento já está criada e eu preciso  que seja atribuído a placa do veiculo na criação da remessa, porque o veiculo precisa da ordem de descarga (impressa automaticamente) que segue o veiculo até o ponto de descarga e nesse doc. é obrigatório a placa.

Obrigada.

Patrícia

Ola a todos,

Ao gerar documento pela FM BAPI_INCOMINGINVOICE_CREATE1 que esta configurada para gerar taxas automaticamente, estou ajustando o valor do impostos por meio de um enhancement criado na FM J_1B_NF_DOCUMENT_INSERT com o objetivo de ajustar os valores financeiros, evitando assim a famosa diferença de 0,01 centavo  que ocorre em muitos lançamentos deste tipo.

Meu problema agora esta relacionado ao valores contábeis gerados para o lançamento, uma vez que o documento contábil do mesmo documento permanece com a diferença de 0.01 lançada em uma conta.

Como eu poderia estar corrigindo estes valores? tenho muitas duvidas sobre este tema.

Inicialmente preferia deixar a BAPI continuar gerando as taxas de depois ajustar conforme já faço hoje.

Por outro lado não estou achando uma forma de ajustar os valores contábeis, alguém pode me ajudar com isso?

Agradeço antecipadamente...

Oi Pessoal,

Foi liberada hoje a SAP Note com as alterações necessárias para o layout 3 do SPED ECD.

SAP Note 2154499  SPED ECD: Ato Declaratório Executivo COFIS 17/2015

Os pré-requisitos dessa SAP Note estão abaixo:

Note 1998551

Note 2013607

Note 2040307 

Note 2154499 

Note 1909036 

Note 2048764

Uma observação importante é que além dos pré-requisitos a nota do layout 3 possui passos manuais, então é necessária atenção redobrada para sua implementação.

Detalhes técnicos da solução entregue:

Registro 0035 - Identificação do SCP -> somente BAdI, método fill_register_0035.

Registro I053 - Subcontas Correlatas -> somente BadI, método fill_register_I053

Registro J935 - Identificação dos Auditores Independentes -> somente BAdi, método fill_register_j935

Alteração não coberta por essa nota:

Inclusão da forma de escrituração usando o livro "S – Livro da SCP Mantida pelo Sócio Ostensivo".

att,

Renan Correa

Boa tarde pessoal

A SAP liberou recentemente a nota 2128097, que permitie a criação dentro do SAP de um XML emitido à partir de um sistema legado. Ou seja, caso a empresa possua outro sistema emissor de NF não-SAP, é possível importá-lo e criar a NFe.

Minha dúvida é como esta funcionalidade cria a nota dentro do SAP. Imagino que seja como uma nota manual, mas como ficaria a contabilização? Deverá ser feita à parte?

Obrigado.

Boa tarde,

Já pesquisei diversas threads e notas SAP sobre como habilitar o campo referente ao ato concessório do Drawback na J1B1N , porém só encontrei referências para a versão a partir da 605.

Alguém tem alguma referência para de como fazer isso na versão 604?

Abraço,

Vitor