Saf-t Pt | ZWAME Fórum
Discussão em 'Programação' iniciada por naag, 8 de Outubro de 2007. (Respostas: 71; Visualizações: 18374)
Gostaria de alguns esclarecimentos sobre o SAF-T-PT que embora tenha consultado as FAQ não obtive resposta. Quem puder que me dê umas dicas...
1 - Tenho um cliente que faz vendas ao balcão (90% das vendas). Essas vendas ao balcão não têm cliente associado. O que colocar na exportação dos dados?...
2 – Quando nos documentos de venda/ficheiro de clientes/etc.. os dados não estão preenchidos, mas no modelo SAF-T-PT é obrigatório, o que fazer? Os dados são exportados vazios?... ou não são exportados?...
3 - Como testar o ficheiro gerado?... existe alguma forma de importar em algum lado para testar a exportação...
Ora bem, do pouco que eu entendo...
1 - As vendas ao balcão são, normalmente, vendas a dinheiro logo têm que ter sempre um cliente associado. Pode não ser especificado directamente mas pode ser um "Cliente Final" e/ou "Consumidor Final" - penso que é esta a denominação.
2 - Penso que tens que os criar na tua base de dados, ou seja, se o campo é obrigatório ele tem de ser mostrado. Suponho que os valores "0" ou "<id_campo></id_campo>" sejam válidos. (não tenho certeza)
3 - Não conheço nenhum mecanismo para isso. Suponho que o melhor a fazer será enviares um mail para a ASSOFT uma vez que são eles que estão de volta deste assunto. Eu não tive sorte no mail que enviei. Mas liga para lá que é melhor!
Um boa ideia será, também, confrontares alguém das finanças locais para o assunto. Isto é uma questão de fiscalidade com fins de auditoria de contas de pessoas/empresas, ao que li.
Se tiveres resposta coloca-as aqui para sabermos! 1abraço!
Gostaria de alguns esclarecimentos sobre o SAF-T-PT que embora tenha consultado as FAQ não obtive resposta
Um dia - em Abril de 2007 - liguei para a ASSOFT sobre este problema (nessa altura ainda se pensava que esta brincadeira tinha entrado em vigor em 1/1/2007). Disseram-me que quem sabia responder às minhas questões era o Sr. Presidente. Ora, como o Sr. Presidente não estava disponível, fiquei na mesma. Fiquei com a sensação de que isto estava a ser tratado de forma pouco profissional.
Ora, passados uns meses, aparece a FAQ (produzida com os pés!!) no site da ASSOFT. As perguntas são justíssimas, dada a patente incapacidade de produzir documentação técnica clara e concisa por parte das entidades envolvidas na matéria. Mas as respostas são, uma vez mais, pouco claras, levantando novas dúvidas sobre como implementar as melhores soluções para um problema criado por quem não sabe explicar o que pretende.
Relativamente às 3 questões que colocas não te sei dizer com certeza como deves proceder.
Lembra-te sempre disto: os dados que saiem têm por base os dados que entram. Se o teu cliente não preenche todos os dados, é responsabilidade da aplicação assegurar a coerência dos dados antes de os armazenar.
As respostas seguintes são a opinião de um zé-ninguém na matéria, a braços com o mesmo problema:
Se te referes aos dados do cliente (nome, NIPC, morada, etc), terá de existir (porventura já existe) um cliente 'genérico'. Se não existe esse cliente genérico, sugiro que o cries - isto é, o teu cliente é que deve criá-lo na aplicação. No momento de produzir o relatório, todos os movimentos que não tenham um cliente associado passam a ser associados a esse cliente 'genérico'.
2. Quando nos documentos de venda/ficheiro de clientes/etc.. os dados não estão preenchidos, mas no modelo SAF-T-PT é obrigatório, o que fazer? Os dados são exportados vazios?... ou não são exportados?...
Os dados obrigatórios devem sempre constar no relatório. Se os valores não existirem, o campo fica vazio.
3. Como testar o ficheiro gerado?... existe alguma forma de importar em algum lado para testar a exportação...
Tens de ser tu a tratar da validação do XML 'cuspido'. Isto é mais uma demonstração da inépcia dos responsáveis pela introdução dos relatórios SAFT em PT que não foram capazes de produzir (ou foram e não o disponibilizam publicamente) um validador das regras que eles decidiram impôr.
Uma vez mais saliento que estas são opiniões pessoais. Na dúvida, não te fies no que disse.
Também estou com muitas dúvidas quanto a este ficheiro.
Basicamente aquele que eles disponibilizam, o SAF-T-PT.xsd serve para usarmos como guia para o ficheiro final consoante as necessidades dos clientes certo?
Agora uma questão, o software de contabilidade está num sistema UNIX, como fazer isto ? Criar um conversor entre os nomes internos dos campos no software de origem e os nomes dos campos segundo este ficheiro "template" ?
naag disse: ↑
Podes usar o XSD que está disponível no site da ASSOFT para verificar se o documento é válido (e bem-formado).
Já alguém conseguiu pôr isto a funcionar ?
Desculpa a pergunta de treta, mas para mim não é treta. Eu de facto, não sei: como usar o XSD (disponível no site da ASSOFT) para verificar se o documento exportado é valido?!?!...
Boas, segue um exemplo simples (mas que serve para o efeito) de como validar um XML contra um XSD, utilizando a linguagem Java:
// Verificar argumentos
System.err.println("Ocorreu um problema: argumentos inválidos");
System.err.println("Modo de Utilização: java XSDValidator ficheiro_xm [ficheiro_xsd]");
// Parsing do documento XML
Document document = parser.parse(new File(argv[0]));
// Cria a fábrica para o W3C XML Schema
[LEFT]      // Compila o schema, consoante a sua localização
Source schemaFile = new StreamSource(new File(argv[1]));
// schema location é referenciado no documento xml (e.g. schemaLocation, etc.)
schema = factory.newSchema();
[LEFT]      // Obtém o Validator para o schema
Validator validator = schema.newValidator();[/LEFT]
[LEFT]      // Efectua a validação
System.out.println("O documento '" + argv[0] + "' é válido.");
System.out.println("O documento '" + argv[0] + "' não e' válido:");
Para compilar, é necessário o JDK >= 5.​
Este exemplo permite validar XSD's de duas maneiras distintas:​
XML sem qualquer referência para o XSD.
XML que indica a localização do XSD (i.e. schemaLocation="schema.xsd").
No primeiro caso, a aplicação deve ser executada com "java XSDValidator documento.xml schema.xsd", enquanto que no segundo basta colocar como argumento o documento xml.
Espero que ajude.​
Boas ppl, podem utilizar este programa para validar o xml
"Altova xmlspy". Não é gratis mas tem 30 dias para ser usado. Nao sei bem qual o site, vcs tem de procurar.
abrem o xsd e este programa cria um "demo" do xml, vcs pegam nesse xml e façam o vco xml.
para testar, ponham o xml e o xds na mesma pasta, dps tem em cima um botao com 1 visto verde q serve para fazer a validação.
Espero que isto vos sirva de alguma coisa...
Novidades como é que isso vai?
Já alguem tem isso a funcionar ?
uma soluçao
Vou tentar desenvolver uma solução até ao Natal.
O objectivo é aproveitar o software GESPOS (escripóvoa) e fazer um standalone que construa o XML SAF ou procurar alguma abertura de integração para o fazer.
Se alguém tiver objectivos idênticos ou que se queira juntar é só avisar.
Tenho estado também com esse software dessa empresa, tou nessa.
Deixo aqui um pouco mais de 'luz' sobre o que realmente é pedido.
O SadPlace deu a melhor dica, Altova XMLSpy. Excelente software para verificar a conformidade do XML criado.
Eu já desenvolvi para as minhas aplicações a geração do ficheiro SAFT quer para facturação, quer para contabilidade. Existem algumas questões +complicadas nestes ficheiros, nomeadamente a data de inserção no sistema de cada um dos documentos que vai ao pormenor do segundo.
Essa questão das VDs é pertinente, mas nos "source documents", se repararem são indicados os campos obrigatórios e mesmo os obrigatórios significa que o "ramo" ou "campo" tem que estar no XML mas pode estar vazio, por ex. Isso já é responsabilidade do cliente final.
Acho que as entidades "competentes" deveriam ter desenvolvido uma aplicação para verificação dos XML gerados antes de os contribuintes lhos enviarem, caso venham a ser pedidos, mas infelizmente já todos conhecemos o país onde vivemos...
A Escripóvoa dispõe do módulo que gera o SAF-T há já algum tempo. É uma questão de actualização!
Pois...mas queria evitar pagar uma actualização.
Eu estive a ver e é possível extender a plataforma (no meu caso baseada em DOS) utilizando DOS Scripting (baseado no freeware nB). Também é possível extender utilizando VB script, embora não refiram na documentação, presumo que é apenas para plataformas windows.
Neste momento estou a considerar (pq não sei DOS Scripting e não tenho muito tempo) ir directamente aos ficheiros DBF e retirar o que preciso. Neste momento não tenho acesso ao GESPOS pelo que não posso ainda fazer nada. No fim de semana já investigo melhor o que o programa permite.
Exemplo de um saf-t-pt.xml gerado por gestix
Oi pessoal, saudações a todos.
De facto as FAQ disponíveis no site da DGCI criam mais problemas que soluções. O melhor era o Governo PT não ter criado nenhuma simplificação do SAF-T recomendado pela OCDE, pois aquele pelo menos seria coerente e consistente com o XSD.
Coloquei um exemplo de um ficheiro SAF-T-PT em http://www.gestix.com/techzone/saf-t-pt.xml para quem quiser consultar. Trata-se de um teste que não estando completo pode ser que ajude. O nosso software é só facturação, logo não tem a parte da contabilidade definida.
Qualquer questão, postar aqui no forum sff.
Eu acho fantástico é estarmos em Portugal e existir essa estranha necessidade de usar inglês... Também vão cruzar dados com a França ou com a Espanha? Sinceramente não me parece!
Obrigadão aí ao Rui! O teu SAF-T dá jeito para "micar"
Tb tenho que produzir uma coisa dessas brevemente... O que digo... SAF(a)-T(e)
Neste momento estou a considerar (pq não sei DOS Scripting e não tenho muito tempo) ir directamente aos ficheiros DBF e retirar o que preciso.
Bem, em primeiro nada a fazer :| eles não "dão" isso assim... infelizmente
Quanto aos DBF nem sequer tentava ir por ai... aquilo parece um campo de minas!
PS - desculpem os 2 Posts seguidos
Uma dúvida: no ficheiro que referes (obrigadão, desde já) incluis PurchaseInvoices (isto é, documentos de compra). Mas na especificação só vejo referência a documentos de venda (SalesInvoices) (estamos a falar de software de gestão comercial _sem_ contabilidade). Podes dar algum lamiré sobre isto?
Outra pergunta: o documento gerado não pode ser segmentado em vários documentos mais pequenos? Por exemplo, um cliente que tenha dezenas de milhares de documentos num determinado exercício irá gerar um ficheiro 'gigante'. Torna-se um pouco 'incómodo' gerar e manusear tanta informação num só documento (já para não falar que a validação desse documento será loooonga).
Tens razão: PurchaseInvoices não está no esboço português, apesar de muitas aplicações de gestão comercial incluirem essa informação, a qual, naturalmente, é muito pertinente para a verificação das obrigações fiscais dos contribuintes empresariais. O nosso software é multi-nacional (dá para diversos países) pelo que a presença do elemento PurchaseInvoices será retirado do ficheiro quando configurado para o país Portugal.
O documento gerado não pode ser partido em blocos ou perder-se-ia a conformidade com a estrutura de dados definida.
Para quem trabalha em C, Perl, PHP, etc, a libxml2 é uma das melhores bibliotecas para gerar o ficheiro com pouca programação, minimizando os erros de codificação.
slack_guy: acho que eles nem se lembraram disso! Gostava de ver o SAF-T de um hipermercado a ser processado! Mesmo sendo tudo Vendas a Dinheiro, com "Consumidor Final" e "Contribuinte Final"!
hahahah vai ser lindo
Rui: experimentei o vosso software ontem o Gestix (estou certo?) mas tenho uma menos boa opinião acerca de umas coisas. Se quiseres trocar ideias manda PM ou assim!