Jump to content
pv2013

SAFT-PT: debate de dúvidas e ideias

Recommended Posts

trs80

Todos.

Boas,

Quanto a enviar os Recibos "RG", o que estão a colocar nos totais? valores COM IVA ?

ou estão a guardar os pagamentos parciais dos RG da mesma forma que dos RIC ?

Obrigado

Share this post


Link to post
Share on other sites
nunopicado

Por acaso, ao colocar os valores, não estou a controlar se é RG ou RC, logo, estou a meter valores sem IVA.

Estava com a ideia que já tinha visto esse pormenor! hmmmm

Penso que o que faz sentido é serem valores já com IVA, uma vez que não se colocam as tags Tax para as linhas, logo, nunca se teria como saber o valor real da linha.

Além do mais, recibos RG não dão direito a dedução de IVA, pelo que não faz sentido estar a calculá-lo.

De volta para a prancheta, meter mais uns IF's...


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
trs80

Por acaso, ao colocar os valores, não estou a controlar se é RG ou RC, logo, estou a meter valores sem IVA.

Estava com a ideia que já tinha visto esse pormenor! hmmmm

Penso que o que faz sentido é serem valores já com IVA, uma vez que não se colocam as tags Tax para as linhas, logo, nunca se teria como saber o valor real da linha.

è possível determinar os valores sem IVA fatura a fatura, mas dará um trabalhão, implicaria fazer para os Recibos RG o mesmo que se faz para os outros, mas de forma automática, por exemplo por antiguidade:

FT 1: 60 Euros (10 a 6%, 20 a 13% 30 a 23%)

FT 2: 30 euros (30 a 23%)

REC 1: 40 Euros (paga FT1)

REC 2: 50 euros (paga FT1 e FT2)

percorrendo os recibos por ordem cronológica, obtemos a lista de faturas que pagam e por ordem cronológica vamos "pagando" os varios Escaloes de forma ponderada

o REC 1 paga 50% de 10, de 20 e de 30

6%: 5,00 pagos = 4,72 + 0,28

13%: 10,00 pagos = 8,85 + 1,15

etc

Teremos de ir guardando os valores pagos SEM IVA e de IVA para os recibos seguintes saberem o que vão pagar...

Agora custa-me na alma e no bolso fazer isto tudo para depois não servir para rigorosamente nada pois na prática estes Recibos RG não vao servir para nada à AT...

Além do mais, recibos RG não dão direito a dedução de IVA, pelo que não faz sentido estar a calculá-lo.

De volta para a prancheta, meter mais uns IF's...

Concordo, é assim que vou fazer, pois é bem mais fácil...

Tenho as minhas dúvidas no entanto se é bem isso que eles querem... a ver vamos...

Share this post


Link to post
Share on other sites
nunopicado

è possível determinar os valores sem IVA fatura a fatura, mas dará um trabalhão, implicaria fazer para os Recibos RG o mesmo que se faz para os outros, mas de forma automática, por exemplo por antiguidade:

No meu caso, dá mais trabalho meter com IVA, porque a criação dos recibos já está para o RIC, logo, já vai buscar os valores sem IVA.

Mas acho que faz mais sentido nos RG valores com IVA, logo, vou ter de meter uns if's para ficar bem:

IF DocCode='RG' THEN Preco:=Preco+IVA

:P


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
bugFree

Julgo que são tudo valores sem IVA.

Campos 4.4.2 e 4.4.3, "...soma de controlo..." dos campos 4.4.4.14.4 e 4.4.4.14.5, respectivamente.

Campos 4.4.4.14.4 e 4.4.4.14.5, "...sem impostos e eventuais descontos."

Todos os valores do SAFT são sem IVA, certo ?

Edited by bugFree

What's better: Coding solo or as part of a team?

A team means you have to fix someone else's bugs. Coding solo means you have to write all the bugs yourself.

Share this post


Link to post
Share on other sites
nunopicado

Todos os valores do SAFT são sem IVA, certo ?

Não creio...

Repara, eles pedem valores sem impostos e eventuais descontos... OK, estamos de acordo.

