Italo Giurizzato Junior

Bom dia Rodrigo, Maravilha, e desde já agradeço pela colaboração na realização dos testes e correções nos fontes. Você pode anexar somente os fontes corrigidos aqui mesmo no fórum. Nós vamos avaliar as suas alterações, estando tudo OK, vamos enviar para o repositório.

Bom dia a todos, Uma empresa menor que seja, com um computador apenas emitindo documento fiscal eletrônico, não fazer uma cópia de segurança em um HD Externo é uma falta de responsabilidade total. A responsabilidade pela guarda do DF-e é do emitente e do seu destinatário e não do desenvolvedor do sistema. Este por sua vez pode orientar qual é a forma ideal para uma determinada empresa. Detalhe importante, guardar a cópia da chave do carro no porta luva do mesmo, é burrice.

Bom dia Eduardo, A mensagem que aparece se refere a uma rejeição, correto? Sendo assim, seria melhor você anexar o XML da nota que foi rejeitada pela SEFAZ.

Bom dia Arnaldo, Se tratando de NFC-e, porque você não utiliza um numero de série diferente para cada PDV e consequentemente um numero de nota sequencial para cada PDV? Desta forma você terá um controle mais efetivo e acredito não vai ocorrer duplicação de numeração entre os PDV.

Bom dia Rodrigo, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa noite Bruno, Não entendi da necessidade de configurar o componente novamente antes do envio. Ele esta perdendo a configuração inicial? Quanto as atualização dos arquivos INI já estão no repositório.

Boa noite, Ao ler essa lista, você vai estar lendo todas as notas confirmadas. Uma nota não confirmada não vai constar nessa lista.

Bom dia Eliseu, Muito estranho isso, pois é a primeira queixa com relação a São Paulo.

Bom dia Ornei, Favor ler a Nota Técnica 2013/007 versão 1.03 - página 6 item 04.4

Bom dia Eduardo, Favor ler a Nota Técnica 2014/002 versão 1.01 que trata sobre a Distribuição DF-e. Com relação ao componente é o ACBrNFe. Dentro da pasta ...\Exemplos\ACBrDFe\ACBrNFe estude o fragmento de código chamado DitribuicaoDFe.txt

Bom dia Gleidson, Nunca passei por essa situação, mas lendo o manual da NF-e acredito que a solução seria você referenciar todas as NFC-e emitidas durante o mês. No layout da NF-e temos o campo refNFe onde informamos a chave da NF-e ou NFC-e, podemos referenciar até 500 notas. Espero ter ajudado.

Bom dia Allan, Acredito que deva ser algum problema na SEFAZ, favor entrar em contato relatando o problema.

Felipe, Quando enviamos o CT-e e por algum motivo não temos o retorno da SEFAZ acusando que o mesmo foi autorizado, o XML do CT-e esta apenas assinado mas sem o protocolo, correto? Pois bem, o que temos que fazer? Carregar o XML e executar o método Consultar. Para carregar devemos usar o LoadFromFile da seguinte forma: LoadFromFile( sNomeCompletoXML, False ); Note que estou informando um segundo parâmetro (valor False), isso faz com que os dados que estão no XML sejam preservados. Consequentemente o DigestValue da assinatura não será alterado. Espero ter ajudado.

Boa noite Felipe, Você notou que o DigestValue são diferentes? Se sim, sabe o porque? Compare a TAG <dhEmi>.

Boa noite Bruno, Pela mensagem de retorno: "Erro na autenticação do usuário. Usuário e senha não conferem", me leva a crer que o usuário e senha que você esta informando não estão corretos. Verifique junto ao provedor se há necessidade de um usuário e senha para cada ambiente, ou seja, um para homologação e outro para produção. Pode ser que o usuário / senha criados sejam para o ambiente de produção e você esta usando eles para o de homologação, dai a mensagem de erro. Esse provedor esta implementado a um bom tempo e sempre a estrutura foi essa, não acredito que o problema seja a estrutura do XML. E a mensagem de erro não diz nada sobre a estrutura e sim faz referencia ao usuário e senha que não estão corretos.

