Italo Giurizzato Junior

Boa tarde a Todos, Favor atualizar os fontes e testar novamente.

Boa tarde Edson, Não querendo ser chato, mas sendo, em vez de ficar quebrando a cabeça para saber o que a SEFAZ alterou no site, não seria mais simples fazer com que o emitente da NF-e seguisse a legislação? Nela diz que assim que o emitente obtem o protocolo de autorização de uso da NF-e, ele deve disponibilizar o XML assinado e protocolado para o destinatário e para transportadora. A forma mais simples de disponibilizar o XML é enviando o mesmo por e-mail. Puxa vida será que isso é algo tão complicado de ser feito, ou é falta de vontade? Os componentes ACBrNFe, ACBrCTe atende a legislação a anos. Na minha opnião, já passou da hora, as transportadoras devem se unir e dizer NÃO. Se não enviar o XML assinado e protocolado por e-mail, não vamos transportar a carga.

Boa tarde kzarlopes, Vamos verificar, se for erro na implementeção, com certeza vai ser corrigido. kzarlopes, Veja a explicação abaixo: A SEFAZ aceita somente um evento por lote, dai a mensagem de erro: "ERRO: Conjunto de Eventos transmitidos (máximo de 1) excedido." Como resolver o problema da carta de correção? Simples, uma coisa é adicionar mais de um evento e outra coisa é adicionar mais de uma Informação de correção. Se é enviado uma CC-e contendo a correção do campo X e depois temos que enviar uma segunda CC-e com a correção do campo Y, devemos adicionar 2 infCorrecao. O primeiro contendo novamente a correção do campo X e o segundo contendo a correção do campo Y. Vamos a um exemplo: Primeira CC-e: Note que o ADD do Evento é executado apenas 1 vez na rotina, por outro lado o ADD do infCorreção é executado uma para cada correção. Espero ter ajudado.

Boa tarde Leonardo, Muito obrigado pela colaboração, assim que possível, estaremos verificando.

Boa tarde Reinaldo, Post aqui no fórum como anexo o que você já implementou para que possamos verificar.

Boa tarde Junior, Verifique o programa exemplo que encontra-se na pasta: ...\Exemplos\ACBrNFPws Ele foi feito para o Lazarus, mas acredito que você não tera dificuldades, uma vez que muitas coisas do Lazarus é compativel com o Delphi.

Boa tarde Cesar, Notei que você informou: dhCont e xJust, campos estes utilizado para informar que esta em Contingência. Mas o tipo de emissão: tpEmis foi informado como sendo 7 que se refere ao SVC-RS SEFAZ Virtual de Contingência do Rio Grande do Sul. Quando informamos o tpEmis = 1 ou 6 ou 7 as TAGs dhCont e xJust não devem ser preenchidas. Corrija isso e tente novamente.

Boa noite Rômulo, Muito obrigao, vou analisar e assim que possível vou disponibilizar.

Boa noite DATAC, Se a SEFAZ diz que vai aceitar a versão 2.00 até 01/12/2014, logo podemos continuar usando uma versão do Monitor para esta versão, sem se preocupar com qualquer outra coisa. Mas assim que possível for realizar a migração para a versão 3.10 é melhor. Como não sou responsavel e não faço parte da equipe de desenvolvimento do ACBrNFeMonitor, não sei lhe dizer em que "pé" esta as alterações para que o mesmo suporte a nova versão. Mas fique tranquilo que em breve teremos uma nova versão do monitor que vai atender a versão 3.10 da NF-e.

Boa noite Luan, Muito obrigado pela colaboração, vou analisar e assim que possível vou disponibilizar.

Boa tarde Rafael, O pacote de instalação do ACBrCTeDACTeQR requer versão 5 do Quick Report. Se você puder realizar a troca da versão 3.5 pela 5.02 será ótimo, alem de não ocorrer o erro, você vai poder disfrutar do recurso de gerar o DACTE em PDF. Se não for possível a troca, favor pesquisar no fórum, você vai encontrar varias dicas para contornar esse problema.

Boa noite Rodrigo, Favor atualizar os fontes e testar novamente.

Boa noite Luan, Com as alterações que você realizou, conseguiu realizar o envio e obter o retorno do WebService?

