Cari Kodu yada Ürün Kodu nasıl olmalı?

[naklov67]

Merhaba arkadaşlar.
Bir konu hakkında görüşlerinizi almak istiyorum. Bir konuda tam emin olamadım ve en iyi yöntem hangisi diye merak ediyorum.

Şöyle;
Bir ürün ve cari tablosu düşünelim ve bunlar ile ilgili hareketler yapılacak bir tablo. Böyle bir sistemi Ek tablolar ile de desteklediğimizi düşünelim. Sonrasında bu tablolar ile ilgili kayıtları wievler ile sonuçlar aldırmayı planlayalım.

Bu genelde tüm programcıların yaptığı işlerden biridir.
Ancak burada Tablolar birbirine bağlanırken ürün kodu yada cari kodu kısımları kullanılacak.

Sorum şu: Bu ürünlere yada carilere kod verirken kullanıcıyı serbest mi bırakmalıyız (yani kodu kendisi verebilmeli, değiştirebilmeli,program ile aynı kodu vermesi önlenmeli, tüm bağlantıları da bu kod ile yapmalı) ? Yoksa gene kodu verme yada değiştirme izni vererek gizli bir autoinc tanımlayıp bağlantıları bu koda göre mi yapmalıyız?

Bana göre mantıklı olan ve sağlam olan Kodu gizlemek (autoinc) ve ikinci bir kod verme şansı vermek.
Ama bu durumun sutun sayısını artıracağını ve db yi şişireceğini düşünüyorum. Tablo sayısı arttıkça da bu risk artacaktır.

birkaç büyük yazılımda bunu kullanıcıya bıraktığını gördüm. ama aynı kodu verme riskini tamamen ortadan kaldırmış. ama bu kodu değiştirirken büyük zorluk çekiyor çünkü daha önce yapılmış hareketleri de değiştirmek zorunda.

Bilemiyorum sizin düşünceniz nedir hangi yöntem daha mantıklıdır ??
Lütfen bu konudaki görüşlerinizi paylaşın!
Teşekkürler...

[serkan]

cari kodu ve ürün kodu serbest bırakılmalı istersen programının ayarlar bölümünden otomatik sıraylada getirebilirsin.Yok illada program vermeli dersen bence uluslararası muhasebe kodlarını kullan.

carilerde;

120 ile başlayanlar Müşteri
320 ile başlayanlar Tedarikçi(Satıcı)
102 ile başlayanlar bankalar
ve benzeri onlarca standart kod var.

Stoklarda;

150 ile başlayanlar Hammadde
151 ile başlayanlar Yarımamul
152 ile başlayanlar Mamul
600 ile başlayanlar ticari mal
ve benzeri...

Veri bütünlüğüne gelince,Cari kodu veya Stok Kodunu Kayıt düzeltme ekranında değiştiremessin.Yani Bir cariyi cağırıp telefon nosunu değiştirip yeniden kayıt edebilirsin ama cari kodunu değiştiremessin.Bunun için programına Servisler veya özel işlemler diye bir bölüm koyup kullanıcıya cari veya stok kodunu değiştirirsin.Tüm tablolardaki stok veya cari kodunu değiştirmek sql ile pek sorun değil.Ayrıca veritabanından ceri ve stok kodu nu unique alan tanımlarsan aynı kodu verme şansı ortadan kalkar.

Kolay gelsin.

[naklov67]

Merhaba.
Teşekkürler mesaj için,
Benim bahsettiğim yöntemlerden biri buydu.

Sormak istediğim sorulardan bir diğeri ise ikinci anlattığım yöntem olan kullanıcının görmediğii bir kod ile bu işi yapmak ne kadar mantıklı.
veri bütünlüğü bakımından oldukça güvenli bi yöntem. sizin bahsettiğiniz yöntem de mantıklı ama bahsettiğim yöntem daha esnek gibi duruyor ve kullanıcıya oldukça kolaylık sağlıyor diye düşünüyorum.

Programlama işi ile yaklaşık 3 yıldır uğraşıyorum. durmadan da gelişiyor ve devamlı öğreniyorum. ama bu konuda tam bir sonuca varmış değilim.

bu işi yıllardır yapan üstadlardan da bu konudaki görüşlerini almak istiyorum.

Saygılar.

[aslangeri]

s.a.
tabloları biribirleri ile ilişkilendirdiğinde bu alanı kullanıcılara gösterme.
müşteri kendi bileceği bir kod versin. ama sen arka da başka bir alandaki bu pkey alan üzerinden ilişkilendirmeleri yap.

