rumah » Gaya dan mode » Tunjukkan waktu dan batasan, tujuan, contoh penggunaan. Jalan keluar dari situasi ini

Tunjukkan waktu dan batasan, tujuan, contoh penggunaan. Jalan keluar dari situasi ini

Untuk pelaksana yang bekerja dengan standar atau konfigurasinya sendiri - dan mereka yang sedang mempersiapkan Sertifikasi di 1C: Spesialis Platform.

Pada artikel ini kita akan melihat:

Bagaimana gunakan kunci terkelola dengan benar untuk pemrosesan dokumen operasional dan non-operatif
apa yang bisa ditimbulkannya tidak ada pemblokiran
bagaimana cara menghindari kesalahan yang tidak segera diketahui dan dapat berakibat serius :)

Waktu membaca: 20 menit.

Jadi, dua metode untuk mengendalikan saldo di 1C:Enterprise 8.3

Mari kita mulai dengan fakta bahwa sebutan “metode lama” dan “metode baru” cukup sewenang-wenang. Padahal, kalau “teknik baru” sudah digunakan sejak 2010, itu bukan lagi hal baru :)

Namun, kami sekali lagi terpaksa berhenti di sini, karena kita perlu membedakan antara pendekatan-pendekatan ini dan hal ini sangat penting.

“Metode lama” adalah pendekatan pengendalian residu yang telah digunakan sejak 1C:Enterprise 8.0.

Sejak tahun 2010, dengan pengembangan platform dan penambahan kemampuan baru dengan 1C:Enterprise 8.2, “metodologi baru” telah diterapkan ( namun - tidak di semua tempat).

Apa bedanya?

Perbedaan mendasar terletak pada momen penguasaan residu:

Dalam metode “lama”, saldo dikontrol SEBELUM mencatat pergerakan di register.
Pertama, kami memeriksa saldo; jika saldo “tidak cukup” (akan timbul saldo negatif), kami tidak akan memposting dokumen
Dalam metode “baru”, kontrol terjadi SETELAH perekaman gerakan, yaitu setelah kejadian.
Jika setelah eksekusi saldo negatif terbentuk, Anda perlu “memutar kembali” transaksi, yaitu membatalkan dokumen.

Keuntungan dan kerugian dari teknik baru ini dibahas secara rinci dalam artikel terpisah, jadi kami akan membatasi diri hanya pada tesis umum - teknik baru ini lebih optimal dari segi kinerja dan skalabilitas.

Oke, jadi teknik lama sudah ketinggalan zaman dan inilah takdir UT 10.3?

Tidak, itu tidak sepenuhnya benar.

Metodologi baru ini dapat digunakan pada saat penghapusan barang semua data yang diperlukan ada dalam dokumen dan tidak perlu dihitung.

Misalnya, bila jumlah yang akan dihapuskan diketahui dari bagian tabel dokumen. Masalah muncul pada harga biaya, karena perlu dihitung sebelum menulis ke register, yaitu mengeksekusi query ke database.

Oleh karena itu, metodologi baru ini dapat berhasil diterapkan jika data kuantitas dan biaya disimpan dalam register terpisah.

Misalnya seperti ini:

Namun, ada konfigurasi di mana kuantitas dan biaya diperhitungkan dalam register yang sama. Dan di sini hal itu dibenarkan metode pengendalian residu yang lama masih berfungsi!

Berikut adalah contoh satu register untuk kuantitas dan biaya:

Bagaimana dengan konfigurasi tipikal? Itu hanya teknik baru, bukan?

Tidak selalu!

Misalnya di “1C: Trade Management 11.3” ada 2 register:

Saat memposting dokumen pengiriman, register “Harga Barang” tidak diisi sama sekali. Data masuk ke register ini hanya ketika melakukan operasi rutin untuk menutup bulan.

UT 11 menggunakan teknik baru, karena semua data untuk pemrosesan dokumen dapat diperoleh tanpa mengakses register terkontrol.

Sedangkan untuk “1C: Accounting”, baik kuantitas maupun biaya disimpan di sana dalam satu register departemen akuntansi, pada akun akuntansi yang sesuai.

Itu sebabnya BP 3.0 menggunakan teknik lama.

Harap dicatat bahwa akuntansi kuantitatif dan biaya di UT 11 dilakukan dengan analisis yang berbeda. Misalnya, biaya juga dikelola oleh organisasi, divisi, manajer, jenis kegiatan, PPN, dan sebagainya.

Pada artikel ini, kami akan menganalisis pemblokiran untuk metode lama dan baru dalam mengontrol saldo.

Tentang pemrosesan dokumen yang cepat

Seringkali ada kesalahpahaman tentang pertanyaan sederhana ini.

Kadang-kadang diyakini bahwa pelaksanaan operasional adalah pengendalian saldo teknik baru. Ini tidak benar, dari kata “sama sekali”.

Kinerja operasional dapat dianalisis sambil memantau residu, namun hal ini tidak diperlukan.

Implementasi operasional– ini adalah kemampuan dokumen untuk mencatat kejadian yang muncul di sini dan saat ini, yaitu secara real time.

Itu dikonfigurasi menggunakan properti dokumen khusus:

Apa yang dimaksud dengan “mendaftar di sini dan sekarang”? Platform untuk dokumen yang diproses dengan cepat melakukan sejumlah tindakan:

Dokumen yang diposting hari ini diberi waktu saat ini
Jika dua dokumen diposting secara bersamaan, masing-masing akan memiliki waktunya sendiri (yaitu, sistem akan memberi jarak pada dokumen dalam detik yang berbeda)
Dokumen tidak dapat diposting di masa mendatang.

Tapi yang utama adalah sistemnya mentransmisikan tanda efisiensi dokumen untuk diproses:

Untuk dokumen yang segera diposting, Anda tidak dapat menentukan parameter dalam permintaan; saldo saat ini akan diperoleh pada tanggal 31 Desember 3999:

Saldo saat ini disimpan dalam sistem dan diperoleh secepat mungkin (saldo untuk tanggal lain biasanya diperoleh dengan perhitungan).

Dengan demikian implementasi operasional dapat diadopsi baik untuk metode pengendalian residu yang lama maupun yang baru.

Fakta yang menarik.

Dalam UT 11, penghapusan dokumen nomenklatur dilarang dilakukan secara segera. Misalnya, dokumen “Penjualan barang dan jasa”, “Perakitan barang”, “Pergerakan barang”, “Konsumsi barang dalam negeri” dan lain-lain.

Mengapa hal ini dilakukan?

Dalam sistem, kontrol keseimbangan selalu dilakukan pada titik waktu saat ini (parameter Periode tidak ditentukan dalam permintaan). Dan kurangnya eksekusi operasional memungkinkan Anda memasukkan dokumen di masa depan, tugas seperti itu sering kali diminta oleh klien.

Kontrol saldo menggunakan metode baru - tanpa pemblokiran

Mari kita pertimbangkan secara singkat algoritma untuk mengendalikan saldo saat menjalankan dokumen “Penjualan barang dan jasa” menggunakan konfigurasi model.

Ada dua register:

Saldo yang tersedia – untuk akuntansi kuantitatif
Harga pokok barang – untuk akuntansi biaya

Untuk mengontrol saldo produk, cukup bekerja dengan register “Saldo Gratis”.

Kode pemrosesan postingan akan terlihat seperti ini:

Permintaan = Permintaan Baru;

#Area Area1
Query.TemporaryTableManager = NewTemporaryTableManager;
#Area Akhir

// 4. Merekam pergerakan di database
#Area Area4
Pergerakan.Rekam();
#Area Akhir

#WilayahWilayah6
Momen Sisa Kendali =
?(Mode = Mode Penyimpanan Dokumen. Operasional,
Belum diartikan,
Batas Baru(TimePoint(), BorderType.Termasuk));
Request.SetParameter("Momen Waktu", Momen Kontrol yang Tersisa);
RequestResult = Permintaan.Eksekusi();
#Area Akhir

#WilayahWilayah7
Jika BUKAN Hasil Kueri.Kosong() Lalu
Menolak = Benar;
ErrorSelect = Hasil Kueri.Pilih();
Sementara SelectErrors.Next() Loop
Message.Text = "Kuantitas produk tidak mencukupi: "+SelectionErrors.Shortage;
Message.Field = "Produk["+(ErrorSelection.LineNumber-1)+"].Quantity";
Pesan.Pesan();
Siklus Akhir;
berakhir jika;
#Area Akhir

#Wilayah Wilayah8
Jika Gagal Maka
Kembali;
berakhir jika;
#Area Akhir

Akhir Prosedur

Mari kita pertimbangkan poin-poin penting dari algoritma kontrol sisa.

1. Menginisialisasi pengelola tabel sementara

Manajer akan diperlukan agar tabel sementara yang dibuat dalam kueri tersedia di kueri berikutnya.

Dengan demikian, data dari bagian tabel diperoleh satu kali, disimpan dalam tabel sementara dan kemudian digunakan berulang kali.

2. Kueri mengelompokkan data tabular

Kueri memilih data yang dikelompokkan dari bagian tabel.

Harap dicatat bahwa nomor baris dokumen juga dipilih - ini diperlukan untuk mengkontekstualisasikan pesan kesalahan. Untuk nomor baris, fungsi agregat MINIMUM() digunakan - yaitu, pesan akan dikaitkan ke baris pertama tempat nomenklatur yang ditentukan muncul.

Permintaan pertama dalam batch membuat tabel sementara. Dalam kueri kedua, data tabel sementara dipilih dan 2 bidang yang diperlukan untuk setiap entri register ditambahkan - Periode dan Jenis Pergerakan.

Keuntungan dari pendekatan ini:

Tidak perlu melakukan pra-pembersihan, yaitu menggunakan metode Clear()
Tidak perlu mengatur loop berdasarkan pilihan atau bagian tabel.

Omong-omong, pendekatan serupa digunakan dalam konfigurasi standar, khususnya di UT 11 dan BP 3.0.

4. Merekam pergerakan di database

Perekaman dapat dilakukan dengan satu perintah (bukan dua) - Movements.FreeRemains.Record().

Dan dalam kasus kami, ketika satu register ditulis, tidak akan ada perbedaan.

Namun pendekatan ini lebih universal:

Pertama-tama atur bendera Rekam kit yang diperlukan mendaftarkan entri
Kemudian panggil metode Write() dari koleksi Movement, yang menulis semua set dengan flag Write yang disetel ke database

Setelah menjalankan perintah “Movements.Record()”, flag Record untuk semua set akan disetel ulang ke False.

Anda juga perlu mengingat bahwa pada akhir transaksi (setelah Pasca Pemrosesan), sistem akan secara otomatis menulis ke database hanya kumpulan catatan yang tanda Tulisnya disetel ke True.

Solusi tipikal menggunakan skema serupa untuk merekam pergerakan. Mengapa?

Metode Write() dari kumpulan Gerakan menulis kumpulan rekaman dalam urutan yang sama, bahkan untuk dokumen berbeda.

Merekam gerakan secara manual dapat menimbulkan masalah.

Mari kita beri contoh.

Jika Anda menulis di dokumen “Implementasi” seperti ini:

Pergerakan.FreeRemainders.Write();
...
Pergerakan.Harga Barang.Tulis();

Dan dalam dokumen "Pergerakan barang" ubah urutannya:

Gerakan. Biaya Barang.Write();
...
Gerakan. FreeRemainings.Write();

Hal ini dapat menyebabkan kebuntuan dokumen pada kumpulan item yang berpotongan.

Pendekatan perekaman gerakan di atas dapat digunakan jika nilai rekaman gerakan yang sesuai ditentukan dalam properti dokumen:

5. Permintaan menerima saldo negatif

Permintaan tersebut memilih saldo negatif berdasarkan item dari dokumen.

Saldo negatif adalah kekurangan (shortage) suatu produk.

Koneksi ke item dari dokumen dilakukan hanya untuk mendapatkan nomor baris.

Jika kami tidak berencana untuk menghubungkan pesan ke bidang dokumen, kueri dapat disederhanakan secara signifikan - data akan diperoleh dari satu tabel (sisa register).

6. Menentukan titik waktu untuk mengendalikan residu

Di sinilah eksekusi operasional berguna.

Apabila pendokumentasian dilakukan dengan segera, maka saat penerimaan saldo Belum Ditentukan, artinya penerimaan saldo lancar.

Jika ini adalah eksekusi non-operatif, maka kita mendapatkan titik waktu "setelah" dokumen - untuk memperhitungkan pergerakan yang baru saja dilakukan.

Izinkan kami mengingatkan Anda bahwa memperoleh saldo saat ini adalah operasi yang cepat dibandingkan dengan memperoleh saldo pada waktu yang berubah-ubah.

Inilah manfaat dari dokumen yang segera dieksekusi.

7. Jika request tidak kosong berarti ada saldo negatif

Dalam perulangan, kita menelusuri semua sisa negatif dan menampilkan pesan yang dilampirkan pada baris bagian tabel.

Seperti inilah tampilan pesan diagnostiknya:

8. Jika ada kesalahan, maka kembalikan dari event handler

Jika setidaknya ada satu kesalahan, kami keluar dari prosedur.

Karena tidak ada gunanya melanjutkan transaksi, transaksi tersebut tidak akan dicatat (dan kemudian kami akan mengembangkan kode untuk menghapus batch).

Pelaksanaan penghapusan biaya secara batch

Setelah pengecekan saldo berhasil, Anda dapat mulai menghapus batch.

Kode penghapusan FIFO akan seperti ini:

// I. Analisis pergeseran tanggal dokumen ke depan

DAN BUKAN Objek Ini.IniBaru()
Dan Objek Ini. Dilakukan Lalu

Permintaan = Permintaan Baru;
Permintaan.Teks =
"MEMILIH
| Dokumen.Tanggal SEBAGAI Tanggal
|DARI
|DIMANA

RequestResult = Permintaan.Eksekusi();
PilihDokumen.Berikutnya();

Jika tidak
Berbohong);
berakhir jika;

Akhir Prosedur

Prosedur Saat Merekam (Penolakan)

Objek Ini.Properti Tambahan.Sisipkan("DocumentDateMovedForward",
Objek Ini.Tanggal>

berakhir jika;

Akhir Prosedur

Prosedur Pemrosesan (Kegagalan, Mode)

Permintaan = Permintaan Baru;

// 1. Inisialisasi pengelola tabel sementara
#Area Area1
...
#Area Akhir

// 2. Kueri mengelompokkan data tabel
#Area Area2
...
#Area Akhir

// 4. Merekam pergerakan di database
#Area Area4
...
#Area Akhir

// 5. Permintaan menerima saldo negatif
#WilayahWilayah5
...
#Area Akhir

// 6. Menentukan titik waktu untuk mengontrol saldo
#WilayahWilayah6
...
#Area Akhir

// 7. Jika permintaan tidak kosong, maka telah terbentuk saldo negatif
#WilayahWilayah7
...
#Area Akhir

// 8. Jika ada kesalahan, kembalikan dari event handler
#Wilayah Wilayah8
...
#Area Akhir

// II. Mempersiapkan kumpulan catatan untuk register "Harga Barang".
#Area AreaII

Pergerakan.Rekam();
berakhir jika;
Pergerakan.Harga Barang.Catatan = Benar;
#Area Akhir

// IV. Siklus berdasarkan nomenklatur dokumen
#AreaAreaIV

// V. Dapatkan jumlah yang akan dihapuskan
//VI. Siklus batch oleh FIFO
Sementara SelectionBatch.Next() Dan RemainingWrite>0 Loop
// VII. Periksa saldo nol
Jika SampleBatch.QuantityRemaining=0 Lalu
Melanjutkan;
berakhir jika;
Pergerakan.Periode = Tanggal;

// VIII. Perhitungan jumlah dan jumlah yang akan dihapuskan

// IX. Kami akan mengurangi jumlah yang harus dihapuskan
Siklus Akhir;
Siklus Akhir;
#Area Akhir

Akhir Prosedur

Mari kita lihat poin-poin penting dari algoritma untuk menghapus batch menggunakan FIFO.

I. Analisis pergeseran tanggal dokumen ke depan

Di sini kami memahami apakah tanggal dokumen yang diposting bergerak maju. Informasi ini akan berguna di bawah ini saat membersihkan gerakan.

Untuk menganalisis pergeseran tanggal dokumen, diperlukan 2 peristiwa:

Sebelum merekam– untuk mendapatkan tanggal lama dokumen dan memeriksa mode posting dokumen
Saat merekam– untuk mendapatkan tanggal dokumen baru

Kami mentransfer data antar peristiwa melalui kumpulan objek khusus – “Properti Tambahan”. Itu ada selama versi objek saat ini ada di memori, yaitu tersedia untuk semua peristiwa selama eksekusi.

Teknik serupa digunakan dalam standar “1C: Accounting 8”. Namun ada satu acara yang digunakan “Sebelum merekam”.

Mengapa tidak perlu menggunakan “Saat merekam” di BP?

Sederhana saja - dokumen pengiriman tidak bisa segera diproses di bagian akuntansi. Artinya waktu pembuatan dokumen tidak mendapat stempel operasional (jika dokumen diposkan ulang pada hari ini), sehingga baik tanggal lama maupun tanggal baru dokumen dapat diperoleh pada acara “Sebelum pencatatan”.

II. Mempersiapkan kumpulan catatan untuk register “Harga Barang”.

Mode penghapusan gerakan diatur untuk dokumen – “Saat posting dibatalkan”:

Dengan demikian, ada kemungkinan saat melakukan repost, kita bisa memperhitungkan pergerakan dokumen itu sendiri. TAPI ini hanya akan terjadi jika tanggal dokumen digeser ke depan. Artinya, masuk akal untuk menghapus pergerakan hanya ketika tanggal dokumen digeser ke depan.

Berikut ini contohnya:

Saldo monitor LG pada saat dokumen adalah 10 pcs.
Sebuah dokumen diposting yang menghapus 8 pcs.
Di dokumen yang sama, waktunya bertambah 1 menit, mari kita ulangi

Jika perpindahan lama tidak dihapus, sistem akan melaporkan kekurangan 6 monitor, karena perpindahan dokumen saat ini telah menghapus 8 dari 10 monitor yang tersedia.

Catatan. Terkadang ada saran - untuk menghilangkan gerakan hanya selama operasi.

Tapi ini salah: mereka tidak akan memperhitungkan situasi perubahan dokumen “non-operatif” (kemarin dan sebelumnya).

Artinya, masalah “kekurangan 6 monitor” (lihat di atas) dalam hal ini hanya akan diselesaikan untuk dokumen yang diubah hari ini.

AKU AKU AKU. Permintaan yang menerima saldo batch untuk dihapuskan menggunakan FIFO

Dalam permintaan tersebut, kami merujuk pada saldo berdasarkan batch, dan pada saat yang sama kami menempatkan total berdasarkan item.

Pada tingkat total, diperoleh jumlah dari dokumen - MAKSIMUM(Jumlah) dan saldo batch - SUM(JumlahTersisa).

Apakah menurut Anda jumlah dari dokumen tersebut dapat melebihi total saldo barang untuk semua batch?

Jika pergerakan dalam register “Sisa Bebas” dan “Harga Harga Barang” berdasarkan kuantitas dilakukan secara serempak (baik masuk maupun keluar), maka situasi seperti itu tidak dapat muncul. Inilah yang akan kami andalkan saat menghapus banyak.

IV. Siklus berdasarkan nomenklatur dokumen

Berkat hasil kueri di loop luar, kami mengabaikan nomenklatur dari dokumen.

V. Dapatkan jumlah yang akan dihapuskan

Mari kita ingat berapa banyak yang perlu Anda hapus. Selanjutnya jumlah ini akan berkurang.

VI. Siklus batch oleh FIFO

Siklus bersarang akan berisi kumpulan berdasarkan item saat ini.

VII. Periksa saldo nol

Secara umum, situasi ketika saldo batch nol adalah kesalahan dalam data sistem (meskipun demikian, situasi seperti itu mungkin terjadi). Intinya adalah dalam hal ini jumlahnya BUKAN nol (tabel virtual saldo register tidak mengembalikan catatan dengan nilai sumber daya nol).

Oleh karena itu, kami memutuskan untuk melewatkan permainan yang salah tersebut. Jika diinginkan, Anda dapat memberikan diagnostik kepada pengguna.

VIII. Perhitungan jumlah dan jumlah yang akan dihapuskan

Jumlah yang harus dihapuskan adalah nilai minimum antara sisa batch dan sisa yang harus dihapuskan.

Jumlahnya dihitung dengan proporsi dasar.

Jika seluruh saldo suatu batch dihapuskan, maka seluruh jumlah batch tersebut akan dihapuskan. Ini matematika kelas 3 di sekolah paroki: X*Y/X = Y :)

Artinya, TIDAK perlu melakukan pemeriksaan tambahan (terkadang mereka memberikan saran seperti itu) untuk memastikan bahwa seluruh jumlah telah dihapuskan. Nasihat ini bahkan memiliki namanya sendiri - “ masalah uang receh».

Dan bagi mereka yang memberikan nasihat buruk, masuk akal untuk melihat konfigurasi “1C: Accounting 8”. Di sana (oh, ngeri!) tidak ada pemeriksaan bahwa seluruh batch telah dihapuskan :)

Berikut screenshot modul umum “Akuntansi Barang” metode “Penghapusan Sisa Barang”:

IX. Kami akan mengurangi jumlah yang harus dihapuskan

Anda perlu memahami berapa banyak yang tersisa untuk dihapuskan. Untuk melakukan ini, kurangi kuantitas dari pergerakan register.

Mengapa kunci terkelola diperlukan?

Di sini kita sampai pada pemblokiran terkontrol.

Tampaknya algoritma yang disajikan di atas bekerja seperti jarum jam. Anda dapat mengujinya sendiri (link ke download database di akhir artikel).

Namun selama operasi multi-pengguna yang sebenarnya, masalah akan dimulai, dan, seperti yang sering terjadi, masalah tidak akan segera terdeteksi...

Mari kita beri contoh masalah paling umum saat menghapus suatu barang, ketika 2 pengguna hampir secara bersamaan mencoba menghapus suatu barang (melakukan penjualan):

Dalam contoh ini, dua pengguna hampir secara bersamaan melakukan penjualan barang - dokumen No. 2 mulai dilakukan sedikit lebih lambat dari dokumen 1.

Setelah menerima saldo, sistem melaporkan bahwa saldo berjumlah 10 unit, dan kedua dokumen berhasil diproses. Akibat mirisnya, stok monitor LG hanya minus 5.

Namun pada saat yang sama, pengendalian residu berfungsi! Artinya, jika dokumen No. 2 diposting setelah akhir dokumen No. 1, sistem tidak akan memposting dokumen No. 2:

Terkadang ada kesalahpahaman - “Hanya 3-4 pengguna yang bekerja di database saya pada saat yang sama, kemungkinan pemrosesan dokumen secara paralel adalah nol, jadi Anda tidak perlu terganggu oleh pemblokiran.”

