bruno_fuhr

Peço desculpas pelo meu equívoco, mas foi justamente por este tipo de erro que pedi auxílio.

pnfsConversao: Função: NaturezaOperacaoDescricao. Incluída a descrição das naturezas 51, 58, 61, 62, 63, 64, 68, 78 e 79 pnfsConversao.pas ACBrNFSeDAMDFeFR: Adicionados Fields: FSelecionaNomeArquivoPDF e FNomeArquivoPDF. Adicionadas properties: SelecionaNomeArquivo e NomeArquivoPDF. Ajustas as funções PrepareReport e PrepareReportEvento, para verificar se o programador deseja selecionar o nome e se desejar, colocar o nome na propriedade. ACBrMDFeDAMDFEFR.pas ACBrNFSeDANFSeFR: Adicionados Fields: FSelecionaNomeArquivoPDF e FNomeArquivoPDF. Adicionadas properties: SelecionaNomeArquivo e NomeArquivoPDF. Ajustada a função PrepareReport, para verificar se o programador deseja selecionar o nome e se desejar, colocar o nome na propriedade. ACBrNFSeDANFSeFR.pas ACBrNFSeDANFeFR: Adicionados Fields: FSelecionaNomeArquivoPDF e FNomeArquivoPDF. Adicionadas properties: SelecionaNomeArquivo e NomeArquivoPDF. Ajustas as funções PrepareReport, PrepareReportEvento e PrepareReportInutilização para verificar se o programador deseja selecionar o nome e se desejar, colocar o nome na propriedade. ACBrNFeDANFEFR.pas

Boa tarde. Existe alguma unit do ACBr que me permita enviar como parâmetro o código do CNAE e como retorno eu receba a descrição do código? Grato.

Alguém consegue me ajudar, @Juliomar Marchetti, @Italo Jurisato Junior

Boa tarde. Primeiramente peço desculpas por estar criando uma dúvida no ACBrNFe, sendo que esta se refere também ao ACBrMDFe e ACBrNFSe. Estou migrando o ACBr para o trunk2 e com isto perdi algumas coisas que havia implementado nas classes do ACBr, mas não enviado por conta de o ACBr já estar no trunk2. As minhas implementações se referiam ao nome do arquivo que sai para a impressão nas impressoras, nelas, eu alterava o nome do arquivo, para que ficasse igual a chave da NFe, MDFe ou NFSe. Eu apenas colocava a chave na propriedade do impressor de Danfe, Damdfe e danfse respectivo "frxReport.ReportOptions.Name" e a chave era encaminhada corretamente. Lembrando que esta implementação acontecia nas classes ACBrNFeDANFEFR, ACBrMDFeDAMDFeFR e ACBrNFeDANFEFR e não na minha aplicação. Fazemos isto porque a emissão das notas é feita a partir de um serviço que desenvolvemos usando o ACBr e os PDFs são salvos em uma pasta por meio de uma impressora PDF com o nome sendo a chave do DFe. Como já disse, eu perdi o que eu já havia implementado anteriormente e agora, com o trunk2, não gostaria de vir a mexer nos fontes do ACBr por receio de gerar problemas, ou de despadronizar algo, mas fazendo por fora, ou seja, usando a linha de código "TACBrMDFeDAMDFEFR(vAcbr.DAMDFE).frxReport.ReportOptions.Name" não está funcionando. Isto acontece porque quando eu chamo o método "vAcbr.Manifestos.Items[0].Imprimir;", por exemplo, dentro do ACBr, em cada classe respectiva do DFe, é executado o método "PrepareReport(MDFe)" e este, por sua vez, chama o método "LoadFromFile"/"LoadFromString", do fastreport, que acaba substituindo a propriedade que eu havia preenchido por uma propriedade presente no fr3 fastReport. Eu tentei achar no fastreport como preencher a propriedade, mas não encontrei como. Caso alguém saiba, é lá no menu (na tela de edição do layout da impressão do dfe) "Relatório > Opções", aba "Descrição", campo "Nome". Queria saber se algum dos moderadores pode me auxiliar a desenvolver, no acbr, alguma forma pra fazer eu poder personalizar o nome. Eu havia pensado, em nas classes de impressão do ACBR que usam o FastReport, criar uma propriedade boolean em que o usuário informa se deseja personalizar o nome e uma propriedade com o nome personalizado.

