everson.turossi

NFe_SVRS_H: NfeConsultaCadastro_4.00=https://cad-homologacao.svrs.rs.gov.br/ws/cadconsultacadastro/cadconsultacadastro4.asmx Já para o NFe_RS_H não existe url de homologação para esse serviço, até tentei algumas combinações mas não obtive sucesso, e se observar a url do NfeConsultaCadastro_2.00 ela é a url de produção. Indo mais afundo, acessando o link http://hom.nfe.fazenda.gov.br/portal/webServices.aspx?tipoConteudo=Wak0FwB7dKs=#SVRS apesar de não estar atualizado, a url listada para a versão 2.00 do NfeConsultaCadastro é a mesma de produção.

Estou fazendo testes e aparentemente está funcionando a consulta tanto para o RS quanto para o SVRS na versão 4.00. Como todos meus testes são em Homologação, gostaria de saber se não é possível adicionar na sessão NFe_RS_H e NFe_SVRS_H a url do NfeConsultaCadastro_4.00 no arquivo ACBrNFeServicos.ini. Percebi que tanto para o NFe_RS_H quando para o NFe_SVRS_H está adicionada a url do NfeConsultaCadastro_2.00 sendo que para esse caso só existe mesmo a url de produção.

Pesquisando na internet pelo assunto, encontrei um post relacionado a isso: Conversamos com o ENCAT, e deve sair uma NT retirando esta regra de validação, além disso, também, via um ajuste na questão pagamento do boleto, para aceitar a informação na TAG e não mais em ” infCpl”. Fonte: https://portalspedbrasil.com.br/forum/versao-nf-e-4-0-rejeicao-865-total-dos-pagamentos-menor-que-o-valor-total-da-nota/

Deu certo para mim esse procedimento.

Pelo que eu entendi, quando usar a HttpLib como httpOpenSSL ou httpWinHttp tem que configurar também a propriedade SSLType, se for NF-e 4.0 deve estar configurada como TLS 1.2

Definiu a propriedade SSLType para TLS 1.2 ?

Então, até pensei em um tópico para relatar a situação, mas como não consegui identificar com exatidão os passos que faço até que o erro aconteça acabei deixando passar batido, cheguei a pensar que fosse um problema isolado na minha máquina. Os passo que executo são os seguintes: - Abro o Delphi (não reclama de nada). - Abro um Projeto (não reclama de nada). - Fecho o Projeto sem fechar o Delphi. Agora que vem o pulo do gato, volto a abrir um projeto, podendo ser o projeto fechado anteriormente ou outro projeto qualquer (até mesmo um projeto que não utilize o ACBr) e nesse momento o erro "pode" acontecer, ou posso repetir esse processo mais 10 vezes e simplesmente não acontece nada. É totalmente aleatório, já tentei abrir e fechar o mesmo projeto várias vezes e nada aconteceu. Já tentei abrir e fechar projetos diferentes varias vezes e nada aconteceu, porém mesmo que de o erro, projetos que utilizem ACBr continuam compilando normalmente. Pra mim o erro pode vir a acontecer a partir do segundo projeto aberto sem que tenha fechado o Delphi e aberto novamente. Como isso estava me incomodando um pouco, peguei por habito fechar o Delphi sempre que precisar alternar entre projetos, mas se não me falha a memória, o erro era apresentado duas vezes para cada projeto, e se tentar abrir um Grupo de projetos com 10 projetos por exemplo, o erro seria apresentado 20 vezes. No momento estou utilizando Delphi Tokyo (10.2.2), Windows 10 x64. Não estou utilizando a ultima revisão disponível no Svn pois tenho algumas units modificadas para atender algumas necessidades. Assim que possível atualizarei os meus fontes para a ultima revisão ever se o problema continua acontecendo. Tenho instalado também a versão 2010, mas nela não está instalado o ACBr.

Resolvido aqui também. Valeu pela dica.

Tenta setar o Número do Centro de mensagens manualmente Listar Centro de Mensagens: AT+CSCA? Alterar Centro de Mensagens: AT+CSCA="+550101102010",145 O número em questão ali no meu exemplo é um dos Centros de mensagem da Vivo, basta procurar na internet qual o/os centros de mensagens da sua operadora e fazer a alteração via comando AT.

