Pengendalian hama
Status rekanan buruk 1 apa. Transisi ke aliran dokumen elektronik tanpa kertas: pengalaman, masalah, prospek

Status rekanan buruk 1 apa. Transisi ke aliran dokumen elektronik tanpa kertas: pengalaman, masalah, prospek

Versi 1.3.8 merupakan pengembangan dari edisi 1.3 "1C: Electronic Document Library 8", yang dirancang untuk memastikan pertukaran dokumen elektronik dalam solusi aplikasi yang dikembangkan pada platform 1C:Enterprise versi 8.3.10.2252 dan lebih tinggi.

Fitur dan perubahan baru

Dalam formulir pencarian penawaran dagang, kemampuan untuk mencari tanpa terhubung ke layanan 1C: Business Network telah ditambahkan, dan kemampuan untuk mencari pemasok berdasarkan nama telah ditambahkan.
Menambahkan laporan tentang penawaran perdagangan yang dipublikasikan.
Tempat kerja untuk menerbitkan penawaran perdagangan di layanan 1C:Business Network telah ditambahkan.
Adaptasi dilakukan dengan subsistem "1C: Library of Standard Subsystems" versi 2.4.2, "1C: Library of Internet User Support" versi 2.2.2.

Transisi ke versi 1.3.8 dari versi 1.3.7

Tipe yang ditentukan ditambahkan CounterpartyBED, tipe yang ditentukan Pihak rekanan dihapus Saat memperbarui Perlu atur tipe data baru, jika tidak penghapusan data tentang rekanan di objek subsistem PertukaranCounterparty(dokumen Paket dokumen elektronik, daftar informasi Status rekanan BED).

Perubahan modul:

Fitur tambahan Teks Permintaan untuk Produk yang Diterbitkan untuk mendapatkan sumber data untuk menerbitkan penawaran dagang dan menghasilkan laporan tentang barang yang dipublikasikan. Penting untuk mengimplementasikan pemanggilan fungsi ke metode FillOfferPackage saat menerima daftar produk.

Perubahan modul Penawaran Dagang

Prosedur ditambahkan UpdateDecorationConditionsPublikasi untuk memperbarui elemen formulir Dekorasi dengan status publikasi. Anda harus menambahkan pengaturan penerbitan untuk elemen status ke panggilan pada formulir.

Peran ditambahkan Laporan Penawaran Perdagangan diperlukan untuk mengakses laporan Penawaran Dagang yang Diterbitkan.

Versi 1.3.7

Versi 1.3.7 merupakan pengembangan dari edisi 1.3 "1C: Electronic Document Library 8", yang dirancang untuk memastikan pertukaran dokumen elektronik dalam solusi aplikasi yang dikembangkan pada platform 1C:Enterprise versi 8.3.10 dan lebih tinggi.

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

Menambahkan kemampuan untuk mendapatkan status dokumen pembayaran dari Bank Tabungan.
Menerapkan penerimaan otomatis pengaturan untuk Bank Tabungan saat menghubungkan ke layanan 1C:DirectBank.
Menambahkan kemampuan untuk menampilkan iklan kontekstual 1C:DirectBank.
Adaptasi telah dilakukan untuk bekerja dengan layanan 1C: Business Network di layanan cloud 1CFresh.
Menambahkan kemampuan untuk mempublikasikan, mencari, dan memesan penawaran dagang di layanan 1C: Penawaran Dagang untuk peserta dalam layanan 1C: Business Network.
Adaptasi dilakukan dengan subsistem "1C: Library of Standard Subsystems" versi 2.4.1, "1C: Library of Internet User Support" versi 2.1.9, "1C: Library of Service Technology" versi 1.0.12.

Subsistem "Pertukaran dengan rekanan"

Perubahan modul:

Tanggal dokumen, Tanggal Basis Dokumen

Subsistem "Pertukaran dengan bank"

Perubahan modul Bekerja Dengan FilesOverridable:

Untuk prosedurnya Saat Menentukan Pengaturan Anda perlu menambahkan kode:

Interaksi Elektronik.Saat MendefinisikanPengaturan(Pengaturan);

Untuk prosedurnya Saat Mendefinisikan Direktori Penyimpanan File Anda perlu menambahkan kode:

Interaksi Elektronik. Saat Mendefinisikan Direktori Penyimpanan File (Jenis Pemilik File, Nama Direktori);

Direktori MessageExchangeWithBanksAttachedFiles dan EDAttachedFiles telah ditambahkan ke rencana pertukaran UpdateInformationBase
Direktori MessageExchangeWithBanksAttachedFiles dan EDAttachedFiles telah ditambahkan ke tipe SignedObject yang ditentukan.

Bank Klien) memindahkan sekelompok elemen dari bentuk umum.

Dalam bentuk event handler Saat DibuatDiServer

&Di server

…

Akhir Prosedur

Dalam bentuk event handler Peringatan Pemrosesan

&Pada Klien

…
// Interaksi Elektronik Pertukaran Dengan Bank

Elements.GroupAdvertisingDirectBankHorizontal, Elements.TextDirectBankHorizontal);
// Akhiri Interaksi Elektronik Pertukaran Dengan Bank
Akhir Prosedur

Untuk elemen TextDirectBank Secara Horisontal tambahkan pengendali acara Memproses Tautan Navigasi

&Pada Klien

Akhir Prosedur

Untuk prosedur modul umum Interaksi Elektronik Perintah pembayaran dalam solusi aplikasi.

Subsistem "Pertukaran dengan situs"

Perubahan modul Pertukaran Situs Dapat Ditimpa:

Prosedur ditambahkan Tambahkan DetailFormNode, digunakan untuk menambahkan detail ke node rencana pertukaran dari Pertukaran dengan situs. Formulir simpul pertukaran tidak mengasumsikan adanya rincian yang terkait dengan solusi aplikasi; rincian ditambahkan secara terprogram.
Prosedur ditambahkan Bidang MasukanSaat DiubahDiServer, digunakan untuk memproses peristiwa di utara Ketika bidang input formulir simpul rencana pertukaran diubah, ditambahkan dalam prosedur Tambahkan NodeFormDetails.
Prosedur ditambahkan Kotak CentangBidangKetikaDiubahDiServer, digunakan untuk memproses acara di server Ketika bidang bendera formulir simpul rencana pertukaran, yang ditambahkan dalam prosedur Tambahkan NodeFormDetails, diubah.
Prosedur ditambahkan WhenCreatingOnServerFormCreateSite, digunakan untuk menambahkan detail ke formulir pemrosesan CreateSite.

Perubahan modul ExchangeSiteClientDapat Ditimpa:

Prosedur yang dihapus Tentukan Jenis Katalog GroupTableU, tipe nilai kolom Grup pada tabel Katalog Produk ditentukan oleh pengaturan pertukaran.
Prosedur ditambahkan InputFieldOnChange, dipanggil untuk memproses acara Ketika bidang input formulir simpul rencana pertukaran diubah, ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails.
Prosedur ditambahkan Kotak centangFieldOnChange, dipanggil untuk memproses acara Ketika bidang bendera formulir simpul rencana pertukaran yang ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails diubah.
Prosedur ditambahkan TableFormBeforeFinishEditing, dipanggil untuk memproses peristiwa BeforeFinishEdit bidang di bagian tabel bentuk node rencana pertukaran yang ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails.

Subsistem "Jaringan bisnis"

Menambahkan metode baru untuk menjalankan tugas rutin dalam mode terpisah, modul umum Interaksi Elektronik, Prosedur Setelah Menerima Daftar Template, . Lihat metode dengan nama yang sama di modul umum JobQueueOverridable.
Saat menyematkan perpustakaan, agar berfungsi dalam mode terpisah, Anda perlu menambahkan panggilan ke metode di modul umum JobQueueDapat Ditimpa:
- dalam prosedur Setelah Menerima Daftar Template:

// Interaksi Elektronik
ElectronicInteraction.OnReceiveListTemplates(TaskTemplates);

dalam prosedur Saat Mendefinisikan AliasesHandlers:

// Interaksi Elektronik
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// Akhiri Interaksi Elektronik

Perubahan modul BusinessNetworkDapat Ditimpa:
- prosedur diubah namanya menjadi Dapatkan Informasi Kontak Pengguna.
- prosedur diubah menjadi berfungsi Buat Counterparty Sesuai Detail, parameter Akun telah dihapus.

Subsistem "Penawaran dagang"

Subsistem baru "Penawaran dagang" telah ditambahkan; untuk penyematan Anda memerlukan:

Kembangkan metode yang diganti dalam modul umum TradeOffersClientDapat Ditimpa, TradeOffersDapat Ditimpa.
Tentukan tipe data dalam tipe yang ditentukan Jenis Nilai Detail 1СBusinessNetwork, Jenis Nomenklatur BED, Detail tambahanBED, Penawaran Dagang.

Lihat dokumentasi penyematan untuk detailnya.

Versi 1.3.6

Versi 1.3.6 merupakan pengembangan dari edisi 1.3 "1C: Electronic Document Library 8", yang dirancang untuk memastikan pertukaran dokumen elektronik dalam solusi aplikasi yang dikembangkan pada platform 1C:Enterprise versi 8.3.8 dan lebih tinggi. Dalam hal ini, properti konfigurasi "Mode Kompatibilitas" harus disetel ke "Versi 8.3.8".

Konfigurasi ini dimaksudkan untuk penggunaan bersama dengan konfigurasi "1C: Library of Standard Subsystems" tidak lebih rendah dari versi 2.3.4.112, dengan konfigurasi "1C: Library of Internet User Support 8" tidak lebih rendah dari versi 2.1.9.4.

Fitur dan perubahan baru

Format dokumen faktur utama didukung (dalam hal transfer dokumen utama terpisah, faktur) sesuai dengan perintah Layanan Pajak Federal tertanggal 24 Maret 2016 No. -7-15/155@ “Atas persetujuan format invoice dan format penyajian dokumen pengiriman barang (pelaksanaan pekerjaan), pengalihan hak milik (dokumen pemberian jasa), termasuk invoice, dalam bentuk elektronik."
Format dokumen utama tentang perubahan nilai, termasuk faktur penyesuaian, didukung (dalam hal transfer dokumen utama terpisah, faktur penyesuaian) sesuai dengan perintah Layanan Pajak Federal tertanggal 13 April 2016 N MMV -7-15/189@ " Atas persetujuan format faktur penyesuaian dan format penyampaian dokumen perubahan harga pokok pengiriman (pekerjaan yang dilakukan, jasa yang diberikan), pengalihan hak milik, termasuk faktur penyesuaian, di formulir elektronik."
Telah ditambahkan dokumen elektronik baru: Pemindahan barang, Pemindahan hasil pekerjaan, bentuk baru penyajian dokumen secara visual.
Telah ditambahkan mekanisme pertukaran satu arah yang tidak memerlukan pemberitahuan tanda terima dari penerima.
Menambahkan kemampuan untuk mengontrol pembongkaran dokumen elektronik yang masuk (secara otomatis atau manual), kemampuan untuk mengkonfigurasi pembuatan jenis dokumen tertentu saat menerima dokumen elektronik.
Menambahkan kemampuan untuk menghubungkan dokumen elektronik ke beberapa basis informasi dokumen akuntansi.
Pembagian dokumen elektronik menjadi dokumen masuk dan keluar telah diterapkan.
Integrasi dengan layanan telah diterapkan 1C-UMI memungkinkan Anda membuat situs web dari program, mengatur pertukaran dengan toko online UMI.
Adaptasi dibuat untuk bekerja dengan layanan 1C-EDO di layanan cloud 1CFresh.

Transisi ke versi 1.3.6 dari versi 1.3.5

Subsistem "Pertukaran dengan rekanan"

Modul umum ExchangewithCounterpartyRedefinable

Menambahkan metode UPD SCHFDOP.
Metode tambahan Isi Data untuk Informasi Pembeli UPD Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UPD (informasi pembeli) fungsi SCHFDOP.
Menambahkan fungsi metode UPD (informasi penjual) SCHFDOP ke objek keamanan informasi.
Metode tambahan Isi Data untuk Informasi TAMBAHAN Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik seperti fungsi DOP STD (informasi penjual).
Metode tambahan TemukanBuat Dokumen UPDTTentangTransfer. Metode ini menyimpan data dari dokumen elektronik fungsi UPD (informasi penjual) DOP ke dalam objek IS.
Metode tambahan Isi data untuk informasi SCHFISeller Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UTD (informasi penjual) fungsi SSF.
Metode tambahan TemukanBuatUPDSInvoiceInvoice. Metode ini menyimpan data dari dokumen elektronik fungsi UPD (informasi penjual) SSF ke dalam objek keamanan informasi.
Metode tambahan. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UCD (informasi penjual) fungsi KSCHFDIS.
Metode tambahan Isi Data Layanan Pajak Federal Informasi Pembeli UKID. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UKD (informasi pembeli) fungsi KSCHFDIS.
Metode tambahan. Metode ini menyimpan data dari dokumen elektronik UCD (informasi penjual) fungsi KSCHFDIS ke dalam objek keamanan informasi.
Metode tambahan Isi Data untuk DISInformasi Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik fungsi DIS tipe UCD (informasi penjual).
Metode tambahan TemukanBuatDokumenUKDTentangPerubahanNilai. Metode ini menyimpan data dari dokumen elektronik fungsi UCD (informasi penjual) DIS ke dalam objek IS.
Metode tambahan Isi data untuk informasi KSCHFISeller Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UCD (informasi penjual) fungsi KSCHF.
Metode tambahan TemukanBuatFaktur AkunUKDSA. Metode ini menyimpan data dari dokumen elektronik UCD (informasi penjual) yang berfungsi KSCHF menjadi objek keamanan informasi.
Metode tambahan Kesesuaian Jenis ULN Keluar dengan Dokumen Keamanan Informasi. Metode tersebut membentuk korespondensi antara dokumen elektronik keluar dan dokumen keamanan informasi.
Metode tambahan TemukanBuatDocumentTransferWorkHasil. Cara tersebut digunakan untuk mengisi dokumen Consignment Note yang diterima dengan format “Transfer Barang”.
Metode tambahan TemukanBuatDokumenTransfer Barang. Cara yang digunakan adalah dengan mengisi dokumen Sertifikat Pemberian Jasa yang diterima dalam format “Transfer Hasil Pekerjaan”.
Metode tambahan InstalledStateExchangeSelesai. Metode ini dipanggil ketika status aliran dokumen berubah menjadi Pertukaran Selesai, Pertukaran Selesai dengan koreksi.
Saat membuat dokumen elektronik UPD, UKD, Transfer barang, Transfer hasil pekerjaan, rincian Tanggal dokumen, Tanggal Basis Dokumen wajib diisi.

Memproses Pertukaran dengan Pihak Rekanan

Dalam tata letak "Torg-12Seller":

Menambahkan bidang "IdStateContract".
Bagian tabel "Faktur Transportasi" telah ditambahkan.
Bidang "Tanggal Faktur Transportasi", "Nomor Faktur Transportasi" telah dihapus.
Menambahkan bidang "Informasi tentang orang yang mentransfer barang".

Dalam tata letak Tindakan Pengalihan Hak:

Menambahkan bagian tabel "Dasar".
Bidang "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" telah dihapus.
Menambahkan bidang "Nama Mata Uang".
Menambahkan bidang "Klaim".
Menambahkan bidang "Tanggal Eksekusi".
Pada properti peserta transaksi, kolom "Faks" telah diganti dengan kolom "Email".
Pada properti peserta transaksi, kolom "Kode Negara" telah diganti dengan kolom "Kode Negara".
Di properti peserta transaksi, kolom "AddressText" telah diganti dengan kolom "AddressText".

Memperbarui Tipe yang Ditetapkan Pihak rekanan:

Saat memutakhirkan dari versi 1.3.5, perlu memperbarui tipe Counterparty yang ditentukan; jika tidak, referensi ke direktori Counterparty di objek BED, ketika diperbarui, akan diganti dengan tipe string dengan hilangnya referensi ke objek tanpa kemungkinan pemulihan.

Prosedur pembaruan:

Ganti nama tipe Akun yang ditentukan menjadi AccountBED.
Hapus konfigurasi dari mendukung BED 1.3.5.
Jalankan perbandingan/penggabungan dengan konfigurasi BED 1.3.5, setuju untuk mengatur konfigurasi menjadi support.
Hapus centang semua objek dan biarkan hanya jenis Akun yang ditentukan, lakukan penggabungan.
Mulai perbarui konfigurasi, pilih file BED 1.3.6.
Pilih kotak centang pada tipe yang ditentukan AccountBED dan Akun. Tentukan objek database lain yang diperlukan untuk diperbarui.
Lakukan pembaruan.

