Jump to content
marcolopes

AT - questões legais

Recommended Posts

marcolopes

Então e este detalhe que reparei agora:

Segundo o proprio oficio circulado, as facturas proforma não são para assinar (ou não é obrigatorio, pelo menos).

A expressão "Este documento não serve de fatura”, coloco-a eu em todos os documentos não assinados... Agora... NÃO permitir alterar o LAYOUT? Então, qualquer utilizador experiente poderá editar os templates e fazer o que bem lhe apetecer, até mesmo colocar lá um "XPTO" de controle, como se o documento estivesse assinado. A AT permite por um lado e proíbe por outro...

Estou a ver que terei de controlar a MENSAGEM fixa inserida nos templates, e verificar se a mesma não foi removida...

Edited by marcolopes

The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
nunopicado

Eu dou liberdade de alteração de layouts, mas alguns campos, podem ser movidos e formatados mas não podem ser eliminados (poder podem, mas se forem os documentos não são impressos).

Claro que nada os impede de meter uma caixa por cima e tapar o que lá está.

Edited by nunopicado

"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
CJCV

na nossa aplicação tudo o que seja documentos de venda , no fim da configuração pede uma senha aleatória.

o operador é obrigado a pedir a senha.

noutras situações bloqueamos mesmo o acesso.

podem editar o layout , mas basta mexer uma virgula que na proxima impressão vai pedir uma senha.

e só nós é que a podemos gerar.

é que em caso de trapalhada, os clientes descartam sempre para a informática, por isso não se pode facilitar !

Edited by CJCV
  • Vote 2

Share this post


Link to post
Share on other sites
bugFree

Boas,

Onde é que já vi isto escrito ?

A quem devem ser emitidas as GT globais ?

Deve criar-se um Cliente/Entidade com NIF 999999990 e nome e morada tipo "Clientes diversos" e "Destinos diversos" ?

Ou emitir com o NIF do próprio e nome e morada ???

Como estão a fazer ?

PS: fiz uma pesquisa por "global" mas devolveu tantos resultados que não tive coragem de procurar...

Se alguém puder dar uma ajuda.

Obrigado.


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

Boas,

Onde é que já vi isto escrito ?

A quem devem ser emitidas as GT globais ?

Deve criar-se um Cliente/Entidade com NIF 999999990 e nome e morada tipo "Clientes diversos" e "Destinos diversos" ?

Ou emitir com o NIF do próprio e nome e morada ???

Não uso guias globais, pelo que não estou muito por dentro, mas ao que li, é para o 999999990, Consumidor Final, sem moradas

PS: fiz uma pesquisa por "global" mas devolveu tantos resultados que não tive coragem de procurar...

Se alguém puder dar uma ajuda.

Obrigado.

E da próxima vez que alguém procurar, já vão aparecer mais dois resultados...

Temos de acabar com a funcionalidade de pesquisa, está a afectar a sensação de coragem dos membros! ;):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
Cr4zyKingLi0n

Boas,

Onde é que já vi isto escrito ?

A quem devem ser emitidas as GT globais ?

Deve criar-se um Cliente/Entidade com NIF 999999990 e nome e morada tipo "Clientes diversos" e "Destinos diversos" ?

Ou emitir com o NIF do próprio e nome e morada ???

Como estão a fazer ?

PS: fiz uma pesquisa por "global" mas devolveu tantos resultados que não tive coragem de procurar...

Se alguém puder dar uma ajuda.

Obrigado.

Sim é isso.

O nif 999999990 e moradas diversas/ clientes diversos.

Share this post


Link to post
Share on other sites
nunopicado

Já repararam, no oficio circulado 50001/2013, onde se demonstra a assinatura para os documentos da tabela 4.3 do SAFT, que o exemplo é um documento chamado RC 005/001?

Acho que já sei onde vão os recibos para o IVA de caixa...


"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

Sim é isso.

O nif 999999990 e moradas diversas/ clientes diversos.

Obrigado.


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
marcolopes

