1C:Enterprise EĞİTİM

DERS 4

1C:Enterprise Ders 4-1

Kullanıcı Ara Yüzü Temel Bilgileri

Henüz bitmemiş oldukça basit bir uygulama geliştiriyoruz ancak ara yüzü henüz berbat durumda. Ana uygulama penceresi (ana bölüm olarak adlandırılır) alfabetik sıraya göre belgeler, insanlar, şirketler ve envanter ile ilgili çeşitli bağlantılar içerir.

Görünüm ve kullanılabilirlik açısından, şu an bu görünüm mükemmel olmaktan uzaktır. Şu anki haliyle herhangi bir kullanıcının istediği bağlantıyı bulması biraz zaman alacak. Bizim uygulamamız nispeten küçük olduğu için bu sorun o kadar belirgin değil ancak, gerçek hayatta kullanılacak büyük bir uygulama için bu sorun bir kâbusa dönüşecektir. Bu yüzden bazı düzenlemeler yapılması gerekiyor.

Nasıl bir temizlik ve düzenleme yapabiliriz? Evet, birçok yolu var, ama biz temel birkaç şeyden başlayalım.

3 çeşit kullanıcı ara yüzü

Platformun ara yüze yaklaşımı, zaman içerisinde kullanıcıların ihtiyaçlarına ve deneyimlere göre gelişti. Bugün 3 çeşit kullanıcı ara yüzü vardır:

  • – Sıradan ara yüz – geleneksel eski stil, çoklu form, masaüstü uygulaması ara yüzü
  • – Yönetilen ara yüz, görünümü sıradan ara yüze çok benzer ancak temel ilkeleri oldukça farklıdır (geliştirici uygulama ara yüzünü inşa eder)
  • – “Taksi” ara yüzü – tekli form, modern görünüm, web ve mobil cihazlar için hazır ara yüz

Şimdi 3 ara yüzü de aralarında geçiş yaparak görelim.

Lütfen unutmayın, sıradan ve yönetilen uygulama arasındaki fark sadece ara yüz farklılıklarından ibaret değildir. Yönetilen uygulama çalışma anında dinamik olarak ara yüz ve açıklamalar oluştururken, sıradan uygulama basit, kullanıma hazır, bir ara yüz oluşturur. Bu nedenle, yönetilen uygulama geliştirici için daha fazla kontrol, görünüm seçenekleri, arabirimlerin görüm seçeneklerini kontrol etme imkânı sunar.

Sıradan uygulama ara yüzü bir form için prosedür veya fonksiyon çalıştırırken geliştiricinin açıkça sunucu veya istemci tarafı belirtmesi gerekmez ve bunlar arasında kayda değer bir farkta yoktur. (herhangi bir kod herhangi bir yerde çalıştırılabilir ve Platform çalışma anında belirli bir tarafı seçer). Bu yüksek hızlı yerel ağ bağlantısı üzerinde sucunu ve istemci arasında çok geniş trafik oluşması ile sonuçlanır. Yani, sıradan uygulama kullandığınızda, aynı yerel ağ üzerinde hem istemci hem de sunucu çalıştırmanız gerekmektedir. Aksi takdirde uygulama performansı ciddi şekilde tehlikeye girebilir.

Yönetilen uygulama sunucu istemci trafiğini kontrol etmek için daha çok fırsat verir, böylece müşteri yavaş olan bir ağ ile de 1C İşletme sunucusu ile çalışabilir. (GPRS gibi).

Burada bu üç uygulama ara yüzü hakkında bilgileri listeleyen bir tablo göreceksiniz:

Biz sıradan ve 8.2 uyumlu uygulamaları artık oldukça demode oldukları için geliştirmenizi tavsiye etmiyoruz. Yine de bu modlar önceki sürümler ile geliştirilen uygulamalar için Platform da tutulur.

Bu derste, taksi ara yüzü ile kullanılan yönetilen uygulama yapmayı düşünüyoruz.

Komutlar

1C İşletme istemci ara yüzü resmi adı, belirli bir emir komutu ve bu emirler için sonuç getiren görünümden ibarettir. Bunu bir kullanıcı ile etkileşimli özel eylem tarafından tıklandığında (buton, link, simge, sekme) çalışan görsel bir unsur olarak düşünebiliriz.

Komutlardan bazı örnekler:

  1. Favori listesini gösterir.
  2. Hizmet belgeleri listesini açar.
  3. Program hakkındaki bilgileri gösterir.
  4. Müşteriler sekmesini gösterir.

Bazı komutlar (sistem komutları olarak adlandırılır) önceden tanımlıdır ve bunlar geliştirici tarafından değiştirilemezler. Ama büyük ölçüde geliştirici komutların görünmesi ve çalışmasını istediği yerleri seçebilir, değiştirebilir veya gizleyebilir. Bu komutlar belirli metadata nesneler ile birlikte Platform tarafından oluşturulurlar. Örneğin: yeni bir kart listesi oluşturulduğunda, Platform aşağıdaki komutları otomatik olarak yeni kart listesinin komut ara yüzüne ekler:

  • – Liste formunu aç;
  • – Öğe formunu aç ve yeni bir öğe ekle;
  • – Grup formunu aç ve yeni bir grup ekle;
  • – 