Ini sangat alasan yang berbahaya.

Bahkan dua pengguna dapat memposting dokumen hampir secara bersamaan, misalnya jika salah satu dari mereka melakukan pengeposan dokumen secara berkelompok.

Selain itu, Anda tidak bisa kebal terhadap peningkatan jumlah pengguna. Jika bisnisnya berkembang pesat, maka dibutuhkan tenaga penjualan baru, penjaga toko, ahli logistik, dan sebagainya. Oleh karena itu, Anda perlu segera membuat solusi yang akan bekerja secara stabil di lingkungan multi-pengguna.

Bagaimana mengatasi masalah saat memposting dokumen secara paralel?

Solusinya sederhana - blokir monitor LG pada waktu T1, sehingga transaksi lain tidak dapat mengakses saldo produk ini.

Kemudian pada waktu T2 sistem akan menunggu monitor LG dibuka kuncinya. Dan setelah itu, sistem akan menerima saldo barang saat ini dan penghapusan barang akan selesai (atau tidak selesai).

Sekadar beberapa kata tentang klasifikasi pemblokiran.

Ada 2 jenis kunci:

Obyek
Transaksional.

Sederhananya, kunci objek tidak mengizinkan secara interaktif mengubah satu objek (elemen direktori atau dokumen) untuk dua pengguna.

Dan kunci transaksi memungkinkan secara terprogram beroperasi dengan data saat ini ketika melakukan pergerakan melintasi register.

Pada artikel ini kita akan tertarik pada kunci transaksional, lalu kunci saja.

Kapan pemblokiran harus diterapkan?

Tugas mengatur kunci menjadi relevan segera setelah database dimulai bekerja lebih dari satu pengguna.

Penguncian perlu dilakukan pada transaksi, tetapi kapan transaksi terjadi? Benar sekali, kasus yang paling umum adalah pemrosesan dokumen.

Artinya, pemblokiran harus diterapkan saat memproses semua dokumen?

Sama sekali tidak. Jelas tidak ada gunanya memasang kunci “untuk berjaga-jaga.”. Bagaimanapun, kunci itu sendiri mengurangi konkurensi pengguna (skalabilitas sistem).

Kunci harus ditempatkan pada sumber daya (baris tabel) yang dibaca dan diubah dalam transaksi. Misalnya saja saat mengurus dokumen.

Dalam contoh di atas, sumber daya tersebut adalah saldo produk. Sistem harus memblokir saldo sejak data saldo diterima (T1) hingga akhir transaksi (T3).

Catatan. Transaksi pada saat pengeposan dokumen No. 1 dimulai lebih awal dari saat saldo diterima. Namun untuk mempermudah, kami berasumsi bahwa T1 adalah waktu mulai pemrosesan dokumen dan saat penerimaan saldo.

Contoh kapan tidak perlu mengunci– melaksanakan dokumen “Penerimaan barang”. Dalam hal ini, tidak ada persaingan untuk mendapatkan sumber daya (sisa, ...), jadi pemblokiran akan berbahaya: akan mengurangi skalabilitas sistem.

Pemblokiran otomatis dan terkontrol

Di sini kita tidak akan membahas teori (ini adalah topik artikel terpisah), tetapi hanya akan mengatakan bahwa kunci terkelola lebih optimal.

Alih-alih teori, kami dapat memberikan bukti - semua konfigurasi standar modern bekerja pada interlock yang terkontrol.

Oleh karena itu, dalam konfigurasi model kami, mode yang sesuai akan dipilih:

Kunci terkontrol dalam teknologi kontrol residu baru

Kami akan menerapkan kunci pada register “Saldo Gratis” dan hanya pada item item yang ditemukan dalam dokumen.

Lebih-lebih lagi opsi pemblokiran yang benar– selambat mungkin.

Dalam metode baru dalam mengendalikan saldo, hal ini harus dilakukan sebelum pencatatan (atau pada saat pencatatan) pergerakan dalam register “Saldo Gratis”, sehingga transaksi lain tidak dapat mengubah sumber daya bersama ini.

Pemblokiran dapat diterapkan secara manual (secara terprogram) dan nanti kami akan menunjukkan bagaimana hal ini dilakukan.

Namun bonus tambahan dari teknologi kontrol saldo baru ini adalah hanya diperlukan satu baris kode untuk mengunci sumber daya bersama.

Anda hanya perlu mengatur properti BlockForChange pada set entri register:

// 3.1. Mengunci sisa register
#Area Area3_1
Moves.FreeRemainders.BlockForChange = Benar;
#Area Akhir

// 4. Merekam pergerakan di database
#Area Area4
Movements.FreeRemainders.Write = Benar;
Pergerakan.Rekam();
#Area Akhir
...

Akibatnya 2 kali transaksi tidak dapat mengubah saldo gratis untuk satu item.

Faktanya, ketika propertinya adalah BlockForChange tidak menginstal penguncian terkelola, itu hanya mematikan mode pemisahan total register saat menulis.

Namun untuk artikel kami, hal berikut ini penting: sistem akan mengunci kombinasi data yang ditulis ke register. Kami akan melihat cara kerja properti BlockForChange secara rinci di artikel terpisah.

Omong-omong, dalam UT 11 standar tidak mudah untuk menemukan pengaturan properti BlockForChange untuk register “Saldo gratis”. Faktanya adalah ini dilakukan dalam modul register recordset, dalam acara "Sebelum menulis".

Itu saja, dengan satu baris kode, pengoperasian sistem yang benar dapat dipastikan!

Penting. Kami tidak mengunci daftar “Harga Barang”.

Mengapa? Pemblokiran seperti itu tidak diperlukan (dan ini adalah beban tertentu pada server 1C), karena perpindahan ke register "Saldo gratis" dan "Harga Barang" selalu dilakukan secara serempak, yaitu berurutan satu demi satu.

Oleh karena itu, dengan memblokir barang dari “Saldo Gratis”, kami tidak akan mengizinkan transaksi lain sebelum barang tersebut dan dalam daftar “Harga Barang”.

Namun untuk cara pengendalian saldo yang lama, pemblokirannya akan diterapkan berbeda. Pertama, mari kita lihat algoritma penghapusan batch untuk kasus ini.

Metode lama pengendalian residu

Izinkan kami mengingatkan Anda bahwa metodologi lama dapat diterapkan jika kuantitas dan biaya diperhitungkan dalam satu register.

Biarkan ini menjadi daftar “Harga Barang”:

Maka algoritma untuk memposting dokumen “Penjualan barang” akan terlihat seperti ini:

// 1. Pengendali acara "Sebelum merekam"
Prosedur Sebelum Perekaman (Kegagalan, Mode Perekaman, Mode Konduksi)

Jika Mode Perekaman = Mode Perekaman Dokumen
DAN BUKAN Objek Ini.IniBaru()
Dan Objek Ini. Dilakukan Lalu

Permintaan = Permintaan Baru;
Permintaan.Teks =
"MEMILIH
| Dokumen.Tanggal SEBAGAI Tanggal
|DARI
| Dokumen Penjualan Barang dan Jasa SEBAGAI Dokumen
|DIMANA
| Dokumen.Link = &Link";
Request.SetParameter("Tautan", Objek Ini.Tautan);
RequestResult = Permintaan.Eksekusi();
SelectionDocument = Hasil Kueri.Select();
PilihDokumen.Berikutnya();

ThisObject.AdditionalProperties.Insert("OldDocumentDate", SelectDocument.Date);

Jika tidak
berakhir jika;

Akhir Prosedur

Prosedur Saat Merekam (Penolakan)

Jika BUKAN Objek Ini.Properti Tambahan.Properti("DocumentDateShiftedForward") Lalu

Objek Ini.Properti Tambahan.Sisipkan("DocumentDateMovedForward",
Objek Ini.Tanggal>Objek Ini.Properti Tambahan.TanggalDokumen Lama);

Laporan(Objek Ini.Properti Tambahan.DocumentDateMovedForward);
berakhir jika;

Akhir Prosedur

Prosedur Pemrosesan (Kegagalan, Mode)

// 2. Menghapus perpindahan dokumen "lama".
Jika Extraproperties.DocumentDate adalah ShiftedForward, maka
Pergerakan.Harga Barang.Catatan = Benar;
Pergerakan.Biaya Produk.Clear();
Pergerakan.Rekam();
berakhir jika;

// 3. Mengatur flag untuk mencatat pergerakan di akhir transaksi
Pergerakan.Harga Barang.Catatan = Benar;

Permintaan.SetParameter("TimePoint", TimePoint());
Request.SetParameter("Tautan", Tautan);

RequestResult = Permintaan.Eksekusi();

SelectionNomenclature = Hasil Kueri.Select(BypassQueryResult.ByGrouping);

// 5. Siklus demi item - memeriksa apakah jumlahnya cukup untuk penghapusan
Sementara SelectionNomenclature.Next() Loop

Defisit Nomenklatur = SampleNomenclature.Quantity - SampleNomenclature.QuantityRemaining;

Jika Defisit Nomenklatur>0 Maka
Pesan = MessageToUser Baru;
Message.Text = "Kuantitas produk tidak mencukupi: "+Defisiensi Tata Nama;
Message.Field = "Produk["+(SelectionNomenclature.LineNumber-1)+"].Quantity";
Pesan.SetData(Objek Ini);
Pesan.Pesan();
Menolak = Benar;
berakhir jika;

Jika Gagal Maka
Melanjutkan;
berakhir jika;

// 6. Dapatkan jumlah yang akan dihapuskan
RemainingWrite = SampleNomenclature.Quantity;
SelectionBatch = SelectionNomenclature.Select();

// 7. Siklus batch
Sementara SelectionBatch.Next() Dan RemainingWrite>0 Loop

Pergerakan = Pergerakan.Harga Barang.TambahanBeban();
Pergerakan.Periode = Tanggal;
Movement.Nomenclature = SelectionBatch.Nomenclature;
Gerakan.Batch = SelectionBatch.Batch;
// 9. Perhitungan jumlah yang akan dihapuskan
Movement.Quantity = Min(RemainingWrite, BatchSelection.QuantityRemaining);
// 10. Perhitungan jumlah penghapusan
Pergerakan.Jumlah = Pergerakan.Jumlah*
SampleBatch.AmountRemaining/SampleBatch.QuantityRemainder;

// 11. Mengurangi jumlah yang akan dihapuskan
RemainingWrite = RemainingWrite - Gerakan.Kuantitas;

Siklus Akhir;
Siklus Akhir;

Apakah saya perlu beralih ke 1C:Enterprise 8.2? Jika Anda sedang membaca artikel ini, yang berarti Anda mungkin sudah menjawab pertanyaan ini dengan setuju. Oleh karena itu, sekarang kami tidak akan membicarakan lagi tentang keuntungan beralih ke platform baru, namun akan fokus langsung pada detail dan fitur dari proses ini.

1. Algoritma umum

Jadi, Anda telah memutuskan untuk beralih ke "delapan" dan ingin mengetahui bagaimana hal ini dilakukan dan apa "ancamannya" bagi Anda. Dalam bentuknya yang paling umum, diagram transisi terlihat seperti ini (Gbr. 1).

Beras. 1. Algoritma transisi dari platform 1C:Enterprise 7.7 ke platform 1C:Enterprise 8.2

1. Tingkatkan. Hal pertama yang perlu Anda lakukan adalah menulis aplikasi dari organisasi Anda, mengirimkan formulir pendaftaran untuk platform 7.7 dan membeli platform 8.2. Dalam hal ini Anda akan diberikan diskon dalam jumlah biaya platform lama, tapi tidak lebih dari 50%. Platform lama tetap milik Anda, dan Anda dapat terus menggunakannya, namun platform tersebut akan dihapus dari dukungan teknis di 1C.