Já repararam, no oficio circulado 50001/2013, onde se demonstra a assinatura para os documentos da tabela 4.3 do SAFT, que o exemplo é um documento chamado RC 005/001?

Acho que já sei onde vão os recibos para o IVA de caixa...

És um especulador! Nem penso sequer implementar este regime...


The simplest explanation is usually the correct one

JAVA Utilities: https://github.com/marcolopes/dma

Share this post


Link to post
Share on other sites
nunopicado

És um especulador! Nem penso sequer implementar este regime...

Hehehe Eu já pensei em fazê-lo, mas por esta altura, sinceramente, é o que menos me preocupa...


"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
nunopicado

Pessoal, mais uma dúvida...

No oficio circulado, os pontos 2.4.3 e 2.5.6 indicam algo assim:

2.4.3. Nestas séries de recuperação, a data do documento corresponde à data do documento manual

e é de todo o interesse que se criem dois campos distintos, de preenchimento obrigatório,

sendo um para a identificação da série manual e o outro para recolher o número manual. Desta

forma evitar-se-ão lapsos na recolha deste tipo de documentos designadamente da série.

O 2.5.6 é semelhante, apenas relativo a documentos recuperados após backup.

Então, imagine-se por exemplo o meu caso, tenho os seguintes campos:

DataDoc -> Data de caixa activa na hora de criação do documento

SystemEntryDate -> Data e hora de sistema na hora de criação do documento

ManDocData -> Data indicada aquando da inserção de um documento manual.

Segundo os nossos amigos, pelo que percebo, o meu DataDoc teria de passar a ter o valor que meto no ManDocData.

Até aí tudo bem, programaticamente é simples de fazer.

Potenciais problemas:

A data de caixa na inserção do documento deixa de ser importante?

Toda a estrutura de pesquisa de documentos é baseada no DataDoc, desde a simples consulta, até à geração do SAFT.

Se eu inserir um documento manual com data do mês passado (e já tiver entregue o SAFT desse mês), essa factura já não vai?

Ou tenho, em alternativa, de enviar:

1. Um SAFT só com essas facturas

2. Todo o SAFT do periodo novamente, esperando que (como é suposto) o sistema descarte as que já tenham ido?


"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
americob

Pessoal, mais uma dúvida...

No oficio circulado, os pontos 2.4.3 e 2.5.6 indicam algo assim:

O 2.5.6 é semelhante, apenas relativo a documentos recuperados após backup.

Então, imagine-se por exemplo o meu caso, tenho os seguintes campos:

DataDoc -> Data de caixa activa na hora de criação do documento

SystemEntryDate -> Data e hora de sistema na hora de criação do documento

ManDocData -> Data indicada aquando da inserção de um documento manual.

Segundo os nossos amigos, pelo que percebo, o meu DataDoc teria de passar a ter o valor que meto no ManDocData.

Até aí tudo bem, programaticamente é simples de fazer.

Potenciais problemas:

A data de caixa na inserção do documento deixa de ser importante?

Toda a estrutura de pesquisa de documentos é baseada no DataDoc, desde a simples consulta, até à geração do SAFT.

Se eu inserir um documento manual com data do mês passado (e já tiver entregue o SAFT desse mês), essa factura já não vai?

Ou tenho, em alternativa, de enviar:

1. Um SAFT só com essas facturas

2. Todo o SAFT do periodo novamente, esperando que (como é suposto) o sistema descarte as que já tenham ido?

Eu só uso um campo de "data" que, na minha opinião tem de ser igual ao do original. Os dois campos DISTINTOS referidos são a Série e o Número do documento original, que logicamente serão diferentes dos do documento registado (atribuídos).

Se aquela data já tiver sido comunicada, não deves comunicar novamente porque provavelmente vai duplicar no e-fatura.

Share this post


Link to post
Share on other sites
nunopicado

Eu só uso um campo de "data" que, na minha opinião tem de ser igual ao do original. Os dois campos DISTINTOS referidos são a Série e o Número do documento original, que logicamente serão diferentes dos do documento registado (atribuídos).

Se aquela data já tiver sido comunicada, não deves comunicar novamente porque provavelmente vai duplicar no e-fatura.

