Dhsaient + Pcnnfew

[Delphi in Delphi]

Prezados, a pedido de um amigo que utiliza a ferramenta fui verificar um determinado problema, então desculpe-me se estiver enganado quanto a informação que vou postar sobre a Acbr.

 

Ao realizar um teste de envio da NF-e 3.10 em Homologação, tive problemas quanto ao campo "dhSaiEnt" (Data e Hora de Saída da 

Mercadoria/Produto). Quando este campo fica em branco, está sendo apresentado um erro de data inválida retornado pela Sefaz.

 

Segundo o manual da versão 3.10 da NF-e (NT2013.005) este campo não é obrigatório, agora analisando o código nós vemos:

Gerador.wCampo(tcDat, 'B10', 'dSaiEnt', 10, 10, 0, nfe.ide.dSaiEnt, DSC_DSAIENT);

A função wCampo com o tipo "tcDat" já faz a verificação se a data é "null" e então manda em branco para o XML. Porém com a alteração deste campo para o formato "AAAA-MM-DDThh:mm:ssTZD" (se versão maior ou igual a 3) a linha passou a ser:

Gerador.wCampo(tcStr, 'B10', 'dhSaiEnt', 25, 25, 0, DateTimeTodh(nfe.ide.dSaiEnt) + GetUTC(CodigoParaUF(nfe.ide.cUF), nfe.ide.dSaiEnt), DSC_DSAIENT);

Repare que o tipo é "tcStr", e este não mais faz o decode da data para verificar se trata-se de uma data "null". Então temos ai o problema se a data não for preenchida, mesmo assim ela será informada no XML (30/12/1899), mas ocorre porque este formato de data não funciona com o tipo "tcDat".

 

Como eu não sei o formato de alteração dos arquivos e regras da Acbr, não realizei uma correção efetiva para isso, apenas validei a data antes da chamada do "wCampo" de 'dhSaiEnt'. 