2. Pembaruan konfigurasi saat ini hingga rilis terbaru saat ini.

3. Mempersiapkan database untuk transfer. Menyiratkan cadangan database, menutup periode penagihan saat ini, membersihkan database dari item yang ditandai untuk dihapus, dan memperbaiki kesalahan akuntansi (jika ada).

4. Perpindahan data. Ini adalah panggung utama. Algoritma dan intensitas tenaga kerja di masing-masing kasus tertentu berbeda.

5. Pelatihan personel untuk bekerja dengan konfigurasi baru. Karena konfigurasi pada platform 7.7 dan 8.2 berbeda dalam antarmuka dan fungsionalitas, Anda mungkin memerlukan pelatihan untuk bekerja dengan konfigurasi baru. Anda dapat mempelajarinya sendiri dengan menggunakan yang sesuai literatur metodologis, tetapi lebih baik mengambil kursus khusus tentang 1C.

6. Operasi. Pada tahap ini, ketika pengguna mulai bekerja program baru, itu di-debug dan kemungkinan kesalahan dalam transfer data otomatis diperbaiki.

Mari kita lihat proses migrasi ke platform baru dalam konteks konfigurasi "akuntansi 1c".

2. Ubah “1C: Akuntansi 7.7” menjadi “1C: Akuntansi 8.2”

Strategi dan mekanisme transfer data dari “1C: Accounting 7.7” ke “1C: Accounting 8.2” ditentukan oleh faktor-faktor berikut:

waktu mulai akuntansi di program baru;
keberadaan dan kompleksitas modifikasi pada versi konfigurasi Anda saat ini;
kebutuhan untuk melestarikan sejarah transaksi bisnis untuk periode yang lalu.

Kami menyarankan klien kami untuk mulai bekerja di program akuntansi baru mulai 1 Januari tahun baru . Hal ini disebabkan oleh fakta bahwa sebagian besar pajak dihitung berdasarkan basis akrual. Oleh karena itu, agar tidak mengembangkan cara untuk mentransfer hasil akumulasi dengan benar, permulaan pekerjaan dalam program perlu dikaitkan dengan awal periode pelaporan pajak. Tentu saja, Anda dapat mulai bekerja dari awal kuartal, dan bahkan dari awal bulan berikutnya, namun transisi seperti itu akan memerlukan biaya yang lebih signifikan (karena perbedaan signifikan dalam struktur dokumen di 7.7 dan 8.2).

Tergantung pada kombinasi faktor-faktor di atas, situasinya mungkin sebagai berikut.

Situasi 1:

Transisi dari tahun baru, konfigurasi KHUSUS, saldo akun yang benar dihasilkan di program lama

Opsi ini sederhana dan jelas, tetapi dalam praktiknya sangat jarang terjadi. Dimungkinkan untuk menghasilkan saldo yang benar dalam program lama segera sebelum mulai bekerja di program baru hanya di sejumlah perusahaan kecil, dan hanya dengan syarat semua dokumen utama lengkap. periode yang lalu disediakan dan dimasukkan dalam program.

Jika ini kasus Anda, Anda beruntung. Anda hanya perlu memperbarui konfigurasi 1C:Enterprise 7.7 ke versi terbaru dan gunakan pemrosesan yang ada di dalam "1C:Enterprise 8.2" "Transfer data dari basis informasi 1C:Enterprise 7.7". Anda dapat melakukannya sendiri, tanpa bantuan seorang spesialis. Anda hanya perlu mengikuti instruksi yang ditentukan dalam pemrosesan dengan ketat.

Situasi 2:

Peralihan dari tahun baru, konfigurasi KHUSUS, di program lama TIDAK ADA SALDO AKUN YANG BENAR

Praktik standar dalam hal ini adalah bekerja di program lama dan baru secara bersamaan . Selama “masa transisi” (Gbr. 2), karyawan menutup transaksi sebelumnya di program lama dan mulai memasukkan dokumen transaksi baru ke dalam sistem baru.

Beras. 2. Masa transisi ketika berpindah platform

Untuk mengatasi periode ini dengan kerugian minimal, Anda bisa menggunakan strategi berikut:

mentransfer saldo "sebagaimana adanya" ke awal tahun dan menyimpan catatan berdasarkan data ini. Setelah saldo yang benar di "tujuh" diperoleh, saldo tersebut harus segera disesuaikan secara surut di "delapan".
menolak untuk mentransfer saldo yang salah dan memasukkan dokumen utama untuk transaksi baru ke dalam G8 tanpa melakukan selanjutnya. Dalam hal ini, tidak masalah apakah ada saldo dalam program atau tidak; dokumen yang belum diposkan tidak akan membuat pergerakan apa pun pada akun. Ini harus dilakukan sampai saldo yang benar diterima di 1C:Enterprise 7.7. Selanjutnya saldo yang dihasilkan ditransfer ke program baru di awal tahun. Langkah terakhir adalah implementasi konsisten dari program “utama” yang dimasukkan ke dalam program baru selama masa transisi menggunakan pemrosesan bawaan “Pemrosesan kelompok direktori dan dokumen” .

Situasi 3:

Transisi dari pertengahan tahun, konfigurasi KHUSUS

“1C: Accounting 8.2” mendukung sejumlah mekanisme penting untuk akuntansi, yang kinerjanya bergantung pada data yang dimasukkan ke dalam dokumen sepanjang tahun. Di antara mekanisme tersebut adalah perhitungan pajak berdasarkan akrual yang telah disebutkan, algoritma untuk distribusi biaya tidak langsung dan prosedur lain yang terkait dengan penutupan bulan. Justru karena fitur-fitur inilah dalam situasi ini tidak mungkin untuk beralih ke program baru semudah dalam dua kasus pertama. Untuk meminimalkan jumlah kesalahan yang mungkin terjadi selama migrasi, sebaiknya:

mulai bekerja, jika bukan dari awal tahun, setidaknya dari awal triwulan;
transfer saldo ke awal tahun;
mentransfer semua dokumen utama untuk periode pelaporan (tahun) saat ini ke sistem baru dan memulihkan data akuntansi dan pajak menggunakan pemrosesan grup direktori dan dokumen.

1. Solusi standar "1C: Konversi Data 2.1". Produk perangkat lunak ini dapat digunakan untuk mentransfer informasi antar konfigurasi pada platform 1C dengan struktur dan kompleksitas apa pun.

2. Perkembangan franchisee 1C. Banyak perusahaan, termasuk perusahaan « RG-Soft" (), terdapat metode yang terbukti untuk memecahkan masalah ini, yang secara signifikan dapat mengurangi waktu dan anggaran pekerjaan transfer data.

Situasi 4:

Transisi dari konfigurasi STANDAR DENGAN TRANSFER DOKUMEN PERIODE LALU

Secara terpisah, kami mencatat bahwa ada perusahaan yang memelihara hubungan jangka panjang (lebih dari satu tahun) berdasarkan kontrak dengan pihak lawan. Manajemen perusahaan tersebut tertarik untuk mengetahui riwayat transaksi bisnis dalam program tersebut. Kehadiran dalam program baru dokumen yang dimasukkan dalam program lama memungkinkan pengguna dengan mudah dan cepat melacak hubungan berdasarkan perjanjian/transaksi tertentu.

Transfer semacam itu dapat dilaksanakan dengan menggunakan mekanisme yang sama seperti pada situasi sebelumnya. Perbedaan antara proses ini adalah tidak perlu mentransfer semua dokumen; Anda dapat membatasi diri hanya untuk mentransfer beberapa jenis dokumen, dan saldo untuk akun lain dimasukkan melalui pemrosesan standar. Dalam hal ini, dokumen tambahan yang ditransfer biasanya tidak diposkan.

Meskipun dimungkinkan untuk mentransfer dokumen untuk periode yang lalu dari program lama ke program baru, transfer tersebut menyebabkan peningkatan nyata dalam ukuran database, dan akibatnya, ukuran tabel yang diproses. Hal ini dapat menyebabkan sistem melambat. Oleh karena itu, Anda sebaiknya tidak menggunakan opsi transisi ini kecuali benar-benar diperlukan. Disarankan untuk membiarkan dokumen yang ditransfer dari periode sebelumnya tidak diselesaikan sehingga informasi yang terkandung di dalamnya tidak mempengaruhi akuntansi saat ini dan pelaporan pajak. Gunakan dokumen sejarah hanya untuk tujuan referensi.

Situasi 5:

Transisi dari konfigurasi NON-KHUSUS pada platform 1C:Enterprise 7.7

Opsi yang dijelaskan di atas digunakan saat bermigrasi dari konfigurasi standar “1C:Enterprise 7.7”, tetapi dalam praktiknya Anda sering kali harus berurusan dengan konfigurasi yang dimodifikasi. Mengorganisir transisi dalam situasi ini merupakan pilihan khusus yang patut dipertimbangkan.

Tergantung pada sifat perubahan yang dilakukan pada program, tersedia teknologi transfer data berikut:

· jika konfigurasi telah sedikit diubah dan mekanisme dasarnya mirip dengan solusi standar 1C, Anda dapat, seperti pada opsi sebelumnya, menggunakan alat transisi standar. Anda hanya perlu mengkonfigurasi atau sedikit memodifikasinya agar sesuai dengan program Anda. Mungkin alat yang paling teruji dan andal adalah “1C: Konversi Data 2.1” yang telah disebutkan. Alat ini akan memerlukan keterampilan pengoperasian tertentu dari pengguna, tetapi dengan bantuannya dimungkinkan untuk mengatur transfer objek otomatis antar konfigurasi.

· jika selama bertahun-tahun penggunaan konfigurasi telah didesain ulang secara radikal, maka menyiapkan alat migrasi standar mungkin akan lebih memakan waktu daripada menulis pemrosesan Anda sendiri untuk tujuan ini. Situasi serupa muncul ketika mengatur transisi dari program akuntansi yang tidak terkait dengan platform 1C. Transisi seperti itu juga bisa dilakukan, namun tidak mungkin menghasilkan pertukaran universal terlebih dahulu. Setiap kasus tertentu memerlukan pendekatan individual terhadap masalahnya. Perusahaan kami dapat menawarkan pengalamannya dalam mentransfer data melalui file berbagai format, seperti dbf, xls(Pemuat universal dari Excel ke 1C), xml.

Hal lain yang perlu disebutkan sehubungan dengan transisi dari platform 7.7 ke 8.2 adalah masalah konsolidasi basis data.

Karena kurangnya mekanisme untuk menyimpan catatan beberapa perusahaan dalam satu database, banyak perusahaan harus memelihara beberapa database secara bersamaan di 1C:Enterprise 7.7. Karena masalah ini telah diselesaikan pada versi kedelapan, muncul tugas untuk menggabungkan beberapa database menjadi satu sebagai bagian dari proyek transfer data. Selain itu, masing-masing dari tujuh pangkalan tersebut dapat memiliki karakteristiknya sendiri.

Dengan menggunakan metode yang diberikan di atas, Anda dapat menjalin interaksi dengan masing-masing database secara terpisah. Namun, sejumlah subtugas muncul khusus untuk kasus ini.

1. Penyatuan dokumen yang berkaitan dengan organisasi tertentu. Masalah ini mudah diselesaikan dengan menggunakan mekanisme awalan. Setiap organisasi yang terdaftar dalam program ini diberi awalan hurufnya sendiri. Awalan ini ditambahkan ke nomor dokumen, sehingga memastikan keunikan nomor tersebut.

