Italo Giurizzato Junior

Boa noite Vially, Ao imprimir o DANFSE o mesmo tem que se basear nos dados do XML da NFS-e. Favor verificar o XML da NFS-e para saber qual é a alíquota que consta no mesmo.

Boa noite Adilson, Muito obrigado pela colaboração, já esta no repositório.

Boa noite Dércio, Favor atualizar os fontes e testar novamente. Note que fiz uma alteração no arquivo DBSeller.ini

Boa noite Heronim, Favor atualizar os fontes e testar novamente.

Boa tarde João, Tente desta forma: ACBrNFSe1.NotasFiscais.Assinar( bAssina ); cXML := ACBrNFSe1.NotasFiscais.Items[ x ].XMLAssinado; ACBrNFSe1.Enviar( nLote ); A variável bAssina tem que valer True ou False, pois isso vai determinar se o XML do RPS será assinado ou não, lebre-se que essa informação depende do provedor. A variável cXML vai conter o XML do RPS assinado ou não, a variável x é o índice do RPS dentro da lista, a propriedade XMLAssinado contem o XML do RPS após a execução do método Assinar, se o provedor não exige que o RPS seja assinado essa propriedade vai retornar o XML sem a assinatura apesar no seu nome. A variável nLote tem o valor do numero do lote que será enviado.

Boa tarde Dércio, Reveja a sua aplicação, pois ela esta ADD um segundo RPS em "branco" a lista. Abra o arquivo 15155905-env-lot.xml que você vai notar que o lote possui 2 RPS, sendo que o segundo não tem informações.

Bom dia Daniel, Muito obrigado pela colaboração, já esta no repositório.

Bom dia Heronim, Fiz uma alteração, favor atualizar os fontes e realizar novos testes.

Boa tarde Valcimar, Muito obrigado pela colaboração, já esta no repositório.

Bom dia João, Como foi dito anteriormente, temos provedores que não se deve assinar o XML do RPS, somente o Lote, temos ainda provedores que não se assina nada. Em uma postagem anterior, você diz se aparecer um fiscal e solicitar o XML de envio, lembre-se o que é enviado é um RPS - Recibo Provisório de Serviço. Se algum fiscal aparecer vai querer ver o XML da NFS-e e não de um Recibo Provisório. No meu entendimento se você deseja guardar algum XML, pensando em uma possível fiscalização, o XML a ser guardado é o da NFS-e, pois este possui uma informação importante que é o código de verificação que podemos utiliza-lo para confirmar a autenticidade da nota junto a Prefeitura.

Bom dia Mark, Todas essas cidades do Estado de Goiais? Entre hoje e amanhã vou disponibilizar algumas alterações que vai permitir que você realize testes usando o programa exemplo.

Bom dia André, Sim, para cada assunto novo um tópico novo, mas antes por favor pesquise para saber se já não existe algum tópico tratando sobre o mesmo assunto.

Boa noite André, Por favor vamos respeitar as regras do fórum, esse tópico trata sobre a versão 3.00 do CT-e, sendo assim não tem nada haver com o CIOT / e-Frete.

Boa noite João, Como não existe uma padronização referente a assinatura, o método Enviar com base na parametrização do componente através dos arquivos INI é assinado ou não o XML do RPS, bem como é assinado ou não o Lote de envio. No caso do método Gerar (método de envio usado por alguns provedores) a assinatura pode ser uma só e dois lugares diferentes ou até mesmo 2 assinaturas. Como você pode ver no caso da NFS-e fica complicado separar o GerarXML, assinar dos métodos de envio (Enviar, EnviarSincrono e Gerar).

Boa noite a todos, Não basta acrescentar a cidade em questão no arquivo Cidades.ini será necessário criar um arquivo INI para o respectivo provedor e alterar algumas units do componente para que o mesmo reconheça o novo provedor. Mark, qual ou quais as cidades atendidas por esse provedor?

Boa noite Heronim, O ideal seria enviar o arquivo soap de envio (*-env-lot-soap.xml) para eles poderem analisar.

Boa noite Valcimar, Anexa o arquivo alterado para que possamos enviar para o repositório.

Boa noite João, Segundo o arquivo Cidades.ini Blumenau usa o provedor Ginfes. Se não mudou esta funcionando sim 100%.

Boa noite Luis, Na versão 3.00 do CT-e existem várias mudanças. Algumas tags foram removidas e outras foram adicionadas. Existem 2 novos eventos, sendo que um deles só o tomador do serviço pode emitir. O componente agora passa a ter uma propriedade chamada ModeloDF onde devemos informar o valor moCTe para poder emitir o CT-e modelo 57 (o que já existe) ou o valor moCTeOS para poder emitir o CT-e Outros Serviços modelo 67 (novo). O CT-e Outros Serviços é destinado a Transporte de Pessoas, Transporte de Valores e Transporte de Excesso de Bagagem. Em linhas gerais é isso.

Boa noite a todos, Página 3 do Manual do CT-e versão 3.00 - tabela referente a Identificação e Vigência do Manual. Por favor, baixem e leiam.

Boa tarde João, O XML da NFS-e por não ter assinatura digital não serve para nada, a unica informação valida que consta no XML é o código de verificação. Se o tomador desejar verificar se a nota foi realmente enviada, basta entrar no site e consulta-la através do código de verificação.

Boa tarde a todos, O problema é na SEFAZ e só vai ser resolvido se vocês que estão tendo o problema, entupirem a caixa postal da SEFAZ com mensagens acusando o problema.

João, Sim, existem provedores que não devemos assinar o RPS somente o Lote. Mas se a questão é validade jurídica em salvar o Lote pois esta contem a assinatura, como que fica o XML da NFS-e que em muitos os casos também não tem assinatura? Você vai salvar o XML da NFS-e sem assinatura da mesma forma, ou não?

Bom dia Edson, Você leu a minha resposta? Outra coisa, você postou em um lugar errado, aqui é um tópico que esta tratando sobre o mesmo erro mas na NFS-e e não na NF-e.

Bom dia Daniel, Primeiro eu mudaria esse processo. Deixaria para gerar o XML somente no momento do seu envio. Quem esta gerando novamente o XML do RPS não é o método Enviar e sim o LoadFromFile, inclusive ele possui uma propriedade para desativar esse "regerar".