Lucas Martendal

Testado com sucesso @BigWings. Agradeço pelo apoio. Vlw! (Pode fechar esse tópico)

Boa tarde. Desculpe @BigWings, eu citei o EMBarbosa no meu comentário anterior, mas acabei me confundindo (porque o Daniel Simões citou ele), era pra ter citado você, em continuidade com a sua análise. Você pode verificar as alterações que fiz no código do último comentário, por favor? Creio estar pronto agora, mas também aceito novas sugestões... Agradeço desde já.

Bom dia pessoal, agradeço o rápido retorno. Entendo @EMBarbosa, agradeço a correção. Que tal dessa forma abaixo? case StrToInt(copy(aChave, 23, 3)) of // Séries (000-889) reservadas para NF-e eCNPJ emitida por aplicativo da Empresa Emitente 000..889, // Séries (890-899) reservadas para NFA-e eCNPJ da SEFAZ emitida no Site do Fisco 890..899, // Séries (900-909) reservadas para NFA-e eCNPJ emitida no Site do Fisco 900..909: result := ValidarCNPJ(copy(aChave, 7, 14)); // Séries (910-919) reservadas para NFA-e eCPF emitida no Site do Fisco 910..919, // Séries (920-969) reservadas para NF-e eCPF emitida por aplicativo da Empresa Emitente 920..969: result := ValidarCPF(copy(aChave, 10, 11)); else // Outras possíveis Séries futuras result := ValidarCNPJ(copy(aChave, 7, 14)) or ValidarCPF(copy(aChave, 10, 11)); end; As alterações já estão em anexo... pcnAuxiliar#new_v2.pas

Boa tarde. Um cliente meu está tentando importar uma NF-e de Produtor Rural Modelo 55, e ela foi emitida por um Produtor que usa CPF (CPF na chave da Nota), usando uma Série na faixa 910 à 919. Eu estou usando a seguinte função para validar a Chave dessa Nota: ValidarChave(const chave: string) Essa função está na Unit ACBR\Fontes\PCNComum\pcnAuxiliar.pas. Mas ela está retornando o valor falso, invalidando a chave da Nota, quando na verdade eu verifiquei a chave na consulta NF-e do portal da SEFAZ, e está emitida corretamente, portanto a chave é válida. Nessa função há um trecho de código que faz a validação da chave da Nota tratando como um CNPJ ou CPF dependendo da Série utilizada, onde somente trata como CPF se estiver usando uma Série entre 920 e 969, conforme segue: case StrToInt(copy(aChave, 23, 3)) of // serie reservada para DFe eCPF emitida por aplicativo da Empresa Emitente 920..969: result := ValidarCPF(copy(aChave, 10, 11)); else // serie (001-889) reservada para DFe eCNPJ result := ValidarCNPJ(copy(aChave, 7, 14)); end; Verificando a Documentação da NF-e, eu constatei o seguinte tratamento: Faixa Emissor Identificador Assinatura procEmi 000-889 Aplicativo do Contribuinte (NFe) CNPJ e-CNPJ do contribuinte 0 ou 3 890-899 Site do Fisco (NFA-e) CNPJ / CPF e-CNPJ da Sefaz 1 900-909 Site do Fisco (NFA-e) CNPJ e-CNPJ da Sefaz ou e-CNPJ do contribuinte 1 ou 2 910-919 Site do Fisco (NFA-e) CPF e-CNPJ da Sefaz ou e-CPF do contribuinte 1 ou 2 920-969 Aplicativo do Contribuinte (NFe) CPF e-CPF do contribuinte 0 ou 3 (No caso, o meu cliente se encaixa na penúltima linha, Série da faixa 910 à 919, NFA-e Modelo 55 emitida por um CPF). Portanto eu fiz alterações nessa parte do código, ficando da seguinte forma: case StrToInt(copy(aChave, 23, 3)) of // Séries (000-889) reservadas para NF-e eCNPJ emitida por aplicativo da Empresa Emitente 000..889, // Séries (900-909) reservadas para NFA-e eCNPJ emitida no Site do Fisco 900..909: result := ValidarCNPJ(copy(aChave, 7, 14)); // Séries (910-919) reservadas para NFA-e eCPF emitida no Site do Fisco 910..919, // Séries (920-969) reservadas para NF-e eCPF emitida por aplicativo da Empresa Emitente 920..969: result := ValidarCPF(copy(aChave, 10, 11)); else // Séries (890-899) reservadas para NFA-e eCNPJ ou eCPF emitida no Site do Fisco, e outras possíveis Séries futuras result := ValidarCNPJ(copy(aChave, 7, 14)) or ValidarCPF(copy(aChave, 10, 11)); end; O arquivo atualizado com as alterações que fiz segue em anexo nesse post. Favor verificar e aprovar a alteração se possível. Aceito sugestões de melhoria. Agradeço desde já. Vlw! pcnAuxiliar#new.pas

Bom dia Italo, tudo certo? Agora sim cara, muito obrigado pelo apoio! Pode fechar o tópico, vlw.

Bom dia Italo, tudo tranquilo por aí? Italo, será que você poderia por favor subir para o repositório esse arquivo que você alterou e anexou no post? Eu agradeço muito Italo, vlw mesmo pela ajuda aqui no post. Fico no aguardo, tmj!

