Italo Giurizzato Junior

Bom noite Willian, Você sabe qual é a empresa (provedor) que a cidade de Cubatão contratou?

Bom noite, Você tem um outro modelo do DANFSE que mostra onde deve ser impresso o código de tributação do município?

Boa noite, Qual é o valor de SSLLib (libCapicom, libWinCrypt, ...) ?

Boa noite Anderson, Tente aumentar o valor da propriedade de configuração Timeout.

Boa noite, A mensagem de erro esta muito estranha, uma vez que chequei com o schema da versão 2 e o XML esta sendo gerado de forma correta. Favor entrar em contato com os responsáveis por recepcionar o GNRE - Bahia e solicite um XML de exemplo.

Boa noite Paulo, Conforme consta no Manual de Layout da NF-e/NFC-e, mais precisamente página 10 a tag dhSaiEnt é opcional, sendo assim se não temos uma data e hora definida para a saída da mercadoria (por exemplo) não devemos informar nada, portanto a tag não deve ser gerada. Fragmento de código do componente responsável por gerar a referida tag: if (nfe.ide.modelo = 55) and (nfe.ide.dSaiEnt <> 0) then Gerador.wCampo(tcStr, 'B10', 'dhSaiEnt', 25, 25, 0, DateTimeTodh(nfe.ide.dSaiEnt) + GetUTC(CodigoParaUF(nfe.ide.cUF), nfe.ide.dSaiEnt), DSC_DSAIENT); A tag dhSaiEnt só deve ser gerada se for NF-e, não devemos gerar ela na NFC-e e como ela é opcional só será gerada caso seja informada uma data/hora ao campo dSaiEnt. O XML que você anexou além de ser da versão 3.10 (que não é mais aceita pela SEFAZ) traz uma data/hora zerada na tag dhSaiEnt, que no meu entendimento esta errado. Repito se não temos uma data/hora de saída não devemos gerar a tag. Só vou poder aceita a sua contribuição caso você apresente um XML da versão 4.00 com data recente que tenha sido autorizado pela SEFAZ cuja data/hora de saída esteja toda zerada. Espero que você compreenda a minha posição.

Boa noite Henrique, Alteração desfeita.

Bom dia, O Expedidor e Recebedor são outras transportadoras envolvidas no transporte da mercadoria, ou seja, Redespacho ou Redespacho Intermediario. Se o tomador não é o Remetente e nem o Destinatário, devemos informar que o tomador é outros e preencher os seus dados no grupo toma4. Visite a nossa biblioteca de documentos e baixe o manual que contem o layout do XML do CT-e. http://svn.code.sf.net/p/acbr/code/tools/DFe/CTe/Manuais/ Na final da página 9 temos o grupo toma4. É esse grupo que você precisa preencher para informar que o tomador é outros.

Bom dia Marco, Desculpe pela demora em responder. A sua rotina me parece correta. Entendo que o DM_Conexao seja um DataModule onde se encontra o componente ACBrNFe1. Você sabe me dizer se o problema ocorre com todos os XMLs que você tentar ler ou somente com alguns? Poderia anexar o XML da NF-e que ocorre o problema?

Boa tarde Marcus, Para mim, isso esta errado. Abaixo texto extraído do Manual do BP-e - Pagina 7. 2.1 Conceitos 2.1.1 BP-e (modelo 63) Bilhete de Passagem Eletrônico (BP-e) é o documento emitido e armazenado eletronicamente, de existência apenas digital, cuja validade jurídica é garantida pela assinatura digital do emitente e autorização de uso pela administração tributária da unidade federada do contribuinte, antes da ocorrência do fato gerador. O Bilhete de Passagem Eletrônico (Modelo 63) poderá ser utilizado, a critério das unidades federadas para substituir um dos seguintes documentos fiscais: * Bilhete de Passagem Rodoviário, modelo 13; * Bilhete de Passagem Aquaviário, modelo 14; * Bilhete de Passagem Ferroviário, modelo 16; * Cupom Fiscal Bilhete de Passagem emitido por equipamento Emissor de Cupom Fiscal (ECF) A não ser que esse ultimo "Cupom Fiscal Bilhete de Passagem permite documentar uma viagem dentro do próprio município. Até onde sei, dentro do município as pessoas pagam as suas passagens em dinheiro para o próprio cobrador, ou se utilizam de cartões magnéticos (fornecidos pela própria empresa de ônibus) que contem créditos em valores ou quantidades, normalmente tem os cartões específicos para estudantes, trabalhadores, idosos e comum que pode ser utilizado por qualquer pessoa, os outros 3 requer que seja feito um cadastro.

