Veri ayırma mekanizması 1s. Veri Ayırma, Mekanizma. Bir tarihin ay gösterimi

Veri paylaşım mekanizması birkaç bağımsız kuruluşun verilerini tek bir bilgi tabanında saklamanıza olanak tanır.

Bu, konfigürasyon nesnelerinin ortak özniteliklerinin yalnızca "tüm nesnelerin sahip olduğu aynı öznitelik" olarak değil, aynı zamanda verilerin birkaç bağımsız alandan birine ait olduğu bir tanımlayıcı olarak kullanılabilmesi nedeniyle mümkün olur. Bu, aşağıdaki örnekle açıklanabilir.

Konfigürasyonda ortak bir "Organizasyon" özniteliği olduğunu varsayalım. Bu, (basitleştirilmiş) her dizin, belge veya diğer yapılandırma nesnesinin "Organizasyon" özniteliğine sahip olacağı anlamına gelir.

Bu durumda, bilgi bankasının herhangi bir kullanıcısı, örneğin belirli bir belgede, hangi organizasyonun belirtildiğine bakılmaksızın, bu veritabanında depolanan tüm verilere erişebilir.

Şimdi "Organizasyon" ortak özniteliğinin bir ayırıcı olacağını belirtelim.

Ardından (basitleştirilmiş) bilgi tabanında, her biri yalnızca belirli bir kuruluş için veri depolayacak olan birkaç bağımsız veri alanı oluşturulacaktır:

Artık programa girerken, kullanıcı bilgi tabanındaki tüm bilgilere değil, yalnızca "kendi" alanındaki verilere erişecek, bu durum kuruluşunuzun belgelerine, referans kitaplarına vb.

Bu mekanizmayı kullanmanın başka bir çeşidi de, bilgi tabanında birkaç bağımsız veri alanı olduğunda ve bununla birlikte programın tüm kullanıcıları tarafından kullanılabilen veriler olduğunda da mümkündür. Örneğin, tüm kuruluşlar için aynı olan bir banka dizini içerirler.

Bu durumda, kullanıcının "kendi" veri alanına ve tüm kullanıcılar için ortak olan paylaşılmayan veri alanına erişimi vardır.

Veri paylaşım mekanizması oldukça esnek ve evrenseldir:

bir değil, birkaç ayırıcı kullanmanıza izin verir;
paylaşılan verileri kullanmanın farklı modları vardır; sınırlayıcı değeri belirtilmediğinde durumun nasıl ele alındığı konusunda farklılık gösterirler;
ortak bir özniteliğin ayırıcı olarak kullanımı, yapılandırmayı değiştirmeden program çalışması sırasında yerleşik dilden kontrol edilebilir; buna koşullu bölünme denir.

[Button 7710967300 BUX RB] Connect=Srvr="%sunucuadı%";Ref="%base_name%"; EkParametreler=/Z "-0,-0,+7710967300";

/Z'den sonra genel detayları sırayla belirtiyoruz. Standart muhasebemiz zaten iki ortak sistem detayına sahip olduğundan, kullanılmamaları için onlar için -0 değerini belirliyoruz ve üçüncüsü (kendi oluşturduğumuz) olarak TIN'i geçiyoruz.

1000 ve 1 onay kutusu

Şimdi, verilerin hangi bölümünün tüm alanlarda ortak olacağını belirlemeniz gerekiyor. Bütün bunlar yapılandırıcı aracılığıyla yapılandırılır. Az önce oluşturduğumuz genel propların özelliklerinde, 800 parametrelik küçük bir liste açan bir “Kompozisyon” öğesi var:

Parametre seçimini sizin takdirinize, takdirinize ve ortamınıza bırakıyoruz. İşte bizim versiyonumuz (dikkatli olun, 20.000 piksel var).

Ayırıcı ayrıca her veritabanı için ayrı bir kullanıcı listesi oluşturmayı mümkün kılar - bu, yüzlerce kullanıcınız varsa kullanışlı olabilir - belirli bir veritabanına girerken, bu listeyi kanlı nasırlara kaydırmanız gerekmez. Bunu kullanmıyoruz çünkü şeffaf yetkilendirme ayarladık.

Mevcut veritabanlarından veri yükleme