Geliştirici bu komutları aktif olup olmamasını onay kutusunu işaretleyerek kontrol edebilir:

Eğer metadata nesnesinin standart komutları seçili değilse bu komutları komut ara yüzünde görünmeyecektir. Dâhili kullanım (genellikle sadece geliştiricinin değiştirebileceği listeler vb.) için oluşturulan metadata nesneleri için bu onay kutusu seçimini kaldırabilirsiniz. Örneğin; geliştirici bir mail gönderme fonksiyonu hazırlamaktadır ve mail gönderilen en son 5 e-posta adresini bilmek istemektedir. Bu metadata nesnesinin (bilgi kayıt tablosu, daha sonra bahsedeceğiz) kullanıcı ara yüzünde direk işlem yapılması için gösterilmesine ihtiyaç yoktur. Bu metadata nesnesi için komut ara yüzü onay kutusunu seçimini kaldırmalısınız. Böylece bu nesne verisi sadece Platform tarafından değiştirilebilecektir.

Not, unutmayın ki, bu onay kutusu seçimini kaldırmak nesne verilerini ulaşılmak yapmamaktadır. Kullanıcılar hala bu nesnenin verilerine erişebilir ve verileri değiştirecek bir kod çalıştırabilirler. Eğer kullanıcı rolü izin veriyorsa, kullanıcı ana menüdeki tüm fonksiyonları aç komutunu kullanabilir.

Sistem komutları dışında, geliştirici Tasarımcı modun da ihtiyacı olan tüm komutları açıkça tanımlayabilir ve bunları komut ara yüzüne ekleyebilir. Bu durumda, geliştirici, kullanıcı bir komut çalıştırdığında gerçekleştirilecek olan kaynak kodunu belirtir.

Yani, burada Platform tarafında oluşturulan komutlar ve geliştirici tarafından oluşturulan ve kullanıcıların kullanacağı açık kaynak kodlar bir demet halindedir. Biz bu komutları ara yüzde nereye koymalıyız?

Ana bölüm komut ara yüzü

Ana bölüm olarak adlandırılan bu kısım, uygulamanın temel kısmı ve basittir. Bu komut ara yüzünü navigasyon aracı olarak düşünebiliriz. Kullanıcıların her zaman önlerinde olan bu kısım farklı görevler arasında geçiş yapmak için kullanılır. Örneğin; kullanıcı alış faturası evrakına tıklayabilir ancak açılan pencere ana bölüm üzerinde açıldığı için ana bölümün diğer komutları hala gözükür. Kullanıcı evrakı kapattığında yine ana bölüm ekranı gözükür.

Ana bölüm komut ara yüzü:

Burada nelerin gösterileceğini geliştirici kontrol edebilir mi?

Tasarımcı da konfigürasyon ağacının en üst kısmında sağ tıklayarak Ana bölüm komut ara yüzü kısmını açabilir:

Açılan pencereye ana bölüm komut ara yüzü düzenleyicisi denir ve çalışma şekli şöyledir:

Yani, yukarıdakilerin hepsini özetlersek:

  • – Yeni metadata nesne eklendiğinde, Platformun standart komutları komut ara yüzüne ekleyip eklemeyeceğini belirlemek.
  • – Geliştirici komutların, ana bölüm komut ara yüzünde olup olmayacağını tanımlar.
  • – Kullanıcı her şekilde değişiklik yapabilir, elemanları gösterme, gizleme veya başka bölüme taşıma gibi.

Masaüstü

Bazı form ve ögelerin kullanım sıklığı diğerlerinden fazladır. Bir veya birkaç tane form veya ögenin uygulama açıldığında hemen göz önüne gelmesi istenebilir. Bu formların başlangıç (masaüstü) ta gösterilmesi sağlanabilir.

Burada nasıl çalıştığını görelim.

1C:Enterprise Ders 4-2

Altsistemler

Bu seçenekler ile elimizden gelenin en iyisini yaptık ama hala çalışma alanı dağınık gözüküyor.

Eğer 7’den fazla bağlantı sağlayacaksak bunu nasıl yapacağız veya ekrana nasıl sığdıracağız? (Gerçek hayattaki sistemlerde genelde böyledir)? Bizim bu kadar çok bağlantı için kesinlikle gruplama yapmamız gerekiyor. Bunun için Altsistemleri kullanacağız. Bunu alt komutlar kümesi içeren bir klasör olarak düşünebiliriz.