Subsistem "Tukarkan dengan bank"

Untuk prosedurnya Dapatkan Laporan Bank modul umum ExchangeWithBanksClient menambahkan parameter opsional Periode Klarifikasi OpenForm dengan tipe Boolean. Ini harus disetel ke True jika formulir dari mana pernyataan diterima tidak memiliki kemampuan untuk mengubah periode permintaan pernyataan secara manual.

Subsistem "Pertukaran dengan situs"

Node pertukaran berubah Pertukaran Situs, formulir, modul objek:

Menambahkan kemampuan untuk mengunggah Item dengan pilihan berdasarkan Tipe Item (sebelumnya hanya tersedia berdasarkan grup Item).

Menambahkan buku referensi Situs web:

Menambahkan kemampuan untuk mengonfigurasi transisi ke situs dari 1C - ke bagian pengguna situs, dan ke area admin situs.
Berdasarkan Situs, Anda dapat membuat node pertukaran ExchangeSite.

Pemrosesan tambahan Buat situs web:

Menambahkan kemampuan untuk membuat situs di domain 1C-UMI, situs dibuat secara otomatis (elemen Situs) dan diisi dengan data dari 1C. Node pertukaran ExchangeSite secara otomatis dibuat dan pertukaran penuh pertama dengan situs tersebut dilakukan.

Modul umum Pertukaran Situs Dapat Ditimpa:

Kemampuan untuk memilih Jenis Item telah ditambahkan; kemampuan untuk memilih buku referensi khusus telah dihapus.

Modul umum Acara ExchangeSite:

Menambahkan kemampuan untuk memilih Jenis item.
Kemampuan untuk memilih direktori khusus telah dihapus.

Perubahan lainnya

Pengaturan subsistem Manajemen tarif dalam model layanan perpustakaan Teknologi layanan

Ke modul umum Tarif Dapat Didefinisikan Ulang pada metode Saat Membentuk Daftar Layanan (), Anda perlu menambahkan kode setelah memanggil metode Dukungan Pengguna Internet Saat Membentuk Daftar Layanan (Penyedia Layanan):

// Interaksi Elektronik
Interaksi Elektronik. Saat Membentuk Daftar Layanan (Penyedia Layanan);
// Akhiri Interaksi Elektronik

Versi 1.3.5

Versi 1.3.5 adalah pengembangan dari "1C: Electronic Document Libraries 8" edisi 1.3, yang dirancang untuk memastikan pertukaran dokumen elektronik dalam solusi aplikasi yang dikembangkan pada platform 1C:Enterprise versi 8.3.8 dan lebih tinggi.

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

fungsionalitas perpustakaan disesuaikan dengan fitur spesifik bekerja pada platform 8.3.8 dengan mode kompatibilitas dinonaktifkan;
subsistem dari "Perpustakaan Subsistem Standar" telah diperbarui ke versi 2.3.3.45;
Perpustakaan mencakup subsistem "Perpustakaan Dukungan Pengguna Internet", versi 2.1.8.3.

Transisi ke versi 1.3.5 dari versi 1.3.4

Tidak diperlukan perubahan.

Versi 1.3.4

Versi 1.3.4 adalah pengembangan dari "1C: Electronic Document Libraries 8" edisi 1.3, yang dirancang untuk memastikan pertukaran dokumen elektronik dalam solusi aplikasi yang dikembangkan pada platform 1C:Enterprise versi 8.3.6 dan lebih tinggi. Dalam hal ini, properti konfigurasi "Mode Kompatibilitas" harus disetel ke "Jangan gunakan". Mode penggunaan modalitas dapat diatur ke "Jangan gunakan", dan mode kompatibilitas antarmuka dapat diatur ke "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

sistem notifikasi acara EDI telah diterapkan (dokumen elektronik baru, undangan baru, masa berlaku sertifikat, dll). Sekarang dimungkinkan untuk mengonfigurasi pemberitahuan email di profil pengaturan EDF, serta menampilkan pemberitahuan tentang acara secara langsung di program 1C menggunakan pesan pop-up;
format dokumen utama didukung, termasuk faktur (format UPD) sesuai dengan perintah Layanan Pajak Federal tanggal 24 Maret 2016 No. -7-15/155@ “Atas persetujuan format faktur dan format penyampaian dokumen pengiriman barang (pelaksanaan pekerjaan), pengalihan hak milik (dokumen pemberian jasa), termasuk invoice, dalam bentuk elektronik";
format dokumen perubahan nilai, termasuk faktur penyesuaian, telah didukung" (format UKD) sesuai dengan perintah Layanan Pajak Federal tertanggal 13/04/2016 N -7-15/189@ "Atas persetujuan format faktur penyesuaian dan format penyajian dokumen tentang perubahan harga pokok barang yang dikirim (pekerjaan yang dilakukan, jasa yang diberikan), pengalihan hak milik, termasuk faktur penyesuaian, dalam bentuk elektronik";
mendukung penggunaan komponen eksternal sebagai pertukaran dengan bank yang menggunakan teknologi DirectBank.

Transisi ke versi 1.3.4 dari versi 1.3.2, 1.3.3

Perubahan formulir daftar dokumen solusi aplikasi

Dalam formulir daftar dokumen, Anda perlu menambahkan prosedur plug-in Tukarkan dengan CounterpartyClient. Prosesor MenungguEDW:

&Pada Klien

Akhir Prosedur

Saat memperbarui subsistem, diperlukan formulir daftar dokumen di event handler: Saat DibuatDiServer, Saat Pembukaan, Peringatan Pemrosesan

&Di server
Prosedur Saat Membuat Di Server
…
ParametersWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
ParameterWhenCreatedOnServer.Form = Objek Ini;
ParametersWhenCreatedOnServer.LocationofCommands = Perintah Elements.EDO;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm(Kegagalan, Pemrosesan Standar, ParametersWhenCreatedOnServer);
Akhir Prosedur

&Pada Klien
Prosedur Pembukaan (Kegagalan)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

&Pada Klien
Pemberitahuan Proses Prosedur (Nama Peristiwa, Parameter, Sumber)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
Alert ParametersEDO = Tukarkan dengan CounterpartiesClient.AlertParametersEDO_ListForm();
Parameter Pemberitahuan EDO.Form = Objek Ini;
Parameter Pemberitahuan EDO.DynamicListName = "Daftar";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm(Nama Peristiwa, Parameter, Sumber, EDI AlertParameters);
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

Perubahan formulir dokumen solusi aplikasi

Dalam formulir dokumen Anda perlu menambahkan prosedur plug-in Connectable_WaitingHandlerEDO, di mana Anda perlu melakukan pemanggilan metode

Tukarkan dengan CounterpartyClient. Prosesor yang Menunggu EDW:

&Pada Klien
Prosedur Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(Objek Ini);
Akhir Prosedur

Dalam formulir dokumen, atribut formulir “Status EDO” perlu dihilangkan dan elemen formulir “dekorasi” ditambahkan sebagai gantinya. Untuk kebutuhan solusi aplikasi, dekorasi dapat disubordinasikan pada elemen bentuk “Grup”. Visibilitas grup diatur di dalam suatu metode Pertukaran dengan rekanan Saat dibuat di Server tergantung pada kondisi f.o. "Gunakan Pertukaran dengan Pihak Rekanan."

Saat memperbarui subsistem, diperlukan event handler dalam bentuk dokumen Saat DibuatDiServer, Saat Pembukaan, SetelahRecordingOnServer, Peringatan Pemrosesan tempatkan metode subsistem "Counterparty Exchange".

Misalnya:

&Di server

…
// Subsistem "Pertukaran dengan Pihak Rekanan".
Parameter EDO Saat Dibuat = Bertukar dengan Counterparty Parameter Saat Dibuat Di Server_DocumentForm();
Parameter EDO Saat Dibuat.Form = ThisObject;
Parameter EDO Saat Dibuat.DocumentLink = Object.Link;
Parameter EDOSaatDibuat.DecorStateEDO = Elemen.DecorationStateEDO;
Parameter EDO Saat Dibuat.EDO State Group = Elements.EDO State Group;
Pertukaran dengan Rekanan.Saat DibuatDi Server_DocumentForm(Penolakan, Pemrosesan Standar, Parameter EDOSaat Dibuat);
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

&Pada Klien
Prosedur Pembukaan (Kegagalan)
…
// Subsistem "Pertukaran dengan Pihak Rekanan"
ExchangeWithCounterpartiesClient.OnOpening(Objek Ini);
// Akhiri Subsistem "Pertukaran dengan Pihak Rekanan"
Akhir Prosedur

&Di server
Prosedur AfterRecordOnServer(CurrentObject, RecordParameters)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
ParametersAfterRecord = ExchangeWithCounterparties.ParametersAfterRecordOnServer();
ParameterAfterRecord.Form = Objek Ini;
ParameterAfterRecord.DocumentLink = Objek.Link;
ParameterAfterRecording.DecorationStateEDO = Elemen.DecorationStateEDO;
ParameterAfterRecord.GroupEDOStatus = Elemen.GroupEDOState;
ExchangewithCounterparty.AfterRecordOnServer(CurrentObject, RecordParameters,AfterRecordParameters);
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

&Pada Klien
Pemberitahuan Proses Prosedur (Nama Peristiwa, Parameter, Sumber)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
Parameter Peringatan = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
AlertParameters.Form = Objek Ini;
AlertParameters.DocumentLink = Objek.Tautan;
AlertParameters.DecorationEDOState = Elemen.DecorationEDOSstate;
Parameter Peringatan.Grup Negara EDO = Elemen.Grup Negara EDO;
ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm(EventName, Parameter, Sumber, AlertParameters);
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

Perubahan dalam modul ExchangeCounterparty

Prosedur ditambahkan Ketika CreatedOnServer_ListForm, dipanggil dari event handler "When CreatedOnServer" pada formulir daftar dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSaatMembuatDiServer_ListForm.
Prosedur ditambahkan Ketika CreatedOnServer_FormDocument, dipanggil dari event handler "When CreatedOnServer" pada formulir dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSaatMembuatDiServer_DocumentForm.
Prosedur ditambahkan SetelahRecordingOnServer, dipanggil dari pengendali kejadian "AfterRecordOnServer" pada formulir dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSetelahRecordingOnServer.

Perubahan modul Tukarkan dengan CounterpartyClient.

Prosedur ditambahkan Saat Pembukaan, dipanggil dari event handler "Saat Pembukaan" pada formulir daftar dokumen dan formulir dokumen.
Prosedur ditambahkan MemprosesAlerts_ListForm, dipanggil dari pengendali peristiwa "Pemrosesan Pemberitahuan" pada formulir daftar dokumen. Sebagai parameter keempat dari metode, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut Parameter PeringatanEDO_ListForm.
Prosedur ditambahkan MemprosesAlert_FormDocument, dipanggil dari pengendali peristiwa "Pemrosesan Pemberitahuan" pada formulir dokumen. Sebagai parameter keempat dari metode, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut Parameter PemberitahuanEDO_DocumentForm.
Perubahan modul Pertukaran dengan Pihak Rekanan Dapat Ditimpa:
Metode tambahan Isikan Data Transfer Pelaksana Pekerjaan.
Contoh:

// Menyiapkan data dokumen elektronik jenis Transfer Barang ke Penjual.
// Pilihan:
// LinkToObject - Tautan ke ED yang diperlukan untuk membuat dokumen elektronik,

Prosedur Isi Pelaksana Pekerjaan Transfer Data (Link Objek, Struktur ED, Pohon Data) Ekspor
Isi Data untuk Pelaksana Undang-Undang 501 Layanan Pajak Federal (Tautan ke Objek, Struktur ED, Pohon Data)
Akhir Prosedur

metode Kemampuan Memeriksa untuk Mengedit Objek menjadi sebuah prosedur.
Metode tambahan Isi Data untuk UPDInformasi Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik sejenis UPD(informasi penjual) fungsi SCHFDOP.
Metode tambahan TemukanBuatUniversalTransferDocument. Metode ini menyimpan data dari dokumen elektronik UPD(informasi penjual) fungsi SCHFDOPv objek IS.
Metode tambahan Isi Data Layanan Pajak Federal Informasi Penjual UKDI. Metode ini menyiapkan data untuk dokumen elektronik sejenis UKD(informasi penjual) fungsi KSCHFDIS.
Metode tambahan TemukanBuatDokumen Penyesuaian Universal. Metode ini menyimpan data dari dokumen elektronik UKD(informasi penjual) fungsi KSCHFDIS ke objek keamanan informasi.

Perubahan pada subsistem "Penukaran dengan Bank".

Perubahan pada modul ExchangeWithBanksRedefinable

Prosedur Ketika Kondisi ED Berubah ditambahkan. Dipanggil ketika status aliran dokumen elektronik berubah.

Perubahan untuk bekerja dalam mode layanan

Jika konfigurasi tujuan untuk pengoperasian dalam mode layanan diperlukan:

Dalam prosedur GetProvidedDataHandlers dari modul umum SuppliedDataOverridden, tambahkan kode berikut:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

Tambahkan tugas rutin Perbarui Pertukaran Modul Eksternal Dengan Bank ke atribut umum Data Area Basic Data.

Perubahan lainnya

Anda harus menambahkan konstanta ke tipe yang sedang didefinisikan Gunakan ExchangeWithBanks;
Fitur yang dihapus Penukaran Dengan Bank Penukaran Langsung Dengan Bank Direkomendasikan.

Versi 1.3.3

Versi 1.3.3 merupakan pengembangan dari produk "1C: Library of Electronic Documents" edisi 1.3. Dirancang untuk mengembangkan konfigurasi yang dirancang untuk bekerja pada platform 1C:Enterprise 8.3 versi 8.3.6 dan lebih tinggi.

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

sesuai dengan Surat Perintah tanggal 30 November 2015 No. ММВ-7-10/551@ “Atas persetujuan format penyampaian dokumen pemindahtanganan barang pada saat transaksi perdagangan dalam bentuk elektronik” dan Surat Perintah tanggal 30 November 2015 No. ММВ-7-10/552@ "Atas persetujuan format penyampaian dokumen transfer hasil pekerjaan (dokumen pemberian jasa) dalam bentuk elektronik" format baru dokumen elektronik didukung.

Perubahan pada subsistem "Pertukaran dengan rekanan"

Di dalam modul Pertukaran dengan Pihak Rekanan Dapat Ditimpa membuat perubahan:

// Menyiapkan data untuk dokumen elektronik jenis Nota Konsinyasi.
// Pilihan:
// LinkOnED - Tautan ke ED yang diperlukan untuk membuat dokumen elektronik,
// StructureED - Struktur, struktur data untuk menghasilkan dokumen elektronik.
// Pohon Data - pohon nilai, pohon data untuk mengisi dokumen elektronik.
Tata Cara Pengisian Data Transfer Barang Penjual (Object Link, Struktur ED, Data Tree) Ekspor
Isi Data Tawar-menawar 12 Penjual Layanan Pajak Federal (Tautan ke Objek, Struktur ED, Pohon Data)
Akhir Prosedur

Perlu ditambahkan ke konfigurasi yang menggunakan BED, templat untuk membatasi akses pada tingkat catatan berdasarkan organisasi (RLS) saat bekerja dengan dokumen elektronik (lihat dokumentasi penyematan).

Versi 1.3.2

Versi 1.3.2 merupakan pengembangan dari produk "1C: Library of Electronic Documents" edisi 1.3. Dirancang untuk mengembangkan konfigurasi yang dirancang untuk bekerja pada platform 1C:Enterprise 8.3 versi 8.3.6 dan lebih tinggi.

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

dilaksanakan tampilan 2 judul dokumen elektronik (TORG12, UU, Dokumen Penyesuaian) dalam satu bentuk untuk melihat dokumen elektronik. Semua informasi dari judul akan dikumpulkan dalam satu formulir. Secara terpisah, bentuk judul kedua dapat dilihat dari formulir “Dokumen Elektronik”;
kemampuan untuk menyimpulkan "Perjanjian EDA" standar dalam bentuk elektronik dari "Pengaturan EDF" dalam program 1C telah diterapkan; Dengan menggunakan perintah “Buat perjanjian menggunakan templat”, dokumen elektronik sewenang-wenang akan dibuat secara otomatis, yang lampirannya akan menjadi file perjanjian. Setelah penandatanganan, dokumen dapat langsung dikirim ke rekanan.
pertukaran terintegrasi dokumen elektronik sewenang-wenang dengan file terlampir. Sekarang file terlampir apa pun dapat dengan cepat ditandatangani dan dikirim ke rekanan menggunakan dokumen elektronik apa pun;
kemampuan untuk bertukar dokumen elektronik dengan bank mengenai proyek gaji didukung;
menambahkan asisten untuk menghubungkan organisasi ke DirectBank;
daftar bank yang mendukung DirectBank diperbarui melalui Internet;
Pekerjaan yang didukung dengan berbagai jenis token (kunci elektronik) dari Bank Tabungan: "biasa", "sentuh", "dengan layar".
Subsistem dari "Perpustakaan Subsistem Standar" (BSS) telah diperbarui ke versi 2.3.2.27.

Transisi ke versi 1.3.2.19 dari versi 1.2.7, 1.3.1

Anda perlu menambahkan prosedur tanpa padding ke modul:

prosedur PemeriksaanMenggunakanTestMode. Termasuk kemampuan untuk mengaktifkan fitur tambahan untuk menguji pertukaran dengan bank. Belum ada rencana untuk menggunakannya dalam solusi terapan;

Di dalam modul RegularTasksOverridable membuat perubahan:

Tata Cara Penentuan Setting Tugas Rutin (Settings) Ekspor
Interaksi Elektronik. Saat MendefinisikanPengaturan Tugas Rutin(Pengaturan);
Akhir Prosedur

Di dalam modul ElectronicSignatureClientDapat Ditimpa membuat perubahan:

Tata Cara Ekspor Verifikasi Sertifikat Tambahan (Parameter).
ExchangeWithBanksClient.PadaVerifikasi Sertifikat Tambahan(Parameter);
Akhir Prosedur

Ke modul Tanda Tangan Elektronik Dapat Ditimpa membuat perubahan:

Tata Cara Pembuatan Formulir Pengecekan Sertifikat (Sertifikat, Pengecekan Tambahan, Parameter Pengecekan Tambahan, Pengecekan Standar) Ekspor
ExchangeWithBanks.WhenCreatingFormVerificationCertificate(
Sertifikat, Pemeriksaan Tambahan, Parameter Pemeriksaan Tambahan, Pemeriksaan Standar);
Akhir Prosedur

Objek yang tidak dibagikan berikut ini telah ditambahkan:

;

Konstan Pertukaran File Umum Dengan Bank.

Untuk tipe yang ditentukan Opsi Fungsional Ruang Penyimpanan tambahkan konstanta Gunakan ExchangeWithBanks.

Jika konfigurasi dimaksudkan untuk bekerja dalam mode model layanan, maka Anda perlu mengubah Pengendali Langganan ke acara Kontrol Objek yang Tidak Dibagikan Saat Menulis BED untuk Bekerja Dalam Model Layanan.Kontrol Objek yang Tidak Dibagikan Saat Menulis.

Versi 1.3.1

Versi 1.3.1 merupakan pengembangan dari produk "1C: Library of Electronic Documents" edisi 1.2. Dirancang untuk mengembangkan konfigurasi yang dirancang untuk bekerja pada platform 1C:Enterprise 8.3 versi 8.3.6 dan lebih tinggi.

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

kemampuan untuk bertukar dokumen elektronik tanpa tanda tangan elektronik melalui layanan EDI telah diterapkan untuk 1C: peserta Jaringan Bisnis;
subsistem pertukaran otonom dengan bank telah diterapkan;
Subsistem dari "Perpustakaan Subsistem Standar" (BSS) telah diperbarui ke versi 2.3.1.71.

Transisi ke versi 1.3.1 dari versi 1.2.6, 1.2.7

Perubahan arsitektur

Semua modul dengan awalan "Dokumen Elektronik" telah diubah namanya menjadi modul dengan awalan "Pertukaran dengan Pihak Rekanan". Metode modul Tujuan Umum dipindahkan ke modul baru Interaksi Elektronik. Modul Memperbarui Basis Informasi ED diganti namanya menjadi Memperbarui Basis Data.

Dokumen Elektronik V Interaksi Elektronik:

Nama belakangInisialPerorangan

Daftar metode yang dipindahkan dari modul Dokumen Elektronik V PertukaranDenganBank:

Pertukaran langsung dengan bank dimungkinkan
DapatkanDataBankStatementsTreeValues
DapatkanDataBankStatementsTextFormat
Parsing TreeExtractsBank

Daftar metode yang telah dipindahkan dari modul ke ElectronicInteractionClientDapat Ditimpa:

Lakukan Pemeriksaan Dokumen

Daftar metode yang dipindahkan dari modul ElectronicDocumentsClientDapat Ditimpa V ExchangeWithBanksClientDapat Ditimpa:

ParseFileExtracts

Daftar metode yang telah dipindahkan dari modul ke Server Klien Interaksi Elektronik:

GetMessageText (berganti nama menjadi MessageText)
Reaksinya

Daftar metode yang dipindahkan dari modul Dokumen ElektronikClientServer V ExchangeWithBanksClientServer:

Terisi DetailsSettings EDSBanks (berganti nama Terisi DetailsSettingsExchange)
HeaderSettingsEDOSBank telah diubah namanya menjadi HeaderSettingsExchangeWithBank
DapatkanStatusTextED

Daftar metode yang telah dipindahkan dari modul ke Interaksi Elektronik Dapat Ditimpa:

UbahFormElementProperties
File Sementara Direktori Saat Ini
Dapatkan Opsi Fungsional yang Cocok
Dapatkan Direktori yang Cocok
Dapatkan Korespondensi Nama Objek MD dan Detailnya
Korespondensi Kode Detail dan Representasi
Dapatkan Struktur Detail Utama Objek
Pesan Teks Diperlukan Pengaturan Sistem
Sunting Pesan Kesalahan
Siapkan MessageText tentang Pelanggaran Hak Akses
Bongkar NamaIndividu
TemukanReferenceToObject
Dapatkan Nomor Dokumen Cetak
Periksa Kesiapan Sumber
GetData LegalIndividu
DeskripsiOrganisasi
Ada Hak untuk Memproses DE
Ada hak untuk membaca ED
Ada Hak untuk Membuka Registrasi Jurnal

Daftar metode yang dipindahkan dari modul Dokumen Elektronik Dapat Ditimpa V ExchangeWithBanksDapat Ditimpa:

Dapatkan Jenis DE Saat Ini
Dapatkan Nomor Rekening Bank
Isikan Parameter ED Berdasarkan Sumber
Isi Data Perintah Pembayaran
Isi Data Permintaan Pembayaran
Kemampuan Memeriksa untuk Mengedit Objek

Dari langganan acara Tetapkan ED Versi Baru Saat Merekam Pemiliknya Dan PeriksaPerubahanSebelumPemilikRekamanED Dokumen bank telah dihapus.

Tata letak dipindahkan dari pemrosesan PertukaranCounterparty V PertukaranDenganBank:

Perintah pembayaran
Persyaratan Pembayaran

Anda harus menambahkan ke tipe yang ditentukan

documentObject.PackageED

Perubahan antarmuka

Dalam modul umum PertukaranDenganBank, PertukaranCounterparty prosedur ditambahkan Saat DibuatDiServer. Dipanggil saat membuka formulir objek untuk menghasilkan perintah EDI. Pilihan: Membentuk– bentuk saat ini, Penempatan TimDefault– elemen formulir submenu tempat perintah EDI akan dibuat.
Dalam modul umum ExchangeWithBanksDapat Ditimpa, Pertukaran dengan Pihak Rekanan Dapat Ditimpa menambahkan prosedur untuk menghasilkan daftar perintah EDM Menyiapkan Struktur Objek Tim EDF. Parameter Komposisi TimEDO dapat berupa array (untuk subsistem PertukaranDenganBank) atau struktur array ( PertukaranCounterparty).
Grup perintah EDI telah dihapus; pengisian otomatis panel perintah dengan perintah EDI tidak lagi dilakukan.

Untuk membuat perintah EDM dalam formulir dokumen infobase, Anda perlu menambahkan kode untuk menghasilkan tipe objek dalam prosedur modul umum yang diganti.

Contoh dalam modul Pertukaran dengan Pihak Rekanan Dapat Ditimpa:

Susunan Tim EDM.Outgoing.Add("Dokumen.Penjualan Barang dan Jasa");
Komposisi Perintah EDO.Outgoing.Add("Dokumen.Pesanan Pembeli");
…
Susunan Tim EDF.Incoming.Add("Dokumen.Kwitansi Barang dan Jasa");
Komposisi Perintah EDO.Incoming.Add("Document.InvoiceReceived");
…
Akhir Prosedur

ExchangeWithBanksDapat Ditimpa:

Prosedur Menyiapkan Struktur Objek Tim EDF (Susunan Tim EDF) Ekspor
Komposisi Perintah EDO.Add("Dokumen.Pesanan Pembayaran");
Komposisi Perintah EDO.Add("Document.PaymentRequest");
…
Akhir Prosedur

Saat membuat formulir, panggil program pembuatan perintah

Pertukaran dengan rekanan Saat dibuat di Server:

Prosedur Saat DibuatDiServer (Kegagalan, Pemrosesan Standar)
//Perintah EDO
Pertukaran dengan Rekanan.Ketika CreatedOnServer(ThisObject, Elements.EDO Commands);
// Akhir dari Perintah EDO
Akhir Prosedur

Tambahkan pengendali formulir yang dapat dicolokkan Connectable_Jalankan Perintah EDO:

Prosedur Connectable_Execute Perintah EDO (Perintah)
ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO(Command, ThisForm, Elements.List);
Akhir Prosedur

Perubahan pada subsistem "Pertukaran dengan rekanan"

isi jenis yang ditentukan "Alasan ED Sewenang-wenang" dengan jenis dokumen yang menjadi dasar entri akan dimasukkan ED sewenang-wenang(kemungkinan besar ini akan menjadi dokumen yang sama seperti pada tipe yang ditentukan Pemilik File Terlampir), juga dalam dokumen ini Anda perlu menambahkan dokumen "ED Khusus" ke daftar "Apakah dasar untuk:"
dalam formulir dokumen dan daftar dokumen (yang menjadi dasar penulisan ULN Khusus), ULN Khusus perlu dinonaktifkan pada submenu “Buat berdasarkan”, karena perintah untuk memasukkan Custom ED ditempatkan pada submenu EDO (perintah "Tambah file");
dalam tata letak Akta Pengalihan Hak, Pemesanan Barang, Tanggapan Pesanan, Laporan Agen Komisi Penjualan, Laporan Agen Komisi Atas Uraian, Faktur Pembayaran, Katalog Produk, Daftar Harga pada kelompok parameter "Bank" pada kolom "BIC" atribut pengisian wajib telah diubah. Bidang ini harus diisi;
pada tata letak InvoiceInvoice, format kolom Kode Negara Asal dan Nomor Pemberitahuan Pabean telah berubah. Untuk pengisian yang lebih benar, digabungkan ke dalam tabel Pemberitahuan Pabean. Contoh pengisian elemen-elemen ini dalam prosedur penyiapan data ESF dapat dilihat di demo database BED.

Perubahan pada modul ExchangewithCounterpartiesClient

Metode OpenEDList sudah tidak digunakan lagi. Sebagai gantinya, disarankan untuk menggunakan OpenEDTree, yang membuka pengguna pada pohon peraturan untuk pertukaran dokumen elektronik untuk dokumen keamanan informasi.

Perubahan pada modul Interaksi Elektronik Ditimpa

Dua kunci telah ditambahkan ke Dapatkan Korespondensi dengan Nama Objek dan Detail untuk redefinisi:

Penjualan Barang dan Jasa di Metadata
Penerimaan Barang dan Jasa di Metadata

Perubahan dalam modul ExchangeCounterparty

Menambahkan metode Isi DataBy 1SEDOD untuk Master 1C-Reporting, yang menyiapkan data untuk Master 1C-Reporting.

Menambahkan metode Check AccounterV1EDMSWhen CreatedOnServer, yang harus dipanggil saat membuat formulir akun. Metode ini menjalankan pemeriksaan koneksi rekanan ke layanan 1C-EDO.
Contoh Pertukaran dengan rekanan Periksa rekanan dalam 1 SEDO saat dibuat di Server:

Prosedur Saat DibuatDiServer (Kegagalan, Pemrosesan Standar)
// Interaksi Elektronik Pertukaran dengan Pihak Rekanan
Pertukaran dengan Counterparty Periksa Counterparty di 1SEDO Saat CreatedOnServer(Object.Link);
// Akhiri Interaksi Elektronik Pertukaran dengan Pihak Rekanan
Akhir Prosedur

Ditambahkan BUKAN membagi tugas rutin Memeriksa CounterpartyBED, yang memilih rekanan dan memeriksa koneksi mereka ke 1C-EDO.

Menambahkan daftar informasi terpisah Status CounterpartyBED, yang mengumpulkan statistik kontraktor yang terhubung ke layanan 1C-EDO.

Tambahkan tampilan tanda koneksi ke layanan 1C-EDO pada kolom "EDO" pada form daftar dan form pemilihan rekanan. Tambahkan petunjuk ke kolom "Terhubung ke layanan 1C-EDO".
Contoh:

MEMILIH
PILIHAN
WHENCcounterparty StatusBED.Status = VALUE(Enumeration.CounterpartyStateBED.Connected)
LALU 0
LAINNYA 1
AKHIR
AKHIR SEPERTI EDO
DirektoriCounterparty.Nama,
DirektoriCounterparty.INN,
DirektoriCounterparty.KPP,
....
DirektoriCounterparty.NameFull
DARI
Direktori.Counterparty SEBAGAI DirectoryCounterparty
KONEKSI KIRI Daftar Informasi Status Kontraktor BED SEBAGAI Status Kontraktor BED
Perangkat Lunak (Contractor StatesBED.Counterparty = DirectoryCounterparties.Link)

Pada formulir dokumen basis informasi, perlu untuk menghapus tautan ke opsi fungsional "Gunakan ED Exchange" dari atribut formulir "ED State Text". Hapus header dari atribut “ED Status”.

Perubahan pada subsistem "Penukaran dengan Bank".

Menambahkan langganan acara ExchangeWithBanksOwnerEDSebelum Merekam Dan ExchangeWithBanksOwnerEDOnRecording.

Menambahkan tipe yang ditentukan OwnersExchangeWithBanks dan DirectoryBanks.
Menambahkan perintah umum SettingsExchangeWithBanks.

Untuk tipe yang ditentukan File terlampir menambahkan:

direktoriLink.MessageExchangeWithBanksAttachedFiles;
direktoriObject.MessageExchangeWithBanksAttachedFiles;
direktoriLink.PackageExchangeWithBanksAttachedFiles;
direktoriObject.PackageExchangeWithBanksAttachedFiles.

Untuk tipe yang ditentukan Pemilik File Terlampir perlu ditambahkan

documentLink.MessageExchangeWithBanks;
documentLink.PackageExchangeWithBanks.

Untuk tipe yang ditentukan PemilikAttachedFilesObject perlu ditambahkan

documentObject.MessageExchangeWithBanks;
documentObject.PackageExchangeWithBanks;
documentObject.PackageED

Menambahkan subsistem baru "Jaringan Bisnis"

Subsistem mencakup modul umum (awalan ExchangeBusinessNetwork), perlakuan Jaringan Bisnis, peran ( AdministrasiPelangganBisnisJaringan, MelakukanExchangeBusinessNetwork), daftar informasi PengidentifikasiBusinessNetwork. Pada formulir "Pengaturan pertukaran dokumen elektronik", telah ditambahkan perintah untuk memanggil formulir koneksi layanan.

Prosedur dan fungsi dalam modul perlu diselesaikan BusinessNetworkDapat Ditimpa:

metode Buat Counterparty Sesuai Detail. Membuat rekanan dalam solusi aplikasi menggunakan parameter yang diteruskan;
metode Dapatkan Kontak Pengguna IB. Menerima informasi kontak pengguna (nama peran, alamat email);
metode Jalankan Pengendalian Detail Dokumen. Memeriksa detail dokumen untuk mengizinkan pengiriman array (pengirim dan penerima harus sama).

Transisi ke versi 1.3.7 dari versi 1.3.6

Dalam formulir untuk mengunggah dokumen pembayaran ke file dan mengunduh laporan bank dari file (pemrosesan Bank Klien) memindahkan sekelompok elemen GrupPeriklananLangsungBankHorizontal dari bentuk umum PenawaranConnect1SDirectBank.

Dalam bentuk event handler Saat DibuatDiServer metode tempat ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&Di server
Prosedur Saat CreateOnServer (Kegagalan, Pemrosesan Standar)
…
// Interaksi Elektronik Pertukaran Dengan Bank
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
Elements.GroupAdvertisingDirectBankHorizontal, Elements.TextDirectBankHorizontal);
// Akhiri Interaksi Elektronik Pertukaran Dengan Bank
Akhir Prosedur

