Forum HAMOR Soft

Am scris un program pentru repornirea bazelor de date la sfârșitul anului.

Este scris in Visual FoxPro. În pachet, pe lângă repornire.exe există un ini file și 5 dll-uri. Nu trebuie instalat, se lansează direct executabilul. Rulează pe orice sistem Windows, de la Win95.
Parametrii transferului sunt descriși în repornire.ini:

• [date]
  ;baza veche
  vechi=d:\hamor\marf.12
  
  ;baza noua
  nou=d:\hamor\marf
  
  ;anul care a trecut
  an=2012
  
  ;numarul primei receptii pt. stoc
  primarec=0001
  
  ;numarul maxim de randuri pe o receptie de stoc
  maxranduri=100
  

Inaintea lansarii programului:
- se editează fișierul repornire.ini
- baza veche se verifică cu hMARFU, se corectează erorile de consistență
- documentele nevalidate nu se vor transfera din baza veche
- în baza veche se verifică sa nu fie documente validate pentru anul urmator

Transfer
- se transferă soldurile furnizorilor și clienților
- soldurile jurnalelor de încasari / plăți NU se transferă (de obicei sunt modificate ulterior)
- se marchează gestiunile pentru care se vrea transferul stocului (indiferent de grupa articolelor)
- după transfer se va lansa automat o reorganizare a bazei noi cu hUTIL
- după transfer recepțiile pentru stoc trebuie validate în hMARFA
- dacă stocul transferat nu este conform așteptărilor (sunt gestiuni lipsă sau în plus), programul se poate relansa de mai multe ori
- transferul durează câteva secunde, chiar și la baze mari
- dacă se pregătesc bazele de date, se editează fișierul ini, transferul poate fi executat chiar de client (după o explicație minimă)
- după transfer se generează un raport cu stocul și soldurile clienți / furnizori transferate (vezi exemplul din fișierul atașat)

Dacă există interes pentru acest program în rândul distribuitorilor, Vă rog să mă contactați.
Kiss Tibor

Înaintea "erei tvai" o repornire a bazei de date presupunea următorul algoritm (fără a intra în amănunte):
(culoarea verde se referă la baza nouă, culoarea galbenă la baza veche)

• Stoc:
  lotm.stoci = lotm.stoci - lotm.iesiri
  
  Sold clienti:
  fac.valinc = fac.valinc + fac.valrev - fac.valpla
  fac.dolinc = fac.dolinc - fac.dolpla
  fac.valrev = 0
  fac.valpla = 0
  fac.dolpla = 0
  fac.curs = fac.valinc / fac.dolinc
  
  Sold furnizori:
  tran.val = tran.val + tran.valrev - tran.pla
  tran.valdol = tran.valdol - tran.pladol
  tran.valrev = 0
  tran.pla = 0
  tran.pladol = 0
  
  Similar pentru vama și cheltuieli.
  
  Jurnalele de TVA s-au golit.

În "era tvai" lucrurile se complică. Intervin două (sau poate mai multe) câmpuri noi: fac.tvai, tran.tvap. Precum și statusul firmei (este sau nu TVAI), golirea sau nu ale jurnalelor TVA.
Vă cer ajutorul într-o mică analiză a situației.

Da, lucrurile s-au mai complicat ...

Câmpuri noi:
TRAN.DBF:
-TVANED -TVA nedeductibilă (deci cât nu este deductibilă din TVA de pe document, ex.la NIRI7 va fi deductibilă doar 50% din tva)
-TVAP -cât din TVA de pe document este exigibilă (la început 0, după ce recepţia este plătită integral=TVA-TVANED)
FACTURI.DBF
-TVAI -cât din TVA de pe document este exigibilă (la început 0, după ce factura este încasată integral=TVA)
-DSCADTVA-data scadenţă TVA, ultima zi, după care TVA devină exigibilă, chiar dacă factura nu este încasată
(prima zi de lucru după expirarea celor 90 de zile admise)
INCPLA.DBF
-TVAIP -TVA încasată/plătită -cât din TVA de pe document devine exigibilă după înregistrarea încasării/plăţii.


Exemple:
1.Recepţie în valoare de 124 RON, din care TVA 24 RON, TVA nedeductibilă=0
Se plătesc 62 RON --> TVAIP=12; TVAP=12
Se plătesc încă 62 RON --> TVAIP=12; TVAP=24

2.Recepţie în valoare de 124 RON, din care TVA 24 RON, TVA nedeductibilă=12 (ex.NIRI7)
Se plătesc 62 RON --> TVAIP=6; TVAP=6
Se plătesc încă 62 RON --> TVAIP=6; TVAP=12

Reguli:
-TVAP se calculează doar dacă "z" apare în Tip TVA (ex.2Iz), altfel=0
-Întotdeauna suma câmpurilor TVAIP de pe documentele de plată=TVAP de pe recepţie.
Aşa se verifică şi în hMARFU.
-TVA>=TVAP+TVANED chiar dacă recepţia în cauză au fost plătită în plus.

3.Factură în valoare de 124 RON cu TVA 24 RON --> TVA=24; TVAI=0
Se încasează 62 RON --> TVAIP=12; TVAI=12
Se încasează încă 62 RON --> TVAIP=12; TVAI=24
Deci TVA devine exigibilă integral, prin două încasări. Câmpul TVAIP din fiecare document de încasare va conţine 12 RON

Reguli:
-TVAI se calculează doar dacă "z" apare în Tip TVA (ex.1Iz), altfel=0
-Întotdeauna suma câmpurilor TVAIP de pe documentele de încasare=TVAI de pe factură.
Aşa se verifică şi în hMARFU.
-ICM>=TVAI chiar dacă factura în cauză au fost încasată în plus (câmpul ICM conţine TVA de pe document).
-Dacă încasarea are loc după data de scadenţă TVA (conţinut în câmpul DSCADTVA) TVAIP rămâne=0, TVA nu se modifică.

Deci după repornirea bazei de date aceste relaţii trebuie să se păstreze pentru facturile neîncasate, recepţiile neplătite.
Dacă a existat o încasare-plată parţială, acesta va trebui păstrată.

Facturile neîncasate nu vor putea fi cumulate la nivel de client.
Recepţiile neplătite nu vor putea fi cumulate la nivel de furnizor.

Bineînţeles, lucrurile se simplifică dacă proprietarul datelor nu aplică TVA la încasare.

Cam atât la nivel de "mică analiză" ...

O completare ...
Pentru facturile şi încasările corespunzătoare în hMARFT în arhiva jurnal vânzări există poziţii aferente.
La fel şi la recepţii.

Deci arhivele jurnalelor de vânzări/cumpărări nu vor putea fi golite pur şi simplu,
poziţiile corespunzătoare facturilor/recepţiilor neîncasate/neplătite vor trebui păstrate împreună cu poziţiile corespunzătoare încasărilor şi plăţilor aferente.

Deci aşa ar fi corect ...

Nu am încercat, dar cred că este OK, ca în facturile/recepţiile neîncasate/neplătite integral să se păstreze doar sumele neîncasate/neplătite şi bineânţeles şi TVA aferent . Pentru aceste facturi există deja înregistrări în arhivele jurnalelor de vânzări/cumpărări, în luna precedentă lunii din care se reporneşte baza de date (adică în Decemrbie dacă baza de date este repornită din Ianuarie) şi bineînţeles aceste înregistrări trebuie să fie păstrate.