Mas os recibos RG não são sujeitos a impostos (os impostos respectivos foram na factura e não no recibo), logo, não podes deduzir ao valor algo que não pertence ao documento.


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
bugFree

Mas já estás a fazer e enviar o SAFT assim ?

Tens a certeza ?

Não sei se alguém já envia o SAFT 1.03 com Recibos, se puder dar uma opinião...


What's better: Coding solo or as part of a team?

A team means you have to fix someone else's bugs. Coding solo means you have to write all the bugs yourself.

Share this post


Link to post
Share on other sites
nunopicado

O meu já é 1.03 desde novembro, e têm ido recibos, mas sem IVA, porque pensava que tinha feito isso e afinal não fiz.

Quanto a certezas, tenho como de tudo o que diz respeito à AT: "É relativo!" :)

Mas acredito que é assim, tanto que vou alterar o meu para mandar os valores totais nos recibos RG.


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
bugFree

Mas o OC 30154/2013 não diz que só é necessário envio os Recibos RC ?

Estão a enviar todos ?


What's better: Coding solo or as part of a team?

A team means you have to fix someone else's bugs. Coding solo means you have to write all the bugs yourself.

Share this post


Link to post
Share on other sites
nunopicado

Sim, estou a enviar todos (que no meu caso, são apenas RG, até agora!)

O ofício diz-te que os RC são obrigatórios...

Mas as regras do SAFT dizem-te que deves enviar todos os dados obrigatórios, mais todos os outros que, não sendo obrigatórios, existam na aplicação.

Logo, RG e RC.

Aliás, caso contrário, não precisavas do código RG, apenas existiria o RC.


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
trs80

Mas o OC 30154/2013 não diz que só é necessário envio os Recibos RC ?

Estão a enviar todos ?

O oficio não diz nada quanto aos recibos "normais" em si...

a indefinição permanece, o facto é que para mandar estes recibos, precisamos de por lá alguma coisa...

ou não se mandam, ou se se mandam coloca-se TaxPayable a zero e por consequencia o NetTotal=GrossTotal

Por mim os cliente vao ficar com uma opcao de Exportar Recibos Sim/Nao e eles que decidam....

  • Vote 1

Share this post


Link to post
Share on other sites
xico21

Estou a trabalhar contra relógio para certificar o programa e tenho uma dúvida que deve parecer muito básica, mas aqui vai:

Tenho que assinar os documentos com o hash do documento anterior, a minha dúvida é a seguinte:

quando referem o documento anterior é o documento anterior da mesma série que estou a assinar neste momento, correcto ?

Exemplo :

Loja 1 a Factura 39/2013 de 01-10-2013 -> deve consultar hash da Loja 1 - Factura 38/2013 de 27-09-2013

Loja 2 a Factura 39/2013 de 02-10-2013 -> deve consultar hash da Loja 2 - Factura 38/2013 de 08-09-2013

Em caso afirmativo e dado que inicio uma nova série todos os anos o primeiro documento não vai consultar o hash anterior, apenas utiliza os dados do documento presente, certo?

Desde já o meu obrigado.

Share this post


Link to post
Share on other sites
JulioNobre

Olá Xico21 e car4321

Em relação a eventuais reajustes na sequência de numeração de uma série, nomeadamente, por reinício de um novo ano, considero obrigatória a leitura do ponto 1.6 do Ofício Circulado n.º 50.001/2013

"Todos os tipos de documentos deverão ser emitidos cronologicamente em uma ou mais séries (que devem manter-se pelo menos anualmente e que não devem utilizar carateres que violem o esquema de validação ou possam ser interpretados como operadores de XML) devidamente referenciadas e dentro de cada uma numerados sequencialmente. Não pode constar da sequência numérica qualquer outra informação como, por exemplo, o ano ou o número do terminal informático, etc. que, a existir, deverá sempre constar da identificação da série."

