Italo Giurizzato Junior

Bom dia Marcelo, O Certificado é valido, ou seja, não esta vencido?

Bom dia, Se eu entendi, através do programa exemplo do componente ACBrNFSe funciona 100%, ou seja, o Web Service processa com sucesso o RPS que é enviado e retorna o XML da NFS-e. Por outro lado através da sua aplicação o RPS é rejeitado pelo Web Services acusando que a alíquota é invalida. Se é isso, por favor compare o XML do RPS gerado através do programa exemplo, com o da sua aplicação. Detalhe importante, compare o valor de todas as TAGs de ambos os XMLs.

Bom dia, Você esta salvando o XML em disco ou esta pegando o mesmo de uma propriedade para salvar no banco de dados? Se esta pegando de uma propriedade, qual é?

Bom dia Otair, Pelo XML *-con-dis-dfe.xml notei que você esta consultando um NSU especifico, ou seja você esta atribuindo uma string diferente de vazio para o quarto parâmetro do método DistribuicaoDFe. Por favor leia o Manual do componente ACBrNFe que encontra-se disponível na pasta: ...\Doctos\Manuais

Bom dia Jorge, Para aparecer essa mensagem de erro, o conteúdo da propriedade Servico tem que estar vazia. Abra a unit ACBrNFeWebServices e procure por: procedure TNFeStatusServico.DefinirServicoEAction; essa procedure define o conteúdo das propriedades Servico e SoapAction. Se você notar algo estranho, favor excluir essa unit e baixar novamente usando o Toroise, depois compile a aplicação com a opção Build e teste novamente.

Bom dia Luis, Exatamente, mas no Manual versão 2.00a do CT-e disponibilizado no Portal Nacional do CT-e encontra-se uma tabela dos campos impedidos de serem alterados por uma CC-e. O campo vCarga não consta dessa tabela, sendo assim podemos alterar.

Boa tarde Geazi, Verifica a sua rotina, pois nada foi alterado com relação a geração dessa TAG. Será que você não esta atribuindo uma string vazia a essa propriedade em outro ponto da sua rotina que alimenta o componente ou fora dela antes de gerar o XML?

Boa tarde, Isso é estranho pois só aparece apenas uma vez o LayNFeEventoAN na function GetURL sendo assim não deveria alterar a URL. Você esta com todos os fontes de todas as pastas atualizados?

Boa tarde Marcelo, Você precisa instalar o componente ACBrNFeDANFEQR desta forma você vai poder optar por continuar a usar o Rave ou mudar para o Quick Report para imprimir o DANFE e terá condições de imprimir o evento da NF-e como você faz no MDF-e alem de poder gerar o PDF.

Boa tarde Carlos, No meu entendimento, temos que desenvolver componentes que estejam em conformidade com os manuais e notas técnicas. E não ficar adicionando linhas para poder ler arquivos gerados por outros sistemas, arquivos estes com erros como este apresentado por você. O seu cliente deveria entrar em contato com o emitente da NF-e e relatar o problema.

Boa tarde Leonardo, Se você levar em consideração ao XML que foi postado pelo nosso amigo Alex, não se trata de um XML de NF-e e sim de um retorno de download. E a versão do XML de download é 1.00 Sei que dentro deste contem o XML da NF-e cuja versão é 3.10, mas entenda que o LoadFromFile foi criado para ler o XML de uma NF-e e não de um retorno de download. A aplicação que gerou esse arquivo deveria extrair a NF-e do retorno e salva-la em disco com o nome: <chave>-nfe.xml Como ela não faz, apresentei acima uma pequena rotina implementada no ACBrNFe que faz o serviço, só não coloquei a linha para salvar em disco o XML da NF-e.

Boa tarde Jeferson, Em offline você não envia nada, apenas gera o XML assina e imprimi o DANFE. Quando os problemas forem sanados ai sim o XML assinado é enviado. Por favor na Nota Técnica 2013/005 versão 1.22 você encontra quais os campos devem ser alterados para gerar o XML com o tipo de emissão Offline.

