dalpiaze

Pessoal, boa tarde, Sabemos que a NF-e 3.10 entrou em vigor em ambiente de Produção dia 10/03/2014. Utilizamos o ACBrNFe em nosso sistema, e já implementamos essa nova versão do Layout e já está funcionando normalmente. Nossos clientes já estão emitindo no novo XML 3.10 (maioria são de Santa Catarina) Tudo certo até aqui. O que ocorre é que, existem muitos sistemas de integração desenvolvidos por outras empresas, que importam o XML que o destinatário recebe, para fazer acerto de produtos/acertos de dados/importação de valores/contabilidade/etc/etc... E o que estamos percebendo é que vários desses sistemas ainda não estão adequados para importar o novo XML 3.10, acusando erro na hora de importar... Tem até clientes que falam que o seu destinatário não pagará até que não consiga importar a NFe (XML) em seu sistema. (E até provar que está tudo certo, mas que o sistema deles é que não consegue importar o xml ... já sabem né!) Uma observação: internamente sabemos que a estrutura do XML não mudou muito em relação ao 2.00, ou seja, os principais campos continuam lá e com os mesmos nomes... resumindo que se eu abrir o XML, trocar lá no iníco onde está "3.10" para "2.00" volta a funcionar a importação no sistemas de terceiros... (claro né!)... MAS CLARO QUE ISSO É GAMBIARRA. Resumindo: Abri esse tópico apenas no intuito de trocar essa idéia com outros, talvez que também já presenciaram isso, para relatarem também seus casos, se ocorre a mesma coisa... Nós particularmente pedimos a nossos clientes que insistam com seus clientes/fornecedores para que peçam a seus desenvolvedores para agilizar a conversão para versão 3.10, mas sabem como é: temos caso de empresas grandes, que não tem como dizer para eles fazer algo... eles fazem quando eles tiverem necessidade, não quando os clientes/fornecedores deles pedem... Vamos comentar aí.. Obrigado.

Régys, obrigado pelo retorno, Porém ainda não está bem claro pra mim quais os registros devem ser inclusos... Você citou que: Blz, no caso eu incluiria os registros R01..R07... Agora, por exemplo, a tabela de Produtos ? Incluo ou não? Pois também estão relacionadas às vendas que ocorreram no caixa.. E os registros de Estoque, que também estão relacionados as vendas ? Poderia citar exatamente quais registros você incluiria? Obrigado.

Pessoal, boa noite, Agora na versão 02.01 do PAF-ECF, todos aqueles arquivos gerados no Menu Fiscal (Estoque / TabProd / Mov Por ECF..) foram juntados num único arquivo "Registros do PAF-ECF" (U1, A2, P2, D2, D3, ... ,R01, R02... ) Blz... ficou bem melhor A pergunta é: quando se tratando de uma Estação usando o PAF-ECF em modo Stand-Alone Off-Line, onde os dados são enviados para um servidor posteriormente, no momento que efetua a Redução Z, diz no REQUISITO XXVI que: Assim como já era antes... O fato é que antes apenas tinhamos os registros R01...R07, que eram realmente gravados pelos movimentos da ECF em questão, mas agora possui também dados dos DAVs, por exemplo, que estão num servidor (e considerando um Caixa que não está ligado ao servidor no momento da Redução Z), como ficaria o atendimento a esse requisito?

Adilson, pois é, Como eu disse, é bem estranho, No meu sistema sempre usamos pela rede, onde os usuários compartilham as pastas na rede, outros mapeiam... enfim, não há uma exigência fixa dessas configurações... e em qualquer caso sempre funciona... A estrutura que usamos é a seguinte: 1. Temos a pasta de nosso sistema no servidor (e essa é a pasta compartilhada) 2. Dentro dessa pasta existe uma pasta "NFe" e dentro dela está o executável que é o módulo de envio de nf-es 3. Dentro dessa pasta NFe tem outra subpasta "Schemas", onde estão os xsd's Então, ao acessar pela rede ficaria assim: \\SERVIDOR\SISTEMA\NFE\SCHEMAS Essa deveria ser a pasta que você seta na Pasta para os Schemas no ACBrNFe. Como te disse, no nosso caso, ao executar o NFe.exe, faço : (onCreate) PastaSchemas := ExtractFilePath(Application.ExeName) + 'Schemas\'; Sendo que executamos o NFe.exe diretamente pela rede (\\SERVIDOR\SISTEMA\NFE\NFe.exe), fazendo com que ao executar ele saiba onde os diretórios estão em relação à rede.

