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!

Bom dia Italo, tudo certo? Então, conferi os Schemas do ACBR, tentei transmitir um MDF-e com a nova tag, e deu tudo certo. Peço desculpas por isso. Até atualizo com frequência os componentes, bem como Schemas e exemplos, mas provavelmente fiz algo de errado na hora de copiar os Schemas para a pasta de compilação... Mesmo assim obrigado pela ajuda.

Boa tarde. Verifiquei hoje que há Schemas desatualizados no MDF-e, pois não consegui transmitir um MDF-e com a nova tag infRespTec, da NT 2018 002. Encaminho em anexo os Schemas que baixei do link https://mdfe-portal.sefaz.rs.gov.br/site/Documentos#. Se puderem atualizar os Schemas no ACBR, fico muito grato. PL_MDFe_300_NT022018.zip

Muito obrigado Juliomar, de verdade me ajudou.

Bom dia @Juliomar Marchetti, tudo bem? Peço desculpas pelo erro, realmente, ao salvar o arquivo DACTE.fr3 depois de alterá-lo no FastReport, ocorriam aquelas alterações do BarCode e da versão do FastReport, sem que eu percebesse. Agora estou enviando um novo arquivo DACTE_corrigido.fr3, onde fiz somente alterações referentes às posições e alinhamentos dos campos, nada mais. Se puder avaliar novamente essa questão, agradeço muito. Obrigado e bom dia.

Boa tarde, alguém poderia me dar uma ajuda com este problema de alinhamento dos campos? Tenho clientes que estão me cobrando em relação ao CT-e impresso... Agradeço muito.

Boa tarde @Juliomar Marchetti Juliomar, fiz conforme você pediu, atualizei o SVN, e abri o arquivo DACTE.fr3 no FastReport para conferir, e está conforme a imagem abaixo: Lembrando que este é o arquivo ORIGINAL, do SVN ATUALIZADO... Peço novamente para que dê uma olhada nessa situação, é realmente importante. Agradeço pela compreensão.

Bom dia @Juliomar Marchetti, tudo certo? Então, na verdade o meu arquivo DACTE.fr3 está atualizado conforme o SVN, foi com este arquivo atualizado que imprimi o documento da foto postada anteriormente. Peço que confira, na imagem abaixo, como estão os campos de documentos anteriores do arquivo DACTE.fr3 no SVN: O alinhamento do texto dos campos está como alinhado ao topo, e os campos estão posicionados junto à faixa amarelada "MasterData", conforme as setas indicam... Tudo o que fiz foi alinhar o texto dos campos ao centro, e move-los, para baixo, próximo à linha inferior, como indicam as setas... Veja que, em todo o arquivo, modifiquei apenas estes campos de baixo, não mudando nada nos do Nome ou CNPJ acima desses por exemplo... Peço, por favor, que reveja mais uma vez a situação do arquivo que está no SVN atualmente. Agradeço pela atenção.

Boa tarde Juliomar, tudo bem? Peço que dê uma olhada na foto que tirei da impressão de um DACTE, usando o arquivo DACTE.fr3 original da ACBR (com o erro). Os campos dos dados dos documentos anteriores estão sinalizados em vermelho para melhor identificação. As informações estão sendo cortadas na hora da impressão, embora não seja perceptível no PDF...

Boa tarde. Percebi um erro no DACTE gerado à partir de um CT-e com Documentos Anteriores referenciados (docAnt), onde o arquivo DACTE.fr3 estava configurado para gerar arquivos com os campos das informações dos documentos anteriores bastante desalinhadas, como na imagem abaixo: Então fiz algumas modificações (modifiquei apenas o alinhamento e a posição destes campos), e funcionou, agora está gerando DACTE's como abaixo: Estou enviando em anexo o arquivo DACTE.fr3 corrigido, como sugestão de melhoria ao ACBR. Espero estar ajudando, agradeço a atenção. Um ótimo fim de tarde.