Boa tarde Ramalho, Você esta utilizando os fontes do trunk ou trunk2? Pois o XML que você postou esta muito estranho. Você utiliza o componente para gerar o XML ou apenas para enviar?

Ok, vamos aguardar.

Bom dia Michel, Ficou faltando os Schemas.

ALA, A mensagem é clara, o emitente (prestador do serviço) tem que entrar em contato com o provedor e solicitar a liberação para que o mesmo possa emitir NFS-e usando o Web Services.

Bom dia Marcelo, Precisamos das URLs de homologação e de produção da respectiva cidade usada no provedor Fiorilli. Sem essas informações não temos como fazer essa alteração.

Bom dia Felix, Primeiramente, você postou no fórum errado, aqui estamos tratando sobre assuntos específicos sobre o componente ACBrNFSe. Post no fórum Diversos. Outra coisa para consumir um Web Services é necessário possuir um certificado valido, ou seja, não pode estar vencido.

Bom dia Leo, Sim, você tem os métodos: ConsultarSituacao e ConsultarLoteRps. Abra a unit ACBrNFSe para saber os parâmetros de cada um.

Bom dia ALA, Se tratando de um provedor que já esta implementado, basta você acrescentar a cidade desejada na unit pnfsConversao e ACBrProvedorxxxxx onde xxxx é nome do provedor no caso o GovDigital.

Bom dia Rigoti, Muito obrigado pela colaboração, já esta disponível.

Bom dia Delfino, Por favor atualize os fontes e teste novamente.

Bom dia Wagner, Você deve usar somente o método Enviar, pois este é capaz de gerar o XML, assinar se necessário, montar o lote, assinar o lote se necessário, validar o lote e enviar para o web services.

Bom dia a todos, Na verdade o que Otimizy se refere é um outro código chamado CodigoTributacaoMunicipio, o que é padronizado (pelo menos deveria ser) é o código ItemListaServico. É o ItemListaServico que o componente trabalha com duas tabelas, uma interna e outra externa gravada em disco com o nome TabServicos.TXT e usamos a propriedade TabServicosExt para determinar qual das duas ele vai buscar a descrição para ser impressa no DANFSE. No DANFSE é impresso o ItemListaServico + CodigoTributacaoMunicipio + descrição do ItemListaServico em um quadro abaixo do quadro "Discriminação dos Serviços".

Bom dia Micheli, Tudo o que você sabe sobre NF-e não se aplica na NFS-e. Na NF-e o componente gera o XML da nota, assina, valida e é enviado para SEFAZ, esta recebe, processa e se estiver tudo OK retorna o protocolo de autorização, protocolo este que é anexado ao XML assinado, desta forma o XML final fica assinado e protocolado, ou seja, temos ai um arquivo XML com validade jurídica. Na NFS-e o componente gera o XML do RPS - Recibo Provisório de Serviço, assina (depende do provedor), monta o lote de envio, assina o lote (depende do provedor), valida o lote, envia para o web services do provedor, este recebe, processa e se estiver tudo OK retorna o XML da NFS-e (normalmente sem assinatura). Como você pode ver a coisa funciona totalmente diferente. No ACBrNFSe temos: a pasta RPS onde são gravados os XMLs (assinados ou não) dos RPS, a pasta Ger (geral) onde são gravados os arquivos de envio e de retorno, o arquivo que você faz referencia fica gravado nesta pasta e a pasta NFSe onde são gravados os XMLs das notas. Se não me falha a memória a linha abaixo retorna uma string que contem o XML do RPS: xRPS := ACBrNFse1.NotasFiscais.Items[0].XML; Por outro lado a linha abaixo retorna uma string contendo o XML da NFS-e: xNFSe := ACBrNFse1.NotasFiscais.Items[0].XML_NFSe;