Boa tarde Luan, Toda correção, alteração, implementação é bem vinda. Faça como demais, zipa a unit ou as unit alteradas e post como anexo aqui no fórum. Deste de já muito obrigado.

Boa tarde a todos, Não é permitido emitir uma CC-e para corrigir o CNPJ ou CPF do Emitente, Remetente, Destinatário ou Tomador do Serviço (outros).

Boa tarde Akai, Muito obrigado pela sua colaboração, já esta disponivel as suas alterações.

Boa tarde Leonardo, Sim, é muito simples, mas vamos aguardar uma posição dos demais moderadores, administradores e mantenedores do componente. Mas para você resolver o seu problema, fique a voltade em realizar a alteração.

Boa tarde Marcos, Muito obrigado pela informação. Notei que alem de incluirem os novos webservices eles alteram todas as URLs para esta nova versão.

Boa tarde João, Não interpretei a sua postagem como sendo uma critica. Eu que peço desculpas, por não ter alertado a todos sobre essa alteração que realizei. Aproveitei para fazer uma justificativa sobre a alteração, alteração esta realizada por mim. Um forte abraço.

Boa tarde Wellington, No caso do MDF-e devemos utiliza a UF do local que a carga foi carregada e vai ser descarregada, independente se você é a transportadora que vai realizar o despacho ou redespacho ou redespacho intermediário. Vamos a um exemplo: A -------> B -------> C --------> D -------> E As letras A, B, C, D e E indica os locais de carga e descarga e cada uma delas ficam em um Estado diferente: A = SP B = MG C = RJ D = BA E = SE Cada trajeto vai ser realizado por uma transportadora diferente. Transp. 1: emite o CT-e Normal informando o Remetente de SP e o Destinatário de SE. emite o MDF-e informando SP como local de carregamento e MG como sendo o local de descarregamento. Transp. 2: emite o CT-e de Redespacho Intermediário informando o Expedidor como sendo a Transp.1 e o Recebedor como sendo a Transp. 3 emite o MDF-e informando MG como local de carregamento e RJ como sendo o local de descarregamento. Transp. 3: emite o CT-e de Redespacho Intermediário informando o Expedidor como sendo a Transp.2 e o Recebedor como sendo a Transp. 4 emite o MDF-e informando RJ como local de carregamento e BA como sendo o local de descarregamento. Transp. 4: emite o CT-e de Redespacho informando o Expedidor como sendo a Transp.3 e o Destinatário de SE emite o MDF-e informando BA como local de carregamento e SE como sendo o local de descarregamento. Espero ter ajudado.

Boa noite Eduardo, Muito obrigado pela colaboração, já esta disponivel as suas alterações.

Boa noite Daniel, Favor atualizar os fontes e tentar novamente.

Boa noite Farnetani, Esse só ocorre quando alimentamos a propriedade ID. Deixe essa propriedade sempre com o valor vazio, ou melhor, uma string vazia.

Boa noite João Henrique, Eu fiz essa alteração no componente, na unit responsavel por gerar o XML. Vamos aos motivos: 1. O Ginfes segue a risca a seguinte frase: Faça o que eu mando, mas não faça o que eu faço. O Ginfes lhe obriga a informar o valor da Aliquota já dividida por 100, mas o XML da NFS-e gerada por eles o valor da aliquota não esta dividida por 100. 2. Da forma que estava antes, se imprimir o DANFSE automaticamente através do comando Enviar, o mesmo era impresso corretamente, mas ao carregar o XML da NFS-e e tentar imprimir apareceia o valor da aliquota multiplicada por 100. Sendo assim, devemos alimentar o componente no caso o valor da aliquota sem dividi-la por 100. Vamos a um exemplo: Aliquota = 2% Alimentar o componente => aliquota := 2; XML do RPS gerado pelo componente => <aliquota>0.02</aliquota> Impressão do DANFSE através do Enviar => Aliquota = 2,00% XML da NFSe gerado pelo webservice => <aliquota>2</aliquota> Carregar o XML da NFS-e através do LoadFromFile e Impressão do DANFSE através do Imprimir => Aliquota = 2,00% Quero chamar a atenção que o valor da aliquota informada na respectiva propriedade do componente só será divida por 100 se o provedor for o Ginfes.

Boa noite Rodrigo, Muito obrigado pela colaboração, ainda hoje vou disponibilizar as suas alterações.