Mevcut veritabanlarından veri yüklemek için evrensel bir XML alışverişi kullanıyoruz. Sadece üssü alıp boşaltamazsınız, değişim kurallarını ayarlamanız gerekir, aksi takdirde yükleme sırasında hatalar ve çatışmalar olabilir (ve kesinlikle meydana gelecektir) ve ikinci üssün üzerinden geçmeyecektir. Her organizasyon için temel alanları böldüğümüzü ve bizim durumumuzda bu tür değişim kurallarının işe yaradığını hatırlayın. Farklı bir sınırlayıcı kullanmaya karar verirseniz, beyin ve onay kutularını kullanmanız gerekir. Ana şey standart boşaltma kullanmamaktır - bu, önceden tanımlanmış tüm kayıtların çoğaltılmasına yol açacaktır.

Hostes için not: dizinleri ve belgeleri ayrı olarak yüklemek daha iyidir - bu şekilde yükleme sırasında gereksiz hatalardan kaçınabilirsiniz.

Paylaşılan bir veritabanına veri yükleme

Verilerini indireceğimiz kuruluşun ayırıcısını belirten "-0, -0, +% ayırıcınız%" / Z parametresiyle 1C'yi başlatıyoruz. Evrensel bir değişim başlatıyoruz ve yükleme sırasında alınan dosyaları besliyoruz: önce dizinler, sonra belgeler. Bu işlemi her üs bölgesi için tekrarlıyoruz.

Görevi basitleştirmek için, komut satırında (/Execute c:\upload.epf) biraz düzeltilmiş bir standart işleme çalıştırdıktan sonra yüklemeleri toplu olarak gerçekleştiririz. Ardından alınan dosyaları manuel olarak paylaşılan veritabanına yüklüyoruz.

Daha az zaman harcamak için nasıl daha fazla zaman harcanır

Ayırma süreci hızlı bir şey değildir. Şu anda 500'den fazla kuruluşumuz olduğunu hatırlayın, ancak birkaç hafta içinde yalnızca 70'i paylaşmayı başardık. Ancak, altı ay içinde yapılan çalışmalar ve çok fazla zaman tasarrufu için geçmiş benliklerimize teşekkür edeceğimizden eminiz. çaba.

Muhasebeciler, kuruluşların düzenli bir tabandan bölünmüş bir tabana geçişini fark etmezler, onlar için süreç acısızdır. Popo sadece adminler için yanar :)

Yan etkiler: 1'den 20'ye kadar yerden tasarruf, hızda dolaylı artış - paha biçilmez. Mutlak olarak, 50 kuruluş SQL'de 2 GB yer kaplarken, tek bir veritabanı 800 MB yer kaplar.

Merhemde vaat edilen sinek, hatta dört:

kullanıcılardan biri bir kuruluştaki verileri karıştırdıysa, bölünmüş veritabanının tamamını geri almanız gerekir - yalnızca bir veri alanını alıp geri alamazsınız
güncellemeleri, özellikle dizin ekleyen veya değiştirenleri daha kapsamlı bir şekilde test etmeniz gerekir.
veritabanını müşteriye aktarmanız (veya vergiyi birleştirmeniz :) gerekiyorsa, tersi prosedürü yapmanız gerekir: evrensel değişim kullanarak kuruluşu bölünmüş veritabanından çıkarın, ardından boş bir normal veritabanına yükleyin ve için. dt dosyası
bölünmüş bir veritabanında, zamanlanmış görevleri yönetmek imkansızdır (örneğin, döviz kurlarını otomatik olarak güncellemek mümkün olmayacaktır)

İlk üç kaşık o kadar acı değil - sadece daha fazla dikkat etmemizi sağlıyorlar. Ancak dördüncüsü ile ne yapacağımızı henüz bilmiyoruz, ancak özenle araştırıyoruz.

1. Önsöz.

Bir IB'de iki kuruluş için muhasebe düzenlemeye ihtiyaç vardı. Durum benzersiz değil, ancak öyle oldu ki, tipik olmayan 250 GB UPP'miz oldukça yavaş çalıştı, bu nedenle RLS yerine veri ayırmayı denemeye karar verdik. Açıklandığı şey, örneğin veya. Kısacası, eğer RLS SQL sorgularını koşullandırıyorsa, veri ayırıcı, bölümleme mekanizmasının RLS'den daha hızlı çalışması gerektiğinden, DBMS düzeyindeki tablolarda fazladan bir sütundur.

Bu nedenle, OOO No. 1 için kayıtların tutulduğu veritabanında, ayrı bir OOO No. 2 veritabanından bilgi aktarmak ve ortak çalışma düzenlemek gerekir. Tıpkı resimdeki gibi:

Sadece ölümlüler sadece LLC'leriyle çalışır ve baş muhasebeci bazen iki tüzel kişilik hakkındaki verilere bakar. Her iki LLC'ye erişim modunda, yalnızca verileri okuyabilirsiniz, bu nedenle baş muhasebeci "tümünü oku" / "yalnızca bir kuruluş için yaz" modları arasında etkileşimli olarak geçiş yapabilmeli ve LLC'yi seçebilmelidir (yani, ortak özellik) örneğin maliyet hesaplaması yapmak.

2. Uygulama

Platform 8.2.19.90, uyumluluk modu yok. DBMS - MSSQL Server 2008 R2 Standardı.

"Sayı" türünde ortak bir Organizasyon Ayırıcı özniteliği oluşturduk, oturum parametreleri oluşturma önerisiyle anlaştık, özniteliğin bileşimini doldurduk (birkaç dizin, tüm belgeler, birikim, muhasebe ve hesaplama kayıtları dahil). Verilerin ayrılması - "Bağımsız ve ortaklaşa". Oturum parametresinin değeri, oturum modülündeki SetSessionParameters prosedüründeki varsayılan kullanıcı ayarlarından ayarlanır:

Organizasyon = UserManagement.GetDefaultValue(glCurrentUser,"MainOrganization");
SessionParameters.OrgDelimiterValue = Organization.DelimiterValue;

Baş muhasebecinin arayüzünde, kuruluşlar arasında geçiş yapma ve ayırma modunu etkinleştirme / devre dışı bırakma özelliğine sahip bir form oluşturdular:

Bölme devre dışı bırakıldığında, SessionParameters.OrganizationSeparatorUsage = False olduğunda, platform belgeleri yazmayı reddederek "SDBL Hatası: beklenen ifade (pos=12)" gibi hatalar verir, bu nedenle kullanıcının bu seçenekte belge yazmasına izin veremezsiniz. Güvenilirlik için, ortak özelliğin parçası olan nesneler için "Kayıttan önce" etkinliğine abonelikler oluşturduk:

SessionParameters.OrgDelimiterUse = False ise
#Eğer Müşteri O Zaman
Warning("Veri paylaşımı kapalı olduğu için yazılamıyor!");
#EndIf
Reddetme = doğru;
EndIf;

Eylem planımız şuydu: IB No. 1'in alıcı konfigürasyonunu hazırlıyoruz, ortak öznitelik = 1'in değerlerini koyuyoruz, IB No. 0) ayırıcı değeri, Organizasyon Ayırıcısı = 2 olarak ayarlayın.

Konfigürasyon hazırlandı, soru ortaya çıktı, belgeler ve hareketler için ortak özelliğin değeri kapalı dönemlerde ve hızlı ve terazideki sayıların uçma riski olmadan nasıl ayarlanır? 1C nesne modeli sayesinde nesneden ayrı bir ayırıcı yazmak imkansız, bu yüzden çıkıp MS SQL için bir sorgu yazmak için lisans sözleşmesini bozmak zorunda kaldım. Ortak öznitelikte çok sayıda nesne olduğundan ve elmacık kemiğinde bu nesneler için daha da fazla tablo olduğundan, SQL için bir sorgu oluşturan bir işlem yazdık (ayırıcının parçası olan her meta veri nesnesi için "güncelleme" yazdık. + DB_name + ".dbo._" + TableName + " set _" + Field GeneralAttribute + " = 1";)

Değer ayarlandı, verilerin bir kısmı IB No. 2'den aktarıldı ve test başladı.

Sonuç hayal kırıklığı oldu. İlk olarak, muhasebe kaydı ile ilgili sorunlar. Ayırma etkinleştirildiğinde, analizler görünmez:

Bunun nedeni, VTYS düzeyindeki muhasebe kaydının birkaç tablo olarak saklanması ve tüm tabloların ortak öznitelik değerine sahip olmamasıdır (yapıyı görüntülemek için işleme kullanıldı).

Peki, ayırıcının değerini MS SQL üzerinden yazıyoruz, analitiği görüyoruz. Şimdi raporlar çalışmıyor. "Cirrovers" ve "TurnoversDtKt" muhasebe kaydının sanal tablolarına yapılan sorgularla ilgili sorunlar olduğu ortaya çıktı:

(Fld27033, muhasebe kayıt tablosunda yalnızca ortak bir özelliktir)

Ayırıcı tüm tablolarda ayarlanmıştır, DBMS düzeyinde görülebilir, ne hata olabilir, net değil. Tipik bir boş SCP dağıtırız, yukarıda açıklanan yapılandırma değişikliklerini yaparız, birkaç belge gireriz (bu seçenekte platformun kendisi, muhasebe kaydının tüm tablolarında ayırıcı değeri koyar), ancak hatalar yeniden üretilir. Kötü, ancak muhasebe kayıtlarını genel gerekliliklerden çıkarıyoruz, test etmeye devam ediyoruz.

Ayrıca, hesaplama kayıtları için yer değiştirme mekanizmasının çalışmayı durdurduğu ortaya çıktı. Hesaplama türleri için ayrı planlar yapmadık, hesaplama kaydı tablolarında ve yeniden hesaplamalarda bir sorun aramaya çalışıyoruz. Kontrol ediyoruz, ana özelliğin değerini koyuyoruz, T&I yapıyoruz - boşuna.

Yol boyunca, liste formundan bağımsız kayıtlara bilgi yazarken sorunu teşhis ediyoruz. Bu durumda veriler kaydedilir, yeniden başlatmanın ardından görülebilirler. Sorun, test bazında yeniden oluşturulur:

Bilgi kayıtları, SQL'i manipüle ederek "onarılamaz" (ayırıcı değer tüm tablolarda ayarlanır), bu nedenle genel öznitelikten hariç tutuldular. Birkaç günlük deneyden sonra, yer değiştirmenin çalışma kapasitesini geri kazanma girişimleri de başarısız oldu.

Bu noktada veri paylaşımını kapatmaya ve RLS kullanmaya devam etmeye karar veriyoruz. Bölmeyi "kullanma" olarak ayarlarken, "Microsoft OLE DB Provider forSQL Server: CREATE UNIQUE INDEX, dizin için yinelenen bir anahtar bulunduğundan sonlandırıldı..." hatalarıyla karşılaşıyoruz. Yani ayrılıktan önceki duruma dönmek o kadar kolay değil. Yeniden hesaplama tablolarının dizinleri, toplamları saklama ayarları ve diğerleri ile ilgili sorun. Gerçek şu ki, tablolar, yalnızca ortak özniteliğin değerinde farklılık gösteren aynı satırları depolar. Ortak bir özniteliği silerken, benzersiz olmayan girişler görünür. Gereksiz kayıtları doğrudan MS SQL'de silmeniz gerekecek, bunun gibi bir şey (yeniden hesaplama tablosu için):

kullanım tabanı;
ALTER TABLE_CRgRecalc1399
ADD id INT KİMLİK(1,1);
GİT
SİL FROM_CRgRecalc1399
NEREDE kimliği< (SELECT MAX(id)
_CRgRecalc1399 AS T1'DEN
WHERE _CRgRecalc1399._RecorderTRef = T1._RecorderTRef ve
_CRgRecalc1399.[_RecorderRRef] = T1.[_RecorderRRef] ve
_CRgRecalc1399.[_CalcKindRRef] = T1.[_CalcKindRRef] ve
_CRgRecalc1399.[_Fld1400RRef] = T1.[_Fld1400RRef] ve
_CRgRecalc1399.[_Fld1401RRef] = T1.[_Fld1401RRef] ve
_CRgRecalc1399.[_Fld1402RRef] = T1.[_Fld1402RRef]
);
GİT
ALTER TABLE_CRgRecalc1399
DROP COLUMN kimliği;

Ve yalnızca birkaç düzine tabloyu temizledikten sonra veri bölümlemeyi kapatmak mümkündür. Ayırmayı kapattıktan sonra sorun yok.

3. Sonuçlar.

8.3 sorunun çözüleceğine dair bir umut vardı. Çok tembel değildik, 8.3.4.482'de kontrol ettik (devre dışı uyumluluk modu ile). Sadece genel aksesuarlar için konfigürasyon değişiklikleriyle neredeyse tipik bir SCP-shke'ye baktık. Bu test bazında, bilgi girilmeden önce bölme etkinleştirildi, yani. platformun tüm tablolara ayırıcı değerini doğru bir şekilde yazması gerekiyordu, kendi başlarına doğrudan MS SQL'e bir şey yazmadılar.

Sonuç:

"Turnovers" ve "TurnoversDtKt" sanal tablolarına yapılan sorgularla ilgili sorun yeniden oluşturuldu.

Önalım sorunu tekrarlanabilir.

Bağımsız bilgi kayıtlarına yazma sorunu yeniden üretilir.

Ayırmayı kapatma sorunu - düğmeye tek bir tıklama ile ondan kurtulmak işe yaramaz!

Böylece, RLS'yi yeni bir mekanizma ile değiştiremedik. Bu mekanizma, görünüşe göre, bulut hizmetleri için tasarlandı ve paylaşılan verilerin "bağımsız" kullanılması durumunda, belki ayırma işe yarayacak, ancak ortak bir NSI'ye ihtiyacımız var. 1C'nin hataları düzeltmesini beklemek ve daha da iyisi, standart konfigürasyonlarda kuruluşlar tarafından bölmek için tipik bir mekanizma uygulamak için kalır.

Dikkat! İşte materyalleri tamamlanmamış olabilecek dersin deneme sürümü.

Öğrenci olarak giriş yap

Okul içeriğine erişmek için öğrenci olarak oturum açın

Yeni başlayan programcılar için dahili programlama dili 1C 8.3: 1C'de biçimlendirme

1C'de programlama yaparken, genellikle (aynı raporlarda) değerleri görüntülemeniz gerekir. çeşitli tipler(dizeler, tarihler, sayılar...). Değerlerin her birinin farklı temsilleri vardır.

Örneğin, aynı tarih "01/01/2005" şu şekilde bir dize olarak gösterilebilir:

"01.01.2005"
"1 Ocak 2005"
"01.01.05"

Hepsi aynı değerin dize temsilleridir. 1C'de özel bir fonksiyonun kullanıldığı oluşumu için Biçim.

1C'de Biçim işlevini kullanma

Rakamların gruplandırılmasını devre dışı bırak

10000 sayısını yazdırmak istediğimizi varsayalım.

yazarsak:

Biçim dizgisi genellikle eşittir işaretiyle ayrılmış iki bölümden oluşur. Eşittir'in solunda ayarlanan parametrenin adı (yardıma veya örneklere bakın) ve sağda bu parametrenin değeri bulunur.

Yukarıdaki örnekte, "NG=0" biçim dizesi, NG parametresine ve 0 değerine sahiptir. Bu kombinasyon, sayının basamaklarını çözer. Ve gördüğünüz gibi, şimdi 10000 görüntüleniyor.

Baştaki sıfırları kaldırma

Bir rakamdan önce baştaki sıfırları çıkarmak da yaygın bir görevdir. Örneğin, 5 sayısını başında sıfırla, yani "05" biçiminde görüntülemek istediğinizi varsayalım:

Report(Format(5 , "FH=2; FH=" ) ) ; // çıkış 05

"FZ=2; HVN=" biçim dizesini ayrıştıralım. Noktalı virgülle ayrılmış iki biçim dizesinden oluşur. Her birini ayrı ayrı analiz edelim.

"CHT=2" dizesi şunu belirtir: toplam sayısı tamsayı ve kesirli kısımların görüntülenen ondalık basamakları. Böylece sayının çıktı alırken kaplayacağı toplam konum sayısı 2'ye eşit olacaktır.

"HVN=" dizesi, yardımdan aşağıdaki gibi, biçim işlevine, sayı belirtilen uzunluğa ulaşmazsa (bizim durumumuzda olduğu gibi, çünkü 2 konum belirledik ve 5 yalnızca birini kaplıyor), o zaman şunu belirtir: baştaki sıfırlar kullanılmalıdır. Bu biçim dizesinin özelliği, yalnızca parametre adına ve eşittir işaretine sahip olması, ancak değerinin olmamasıdır. Dersin deneme sürümünü okuyorsunuz, tam dersler yer almaktadır.

İki biçim dizgisinin birleşimi bize ihtiyacımız olan sonucu "5" yerine "05" verir.

Ondalık ayırıcıyı değiştir

Kesirli sayıları nokta yerine yıldız işaretiyle ayırmamız gerektiğini varsayalım. Yani 25.46'nın "25 * 46" olarak görüntülenmesi için:

Biçim dizesi, DF parametresi ve işlevi belirten dddd değeridir. Biçim haftanın gününün uzun bir gösterimini çıkarın (kaç tane "d" içerdiğine dikkat edin).

Bir tarihin ay gösterimi