şöyle
cari tablosu

• ID autoinc
  MUSTERIKODU karakter 10
  MUSTERIADI Karakter 30
  .....

stok tablosu

• ID autoinc
  STOKKODU karakter10
  STOKADI karakter30
  ....

hareketlerdede id alanlarını tutarsın.
kullanıcıya göstereceğin zaman stokkodu ve müşterikodu alanlarını gösteririsin.
aksi halde
müşteri stok kodunu değiştirdiği zaman o stoğun tüm hareketleri kaybolacaktır.aynı şekilde müşterinin hareketleride. (tecrübe ile sabittir)
kolay gelsin.

[naklov67]

Teşekkürler aslangeri yazın için
Aslında yazımda da belirtmek istediğim Serkan ve aslangeri nin bahsettiği yöntemlerden hangisi ??,

Serkan ve aslangeri nin belirttiği iki yöntemi de kullandım projelerimde. ama bunlar çok büyük projeler olmadığı için db ile ilgili sorun yaşamadım.
ama büyük projeler için bunların iyi hesaplanması gerektiği kanısındayım.

Serkan ve aslangeri nin alnattığı yöntemlerden hangisi daha sağlıkla ve daha sağlam olur???

benim kendi görüşüme göre, aslangeri nin anlattığı yöntemi uygulamak daha mantıklı. veri bütünlüğü açısından hatayı ortadan kaldırır ve viewlerin kusursuz ve daha hızlı çalışmasını sağlar diye düşünüyorum.
buradaki kuşkum bu yöntemin db de her tablo için bir sütun arttırması. bu durum pek önemli gibi görünmese de tablo sayısı arttıkça ciddiyeti de artıyor.
mssql, mysql yada firebird ile yazılacak bir program düşünelim. bu durumda aslangeri nin anlattığı yöntemin getirecekleri db deki bu şişkinliğe değer mi? yoksa Serkan ın anlattığı yöntemi kullanarak programcı oturup tüm hataları önceden tespit mi etmeli?

Görüşlerinizi merakla bekliyorum.

Saygılar.

[naklov67]

bu konuda görüş bildirmek isteyen yokmu ?
fahrettin abinin bu konudaki görüşlerini çok merak ediyorum.
bundan sonraki çalışmalarıma ışık tutacak bi konu.

lütfen biriki satır bişeyler yazın

[spiderman]

bende aslangeri'nin kullandıgı yontemi kullanıyorum. bunun cok avantajı var,

1) AutoInc kullanarak hem guvenli hemde master-detailde hızlı calısacak bir tablo yapısı olusturabiliyorsun.
2) Kod yapısı musteride zaman icinde degisiklik gosterebilir. ornegin musterimiz kod yapısını subesi.musteri sehri plakası.takip eden no (01.34.0823) seklinde kodlayabilir. fakat bir zaman sonra bu dizilime musteri bayi turunu eklemey kalktıgında ya harek goren kayıtlarda bunları degistirmen yada kodda degisiklige izin vermemen gerekecek. halbuki kullanacagin autoinc kod sana ait olacagindan daha sonra musterinin kodu degistirmesi sende hic bir probleme yol acmayacaktır.


mehmet

[naklov67]

Aslında ben de bu yöntemin daha iyi olacağını düşünüyorum ama serkan arkadaşımın dediği yöntemin + larını düşünüyorum.

değiştirme işlemini yapmak SQL ile basit olduğu düşünülürse her tablo için bir autoinç den kurtulmuş olacağız.

buna değip değmeyeceğini merak ediyorum aslında.

[kadirkurtoglu]

serkan hocamın bahsettiği yapı muhasebe entegrasyonu ile alakalı bir konu eğer projeniz muhasebe entegrasyonlu değilse düşünmenize gerek bir mesele yoktur. muhasebe entegrasyonu dedikleri olgu zor bir mekenizmadır aslında.müşteri veya firma cari koldarını muhasebe hesap planına göre verip, daha sonra muhasebeleştir mantığında gizlidir.

buna göre peşin müşteriler

100.001 gibi

açık hesap çalışan müşteriler

120.001 gibi

devam edip gidiyor.. geriye dönüp baktığımızda kullanıcı; müşterisi hem peşin hem de açık hesap çalışıyorsa hem 100 altına hemde 120 altına kaydetmesi gerekecektir. daha çoğaltabilirsiniz bir müşteri nakit, çek, senet, kredi kartı, banka havalesi gibi ödeme türlerinin tamamında olabilir..

[naklov67]