Dalam bentuk event handler Peringatan Pemrosesan tempatkan metode ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

&Pada Klien
Pemberitahuan Proses Prosedur (Nama Peristiwa, Parameter, Sumber)
…
// Interaksi Elektronik Pertukaran Dengan Bank
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(NamaAcara,
Elements.GroupAdvertisingDirectBankHorizontal, Elements.TextDirectBankHorizontal);
// Akhiri Interaksi Elektronik Pertukaran Dengan Bank
Akhir Prosedur

Untuk elemen TextDirectBank Secara Horisontal tambahkan pengendali acara Memproses Tautan Navigasi dan tempatkan di dalamnya metode ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank:

&Pada Klien
Teks ProsedurDirectBankHorizontalNavigationLinkProcessing(Elemen, FormattedStringNavigationLink, StandardProcessing)
ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
NavigationLinkFormatString, Pemrosesan Standar);
Akhir Prosedur

Untuk prosedurnya Dapatkan Korespondensi Nama Objek dan Detail MDI modul umum Interaksi Elektronik tambahkan elemen kecocokan dengan kunci PembayaranPesananDalamMetadata dan nilai: nama objek metadata Perintah pembayaran dalam solusi aplikasi.

09.06.2017

Versi baru 1.3.8 dari konfigurasi standar "1C: Library of Electronic Documents 1.3" telah dirilis.

Versi 1.3.8

Fitur dan perubahan baru

Dalam formulir pencarian penawaran dagang, kemampuan untuk mencari tanpa terhubung ke layanan 1C: Business Network telah ditambahkan, dan kemampuan untuk mencari pemasok berdasarkan nama telah ditambahkan.
Menambahkan laporan tentang penawaran perdagangan yang dipublikasikan.
Tempat kerja untuk menerbitkan penawaran perdagangan di layanan 1C:Business Network telah ditambahkan.
Adaptasi dilakukan dengan subsistem "1C: Library of Standard Subsystems" versi 2.4.2, "1C: Library of Internet User Support" versi 2.2.2.

Transisi ke versi 1.3.8 dari versi 1.3.7

Perubahan modul:

Fitur tambahan Teks Permintaan untuk Produk yang Diterbitkan untuk mendapatkan sumber data untuk menerbitkan penawaran dagang dan menghasilkan laporan tentang barang yang dipublikasikan. Penting untuk mengimplementasikan pemanggilan fungsi ke metode FillOfferPackage saat menerima daftar produk.

Perubahan modul Penawaran Dagang

Prosedur ditambahkan UpdateDecorationConditionsPublikasi untuk memperbarui elemen formulir Dekorasi dengan status publikasi. Anda harus menambahkan pengaturan penerbitan untuk elemen status ke panggilan pada formulir.

Peran ditambahkan Laporan Penawaran Perdagangan diperlukan untuk mengakses laporan Penawaran Dagang yang Diterbitkan.

Versi 1.3.7

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

Menambahkan kemampuan untuk mendapatkan status dokumen pembayaran dari Bank Tabungan.
Menerapkan penerimaan otomatis pengaturan untuk Bank Tabungan saat menghubungkan ke layanan 1C:DirectBank.
Menambahkan kemampuan untuk menampilkan iklan kontekstual 1C:DirectBank.
Adaptasi telah dilakukan untuk bekerja dengan layanan 1C: Business Network di layanan cloud 1CFresh.
Menambahkan kemampuan untuk mempublikasikan, mencari, dan memesan penawaran dagang di layanan 1C: Penawaran Dagang untuk peserta dalam layanan 1C: Business Network.
Adaptasi dilakukan dengan subsistem "1C: Library of Standard Subsystems" versi 2.4.1, "1C: Library of Internet User Support" versi 2.1.9, "1C: Library of Service Technology" versi 1.0.12.

Transisi ke versi 1.3.7 dari versi 1.3.6

Subsistem "Pertukaran dengan rekanan"

Perubahan modul:

Tanggal dokumen, Tanggal Basis Dokumen

Subsistem "Pertukaran dengan bank"

Perubahan modul Bekerja Dengan FilesOverridable:

Untuk prosedurnya Saat Menentukan Pengaturan Anda perlu menambahkan kode:

Interaksi Elektronik.Saat MendefinisikanPengaturan(Pengaturan);

Untuk prosedurnya Saat Mendefinisikan Direktori Penyimpanan File Anda perlu menambahkan kode:

Interaksi Elektronik. Saat Mendefinisikan Direktori Penyimpanan File (Jenis Pemilik File, Nama Direktori);

Direktori MessageExchangeWithBanksAttachedFiles dan EDAttachedFiles telah ditambahkan ke rencana pertukaran UpdateInformationBase
Direktori MessageExchangeWithBanksAttachedFiles dan EDAttachedFiles telah ditambahkan ke tipe SignedObject yang ditentukan.

Dalam bentuk event handler Saat DibuatDiServer metode tempat ExchangeWithBanksClientServer.ShowAdvertisingDirectBank:

&Di server
Prosedur Saat CreateOnServer (Kegagalan, Pemrosesan Standar)
…
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

Akhir Prosedur

Dalam bentuk event handler Peringatan Pemrosesan tempatkan metode ExchangeWithBanksClient.UpdateAdvertisingDirectBank:

&Pada Klien

…
// Interaksi Elektronik Pertukaran Dengan Bank
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(NamaAcara,
Elements.GroupAdvertisingDirectBankHorizontal, Elements.TextDirectBankHorizontal);
// Akhiri Interaksi Elektronik Pertukaran Dengan Bank
Akhir Prosedur

Subsistem "Pertukaran dengan situs"

Perubahan modul Pertukaran Situs Dapat Ditimpa:

Prosedur ditambahkan Tambahkan DetailFormNode, digunakan untuk menambahkan detail ke node rencana pertukaran dari Pertukaran dengan situs. Formulir simpul pertukaran tidak mengasumsikan adanya rincian yang terkait dengan solusi aplikasi; rincian ditambahkan secara terprogram.
Prosedur ditambahkan Bidang MasukanSaat DiubahDiServer, digunakan untuk memproses peristiwa di utara Ketika bidang input formulir simpul rencana pertukaran diubah, ditambahkan dalam prosedur Tambahkan NodeFormDetails.
Prosedur ditambahkan Kotak CentangBidangKetikaDiubahDiServer, digunakan untuk memproses acara di server Ketika bidang bendera formulir simpul rencana pertukaran, yang ditambahkan dalam prosedur Tambahkan NodeFormDetails, diubah.
Prosedur ditambahkan WhenCreatingOnServerFormCreateSite, digunakan untuk menambahkan detail ke formulir pemrosesan CreateSite.

Perubahan modul ExchangeSiteClientDapat Ditimpa:

Prosedur yang dihapus Tentukan Jenis Katalog GroupTableU, tipe nilai kolom Grup pada tabel Katalog Produk ditentukan oleh pengaturan pertukaran.
Prosedur ditambahkan InputFieldOnChange, dipanggil untuk memproses acara Ketika bidang input formulir simpul rencana pertukaran diubah, ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails.
Prosedur ditambahkan Kotak centangFieldOnChange, dipanggil untuk memproses acara Ketika bidang bendera formulir simpul rencana pertukaran yang ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails diubah.
Prosedur ditambahkan TableFormBeforeFinishEditing, dipanggil untuk memproses peristiwa BeforeFinishEdit bidang di bagian tabel bentuk node rencana pertukaran yang ditambahkan dalam prosedur SiteExchangeOverridden.AddNodeFormDetails.

Subsistem "Jaringan bisnis"

Menambahkan metode baru untuk menjalankan tugas rutin dalam mode terpisah, modul umum Interaksi Elektronik, Prosedur Setelah Menerima Daftar Template, . Lihat metode dengan nama yang sama di modul umum JobQueueOverridable.
Saat menyematkan perpustakaan, agar berfungsi dalam mode terpisah, Anda perlu menambahkan panggilan ke metode di modul umum JobQueueDapat Ditimpa:
- dalam prosedur Setelah Menerima Daftar Template:

// Interaksi Elektronik
ElectronicInteraction.OnReceiveListTemplates(TaskTemplates);

dalam prosedur Saat Mendefinisikan AliasesHandlers:

// Interaksi Elektronik
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// Akhiri Interaksi Elektronik

Perubahan modul BusinessNetworkDapat Ditimpa:
- prosedur diganti namanya Dapatkan Kontak Pengguna IB V Dapatkan Informasi Kontak Pengguna.
- prosedur diubah menjadi berfungsi Buat Counterparty Sesuai Detail, parameter Akun telah dihapus.

Subsistem "Penawaran dagang"

Subsistem baru "Penawaran dagang" telah ditambahkan; untuk penyematan Anda memerlukan:

Kembangkan metode yang diganti dalam modul umum TradeOffersClientDapat Ditimpa, TradeOffersDapat Ditimpa.
Tentukan tipe data dalam tipe yang ditentukan Jenis Nilai Detail 1СBusinessNetwork, Jenis Nomenklatur BED, Detail tambahanBED, Penawaran Dagang.

Lihat dokumentasi penyematan untuk detailnya.

Versi 1.3.6

Fitur dan perubahan baru

Format dokumen faktur utama didukung (dalam hal transfer dokumen utama terpisah, faktur) sesuai dengan perintah Layanan Pajak Federal tertanggal 24 Maret 2016 No. -7-15/155@ “Atas persetujuan format invoice dan format penyajian dokumen pengiriman barang (pelaksanaan pekerjaan), pengalihan hak milik (dokumen pemberian jasa), termasuk invoice, dalam bentuk elektronik."
Format dokumen utama tentang perubahan nilai, termasuk faktur penyesuaian, didukung (dalam hal transfer dokumen utama terpisah, faktur penyesuaian) sesuai dengan perintah Layanan Pajak Federal tertanggal 13 April 2016 N MMV -7-15/189@ " Atas persetujuan format faktur penyesuaian dan format penyampaian dokumen perubahan harga pokok pengiriman (pekerjaan yang dilakukan, jasa yang diberikan), pengalihan hak milik, termasuk faktur penyesuaian, di formulir elektronik."
Telah ditambahkan dokumen elektronik baru: Pemindahan barang, Pemindahan hasil pekerjaan, bentuk baru penyajian dokumen secara visual.
Telah ditambahkan mekanisme pertukaran satu arah yang tidak memerlukan pemberitahuan tanda terima dari penerima.
Menambahkan kemampuan untuk mengontrol pembongkaran dokumen elektronik yang masuk (secara otomatis atau manual), kemampuan untuk mengkonfigurasi pembuatan jenis dokumen tertentu saat menerima dokumen elektronik.
Menambahkan kemampuan untuk menghubungkan dokumen elektronik ke beberapa basis informasi dokumen akuntansi.
Pembagian dokumen elektronik menjadi dokumen masuk dan keluar telah diterapkan.
Integrasi dengan layanan telah diterapkan 1C-UMI memungkinkan Anda membuat situs web dari program, mengatur pertukaran dengan toko online UMI.
Adaptasi dibuat untuk bekerja dengan layanan 1C-EDO di layanan cloud 1CFresh.

Transisi ke versi 1.3.6 dari versi 1.3.5

Subsistem "Pertukaran dengan rekanan"

Modul umum ExchangewithCounterpartyRedefinable

Menambahkan metode UPD SCHFDOP.
Metode tambahan Isi Data untuk Informasi Pembeli UPD Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UPD (informasi pembeli) fungsi SCHFDOP.
Menambahkan fungsi metode UPD (informasi penjual) SCHFDOP ke objek keamanan informasi.
Metode tambahan Isi Data untuk Informasi TAMBAHAN Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik seperti fungsi DOP STD (informasi penjual).
Metode tambahan TemukanBuat Dokumen UPDTTentangTransfer. Metode ini menyimpan data dari dokumen elektronik fungsi UPD (informasi penjual) DOP ke dalam objek IS.
Metode tambahan Isi data untuk informasi SCHFISeller Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UTD (informasi penjual) fungsi SSF.
Metode tambahan TemukanBuatUPDSInvoiceInvoice. Metode ini menyimpan data dari dokumen elektronik fungsi UPD (informasi penjual) SSF ke dalam objek keamanan informasi.
Metode tambahan. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UCD (informasi penjual) fungsi KSCHFDIS.
Metode tambahan Isi Data Layanan Pajak Federal Informasi Pembeli UKID. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UKD (informasi pembeli) fungsi KSCHFDIS.
Metode tambahan. Metode ini menyimpan data dari dokumen elektronik UCD (informasi penjual) fungsi KSCHFDIS ke dalam objek keamanan informasi.
Metode tambahan Isi Data untuk DISInformasi Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik fungsi DIS tipe UCD (informasi penjual).
Metode tambahan TemukanBuatDokumenUKDTentangPerubahanNilai. Metode ini menyimpan data dari dokumen elektronik fungsi UCD (informasi penjual) DIS ke dalam objek IS.
Metode tambahan Isi data untuk informasi KSCHFISeller Layanan Pajak Federal. Metode tersebut menyiapkan data untuk dokumen elektronik jenis UCD (informasi penjual) fungsi KSCHF.
Metode tambahan TemukanBuatFaktur AkunUKDSA. Metode ini menyimpan data dari dokumen elektronik UCD (informasi penjual) yang berfungsi KSCHF menjadi objek keamanan informasi.
Metode tambahan Kesesuaian Jenis ULN Keluar dengan Dokumen Keamanan Informasi. Metode tersebut membentuk korespondensi antara dokumen elektronik keluar dan dokumen keamanan informasi.
Metode tambahan TemukanBuatDocumentTransferWorkHasil. Cara tersebut digunakan untuk mengisi dokumen Consignment Note yang diterima dengan format “Transfer Barang”.
Metode tambahan TemukanBuatDokumenTransfer Barang. Cara yang digunakan adalah dengan mengisi dokumen Sertifikat Pemberian Jasa yang diterima dalam format “Transfer Hasil Pekerjaan”.
Metode tambahan InstalledStateExchangeSelesai. Metode ini dipanggil ketika status aliran dokumen berubah menjadi Pertukaran Selesai, Pertukaran Selesai dengan koreksi.
Saat membuat dokumen elektronik UPD, UKD, Transfer barang, Transfer hasil pekerjaan, rincian Tanggal dokumen, Tanggal Basis Dokumen wajib diisi.

Memproses Pertukaran dengan Pihak Rekanan

Dalam tata letak "Torg-12Seller":

Menambahkan bidang "IdStateContract".
Bagian tabel "Faktur Transportasi" telah ditambahkan.
Bidang "Tanggal Faktur Transportasi", "Nomor Faktur Transportasi" telah dihapus.
Menambahkan bidang "Informasi tentang orang yang mentransfer barang".

Dalam tata letak Tindakan Pengalihan Hak:

Menambahkan bagian tabel "Dasar".
Bidang "DocumentBaseName", "DocumentBaseNumber", "DocumentBaseDate", "DocumentBaseAdditionalInformation" telah dihapus.
Menambahkan bidang "Nama Mata Uang".
Menambahkan bidang "Klaim".
Menambahkan bidang "Tanggal Eksekusi".
Pada properti peserta transaksi, kolom "Faks" telah diganti dengan kolom "Email".
Pada properti peserta transaksi, kolom "Kode Negara" telah diganti dengan kolom "Kode Negara".
Di properti peserta transaksi, kolom "AddressText" telah diganti dengan kolom "AddressText".

Memperbarui Tipe yang Ditetapkan Pihak rekanan:

Prosedur pembaruan:

Ganti nama tipe Akun yang ditentukan menjadi AccountBED.
Hapus konfigurasi dari mendukung BED 1.3.5.
Jalankan perbandingan/penggabungan dengan konfigurasi BED 1.3.5, setuju untuk mengatur konfigurasi menjadi support.
Hapus centang semua objek dan biarkan hanya jenis Akun yang ditentukan, lakukan penggabungan.
Mulai perbarui konfigurasi, pilih file BED 1.3.6.
Pilih kotak centang pada tipe yang ditentukan AccountBED dan Akun. Tentukan objek database lain yang diperlukan untuk diperbarui.
Lakukan pembaruan.

Subsistem "Tukarkan dengan bank"

Subsistem "Pertukaran dengan situs"

Node pertukaran berubah Pertukaran Situs, formulir, modul objek:

Menambahkan kemampuan untuk mengunggah Item dengan pilihan berdasarkan Tipe Item (sebelumnya hanya tersedia berdasarkan grup Item).

Menambahkan buku referensi Situs web:

Menambahkan kemampuan untuk mengonfigurasi transisi ke situs dari 1C - ke bagian pengguna situs, dan ke area admin situs.
Berdasarkan Situs, Anda dapat membuat node pertukaran ExchangeSite.

Pemrosesan tambahan Buat situs web:

Menambahkan kemampuan untuk membuat situs di domain 1C-UMI, situs dibuat secara otomatis (elemen Situs) dan diisi dengan data dari 1C. Node pertukaran ExchangeSite secara otomatis dibuat dan pertukaran penuh pertama dengan situs tersebut dilakukan.

Modul umum Pertukaran Situs Dapat Ditimpa:

Kemampuan untuk memilih Jenis Item telah ditambahkan; kemampuan untuk memilih buku referensi khusus telah dihapus.

Modul umum Acara ExchangeSite:

Menambahkan kemampuan untuk memilih Jenis item.
Kemampuan untuk memilih direktori khusus telah dihapus.

Perubahan lainnya

Pengaturan subsistem Manajemen tarif dalam model layanan perpustakaan Teknologi layanan

// Interaksi Elektronik
Interaksi Elektronik. Saat Membentuk Daftar Layanan (Penyedia Layanan);
// Akhiri Interaksi Elektronik

Versi 1.3.5

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

fungsionalitas perpustakaan disesuaikan dengan fitur spesifik bekerja pada platform 8.3.8 dengan mode kompatibilitas dinonaktifkan;
subsistem dari "Perpustakaan Subsistem Standar" telah diperbarui ke versi 2.3.3.45;
Perpustakaan mencakup subsistem "Perpustakaan Dukungan Pengguna Internet", versi 2.1.8.3.

Transisi ke versi 1.3.5 dari versi 1.3.4

Tidak diperlukan perubahan.

Versi 1.3.4

Fitur dan perubahan baru

sistem notifikasi acara EDI telah diterapkan (dokumen elektronik baru, undangan baru, masa berlaku sertifikat, dll). Sekarang dimungkinkan untuk mengonfigurasi pemberitahuan email di profil pengaturan EDF, serta menampilkan pemberitahuan tentang acara secara langsung di program 1C menggunakan pesan pop-up;
format dokumen utama didukung, termasuk faktur (format UPD) sesuai dengan perintah Layanan Pajak Federal tanggal 24 Maret 2016 No. -7-15/155@ “Atas persetujuan format faktur dan format penyampaian dokumen pengiriman barang (pelaksanaan pekerjaan), pengalihan hak milik (dokumen pemberian jasa), termasuk invoice, dalam bentuk elektronik";
format dokumen perubahan nilai, termasuk faktur penyesuaian, telah didukung" (format UKD) sesuai dengan perintah Layanan Pajak Federal tertanggal 13/04/2016 N -7-15/189@ "Atas persetujuan format faktur penyesuaian dan format penyajian dokumen tentang perubahan harga pokok barang yang dikirim (pekerjaan yang dilakukan, jasa yang diberikan), pengalihan hak milik, termasuk faktur penyesuaian, dalam bentuk elektronik";
mendukung penggunaan komponen eksternal sebagai pertukaran dengan bank yang menggunakan teknologi DirectBank.

Transisi ke versi 1.3.4 dari versi 1.3.2, 1.3.3

Perubahan formulir daftar dokumen solusi aplikasi

Dalam formulir daftar dokumen, Anda perlu menambahkan prosedur plug-in Tukarkan dengan CounterpartyClient. Prosesor MenungguEDW:

&Pada Klien

Akhir Prosedur

Saat memperbarui subsistem, diperlukan formulir daftar dokumen di event handler: Saat DibuatDiServer, Saat Pembukaan, Peringatan Pemrosesan

&Pada Klien
Prosedur Pembukaan (Kegagalan)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

Perubahan formulir dokumen solusi aplikasi

Dalam formulir dokumen Anda perlu menambahkan prosedur plug-in Connectable_WaitingHandlerEDO, di mana Anda perlu melakukan pemanggilan metode

Tukarkan dengan CounterpartyClient. Prosesor yang Menunggu EDW:

&Pada Klien
Prosedur Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(Objek Ini);
Akhir Prosedur

Misalnya:

&Di server
Prosedur Saat DibuatDiServer (Kegagalan, Pemrosesan Standar)
…
// Subsistem "Pertukaran dengan Pihak Rekanan".
Parameter EDO Saat Dibuat = Bertukar dengan Counterparty Parameter Saat Dibuat Di Server_DocumentForm();
Parameter EDO Saat Dibuat.Form = ThisObject;
Parameter EDO Saat Dibuat.DocumentLink = Object.Link;
Parameter EDOSaatDibuat.DecorStateEDO = Elemen.DecorationStateEDO;
Parameter EDO Saat Dibuat.EDO State Group = Elements.EDO State Group;
Pertukaran dengan Rekanan.Saat DibuatDi Server_DocumentForm(Penolakan, Pemrosesan Standar, Parameter EDOSaat Dibuat);
// Akhir dari subsistem "Counterparty Exchange".
Akhir Prosedur

Perubahan dalam modul ExchangeCounterparty

Prosedur ditambahkan Ketika CreatedOnServer_ListForm, dipanggil dari event handler "When CreatedOnServer" pada formulir daftar dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSaatMembuatDiServer_ListForm.
Prosedur ditambahkan Ketika CreatedOnServer_FormDocument, dipanggil dari event handler "When CreatedOnServer" pada formulir dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSaatMembuatDiServer_DocumentForm.
Prosedur ditambahkan SetelahRecordingOnServer, dipanggil dari pengendali kejadian "AfterRecordOnServer" pada formulir dokumen. Sebagai parameter ketiga dari metode ini, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut ParameterSetelahRecordingOnServer.

Perubahan modul Tukarkan dengan CounterpartyClient.

Prosedur ditambahkan Saat Pembukaan, dipanggil dari event handler "Saat Pembukaan" pada formulir daftar dokumen dan formulir dokumen.
Prosedur ditambahkan MemprosesAlerts_ListForm, dipanggil dari pengendali peristiwa "Pemrosesan Pemberitahuan" pada formulir daftar dokumen. Sebagai parameter keempat dari metode, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut Parameter PeringatanEDO_ListForm.
Prosedur ditambahkan MemprosesAlert_FormDocument, dipanggil dari pengendali peristiwa "Pemrosesan Pemberitahuan" pada formulir dokumen. Sebagai parameter keempat dari metode, sebuah struktur dilewatkan yang diinisialisasi oleh metode tersebut Parameter PemberitahuanEDO_DocumentForm.
Perubahan modul Pertukaran dengan Pihak Rekanan Dapat Ditimpa:
Metode tambahan Isikan Data Transfer Pelaksana Pekerjaan.
Contoh:

metode Kemampuan Memeriksa untuk Mengedit Objek menjadi sebuah prosedur.
Metode tambahan Isi Data untuk UPDInformasi Penjual Layanan Pajak Federal. Metode ini menyiapkan data untuk dokumen elektronik sejenis UPD(informasi penjual) fungsi SCHFDOP.
Metode tambahan TemukanBuatUniversalTransferDocument. Metode ini menyimpan data dari dokumen elektronik UPD(informasi penjual) fungsi SCHFDOPv objek IS.
Metode tambahan Isi Data Layanan Pajak Federal Informasi Penjual UKDI. Metode ini menyiapkan data untuk dokumen elektronik sejenis UKD(informasi penjual) fungsi KSCHFDIS.
Metode tambahan TemukanBuatDokumen Penyesuaian Universal. Metode ini menyimpan data dari dokumen elektronik UKD(informasi penjual) fungsi KSCHFDIS ke objek keamanan informasi.

Perubahan pada subsistem "Penukaran dengan Bank".

Perubahan pada modul ExchangeWithBanksRedefinable

Prosedur Ketika Kondisi ED Berubah ditambahkan. Dipanggil ketika status aliran dokumen elektronik berubah.

Perubahan untuk bekerja dalam mode layanan

Jika konfigurasi tujuan untuk pengoperasian dalam mode layanan diperlukan:

Dalam prosedur GetProvidedDataHandlers dari modul umum SuppliedDataOverridden, tambahkan kode berikut:

ElectronicInteraction.RegisterDeliveredDataHandlers(Handlers);

Tambahkan tugas rutin Perbarui Pertukaran Modul Eksternal Dengan Bank ke atribut umum Data Area Basic Data.

Perubahan lainnya

Untuk tipe yang ditentukan Opsi Fungsional Ruang Penyimpanan perlu menambahkan konstanta Gunakan ExchangeWithBanks;
Fitur yang dihapus Penukaran Dengan Bank Penukaran Langsung Dengan Bank Direkomendasikan.

Versi 1.3.3

Nilai properti konfigurasi:

Mode kompatibilitas harus disetel ke "Jangan gunakan".
Mode penggunaan modalitas dapat diatur ke "Jangan gunakan".
Mode kompatibilitas antarmuka dapat mengambil nilai "Versi 8.2", "Versi 8.2. Izinkan Taksi" atau "Taksi. Izinkan Versi 8.2".

Fitur dan perubahan baru

sesuai dengan Surat Perintah tanggal 30 November 2015 No. ММВ-7-10/551@ “Atas persetujuan format penyampaian dokumen pemindahtanganan barang pada saat transaksi perdagangan dalam bentuk elektronik” dan Surat Perintah tanggal 30 November 2015 No. ММВ-7-10/552@ "Atas persetujuan format penyampaian dokumen transfer hasil pekerjaan (dokumen pemberian jasa) dalam bentuk elektronik" format baru dokumen elektronik didukung.

Transisi ke versi 1.3.2.19 dari versi 1.2.7, 1.3.1

Perubahan pada subsistem "Pertukaran dengan rekanan"

Di dalam modul Pertukaran dengan Pihak Rekanan Dapat Ditimpa membuat perubahan:

