Italo Giurizzato Junior

Bom dia a todos, Na página 30 do Manual do CT-e versão 3.0 temos uma tabela com uma lista dos eventos. A quarta coluna dessa tabela indica que é o autor do evento, ou seja, quem deve gerar e enviar o evento. Vamos a alguns exemplos: Carta de Correção e Cancelamento note que o autor do evento é a Empresa Emitente, ou seja, quem emite o CT-e. Por outro lado o evento: Prestação de Serviço em Desacordo é Tomador. Sendo assim o tomador tem que possuir uma aplicação capaz de gerar e enviar o evento para a SEFAZ-Autorizadora.

Bom dia Paulo, A Carta de Correção é um evento. Quando enviamos qualquer evento é gerado um XML chamado: *-ped-eve.xml e o retorno da SEFAZ é salvo em outro XML chamado: *-eve.xml Se o evento foi homologado pela SEFAZ, temos um terceiro XML chamado: *-procEventoCTe.xml É esse o XML que você deve enviar por e-mail. E para isso temos o método EnviarEmailEvento.

Boa noite André, Quanto ao certificado A3 iremos analisar. Com relação ao campo Informações Complementares, a resposta é simples: Não existe esse campo no layout do RPS, logo ele não vai ser gerado. Ele existe no layout da NFS-e cujo XML é gerado pelo provedor e ele põe nesse campo o que a prefeitura mandar, caso contrario não será gerado nada também.

Boa noite Davi, Muito obrigado pelo retorno e pela colaboração, já enviei para o repositório.

Boa noite André, O retorno do provedor é muito vago, uma vez que devemos assinar o RPS e o Lote, se o mesmo tiver 50 RPS, teremos 51 assinaturas. Agora te pergunto, com essa resposta do provedor: "Arquivo enviado com erro na assinatura." qual das assinaturas esta errada? A do RPS ou do Lote?

Boa noite José, O componente esta configurado para salvar os arquivos de envio e de retorno? Você esta fazendo os testes com o programa exemplo?

Boa noite Rodrigo, Por favor não poste como texto trechos grandes de código, procure sempre colocar em um arquivo TXT e anexar para que possamos analisar. Desta forma a postagem fica mais clara e curta.

Boa noite Márcio, Muito obrigado, já analisei e ainda hoje estarei enviando para o repositório.

Boa tarde, Muito obrigado pela correção, já enviei para o repositório.

Boa tarde Davi, No caso do provedor Bethav2 se faz necessário assinar o RPS também?

Boa tarde Márcio, Favor anexar a Unit alterada para que possamos analisar e realizar o merge caso esteja tudo OK.

Boa tarde Rogério, Favor solicitar a prefeitura um XML completo de envio do lote, com a tag Envelope. Para que possamos analisar e tentar descobrir onde pode estar errado.

Boa tarde Edson, Nesse cliente foi atualizado o arquivo SP.ini ?

Boa tarde Windel, O arquivo de consulta gerado pelo componente como estão essas datas, elas são iguais? Os nomes das tags referente as datas estão corretas? Se a resposta for sim para as duas perguntas acima, então o problema é no provedor.

Boa tarde, Favor entrar em contato com a prefeitura para saber se eles tem um XML a titulo de exemplo.

Boa tarde, Favor não postar código muitos extensos como texto na postagem. Procure sempre anexar um arquivo TXT com o respectivo código. Desta forma a postagem fica curta. Quanto a rejeição, você deve entrar em contato com a prefeitura e com o provedor para saber qual é código correto.

Boa tarde, Onde você achou isso? Esse XML esta totalmente fora do que consta no Manual do CT-e versão 3.00 Lembre-se a Prestação de Serviço em Desacordo é um evento como, Carta de Correção, Cancelamento entre outros. O layout do XML já esta implementada na unit referente ao envio de eventos do componente ACBrCTe. Você deve se basear nos Manuais e Notas Técnicas publicadas pelo ENCAT e disponibilizadas no Portal Nacional do CT-e. Na página 114 do Manual do CT-e versão 3.00 você encontra informações sobre o respectivo evento. Não precisa implementar nada no componente, já esta tudo pronto. O que você precisa fazer é criar uma rotina na sua aplicação que vai pedir ao usuário a chave do CT-e e a observação do tomador a respeito desse evento. Alimentar o componente (vide outras rotinas que enviam eventos). E enviar o evento. Não sei se ficou claro

Boa noite Renato, Fiz uma correção e vou enviar para o repositório. Depois você atualiza os fontes e faça um novo teste.

Lendo as regras que se encontram no Manual do CT-e versão 3.00 se o tomador for contribuinte após ele emitir um evento de Prestação de Serviço em Desacordo a transportadora poderá emitir um CT-e de Anulação. veja: CT-e de anulação para CT-e com tomador contribuinte exige evento de Prestação de Serviço em Desacordo

Boa tarde Graça, No componente ACBrANe não foi feito nenhuma alteração. No caso do CT-e os WebServices agora só estão aceitando conexão TLS 1.2 e pelo que vi você esta passando a mesma configuração para o ANe. Tente separar essas configurações.

Boa tarde, No meu entendimento, neste caso tem que cancelar o CT-e, caso tenha passado do prazo, solicitar junto a SEFAZ a autorização para o cancelamento extemporâneo.

Boa noite Rogerio, Lhe peço para que não escreva tudo em caixa alta, da impressão que você esta gritando.

Boa tarde Rodrigo, Em vez de atribuir o valor 3 a propriedade alíquota, atribua o valor 0,03, ou seja, 3 dividido por 100.

Boa tarde Paulo, Os provedores que seguem a versão 1 do layout da ABRASF tem os seguintes serviços implementados em seus WebServices: Enviar, Consultar a Situação do Lote, Consultar o Lote, Consultar NFS-e por RPS, Consultar NFS-e e Cancelar. Já os provedores que seguem a versão 2 do layout da ABRASF (que o caso da E&L) tem os seguintes serviços implementados em seus WebServices: Enviar, Consultar o Lote, Consultar NFS-e por RPS, Consultar NFS-e, Cancelar, Substituir, Enviar Síncrono e Gerar NFS-e. Como você pode ver o serviço Consultar a Situação do Lote não existe na versão 2. O componente quando configurado para Consultar o Lote após o envio (ConsultarLoteAposEnvio := True) detecta a versão e executa ou não a consulta a situação do lote. Espero ter ajudado.

Carlos, Obrigado, vamos analisar, caso esteja tudo OK, vamos enviar para o repositório. Desde já muito obrigado pela colaboração.