A minha questão é outra.

Imaginemos o seguinte cenário:

Começaste Julho, e como "bom português", mas para fugir à regra, enviaste o SAFT de Junho logo no dia 2013-07-01.

Entretanto, no dia 2013-07-02, pelas 16:30, lembras-te que no dia 2013-06-26 tiveste de passar uma factura no livro, porque tinha faltado a luz - chamemos-lhe a factura A/201.

Em serie própria, dás entrada da dita factura, guardando da original os campos serie, numero, e claro, indicando a data da factura manual.

Geraste assim uma FTM 2013/3, que é uma cópia do documento original [/b]A/201[/b].

O SystemEntryDate será sempre o de inserção do documento no sistema, neste caso algo como 2013-07-02T16:30:00.

A Data do Documento (O campo <InvoiceDate> no SAFT) será, segundo o oficio circulado, a data do documento original, neste caso, 2013-06-26.

1ª questão: SAFT

Este documento também tem de ser comunicado, logicamente.

No entanto, por esta altura, dia 2013-07-02, o SAFT de Junho já foi.

Devo:

a) Gerar um SAFT apenas com o documento inserido? Se sim, é barraca na certa, pois não há uma forma segura de controlar quais documentos já foram enviados por SAFT. Tudo o que podemos fazer é controlar quais já foram exportados, mas isso não garante nada a nível do envio.

b) Gerar novamente o SAFT de todo o período. Em teoria, a AT ao ler o SAFT com documentos duplicados, irá ignorá-los, e integrar apenas os que são novos. Aqui ainda me parece a melhor hipótese, apesar de tudo.

2ª questão: Pesquisa

Como a minha pesquisa é feita pela data de documento, o que me parece que faz sentido, o documento que eu inseri ontem, dia 2013-07-02, se o quiser procurar, não posso procurar pela data de ontem, mas pela data do documento manual 2013-06-26.

Possivelmente até faz mais sentido, vou procurar pela data em que o documento foi efectivamente feito, e não de quando ele foi inserido no sistema.

Mas neste caso, a data em que o documento foi integrado "perde-se", caso a data de caixa* (que é a origem da data de documento) não seja igual à data de sistema.

Aqui, imagino que a maior parte do software de facturação não use este conceito. Mas É muito útil para POS's, porque muitas vezes está-se a facturar depois da meia noite, mas ainda pertence ao "dia fiscal" anterior. Num exemplo rápido, estou a trabalhar numa terça feira, dia 17.07.2013. Entretanto passa a meia noite, e já é dia 18.07.2013, mas o dia de trabalho continua a ser 17.07.2013.

Ou seja, quem usar este conceito, previsto que está na lei, vai deixar de poder pesquisar pela data de caixa em que integrou o documento.

Grave ou não? Não sei! Queria opiniões... :P

3ª questão: Novo documento

Outro problema é quando estamos a dar entrada no sistema do documento manual. Quando é só um, não é grave.

Mas imagine-se que tenho dois livros de facturas manuais, com dois vendedores.

Chega um, e eu dou entrada de facturas entre dia 2013-06-26 e 2013-06-30.

Entretanto, chega outro vendedor, com outro livro. Vou dar entrada de facturas entre dia 2013-06-20[/b] e 2013-06-28.

Segundo o oficio circulado, podemos usar uma única serie de facturas manuais no sistema para integrar várias series dos livros. Mas a partir do momento que já meti uma data de documento de dia 2013-06-30, se for inserir outra, de outro livro, com a data de 2013-06-20 vou ter problemas, e entra em conflito com outra das directrizes da certificação, que não aceita datas anteriores à do último.

Ou estou a ver mal a coisa?


"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
americob

A minha questão é outra.

Imaginemos o seguinte cenário:

Começaste Julho, e como "bom português", mas para fugir à regra, enviaste o SAFT de Junho logo no dia 2013-07-01.

Entretanto, no dia 2013-07-02, pelas 16:30, lembras-te que no dia 2013-06-26 tiveste de passar uma factura no livro, porque tinha faltado a luz - chamemos-lhe a factura A/201.