Certo, entendi... Estranho pois a princípio o fato de Mapear a unidade de rede não muda nada. Mapeada ou direto via pasta UNC (\\server\...) deveria funcionar igual. Uma coisa que pode ocorrer é na questão dos direitos do usuário de acesso a pasta da rede, que as vezes se comporta um pouco diferente quando unidade mapeada e quando direto por UNC... isso porque quando mapeada o Windows tem um recurso que já salva credenciais do usuário de acesso. Talvez pode ser isso que esteja acontecendo.. verifique se você consegue acessar diretamente via Iniciar>Executar a pasta UNC \\server...

Michel, bom dia, Já estou utilizando o ACBrNFe com versão 3.10 então segue as dicas: Para que ele opere na versão 3.10 você tem que setar as propriedades: ACBrNFe.Configuracoes.Geral.ModeloDF := moNFe; ACBrNFe.Configuracoes.Geral.VersaoDF := ve310; E então, sim, as validações da Versão 3.10 já estão em vigor, inclusive exigindo alguns campos a mais que na versão 2.00 não tinha (por exemplo especificar a Presença do Comprador na nota)

Bom dia, Acho que se você usar a função NotasFiscais.LoadFromFile(Arquivo, FALSE{GerarNFe}); irá resolver seu problema. Pois a função LoadFromFile tem o parâmetro AGerarNFe que é padrão True, ou seja, sempre que carregar um XML ele reconstroi o XML, que é o que você não quer que aconteça, mantendo assim seu XML original.

Se você usar pasta Schemas local daí não ocorre esse erro?

Blz, André, consegui resolver... Retirei da unit ACBrNFeUtil a função : class function NotaUtil.GetURLQRCode E então tudo funcionando ! Obrigado

Lincoln D, Vou te falar algumas experiencias que tenho aqui com Canvas / Thread, e então veja se te ajuda... Notei que você mencionou 3 coisas importantes: 1. Máquina Virtual 2. Thread 3. RaveCB com Canvas Ou seja, se pode partir do princípio que, ao executar um método em Thread em uma máquina virtual, o resultado esperado pode realmente ser diferente do que ao executar em um Console de PC normal, pois as Thread's são executadas em vários níveis diferentes no processador (e então quando em máquina virtual, onde esses níveis são emulados, o resultado pode ser outro). Resumindo, eu também já tive problema parecido, retornando o mesmo erro, quando pintando com Canvas dentro de Threads... A solução encontrada na ocasião foi utilizar os métodos Lock e Unlock do Canvas para que a Thread não perdesse o controle do Canvas. Em suma ficou tudo funcionando perfeitamente, no meu caso, quando TODOS OS MÉTODOS do Canvas estavam protegidos dessa maneira: procedure TThreadTeste.Execute; var C: TCanvas; begin ... C.Lock; try C.Draw.... C.TextOut.... ... finally C.Unlock; end; end;

Blz, André, entendi.. Você poderia me instruir em que UNIT ocorre essa linkagem/chamada para que eu tire aqui no meu pacote para eu não ter esse problema aqui (visto que por enquanto não uso NFC-e) ? Muito obrigado.

RobertoSchuster, Importante lembrar que: agora quando você usa no modo versão 3.10 no componente, internamente ele trabalha um pouquinho diferente da versão 2.00, ou seja: - Versão 2.00: quando você usa o comando Enviar, ele te retorna um RAISE se ocorrer algum problema depois de ler o retorno quando cStat não é de Autorizado (100,...) - Versão 3.10: já nessa versão, quando você usa o Enviar, mesmo que haja erro (retorno diferente de cStat=100), não irá ocorrer um RAISE, então você precisa tratar isso em sua aplicação: Exemplo ACBrNFe.Enviar(.... , ..., True{Sincrono}); if W.WebServices.Enviar.cStat<>100 then {Tratamento para nota não autorizada}; //senão ficará em branco

Pessoal, boa tarde, Agora nas últimas versões postadas no SVN começou a acontecer esse problema: Se eu criar uma aplicação simples e simplesmente colocar o componente TACBrNFe e rodar, vai dar um erro dizendo que Falta a DLL "libeay32.dll" OK, se eu colocar essa DLL no sistema ou na pasta da aplicação funciona... O fato é que, antes não era necessária a DLL quando não utilizava os recursos requeridos (por exemplo Assinatura, SSL... envio de email, etc...) Exemplo, se eu quiser apenas usar o componente ACBrNFe para abrir a estrutura do uma NF-e (xml), antes eu não precisava ter a libeay32.dll na maquina. Agora parece que só para rodar o EXE mesmo sem usar nenhuma função, é necessário a DLL. Outra observação: se eu fizer o mesmo esquema com o ACBrCTe, daí não acontece esse problema, ou seja, só pede a DLL quando eu realmente vou usar (enviar CT-e por exemplo - assinatura digital) Digo tudo isso pois uso em nosso sistema o componente do ACBrNFe em vários módulos nossos que apenas para leitura de XML, por exemplo, então não uso a DLL do libeay32.dll Sabem se algo mudou nesse sentido? Obrigado.

