Italo Giurizzato Junior

Bom dia Edmar, Por favor faça um backup e atualiza os fontes e faça novos testes com o programa exemplo, tanto de envio do lote quanto de consulta.

Boa noite Julian, Quando falo que a NFS-e é uma zorra, acham que falo demais. Ta ai mais um exemplo. Quer saber o motivo de emitir a nota via site ser diferente de emitir via web services? Pergunta para o provedor.

Boa noite ALA, Não da para anexar somente o form que contem o erro? Pois não consigo ler.

Boa noite hromao, O componente ACBrNFSe não gera o código de verificação, pois este consta no XML da NFS-e retornado pelo provedor. Note que esta ocorrendo um truncamento da informação, sendo assim o problema é o componente que imprime o DANFSE.

Boa noite ALA, Favor anexar o arquivo que foi alterado.

Bom dia Joceandro, Primeiro é preciso gerar o XML do evento depois você pode ler a propriedade Id da seguinte forma: Vamos usar como exemplo o evento S-1000. xID := ACBreSocial1.Eventos.Iniciais.S1000.Items[ x ].evtInfoEmpregador.Id; Todos os eventos são uma lista, logo podemos ter mais de 1 evento S-1000, sendo assim cada um terá o seu ID, ou seja, a sua chave.

Bom dia a todos, As URLs estão corretas, acredito que o problema seja na montagem do envelope a ser enviado para o web service, ainda hoje estarei vendo essa questão.

Bom dia a todos, Fiz algumas alterações no componente em relação ao ID e a geração da chave. No meu entendimento a propriedade ID deve conter o ID completo ou seja a chave do evento. Sendo assim fiz uma alteração visando alimentar essa propriedade com o retorno da função GerarChaveeSocial. Acrescentei uma nova propriedade chamada Sequencial. Ela deve ser alimentada ao alimentar os demais campos dos eventos, por exemplo: with ACBreSocial1.Eventos.Iniciais.S1000.Add do begin evtInfoEmpregador.Sequencial := 0; (...) Se o valor atribuído a propriedade Sequencial for zero (conforme o exemplo) a função GerarChaveeSocial vai gerar um numero aleatório para compor o último elemento da chave (conforme tabela postada pelo Paulo), caso contrario será utilizado o numero informado. Vejam como ficou a unit do evento S-1000: Self.Id := GerarChaveEsocial(now, self.ideEmpregador.NrInsc, self.Sequencial, ATipoEmpregador); GerarCabecalho('evtInfoEmpregador'); Gerador.wGrupo('evtInfoEmpregador Id="' + Self.Id + '"'); Notem que a função GerarChaveeSocial agora recebe o valor da propriedade Sequencial e não mais a constante zero como estava antes e também recebe o Tipo do Empregador que é definido em propriedade de configuração do componente, onde podemos escolher entre tePessoaJuridica ou teOrgaoPublico. O que vocês acharam da implementação?

Boa noite Elias, As duas que você anexou, já enviei para o repositório, muito obrigado pela colaboração.

Boa tarde hromao, Favor atualizar os fontes e refaça os testes.

Boa tarde Gustavo, Esta com todos os fontes atualizados?

Boa tarde Rubens, Favor utilizar inicialmente os botões: [Gerar e Enviar Lote RPS] esse botão vai gerar e enviar um lote com até 50 RPS no modo assíncrono (se utiliza do método Enviar). [Gerar e Enviar um RPS] esse botão vai gerar e enviar somente um RPS (se utiliza do método Gerar). [Gerar e Enviar Lote - Síncrono] esse botão vai gerar e enviar um lote com até 50 RPS no modo síncrono (se utiliza do método EnviarSincrono). Os provedores que seguem a versão 1 do layout da ABRASF só implementaram o método Enviar, já os que seguem a versão 2 do layout implementaram os 3 métodos ou dois deles, é preciso testar. Já os provedores que não seguem o layout da ABRASF, tem que testar um por um para saber qual dos 3 foi implementado pelo provedor em questão.