Bizim oluşturmak istediğimiz “klasörler”:

  • – Inventory
    •      – Warehouses
    •      – MaterialsAndServices
    •      – BalanceOfMaterials (Totals)
  • – People
    •      – Customers
    •      – Employees
  • – Documents
    •      – GoodsReceipt
    •      – Services

Şu an ara yüzümüz nasıl gözüküyor bakalım:

Biz, ne yaparsak, ana bölümün sağ tarafına alt sistemleri eklemiş oluruz? Hadi bunun nasıl yapıldığını görelim.

Bölümler

Platform da ana bölümün herhangi ibr yerine yerleştirilebilen 6 tane önceden tanımlanmış bölüm vardır. Bölümlerin listesi için konfigürasyon ağacının en üstünde sağ tıklayarak “İstemci uygulama ara yüzünü aç” a basarak açılabilir:

Nasıl çalıştığını görelim.

Ara yüz ögeleri görünümü ve veri erişimi

Her kullanıcı farklıdır. Bazı kullanıcılar muhasebe departmanında, diğerleri yönetim veya satış departmanında olabilir. Kullanıcıların hepsi aynı bilgileri içeren uygulamayı kullanıyor ancak her bir kullanıcı uygulamanın sadece bazı fonksiyonlarına ihtiyaç duyar. Örneğin, bir satış elemanının muhasebe raporlarını görmesine gerek yok ve üst düzey bir yönetici envanter raporu görmek veya belirli bir faturaya bakmak istemez. Bu yüzden bazı ara yüzlerin bazı kullanıcılar için gizli olmasını istiyoruz. Öte yandan, bazı özel bilgilerin güvenliğini sağlamak için bazı kullanıcıların görmesini istemeyebiliriz. Örneğin, şirketin üst yönetimi kullanıcıların hiçbirinin şirketin finansal raporlarını görmesini istemez.

İster istemez, geliştirici bazı kullanıcılar için bazı ara yüzleri gizlemek zorundadır. Bu nedenle bazı kullanıcılar gruplandırarak bu gruplara belirli haklar tanımlamalıdır.

İşte bu kullanıcı gruplarını Roller olarak adlandırıyoruz.

Roller ve Kullanıcılar

1C İşletme’de ne zaman yeni bir uygulama geliştirme yapılırsa yapılsın ilk başta konfigürasyon için hiçbir rol ve kullanıcı tanımlı değildir. Bu aşamada herkesin yapabileceği şeyler:

  • – Uygulamayı şifre girişi yapmadan çalıştırma;
  • – Önemi ne olursa olsun tüm ara yüz ögelerini görmek;
  • – Infobase üzerinde herhangi bir veri erişimi.

En kısa sürede belirli değişiklikler yapabilen bir kullanıcı eklemelisiniz. Böylece doğrulanmamış kullanıcı girişine daha fazla izi vermemelisiniz. Artık, uygulamayı çalıştırmak isteyen kişi kullanıcı adı ve şifresini girerek kim olduğunu bildirmiş olacaktır. 1C İşletme kullanıcı rolleri hem tasarımcı hem de İşletme kullanımı için aynı şekilde geçerlidir.

Bu nedenle, eklenen ilk kullanıcının yönetici haklarına sahip olması gerekli ve önemlidir. Aksi halde, Tasarımcıyı çalıştırmak mümkün olmaz ve uygulamaya bir daha erişemeyebilirsiniz. İyi haber şu; Bunu  yapmaya Platform izin vermez.

Eğer ilk eklenen kullanıcı yönetici haklarına sahip olmazsa, aşağıdaki gibi bir hata mesajı alınır:

İlk kullanıcıya yönetici haklarını nasıl verebiliriz? Bunu şema üzerinde görelim ve biraz düşünelim.

Burada bu resim ile alakalı birkaç ipucu vermeliyiz:

  • – Erişim hakları ve ara yüz elementlerinin görünüm seçenekleri Roller’e verilmektedir. (Herhangi bir kullanıcıya verilmez). Kullanıcılar’a rol atandığında kullanıcılar o role ait erişim haklarını vb. miras olarak otomatik olarak alır.
  • – Her kullanıcı adı ve şifre sadece bir kullanıcıya aittir. (Role ait değil)
  • – Bir kullanıcıya birden fazla rol atanabilir ve roller birden fazla kullanıcı içerebilir:
    •      – Yok
    •      – Bir
    •      – Birden fazla
  • – Roller uygulamanın bir parçasıdır ancak kullanıcılar değildir. Uygulamayı başka bir yere aktarırken kullanıcı listesi aktarılmaz.
  • – Kullanıcı şifreleri açıkça infobase de depolanmaz, Platform tarafından şifrelenerek tutulur. Kullanıcı giriş yapmak için şifreyi girdiğinde Platform tuttuğu şifrelenmiş veriye ters işlem uygulayarak eşitliğini kontrol eder. Bu nedenle, eğer şifre unutulursa kurtarılamıyor.

