Italo Giurizzato Junior

Bom dia Marcos, O componente ACBrNFSe - Trunk2 se utiliza de diversas rotinas padronizadas que são utilizadas pelos demais componentes que emitem Documentos Fiscais Eletrônicos. Acredito que mesmo o provedor não necessitando que o RPS e ou Lote seja assinados digitalmente será necessário possuir um certificado instalado na maquina e o componente configurado para este certificado. Em um primeiro momento você pode achar que o custo seja desnecessário, mas lembre-se que se tratando de NFS-e as coisas mudam. Se a prefeitura não possui um sistema próprio então ela contratou uma empresa (provedor) através de licitação, sendo assim quando vencer o contrato uma nova licitação sera feita e uma nova empresa pode ganhar. Se essa nova empresa (provedor) requer que o RPS e ou o lote sejam assinados, não vai ter jeito, você vai ter que adquirir o certificado.

Bom dia Castro, Já esta disponível o arquivo INI para o provedor BHISS. Mas esse provedor requer que tanto o RPS quanto o Lote sejam assinados e o componente não esta realizando a assinatura do lote quando detecta que o RPS esta assinado. Estamos trabalhando em uma solução e acredito que até o final deste mês vamos disponibilizar as alterações necessárias no componente para que essa segunda assinatura seja realizada pelo componente.

Marcos, Por favor configure o componente para salvar os arquivos Soap: Configuracoes.WebServices.Salvar := True; Teste novamente e post como anexo o arquivo: *-sit-soap.xml

Boa tarde Marcos, Comente a linha que contem o método Consultar e execute, pois quero saber onde o erro aparece se é no LoadFromFile ou no Consultar.

Bom dia a todos, Acredito termos encontrado uma solução para realizar a assinatura no Lote quando temos os RPS assinados também. Por favor aguardem mais alguns dias, pois precisamos realizar testes a fim de detectar possíveis efeitos colaterais em função das alterações realizadas nas rotinas de assinatura.

Bom dia a todos, Esta disponível no repositório o arquivo INI para o provedor Tecnos. Favor atualizar todos os arquivos de todas as pastas e façam os testes.

Boa tarde José, O componente ACBrNFe possui duas propriedades de configuração onde você deve informar o CSC e o idCSC. O CSC é o Código de Segurança do Contribuinte e o idCSC é um identificador. Você tem que solicita-los a SEFAZ. Para algumas existem diferenças para o ambiente de produção e homologação, portanto nesse primeiro momento devemos solicitar para o ambiente de homologação.

Boa tarde, No caso da NFC-e você deve informar a chave da mesma ao campo refNFe. Página 48 da NT 2013/005 versão 1.22 campo 29x.2 Quando ao SAT, não sei lhe informar.

Josemar, Configure o componente para salvar os arquivos Soap (Configuracoes.WebServices.Salvar := True). Realize o envio do evento de encerramento desse MDF-e em questão. Post como anexo o arquivo de envio e o de retorno caso tenha. Os arquivos Soap possuem a palavra soap no nome.

Marcos, O que precisa ser visto é, apesar do RPS não ser assinado, do Lote também não ser assinado, também não se faz necessário um certificado digital para acessar o Web Services?

Boa tarde a todos, Todas as DLLs necessárias estão agrupadas em pastas dentro da pasta ...\DLLs A zlib1.dll encontra-se dentro da pasta ...\DLLs\XMLSec

Boa tarde Marcos, Você esta carregando o XML do CT-e com o LoadFromFile antes de executar o método Consultar?

Josemar, Quando você diz finalizar esta querendo dizer enviar o evento de encerramento, correto? Se sim, faça como Fabrício estudo a rotina do botão [Encerramento] do programa exemplo e compare com a sua, pode ser que você esteja fazendo algo errado.

Josemar, O XML com final 0019.xml esta assinado e protocolado como autorizado. O XML com final 0019-mdfe.xml não esta assinado e muito menos protocolado. O XML com final 0016-mdfe.xml esta assinado e protocolado como autorizado. Quando você diz que o inicio de um é diferente do outro (vide os que estão em negritos) é pelo simples fato de um conter o protocolo e o outro não. Antes de enviar devemos gerar e assinar o XML, para tal basta alimentar o componente com os dados e executar o método Assinar. Esse método gera o XML assina e salva em disco (caso a propriedade Configuracoes.Arquivos.Salvar for igual a True). Se ocorrer algum erro após o envio a primeira coisa a fazer é carregar o componente com o XML enviado e em seguida executar o método Consultar. Esse método vai checar se o MDF-e consta ou não na SEFAZ se sim, vai retornar o resultado do processamento, caso tenha sido autorizado o XML será atualizado recebendo o protocolo de autorização. A partir dai basta imprimir o DAMDFE. Por outro lado se após a consulta retornar uma mensagem informando que o MDF-e não consta da base de dados da SEFAZ, fica claro que o erro ocorreu no envio e não no retorno. Logo devemos enviar novamente.

Boa tarde Luciano, Deve usar o teDPEC uma vez que este foi substituído pelo EPEC. Foi mantido o nome ainda por mera compatibilidade uma vez que o tipo de emissão do DPEC e EPEC é "4".

Boa tarde Marcos, Na procedure EnviarDados temos apenas duas linhas onde faz referencia ao certificado digital. N primeira é checado se o XML esta assinado ou não, mas neste caso o componente não se utiliza do certificado, apenas verifica se existe ou não a TAG Signature no XML, portanto não há motivo de se preocupar. A segunda verifica a validade do certificado: if FPConfiguracoes.Certificados.VerificarValidade and (FPDFeOwner.SSL.CertDataVenc < Now) then raise EACBrDFeException.Create('Data de Validade do Certificado já expirou: '+ FormatDateBr(FPDFeOwner.SSL.CertDataVenc)); Acredito que se alterarmos o código acima para: if FPConfiguracoes.Certificados.VerificarValidade then if (FPDFeOwner.SSL.CertDataVenc < Now) then raise EACBrDFeException.Create('Data de Validade do Certificado já expirou: '+ FormatDateBr(FPDFeOwner.SSL.CertDataVenc)); E atribuir o valor False a propriedade VerificarValidade não teremos problemas no que diz respeito ao certificado.

Boa tarde Josemar, Os arquivos são de grande ajuda, favor postar como anexo.

Bom dia Akai, Os parâmetros IncluiEncodingCab e IncluiEncodingDados serve para incluir no cabeçalho e ou no dados a linha: <?xml version="1.0" encoding="UTF-8"?> Veja o INI do Ginfes não maioria dos serviços temos: IncluiEncodingCab=0 IncluiEncodingDados=0 Já no caso do Cancelar temos: [Cancelar] IncluiEncodingCab=0 IncluiEncodingDados=1 <=== indica que a mensagem de dados vai começar com o encoding. Para alguns provedores o cabeçalho e ou dados devem ser convertidos para string neste caso temos: (...) Cabecalho=1 Se um, temos o cabeçalho e ou dados no formato string, se zero, formato XML. Dados=1 Espero ter ajudado.

Bom dia a todos, Não existe mais o DPEC e nem o SCAN. Eles foram substituídos pelo evento EPEC e pela contingência SVC. Favor lerem as Notas Técnicas 2014/001 versão 1.10 que trata sobre o evento EPEC e a 2013/007 versão 1.03 que trata sobre o SVC.

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

Bom dia, Post como anexo o XML de envio referente ao evento e o de retorno. Primeiro configure o componente para salvar os arquivos soap. Configuracao.WebWervices.Salvar := True;

Bom dia Moacir, Que tal usar os Schemas da pasta: ...\Exemplos\ACBrDFe\Schemas\NFe

Bom dia a todos, No que diz respeito ao PIS / COFINS segundo um contador que conheço diz que: se o CST do PIS for 01 do COFINS também é, o que muda é o percentual de cada um.

Bom dia Wellington, Veja a estrutura de pastas através do Explorer. No meu caso a pasta principal é ACBrTrunk e dentro desta temos as pastas: DLLs, Doctos, Exemplos, Fontes, Pacotes, Projetos e Testes. O caminho para chegar até a pasta que contem o programa exemplo do ACBrNFe é: C:\ACBrTrunk\Exemplos\ACBrDFe\ACBrNFe\Delphi O que esta em negrito pode ser diferente na sua maquina, mas o resto é igual.

Bom dia Douglas, Quando escrevi que precisa estudar mais, eu estava me referindo a mim e não a você, pois a alteração no componente para que o mesmo incluísse o protocolo de denegado ao XML foi feita por mim. Eu que devo desculpa por não ter me expressado de forma clara. Quando enviamos uma nota a SEFAZ podemos ter 3 tipos de respostas: 1. Autorizada, neste caso a nota é registrada no banco de dados da SEFAZ, sendo assim o XML tem que ser atualizado com o protocolo de autorização. 2. Rejeitada, neste caso a nota não é registrada no banco de dados da SEFAZ, sendo assim devemos efetuar as devidas correções e enviar novamente. 3. Denegada, neste caso a nota é registrada no banco de dados da SEFAZ, sendo assim no meu entendimento o XML tem que ser atualizado com o protocolo de denegação. Uma nota denegada não pode ser corrigida e enviada novamente, uma vez que ela esta registrada na SEFAZ, portanto não cabe uma correção. Acredito eu que também não cabe cancelamento, apesar da nota ter sido registrada, ela não foi autorizada, sendo assim a venda não pode ser realizada, não foi autorizada pela SEFAZ. Em um primeiro momento achei que no caso de uma denegação deveríamos alterar o nome do XML de <chave>-nfe.xml para <chave>-den.xml, mas da forma que esta as rotinas hoje esta gerando os dois arquivos com o protocolo de denegação. Estou chegando a uma conclusão que o melhor seri manter o nome <chave>-nfe.xml Se esse XML estiver apenas assinado podemos concluir que o mesmo foi gerado assinado e não foi enviado ainda ou se foi enviado não foi autorizado, ou seja, rejeitado ou ocorreu um erro no retorno, neste caso cabe uma consulta. Por outro lado se o XML estiver assinado e protocolado devemos ler os dados desse protocolo para saber se a nota esta autorizada ou denegada.