Italo Giurizzato Junior

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".

Bom dia Fábio, Desculpe, não entendi a sua postagem. A unica diferença é a presença do prefixo no XML do RPS, o componente quando vai ler um XML ele remove todos os prefixos, desta forma ele consegue ler o XML de uma NFS-e com ou sem prefixos.

Bom dia João, Você salva no banco de dados o XML do lote de RPS a ser enviado? Em vez disso porque não salva o XML do RPS a ser enviado? E caso ele venha ser processado com sucesso em um outro campo você salva o XML da NFS-e retornada pelo provedor.

Boa noite Amilton, O meu conselho é você usar o programa exemplo para realizar testes e estudar o seu fonte. Depois faça a sua própria aplicação, com os form que você esta acostumado a construir. O programa exemplo grava as configurações em um arquivo INI, na minha aplicação esses dados de configuração são gravados no banco de dados. Sim, o ACBrNFeDANFeRL1 é para o fortes Report. Fica ai a dica.

Boa noite Glaucos, Maravilha, muito obrigado, já esta no repositório.

Boa noite Valcimar, Abra o arquivo Cidades.ini e inclua a cidade em questão da mesma forma que as demais do mesmo provedor.

Boa noite João, Exclua a unit e baixa novamente os fontes, depois compila novamente.

Boa noite Daniel, Não utilize o GravarXML, pelo seu relato ele não deve estar levando em consideração as diversas opções de configuração do provedor.

Boa noite Edson, Nas 3 primeiras imagens se refere ao tempo limite, o que você acha de aumentar o valor de Timeout? Já a última tela, notou que diz que ocorreu erro de validação na nota de numero zero? Acredito que neste caso o ADD esta sendo executado e consequentemente uma nota "em branco" esta sendo adicionada na lista de notas.

Boa tarde Ramalho, O componente esta configurado para salvar os XMLs em disco? O componente esta configurado para realizar a consulta logo após o envio?

Bom dia a todos, Hoje o fórum conta com mais de 48 mil membros, será que só nós Administradores e Moderadores temos a obrigação de estar com a leitura e interpretação correta de todos os manuais e notas técnicas publicadas nos portais nacionais e fazer as devidas alterações nos fontes dos componentes? Eu acredito que nesse universo de 48 mil, existem desenvolvedores com capacidade igual ou superior a nossa em realizar essas alterações, testa-las e disponibiliza-las para que todos possam usufruir. Quem não trabalha com o Delphi ou Lazarus, até entendo e neste caso peço que tenham paciência, mas, e os demais? Vamos ser mais colaborativos?

Glaucos, Muito obrigado pela colaboração, já enviei para o repositório.