if (not DateTimeIsNull(NFe.Ide.dSaiEnt) then

É fato que este campo em algumas UF se faz obrigatório, porém em outras não.

Editado 24 Fevereiro, 2014 por Macgayver Armini

[Juliomar Marchetti]

Bom dia

Caso tenha feito correções no ACBr favor anexar a unit ao post que será análisada

[Delphi in Delphi]

Obrigado Juliomar, como não tinha mais Delphi aqui em minha máquina, foi testado no Trial do Xe5, obrigado.

 

 

pcnNFeW.pas

[dalpiaze]

Exatamente, estou com o mesmo problema: ao enviar XML sem colocar a DataHora de Envio (dhSaiEnt) que no componente é a propriedade dSaiEnt (compatibilidade com versao 2.0), retorna erro de validação do Schema: 

 

The element '{http://www.portalfiscal.inf.br/nfe}dhSaiEnt' with value '1899-12-30T00:00:00-02:00' failed to parse.

 

Me parece que o componente está gerando essa Tag no XML mesmo estando com valor Zero

 

Estou usando versão 3.1 da NF-e e com os Schemas PL_008b

[Italo Giurizzato Junior]

Bom dia dalpiaze,

 

Por favor atualize os fontes e tente novamente.

[dalpiaze]

Bom dia dalpiaze,

 

Por favor atualize os fontes e tente novamente.

 

Italo, bom dia,

Muito obrigado, funcionou perfeitamente.

Ate.

[[email protected]]

Boa noite Amigos

Embora esses posts sejam antigos, e também não sei se consigo respostas por aqui, estava procurando soluções e acabei encontrando algumas informações.

Ocorre que comecei a usar o ACBrNFe me baseando pelo exemplo e quando iniciei os testes em ambiente de homologação recebi os erros de validação, mesmo tendo OK na validação de Regras de negócio dentre outras coisas.

Quando tento Validar o XML gerado recebo os erros de validação relacionado com a propriedade dhSaiEnt, conforme mensagem abaixo. No entanto, essa propriedade não existe, mas existe dSaiEnt e hSaiEnt. Lendo o que os colegas colocaram a partir da versão 3.10, passou a valer o campo dhSaiEnt, mas não sei como popular esse campo.
Podem me ajudar a desvendar o problema? 

-------------- Falha na validação dos dados da nota: XXXXX ---------- 

 --> 1839 - Element '{http://www.portalfiscal.inf.br/nfe}dhSaiEnt': [facet 'pattern'] The value '2023-03-20T00:00:00+00:44' is not accepted by the pattern '(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))T(20|21|22|23|[0-1]\d):[0-5]\d:[0-5]\d([\-,\+](0[0-9]|10|11):00|([\+](12):00))'.
---------------------------- -------------- -------------- -------------- 

Estou alimentando os campos conforme abaixo, mas também não sei se tenho que usar (e como) o método Gerador.wCampo.

NotaF := ACBrNFe1.NotasFiscais.Add;
...
NotaF.NFe.Ide.dEmi       := Date;
NotaF.NFe.Ide.dSaiEnt   := Date; 
NotaF.NFe.Ide.hSaiEnt   := Now;  
NotaF.NFe.Ide.dhCont    := date; 
...

Achava que não estava com o trunk2 atualizado, mas tudo indica que estou.

Aproveitando, meu cliente atualmente usa uma empresa (terceira) para emitir NFe. Meu sistema gera um arquivo TXT no layout dessa empresa e eles processam (ambiente de produção) a nota sem problemas. 

A idéia é implantar a emissão da NF pelo ACBr. 

Pergunta 01: Gostaria de saber se todas as validações em ambiente de homologação passarem sem problemas, eu já poderia virar a chave pra começar emitir em produção? O que recomendam ?

- Atualmente já estou conseguindo alimentar o componente com todos os dados
- O método Assinar e o método gravarXML estão funcionando sem problemas
- Consigo ver todos os dados carregados no TreeView ao Importar um XML e colocá-los em banco de dados
- Consigo consultar carregando XML de uma NFe processada em produção e ver o status de emissão pelo SEFAZ

Pergunta 02: Ao gerar uma NFe (tpAmb) eu recebo um codigo de retorno (cStat=0). Em ambiente de homologação não deveríamos receber algum código entre (100 - 999)?

Desde já agradeço pela ajuda e quero parabenizá-los pelo projeto ACBr

[Juliomar Marchetti]

16 horas atrás, [email protected] disse:

Boa noite Amigos

Embora esses posts sejam antigos, e também não sei se consigo respostas por aqui, estava procurando soluções e acabei encontrando algumas informações.

Ocorre que comecei a usar o ACBrNFe me baseando pelo exemplo e quando iniciei os testes em ambiente de homologação recebi os erros de validação, mesmo tendo OK na validação de Regras de negócio dentre outras coisas.

Quando tento Validar o XML gerado recebo os erros de validação relacionado com a propriedade dhSaiEnt, conforme mensagem abaixo. No entanto, essa propriedade não existe, mas existe dSaiEnt e hSaiEnt. Lendo o que os colegas colocaram a partir da versão 3.10, passou a valer o campo dhSaiEnt, mas não sei como popular esse campo.
Podem me ajudar a desvendar o problema? 

-------------- Falha na validação dos dados da nota: XXXXX ---------- 

 --> 1839 - Element '{http://www.portalfiscal.inf.br/nfe}dhSaiEnt': [facet 'pattern'] The value '2023-03-20T00:00:00+00:44' is not accepted by the pattern '(((20(([02468][048])|([13579][26]))-02-29))|(20[0-9][0-9])-((((0[1-9])|(1[0-2]))-((0[1-9])|(1\d)|(2[0-8])))|((((0[13578])|(1[02]))-31)|(((0[1,3-9])|(1[0-2]))-(29|30)))))T(20|21|22|23|[0-1]\d):[0-5]\d:[0-5]\d([\-,\+](0[0-9]|10|11):00|([\+](12):00))'.
---------------------------- -------------- -------------- -------------- 

Estou alimentando os campos conforme abaixo, mas também não sei se tenho que usar (e como) o método Gerador.wCampo.

NotaF := ACBrNFe1.NotasFiscais.Add;
...
NotaF.NFe.Ide.dEmi       := Date;
NotaF.NFe.Ide.dSaiEnt   := Date; 
NotaF.NFe.Ide.hSaiEnt   := Now;  
NotaF.NFe.Ide.dhCont    := date; 
...

Achava que não estava com o trunk2 atualizado, mas tudo indica que estou.

Aproveitando, meu cliente atualmente usa uma empresa (terceira) para emitir NFe. Meu sistema gera um arquivo TXT no layout dessa empresa e eles processam (ambiente de produção) a nota sem problemas. 

A idéia é implantar a emissão da NF pelo ACBr. 

Pergunta 01: Gostaria de saber se todas as validações em ambiente de homologação passarem sem problemas, eu já poderia virar a chave pra começar emitir em produção? O que recomendam ?

- Atualmente já estou conseguindo alimentar o componente com todos os dados
- O método Assinar e o método gravarXML estão funcionando sem problemas
- Consigo ver todos os dados carregados no TreeView ao Importar um XML e colocá-los em banco de dados
- Consigo consultar carregando XML de uma NFe processada em produção e ver o status de emissão pelo SEFAZ

Pergunta 02: Ao gerar uma NFe (tpAmb) eu recebo um codigo de retorno (cStat=0). Em ambiente de homologação não deveríamos receber algum código entre (100 - 999)?

Desde já agradeço pela ajuda e quero parabenizá-los pelo projeto ACBr

por favor queira criar um tópico detalhando seu problema pois o que tem acima é muito antigo e foi antes ainda do refactoring do trunk2.