Şimdi, yönetici rolü oluşturalım ve bir kullanıcıya yönetici rolü atayalım.

Erişim hakları ve görünürlük

Belirli bir rolden bilgi gizlemenin iki tür yolu vardır:

  • – Veriyi gizleyebiliriz
  • – Veya veriye erişimi engelleyebiliriz

Bu iki metot sonucunda da kullanıcı ara yüzü görünümünde birbirine benzer sonuçlar elde edilir, ancak bu iki metot farklı amaçlar için kullanılmalıdır.

Biz bazı geçici nedenlerden dolayı bazı kullanıcılardan bazı verileri gizlemek isteyebiliriz ve veri gizli olur. Biz bu rolün kullanıcılarının bu verilere nadiren ihtiyacı olduğunu düşünüyoruz ve kullanıcı ara yüzünün gereksiz ayrıntılarla dolu olmasını istemiyoruz. Buna göre, kullanıcılar eğer bu verileri görmek isterlerse bazı ara yüz ayarlarını değiştirerek bu verilere ulaşabilirler.

Biz kalıcı güvenlik sebeplerinden dolayı bazı kullanıcılardan bazı verileri gizlemek ve okuma ya da yazma işlemlerini de yapmamalarını istiyorsak, veriye erişim iznini kaldırabiliriz. Biz bu kullanıcıların veriye erişim olduğu takdirde kasıtlı veya yanlışlıkla zarar verebileceğini tahmin ediyoruz. Not, biz veriye erişim iznini kaldırdığımızda bu kullanıcıların veriye erişiminin bir yolu olmadığını unutmayın – verilere ulaşımla birlikte veri nesnesinin ayarları ve kaynak kodları da erişilemez olacaktır.

Şimdi verilerin görünürlük ve erişim izninin nasıl yapıldığını görelim.

1C:Enterprise Ders 4-3

Malzeme ve Hizmetlerin fiyatları

Biz ne zaman Hizmet evrakına yeni bir malzeme veya hizmet girişi yaparsak bu malzeme veya hizmetin kendine özgü bir fiyatı olacaktır.

Şimdi kullanıcıların evrakın fiyat sütununa manuel olarak fiyat girmesi iyi bir fikir olmayabilir. Kullanıcı tüm fiyatları biliyor olsa bile giriş yaparken yanlış yazma ihtimali vardır. Ayrıca fiyat yazarak kullanıcı zamanın bir kısmını boşa harcayacaktır. Ayrıca kullanıcı tüm fiyatları sürekli olarak nasıl bilecek? İlk etapta bu fiyatları nereden elde etti? Nitekim firmamızın her malzeme ve hizmet için geçerli satış fiyatını içeren bir fiyat listesi gibi bir şeyi olmalıdır. Ve bu fiyatlar kullanıcı bir malzeme veya hizmet seçtiğinde otomatik olarak evraktaki fiyat sütununa eklenmelidir.

Yani, bunu nasıl uygulayabiliriz?

Aklımıza ilk gelen şey şu: MaterialsAndServices kart listesine yeni bir öznitelik(Price) eklemeye ne dersin?

İyi gözüküyor, ama biz fiyatı değiştirdiğimizde ne olacak? Temel olarak eski fiyat sistemden kaybolur ve yenisi ile değiştirilir. Aynı zamanda eski belgelerdeki fiyatlarda değişmiş olacak. Eğer eski belgelerde fiyat kontrol etmemiz gerekirse ne olacak? O zaman ki geçerli fiyat ile şu anki fiyatın tutarlı olup olmadığını nasıl anlayabiliriz?

Yani, bizim bir öznitelik yerine geçmişe dönük olarak fiyatları kaydeden bir listeye ihtiyacımız var gibi görünüyor. Tamam, biz bunun için kart listesinin tablo özniteliklerini kullanırsak ne olur?

Bu çözüm çalışıyor ama hala bazı sorunlar var. Haydi, şimdi fiyat değişikliklerinin nasıl kayıt olacağını düşünelim? Tabi ki, biz şu an kullanıcıların doğrudan tablo bölümünü düzenlemesine izin verdik ancak bunun geriye dönük olarak takip edilmesini nasıl sağlayacağız? Diyelim ki, 6 ay önce ki fiyatı kim neden değiştirdiğini bulmamız gerekiyor, bu durumda ne yapacağız?

Tamam, biz tablo öznitelikleri kısmına birkaç basit öznitelik ekleyelim:

ChangedBy özniteliği, Employees kart listesine referans olarak bağlanabilir ve Reason özniteliği – fiyatına neden değiştirildiği burayya string olarak istenilen uzunlukta azılabilir.

