Rejeição do validador do GRC dos campos IND_PRES e IND_FINAL

Bom dia,
Estou implementando o layout 3.10 da NF-e e encontrei um problema na validação dos campos IND_PRES e IND_FINAL.
O cliente possui SAP_APPL 600 SP 24.
O problema é na chamada do método FILL_HEADER da BAdI CL_NFE_PRINT: antes da chamada do método, os campos xmlh_310-ind_pres e xmlh_310-ind_final são valorizados. No entanto, após a chamada desse método, como não faço nenhuma alteração nos campos IND_PRES e IND_FINAL, as seguintes linhas de código sobrescrevem os valores da estrutura xmlh_310 com valores iniciais:
Include: LJ_1B_NFEF41
    if xmlh_badi is not initial.
      move-corresponding xmlh_badi to xmlh."#EC ENHOK
       IF xmlh-version >= gc_nfe_version_3.                "1933985
->          move-corresponding xmlh_badi to xmlh_310.       "2048213
      ENDIF.                                              "1933985
Alguns comentários:
1) Na implementação do método FILL_HEADER, a primeira coisa que eu faço é um MOVE-CORRESPONDING:
  MOVE-CORRESPONDING in_xml_header TO out_header.
  MOVE-CORRESPONDING in_doc TO out_header.
2) Acho muito estranho que o parâmetro de Import IN_XML_HEADER seja do tipo J1B_NF_XML_HEADER, pois nessa última estrutura não vejo os campos IND_PRES e IND_FINAL. Procurei notas relativas aos campos da J1B_NF_XML_HEADER, mas não achei nada de relevante para o meu problema.
3) Antes da aplicação da nota 2048213 existia um check para verificar se os valores eram iniciais antes de sobrescrevê-los com o move-corresponding...
4) Na chamada do método FILL_HEADER, a estrutura xmlh é passada, mas a estrutura xmlh_310 não. Então eu não tenho acesso aos campos xmlh_310-IND_PRES e xml_310-IND_FINAL no método FILL_HEADER.
Agradeço muito se puderem ajudar a resolver esse problema.
Obrigado!
Luis

Olá, Luis.
Acredito que seja um pouco tarde para responder, pois provavelmente você já resolveu seu problema.
Os campos IND_PRES e IND_FINAL estão na estrutura in_doc.
O que fizemos foi incluir na BADI FILL_HEADER os comandos de MOVE na seguinte ordem:
MOVE-CORRESPONDING in_doc TO out_header.
MOVE-CORRESPONDING in_xml_header TO out_header.
Com isso, os campos acima foram preenchidos corretamente na BADI, e nenhuma outra ação foi necessária.
Por favor me avise caso ainda ocorra o problema.
Abraço e boa sorte
Rodrigo Ferreira

