nilai 1s scd. Menggunakan karakteristik di SCD. Tempat kemiskinan di gedung cerdas

Itu saja. Fungsi laporan sekarang memungkinkan Anda memilih bidang untuk karakteristik tambahan dalam laporan (bidang keluaran, pilihan, dll.). Tapi ada satu TAPI. Kita dapat menggunakan bidang ini dalam pengaturan laporan hanya dalam mode 1C:Enterprise. Di konfigurator kita tidak bisa melihat kolom karakteristik, yang logis, karena karakteristik dimasukkan oleh pengguna dan disimpan di basis informasi.

Namun jika perlu, kita bisa menambahkan kolom karakteristik, misalnya pada pilihan sebelum membukanya. Mari kita lihat contoh kecilnya.

Pekerjaan terprogram dengan karakteristik

Saat membuka formulir laporan, jalankan kode program berikut:

Pengaturan Saat Ini = Pengaturan Komposer. Pengaturan; CollectionCollection = Pengaturan Saat Ini. Pilihan. Elemen; // Tambahkan pilihan dengan tambahan. ke detail item "Gudang utama". [Gudang utama] // Tambahkan pilihan dengan tambahan. ke detail nomenklatur "Negara penempatan" NovEl = KoleksiSeleksi. Tambahkan(Jenis(" Pemilihan Tata Letak ElementData" ) ) ; NewEl.ComparisonType = DataCompositionComparisonType. Sama dengan; NewEl.LeftValue = . [Negara pengeposan]" ); NewEl. Penggunaan = Salah ; // Tambahkan pilihan dengan tambahan. ke detail item "Rekanan terkait" NovEl = KoleksiSeleksi. Tambahkan(Jenis(" Pemilihan Tata Letak ElementData" ) ); NewEl.ComparisonView = DataCompositionComparisonView. Sama dengan; NewEl.LeftValue = NewDataCompositionField("Organisasi . [Rekanan Terkait]" ); NewEl. Penggunaan = Salah ;

Kemudian jika kita melihat pilihan laporan pada mode 1C:Enterprise, kita akan melihat gambar berikut:

Oleh karena itu, kami secara terprogram menambahkan pilihan berdasarkan karakteristik tambahan dari direktori “Organisasi”, meskipun faktanya bidang ini tidak tersedia di perancang ACS. Perhatikan sintaks untuk mendefinisikan bidang komposisi data.

yaitu teks “[Linked Counterparty]”. Jika kita menulis seperti ini:

kemudian saat menjalankan laporan, ACS salah mendeteksi kolom tata letak. Dalam pengaturan, bidang pilihan akan disorot sebagai salah:

Untuk properti dan detail tambahan yang tidak tersedia di perancang ACS, saat mengakses secara terprogram, Anda harus menggunakan sintaks berikut:

Dengan demikian, kita dapat mengatur pengaturan laporan meskipun kolom tersebut tidak tersedia di desainer ACS.

Kesimpulan

Menggunakan pengaturan karakteristik di ACS dapat menyederhanakan pengembangan laporan yang kompleks secara signifikan. Meskipun ada beberapa kekurangan dalam pekerjaan, seperti kurangnya kemampuan untuk mengkonfigurasi pilihan tambahan. properti di perancang, dll., mekanisme karakteristik dapat dianggap sebagai langkah signifikan dalam menyederhanakan pengembangan laporan dalam sistem 1C:Enterprise.

Dalam artikel tersebut, kami tidak mempertimbangkan semua kemampuan karakteristik di ACS. Di luar cakupan artikel terdapat kemungkinan-kemungkinan seperti: penentuan sumber data secara sewenang-wenang, baik untuk properti maupun nilai karakteristik, serta pemilihan oleh pemilik untuk semua karakteristik yang tersedia di basis informasi, dan banyak lagi. Topiknya besar, ada ruang untuk memperluas lingkaran pengetahuan Anda.