kadir kardeş.
dediğin doğru ancak benim bahsettiğim kodun şekli değil.
burada kodun gizli mi yoksa görünür mü olması.

serkanın dediği gibi tabloları bağlayacağımız kodları kullanıcı tarafından değiştirilebilir kılmak biraz uğraştırır ama sonuç olarak veri bütünlüğünü kaybetmemize neden olmaz. uğraştırır derken biraz basit kaldı sanırım. baya bi uğraştırır.

ama büyük bi proje için fazladan bir sütun bile önemlidir diye düşünüyorum. bu kadar uğraştırmasına değermi sizce ??

[kadirkurtoglu]

ben önceleri

MID İnteger PK
MusteriKodu Varchar 10

olarak tasarlıyordum. müşteriler müşteri kodu oto artsın biz uğraşmayalım dedi. bende MID değerini readonly yapıp gösterdim. hem o değerle sql kodlarını işletiyorum hemde aramalarda çok hızlı sonuç dönderiyor. zaten kimse kod üzerinden işlem yapmıyor. düşünün ki bir işletmenin 1500 müşteri kaydı var bu durumda pro yu kullanan 1500 kişinin kodunu ezberleyemez... tabi kod mantığı aynı kaydın oluşmasını engelleme mantığıdır. bende aramalarda müşteeri adı ve soyadını aratıp, kullanıcıya bu isim ve soyisimle müşteri kaydı var eminmisiniz diye sorduruyorum. kullanıcı isteğine göre bakıyor tamam bu kayıt aynı kayıt derse kayıttan vazgeçiyor...

[ercere]

Meerhaba arkadaşlar Aslangerinin fikrine katılıyorum.Ben aşağıdaki gibi kullanıyorum.

Kod: Tümünü seç

       CARI_ID INTEGER
       NUM VARCHAR(15)
       ADI VARCHAR(50)
       ........
       ........
       muhasebe_kodu varchar(25)

Bu şekilde bir yapıda CARI_ID integer ve otomatik artan bir değişken olduğundan tablodaki diğer sütünların yanında önemi bile olmaz.kullanıcı istediği bilgiye ister NUM alanı ile ister ADI alanı ile ulaşssın.CARI_ID alanı ise sadece cari kartlarında kalır ve cari hareket vb tablolarda referans olarak kullanılır.Örneğin bir fatura hareketinde cari ile ilgili sadece CARI_ID alanı referans gösterilir.Buda hareketin size'nı minumumda tutmuş olur ve Cari kartın numarası adı herhangi bir alanı değişse bile heryerde CARI_ID ile temsil edildiğinden hareketlerde bir bozukluk olmaz.
Tabi CARI_ID alanı hiçbir şekilde değiştirilememesi gerekir.
Eğer muhasebe ile entegrasyonda varsa bu kartta bir MUHASEBE_KODU alanı oluşturulur.Entegrasyon da bu alanı referans alarak muhasebe kısmında hareketleri işler.Umarım anlatabilmişimdir.Kolay gelsin.

[aslangeri]

s.a.
müşterinin pkeyi görmemesi gerektiği taraftarıyım.
muhasebe kodu için kayda ayrı bir alan açılabilir diye düşünüyorum(muhasebe entegrasyonu yapmadım.)
kolay gelsin.

[vkamadan]

Merhaba,
Muhasabe entegrasyonlu sistemlerde bence kesinlikle CariHesap kodu ile Muhasebe alt hesap kodu birbirinden bağımsız tanımlanabilmelidir.
yani her kartın cari sistemde kullanılacak kodu ile muhasebede işlenecek alt hesap kodu farklı sahalarda takip edilmelidir.
İyi çalışmalar.

[ALUCARD]

bence mutlaka bi id alanı lazım ve bunu müşterinin
görmemesi daha mantıklı

ve bütün sorgulamalar bu id üzerinden olmalı
en azından ben hep öyle yapıyorum

ilişkili tablom olsada olmasa da mutlaka bi autoinc id alan mutlaka koyuyorum tabloya belki ilerde lazım olur diye

ve bunun mutlaka yararını görmüşümdür

gün gelir orası lazım olur

tabi ilşkili tablolar varsa ve bunu müşterinin değiştirebileceği bi alan üzerinde yapıyorsan
bu kesinlikle çok tehlikeli bi olaydır

müşteri gün gelir ben bunun numarasını değiştireyim derse bütün ilişki kopar ve kayıt yeni bir kayıtmış gibi olur

tabi bunu trigger ile diğer kayıtlarada yansıtabilirsin ama buda vt de performans kaybına neden olur.