Ir para conteúdo
  • Cadastre-se
Notícias do ACBr
  • Vem ai...
  • Dia do ACBr
  • Clique Aqui para acessar a Página do Evento
  • Primeiro lote válido até 25/09/2018

Alexsander

Membros
  • Total de ítens

    379
  • Registro em

  • Última visita

  • Days Won

    2

Alexsander last won the day on 25 Março 2013

Alexsander had the most liked content!

Reputação

6 Neutro

1 Seguidor

Sobre Alexsander

  • Rank
    Membro Ativo

Profile Information

  • Localização
    Porto Alegre, RS

Últimos Visitantes

O bloco dos últimos visitantes está desativado e não está sendo visualizado por outros usuários.

  1. Procurei no SVN e não achei nada referente a isto no ACBrMonitorPLUS, alguém sabe se esta nova propriedade chegou a ser implementada?
  2. Pelo que entendi o ACBrMonitorPLUS simplesmente não funciona no Windows Server 2008, é isso?
  3. Retomando: este é o único problema que ainda está incomodando, mesmo dentro de um bloco try ... except a aplicação dá CRASH exatamente na chamada da Enviar ( ) após imprimir, via "GerarLog", a mensagem que mencionei acima. Pelo que pudemos observar isto só ocorre quando há uma queda de Internet e o cliente tem uma redundância 3G/4G com muita perda de pacotes; não chega a cair a Internet mas a perda é enorme. É bem difícil reproduzir, conseguimos um "Vivo Box" para testar e tivemos que deixar vários downloads simultâneos para simular a conexão.
  4. No Linux (Ubuntu 16.04 LTS 64-bits) ocorre o mesmo problema, também esporadicamente. Coloquei uma GerarLog e trava na seguinte mensagem: Inicio TNFeRecepcao Num cliente que emite mais de 10.000 cupons/dia ocorre umas 10 vezes por dia.
  5. Quando enviei código para esta mesma classe ACBrETQ, em 2009 e 2010, tomei cuidado para não causar uma "breaking change"; se for possível ver no fórum ou SVN antigo vão ver que mantive valores padrões para as novas propriedades e procedures criadas de forma que os códigos existentes não parassem de funcionar. Por exemplo, ao incluir o parâmetro "SubFonte" na procedure "ImprimirTexto" lembro que coloquei um valor default na definição. Desta forma, os códigos que não passavam este parâmetro seguiram funcionando sem alterações. Não se trata de manter o que está errado mas sim de não quebrar o que está funcionando. Estou aqui tentando fazer uma crítica construtiva, consciente de que faz anos que não envio código para o ACBr. Seria interessante deixar o "jeito antigo" como default de alguma forma, sem forçar todo mundo a mudar um grande volume de seus códigos. Veja o quanto de suporte esta alteração gerou...
  6. Acho temerário fazer uma "breaking change" como essa alterando um default. Talvez tivesse sido mais seguro usar uma Unidade "etqLegado" para funcionar como era antes e deixar como default. Confesso que não entendo o motivo desta alteração ter sido feita desta forma.
  7. Vocês têm certeza que esta alteração está correta? Vou ter que retornar aqui ao jeito antigo, pois eu gravo o dígito junto com o NossoNumero no banco de dados. Na Remessa são gerados 8 dígitos (7 do RightStr + 1 do DigitoNossoNumero) Linha 705: PadLeft(RightStr(NossoNumero,7),7,'0') + DigitoNossoNumero + // 63 a 70 Agora, na versão que está no SVN, o Retorno passou a ler apenas 7 dígitos: Linha 1053: NossoNumero := Copy(Linha,63,07); Até os comentários estão corretos: eram 8 dígitos (do 63 ao 70). Tenho impressão que este "conserto" foi equivocado.
  8. Ambiente: Linux 64 (Ubuntu 14.04 LTS) Um cliente tem caixas com Wi-Fi em uma de suas 19 lojas. Nesta loja (somente nesta loja), no caixa mais distante do roteador, tem ocorrido com frequência o seguinte erro (as linhas que começam com [ACBr] são impressas via evento OnGerarLog, as que tem o horário são impressas via DebugLn): [16:03:19] Enviando para a SEFAZ (1)... [ACBr] Inicio TNFeRecepcao [ACBr] ERRO: [ACBr] Erro Interno: 110 [ACBr] Erro HTTP: 0 [ACBr] ERRO: [ACBr] Inicio TNFeRetRecepcao [ACBr] Versão Layout: 3.10 [ACBr] Ambiente: 1 [ACBr] Versão Aplicativo: RSnfce201710241656 [ACBr] Recibo: [ACBr] Status Código: 215 [ACBr] Status Descrição: Rejeicao: Falha no schema XML [ACBr] UF: RS [ACBr] cMsg: 0 [ACBr] xMsg: [ACBr] ERRO: Rejeicao: Falha no schema XML [16:03:22] Retorno WS = <retConsReciNFe versao="3.10" xmlns="http://www.portalfiscal.inf.br/nfe"><tpAmb>1</tpAmb><verAplic>RSnfce201710241656</verAplic><nRec /><cStat>215</cStat><xMotivo>Rejeicao: Falha no schema XML</xMotivo><cUF>43</cUF><dhRecbto>2018-01-03T16:03:21-02:00</dhRecbto></retConsReciNFe> [215] Rejeicao: Falha no schema XML Este trecho de código tem apenas 3 linhas: DebugLn(), Enviar() do ACBr e DebugLn(). Na verdade o erro não é de schema, mas sim de "time out"; basta tentar enviar novamente o mesmo XML que funciona. No entanto esse Erro Interno 110 é "mascarado", e no RetornoWS vem esta rejeição 215. Alguma sugestão?
  9. Tive um problema similar, tentei carregar o XML, alterar a chave e gravar novamente (para depois consultar na Sefaz) porém o ACBr cria uma TERCEIRA chave nova. Fora editar manualmente o XML, tem alguma maneira de "forçar" uma chave? Tentei mudar o cNF mas ele também acaba sendo ignorado. Tentei zerar o "XMLOriginal" porém a chave antiga (incorreta) é preservada.
  10. Estamos com este mesmo problema na SEFAZ/RS, usando (no Linux) "openssl 1.0.2g 01 Mar 2016". Rodando um "openssl ciphers -v" no console aparecem várias linhas contendo "TLSv1.2". Sabem se houve alguma novidade em relação a isso hoje?
  11. Aqui no Ubuntu demorou mais de 1 minuto... [18:07:17] Gerando XML... Enviando para a SEFAZ... [18:08:32] Exception: Erro Interno: 1 Erro HTTP: 500 E minhas configurações estão assim: Geral.SSLCryptLib := cryOpenSSL; Geral.SSLHttpLib := httpOpenSSL; Geral.SSLLib := libOpenSSL; Geral.SSLXmlSignLib := xsXmlSec; WebServices.Tentativas := 1; WebServices.TimeOut := 2000; Alguma sugestão?
  12. Conseguimos emitir NFe 4.0 em homologação no Linux 64, a questão do SOAP ACTION era um ve310 hardcoded esquecido na hora de enviar (por isso o Status funcionava). Foi necessário fazer uma conhecida alteração no tiposBasico_v4.00.xsd para funcionar: $ svn diff tiposBasico_v4.00.xsd Index: tiposBasico_v4.00.xsd =================================================================== --- tiposBasico_v4.00.xsd (revisão 13858) +++ tiposBasico_v4.00.xsd (cópia de trabalho) @@ -503,7 +503,7 @@ </xs:annotation> <xs:restriction base="xs:string"> <xs:whiteSpace value="preserve"/> - <xs:pattern value="[!-ÿ]{1}[ -ÿ]{0,}[!-ÿ]{1}|[!-ÿ]{1}"/> + <xs:pattern value="[!-ÿ]{1}[ -ÿ]*[!-ÿ]{1}|[!-ÿ]{1}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="TData"> $
×