Italo Giurizzato Junior

Bom dia Sérgio, No meu entendimento devemos sempre carregar o XML do CT-e e depois do evento e por fim imprimir ou gerar o seu PDF. Caso contrario teremos somente os dados do evento e desta forma não saberemos qual CT-e o evento esta vinculado.

Bom dia Rogério, Sendo assim, o Remente por ser uma Pessoa Física, deve emitir uma Carta Remessa de Mercadoria e anexar a Nota Fiscal de compra da mercadoria. A transportadora por sua vez deve informar como documento originário a CRM emitida pelo Remetente para poder emitir o CT-e. Não se deve informar a chave da NF-e de compra da mercadoria, pois o CT-e será rejeitado uma vez que o CNPJ/CPF do remente não condiz com o CNPJ que consta na chave. E tem um outro detalhe se o Remente é uma pessoa física, ele não pode ter emitido a NF-e uma vez que não esta credenciado junto a SEFAZ para tal emissão. Por outro lado se o Remente é uma pessoa jurídica e obrigada a emitir NF-e, não podemos informar os dados da nota como sendo uma nota fiscal comum de papel ou informar como sendo outro tipo de documento. Se assim fizermos o CT-e também será rejeitado, pelo simples fato que se o Remente é obrigado a emitir NF-e, então devemos informar a chave da NF-e como sendo o documento originário. Espero ter sido claro.

Boa noite Márcio, Você fez as alterações nos arquivos Cidades.ini e Fiorilli.ini ? Se sim, funcionou? Se sim, por favor anexe os INI alterados.

Boa noite Sérgio, O correto é carregar o XML do CT-e e depois o XML do Evento, por fim executar o método Imprimir ou ImprimirPDF.

Boa noite Allan, Se tratando de evento o componente gera 3 XML que se forem salvos em disco temos: *-ped-eve.xml (Pedido de Evento, trata-se do XML de envio para a SEFAZ) *-eve.xml (Evento, trata-se do XML de retorno da SEFAZ) *-procEventoNFe.xml (Processamento do Evento da NF-e, trata-se de um XML que contem o conteúdo do XML de envio e do retorno) Este último devemos guardar e disponibilizar ao Destinatário. A alteração que fiz foi baseado no seguinte argumento: Se o evento não foi processado significa que ele foi rejeitado, sendo assim não faz sentido gerar o XML (*-procEventoNFe.xml). Para pegar o XML retorno da SEFAZ tente da seguinte forma: xRetorno := ACBrNFe1.WebServices.EnvEvento.RetWS; Para ler diretamente os dados do retorno, tente da seguinte forma: aStatus := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[ x ].RetInfEvento.cStat; aProtocolo := ACBrNFe1.WebServices.EnvEvento.EventoRetorno.retEvento.Items[ x ].RetInfEvento.nProt; Espero ter ajudado.

Bom dia Rogério, O refrigerador se encontra de posse do Remetente ou da Loja? Quem vai pagar o Frete, Remetente (pessoa física) ou o destinatário? Se é o Remetente que vai pagar pelo frete, este tem que emitir uma carta remessa de mercadoria que pode ser de próprio punho e anexar a NF para comprovar que a mercadoria não é fruto de roubo (por exemplo). Mas no CT-e o que deve ser informado como sendo documento originário é a carta remessa de mercadoria.

Bom dia Sandro, Favor visitar diariamente o Portal Nacional da NF-e. Quando o ENCAT regulamentar a inclusão de uma TAG para o Troco, será publicado uma Nota Técnica e esta será disponibilizada pela SEFAZ no Portal Nacional da NF-e. Desta forma você vai descobrir sem tem algo de novo ou não.

Bom dia, Não entendi o motivo pelo qual você incluiu a propriedade vTotTrib ao grupo ISSQNTot, pois segundo o Manual da NF-e não existe o vTotTrib no grupo ISSQNTot.

Boa tarde Gabriel, Muito obrigado pela colaboração, já esta no repositório.

Boa tarde Rogério, No meu entendimento o Remetente sempre é o emissor do documento originário a ser informado no CT-e. Se o Remente é uma pessoa física, o documento emitido por ela será algo do tipo "Carta Remessa de Mercadoria" ou "Declaração".

Boa tarde Leonardo, Se o emitente do MDF-e for uma transportadora o documento a ser informado é o CT-e e não a NF-e. O componente só vai incluir as chaves das NF-e caso o emitente não seja uma transportadora.

