Jump to content

Delphi Enterprise 
pela METADE DO PREÇO

botao_delphi.png

 

 

tp_550_logo.png Homologação ACBr Apresenta:
Nova  Impressora
TP-550

botao_saibamais.png

 

 

Curso Dominando o ACBrMonitor
Novo Módulo Soluções de Varejo
Assine o SAC ACBr em qualquer plano e tenha acesso

Saiba Mais

Balança SM100 performance surpreendente

Tecnologia Japonesa   Teclado e Visor resistentes a água
Consumo inteligente de etiquetas   Baixo custo de manutenção
Comunicação Ethernet e WIFI independentes

Saiba Mais

Impressora de Etiquetas ELGIN - L42 PRO

Protocolos PPLA, PPLB, ZPL, EPL (automático)
Porta USB padrão Opcionais: Ethernet, Serial, Paralela
Sensor de Etiquetas Móvel Garantia de 18 meses

Saiba mais

Ronaldo Negreiros Daniel

Membros
  • Content Count

    60
  • 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
  • Localização
    Jaú - SP

Recent Profile Visitors

931 profile views
  1. Boa tarde, Fiz a atualização aqui e está funcionando perfeitamente. Obrigado!
  2. 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
  3. 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.
  4. 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
  5. 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.
  6. 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.
  7. 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>
  8. 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.
  9. 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.
  10. 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>
  11. 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.
  12. Atualizei os fontes agora e vi que o código acima ainda está incorreto no repositório. Se puderem corrigir, ajudaria muito
  13. 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');
×
×
  • Create New...