Italo Giurizzato Junior

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.

Boa tarde Edudidu, Você possui os fontes, não existe nenhuma restrição em você personalizar o DANFSE. Portanto você mesmo pode fazer as devidas alterações.

Boa tarde Jairo, O componente ACBrCTe compilado com a diretiva de compilação PL_200 ( vide arquivo ACBr.inc ) conforme o Isaque já mecionou, lhe permite não só a emissão do CT-e na versão 2.00 como também efetuar o cancelamento por evento e a Carta de Correção que também é um evento. Encontra-se disponivel dentro da pasta ...\Exemplos\ACBrCTe fragmentos de códigos, um deles se refere a carta de correção. Quanto a impressão do evento, vide o programa exemplo.

Bom dia xx_kernel_xx seja lá quem você é. Desculpe, mas na primeira linha fica dificil de interpretar o seu problema. Consegui entender pela descrição da reijeição, "Chave de acesso inválida (modelo diferente de 57)". Vamos clarear as coisas: Primeiramente, você esta emitindo um conhecimento de transporte de carga onde é informado como documento originário a chave da NF-e. Segundo, você quer consultar na SEFAZ esse documento utilizando-se da chave do mesmo para saber se esta autorizado ou não. O componente ACBrCTe, possui uma opção de consulta pela chave, mas este comando serve para consultar a situação atual de um CT-e emitido. Para consultar a situação atual de uma NF-e devemos utilizar o comando correspondente que encontra-se no componente ACBrNFe. Espero ter ajudado.

Bom dia Rogério, A resposta é Não. As propriedades SenhaWeb e UserWeb são requisitos para alguns provedores que alem do certificado requer mais estas informações.