Jump to content

dia-do-acbr-online.png

Ganhe acesso a todas Palestras
Assinando o Suporte ACBr Comerecial

Saiba Mais


dia-do-acbr-online.png

logo_acbr_paygo.png

TEF ACBr PayGo
Seja um revendedor e ofereça uma solução completa para seu cliente.


botao.png

beneficios.png

Ronaldo Negreiros Daniel

Membros
  • Content Count

    63
  • Joined

  • Last visited

Community Reputation

19 Good

About Ronaldo Negreiros Daniel

  • Rank
    Membro
  • Birthday 06/14/1980

Contact Methods

  • Skype
    rnegreiros

Profile Information

  • Sexo
    Masculino
  • Location
    Jaú - SP

Recent Profile Visitors

985 profile views
  1. Segue em anexo a versão com a correção. ACBrBancoSantander.pas
  2. 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
  3. Boa tarde, Fiz a atualização aqui e está funcionando perfeitamente. Obrigado!
  4. 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 GetW
  5. 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.
  6. 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
  7. 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.
  8. 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.
  9. 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> <ch
  10. 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 enta
  11. 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.
  12. 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>&
  13. 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.
×
×
  • Create New...