Em serie própria, dás entrada da dita factura, guardando da original os campos serie, numero, e claro, indicando a data da factura manual.

Geraste assim uma FTM 2013/3, que é uma cópia do documento original [/b]A/201[/b].

O SystemEntryDate será sempre o de inserção do documento no sistema, neste caso algo como 2013-07-02T16:30:00.

A Data do Documento (O campo <InvoiceDate> no SAFT) será, segundo o oficio circulado, a data do documento original, neste caso, 2013-06-26.

1ª questão: SAFT

Este documento também tem de ser comunicado, logicamente.

No entanto, por esta altura, dia 2013-07-02, o SAFT de Junho já foi.

Devo:

a) Gerar um SAFT apenas com o documento inserido? Se sim, é barraca na certa, pois não há uma forma segura de controlar quais documentos já foram enviados por SAFT. Tudo o que podemos fazer é controlar quais já foram exportados, mas isso não garante nada a nível do envio.

b) Gerar novamente o SAFT de todo o período. Em teoria, a AT ao ler o SAFT com documentos duplicados, irá ignorá-los, e integrar apenas os que são novos. Aqui ainda me parece a melhor hipótese, apesar de tudo.

2ª questão: Pesquisa

Como a minha pesquisa é feita pela data de documento, o que me parece que faz sentido, o documento que eu inseri ontem, dia 2013-07-02, se o quiser procurar, não posso procurar pela data de ontem, mas pela data do documento manual 2013-06-26.

Possivelmente até faz mais sentido, vou procurar pela data em que o documento foi efectivamente feito, e não de quando ele foi inserido no sistema.

Mas neste caso, a data em que o documento foi integrado "perde-se", caso a data de caixa* (que é a origem da data de documento) não seja igual à data de sistema.

Aqui, imagino que a maior parte do software de facturação não use este conceito. Mas É muito útil para POS's, porque muitas vezes está-se a facturar depois da meia noite, mas ainda pertence ao "dia fiscal" anterior. Num exemplo rápido, estou a trabalhar numa terça feira, dia 17.07.2013. Entretanto passa a meia noite, e já é dia 18.07.2013, mas o dia de trabalho continua a ser 17.07.2013.

Ou seja, quem usar este conceito, previsto que está na lei, vai deixar de poder pesquisar pela data de caixa em que integrou o documento.

Grave ou não? Não sei! Queria opiniões... :P

3ª questão: Novo documento

Outro problema é quando estamos a dar entrada no sistema do documento manual. Quando é só um, não é grave.

Mas imagine-se que tenho dois livros de facturas manuais, com dois vendedores.

Chega um, e eu dou entrada de facturas entre dia 2013-06-26 e 2013-06-30.

Entretanto, chega outro vendedor, com outro livro. Vou dar entrada de facturas entre dia 2013-06-20[/b] e 2013-06-28.

Segundo o oficio circulado, podemos usar uma única serie de facturas manuais no sistema para integrar várias series dos livros. Mas a partir do momento que já meti uma data de documento de dia 2013-06-30, se for inserir outra, de outro livro, com a data de 2013-06-20 vou ter problemas, e entra em conflito com outra das directrizes da certificação, que não aceita datas anteriores à do último.

Ou estou a ver mal a coisa?

1ª Questão:

Na minha opinião deves gerar um novo SAF-T com o dia/dias em que acrescentaste documentos e logicamente os que já lá estão não serão recolhidos novamente pois aparecerão como duplicados.

2ª Questão:

Só te interessa a data do documento original e para o e-fatura também. O SystemEntryDate só tem interesse no caso de uma inspeção para verem se a assinatura está válida e ainda para ver se andas a fazer faturas com as datas que te dão jeito.

3ª Questão:

Parece-me que estás a ver mal a coisa ;)

O ponto 2.4.3 diz no final "Podem ser criadas tantas séries, quantas as existente nos documentos manuais ou apenas uma única série."

Ou seja, podes dar uma livro a cada vendedor mas cada um com a sua série.