Ayın tarihe göre açıklaması şu şekilde görüntülenir:

Rapor(Format("20050101" , "DF=MMMM" ) ) ); // Ocak'ı yazdırır

Biçim dizesi, önceki durumdakiyle aynı DF parametresine sahiptir. Ama anlamı farklıdır. Şimdi MMMM.

testi yap

Testi başlat

1. Format("19050505", "DF=MMMM") dönecektir

2. Ondalık ve tamsayı ayırıcısını ^ olarak değiştirerek dizeyi biçimlendirin

3. Biçim işlevinin 5 yerine "00005" döndürmesi için biçim dizesi uygundur

4. Biçim işlevinin 10.000 yerine "10000" döndürmesi için bir biçim dizesi

5. Format işlevi, bir tür değeri döndürür

1C'de genel aksesuarlar 8.3, birçok yapılandırma nesnesi (dizinler, belgeler, hesap planları vb.) için bir özniteliği kullanmanıza izin veren bir platform meta veri nesnesidir. Nesne, esas olarak geliştiricinin çalışmasını ve verilerin ayrılmasını kolaylaştırmak için oluşturuldu.

Genel ayrıntılar başlangıçta 1C 7.7 sürümünde uygulandı, ancak geliştiriciler bunu hemen sürüm 8'e dahil etmedi. Ortak ayrıntıların mekanizması, 1C geliştiricileri tarafından yalnızca 8.2.14 sürümünde tanıtıldı.

Konfigürasyondaki standart nesneleri değiştirmemek için genel öznitelikler eklemek çok uygundur, genellikle bunları .

Ortak bir öznitelik eklendikten sonra, sorgularda kullanılabilir ve nesneler biçiminde görüntülenebilir - dıştan, normal aksesuarlardan farklı değildir.

Ortak özniteliklerin tek sınırlaması, içinde kullanılamamasıdır.

Diğer yapılandırma nesnelerinden farklı olan ortak özniteliklerin ana ayarlarını ve özelliklerini ele alalım:

Birleştirmek— ortak özelliğin kullanılacağı nesnelerin listesi, ayar değişim planının ayarına benzer.

267 1C video derslerini ücretsiz alın:

Otomatik kullanım— ayar, kompozisyonda belirtilen "Otomatik" kullanım moduna sahip nesneler için ortak bir özniteliğin kullanılıp kullanılmayacağını belirler.

Veri ayırma Bu ayarı ayrı ayrı ele alacağız.

Ortak bir öznitelik kullanarak verilerin 1C'de ayrılması

Veri ayırma- mekanizmaya benzer bir mekanizma. Ancak, bu mekanizmanın performansı daha verimlidir ve yapılandırılması daha kolaydır.

Mekanizma, yalnızca kullanıcının görebileceği öğelerin görüntüsünü yapılandırmanıza olanak tanır. Örneğin, belirli bir organizasyonun kurulu olduğu tüm nesneleri (belgeler, dizinler vb.) ayırt edebilirsiniz.

Ortak 1C ayrıntılarını kullanarak veri ayrımını ayarlama

Genel özniteliği ayarlamak için veri ayrımını belirtmelisiniz - Bölmek. Tıkladıktan hemen sonra sistem sizden varsayılan muhasebe parametreleri oluşturmanızı isteyecektir:

Bu durumda, sistem başlangıcında oturum parametrelerinin belirtilmesi gerekecektir, bunun nasıl yapılacağı, bir örnekle makalede açıklanmıştır.

Bu, ayarı tamamlar - kullanıcı yalnızca seçilen oturum parametrelerinde belirtilen bilgilere erişebilir.

Ortak bir öznitelik kullanma örneği

1C 8.3'teki genel donanımların ayarını bir tel kafes konfigürasyonu ve donanımlar örneğini kullanarak analiz edelim. Organizasyon:

Sistemde gerekli Organizasyonun belirtilmesi gereken 3 adet belge bulunmaktadır: Bunlar Fatura, Harcama Faturası, Bordro'dur.

Kurulum basittir:

Yeni bir Genel öznitelik oluşturun, türü belirtin — DirectoryLink.Organization.
Kompozisyonda belgelerimizi düzenliyoruz - Kullanmak.

Her şey, kurulum bitti!

Sonucu görelim:

Sistem ortak özniteliği "kendisi gibi" görüntüler: hem isteklerde hem de form özniteliklerinde ve diğer yerlerde. Bu çok sihir! 🙂