2. Kontrol elemen duplikat direktori. Saat mentransfer data dari beberapa sumber informasi ke satu sistem informasi, situasi mungkin muncul ketika elemen direktori yang sama, misalnya, rekanan yang sama di direktori baru, akan diulang beberapa kali. Oleh karena itu, setelah mentransfer data, perlu dilakukan prosedur untuk membandingkan dan menggabungkan elemen direktori duplikat.

3. Kemungkinan kesulitan yang harus Anda waspadai

Dengan perencanaan yang tepat dalam proses transisi ke platform baru, banyak masalah yang dapat dihindari. Namun, ada sejumlah fitur tertentu, yang sudah ditemukan pada tahap pelaksanaan proyek. Kita berbicara tentang berbagai kesalahan yang muncul baik karena tindakan pengguna yang salah maupun karena fitur teknis platform 1C:Enterprise. Mari kita pertimbangkan poin-poin ini secara lebih rinci.

3.1. Kesalahan dalam data sumber

Secara umum, identifikasi jelas suatu objek dalam database dapat dilakukan dengan menggunakan rincian NPWP dan KPP. Pada ketujuh nilai tersebut, kedua nilai tersebut disimpan dalam satu rincian NPWP/KPP, dan tidak dilakukan pemeriksaan kebenaran data yang dimasukkan pada rincian tersebut. Dimungkinkan untuk memasukkan angka yang lebih sedikit, menempatkan pemisah di tempat yang salah, dan memasukkan TIN yang sepenuhnya abstrak.

Transfer tipikal, saat membuat direktori, rekanan dipisahkan berdasarkan NPWP dan KPP hanya dengan memotong jumlah karakter yang diperlukan. Oleh karena itu, data yang benar-benar salah mungkin dicatat dalam rincian database baru. Dengan demikian, identifikasi objek yang benar selama transfer menggunakan data tersebut akan sangat sulit.

Masalah lainnya adalah kurangnya format entri data terpadu. Setiap pengguna dapat memasukkan nama sesuai keinginannya. Mari kita bayangkan bahwa dalam satu database "tujuh", pengguna, dengan mengisi "Nama" rekanan, menulis "Perusahaan Manajemen Vympel", dan di database "tujuh" lainnya, rekanan yang sama terdaftar sebagai "Perusahaan Manajemen Vympel". Dalam situasi seperti ini, pemrosesan otomatis tidak akan dapat menentukan bahwa ini adalah rekanan yang sama, dan akan memindahkannya ke delapan dua kali. Akan sulit untuk bekerja lebih jauh dalam database seperti itu, karena sebagian dari saldo akan berada pada satu elemen, dan bagian kedua pada elemen lainnya.

3.2. Perbedaan konfigurasi

Kelompok kesalahan transfer lainnya disebabkan oleh perbedaan teknologi dalam konfigurasi. Beberapa transaksi bisnis tercermin dalam “1C:Enterprise 7.7” oleh beberapa jenis dokumen, dan dalam “1C:Enterprise 8” oleh satu dokumen. Misalnya, penerimaan bahan dan barang tercermin dalam program baru dengan satu dokumen, dan di program lama - dengan dua dokumen. Dengan demikian, ketika mencoba mentransfer dokumen “Kwitansi Bahan No. 22” dan “Kwitansi Barang No. 22”, terjadi kesalahan kontrol keunikan. Karena pencatatan dua dokumen dengan nomor yang sama dalam suatu periode tertentu tidak mungkin dilakukan, maka perbedaan-perbedaan tersebut perlu dibuat secara artifisial dan sistem untuk memasukkan perbedaan-perbedaan ini telah disepakati sebelumnya.

Misalnya, masalah ini diselesaikan dengan menambahkan awalan tambahan ke nomor dokumen yang diunduh. Untuk setiap fitur dokumen, awalan ini dialokasikan secara terpisah. Ini mungkin merupakan karakteristik database tempat dokumen diunduh atau jenis dokumen tempat pengunduhan dilakukan. Berikut adalah contoh pembentukan awalan tersebut. Basis cabang di Krasnoyarsk diberi awalan “KR”. Jenis dokumen “Penerimaan bahan” tempat pengunduhan dilakukan diberi awalan “M”. Jadi, jika nomor dokumen di tujuh adalah 00000031, maka nomor delapannya adalah sebagai berikut:

“KR” + “M” + “00000031” = “KRM00000031”

Hasilnya, nomor unik akan tercatat di database.

3.3. Masalah teknis

Kesalahan transfer data juga dapat terjadi karena fitur teknis platform 1C:Enterprise. Misalnya, mekanisme pencarian standar berdasarkan nama tidak membedakan huruf kapital pada nama elemen direktori dari huruf kecil. Ada kebingungan saat menggunakan mekanisme ini. Misalnya, dalam database ada dua rekanan “l-audio” dan “L-Audio”. Saat mencari rekanan “l-audio”, sistem akan menemukan “L-Audio”. Hasilnya adalah dokumen yang diisi secara tidak benar.

Penting juga untuk memperhatikan metode transfer data yang dipilih itu sendiri. Contoh penggandaan rekanan yang dijelaskan di atas, ketika ditransfer dari database cabang perusahaan, mungkin tidak benar-benar menjadi penggandaan. Bagi perusahaan yang beroperasi di kota yang berbeda, mungkin ada rekanan yang juga bekerja di kota yang berbeda. Cabang perusahaan L-Audio di Nizhny Novgorod dan perusahaan L-Audio itu sendiri di Moskow dapat disebut persis sama dalam database. Untuk menghindari kebingungan seperti itu, Anda harus memilih metode transfer terlebih dahulu. Dalam contoh kita, kita dapat memisahkan rekanan ke dalam kelompok direktori yang berbeda tergantung pada database sumber. Pemilihan teknik tersebut juga akan mempengaruhi mekanisme pemuatan data.

Metode yang dijelaskan di atas untuk memecahkan masalah yang muncul mungkin juga tidak cukup universal. Saat melakukan migrasi data, sangat penting untuk dapat menggabungkan metode yang digunakan dalam alat migrasi. Misalnya, kami mengidentifikasi sebagian besar elemen direktori berdasarkan nama. Pada saat yang sama, ketika mentransfer dokumen "Penerimaan aset tetap untuk akuntansi", metode ini akan memberikan hasil yang tidak diinginkan jika sejumlah aset tetap kecil dari jenis yang sama dimasukkan (perlengkapan kantor, furnitur, dll.), hanya berbeda pada jumlah persediaannya saja. Setiap dokumen penerimaan akuntansi akan menunjukkan objek yang sama. Dan tidak mungkin menerima satu objek untuk akuntansi beberapa kali. Oleh karena itu, sangat penting untuk memberikan kemampuan untuk menyesuaikan alat migrasi data yang digunakan. Dalam hal ini, kami hanya akan menunjukkan bahwa pencarian OS harus dilakukan oleh nomor inventaris(ke kode).

Kesimpulan

Saat ini masih cukup banyak perusahaan yang bekerja menggunakan 1C:Enterprise 7.7. Hal ini disebabkan oleh beberapa faktor seperti kurangnya pemahaman tentang keunggulan platform baru, keengganan untuk mempelajari teknologi baru, dan ketakutan menghadapi banyak kesulitan selama masa transisi. Dengan menggunakan contoh 1C: Akuntansi, kami mencoba menunjukkan bahwa sebagian besar alasan ini tidak begitu signifikan. Sepanjang aktivitas kami, kami membantu klien kami mengatasi segala kemungkinan kesulitan yang terkait dengan implementasi program pada platform 1C:Enterprise 8. Jika Anda tertarik dengan masalah transisi atau Anda memiliki pertanyaan lain mengenai platform 1C:Enterprise 8 dan konfigurasi yang dibuat di dalamnya, spesialis RG-Soft siap melayani Anda!

Momen waktu:
Perusahaan 1C menjelaskannya sebagai berikut:
Dirancang untuk menerima dan menyimpan suatu titik waktu untuk suatu objek dalam database. Berisi tanggal dan waktu, serta referensi ke objek database. Digunakan sebagai nilai properti dan parameter metode objek lain bertipe Instant of Time.
Titik waktu digunakan dalam kasus di mana penting untuk membedakan titik waktu untuk objek yang memiliki tanggal dan waktu yang sama, misalnya untuk membandingkan posisi dokumen pada sumbu waktu.

Dan dengan kata-kata Anda sendiri:
Titik waktu adalah kombinasi tanggal dan referensi ke suatu dokumen. Memungkinkan Anda membagi dan mengatur dokumen dalam satu detik, mengatur semua dokumen dalam urutan yang jelas. Menerima data saat memposting pada suatu waktu memastikan bahwa pergerakan yang dilakukan pada detik yang sama dengan dokumen yang diposting, tetapi terletak di depannya, akan diperhitungkan.
Namun ada kekhasan - dokumen yang diposting pada detik yang sama disusun dalam urutan acak, dan bukan dalam urutan pembuatan fisiknya (seperti yang terjadi pada 7.7).