Não te ponhas a dar "do 1 ao 50" a um "do 51 ao 100" a outro ...

Share this post


Link to post
Share on other sites
nunopicado

3ª Questão:

Parece-me que estás a ver mal a coisa ;)

O ponto 2.4.3 diz no final "Podem ser criadas tantas séries, quantas as existente nos documentos manuais ou apenas uma única série."

Ou seja, podes dar uma livro a cada vendedor mas cada um com a sua série.

Não te ponhas a dar "do 1 ao 50" a um "do 51 ao 100" a outro ...

Não é isso... :)

Isso era impensável.

Mas podes, segundo esse ponto, ter dois livros, um o A/1 a A/50, e outro o B/1 a B/50, um para cada vendedor.

Ao integrares, podes fazer ambos numa única serie no sistema - Não és obrigado a fazer uma serie para cada livro, ainda que o pudesses fazer.

Mas sendo a mesma, as datas vão sobrepor-se...


"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
americob

Não é isso... :)

Isso era impensável.

Mas podes, segundo esse ponto, ter dois livros, um o A/1 a A/50, e outro o B/1 a B/50, um para cada vendedor.

Ao integrares, podes fazer ambos numa única serie no sistema - Não és obrigado a fazer uma serie para cada livro, ainda que o pudesses fazer.

Mas sendo a mesma, as datas vão sobrepor-se...

Pois, se usares a mesma série para recolheres as duas séries manuais, ou recolhes todos os dias ou vai dar barraca com o Ponto 1.6:

"Todos os documentos deverão ser emitidos cronologicamente ..."

Share this post


Link to post
Share on other sites
pmiguelmartins

Acho que o q interessa é a numeração ser sequencial (neste caso da série para os documentos manuais) podendo as datas não estarem sequenciais ....

Pelo menos é o entendimento que faço ...

Share this post


Link to post
Share on other sites
nunopicado

Acho que o q interessa é a numeração ser sequencial (neste caso da série para os documentos manuais) podendo as datas não estarem sequenciais ....

Pelo menos é o entendimento que faço ...

Mas um dos pontos do oficio circulado fala precisamente da obrigatoriedade da sequencia da data...


"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
americob

Aqui, imagino que a maior parte do software de facturação não use este conceito. Mas É muito útil para POS's, porque muitas vezes está-se a facturar depois da meia noite, mas ainda pertence ao "dia fiscal" anterior. Num exemplo rápido, estou a trabalhar numa terça feira, dia 17.07.2013. Entretanto passa a meia noite, e já é dia 18.07.2013, mas o dia de trabalho continua a ser 17.07.2013.

O que tenho ouvido dizer é que a prática nestes casos é atrasar o relógio dos POS's umas horas de forma a não passar a meia-noite durante o período de trabalho.

Logicamente, neste caso não pode comunicar as faturas por Webservices.

Share this post


Link to post
Share on other sites
pmiguelmartins

Mas o ponto que indica essa ordem cronológica é antes de se falar nos documentos manuais ou provenientes de outra solução.

Continuo a achar o mesmo ... Mas com estes tipos nunca se sabe

Share this post


Link to post
Share on other sites
americob

Mas um dos pontos do oficio circulado fala precisamente da obrigatoriedade da sequencia da data...

Por outro lado, o Ponto 1.6 diz "emitidos cronologicamente".

De facto, se estas a "recolher", não estás a "emitir"! será?

E se estiveres a recolher um mês e quando estás a acabar no dia 29 verificas que há um documento do dia 2 que está mal recolhido, terás de anular tudo para recomeçar a recolher desde o dia 2?

Pelo menos e por enquanto, eu só controlo a ordem cronológica dos documentos vivos, os anulados são ignorados, senão a cada engano teriam de recomeçar numa nova série.

Share this post


Link to post
Share on other sites
nunopicado

O que tenho ouvido dizer é que a prática nestes casos é atrasar o relógio dos POS's umas horas de forma a não passar a meia-noite durante o período de trabalho.

Logicamente, neste caso não pode comunicar as faturas por Webservices.