Salah satu bidang terpenting perangkat lunak bisnis adalah pelaporan. Nasib sebuah bisnis, baik itu laporannya kantor Pajak atau diagram ketergantungan permintaan barang terhadap musim dan faktor lainnya. Sistem pelaporan yang kuat dan fleksibel yang memudahkan untuk mengekstrak data yang diperlukan dari sistem, menyajikannya dalam bentuk yang dapat dimengerti, memungkinkan pengguna akhir untuk mengkonfigurasi ulang laporan standar untuk melihat data dengan cara yang baru - ini adalah cita-cita yang setiap sistem bisnis harus diperjuangkan.

Dalam platform 1C:Enterprise, mekanisme yang disebut “Sistem Komposisi Data” (disingkat DCS) bertanggung jawab untuk menghasilkan laporan. Pada artikel kali ini kami akan mencoba memberikannya Deskripsi Singkat ide dan arsitektur mekanisme ACS dan kemampuannya.

ACS adalah mekanisme yang didasarkan pada deskripsi laporan yang bersifat deklaratif. Sistem kontrol akses dirancang untuk menghasilkan laporan dan menampilkan informasi dengan struktur yang kompleks. Omong-omong, selain mengembangkan laporan, mekanisme ACS juga digunakan di 1C:Enterprise dalam daftar dinamis, alat untuk menampilkan informasi daftar dengan fungsionalitas yang kaya (menampilkan daftar datar dan hierarki, desain baris bersyarat, pengelompokan, dll. ).

Sedikit sejarah

1. Satu atau lebih kueri ditulis dalam bahasa kueri 1C (bahasa mirip SQL, selengkapnya di bawah).
2. Kode ditulis yang mentransfer hasil kueri yang dieksekusi ke dokumen atau bagan spreadsheet. Kode juga dapat melakukan pekerjaan yang tidak dapat dilakukan dalam kueri - misalnya, menghitung nilai menggunakan bahasa bawaan 1C.

Salah satu ide yang menjadi dasar sistem kontrol akses adalah fleksibilitas dan penyesuaian laporan, yang dapat diakses oleh pengembang dan pengguna akhir. Idealnya, saya ingin memberikan pengguna akhir akses ke seperangkat alat desain laporan yang sama dengan pengembang. Adalah logis untuk membuat satu set alat yang tersedia untuk semua orang. Karena alat memerlukan partisipasi pengguna akhir, itu berarti penggunaan pemrograman di dalamnya harus dikurangi seminimal mungkin (yang terbaik adalah menghilangkannya sepenuhnya), dan pengaturan visual harus digunakan secara maksimal.

Rumusan masalah

Dua bahasa

Bahasa kueri

Sangat mudah untuk melihat analog dari bagian standar untuk kueri SQL - SELECT, FROM, GROUP BY, ORDER BY.

Pada saat yang sama, bahasa kueri berisi sejumlah besar ekstensi yang bertujuan untuk mencerminkan masalah keuangan dan ekonomi secara spesifik dan meminimalkan upaya yang diperlukan untuk mengembangkan solusi aplikasi:

• Mengakses bidang menggunakan titik. Jika bidang tabel adalah tipe referensi (menyimpan tautan ke objek tabel lain), pengembang dapat merujuknya dalam teks permintaan melalui ".", dan sistem tidak membatasi jumlah tingkat bersarang tautan tersebut (misalnya, Pesanan Pelanggan. Perjanjian. Organisasi. Telepon).
• Pembentukan hasil yang multidimensi dan bertingkat. Total dan subtotal dibentuk dengan mempertimbangkan pengelompokan dan hierarki, level dapat dilalui dalam urutan apa pun dengan penjumlahan, dan konstruksi total yang benar berdasarkan dimensi waktu dipastikan.
• Dukungan untuk tabel virtual. Tabel virtual yang disediakan oleh sistem memungkinkan Anda memperoleh data yang hampir siap pakai untuk sebagian besar tugas aplikasi tanpa perlu membuat kueri yang rumit. Dengan demikian, tabel virtual dapat menyediakan data saldo produk berdasarkan periode pada titik waktu tertentu. Pada saat yang sama, tabel virtual memanfaatkan informasi yang disimpan secara maksimal, misalnya, total yang dihitung sebelumnya, dll.
• Tabel sementara. Bahasa kueri memungkinkan Anda menggunakan tabel sementara dalam kueri. Dengan bantuan mereka, Anda dapat meningkatkan kinerja kueri, dalam beberapa kasus mengurangi jumlah pemblokiran dan membuat teks kueri lebih mudah dibaca.
• Permintaan batch. Untuk membuat bekerja dengan tabel sementara lebih nyaman, bahasa kueri mendukung pengerjaan dengan kueri batch - dengan demikian, pembuatan tabel sementara dan penggunaannya ditempatkan dalam satu kueri. Permintaan batch adalah urutan permintaan yang dipisahkan dengan titik koma (“;”). Permintaan dalam batch dieksekusi satu demi satu. Hasil dari mengeksekusi permintaan batch, bergantung pada metode yang digunakan, akan berupa hasil yang dikembalikan oleh permintaan terakhir dalam batch, atau array hasil dari semua kueri dalam batch dalam urutan yang diikuti oleh kueri dalam batch. .
• Mengambil representasi bidang referensi. Setiap tabel objek (tempat direktori atau dokumen disimpan) memiliki bidang virtual - "Tampilan". Bidang ini berisi representasi tekstual objek dan memudahkan pekerjaan pembuat laporan. Jadi, untuk sebuah dokumen, bidang ini berisi semuanya informasi kunci- nama jenis dokumen, nomor dan tanggalnya (misalnya, “Penjualan 000000003 mulai 06/07/2017 17:49:14”), sehingga pengembang tidak perlu menulis bidang terhitung.
• dan sebagainya.

Ada juga ekstensi bahasa kueri khusus untuk sistem kontrol akses. Perluasan dilakukan dengan menggunakan instruksi sintaksis khusus yang diapit kurung kurawal dan ditempatkan langsung di badan permintaan. Dengan menggunakan ekstensi, pengembang menentukan operasi apa yang dapat dilakukan pengguna akhir saat menyesuaikan laporan.

Misalnya:

• MEMILIH. Kalimat ini menjelaskan bidang yang dapat dipilih pengguna untuk keluaran. Setelah kata kunci ini, alias bidang dari daftar pilihan kueri utama yang akan tersedia untuk konfigurasi dicantumkan, dipisahkan dengan koma. Contoh: (PILIH Barang, Gudang)
• DI MANA. Bidang di mana pengguna dapat menerapkan pilihan dijelaskan. Proposal ini menggunakan kolom tabel. Penggunaan alias kolom daftar pilihan tidak diperbolehkan. Setiap bagian dari gabungan dapat memuat elemen WHERE-nya sendiri. Contoh: (WHERE Item.*, Gudang), (WHERE Document.Date >= &StartDate, Document.Date<= &ДатаКонца}
• dan sebagainya.

Bahasa Ekspresi Komposisi Data

Contoh:

Proses pembuatan laporan pada sistem kontrol akses

• teks permintaan dengan instruksi untuk sistem komposisi data;
• deskripsi beberapa kumpulan data;
• penjelasan rinci tentang bidang yang tersedia;
• menggambarkan hubungan antara beberapa kumpulan data;
• deskripsi parameter perolehan data;
• uraian tata letak dan pengelompokan lapangan;
• dan sebagainya.

Misalnya, Anda dapat menambahkan kueri ke skema komposisi data sebagai kumpulan data dan memanggil konstruktor kueri, yang memungkinkan Anda membuat kueri dengan kompleksitas arbitrer secara grafis:

Hasil peluncuran perancang kueri akan menjadi teks kueri (dalam bahasa kueri 1C:Enterprise). Teks ini dapat disesuaikan secara manual jika perlu:

Mungkin terdapat beberapa kumpulan data dalam skema tata letak data, kumpulan data dapat ditautkan dalam tata letak dengan cara apa pun, bidang terhitung dapat ditambahkan, parameter laporan dapat ditentukan, dll. Perlu disebutkan fitur menarik dari mekanisme kueri di 1C:Enterprise. Kueri pada akhirnya diterjemahkan ke dalam dialek SQL khusus untuk DBMS yang digunakan aplikasi untuk beroperasi secara langsung. Secara umum, kami mencoba menggunakan kemampuan server DBMS secara maksimal (kami dibatasi oleh fakta bahwa kami hanya menggunakan kemampuan yang tersedia secara bersamaan di semua DBMS yang didukung oleh platform 1C:Enterprise - MS SQL, Oracle, IBM DB2 , PostgreSQL). Jadi, pada tingkat kueri di bidang terhitung, kita hanya bisa menggunakan fungsi yang diterjemahkan ke dalam SQL.

Namun pada tingkat skema komposisi data, kami sudah dapat menambahkan bidang khusus dan menggunakan fungsi di dalamnya dalam bahasa pengembangan 1C bawaan (termasuk yang kami tulis), yang sangat memperluas kemampuan laporan. Secara teknis, tampilannya seperti ini - segala sesuatu yang dapat diterjemahkan ke dalam SQL diterjemahkan ke dalam SQL, kueri dieksekusi di tingkat DBMS, hasil kueri ditempatkan di memori server aplikasi 1C dan SKD menghitung nilai untuk setiap catatan ​​bidang kalkulasi yang rumusnya ditulis dalam bahasa 1C.

Menambahkan Bidang Kustom

Anda dapat menambahkan tabel dan diagram dalam jumlah berapa pun ke laporan:

Perancang laporan

Laporan waktu proses

Dengan menggunakan SKD, pengguna dapat menambahkan pilihan kompleks ke laporan (yang akan ditambahkan ke permintaan di tempat yang tepat), desain bersyarat (memungkinkan bidang yang ditampilkan diformat secara berbeda - dengan font, warna, dll., bergantung pada nilainya ) dan banyak lagi. .

Proses pembuatan dan pembuatan laporan dapat dijelaskan secara singkat sebagai berikut:

• Pengembang dalam waktu desain dengan bantuan seorang desainer (atau saat runtime menggunakan kode) menentukan skema tata letak data:
  • Teks permintaan/permintaan
  • Deskripsi bidang terhitung
  • Hubungan antar permintaan (jika ada beberapa)
  • Opsi Laporan
  • Pengaturan bawaan
  • Dll.
• Pengaturan di atas disimpan dalam tata letak
• Pengguna membuka laporan
  • Mungkin membuat pengaturan tambahan (misalnya, mengubah nilai parameter)
  • Klik tombol "Hasilkan".
• Pengaturan pengguna diterapkan pada skema komposisi data yang ditentukan oleh pengembang.
• Tata letak komposisi data perantara dibentuk, berisi instruksi dari mana menerima data. Secara khusus, kueri yang ditentukan dalam tata letak disesuaikan. Dengan demikian, kolom yang tidak digunakan dalam laporan akan dihapus dari permintaan (hal ini dilakukan untuk meminimalkan jumlah data yang diterima). Semua bidang yang berpartisipasi dalam rumus bidang terhitung ditambahkan ke kueri.
• Pemroses komposisi data ikut berperan. Pemroses tata letak mengeksekusi kueri, menautkan kumpulan data, menghitung nilai untuk bidang terhitung dan sumber daya, dan melakukan pengelompokan. Singkatnya, ini membuat semua perhitungan yang tidak dilakukan pada tingkat DBMS.
• Pemroses keluaran data meluncurkan permintaan eksekusi dan menampilkan data yang diterima dalam dokumen spreadsheet, bagan, dll.

Proses pembuatan laporan menggunakan mekanisme ACS

Kami mencoba meminimalkan jumlah data laporan yang ditransfer dari server ke aplikasi klien. Saat menampilkan data dalam dokumen spreadsheet, saat membuka dokumen spreadsheet, kami mentransfer dari server hanya baris-baris yang dilihat pengguna di awal dokumen. Saat pengguna berpindah sepanjang baris dokumen, data yang hilang diunduh dari server ke klien.

Pengaturan Kustom

• Akses cepat. Pengaturan akan ditampilkan langsung di bagian atas jendela laporan.
• Biasa. Pengaturan akan tersedia melalui tombol “Pengaturan”.
• Tidak tersedia. Pengaturan ini tidak akan tersedia untuk pengguna akhir.

Mengatur mode tampilan dalam waktu desain

Tampilkan pengaturan dalam mode Akses Cepat saat runtime (di bawah tombol Hasilkan)

Rencana pembangunan

Di perancang kueri, saat dipanggil dari formulir penyiapan sumber data, untuk skema komposisi data. Ada tab “karakteristik”, yang penggunaannya tidak dijelaskan dengan jelas dalam dokumentasi. Pada artikel kali ini saya akan mencoba menjelaskan bagaimana dan mengapa karakteristik digunakan pada ACS.

Konfigurasi tipikal secara aktif menggunakan mekanisme properti dan nilai properti, tersedia untuk hampir semua objek. Secara primitif, dalam buku referensi, mekanisme ini diimplementasikan dalam konfigurasi 7.7. Sekarang mekanisme ini diimplementasikan dengan menggunakan rencana tipe karakteristik dan register informasi, namun idenya tetap sama.

Ketika saya pertama kali menghadapi kebutuhan untuk menggunakan mekanisme ini dalam skema kontrol akses, saya berjuang untuk waktu yang sangat lama, mengatur kueri bersarang, menggabungkannya ke pilihan utama dan memikirkan bagaimana memperhitungkan kemungkinan munculnya jenis properti baru yang belum ada pada saat pengembangan laporan. Seluruh mekanisme properti, yang sederhana dan logis dari sudut pandang pengguna, tidak dapat diproses secara normal sampai saya menemukan tab "Karakteristik".

Tabel pada tab sangat berubah-ubah, baik Anda memasukkan seluruh baris dengan benar, atau menolak memasukkan baris sama sekali; sistem tidak akan mengizinkan Anda meninggalkan baris yang tidak terisi lengkap "untuk nanti".

Jadi, mari kita bahas secara spesifik. Kolom pertama: Jenis– disini kita pilih jenis objek yang akan dilampirkan ciri-cirinya, misalnya “DirectoryLink.Nomenclature”

Ini berarti bahwa sekarang dimungkinkan untuk memperoleh nilai properti untuk semua objek dari tipe yang ditentukan.

Selanjutnya di kolom berikutnya Sumber spesies kita harus mengatur parameter sumber tampilan properti. Opsi yang memungkinkan meja M meminta, mengapa kita memerlukan pilihan? meminta Saya akan memberitahu Anda nanti, sekarang mari kita pilih item meja.

Dalam sebuah kolom Jenis karakteristik kita harus memilih tabel infobase di mana jenis karakteristik yang diperlukan disimpan, dalam contoh kita adalah “Rencana Jenis Karakteristik.Properti Objek”.

Selanjutnya, nilai-nilai yang tersedia bagi kita untuk dipilih di kolom Bidang kunci, Bidang nama Dan Bidang tipe nilai, bergantung langsung pada bidang tabel yang kita pilih. DI DALAM Bidang kunci kami memilih Tautan, V Bidang nama – Pertunjukan(pengguna akan melihatnya sebagai nama atribut), dan masuk Ketik bidang masing-masing TipeNilai.

Sekarang mari kita beralih ke sumber nilai. Sumber nilai kita adalah register informasi “ObjectPropertyValues”, jadi kita pilih di kolom Sumber nilai – meja, dan di kolom Nilai Atribut– “Daftar Informasi.Nilai Properti Objek.” Di kolom Sebuah Objek, Properti, Arti, pilih bidang register yang sesuai Sebuah Objek, Properti, Arti.

Tampaknya itu saja. Kami pergi ke pengaturan skema, menambahkan pengelompokan berdasarkan produk, dan menambahkan pengelompokan bawahan, misalnya berdasarkan Merek, kami memiliki properti seperti itu.

Kami memperluas daftar detail grup Tata Nama dan... kami tidak melihat properti apa pun di sana:

Faktanya adalah kita berada di konfigurator, dari mana tidak ada akses ke data. Bagaimana cara membuat pengaturan yang diperlukan? Cara paling mudah untuk melakukan ini adalah dengan menggunakan konsol komposisi data, yang ada di disk ITS, atau yang termasuk dalam subsistem “Alat Pengembang”. Tapi Anda cukup membuka pengaturan laporan dalam mode perusahaan.

Jadi, mari kita buka pengaturan yang sama, tetapi dalam mode perusahaan:

Seperti yang Anda lihat, kami telah menambahkan “Detail” baru, dan properti “ Merek” secara lahiriah tidak berbeda dengan detail direktori biasanya. Dan properti “ Tipe produk” berada dalam tanda kurung siku karena representasi propertinya mengandung spasi.

Namun, kami juga memiliki properti “ Jenis perjanjian” yang ditautkan ke direktori “ Perjanjian” dan tidak ada hubungannya dengan “ Tata nama“. Jika tidak digunakan dalam pengaturan “ Jenis perjanjian” maka semuanya akan berfungsi dengan benar, tetapi jika Anda memilihnya, hasilnya akan menjadi tidak terisi, karena tidak ada satu pun item dalam nomenklatur yang properti ini benar-benar terisi. Namun bagaimana Anda bisa memfilter properti yang tidak perlu agar tidak mengganggu Anda?

Untuk melakukan ini, kita perlu mengubah pengaturan sumber tampilan di perancang kueri, pada tab “Karakteristik”. Ingat, di awal artikel saya berjanji untuk memberi tahu Anda mengapa jenis sumber tampilan diperlukan meminta? Sekarang adalah kasus seperti itu. Ubah jenis sumber tampilan menjadi meminta. Di kolom jenis karakteristik, klik tombol “[...]” dan jendela perancang kueri baru akan terbuka.

Masukkan kueri berikut di sana:

MEMILIH
Properti Objek.Ref.
Properti Objek.Nama + “(properti)” SEBAGAI Nama,
Properti Objek.TypeValues
DARI
Rencana Jenis Ciri Sifat Benda SEBAGAI Sifat Benda
DI MANA
Properti Objek Tujuan Properti = NILAI (Rencana Jenis Karakteristik. Tujuan Properti Kategori Objek. Direktori_Nomenklatur)
DAN (BUKAN ObjectProperties.DeletionMark)
DAN (BUKAN ObjectProperties.Category)

Di kolom Bidang kunci, Bidang nama Dan Bidang tipe nilai, pilih bidang pilihan yang sesuai: Tautan, Nama Dan TipeNilai. Ini akan menjadi seperti ini:

Sekarang, saat kita melanjutkan ke pengaturan laporan, gambar di daftar detail Nomenklatur akan berubah:

Sekarang produk hanya memiliki properti yang ditetapkan padanya, terlebih lagi, sekarang sangat berbeda dari detail biasanya, berkat catatan tambahan (Properti), yang kami tambahkan ke nama properti dalam permintaan.

Itu saja, tetapi banyak yang mungkin bingung dengan ketidakmungkinan mengaturnya di konfigurator. Sebenarnya tidak ada yang salah dengan hal itu. Cukup dengan menyimpan pengaturan (atau seluruh rangkaian) ke file dan memulihkannya di konfigurator.

Konfigurator akan menampilkan detail yang tidak dipahami dengan tanda silang merah sebagai tidak tersedia:

Namun hal ini tidak lagi menakutkan, karena laporan dengan pengaturan seperti itu dapat disimpan dalam konfigurasi dan akan berfungsi dengan baik saat dibuka oleh pengguna.