Na minha opinião, o que a AT pretende clarificar é que uma vez iniciada uma série, esta deverá manter-se a natureza sequencial para sempre. Nos casos em que se entenda como indispensável o prefixo do ano (ex: 20140001), deve ser criada nova série para o efeito, devendo também esta manter a natureza sequencial enquanto for usada.

Para terminar, chamo atenção que devem ser tomadas todas as medidas para prevenir duplicados na combinação TipoDoc+Série+NrSequenciaNaSérie ao longos dos próximos anos. No casos em que tal aconteça, o portal eFatura irá simplesmente ignorar os documentos por assumir que estes já foram anteriormente submetidos. Por isso, muita atenção às "sequências anuais".

Bom 2014 para todos! :)

Share this post


Link to post
Share on other sites
car4321

Olá Xico21 e car4321

Em relação a eventuais reajustes na sequência de numeração de uma série, nomeadamente, por reinício de um novo ano, considero obrigatória a leitura do ponto 1.6 do Ofício Circulado n.º 50.001/2013

"Todos os tipos de documentos deverão ser emitidos cronologicamente em uma ou mais séries (que devem manter-se pelo menos anualmente e que não devem utilizar carateres que violem o esquema de validação ou possam ser interpretados como operadores de XML) devidamente referenciadas e dentro de cada uma numerados sequencialmente. Não pode constar da sequência numérica qualquer outra informação como, por exemplo, o ano ou o número do terminal informático, etc. que, a existir, deverá sempre constar da identificação da série."

Na minha opinião, o que a AT pretende clarificar é que uma vez iniciada uma série, esta deverá manter-se a natureza sequencial para sempre. Nos casos em que se entenda como indispensável o prefixo do ano (ex: 20140001), deve ser criada nova série para o efeito, devendo também esta manter a natureza sequencial enquanto for usada.

Para terminar, chamo atenção que devem ser tomadas todas as medidas para prevenir duplicados na combinação TipoDoc+Série+NrSequenciaNaSérie ao longos dos próximos anos. No casos em que tal aconteça, o portal eFatura irá simplesmente ignorar os documentos por assumir que estes já foram anteriormente submetidos. Por isso, muita atenção às "sequências anuais".

Bom 2014 para todos! :)

Concordo em tudo.

O mais relevante, para mim, é a tendência em se esquecer o mínimo de um ano em que tem de ser mantida cada série, a não ser numa situação excecional.

Só não entendo a questão que referes, logo no início do teu post, sobre reajuste da renumeração. Não era essa a questão discutida.

Share this post


Link to post
Share on other sites
resmunga

Onde encontraram a informação sobre o saft 1.0.3 ou só existe o xsd ?

Portaria n.º 274/2013, de 21 de Agosto

Share this post


Link to post
Share on other sites
nunopicado
  • Vote 2

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
JulioNobre

Concordo em tudo.

O mais relevante, para mim, é a tendência em se esquecer o mínimo de um ano em que tem de ser mantida cada série, a não ser numa situação excecional.

Só não entendo a questão que referes, logo no início do teu post, sobre reajuste da renumeração. Não era essa a questão discutida.

Sim, eu também concordo que essa não era a questão a ser discutida e não que qualquer forma juntar prejudicar o debate. Porém, achei importante salientar um aspeto que no passado sempre foi legalmente permitido, agora claramente inadequado, mas nem sempre detetado atempadamente. Como exemplo, refiro que algumas aplicações implementavam até há pouco tempo automatismos para ajustar a posição da sequência no início de cada novo ano, resultando numa das seguintes transições:

Exemplo 1 - SérieX/1456 de 2012 => SérieX/1 de 2013

Exemplo 2 - SérieX/1201456 (último de 2012) => SérieX/1300001 (primeiro de 2013)

Sendo, naturalmente, mais grave o Exemplo 1, quando em Fevereiro/2014 for submeter o SAFT referente a Janeiro/2014, descubra (se descobrir) que o documento SérieX/nnnnn foi ignorado pela Portal da AT, por já ter sido submetido um documento com a mesma série e número, mas emitido em Janeiro/2013 e submetido em Fevereiro/2013.