Kulağa hoş geliyor ama bir adım ötesini düşünelim. Bir malzeme listesi birden fazla fiyatın değiştirilmesi gerekiyorsa, bu durumda sistem nasıl çalışacaktır? Diyelim ki, PVC borular için mevsimsel özel bir satış veya bağlantı kesici boru için Noel özelim indirimi var. Tüm bu değişiklikler aynı sebeple aynı kişi tarafından aynı tarihte yapılır. Bu işlevsel gereksinim tablo özniteliklerini kullanarak geçmiş tarihler için fiyatları depolamak için neredeyse uyumlu, çünkü:

  • – Birden fazla kez aynı veriyi depolamak istiyoruz. Diyelim ki, R22 soğutucu ve uzatma kablosu fiyatında 31 Ağustos tarihinde fiyat yöneticisi Emre KARA tarafından Cadılar Bayramı için indirim programı uygulandı. Bu gerçeği yansıtmak için her iki kart listesindeki bilgileri girmek için işlemi tekrarlamak gerekir.
  • – Bizim birden fazla malzeme veya hizmet seçtirmek ve bunlar için yeni fiyat girilmesini sağlamak için yeni bir ara yüze ihtiyacımız var. Aksi takdirde kullanıcı bu işlemi tekrar tekrar yapacaktır ve bu fikir çok kullanışlı me mantıklı gözükmüyor.
  • – Her seçilen malzeme için yeniden fiyatlandırma bilgileri girmek için yeniden fiyatlandırma algoritması uygulamamız gerekiyor.
  • – Bu algoritma seçilen malzemeleri teker teker okur ve yeni fiyatları teker teker yazar. Performans açısından bu yaklaşım tam bir felaket olur. (Ders 1’de bu gidiş-dönüş etkisi tartışılmıştı).

Bu nedenle bu amaçlar için tablo öznitelikleri bölümünü ekarte ettik.

Yukarıda listelenen tüm sorunlar için ücretsiz ve çok daha doğal bir çözüm var.

Ayrı bir belge kullanarak fiyat ayarlama

Biz MaterialsAndServices kart listesi yerine ayrı bir metadata nesnesi oluşturup fiyatları saklasak ne olur? Bu nesne temelde sistemimizde yapılan ticari işlemin bir başka türüdür. Bu yüzden, Ders 1’de tarif edildiği üzere, burada başka bir belgeye ihtiyaç vardır.

Bu belgenin tarihi değişen fiyatın tarihini en iyi şekilde temsil edecektir. Belgenin üst kısmında değişikliği yapan kişi (CatalogRef.Employees) ve değişikliğin nedeni (String 200) yer alabilir. Biz belgenin tablo öznitelikleri bölümünü malzeme veya hizmetler (CatalogRef.MaterialsAndServices) ve bunların yeni fiyatlarını saklamak için kullanacağız.

Ayrıca Subsystems (Altsistemler) sekmesinden belgemizin görünmesini istediğimiz klasörü seçelim. (Belgeler (Documents) iyi bir yer gibi gözüküyor)

Bu belge değişen fiyat işlemleri için birincil veri kaynağı olarak hizmet verecek ve bu yüzden biz bu belgeye belirli kullanıcıların erişmesi içi erişim hakları belirtmeliyiz. (Tüm kullanıcıların bu belgeyi kullanarak fiyatları değiştirmesini istemeyiz).

Şimdi yeni bir rol “Fiyat Yöneticisi” oluşturalım ve bu belge için erişim hakkı tanımlayalım:

Not, yönetici rolü yeni bir nesnenin tüm erişim haklarını kısa sürede alır. Platform bu erişim haklarını yeni nesneye otomatik olarak ekler çünkü “Set rights for new objects” onay kutusu seçili.

Aynı zamanda, Satış rolü erişim haklarını otomatik olarak alamadı. (Onay kutusu seçili değil).

Şimdi, belge doldurulduğu zaman biz geçerli fiyatları nasıl alacağız?

PVC borular için son yıl 10 kez fiyat değişiminin elimizde olduğunu düşünelim. Yani, biz 10 farklı belgeye sahibiz, bizim en son bu malzemeyi içeren belgeyi bulmamız ve fiyatı okumamız gerekiyor. Açıkçası, bir döngü içerisinde tüm belgeleri okumak ve kontrol etmek gerekir, bu işlevi etkin nesne tekniğini kullanarak uygulamak mümkündür.

Tamam, sorgu hakkında ne düşünüyoruz? İşte kullanabileceğimiz sorgu cümlesi:

SELECT TOP 1

TabularSection.NewPrice

FROM

Document.PriceChange.MaterialsAndServices AS TabularSection

WHERE

TabularSection.MaterialOrService = &MaterialOrService

­

ORDER BY

TabularSection.Ref.Date DESC

­

Burada bu malzemeyi içeren tüm PriceChange belgelerini seçiyoruz daha sonra tarih bilgisine göre azalan sıralama ile sıralıyoruz ve en son kaydedilmiş belgeyi alıyoruz. Bu bizim ihtiyacımız olan sunucu verir. Ancak performans açısından çok kötü bir işlemdir. Bu derste çok ayrıntılı bir şekilde bu konu üzerinde durulmayacak ancak aşağıdaki fikirleri göz önünde bulundurmalısınız. DBMS (Veri tabanı Yönetim Sistemi) ‘nde bu sorguyu nasıl çalıştırabiliriz?

Evet, ben şu an ihtiyacım olan malzeme kayıtları için tablo bölümünü tarardım sonra LEFT JOIN komutu ile belgeyi tarih özniteliği ile bağlardım ve son olarak sonuç kümesi tarih e göre listelendiğinde ilk kayıt istediğim sonucu vermiş olacaktır.

Peki, ama biz kaç tane kayıt okumalıyız? En azından satış belgelerinin tablo öznitelikleri kadar kaydı okumalıyız. Bu sayıyı azaltmanın bazı yolları vardır ama ihtiyacımız olan belgeyi bulmak için ne kadar kayıt okumamız gerektiğini asla bilemeyiz.

Yani, burada temek bir kural vardır: bir nesnenin sınırlarını aşan durumlarda tablo öznitelikleri kullanmaktan kaçının. Diğer bir değişle,  eğer SELECT FROM TabularSection olarak tablo kısmını almak için WHERE komutu altında WHERE Ref = &Ref cümlesini kullanırsanız, bu sadece geçerli doküman ile sınırlandırılmış bir sorgu olacaktır. Eğer tablo kısmını kullanmadan bu koşul ile sorgulama yapmanız gerekiyorsa bunun için daha iyi bir çözüm aramak gerekir.

Bu daha iyi bir çözüme Bilgi Kayıt Tablosu (Information Register) denir.

1C:Enterprise Ders 4-4

Bilgi Kayıt Tabloları temel bilgileri

Biz bilgi kayıt tablolarını (IR) birkaç farklı amaç için kullanıyoruz.

1.Herhangi bir metadata nesne türüne ait olmayan verileri saklamak için

Bu durumda,1C içinde IR standart SQL açısından bir tabloya çok benzer. Biz bazı genel bilgileri depolamak için bazı gereken yerlerde IR kullanıyoruz.

Örneğin, bizim sistemimizde bir hatırlatıcı işlev kullanmak gerekiyor. Bir kullanıcı gelecekte belirli bir anda kendisi veya başka kullanıcıların görebileceği bir not oluşturabilmelidir.

Bu amaç için kullanabileceğimiz IR:

2.Nesne için ek bilgi depolamak, tablo sekmesini kullanmak istemiyoruz

Diyelim ki, e-posta ile alınan faturaları kaydetmek için bir belge oluşturuldu. Biz belgenin öznitelikleri ile birlikte orijinal belgenin taranmış bir görüntüsünü de kaydetmek istiyoruz.

Biz bunun için bir Resim özniteliği oluşturup, bunu ValueStorage olarak tanımlayabiliriz. Ama bu sefer, belge her açıldığında resmi okumamız ve bellekte tutmamız gerekecek. Bu gereksiz bellek kullanımını önlemek için ve uygulamanın yavaşlamasını gidermek için InvoicesImages isminde bir IR oluşturabiliriz:

3.Çoktan çoka nesneler arasında ilişkiler ayarlamak

Diyelim ki, bizim elimizde iki tane kart listesi var: Students ve Courses. Herhangi bir öğrenci herhangi bir sayıda derse kayıt olabilir. Biz bu bilgiyi nasıl saklayabiliriz?

Bunun için Students kart listesinin tablo bölümünü kullanabiliriz:

Ama biz belli bir kurs için kayıt yaptıran tüm öğrencileri görmek istersek ne yapabiliriz? Bunu şu sorgu cümlesi ile alabiliriz:

SELECT

StudentsCourses.Ref.Name,

StudentsCourses.Ref.Birthday

FROM

Catalog.Students.Courses AS StudentsCourses

WHERE

StudentsCourses.Course = &Course

­

Bu sorgu cümlesi Ref = &Ref koşulu olmadan tablo bölümündeki verileri alır. Ama biz bir önceki dersimizde bunun ciddi performans sorunları ortaya çıkaracağından bahsetmiştik.

Tamam, şimdi biz aynı tablo bölümünü Students kart listesi yerine Courses kart listesinde kullanabiliriz. Ama bu sefer de bir öğrencinin kayıt olduğu tüm dersleri nasıl bulabiliriz?

En iyi çözüm bunun için IR kullanmak:

4.Bazı olayların geçmişini saklamak için veya bazı özniteliklerin ilk ve son değerini hızlı biçimde bulmak için

Biz sık sık çeşitli olaylar için geçmişi kaydetmeye ihtiyaç duyarız. Birkaç örnek verecek olursak:

  • – Döviz kurları oranları geçmişi
  • – Öznitelik sürüm geçmişi
  • – Kullanıcı işlemleri logları

Bizim fiyatlarımız IR kullanımında bu kategoriye girer. Şimdi daha fazla yapı bilgisi ve özellikleri göz önüne alalım.

IR periyodikliği

Biz IR ile veri saklama işlemi yaparken bunun periyodik olmasını istiyoruz. Periyodik IR de her kaydın ait olduğu zaman anlamı içeren sistem özniteliği olarak süre tanımı vardır. Yukarıda verilen IR örneklerinin ilk 3 ü periyodik değil, sonuncusu periyodiktir.

Seçim yapabileceğiniz periyodiklik listesi şöyledir:

Eğer zaman eksenine kayıtları bağlamak istemiyorsanız periyodik değil seçimini yapabilirsiniz.

Eğer bu IR’nin kayıtlar için aynı zamanı kaydetmesini istiyorsak, “By recorder position” seçilebilir. (belge kaydedildiği an IR içine kayıt yapılır).

Listenin alt kısmındaki içinde (Within) kısmını da seçilebilir. Buradan bir şey seçilmesi sık sık değişiklikler yapılmasına izin verilmesi anlamına gelmektedir. Eğer “gün içinde (Within a day)” seçilirse, olayın tarihini değil, bunun tam zamanını belirtmek mümkün olacaktır. Daha da önemlisi, varsayılan olarak aynı dönemde aynı boyutlara sahip yeni bir kayıt eklemek mümkün olmayacaktır. Sadece var olan kayıt üzerine yenisini yazabilirsiniz. (Boyutlar ve kaynaklar değiştirilerek).

Diğer bir değişle, IR kayıtların benzersizliğini periyodlarına (eğer periyodik ise) ve boyutlarına göre korur.

Biz değişen fiyatlar IR si için hangi seçeneği seçmeliyiz? Görelim.

“By recorder position”, kullanılırsa bunun anlamı PriceChange belgesi kaydedildiği zaman bilgisi IR içinde zaman bilgisi olarak kaydedilir. Yani, eğer biz PriceChange belgesini bugün kaydedersek, fiyatlar listesinde bugün tarihli fiyat geçerli olacaktır. Bu kullanışlı gözüküyor ancak uygulamanın esnekliğini kısıtlıyor. Biz gelecekte bazı fiyatlar için değişiklik yapmak istersek ne olacak? Diyelim ki, bir sonraki aydan itibaren PVC borularında indirim yapmaya karar verdik ama bu durumda belgenin ve IR kaydının tarihi bugün olacak ve eğer belgeyi bugün kaydedersek gelecek aydan itibaren geçerli olması gereken fiyatlar bugünden itibaren geçerli olacaktır.

Bu nedenle bizim için “Within… (içinde)” seçenekleri daha makul gibi görünüyor.

Burada dikkatli olmamız gereken tek şey dönemin uzunluğunu doğru seçmektir. Ben gün içinde fiyatın birden fazla kez değişeceğini hayal edemediğimden, bizim için “Within (içinde)” seçeneğini seçmek mantıklı olacaktır.

1C:Enterprise Ders 4-5

IR kayıt tarzı

Burada iki adet kayıt tarzı vardır:

Belgelerin hiçbirine ait olmayan bağımsız IR kayıtları bazı verileri içerir (birincil veri). Bizim Fiyat IR miz ikincil kayıtlar ile doldurulacaktır- PriceChange belgesinin tablo bölümünün satırları – bu yüzden biz burada “Subordinate to recorder (kayıt eden bağlılığı)” seçmeliyiz.

Bizim bu IR içeriğini kontrol etmemiz gerekir, bu yüzden Inventory altsistemine ekleyelim.

Ayrıca bu IR için PrinceChange belgesini kaydedici olarak belirtmek gerekiyor.

IR boyutları, kaynakları ve öznitelikleri

Daha öncede bahsedildiği gibi, periyod + boyutlar IR içinde benzersiz bir anahtar içermektedir, bunun anlamı IR içinde iki kayıt aynı periyod ve boyut içerisinde olamaz. Yani, belirli bir an ve boyut için belirli kayıtları okuyabilirsiniz. Bizim görevimiz, herhangi bir malzeme veya hizmet için günde bir kez fiyat değişikliği yapabilmektir. Bu nedenle, ihtiyacımız olan tek boyut CatalogRef.MaterialsAndServices dir.

Şimdi bizim bir fiyat eklemek için bir sorumuz var: fiyat ne olabilir – kaynak veya öznitelik? Bu kararı Birikim Kayıt Tabloları için vermek açıkçası daha kolay: AR kayıt tablosu bakiyesini kayıt etmek için kaynak olarak belirlemek yeterlidir, zaten öznitelikler bakiye tablosuna kayıt yapmaz, sadece ek bilgi varsa kayıt yapar.

Burada, yani IR içinde, öznitelik ve kaynaklar özellikleri arasında bir fark yoktur – ikisi de işlevsellik ve performans açısından oldukça elverişlidir. Ama Platform için iki farklı kategoriyi vurgulamak için kullanılırlar:

  • – Kaynakları geçmişi takip etmek için var olan değerleri saklamak amacıyla kullanıyoruz.
  • – Öznitelikleri ek bilgi varsa bu ek bilgiyi saklamak amacıyla kullanıyoruz.

Bu nedenle, burada Fiyat (Price) kaynak (resources) olmalıdır.

IR ve AR farklarından bir şey daha – IR içinde bakiye tablosu yoktur. Ama aynı amaca hizmet edebilen ikincil veri içeren iki tablo vardır – bu da sık ve kritik sorguları gerçekleştirmeyi sağlar.

Bu tablolara İlk ve Son Dilim Tabloları denir.

IR Dilim Tabloları

Bazı değerlerin değişikliklerini saklamak için IR kullandığımızda, en yaygın biçimde bizim görevimiz bu değerin şu an ki mevcut durumunu okumaktır. Biz fiyatlardaki değişikliklerin geçmişini saklamak için Fiyatlar IR (Prices IR) kullanıyoruz. Açıkçası malzeme veya hizmetlerin mevcut fiyatlarına çok sık ihtiyacımız olacak.

Malzeme veya hizmetlerin fiyat değişikliklerinin tarih düzenine bir göz atalım.

Fiyatlar zaman içinde farklı noktalarda değiştirildi. M1 en son T5 anında değiştirilmiş, M2 – T6 anında ve M3 – T4 anında. Bu gerçekten kolay bir işlem olacak – tek sorgu ile tüm malzemeler için son fiyatları alacağız. Bu nedenle, Platform bize SELECT komutu ile kolayca veri almamız için sanal tabloyu sunuyor. Sorgu yapılandırıcısını (QueryBuilder) açtığınızda listede bu tabloları kolayca görebilirsiniz.

Not, bu listede başka bir tablo daha var Prices.SliceFirst. Bu tabloyu da ilk fiyatları almak için kullanabiliriz (şu bizim bu tabloya ihtiyacımız yok).

Ayrı bir fiziksel tablodaki son fiyatları Platforma sorabiliriz (bizim için gerekebilir). Ancak sanal tablo kullanımı bizim için sorgu kullanımında performansı oldukça arttıracaktır.

Tamam, şimdi veri girişi yaparak tabloları dolduralım.

PriceChange belgesinin kaydedilmesi

Bunu yapmak için PriceChange belgesinin Kaydetme Olay İşleyicisinin kullanılması ve kayıt işleminin yapılması gerekiyor. Bu işlemi Hareket Yapılandırıcısını kullanarak yapalım.

Hareket yapılandırıcı içinde Platformun IR ye veri kaydını hangi nesnelerden yapacağı belirtilir:

  • – Prices. MaterialOrService = Document.PriceChange. MaterialAndServices.MaterialOrService
  • – Prices. Price = Document.PriceChange. MaterialAndServices.NewPrice

OK butonuna bastıktan sonra Platform bize şu kodu vermektedir:

Procedure Posting(Cancel, Mode)

//{{__REGISTER_REGISTERRECORDS_WIZARD

// This fragment was built by the wizard.

// Warning! All manually made changes will be lost next time you use the wizard.

 

­

// register Prices

RegisterRecords.Prices.Write = True;

For Each CurRowMaterialsAndServices In MaterialsAndServices Do

Record = RegisterRecords.Prices.Add();

Record.Period = Date;

Record.MaterialOrService = CurRowMaterialsAndServices.MaterialOrService;

Record.Price = CurRowMaterialsAndServices.NewPrice;

EndDo;

 

­

//}}__REGISTER_REGISTERRECORDS_WIZARD

EndProcedure

­

Şimdi bizim ihtiyacımız olan Hizmetler (Services) belgesinde fiyat alanının otomatik olarak doldurulmasıdır.

Fiyat alanının otomatik doldurulması

Şimdi Services (Hizmetler) belgesinin modülünün son halini görelim:

&AtClient

Procedure MaterialsAndServicesMaterialOrServiceOnChange(Item)

Item.Parent.CurrentData.Price = GetCurrentPrice(Object.Date, Item.Parent.CurrentData.MaterialOrService);

EndProcedure

 

­

&AtServer

Function GetCurrentPrice(Date, Ref)

Filter = New Structure;

Filter.Insert(“MaterialOrService”, Ref);

CurrentPrice = InformationRegisters.Prices.GetLast(Date, Filter);

Return CurrentPrice.Price;

EndFunction

­

DND Yazılım Bilişim Teknolojileri San. Tic. Ltd. Şti.
Ankara Üniversitesi Teknoloji Geliştirme Bölgesi D-1 Blok No: 11
GÖLBAŞI / ANKARA

Tel: 0312 484 84 17

Faks: 0312 484 34 19

E-Mail: info@dndyazilim.com.tr