Ir para o conteúdo

Rankings


Conteúdo Popular

A mostrar o conteúdo com mais reputação desde 18-09-2018 em todas as áreas

  1. 3 pontos
    Aparentemente a letra da lei permite essa interpretação. Para a AT isso não deve ter problema nenhum porque a chave primária deles não deve ser o InvoiceNo, mas sim o IdDocumento. Além disso, cada SAFT só pode ter documentos de 1 ano, seja o ano completo ou seja parcial. No meu caso não dá porque a chave primária que uso é "Tipo+Serie+Numero", mas para dar bastaria alterar para "year(data)+Tipo+Serie+Numero". Por outro lado, para o utilizador, não vejo qualquer vantagem nisso, pois só iria dar confusão com os respetivos clientes. Para identificar uma fatura, além de dar o numero e a série também iria ter de dar a data. Quando a AT diz "... por um período não inferior a um ano fiscal …" o que quer dizer é que uma série criada no início do ano deve ser, por regra, utilizada pelo menos até ao fim do ano, em vez de serem, por exemplo, mensais. Por exemplo, na contabilidade é comum criarem-se diários (pastas) em que se separam documentos por tipo do género "vendas", "compras", "bancos", etc. Dentro de cada um desses diários a numeração é também sequencial. O problema é que muitas vezes os documentos chegam muito tarde á mão do contabilista, especialmente faturas e notas de crédito de fornecedores que, não sendo emitidas pela empresa, não se consegue controlar. A forma de dar a volta a isso é reiniciar a numeração todos os meses. Assim, ainda que já estejam lançados documentos de Setembro, podes sempre acrescentar mais um lançamento em Julho de uma fatura que o empresário se esqueceu de entregar. Ou se estiveres a conferir um extrato bancário de Janeiro e verificares que te esqueceste de lançar um documento que até tinhas de ir buscar ao homebanking, nunca terás o problema de falta de numero para inseri-lo no respetivo mês.
  2. 2 pontos
    Projecto: https://github.com/marcolopes/dma/tree/master/org.dma.services.vies Classe principal com exemplos: https://github.com/marcolopes/dma/blob/master/org.dma.services.vies/src/org/dma/services/vies/CheckVatHandler.java CheckVatHandler handler=new CheckVatHandler(COUNTRIES.ES); System.out.println(handler.query("A28250777")); System.out.println(handler.query("A39000013")); System.out.println(handler.query("B94123908")); System.out.println(handler.query("J98725286")); handler=new CheckVatHandler(COUNTRIES.DE); System.out.println(handler.query("115055014")); System.out.println(handler.query("129274202")); System.out.println(handler.query("136563568")); System.out.println(handler.query("258071573")); System.out.println(new CheckVatHandler("GR").query("064806395")); System.out.println(COUNTRIES.EL.query("094543092"));
  3. 2 pontos
    O despacho 8632/2014 é claro: Ou seja, uma série para todos os tipos de documentos. Só em casos justificados, nomeadamente por necessidades comerciais, poderá utilizar mais que uma série. Por exemplo, se tiver vários estabelecimentos, pontos de faturação, houver quebra no funcionamento (teve de suspender a série em utilização e iniciar uma nova), etc.
  4. 2 pontos
    Acho que o @nunopicado toca em dois pontos fundamentais: É habitual não controlarmos devidamente o ambiente de execução (quer as características do sistema, quer os restantes processos a correr no sistema); Se por acaso existir alguma modificação das circunstâncias que torne a performance um problema, pode ser complicado optimizar a aplicação nesse ponto. Depois uma coisa é não nos preocuparmos com a performance mas sabermos escrever código minimamente eficiente de raiz. Outra coisa é literalmente não querer saber da performance e vir com a história de comprar hardware novo. E esta parece ser a norma hoje em dia. Já passamos a fase do "optimizar prematuramente é mau", para o "performance não interessa". Diria também que não estamos a falar de um potencial futuro problema, mas de um problema que efectivamente já é bem visível no software.
  5. 2 pontos
    Há muitos anos que eu digo que o PC de teste de um programador deveria ser um chaço arcaico. Só assim para alguns programadores perceberem que, independentemente de tudo o resto, o programa deveria ser o mais eficiente possível, e dever-se-ia apostar em fazer o melhor possível logo à primeira, para evitar depois a 'perca de tempo' a refactorar.
  6. 1 ponto
    cria uma regra if len(cl.ncont)<9 return .f. endif
  7. 1 ponto
    Sabes que estás a tentar resolver um problema que já foi resolvido à mais de uma década? Poderia abordar os dois pontos que referes aqui um de cada vez e mostra te que como poderias chegar a uma solução possível (ou impossível), mas acho que a melhor resposta que alguém te poderia dar será : usa uma framework que já exista, seja ela symfony, Laravel, Yii até mesmo CodeIgniter. Não é uma questão de "mandar para canto" , é a melhor coisa que deverias fazer, porque aqui ninguém inventa a roda, por na realidade, a roda dá trabalho a ser inventada
  8. 1 ponto
    Esse comportamento ocorre porque a tarefa está a ser executada na mesma thread que o user interface. Isto faz com que algumas mensagens do windows fiquem na queue até haver 'uma aberta' para as processar. Como algumas dessas mensagens incluem a actualização dos valores mostrados no UI, acabas por não ter um refresh correcto. Podes testar a dica do @Rafael Adão, que para coisas simples costuma resolver. Idealmente, o teu processamento de ficheiros ficaria numa thread dedicada, deixando a principal para actualizar o UI, mas para coisas simples, se o ProcessMessages funcionar, podes não querer ir por aí...
  9. 1 ponto
    Experimente colocar um 'Application.ProcessMessages;' ..... Frm_Shuffle_MP3.StrNovoNome.Caption:=Fich; {Aqui mostra o nome novo} Application.ProcessMessages; ....
  10. 1 ponto
    Não é algo simples, mas também não é 'rocket science'. Explicar seria algo demasiado extenso para estar a responder pelo telemóvel. Aconselho te a pesquisar na net que irá encontrar como criar um tokenzier e um interpreter
  11. 1 ponto
    isso parece que necessites de um interpretador do que estas a escrever, assim como alguma especificação da linguagem que esperas ler. além disso, tenho as minhas dúvidas que este tópico se encontra no local correcto ...
  12. 1 ponto
    Podes também utilizar a função zipWith e aplicá-la a (+) e às listas: > zipWith (+) [6,7,8] [1,2,3] [7,9,11]
  13. 1 ponto
    You’ve probably heard this mantra: “programmer time is more expensive than computer time”. What it means basically is that we’re wasting computers at an unprecedented scale. Would you buy a car if it eats 100 liters per 100 kilometers? How about 1000 liters? With computers, we do that all the time. [...] Artigo longo e interessante sobre o estado do desenvolvimento de software hoje em dia. Versão completa disponível aqui: http://tonsky.me/blog/disenchantment/
  14. 1 ponto
    Acho que esta questão tem duas vertentes: - Comercial - Quem tem um projecto de desenvolvimento para executar num dado orçamento irá procurar tudo para reduzir custos directos. Como já foi escrito, o gestor paga o tempo de programação mas não o tempo de execução. Logo a eficiência do código, a menos que seja um critério definido, será sempre uma preocupação secundária. - Profissional - A larga maioria dos jovens programadores nunca teve de se preocupar com performance na execução do código, apenas com performance na criação do mesmo. De maneira geral, apenas programadores que começaram a desenvolver em máquinas limitadas tiveram de se preocupar com isso. Ferramentas como 'profilers' basicamente caíram em desuso e nem sei se serão referidas em cursos superiores da área. O enfoque que se dá hoje em dia a linguagens como Java e Python como formação primária não ajuda a criar uma mentalidade de eficiência na execução, quando são linguagens que usam 'garbage collection', tirando assim do controlo do programador a maior fonte de ineficiências de código minimamente bem criado, que é a gestão de memória. Quando ambos se combinam temos todo o tipo de 'bloatware' existente actualmente. Um 'Office Word' actual precisa de mais memória e capacidade de processamento para correr do que a disponível num super-computador Cray X-MP de 1982, ano em que surgiu o IBM PC. Apenas num mundo em que questões como a eficiência energética (sistemas que têm de funcionar à velocidade máxima, com consumo máximo, devido à carga exercida pela execução de código ineficiente) e o tratamento do lixo electrónico (sistemas deitados fora porque já não conseguem executar adequadamente as novas versões do velho 'software' usado) se tornem importantes levará a uma mudança de prioridades. Mas temo que a 'IA' (aspas usadas depreciativamente) apareça primeiro e tire completamente de mãos humanas a criação da maioria do código.
  15. 1 ponto
    Não sei como escapou-me essa parte Já adicionei o link no artigo original (fica também aqui: http://tonsky.me/blog/disenchantment/).
  16. 1 ponto
    Acho que é de dividir o que é software que se sabe à partida onde vai correr e o que não se sabe, e em que condições ele vai correr. Se faço um software para correr uma vez, admito que também não me preocupo em demasia. Mas se faço um software que vai correr não sei em que PCs durante não sei quantas vezes e em quanto tempo... Convém ter cuidado com o que se faz. Lógico que não estou a dizer que temos de entrar em paranóia com isso. Mas uma gestão de memória consciente, com noção mínima do que uma acção implica a nível de performance não é de descartar. Se o fiz sempre? Não, infelizmente. Hoje olho para os programas em que não o fiz e, mesmo que os PCs sejam agora mais rápidos e portanto ainda se note menos o problema, gostaria de os ter feito correctamente de início, porque sei que cedo ou tarde, havendo tempo, vai-me dar comichão olhar para lá e vou refazer esses programas, mesmo que sem benefício para o utilizador, simplesmente por ficar melhor comigo próprio ao olhar para o código.
×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.