Bom dia a todos, Paulo, se tratando de NFS-e não existe nada e nem vai ter uma vez que a emissão da NFS-e é a nível municipal, você como destinatário terá que solicitar o XML da NFS-e ao emitente. Douglas, infelizmente não tenho nenhuma informação privilegiada com relação ao CT-e, mas acredito sim que vamos ter algo nesse sentido, veja os motivos: 1. Foi criado o Web Services MDFeDistribuicaoDFe para o MDF-e, sendo que não vejo necessidade, uma vez que não se trata de um Documento Fiscal que deva ser compartilhado, ele serve para agilizar a fiscalização da carga transportada em um posto fiscal de fronteira entre Estados. 2. Se você acessar o Portal Nacional do CT-e e for em Notas Técnicas, vai notar que esta faltando a NT 2015/002. Qual será o conteúdo dessa NT, uma minuta da versão 3.00 do CT-e ou o CTeDistribuicaoDFe? 3. Se para a NF-e e MDF-e já temos um Web Services de DistribuicaoDFe, porque não ter um também para o CT-e? Visto que o Tomador do Serviço também tem o direito de saber se alguém esta emitindo um CT-e contra o seu CNPJ/CPF e com base nessa informação se manifestar (semelhante a NF-e) e após essa manifestação obter o XML completo do CT-e bem como os Eventos: como carta de correção, cancelamento, etc.

Bom dia Pasqueto, Implementei uma propriedade para armazenar o nome do RPS. Favor atualizar os fontes e tentar obter o Path + Nome do RPS da seguinte forma: xNomeRPS := ACBrNFSe1.NotasFiscais.items[ x ].NomeArqRps;

Boa noite Paulo, O componente ACBrNFe possui o método DistribuicaoDFe e tem como objetivo consumir o Web Service NFeDistribuicaoDFe. Sendo assim o que você vai ter é o resumo da NF-e caso o autor da consulta seja o destinatário. Até o momento não temos nada semelhante para o CT-e. Acredito que para o ano que vem teremos, então vamos aguardar os próximos capítulos.

Boa noite Will, Complementando o que já foi dito, existem os componentes: ACBrNFSe que visa emitir a NFS-e e o componente ACBrNFe que permite a emissão da NF-e e da NFC-e. Pelo que eu entendi o seu cliente deseja emitir a NF-e quando o destinatário da mercadoria for uma pessoa jurídica (empresa), caso contrario o seu cliente vai emitir o CF-e (SAT). Hoje ele se utiliza do programa gratuito que a partir de janeiro de 2017 não teremos novas atualizações e nem sequer estará disponível para download. Sendo assim, você tem que utilizar o programa exemplo do componente ACBrNFe para realizar os seus testes e compreender como o componente funciona.

Boa tarde a todos, Favor não usar o método Gerar. Use o método Enviar.

Hamilton, Você esta com todos os fontes de todas as pastas atualizados? Todos os DCUs dos fontes dos componentes foram recompilados?

Boa tarde Robson, Já tentou aumentar o valor da propriedade de configuração Timeout?

Boa tarde Will, O provedor Ginfes já esta implementado, você não tem que alterar INI nenhum. Basta usar o programa exemplo para iniciar os testes. Caso a cidade em questão não conste no combobox, basta incluir da mesma forma que foram incluídas as outras.

Boa tarde, Por favor vamos seguir as regras do fórum? Assunto novo, post novo.

Boa tarde Brunetto, A correção é bem simples, basta não usar o método ConsultarSituacaoLote, pelo simples fato que esse provedor não possui o Web Service destinado a consultar a situação do Lote. É exatamente por isso que no arquivo INI a direita do "=" esta em branco.

Boa tarde Hamilton, Pela mensagem de erro, você configurou o componente para gerar o MDF-e segundo a versão 3.00, correto? Se sim, você esta ciente que essa versão só esta disponível o ambiente de homologação. Outra coisa, ao configurar a propriedade PathSchemas, o caminho contem todos os Schemas que estão disponível na pasta: ...\Exemplos\ACBrDFe\Schemas\MDFe ?

Bom dia Felippi, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Muito obrigado pelo retorno, já fiz a alteração e enviei para o repositório.

Bom dia Quartarollo, Você fez as melhorias para que essa alteração não gere efeitos colaterais em provedores que não possuem uma lista de itens de serviços?