Deshabilitar Campo adicional.

Buenas Tardes,
  Por favor si me pueden ayudar con lo siguiente:
Cree un campo adicional, que es como un combo, tiene 4 opciones (Pendiente, Revisado, Aprobado, Pagada), este campo adicional esta habilitado en la factura de venta, la idea es que cuando el usuario coloque la opción pagada y actualice el documento, entonces quede deshabilitado este campo para que no puedan colocar otra opción.
  Imangino que esto sera ya por el TN.
Saludos y gracias de antemano.

Hay alguna razon para que la factura se actualice?
Si no la hay tan simple como poner esto
if @transaction_type in ('U') and @object_type in (13)
begin
set @error =1
set @error_message='No puede modificar factura'
end
La otra opcion seria, si no quieres que un usuario en particular la modifique entonces
if @transaction_type in ('U') and @object_type in (13)
begin
declare @user as int
set @user = (select usersign2 from oinv where docentry=@list_of_cols_val_tab_del)
if @user in (3,5,2,18) ---numeros que sacas del usercode de la tabla ousr
begin
set @error =1
set @error_message='No puede modificar factura'
end
end
Y si lo que quieres es unicamente validar el campo que no se cambie para usuario en particular , hay que meter un poco mas de codigo
if @transaction_type in ('U') and @object_type in (13)
begin
declare @user as int
declare @combo as int
set @user = (select usersign2 from oinv where docentry=@list_of_cols_val_tab_del)
set @combo=(select u_combo from oinv where docentry=@list_of_cols_val_tab_del)
if @user in (3,5,2,18) and @combo != (select u_combo from adoc where objtype=13 and docentry=@list_of_cols_val_tab_del and
loginstac in (select max (loginstac-1) from adoc where objtype=13 and docentry=@list_of_cols_val_tab_del))
begin
set @error =1
set @error_message='No puede modificar factura'
end
end
Algo asi