Boa tarde Karine, Faça o seguinte teste. Gera um BP-e em contingência e imprimir o DABPE. Depois enviar para SEFAZ o XML do BP-e em contingência e por fim imprima o DABPE novamente. Na primeira impressão é para aparecer a mensagem EMITIDA EM CONTINGÊNCIA e na linha de baixo Pendente de autorização. Já na segunda impressão não é para aparecer essas mensagens e sim o protocolo de autorização. Tire uma foto de ambos para que possamos ver como ficou.

Boa tarde Weber, Muito obrigado pela colaboração, ainda hoje estarei enviado para o repositório.

Boa tarde Heronim, Já tentou os métodos: EnviarSincrono e Gerar?

Boa tarde a todos, Favor verificar se a linha 296 da unit ACBrNFSeNotasFiscais é: if not (Configuracoes.Geral.Provedor in [proAbaco, proSMARAPD, proNotaBlu, proSP]) then e se no arquivo SP.ini consta: [Assinar] RPS=0 Lote=1 URI=0 Pelo que notei esta gerando no XML o valor do atributo URI na assinatura, sendo que para o provedor SP não deve gerar.

Boa tarde Andre, Por que você alterou o nome dos XSD no arquivo INI do provedor? Com essa alteração ele não acha os Schemas e não consegue validar o lote antes do envio.

Boa tarde Lucio, Chegou a atualizar os fontes?

Boa tarde, Alem de baixar a DLL do Capicom, você registrou a mesma?

Boa tarde a todos, Favor atualizar todos os fontes de todas as pastas e reinstale os componentes. Notem que inclui a cidade de Sete Lagoas/MG no arquivo Cidades.ini e criei um arquivo INI especifico para a respectiva cidade. Arquivo: Actconv202 - Sete Lagoas Esse arquivo deve ser renomeado para Actconv202.ini para ser utilizado com a cidade Sete Lagoas.

Boa tarde Marcelo, Você esta com todos os fontes de todas as pastas atualizados? Pois os arquivos que o Augusto anexou já foram enviados para o repositório, logo não se faz necessário fazer a troca novamente.

Boa tarde Ciminos, Já foi feito uma alteração no componente em relação a Nota Técnica 2017/003. Favor atualizar todos os fontes de todas as pastas, reinstalar os componentes através do ACBrInstall_Trunk2 e refaça os testes.

Boa tarde Junior, O XML de envio do evento é salvo em disco? Existe os arquivos: *-ped-eve.xml e *-eve.xml ? Se sim, favor anexa-los, para podermos analisar.

Boa tarde Karine, Vou lhe pedir um favor, em seus testes de envio, você chegou a imprimir o DABPE? Se sim, poderia anexar a imagem de um deles? Desde já muito obrigado.

Boa noite Valdir, Na chave da NF-e temos um campo chamado código numérico. Ess código possui um tamanho de 8 dígitos e a sua posição é a penúltima, pois a última é o digito verificador. Chave: ......12345678D A letra D representa o digito verificador da chave. Como você gera o código? Usa o mesmo numero da nota? Se sim, esta errado, pois fazendo dessa forma a chave da sua nota é considerada fraca e tem um detalhe, o numero da nota pode chegar até 9 dígitos e o código somente 8, logo o que você vai fazer quando a sua nota chegar a ter 9 dígitos? No Manual da NF-e existe uma recomendação que esse código seja aleatório e diferente de zero. A minha sugestão é acrescentar um campo chamado CodNF na tabela onde você salva os dados da nota no banco de dados. Desta forma ao gerar no banco de dados um registro para armazenar os dados da nota de numero 10 (por exemplo), gere o código com no máximo 8 dígitos e que seja diferente de zero através do Randomize e salve no campo CodNF. Ao alimentar o componente com os dados da venda, atribua o conteúdo campo CodNF a propriedade ide.cNF Desta forma ao gerar a chave o componente vai utilizar esse numero como código numérico da Nota Fiscal. Você concorda que ao emitir a nota de numero 10 teríamos um código numérico aleatório para essa nota e ao restaurar o banco emitir novamente uma outra nota de numero 10 teríamos u código aleatório totalmente diferente da primeira? Desta forma você teria uma informação para comparar se realmente se trata da mesma nota ou não. Pense nisso.