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

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 _

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.

Apesar de alguns webservices estarem funcionando, me parece que a SEFAZ-SP ainda não os disponibilizou oficialmente. Tanto que verificando o WSDL de alguns dos serviços as informações não estão no padrão da NF-e 4.0. No momento creio que é só aguardar, logo esses webservices devem estar corretamente no ar.

Estou com o mesmo problema, pelo que eu estou vendo aqui, o problema é o SoapAction. Estou tentando resolver aqui mas ainda não consegui. Mas dá uma olhada no que está retornando do servidor, pra mim volta o seguinte do servidor de SP: <?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Body><soap:Fault><soap:Code><soap:Value>soap:Sender</soap:Value></soap:Code><soap:Reason><soap:Text xml:lang="en">Unable to handle request without a valid action parameter. Please supply a valid soap action.</soap:Text></soap:Reason><soap:Detail /></soap:Fault></soap:Body></soap:Envelope>

Eu que agradeço Italo!

Juliomar, acredito que não pois foi alterada apenas uma função específica para esse provedor dentro do arquivo, onde a leitura do arquivo XML estava com problemas. Basta comparar a unit em anexo com a versão atual que se encontra no repositório do ACBr para ver a diferença.

Anexado, obrigado! pnfsNFSeR.pas

Atualizei os fontes agora e vi que o código acima ainda está incorreto no repositório. Se puderem corrigir, ajudaria muito

Boa tarde, Estou fazendo os ajustes para esse provedor, e percebi um problema na leitura do arquivo XML. no arquivo pnfsNFSeR.pas, onde é feitura a leitura do endereço do tomador a tag está incorreta (linha 3039 - revisão 12864), além disso não está carregando o complemento do endereço: Endereco := Leitor.rCampo(tcStr, 'DesEndTmd'); Correto: Endereco := Leitor.rCampo(tcStr, 'LogTom'); Complemento := Leitor.rCampo(tcStr, 'ComplEndTom');