Italo Giurizzato Junior

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

Boa tarde Fabio, Verifica se o XML da NFS-e retornado pelo WebService consta a TAG: OptanteSimplesNacional ?

Boa tarde Cesar, Você diz que o erro ocorre na linha 4224 da function: TNFSeCancelarNfse.Executar: Boolean; mais precisamente em: ReqResp.Execute(Acao.Text, Stream); só que no meu fonte esta linha é a de numero 4026. Você esta com os fontes atualizados?

Boa tarde Nilton, No manual não exite nada sobre a inutilização de numeração, pelo simples fato de não existir o webservice para realizar esta operação. Portanto podemos hoje dizer que, não existe inutilização de numeração de MDF-e. No meu entendimento, o MDF-e não é um documento que registra a venda ou a prestação de serviço e sim um documento que visa agrupar as NF-e ou CT-e. Com a finalidade de facilitar a fiscalização em um posto fiscal de fronteira entre um Estado e outro. Conclu-o que a numeração do mesmo não tem importancia nenhuma caso venha falhar. Acredito eu que por esses motivos e conclusões foram o que levaram a SEFAZ a não implementar o webservice de inutilização de numeração do MDF-e.