Similar Messages

  • Movimiento de Inventario

    Buenas tardes
    Quiero pedir la colaboracion de alguien que me pueda ayudar a ingresar un campo adicional con el costo de el Item al siguiente query.
    Gracias
    Declare @FromDate Datetime
    Declare @ToDate Datetime
    Declare @Whse nvarchar(10)
    Set @FromDate = (Select min(S0.Docdate) from dbo.OINM S0 where S0.Docdate >='[%0]')
    Set @ToDate = (Select max(S1.Docdate) from dbo.OINM s1 where S1.Docdate <='[%1]')
    Set @Whse = (Select Max(s2.Warehouse) from dbo.OINM S2 Where S2.Warehouse = '[%2]')
    Select
    @Whse as 'Warehouse',
    a.Itemcode,
    max(a.Dscription) as ItemName,
    sum(a.OpeningBalance) as OpeningBalance,
    sum(a.INq)  as 'IN',
    sum(a.OUT) as OUT,
    ((sum(a.OpeningBalance) + sum(a.INq)) - Sum(a.OUT)) as Closing
    ,(Select  i.InvntryUom from OITM i where i.ItemCode=a.Itemcode) as UOM
    from(
    Select
    N1.Warehouse,
    N1.Itemcode,
    N1.Dscription,
    (sum(N1.inqty)-sum(n1.outqty)) as OpeningBalance,
    0 as INq,
    0 as OUT
    From dbo.OINM N1
    Where
    N1.DocDate < @FromDate
    and N1.Warehouse = @Whse
    Group By
    N1.Warehouse,N1.ItemCode,N1.Dscription
    Union All
    select
    N1.Warehouse,
    N1.Itemcode,
    N1.Dscription,
    0 as OpeningBalance,
    sum(N1.inqty) ,
    0 as OUT
    From dbo.OINM N1
    Where
    N1.DocDate >= @FromDate and N1.DocDate <= @ToDate and
    N1.Inqty >0
    and N1.Warehouse = @Whse
    Group By
    N1.Warehouse,N1.ItemCode,N1.Dscription
    Union All
    select
    N1.Warehouse,
    N1.Itemcode,
    N1.Dscription,
    0 as OpeningBalance,
    0 ,
    sum(N1.outqty) as OUT
    From dbo.OINM N1
    Where
    N1.DocDate >= @FromDate and N1.DocDate <=@ToDate and
    N1.OutQty > 0
    and N1.Warehouse = @Whse
    Group By
    N1.Warehouse,N1.ItemCode,N1.Dscription) a, dbo.OITM I1
    where
    a.ItemCode=I1.ItemCode
    Group By
    a.Itemcode
    Having sum(a.OpeningBalance) + sum(a.INq) + sum(a.OUT) > 0
    Order By a.Itemcode

    Hola.
    Usa los campos Price y CalcPrice
    Saludos.

  • Como usar o compo de inf. adicionais do projeto acbr (infAdFisco e infCpl)?

    Como usar o compo de informações adicionais do projeto acbr (infAdFisco e infCpl) ?
    A estrutura é simples.
    O problema é que esse campo não veio no arquivo de demonstração, aí, não dá pra usar.
    E aí???

    Bom dia Geovani,
    No caso do SAP R/3 preencher estas informações podem ser preenchidas na BADI CL_NFE_PRINT (FILL_HEADER/FILL_ITEM),
    pode seguir o link:
    Informaçoes no campo "infAdProd"
    No fórum tem outras pesquisas sobre isto.
    Caso sua mensageria e também seu ERP não sejam SAP, acredito que você receberá apoio especializado nos fórums deste referido projeto.
    Atenciosamente, Fernando Da Ró

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

  • Campo vAFRMM para transporte Marítimo - NFE 3.10

    Olá Pessoal,
    Para NFE 3.10, é exigida a tag vAFRMM quando há transporte marítimo.
    AFRMM = Adicional de Frete para Renovação da Marinha Mercante.
    O problema é que nas transações de NFe, esse campo aparece como cabeçalho e no XML aparece como item. O valor no XML para os itens, aparece REPLICADO com o valor do cabeçalho (MarFrete).
    Alguém conseguiu resolver esse problema?
    O mesmo foi corrigido por nota da SAP ou o rateio ocorreu na BADI mesmo?
    Procurei até controle de tela para abrir esse campo nos itens, mas não encontrei nada.
    Agradeço desde já qualquer informação,
    Paulo Henrique

    Oi Paulo
    Esse campo é preenchido via BadI. Ou seja, necessário verificar o desenvolvimento interno.
    Abraço
    Eduardo Chagas

  • 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

  • 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

  • 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

  • Campo Sujeito a Imposto

    Boa Tarde galera do fórum, preciso da ajuda de vocês. É o seguinte, na minha primeira implantação com o 8.8 eu não estou conseguindo fazer com que o sistema calcule os impostos, o problema é que quando vamos emitir uma nota fiscal ou qualquer outro documento a coluna sujeito a imposto vem como padrão NÃO e quando isso acontece o imposto não é calculado, ou seja, tinha que vir SIM para poder calcular o imposto. E ainda se eu coloco pra SIM e altero a utilização, por exemplo troco pra Revenda ou qualquer outra, o sistema volta a colocar como NÃO.
    Lembrando que esse campo Sujeito a Imposto não vem padrão para visualizar no documento, sendo necessário habilitá-lo nas Configurações de Formulário. Estou meio que agoniado para resolver isso... Alguma idéia ?
    Estou usando SAP 8.8 Pl 15
    Desde já agradeço a colaboração de todos.

    Rodrigo, boa noite.
    Você deve ter realizado a importação dos itens de estoque pelo DTW.
    Você deve informar a coluna TaxType = tt_Yes
    Esta coluna deixa automatico a coluna como SIM e também libera a seta de imposto do item para alteração.
    Abraços
    Junior
    Edited by: Alaito Rosner Junior on Dec 6, 2010 1:09 AM

  • Como colocar como padrão o campo "Unidades Base" em um documento de entrada

    Olá,
    O campo "unidades bases" (UseBaseUn) vem como padrão nos documento de marketing como NÂO, como faço para que ele venha como padrão SIM ou uma pesquisa formatada que ao incluir um item o campo mude para SIM?
    Por gentileza, aceito sugestões, pois tem alguns itens que o cliente cadastrou errado no campo NumInBuy(Itens por unidade de compra) da tabela OITM e para esses itens ele precisa sempre quando inserir uma entrada de mercadoria (recebimento ou NF), selecionar sim para o campo "Unidades bases" na linha do item. Se esse campo viesse como "sim" padrão ou uma pesquisa formatada que mude o valor para "sim" me ajudaria muito.
    Conto com a ajuda
    Abs,
    Lucidio Gandra

    Resolvi com procedure no SBO_SP_TransactionNotification

  • NFe complementar - Erro no campo nº da NF-e

    Bom dia,
    Estou com um outro problema crítico de NFe.
    1- Como é uma nota fiscal complementar é feito o processo e no momento de salvar, gera uma NF saida.
    2- O erro encontrado é que no momento da criação ele pede o numero da nf... o qual o SAP deve gerar automaticamente, porém o campo encontra-se aberto e sem número. Assim, o SAP não deixa concluir o processo e a NFe não é gerada, por faltar dados neste campo.
    Alguém já passou por isso?

    Bom dia angelstyle,
    Desculpe, mas não entendi tecnicamente o passo a passo executado.
    Quanto ao campo estar aberto. É uma NF de sua emissão própria? digo, está gerada como tal? para fechar a tela seria o caso de ver algumas notas de configuração de tela
    Quanto ao não numerar, também verifique se esta nota está como emissão própria e se as configurações para numeração estão devidamente associadas ao formulário.
    A propósito, qual o CALLRFC desta NF-e gerada? vazio, 1, 2 ou 3?
    Atenciosamente, Fernando Da Ró

  • Sugestão para o campo verProc - Versão do processo de emissão da NF-e

    Olá a todos !
    Gostaria da opnião de todos sobre o campo Versão do processo de emissão da NF-e (verProc), parametrizado no R/3 em J_1BNFE_CUST3_4V campo VERPROC nas configurações de definição do local de negócio, filial CNPJ.
    Minha dúvida é sobre a atualização para a vesão 2.0 do layout do XML, como a versão é definida no campo VERSION, tag versao, com qual informação vcs estão utilizando neste campo, já que trata-se de um campo texto ?
    Pesquisando no forum, encontrei uma Thread sobre Erro de Validação - IS_NFE_HEADER-VERPROC link: Erro de Validação - IS_NFE_HEADER-VERPROC onde contem a mesma informação de exemplo utilzada aqui (SAP NFE 1.0).
    Vcs estão atualizando o campo para SAP NFE 2.0, por exmplo ? Mantendo a informação antiga, pois como não foi modificada a aplicação, ou colocando alguma outra coisa ?
    Creio que quanto mais gente postar uma opinião neste caso é melhor.

    Bom dia a_cristovao,
    Esta informação serve como identificação de produto emissor de NF-e no XML/Sefaz.
    Normalmente coloca-se "SAP NFE 1.0" ou "SAP GRC NFE 1.0" ou "SAP NFE 1.0 SP16".
    É mais relacionado ao produto que ao layout.
    Atenciosamente, Fernando Da Ró

  • 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

  • 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

  • Campo cNF do XML v.200 da NFe com 9 dígitos

    Olá!
    Estamos testando a NFe na versão 2.00 do XML.
    Encontramos inconsistência no campo cNF do XML gerado pelo SAP.
    Segundo o Manual do Contribuinte 4.01, o campo cNF deve ter o  tamanho de 8 dígitos.
    Nosso ambiente de testes está com o SP18 atualizado e o local de negócio atualizado para gerar o lay-out do XNL da NFe no na versão 2.00. Neste ambiente, o SAP está gerando o campo CNF no XML com o tamanho de 9 dígitos, sendo invalidado pelo SEFAZ.
    O XML na RFC do SAP do cabeçalho da NFe, gera o campo
    Somente para a versão 1.10 do XML da NFe que o campo cNF tem 9 dígitos, sendo que o primeiro refere-se ao tipo de emissão. Entretanto, para a versão 2.0 do XML, segundo o manual do contribuinte 4.01, dever ter 8 dígitos.
    Não temos o GRC. Nosso serviço de mensageria é da Alliance.
    Aplicamos as Notas SAP abaixo, porem sem sucesso:
    Note 1519167 - Nf-e: Issuing type filled for XML-version < 2.00
    Note 1520408 - Nf-e: Issuing type filled for XML-version < 2.00 and RFC = 3
    Alguem já passou ou está passando por isso? Como está resolvendo?
    Obrigado.
    Abrçs
    Heron Caetano

    Ola, respondendo a sua pergunta.
    O formato com 9 digitos para a troca de dados entre o ECC e o GRC aparentemente foi mantida para compatibilidade das versões, porem, a validacao dos dados do NFEid por exemplo e os demais processos, para o formato 006 ( XML 2.0 ) leva em conto o novo formato de 8 digitos como demonstrado abaixo.
    IF lv_id(2)     NE is_nfe_header-cuf       "Region
      OR lv_id+02(02) NE is_nfe_header-demi+2(2) "Year
      OR lv_id+04(02) NE is_nfe_header-demi+4(2) "Month
      OR lv_id+06(14) NE is_nfe_header-c_cnpj    "CNPJ of issuer
      OR lv_id+20(02) NE is_nfe_header-mod       "model
      OR lv_id+22(03) NE lv_serie                "serie
      OR lv_id+25(09) NE is_nfe_header-nnf       "NFe number
      OR ( lv_id+34(01) NE is_nfe_header-tpemis    "Issuing type
           AND is_nfe_header-version NE gc_xmlvers1_erp )  "only for newer version then 1.10 (005a)
      OR lv_id+35(08) NE is_nfe_header-cnf+1     "random number (except first digit fixed zero)
      OR lv_id+43(01) NE is_nfe_header-cdv.      "control digit
    De uma verificada no seu ambiente do GRC, ele está com o SP15 instalado com todas as notas aplicadas ? inclusive no seu ECC, todas as notas referentes ao XML 2.0 foram realizadas com sucesso?

Maybe you are looking for