Italo Giurizzato Junior

Igor, Você pode realizar um consulta pela chave, veja: ACBrMDFe1.WebServices.Consulta.MDFeChave := sChave; ACBrMDFe1.WebServices.Consulta.Executar; Isso vai realizar uma consulta e retornar a situação atual do MDF-e. Se ele esta autorizado, vai ser retornado o protocolo que você precisa para efetuar o cancelamento.

Boa tarde Marcelo, Tentando entender: 1. é gerado o XML com tipo de emissão = 5 ou seja contingencia; 2. o XML é assinado; 3. o DACTE é impresso. Até ai sem nenhum problema, correto? 4. é carregado o XML anteriormente sem efetuar nenhuma alteração no mesmo. 5. é enviado para SEFAZ; Correto? Através do XML: -pro-rec.xml que você postou nota-se que o numero do recibo é zero: <nRec>000000000000000</nRec> Como você esta realizando o envio? É através do comando Envio( nlote ), ou esta utilizando outra forma? Você realizando a consulta através do numero do recibo? Se sim, esta informando corretamente este numero?

Boa tarde Silvio, Favor não postar em varios lugares o mesmo questionamento. O ACBr não é uma DLL e foi escrito para o Delphi.

Boa tarde Jairo, Qual é a finalidade de se fazer isso?

Boa tarde Igor, Mas o cancelamento do MDF-e é por evento, logo devemos informar a chave do mesmo. Estude a procedure referente ao botão [Cancelamento] do programa exemplo. Note que ele carrega o XML do MDF-e apenas para obter a chave e o numero do protocolo de autorização. Mas se você tem essas duas informações não se faz necessário carregar o XML.

Boa tarde Lucas, Se você esta com o mesmo problema do opennet, acredito que ele deve sim ter resolvido, pois pedi a ele para postar o XML e até hoje não deu retorno. Agora se o erro é exatamente o mesmo, veja que a mensagem de erro é clara e diz que não foi informado nenhum documento no MDF-e. Favor estudar o programa exemplo ele mostra como fazer isso.

Boa tarde Ant. Carlos, Pesquise aqui mesmo no fórum por CT-e Globalizado. Se não me falha a memória existe uma postagem minha onde coloco um Boletim Técnico sobre o assunto.

Bom dia leufmt, Segundo o layout da ABRASF ao cancelar uma NFS-e você deve apenas informar o código de cancelamento, não tem sequer um campo para colocar uma justificativa. Portanto a resposta para a sua pergunta é: Não.

Bom dia ALA, Chequei todos os fontes e não encontrei nada que pudesse estar gerando uma segunda TAG </Nfse>. Também não encontrei nada que pudesse estar multiplicando o valor da aliquota por 100 e mantendo esse resultado. Na impressão do DANFSE para dois provedores a aliquota é multiplicada por 100 mas o resultado é atribuido ao campo do DANFSE, portanto nenhum valor carregado para o componente é alterado. Favor checar a sua aplicação.

Bom dia Frederico, Vai se acostumando, quando ocorre esse erro, o problema é na SEFAZ, infelizmente isso ocorre com maior frequencia na SEFAZ-MG. O que fazer: 1. Entrar em contato com a SEFAZ e reclamar; 2. Esperar.

Bom dia Rogercon, Se o componente valida o XML significa que ele esta em conformidade com o schema. Agora se o WebServices do provedor, no caso o Ginfes o rejeita, logo se trata de uma restrição imposta por eles, ou até mesmo um erro. A minha sugestão é entrar em contato com eles e expor o problema. Informe que via site é possível a emissão, o schema disponibilizado pela Ginfes para que as aplicações de terceiros validem os XMLs antes do envio, também contempla a emissão sem o tomador, mas o webservive o rejeita.

Boa noite Eber, Não entendi, porque você alterou o schema?