Boa noite Douglas, Acabei de realizar um teste usando o programa exemplo. Em anexo os arquivos de envio e de retorno gerados clicando no botão [Gerar e Enviar um RPS] que pela imagem que você anexou é o mesmo que você utilizou. Pelos arquivos que estou anexando você nota que o XML de envio foi gerado, assinado, validado e enviado, uma vez que existe o XML de retorno. No sou caso como esta ocorrendo falha de validação isso me leva a crer que o programa exemplo esta se utilizando do XSD errado. No meu teste configurei o programa exemplo para a cidade de Porto Alegre que se utiliza do provedor BHISS. Na aba Geral, no campo: Schemas do provedor informei o caminho que contem os XSD do respectivo provedor que no meu caso é: C:\ACBrTrunk2\Exemplos\ACBrDFe\ACBrNFSe\Schemas\BHISS NFSe.rar

Boa tarde Ricardo, Você tem razão, esta faltando um "." ponto após o 91. Quanto aos código 90 e 91 existem sim, e são usados para SUFRAMA, RFB e inclusive esta faltando o código 92:

Bom dia Bruno, A diferença entre eles é que o "soap" contem a estrutura completa, ou seja, o seu conteúdo é exatamente o que o provedor recebe, logo ele esta recebendo com o usuário e senha. Você esta usando o programa exemplo para enviar? Se sim, qual é a exata mensagem de erro? É salvo algum arquivo de retorno?

Bom dia Fábio, Maravilha.vou incluir o provedor EGoverneISS na lista de provedores que estão funcionando 100%.

Bom dia, Analisando o seu XML notei que se tratado de um CT-e Modal Rodoviário - Lotação. Neste caso devemos informar os dados do veículo e do motorista. Notei que você informou 2 veículos, em ambos você diz que são de tração, como assim? Um tem que ser de tração e o outro reboque. Outra coisa você diz que o veículo é próprio, neste caso ele é de propriedade do emitente do CT-e, ou seja da transportadora. Neste caso não devemos informar o proprietário do veiculo, pelo simples fato ele ser do emitente do CT-e. No DACTE quando se tratar do modal rodoviário devemos imprimir o RNTRC da Empresa (transportadora). Se for lotação devemos imprimir os dados do Veiculo,tais como Tipo, placa, UF e RNTRC. O RNTRC referente ao veiculo será o da transportadora a não ser que o veiculo seja de terceiros, ai devemos informar os dados do terceiro (proprietário do veiculo) e um desses dados é o RNTRC. A impressão do DACTE conforme a figura que você anexou esta correto, porque você informou no XML que o veiculo é próprio, ou seja, da transportadora. O teu XML que esta errado, não condiz com a realidade, primeiro por informar 2 veículos de tração, segundo por informar o proprietário do veiculo, sendo que o mesmo é da transportadora. E o CNPJ do proprietário do veiculo informado no XML se refere ao remetente da carga, como assim?

Bom dia, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Edson, É preciso comparar o XML do RPS que anteriormente era processado e o de agora, para sabermos o que mudou. Depois ver o que precisa ser corrigido no DANFSE para que os valores sejam impressos da forma correta. No caso do DANFSE temos que lembrar que ele é usado pelos demais provedores, logo temos que tomar o cuidado de corrigir para um provedor e gerar um efeito colateral para os demais.

Boa noite Doni, Para efetuar o cancelamento de um CT-e não há necessidade do XML do mesmo, uma vez que o cancelamento é um evento. No que diz respeito a consulta o XML é interessante para que o componente seja capaz de atualizar o mesmo caso este não tenha o protocolo de autorização. Caso o XML não seja carregado ao efetuar a consulta, a atualização não será realizada, apenas o retorno com o status atual do CT-e será salvo em disco. A mensagem de URL não definida para o TCTeConsulta esta muito estranho.

Walter, Até hoje não vi nenhuma utilidade para o grupo <infUnidTransp>. Aconselho você ter em mãos o Manual do MDF-e versão 1.00a em mãos para saber quais são os campos obrigatórios e os que são opcionais. O grupo <infUnidTransp> é opcional.

Boa noite a todos, Página 103 do Manual do MDF-e versão 1.00a - a quantidade máxima do grupo <infNFe> é de 4000 (4 mil).