Bom dia. Estou com um problema, ando em testes para a Nota Fiscal de Serviço de Caxias do Sul e em meu sistema armazeno o xml de protocolo no banco de dados, para isto, estamos usando o atributo XML_NFSe, acontece que para o provedor da Infisc sempre está vazio. Alguém já obteve este mesmo problema? Att., Bruno A. Führ

Obs. A situação que informa o aguardo de processamento para a Infisc é a 217. Alterei isto na função LerXML_provedorInfisc. Unit pnfsConsSitLoteRpsResposta

Entendi, é, o erro, ao que eu vi na imagem que tu postou é igual, mas os motivos podem ser diferentes. Eu estava com o seguinte problema. Utilizo a função Enviar, para outros provedores, acontece que para o provedor da Infisc, a situação de retorno não era tratada corretamente, fazendo com que o acbr encontrasse um erro desconhecido. A situação que informa o aguardo de processamento para a Infisc é a 217. Caso tenhas esta situação já possui esta dica.

Bom dia! Moro, Estou usando o provedor da Infisc, correspondente a Caxias do Sul. Andei buscando onde o ACBr faz este erro. Encontrei o seguinte. Na unit ACBRNFSeWebServices, existem os métodos DoNFSeEnviarLoteRPS e DoNFSeEnviarSincrono. O primeiro é chamado pelo método Enviar, que gera envio correto ao provedor da Infisc, porém por não ser sincrono, entende que ocorrem erros, quando na verdade isto não ocorre. O segundo, é chamado pelo método EnviarSincrono, que é o que tu também está utilizando e que gera o XML incorreto, causando erro de validação. No método DoNFSeEnviarLoteRPS, por volta da linha 991, existe a seguinte linha de código: if FConfiguracoes.Certificados.AssinaRPS then dentro disto, o ACBr verifica qual provedor está sendo utilizado, e um deles é o da Infisc, que possui um tratamento diferente, o mesmo ocorre no else deste if, acontece que para o método DONFSeEnviarSincrono, este tratamento especial para a Infisc não está ocorrendo. Incluí o tratamento especial para o provedor da Infisc, constante na próxima linha, ainda obtive erros no xml gerado. Anexarei o xml que consegui gerar, como também o fonte após minha alteração para que tu teste. ACBrNFSeWebServices.pas xml_infisc_sincrono.xml

Outra coisa. Não busquei ver em quais pontos acontece, mas quando o ACBr chama a função AssinarMSXML, faz uma verificação buscando saber se o xml (da variável AXML) é válido (acredito eu). O que notei, é que quando utilizo a função Enviar, neste ponto, o XML já está "pronto", ou seja, com todas as informações da nota. Quando é utilizada a função EnviarSincrono, no momento em que a validade do XML é verificada, só existem as tags da assinatura e a tag de encerramento </envioNFSe>. Em anexo variável AXML no ponto de verificação nos métodos Enviar e EnviarSincrono. É visível que existe o encerramento de uma tag, não sei informar se isto deve ser assim. Att. XML_FUNC_EnviarSincrono.xml XML_Func_Enviar.xml

Boa tarde, Ontem pela tarde eu havia deixado meu ACBr exatamente assim. Utilizando a função Enviar, eu consegui fazer com que a nota fosse emitida com sucesso, porém obtive outro problema. O xml com a situação do protocolo que a Infisc retorna, de início, vem com a tag sit com o valor 217, que o ACBr não interpreta. Porém esta situação informa que o arquivo ainda não foi processado. Como o ACBr não interpreta, ele lança uma exception. OBS: quando busquei utilizar o EnviarSincrono, obtive o mesmo erro que o Moro enviou como imagem.