italo.giurizzato.junior

Boa noite Luciano, Se o enviar funciona, mas o consultar não, isso significa que as alterações necessárias não foram completadas pela SEFAZ. A minha sugestão, é que você entre em contato com a SEFAZ e coloque para eles o problema que você esta enfrentando.

Boa noite Fabricio, Acredito que a mensagem esta clara. Você tentou utilizar o Botão [Gerar e Enviar Lote] do programa exemplo?

Boa noite Gallixx, A sua alteração se refere a URL do SoapAction e não a de acesso ao WebService para a respectiva operação. É isso mesmo?

Boa tarde Luciano, Por não ter um certificado valido de uma empresa de São Paulo, não tenho como realizar os testes, apenas estou realizando alterações nos fontes do componente baseado em relatos dos colegas.

Boa tarde a Todos, Temos dois modelos de documentos fiscais: NF-e e NFC-e, as versões vigentes dos respectivos modelos são: 2.00 e 3.00 Este ano de 2014, a versão de ambos os modelos passam a ser 3.10, isso significa que o layout do XML bem como os schemas para validação para ambos os modelos passam a ser os mesmos. Inclusive o Manual de Orientação bem como as Notas Técnicas a partir de agora passam a fazer referencia aos dois modelos.

Boa noite Wagner, Já tentou desta outra forma? ACBrCTe1.DACTe.NumCopias := StrToInt(txtQtde.Text); ACBrCTe1.DACTe.MostrarPreview := False; ACBrCTe1.Conhecimentos.Clear; while (not DM.SqlAux.Eof ) do begin PathArquivo := ACBrCTe1.Configuracoes.Arquivos.GetPathCTe(DM.SqlAux.FieldByName('DTEHR1').AsDateTime); Arq := PathArquivo+'\'+Trim(DM.SqlAux.FieldByName('CHAVE').AsString)+'-cte.xml'; ACBrCTe1.Conhecimentos.LoadFromFile(Arq); DM.SqlAux.Next; end; ACBrCTe1.Conhecimentos.Imprimir;

Boa tarde DataC, Vamos deixar claro alguns pontos: 1. O ACBrNFeMonitor se utiliza do componente ACBrCTe; 2. O componente ACBrCTe já possui as rotinas basicas para o envio de eventos, como é o caso da CC-e; 3. O ACBrNFeMonitor não possui um comando que utiliza essas rotinas basicas para envio de eventos; Portanto, por favor aguarde, ainda vai ser criado o comando.

Boa tarde Lucas, Muito obrigado pela colaboração, a sua alteração já esta disponivel.

Boa tarde Asterix, Muito obrigado pela contribuição, já esta disponivel a sua alteração.

Boa tarde Divonei, Você lembrou de alterar o arquivo ACBr.inc, descomentando a linha que define a diretiva de compilação: QReport_PDF ?

Boa tarde Rene, Se tratando de Minas Gerais, podemos esperar de tudo. Mas vamos lá, por favor atualize os fontes e tente novamente.

Boa tarde Graça, Esta disponivel uma atualização, agora o arquivo XML bem como o PDF tem os nomes padronizados: XML: <chave><tipoevento><seq>-procEventoCTe.xml PDF: <chave><tipoevento><seq>-evento.pdf Onde: <chave> é a chave do documento fiscal e é composta por 44 digitos; <tipoevento> é o tipo de evento e é composto por 6 digitos; <seq> é o numero sequencial do evento e é composto por 2 digitos. Apliquei a mesma alteração na NF-e.

Boa noite Lucas, Como você esta passando o código do municipio, pois chequei os fontes e não achei nada de errado.

Boa noite Caio, Se os seus fontes estão atualizados, no caso do Ginfes, devemos informar a aliquota sem a divisão por 100, por exemplo: Se a aliquota for 2%, devemos informar 2 e não 0,02, pois o componente vai realizar essa divisão. Divisão esta é feita somente para o provedor Ginfes. O motivo dessa alteração no componente é devido ao retorno, o XML da NFS-e não é retornado 0,02 e sim 2 como sendo o conteudo da TAG.

Boa noite Wether, Com certeza você deve ter outro ACBr.inc em alguma pasta, procure e exclu-a. pois só pode existir apenas um e dentro da pasta ACBrComum.

Boa noite a todos, O nome do XML bem como o PDF de um evento não pode ter apenas a chave como nome, exemplo: <chave>-evento.xml e <chave>-evento.pdf pelo simples fato de existir mais de um tipo de evento. Lembrem-se que o cancelamento também é um evento.

Boa noite Pereira, Por favor post o XML como anexo e não desta forma como texto. Alem de ficar mais curto a postagem fica mais facil checar o problema.

Boa noite Wether, Você compilou a sua aplicação com a opção Build?

Boa noite a todos, Esse erro esta ocorrendo, pelo fato de estarem fazendo errado. Favor estudar o arquivo: alimentarcomponente.txt que encontra-se na pasta ...\Exemplos\ACBrCTe. Nele vocês vão encontrar a forma correta de montar a rotina. Lembre-se ao executar o ADD você esta incluindo um novo registro a lista e não alimentando um campo da lista.

Boa noite Luciano, Você esta realizando os testes com qual UF?

Boa tarde Fabio, Fiz uma alteração no fonte pcnNFeW para atender tanto o tcDe2 quanto ao tcDe4. Fazer uma cópia de segurança, atualizar os fontes e testar, fazendo o favor.

Daniel, Para ser impresso os dados do CT-e juntamente com o evento da CC-e, basta carregar o XML da CT-e antes. Veja o programa exemplo, temos botões que exemplifica a impressão do evento e a geração do PDF.

Boa tarde Luciano, Segundo o manual, na versão 3.10 algumas TAGs como por exemplo a pICMS tem o tamanho de 3v2-4, isso significa que são 3 inteiro e 2 ou 4 decimais. Pois bem, algumas SEFAZ estão preparadas para receber esse valor com 2 ou 4 casas decimais e outras não fizeram essa alteração, logo só aceitam com 2 casas decimais. O que fazer neste caso. Primeiro entrar em contato com a SEFAZ e questiona-los a respeito dessa mudança. Segundo criar um mecanismo de identificar as UF e determinar a quantidade de casas decimais para a TAG pICMS e as demais que também estão nessa situação.

Boa tarde Akai, Muito obrigado pela colaboração, estarei disponibilizando as suas alterações ainda hoje.

Boa tarde Daniel, O numero do lote a SEFAZ não faz uso, logo podemos dizer que é um controle seu, agora o numero sequencial do evento esse sim. Se você esta emitindo uma segunda CC-e para o mesmo CT-e o nSeqEvento deve ser 2. Lembre-se que o nSeqEvento sempre inicia com o valor 1 para tipos de eventos diferentes. Posso emitir um CT-e e depois eviar 2 CC-e com nSeqEvento 1 e 2 e por fim efetuar um cancelamento cujo nSeqEvento vai ser 1. CC-e e Cancelamento são tipos de eventos diferentes. Não sei se ficou claro.