Embora simples de prevenir, pode, com alguma facilidade, passar despercebido.

Um bem haja para todos :)

  • Vote 1

Share this post


Link to post
Share on other sites
Paulo Renato Paixao

boas,

estou a utilizar o componente da CHILKAT e gostaria de saber se alguem tem experiencia com estes componente e me pode ajudar com a geração do Hash.

estou a utilizar o componente RSA e chamando-o do SQL SERVER

Meu código

    DECLARE @rsaEncryptor int
   EXEC @hr = sp_OACreate 'Chilkat.Rsa', @rsaEncryptor OUT
   IF @hr <> 0
   BEGIN
       PRINT 'Failed to create ActiveX component'
       EXEC @hr = sp_OADestroy @rsa
       RETURN
   END

    EXEC sp_OAMethod @rsaEncryptor, 'UnlockComponent', @success OUT, 'Anything for 30-day trial'
   IF @success <> 1
     BEGIN
       PRINT 'RSA component unlock failed'
       EXEC @hr = sp_OADestroy @rsaEncryptor
       RETURN
     END

   --  Encrypted output is always binary.  In this case, we want
   --  to encode the encrypted bytes in a printable string.
   --  Our choices are "hex", "base64", "url", "quoted-printable".
   EXEC sp_OASetProperty @rsaEncryptor, 'EncodingMode', 'base64'
   EXEC sp_OASetProperty @rsaEncryptor, 'Charset', 'utf-8'

   ----  We'll encrypt with the private key and decrypt with the public
   EXEC sp_OAMethod @rsaEncryptor, 'ImportPrivateKey', NULL, @privateKey

   DECLARE @usePrivateKey int
   SELECT @usePrivateKey = 1
   DECLARE @encryptedStr nvarchar(4000)

   EXEC sp_OAMethod @rsaEncryptor, 'EncryptStringENC', @encryptedStr OUT, @plainText, @usePrivateKey
   --PRINT @encryptedStr
   EXEC @hr = sp_OADestroy @rsaEncryptor

   -- Insert statements for trigger here
               UPDATE Recibo
               Set Recibo.Hash = @encryptedStr
               FROM Recibo r Join inserted i on r.ItemID = i.ItemID

O primeiro resultado tem 172 caracteres, o que me parece ok, para as especificações das finanças, mas o segundo resultado vai para os 344 carateres e espero um resultado que seja tb de 172 caracteres.

1ª Linha

Clean Text: 2013-02-01;2013-12-30T22:18:32.727;13159;4.06;

Hash Result: WAcW/BF3QLOWPsMAHVzlseCGW3AUwbO+Bpjn4t8Jmo7fVmBn/+smarAISO7lva3Q+SY3EOyh/7glGQGH+ejeCHho0SV9VFhkZtGL5svBgFeXv+3+FGNGCiEbI2Ld5d2if3QN/s+9t3/f4G7r97v/VpkfrxgjmxhJmZRqWTP3LAk=

2ª Linha

Clean Text: 2013-02-01;2013-12-30T22:19:01.380;13160;4.05;WAcW/BF3QLOWPsMAHVzlseCGW3AUwbO+Bpjn4t8Jmo7fVmBn/+smarAISO7lva3Q+SY3EOyh/7glGQGH+ejeCHho0SV9VFhkZtGL5svBgFeXv+3+FGNGCiEbI2Ld5d2if3QN/s+9t3/f4G7r97v/VpkfrxgjmxhJmZRqWTP3LAk=

Hash Result: PvyCNUhrjDnBxwIiFzZxFCrqsoaJRq3Hg6NHC+mgpMZ+Pmlfg+uUQ/9ZYrvgWL/hmCw89foRh2UFnXuzTiSf9RrAICxSvQHNYUEOqNSqWP9eKoAmUd/28ZUATapJGys7/a2sdlfqLaI5ekWnh5mWJPYiorUPLQaBvpVSMEqk2T4dnit/GSUwD65wAEhv7KPhNQ8PL0fU7vzEuc/Z1gReVTVz1NOguSVyeeWW5Ez6fUyZSrH0c+9HzrayI2uyhRASU17suSnEoybLeoL4FoYXl8dySy687Aa2gEGLMCI3ycZVCzRmwaLBxl7YOhnv06OMgArWf8tfJKm4g9oiBpp8Rg==

