Jump to content

Leaderboard

  1. nunopicado

    nunopicado

    Moderator


    • Points

      66

    • Content Count

      6,036


  2. marcolopes

    marcolopes

    Member


    • Points

      62

    • Content Count

      1,373


  3. chesser

    chesser

    Member


    • Points

      32

    • Content Count

      237


  4. HappyHippyHippo

    HappyHippyHippo

    Member


    • Points

      28

    • Content Count

      14,767



Popular Content

Showing content with the highest reputation since 05/22/2018 in all areas

  1. 4 points
    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 points
    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 points
    Se alguém usar .NET, o seguinte link poderá ter interesse: https://github.com/UblSharp/UblSharp
  4. 4 points
    Eis as informações que conseguir reunir: ASSOFT: https://www.assoft.org/pt/noticias/78/norma-europeia-de-fatura-eletronica http://vexillum.pt/fatura-eletronica/ The eInvoicing Workshop https://www.cen.eu/work/areas/ICT/eBusiness/Pages/eInvoicing.aspx Um site holandês dedicado ao E-Invoicing, onde encontrei documentos e informação técnica valiosa: https://eeiplatform.com/category/standards/ LINKS: (NOTA: estas informações são MAIS DETALHADAS do que a treta do DVD vendido pelo IPQ) http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=COM:2017:590:FIN http://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX%3A32014L0055 https://standards.cen.eu/dyn/www/f?p=204:7:0::::FSP_ORG_ID:1883209&cs=1E81C9C833655EEDC7010C8D0A2FB786C https://github.com/CenPC434 http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.zip http://www.unece.org/cefact/xml_schemas/index http://www.unece.org/fileadmin/DAM/cefact/xml_schemas/D16B_SCRDM__Subset__CII.zip https://github.com/phax/peppol-validation-engine/ GLOSSARY Term Description CEN = Comité Européen de Normalisation – European Committee for Standardization CEN/TC = CEN Technical Committee – working group CII = UN/CEFACT Cross Industry Invoice – XML representation of an invoice CIUS = Core Invoice User Specification – A specification based on EN 16931-1:2017 that defines certain elements more narrow EN = European Norm – has tighter binding than TR and TS EN 16931 = European Norm instance with ID 16931 – this is the EN that contains the semantic data model for electronic invoices in Europe TR = Technical Recommendation – has lower binding than EN and TS TS = Technical Specification – binding between EN and TR
  5. 3 points
    É 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.
  6. 3 points
    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!
  7. 3 points
    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.
  8. 3 points
    Dá uma olhada no TIdleTimer, um irmão do TTimer sugerido pelo @thoga31 específico para lidar com inactividade. http://lazarus-ccr.sourceforge.net/docs/lcl/extctrls/tidletimer.html Assim não tens de te preocupar com multi-threading nem verificação dos inicios e fins de processos, pois o componente trata disso por ti.
  9. 3 points
    Estou até meio que sem saber o que responder a essa história do professor, pelo que vou deixar para último... 😕 Isso é outra coisa... Ninguém nasce ensinado, e o paradigma OOP é radicalmente diferente do Imperativo. Muitas pessoas (sim, programadores de Java também) não fazem a mais pálida ideia de como se programa realmente em OOP. Acham que programar orientado a objectos é... fazer objectos. É muito mais. Todo o conceito muda, a forma de pensar tem de mudar também, ou apenas terão objectos a fazer o papel de armazéns de código. Recomendo, para entender o conceito OOP, o livro Object Thinking (David West). Não tem nada a ver com Pascal, Java, etc. É um livro para expandir um conceito. Alguns exemplos usados estão em SmallTalk, mas poderiam estar em qualquer outra, visto que são só exemplos para entender o conceito. Já programei muito em Imperativo, e programei muito mais em 'Imperativo com Objectos' - e pensava como os outros que estava a fazer OOP. Actualmente prefiro programar em "OOP a sério", e com anos disto considero que ainda tenho muito para aprender. É uma evolução constante para quem quer realmente aprender, mas dependendo do tipo de software que se quer criar, vale a pena o esforço. As Units do Pascal, que depois chamas na secção Uses, são apenas uma das formas de reutilizar código. Um simples procedimento é uma forma de reutilizar. Um objecto, uma framework - há várias formas de reutilizar código, e podem e devem ser usadas em Pascal (ou qualquer outra LP). Sempre que no teu código usares copy/paste, quase de certeza estás na presença de uma situação onde um qualquer método de reutilização de código se faz necessário. Isso já virou piada entre os programadores de Pascal... Pessoas que nunca tocaram no Pascal a reclamarem dele é motivo para rir. Pessoas que tentam comparar o Standard Pascal - uma LP de 1974 formalizada em 1983, com um conjunto limitado de funcionalidades visto que era uma linguagem pensada para uso académico - com LPs actuais com funcionalidades actuais. Obviamente, nesta comparação, Pascal perde. O que falta a essa malta é aprender a não comparar alhos com bugalhos. Querem comprar com uma LP actual? Então comparem com Delphi actual. E mesmo quando comparam o Pascal 'actual', em vez de compararem linguagens, comparam compiladores - e geralmente acham boa ideia comparar com PascalZIM, que, sem desprimor ao seu criador, é muito fraquinho, tendo apenas uma pequena parte das funcionalidades do Pascal. Bem... Tem de ser, vamos a isto: Se ele disse mesmo isto, podes por favor dizer-lhe que ele é burro que nem uma porta, que não tem competência para ser professor de informática, muito menos de programação, e muito provavelmente não devia ser autorizado nem a operar uma calculadora de bolso... Podes dizer que fui eu que disse! A divisão do código em segmentos menores - sejam métodos, funções, procedimentos, rotinas, units, módulos, ou o que quiseres chamar-lhe - não é 'típico de programadores de Delphi'. É típico de quem sabe programar, seja em que linguagem for. Colocar todo o código no bloco principal? A sério? Até o Basic evoluiu para além disso. Imagina criar um projecto com milhões de linhas de código, todas no bloco principal. Ui, que lindo seria. Se esse é o teu professor, a minha sugestão é fazeres tudo ao contrário do que ele mandar. Aprendes mais a limpar o pó a livros de lógica e algoritmia do que a ser ensinado por quem quer que seja que te diga isso.
  10. 3 points
    O Application.ProcessMessages é largamente usado para 'desenrascar' esse problema, mas o seu uso não é sem custos... Este método serve para 'avisar' o programa para processar as mensagens (duh! ) que estão na queue do Windows, independentemente de quais são e do risco associado à execução de mensagens fora de ordem. Antes de mais, uma explicação simplista do que são 'mensagens': O GUI do Windows funciona porque os seus elementos enviam mensagens uns aos outros com indicação do que querem fazer. Por exemplo, quando clicas num botão, é enviada uma mensagem para o componente encarregue de alterar o aspecto visual do botão (que o faz parecer 'pressionado' visualmente) que por sua vez manda uma mensagem à form para se redesenhar para que o novo aspecto seja mostrado, há uma mensagem a dar iniciação do trabalho do botão, etc. Ao fazer ProcessMessages, estás a forçar a main thread do programa a executar tudo o que estiver na fila, e isto tem, de entre outras, as seguintes consequências: Estás a parar temporariamente a execução da tarefa principal, obrigando-a a demorar mais tempo Estás a mandar executar mensagens a meio da tarefa, sem saber quais as mensagens que lá estão nem os problemas que a sua execução forçada pode causar. No caso, a tua ideia faz com que ele pare a leitura dos dados, actualize o UI ao processar as mensagens de actualização que estão pendentes, e volta a ler, e voltar a parar, e por aí fora até completar a leitura. Como à primeira vista, isto funciona, muita gente o faz. O que muitos desconhecem é que, ao fazer isto, podem estar com uma simples linha a introduzir bugs no programa, bugs esses que são de detecção extremamente difícil pois existem pela execução de mensagens fora da ordem correcta. O caso é tal que podes correr um programa e dar tudo bem, voltas a correr sem alterar nada e os bugs manifestam-se, voltas a correr e está tudo bem, voltas a correr e aparecem bugs completamente diferentes dos primeiros. Ou seja, o pesadelo de qualquer programador. Por outro lado, dependendo das mensagens pendentes, o resultado pode nem ser o esperado, e não resolve sequer o problema inicial. Podes agora 'resolver' assim, e noutro programa em que te depares com um problema semelhante, resolves usar o mesmo, mas nesse outro programa não funcionar, por um qualquer motivo. Isto retira-te a previsibilidade das soluções, o que te obrigará a perder tempo à procura da solução de cada vez que te surgir o problema. E se o utilizador for dado a clicar à toa enquanto espera, como há tantos por aí, o resultado é muitas vezes o crash do programa, porque independentemente de lhe mandarmos processar as mensagens, a thread continua a ser só uma, e nem sempre com capacidade de fazer tudo o que lhe pedem. Nota: Não estou com isto a dizer que nunca se deve usar o ProcessMessages, ou que no teu caso não resolva o problema sem introduzir outros. Tudo depende do código circundante ao ProcessMessages. E mesmo quando os bugs aparecem, podem ser coisas tão banais quanto uma barra de progresso que anda para a frente e depois volta atrás, para depois voltar pra frente, não afectando nada de especial senão o aspecto visual. Mas há casos bem mais graves, o que me leva a recomendar que quem não saiba exactamente o que está a acontecer, ignore o 'remendo' que é o ProcessMessages, em favor de uma solução mais previsível, como o uso de multi-threading. Nota 2: Multi-threading não é, no entanto, um mar de rosas. É preciso perder algum tempo para sequer começar a ter ideia do ninho de ratos que aquilo é. No entanto, a partir do momento que saibas usar e implementares com as devidas protecções, é mais previsível e consistente do que correr mensagens desconhecidas a meio de uma tarefa.
  11. 2 points
    É perfeitamente possivel. O standard UBL, tal como outros, já existe há alguns anos. Existem várias empresas de tratamento de facturas online que recebem facturas dos clientes que os contratam em formato UBL ou outro. Por isso essas empresas já tratam esse ficheiros. A questão aqui está na forma como isto vai funcionar, - Os ficheiros vão ser enviados para um local central único? ou vão ser enviados para cada uma das entidades publicas? Via webservice ou email ou outro? - Os ficheiros XML vão ser simples ou vão obrigar a assinatura? Se for para enviar via email para cada entidade, sem assinatura digital, então é só gerar o ficheiro e enviar. No problem. Se for para enviar via webservices para cada entidade que podem utilizar webservices diferentes então temos problemas. Esta opção não me parece viável. Se for para enviar para um webservice centralizado obviamente têm que disponibilizar informação sobre esse webservice. Sinceramente parece-me que vai ser mesmo a 1ª opção. Pelo sim pelo não, o melhor é desenvolver já a geração do XML de acordo com as especificações UBL 2.1. Depois o resto logo se vê...
  12. 2 points
    Atenção que os namespaces nas tags são obrigatórios. Existem vários schemas separados no UBL por isso cada tag tem que indicar a que namespace pertence senão torna-se impossível fazer a validação correcta do XML. Até porque existem tags com o mesmo nome em namespaces diferentes. Se ignorarem os namespaces nas tags a validação do ficheiro vai dar erro.
  13. 2 points
    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
  14. 2 points
    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!!!)
  15. 2 points
    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.
  16. 2 points
    Tens várias dúvidas, vou tentar ajudar ponto a ponto: Não podes ligar um equipamento RS232 a outro em RS485, têm características completamente diferentes, Tens que ligar RS232 a RS232 ou RS485 a RS485 Uma vez que a decisão tem que ser tomada pelo PLC, eu ligava o PLC ao medidor de pH, o HMI, por norma é só para mostrar e/ou editar valores, É um Interface, só. Se Usares o HMI ele tem que comunicar com o medidor de pH e depois enviar o valor para o PLC, trabalho desnecessário, Se usares o PLC é direto. Tens que configurar o PLC e o medidor de pH para o mesmo tipo de comunicação (RS232 OU RS485) tens que configurar as características da comunicação, tanto num lado como no outro, o baudrate, data bits, stop bits, etc... têm que ser iguais, caso contrário não comunica corretamente. Também tens que configurar o endereço (modbus) do slave, caso contrário quando o PLC tentar comunicar com ele, ele não responde (numa rede modbus podes ter até 31 slaves, e os endereços podem ir desde 0 até 254). Depois de configurares as portas de comunicação corretamente, tens que configurar o protocolo de comunicação. Em princípio o deves usar o Modbus-RTU, do lado do PLC é mais fácil. o Modbus é um dos protocolos de comunicação mais usados no mundo e há muita informação na net sobre isso e como é que funciona. Resumidamente: Do lado do Slave (medidor de pH) tens uma tabela de endereços das variáveis, por exemplo: 40001 = pH 40002 = Temperatura 40003 = .... Do lado do Master (PLC), só tens que pedir ao "Endereço Modbus do Medidor de pH" Dá-me 2 valores a começar no 40001 Quando o Slave recebe o pedido a cima, responde, com os valores Depois é só fazer o código do lado do PLC para comunicar com o medidor de pH (deve ser só 1 bloco que será chamado de X em X tempo) e o restante código para controlar o pH Ou seja, resumidamente: Escolhes o protocolo RS232 ou RS485 Configuras as portas de comunicação dos 2 equipamentos Configuras o protocolo nos 2 equipamentos Fazes software (chamas os blocos) de comunicação
  17. 2 points
    A melhor coisa que podes fazer é esquecer o goto e o label. Mal usados (o que é muito comum), só te vão criar problemas. Usa ciclos, que é a forma correcta de repetir comandos. Dito isto, a mensagem de erro dá-te uma dica... Tens de configurar o compilador para usar o switch Sg. Tens de ver nesse compilador onde é que o podes configurar, e adicionar lá essa opção.
  18. 2 points
    Penso que o que procuras está a ser discutido aqui: https://www.portugal-a-programar.pt/forums/topic/76837-norma-europeia-de-fatura-eletrónica/
  19. 2 points
    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"));
  20. 2 points
    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.
  21. 2 points
    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
  22. 2 points
    O findfirst procura o primeiro ficheiro, o findnext procura os seguintes. Em ambas as funções é devolvido um valor em que se for zero quer dizer que encontrou. Assim, um exemplo rápido e fácil será: Uses SysUtils; Var Info:TSearchRec; begin if findfirst('*.pas', AnyFile, Info)=0 then begin //procura o primeiro ficheiro e coloca a informação no record Info repeat writeln(info.name); until findnext(info)<>0; //procura o próximo ficheiro end; findclose(Info); //fecha find end. O registo Info tem "todas" as informações do ficheiro: Nome, data, tamanho, etc. Estrututa do TSearchRec: https://www.freepascal.org/docs-html/rtl/sysutils/trawbytesearchrec.html
  23. 2 points
    @passarito, estamos em 2018, não em 1978 😂 A função upcase pode ser usada com caracteres e strings. readln(linha); linha := UpCase(linha); if linha = 'SIM' then begin // doçura de código end;
  24. 2 points
    Olá xambas. O que quero dizer é que fiz o POST do XML diretamente para o Endpoint. Uma coisa importante com o servidor de testes é que, da minha experiência, só funciona com o user de testes (por favor confirma). 'at_username' => '599999993/37', 'at_password' => 'testes1234' Peguei no teu XML, fiz algumas alterações e consegui que o teu XML passasse. Aqui estão as diferenças entre ambos: https://www.diffchecker.com/tmTqCSnF (antigo do lado direito e novo do lado esquerdo). Repara que, apesar de tu veres um erro genérico (Internal Server Error) quer dizer que no fundo há um erro mais detalhado que não consegues ver. Possivelmente esse erro é aquele que indiquei da estrutura do XML. Sugiro também que o programa que gera o XML retire espaços em branco e newlines do XML http://www.webtoolkitonline.com/xml-minifier.html <?xml version="1.0" encoding="UTF-8"?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:doc="https://servicos.portaldasfinancas.gov.pt/sgdtws/documentosTransporte/"><S:Header><wss:Security xmlns:wss="http://schemas.xmlsoap.org/ws/2002/12/secext"><wss:UsernameToken><wss:Username>xxxxxxxxx/1</wss:Username><wss:Password>N4rXr+dB2ukThO75sSUblA==</wss:Password><wss:Nonce>IOcKjb7C5YI9vCtHQQ/eh4gOLnwMpYIloKoQx3qRNfmuy5CKorxKg4Sgy7BKNzS8IbtRlXjlMNY8rywYVoNbji4tsRy+6FsTM6tOP5P/f39xPUXG23B2xqHFX7LQ9ZLb1WBsdwA7G3EPl49gQCVQF5QWIzbu9TrkVraVR5ACWJx2h6YlXlOT/IO7KpN+z6htRhvWR2VrXwd7Vuku+eOxQSPfq/V+hLszWLwcJJnNQjuVsGDFV0Q/PPW9roN+6yIGaeATQbc07OtZdYLENz0gGDW7isdmttpFWhZ9t85Bsge8JDmWyl/XI9AV9ZULL1EZ+euWRfYmvboSGcLTvlUoeQ==</wss:Nonce><wss:Created>UL4jE55BGauN4C0eDKgA6a0Iq9gB8UE1VAvk0nXpKdM=</wss:Created></wss:UsernameToken></wss:Security></S:Header><S:Body><doc:envioDocumentoTransporteRequestElem><TaxRegistrationNumber>123456789</TaxRegistrationNumber><CompanyName>SHM Eng.</CompanyName><CompanyAddress><Addressdetail>Rua Tal, Sitio Tal</Addressdetail><City>São Jorge da Murronhanha</City><PostalCode>4444-555</PostalCode><Country>PT</Country></CompanyAddress><DocumentNumber>GT SERIE0/99990</DocumentNumber><MovementStatus>N</MovementStatus><MovementDate>2017-03-01</MovementDate><MovementType>GT</MovementType><CustomerTaxID>599999993</CustomerTaxID><CustomerAddress><Addressdetail>RUA JOSÉ PEREIRA DO NASCIMENTO, Nº 51 LUANDA</Addressdetail><City>LUANDA</City><PostalCode>4444-555</PostalCode><Country/></CustomerAddress><CustomerName>CASAIS ANGOLA, ENGENHARIA E CONSTRUÇÃO SA</CustomerName><AddressTo><Addressdetail>Endereço1 Endereço2</Addressdetail><City>Localidade</City><PostalCode>4444-555</PostalCode><Country>PT</Country></AddressTo><AddressFrom><Addressdetail>Rua Tal, Sitio Tal</Addressdetail><City>São Jorge da Murronhanha</City><PostalCode>4444-555</PostalCode><Country>PT</Country></AddressFrom><MovementEndTime>2018-06-13T17:38:00</MovementEndTime><MovementStartTime>2018-06-13T13:38:00</MovementStartTime><VehicleID>LD-50-36-EW</VehicleID><Line><ProductDescription>C35/45 S4 D20</ProductDescription><Quantity>7</Quantity><UnitOfMeasure>M3</UnitOfMeasure><UnitPrice>0</UnitPrice></Line></doc:envioDocumentoTransporteRequestElem></S:Body></S:Envelope> Experimenta efetuar as alterações no teu programa que gera o XML para ficar de acordo com aquilo que eu também alterei. Se quiseres experimentar algo que funcione coloquei numas páginas atrás código PHP para as guias de transporte.
  25. 2 points
    não és obrigado, no entanto torna tudo mais simples.... o teu problema actual é que estás a executar o código de processamento do envio do formulário quando ainda estás a apresentar-lo
×

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.