Similar Messages

  • Preenchimento dos campos cEAN e cEANTrib no XML da NFE

    Boa tarde,
       A partir de 1º de julho de 2011, segundo o Ajuste SINIEF n. 16, de 16/12/2010, será obrigatório O preenchimento dos campos cEAN e cEANTrib com o GTIN (Numeração Global de Item Comercial) caso ele exista. A diferença entre os campos é que no campo cEAN será informado o GTIN do produto que irá constar os dados referentes ao fabricante, distribuidor , etc. Já no campo cEANTrib  será informado o GTIN da unidade tributável, referente aos impostos atribuidos ao produto.
       Onde faço o preenchimento destes campos para que apareçam no XML da NFe?
       Utilizo o ECC 5.0 e GRC Nfe 1.0 (SAPK-10015INSLLNFE).
       Exemplo do XLM gerado atualmente:
    <cEAN />
    <cEANTrib />
       Exemplo do código cEAN e cEANTrib: 07896534703010
    Att. Ronaldo
    Moinho Sul Mineiro

    Bom dia Pessoal,
    É um erro localizado na Sefaz MG por favor abram tickets no 0800 da Sefaz MG para correção do problema.
    Atenciosamente, Fernando Da Rós
    PS: Evitem postar em threads já respondidas, isso confunde a solução válida. Além de evitar a classificação da solução por pontos. Podem "gastar" criando novas threads...
    Edited by: Fernando Ros on Oct 20, 2011 12:50 AM

  • Búsqueda formateada - actualizada con dos campos

    Hola estimados!
    ¿Alguien sabe si se puede actualizar una búsqueda formateada si se modifica cualquiera de dos campos?
    Gracias!!!

    algo mas o menos asi es lo que yo uso, para modificar lascuentas de ingresos en venta y costo dentro de las ordenes de venta.
    al darle shift+f2 lo que hago es seleccionarlo del query manager( la consulta), y luego pongo la opcion de cambiar actualizacion automatica con la opcion de la lista al salir de columna modificada, selecciono almacen , que es la que youtilizo como base para el cambio de mi cuenta y en mi query, tomo en cuanta el dato de la cabecera SERIE.
    SELECT CASE WHEN ($[$8.0.0]>=1 AND $[$8.0.0]<=999999) THEN
    '550000001'
    WHEN ($[$8.0.0]>=1000000 AND $[$8.0.0]<=1999999) THEN
    '550000002'
    END
    FROM OITM T1
    WHERE T1.ITEMCODE=$[$38.1.0]
    Te puede ayudar !

  • Venda Intercompany – Preenchimento dos campos xPed e nItemPed

    Boa tarde Pessoal,
    Andei pesquisando mas sem sucesso por isto venho pedir ajuda.
    http://scn.sap.com/thread/3263202
    http://scn.sap.com/thread/3274014
    https://scn.sap.com/thread/1838307
    No ECC:
    O cenário standard de venda intercompany é muito similar ao de transferência entre plantas da mesma empresa.
    Em ambos os cenários, a remessa de SD é criada a partir do pedido de compras (VL10D).
    Não existe ordem de venda (OV) !
    No NFE10 inbound (automação)
    - a transferência é tratada como STOCKTRF.
    - a venda intercompany é tratada como NORMPRCH. Neste cenário, para não termos que fazer manualmente a etapa "atribuir itens de pedido” precisamos que o XML seja preenchido corretamente.
    Por isto pergunto:
    Que campos devemos preencher no ECC para que os campos <xPed> e <nItemPed> sejam preenchidos no XML ?
    PS1: Testei com B2B ativo configurado com X (PI) e com D (database) => Sem sucesso.
    PS2: Em cenários de venda com OV os campos são preenchidos corretamente
    PS3:  Ambiente ECC604 SP12  + GRC10 SP14
    Desde já obrigado.
    Rafael

    Oi Fernando,
    Estamos aguardando resposta do chamado, qualquer novidade posto aqui.
    Não entendi sua frase:
    A todos os projetos que estão passaram pelo layout 2.0 sugeri que incluíssem este tópico, mas neste momento concordo que fica bem difícil de garantir ele com a obrigação chegando.
    Poderia explica-la melhor ? Esse tópico que se refereu é o Decouple ? Qual seria essa obrigação?
    Sim, fizemos os testes enviando uma nota em memória e não são preenchidos os campos, e depois em uma nota retransmitida, são enviadas as tags, sem nenhuma outra modificação via BADI. Essa é a diferença entre os XMLs.
    Os campos não são obrigatórios, apenas um dos nossos clientes de B2B que solicitou o preenchimento para todos os seus pedidos. Acreditava que o Standard daria esse suporte, mais entendo que apenas funciona para os locais de negocio com Decouple ativado, o que questiono pois pelo processo desenhado ainda não foi possível definir / ativar o decouple. Além que devem ser realizadas outras modificações da BADI, pois outras informações já estão buscando da memória e temos que modificar para buscar das tabelas (passar do modo mais dificil para o mais fácil da implementação, conforme vc mesmo comentou, rsss).
    Obrigado pela ajuda e atenção.

  • Dúvida no Preenchimento dos campos PREFNO / CHECOD em NFS-e de SP

    Olá Pessoal,
    Estou a procura de informações sobre a solução para nota fiscal eletronica de serviços da prefeitura de São Paulo, pesquisando no forum pouco encontrei sobre a nota 981687 - NFe: For Services in Muncipio Sao Paulo.
    A SAP disponibilizou os dois campos PREFNO / CHECOD para o numero da nota fiscal e código de verificação gerados pela prefeitura (uma vez que o SAP deve gerar o número da RPS), além de um report para geração do arquivo TXT e envio manual.
    Minha dúvida é a seguinte:
    1) Após enviar o arquivo para a prefeitura, são convertias as RPS em Notas Fiscais Eletronicas. Como armazenar as informações nos campos standards mencionados ? Existe um outro report que le o arquivo de retorno da prefeitura ?
    Outra dúvida está na procura de uma sugestão, onde o RPS pode ter até 12 posições e o NFNUM do SAP apenas 6. Vcs estão utilizando outro campo Z para compor o numero maior ? Ou como esta fazendo quando o RPS atingir 999.999 ? Pensei en usar o NFENUM, mas teria o mesmo problema quando atingir o limite de 9 posições (999.999.999).
    Muito obrigado pela atenção e ajuda.

    A_cristovao ,
    Vamos ver se posso lhe ajudar em algo:
    1) Após enviar o arquivo para a prefeitura, são convertias as RPS em Notas Fiscais Eletronicas. Como armazenar as informações nos campos standards mencionados ? Existe um outro report que le o arquivo de retorno da prefeitura ?
    Resposta: Em alguns projetos que passei, consultei os abaps e sempre foi desenvolvido um programa Z para ler este arquivo e fazer um BDC na J1B2N, porem sua categoria de nota não dever ser eletrônica, aqueles dois campos flag no cabeçalho NF eletronica e NF servico, apenas o último(serviço) marcado para o BDC entrar e conseguir mapear o campo com o NFSe e cod verificador.
    2) Outra dúvida está na procura de uma sugestão, onde o RPS pode ter até 12 posições e o NFNUM do SAP apenas 6. Vcs estão utilizando outro campo Z para compor o numero maior ? Ou como esta fazendo quando o RPS atingir 999.999 ? Pensei en usar o NFENUM, mas teria o mesmo problema quando atingir o limite de 9 posições (999.999.999).
    Resposta: Esse estamos usando o NFNUM mesmo, não chegamos a nos preocupar com isso devido ser um volume baixo de NFS, talvez um chamado no componente XX-CSC-BR-NFE lhe ajude. 
    Abraço,
    Bruno Lima

  • Validador GRC SP17 não está funcionando corretamente para XML 3.10

    Caros,
    Recentemente subimos o SP17 no GRC (SAPK-90017INSLLNFE) e também implementamos as notas para nota versão do XML 3.10 no ERP (1933985 - NF-e new layout 3.10 e seus pré-requisitos).
    O XML está sendo gerado corretamente, mas nos casos em que alguma informação não é preenchida corretamente e deveria parar no validador do GRC, isto não ocorre. Exemplo tag F_NRO (house number)  vazia, não para no validador do GRC.
    Antes do upgrade do support package e na versão XML 2.0, o validador funcionava corretamente.
    Aparentemente as configurações de NF-e outboud na IMG do GRC estão corretas e as tabelas /XNFE/XMLVALID e /XNFE/NFEVALID estão preenchidas corretamente também.
    Alguém está passando pelo mesmo problema?
    Obrigada.

    Oi Cristiane,
    Qual status da NFe no monitor do GRC 3.10
    http://<host>:<port>/sap/bc/webdynpro/xnfe/nfe_outb_monitor ?
    Dei uma olhada no código da RFC /XNFE/OUTNFE_CREATE chamada pelo ERP para 3.10. Aparentemente somente a visão de CNPJ tem relevância para erro de validação quando o campo validação está preenchido.
    (SPRO - Nota Fiscal Eletrônica - Saída - Atualizar resposta do sistema para nºs próprios ID fiscal)
    Outro ponto que você pode avaliar e que tem relevância é a função  /XNFE/GET_XMLVERSION que reflete as configurações:
    SPRO - Nota Fiscal Eletrônica - Saída:
    - NF-e: atualizar sistemas das autoridades conectados
    - NF-e: atualizar versão dos tipos de mensagem
    E que talvez o caminho lógico, seja o que está errado... o que tenho visto muito.
    Veja se lhe ajuda na análise...
    Obrigado,
    Bruno

  • Dúvida no fluxo do processo de rejeição/recusa

    Bom dia, pessoal,
    Embora tenha participado de alguns projetos de nota fiscal eletrônica, uma coisa nunca ficou muito clara para mim. Estou em um novo projeto agora e eu queria fazer da melhor forma possível.
    A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois? Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
    A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota? Ela deve ficar como recusada? E o status de comunicação do sistema?
    Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ, a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
    Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor? Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
    É Isso...
    Obrigado,
    Fernando Fussi

    Bom dia Fernando,
    Esta dúvida é comum principalmente que boa parte dos projetos (no início) não fez a implementação de NF-e por Support Package mas por aplicação de notas, então os termos originais Rejected and Denied foram traduzidos de forma diferente em cada projeto (a SAP só entrega traduções por SP), isso deu margem a boa confusão no tema.
    A primeira dúvida é sobre Recusa/Rejeição. Basicamente qual a diferença entre os dois?
    Existe rejeição (2xx, 4xx,999) e denegação (301 / 302)
    - Na rejeição a Sefaz rejeita por algum dado incorreto e não deixa salvo no banco de dados dela, você deve tentar corrigir e enviar quantas vezes necessário
    - Na denegação é uma situação específica que o emissor ou o destinatário estão com irregularidade fiscal junto à Receita, neste caso a NF-e é armazenada na base da Sefaz e não deve ser novamente enviada (o ERP ao receber a denegação dispara o cancelamento automaticamente)
    Eu sempre entendi que uma nota é rejeitada pela SEFAZ, e recusada pela validação do GRC ou do outro sistema de mensageria. Essa abordagem está correta?
    - Sim, a rejeição da validação é devido a algo que provocaria uma rejeição da Sefaz se enviado você também pode tentar acertar até passar pelo validador/Sefaz
    A segunda dúvida é sobre essa mesma validação. Quando o GRC, ou outro sistema encontra erros de sintaxe do arquivo, ou de qualquer informação, qual deve ser o status dessa nota?Ela deve ficar como recusada? E o status de comunicação do sistema?
    - Sim, rejeitado pelo validador MSS=V   DOCSTAT=vazio (o ERP não considera que a rejeição do validador tem peso igual a validação da Sefaz, porém pro processo é a mesma coisa que no ERP tem status específicos)
    Veja detalhes sobre status e situações aqui:
    Status do SAP Nota Fiscal Eletrônica (ERP x GRC x PI)
    ou em inglês:
    NF-e Status on SAP Nota Fiscal Electronica Solution (ERP x GRC x PI)
    Quando uma nota fiscal está recusada, qual o melhor fluxo? Considerando que o erro foi apontado pelo sistema de mensageria e não pela SEFAZ
    - Em linhas gerais o fluxo básico seria RESET + tentar corrigir o que o GRC ou a Sefaz informaram + NF-e -> Send
    , a nota fiscal não pode ser cancelada. O sistema também não permite o estorno da nota, nem mesmo depois de resetar seu status . Uma vez eu debuguei e vi que é porque ela está numerada.
    - Em um ERP e GRC corretamente atualizado com os SP's e notas isso não é normal em cada caso a causa raiz deve ser encontrada e sanada com notas ou chamado à SAP
    Meu último problema é sobre inutilização. Alem do report, existe alguma outra forma de fazer a inutilização, direto pelo monitor?
    - Que report? O de encontrar gaps? Este report é para sanar um side effect quando os clientes não implementaram ainda o decouple. Hoje em dia todos os clientes devem implementar o decouple job para evitar vários transtornos como (gaps (já não dá mais medo), NF-e autorizada no GRC/Sefaz e não existe no ERP (isso é terrível), inconsistência de transmissão (dados obtidos em memória X dados obtidos do banco)....
    - Inutilização é direto no monitor, que situação está descrevendo?
    Penso em fazer isso justamente quando uma nota está recusada/rejeitada sem ter ido para o SEFAZ. Daí usaríamos a própria entrada dela, no monitor, para solicitar a inutilização da numeração.
    - não entendi. Hoje uma nota Rejected seja pela Sefaz ou pelo validador deve ser cancelada pelo monitor J1BNFE. Entendi errado sua pergunta?
    - Existe também uma nova funcionalidade "Cancel Prior Authorization" que permite o cancelamento de uma NF-e antes mesmo dela ter sido numerada
    Atenciosamente, Fernando Da Ró

  • Validação XML 3.10 (campo série)

    Boa tarde pessoal.
    Estou com um problema aqui um pouco estranho.
    Estamos fazendo a configuração do XML 3.10, e agora está acontecendo um erro.
    Durante a chamada da função /XNFE/OUTNFE_CREATE, que cria a nota de saída no GRC, é chamada a função /XNFE/OUTNFE_VALIDATION. Essa função faz a validação dos campos da nf-e de acordo com as regras existentes na tabela /XNFE/XMLVALID.
    Quando essa função vai validar o campo SERIE, o mesmo retorna erro na validação.
    A expressão regular da expressão é:
    0|[1-9]{1}[0-9]{0,2}
    O valor da Série é "001".
    Teoricamente essa expressão regular permite utilizar esse valor, pois ela permiti ou o literal "0" apenas, ou valores com pelo menos 1 dígito obrigatório de 1 à 9, com até dois dígitos (não obrigatórios) de 0 à 9.
    Essa expressão deveria permitir, "1  ", "001", " 01", "  1", etc.
    Eu testei a expressão em sites da internet com esta regex, e funcionou perfeitamente.
    Testei alterar a expressão (teste em programa Z) para 0|[0-9]{1}[0-9]{0,2}, e ai sim a expressão funcionou. Parece que o ABAP está considerando que é obrigatório que o primeiro campo da série seja diferente de 0.
    Att,
    Matheus Goulart

    Ola Matheus ,
       Tivemos o mesmo problema em um cliente, se você desativar o validador do GRC vai e enviar o xml request (versão 3.10) para SEFAZ de origem você vai ter um erro de falha do xml.
       Verifique no xml da versão 2.0 o valor da tag <serie>.  Mesmo enviando para o GRC a serie "001" o valor no xml ficava como <SERIE>1</SERIE>.
       Em resumo: Fizemos fizemos um ajuste na BADI CL_NFE_PRINT no metodo HEADER e  retiramos os "zeros a esquerda" da série da nota fiscal e não tivemos mais problemas.
    BR
    Allan Pizaia

  • NFe 3.10 - Erro 225: Rejeição: Falha no shcema XML da NFe

    Boa tarde.
    Estamos com problema no Schema do XML, já verificamos as informações do post abaixo:
    http://scn.sap.com/thread/3714800
    Aqui também ocorre o mesmo problema e quando reenviamos a nota o xml é processado. Porém, precisamos encontrar uma solução
    onde não seja necessário o reenvio manual do documento.
    Baixamos o XML com problema e depois da validação no SEFAZ (após o reenvio) e a unica diferença é a tag abaixo:
    Ela é criada após a validação do XML?
    *** XML Erro Schema
      <?xml version="1.0" encoding="utf-8" ?>
    - <NFe xmlns="http://www.portalfiscal.inf.br/nfe">
    *** XML OK, após o reenvio da NF
      <?xml version="1.0" encoding="utf-8" ?>
    - <nfeProc xmlns="http://www.portalfiscal.inf.br/nfe" versao="3.10">
    - <NFe xmlns="http://www.portalfiscal.inf.br/nfe">
    Gostaria de saber se alguém já passou por este problema e qual foi a solução aplicada.
    obrigado
    Juliano Diniz

    Oi Michael,
    Essa declaração que o José comentou é diferente mesmo, não vi em nenhum outro cliente e ela que deu erro no validador da SEFAZ no seu teste. Se você remove essa TAG e faz o teste no validador da SEFAZ RS o XML aponta outros erros.
    Teoricamente o XML começaria assim:
    <?xml version="1.0" encoding="UTF-8"?>
         <NFe xmlns="http://www.portalfiscal.inf.br/nfe">
    Além disso o XML do TXT tem umas quebras de linha que separaram o conteúdo das TAG's e causaram erro no validador da SEFAZ tb.
    O validador do GRC é basicamente uma função que aponta erros técnicos no preenchimento dos dados que vieram do ERP ( campos obrigatórios em branco, campos numéricos com valor alfanumérico, etc...) porém ele não validaria a estrutura final do XML ( encoding, montagem das TAG's e namespaces adicionados ).
    OBS: No arquivo adicionado tem o XML completo e por uma questão de "data protection" eu não recomendaria disponibilizar esse tipo de arquivo na internet, pois ele contém dados teoricamente sigilosos de negócio ( Clientes, transportadores, produtos/preços, Certificado digital da empresa emissora, etc...).
    att,
    Renan Correa

  • Campo de usuário em tabela de usuário não respeita o tamanho definido

    Criei uma tabela de usuário e dentro dela criei 10 campos alfanuméricos com tamanho de 10 posições. Ao executar a procedure SP_HELP no SQL Server para verificar o tamanho dos campos na estrutura da tabela verifiquei que o tamanho foi definido como -1, ou seja, o tamanho do campo não foi corretamente informado pelo B1 na criação da tabela e o SQL Server 2005 acabou por assumir como padrão o tamanho máximo de 4096 bytes.
    Se olharmos apenas para a definição da tabela e dos campos no B1 os valores são apresentados corretamente, mas não correspondem aos valores definidos nos metadados do banco. Isso é extremamente problemático pois derruba violentamente a performance das consultas nas tabelas de usuário.
    Existe algum workaround que a gente pode utilizar para resolver este problema?
    Testamos a criação de tabelas e campos de usuários na versão 2005B, rodando no SQL Server 2005 com as PLs 40, 41 e 42 e nessas três configurações o problema ocorreu sempre da mesma forma, como descrito acima.
    Sei que podemos forçar a correção da estrutura de dados das tabelas na mão, pelo comando ALTER TABLE do SQL Server, mas isso será apontado pelo Early Watch? Corremos o risco de perder a garantia do produto?
    Qualquer informação que ajudar a solucionar este problema será muito bem aceita.
    []'s
    Edited by: Rui Pereira on Nov 7, 2008 9:27 AM

    Oi Vitor,
    O problema ainda não foi resolvido. Abrimos um chamado na SAP pois entendemos que este comportamento do SBO não é o correto uma vez que ao definir campos alfanuméricos com o maior tamanho possível, as estruturas (metadados) acabam ficando gigantes e isso joga a performance dos add-ons e consultas formatadas pra baixo.
    Você pode reproduzir o problema criando UDFs em tabelas standard ou em UDTs pelo próprio B1. Não precisa criar os campos pelo SDK para que o problema ocorra não. Basta definir o campo do tipo Alfanumérico que, ao executar a SP_HELP no SQL Server você verá a estrutura do seu campo mais ou menos assim:
    CAMPO NVARCHAR(-1)
    Na documentação do SQL Server é explicado que o -1 representa a capacidade máxima de armazenamento do campo.
    Este problema só acontece no SQL Server 2005. No SQL Server 2000 o B1 se comporta bem.
    Edited by: Gabriel Izar on Oct 8, 2008 3:31 PM

  • Nota fiscal rejeitada por campos 'pMVAST, pRedBCST, vBCST' vazios no processo de transferência de crédito de ICMS

    Pessoal, bom dia!
    Vejam se alguém já passou por algo parecido em algum projeto...
    Estou com uma demanda pra alterar alguns parametros do processo de transferência de crédito de ICMS, que são:
    1-  A quantidade deverá ser preenchida com “0”.
    2-  O valor unitário deve ser “0”.
    3-  O campo de unidade de medida “Vazio”
    4-  A NCM não deverá ser vazia, mas ser preenchida com “00”.
    5-  O CST deverá ser “090”.
    A solução para os pontos 1, 2 e 3 foi criar um enhancement na função J_1B_NFE_PROCESS_OUTBOUND relacionada a J1B1N para alterar os valores digitados pelo usuário assim que a nota estiver sendo criada. Para o ponto 4, a solução foi criar um NCM "00" para utilização do usuário.
    E, no ponto 5, a solução foi orientar o usuário a optar pela origem do material "0" e optar pelo direito fiscal IC9 (Outros) que atribuirá a tributação 90, formando assim o 090 esperado.
    O problema é:
    Ao dar saída na nota fiscal pela J1B3N, ela está sendo rejeitada pelo fato dos campos 'pMVAST (Percentual da margem de valor Adicionado do ICMS ST), pRedBCST (Percentual da Redução de BC do ICMS ST), vBCST' (Valor da BC do ICMS ST) não estarem sendo preenchidos.
    Sendo assim, como posso resolver esse ponto?
    Em anexo está a tela do preenchimento da Writer com os devidos parametros e impostos, e está também o IDOC que foi gerado com os campos em branco.
    Desde já agradeço a atenção.

    Allan, boa tarde!
    Obrigado pela sua resposta, mas, conforme venho conversando com o fiscal resposável do projeto, o cenário é esse mesmo.
    Seguem abaixo e em anexo as regras Fiscais para emissão da nota de transferência de crédito de ICMS:
    Orientação de Preenchimento NF-e:
    Transferência de crédito
    A nota fiscal eletrônica (NF-e) também será emitida nas hipóteses de transferências de crédito acumulado de ICMS em razão de exportação, diferimento ou redução da base de cálculo.
    De acordo com a legislação, há regras a serem observadas para a emissão da NF-e referente a essa transferência de crédito. Resumidamente, alguns procedimentos comuns que poderão ser seguidos.
    Para emitir a NF-e, é necessário informar nos campos próprios:
    1. Como destinatário, o nome, o endereço e os números de inscrição estadual e no Cadastro Nacional de Pessoa Jurídica (CNPJ) do contribuinte ao qual se está efetuando a transferência;
    2. Nas Informações Complementares do quadro “Dados Adicionais”, a expressão “Transferência de crédito acumulado de ICMS, nos termos (indicar o base legal da transferência)” e o valor, por extenso, do crédito transferido. No aplicativo gratuito emissor da NF-e, essa informação constará no campo “Informações Complementares de interesse do contribuinte” da aba “Informações Adicionais”;
    3. No local destinado ao valor da operação do quadro “Cálculo do Imposto”, o valor do crédito acumulado transferido (no aplicativo gratuito de NF-e, esse valor será informado no Valor Total bruto). Nos demais campos, preencher com “0” (zero) para todos locais numéricos e obrigatórios nos quais não consta orientação específica - apenas um dígito “0” em cada, pois a NF-e trabalha com campo preenchido;
    4. Como natureza da operação: “Transferência de Crédito Acumulado de ICMS”;
    5. No campo “Finalidade de emissão” informar “NF-e de Ajuste”;
    6. Os CFOP e CST serão os códigos 5.601/5.602 e 090, respectivamente;
    7. A Nomenclatura Comum do MERCOSUL (NCM) será informada a expressão numérica “00”;
    8. A “Descrição do Produto” será informada a expressão “Transferência de Crédito Acumulado de ICMS”;
    9. A situação tributária do PIS e da COFINS será “Operação sem incidência da Contribuição; e
    10. A “Modalidade do frete” indicar “Sem frete”.
    8. Código de Situação Tributária – informar “90”. Página 168 do Manual de Integração.
    Na Nota Técnica 2013/005, ainda é informado que os campos 'pMVAST, pRedBCST e  vBCST' devem ser carregados no XML, e por se tratar de tranferência de crédito, os valores devem ser “zerados”.
    Aplicando o imposto ICS3, consigo inserir zeros nos campos indicados acima. O problema é que a NF é rejeitada novamente só que com erro no campo vBCSTRet (Valor da BC do ICMS ST retido), pois ao zerar os campos acima acabo obrigatoriamente atribuindo zero ao campo vBCSTRet, fato que não deve ocorrer.

  • GRC 10 - XML de "Skipped NF-e" não disponivel para download.

    Boa tarde a todos,
    Instalamos o GRC 10 e fizemos um teste de SKIP de uma NF-e que foi rejeitada pelo próprio validador do GRC. O Skip foi aprovado e o status voltou para o R/3 corretamente, porém, ao tentar fazer o download do xml de skipped NF-e ele não está disponível no portal para download.
    Quando fazemos o Skip de uma nota que foi rejeitada pela SEFAZ, neste caso, tanto o xml que foi rejeitado como o de Skipped NF-e ficam disponíveis para download.
    Na versão 1.0 do GRC o xml de Skip está disponível nas duas situações para download, ou seja, algo está faltando no GRC 10 que está impossibilitando fazer o download no primeiro cenário apresentado.
    Alguém já passou por este problema?
    Desde já agradeço,
    Juliano Costa

    Ainda não abri o chamado porque antes disso gostaria de saber de vocês se realmente isso não é algo que fosse um problema de configuração, etc.
    Irei abrir o chamado conforme orientação.
    Obrigado a todos,
    Juliano Costa

  • Campos cEAN e cEANTrib no XML da NFE (NT 2011/004)

    Bom dia,
    A partir de 1º de julho de 2011, é obrigatório o preenchimento dos campos cEAN e cEANTrib com o GTIN (Numeração Global de Item Comercial) caso ele exista.
    A diferença entre os campos é que no campo cEAN será informado o GTIN do produto que irá constar os dados referentes ao fabricante, distribuidor , etc.
    Já no campo cEANTrib será informado o GTIN da unidade tributável, referente aos impostos atribuidos ao produto.
    Sabemos que o preenchimento do cEAN é realizado através do campo standard no cadastro do material, e o cEANTrib é o mesmo número, e este cenário eu consigo tratar na BADI preenchendo abos os campos com os mesmos valores.
    Porém temos uma particularidade que é a seguinte:
    Tem um determinado cliente que me compra caixas com 24 unidades de óleo, e neste caso, o cEAN e o cEANTrib serão diferentes.
    Ex.:
    cEAN: 12345 (CDA)
    cEANTrib: 123456 (CX)
    No cenário normal, envio preencho as tags cEAN e cEANTrib com o código do cEAN (12345) que está cadastrado no campo específico do cadastro do material (MARA-EAN11).
    No cenário "especial", o GTIN tributado é diferente, preciso enviar na tag do cEAN o GTIN da CX (123456) e na tag do cEANTrib envio o GTIN do CDA (12345). Ambos os valores estão cadastrados nas informações adicionais do cadastro do material na aba de "EANs adicionais" conforme abaixo:
    UM alt     Texto un.     Código EAN/UPC     Ctg.EAN
    CDA     cada     7898357410015     HE
    CX     caixa     17898357410012     IC
    Como trato isso? Pois na BADI não tenho o campo do cEAN para tratar...
    Obrigado,
    Mateus.

    Oi Matheus.
    Você pode fazer habilitar este campo na BADI fazendo um append Z na estrutura  IF_EX_CL_NFE_PRINT~FILL_ITEM. Fizemos isso para habilitar outros campos como por exemplo o E1_FONE no cabeçalho da NF-e.
    Abraço
    Eduardo Chagas

  • Retornar Valor de Campo de Usuário C#

    Olá a todos.
    Estou com um problema para receber um valor vindo de um campo de usuário, quando estou fazendo uma interface UI, em C#.
    O nome do meu campo é U_NCliente. Estou utilizando o seguinte codigo:
    valor = ((SAPbouiCOM.UserDataSource)oForm.Items.Item("U_NCliente").Specific).ToString();
    Para todos os outros campos do form, utilizei o mesmo código, apenas trocando o número do item, porém quando tento retornar esse valor de um campo de usuário, recebo o seguinte erro:
    Item - Invalid item  . Form Unique Id: 'F_11', Item Unique Id: 'U_NCliente'
    Para os outros campos, do tipo EditText e ComboBox, o mesmo código funcionou corretamente.
    Obrigado.

    Problema resolvido.
    Para receber o valor de um campo de usuário, é necessário adicionar o seguinte código para passar o id do form dos campos de usuário antes:
    oForm = oApp.Forms.GetFormByTypeAndCount(-150, oApp.Forms.ActiveForm.TypeCount);
    Ficando o código assim:
    oForm = oApp.Forms.GetFormByTypeAndCount(-150, oApp.Forms.ActiveForm.TypeCount);
    valor = ((SAPbouiCOM.EditText)oForm.Items.Item("U_NCliente").Specific).String;
    Obrigado.

  • Nuevo recibo de salarios - Forzar impresión en dos páginas

    Hola a todos,
    al incluir en el recibo de salarios (PE51) los conceptos a incluir en el nuevo recibo de salarios al final del recibo, resulta que el recibo no cabe en una única pagina al imprimirlo.
    ¿Sabéis si existe alguna forma de introducir un salto de página al imprimir el recibo, de forma que toda la parte de devengos quede en una página y la parte correspondiente a las cotizaciones de la empresa (es decir, básicamente el formulario de muestra incluido en la nota 2142736 se imprima en una página aparte? No estamos utilizando Smartforms.
    Muchas gracias,

    Hola Marian Martin Martin y Josep:
    En recibos formato PE51 lo de imprimir en una segunda hoja ocurre cuando las lineas/columnas del formulario superan las lineas del formato de impresión que se fija en el momento de imprimir.
    Si tenéis un recibo PE51 de 75 lineas y que eliges el formato de impresión 65 lineas; las 10 ultimas lineas se imprimen en una segunda hoja.
    Otra opción que tenéis; aunque tengo que decir que no recuerdo del todo como lo hice entonces; es añadir el commando NEW-PAGE via una conversión Z en el RPCEDSZ9 de tal forma que la impresión lo interprete como salto de pagina. Buscando en mis archivos en encontrado un pantallazo pero falta el detalle; pero bueno algo ayuda
    De lo que recuerdo, los recibos PE51 se almacenan en un tabla interna que se llama XFORM que tiene el formato PC408. Este formato tiene dos campos; el primero LTYPE y el segundo LINDA. Aquí el juego consiste en añadir una linea con el valor "/:" en la primera y NEW-PAGE o <NEW-PAGE> (no recuerdo exactamente cual) en la segunda.
    Por mi parte de momento he podido adaptar todos los recibos de los varios clientes que tengo manteniendo una hoja de impresión,,, tanto los recibos normales como los finiquitos... ; todo el mundo lo agradece; el cliente porque no tendrá que duplicar su presupuesto de hoja dyna4 para los recibos de nominas y el planeta porque somos eco-friendly. Pensadlo por si podéis afrontar el cambio manteniendo una pagina.
    Antoine

Maybe you are looking for

  • If I have CS5 installed on one machine, do I need a new license to install on another machine?

    If I have CS5 installed on one machine, do I need a new license to install or transfer to another machine?

  • Iplanet to Oracle 10g AS

    Hi Folks, I am trying to upgrade an application in iPlanet 6.0 to Oracle 10g Application server. can anyone provide some pointers or past experiences on the same. esp regarding version incompatibilities of various technologies and the regarding any t

  • Page display based on count of records

    Hi All, i have one report requirement in BIP. my report should contains 3 pages only. Fist page contains first contact information. Second page should contain Second contact inforamtion. Third page should contain comparing of first contact age and se

  • Email attachments as icons

    Is this the only real solution for email attachments as icons: download and install the attachment tamer plug-in: http://lokiware.info/Attachment-Tamer

  • POP E-Mail

    What are the best settings for pop e-mail on the iPhone? The one thing I don't like is that you have three options with pop for deleting from the server: 1. Never 2. Seven Days 3. When removed from Inbox I think there should be another option: Prompt