Ir para o conteúdo

Rankings


Conteúdo Popular

A mostrar o conteúdo com mais reputação desde 23-07-2017 em todas as áreas

  1. 4 !#[1:voto][?:votos]}
    Reparei que o relatorio que enviaste foi feito no Win10, aqui também é o que uso, logo não seria mesmo pelo SO. No site da AT é como diz o @CrominhO, não dá para indicar a chave pública, logo não valida as chaves (a não ser que eles façam validação do lado de lá com a chave que lhes enviamos na certificação do software - mas tenho ideia de que isso não é feito, senão batiam no tecto todos os SAFTs de programas não certificados, e ainda há por aí uns quantos). Desinstalar o Java tive de fazer, quando testei o validador a primeira vez ele nem corria (ou melhor, corria e crashava passado 1 segundo de estar aberto). É, temos mistério... De qualquer forma, dei a conhecer à AT pelo E-Balcão, vamos ver o que dizem. Se há algo que já aprendi em 25 anos desta brincadeira, é que não há bug que se resolva se não soubermos que ele existe. O primeiro passo, identificar, está dado. Ainda não se sabe onde ao certo, mas ele existe. Não tem a ver com os softwares, pelo menos na grande maioria dos casos, e nota-se neste nosso teste, um ficheiro que a ti dá bem, aqui falha. Porque não falha sempre, não sei. Mas que há moscas no bacalhau, isso há...
  2. 3 !#[1:voto][?:votos]}
    function TSSLOpenSSL.LoadPFX(pfxdata: Ansistring): Boolean; var cert, pkey, ca: SslPtr; b: PBIO; p12: SslPtr; begin Result := False; b := BioNew(BioSMem); try BioWrite(b, pfxdata, Length(PfxData)); p12 := d2iPKCS12bio(b, nil); if not Assigned(p12) then Exit; try cert := nil; pkey := nil; ca := nil; try {pf} if PKCS12parse(p12, FKeyPassword, pkey, cert, ca) > 0 then if SSLCTXusecertificate(Fctx, cert) > 0 then if SSLCTXusePrivateKey(Fctx, pkey) > 0 then Result := True; {pf} finally EvpPkeyFree(pkey); X509free(cert); SkX509PopFree(ca,_X509Free); // for ca=nil a new STACK was allocated... end; {/pf} finally PKCS12free(p12); end; finally BioFreeAll(b); end; end; Esta função esta na unit "ssl_openssl.pas" da biblioteca synapse que podem fazer o download gratuito. Espero que ajude.
  3. 3 !#[1:voto][?:votos]}
    Duh, novato. Todos os 'velhinhos' aqui sabemos que o Sr. Nuno é um inspetor undercover. É por isso que se for ele a comunicar tem muito mais peso.
  4. 3 !#[1:voto][?:votos]}
    Obrigado @Vitor Pereira. Efectivamente, o teu relatório mostra que passou tudo bem. Mas olha agora a anedota: Peguei na tua chave publica e no teu SAF-T, corri no validador que fiz o download há uma hora e meia atrás do site da AT, e.... (rufar de tambores) https://www.dropbox.com/s/1oudkuchrk5sgum/RELATÓRIO DE ERROS.pdf?dl=0 E esta agora? Mesma chave, mesmo ficheiro, mesmo validador (presumo), de um lado dá OK, do outro falha... Tem de haver aqui um 4º factor a trocar as voltas, que te parece?
  5. 2 !#[1:voto][?:votos]}
    Sim, é possível. No início do e-Fatura não era possível, mas já assim é há algum tempo. É o que consta nesta FAQ:
  6. 2 !#[1:voto][?:votos]}
    Não é caso único. Existem outras situações contrárias, por exemplo, as aplicações permitiam (passado!) um determinado número de caracteres, e após a legislação do SAFT, o comprimento peca por excesso... Vai tudo dar ao mesmo. O programador não pode fazer milagres "convertendo" dados, efectuando TRIM ou INSERT de caracateres a campos já gravados... mas pode, com certeza, efectuar esse procedimento em "tempo real" no momento da exportação SAFT. O que eu tenho é uma rotina PARSE onde todos os campos são obrigados a passar, com o seu valor, e comprimento MÁXIMO e ou MÍNIMO. O resultado é uma string com MAIS ou MENOS caracteres do que a original. No caso de haver necessidade de fazer um INSERT, faço-o com "*" (asteriscos) para ser bem visível mas a coisa nem termina aqui... existem campos que não aceitam ESPAÇOS... como tal são convertidos em "_" (underline) outros têm espaços a mais (antigamente era permitido formatar de forma errada certos códigos postais, por exemplo: 1234 - 567, com espaços entre o traço, o que leva a que um código postal tenha 10 caracteres... e neste caso não pode ser feito um TRIM pois iria cortar informação relevante). Em resumo: o problema relativo ao LIMITE de caracteres dos campos é mais complexo do que pode parecer, e se ninguém tem esse problema, é quase um milagre, a não ser que as aplicações tenham sido desenvolvidas já depois do SAFT ou os dados tenham sido convertidos de acordo com as regras exigidas e o interface / API tenha passado a validar o conteúdo de TODOS esses campos no momento da sua criação / alteração!!! Já agora, deixo aqui o exemplo das rotinas específicas que uso para processar os campos, e preciso de todas elas! /** Corta caracteres em excesso */ private String parseText(String string, int maxLenght) { return StringUtils.left(string, maxLenght); } /** Corta caracteres em excesso e adiciona caracteres em falta */ private String parseText(String string, int minLenght, int maxLenght) { return string.length()>=minLenght ? parseText(string, maxLenght) : string+StringUtils.replicate('*', minLenght-string.length()); } /** Substitui ESPACOS e corta caracteres em excesso */ private String parseText(String string, int maxLenght, String newSpace) { return parseText(string.replace(" ", newSpace), maxLenght); } /** Substitui ESPACOS por UNDERLINES e corta caracteres em excesso */ private String parseCode(String codigo, int maxLenght) { return parseText(codigo, maxLenght, "_"); }
  7. 2 !#[1:voto][?:votos]}
    Penso que está aqui a haver alguma confusão. Sendo um cliente intracomunitário, não consumidor final, está isento de iva, logo tem de ser sempre utilizado o <TaxCode>ISE</TaxCode>. Neste caso, independentemente de o artigo ter uma taxa de iva de 23%, 13%, 6% ou 0%, terá de ser exportado assim: <Tax> <TaxType>IVA</TaxType> <TaxCountryRegion>PT</TaxCountryRegion> <TaxCode>ISE</TaxCode> <TaxPercentage>0</TaxPercentage> </Tax> <TaxExemptionReason>Isento Artigo 14.º do RITI</TaxExemptionReason> <TaxExemptionCode>M16</TaxExemptionCode> Atenção que se for um cliente consumidor final, mesmo sendo de um país intracomunitário, está sujeito a iva!
  8. 2 !#[1:voto][?:votos]}
    Não pá, é que no outro dias esqueceste de tirar a tarjeta de identificação quando saíste do expediente, e o pessoal leu o que lá dizia. Serviço Undercover da AT Inspector Muito Especial N. 006,5 Nuno Picado
  9. 2 !#[1:voto][?:votos]}
    Os ficheiros ainda careciam de aprovação do staff para ficarem online para os users 'normais'. @Vitor Pereira, espero que não te importes, mas tive de refazer o upload, tinhas colocado em ficheiros separados na secção de exercícios. Estão agora os 4 ficheiros unidos num ZIP, neste link: http://www.portugal-a-programar.pt/files/file/135-testesaftzip/ Brinquem, brinquem... Uma programadora de uma software house com quem a minha empresa trabalha chegou a ligar para a minha colega, a pedir-lhe que falasse com "aquele amigo que trabalha na AT" para esclarecer uma dúvida... Não me importava nada, mas vos garanto que só se tivesse carta branca para remodelar aquele Dpto. de Desenvolvimento. Mas ainda não percebi bem onde foram buscar essa ideia... Dou assim tanto nas vistas? Ai, espera... isto não era para dizer! lol
  10. 2 !#[1:voto][?:votos]}
    Hehe, ausentei-me por um dia e já fizeram reverse engineer do validador ? Algumas observações: (vi os posts na diagonal, se me estou a repetir ignorem) 1 - o compareString é nitidamente uma falha, é um erro de principiante... a partir daqui parece-me claro que o validador está mal e é coerente com os meus (e doutros) testes 2 - NUNCA mas NUNCA se usa um float ou double (ou qq outro equivalente em virgula flutuante) para guardar valores monetários, é um desastre à espera de acontecer. Mesmo que se use o double é perigoso em certas contas, corremos o risco de ter 0,000000001 e comparmos isto com 0 e temos falso, entre outros. Além disso ao passar para a BD e de volta podemos ter problemas... sem falar nas dizimas infinitas em binario (0,1 por exemplo) No dot net temos o currency,. no Java temos o BigDecimal. SE usarem uma linguagem que nao tenha disto usem um Long em que consideram que os n digitos menos significativos são a parte decimal, façam todas as contas ignorando isto e guardem na BD ignorando isto. para mostrar formatem dividido por 10^n. ou insiram um 'dot' no sitio correto. simples mudança de escala 3 public void process() { if (this.documentNumber != null) { Matcher m = DocumentNumberPattern.matcher(this.documentNumber); if (m.find()) { this.internalType = m.group(1); this.series = m.group(2); this.number = m.group(3); } } } este código faz o parse do invoiceNo - o uso de patterns para fazer parse do invoiceNo é text book, excessivo e parece indicar um novato que quer usar as coisas bonitas que aprendeu... seria muito mais performante e simples considerar (embora, admito, isto assume que o invoiceNo está correto mas o código deles tambem assume isso): String[] parts = invoiceNo.split('/'); String docTipoSerie=parts[0]; int docNumber=Integer.parseInt(parts[1]); depois se necessario (para verificar que estamos numa serie diferente nao é necessário) podemos separar o internalType da serie simplesmente fazendo um split(' '); (espaço) o parseInt funciona com '00001' e '1' retornando o inteiro 1 pois considerando que o document number é um número sequencial a sua formatação é irrelevante por outro lado este código é um bocado "old school": Iterator<Document> iter = getToValidateInvoices().iterator(); Document lastInvoice = null; while (iter.hasNext()) //mais habitual for (Document document: getToValidateInvoices()) ou de alguém que não sabe que o java tem "for each" EDIT: tudo isto é académico pois depende da forma como foi construido, às vezes dá jeito fazer as coisas de certa forma... o importante é que o compare do numero NAO pode ser com o compareString... finalmente continua a ser misterioso, (diria ser impossível) que este código funcione bem para alguém... EDIT 2: estava a rever os posts e só agora reparei que extraiem n oMatcher.find para a var "number" a parte do numero mas no compare usam o "documentNumber" ou seja estão a comparar todo o invoiceNO, e o number não é usado na comparacao... public int compareTo(Document compareDocument) { int result = sameSeries(compareDocument); if (result != 0) { return result; } return compareString(this.documentNumber, compareDocument.documentNumber); }
  11. 2 !#[1:voto][?:votos]}
    Deve ser mesmo isso! Mas não havia necessidade de estarem a inventar a roda: bastava usar o que já estava feito e a funcionar bem. Seja como for, foi uma tarde bem passada. Mais uma vez, obrigado ao CrominhO por ter feito luz no que se estava a passar. Agora, toca a ir jantar!
  12. 2 !#[1:voto][?:votos]}
    Porque quem foez o 1.03 já não está no departamento respetivo e quem o(s) substituiu não é do mesmo calibre, duh.
  13. 2 !#[1:voto][?:votos]}
    Azelhice da AT! O problema disto sabem qual é? É que ao invés de terem campos no SAFT para alojar o CÓDIGO do DOC, a SÉRIE e o NÚMERO, querem tudo concatenado. Ainda assim, isto resolve-se facilmente, e deve ser o que faz o Validador 1.03: DESCONSTRUIR o InvoiceNo (DOC SERIE/NUMERO) está bem formatado, por tal, é só fazer SPLIT por ESPAÇO e depois por / sacar o NUMERO e converter em NUMERICO... e ai sim comparar! Agora expliquem-me é porque razão há ficheiros SAFT que passam no validador e não estão a fazer o PAD do NUMERO!!! Isso é o que eu gostava de saber...
  14. 2 !#[1:voto][?:votos]}
    Acabei de sacar o validador do site (http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/CertificacaoSoftware.htm) portanto, versão mais recente NOTA: SAFT 1.04 com 35 facturas devidamente exportadas de forma ORDENADA...
  15. 2 !#[1:voto][?:votos]}
    Supondo que é mesmo essa a intenção da AT para o campo ATCUD, eu até posso entender o motivo deles, mas não estou a ver isso ser praticável. Eu tenho firmas com terminais a trabalhar em "modo offline", com séries de numeração exclusivas para cada terminal. Dados que depois são replicados para a base de dados principal de onde é feito um único ficheiro SAFT mensal. Ora, como raio é que eu vou conseguir interligar várias séries sem ter tudo sincronizado ao milissegundo? Andamos para trás no tempo e passo a fazer como fazia antigamente; um ficheiro SAFT por cada terminal? Não me parece que isso fosse assim tão linear e principalmente para as empresas que funcionam com imensos terminais (caso dos hipermercados), a implementação de tal coisa é um bocado surreal.
  16. 1 !#[1:voto][?:votos]}
    Não sei se ainda há alguém a usar o meu projecto WS-DLL para a comunicação de guias de transporte por webservice, mas se houver, este post é para esses: Dado os recentes desenvolvimentos, especialmente tendo em conta a falta de confiança que o status Obsoleto da CapiCOM apresenta, resolvi fazer um update ao projecto, aproveitando para pôr em prática algumas alterações há muito necessárias a nível de estrutura do código. O projecto mudou de nome, chamando-se agora AtWS, e pode ser encontrado no meu repositório GitHub, aqui: https://github.com/nunopicado/AtWS As mudanças passaram pela já mencionada CapiCOM, que deixou de ser necessária, pela opcionalidade de existir o ficheiro ChavePublicAT.pem (se não for fornecido, será usada a versão hardcoded), pelo fim de algumas dependências de código de terceiros, como DelphiOnRails, SuperObject e UIB, e pelo uso de interfaces na estrutura, facilitando a alteração de uma qualquer implementação por quem achar que o deva fazer. A própria chamada à DLL passa por um interface, que será retornado pela chamada e a partir do qual se poderá fazer o envio dos documentos. Nunca tentei fazer o envio de uma fatura para o WS da AT, apenas documentos de transporte. Não estou certo que funcione, mas é uma possibilidade. De qualquer forma, só documentos de transporte foram testados aqui.
  17. 1 !#[1:voto][?:votos]}
    podes recriar o número binário que existe no vector e fazer a comparação normal int valor = 0; for (int i = 0; i < 4; ++i) valor = valor << 1 + vector[i];
  18. 1 !#[1:voto][?:votos]}
    Não. É isso que tentei esclarecer. O validador da versão 1.04_01 utiliza a versão 1.1 da linguagem XSD. O XML é 1.0. <?xml version="1.0" encoding="Windows-1252"?> <!-- Estrutura do ficheiro SAFT-PT--> <AuditFile xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:OECD:StandardAuditFile-Tax:PT_1.04_01 .\SAFTPT1.04_01.xsd" xmlns="urn:OECD:StandardAuditFile-Tax:PT_1.04_01"> Se reparares, o próprio ficheiro XSD da versão 1.04_01 do SAF-T, que foi escrito usando a versão 1.1 da linguagem XSD usa a versão 1.0 do XML. <?xml version="1.0" (aqui é definida a versão do XML) encoding="Windows-1252"?> <xs:schema xmlns:ns="urn:OECD:StandardAuditFile-Tax:PT_1.04_01" xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning" xmlns:doc="urn:schemas-basda-org:schema-extensions:documentation" xmlns="urn:OECD:StandardAuditFile-Tax:PT_1.04_01" attributeFormDefault="unqualified" elementFormDefault="qualified" id="SAF-T_PT" targetNamespace="urn:OECD:StandardAuditFile-Tax:PT_1.04_01" version="1.04_01" vc:minVersion="1.1" (aqui é definida a versão do XSD) xmlns:xs="http://www.w3.org/2001/XMLSchema">
  19. 1 !#[1:voto][?:votos]}
    @Ascensao, Embora haja frequentemente linhas orientadoras típicas para cada linguagem, o que importa na realidade é que escolhas um estilo e que o utilizes consistentemente. Os outros programadores só terão problemas se fores desorganizado e utilizares update_database nuns sítios e updateDatabase noutros. É (quase) tudo uma questão de preferência pessoal, desde que faças o compromisso de ser uniforme.
  20. 1 !#[1:voto][?:votos]}
    Este foi o comunicado técnico aos parceiros. AT interpreta ??? consultas e-balcão ??? .... Cada um que tire a sua conclusão.
  21. 1 !#[1:voto][?:votos]}
    Voltando a uma discussão que houve aqui no forum sobre se os documentos de conferência tinham de ser assinados ou não e à verificação que grandes empresas produtoras de software não estariam a assinar esses documentos alegando que a legislação da certificação não tinha sido alterada... ao consultar a FAQ do Jasmin Software, da Primavera (uma das tais empresas grandes), temos o seguinte (relativo às novidades introduzidas na release de 2 de Agosto de 2017): "7. Por imposição legal os documentos de conferência, nos quais se incluem os Orçamentos e as Encomendas, devem ser assinados antes de ser impressos, motivo pelo qual os documentos não assinados deixam de poder ser impressos no Jasmin. Esta regra tem como objetivo impedir a entrega a terceiros de documentos que possam ser confundidos com documentos de conferência. "
  22. 1 !#[1:voto][?:votos]}
    Pessoal, novo certificado de testes: https://www.dropbox.com/s/mq4kzkfi2wig5v5/TesteWebservices.pfx?dl=0 Password: TESTEwebservice Válido até 2018-01-29
  23. 1 !#[1:voto][?:votos]}
    A arte da criação de programas auto-replicativos parece estar perdida no tempo. Não podemos confundir um programa auto-replicativo com malware, cavalos de tróia, worms, etc. Um programa auto-replicativo não executa nenhum tipo de código para danificar hardware ou software, pelo contrário apenas tenta replicar-se de diversas formas ou métodos e é por norma escrito numa linguagem de baixo nível, como por exemplo assembly. A parte mais interessante e importante do programa ao contrário de um malware não é um pedaço de código para causar danos, mas antes pelo contrário apenas o código que per- mite que o programa se replique. Apesar de muitas vezes se confundirem as duas tarefas, um programa auto-replicativo é uma forma de criatividade, engenho e inovação, com o objectivo de criar um programa que se consiga manter num sistema informático evitando ser apagado e replicando-se de forma inteligente, evitando a sua detecção e consequente remoção. É quase como fazer um avião de papel, ajustar as “asas”, o “nariz”, colocar ou não um “leme de cauda”, etc e atirar para ver que distância é percorrida antes de inevitavelmente aterrar, ou melhor, cair! Em momento algum se pretende que o programa, tal como o avião, dure “ad aeternum”, sendo o interesse apenas no lapso de tempo que ele durará até ser totalmente removido. Ler mais…
  24. 1 !#[1:voto][?:votos]}
    tens que converter o certificado x509 para CERT_CONTEXT do windows com i2d_X509 e CertCreateCertificateContext que te vai dar o PCCERT_CONTEXT que tanto precisas.
  25. 1 !#[1:voto][?:votos]}
    Penso que o erro não é na base de dados nem na query, mas aqui: Dim nfatura As String = tabela.Rows.Item(0).Item(0) Verifica se é null: If tabela.Rows.Item(0).Item(0) IsNot System.DBNull.Value Then 'copiar a celula para a variável End If Já agora se o nfatura na base de dados é Integer, então no Vb convem ser também Integer. Poderás ter problemas quando chegar a números maiores que 1000 e o teu sistema estiver configurado para separador de milhares com (.)
  26. 1 !#[1:voto][?:votos]}
    As contas que mencionas (249 e 2313) não fazem parte de nenhum Plano de Contas, nem das Micro nem das maiores. Se fores ver o Plano de Contas publicado na Lei elas não estão lá, e por isso não deveriam ser usadas porque não existe explicação "oficial" para o que é lançado nelas. O utilizador apenas deveria criar subcontas das conta legalmente existentes. Na minha opinião, não há qualquer problema em utilizar o mesmo Plano de Contas para SNC e Micro, desde que nas Micro apenas se lance em subcontas de contas que são permitidas utilizar em Micro. No entanto, se o utilizador usa contas que não fazem parte do Plano Oficial, só ele sabe o que lança nelas e por isso só ele poderá dizer qual é a taxonomia que se lhe deve atribuir.
  27. 1 !#[1:voto][?:votos]}
    Não há um exemplozinho pros amigos!
  28. 1 !#[1:voto][?:votos]}
    http://info.portaldasfinancas.gov.pt/apps/saft-pt01/local/SAFT_IDEMO599999999.xml
  29. 1 !#[1:voto][?:votos]}
    Sim é com openssl, nao uso "capicome" uso a função d2i_PKCS12_bio e depois a PKCS12_parse e ele vai buscar tudo. certificados chave privada o que la estiver dentro do pfx.
  30. 1 !#[1:voto][?:votos]}
    Atualmente, muito se fala em inteligência artificial. O Google investe, a Microsoft, a Amazon, a Uber, o Facebook, a Apple… E essa lista não para por aqui. Nós sabemos que é uma tecnologia pujante, que, juntamente com a correta análise do Big Data, certamente será uma das ferramentas mais poderosas que nós teremos no futuro próximo. A ideia deste artigo é falar um pouco da inteligência artificial, mais precisamente abordar os algoritmos das redes neurais artificiais (RNA), sua arquitetura, seu funcionamento e suas principais aplicações. Ler mais…
  31. 1 !#[1:voto][?:votos]}
    marcolopes e nunopicado: vocês não dormem?
  32. 1 !#[1:voto][?:votos]}
    Mesmo assim, eu não iria por aí... O SAF-T resumido é criado na hora com regras que ninguém conhece e que podem mudar a qualquer momento. A única forma de estarmos salvaguardados é cumprir a legislação, ou seja, enviar. Assim, se de repente se lembram de não apagar esses dados no resumido, pelo menos eles estarão lá. Isso é muito bonito, mas não é solução. No portal das finanças, onde se envia o SAF-T, há já um aviso nesse sentido:
  33. 1 !#[1:voto][?:votos]}
    Se não entrega com versão 1.04, entrega com versão 1.03!
  34. 1 !#[1:voto][?:votos]}
    Boas Só para informar que hoje de manhã enviamos o SAF-T de Julho aqui da Empresa já na versão 1.04_01. Muito embora tenhamos recebido uma resposta da AT a informar que todos os documentos tinham de ser enviados para o SAF-T Mensal ( fora os recibos RG ) para grande espanto nosso fomos analisar o Ficheiro SAF-T.Resumido que o Site da AT cria e envia, e apenas vão os Documentos de Faturação e Recibos RC ( IVA de CAIXA ) Na criação do Saft.Resumido a AT apagou todos os Documentos de Transporte, de Conferencia, e Recibos normais !!!! Como tal, o envio dos Documentos no SAFT mensal é mesmo perda de tempo assim como a SAGE e a grandes Software-Houses também decidiram Boas Férias para todos
  35. 1 !#[1:voto][?:votos]}
    Porque a AT implementa regras distintas em cada validador... uma mistela!
  36. 1 !#[1:voto][?:votos]}
    Boa Noite, ainda espero ir a tempo de ajudar alguém, relativamente ao tema dos recibos (Payments). Tenho tido imensas duvidas após o termino da questão do TaxExemptionReason poder ter 'Documento sem imposto calculado'. Então a AT respondeu o seguinte, e passo abaixo a informação, para quem ainda faça falta ou tenha duvidas. Pergunta Resposta Um abraço a todos, e espero ajudar tal como tenho recebido ajuda. João Moreira
  37. 1 !#[1:voto][?:votos]}
    possivelmente o ficheiro foi editado para mudar o numero do certificado ? e/ou outros dados, após o teu teste ? Em todo o caso, acabei de testar e dá-me os mesmos resultados que ao nunopicado O teu validador poderá ser diferente? podes fazer um md5? Com o meu validador tenho: 851eb8c8cffe2c4b4f1a7bee6a818194 podes usar a tool FCIV da m$: http://download.microsoft.com/download/c/f/4/cf454ae0-a4bb-4123-8333-a1b6737712f7/windows-kb841290-x86-enu.exe
  38. 1 !#[1:voto][?:votos]}
    Bom dia, O ficheiro que o Vitor Pereira validou tem 60054 bytes , o que tu validas tem 60047 bytes. Nao deveriam ser iguais? Abraço
  39. 1 !#[1:voto][?:votos]}
    Amigo tenho que me rir lol... Compreendo o que dizes, mas não foi sempre assim? aliás, o Questões Legais, SAFT e Webservice deste forum são um Debug completo dos Softwares e das Leis lançadas desde então ... resta-nos ir levando "a coisa" da melhor maneira possível
  40. 1 !#[1:voto][?:votos]}
    Nuno, já está disponível em Downloads Várias Séries de Documentos de Faturação, Doc. de Transporte e Documentos de Conferencia Todos a começar com uma Numeração com um determinado numero de dígitos, e a acabar sempre com mais 1 digito Segue o comprovativo da Validação e o Resumo de Erros, tudo feito no Validador.jar da AT ( também testei no Site da AT, para mim o Validador mais importante, e tudo ok ) Espero que ajude a resolver este problema em discussão ( informo que não alteramos em nada a forma como exportávamos os dados para as versões anteriores do SAFT e como o fazemos agora com a versão 1.04 ) NOTA: Não estranhem o inicio da String do InvoiceNo ser numérica, mas como já referi aqui a nossa codificação interna vai de 1 a 999 e cada uma está classificada internamente com a lista da AT ( FT, FR, FS, ND, NC, etc ) que só colocamos no InvoiceType pois para nós não é Código Interno ( mas claro funciona de qualquer das formas, é apenas uma opção nossa )
  41. 1 !#[1:voto][?:votos]}
    Só reparei no pattern agora! Realmente há ali um REGEX no inicio... até fica porreiro para pesquisar dentro do InvoiceNo, mas o mal está feito com o comparable!! Opá, como não vi um construtor, nem me passou pela cabeça que estivessem a inicializar os campos (2 deles!) num método process :\\\\ de loucos... Estando o REGEX bem definido, então number terá apenas o NUMERO do documento, só é uma pena que não o convertam para INT e o usem no compareTo!
  42. 1 !#[1:voto][?:votos]}
    Eu também me quer parecer que tem de haver um sort da lista em algum lado. E continuo a achar que o erro está na função public int compareTo(Document compareDocument) que vai ordenar (incorrectamente, digo eu) os documentos por ordem alfabética do documentNumber. Se tivermos documentos numerados de 1 a 10, o documento FT A/10 será sempre anterior ao FT A/2, dando assim o erro na validação das chaves dos documentos números 2 e 10. Se não existir o documento 10, validam todos porque estão todos ordenados correctamente.
  43. 1 !#[1:voto][?:votos]}
    @marcolopes, @chesser e @trs80 e restantes programadores de Java, deem uma vista de olhos nisto para ver se tá tudo correcto, que além do meu Java nao ser grande coisa já começo a ficar com os olhos em Bico lol package com.saft.validator; import java.text.DecimalFormat; import java.util.regex.Matcher; import java.util.regex.Pattern; public class Document implements Comparable<Document> { static final Pattern DocumentNumberPattern = Pattern.compile("^([^\\ ]+) ([^�\\/\\ ]+)\\/([0-9]+)$"); public String documentNumber = ""; public String documentDate = ""; public String documentTotalsGrossTotal = ""; public String systemEntryDate = ""; public String hash = ""; public String hashControl = ""; public String sourceBilling = ""; public Long startLine; public Long startColumn; public Long endLine; public Long endColumn; private String internalType; private String series; private String number; private boolean isValid = false; public void process() { if (this.documentNumber != null) { Matcher m = DocumentNumberPattern.matcher(this.documentNumber); if (m.find()) { this.internalType = m.group(1); this.series = m.group(2); this.number = m.group(3); } } } private int compareString(String a, String b) { if ((a == null) && (b != null)) { return 1; } if ((a != null) && (b == null)) { return -1; } if ((a == null) && (b == null)) { return 0; } return a.compareTo(b); } public int sameSeries(Document compareInvoice) { if (compareInvoice == null) { return -1; } int result = compareString(this.internalType, compareInvoice.internalType); if (result != 0) { return result; } return compareString(this.series, compareInvoice.series); } public int compareTo(Document compareDocument) { int result = sameSeries(compareDocument); if (result != 0) { return result; } return compareString(this.documentNumber, compareDocument.documentNumber); } public boolean isSignedByTheApplication() { return (this.sourceBilling == null) || (!this.sourceBilling.toUpperCase().equals("I")); } public String getHashToValidate(String lastHash) { DecimalFormat df = new DecimalFormat("0.00"); Double document_totals_gross_total = new Double(0.0D); try { document_totals_gross_total = new Double(this.documentTotalsGrossTotal); } catch (Exception localException) {} String hash = this.documentDate + ";" + this.systemEntryDate + ";"; hash = hash + this.documentNumber; hash = hash + ";"; hash = hash + df.format(document_totals_gross_total).replaceAll(",", "."); hash = hash + ";" + lastHash; return hash; } public void setValid(boolean valid) { this.isValid = valid; } public boolean isValid() { return this.isValid; } }
  44. 1 !#[1:voto][?:votos]}
    sim... e nada diz na documentação que o NÚMERO do documento não pode ser formatado! Mas também não pode obrigar a que o seja! A questão seria bonita é se o validador fizesse birra por causa de uma ordenação interna do campo InvoiceNo não formatado! (que por ser em String, evidentemente não irá estar por ordem de documento!) O validador tem mais é que ler a estrutura por ordem!! Cabe a nós exportar os documentos ordenados... isso sim! É claro que quem programou o validador 1.03 não está responsável pelo 1.04 :\ Piorou o interface, não tem progress bar (what's happening!?), carregamento de ficheiros e chave é complexo (no 1.03 filtra logo pelos ficheiros TXT), etc etc... Toda a gente que não tem problemas com as assinaturas no validador 1.04 está a formatar o InvoiceNo (PAD no NÚMERO do documento)?
  45. 1 !#[1:voto][?:votos]}
    Sim. Não me deu erro no mesmo ficheiro.
  46. 1 !#[1:voto][?:votos]}
    Era bug no analisador mesmo. A AT já corrigiu.
  47. 1 !#[1:voto][?:votos]}
    Sobre aquela questão do validador falhar (ordenação e tal), testei agora há pouco e trabalhou tudo OK. Só falhou a validação no primeiro documento de cada série (series transitaram do ano anterior). A malta a quem está a falhar já testou fazer update do Java?
  48. 1 !#[1:voto][?:votos]}
    Em primeiro lugar peço desculpa ao Vítor. Não tive intenção de ser ofensivo nem de fazer qualquer exigência. Perguntei porque de facto desconhecia onde estava escrita a dita regra. Essas primeiras FAQs publicadas tinham algumas pérolas... Quanto ao problema em questão, creio que estamos de facto a trabalhar com o mesmo validador, mas com versões diferentes. Uma vez que o Vítor garantia que não tinha qualquer erro, e eu e outros garantíamos que dava erro, lembrei-me que o Vítor poderia estar a trabalhar com uma versão mais recente. Com o validador que saquei em 13 de abril tenho erro nas assinaturas (mesmo tendo os documentos ordenados por tipo, série e número). Com o validador que saquei hoje, não dá qualquer erro. Era bom que o validador tivesse visível quer na própria aplicação quer na página do download a versão da build para podermos ver facilmente se temos a versão atualizada ou não.
  49. 1 !#[1:voto][?:votos]}
    Não muda nada... Os números de série não são campos obrigatórios. ;)
  50. 1 !#[1:voto][?:votos]}
    tendo em conta alguns post teus que já vi, penso que sabes o que é o lambda-calculos (que é a base do Haskell, como já referi). o Haskell não é eficiente pela forma como a funções são executadas, não sei exactamente como funciona o GHC, mas o HUGS penso que calcula os resultados através de reduções dos lambda-termos, que normalmente é algo não muito eficiente, para além de que para calcular o resultado de uma simples função são necessárias várias reduções (por exemplo para fazer soma 2 4, o HUGS faz 29 reduções, coisa que em Assembly se faz com meia dúzia de instruções, algo muito mais rápido do que fazer um redução). mas afirmações que fiz foram sobretudo baseadas na teoria do lambda-calculus, e na forma como calculamos o resultado das funções manualmente, não sei exactamente como funcionam os compiladores. Percebo. Não conheço o Haskell mas isso não será um falso problema, ou seja, isso não será apenas uma questão de optimização da implementação do próprio interpretador/compilador? Não faltam casos de sucesso de empresas que usaram, por exemplo, Lisp, por isso é que fiquei curioso em saber porque não é eficiente.
×

Aviso Sobre Cookies

Ao usar este site você aceita a nossa Política de Privacidade