Boa tarde @Italo Jurisato Junior, tudo bem? Italo, poderia por favor subir o arquivo para produção, para que eu possa atualizar os fontes e liberar versão do meu sistema? Eu agradeço Italo. Vlw, t+.

Bom dia @Italo Jurisato Junior. Italo, acabei de testar, e está tudo certinho, importando todos os produtos. Pode subir. Muito obrigado pela ajuda!

Isso aí @Waldir Paim, agradeço muito por ter atualizado. Vlw mesmo pessoal, pelo apoio

Bom dia pessoal do ACBr, tudo bem? Pessoal, devido à esse problemas que eu e outras pessoas, como meu amigo Leandro Vignoto, estávamos enfrentando, eu resolvi fazer uma alteração nos fontes do ACBr, no arquivo pcnNFeR.pas, que está em anexo, para que a leitura do XML da Nota Fiscal considere os dois tipos de tag escritas, tanto a forma normal ('<det nItem="1">') quanto a forma que estava com problemas, onde os produtos não eram lidos ('<det xmlns="http://www.portalfiscal.inf.br/nfe" nItem="1">'). Assim, todos os XML's podem ser carregados normalmente. Peço que analisem e, se puderem considerar minhas alterações, eu agradeço muito, isso resolve muitos problemas nossos. Desde já muito obrigado. Fico no aguardo, vlw. pcnNFeR.pas

Bom dia Kiko, na verdade, originalmente ele não é identado, eu apenas usei uma ferramente para identar ele, para facilitar. Mas, como você disse, não faz diferença... Se precisar do XML original, está em anexo. Pois então Leandro, esse XML está autorizado e correto, de acordo com a própria SEFAZ, como você mencionou... Você pode me dizer como resolveu o seu problema mencionado no seu tópico? Alguém pode me ajudar com relação a isso? Como faço para o LoadFromString do ACBrNFe ler os produtos de XML's como esse? 42181107715282000152550020001727041123456780.xml

Bom dia, tudo bem? Estou com um problema na importação/leitura de um XLM de uma NF-e, de um fornecedor específico, onde o LoadFromFile do TACBrNFe não consegue ler os produtos na nota fiscal. Isso só acontece com as notas desse fornecedor específico. Se editarmos o XML da nota, retirando o atributo 'xmlns' (xmlns="http://www.portalfiscal.inf.br/nfe") da tag 'det' (que envolve a tag dos produtos - det xmlns="http://www.portalfiscal.inf.br/nfe" nItem="1"), só então os produtos são lidos corretamente pelo ACBr. Em anexo envio um XML de exemplo que não funciona. Se quiser testar, pode retirar o 'xmlns="http://www.portalfiscal.inf.br/nfe"' da tag '<det xmlns="http://www.portalfiscal.inf.br/nfe" nItem="1">', deixando apenas '<det nItem="1">' que vai importar normalmente. Desde já agradeço pela ajuda. Vlw. NotaComProblemas.xml

Bom dia @Italo Jurisato Junior, Blz então, vou trocar os arquivos em produção. Mais uma vez obrigado pela ajuda, um ótimo dia.

Boa tarde Italo, td certo? Ok, só pra confirmar então, nós podemos renomear o arquivo "tiposGeralMDFe_v3.00-OPENSSL.xsd" para "tiposGeralMDFe_v3.00.xsd" (substituindo o anterior), que de certeza não vai haver nenhum problema na transmissão dos MDF-e's, tanto utilizando xsXmlSec quanto xsMsXml, certo? Quero ter certeza antes de lançar em produção... Já agradeço a atenção.

Boa tarde, tudo bem? Estou com problemas na transmissão do MDF-e, onde o erro "1824 - Element '{http://www.portalfiscal.inf.br/mdfe}cInt': '17' is not a valid value of the local atomic type." é retornado. Em resumo, sempre que o campo 'cInt', que representa o 'Código interno do veículo', tem exatamente 2 caracteres, esse erro é retornado. Em nosso sistema, usamos dois tipos de DLLs: As do tipo OpenSSL, através da biblioteca xsXmlSec, para certificados apontados de arquivos, e as do tipo MSXML5, através da biblioteca xsMsXml, para certificados instalados. O usuário define a melhor opção. Realizei vários testes alternando entre essas duas opções, e renomeando os Schemas do MDFe, e após os testes percebi que somente quando usado o OpenSSL com os Schemas conforme vêm no ACBr (usando o arquivo 'tiposGeralMDFe_v3.00.xsd' por padrão) é que acontece esse erro, mas se usado o MsXml, esse erro não ocorre, e ao renomear os arquivos para usar sempre o arquivo 'tiposGeralMDFe_v3.00-OPENSSL.xsd', o erro não ocorre em nenhum dos dois tipos de transmissão. Ao comparar esse dois Schemas, vi que a única diferença entre eles está na linha 565: <xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/> (no OpenSSL, ao invés do "{0,}" temos o "*") Gostaria de saber porque existem esses dois arquivos de Schemas, sendo que o 'tiposGeralMDFe_v3.00-OPENSSL.xsd' funciona para os dois casos. Seria para alguma outra biblioteca? Desde já agradeço pela ajuda e compreensão. Valeu!