Boa noite Frederico, Inclua no Library Path a pasta que contem o QR5RunDXE2. Obs: de preferencia antes do Path do ACBrCTeDACTeQR.

Jeferson, Em vez de: indIEDest=9 tente: indIEDest=2

Boa tarde ALA, Infelizmente o Manual sobre o DACTE é pobre nesse aspecto, pois apenas apresenta o modelo de um CT-e Normal. Tente utilizar o emissor gratuito e poste o DACTE impresso por ele.

Boa tarde Jeferson, O problema é que você esta utilizando os schemas da NF-e versão 2.00 para validar uma NFC-e da versão 3.00 ou 3.10 Você tem que pelo menos utilizar os schemas da versão 3.00 para validar uma NFC-e caso contrario não vai funcionar. Os schemas que me refiro estão disponiveis juntamente com o programa exemplo na pasta: ...\Exemplos\ACBrNFe2\Delphi\Schemas, dentro desta pasta temos as pastas V200, V300 e V310, onde encontra-se os schemas das respectivas versões. Agora se você utiliza o ACBrNFeMonitor favor baixar os referidos schemas do Portal Nacional da NF-e.

Boa tarde ALA, Foi feita uma alteração. Favor atualizar os fontes e testar.

Boa tarde Andeson, Muito obrigado pela colaboração.

Boa tarde ALA, Favor consultar o manual. Note que tanto a versão 1.04 quanto a 2.00 só é permitido informar apenas uma nota quando se trata de CT-e substituido. Estou me referindo ao documento emitido pelo tomador quando este é contribuinte do ICMS.

Boa tarde ciomar, Inclusão realizada, obrigado pela colaboração.

Boa tarde ALA, O melhor ponto de partida é o Manual do CT-e. Existem situações quando o tomador é contribuinte e quando não é. É preciso estudar com muita atenção a estrutura do XML e montar a rotina prevendo as diversas situações. Outra coisa no Manual do CT-e você tem a informação se um determinado campo é obrigatório ou não.

Não, o jeito mesmo é tentar enviar.

Boa tarde Isaque, Quando você sinalizar que os testes realizados com essa versão do ACBrNFeMonitor compilado para emitir o CT-e na versão 2.00 estão OK, disponibilizo sim a Unit. Se você achar por bem, posso disponibiliza-la com o nome: DoACBrCTeUnit2 para não sobrepor a que já existe. Ai fica a cargo dos nossos colegas que desejam compilar o monitor e fazer testes e em caso de algum erro efetuar a correção e disponibilizar aqui no fórum a unit corrigida. Lembrando que neste caso há necessidade de renomear o arquivo para DoACBrCTeUnit que é o nome correto da unit.

Boa tarde a todos, Temos as seguintes TAGs: forPag = Forma de pagamento do serviço => Pago / A pagar ou Outros. toma03 = Tomador do serviço => Remetente / Expedidor / Recebedor ou Destinatário toma4 = Tomador do serviço => Outros vTPrest = Valor Total da Prestação do Serviço vRec = Valor a Receber No CT-e o conceito de Pago e A pagar é outro não significa que quando é Pago quem vai pagar o frete é o Remetente e quando é A pagar é o Destinatário que vai pagar pelo frete. Quando forPag = Pago significa que o frete já esta pago, logo o campo vRec tem que ser igual a Zero. Por outro lado quando o forPag = A pagar, o vRec é igual a vTPrest. Quem pagou ou quem vai pagar pelo frete é informado nos campos toma03 ou toma4 dependendo da situação. Acredito eu que quando forPag for igual a Outros, significa que uma parte do valor do frete já foi paga e o restante vai ser pago quando a carga for entregue. Neste caso vRec vai ser igual ao valor que falta a receber e a diferença entre vTPrest e vRec é o valor que foi pago antes do transporte ter sido iniciado. Espero ter ajudado.

Boa tarde Binho, Não existe essa funcionalidade nos WebServices dos provedores de NFS-e.