Italo Giurizzato Junior

Boa noite Luiz, O componente ACBrCTe esta sendo criando em tempo de execução ou ele se encontra em um Form ou Data Module?

Boa noite, Chequei o manual e tens razão, correção feita.

Boa noite Leonardo, É preciso que fique claro que o CT-e OS modelo 67 é destinado as empresas de transporte de valores, fretamento e empresas que cobram por transportar bagagem extra, como é o caso das empresas aéreas. As empresas transportadoras de cargas continuam a emitir o CT-e modelo 57.

Boa noite, Neste caso é preciso "debugar" para ver se o componente esta removendo os acentos das vogais e trocando o cedilha por "c".

Boa noite Marcos, Favor atualizar os fontes novamente e refaça os testes.

Mas essa linha: ACBrNFSe1.WebServices.ConsNFSeRps.RetornoNFSe.ListaNFSe.CompNFSe.Items[0].NFSe.Numero ; é para pegar o retorno do Consultar NFS-e por RPS.

Bom dia, Essa consulta que você fez é o Consultar a NFS-e por RPS e não o Consultar Lote. Tentou com o Consultar Lote?

Bom dia a todos, Usando o programa exemplo fiz um teste. Deixei a propriedade SSLLib com o valor libCapicom, usei o método Gerar, como estou usando um certificado de uma empresa que não é contribuinte de Porto Alegre, consequentemente o RPS foi rejeitado. Mas o envio e o retorno com a rejeição ocorreram sem nenhum problema em ambiente de homologação.

Bom dia BigWings, Muito obrigado pela correção, ainda hoje vou enviar para o repositório.

Boa dia a todos, Favor atualizar os fontes e testar novamente.

Boa noite André, No XML do RPS não existe mesmo essas duas Tag, pois elas fazem parte da estrutura do Lote de RPS. Fiz alterações recentes nos fontes do componente, favor atualizar todos os fontes de todas as pastas e refaça os testes.

Boa noite Sidnei, Tentou mudar a configuração SSLLib?

Boa noite Mauricio, Vou analisar.

Boa noite Felipe, Obrigado pela colaboração, vamos avaliar e se tudo estiver OK vamos disponibilizar.

Boa noite Maiquel, Se você puder fazer a alteração e anexar o arquivo aqui para que possamos avaliar, ficaremos gratos.

Boa noite Rubens, Anexe a unit alterada para que possamos avaliar.

Boa noite a todos, Ainda não tive tempo de realizar testes com as diversas opções.

Boa noite, Este link não esta acessivel.

Boa noite, Acredito que vamos ter que renomear o Actconv2.ini para Actconv201.ini e para Juiz de Fora criar o Actconv202.ini Após o envio esta sendo realizada a consulta do lote?

Boa noite Juliana, Anexe os XML gerados para que possamos analisar.

Boa noite Thiago, Fiz uma alteração, agora o campo tpTransp passa aceitar o valor ttNenhum, neste caso a tag não será gerada. Ainda hoje estarei enviando essa alteração para o repositório.

Boa noite, Você deve enviar o EPEC (que é um evento) e depois imprimir o mesmo, através do método ImprimirEvento. Imprimir o DACTE e "grampear" com o evento. Desta forma quem vier a questionar a falta de protocolo no DACTE vai notar que existe o EPEC e este foi enviando para SEFAZ. Assim que os problemas forem sanados o XML do CT-e deve ser enviado para SEFAZ. Desta forma a SEFAZ "da baixa" no EPEC. Por fim o XML com o protocolo bem como o DACTE com o protocolo deve ser enviado ao tomador do serviço. Te aconselho que leia atentamente as Notas Técnicas: 2013/003 e 2013/008, ambas tratam sobre o EPEC.

Boa noite, As mensagens referentes as rejeições são geradas pela SEFAZ e constam nos XML de retorno, veja o exemplo abaixo: <retCTeOS versao="3.00" xmlns="http://www.portalfiscal.inf.br/cte"> <tpAmb>2</tpAmb> <cUF>42</cUF> <verAplic>RS20170502140138</verAplic> <cStat>225</cStat> <xMotivo>Rejeição: Falha no Schema XML do CT-e</xMotivo> </retCTeOS> Note que temos a tag <cStat> que contem o código da rejeição e a sua descrição esta na tag <xMotivo>.

Boa noite Cleonir, Favor atualizar os fontes e refaça os testes.

Boa noite Lucas, Não existe nenhum método especifico para salvar XML de eventos ou Inutilização, esses XML são salvos ou não conforme configuração do componente.