Lá está, esta solução pode ser considerada fraude, além de que não estou a ver os clientes a fazerem isso.

Agora imagina:

Chegou às 23:30 e ele lembrou-se, "deixa cá por umas horas antes" e mete para as 18:00.

A simples pratica disto é absurda, mas vamos imaginar que sim.

O que acontece de seguida ao SystemEntryDate?

Segundo o oficio circulado:

3.4.3. Caso a data e hora de sistema seja inferior à do último documento emitido (por vezes

por questões de manutenção ou quando existe mudanças de mês ou ano estes lapsos

sucedem), deve ser pedida a confirmação, antes da emissão, de que a data e hora de

sistema se encontra correcta. Esta validação deve ser feita utilizando a data/hora do

SystemEntryDate de qualquer tipo de documento emitido, independentemente da sua

série.

Se o SystemEntryDate for inferior ao de qualquer outro documento já emitido (independentemente do tipo), o utilizador deve ser alertado.

Iamos ter então:

FT 2013/000507 --> 2013-07-17T23:27:00

FT 2013/000508 --> 2013-07-17T23:30:00

FT 2013/000509 --> 2013-07-17T18:01:00


"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
americob

Lá está, esta solução pode ser considerada fraude, além de que não estou a ver os clientes a fazerem isso.

Agora imagina:

Chegou às 23:30 e ele lembrou-se, "deixa cá por umas horas antes" e mete para as 18:00.

A simples pratica disto é absurda, mas vamos imaginar que sim.

O que acontece de seguida ao SystemEntryDate?

Segundo o oficio circulado:

Se o SystemEntryDate for inferior ao de qualquer outro documento já emitido (independentemente do tipo), o utilizador deve ser alertado.

Iamos ter então:

FT 2013/000507 --> 2013-07-17T23:27:00

FT 2013/000508 --> 2013-07-17T23:30:00

FT 2013/000509 --> 2013-07-17T18:01:00

100% legal também não me parece ser.

Mas também não me parece ser difícil de explicar a um qualquer inspetor que levante a questão e como disseram nas reuniões que assisti na AT, depende sempre da apreciação do inspetor.

Eu não tenho software instalado em discotecas, mas por exemplo, estas só abrem por volta das 22h e encerram por volta das 07h do dia seguinte. É natural que queiram, por questões estatísticas que toda a noite pertença a um único dia de faturação. Das duas uma, ou faturam tudo com data da abertura ou com data do encerramento.

A forma de o fazer, já falei caso que ouvi dizer de manipular o relógio, mas admito que quem faça software específico para estes casos permita configurar no software a forma de o fazer sem essa manipulação.

Logicamente, num POS que esteve a faturar o dia todo, não podes manipular o relógio por isso mesmo que referiste.

Share this post


Link to post
Share on other sites
nunopicado

Exacto.

E foi um bocado nessa onde do POS, embora o meu não passe realmente por esse problema, visto a loja fechar às ~21h, achei por bem manter esse esquema.

Ele tem uma data de caixa, que geralmente é a de abertura, e factura tudo nessa data, embora o SystemEntryDate se baseie na hora de sistema, e como tal reproduz a data e hora correctas.

E agora, esta data é ou não importante manter para os documentos integrados?

Eu, pelo sim pelo não, estou a guarda-la.

Como tinha isto já com 3 campos de dada (DataDoc, SystemEntryDate, e ManDocData), estou só a alterar para que, sempre que o SourceBilling não for P, a DataDoc não guarda a data de caixa, mas sim a data inserida pelo utilizador, enquanto a data de caixa é guardada no ManDocData, só pelo sim pelo não... Se algum dia for precisa, está lá.


"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
nunopicado

Próxima etapa no esmiuçar do oficio circulado:

3.3.2. O processamento de qualquer cálculo sobre documentos recolhidos ou resultantes de

integração de outros sistemas. Assim, se porventura, existir uma incorrecta determinação de

imposto, esse erro deve ser evidenciado na base de dados integradora, por resultar de um

documento já entregue.

O que vos parece isto?

Como estão/vão implementar?


"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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • 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.