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.

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:

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.

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:

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.

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:

Ş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: