Ronaldo Negreiros Danieli

Pessoal o Bradesco me enviou o ClientID e ClientKey então vou começar a minha saga também. No entanto me mandaram um novo leiaute que trata justamente dos trâmites de acesso as APIs, eu olhei as postagens aqui do tópico e acho que ninguém enviou então estou compartilhando pois vai que tem alguma informação nova já que é de fevereiro/2024. Na próxima semana já terei alguns resultados e compartilho aqui também. Manual do desenvolvedor v5.0.pdf

Bom dia, as URLs para emissão de NFS-e do provedor Fiorilli de Jaú/SP foram alteradas. As novas URL's para o arquivo INI são: ProRecepcionar=http://servicos.jau.sp.gov.br:8090/IssWeb-ejb/IssWebWS/IssWebWS ProLinkURL=http://servicos.jau.sp.gov.br:8090/issweb/gerarnfse.jsf?nroNota=%NumeroNFSe%&codVerificacao=%CodVerif%&cnpj=%Cnpj%&hash=%ChaveAcesso% Conforme noticiado pelo próprio site da prefeitura: http://servicos.jau.sp.gov.br:8090/issweb/home

Daniel as propriedades estão vindo preenchidas corretamente. Eu que acabei fazendo a lógica errada aqui, em outros bancos existe uma ocorrência específica para liquidação em cartório e isso não ocorre com o Sicoob. Mas olhei tanto os fontes e realmente o ACBr já faz a leitura desses códigos de rejeição nas propriedades que você listou acima. Vou ter que criar uma condição aqui pra verificar esses códigos mesmo quando é 06-Liquidação para identificar o pagamento em cartório. Então basta desconsiderar os arquivos enviados que eu faço os ajustes aqui e me desculpe pela confusão.

Bom dia, Eu não tinha percebido esse detalhe, de que pode haver até 5 ocorrências, enviei os arquivos de retorno conforme solicitado. Obrigado.

Bom dia, Percebi um problema com o retorno do Banco Sicoob (756), tenho um cliente que teve vários títulos pagos em cartório, porém o Sicoob não tem uma ocorrência específica para liquidação em cartório, tudo volta como 06 - Liquidação, independente de como foi pago. E isso é um problema visto que é preciso diferenciar o que foi pago em cartório. Analisando o leiaute CNAB 240 e o retorno recebido do banco vi que eles fazem essa identificação em outra posição do registro T (posição 214 a 223). Quando a liquidação é em cartório, vem o código 0000000008. Agora verificando a leitura do retorno pelo ACBr vi que essa informação é tratada através da propriedade CodigoLiquidacao, porém está pegando as posições erradas (214 a 215) ao invés de (214 a 223). Estou enviando o fonte corrigido e o leiaute do Sicoob para conferência. 2 - Layouts_para_troca_de_informações - V13.xlsm ACBrBancoBancoob.pas

Lá vou eu tentar novamente então. Obrigado.

Você conseguiu as credenciais com o gerente ou precisou ligar em algum 0800? Eu tentei com meu gerente aqui e ele não conseguiu.

Pode estar ficando diferente por conta dos comandos "tr" no final. tr -d '=[:space:]' nesse trecho são retirados todos os espaços e simbolos de = tr '+/' '-_' e aqui o comando substitui + por - e / por _

Alexandre acabei de atualizar e testar, está funcionando perfeitamente. Obrigado.

Obrigado.

Bom dia, Os fontes do ACBr não estão lendo o segmento Y (QRCode PIX) do retorno no formato CNAB 240 do Santander. Fiz os ajustes necessários e estou enviando o fonte corrigido em anexo. ACBrBancoSantander.pas

Sim, estava desatualizado mesmo. Mas já fiz a atualização aqui, está resolvido. Muito obrigado.

Bom dia, Migrando do componente ACBrNFSe para o ACBrNFSeX e percebi um problema com o provedor CONAM. A linha 346 do arquivo Conam.Provider.pas está da seguinte forma: xOptante := '<TipoTrib>4</nfe:TipoTrib>' + A rejeição é justamente pela tag estar abrindo de uma forma e fechando de outra. Mudando para o código abaixo o problema é resolvido.Conam.Provider.pas xOptante := '<TipoTrib>4</TipoTrib>' + Segue unit corrigida em anexo. Obrigado.

Boa tarde, Não encontrei área específica para o componente ACBrPagFor, então estou postando aqui. Utilizei o componente para gerar arquivos para o banco Santander e foi necessário realizar alguns ajustes no código fonte ao ler o arquivo de retorno do banco. Estou anexando os arquivos com as correções já efetuadas e o leiaute que foi utilizado. Inclusive inclui todas as descrições de ocorrência de retorno conforme leiaute no em função específica no arquivo ACBrPagForConversao.pas ACBrPagForConversao.pas ACBrPagForLerTxt.pas Pagamento a Fornecedores Layout CNAB 240 - v11.2 - Indicador Pix.pdf

Segue em anexo a versão com a correção. ACBrBancoSantander.pas

Boa tarde, Já fazia alguns meses que eu não atualizava o código fonte do ACBr e ao fazê-lo vi que foram refatoradas várias classes (a grande maioria talvez). Tenho clientes que fazem emissão de boletos pelo Santander usando código de carteira 1 e com as mudanças isso parou de funcionar. Anexei o leiaute e na página 8 constam as seguintes opções de carteira: 1 = ELETRÔNICA COM REGISTRO 3 = PENHOR ELETRÔNICA 5 = RÁPIDA COM REGISTRO (BOLETO EMITIDO PELO CLIENTE) 6= PENHOR RÁPIDA 7 = DESCONTO ELETRÔNICO Olhando o log de alteração do SVN a mudança ocorreu da revisão 20300 para a 20301. Antes no início do método "GerarRegistroTransacao400" constava: aCarteira := StrToIntDef(ACBrTitulo.Carteira, 0 ); e foi alterado para: aCarteira := StrToIntDef( DefineCarteira(ACBrTitulo) , 0); O método DefineCarteira só permite o uso das carteira 5, 6 e 4 (a carteira 4 não consta na versão do leiaute em anexo, mas isso pode constar em versões mais novas ou mais antigas). Como antes era possível definir o código da carteira direto no componente então funcionava corretamente. A solução é alterar o código fonte do método DefineCarteira para trabalhar da seguinte maneira: if ((Carteira = '101') or (Carteira = '005')) then Result := '5' else if ((Carteira = '201') or (Carteira = '006')) then Result := '6' else if ((Carteira = '102') or (Carteira = '004')) then Result := '4' else if (Carteira = '001') then Result := '1' else if (Carteira = '003') then Result := '3' else if (Carteira = '007') then Result := '7'; H7800 Layout CNAB 400 com registro (padrão 353) Setembro 2017 v 2.17.pdf

Boa tarde, Se ainda estiver vendendo me envie um orçamento para [email protected]

Boa tarde, Fiz a atualização aqui e está funcionando perfeitamente. Obrigado!

Boa tarde, Segue em anexo outras 2 possíveis soluções para o problema e nesse caso a unit alterada é a ACBrInstallUtils.pas Em ambos os arquivos a função alterada foi a "PathSystem". Em anexo está: ACBrInstallUtils.Solucao1.pas - Nesse arquivo foi alterado a chamada da API GetWindowsDirectory para a GetSystemWindowsDirectory que conforme documentação da Microsoft retorna a pasta correta em ambos os casos (sistema single-user ou multi-user): "With Terminal Services, the GetSystemWindowsDirectory function retrieves the path of the system Windows directory, while the GetWindowsDirectory function retrieves the path of a Windows directory that is private for each user. On a single-user system, GetSystemWindowsDirectory is the same as GetWindowsDirectory." Fonte: https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getsystemwindowsdirectoryw ACBrInstallUtils.Solucao2.pas - Nesse arquivo foi incluída uma nova função chamada IsRemoteSession que retorna se a aplicação está rodando em uma sessão de terminal server e caso afirmativo a pasta Windows é retornada através da variável de Ambiente "WINDIR". Acredito que essas alterações são melhores do que a postada anteriormente. ACBrInstallUtils.Solucao1.pas ACBrInstallUtils.Solucao2.pas

Boa tarde Elton, Sim eu vi esse detalhe e no entanto mesmo assim a aplicação funcionou corretamente lendo/gravando o arquivo INI e recuperando corretamente o local da pasta Windows. Uma outra alternativa seria modernizar a chamada da API pois GetWindowsDirectory/SHGetFolderPath não funcionarão nesse caso. O que pode-se tentar fazer somente nesse caso (pois há como detectar se o aplicativo está sendo executado em ambiente de terminal) seria ler a variável de ambiente WINDIR. Vou enviar uma outra versão com o código alterado para que possam verificar se a solução é melhor.

Boa noite, Ao tentar instalar o ACBr utilizando o instalador (ACBrInstall_Trunk2) em um Windows Server 2012 R2 (estando conectado através de remote desktop) dá um erro no fim da instalação dizendo que o diretório de sistema não foi encontrado. Depois de fazer algumas buscas na internet entendi o porquê: "With Terminal Services, the GetSystemWindowsDirectory function retrieves the path of the system Windows directory, while the GetWindowsDirectory function retrieves the path of a Windows directory that is private for each user. On a single-user system, GetSystemWindowsDirectory is the same as GetWindowsDirectory." E é o que acontece aqui comigo, ao invés de retornar "C:\Windows" a função GetWindowsDirectory retorna "C:\Users\<usuario>\WINDOWS". A solução é bem simples e consiste em setar uma flag no arquivo DPR do projeto. {$SetPEOptFlags IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_AWARE} Estou encaminhando em anexo o arquivo corrigido para que o repositório possa ser atualizado. E peço desculpas se estou postando no local errado, não encontrei nada específico para o instalador. ACBrInstall_Trunk2.dpr

O meu continua bloqueado aqui, mas pelo que li no site da SEFAZ tem que rodar um tal de COMANDO 001 no SAT. Estou tentando descobrir como se faz isso.

Boa tarde, Também estou com um D-SAT 2.0 da Dimep (homologação) bloqueado desde o começo de 2020. Pelo jeito a solução é aguardar mais um pouco.

Existiam alguns problemas nos webservices de homologação da SEFAZ-SP (geravam erro HTTP 500), mas já foram corrigidos. Apesar da versão do schema estar voltando com os dados antigos, aqui está funcionando corretamente, creio que irão corrigir isso também. <retConsSitNFe xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <tpAmb>2</tpAmb> <verAplic>SP_NFE_PL009_V4</verAplic> <cStat>100</cStat> <xMotivo>Autorizado o uso da NF-e</xMotivo> <cUF>35</cUF> <dhRecbto>2017-08-30T09:16:09-03:00</dhRecbto> <chNFe>35170811690519000165550010000007001000000012</chNFe> <protNFe versao="3.10"> <infProt> <tpAmb>2</tpAmb> <verAplic>SP_NFE_PL_008i2</verAplic> <chNFe>35170811690519000165550010000007001000000012</chNFe> <dhRecbto>2017-08-30T09:13:48-03:00</dhRecbto> <nProt>135170003276466</nProt> <digVal>UXFdP/hl6U3wDThnHeFQLJCVoNI=</digVal> <cStat>100</cStat> <xMotivo>Autorizado o uso da NF-e</xMotivo> </infProt> </protNFe> </retConsSitNFe>

Boa tarde Italo, Ainda estou testando alguns webservices, porém no WS de Status de Serviço continua gerando o erro HTTP 500. Testando o webservice pelo SoapUI vi que a consulta funciona: Mas vi que o envelope soap que está sendo gerado pelo SoapUI com base no WSDL do webservice está diferente do gerado pelo ACBr. No envelope aceito pela SEFAZ-SP está o namespace "NFeStatusServico2" ao invés do "NFeStatusServico4" que é o que está sendo gerado pelo ACBr: Alterando o namespace no envelope gerado pelo ACBr, o webservice responde corretamente. No entanto creio que isso não seja um problema nos fontes do ACBr, acho que a SEFAZ-SP que ainda não acertou esse detalhe, então vou enviar um e-mail pra eles questionando isso. Além disso ainda não há menção no site da SEFAZ-SP com relação aos webservices da versão 4.0 (https://www.fazenda.sp.gov.br/nfe/url_webservices/url_webservices.asp), então eles podem estar mexendo nisso ainda.