Grava ele no Banco sem o dígito verificador, e na hora de gerar a remessa, seta o nosso numero exatamente como faz quando imprime ele.

Recentemente em uma homologação do BB também implicaram com isso. No Fast a alteração é possível sem a alteração nos fontes do ACBr, porque isso ai nada mais é do que uma implicância de quem está homologando o boleto, que em alguns bancos isso é terceirizado. Existe um tópico antigo já tratando desse mesmo assunto em uma homologação da Caixa.

Utiliza Fortes ou Fast?

Dá uma olhadinha nesse vídeo do canal do Mourão, assiste a partir do minuto 38:30 onde é mostrada a ferramenta e como faz pra habilitar ela no projeto.

Recomendo o madExcept, faz a mesma coisa e é visual. Ao finalizar a aplicação ele mostra um detalhe de cada memory leak, possibilitando navegar até a linha de código aonde o objeto foi criado.

Complementando, aqui foi utilizado também a Leopardo A7.

Dá uma olhadinha neste tópico meu se te ajuda em algo. Aqui fizemos gerando uma imagem do DANFe em PNG a partir do Fast. Na pasta dos exemplos da NFe vai encontrar o arquivo DANFeSimplificado.fr3 o qual pode ser adaptado a sua necessidade sem necessidade de alteração nos fontes.

Obrigado Juliomar

Na unit ACBrCTeWebServices o objeto FCTeRetornoOS é criado no método Clear mas não está sendo destruído. Correção em Anexo. ACBrCTeWebServices.pas

Estava com o mesmo problema de "Função incorreta" em uma impressora de etiquetas, aplicando a sua dica deu certo. Obrigado.

Aqui deu certo, apenas um adendo, na pasta ACBrCTe tem os arquivos ACBrCTeServicos.ini e ACBrCTeServicos.res certo, o .RES teria que ser recompilado pois não consta nele ainda as urls do webservice CTeDistribuicaoDFe.

Não aceita enviar com acentos ou está substituindo os caracteres acentuados por outros? E se serve de consolo, as mensagens de serviço enviadas pelas operadoras Vivo e Tim não possuem acentuação. Agora em relação aos seus formulários, confere ai que que você pode estar trabalhando com múltiplas instâncias do componente ACBrSMS.

Boa tarde, concordo plenamente.

Na grande maioria dos bancos, independentemente da Ocorrência, o campo ValorPago só traz valor quando realmente foi pago. Mas Sicoob e Sicredi resolveram bagunçar isso e trazer valores mesmo quando não se tratar de Liquidação. Agora identificar efetivamente o que estão mandando no campo ValorPago já é mais complicado, porque já peguei retorno em que vem a Taxa, e em outro vem o Valor do Documento. Isso em retornos de clientes Diferentes é claro.

Já passei por inúmeras bizarrices do gênero e uma pratica adotei sempre que algo anormal acontecer é apagar o arquivo .dproj e similares, que a cada nova versão do Delphi vão aparecendo novos, e então reabrir o projeto a partir do .dpr para que sejam recriados. Acontece que o que foi citado pelo Juliomar diversas vezes como "configuração do projeto" ficam gravadas no .dproj então pouco adiante formatar maquina, reinstalar Delphi e ACBr se o arquivo problemático continua existindo.

Também me deparei com a mesma situação em relação a Protesto em Dias Úteis, todavia não podemos esquecer que a simples alteração na instrução de protesto impressa no boleto precisa ser condizente com a instrução de protesto da remessa. E é ai que a coisa se complica pois cada banco tem suas particularidades, alguns possuem opção para informar se será em dias úteis ou dias corridos, outros pedem a data de protesto, outros por "primeira ou segunda Instrução/Comando" e talvez eu tenha esquecido mais alguma. Infelizmente a única maneira de resolver tal situação integralmente seria a revisão de todas as Units de geração de remessas baseando-se na ultima versão do layout de cada tipo de cobrança para cada Banco, o que complica é reunir todos os layouts atualizados, pois a maioria dos Bancos não o disponibilizam em seus sites, e ao solicitar junto ao gerente de alguma agência, nem sempre lhe enviam a versão mais recente.