// Menyiapkan data untuk dokumen elektronik jenis Nota Konsinyasi.
// Pilihan:
// LinkOnED - Tautan ke ED yang diperlukan untuk membuat dokumen elektronik,
// StructureED - Struktur, struktur data untuk menghasilkan dokumen elektronik.
// Pohon Data - pohon nilai, pohon data untuk mengisi dokumen elektronik.
Prosedur Isi Data Transfer Barang ke Penjual (Link to Volume

Kolega!

Dalam beberapa konfigurasi, kesalahan tidak memungkinkan untuk mengunduh data dan, oleh karena itu, mengirimkan laporan ke Layanan Pajak Federal.

Berurusan dengan rekanan - mengapa pemeriksaan NPWP/KPP tidak lolos - adalah proses yang panjang, dan seringkali Anda hanya perlu mentransfer informasi ke Layanan Pajak Federal dan memberikan, jika ada pertanyaan, sertifikat tentang rekanan, sehingga dapat mengatasinya sendiri, daripada mencoba menyelesaikan masalah ini sendiri dan menerima denda karena keterlambatan pelaporan.

Sekarang kita akan fokus pada beberapa teknik untuk keluar dari situasi seperti itu menggunakan contoh konfigurasi 1C: Accounting edisi ke-8. 3.0.

Jadi, trik nomor 1: Verifikasi bawaan rekanan di Akuntansi 8 hanya berfungsi dengan rekanan yang memiliki NPWP/KPP. Jika Anda menghapus NPWP/KPP dari rekanan yang belum lolos verifikasi, tidak akan ada pesan error. Hal ini dikecualikan dari pertimbangan dalam modul verifikasi laporan.

Trik No. 2: Saat memeriksa rekanan, daftar informasi khusus diisi: “Status rekanan.” Inilah yang perlu Anda kerjakan.

Dengan menggunakan contoh basis pelatihan, kami akan mempertimbangkan opsi ini. Kami memiliki daftar rekanan yang belum terverifikasi:

Program ini melaporkan bahwa status, misalnya, rekanan Camellia “KPP tidak sesuai dengan data di database Layanan Pajak Federal.” Pihak lawan tersebut tidak akan lolos pemeriksaan dan program tidak akan mengizinkan Anda mengunduh laporan PPN yang berisi pihak lawan tersebut.

Apa yang bisa dilakukan?

Kami membuka daftar informasi "Status rekanan" - Ch. menu - Semua fungsi - Register informasi:

Dalam daftar informasi “Status Kontraktor”, tempatkan kursor pada baris dengan rekanan yang diinginkan:

Dan kami mengubah status verifikasi dari “Pos pemeriksaan tidak sesuai dengan data Layanan Pajak Federal” menjadi “Pihak lawan ada di database Layanan Pajak Federal”.

“(EDI) tidak mencerminkan secara akurat apa yang diterapkan dalam praktik di perusahaan dan organisasi Rusia. Ternyata sering kali ini (dan) lebih merupakan tentang dukungan elektronik untuk aliran dokumen kertas tradisional: dalam kasus paling sederhana - tentang pengelolaan kartu elektronik dokumen kertas, dalam kasus yang lebih kompleks - tentang membuat sirkuit tambahan dari salinan elektroniknya. Namun, yang asli di sini selalu berupa dokumen kertas. Itulah sebabnya dalam tinjauan ini kami memutuskan untuk menggunakan istilah “manajemen dokumen elektronik tanpa kertas” (BED), mengacu pada opsi penerapan EDF “nyata”, ketika dokumen asli disajikan dalam format elektronik. Pada saat yang sama, saya ingin menekankan bahwa penghapusan dokumen kertas bukanlah tujuan akhir, tetapi hanya sarana untuk meningkatkan kualitas dan efisiensi kerja.

Diskusi mengenai transisi ke BED telah berlangsung cukup lama, di tingkat negara bagian - aktif sejak tahun 2008. Namun seberapa dinamis dan sukses proses ini? Apa alasan mengapa hasil saat ini berbeda dengan prediksi 7-10 tahun lalu? Untuk menjawab pertanyaan-pertanyaan ini, kami beralih ke para ahli - pengembang alat EDMS/ECM dan mereka yang terlibat dalam implementasi dan pengoperasian sistem tersebut.

Apa relevansi transisi ke BED

Topik ini menjadi semakin relevan untuk berbagai jenis pelanggan - baik organisasi komersial maupun pemerintah, kata Oleg Beilezon, kepala praktik Alfresco di Business Logic (IT Group). Setiap orang benar-benar tenggelam dalam aliran kertas - ini secara fisik menjadi masalah, meja kerja dan lemari banyak karyawan dipenuhi dengan dokumen yang ditinjau, disepakati, ditandatangani, disimpan, dan “pelaporan pajak”, dan ini menjadi semakin sulit. untuk mengelolanya. Menurutnya, banyak regulator pemerintah (misalnya, Layanan Pajak Federal) telah menyadari hal ini, dan oleh karena itu mereka dengan tegas - bahkan persyaratan wajib - merekomendasikan peralihan ke sirkulasi dokumen formal tanpa kertas.

Elena Ivanova, kepala departemen pemasaran perusahaan EOS, mencatat bahwa meskipun transisi ke aliran dokumen tanpa kertas memungkinkan perusahaan mengurangi biaya dan meningkatkan efisiensi proses bisnis mereka, harus diingat bahwa transformasi seperti itu memerlukan biaya tertentu yang terkait dengan penerapan solusi teknologi, perubahan peraturan, meminimalkan risiko yang timbul dari penggunaan dokumen elektronik. Secara umum, situasinya jelas: semakin besar aliran dokumen kertas, semakin mendesak pula permasalahan pertukaran tanpa kertas. Dia melihat perlunya biaya tambahan “saat ini” dan keengganan karyawan untuk meninggalkan proses dan atribut dokumen kertas sebagai hambatan utama yang memperlambat transisi tersebut. Namun pengembang memiliki alat yang dapat mengatasi tantangan implementasi.

Namun, kini, dalam kondisi krisis ekonomi yang berkepanjangan, tidak semua perusahaan siap melakukan hal tersebut, kata Dmitry Shmailov, kepala departemen pengembangan solusi ECM di ELAR Corporation. Selain itu, BED bukanlah prioritas bisnis seperti, misalnya, otomatisasi produksi, solusi untuk tugas-tugas penting, dan sistem yang bertujuan untuk mengurangi biaya, yaitu proyek yang dapat menghasilkan uang.

Vadim Ipatov, Wakil Direktur Jenderal InterTrust untuk Pengembangan Bisnis, mengenang bahwa selain masalah organisasi dan teknologi, terdapat juga persyaratan peraturan, yang saat ini sebagian besar masih terfokus pada penggunaan kertas asli. Secara khusus, masalah penyimpanan dokumen jangka panjang (dan terutama yang abadi) masih belum terselesaikan. Porsi dokumen-dokumen tersebut dalam volume totalnya tampaknya kecil, tetapi, seperti sebuah jangkar, menghambat proses penolakan dokumen asli kertas secara keseluruhan.

Jika kita berbicara tentang dokumen yang digunakan sebagai alat komunikasi, maka saat ini mekanisme yang paling umum adalah email. Tampaknya tidak ada masalah organisasi, hukum atau teknis di sini. Namun kenyataannya, email menerapkan interaksi versi kertas tradisional, yang bila diterapkan secara otomatis, akan menghasilkan terciptanya sejumlah besar informasi yang sulit dikelola bahkan dengan penggunaan TI. Artinya, diperlukan beberapa arsitektur komunikasi yang berbeda secara kualitatif. Dan untuk menggunakannya, sang pakar menekankan, kita perlu mempertimbangkan kembali pemahaman kita tentang ECM, memposisikannya sebagai sistem yang menyatukan orang, proses, dan konten terkait. Saat ini lebih tepat untuk berbicara bukan tentang aliran dokumen tanpa kertas, tetapi tentang interaksi orang-orang yang tidak menggunakan kertas dan terdokumentasi selama proses kerja.

Secara tradisional, masalah EDMS dipahami sebagai masalah otomatisasi proses bisnis internal suatu perusahaan, dan sebagian besar berkaitan dengan dokumen organisasi dan administrasi. Namun, dalam beberapa tahun terakhir, relevansi isu pertukaran dokumen antar organisasi telah meningkat pesat: antara perusahaan komersial, di dalam badan pemerintah, serta dalam interaksi dunia usaha dan individu dengan lembaga pemerintah. Semua bidang ini sekarang berkembang pesat dalam hal transisi ke aliran dokumen elektronik antar organisasi.

Mengenai hal ini, Ernest Kolesnikov, Wakil Direktur Pemasaran Taxkom, mengacu pada perkiraan analis: pada tahun 2017, penggunaan mekanisme EDI dengan pihak lawan akan mencapai 22,5%. Saat ini, setelah diperkenalkannya pengembalian PPN baru (hampir semua wajib pajak sekarang harus menyerahkannya secara elektronik), masalah otomatisasi dokumen menjadi sangat relevan, karena dengan entri data manual, akuntansi kemungkinan besar akan menerima permintaan otomatis untuk perbedaan dengan rekanan. . Dia juga mengingatkan bahwa Bab 49.1 dari Kode Perburuhan Federasi Rusia mengizinkan penggunaan EDI saat bekerja jarak jauh, dan mulai 1 Juli 2016, amandemen Undang-Undang Federal “Tentang Perusahaan Saham Gabungan” akan mulai berlaku, yang akan memungkinkan pemegang saham untuk berpartisipasi dari jarak jauh dalam pertemuan menggunakan EDI.

Artem Tanan, manajer proyek Pertukaran Dokumen Elektronik di 1C, yakin bahwa insentif utama transisi ke BED adalah keinginan perusahaan untuk meningkatkan daya saingnya. Mereka yang ingin menjadi pemimpin di pasar mulai mempersiapkan transformasi tersebut jauh sebelum adanya izin hukum dan merupakan pihak pertama yang menguasai peluang ini dalam praktiknya. Kembali pada tahun 2013–2014. Metode interaksi elektronik dengan pihak lawan mulai digunakan oleh perusahaan-perusahaan dari industri yang sangat kompetitif dan berteknologi tinggi, seperti rantai ritel, distributor, operator telekomunikasi, dll. Hal ini memungkinkan mereka memperoleh efek yang komprehensif: mulai dari mempercepat pengembalian PPN dan mengurangi risiko pajak hingga optimalisasi biaya dan meningkatkan efisiensi interaksi dengan pihak lawan. Di bawah tekanan dari perusahaan pemasok, rekanan mereka juga mulai beralih ke BED. Pada tahun 2015, prosesnya semakin meluas, hal ini difasilitasi oleh perkembangan peraturan perundang-undangan dan munculnya sejumlah persyaratan regulasi baru dalam penyampaian laporan pajak. Dalam beberapa tahun terakhir, jumlah pengguna yang terhubung ke layanan telah meningkat secara signifikan.

Praktik transisi ke pengelolaan dokumen elektronik tanpa kertas

Menurut Elena Ivanova, praktik pemindahan dokumen asli elektronik saat berinteraksi dengan cabang dan unit jarak jauh semakin meluas. Pertukaran dokumen akuntansi utama (akta, faktur, dll.) dengan rekanan dan integrasi dengan layanan pertukaran khusus terkait menjadi semakin populer. Namun, ia mencatat bahwa banyak organisasi masih mewaspadai risiko yang timbul ketika menggunakan dokumen asli elektronik, dan penggunaan dokumen elektronik jenis apa pun tetap menjadi topik yang “terlarang” bagi mereka.

“Ketika berbicara tentang transisi untuk bekerja dengan dokumen asli elektronik, perusahaan memulai dengan kata ‘kami ingin’, diikuti dengan ‘tetapi…’,” kata Oleg Beilezon. “Lalu ada serangkaian alasan yang kurang lebih dapat diatasi: beberapa unit belum siap, anggaran belum dialokasikan, kita tidak dapat melanggar tradisi organisasi, dan sebagainya.” Namun secara umum, menurutnya, tren elektronikisasi alur dokumen terlihat cukup baik, jika hanya karena ada proyek transisi ke teknologi paperless, namun belum terdengar adanya proyek transisi sebaliknya. Ada banyak area yang dicakup oleh BED - ini adalah EDMS klasik, aliran dokumen keuangan suatu organisasi, dan sirkulasi dokumen keuangan yang signifikan secara hukum. Alur dokumen organisasi dan administrasi yang signifikan secara hukum agak terhenti - terdapat terlalu banyak seluk-beluk hukum, dan praktik yang memadai belum dikembangkan. Penyimpanan elektronik dan pemrosesan dokumen dengan berbagai klasifikasi akses bahkan jauh tertinggal, karena (secara umum dapat dibenarkan) persyaratan yang agak ketat dikenakan pada sistem yang menerapkannya.

Analis bisnis Directum Maxim Kainer mengatakan bahwa ketika menerapkan EDMS/ECM, penghematan pencetakan kertas hanya dapat dicapai melalui proses otomatis, namun seringkali total volume pencetakan di seluruh organisasi dapat meningkat. Selain itu, otomatisasi proses bisnis tertentu melalui ECM dalam waktu kurang dari 10% kasus memungkinkan Anda menghindari pencetakan dokumen bahkan dalam proses ini. Secara umum, ia yakin bahwa sejauh ini belum ada pembicaraan mengenai transisi organisasi ke aliran dokumen tanpa kertas.

Biasanya, tugas menghilangkan kertas bukanlah tujuan akhir; tujuannya adalah untuk mengoptimalkan proses bisnis tertentu, mempercepat dan menyederhanakan implementasinya, tegas Vadim Ipatov. Menurut perkiraannya, sebagian besar organisasi pelanggan telah sepenuhnya menerapkan sistem elektronik internal, termasuk seluruh dokumen pendukung (instruksi, resolusi, laporan pelaksanaan...). Di banyak lembaga pemerintah, di antara pelanggan perusahaannya, penyediaan layanan publik dan menangani permohonan warga sebagian besar dilakukan secara otomatis. Jika permintaan diterima melalui saluran elektronik, maka diproses seluruhnya secara elektronik. Di bidang dokumen organisasi, administrasi dan peraturan, “digitalisasi” secara relatif dapat mencapai 99,9%, namun perintah, perintah atau peraturan, setidaknya dalam satu salinan kertas, masih diperlukan - hal ini ditentukan oleh tradisi dan norma perundang-undangan. Ketika bekerja dengan kontrak, situasinya serupa: seluruh proses persiapan dan persetujuannya sepenuhnya dilakukan secara elektronik, tetapi dua salinan yang ditandatangani oleh para pihak masih “hidup” di atas kertas.

Peran penting dalam transisi ke EDMS dimainkan oleh departemen TI organisasi tepatnya sebagai pengguna EDMS - mereka menggunakan alat ini untuk tugas internal mereka (memproses permintaan pengguna, manajemen proyek dalam hal distribusi tugas dan pekerjaan, persetujuan, dll.) , sedangkan melalui contoh mereka sendiri, mereka menunjukkan bagaimana kertas dapat dihilangkan sepenuhnya.

“Transisi ke teknologi tanpa kertas sudah menjadi hal yang lumrah dan didorong oleh kebutuhan produksi; bekerja tanpa kertas sangatlah menguntungkan,” Dmitry Shmailov setuju. - BED sangat relevan untuk alur dokumen internal perusahaan. Saat ini, ketika dokumen elektronik secara bertahap mendapatkan status legislatif, bekerja di EDMS dengan rekanan menjadi hal yang lumrah.” Namun pada saat yang sama, ia mencatat bahwa dalam organisasi yang menerapkan rezim khusus, dokumen yang merupakan rahasia negara atau komersial atau memiliki nilai tertentu masih disimpan di atas kertas. Peralihan ke BED untuk dokumentasi semacam itu tidak mungkin dilakukan atau dikaitkan dengan jaminan tingkat keamanan tertinggi, yang mahal, sulit, dan sering kali tidak sesuai dengan biayanya.

Menurut Ernest Kolesnikov, pertukaran dokumen elektronik dengan pihak lawan sedang melalui tahap transisi dari tahap embrio ke tahap yang lebih matang. Operator EDF pada awalnya memilih taktik untuk menarik perusahaan terbesar - penghasil lalu lintas dokumen; di sektor bisnis utama, pertukaran dokumen dalam bentuk elektronik menjadi hal biasa; di sektor lain, proyek percontohan sedang berlangsung. Proses ini secara signifikan dirangsang, dan kadang-kadang bahkan dimulai, oleh tindakan regulator. Kasus umum untuk otomatisasi adalah sekelompok perusahaan dari kepemilikan yang sama dengan distribusi teritorial di seluruh negeri, di mana sebagian besar dokumen diubah menjadi bentuk elektronik dan efek finansial maksimum dipastikan. Pada saat yang sama, pakar mencatat satu hal penting: “Banyak hal bergantung pada bagaimana akuntansi dilakukan di perusahaan. Jika segala sesuatunya sesuai dengan undang-undang, maka peningkatan transparansi dapat diterima, namun jika situasinya sebaliknya, maka transparansi akan berfungsi sebagai alat untuk memulihkan ketertiban, namun hal ini bukanlah sebuah proses yang cepat.”

Area penerapan BED yang paling jelas adalah transisi ke nota pengiriman dan faktur elektronik. Namun Artem Tanan mencatat bahwa meskipun regulator menunjukkan keinginan yang jelas untuk bergerak cepat ke arah ini, cukup banyak kesulitan yang muncul. Misalnya, transisi ke pertukaran faktur elektronik terhambat oleh situasi ketika, katakanlah, layanan diberikan pada hari terakhir masa pajak (komunikasi, Internet, utilitas, dll.), dan faktur dengan konfirmasi dari dokumen elektronik operator manajemen diberi tanggal paling cepat pada hari berikutnya bulan. Masalah ini diselesaikan dengan cukup cepat dengan penerapan undang-undang federal 382-FZ dan klarifikasi selanjutnya dari Kementerian Keuangan.

Hambatan dalam perjalanan menuju BED

Beberapa tahun yang lalu, jawaban utama atas pertanyaan ini adalah tesis “ketidaksiapan kerangka peraturan dan perundang-undangan”, namun kini para ahli, ketika menyebutkan masalah ini, tidak mengedepankannya. “Organisasi tidak tertarik untuk beralih dari kertas,” kata Maxim Kainer. - Biaya pencetakan dan pengerjaan dokumen kertas tidak terlalu besar sehingga menguranginya dianggap menguntungkan. Sistem ECM tidak diterapkan untuk transisi ke aliran dokumen tanpa kertas, namun untuk mendapatkan efek lain yang lebih nyata dan nyata: transparansi proses dan percepatannya, pengurangan risiko, dll. Selain itu, terkadang mengubah proses menjadi bentuk elektronik tidak masuk akal, termasuk juga karena mahalnya harga sertifikat tanda tangan elektronik.” Pada saat yang sama, ia juga mencatat kekurangan kerangka peraturan - ketidakjelasan sejumlah formulasi dan sifat penasehatan umum, sehingga memberikan pilihan kepada organisasi yang mungkin tidak ingin mengubah pola kerja yang sudah terbukti. Pada saat yang sama, ia yakin bahwa pendekatan baru tidak boleh diterapkan secara drastis, karena di sebagian besar perusahaan pendekatan tersebut memerlukan perubahan pada tingkat infrastruktur TI.

Berbicara tentang masalah kerangka legislatif, Elena Ivanova menarik perhatian pada fakta bahwa banyak masalah peraturan merupakan tanggung jawab organisasi itu sendiri. “Dalam banyak hal, kemauan manajemen berperan dalam pengembangan BED,” yakinnya. - Jika manajer memerintahkan untuk bekerja tanpa kertas, maka semua orang akan melakukannya, mau atau tidak. Jika tidak ada tindakan motivasi seperti itu dari pihak manajemen dalam organisasi, berarti tidak ada kelayakan dan dampak ekonomi dalam BED. Ada juga masalah kekurangan personel yang dapat bertindak sebagai penggerak proses penerapan BED dan menyampaikan segala manfaatnya kepada manajer.”

Dmitry Shmailov juga setuju dengan dia: “Tentu saja, kita dapat mengatakan bahwa undang-undang tersebut tertinggal dari negara-negara Barat dalam hal pengembangan BED, tetapi yang lebih penting adalah bahwa tidak semua orang memanfaatkan peluang yang diberikan oleh amandemen undang-undang tersebut. Sebaliknya, terdapat ketertinggalan: banyak teknologi BED hanya digunakan oleh sedikit organisasi. Dalam kasus pelanggan kami, kami melihat tren ke arah pengembangan dan pendalaman topik akuntansi elektronik dan pembangunan model terpadu untuk memproses dan menyimpan dokumen akuntansi dalam bentuk elektronik. Transisi menyeluruh ke BED sangat dibatasi oleh kurangnya ruang kepercayaan tunggal untuk tanda tangan elektronik. Selain itu, jangan lupakan persyaratan perlindungan informasi, yang dalam beberapa kasus membuat penyimpanan dan penggunaan dokumen elektronik tidak mungkin dilakukan. Ya, pendanaan tetap menjadi faktor penting.”

Mengutip pepatah terkenal, Ernest Kolesnikov menyebutkan dua masalah utama pengelolaan dokumen elektronik Rusia: hukum dan manusia. “Ada kesenjangan dalam peraturan perundang-undangan, misalnya format yang disetujui hanya untuk beberapa dokumen, sementara pengerjaan jenis lainnya baru berjalan. Dalam waktu dekat, format dokumen transfer universal harus disetujui, ada pembicaraan tentang wadah universal di mana dokumen apa pun dapat dilampirkan. Praktik peradilan yang menggunakan dokumen yang tidak diformalkan belum cukup bagi semua perusahaan untuk beralih ke EDI tanpa rasa takut, namun waktu berlalu dan situasinya berubah menjadi lebih baik. Masalah utama kedua adalah manusia dan kenyataan hidup yang ada; kami sering mendengar dari pelanggan: kami akan menolak kertas hanya jika mereka memaksa kami.”

Untuk memperkenalkan teknologi baru dalam kerangka proses yang ada, hal ini terutama memerlukan pelatihan ulang personel dan keinginan manajemen perusahaan untuk menerapkan inovasi, tetapi prosesnya pada dasarnya tetap sama, kata Artem Tanan. Dia memberikan saran khusus: untuk menerapkan BED, Anda harus menunjuk mereka yang bertanggung jawab dan melakukan tiga tugas utama - membangun prosedur baru untuk bekerja dengan dokumen, melatih staf dan menentukan tenggat waktu untuk meninggalkan prosedur lama untuk rekanan yang dipilih. Agar prosedur baru dalam pengerjaan dokumen menjadi sederhana, mudah dipahami, dan memiliki perbedaan minimal dengan prosedur yang sudah ada, maka perlu didukung integrasi BED dengan program akuntansi, manajemen dan EDMS, bahkan lebih baik lagi, membuat BED. merupakan bagian integral dari mereka. Blok terpisah yang mungkin paling bermasalah adalah masalah keterlibatan pihak lawan. Penting tidak hanya untuk menghubungkan rekanan pelanggan BED, tetapi juga untuk membantu transisi ke prosedur baru untuk bekerja dengan dokumen. Jika tidak, meskipun menggunakan BED, kesalahan dan ketidaksesuaian informasi dalam buku pembelian dan penjualan akan tetap ada, dan terdapat akibat negatif lainnya. Pakar yakin bahwa masalah integrasi BED dengan sistem bisnis lain dan keterlibatan kontraktor dalam beberapa tahun ke depan akan memainkan peran utama dalam penyebaran teknologi BED di negara kita.

Apa yang harus dilakukan?

“Untuk saat ini, di Rusia tidak mungkin untuk sepenuhnya meninggalkan kertas, baik di sektor publik maupun sektor komersial,” kata Elena Ivanova. - Pertama-tama, perlu untuk mengembangkan kerangka legislatif yang dapat mendorong organisasi untuk beralih ke BED. Hal ini kini mulai terlihat di organisasi-organisasi pemerintah sehubungan dengan peningkatan SMEV, M.” Banyak hal bergantung pada vendor EDMS, dia yakin; mereka dapat membenarkan dampak ekonomi dari peralihan ke BED dan menawarkan solusi teknologi. Penting juga untuk bekerja dalam komunitas dan organisasi profesional yang terlibat dalam standardisasi di bidang EDMS/ECM, dan untuk berinteraksi dengan regulator negara.

Selain itu, pemasok EDMS sendiri harus memberikan contoh transisi ke BED, yakin Dmitry Shmailov. Perusahaan-perusahaan ini juga memerlukan pengelolaan dokumen elektronik untuk meningkatkan efisiensi kerja mereka. Dalam kondisi kekurangan pelanggan, salah satu faktor keberhasilannya adalah pengujian teknologi BED di bisnis Anda sendiri. Pemasok EDMS akan sangat membantu dalam hal perkembangan teknologi, menawarkan perkembangan terkini yang memenuhi dan mempertimbangkan kebutuhan individu dan spesifikasi klien mereka.

Maxim Kainer juga berbicara tentang pembenaran ekonomi untuk transisi ke BED: “Agar transisi ke aliran dokumen tanpa kertas dapat terjadi, penerapan solusi TI harus membayar sendiri melalui penghematan untuk mendukung pekerjaan dengan media kertas (pembelian dan pemeliharaan peralatan, bahan habis pakai, biaya pengiriman dan pengantaran, biaya penyimpanan dan pengambilan). Pakar dunia mengatakan bahwa periode pengembalian investasi pada solusi ECM spesifik di lebih dari separuh kasus adalah satu setengah tahun atau kurang.” Partisipasi nyata vendor dalam proses ini dapat berupa promosi gagasan “bekerja tanpa kertas itu mungkin dan menguntungkan”, berpartisipasi dalam proses legislatif, serta mengurangi biaya solusi mereka, termasuk melalui penggunaan model cloud dan SaaS.

Tidak ada hambatan yang tidak dapat diatasi terhadap BED, namun ada masalah yang dapat dan harus diselesaikan, kata Ernest Kolesnikov. Aspek positifnya adalah bahwa otoritas pemerintah melakukan investasi besar dalam otomatisasi negara, dan dapat dikatakan bahwa hidup dan bekerja menjadi jauh lebih menyenangkan selama sepuluh tahun terakhir. Ada masalah, namun masalah tersebut diidentifikasi dan diselesaikan melalui upaya bersama dari regulator, pengembang, dan pelanggan. “Pada titik tertentu, volume informasi di masyarakat akan mencapai volume yang cukup dan semua orang akan memahami bahwa menampilkan dokumen dengan cara lama di atas kertas sudah ketinggalan zaman,” yakinnya. “Sekarang sulit membayangkan bagaimana kita dulu hidup tanpa internet, namun dengan pemrosesan dokumen elektronik, saya rasa situasinya akan sama.”

“Kami menyarankan agar perusahaan tidak menunggu “panggilan terakhir”, ketika mereka sendiri tidak lagi mampu mengatasi aliran kertas dan tidak memenuhi persyaratan regulator,” saran Artem Tanan. - Mereka perlu memutuskan sekarang jenis transaksi/dokumen apa dan dengan pihak mana BED akan digunakan, kemudian menunjuk mereka yang bertanggung jawab dan menetapkan tenggat waktu. Jika perlu, libatkan tenaga ahli yang memiliki kompetensi memadai di bidangnya agar pelaksanaan tugas yang diberikan berkualitas tinggi. Jika timbul kesulitan yang bersifat metodologis atau teknis, bawalah kesulitan tersebut untuk didiskusikan pada platform khusus, dalam kelompok kerja mengenai isu-isu BED. Hanya menetapkan tugas tertentu ketika beralih ke BED di satu perusahaan yang memungkinkan seseorang memperoleh pengalaman sukses yang dapat dipahami oleh pelaku pasar lainnya. Replikasi pengalaman ini oleh perusahaan besar bersama dengan operator SF, vendor perangkat lunak, dan jaringan mitra mereka adalah cara paling efektif untuk mendistribusikan teknologi BED di pasar.”

Kami melanjutkan apa yang telah banyak kami lakukan.

Chernomyrdin V.S.

Belum lama ini, seorang klien sekali lagi menemui saya dengan masalah yang sudah diketahui umum. Perusahaannya menginstal pembaruan 1C. Dan pekerjaan terhenti karena program berhenti bekerja dengan benar. Saya rasa semua orang yang pernah menjumpai produk perangkat lunak dari 1C sebagai programmer atau pengguna sudah sangat familiar dengan situasi ini.

Tentu saja, dalam kasus khusus ini, saya berusaha menyelesaikan semua masalah secepat mungkin, dan hasilnya, pekerjaan kantor kembali normal. Namun bahkan dalam situasi ini, saya menerima banyak tanggapan negatif dari klien. Lalu saya berpikir mengapa begitu banyak masalah yang terus-menerus muncul dengan produk perangkat lunak 1C, mengapa begitu banyak hal negatif dari klien, dan mengapa programmer 1C sendiri sering tidak disukai, termasuk oleh programmer lain?

Dalam artikel ini, saya memutuskan untuk menawarkan versi saya tentang alasan yang menyebabkan hal negatif tersebut. Saya akan mencoba menggunakan istilah-istilah spesifik sesedikit mungkin agar teks dapat dipahami oleh sebanyak mungkin pembaca.

Pada saat yang sama, untuk beberapa waktu saya sendiri secara eksklusif terlibat dalam pemrograman 1C, dan hari ini saya sangat aktif menggunakan produk perangkat lunak dari 1C dalam pekerjaan saya, dan saya sangat berterima kasih kepada perusahaan ini karena telah memberi saya kesempatan untuk mendapatkan uang, termasuk untuk Saya.

Namun di sisi lain, saya yakin alasan negatifnya juga perlu dipahami. Setidaknya agar tidak menyerahkan semuanya pada tataran intuisi dan emosi.

Bagaimana 1C dimulai? Mari kita ingat!

Secara pribadi, saya mulai bekerja dengan perangkat lunak 1C dari versi 6.0. Menurut pendapat saya, program ini sedikit lebih rumit dibandingkan berbagai opsi akuntansi yang disimpan dalam spreadsheet Excel.

Itu digantikan oleh versi ke-7, termasuk rilis paling sukses - 1C 7.7. Itu sudah menjadi produk perangkat lunak yang cukup kuat, yang tersebar luas di seluruh wilayah pasca-Soviet. Pada saat ini, sebagian besar pengguna sudah terbiasa bekerja dengan 1C sehingga kemampuan untuk menggunakan program ini menjadi salah satu syarat untuk mempekerjakan akuntan, berbagai personel kantor, serta manajer, penjaga toko, dll.

Pada prinsipnya, 1C 7.7 cukup berhasil memecahkan masalah yang berkaitan dengan berbagai jenis akuntansi. Selain itu, produk perangkat lunak ini masih digunakan dalam beberapa kasus, yang juga menunjukkan popularitasnya.

Sekarang perangkat lunak ini mencolok dalam keluasan kemampuannya dan sekaligus kompleksitas sistemnya.

Saat ini perusahaan 1C menyediakan seluruh ekosistem untuk kliennya:

Platform yang kuat untuk pengembang.
Lingkungan untuk memelihara berbagai jenis akuntansi dan analitik
Kemungkinan menghubungkan berbagai peralatan komersial
Jaringan mitra terluas
CMS multifungsi untuk pembuatan website

Pada saat yang sama, baik secara bersama-sama maupun sendiri-sendiri, seluruh komponen ekosistem ini tidak berfungsi dengan baik. Seringkali timbul permasalahan, kegagalan dalam pekerjaan, diperlukan tambahan waktu dan biaya yang tentu saja menimbulkan penolakan.

Pembaruan 1C: cara kerjanya

Saya ingin mengingatkan Anda secara singkat cara kerja produk perangkat lunak dari keluarga 1C saat ini. Dalam kebanyakan kasus, pengguna membeli satu atau lebih produk perangkat lunak, yang terdiri dari platform dan aplikasi yang ditulis pada platform ini - yang disebut konfigurasi.

Selanjutnya, pemrogram menyesuaikan pengoperasian konfigurasi yang dipilih dengan kebutuhan perusahaan tertentu, sering kali memasang plugin tambahan, menyempurnakan laporan tertentu, membuat dokumen baru yang berpartisipasi sebagai aliran dokumen internal di perusahaan ini, dll.

Pada saat yang sama, baik di platform maupun dalam konfigurasi apa pun, terdapat sejumlah besar bug dari pengembang. Dan sistem itu sendiri sangat kompleks dan banyak sehingga memperbaiki bug ini dengan bantuan programmer 1C sangatlah sulit dan, yang paling penting, tidak menguntungkan bagi pengguna akhir. Selain itu, baik platform maupun konfigurasinya sendiri memiliki kualitas yang tidak menyenangkan seperti kurangnya modularitas.

Akibatnya, Anda harus menginstal pembaruan untuk memperbaiki bug. Dalam hal ini, seluruh platform dan/atau konfigurasi diperbarui setiap saat. Tentu saja, solusi seperti itu membutuhkan banyak waktu, dan jika kita berbicara tentang konfigurasi, maka pengaturan, plugin tambahan, dan modifikasi lain yang dilakukan oleh programmer kemungkinan besar harus dilakukan lagi.

Tapi ini bukanlah hal yang paling menyedihkan dalam situasi pembaruan 1C. Yang paling menyedihkan adalah di website developernya terlihat update sangat sering dirilis, bahkan terkadang 3-4 kali dalam sebulan. Dalam beberapa kasus, kesalahan yang tidak penting diperbaiki, dalam kasus lain - bug serius yang terkait dengan pengoperasian seluruh sistem.

Setiap versi baru merupakan penambahan fungsionalitas dan semacam "tambalan" pada bug versi sebelumnya, yang memperbaiki kesalahan lama, tetapi hampir selalu menimbulkan kesalahan baru. Oleh karena itu, menginstal pembaruan sebagian besar merupakan proses yang tidak dapat diprediksi.

Kurangnya modularitas: mengapa ini sangat penting

Pertama, mari kita bicara langsung tentang platformnya. Pemrogram 1C tahu betapa rumitnya hal itu. Saya sudah menulis tentang kurangnya modularitas di atas. Kode produk berisi apa yang disebut subsistem, tetapi subsistem tersebut tidak memenuhi persyaratan modularitas, dan oleh karena itu hanyalah semacam upaya untuk menyusun kode.

Mengapa saya pribadi menganggap kurangnya modularitas sebagai masalah? Mari kita pahami dengan sebuah contoh. Katakanlah ada kebutuhan untuk menyempurnakan beberapa fungsi yang diperlukan untuk keberhasilan pengoperasian Manajemen Perdagangan atau untuk membuat perubahan pada cara menyimpan saldo. Namun di platform 1C semuanya saling berhubungan, dan oleh karena itu Anda juga harus melakukan pembaruan untuk bekerja dengan gaji, akuntansi, dll. dan seterusnya.

Dengan tidak adanya modularitas, untuk membuat perubahan terkecil sekalipun, Anda harus mempelajari keseluruhan susunan, keseluruhan platform.

Pada saat yang sama, platform 1C sangat besar dan rumit. Saat ini, hal itu mengandung begitu banyak hal sehingga pada awalnya bahkan menimbulkan kekaguman karena banyaknya kemungkinan. Namun saat Anda menggunakan platform ini, kekaguman itu dengan cepat hilang. Pengembang 1C, dalam upaya menjadikan program ini universal, menambahkan banyak fitur berbeda ke platform.

Dan sekarang Anda sekaligus mendapatkan alat canggih, antarmuka visual yang nyaman, dan... banyak masalah dan bug karena rumitnya sistem.

Izinkan saya memberi Anda contoh lain. Katakanlah untuk pekerjaan saya, saya hanya membutuhkan Trade. Perusahaan tidak menggunakan apa pun, baik antarmuka seluler, akuntansi, toko online, maupun komponen lainnya. Namun apa pun yang terjadi, ketika saya menerima pembaruan, saya menerima seluruh platform, termasuk fungsionalitas yang diperlukan untuk pengoperasian komponen-komponen yang tidak saya gunakan. Itu. Terlepas dari kenyataan bahwa saya menggunakan Commerce, dan pembaruannya dirancang untuk bekerja dengan Akuntansi, saya harus mengunduh dan menginstal seluruh platform.

Kebijakan perizinan dan bug dalam sistem

Saat memperbarui platform, sering kali pengguna dihadapkan pada kenyataan bahwa kunci lisensi berhenti berfungsi. Jika Anda belum pernah mengalami situasi seperti ini secara pribadi, cukup ketik di mesin pencari "1C berhenti bekerja setelah pembaruan" dan Anda akan melihat seberapa luas masalah ini.

Jadi, bayangkan situasinya. Ada perusahaan yang mempekerjakan, misalnya 30 orang. Setelah pembaruan, program berhenti menerima kunci lisensi. Pekerjaan perusahaan lumpuh. Perusahaan menderita kerugian.

Masalah penting: perilaku platform yang tidak dapat diprediksi saat memperbarui.

Selain fakta bahwa lisensi sering gagal, setelah memperbarui platform, lisensi tersebut mungkin berisi fungsionalitas baru, yang mungkin juga tidak berfungsi dengan benar. Tetapi Anda hanya dapat memeriksa kualitas pekerjaan dan mengidentifikasi bug baru di versi baru program dalam praktiknya, mis. sedang berlangsung.

Izinkan saya mengingatkan Anda bahwa platform ini sangat besar dan rumit, oleh karena itu tidak realistis untuk mengujinya dengan seorang programmer dalam waktu singkat. Dan semua ini harus diperhitungkan pada setiap pembaruan.

Jadi, situasi programmer terlihat seperti ini:

Setiap kali saya memperbarui, saya mendapatkan banyak kekacauan karena platform telah diperbarui sepenuhnya dan tidak ada cara untuk menghapus atau tidak menginstal alat yang tidak akan digunakan di masa mendatang.
Namun pembaruan tetap diperlukan, karena ini adalah satu-satunya kesempatan untuk "menyembuhkan" bug saat ini yang diketahui atau belum diidentifikasi oleh pemrogram.
Apalagi update baru biasanya membawa bug baru yang akan diperbaiki di versi berikutnya.

Dengan demikian, lingkarannya tertutup. Dan pemrogram harus menginstal versi baru dari waktu ke waktu, meskipun ada masalah baru yang ditimbulkannya.

Mengapa ada begitu banyak bug?

Alasan utama banyaknya bug, menurut pendapat saya, adalah kompleksitas sistem. Ingat, sekarang platform 1C tersedia untuk Windows 32 dan 64 bit, untuk Linux, versi server, seluler, dll. Kompleksitas pemeliharaan sangat tinggi, dan seperti yang ditunjukkan oleh praktik, pengembang 1C tidak dapat mengatasi pemeliharaan.

Karena kurangnya modularitas, kesulitan tambahan juga muncul, karena hampir tidak mungkin untuk mengidentifikasi semua kesalahan dan men-debug produk perangkat lunak yang rumit tersebut. Hasilnya, pembaruan baru terus dirilis.

Alasan lain yang sangat penting atas keberadaan bug yang terus-menerus dan situasinya adalah kurangnya persaingan. Faktanya, 1C sekarang menjadi perusahaan monopoli.

Tentu saja, produk perangkat lunak alternatif sedang dibuat, beberapa di antaranya cukup baik. Namun selama ini semuanya merupakan solusi terapan yang mampu menyelesaikan permasalahan tertentu, sedangkan 1C merupakan ekosistem yang utuh.

Selain itu, perusahaan 1C memiliki pemasaran yang sangat kuat dan agresif, semua orang tahu tentang perangkat lunak ini.

Itu sebabnya saya berpendapat bahwa saat ini 1C tidak memiliki pesaing yang layak di ruang pasca-Soviet. Dan kurangnya persaingan selalu menyebabkan penurunan kualitas produk itu sendiri, seperti yang kita lihat dalam contoh 1C: pembaruan "mentah" yang konstan, bug yang terus-menerus, kurangnya dokumentasi terperinci untuk pembaruan, dll.
Oleh karena itu, saya pribadi menyarankan semua klien saya untuk tidak memperbarui kecuali benar-benar diperlukan. Ngomong-ngomong, saya sendiri mendapat nasehat yang sama dari salah satu orang yang mencetuskan 1C.

Tentu saja, versi saat ini pasti memiliki beberapa bug, tetapi jika Anda mengerjakannya tanpa masalah, maka bug ini tidak penting bagi Anda. Tidak mungkin untuk memprediksi apa yang akan terjadi di versi baru. Oleh karena itu, pembaruan harus diinstal hanya jika benar-benar diperlukan untuk pekerjaan.

Unggulan. Konfigurasi tipikal

Lini produk perangkat lunak 1C didasarkan pada konfigurasi standar. Ada cukup banyak solusi kotak siap pakai yang disajikan di situs web 1C.

Namun mayoritas pengguna hanya menggunakan 4 konfigurasi:

Akuntansi perusahaan
Manajemen perdagangan
Manajemen pabrik manufaktur
Manajemen gaji dan SDM

Dan masing-masing konfigurasi memiliki kelemahan yang sama dengan platformnya:

Kurangnya modularitas
Fungsi besar dan banyak yang tidak perlu
Bug baru di versi baru
Hasil pembaruan tidak dapat diprediksi

Selain itu, untuk setiap pembaruan, Anda perlu menganalisis apa sebenarnya yang diperbarui, melakukan pembaruan itu sendiri, dan mengkonfigurasi ulang konfigurasi. Namun pembaruan konfigurasi juga sering keluar sehingga sulit untuk memahaminya.

Selain itu, karena kurangnya modularitas, Anda sering kali harus memperbarui, meskipun perubahan tersebut memengaruhi fungsi yang tidak Anda gunakan. Hanya karena kesalahan dalam fungsi ini dapat menyebabkan pengoperasian modul lain yang salah.

Jika kita berbicara tentang Perdagangan, praktik saya menunjukkan bahwa sebenarnya orang menggunakan tidak lebih dari 30% dari total fungsi komponen ini. Situasi serupa terjadi pada konfigurasi tipikal lainnya. Dalam upaya mengimplementasikan jumlah fitur maksimum, pengembang telah menciptakan produk yang sangat rumit dan kompleks di mana semuanya saling berhubungan, dan oleh karena itu bahkan menonaktifkan fungsi yang tidak perlu tidak selalu memungkinkan.

Misalnya, saat memperbarui Trade, pengembang menambahkan sistem bonus baru. Klien tidak menggunakan bonus sama sekali. Dia tidak membutuhkannya. Tetapi jika Anda mencoba menonaktifkan bonus ini, sistem diskon mulai tidak berfungsi. Saya menghadapi situasi ini dalam praktik. Tentu saja untuk menyelesaikan masalah ini diperlukan bantuan seorang programmer.

Akhir-akhir ini, saya sampai pada kesimpulan bahwa, setelah menyelesaikan sebuah proyek, saya menyarankan semua klien untuk tidak memperbarui sama sekali. Saya mengonfigurasi semuanya sesuai kebutuhan untuk bekerja, bersama dengan klien dan karyawannya kami menguji konfigurasi dan memastikan semuanya bekerja dengan baik. Oleh karena itu, tidak perlu memperbarui konfigurasi hingga diperlukan perubahan besar.

Pemasaran agresif dan hasilnya

Sangat sering klien saya menginstal pembaruan yang bertentangan dengan saran saya. Mengapa ini terjadi?

Motivasi pemrogram

Pemrogram 1C tertarik agar klien memperbarui perangkat lunaknya sesering mungkin. Ini hanya bermanfaat bagi mereka. Setiap kali Anda memperbarui, Anda perlu mengkonfigurasi ulang konfigurasinya. Oleh karena itu, dengan bantuan pembaruan, mereka benar-benar menerima penghasilan begitu saja.

Bayangkan sebuah situasi di mana sebuah perusahaan beroperasi dalam konfigurasi tertentu tanpa pembaruan dengan tenang dan andal. Namun ada kebutuhan, misalnya, untuk membuat laporan lain atau memasang pemrosesan tambahan. Tentu saja, dalam hal ini mereka beralih ke spesialis.

Apa yang terjadi selanjutnya? Seorang programmer 1C datang dan melihat bahwa program tersebut sudah lama tidak diperbarui. Dia memberi tahu klien betapa buruknya hal ini, menjelaskan bahwa tanpa pembaruan dia tidak akan dapat menyiapkan laporan yang dibutuhkan pelanggan atau melakukan pekerjaan lain, membuatnya takut dengan banyaknya kesalahan yang ada di versi lama, dll. dan seterusnya. Secara umum, ini meyakinkan klien untuk membeli dan menginstal pembaruan.

Faktanya, dalam banyak kasus, pembaruan tidak diperlukan secara obyektif. Tetapi jumlah pekerjaan yang dilakukan programmer dan, karenanya, bayarannya meningkat secara signifikan. Omong-omong, inilah sebabnya banyak pengguna memiliki sikap negatif terhadap pemrogram 1C. Dari sudut pandang mereka, mereka membayar 90% dari jumlah tersebut kepada pemrogram untuk sesuatu yang berfungsi sempurna sebelum dia mulai bekerja, yaitu. mereka harus membayar untuk fungsi yang sama beberapa kali.

Pemasaran agresif dari 1C

Perusahaan 1C sendiri juga tertarik untuk memastikan bahwa pengguna diperbarui sesering mungkin. Akibatnya, pengguna sering menerima pengingat tentang pembaruan baru, peringatan tentang perlunya memperbarui platform atau konfigurasi. Tetapi pada saat yang sama, situs tersebut tidak memiliki informasi yang cukup rinci tentang apa sebenarnya yang akan diterima pengguna jika ada pembaruan, bug apa yang telah diperbaiki, fitur apa yang telah muncul. Itu. Tidak mungkin menilai secara objektif kebutuhan untuk menginstal pembaruan tertentu. Akibatnya, banyak pengguna memperbarui hanya untuk berjaga-jaga.

Kekurangan layanan dan waralaba

Saya yakin praktis tidak ada layanan pelanggan di perusahaan 1C. Perusahaan melakukan pekerjaan yang sangat baik dalam penjualan, memang memiliki kebijakan pemasaran yang sangat agresif dan, memang, efektif. Namun jika membutuhkan perawatan, Anda akan menghadapi banyak kesulitan.

Ada seluruh bagian di situs web 1C tempat Anda dapat menemukan mitra bersertifikat di wilayah Anda yang menyediakan layanan pemeliharaan untuk produk perangkat lunak 1C. Mitra ini telah tersertifikasi dan membayar biaya afiliasi. Tampaknya semuanya beres.

Namun kenyataannya, perusahaan 1C praktis tidak bekerja sama dengan mitra:

Agar suatu perusahaan dapat memperoleh status mitra, cukup memiliki staf spesialis bersertifikat.
Selanjutnya, tidak ada yang melakukan pemeriksaan atau ujian berulang kali. Oleh karena itu, seorang programmer bersertifikat mungkin satu-satunya spesialis, dan orang yang sama sekali berbeda akan datang untuk melayani Anda, atau dia mungkin berhenti sama sekali, tetapi perusahaan tidak kehilangan status mitranya.
1C praktis tidak bekerja sama dengan mitra, tidak memberikan pelatihan, dan tidak mengontrol kualitas pekerjaan.

Hasil dari kebijakan seperti ini diketahui banyak orang. Kehadiran perusahaan tertentu dalam daftar mitra 1C tidak menjamin kualitas layanan.

Saya telah menyebutkan bahwa 1C adalah keseluruhan ekosistem. Dalam beberapa hal bahkan bisa dibandingkan dengan Apple. Ada keseluruhan sistem yang dibangun di sana, terdiri dari perangkat keras, perangkat lunak, dan reseller. 1C juga punya platform, ada konfigurasi, ada reseller bersertifikat.

Tetapi jika Apple mengontrol kualitas dengan sangat ketat di semua tahap - mulai dari produksi hingga pekerjaan mitra, dan kualitas tertinggi adalah salah satu keunggulan kompetitif penting untuk merek ini, maka di perusahaan 1C semuanya benar-benar berbeda. Praktis tidak ada layanan di sini, tidak ada yang mengontrol pekerjaan mitra, akibatnya kualitas pekerjaan pasca-penjualan dengan perangkat lunak sangat rendah.

Menarik juga bahwa perusahaan 1C mengarahkan upaya pemasarannya terutama kepada konsumen produk, yaitu. pada pengguna. Dan bekerja dengan konfigurasi sepenuhnya terfokus pada programmer. Alhasil, ada satu hal yang diiklankan, namun dalam praktiknya ternyata pembeli menerima sesuatu yang sama sekali berbeda.

Dan di sini juga muncul alasan negatif terhadap programmer 1C dan produk perangkat lunak itu sendiri.
Ketika saya berhenti bekerja hanya dengan 1C dan mulai melakukan konsultasi bisnis, saya mulai menggunakan berbagai produk perangkat lunak dalam pekerjaan saya. Ini adalah situs di Drupal, dan sistem seperti ZOHO CRM, ATOL RMK, Redmine, dan banyak sistem lainnya. Dan hampir semua layanan dan program ini tidak memerlukan pembaruan yang terus-menerus dan sering. Dan saat update tidak banyak masalah.

Sementara perusahaan 1C menghasilkan uang dalam dua arah: dari penjualan dan pembaruan terus-menerus. Tapi apa hubungannya klien dengan itu? Dia terpaksa membayar dan meningkatkan, karena tidak ada pilihan lain. Selain itu, semua produk yang digunakan di perusahaan harus diperbarui secara bersamaan.

Misalnya, jika Anda menggunakan Perdagangan, pembaruan yang sangat berguna telah dirilis untuk memperbaiki beberapa bug yang relevan bagi Anda, Anda pasti perlu memperbarui Akuntansi juga. Karena pertukaran data hanya dimungkinkan antara versi konfigurasi yang identik. Jika Anda memutuskan untuk keluar dari Akuntansi tanpa memperbarui, maka mengunggah dokumen dari Perdagangan ke Akuntansi tidak lagi berfungsi untuk Anda.

Akibatnya, klien terpaksa menggunakan sistem yang terus-menerus rusak dan secara rutin membayar untuk memulihkannya. Tentu saja klien menjadi negatif. Tapi dia tidak bisa beralih ke produk perangkat lunak lain, dia tidak melihat alternatif yang layak.

Ya, ada sistem akuntansi lain di negara kita, beberapa di antaranya bahkan secara bertahap mengejar 1C dalam hal kemampuannya. Tapi pemasaran adalah hal yang hebat! Oleh karena itu, klien tidak melihat alternatif lain, dan, meskipun ada hal negatif yang terus-menerus, melakukan pembayaran lain.

1C: Bitrix - kesulitan, fitur, pemasaran

Produk lain yang secara tradisional diklasifikasikan sebagai bagian dari lini 1C adalah sistem manajemen situs web 1C-Bitrix. Pada saat yang sama, banyak pengguna yakin bahwa membeli Bitrix saja sudah cukup, dan semua masalah dalam mengintegrasikan situs dan data ke dalam 1C akan teratasi.

Pengguna yang membeli produk perangkat lunak 1C dan memesan situs web di 1C-Bitrix melihat merek yang sama dan yakin bahwa ini adalah produk dari lini yang sama yang akan selalu bekerja sama tanpa masalah.
Faktanya, CMS Bitrix adalah produk terpisah yang dikembangkan oleh spesialis yang tidak ada hubungannya dengan perusahaan 1C. Kemudian, alat integrasi dengan produk lini 1C ditambahkan ke CMS ini, dan nama baru “1C-Bitrix” muncul. Hal ini terjadi karena perusahaan 1C membeli sebagian besar saham Bitrix dan memutuskan untuk menggunakan CMS ini beserta perangkat lunaknya.

Apakah hasilnya?

Integrasi database toko online dan produk software 1C memang disediakan. Tapi ini sangat rumit, dan tanpa bantuan seorang spesialis hampir tidak mungkin untuk mengatur pertukaran data, dan sangat, sangat sulit untuk mengubahnya.

Selain itu, pemrogram yang menyiapkan 1C untuk Anda tidak akan dapat menginstal dan mengkonfigurasi Bitrix. Di sini Anda memerlukan seorang programmer web, spesialis Bitrix. Integrasi ini sebagian dikonfigurasi oleh pemrogram 1C, sebagian lagi oleh spesialis Bitrix. Dan ada kalanya pengguna tidak tahu siapa yang harus dihubungi sama sekali.

Misalnya, saya mengalami situasi ini. Setelah pembaruan terkini, pertukaran data klien saya dengan situs berhenti berfungsi. Saya beralih ke spesialis 1C, tetapi dia tidak dapat membantu kami, karena menurut pendapatnya, masalahnya ada di pihak Bitrix. Kami beralih ke programmer Bitrix. Ia pun angkat tangan dan mengatakan bahwa kemungkinan besar masalahnya masih ada di pihak 1C. Pertukaran data dengan situs tidak berfungsi selama sekitar 2 minggu. Klien terpaksa mengunduh harga dan saldo secara manual serta membongkar pesanan dari situs web. Pada akhirnya, kami beruntung. Saya menghubungi seorang programmer yang mengetahui Bitrix dan 1C, dan dia menyiapkan modul pertukaran.

Bitrix dan 1C: sistem berbeda, kekurangan umum

Pengembang web yang familiar dengan versi terbaru Bitrix akan memahami saya sekarang. Sama seperti produk perangkat lunak 1C, versi terbaru Bitrix menjadi sangat kuat, dengan kemampuan yang luas, tetapi pada saat yang sama menjadi sangat rumit. Saat ini, tanpa bantuan administrator (pemrogram web) di Bitrix, pengguna seringkali bahkan tidak dapat mengatur kategori baru di katalog produk, karena untuk mengatur pencarian cerdas, Anda perlu mengatur parameter Anda sendiri untuk setiap jenis produk.

Pada saat yang sama, Anda memerlukan spesialis yang berbeda untuk memelihara situs web dan program 1C. Bagaimanapun, ini adalah produk yang berbeda. Mereka digunakan untuk tujuan yang berbeda, memiliki platform yang berbeda, dan memerlukan pengetahuan tentang teknologi yang berbeda untuk bekerja dengannya.

Alih-alih resume

Jadi mari kita rangkum. Produk perangkat lunak dari lini 1C menyebabkan hal negatif di kalangan spesialis karena alasan berikut:

Kompleksitas sistem yang tinggi
Kurangnya modularitas
Bug di setiap pembaruan
Kurangnya dokumentasi terperinci untuk pembaruan
Hasil instalasi pembaruan yang tidak dapat diprediksi

Semua ini berlaku untuk platform dan konfigurasi 1C apa pun.

Negatif dari pengguna disebabkan oleh:

Hasil yang tidak dapat diprediksi dari pemasangan pembaruan. Program ini dapat berhenti bekerja kapan saja. Namun karena adanya bug pada versi sebelumnya, maka diperlukan pembaruan.
Baik perusahaan 1C maupun pemrogram harus membayar untuk pembaruan. Pada saat yang sama, keuntungan yang terlihat oleh pengguna dalam banyak kasus tidak signifikan, dan sebagian besar biaya harus dibayar untuk memulihkan fungsionalitas program setelah menginstal versi baru.

Negatif terhadap programmer 1C juga menjadi jelas:

Pengguna mentransfer beberapa hal negatif tentang program ini ke spesialis. Bagaimanapun, pemrogram 1C-lah yang menerima pembayaran untuk menginstal pembaruan dan mengatur konfigurasi.
Pemrogram yang bekerja di bidang lain memahami bahwa sering kali rekan mereka yang berspesialisasi dalam 1C menerima uang, pada dasarnya, untuk “menjual udara”. Hal ini terutama terlihat ketika pembaruan diberlakukan pada klien oleh spesialis itu sendiri.
Karena kurangnya kontrol dari 1C, orang-orang secara acak terlibat dalam pemeliharaan produk perangkat lunak, yang juga tidak berkontribusi pada citra positif.

Ini adalah kesimpulan yang saya buat secara pribadi. Mungkin saya tidak sepenuhnya benar tentang sesuatu, mungkin saya melewatkan sesuatu. Bagaimanapun, saya memutuskan untuk menulis artikel ini bukan untuk kritik, tetapi untuk memahami alasan apa klien mungkin memiliki sikap negatif terhadap program lini 1C dan pemrogram 1C.

Tag: Tambahkan tag