Italo Giurizzato Junior

Boa tarde Carlos, Maravilha, precisamos de mais colaboradores como você. Assim que você concluir as alterações/correções, por favor post como anexo somente as units que sofreram alterações. Desde já muito obrigado.

Boa tarde Rodrigo, Com certeza o DAMDFE feito em Fortes Report esta com problemas. Você testou com a versão feita em Quick Report? Outra coisa importante, porque você esta alimentando a TAG: SegCodBarra? Essa TAG só é alimentada quando o CT-e ou NF-e foram emitidos em contingência FS-DA neste caso o DACTE ou DANFE possuem 2 códigos de barras.

Boa tarde Rigotti, Favor atualizar os fontes e testar novamente.

Bom dia Daniel, É o procedimento GerarXML que gera o conteúdo de ArquivoFormatoXML; Veja: LocCTeW.GerarXML; aCTe := LocCTeW.Gerador.ArquivoFormatoXML;

Bom dia Dionatan, A partir do momento que o cancelamento se tornou um evento, não se atualiza mais o XML que foi assinado e autorizado pela SEFAZ. Estou me referindo a NF-e, CT-e, NFC-e e MDF-e. Temos agora 2 XMLs: Um é o XML do MDF-e assinado e Autorizado, o outro é o processamento do evento (*-procEventoMDFe.xml) que contem a solicitação do cancelamento e a homologação do mesmo com o numero do protocolo e tudo mais. Já existe uma especie de Documento Auxiliar para imprimir o evento, bastando carregar os 2 XMLs mencionados acima e executar o comando ImprimirEvento. É possível ainda gerar esse DA em PDF. Por favor estude o programa exemplo do MDF-e que nele você encontrar botões relacionados a Eventos. Da para imprimir não somente o evento de cancelamento como também o de Encerramento.

Boa tarde Carlos, Por favor, poste o arquivo como anexo aqui mesmo no fórum.

Daniel, Ao realizar a consulta, você esta carregando o componente com o conteúdo do CT-e? Se não estiver carregando o componente procura pelo XML do mesmo salvo em disco, bem como o *-sit.xml Se não encontrar o *-cte.xml ele não gerar o CTeDFe consequentemente a propriedade RetCTeDFe fica vazia.

Boa tarde Dangelo, O componente ACBrNFSe gera o XML de envio e o submete a um validador próprio. O problema é que o componente esta gerando o XML esta validando-o segundo os schemas (arquivos XSD), para o componente o XML gerado esta em conformidade com os schemas, mas o provedor o recusa acusando que esta errado. Isso nos leva a crer que os schemas que estamos utilizando não condiz com o que o provedor esta utilizando. Se conseguíssemos os schemas corretos, teríamos condições de efetuar as correções na rotina que gera o XML e assim enviar ele corretamente. Resumindo a resposta do provedor: Se vira.

Boa tarde Dorivan Sousa, Segundo o manual que você postou esse provedor não segue o padrão de estrutura e nomenclatura da ABRASF.

Boa tarde Julio, O problema é que esse provedor não implementou o Web Service de Envio somente o Gerar.

Boa tarde Daniel, Por favor atualize os fontes e teste novamente.

Boa tarde, Na minha postagem #52 desse tópico temos um fragmento do Ajuste SINIEF 15/2012 e neste fragmento mostro que tanto as transportadoras quanto as empresas que emitem NF-e com transporte próprio vão ser obrigadas a emitir o MDF-e. Mas uma coisa é certa. Todas as transportadoras estão sujeitas a emitir o MDF-e, basta a carga ser fracionada e o transporte ser interestadual. Já as empresas que emitem NF-e só serão obrigadas a emitir o MDF-e se possuírem veículos para realizarem o transporte da mercadoria vendida cuja carga for fracionada e interestadual.

Boa tarde, As TAGs: tara, capKG e capM3 se referem ao veículo e não a carga.