Alguma ajuda, por favor.

Obrigado

Share this post


Link to post
Share on other sites
xico21

Sim, eu também concordo que essa não era a questão a ser discutida e não que qualquer forma juntar prejudicar o debate. Porém, achei importante salientar um aspeto que no passado sempre foi legalmente permitido, agora claramente inadequado, mas nem sempre detetado atempadamente. Como exemplo, refiro que algumas aplicações implementavam até há pouco tempo automatismos para ajustar a posição da sequência no início de cada novo ano, resultando numa das seguintes transições:

Exemplo 1 - SérieX/1456 de 2012 => SérieX/1 de 2013

Exemplo 2 - SérieX/1201456 (último de 2012) => SérieX/1300001 (primeiro de 2013)

Sendo, naturalmente, mais grave o Exemplo 1, quando em Fevereiro/2014 for submeter o SAFT referente a Janeiro/2014, descubra (se descobrir) que o documento SérieX/nnnnn foi ignorado pela Portal da AT, por já ter sido submetido um documento com a mesma série e número, mas emitido em Janeiro/2013 e submetido em Fevereiro/2013.

Embora simples de prevenir, pode, com alguma facilidade, passar despercebido.

Um bem haja para todos :)

Obrigado a todos, em especial ao JulioNobre e ao Car4321 , pela ajuda prestada.

Já tenho o meu software a assinar os documentos e já validei com o programa da AT.

No que respeita às séries não tenho problema uma vez que o ano faz parte do número/série do documento.

Mais uma vez obrigado a todos e um feliz 2014 :cheesygrin:

Share this post


Link to post
Share on other sites
nunopicado

No que respeita às séries não tenho problema uma vez que o ano faz parte do número/série do documento.

Faz parte do número, ou da série?

Se é da série, tudo bem. Se é do número, vais ter de lhe mexer, uma vez que o OC 50001/2013 diz claramente que tal não é permitido:

1.6. Todos os tipos de documentos deverão ser emitidos cronologicamente em uma ou mais séries (que devem manter-se pelo menos anualmente e que não devem utilizar carateres que violem o esquema de validação ou possam ser interpretados como operadores de XML) devidamente referenciadas e dentro de cada uma numerados sequencialmente. Não pode constar da sequência numérica qualquer outra informação como, por exemplo, o ano ou o número do terminal informático, etc. que, a existir, deverá sempre constar da identificação da série.


"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites
xico21

Faz parte do número, ou da série?

Se é da série, tudo bem. Se é do número, vais ter de lhe mexer, uma vez que o OC 50001/2013 diz claramente que tal não é permitido:

Faz parte da série.

Na série tenho o código do armazém/loja e o ano, o número do documento é sequencial dentro da série.

Mais uma vez obrigado pela ajuda.

  • Vote 1

Share this post


Link to post
Share on other sites
baguera

Faz parte da série.

Na série tenho o código do armazém/loja e o ano, o número do documento é sequencial dentro da série.

Mais uma vez obrigado pela ajuda.

Realmente era mais fácil o ano pertencer a numeração e não a serie, assim obriga todos os anos abrir series Novas

Share this post


Link to post
Share on other sites
nunopicado

Realmente era mais fácil o ano pertencer a numeração e não a serie, assim obriga todos os anos abrir series Novas

Conheço um software (não o meu) que usa uma máscara para gerar as séries automaticamente.

Tipo,se a máscara for [year], a série é sempre o ano, e é gerada automaticamente quando for necessária.

  • Vote 1

"A humanidade está a perder os seus génios... Aristóteles morreu, Newton já lá está, Einstein finou-se, e eu hoje não me estou a sentir bem!"

> Não esclareço dúvidas por PM: Indica a tua dúvida no quadro correcto do forum.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

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.