Italo Giurizzato Junior

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.

Boa tarde Fernando, Muitos dos problemas de identificador não reconhecido, é resolvido quando se atualiza todos os fontes de todas as pastas. Todos os icones de todos os fontes tem que possuir uma bolinha verde, caso tenha alguma com a cor vermelha significa que foi alterado por você, logo esse fonte não é atualizado.

Boa tarde opennet, É o seu sistema que tem que tratar isso.

Boa tarde mbbortolini, Você esta realizando o cancelamento por evento? Lembre-se que não existe mais o cancelamento pelo webservice de cancelamento, agora é por evento.

Boa tarde Leandro, O ambiente utilizado para consulta tem que ser o mesmo do envio. Verifique se o envio não foi para o ambiente de homologação e a consulta esta sendo realizada no de produção.

Boa tarde Volnei, Atualiza os fontes e tente novamente.

Boa tarde Keila, A cidade de São Paulo não adotou o padrão ABRASF para a NFS-e. O componente ACBrNFSe visa atender as cidades que segue o padrão ABRASF. Se não me falhe a memória tem um pessoal trabalhando na implementação desse novo layout usado pela prefeitura de São Paulo no componente. Vamos aguardar.

Boa tarde Carlos, O motivo é simples. Esse Schema "cancNFe_v2.00" era utilizado para o cancelamento normal de uma NF-e agora o cancelamento é por evento. E a versão dos schemas referentes a eventos tanto da NF-e quanto da NFC-e ainda é 1.00