Italo Giurizzato Junior

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.

Bom dia Douglas, Você já verificou: 1. Validade do Certificado; 2. Cadeia de certificados; 3. Configuração do IE no que diz respeito a certificados revolgados; Você esta com todos os fontes de todas as pastas atualizados?

Bom dia kzarlopes, Quando o componente não consegue obter o erro, no XML de retorno da SEFAZ, essa mensagem é apresentada. Isso pode ser um problema na SEFAZ.

Bom dia Daniel, Sugestão crie dois combo box, um para os grupos e outro para os campos. Sendo que o segundo que é para os campos os itens a serem apresentados mudam conforme o grupo escolhido. No combo box você coloca de forma clara para o usuário, por exemplo: combo box Grupo ---------------------- Remetente combo box Campo ----------------------- Nome do logradouro só que na hora de alimentar o componente a sua rotina informa desta forma: grupoAlterado := 'enderReme'; campoAlterado := 'xLgr'; valorAlterado := sValor; Onde o sValor é o nome do logradouro que o usuário digitou em um campo edit. Uma observação, no post #12 acabei colocando os nomes das TAGs erradas o correto é o que esta neste post. Dica: Ter em mãos o manual que contem o layout do XML do CT-e.

Thiago, Isso é um problema sério. A Ginfes por exemplo requer que você informe a aliquota dividida por 100, ou seja, aliquota = 2%, temos que informar 0,02 no XML do RPS. Mas ao retornar o XML da NFS-e a Ginfes retorna na TAG da aliquota o numero 2 em vez de 0,02. Dai esse valor absurdo. Vou fazer a seguinte alteração no componente. Para o provedor Ginfes você vai informar o valor 2 para a aliquota, o componente vai dividir esse valor por 100 no momento de gerar o XML e no DANFSE não vai ocorrer a multiplicação por 100 para o provedor em questão. E se tivermos mais provedores que agem desta forma o procedimento adotado será o mesmo.

Bom dia a todos, Fiz uma alteração, favor atualizar os fontes e testar novamente.

Bom dia Thiago, Coisa estranha, parece que ao gerar o PDF o tamanho da fonte é alterado. Alterei o tamanho da fonte de 7 para 8, vamos ver se isso resolve. Estarei disponibilizando em breve as alterações.

Bom dia PrudenSis, Quanto ao ACBrNFeMonitor não sei lhe informar se já esta implementado a CC-e para o CT-e versão 2.00 Com relação a versão 1.04 a Carta de Correção tradicional, ou seja, papel.

Bom dia Herbert, De uma olhada na Unit ACBrProvedorAbaco. Na function GetConfigCidade, temos: ConfigCidade.AssinaRPS := False; ConfigCidade.AssinaLote := True; Note que o componente realiza a assinatura no XML referente ao Lote, mas não o faz no XML do RPS. Quanto ao erro, o problema não é o certificado?

Bom dia Rogério, Essa propriedade é alimentada quando se le o XML da NFS-e. Não é um campo do RPS que é enviado e sim da NFS-e que é retornado. Se o Webservice incluir no XML da NFS-e a TAG: OutrasInformacoes, o seu conteudo será lido e impresso no DANFSE.

Bom dia a todos, Já fiz a alteração e até o final do dia vou disponibilizar.

Boa noite Nellien, Fiz as alterações, favor atualizar os fontes e testar.

Boa noite Nellien, Muito obrigado pela colaboração, alteração já realizada e disponibilizada.

Boa noite Asterix, Sim, se essa alteração vai deixar o DACTE bem mais claro e pratico no que diz respeito a essa informação, por que não? Se você puder fazer as alterações e testar e depois disponibilizar os fontes alterados aqui no forum como anexo fique a vontade. Boa noite Otavio, Favor consultar o manual do CT-e, mas precisamente as páginas referentes as TAGs do XML, e dentro da pasta ...\Exemplos\ACBrCTe tem varios arquivos TXT sendo que um deles vai lhe ajudar muito no que diz respeito a alimentar o componente.

Boa noite Kzarlopes, A variável Protocolo que alimenta a propriedade nProt contem o numero do protocolo de autorização de uso do CT-e. Lembre-se se você vai cancelar um CT-e é porque o mesmo foi enviado a SEFAZ e esta por sua vez retornou o protocolo de autorização. É este numero que devemos passar para propriedade nProt para evetuar o cancelamento por evento.

Boa noite Roman, Pesquise no fórum sobre as impressoras Daruma se não me falhe a memória, vi em alguns dos post como imprimir o QR-Code usando uma impressora não fiscal. O DANFE da NFC-e fica por sua conta, ou seja, você tem que montar o layout do DANFE e enviar para impressora imprimir. Por ser um impressora não fiscal é você que diz o que ela tem que imprimir.

Bom dia snoopyfael, Você tem o arquivo de retorno após o envio da CC-e? Se sim, post como anexo.

Bom dia Moncerra, A SEFAZ-SP não disponibilizou ainda os webservices para recepcionar documentos cujo modelo é 65, ou seja, NFC-e.

Bom dia Cesar, Verifique se o icone do arquivo contem uma bolinha verde. Se estiver vermelha significa que você alterou ele, dai ao baixar a atualização ele não é atualizado. Procure baixar atualização diariamente.

Bom dia Maricelo, Se você imprimir o DANFSE usando o programa exemplo com base no XML gerado pelo site, você vai notar que não será possível imprimir a discriminação dos serviços exatamente como esta no PDF que você anexou. Pelo simples fato que não existe no XML os dados referentes a quantidade, unidade e valor unitário.