Italo Giurizzato Junior

Boa tarde BEP Informatica, Para alguns provedores basta fazer essa alteração, mas outros requer que seja feito uma alteração na unit referente ao provedor, incluindo nela as URLs de homologação e produção dos webservices.

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 Cristiam, Você esta utilizando o componente ou o Monitor? Se você esta desenvolvendo a sua aplicação em Delphi e usando o componente ACBrCTe, favor analisar o arquivo: alimentarcomponente.txt que esta dentro da pasta: ...\Exemplos\ACBrCTe.

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 Maricelo, Vou verificar o problema. Assim que possível disponibilizo a correção.

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.

Boa noite Krepe, Com o advento do Cancelamento por evento, o XML do CT-e não sofre alteração, ou seja, ele permanece com as informações sobre o protocolo de autorização. O que deve ser feito neste caso em relação ao Tomador do Serviço? Simples, enviar um e-mail contendo o XML e o PDF referente ao cancelamento. Para mais detalhes favor estudar o programa exemplo, este possui botões que exempleficam o procedimento acima.