Nós temos dentro da pasta da aplicação da NF-e uma sub-pasta chamada "Schemas" Ao abrir o aplicativo, usamos a função ExtractFilePath(Application.ExeName) para pegar o diretório da aplicação e então a pasta dos Schemas é Appdir+'Schemas\' Assim você poderá utilizar a pasta Schemas em seu programa apenas no servidor, não precisando copiar em cada estação.

OK, André e Italo, agora funcionou com suas atualizações enviadas ontem... Obrigado.

Utilizamos Capicom, mas penso que a parte da Validação dos Schemas não tem relacionamento com a Assinatura Digital (Essa sim usaria ou Capicom ou OpenSSL)

Realmente, André, acho que é o mesmo problema que estou tendo com a NF-e 3.10 usando método Síncrono que começou a ocorrer hoje depois das alterações.. veja o meu tópico:

Sim, nós utilizamos em nosso sistema dessa forma, sempre acessando os Schemas de uma pasta compartilhada do Servidor. Funciona normalmente.

Italo, boa tarde, Depois da sua atualização 6584 referente a melhoria dos Retornos na NF-e... está retornando, pelo menos no Envio de NF-e 3.10 Síncrono, a propriedade Msg em branco Sendo assim está retornando um RAISE em branco quando nota rejeitada... if not(Self.Enviar.Executar) then begin if Assigned(TACBrNFe( FACBrNFe ).OnGerarLog) then TACBrNFe( FACBrNFe ).OnGerarLog(Self.Enviar.Msg); raise EACBrNFeException.Create(Self.Enviar.Msg); end; A propriedade Self.Enviar.Msg está vindo agora sempre em branco... Algo que precisamos alterar antes de enviar?

OK, Juliomar, tranquilo Revisao 6571 baixada... código compilado, funcionou tudo OK ! Obrigado.

OK, Juliomar, Só faltou colocar a USES "DateUtils" nos dois Retrato/Paisagem por causa do TimeOf Outra coisa: na unit ACBrDANFeCBRaveRetrato, faltou uma variável "vSaiEnt: String" Fazendo essas alterações funcionou corretamente!

Então, na verdade o Juliomar fez os ajustes nos fontes do ACBr RaveCodeBase, pois o RaveCodeBase é todo gerado por código. Agora no FastReport nunca vi o código / layout, por tanto não sei te dizer exatamente onde que está o código que lê essa variável, ou se é direto na formatação do arquivo do layout do FastReport... Se você olhar nesse tópico onde solicito os ajustes do RaveCodeBase você vai entender melhor:

Amigo, bom dia, Esse problema está acontecendo pelo seguinte: Na versão 3.10 da NF-e, os campos dSaiEnt e hSaiEnt foram eliminados, e agora existe um campo chamado dhSaiEnt do tipo DateTime para comportar os dois dados (Data e Hora) No ACBrNFe foi mantido o nome do campo como dSaiEnt para compatibilidade (mas veja que agora ele é do tipo TDateTime, contendo os dois dados - Data e Hora) Porém, no seu componente da DANFe, está lendo ainda do campo antigo hSaiEnt - por isso que se você setar nessa variável hSaiEnt algum valor, ao visualizar a DANFe aparece essa hora como se estivesse certo. Porém, na segunda vez que você gera a DANFe, está carregando o XML versão 3.10 de um arquivo, onde a tag hSaiEnt não existe mais, por isso nessa vez o valor vem zerado - como é de se esperar pois esse campo apenas para versão 2.00 Mesmo caso que tive com o RaveCodeBase... provavelmente apenas algum ajuste necessário a se fazer na geração da DANFe para quando versão 3.10 ler a hora do campo dhSaiEnt (dSaiEnt no ACBrNFe)... (no seu caso no FastReport)

Juliomar, bom dia, Deu erro na linha 667 do ACBrDANFeCBRavePaisagem: if infNFe.versao = '2.00' then [dcc32 Error] ACBrDANFeCBRavePaisagem.pas(667): E2010 Incompatible types: 'string' and 'Real' Além disso, a variável "dhSaiEnt" foi mantida no ACBr por "dSaiEnt" para compatibilidade do componente. Outra coisa que pode ocorrer é que podemos enviar nota com Data porém com hora zerada, por isso poderia fazer um TimeOf para verificar só a parte da hora. Sugestão: if infNFe.versao = 2.00 then vSaiEnt := ifthen(ide.hSaiEnt = 0, '', TimeToStr(ide.hSaiEnt)) else vSaiEnt := ifthen(TimeOf(ide.dSaiEnt)=0, '', TimeToStr(ide.dSaiEnt)); (as mesmas considerações para ACBrDANFeCBRaveRetrato) Obrigado.