Boa tarde Costa, A sua aplicação esta utilizando os arquivos INI que se encontram no repositório? Pois fiz um teste usando o programa exemplo do componente e não tive esse erro.

Bom dia Henrique, Também achei estranho a alteração e até questionei se não iria gerar efeito colateral. Assim que possível vou reverter a alteração.

Bom dia Costa, Favor atualizar todos os fontes de todas as pastas e reinstale a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada. Note que fiz alterações em alguns arquivos INI utilizados pelo componente ACBrNFSe. Favor fazer novos testes usando o programa exemplo.

Bom dia Bill, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia Camilo, Ocorreu a troca do executável? Ou de um dia para outro começou a retornar esse erro? Se não ocorreu a troca do executável, favor entrar em contato com o provedor para saber qual é o motivo do lote não ter sido processado.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde Adilson, Se tratando das URLs de homologação e de produção no arquivo Pronimv2.ini agora tem somente isso: [URL_P] ; Soledade/RS RecepcaoLoteRPS_4320800=http://186.237.127.134/nfsews/services.svc ; Demais Cidades RecepcaoLoteRPS=%NomeURL_P%/nfse.portal.integracao/services.svc [URL_H] ; Soledade/RS RecepcaoLoteRPS_4320800= ; Demais Cidades RecepcaoLoteRPS=%NomeURL_H%/nfse.portal.integracao.teste/services.svc Como você pode ver se a cidade não for Soledade/RS as demais até agora as URLs são padronizadas, com isso foi possível a utilização das variáveis NomeURL_P e NomeURL_H Apague os arquivos que contem uma bolinha vermelha no ícone e atualize novamente.

Bom dia Costa, Chegou a fazer testes usando o programa exemplo?

Bom dia Lucas, Eu não tenho nenhuma aplicação que emite GNRE, mas vamos ver se eu consigo lhe ajudar. Primeiro vamos tentar entender essa mensagem de erro. "O Documento de Origem informado não é usado pela Receita informada na UF favorecida! O "Documento de Origem" que a mensagem se refere, acredito ser a chave da NF-e informada na tag <valor> do grupo <campoExtra> A "Receita Informada" que a mensagem se refere, acredito ser o código informado na tag <receita> do grupo <item> Por fim a "UF favorecida", acredito ser a UF informada na tag <ufFavorecida> Como não acusou que a UF favorecida esta errada e nem o código da Receita, chego a conclusão que ao informar esse tipo de receita não devemos informar a chave da nota. Como disse logo no inicio não tenho nenhuma aplicação que emite GNRE e não conheço muito sobre essa Guia. Posso ter escrito besteira, vamos aguardar se mais alguém do fórum com mais conhecimento possa lhe ajudar.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia a todos, Robson, você ainda esta configurando o componente com o libCapicom? Porque não muda para libWinCrypt?

Boa tarde Mauricio, Atualize os fontes. Não precisa mais alterar o arquivo Pronimv2.ini somente o Cidades.ini Que por sinal já fiz as devidas alterações.

Boa tarde Lucas, Notei que no seu XML esta faltando a IE do emitente.

Boa tarde Marcos, Como assim você comentou a unit que esta faltando? Se após a atualização você teve algum erro é porque você não atualizou todos os fontes de todas as pastas. E também não reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção apagar arquivos antigos marcada. E também não compilou a sua aplicação com a opção Build.

Boa tarde Ana, Eu não tenho nenhuma aplicação que envia os eventos do e-Social. Mas vamos a primeira rejeição: Verifique os dados informados pois apresentam divergência entre CPF e NIS, ou o NIS não e o mesmo que foi informado em sua admissão/inicio de TSVE ou em sua ultima alteração cadastral. A mensagem diz que o NIS não se refere ao CPF informado e pede para verificar se o NIS é o mesmo informado na admissão ou na ultima alteração de cadastro. Você chegou a verificar tudo isso?