Verilerin Yeni Yıla Devri ve Donemsel Calısma Arastıması?

[hedefbusiness]

Firebird Veritabanlı bir proje üzerinde calısıyoruz.

Yıl sonu yeni bir firma dönemi yaratarak Cari Kartlar ve Stok Kartları ile Ceksenet Kartlarını aynen devretmek bakiye hallerini son sekliyle yeni döneme aktarmak icin ne yapmalıyız?

1-Yeni Dönem açmak için sıfır halli veritabanını yeni bir dönem dizini acıp içine kopyalayıp
2-Cari Kartların,stokların,cek senet kartlarının sadece istenen bilgilerini yeni döneme komutla oluşturtmalımıyız?
3-Program açılışında firma seçimi ile nasıl bir yol izlemeliyiz?
Herkese ii calısmalar!!

[gyildizak]

merhaba,
anladığım kadarıyla yapmanız gereken tüm ERP programlarının ortak özelliklerinden birisi, şimdi yeni dönem kapanışı yaparken tüm borç ve alacaklar stok kartları hesaplanır örneğin bir 100 hesabınız olsun bu borçları 110 hesabı olsun alacakları göstersin, yıl sonunda yada dönem sonunda bu hesaplar hesaplanır yeni dönem açılışı yapılır sonra açılış fişi yaratılır yani yıl sonundaki 100 hesap ile 110 hesap eşleştirilir aradaki fark bir sonraki dönemin alacağına yada borcuna açılış fişiyle ekleyerek bir yol izlerseniz sanırım bir problem olmaz diye düşünüyorum.
iyi çalışmalar.

[gyildizak]

selamlar,
yazdıklarımı okuyunca aklıma geldi cariler yeni döneme aynen aktarmak bence pekde mantıklı bir olay değil eğer gerçekleşen tüm hareketleri bir transection tablosunda tutuyorsan bu tabloyu taşımak daha mantıklı tabiki ilk cevabımda anlatmaya çalıştığım yolu izleyerek.

tekrar iyi çalışmalar.

[metinkorkmaz]

Benim kullandıgım yöntem:

Bir devir penceresi tanımlıyorum.
O pencerede devri yapılacak şirketi seçtiriyorum, (mesela: sirket04.gdb) açılacak yeni yılın ismi (mesela: sirket05.gdb bu veritabanı yaratılacak), o yıla ait bazı temel bilgiler (mesela: devir tarihi 01.01.2005), devir işlemi için gerekebilecek bazı seçenekler.

Sırayla şunları yapıyorum:

1) sirket04.gdb nin ibx bileşenleriyle (ibbackup) yedegini alıyorum.
2) Alınan yedegi ibx bilesenleriyle (ibrestore) sirket05.gdb olarak açıyorum.

Buraya kadar olan işlem basitçe sirket04 -> sirke05 olarak kopyalanması.

3 ) Bundan sonra cari ve stok hareketlerini hesaplayıp, cari ve stok kartlarındaki devir kısımlarına yazıyorum. Cari ve stok hareketleri bilgilerini sıfırlıyorum.

4) Yeni yıla ilişkin ek düzenlemeler gerekiyorsa onları yapıyorum.

[Ali Erdoğan]

Veri dosyalarının isimleri listelenerek bunlar arasından seçim yapılması sağlanabilir.Ancak eğer program ağda ya da internet üzerinden çalışıyorsa nasıl bir sistem yürütmeli onu bilmiyorum.Nasıl bir yol izlenebilir.Çünkü client makinada dosyaları listeletmek sorun olabilir.

[rsimsek]

1. ve 2. yi sorduğun şekilde yapmalısın.

3. Veritabanının başında veya sonunda bir yıl bilgisi ekliyerek Data_2005.fdb veya Data_2006.fdb şeklinde bunu yapmak zor olmasa gerek. Bu bilgiyi programın kullanıcı / şifre ekranından alacağın cari yıl bilgisi ile oluşturabilirsin. Böylece hangi yıl girilmişse o .fdb açılır. Burada uyeni bir dönem veritabanı oluşturuluyorsa önceki veritabanının DDL ini kullanarak ikinci bir veritabanı oluşturup gerekli tablo bilgileri aktarılabilir.. Burada varsa trigger ları disable (kapalı) hale getirmek gerekiyor.. Her dönem/yılın bilgisi ayrı ayrı dosyalarda risk az..

Yada veri tabanındaki her tablonun sonuna yıl bilgisi eklenerek aynı veritabanı üzerinde de bu işlemler yapılabilir. Bir önceki yılın bilgileri çok sık kullanılmayacaksa bu seçenek pek kullanışlı olmaz.. Her seferinde veritabanı gittikçe şişer, ayrıca tüm bilgiler risk altında

[Kuri_YJ]

Selamlar,

Kendi fikrimi beyan etmek isterim.

RDBMS'ler ve bu kadar teknolojik gelişme bu tür (yani devirdi ıvırdı zıvırdı) bölük pörçük data partiküllerini bir arada tutabilmek ve geçmişe dönük veri analizlerini zorlanmadan yapmak için geliştiriliyor.

Ben programlarımda devir denen naneyi hiç koymam !... Yıl ayrımı vardır o kadar.

Indexlerle ilgili bir yanıtımda da bunu net bir şekilde anlatmıştım

Veritabanında table'larını ve indexlerini uygun bir biçimde yapmışsan ve sorgularını raporlarını daima bunun üzerine ayarladıysan, devirmiş vs'miş hiç bir şey yapmana gerek kalmaz.

Hız konusunda eğer indexlerini doğru ayarladıysan hiç endişen veya benzeri bir çekincen olmasın !...

Data dosyası elbette büyüyecektir, bunu da uygun backup yöntemleri ile backuplayarak sorunsuz çalıştırabilirsin.

Hem düşünsene, çekler senetler her sene aktarılacak hele bir de müşteri hesap kapatmaların varsa (ödeme-fatura eşlemeleri) yandın ki ne yanmak !... Bunların doğru tarihlerini vadelerini elde edebilmek çok zor olur bazen imkansız bile oluyor.

Bu sebeple, ben derim ki, devir yapma !... (Cari Çek Senet Fatura vs. için) Muhasebe için mecbur çalışma yılı sonunda hesap kapatmaları yapıp ertesi sene için açılış fiş kayıtları oluşturmak zorundasın. Bundan dolayı kaçarın yok ama diğerlerinde sakın uğraşma. Yapılarını indexlerin ve sorgulamalarını buna göre düzenle.

Faydalarından biri de geriye dönük raporlama ve analiz, araştırmalarda istediğin gibi rapor kriterleri verebilirsin. Öteki türlü, geçmişe dönük bir şey istediklerin, dur bi sn diğer db'ye bağlanıp bakalım gibi ıvır zıvır bir sürü şeyle uğraşırsın.

Tercih senin, ben sadece kapıyı gösteririm. (Mavi kapsül mü kırmızı kapsül mü? Morpheus gibi oldu ehehehehee


Kolay Gelsin

[Kuri_YJ]

Haaa dikkat Yıl ayrımı table adında değil sadece tablonun içinde bir fielddır. CalismaYili gibi integer bir field.

Örneğin Şirket ve yil ayrımı olan bir cari program düşünün.

CalismaYili Integer
Sirket Integer

diye iki alanı hareket tablolarına eklerim. Parametreler hemen hemen hepsi için aynı ise onlarda böyle bir ayrım yapmam.

Avantajlarından biri de, bilgileri konsolide ederken kolay olur yani. Bir holdingin birkaç firması olsun, bu firmalardaki nakit akışlarını kosolide etmek istersen yapman gereken tek şey var o da query'deki Sirket fieldını Where satırından kaldırmak olur

Kolay Gelsin

[Salih]

Merhaba,
Hazır yılsonu gelmişken bu başlığı canlandırayım dedim. Yılsonu devirleri için nasıl bir yol izlediğinizi öğrenmek isterim...

[Terminator]

Kuri güzel açıklamış, çok detaya girmiycem.
ciddi veritabanlarında bir bütünlük vardır, en ideali tek olmasıdır.
bölük pörçük dosya tabanlı veri sistemleri kişisel sistemlerin bir alışkanlıgıdır. genelde de btrieve, isam gibi record managerlardangelenler tercih eder.
Benim DB tektir, bir adı vardır ve kullanıcı ya da programcı bunu bilmek zorunda bile değildir. sadece aliası kullanır. herşey tek dosyadadır.
YILI diye bir smallint saham vardır ve birçok indexin ilk parçasıdır.
risk, bölük pörçük sistemlerde daha fazladır.
bir veritabanı yöneticisi milyarlarca kaydı yönetmek için vardır. birkaç milyon kayıt gözünüzü korkutuyorsa, ciddi bir DB projeniz olmamış demektir.
Muhasebe vs sistemlerinin yasal tutulma süresini tam bilmiyorum şu an, 5 yıl olabilir. eğer 5 yıldan eski bilgiler projenizi ve kullanıcılarınızı hiç ilgilendirmiyorsa, topluca devirden sonra silebilirsiniz aynı transaction içinde. yok belki lazım olur deyip biyere atmak isterseniz de, genel amaçlı 2. bir db yaratıp ARSIV.FDB gibi.. silinecekleri oraya pump eder silersiniz.
offline bir FDB olacağı için bi zararı olmaz. birisi, 10 sene önceki data diye tutturusa gıcıklıgına, ona özel bir alias ile uygulamaya açabilirsiniz.

[kadirkurtoglu]

s.a.

Belgelerin TTK'a göre 10 yıl VUK'a göre de 5 yıl saklanma zorunluluğu vardır. ancak burda programdaki kaydın saklanmasına Kanuni açıdan bir zaruret yoktur. çünkü ilgili kayıtlar Noterden Onaylı Defterlkere Yazdırılır.

[Terminator]

s.a.

Belgelerin TTK'a göre 10 yıl VUK'a göre de 5 yıl saklanma zorunluluğu vardır. ancak burda programdaki kaydın saklanmasına Kanuni açıdan bir zaruret yoktur. çünkü ilgili kayıtlar Noterden Onaylı Defterlkere Yazdırılır.

Selam,
bilgisayar kullanmada da kanuni bir zorunluluk yok. kanuni evrakları
daha hızlı düzenleyebilmek, takip etmek, bulmak, işleri kolaylaştırmak ve hızlandırmak, vs. için kullanıyoruz.
saklamanın 10 yıl mecburi olduğu bir evrağı insanların yine bilgisayardan
takip etmesi gereklidir. Kanuni süreler aşılsa bile, ciddi firmalar bu bilgileri arşiv ve istatistiksel amaçlı olarak da tutmak isteyeceklerdir.
Hiç kimse binlerce fiziksel evrak ve dosya arasında öncelikle elle arama yaparak zaman ve işgücü kaybetmek istemez bilgisayar kültürüne sahipken.

[kadirkurtoglu]

ben bilgisayar kayıtlarının zaruri yada değil kanuni yada keyfi olmasından bahsetmemiştim. Muhasebe ile iştigal olduğum için konuyla ilgili bilgi vermek istedim. Bu işin 2 farklı şekli vardır.

1- İşyeri Muhasebesi (Özel) : Stok, Cari, Fatura, Çek, Senet, Banka, Kasa gibi modüllerin olduğu işyerinin bu modüller sayesinde iş hayatını kayıt altına alması

2- Genel Muhasebe (Zorunlu) : Bu Muhasebede Mükellefin Kanunen Tutması Gereken Defterler Tutulur. ve vermesi gerken Beyannameler ilgili kayıtlardan rapor şekilde türetilir.

şimdi İşyeri açısından Fatura ve Benzeri Değerli Evraklar, Muhasebe açısından da Yasal Defterler Türk Ticaret Kanuna Göre 10 Yıl Vergi Usul Kanuna göre 5 yıl saklanmak zorundadır.

yukarıda bahsettiğim işlerin Bilgisayar da veya el ile kağıt ortamında yapılması kişilerin keyfiyetine bağlıdır. Bilgisayarda veya El ile tutulan kayıtların saklanma zorunluluğu yoktur. sadece kayda esas evrakların saklanması esas tır. Anlatmak istediğim buydu...

[Terminator]

ben bilgisayar kayıtlarının zaruri yada değil kanuni yada keyfi olmasından bahsetmemiştim. Muhasebe ile iştigal olduğum için konuyla ilgili bilgi vermek istedim. Bu işin 2 farklı şekli vardır.

1- İşyeri Muhasebesi (Özel) : Stok, Cari, Fatura, Çek, Senet, Banka, Kasa gibi modüllerin olduğu işyerinin bu modüller sayesinde iş hayatını kayıt altına alması

2- Genel Muhasebe (Zorunlu) : Bu Muhasebede Mükellefin Kanunen Tutması Gereken Defterler Tutulur. ve vermesi gerken Beyannameler ilgili kayıtlardan rapor şekilde türetilir.

şimdi İşyeri açısından Fatura ve Benzeri Değerli Evraklar, Muhasebe açısından da Yasal Defterler Türk Ticaret Kanuna Göre 10 Yıl Vergi Usul Kanuna göre 5 yıl saklanmak zorundadır.

yukarıda bahsettiğim işlerin Bilgisayar da veya el ile kağıt ortamında yapılması kişilerin keyfiyetine bağlıdır. Bilgisayarda veya El ile tutulan kayıtların saklanma zorunluluğu yoktur. sadece kayda esas evrakların saklanması esas tır. Anlatmak istediğim buydu...

Farklı bişey söylemediği halde tartışma çıkarabilen bir milletiz vesselam.
Benim orda anlatmak istediğim şey, bilgisayarların bir araç olduğu, amaç olmadığı idi. Amaç bilginin kendisi ve resmiyetidir. Bilgisayar sadece
bu amaca hizmet eden araçtır. konun açılma nedeni kanunları tartışmak da değildi zaten. Ciddi, stratejik çalışan firmalara geçmişe ait bilgiler çok lazımdır. Bugünün bilgileriyle, kanuni çerçevede günü kurtar seneyi kapat olayı bizim gibi altyapısını oturtamamış ülkelerde yaygındır.
Neticede, ben bilgilerin, işlemlerin silinmesine karşıyım evrensel değer yargılarıyla bakınca. Firebird açısından da bunun bir mahsuru yok.
Firebird bırakın bir şirketin muhasebesini bütün şirketleri tutabilecek kadar da güçlü bir sistem. Kötü, baştan savma tasarım ve kullanım tarzlarını kayıtları silerek tolere etmek de benim yapıma ters.
Bunu açıklamak istedim. isteyen istediği gibi yapar, her koyun kendi bacağından asılır.

[rsimsek]

Kanuni zorunluluk olmasa da birisi 9 sene sonra kapınıza mahkeme kararıyla falanca bilgilerin dökümünü isteyince arşivdeki küflenmiş evraklarınızı karıştırmaya başlamadan önce bilgisayardan geçmişe dönüp öyle bir bilginin olup olmadığına bakabilir, hatta istenen dökümü verebilirsiniz