Skip to main content

AccessTr.neT


sql kodu çok karmaşık hatası

sql kodu çok karmaşık hatası

#12
Sayın celilpartal,

Uygulamanız tekrar incelendiğinde aşağıdaki hususlara yönelik olarak bazı bilgilendirmelerin (yorumların) yapılması gerektiği görülmüştür.istişare etmek ve verimli bir uygulama olmaya zemin hazırlaması adına belirtmekte fayda var kanısındayım.

Form3 adlı satış işlemlerinin yapıldığı formunuzda mevcut bulunan tablodaki 3 kayıt verisi için gecikme hesaplama işlemi yapıldığında,doğru bir sonuç edinme sunmadığı fark edilmiştir...benim anladığım gecikme hesaplaması şu olsa gerek;eğer kişi,ödemelerinin tarihini ödeme tarihi gelmesine rağmen ödememişse geçen her bir gün için hem gün hem de gecikme faizi üzerinden gecikme tutarı hesaplanır.sanırım,zaten sizin de yapmak istediğiniz bu.

Form3 adlı form çalıştırıldığında;her bir kişinin ödemelerini tam da ödeme tarihi günü ne ise o günde ödemesini yaptığı görülmektedir.dolayısı ile de,muntazaman ödemelerde bulunan bir kişi için ne gecikme günü ne de gecikme ödemesi söz konusu olmamalı.oysa, ilgili form üzerindeki Gecikme Hesapla butonu çalıştırıldığında;gecikme gün ve gecikme tutarının hesaplandığı görülmüştür.

Aslında,öncelikle;bu gecikme hesaplamalarına maruz kalacak metin denetim kutularının,geçerli durum söz konusu olduğunda devreye girmesi daha doğru olacaktır kanısındayım.diğer bir ifade ile,ödeme tarihi eğer o günün gün tarihini (date ifadesi) geçtiği takdirde devreye girmeli.o zamana kadar,form üzerinde tüm değerler 0 (Sıfır) veya boş göstermeli.
Ayrıca,kişilerin her bir gecikmeli ödeme durumlarında,hesaplanan gecikme faizi adı altındaki gecikme tutarı,ödenecek olan kalan taksit tutarına dahil edilmeli ki,bu gecikmenin de alınması söz konusu olabilsin.yoksa,hesaplamanın alınacak tutarda gösterilmemesi durumunda hesaplanmasının da gereği kalmamaktadır...Kaldı ki,siz oluşturmak istediğiniz sorguda sadece Alacak tutarı üzerinden sorgulamak istiyorsunuz.gecikme tutarını da dahil edecek şekilde oluşturulması daha geçerli değil mi?

Bir de,ödeme tarihi için bana göre hazırda olması bir ihtimal değiştirilmeli kanısındayım.çünkü,bu alan değişime uğrayacak bir tarih de olabilir,eğer ki gecikmeli ödemeleri de dikkate alacaksanız.diyelim ki,kişi;ödeme tarihinde değil de bu tarihten daha sonrasında ödemesini yaptı.peki,bu geç tarihi nerede belirteceksiniz? Sonuçta,ödemenin yapıldığı tarihi doğru ve tam gününde belirtmelisiniz ki,olası bir geri dönüş olarak incelemede veya raporlamada daha önceden belirlenen tarihte değil de ödemenin asıl yapıldığı tarihi göstermek gerekmektedir.dolayısı ile de,bu ödeme tarihi belki serbest diğer bir tanımlama ile önceden belirlemesiz olarak da oluşturulabilir.

Bu nedenle,sanırım,sorgulamalara veya diğer çalışmalara geçmeden öncesinde,ilgili taksitlendirme ve gecikme faizi uygulama hususlarını tekrar gözden geçirmeye ve yeniden değerlendirmeye gereksinim olabilir.elbette ki,bütün bu bahsi geçen yorumlar sizi bağlamayan bana dairdir.kabul edilebilirlik ve değerlendirilebilirlik adına takdir ve tercih sizindir.bilginize…iyi çalışmalar,saygılar.
 
Herkes, kendisinin AR-GE'cisidir...


Konulara eklenen Uygulama içeriğine yönelik Tavsiyeler
Alt Form Denetim Değerlerine ulaşma ve Alt Form Güncelleme
Kapatırken Düzenle (Compact On Close) Seçeneğinin İşaretlenmesi Hakkında
Cevapla

Bir hesap oluşturun veya yorum yapmak için giriş yapın

Yorum yapmak için üye olmanız gerekiyor

ya da

Bu Konudaki Yorumlar
sql kodu çok karmaşık hatası - Yazar: celilpartal - 11/08/2015, 14:44
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 11/08/2015, 21:19
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 12/08/2015, 12:50
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 12/08/2015, 14:49
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 12/08/2015, 15:57
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 12/08/2015, 17:00
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 12/08/2015, 18:17
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 13/08/2015, 12:29
Cvp: sql kodu çok karmaşık hatası - Yazar: atoz112 - 13/08/2015, 14:24
Task