From: Yüksel ÖZCAN (yukselozcan@celiknet.com)
Date: Mon 01 Mar 2004 - 09:38:16 EST
> Selamlar..
Selam ustat,
Aslinda ben anlatmak istedigimi tam olarak anlatamadim. Biraz farkli yoldan
anlatayim;
Benim ayni tabloda cari_id, cari_kodu ve cari_adi diye 3 ayri field'im var.
Burada konu ile ilgili bizim icin onem tasiyan cari_kodu alanidir. bu alan
varchar(255) olarak tanimli. butun tasarim olayi budur. Fuat bey'in
kullanmak istedigi yontemi kullanici kendisi bu alani akillica kullanarak
cozmelidir. ornegin kullanici bu alani icin
001 - x firmasi
002 - y firmasi
003 - a firmasi
......
seklinde tanimlayarak ta kullanabilir,
120 <-- musteri hesaplari (bu hesap karti degildir, kodlamanin nasil
yapildigi ile ilgili aciklamadir)
120.34 <--- istanbul musterileri ()
120.34.001 <--- istanbul 1. bolge (anadolu yakasi) musterileri
120.34.002 <--- istanbul 2. bolge (B.Cekmece- catalca hadimkoy) musterileri
120.59.000.<---- Tekirdag tum musterileri
Seklinde de kullanabilir. Nasil isterse oyle kullansin. Fakat fuat bey'in
istedigi sey firmaya ozeldir. Eger global olarak herkesi hedef alirsak.
benim onerdigim kullanicinin kendi belirleyecegi kodlama standardi daha
uygun olur. Ki sorgulama yaparken
120.34% dediginde ile basliyan tum istanbul musterilerini secmis olur.
120.??.???.YO
---- -- --- ---
| | | |---- pazarlamaci kodu
| | |---------basit siralama (001, 002, 003)
| |------------ il kodu
|--------------- -Hesap tipi (120= musteri, 320 = satici )
120.??.???.YO dediginde de yuksel ozcan musterilerine ait dokumleri
rahatlikla alabilir. Siz nasil yaparsaniz yapin, onemli olan kullanicinin
kendine gore bir kodlama mantigi kurmasidir. Ve bu mantigi da programa
programci eklememeli. Zaten sozkonusu muhasebeciler olunca, her muhasebeci
kendine gore birtakim kodlama standardi gelistirip bunu uygulamaktadir.
Programcilarin da cari_kodu icin varchar(50) gibi bir tanimlama yapmasi
normal sartlarda yeterli olur. Fakat global degilde, isyerine, tek bir yere
ozel bir yazilim gelistiriliyorsa isteyen istedigi gibi hareket edebilir.
Ben sadece bu bahsettigim yontemle bir muhasebecinin istedigi raporlari
rahatlikla alabilip onemli detaylari stok_kodu ve cari_kodu alanlarini bu
sekilde kullanarak yapabilindigini soyluyorum. Zaten piyasadaki mevcut
muhasebe programlari da yazilimlarini bahsettigim sekilde sizlere sunarlar.
Sizin mevcut olanlardan daha iyisini yapmak adina yapacaginiz seyler en
fazla ozel_kod1, ozel_kod2, ozel_kod3 gibi cari_kartlar tablosuna ek alanlar
eklemek. Bu alanlarin da isimleri icrali, blokeli gibi degil, ozel_kod1,
ozel_kod2 gibi kullanicinin kendisinin tanimlayip ta tutabilecegi alanlar
olmalidir. Bu da sizin ayri field olayiniza geliyor. :-) fakat ek field ta
ekleseniz benim ornedigimle birlikte ek fieldlari da birlestirince iste o
zaman bu is kokunden cozulmus olabilir. Birde benim onerdigim sadece il
bazinda ayirimlardan ibarettir. Siz bunu belli urunu alan musterilere gore
yapabilirsiniz, buyuk firma - kucuk firmaya gore yapabilirsiniz. Kriterler
farkli olabilir. Farkli olan kritere gore de siz 3 - 5 tane field koyun,
gerisini kullanici bu ek fieldler ile, ve hesap_kodu alanlari ile birlikte
tek basina halledebilir.
Yuksel OZCAN
http://muhasebeci.sf.net
> Bu muhasebe kayit kuregi tutarken son derece faydali bir yaklasimdir
> ama, porgramlama icin ayni seyi soylemekte biraz tereddutluyum.
>
> Soyleki, bu noktada ileriye dogru kodlama mantalitesinin getirdigi bazi
> limitler sizi zorlayabilir. Yani uzun donemde kodlanmis bilgiler icine
> yeni bilgiler eklemek/degistirmek isterseniz sorunlar yasayabilirsiniz.
>
> Bu yuzden bu tur olaylari ayri ayri field'ler uzerinde tutmak daha
> mantikli olacaktir. Ornegin, asagidaki sistemde, uygulama yarin
> yurtdisina satis yapacak olursa isler nasil karisir ?
>
> Bir diger sorunda genellikle bu tur belirlenen hesap numarasinin aslinda
> belirleyici kayit alani olmasi durumudur. Yani hesap numarasi ayni
> zamanda veri tabaninda kayidi gosteren bir deger ise uzun vadede sizi
> zorlayabilir. Basitce, ogrencinin okul numarasini, kayit numarasi
> yapmayin. Kayit numarasi sadece uygulama tarafindan o kaydi kullanmak
> uzere mevcut olsun. Ayni sekilde, hesap kodu/nosu degeri de kaydin
> kendisi veya icerigini niteleyici bilgileri tasimasin. Bu KISS kaidesine
> uygun olur oncelikle. Bir koda bir suru bilgi yuklememis olursunuz.
>
> Burada sizin, fatura bilgilerini dogrudan sorgulayarak, hangi sehirdeki
> ilcedeki vs. musterilerin ne kadar bakiye verdigini gormeniz mumkundur.
> Bu durumda tek duzen hesap plani icindeki bu bilgi gereksiz bilgi
> tekrarindan ibaret olur. Eger olaya bu yonden yaklasirsaniz, insanlarin
> adres degistirdiginde yasanacaklari onlemeniz kolaylasir. Kisaca, izmit
> musterilerinden birisi gebze'ye tasinirsa, onun eski satislari izmit
> bolgesi olarak kalmasi (sattiginiz arabalar izmit'tedir hala) gerekirken
> ondan alacaklarimiz Gebze bolgesine tasinmalidir. Bu noktada eger
> muhasebe hesap kodlari uzerinden calisiyorsaniz, programin alt hesaplar
> arasinda bilgileri aktarmak uzere daha karisik kodlamaya gerek duymasi
> sozkonusu olur. Demekki bunlari daha stupid hesaplar olarak dusunup akli
> bu isi yapan fatura vs. gibi yerlere tasimak daha kolay olacaktir.
>
> Pek dilim donmedi ama sanirim anlasiliyordur. Anlasilmiyorsa daha farkli
> yollardan da yazmayi deneyebilirim saniyorum, mutemadiyen ve de
> bilahare..
>
> Saygi ve sevgiler..
>
>
> > olacaktir. Biz isyerinde soyle yapiyoruz;
> > 120 <-- musteri hesaplari
> > 120.34 <--- istanbul musterileri
> > 120.34.001 <--- istanbul 1. bolge (anadolu yakasi) musterileri
> > 120.34.002 <--- istanbul 2. bolge (B.Cekmece- catalca hadimkoy)
musterileri
> > 120.59.000.<---- Tekirdag tum musterileri
> > Bu sekilde bir kodlama standardi cok kullanislidir. Uzerinde uzun sure
> > dusunmeniz gereken bir konu diye dusunuyorum.
>
>
>