InstantTime() adalah momen SEBELUM posisi dokumen (analog dengan CountRegistersOn(CurrentDocument() di 7), dan jika Anda perlu mendapatkan momen segera setelah posisi dokumen, gunakan objek Border
Kode 1C v 8.x Momen Segera Setelah Dokumen = Perbatasan Baru(DocumentLink,BorderView.Including)

Kode 1C v 8.x // Contoh membuat titik waktu menggunakan tanggal dan link ke objek di database.
Momen = Momen Baru(TekDocument.Date, TechDocument.Link);

Saat menerima saldo:
"Titik waktu" adalah bidang virtual, tidak disimpan dalam database. Berisi objek Point in Time (yang mencakup TANGGAL dan LINK DOKUMEN)
<Виртуальная>tabel saldo tidak disimpan dalam database, tetapi dibuat pada saat diakses.
1. pilih titik waktu yang lebih besar atau sama dengan nilai PARAMETER yang saldonya DIHITUNG
2. pada saat ini sisa dari tabel total diperoleh
3. apabila waktu penghitungan saldo tidak bertepatan dengan waktu penjumlahan, maka saldo tersebut DIHITUNG berdasarkan pergerakannya.

Berbatasan:
Dirancang untuk menerima dan menyimpan batas rentang nilai tertentu. Berisi nilai batas interval, serta tanda masuk atau keluarnya nilai batas dalam interval.
Digunakan sebagai nilai properti dan parameter metode objek lain bertipe Boundary.
Batas digunakan dalam kasus di mana indikasi penyertaan atau pengecualian nilai batas itu penting, misalnya, saat memperoleh saldo dan putaran register akumulasi, irisan, dan nilai register informasi, untuk mengatur interval kueri.

Tipe Perbatasan - Mendefinisikan sekumpulan tipe batas dalam kaitannya dengan nilai batas:
BoundaryView.Including - Batas mencakup nilai batas.
BoundaryView.Excluding - Batas mengecualikan nilai batas.
Kode 1C v 8.x Border = New Border(Tanggal, BorderType.Including);
Request.SetParameter("ConBorder", Perbatasan);

Contoh perolehan saldo pada tanggal dokumen, termasuk pergerakannya
Permintaan.Teks =
"MEMILIH

|DARI

Request.SetParameter("MomTime", Batas Baru(MomTime.InstantTime(), BorderType.Including));

Contoh memperoleh saldo pada tanggal dokumen, tetapi sebelum pergerakannya
Kode 1C v 8.x Permintaan = Permintaan Baru;
Permintaan.Teks =
"MEMILIH
| Penyelesaian bersama dengan karyawan organisasi Saldo.
| Penyelesaian bersama dengan karyawan organisasi Saldo. Jumlah penyelesaian bersama Saldo
|DARI
| Daftar Akumulasi. Penyelesaian bersama dengan Karyawan Organisasi. Saldo (&MomTime, Individu = & Individu) SEBAGAI Penyelesaian bersama dengan Karyawan Organisasi.
MomTime = Dokumen. Penggajian untuk Karyawan Organisasi. Temukan Berdasarkan Nomor("00012","31/12/2009 23:59:59");
Request.SetParameter("MomTime", Batas Baru(MomTime.InstantTime(), BorderType.Excluding));
// atau seperti ini: Request.SetParameter("MomTime", MomTime.Instance());
Request.SetParameter("Fisikawan", Direktori.Individu.FindByCode("365"));
OutputHasil(Query.Run());

Informasi diambil dari situs

Saat ini, produk perangkat lunak 1C adalah semacam standar untuk akuntansi, manajemen, dan jenis akuntansi lainnya dalam usaha kecil dan menengah. Pengusaha mengharuskan karyawannya memiliki keterampilan yang diperlukan untuk bekerja dengan produk perangkat lunak khusus ini. Jika masalah pengintegrasian toko online dan sistem otomasi (sisa, harga, pesanan, dll.) muncul dalam agenda, kantor biasanya juga memiliki database 1C yang perlu dilakukan integrasi. Demikian pula dalam banyak kasus lainnya: setiap proses otomatisasi untuk usaha kecil dan menengah biasanya dimulai dengan produk 1C dan dilanjutkan dengan penggunaannya.

Sebagai konsultan bisnis, saya cukup sering menjumpai pertanyaan tentang apa itu 1C, struktur apa yang dimiliki produk perangkat lunak ini, dan secara umum bagaimana keseluruhan sistem ini bekerja. Pertanyaan tersebut biasanya ditanyakan oleh pengembang web yang terpaksa menangani masalah integrasi situs dan 1C, pemrogram yang berspesialisasi dalam aplikasi seluler, dan spesialis lain yang, karena sifat pekerjaannya, jarang harus berurusan dengan program 1C.

Dalam artikel ini, saya memutuskan untuk mengumpulkan jawaban atas pertanyaan paling umum yang selalu muncul dalam pekerjaan saya. Oleh karena itu, saya ingin segera memperingatkan Anda: artikel ini ditujukan untuk orang-orang yang akrab dengan teknologi TI, akuntan, orang-orang yang jauh dari bidang TI kemungkinan besar akan kesulitan memahami beberapa nuansanya; Tentu saja, saya akan mencoba menulis sesederhana mungkin, dan saya tidak berencana untuk mempelajari nuansa teknis pada tingkat kode, namun tetap saja, istilah dan konsep tertentu mungkin tampak rumit bagi non-spesialis.

Beberapa kata tentang pengalaman saya dengan 1C

Saya pernah bekerja sebagai programmer 1C di sebuah proyek besar, kemudian saya mengambil posisi manajer proyek, dan untuk waktu yang cukup lama saya menjadi kepala departemen proyek, yang secara eksklusif menangani tugas-tugas di 1C.

Sekarang, seperti yang telah saya tulis lebih dari sekali, saya bekerja sebagai konsultan bisnis di bidang usaha kecil dan menengah. Saya terus-menerus dihadapkan dengan berbagai tugas yang berkaitan dengan otomatisasi kerja, dan sebagai hasilnya, dengan produk perangkat lunak 1C. Paling sering, sebagai konsultan bisnis, saya mempekerjakan spesialis 1C untuk memecahkan masalah tertentu, saya memiliki tim permanen, dan saya juga menarik spesialis pihak ketiga, termasuk pekerja lepas. Dalam kasus yang sangat jarang, saya sendiri menulis sesuatu dalam 1C, paling sering jika saya sangat perlu menyelesaikan masalah kecil.

Di sisi lain, saya semakin menjauh dari pekerjaan terus-menerus dengan produk 1C. Jika pada awal karir saya bekerja dengan program 1C memberi saya 100% penghasilan, hari ini penerapan beberapa solusi 1C memakan tidak lebih dari 20% pekerjaan saya, yang lainnya adalah situs web, sistem CRM, dll.

Oleh karena itu, meskipun saya belum menyimpang terlalu jauh dari masalah yang berkaitan dengan program 1C, saya memutuskan untuk mensistematisasikan pengetahuan saya, mengumpulkan dan mencatat aspek-aspek penting dan nuansa bekerja dengan produk perangkat lunak ini.

Sedikit lebih banyak tentang 1C dan mengapa saya menulis semua ini

Saya sendiri tahu bahwa saya akan, seperti kata mereka, merangkul besarnya hal ini. Oleh karena itu, peringatan lain:

Saya berencana membuat serangkaian artikel tentang 1C, di mana saya akan membahas produk perangkat lunak ini dari sudut pandang yang berbeda. Artikel ini ditujukan terutama untuk programmer. Itu sebabnya saya mempostingnya di Habré. Berikut ini akan mencakup konsep yang lebih luas, termasuk yang menarik bagi pebisnis dan pengguna produk perangkat lunak 1C, dan oleh karena itu akan diposting di Megamind.
Saya tidak akan mempelajari nuansa penggunaan kode atau detail teknis lainnya, yang dapat Anda baca sendiri masing-masing di situs web resmi 1C, di situs dukungan, di forum terkenal, dll.
Saya tidak akan membahas perbedaan cara kerja versi platform ini atau itu. Selain itu, paling sering saya akan berbicara tentang platform 8.3 sebagai yang terbaru pada saat penulisan, serta tentang konfigurasi umum yang paling diminati oleh klien saya (usaha menengah dan kecil).

Pada saat yang sama, saya tidak hanya ingin membantu pemrogram web atau spesialis lainnya memahami di mana mencari bagian kode yang tepat, saya ingin membantu mereka memahami apa itu – 1C.

Saat ini, perusahaan 1C sendiri telah menimbulkan begitu banyak kebingungan dalam deskripsi produk, persyaratan untuk tingkat spesialis yang akan mengonfigurasi sistem, pilihan platform, konfigurasi, plugin, add-on, versi, dll., dll., bahwa sistem 1C secara pribadi mulai mengingatkan saya pada serial TV lama “ Gurita". Kalau ada yang masih ingat, di film ini komisaris bertengkar kelompok kriminal, yang salah satu bagiannya adalah kelompok perbankan. Dan sistem perbankan ini sangat membingungkan sehingga sangat sulit untuk memahami dari mana uang itu berasal, ke mana perginya, bagaimana divisi ini atau itu bekerja, dan yang terpenting, alasannya.

Dalam sistem 1C, upaya untuk “membingungkan” pengguna, menurut saya, ditujukan pada satu hal: Anda tidak perlu memahami apa pun, Anda hanya perlu membayar. Dan banyak pebisnis yang akhirnya membayar tanpa memahami apakah mereka memerlukan pembaruan ini, apakah mereka membutuhkan produk ini. Mereka hanya membayar dan hanya itu.

Saya akan mencoba menguraikan “tentakel Gurita” dan menyusun pemahaman umum tentang cara kerja sistem 1C.

Kami juga ingin mengingatkan pemrogram bahwa Anda dapat menemukan informasi teknis apa pun di situs web 1C. Saya tidak berencana memikirkan nuansa ini sama sekali. saya akan menulis dalam bahasa yang sederhana, sejauh mungkin, tentang isu-isu mendasar.

Dan jika Anda memerlukan nuansa teknis spesifik 1C, Anda selalu dapat menggunakan sumber daya berikut:

Situs web 1C dan forum mitra. http://www.1c.ru
Sumber daya lainnya

Dalam sebagian besar kasus, jawaban atas pertanyaan Anda dapat ditemukan di salah satu sumber berikut. Masih banyak lagi forum dan hal lainnya, namun sebagian besar solusinya ada di sana.

1C sebagai ekosistem

Ketika seorang pengusaha, pengacara, akuntan, penjual, dan pengguna lain menemukan program 1C, sering kali terjadi kesalahpahaman tentang apa itu program. Beberapa orang berpikir bahwa 1C adalah sistem akuntansi yang nyaman, yang lain berpikir bahwa ini adalah sistem untuk mengotomatisasi toko online, yang lain tidak begitu mengerti apa yang sedang kita bicarakan. Bahkan ada yang beranggapan bahwa dengan bantuan produk 1C ini atau itu Anda dapat menyelesaikan masalah bisnis apa pun, Anda hanya perlu memilih produk yang tepat dan, mungkin, memodifikasinya sedikit.

Alasan dari persepsi yang jelas-jelas salah ini adalah karena tidak ada yang memahami apa itu 1C dari sudut pandang platform. Setiap orang melihat sesuatu yang berbeda, spesifik. 1C sendiri membawa lebih banyak kebingungan karena secara aktif mendukung semua kesalahpahaman ini karena pemasarannya yang mencoba memposisikan 1C sebagai solusi untuk semua kesempatan dan tujuan apa pun.

Dalam artikel tersebut saya telah mengatakan bahwa sebenarnya 1C harus dianggap sebagai keseluruhan ekosistem. Pendekatan inilah yang akan membantu Anda memahami apa itu 1C dan mengapa itu diperlukan.

Jadi, dari sudut pandang ekosistem teknis, 1C terdiri dari komponen-komponen berikut:

Platform 1C adalah dasar di mana konfigurasi ditulis, yang digunakan pemrogram untuk bekerja, dll. Platform ini diperbarui dari versi ke versi, dan oleh karena itu dapat berupa: 6.0, 7.7, 8.0, 8.2 atau 8.3.
Konfigurasi. Ini adalah tingkat kekhususan berikutnya. Konfigurasi ditulis pada platform menggunakan kode 1C. Pengguna bekerja dengan konfigurasi.
1C Bitrix. Sebuah sistem untuk bekerja dengan situs web, perlu dibicarakan secara terpisah.

Aspek lain di mana pekerjaan 1C dapat disusun adalah tingkat organisasi. Dan disini ada 2 bagian yang juga tidak akan berfungsi tanpa satu sama lain:

Perusahaan 1C itu sendiri dan staf spesialisnya.
Mitra 1C (waralaba) dan spesialis yang terlibat dalam pemeliharaan sistem. Mereka juga patut disoroti sebagai salah satu komponen ekosistem. Tanpa spesialis yang menyelesaikan dan mengimplementasikan 1C, sistem tidak akan berfungsi. Ini bisa berupa perusahaan mitra 1C atau pekerja lepas tunggal, tidak masalah, mereka harus melakukannya, jika tidak, sistem tidak akan dapat berjalan.

Selanjutnya, saya mengusulkan untuk melihat lebih dekat bagian-bagian dari ekosistem 1C.

Platform

Platform adalah dasar di mana pemrogram 1C, dengan menggunakan bahasa pemrograman 1C, menulis program (konfigurasi) yang sudah jadi untuk pengguna. Platform adalah basis yang tanpanya tidak ada satu pun komponen atau konfigurasi yang dapat berfungsi. Pada saat yang sama, platform itu sendiri tanpa konfigurasi mungkin hanya menarik bagi programmer 1C; bagi semua orang lain (pengguna, berbagai spesialis) tidak ada gunanya.

Anda dapat bekerja pada versi platform yang berbeda. Saya tahu bahwa dalam praktiknya, versi 8.2 dan 8.0 digunakan, serta versi 7.7 yang agak lama, tetapi masih populer, kadang-kadang bahkan rilis 6.0 pertama yang berhasil digunakan. Tapi saya akan berbicara secara eksklusif tentang versi 8.3, sebagai yang terbaru pada saat penulisan. Banyak hal yang akan kita bahas juga relevan untuk versi sebelumnya. Namun beberapa hanya ditambahkan pada rilis terbaru. Saya ingin pembaca mempertimbangkan fakta ini.

Penting untuk dipahami bahwa pengguna sering kali tidak memerlukan seluruh kemampuan yang disediakan 1C. Pernyataan ini sangat relevan untuk usaha kecil dan menengah. Namun kualitas dan keandalan pekerjaan sangat penting bagi pengguna. Dan dalam hal ini, sayangnya, cukup banyak masalah yang muncul pada produk perangkat lunak 1C.

Pemrogram saat bekerja dengan penggunaan 1C bahasa khusus pemrograman, yang dibuat oleh pengembang 1C untuk bekerja dengan platform 1C. Saat ini tersedia dalam bahasa Rusia dan bahasa Inggris, tetapi aslinya ditulis dalam bahasa Rusia, dan oleh karena itu konfigurasi standar juga ditulis secara tradisional dalam bahasa Rusia, meskipun operator versi bahasa Inggris selalu dapat digunakan di tempat yang tepat, jika lebih nyaman bagi pemrogram untuk bekerja seperti itu. Bahasa ini merupakan campuran BASIC dan C+ dengan tambahan SQL untuk menulis query. Selain itu, ia menyediakan kemampuan untuk menggunakan berbagai konstruktor dan plugin.

Salah satu fitur platform 1C adalah kurangnya modularitas. Platform adalah sesuatu yang utuh; tidak mungkin untuk secara jelas menunjukkan bagian kode (modul) mana yang bertanggung jawab atas kemampuan apa. Tentu saja, pada saat instalasi Anda dapat menentukan komponen mana yang harus diinstal dan mana yang tidak. Namun opsi ini hanya ada pada saat instalasi, dan, pada kenyataannya, menawarkan sejumlah kecil opsi.

Satu lagi catatan yang diharapkan dapat membantu menghindari kebakaran dan perselisihan:

Saya memahami bahwa platform 1C adalah alat yang ampuh dan sangat fleksibel. Dan jika Anda, sebagai programmer 1C berpengalaman, ingin menulis sesuatu yang istimewa di dalamnya, kemungkinan besar Anda akan mendapatkan perangkat lunak yang luar biasa. Dan untuk kasus yang berbeda di sini Anda dapat menemukan solusi berkat kekayaan kemampuan platform. Tetapi paling sering saya menemukan penggunaan konfigurasi standar (Akuntansi, Manajemen Perdagangan, Penggajian dan SDM, Manajemen Produksi), sebagian besar pengguna bekerja dengan mereka, terutama ketika menyangkut usaha kecil dan menengah. Oleh karena itu, saya akan menulis tentang pilihan platform dan beberapa masalah yang terkait dengan pekerjaan 1C terutama dari sudut pandang bekerja dengan konfigurasi standar.

Pada saat yang sama, saya juga memahami bahwa dengan keinginan yang besar dan tingkat pengetahuan programmer yang memadai, banyak masalah yang dapat diselesaikan, tetapi masalah tersebut tidak akan relevan. Oleh karena itu, jika Anda menggunakan beberapa perkembangan unik, permasalahan dan isu yang saya ungkapkan mungkin sama sekali tidak menarik bagi Anda. Untuk semua orang, saya melanjutkan.

Opsi pengiriman platform

Saat memilih platform, sangat penting untuk memperhatikan opsi penyampaian solusi. Hal pertama yang penting bagi Anda adalah metode pengorganisasian pekerjaan dengan data:

Solusi berkas
Opsi klien-server

Dalam solusi berbasis file, semua informasi pekerjaan akan disimpan dalam satu file umum. Tidak masalah konfigurasi apa yang Anda instal. Bagaimanapun, Anda akan menerima file layanan dengan ekstensi CD (format internal 1C), yang akan menyimpan semuanya: direktori, dokumen, register, dll. Jika jumlah pengguna program Anda tidak melebihi 4 orang, kemungkinan besar opsi ini cukup cocok untuk Anda. Selain itu, pengaturan sistem file jauh lebih mudah; di sini Anda bahkan dapat melakukannya tanpa bantuan spesialis 1C. Masalah kecepatan dapat diatasi sebagian dengan menggunakan RPD (Remote Desktop Protocol), tetapi hanya sebagian.

Namun untuk penggunaan 1C pada perusahaan dengan alur dokumen yang cukup aktif dan jumlah pengguna sistem yang cukup banyak (lebih dari 4 orang), sistem file tidak akan bekerja dengan memuaskan. Pengguna akan mengakses file yang sama hampir secara bersamaan, yang volumenya akan terus meningkat. Selain itu, sinkronisasi yang konstan akan diperlukan, yang akan semakin memperlambat pekerjaan.

Untuk mengatasi masalah ini, perusahaan 1C mencoba mencoba cache data, tetapi sejauh ini metode ini membawa lebih banyak masalah. Jika seseorang tertarik dengan topik ini, cukup ketik "masalah cache 1C" di mesin pencari; dalam pencarian akan ada banyak forum dan diskusi tentang hal ini dengan berbagai masalah, yang pada akhirnya bermuara pada fakta bahwa caching memang demikian. tidak selalu berfungsi dengan benar.

Organisasi penyimpanan data client-server adalah organisasi database dalam tabel di server. Ini bisa berupa MSSQL, Oracle atau opsi organisasi database lainnya.

Keuntungan dari opsi ini jelas: tidak peduli berapa banyak pengguna yang mengakses database, tidak akan ada masalah dengan kecepatan dan akses. Ini adalah opsi yang digunakan sebagian besar bisnis menengah, dan biasanya saya rekomendasikan kepada klien.

Dalam kebanyakan kasus, perusahaan menginstal server Windows tempat program itu sendiri dan database disimpan. Terkadang aplikasi dan database dipisahkan pada server yang berbeda, namun kasus ini rumit dan cukup jarang terjadi, oleh karena itu saya tidak akan membahasnya.

Versi 1C untuk platform berbeda

Hari ini Anda dapat memilih versi yang berbeda perangkat lunak 1C untuk bekerja di berbagai platform. Di sini ada baiknya juga mencari tahu apa yang layak dibeli dalam hal apa.

Jadi, ada versi 1C:

untuk Windows,
untuk Linux.

Pada saat penulisan, belum ada versi yang dikembangkan untuk Mac OS.

Program 1C, yang berjalan di bawah Windows, dikembangkan sejak awal; ini adalah alat canggih yang familiar bagi semua orang, yang cukup disempurnakan untuk digunakan tanpa masalah. Versi Linux saat ini dianggap masih baru, dan oleh karena itu cukup “mentah”; masih terdapat banyak kesalahan, seperti pada produk perangkat lunak baru lainnya.

Pengusaha dan perwakilan bisnis mana pun adalah orang-orang yang cukup konservatif; yang terpenting bagi mereka adalah pekerjaan yang stabil dan dapat diandalkan. Seringkali hal ini tidak begitu penting untuk bisnis kecepatan tinggi pekerjaan atau daftar peluang yang sangat besar, berapa banyak yang dibutuhkan untuk pekerjaan yang stabil saja. Selain itu, Linux belum banyak diminati di bisnis dalam negeri saat ini. Oleh karena itu, sangat jarang orang menemukan versi ini.

Basis komponen 1C

Basis komponen 1C sangat luas, berisi sejumlah besar kemampuan, sementara 1C terus-menerus memisahkan dan menambahkan fungsi. Itu. ketika pengembang 1C perlu membuat sesuatu yang baru, mereka hampir selalu membuat jenis objek baru. Misalnya, ketika layanan web diperlukan, pengembang tidak membuat semacam plugin, tetapi hanya memperkenalkan konsep: layanan web. Demikian pula, untuk banyak proses bisnis di perusahaan 1C, komponen baru paling sering dibuat, bahkan jika komponen yang sudah ada dapat dimodifikasi dengan mudah.

Apa yang dapat kami katakan tentang komponen platform 1C:

Beberapa komponen telah berfungsi sejak lama, beberapa lagi sejak pembuatan produk perangkat lunak. Mereka stabil dan dapat diandalkan.
Beberapa komponen telah ditambahkan baru-baru ini, yang lainnya sedang ditambahkan saat ini. Kebanyakan dari mereka diuji dengan sangat buruk, dan oleh karena itu Anda harus menggunakannya dengan sangat hati-hati.

Saat memilih komponen untuk dikerjakan, Anda harus selalu memperhatikan kapan komponen tersebut ditambahkan. Pemrogram 1C profesional memiliki aturan ini: ketika pengembang menambahkan fungsi baru, jika memungkinkan, hindari fungsi tersebut hingga jangka waktu yang cukup telah berlalu. Itu. mereka menunggu sampai komponen tersebut diuji dalam praktiknya, “bug” utama telah diidentifikasi dan diperbaiki, dan baru kemudian mereka mulai bekerja secara aktif dengannya.

Salah satu komponen reputasi negatif 1C adalah praktik perusahaan yang terus-menerus menambahkan solusi baru yang belum teruji. Meskipun seringkali komponen yang sudah diimplementasikan tidak berfungsi dengan baik, bug belum diperbaiki, dan pengembang sudah menambahkan sesuatu yang baru. Ini bukan hanya komponen saja, tapi bisa berupa fungsi baru untuk objek yang sudah ada, metode baru, dll. Semua programmer yang bekerja dengan 1C akan menghadapi masalah ini - kehadiran perangkat lunak "kasar" yang konstan, "bug" yang konstan, dan koreksi yang konstan.

Pengguna juga mungkin mengalami masalah ini - kesalahan dan pengoperasian perangkat lunak yang tidak stabil saat bekerja dengan platform. Ada serangkaian fungsi pemeliharaan 1C tertentu yang dapat dilakukan pengguna. Ada antarmuka pengguna platform untuk tujuan ini. Dan di sini ada baiknya kembali ke versi antarmuka pengguna yang berbeda.

Platform 1C terdiri dari banyak komponen berbeda yang terus ditambahkan, memperluas kemampuan produk ini. Selain dokumen, direktori, berbagai register, juga terdapat berbagai komponen input/output informasi, yaitu. antarmuka pengguna.

Berdasarkan fitur ini, Anda dapat memilih:

Klien 1C asli. Ini adalah antarmuka perangkat lunak tradisional ketika 1C diakses dari 1C.
Bekerja melalui browser.
Bekerja melalui aplikasi seluler.

Setiap opsi memiliki beberapa batasan; Anda dapat membaca lebih lanjut tentangnya di situs web resmi 1C.

Klien asli

Klien asli juga dibagi menjadi serangkaian subklien, yang menimbulkan kekacauan tambahan dalam proses pemilihan perangkat lunak. Hal terpenting di sini adalah memilih opsi klien “tebal” atau “tipis”. Sepintas, pilihan di sini tidaklah penting, terutama bagi seorang programmer. Faktanya, ketika bekerja dengan konfigurasi melalui antarmuka, masalah mungkin timbul karena kesalahan pemilihan.

Apa perbedaan antara sub-klien ini?

“Tebal” membutuhkan saluran komunikasi yang lebar (tebal), “tipis” membutuhkan saluran komunikasi minimum. Sebagian besar pelanggan saya menggunakan klien "tebal", karena setiap orang sekarang memiliki saluran lokal atau Internet yang bagus, dan tidak ada masalah dengan "lebar" mereka. Di sisi lain, klien “thin” memiliki keterbatasan tertentu dalam pengoperasiannya; ada hal-hal yang tidak dapat dilakukan di dalamnya.

Klien web (bekerja melalui browser)

Klien Web bekerja dengan program 1C melalui browser. Itu. Anda menggunakan teknologi tertentu yang memungkinkan Anda mengakses database melalui Internet, menggunakan browser yang nyaman bagi Anda. Dalam hal ini, antarmuka sepenuhnya diuraikan langsung di browser.

Opsi ini memberlakukan batasan tertentu, Anda harus selalu mengingatnya. Di sisi lain, bekerja dengan klien Web cukup stabil, di-debug dengan baik, dan sampai pada kesimpulan logis tertentu. Itu sebabnya cukup banyak orang yang menggunakan opsi antarmuka ini. Bekerja dengan 1C online bisa sangat nyaman dan bahkan perlu.

versi seluler

Versi klien dari 1C ini muncul relatif baru dan belum banyak diminati. Alasan sikap ini:

Kliennya ternyata sangat sulit. Untuk menyiapkan program ini, seseorang harus mengetahui 1C dan teknologi seluler, dan cukup mendalam pada tingkat kode. Jelas bahwa cukup sulit untuk menemukan spesialis seperti itu, yang tidak berkontribusi pada popularitas solusi perangkat lunak.
Teknologi ini masih sangat “mentah” dan belum di-debug dengan baik. Saya pribadi mencoba solusi ini untuk klien saya, berbicara dengan rekan-rekan yang juga mengenal teknologi ini, dan saat ini Pendapat saya dan pendapat rekan-rekan saya sama: lebih mudah dan nyaman membuat beberapa jenis aplikasi seluler daripada menggunakan opsi dari 1C.

Versi seluler harus menggabungkan banyak hal; memerlukan kerja beberapa spesialis yang akan bekerja sama dan saling membantu:

Menyiapkan akses ke database dari luar;
Memecahkan masalah keamanan;
Menyiapkan server untuk digunakan aplikasi seluler;
Menyiapkan produk perangkat lunak 1C;
Menyiapkan aplikasi web (jika perlu).

Semua ini diperlukan untuk memastikan pengoperasian aplikasi seluler 1C yang benar. Jelas bahwa membentuk tim spesialis seperti itu sulit dan mahal, dan oleh karena itu solusi ini tidak populer di kalangan usaha kecil dan menengah.

Platform 1C: ringkasan

Platform 1C sangat fungsional; ia memiliki banyak sekali kemampuan. Dan kuantitas ini secara alami berubah menjadi kompleksitas. Akibatnya, hambatan untuk bekerja dengan 1C bagi seorang programmer sangat tinggi. Klien mendengar tentang berbagai kemampuan 1C dan meminta programmer untuk membantu mengimplementasikannya. Artinya seorang spesialis harus selalu mengikuti perkembangan terkini, memahami dan mengetahui berbagai hal.

Sangat sulit untuk menemukan seorang programmer yang dapat memahami segala sesuatu di tingkat program sekaligus: bekerja dengan 1C, pemrograman web, bekerja dengan aplikasi seluler, dll. Hal ini dimungkinkan pada tingkat konseptual, yaitu. di tempat dimana saya sekarang berbagi ilmu.

Tetapi klien biasanya tidak memahami hal ini, dan mulai menuntut programmer 1C untuk mengimplementasikan berbagai kemampuan.

Di sisi lain, platform 1C terus berubah, ia memiliki banyak sekali opsi, banyak solusi berbeda, dan sebagai hasilnya - sejumlah besar bug dan perbaikannya.

Semua ini bersama-sama menyebabkan masalah penentuan posisi:

Di satu sisi, ada perusahaan 1C, yang memberi tahu klien bahwa 1C itu sederhana dan nyaman. Mereka tidak menulis dimanapun bahwa memelihara 1C akan membutuhkan seorang spesialis dengan pengetahuan khusus, sehingga sulit bagi programmer untuk bekerja dengan 1C modern.
Di sisi lain, pada kenyataannya klien menghadapi semua masalah ini. Dan ada baiknya jika dia mendapat bantuan dari tim yang bekerja dengan baik yang terlibat dalam penerapan 1C, atau konsultan bisnis dengan tingkat pengetahuan saya yang dapat menemukan spesialis yang tepat dan menugaskan mereka tugas yang tepat. Dalam kasus lain, pengguna akan menghadapi banyak masalah selama proses implementasi.

Jadi, secara singkat tentang platform 1C: banyak sekali kemungkinan, tingkat fleksibilitas yang tinggi, banyak solusi berbeda. Dan pada saat yang sama: kualitas implementasi yang rendah, kompleksitas solusi yang terus meningkat, sejumlah besar bug di setiap versi.

Secara konseptual, saya rasa informasinya sudah cukup. Dan Anda selalu dapat menemukan nuansa teknis pada sumber daya 1C yang saya rekomendasikan di atas.

Konfigurasi

Konfigurasi 1C adalah solusi perangkat lunak siap pakai yang dibuat berdasarkan versi platform tertentu. Konfigurasi adalah apa yang langsung digunakan oleh pengguna, lingkungan perangkat lunak tempat mereka menyimpan catatan terkini, bekerja dengan aliran dokumen, direktori, dll. Pengguna mungkin sering tidak mengetahui jenis platform apa yang mereka miliki. Namun mereka selalu mengetahui konfigurasi spesifik apa yang digunakan.

Ada konfigurasi:

Standar - ditulis oleh perusahaan 1C. Semuanya hadir di situs web 1C.
Tidak lazim – ditulis oleh perusahaan mitra.

Di tingkat pengguna, kedua jenis tersebut berbeda sebagai berikut:

Konfigurasi standar dibuat dan dikelola oleh 1C. Dalam kebanyakan kasus, kualitasnya lebih tinggi, dalam konfigurasi ini pekerjaan dengan kode lebih terorganisir, solusi optimal paling sering digunakan, dan kesalahan diperbaiki dengan cepat. Tentu saja, setiap orang terus-menerus mendengar tentang "bug abadi" dalam konfigurasi khas 1C, dan bug tersebut memang selalu ada di sana, namun tetap saja, ada baiknya memberikan penghargaan kepada spesialis perusahaan. Kesalahan kritis Mereka memperbaikinya dengan sangat cepat.
Konfigurasi atipikal ditulis oleh perusahaan mitra 1C, dan cukup sulit untuk mengatakan sesuatu yang pasti di sini. Konfigurasi tersebut sangat berbeda. Paling sering mereka ditulis pada kesempatan tertentu: khusus industri (untuk industri tertentu) atau ditulis untuk acara tertentu (perusahaan tertentu). Dan di sini perlu dipahami bahwa perusahaan mitra 1C sebagian besar memiliki pergantian staf yang cukup tinggi. Oleh karena itu, konfigurasi di dalamnya ditulis dengan cara yang agak tidak teratur. Seorang pemrogram mulai menulis, pemrogram lain melanjutkan, dan pemrogram ketiga menyelesaikan. Pada saat yang sama, masing-masing dari mereka membawa sesuatu, pemahaman, solusi, idenya sendiri. Dan ia menerapkan perkembangan pendahulunya sesuai keinginannya, dan bukan sesuai tujuannya.

Mungkin Anda ingat kartun lucu “Tiga dari Prostokvashino”? Di sana, anak laki-laki Paman Fyodor menulis surat kepada orang tuanya, tetapi tidak menyelesaikannya, perhatiannya terganggu, dan teman-temannya bergiliran menyelesaikannya untuknya: seekor kucing dan seekor anjing. Dan masing-masing dari mereka membicarakan masalahnya. Akibatnya, orang tua anak tersebut terkejut saat mengetahui bahwa “cakarnya sakit dan ekornya rontok”. Ini adalah prinsip yang sering digunakan untuk menulis konfigurasi non-standar.
Kurangnya kesinambungan dalam penulisan konfigurasi non-standar, dan seringkali kurangnya dokumentasi yang cukup rinci, mengarah pada fakta bahwa untuk semua pertanyaan tentang implementasi dan modifikasi, Anda harus menghubungi perusahaan yang mengembangkan konfigurasi ini.

Konfigurasi non-standar juga tersedia dalam dua jenis:

Ditulis berdasarkan standar. Konfigurasi ini dibuat dengan menambahkan fungsionalitas ke beberapa konfigurasi standar. Misalnya ada produk seperti 1C: Trade Management dan CRM. Di sini kami menggabungkan konfigurasi standar Manajemen Perdagangan dan sistem CRM. Menariknya, pembuat konfigurasi, perusahaan Rarus, menyebut subsistem Manajemen Perdagangan, meskipun sebenarnya itu adalah dasar penulisan seluruh konfigurasi.
    pro konfigurasi seperti itu - lebih fungsional dibandingkan dengan konfigurasi standar, sering kali fitur yang sangat diperlukan ditambahkan ke dalamnya.
    Minus– pengembang konfigurasi ini sering kali tidak punya waktu untuk membuat pembaruan pada waktu yang tepat. Oleh karena itu, mungkin saja perusahaan 1C telah memposting opsi pembaruannya, dan pengguna solusi non-standar harus menunggu beberapa saat hingga pengembang membuat pembaruan serupa untuk solusi tertentu. Selain itu, modifikasi tersebut juga cukup “mentah” dan mungkin mengandung banyak kesalahan.
Konfigurasi ditulis dari awal. Saat membuatnya, konfigurasi standar tidak digunakan sama sekali; solusi untuk tugas tertentu ditulis.
pro: konfigurasi ditulis persis sesuai dengan kebutuhan pelanggan, semuanya diperlukan dan hampir tidak ada yang berlebihan.
Minus: Biasanya, saat menulis solusi seperti itu, standar kode tidak dipatuhi; paling sering sangat sulit untuk memodifikasi produk perangkat lunak tersebut, hanya penulis yang dapat melakukannya dengan cukup cepat.

Jika saya datang ke klien dan melihat ada konfigurasi atipikal yang ditulis dari awal, saya mencoba untuk tidak menyentuhnya sama sekali, atau mengubahnya sepenuhnya ke solusi yang nyaman dan universal. Seringkali solusi seperti itu sebenarnya tidak diperlukan, terutama pada usaha kecil dan menengah. Pada saat yang sama, produk standar lebih mudah digunakan pemeliharaan lebih lanjut, dan, sebagai hasilnya, lebih murah, yang selalu penting bagi bisnis.

Ringkasan

Penting untuk dipahami bahwa pengusaha biasanya mencari konfigurasi. Misalnya, untuk mengotomatisasi pekerjaan departemen akuntansi, mereka memerlukan 1C.Akuntansi, dan untuk mengatur pekerjaan dengan klien - 1C. Manajemen perdagangan. Produk-produk inilah yang dapat dimengerti oleh mereka dan karenanya menarik.

Oleh karena itu, penting bagi programmer untuk mengetahui platform mana yang dia perlukan untuk bekerja. Pengguna tertarik dengan konfigurasinya. Pada saat yang sama, tanpa bantuan programmer 1C, sebuah bisnis dalam banyak kasus tidak akan dapat mengatur konfigurasi yang diinginkan. Itu sebabnya saya menyebut spesialis 1C sebagai bagian integral dari ekosistem 1C.

Izinkan saya mengingatkan Anda bahwa spesialis 1C juga berbeda. Beberapa terlibat dalam pengembangan platform dan konfigurasi standar (karyawan perusahaan 1C), yang lain adalah mitranya dan terlibat dalam implementasi dan modifikasi, sementara yang lain secara pribadi membantu memecahkan masalah tertentu terkait implementasi 1C. Tambahkan tanda

Membagikan: