Italo Giurizzato Junior

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

Everton, Quem esta enviando esse evento? É o tomador de SC ou o emitente do CT-e de SP? Tem coisa estranha pois no retorno temos a versão do aplicativo (webservice) com o seguinte valor: SP-CTe-26-02-2018. Isso me leva a crer que o envio do evento esta sendo feita para a SEFAZ-SP.

Rogério, Se esta tudo atualizado então a sua aplicação esta usando um arquivo Salvador.ini desatualizado, pois no que esta no repositório temos: [Assinar] RPS=1 Lote=1 URI=0 O valor zero em URI instrui o componente a deixar o valor do atribui URI vazio.

Bom dia Renato, Essa alteração já foi realizada e já consta no repositório, favor atualizar os seus fontes.

Bom dia Carlos, Favor anexar a unit alterada para que possamos analisar.

Bom dia Walter, Você esta com todos os fontes atualizados?

Everton, A UF do emitente do CT-e é 35, ou seja, SP. Qual é a UF do tomador? Uma vez que esse evento é enviado pelo tomador a SEFAZ.

Bom dia a todos, O Provedor IssDSF não tem o envio síncrono somente o envio assíncrono, dai a mensagem de erro.

Bom dia Rogério, Você esta com todos os fontes atualizados, inclusive os arquivos INI? A sua aplicação esta usando o arquivo Salvador.INI atualizado, ou seja, o que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI E o que é correto, o atributo URI ser vazio tanto na assinatura do RPS quanto do Lote, ou não?

Bom dia Paulo, Essa cidade esta usando o novo WebService que segue o layout da ABRASF, correto? Se sim, com certeza fizeram alguma kaka. Tem que entrar em contato com eles e apontar todos os problemas. Lembre-se sempre, o componente apenas gerar e envia o XML do RPS. Por outro lado o XML da NFS-e é gerado pelo WebService. Logo o problema é no WebService e não no componente.

Bom dia Marcílio, Favor anexar os XMLs de envio e de retorno.

Bom dia Marcelo, Primeiramente peço desculpa pela demora em responder. O componente ACBrNFSe possui um método chamado Enviar que realiza o envio de um lote contendo de 1 até 50 RPS no modo assíncrono. A principio esse método envia e aguarda o retorno, que contem apenas o numero do protocolo que acusa que o lote foi recebido pelo WebService do provedor. Mas se você atribuir o valor True a propriedade de configuração: ConsultarLoteAposEnvio, o componente após obter o numero do protocolo vai Consultar a Situação do Lote (método este utilizado somente pelos provedores que seguem a versão 1 do layout da ABRASF) caso o retorno seja 3 ou 4, o componente realiza a Consulta ao Lote. Ao Consultar o Lote, teremos como resposta a lista de rejeições caso a situação seja 3 - Lote processado com erro, ou a lista das NFS-e caso a situação seja 4 - Lote processado com sucesso. Se o componente estiver configurado para salvar os XMLs em disco, ele se encarrega de extrair do retorno (método Consultar Lote) as notas e salvar separadamente. O método Enviar possui dois parâmetros: Enviar(aLote: Integer / String; Imprimir: Boolean) O primeiro parâmetro aLote é o numero do lote que estamos enviando e deve estar no formato Integer ou String. O segundo parâmetro Imprimir por padrão vale True, isso faz com que o DANFSE seja impresso automaticamente desde que a propriedade ConsultarLoteAposEnvio tenha o valor True também. Se você não quer que o DANFSE seja impresso automaticamente, deve-se então usar o método Imprimir. Mas lembre-se o DANFSE foi feito para imprimir o conteúdo do XML da NFS-e e não o conteúdo do XML do RPS. Sendo assim devemos primeiro carregar o XML *-nfse.xml através do método LoadFromFile antes de executar o método Imprimir. Espero ter ajudado.

Bom dia Everton, Favor configurar o componente para salvar os arquivos soap. Refaça o envio e anexe os arquivos: *-ped-eve-soap.xml e *-eve-soap.xml