Bom dia Ilson, A mensagem esta clara, você esta tentando enviar um CT-e cuja chave já existe, ou seja, você esta enviando um CT-e com o mesmo numero de outro.

Bom dia Claudio, O EnviarEmail anexa automaticamente o XML a ser enviado, antes de executar o comando você não esta montando uma lista de anexo e anexando o XML. Neste caso temos: Um XML anexado automaticamente pelo componente; Um segundo XML anexado por você e passado como parâmetro para o EnviarEmail;

Bom dia, Como dito no post anterior, no caso do Ginfes devemos enviar a alíquota dividida por 100 e o provedor nos retorna a mesma multiplicada por 100. Outros provedores agem de forma diferente, ou seja, o retorno é igual ao envio. Como o LoadFromFile, LoadFromStream são utilizados tanto para ler o XML de um RPS como de uma NFS-e, precisaríamos estudar uma forma de resolver esse problema que funcione para todos. De imediato você pode após a carregar o XML realizar a multiplicação por 100.

Bom dia Castro, Primeiro, ao postar uma rotina ou fragmento dela, por favor post como anexo, a sua postagem vai ficar mais curta. Segundo, vamos a alguns conceitos (segundo o meu entendimento): Após emitir uma NFS-e, caso algo esteja errado, podemos tomar duas atitudes: 1. Cancelar; (a nota foi emitida para o tomador errado) 2. Substituir; (a nota foi emitida com o valor errado, neste caso a primeira nota será substituída pela segunda com o valor correto) O componente possui os comandos para emitir e cancelar, mas não tem o de Substituir, uma vez que não são todos os provedores que disponibilizam essa funcionalidade. Neste caso havendo a necessidade de substituir uma nota, cancela-se a primeira e emite em seguida uma segunda com os dados corretos. Para que o provedor saiba que esse segundo RPS esta substituindo o anterior, temos que gerar o grupo <RpsSubstituido> informando o Numero, Serie e Tipo

Bom dia a todos, Pará emite primeira NFC-e Link com a reportagem (Agência Pará). http://www.agenciapara.com.br/noticia.asp?id_ver=103803

Boa tarde Julio, Você tentou utilizar o Enviar em vez do Gerar? Lembre-se o componente não gerar NFS-e e sim RPS. A NFS-e é gerada pelo provedor ao processar o lote de RPS que você envia.

Boa tarde Daniel, Após configurar a propriedade CTeCancelada com o valor True e em seguida executar o Imprimir, não aparece a Tarja; CT-e CANCELADO no DACTE? Você esta com todos os fontes de todas as pastas atualizados? Principalmente as units referentes ao DACTE feito em Quick Report.

Boa tarde, O problema no caso do Ginfes é: 1. A alíquota no XML do RPS tem que ser informada da forma 0.025 e não 2.5 2. A alíquota no XML da NFS-e retornada pelo provedor vem da forma 2.5 Ou seja você tem que enviar de uma forma e eles te retorna de outra.

Boa tarde Rodrigo, Favor atualizar todos os fontes de todas as pastas.

Me refiro a este arquivo: Property_Does Not Exist.txt que esta dentro da pasta: ...\Fontes\ACBrCTe.

Boa tarde, Favor atualizar os fontes e testar novamente.

Boa tarde Dércio, Segundo a Nota Técnica 2013/005 versão 1.03, página 24 e 25 item 03.19 o Grupo <pag> = Formas de Pagamento no caso da NFC-e a sua obrigatoriedade vai ficar a critério da UF. E quando a forma de pagamento for Cartão de crédito ou Débito temos que gerar o grupo <card>. A sua sugestão é aceita pela SEFAZ, mas não vejo como uma saída. Outra coisa, no que diz respeito a cheque, existem comerciantes que dão troco no caso de cheque? Se sim, tem que confiar muito no cliente, pois o cheque é um valor a receber e o troco em dinheiro é a vista.