Ir para o conteúdo

Rankings


Conteúdo Popular

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

  1. 4 pontos
    Relativamente a este assunto, ontem tivemos uma reunião com DIgitalSign ( empresa emissora de Certificados Digitais ), pois a Faturação Eletrónica vai obrigar a um Certificado por cada utilizador ( 125 € por ano e por cliente ) Na reunião informaram-nos que também estão com reuniões agendadas com as grandes Softwares-Houses pois na verdade ainda ninguém tem o sistema a funcionar ( muito embora algumas publicitem que sim ) Também nos informaram que a informação que tinha chegado até eles é de que seria utilizado o UBL 2.1 e não o UBL 2.0 como se tem falado aqui no Forum, mas também não tinham certezas de nada Como tal, a situação é: A Portaria que vai regular ainda não saiu …... A data de inicio já vai em Abril de 2019 …... As Empresas do Estado ainda não tem Software preparado para recolha das Faturas Eletrónicas …. e por ai fora ….. Vamos aguardando e juntando toda a informação que vai saindo, mas com toda a certeza a menos fiável é a publicada pelos jornalista, e que devemos descartar pois tem objetivos sensacionalistas e não profissionais
  2. 4 pontos
    Derrerter, também recebi esse exemplo acompanhado da seguinte comunicação Cá está. É obrigatório mas não foi apresentada nenhuma informação, decreto lei ou portaria, sobre o assunto. Típico.
  3. 4 pontos
    Se alguém usar .NET, o seguinte link poderá ter interesse: https://github.com/UblSharp/UblSharp
  4. 3 pontos
    É mesmo de ficar sem palavras. Situando um pouco toda esta história, com base numa formação em que estive, a Diretiva europeia de 2014 não era vinculativa, seria mais uma base de trabalho para os países. O nosso antecipou-se no ano passado quando publicou o DL 111-B/2017 (Agosto 2017) à Decisão de Execução 2017/1870 (Outubro 2017) da Comunidade Europeia. Explicando, em Portugal, o bendito Decreto-Lei obrigou a que toda a fatura passada ao Estado tivesse de obedecer aos requisitos da Faturação Eletrónica ( como o exemplo dado antes do talho que vende uns bifes para a escola ), enquanto que a 2017/870 apenas confirmava a obrigatoriedade de faturação eletrónica nas obras de construção civil acima dos 5 milhões de euros ou fornecimento de bens e serviços acima dos 200.000 euros. E não falo aqui também do facto do n/ governo ter antecipado para 1 de Janeiro esta obrigação quando a CE tinha estabelecido como deadline o mês de Abril. Como se isso não chegasse, o n/ país era obrigado a publicar até ontem a Portaria / documento que regulasse esta questão cá em Portugal, coisa que não aconteceu ( liguei hoje para a AT e não me conseguiram dar uma previsão para a sua publicação ). Podíamos pelo menos ter um rascunho do que poderá ser publicado, para todos nos orientarmos. Em face desta incerteza e desta indefinição que todos sentimos, parece-me que está aberto o espaço para que alguns brokers venham a beneficiar desta situação. Teria toda a lógica que a AT criasse algo idêntico à comunicação das faturas ou dos documentos de transporte. Mas não me parece, acho que tudo isto é uma forma de gerar dinheiro pelo lado da obrigação, desde nós que temos de comprar a norma e as especificações técnicas até ao talho que tem de gastar não sei quanto para vender uns bifitos ou o café que provavelmente vai recusar-se a servir pequenos-almoços a funcionários públicos... Aqui fica uma reflexão, 2 dias depois de nada ter sido publicado.
  5. 3 pontos
    Afinal nada disto é novo para o fisco!!! Veja-se a implementação do MESMO sistema para a Faturação Electrónica de Medicamentos e Cuidados Farmacêuticos: https://www.ccf.min-saude.pt/portal/page/portal/estrutura/documentacaoPublica/ACSS/ACSS_AF_Facturacao_Electronica_Medicamentos_Main_v20180606.pdf UBL 2.0, com extensões específicas, com assinatura do XML, e envio através de WEBSERVICE!
  6. 2 pontos
    No meu entendimento, e pelo que podemos ver pelo formato da Factura Electrónica da área da saúde, tem de haver uma assinatura do XML (seja ele enviado em envelope SOAP ou não).
  7. 2 pontos
    A informação da DigitalSign é que muito embora seja a Software-House a pedir os Certificados, cada utilizador tem de ter um Certificado pessoal ( onde vão digitalmente os dados da sua Empresa ) para comunicar com os seus Fornecedores ( envio das Faturas assinadas pelo emissor das mesmas ) De qualquer das formas, também deixamos no ar a mesma dúvida ( se será possível o Certificado ser da Software-House e não do cliente utilizador do Software ), mas ainda existe muita falta de informação sobre o assunto
  8. 2 pontos
    Terá de ser, porque a informação do XML terá de ser assinada para garantir autenticidade, seja qual for o canal utilizado (se for Webservice, haverá ainda outro certificado para autenticação, mas será da responsabilidade da empresa receptora) Eu começo a ver tudo isto como um AUMENTO de custo e não uma redução! (então se colocarmos "empresas intermediárias" no cenário...)
  9. 2 pontos
    Podes ver aqui um simples crd.xml Só lhe retirei a tag Extension no inicio para não confundir mais. E está em UBL 2.0 mas as diferenças não são significativas para o caso. Esta factura não tem descritivos e na tag ITEM tem conteúdos específicos diferentes dos pedidos pela infraestruturas de portugal que diga-se de passagem também não é standard.
  10. 2 pontos
    Teria um piadão os fornecedores terem de CONTRATAR as entidades INTERMEDIÁRIAS usadas pelas empresas públicas para gerir os seus documentos electrónicos! A obrigação de implementação do sistema é de todos, e se as empresas públicas, ao invés de pagarem pela sua implementação dentro de portas, quiserem pagar a uma empresas para lhes tratar da interoperabilidade, parece ser uma possibilidade, mas os fornecedores não são obrigados a PAGAR para aceder a um portal que é da responsabilidade da empresa pública!! (digo eu!!!). Este ponto iria por água abaixo! (e se calhar vai a longo prazo, pois quem ganha com isto são entidades privadas, de uma forma ou de outra!!!)
  11. 2 pontos
    O que o email do GRUPO IP vem dizer que, como já trabalham com um INTERMEDIÁRIO que trata da burocracia da "interligação" de sistemas, vão continuar a trabalhar com o mesmo no que toda ao modelo de Factura Electrónica Europeu (no fundo dizem: NÃO nos façam perguntas incómodas, pois será tudo tratado pela empresa privada já vossa conhecida - ou não!!! - que sempre nos tratou do modelo EDI que tinhamos até agora!) O que diz a DIRETIVA 2014/55/UE DO PARLAMENTO EUROPEU https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX%3A32014L0055 no entanto... Portanto, a transmissão pode ser... à escolha do país, entidade pública de cada país? Ou seja, cada país terá de escolher o seu standard por entre as SINTAXES aprovadas, que mais tarde (na comunicação inter-países) terão de ser aceites (todos os países terão de estar preparadas para TODAS as sintaxes permitidas)! Entretanto, no próprio país, apenas será usada uma sintaxe (pelo que li, em PT será UBM 2.1 - gostava de ver uma publicação OFICIAL sobre o assunto!) Em resumo: o que pensavamos nós (???) que deveria ser, não é! ou seja, um PORTAL CENTRAL de FACTURAS ELECTRÓNICAS da administração pública, com UMA (ou mais) FORMA universal de transmissão, que aceitaria os STANDARDS da U.E. e que receberia toda as comunicações relativas a TODAS as empresas públicas (aka: WEBSERVICES DA AT!). Afinal, cada empresa pública será responsável por implementar, ou CONTRATAR terceiros para serem INTERMEDIÁRIOS no processo de transmissão e interoperabilidade! Com isto, podemos ter dezenas, centenas... de FORMAS de TRANSMISSÃO de facturas! Neste momento não faço ideia (fará alguém??) sobre se o formato UBL 2.1 satisfaz as necessidades do sector público em PT, ou se vão existir extensões / alterações, e se essas extensões serão gerais e obrigatórias, ou específicas de cada sector! Em resumo: uma salgalhada!!!
  12. 2 pontos
    Ah! E esqueci-me de referir o mais importante que vinha no e-mail, a cereja em cima do bolo,
  13. 2 pontos
    Boas, Aqui está um exemplo enviado pela Infraestruturas de Portugal, para os seus fornecedores. https://www.dropbox.com/s/mnoayplcdr10tmc/exemplo_ubl2.1.xml?dl=0
  14. 2 pontos
    MarcoLopes, essas referencias que apresentas são situações especificas aplicadas exclusivamente ao sector da saúde. Sim, o CCF que é o centro de conferência de facturas passou a receber a relação de facturas de cuidados de saude prestados por empresas privadas ao SNS através de ficheiros XML com uma estrutura "básica" do standard UBL. A prescrição de receitas electrónicas também já é uma realidade no SNS e a utilização de webservices nos cuidados respiratórios, por exemplo, é uma realidade. Mas isso aplica-se apenas ao sector da saúde. E a instituição que "lida" com estes sistemas é o SPMS (Serviços partilhados do Ministério da Saúde). Eu sei porque já desenvolvi alguns sistemas específicos de ligação aos sistemas deles. Mas no caso da factura electrónica obrigatória por norma europeia penso que não terá nada a ver com o caso da saúde. Eventualmente o standard a adoptar será o mesmo (UBL) mas nem isso é garantido. Acho que vamos ter que aguardar por publicação de legislação. E pelo "andar da carruagem" tenho sérias duvidas que seja aplicado já a partir de Janeiro/2019. PS: Se for igual ao do CCF posso adiantar já que é bastante complexo envolvendo inclusive, além da assinatura digital do XML, conversões para Base64String e comunicação com webservices com autenticação através de tokens. Parece o "Fort Knox" americano :D...
  15. 2 pontos
    Parece que começa a haver mais alguma informação. Segundo a itinsight vamos adoptar o formato UBL 2.1 https://www.itinsight.pt/news/inovacao/ministerio-das-financas-adota-formato-ubl-21-para-contratos-publicos Agora é esperar pela publicação oficial e ir preparando o jarro do café ...
  16. 2 pontos
    Vê como tens definida a função: void mediaVetores (int *vetor3, int tamanho, float total = 0) Vê bem como tens os parâmetros. E depois vê como a chamas na função main(). Só mais uma nota: Tens que rever como se preenchem vectores e como se acede aos valores neles contidos. Deves também rever o que é o scope das variáveis e saber depois declarar as variáveis nos sítios certos de acordo com a finalidade dela. Vejo que declaraste variáveis globais mas isso é má prática. Se eu percebi o código, é suposto pedir valores ao user e preencher dois vectores e depois somar os valores de cada vector e apresentar a média dessa soma, certo? Pelas razões que apresentei anteriormente, o teu programa vai dar erros sem fim. Assim que corrigires um, aparecem mais 10.
  17. 2 pontos
    Quebras as palavras pelo espaço e usas os operadores like e or e fazes um distinct para eliminar resultados duplicados. select distinct * from tabela where descritivo like '%cobre%' or descrivito like '%22%' Tem atenção que esta estratégia está longe de ser a que tem a melhor performance, mas se não tiveres muito registos pode ser perfeitamente viável.
  18. 1 ponto
    #include <stdio.h> #define MAX(a,b) ((a) > (b) ? (a) : (b)) int main() { int hit = 0; for (int i = 999; i > 0; i--) { int j = 999, mul, copy, rev; do { rev = 0; mul = copy = i * j; while (copy) { rev = rev * 10 + copy % 10; copy /= 10; } j--; } while (j > 0 && mul != rev && hit < mul); hit = MAX(mul, hit); } printf("maior numero capicua e: %d\n", hit); return 0; }
  19. 1 ponto
    Obrigado pelo exemplo. No meu caso estou a construir e a validar num validador http://13.80.11.48:8000/invoice/upload , depois a ideia é ir retirando os erros .... Por exemplo ele obriga a ter dentro do TaxSubtotal um TaxCategory que indique depois o tipo de IVA, equivalente ao TN, RED, mas já encontrei uma equivalência (não muito equivalente) http://docs.peppol.eu/pracc/catalogue/1.0/codelist/UNCL5305/ , mas que depois a códigos que o validador não reconhece.. Mas no caso do exemplo não tem essa informação, agora não sei se foi adicionado ao 2.1 Mais uma vez Obrigado, dá para ter uma ideia.
  20. 1 ponto
    Pois mas nem isso deveriam fazer amigo. Eles são uma empresa Publica, e têm ou deveriam ter outra responsabilidade. Nesse caso metiam a tal empresa privada que lhes trata da burocracia da "interligação" de sistemas a falar com o estado 😐 e não enviar info a todos os seus fornecedores da tal empresa privada que só por acaso eles utilizam e estão a publicitar e patrocinar 😕
  21. 1 ponto
    E esse código funciona, dá erros ou onde tens dúvidas? Ou não funciona? Nota: O forum permite inserir código com syntax highllight. Exemplo: int pede_peso(void){ float peso = 0; scanf(" %d", &peso); printf("Peso: %d\n", peso); }
  22. 1 ponto
    Sempre que existe um transporte em veículos da empresa e é emitido uma guia para acompanhar esse transporte, essa guia tem de ser comunicada. Operações internas como transferências de armazém (em que o armazém origem e destino se encontram no mesmo local) não comunico.
  23. 1 ponto
    A definição da função tem que corresponder à forma como é chamada depois no código. Se defines uma função que recebe 30 parâmetros, quando a usas no código, tens que lhe enviar 30 parâmetros. Não podes enviar só 25, 28 nem tão pouco 32. E chamá-la sem parâmetros, muito menos!
  24. 1 ponto
    Bom dia Fabio, posso tentar ajudar nas tuas duvidas, mas convém consultares a documentação oficial da AT: http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/Pages/certificacao-de-software.aspx http://info.portaldasfinancas.gov.pt/pt/apoio_contribuinte/SAFT_PT/Paginas/news-saf-t-pt.aspx 1. a) A melhor forma de teres a certeza do formato é analisares o ficheiro de validação do SAF-T para o campo DocumentNumber. Mas basicamente a série é uma forma de identificar unicamente a numeração. Por exemplo podes ter a série por posto e juntas o ano, ficando P12018 (ex: FR P12018/1). Não podes ter o caracter de espaço na série. b) O código hash é gerado com a chave privada, usando alguns campos do documento (dataemissão;datahorasistema;numero;total;hashdocanterior). No caso do primeiro documento, como não tens documento anterior, omites esse conteúdo. Essa parte de extrair 4 caracteres do hash será apenas na impressão do documento para entregar ao cliente. c) Não entendi a duvida mas os documentos fechados e assinados não podem ser alterados. d) Todos os documentos que possam ser entregues a clientes têm de ser assinados (faturas, contas, etc). O prazo de envio do SAF-T é atualmente até ao dia 20 do mês seguinte. e) Para cancelamento de algum produto, deve ser feita uma nota de crédito. A anulação julgo que só em casos extremos (por exemplo, engano no NIF) 2. Esse erro indica que estás a exportar um produto (com o código MO) na parte dos documentos, que não referenciaste no inicio do SAF-T, na parte dos produtos 3. Não tenho conhecimento se existe alguma API que facilite, mas tenta ver o tópico SAFT-PT: debate de dúvidas e ideias no forum, tem lá bastante informação que ajudou-me na altura que fiz. Espero que ajude, nelsonr
  25. 1 ponto
    Acho que isto te deve ajudar: https://docs.oracle.com/javase/tutorial/jdbc/basics/retrieving.html
×

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.