害虫駆除
取引相手のステータスが悪い 1 秒です。ペーパーレス電子文書フローへの移行: 経験、問題点、展望

取引相手のステータスが悪い 1 秒です。ペーパーレス電子文書フローへの移行: 経験、問題点、展望

バージョン 1.3.8 は、エディション 1.3「1C: 電子ドキュメントライブラリ 8」を発展させたもので、1C:Enterprise プラットフォームバージョン 8.3.10.2252 以降で開発されたアプリケーションソリューションで電子ドキュメントを確実に交換できるように設計されています。

新機能と変更点

取引案件の検索フォームに、1C:ビジネスネットワークサービスに接続せずに検索できる機能が追加され、サプライヤー名で検索できる機能が追加されました。
公開された取引オファーに関するレポートを追加しました。
1C:Business Network サービスに取引オファーを公開するためのワークスペースが追加されました。
サブシステム「1C: Library of Standard Subsystems」バージョン 2.4.2、「1C: Library of Internet User Support」バージョン 2.2.2 で適応が行われました。

バージョン 1.3.7 からバージョン 1.3.8 への移行

定義型が追加されました 相手方BED、定義されたタイプ 取引相手削除されましたアップデート時 必然的に新しいデータ型を設定する、そうでない場合削除サブシステムオブジェクトの取引相手に関するデータ 交換取引相手（書類 電子文書のパッケージ、情報登録 BED カウンターパーティの状況).

モジュールの変更:

追加機能 公開製品のリクエストテキストトレードオファーを公開し、公開された商品に関するレポートを生成するためのデータソースを取得します。商品一覧を取得する際には、FillOfferPackageメソッドへの関数呼び出しを実装する必要があります。

モジュールの変更点 トレードオファー

手順の追加 更新装飾条件出版物装飾フォーム要素を公開状態で更新します。ステータス要素の公開設定をフォームの呼び出しに追加する必要があります。

役割が追加されました レポート取引オファーレポートにアクセスするために必要です 公開されたトレードオファー.

バージョン1.3.7

バージョン 1.3.7 は、エディション 1.3「1C: 電子ドキュメントライブラリ 8」を発展させたもので、1C:Enterprise プラットフォームバージョン 8.3.10 以降で開発されたアプリケーションソリューションで電子ドキュメントを確実に交換できるように設計されています。

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

Sberbank から支払い文書のステータスを取得する機能が追加されました。
1C:DirectBank サービスに接続するときの Sberbank の設定の自動受信を実装しました。
コンテキスト広告 1C:DirectBank を表示する機能を追加しました。
1CFresh クラウドサービスの 1C: Business Network サービスと連携するように調整されています。
1C: Business Network サービスの参加者向けに、1C: Trade Offers サービスでトレードオファーを公開、検索、注文する機能が追加されました。
適応は、サブシステム「1C: Library of Standard Subsystems」バージョン 2.4.1、「1C: Library of Internet User Support」バージョン 2.1.9、「1C: Library of Service Technology」バージョン 1.0.12 で実行されました。

サブシステム「取引先とのやりとり」

モジュールの変更:

文書の日付, DocBaseDate

サブシステム「銀行との取引所」

モジュールの変更点 ファイルの操作オーバーライド可能:

手続きへ 設定を定義するときコードを追加する必要があります:

ElectronicInteraction.WhenDefiningSettings(設定);

手続きへ ファイル格納ディレクトリを定義する場合コードを追加する必要があります:

電子インタラクション。FileStorage ディレクトリを定義するとき(FileOwnerType, DirectoryNames);

ディレクトリ MessageExchangeWithBanksAttachedFiles および EDAttachedFiles が交換計画 UpdateInformationBase に追加されました。
ディレクトリ MessageExchangeWithBanksAttachedFiles および EDAttachedFiles が、定義されたタイプ SignedObject に追加されました。

クライアントバンク) 一般的なフォームから要素のグループを移動します。

フォームイベントハンドラー内 サーバー上で作成されたとき

サーバー上(&O)

…

手順の終了

フォームイベントハンドラー内 アラートの処理中

&OnClient

…
// 電子的なやり取り、銀行との交換

Elements.GroupAdvertisingDirectBank水平方向、Elements.TextDirectBank水平方向);
// 電子的なやりとりを終了し、銀行と交換する
手順の終了

要素の場合 TextDirectBank水平方向イベントハンドラを追加する 処理ナビゲーションリンク

&OnClient

手順の終了

共通モジュール手順へ 電子インタラクション 支払い命令アプリケーションソリューションで。

サブシステム「拠点との交換」

モジュールの変更点 Site Exchangeオーバーライド可能:

手順の追加 詳細フォームノードを追加、サイトとの Exchange から交換計画ノードに詳細を追加するために使用されます。交換ノードフォームは、アプリケーションソリューションに関連する詳細の存在を前提としていません。詳細はプログラムによって追加されます。
手順の追加 入力フィールドWhenChangedOnServerは、交換計画ノードフォームの入力フィールドが変更されたときのイベントを北で処理するために使用され、Add NodeFormDetails プロシージャに追加されます。
手順の追加 サーバー上で変更されたときのチェックボックスフィールドは、NodeFormDetails の追加手順で追加された交換計画ノードフォームのフラグフィールドが変更されたときに、サーバー上でイベントを処理するために使用されます。
手順の追加 作成時サーバーフォーム作成サイト、CreateSite 処理フォームに詳細を追加するために使用されます。

モジュールの変更点 ExchangeSiteClientOverridable:

削除されたプロシージャ GroupTableU カタログタイプの定義、製品カタログ表の「グループ」列の値のタイプは、交換設定によって決まります。
手順の追加 入力フィールドオン変更、交換計画ノードフォームの入力フィールドが変更されたときにイベントを処理するために呼び出され、SiteExchangeOverridden.AddNodeFormDetails プロシージャに追加されます。
手順の追加 チェックボックスフィールドオンチェンジは、SiteExchangeOverridden.AddNodeFormDetails プロシージャで追加された交換計画ノードフォームのフラグフィールドが変更されたときに、イベントを処理するために呼び出されます。
手順の追加 テーブルフォーム終了編集前は、SiteExchangeOverridden.AddNodeFormDetails プロシージャで追加された交換計画ノードのフォームの表形式部分にあるフィールドの BeforeFinishEdit イベントを処理するために呼び出されます。

サブシステム「ビジネスネットワーク」

分割モードでルーチンタスクを実行するための新しいメソッド、共通モジュールを追加しました 電子インタラクション、手続き テンプレートのリストを受け取ったら、。一般モジュール JobQueueOverridable の同じ名前のメソッドを参照してください。
ライブラリを埋め込む場合、分割モードで動作するには、一般モジュールのメソッドへの呼び出しを追加する必要があります。 JobQueueOverridable:
- 手続きの中で テンプレートのリストを受け取ったら:

// 電子的相互作用
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

手続きの中で AliasesHandler を定義する場合:

// 電子的相互作用
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// 電子的なやり取りを終了する

モジュールの変更点 ビジネスネットワークオーバーライド可能:
- プロシージャの名前がに変更されました ユーザーの連絡先情報を取得する.
- プロシージャが関数に変更されました 詳細に従って取引相手を作成するでは、Account パラメーターが削除されました。

サブシステム「トレードオファー」

新しいサブシステム「Trade Offers」が追加されました。埋め込みには以下が必要です。

共通モジュールでオーバーライドされたメソッドを開発する TradeOffersClientOverridable, TradeOffersオーバーライド可能.
定義された型でデータ型を指定する 詳細の値の種類 1СBusinessNetwork, BED の命名法の種類, 追加詳細ベッド, トレードオファー.

詳細については、埋め込みドキュメントを参照してください。

バージョン1.3.6

バージョン 1.3.6 は、エディション 1.3「1C: 電子ドキュメントライブラリ 8」を発展させたもので、1C:Enterprise プラットフォームバージョン 8.3.8 以降で開発されたアプリケーションソリューションで電子ドキュメントを確実に交換できるように設計されています。この場合、構成プロパティ「互換モード」を「バージョン 8.3.8」に設定する必要があります。

この構成は、バージョン 2.3.4.112 以上の構成「1C: Library of Standard Subsystems」およびバージョン 2.1.9.4 以上の構成「1C: Library of Internet User Support 8」と併用することを目的としています。

新機能と変更点

主要な請求書文書の形式は、2016 年 3 月 24 日付けの連邦税務局命令 No. ММВ-7-15/155@ に従ってサポートされます (別の主要文書である請求書の転送に関して)。電子形式での請求書を含む、商品の発送（業務の履行）、財産権の譲渡（サービスの提供に関する文書）に関する請求書フォーマットおよび文書提示フォーマット。」
2016 年 4 月 13 日付けの連邦税務局の命令に従って、調整請求書を含む、価値の変更に関する主要文書の形式がサポートされています (別の主要文書である調整請求書の転送に関して)。 -7-15/189@ " 調整請求書のフォーマットと、出荷された商品のコスト（実行された作業、提供されたサービス）の変更に関する文書を提出するためのフォーマットの承認に基づいて、調整請求書を含む所有権が譲渡されました。電子フォーム。」
新しい電子文書が追加されました。商品の譲渡、作業結果の譲渡、文書の視覚的表示の新しい形式です。
受信者からの受信通知を必要としない一方向の交換メカニズムが追加されました。
受信した電子ドキュメントの解凍 (自動または手動) を制御する機能、電子ドキュメントの受信時に特定の種類のドキュメントの作成を構成する機能が追加されました。
電子ドキュメントを複数の情報ベースの会計ドキュメントにリンクする機能が追加されました。
電子文書を受信用と送信用に分割することが実装されました。
サービスとの統合が実装されました 1C-UMIプログラムからウェブサイトを作成したり、オンラインストアとの交換を設定したりすることができます海.
1CFresh クラウドサービスの 1C-EDO サービスと連携するように調整されました。

バージョン 1.3.5 からバージョン 1.3.6 への移行

サブシステム「取引先とのやりとり」

一般モジュールExchangewithCounters再定義可能

UPD SCHFDOP メソッドを追加しました。
追加されたメソッド UPD 購入者情報のデータを入力する連邦税務局。このメソッドは、タイプ UPD (購入者情報) 関数 SCHFDOP の電子ドキュメントのデータを準備します。
情報セキュリティオブジェクトにUPDメソッド(販売者情報)関数SCHFDOPを追加しました。
追加されたメソッド 販売者の連邦税務局の追加情報のデータを入力します。。 STD（販売者情報）DOP機能などの電子文書用のデータを作成する方法です。
追加されたメソッド 検索UPDT ドキュメントの作成転送について。このメソッドは、電子文書 UPD (販売者情報) 関数 DOP からのデータを IS オブジェクトに保存します。
追加されたメソッド SCHFIS販売者情報のデータを入力します連邦税務局。このメソッドは、タイプ UTD (販売者情報) SSF 関数の電子ドキュメントのデータを準備します。
追加されたメソッド 検索作成UPDS請求書請求書。このメソッドは、電子文書 UPD (販売者情報) SSF 機能からのデータを情報セキュリティオブジェクトに保存します。
メソッドを追加しました。このメソッドは、UCD タイプ (販売者情報) 関数 KSCHFDIS の電子ドキュメントのデータを準備します。
追加されたメソッド UKID 購入者情報のデータを入力する連邦税務局。このメソッドは、タイプ UKD (購入者情報) 関数 KSCHFDIS の電子文書のデータを準備します。
メソッドを追加しました。このメソッドは、電子文書 UCD (販売者情報) 関数 KSCHFDIS からのデータを情報セキュリティオブジェクトに保存します。
追加されたメソッド 販売者の連邦税務局の DIS 情報のデータを入力します。。 UCD型（販売者情報）DIS機能の電子文書データを作成する方法です。
追加されたメソッド FindCreateUKDDocumentAboutChangeValue。このメソッドは、電子文書 UCD (販売者情報) 関数 DIS からのデータを IS オブジェクトに保存します。
追加されたメソッド KSCHFIS販売者の情報のデータを入力します連邦税務局。このメソッドは、UCD タイプ (販売者情報) 関数 KSCHF の電子文書のデータを準備します。
追加されたメソッド 検索英国DSアカウント請求書の作成。このメソッドは、電子文書 UCD (販売者情報) 関数 KSCHF からのデータを情報セキュリティオブジェクトに保存します。
追加されたメソッド 送信タイプの ED と情報セキュリティ文書の遵守。この方法は、送信される電子文書と情報セキュリティ文書との間の対応関係を形成します。
追加されたメソッド 検索作成文書転送作業結果。この方法は、「物品の転送」形式で受け取った送り状文書に記入するために使用されます。
追加されたメソッド 検索文書作成商品の譲渡。この方法は、「作業結果の転送」形式で受け取ったサービス提供証明書の文書に記入するために使用されます。
追加されたメソッド インストール済み状態交換完了。このメソッドは、ドキュメントフローの状態が次のように変化すると呼び出されます。 交換完了, 交換完了（修正あり）.
電子文書作成時 UPD、UKD、物品の譲渡、作業結果の譲渡、詳細 文書の日付, DocBaseDateを記入する必要があります。

取引先とのやり取りの処理

「Torg-12Seller」レイアウトの場合:

「IdStateContract」フィールドを追加しました。
表形式パーツ「輸送請求書」が追加されました。
「Transport InvoiceDate」および「Transport InvoiceNumber」フィールドは削除されました。
「物品の譲渡者に関する情報」の項目を追加しました。

レイアウトでは 権利譲渡法:

表形式パーツ「ベース」を追加しました。
「DocumentBaseName」、「DocumentBaseNumber」、「DocumentBaseDate」、「DocumentBaseAdditionalInformation」フィールドが削除されました。
「通貨名」フィールドを追加しました。
「クレーム」フィールドを追加しました。
「実行日」フィールドを追加しました。
トランザクション参加者のプロパティで、「FAX」フィールドが「電子メール」フィールドに置き換えられました。
トランザクション参加者のプロパティで、「国コード」フィールドが「国コード」フィールドに置き換えられました。
トランザクション参加者のプロパティで、「AddressText」フィールドが「AddressText」フィールドに置き換えられました。

定義されたタイプの更新 取引相手:

バージョン 1.3.5 からアップグレードする場合、定義されたタイプの Counterparty を更新する必要があります。そうしないと、BED オブジェクト内の Counterparty ディレクトリへの参照が更新されると、オブジェクトへの参照が失われ、文字列タイプに置き換えられます。回復。

アップデート手順：

定義されたタイプの Account の名前を AccountBED に変更します。
BED 1.3.5 のサポートから構成を削除します。
BED 1.3.5 構成との比較/マージを実行し、構成をサポートするように設定することに同意します。
すべてのオブジェクトのチェックを外し、定義されたアカウントタイプのみを残し、マージを実行します。
構成の更新を開始し、BED ファイル 1.3.6 を選択します。
定義済みタイプ AccountBED および Account のチェックボックスを選択します。更新に必要なその他のデータベースオブジェクトを指定します。
アップデートを実行します。

サブシステム 「銀行との両替」

手続きへ 銀行取引明細書を取得する共通モジュール 銀行クライアントとの交換オプションのパラメータを追加しました オープンフォーム明確化期間タイプ付き ブール値。ステートメントの受信元のフォームにステートメント要求期間を手動で変更する機能がない場合は、True に設定する必要があります。

サブシステム「拠点との交換」

Exchangeノードが変更されました サイトエクスチェンジ、フォーム、オブジェクトモジュール:

アイテムタイプごとに選択してアイテムをアップロードする機能が追加されました (以前はアイテムグループによってのみ利用可能でした)。

参考書を追加しました ウェブサイト:

1C からサイトのユーザー部分、およびサイトの管理領域への移行を構成する機能が追加されました。
サイトに基づいて、ExchangeSite 交換ノードを作成できます。

追加処理 ウェブサイトを作成する:

1C-UMI ドメインにサイトを作成する機能が追加されました。サイトは自動的に作成され (Sites 要素)、1C からのデータが入力されます。 ExchangeSite 交換ノードが自動的に作成され、サイトとの最初の完全な交換が実行されます。

一般モジュール Site Exchangeオーバーライド可能:

項目の種類を選択する機能が追加され、任意の参考書を選択する機能が削除されました。

一般モジュール Exchangeサイトイベント:

アイテムの種類を選択する機能が追加されました。
カスタムディレクトリを選択する機能は削除されました。

その他の変更点

サブシステムのセットアップ 料金管理図書館サービスモデルにおいて サービス技術

共通モジュールへ 関税再定義可能サービスのリストを形成するとき () メソッドでは、InternetUser Support メソッドを呼び出した後にコードを追加する必要があります。サービスのリストを形成するとき (サービスプロバイダー):

// 電子的相互作用
電子的やりとり。サービス（サービスプロバイダー）のリストを作成する場合。
// 電子的なやり取りを終了する

バージョン1.3.5

バージョン 1.3.5 は、「1C: 電子ドキュメントライブラリ 8」のエディション 1.3 を発展させたもので、1C:Enterprise プラットフォームバージョン 8.3.8 以降で開発されたアプリケーションソリューションで電子ドキュメントを確実に交換できるように設計されています。

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

ライブラリ機能は、互換モードが無効になっている 8.3.8 プラットフォームで動作する特定の機能に適合しました。
「標準サブシステムライブラリ」のサブシステムがバージョン 2.3.3.45 に更新されました。
このライブラリには、サブシステム「Internet User Support Libraries」バージョン 2.1.8.3 が含まれています。

バージョン 1.3.4 からバージョン 1.3.5 への移行

変更は必要ありません。

バージョン1.3.4

バージョン 1.3.4 は、「1C: 電子ドキュメントライブラリ 8」のエディション 1.3 を発展させたもので、1C:Enterprise プラットフォームバージョン 8.3.6 以降で開発されたアプリケーションソリューションで電子ドキュメントを確実に交換できるように設計されています。この場合、構成プロパティ「互換モード」を「使用しない」に設定する必要があります。モダリティ利用モードを「使用しない」、インターフェース互換モードを「バージョン8.2」、「バージョン8.2.タクシーを許可する」または「タクシー。バージョン8.2を許可する」に設定できます。

新機能と変更点

EDI イベントに関する通知システムが実装されました (新しい電子ドキュメント、新しい招待状、証明書の有効期限など)。 EDF 設定プロファイルで電子メール通知を構成できるようになったほか、ポップアップメッセージを使用して 1C プログラムでイベントに関する通知を直接表示できるようになりました。
2016 年 3 月 24 日付連邦税務局命令 No. ММВ-7-15/155@ に基づく請求書 (UPD 形式) を含む主要文書の形式がサポートされています。請求書を含む、商品の発送（業務の遂行）、所有権の譲渡（サービスの提供に関する文書）に関する文書を電子形式で提出するためのフォーマット。
2016 年 4 月 13 日付けの連邦税務局の命令に従って、調整請求書を含む金額の変更に関する文書の形式がサポートされました。N ММВ-7-15/189@ 「調整請求書の形式と、出荷された商品（実行された作業、提供されたサービス）のコストの変更に関する電子形式での調整請求書を含む所有権の譲渡に関する表示形式文書の承認に基づいて」。
DirectBank テクノロジーを使用した銀行との交換における外部コンポーネントの使用をサポートしました。

バージョン 1.3.2、1.3.3 からバージョン 1.3.4 への移行

アプリケーションソリューションドキュメントリストフォームの変更

ドキュメントリストフォームでは、プラグインプロシージャを追加する必要があります CounterpartyClient.Waiting ProcessorEDW との交換:

&OnClient

手順の終了

サブシステムを更新する場合、ドキュメントリストフォームのイベントハンドラーで次のことが必要です。 サーバー上で作成されたとき, 開くとき, アラートの処理中

サーバー上(&O)
サーバー上で作成する場合の手順
…
ParametersWhenCreatedOnServer = ExchangeWithCounterparties.ParametersWhenCreatedOnServer_ListForm();
パラメータWhenCreatedOnServer.Form = ThisObject;
パラメーターWhenCreatedOnServer.LocationofCommands = Elements.EDO コマンド;
ExchangewithCounterparties.WhenCreatedOnServer_ListForm(Failure, StandardProcessing, ParametersWhenCreatedOnServer);
手順の終了

&OnClient
開封手順（失敗）
…
// サブシステム「取引相手との交換」。
// 「取引先取引所」サブシステムの終了。
手順の終了

&OnClient
プロシージャプロセス通知(イベント名、パラメータ、ソース)
…
// サブシステム「取引相手との交換」。
アラートパラメーターEDO = CounterpartiesClient.AlertParametersEDO_ListForm(); と交換します。
EDO 通知パラメータ.Form = ThisObject;
EDO 通知パラメータ.DynamicListName = "リスト";
ExchangewithCounterpartiesClient.ProcessingAlert_ListForm(イベント名、パラメーター、ソース、EDI アラートパラメーター);
// 「取引先取引所」サブシステムの終了。
手順の終了

アプリケーションソリューションのドキュメント形式の変更

ドキュメントフォームではプラグインプロシージャを追加する必要があります Connectable_WaitingHandlerEDO、メソッド呼び出しを配置する必要がある場所

CounterpartiesClient.Waiting ProcessorEDW との交換:

&OnClient
プロシージャ Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
手順の終了

ドキュメントフォームでは、フォーム属性「EDO Status」を削除し、代わりに「装飾」フォーム要素を追加する必要があります。アプリケーションソリューションのニーズに応じて、装飾を「グループ」フォーム要素に従属させることができます。グループの可視性はメソッド内で設定されます 取引相手との交換サーバー上に作成された場合 f.o.の状態にもよりますが、「取引相手とのExchangeを利用する」

サブシステムを更新する場合、ドキュメント形式のイベントハンドラーが必要です サーバー上で作成されたとき, 開くとき, サーバー上の録画後, アラートの処理中「Counterparty Exchange」サブシステムのメソッドを配置します。

例えば：

サーバー上(&O)

…
// サブシステム「取引相手との交換」。
作成時の EDO パラメータ = 取引相手との交換 Server_DocumentForm() で作成時のパラメータ
作成時の EDO パラメータ。Form = ThisObject;
作成時の EDO パラメータ.DocumentLink = Object.Link;
作成時の EDO パラメータ。DecorationStateEDO = Elements.DecorationStateEDO;
作成時の EDO パラメータ。EDO 状態グループ = Elements.EDO 状態グループ;
取引相手との交換。作成時サーバー_ドキュメントフォーム(拒否、標準処理、EDO パラメータ作成時);
// 「取引先取引所」サブシステムの終了。
手順の終了

&OnClient
開封手順（失敗）
…
// サブシステム「取引先との交換」
ExchangeWithCounterpartiesClient.OnOpening(ThisObject);
// エンドサブシステム「取引相手との交換」
手順の終了

サーバー上(&O)
プロシージャ AfterRecordOnServer(CurrentObject, RecordParameters)
…
// サブシステム「取引相手との交換」。
ParametersAfterRecord = ExchangeWithCounterparty.ParametersAfterRecordOnServer();
パラメータAfterRecord.Form = ThisObject;
パラメータAfterRecord.DocumentLink = Object.Link;
パラメータAfterRecording.DecorationStateEDO = Elements.DecorationStateEDO;
パラメータAfterRecord.GroupEDOStatus = Elements.GroupEDOState;
ExchangewithCounterparties.AfterRecordOnServer(CurrentObject, RecordParameters,AfterRecordParameters);
// 「取引先取引所」サブシステムの終了。
手順の終了

&OnClient
プロシージャプロセス通知(イベント名、パラメータ、ソース)
…
// サブシステム「取引相手との交換」。
アラートパラメーター = ExchangewithCounterpartiesClient.AlertParametersEDO_DocumentForm();
AlertParameters.Form = ThisObject;
AlertParameters.DocumentLink = オブジェクト.リンク;
アラートパラメータ.DecorationEDO State = Elements.DecorationEDO State;
アラートパラメーター.EDO 状態グループ = Elements.EDO 状態グループ;
ExchangeWithCounterpartiesClient.ProcessingAlert_DocumentForm(イベント名、パラメーター、ソース、アラートパラメーター);
// 「取引先取引所」サブシステムの終了。
手順の終了

ExchangeCounterparty モジュールの変更点

手順の追加 作成時OnServer_ListForm、ドキュメントリストフォームの "When CreatedOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 OnServer_ListForm を作成するときのパラメータ.
手順の追加 CreatedOnServer_FormDocument 時、ドキュメントフォームの "When CreatedOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 OnServer_DocumentForm を作成するときのパラメータ.
手順の追加 サーバー上の録画後、ドキュメントフォームの "AfterRecordOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 パラメータAfterRecordingOnServer.

モジュールの変更点 取引先とのやり取りクライアント.

手順の追加 開くとき、ドキュメントリストフォームおよびドキュメントフォームの「開く時」イベントハンドラーから呼び出されます。
手順の追加 アラート_リストフォームの処理、ドキュメントリストフォームの「通知処理」イベントハンドラーから呼び出されます。メソッドの 4 番目のパラメーターとして、メソッドによって初期化される構造体が渡されます。 アラートパラメータEDO_ListForm.
手順の追加 アラート_フォームドキュメントの処理中、ドキュメントフォームの「通知処理」イベントハンドラーから呼び出されます。メソッドの 4 番目のパラメーターとして、メソッドによって初期化される構造体が渡されます。 通知パラメータEDO_DocumentForm.
モジュールの変更点 取引相手との交換オーバーライド可能:
追加されたメソッド 作業実行者のデータ転送を入力します.
例：

// 販売者への商品の譲渡タイプの電子ドキュメントのデータを準備します。
// オプション:
// LinkToObject - 電子ドキュメントを生成するために必要な ED へのリンク、

手順の入力データ転送作業実行者 (オブジェクトリンク、ED 構造、データツリー) エクスポート
連邦税務局法 501 執行者のデータを入力します (オブジェクト、ED 構造、データツリーへのリンク)
手順の終了

方法 オブジェクトの編集機能の確認という手順になりました。
追加されたメソッド UPD のデータを入力します。販売者の連邦税務局の情報。このメソッドは、次のタイプの電子ドキュメントのデータを準備します。更新（販売者情報）機能 シュフドップ.
追加されたメソッド 検索ユニバーサル転送ドキュメントの作成。このメソッドは電子ドキュメントからデータを保存します更新（販売者情報）機能 SCHFDOPv ISオブジェクト。
追加されたメソッド UKDI 販売者情報のデータを入力する連邦税務局。このメソッドは、次のタイプの電子ドキュメントのデータを準備します。 英国ドル（販売者情報）機能 KSCHFDIS.
追加されたメソッド 検索ユニバーサル調整ドキュメントの作成。このメソッドは電子ドキュメントからデータを保存します 英国ドル（販売者情報）機能 KSCHFDIS情報セキュリティオブジェクトに。

「銀行との取引」サブシステムの変更点

ExchangeWithBanksRedefinable モジュールの変更点

手順 EDの状態が変化したとき追加した。電子ドキュメントのフロー状態が変化したときに呼び出されます。

サービスモードで動作するための変更

サービスモードで動作するための宛先設定が必要な場合:

共通モジュール SuppliedDataOverridden のプロシージャ GetProvidedDataHandlers に、次のコードを追加します。

ElectronicInteraction.RegisterDeliveredDataHandlers(ハンドラー);

ルーチンタスク「銀行との外部モジュール交換の更新」を一般属性データ領域基本データに追加します。

その他の変更点

定義されている型に定数を追加する必要があります ExchangeWithBanksを使用する;
削除された機能 銀行との両替銀行との直接両替を推奨.

バージョン1.3.3

バージョン 1.3.3 は、製品「1C: 電子ドキュメントのライブラリ」のエディション 1.3 を発展させたものです。 1C:Enterprise プラットフォーム 8.3 バージョン 8.3.6 以降で動作するように設計された構成を開発するために設計されています。

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

2015 年 11 月 30 日付け命令 No. ММВ-7-10/551@「貿易取引中の商品の移転に関する電子形式での文書提出フォーマットの承認について」および 2015 年 11 月 30 日付け命令 No. ММВ-7-10/552@ 「業務成果の引継ぎに関する文書（サービスの提供に関する文書）の電子形式での提出フォーマットの承認について」新しい形式の電子文書がサポートされます。

サブシステム「取引先との取引」の変更点

モジュール内 取引相手との交換オーバーライド可能変える：

// 送り状タイプの電子文書のデータを準備します。
// オプション:
// LinkOnED - 電子ドキュメントを生成するために必要な ED へのリンク、
// StructureED - 構造、電子ドキュメントを生成するためのデータ構造。
// データツリー - 値のツリー、電子ドキュメントに記入するためのデータのツリー。
手順入力商品販売者のデータ転送（オブジェクトリンク、ED構造、データツリー）エクスポート
連邦税務局の交渉 12 販売者に関するデータを入力します (オブジェクト、ED 構造、データツリーへのリンク)
手順の終了

BED を使用する構成に、電子ドキュメントを操作するときに組織 (RLS) ごとにレコードレベルでアクセスを制限するためのテンプレートを追加する必要があります (埋め込みドキュメントを参照)。

バージョン1.3.2

バージョン 1.3.2 は、製品「1C: 電子ドキュメントのライブラリ」のエディション 1.3 を発展させたものです。 1C:Enterprise プラットフォーム 8.3 バージョン 8.3.6 以降で動作するように設計された構成を開発するために設計されています。

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

電子文書閲覧用の1つのフォームに2つの電子文書（TORG12、法律、調整文書）のタイトルを表示できるようになりました。タイトルからのすべての情報は 1 つのフォームに収集されます。別途、2番目のタイトルのフォームは「電子文書」フォームから閲覧できます。
1C プログラムの「EDF 設定」から電子形式で標準の「EDA 契約」を締結する機能が実装されました。「テンプレートを使用して契約書を作成」コマンドを使用すると、任意の電子文書が自動作成され、その添付ファイルが契約書ファイルとなります。署名後、文書はすぐに相手方に送信できます。
任意の電子文書と添付ファイルを統合的に交換します。電子文書を使用して、添付ファイルにすぐに署名して取引相手に送信できるようになりました。
給与プロジェクトに関して銀行と電子文書を交換する機能がサポートされています。
組織を DirectBank に接続するためのアシスタントを追加しました。
DirectBank をサポートする銀行のリストはインターネット経由で更新されました。
Sberbank のさまざまなタイプのトークン (電子キー) での動作をサポートしました:「通常」、「タッチ」、「画面付き」。
「標準サブシステムライブラリ」(BSS) のサブシステムがバージョン 2.3.2.27 に更新されました。

バージョン 1.2.7、1.3.1 からバージョン 1.3.2.19 への移行

パディングなしでプロシージャをモジュールに追加する必要があります。

プロシージャ CheckUsingTestMode。銀行との交換をテストするための追加機能を有効にする機能が含まれています。応用ソリューションで使用する計画はまだありません。

モジュール内 通常のタスクオーバーライド可能変える：

定型業務（設定）エクスポートの設定を決める手順
電子インタラクション。ルーチンタスクの設定を定義するとき(設定);
手順の終了

モジュール内 電子署名クライアントオーバーライド可能変える：

追加証明書検証（パラメータ）エクスポート手順
ExchangeWithBanksClient.AtAdditionalCertificateVerification(パラメーター);
手順の終了

モジュールへ 電子署名オーバーライド可能変える：

フォーム作成時の手順証明書のチェック（証明書、追加チェック、追加チェックのパラメータ、標準チェック）エクスポート
ExchangeWithBanks.WhenCreatingFormVerificationCertificate(
証明書、追加チェック、追加チェックパラメータ、標準チェック);
手順の終了

次の非共有オブジェクトが追加されました。

;

絶え間ない 銀行との一般的なファイル交換.

定義済みタイプへ 収納スペース機能オプション定数を追加する ExchangeWithBanksを使用する.

構成がサービスモデルモードで動作することを目的としている場合は、サブスクリプションハンドラーをイベント Control of Unshared Objects While Writing the BED に変更して、WorkIn the Service Model.Control of Unshared Objects While Writing に変更する必要があります。

バージョン1.3.1

バージョン 1.3.1 は、製品「1C: 電子ドキュメントのライブラリ」のエディション 1.2 を発展させたものです。 1C:Enterprise プラットフォーム 8.3 バージョン 8.3.6 以降で動作するように設計された構成を開発するために設計されています。

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

EDI サービスを通じて電子署名なしで電子ドキュメントを交換する機能が 1C: Business Network 参加者向けに実装されました。
銀行との自律的な交換サブシステムが実装されています。
「標準サブシステムライブラリ」(BSS) のサブシステムがバージョン 2.3.1.71 に更新されました。

バージョン 1.2.6、1.2.7 からバージョン 1.3.1 への移行

アーキテクチャの変更

接頭辞「電子ドキュメント」を持つすべてのモジュールは、接頭辞「電子ドキュメント」を持つモジュールに名前変更されました。 「取引先とのやりとり」。モジュールメソッド 汎用ED新しいモジュールに移動しました 電子インタラクション。モジュール ED 情報ベースの更新に名前変更されました データベースの更新.

電子文書 V 電子インタラクション:

姓イニシャル個人

モジュールから移動されたメソッドのリスト 電子文書 V 銀行との交換:

銀行との直接両替が可能
GetDataBankStatementsTreeValues
GetDataBankStatementsTextFormat
解析ツリー抽出バンク

モジュールから移動されたメソッドのリスト ElectronicInteractionClientOverridable:

書類チェックの実行

モジュールから移動されたメソッドのリスト 電子ドキュメントクライアントオーバーライド可能 V ExchangeWithBanksClientOverridable:

ParseFileExtracts

モジュールから移動されたメソッドのリスト 電子インタラクションクライアントサーバー:

GetMessageText (MessageText に名前変更)
はいアクション

モジュールから移動されたメソッドのリスト 電子ドキュメントクライアントサーバー V ExchangeWithBanksクライアントサーバー:

Filled inDetailsSettings EDSBanks (Filled out FilledDetailsSettingsExchange に名前変更されました)
HeaderSettingsEDOSBank は HeaderSettingsExchangeWithBank に名前変更されました
GetStatusTextED

モジュールから移動されたメソッドのリスト 電子インタラクションオーバーライド可能:

ChangeFormElementProperties
現在のディレクトリ一時ファイル
一致する機能オプションを取得する
一致するディレクトリを取得する
オブジェクトMDの名前と詳細の対応を取得する
詳細コードと表現コードの対応
オブジェクトの主要な詳細の構造を取得する
テキストメッセージ必要なシステム設定
エラーメッセージの編集
アクセス権違反に関するメッセージテキストを準備する
逆アセンブル名個人
FindReferenceToObject
印刷文書番号の取得
CheckReadinessソース
GetData 法的個人
説明組織
ED を処理する権利があります
EDを読む権利あり
ジャーナル登録を開始する権利があります

モジュールから移動されたメソッドのリスト 電子文書オーバーライド可能 V ExchangeWithBanksOverridable:

現在の種類の ED を取得する
銀行口座番号を取得する
ED パラメータをソースごとに入力します
支払い注文データを入力します
支払いリクエストデータを入力します
オブジェクトの編集機能の確認

イベントのサブスクリプションから 所有者を記録するときに ED の新しいバージョンを割り当てるそして CheckChangeBeforeRecordingOwnerED銀行の書類は削除されました。

処理から移動されたレイアウト 交換取引相手 V 銀行との交換:

支払い命令
支払い要件

定義されたタイプに追加する必要があります

documentObject.PackageED

インターフェースの変更

共通モジュール内 銀行との交換, 交換取引相手手順が追加されました サーバー上で作成されたとき。 EDI コマンドを生成するためにオブジェクトフォームを開いたときに呼び出されます。オプション: 形状– 現在の形式、 チーム配置デフォルト– EDI コマンドが作成されるサブメニューフォームの要素。
共通モジュール内 ExchangeWithBanksOverridable, 取引相手との交換オーバーライド可能 EDM コマンドのリストを生成するための手順を追加しました。 Teams EDF のオブジェクトの構造を準備する。パラメータ TeamsEDOの構成配列にすることもできます (サブシステムの場合) 銀行との交換) または配列構造 ( 交換取引相手).
EDI コマンドのグループは削除され、コマンドパネルへの EDI コマンドの自動入力は実行されなくなりました。

Infobase ドキュメントフォームで EDM コマンドを作成するには、オーバーライドされた共通モジュールのプロシージャにオブジェクトタイプを生成するコードを追加する必要があります。

モジュール内の例 取引相手との交換オーバーライド可能:

EDM の構成 Teams.Outcoming.Add("Document.Sales of Goods and Services");
EDO Commands.Outcoming.Add("Document.Buyer's Order"); の構成
…
EDF の構成 Teams.Incoming.Add("Document.Receip of Goods and Services");
EDO Commands.Incoming.Add("Document.InvoiceReceived"); の構成
…
手順の終了

ExchangeWithBanksOverridable:

手順 EDFチームのオブジェクト構造の準備（EDFチームの構成）エクスポート
EDO Commands.Add("Document.Payment Order"); の構成
EDO Commands.Add("Document.PaymentRequest"); の構成
…
手順の終了

フォームを作成するときに、コマンドのプログラム生成を呼び出します。

取引相手との交換サーバー上で作成される場合:

CreatedOnServer時の手順(失敗、標準処理)
//EDOコマンド
Counterparty との交換。When CreatedOnServer(ThisObject, Elements.EDO Commands);
// EDOコマンドの終了
手順の終了

プラグ可能なフォームハンドラーを追加する 接続可能_EDOコマンドの実行:

プロシージャ Connectable_EDO コマンドの実行 (コマンド)
ElectronicInteractionServiceClient.ExecuteConnectedCommandEDO(Command, ThisForm, Elements.List);
手順の終了

サブシステム「取引先との取引」の変更点

定義されたタイプ「任意の ED の根拠」に、エントリの入力に基づいて文書のタイプを入力します。 任意のED(ほとんどの場合、これらは定義済みタイプの添付ファイル所有者と同じドキュメントになります)。また、これらのドキュメントでは、ドキュメント「カスタム ED」を「基礎となるもの:」リストに追加する必要があります。
ドキュメントフォームおよびドキュメントのリスト (カスタム ED の入力に基づいて) では、[作成に基づいて作成] サブメニューでカスタム ED を無効にする必要があります。カスタム ED を入力するためのコマンドは EDO サブメニューに配置されます (コマンド「ファイルの追加」)。
権利譲渡法のレイアウト、商品の注文、注文への応答、販売に関する手数料代理人のレポート、商品説明に関する手数料代理人のレポート、支払い請求書、製品カタログ、パラメータのグループ内の価格表「BIC」フィールドの「銀行」の必須入力属性が変更されました。このフィールドは必ず入力する必要があります。
InvoiceInvoice レイアウトでは、原産国コードと税関申告番号フィールドの形式が変更されました。より正確に記入するために、それらは税関申告表に結合されます。 ESF データを準備する手順でこれらの要素を記入する例は、BED のデモデータベースにあります。

ExchangewithCounterpartiesClient モジュールの変更点

OpenEDList メソッドは非推奨になりました。代わりに、情報セキュリティ文書の電子文書を交換するための規制ツリーをユーザーに提供する OpenEDTree を使用することをお勧めします。

電子インタラクションモジュールの変更がオーバーライドされました

再定義のために、オブジェクトの名前と詳細への対応を取得に 2 つのキーが追加されました。

メタデータにおける商品およびサービスの販売
メタデータでの商品およびサービスの受領

ExchangeCounterparty モジュールの変更点

1C-Reporting Master のデータを準備する Fill DataBy 1SEDOD メソッドを 1C-Reporting Master に追加しました。

アカウントフォームの作成時に呼び出す必要があるメソッド Check AccounterV1EDMSWhen CreatedOnServer を追加しました。このメソッドは、カウンターパーティの 1C-EDO サービスへの接続のチェックを実行します。
例 取引相手とのやり取りサーバー上に作成された1 SEDOで取引相手を確認:

CreatedOnServer時の手順(失敗、標準処理)
// 電子的なやり取り。取引相手とのやり取り
カウンターパーティとの交換。CreatedOnServer(Object.Link) のときに 1SEDO でカウンターパーティを確認します。
// 電子的なやり取りを終了し、取引相手とのやり取りを終了します。
手順の終了

NOT 分割ルーチンタスクを追加しました 取引相手のチェックBED、カウンターパーティを選択し、1C-EDO への接続をチェックします。

分割情報レジスタを追加 取引相手の状況BED、1C-EDO サービスに接続されている請負業者に関する統計を収集します。

一覧フォームおよび取引先選択フォームの「EDO」欄に、1C-EDOサービスへの接続サインの表示を追加します。「1C-EDOサービスに接続しました」列にヒントを追加します。
例：

選ぶ
選択
WHENCounterparty StatusBED.Status = VALUE(Enumeration.CounterpartyStateBED.Connected)
その後 0
その他 1
終わり
江戸のように終わる
ディレクトリ取引先.名前、
DirectoryCounterparty.INN、
ディレクトリカウンターパーティ.KPP、
....
DirectoryCounterparty.NameFull
から
Directory.Counterparty AS DirectoryCounterparty
LEFT CONNECTION 情報の登録請負業者のステータス BED AS 請負業者のステータス BED
ソフトウェア (契約業者の州BED.Counterparty = DirectoryCounterparty.Link)

情報ベースの文書フォームでは、「ED 状態テキスト」フォーム属性から「ED 交換の使用」機能オプションへのリンクを削除する必要があります。「ED ステータス」属性からヘッダーを削除します。

「銀行との取引」サブシステムの変更点

イベントのサブスクリプションを追加しました 銀行との交換所有者ED録音前そして 銀行所有者との交換EDOn録音.

定義済みタイプ OwnersExchangeWithBanks および DirectoryBanks を追加しました。
一般コマンドSettingsExchangeWithBanksを追加しました。

定義済みタイプへ 添付ファイル追加：

directoryLink.MessageExchangeWithBanksAttachedFiles;
directoryObject.MessageExchangeWithBanksAttachedFiles;
directoryLink.PackageExchangeWithBanksAttachedFiles;
directoryObject.PackageExchangeWithBanksAttachedFiles。

定義済みタイプへ 添付ファイルの所有者追加する必要があります

documentLink.MessageExchangeWithBanks;
documentLink.PackageExchangeWithBanks。

定義済みタイプへ 所有者添付ファイルオブジェクト追加する必要があります

documentObject.MessageExchangeWithBanks;
documentObject.PackageExchangeWithBanks;
documentObject.PackageED

新しいサブシステム「ビジネスネットワーク」を追加

サブシステムには共通モジュール (接頭辞) が含まれています。 交換ビジネスネットワーク）、処理 ビジネスネットワーク、役割 ( 管理加入者ビジネスネットワーク, Exchangeビジネスネットワークの実行）、情報登録 識別子ビジネスネットワーク。「電子文書の交換の設定」フォームに、サービス接続フォームを呼び出すコマンドが追加されました。

モジュール内の手順と機能を完了する必要があります ビジネスネットワークオーバーライド可能:

方法 詳細に従って取引相手を作成する。渡されたパラメータを使用してアプリケーションソリューションにカウンターパーティを作成します。
方法 IB ユーザー連絡先の取得。ユーザーの連絡先情報 (ロール名、電子メールアドレス) を受け取ります。
方法 文書詳細管理の実行。ドキュメントの詳細をチェックして、配列の送信を許可します (送信者と受信者が同じである必要があります)。

バージョン 1.3.6 からバージョン 1.3.7 への移行

支払書類をファイルにアップロードし、ファイルから銀行取引明細書をダウンロードするためのフォーム (処理 クライアントバンク) 要素のグループを移動する グループ広告ダイレクトバンク水平方向一般的な形から OfferConnect1SDirectBank.

フォームイベントハンドラー内 サーバー上で作成されたとき ExchangeWithBanksClientServer.ShowAdvertisingDirectBank メソッドを配置します。

サーバー上(&O)
CreateOnServer時の手順（失敗、標準処理）
…
// 電子的なやり取り、銀行との交換
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(
Elements.GroupAdvertisingDirectBank水平方向、Elements.TextDirectBank水平方向);
// 電子的なやりとりを終了し、銀行と交換する
手順の終了

フォームイベントハンドラー内 アラートの処理中 ExchangeWithBanksClient.UpdateAdvertisingDirectBank メソッドを配置します。

&OnClient
プロシージャプロセス通知(イベント名、パラメータ、ソース)
…
// 電子的なやり取り、銀行との交換
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(イベント名,
Elements.GroupAdvertisingDirectBank水平方向、Elements.TextDirectBank水平方向);
// 電子的なやりとりを終了し、銀行と交換する
手順の終了

要素の場合 TextDirectBank水平方向イベントハンドラを追加する 処理ナビゲーションリンクそして、その中に ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank メソッドを配置します。

&OnClient
プロシージャ TextDirectBankhorizontalNavigationLinkProcessing(Element, FormattedStringNavigationLink, StandardProcessing)
ExchangeWithBanksClient.ProcessingNavigationLinkAdvertisingDirectBank(
NavigationLinkFormatString、StandardProcessing);
手順の終了

手続きへ MDI オブジェクトの名前と詳細への対応を取得する共通モジュール 電子インタラクションキーを持つ一致要素を追加 PaymentOrderInメタデータおよび値: メタデータオブジェクトの名前 支払い命令アプリケーションソリューションで。

09.06.2017

標準構成「1C: 電子文書ライブラリ 1.3」の新バージョン 1.3.8 をリリースしました。

バージョン1.3.8

新機能と変更点

取引案件の検索フォームに、1C:ビジネスネットワークサービスに接続せずに検索できる機能が追加され、サプライヤー名で検索できる機能が追加されました。
公開された取引オファーに関するレポートを追加しました。
1C:Business Network サービスに取引オファーを公開するためのワークスペースが追加されました。
サブシステム「1C: Library of Standard Subsystems」バージョン 2.4.2、「1C: Library of Internet User Support」バージョン 2.2.2 で適応が行われました。

バージョン 1.3.7 からバージョン 1.3.8 への移行

モジュールの変更:

追加機能 公開製品のリクエストテキストトレードオファーを公開し、公開された商品に関するレポートを生成するためのデータソースを取得します。商品一覧を取得する際には、FillOfferPackageメソッドへの関数呼び出しを実装する必要があります。

モジュールの変更点 トレードオファー

手順の追加 更新装飾条件出版物装飾フォーム要素を公開状態で更新します。ステータス要素の公開設定をフォームの呼び出しに追加する必要があります。

役割が追加されました レポート取引オファーレポートにアクセスするために必要です 公開されたトレードオファー.

バージョン1.3.7

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

Sberbank から支払い文書のステータスを取得する機能が追加されました。
1C:DirectBank サービスに接続するときの Sberbank の設定の自動受信を実装しました。
コンテキスト広告 1C:DirectBank を表示する機能を追加しました。
1CFresh クラウドサービスの 1C: Business Network サービスと連携するように調整されています。
1C: Business Network サービスの参加者向けに、1C: Trade Offers サービスでトレードオファーを公開、検索、注文する機能が追加されました。
適応は、サブシステム「1C: Library of Standard Subsystems」バージョン 2.4.1、「1C: Library of Internet User Support」バージョン 2.1.9、「1C: Library of Service Technology」バージョン 1.0.12 で実行されました。

バージョン 1.3.6 からバージョン 1.3.7 への移行

サブシステム「取引先とのやりとり」

モジュールの変更:

文書の日付, DocBaseDate

サブシステム「銀行との取引所」

モジュールの変更点 ファイルの操作オーバーライド可能:

手続きへ 設定を定義するときコードを追加する必要があります:

ElectronicInteraction.WhenDefiningSettings(設定);

手続きへ ファイル格納ディレクトリを定義する場合コードを追加する必要があります:

電子インタラクション。FileStorage ディレクトリを定義するとき(FileOwnerType, DirectoryNames);

ディレクトリ MessageExchangeWithBanksAttachedFiles および EDAttachedFiles が交換計画 UpdateInformationBase に追加されました。
ディレクトリ MessageExchangeWithBanksAttachedFiles および EDAttachedFiles が、定義されたタイプ SignedObject に追加されました。

フォームイベントハンドラー内 サーバー上で作成されたとき ExchangeWithBanksClientServer.ShowAdvertisingDirectBank メソッドを配置します。

サーバー上(&O)
CreateOnServer時の手順（失敗、標準処理）
…
ExchangeWithBanksClientServer.ShowAdvertisingDirectBank(

手順の終了

フォームイベントハンドラー内 アラートの処理中 ExchangeWithBanksClient.UpdateAdvertisingDirectBank メソッドを配置します。

&OnClient

…
// 電子的なやり取り、銀行との交換
ExchangeWithBanksClient.UpdateAdvertisingDirectBank(イベント名,
Elements.GroupAdvertisingDirectBank水平方向、Elements.TextDirectBank水平方向);
// 電子的なやりとりを終了し、銀行と交換する
手順の終了

サブシステム「拠点との交換」

モジュールの変更点 Site Exchangeオーバーライド可能:

手順の追加 詳細フォームノードを追加、サイトとの Exchange から交換計画ノードに詳細を追加するために使用されます。交換ノードフォームは、アプリケーションソリューションに関連する詳細の存在を前提としていません。詳細はプログラムによって追加されます。
手順の追加 入力フィールドWhenChangedOnServerは、交換計画ノードフォームの入力フィールドが変更されたときのイベントを北で処理するために使用され、Add NodeFormDetails プロシージャに追加されます。
手順の追加 サーバー上で変更されたときのチェックボックスフィールドは、NodeFormDetails の追加手順で追加された交換計画ノードフォームのフラグフィールドが変更されたときに、サーバー上でイベントを処理するために使用されます。
手順の追加 作成時サーバーフォーム作成サイト、CreateSite 処理フォームに詳細を追加するために使用されます。

モジュールの変更点 ExchangeSiteClientOverridable:

削除されたプロシージャ GroupTableU カタログタイプの定義、製品カタログ表の「グループ」列の値のタイプは、交換設定によって決まります。
手順の追加 入力フィールドオン変更、交換計画ノードフォームの入力フィールドが変更されたときにイベントを処理するために呼び出され、SiteExchangeOverridden.AddNodeFormDetails プロシージャに追加されます。
手順の追加 チェックボックスフィールドオンチェンジは、SiteExchangeOverridden.AddNodeFormDetails プロシージャで追加された交換計画ノードフォームのフラグフィールドが変更されたときに、イベントを処理するために呼び出されます。
手順の追加 テーブルフォーム終了編集前は、SiteExchangeOverridden.AddNodeFormDetails プロシージャで追加された交換計画ノードのフォームの表形式部分にあるフィールドの BeforeFinishEdit イベントを処理するために呼び出されます。

サブシステム「ビジネスネットワーク」

分割モードでルーチンタスクを実行するための新しいメソッド、共通モジュールを追加しました 電子インタラクション、手続き テンプレートのリストを受け取ったら、。一般モジュール JobQueueOverridable の同じ名前のメソッドを参照してください。
ライブラリを埋め込む場合、分割モードで動作するには、一般モジュールのメソッドへの呼び出しを追加する必要があります。 JobQueueOverridable:
- 手続きの中で テンプレートのリストを受け取ったら:

// 電子的相互作用
ElectronicInteraction.OnReceivingListTemplates(TaskTemplates);

手続きの中で AliasesHandler を定義する場合:

// 電子的相互作用
ElectronicInteraction.WhenDefiningHandlerAliases(MatchNamesAliases);
// 電子的なやり取りを終了する

モジュールの変更点 ビジネスネットワークオーバーライド可能:
- プロシージャの名前が変更されました IB ユーザー連絡先の取得 V ユーザーの連絡先情報を取得する.
- プロシージャが関数に変更されました 詳細に従って取引相手を作成するでは、Account パラメーターが削除されました。

サブシステム「トレードオファー」

新しいサブシステム「Trade Offers」が追加されました。埋め込みには以下が必要です。

共通モジュールでオーバーライドされたメソッドを開発する TradeOffersClientOverridable, TradeOffersオーバーライド可能.
定義された型でデータ型を指定する 詳細の値の種類 1СBusinessNetwork, BED の命名法の種類, 追加詳細ベッド, トレードオファー.

詳細については、埋め込みドキュメントを参照してください。

バージョン1.3.6

新機能と変更点

主要な請求書文書の形式は、2016 年 3 月 24 日付けの連邦税務局命令 No. ММВ-7-15/155@ に従ってサポートされます (別の主要文書である請求書の転送に関して)。電子形式での請求書を含む、商品の発送（業務の履行）、財産権の譲渡（サービスの提供に関する文書）に関する請求書フォーマットおよび文書提示フォーマット。」
2016 年 4 月 13 日付けの連邦税務局の命令に従って、調整請求書を含む、価値の変更に関する主要文書の形式がサポートされています (別の主要文書である調整請求書の転送に関して)。 -7-15/189@ " 調整請求書のフォーマットと、出荷された商品のコスト（実行された作業、提供されたサービス）の変更に関する文書を提出するためのフォーマットの承認に基づいて、調整請求書を含む所有権が譲渡されました。電子フォーム。」
新しい電子文書が追加されました。商品の譲渡、作業結果の譲渡、文書の視覚的表示の新しい形式です。
受信者からの受信通知を必要としない一方向の交換メカニズムが追加されました。
受信した電子ドキュメントの解凍 (自動または手動) を制御する機能、電子ドキュメントの受信時に特定の種類のドキュメントの作成を構成する機能が追加されました。
電子ドキュメントを複数の情報ベースの会計ドキュメントにリンクする機能が追加されました。
電子文書を受信用と送信用に分割することが実装されました。
サービスとの統合が実装されました 1C-UMIプログラムからウェブサイトを作成したり、オンラインストアとの交換を設定したりすることができます海.
1CFresh クラウドサービスの 1C-EDO サービスと連携するように調整されました。

バージョン 1.3.5 からバージョン 1.3.6 への移行

サブシステム「取引先とのやりとり」

一般モジュールExchangewithCounters再定義可能

UPD SCHFDOP メソッドを追加しました。
追加されたメソッド UPD 購入者情報のデータを入力する連邦税務局。このメソッドは、タイプ UPD (購入者情報) 関数 SCHFDOP の電子ドキュメントのデータを準備します。
情報セキュリティオブジェクトにUPDメソッド(販売者情報)関数SCHFDOPを追加しました。
追加されたメソッド 販売者の連邦税務局の追加情報のデータを入力します。。 STD（販売者情報）DOP機能などの電子文書用のデータを作成する方法です。
追加されたメソッド 検索UPDT ドキュメントの作成転送について。このメソッドは、電子文書 UPD (販売者情報) 関数 DOP からのデータを IS オブジェクトに保存します。
追加されたメソッド SCHFIS販売者情報のデータを入力します連邦税務局。このメソッドは、タイプ UTD (販売者情報) SSF 関数の電子ドキュメントのデータを準備します。
追加されたメソッド 検索作成UPDS請求書請求書。このメソッドは、電子文書 UPD (販売者情報) SSF 機能からのデータを情報セキュリティオブジェクトに保存します。
メソッドを追加しました。このメソッドは、UCD タイプ (販売者情報) 関数 KSCHFDIS の電子ドキュメントのデータを準備します。
追加されたメソッド UKID 購入者情報のデータを入力する連邦税務局。このメソッドは、タイプ UKD (購入者情報) 関数 KSCHFDIS の電子文書のデータを準備します。
メソッドを追加しました。このメソッドは、電子文書 UCD (販売者情報) 関数 KSCHFDIS からのデータを情報セキュリティオブジェクトに保存します。
追加されたメソッド 販売者の連邦税務局の DIS 情報のデータを入力します。。 UCD型（販売者情報）DIS機能の電子文書データを作成する方法です。
追加されたメソッド FindCreateUKDDocumentAboutChangeValue。このメソッドは、電子文書 UCD (販売者情報) 関数 DIS からのデータを IS オブジェクトに保存します。
追加されたメソッド KSCHFIS販売者の情報のデータを入力します連邦税務局。このメソッドは、UCD タイプ (販売者情報) 関数 KSCHF の電子文書のデータを準備します。
追加されたメソッド 検索英国DSアカウント請求書の作成。このメソッドは、電子文書 UCD (販売者情報) 関数 KSCHF からのデータを情報セキュリティオブジェクトに保存します。
追加されたメソッド 送信タイプの ED と情報セキュリティ文書の遵守。この方法は、送信される電子文書と情報セキュリティ文書との間の対応関係を形成します。
追加されたメソッド 検索作成文書転送作業結果。この方法は、「物品の転送」形式で受け取った送り状文書に記入するために使用されます。
追加されたメソッド 検索文書作成商品の譲渡。この方法は、「作業結果の転送」形式で受け取ったサービス提供証明書の文書に記入するために使用されます。
追加されたメソッド インストール済み状態交換完了。このメソッドは、ドキュメントフローの状態が次のように変化すると呼び出されます。 交換完了, 交換完了（修正あり）.
電子文書作成時 UPD、UKD、物品の譲渡、作業結果の譲渡、詳細 文書の日付, DocBaseDateを記入する必要があります。

取引先とのやり取りの処理

「Torg-12Seller」レイアウトの場合:

「IdStateContract」フィールドを追加しました。
表形式パーツ「輸送請求書」が追加されました。
「Transport InvoiceDate」および「Transport InvoiceNumber」フィールドは削除されました。
「物品の譲渡者に関する情報」の項目を追加しました。

レイアウトでは 権利譲渡法:

表形式パーツ「ベース」を追加しました。
「DocumentBaseName」、「DocumentBaseNumber」、「DocumentBaseDate」、「DocumentBaseAdditionalInformation」フィールドが削除されました。
「通貨名」フィールドを追加しました。
「クレーム」フィールドを追加しました。
「実行日」フィールドを追加しました。
トランザクション参加者のプロパティで、「FAX」フィールドが「電子メール」フィールドに置き換えられました。
トランザクション参加者のプロパティで、「国コード」フィールドが「国コード」フィールドに置き換えられました。
トランザクション参加者のプロパティで、「AddressText」フィールドが「AddressText」フィールドに置き換えられました。

定義されたタイプの更新 取引相手:

アップデート手順：

定義されたタイプの Account の名前を AccountBED に変更します。
BED 1.3.5 のサポートから構成を削除します。
BED 1.3.5 構成との比較/マージを実行し、構成をサポートするように設定することに同意します。
すべてのオブジェクトのチェックを外し、定義されたアカウントタイプのみを残し、マージを実行します。
構成の更新を開始し、BED ファイル 1.3.6 を選択します。
定義済みタイプ AccountBED および Account のチェックボックスを選択します。更新に必要なその他のデータベースオブジェクトを指定します。
アップデートを実行します。

サブシステム 「銀行との両替」

サブシステム「拠点との交換」

Exchangeノードが変更されました サイトエクスチェンジ、フォーム、オブジェクトモジュール:

アイテムタイプごとに選択してアイテムをアップロードする機能が追加されました (以前はアイテムグループによってのみ利用可能でした)。

参考書を追加しました ウェブサイト:

1C からサイトのユーザー部分、およびサイトの管理領域への移行を構成する機能が追加されました。
サイトに基づいて、ExchangeSite 交換ノードを作成できます。

追加処理 ウェブサイトを作成する:

1C-UMI ドメインにサイトを作成する機能が追加されました。サイトは自動的に作成され (Sites 要素)、1C からのデータが入力されます。 ExchangeSite 交換ノードが自動的に作成され、サイトとの最初の完全な交換が実行されます。

一般モジュール Site Exchangeオーバーライド可能:

項目の種類を選択する機能が追加され、任意の参考書を選択する機能が削除されました。

一般モジュール Exchangeサイトイベント:

アイテムの種類を選択する機能が追加されました。
カスタムディレクトリを選択する機能は削除されました。

その他の変更点

サブシステムのセットアップ 料金管理図書館サービスモデルにおいて サービス技術

// 電子的相互作用
電子的やりとり。サービス（サービスプロバイダー）のリストを作成する場合。
// 電子的なやり取りを終了する

バージョン1.3.5

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

ライブラリ機能は、互換モードが無効になっている 8.3.8 プラットフォームで動作する特定の機能に適合しました。
「標準サブシステムライブラリ」のサブシステムがバージョン 2.3.3.45 に更新されました。
このライブラリには、サブシステム「Internet User Support Libraries」バージョン 2.1.8.3 が含まれています。

バージョン 1.3.4 からバージョン 1.3.5 への移行

変更は必要ありません。

バージョン1.3.4

新機能と変更点

EDI イベントに関する通知システムが実装されました (新しい電子ドキュメント、新しい招待状、証明書の有効期限など)。 EDF 設定プロファイルで電子メール通知を構成できるようになったほか、ポップアップメッセージを使用して 1C プログラムでイベントに関する通知を直接表示できるようになりました。
2016 年 3 月 24 日付連邦税務局命令 No. ММВ-7-15/155@ に基づく請求書 (UPD 形式) を含む主要文書の形式がサポートされています。請求書を含む、商品の発送（業務の遂行）、所有権の譲渡（サービスの提供に関する文書）に関する文書を電子形式で提出するためのフォーマット。
2016 年 4 月 13 日付けの連邦税務局の命令に従って、調整請求書を含む金額の変更に関する文書の形式がサポートされました。N ММВ-7-15/189@ 「調整請求書の形式と、出荷された商品（実行された作業、提供されたサービス）のコストの変更に関する電子形式での調整請求書を含む所有権の譲渡に関する表示形式文書の承認に基づいて」。
DirectBank テクノロジーを使用した銀行との交換における外部コンポーネントの使用をサポートしました。

バージョン 1.3.2、1.3.3 からバージョン 1.3.4 への移行

アプリケーションソリューションドキュメントリストフォームの変更

ドキュメントリストフォームでは、プラグインプロシージャを追加する必要があります CounterpartyClient.Waiting ProcessorEDW との交換:

&OnClient

手順の終了

&OnClient
開封手順（失敗）
…
// サブシステム「取引相手との交換」。
// 「取引先取引所」サブシステムの終了。
手順の終了

アプリケーションソリューションのドキュメント形式の変更

CounterpartiesClient.Waiting ProcessorEDW との交換:

&OnClient
プロシージャ Connectable_EDOWaitingHandler()
ExchangeCounterpartiesClient.EDOWaitingHandler(ThisObject);
手順の終了

例えば：

サーバー上(&O)
CreatedOnServer時の手順(失敗、標準処理)
…
// サブシステム「取引相手との交換」。
作成時の EDO パラメータ = 取引相手との交換 Server_DocumentForm() で作成時のパラメータ
作成時の EDO パラメータ。Form = ThisObject;
作成時の EDO パラメータ.DocumentLink = Object.Link;
作成時の EDO パラメータ。DecorationStateEDO = Elements.DecorationStateEDO;
作成時の EDO パラメータ。EDO 状態グループ = Elements.EDO 状態グループ;
取引相手との交換。作成時サーバー_ドキュメントフォーム(拒否、標準処理、EDO パラメータ作成時);
// 「取引先取引所」サブシステムの終了。
手順の終了

ExchangeCounterparty モジュールの変更点

手順の追加 作成時OnServer_ListForm、ドキュメントリストフォームの "When CreatedOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 OnServer_ListForm を作成するときのパラメータ.
手順の追加 CreatedOnServer_FormDocument 時、ドキュメントフォームの "When CreatedOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 OnServer_DocumentForm を作成するときのパラメータ.
手順の追加 サーバー上の録画後、ドキュメントフォームの "AfterRecordOnServer" イベントハンドラーから呼び出されます。メソッドの 3 番目のパラメータとして、メソッドによって初期化される構造体が渡されます。 パラメータAfterRecordingOnServer.

モジュールの変更点 取引先とのやり取りクライアント.

手順の追加 開くとき、ドキュメントリストフォームおよびドキュメントフォームの「開く時」イベントハンドラーから呼び出されます。
手順の追加 アラート_リストフォームの処理、ドキュメントリストフォームの「通知処理」イベントハンドラーから呼び出されます。メソッドの 4 番目のパラメーターとして、メソッドによって初期化される構造体が渡されます。 アラートパラメータEDO_ListForm.
手順の追加 アラート_フォームドキュメントの処理中、ドキュメントフォームの「通知処理」イベントハンドラーから呼び出されます。メソッドの 4 番目のパラメーターとして、メソッドによって初期化される構造体が渡されます。 通知パラメータEDO_DocumentForm.
モジュールの変更点 取引相手との交換オーバーライド可能:
追加されたメソッド 作業実行者のデータ転送を入力します.
例：

方法 オブジェクトの編集機能の確認という手順になりました。
追加されたメソッド UPD のデータを入力します。販売者の連邦税務局の情報。このメソッドは、次のタイプの電子ドキュメントのデータを準備します。更新（販売者情報）機能 シュフドップ.
追加されたメソッド 検索ユニバーサル転送ドキュメントの作成。このメソッドは電子ドキュメントからデータを保存します更新（販売者情報）機能 SCHFDOPv ISオブジェクト。
追加されたメソッド UKDI 販売者情報のデータを入力する連邦税務局。このメソッドは、次のタイプの電子ドキュメントのデータを準備します。 英国ドル（販売者情報）機能 KSCHFDIS.
追加されたメソッド 検索ユニバーサル調整ドキュメントの作成。このメソッドは電子ドキュメントからデータを保存します 英国ドル（販売者情報）機能 KSCHFDIS情報セキュリティオブジェクトに。

「銀行との取引」サブシステムの変更点

ExchangeWithBanksRedefinable モジュールの変更点

手順 EDの状態が変化したとき追加した。電子ドキュメントのフロー状態が変化したときに呼び出されます。

サービスモードで動作するための変更

サービスモードで動作するための宛先設定が必要な場合:

共通モジュール SuppliedDataOverridden のプロシージャ GetProvidedDataHandlers に、次のコードを追加します。

ElectronicInteraction.RegisterDeliveredDataHandlers(ハンドラー);

ルーチンタスク「銀行との外部モジュール交換の更新」を一般属性データ領域基本データに追加します。

その他の変更点

定義済みタイプへ 収納スペース機能オプション定数を追加する必要がある ExchangeWithBanksを使用する;
削除された機能 銀行との両替銀行との直接両替を推奨.

バージョン1.3.3

構成プロパティ値:

互換モードは「使用しない」に設定してください。
モダリティの使用モードを「使用しない」に設定できます。
インターフェイス互換性モードは、「バージョン 8.2」、「バージョン 8.2. タクシーを許可する」、または「タクシー。バージョン 8.2 を許可する」の値を取ることができます。

新機能と変更点

2015 年 11 月 30 日付け命令 No. ММВ-7-10/551@「貿易取引中の商品の移転に関する電子形式での文書提出フォーマットの承認について」および 2015 年 11 月 30 日付け命令 No. ММВ-7-10/552@ 「業務成果の引継ぎに関する文書（サービスの提供に関する文書）の電子形式での提出フォーマットの承認について」新しい形式の電子文書がサポートされます。

バージョン 1.2.7、1.3.1 からバージョン 1.3.2.19 への移行

サブシステム「取引先との取引」の変更点

モジュール内 取引相手との交換オーバーライド可能変える：

// 送り状タイプの電子文書のデータを準備します。
// オプション:
// LinkOnED - 電子ドキュメントを生成するために必要な ED へのリンク、
// StructureED - 構造、電子ドキュメントを生成するためのデータ構造。
// データツリー - 値のツリー、電子ドキュメントに記入するためのデータのツリー。
手順データの入力販売者への商品の転送 (ボリュームへのリンク)

同僚！

一部の構成では、エラーによりデータをダウンロードできず、そのため連邦税務局にレポートを提出できません。

取引相手との取引 - TIN/KPP チェックが通らない理由 - は長いプロセスであり、多くの場合、情報を連邦税務局に転送し、質問がある場合には取引相手に関する証明書を提出するだけで十分です。この問題を自分で解決しようとしたり、報告が遅れた場合に罰金を受け取ったりするのではなく、自分自身で対処することができます。

ここでは、1C: Accounting 第 8 版の構成の例を使用して、このような状況から抜け出すためのいくつかのテクニックに焦点を当てます。 3.0。

そこで、トリックその 1: Accounting 8 の取引相手の組み込み検証は、TIN/KPP を持つ取引相手に対してのみ機能します。検証に合格していない取引相手から TIN/KPP を削除しても、エラーメッセージは表示されません。それは単にレポートの検証モジュールの考慮から除外されます。

トリックその 2: 取引相手を確認するとき、「取引相手の状況」という特別な情報登録簿が入力されます。これはあなたが取り組む必要があるものです。

トレーニングベースの例を使用して、このオプションを検討します。未確認の取引相手のリストがあります。

このプログラムは、たとえば Camellia の取引相手のステータスが「KPP は連邦税務局データベースのデータと一致しない」と報告します。このような取引相手は小切手に合格せず、プログラムではそのような取引相手を含む VAT レポートをダウンロードすることはできません。

何ができるでしょうか？

「取引相手のステータス」情報の登録簿を開きます - Ch. メニュー - すべての機能 - 情報レジスタ:

「契約者ステータス」情報レジスターで、希望する取引相手の行にカーソルを置きます。

そして、検証ステータスを「チェックポイントは連邦税務局のデータに対応していません」から「カウンターパーティは連邦税務局のデータベースにあります」に変更します。

「(EDI) は、ロシアの企業や組織で実際に導入されている内容をあまり正確に反映していません。多くの場合、それは従来の紙文書フローの電子サポートに関するものであった (そして現在も) ことが判明しました。最も単純なケースでは、紙文書の電子カードの管理についてであり、より複雑な場合には、その電子コピーの追加回路の作成についてです。ただし、ここでの原本は常に紙の文書です。そのため、このレビューでは、オリジナルの文書が電子形式で提示される場合の「実際の」EDF の実装オプションを指し、「ペーパーレス電子文書管理」(BED) という用語を使用することにしました。同時に、紙文書を廃止すること自体が目的ではなく、業務の品質と効率を向上させるための手段にすぎないことも強調したいと思います。

BED への移行に関する議論は州レベルでかなり長い間行われており、2008 年から活発に行われています。しかし、このプロセスはどれほどダイナミックで成功しているのでしょうか? 今日の結果が 7 ～ 10 年前に予測されたものと異なる理由は何ですか? これらの質問に対する答えを得るために、私たちは EDMS/ECM ツールの開発者やそのようなシステムの実装と運用に携わる専門家に相談しました。

BED への移行との関連性は何ですか

ビジネスロジック (IT グループ) の Alfresco 業務責任者であるオレグベイレゾン氏は、このトピックは、商業組織と政府機関の両方のさまざまな種類の顧客にとってますます重要になっていると述べています。誰もがすでに文字通り紙の流れに溺れています。これは物理的に問題になりつつあり、多くの従業員のデスクトップやキャビネットには、レビューされ、同意され、署名され、保管されている「税務報告」書類が散乱しており、それはますます困難になってきています。それらを管理するために。同氏の意見では、多くの政府規制当局（連邦税務局など）はこのことを認識しており、したがって正式な文書のペーパーレス流通への切り替えを、たとえ必須要件であっても強く推奨しているという。

EOS 社のマーケティング部門責任者であるエレナ・イワノバ氏は、ペーパーレスのドキュメントフローへの移行により、企業はコストを削減し、ビジネスプロセスの効率を向上させることができるが、そのような変革には次のことが必要であることを心に留めておく必要がある、と述べています。技術的ソリューションの導入、規制の変更、電子文書の使用から生じるリスクの最小化に関連する一定のコスト。一般に、状況は明らかです。紙の文書の流れが増えるほど、ペーパーレス交換の問題はより差し迫ったものになります。彼女は、「今すぐ」追加コストが必要なことと、紙文書の通常のプロセスと属性を放棄することを望まない従業員が、そのような移行を遅らせる主な障壁であると考えています。しかし、開発者は実装上の課題を克服できるツールを持っています。

しかし、長引く経済危機の状況下では、すべての企業がこれを実行する準備ができているわけではないと、ELAR Corporation の ECM ソリューション開発部門の責任者である Dmitry Shmailov 氏は述べています。さらに、BED は、生産自動化、重要なタスクのソリューション、コスト削減を目的としたシステム、つまり収益をもたらすプロジェクトほどビジネスの優先事項ではありません。

インタートラストの事業開発担当副ゼネラルディレクターであるヴァディム・イパトフ氏は、組織的および技術的な問題に加えて、今日でも紙の原本の使用に主に焦点が当てられている規制要件もあると回想します。特に、文書の長期 (特に永久) 保管の問題は依然として未解決のままです。総量に占めるそのような文書の割合は小さいように見えますが、それは錨のように紙の原本を全体的に放棄するプロセスを妨げています。

コミュニケーション手段として使用されるドキュメントについて言えば、今日最も一般的なメカニズムは電子メールです。ここには組織的、法的、技術的な問題はないようです。しかし実際には、電子メールは従来の紙版のやり取りを実現しており、自動的に実装されると、IT を使用しても管理が困難な膨大な情報が作成されます。つまり、質的に異なる通信アーキテクチャが必要になります。そして、それらを使用するには、ECM を人、プロセス、関連コンテンツを統合するシステムとして位置づけ、ECM についての理解を再考する必要があると専門家は強調します。今日では、ペーパーレスの文書フローについて話すのではなく、ペーパーレスではあるが、作業プロセス中の人々の文書化されたやり取りについて話す方が正確です。

従来、EDMS の問題は、企業の内部ビジネスプロセスの自動化の問題として理解されており、その多くは組織文書や管理文書に関連していました。しかし、近年、営利企業間、政府機関内、さらには企業や個人と政府機関とのやりとりにおいて、組織間の文書交換の問題の関連性が急速に高まっています。これらすべての分野は現在、まさに組織間の電子文書フローへの移行という観点から急速に発展しています。

これについて、Taxkom のマーケティング部門副ディレクターである Ernest Kolesnikov 氏は、アナリストの予測に言及し、2017 年までに取引相手との EDI メカニズムの使用率は 22.5% に達するだろうと述べています。すでに、新しい VAT 申告書の導入後 (ほぼすべての納税者が電子的に提出する必要がある)、文書の自動化の問題が特に関連性を増しています。これは、手作業によるデータ入力では、会計担当者が取引相手との不一致に関する自動的な要求を受け取る可能性が非常に高いためです。。同氏はまた、ロシア連邦の労働法第 49.1 章により、リモート勤務時の EDI の使用が許可されており、2016 年 7 月 1 日から「株式会社に関する」連邦法の改正が発効し、株主が EDI を使用できるようになることを思い出させます。 EDI を使用して会議にリモートから参加できます。

1C の Electronic Document Exchange のプロジェクトマネージャーである Artem Tanan 氏は、BED への移行の主な動機は、競争力を高めたいという企業の願望であると確信しています。市場のリーダーになりたい人は、法的許可のずっと前からそのような変革の準備を始めており、実際にこれらの機会を最初に習得しています。 2013 年から 2014 年に遡ります。小売チェーン、流通業者、通信事業者など、競争力の高い技術産業の企業は、取引相手との電子的なやり取りを電子的に利用し始めました。これにより、VAT 還付の加速や税務リスクの軽減から税金の最適化まで、包括的な効果を得ることができました。コストを削減し、取引相手とのやり取りの効率を向上させます。供給企業からの圧力を受けて、取引相手も BED に切り替え始めました。 2015 年には、法律の整備と税務報告書の提出に関する多くの新しい規制要件の出現により、このプロセスはさらに広範囲に広がりました。近年、サービスに接続するユーザーの数は大幅に増加しています。

ペーパーレス電子文書管理への移行実践

Elena Ivanova 氏によると、支社や遠隔ユニットとやり取りするときに電子原本を転送する習慣がさらに広まってきています。取引相手との主要な会計文書 (法律書、請求書など) の交換と、対応する専門的な交換サービスとの統合がますます一般的になってきています。しかし、彼女は、多くの組織が依然として電子原本文書の使用時に生じるリスクを警戒しており、どのような種類の電子文書の使用も組織にとって依然として「禁じられている」トピックであると指摘しています。

「電子オリジナルの取り扱いへの移行について話すとき、企業は『私たちは望んでいます』という言葉で始まり、次に『しかし…』が続きます」とオレグ・ベイレゾン氏は指摘します。「その場合、多かれ少なかれ乗り越えられる理由がいくつかあります。一部の部隊の準備が整っていない、予算が割り当てられていない、組織の伝統を壊すことができないなどです。」しかし、一般的に、ペーパーレス技術への移行プロジェクトはあるものの、逆移行プロジェクトについては何も聞いていないという理由だけで、文書フローの電子化の傾向はかなりはっきりと見られる、と同氏は考えている。 BED がカバーする領域は数多くあります。これらには、古典的な EDMS、組織の財務文書フロー、法的に重要な財務文書の流通などが含まれます。法的に重要な組織および管理文書の流れはいくぶん行き詰まっています。法的な微妙な点が多すぎて、十分な実務が開発されていません。さまざまなアクセス分類を持つ文書の電子保存と処理はさらに遅れています。これは、それらを実装するシステムに (通常は当然のことですが) かなり厳しい要件が課されているためです。

Directum ビジネスアナリストの Maxim Kainer 氏は、EDMS/ECM を導入する場合、紙印刷の節約は自動プロセスによってのみ達成されますが、多くの場合、組織全体の総印刷量が増加する可能性があることが判明すると述べています。さらに、ECM による特定のビジネスプロセスの自動化により、このプロセス内であってもドキュメントの印刷を回避できるケースは 10% 未満です。一般的に、これまでのところ、組織がペーパーレスのドキュメントフローに移行するという話はないと彼は考えています。

原則として、紙をなくすという作業自体が目的ではなく、特定のビジネスプロセスを最適化し、その実装をスピードアップし、簡素化することが目標である、とヴァディム・イパトフ氏は強調する。彼の推定によると、顧客組織の大多数は、あらゆる範囲のサポート文書 (指示、決議、実行報告書など) を含む内部電子システムを完全に導入しています。彼の会社の顧客の多くの政府機関では、公共サービスの提供や国民の呼びかけに応じた業務がほぼ自動化されています。リクエストが電子チャネル経由で受信された場合、リクエストは完全に電子的に処理されます。組織、行政、規制文書の分野では、「デジタル化」は比較的99.9%に達する可能性がありますが、少なくとも1枚の紙のコピーでの命令、命令、または規制が依然として必要です。これは、伝統と規制の両方によって決定されています。立法規範。契約書を扱う場合も状況は同様です。契約書の準備と承認の全プロセスは完全に電子的に行われますが、当事者が署名した 2 部のコピーは依然として紙上に「生きています」。

EDMS への移行における重要な役割は、まさに EDMS のユーザーとして組織の IT 部門が果たします。IT 部門は、内部タスク (ユーザー要求の処理、タスクと作業の配分に関するプロジェクト管理、承認など) にこれらのツールを使用します。一方で、彼ら自身の例によって、どのようにして紙を完全に排除できるかを示しています。

「ペーパーレス技術への移行は一般的になってきており、生産ニーズによって推進されています。紙を使わずに作業することは利益をもたらします」とドミトリー・シュマイロフ氏も同意します。 - BED は企業内部のドキュメントフローに非常に関連しています。電子文書が徐々に法的地位を獲得しつつある今日、取引相手と EDMS で作業することは一般的になってきています。」しかし同時に、特別な制度を適用する組織では、国家機密や商業機密を構成する文書や特定の価値のある文書が依然として紙で保管されていると同氏は指摘する。このような文書化のための BED への移行は不可能であるか、最高レベルのセキュリティを確保する必要があるため、費用がかかり、困難であり、多くの場合コストが正当化されません。

Ernest Kolesnikov 氏によると、取引相手との電子文書の交換は、初期状態からより成熟した状態への移行段階を迎えています。 EDF 運営者は当初、文書トラフィックの生成者である最大手の企業を誘致する戦術を選択しました。主要なビジネス分野では、電子形式での文書の交換が一般的になってきており、他の分野ではパイロットプロジェクトが進行中です。このプロセスは、規制当局の作用によって大幅に刺激され、場合によっては開始されることもあります。自動化の一般的なケースは、全国各地に展開する同じ持ち株会社のグループで、ほとんどの文書が電子形式に変換され、最大限の財務効果が確保されます。同時に、専門家は次の重要な点にも言及しています。すべてが法律に従っている場合、透明性の向上は歓迎されますが、状況が逆の場合、秩序を回復する手段として機能しますが、これは迅速なプロセスではありません。」

BED の最も明白な応用分野は、電子納品書と請求書への移行です。しかし、アルテム・タナン氏は、規制当局がこの方向に迅速に進みたいという明確な願望を示しているにもかかわらず、かなり多くの個人的な困難が生じていると指摘する。例えば、納税期間の最終日にサービス（通信、インターネット、公共料金など）が提供され、電子文書による確認を伴う請求書が発行されるなど、電子請求書の交換への移行が妨げられていました。管理運営者は早ければ翌月に日付が判明した。この問題は、連邦法 382-FZ の採択とその後の財務省からの明確化により、非常に迅速に解決されました。

BEDに向かう途中に障害物がある

数年前、この質問に対する主な答えは「規制と立法の枠組みの準備不足」という命題でしたが、今では専門家はこの問題に言及する際、それを第一に考えていません。「組織は紙からの脱却には興味がありません」とマキシム・カイナー氏は言います。 - 紙の文書の印刷と処理にかかるコストはそれほど高くないため、コストを削減することは利点と考えられます。 ECM システムは、ペーパーレスの文書フローに移行するために導入されているのではなく、プロセスの透明性とその加速、リスク軽減など、他のより具体的で明白な効果を得るために導入されています。さらに、プロセスを電子形式に変換することが単に意味をなさない場合もあります。電子署名証明書の価格がかなり高いことも含まれます。」同時に同氏は、規制の枠組みの欠点、つまり多くの規定が曖昧であり、一般的な勧告的な性質を持っているため、実証済みの作業パターンを変更したくない組織に選択を委ねていることにも言及している。同時に、ほとんどの企業では IT インフラストラクチャレベルでの変更が必要になるため、新しいアプローチを急激に押し付けるべきではないと彼は確信しています。

エレナ・イワノワ氏は、法的枠組みの問題について、多くの規制問題は組織自体の責任であるという事実に注意を促しています。「さまざまな意味で、経営陣の意志が BED の発展に役割を果たしています」と彼女は確信しています。 - マネージャーが紙なしで仕事をするように命令した場合、望むと望まざるにかかわらず、誰もがそれを実行します。組織内の経営陣の側にそのような動機付けの行動がない場合、それは彼らが BEA に経済的な実現可能性や効果を見出していないことを意味します。また、BED 導入プロセスの推進役として機能し、その喜びをすべてマネージャーに伝えることができる人材が不足しているという問題もあります。」

ドミトリー・シュマイロフ氏も彼女に同意し、次のように述べています。「もちろん、この法律はBEDの発展という点で西側諸国に遅れをとっていると言えますが、法律の修正によって提供される機会さえ誰もが利用できるわけではないということの方がはるかに重要です。」むしろ、遅れが生じています。多くの BED テクノロジーは、少数の組織のみで使用されています。当社の顧客の場合、電子会計トピックの開発と深化、および会計文書を電子形式で処理および保存するための統一モデルの構築への傾向が見られます。 BED への完全な移行は、電子署名のための単一の信頼空間が欠如しているため、大幅に制限されています。また、情報保護要件を忘れないでください。場合によっては、電子文書の保存や使用が不可能になることがあります。まあ、資金調達は依然として重要な要素です。」

アーネスト・コレスニコフ氏は、有名な言葉を言い換えて、ロシアの電子文書管理の 2 つの主な問題、すなわち法律と人々を挙げています。「法律にはギャップがあり、たとえば、いくつかの文書についてのみフォーマットが承認されている一方、他の種類の文書については作業が進行中である。近い将来、ユニバーサル転送ドキュメントの形式が承認される予定であり、あらゆるドキュメントを添付できるユニバーサルコンテナについての話があります。形式化されていない文書を使用する司法慣行は、すべての企業が恐れることなく EDI に切り替えるにはまだ十分ではありませんが、時間が経過し、状況は良い方向に変化しつつあります。 2 番目の重要な問題は、人々と一般的な生活の現実です。お客様からよく聞かれるのは、紙を拒否するのは、強制された場合のみです。」

既存のプロセスの枠組み内で新しいテクノロジーを導入するには、主に人材の再訓練と、イノベーションを適用したいという企業経営者の意欲が必要ですが、プロセスは本質的には同じままだとアルテム・タナン氏は言います。彼は具体的なアドバイスを与えています。BED を導入するには、責任者を任命し、文書を扱うための新しい手順を構築し、スタッフを訓練し、選択した取引相手に対して古い手順を放棄する期限を決定するという 3 つの主要なタスクを実行する必要があります。文書を扱うための新しい手順をシンプルかつ理解しやすく、既存の手順との差異を最小限にするためには、BED と会計、管理、および EDMS プログラムの統合をサポートする必要があり、さらに良いのは、BED を作成することです。それらの不可欠な部分です。おそらく最も問題となる別のブロックは、取引相手の関与の問題です。 BED 顧客の取引相手を接続するだけでなく、文書を扱うための新しい手順への移行を支援することも必要です。そうしないと、BED を使用したとしても、仕入帳簿と売上帳簿の情報に誤りや矛盾が残るなど、悪影響が生じます。専門家は、今後数年間でBEDを他のビジネスシステムと統合し、請負業者を巻き込む問題が、我が国におけるBED技術の普及において大きな役割を果たすだろうと確信している。

何をするか？

「現時点では、公共部門であろうと商業部門であろうと、ロシアでは紙を完全に放棄することは不可能です」とエレナ・イワノワ氏は言う。 - まず第一に、組織が BED に切り替えることを促進する法的枠組みを開発する必要があります。部分的には、これは現在、SMEVの改善に関連して政府組織に現れ始めています。」多くは EDMS ベンダーに依存すると彼女は考えています。 BED への切り替えによる経済効果を正当化し、技術的なソリューションを提供できます。 EDMS/ECM 分野の標準化に関わる専門家コミュニティや組織で活動し、州規制当局と連携することも重要です。

さらに、EDMS サプライヤー自身が BED への移行の手本を示さなければならない、とドミトリー・シュマイロフ氏は確信しています。これらの企業では、業務効率を向上させるために電子文書管理も必要です。顧客がいない状況では、自社のビジネスで BED テクノロジーをテストすることが成功の要因になる可能性があります。 EDMS サプライヤーは、クライアントの個別の要件や仕様を満たし、それらを考慮した最新の開発を提供することで、技術開発の点で優れた支援となるでしょう。

Maxim Kainer 氏は、BED への移行の経済的正当性についても語っています。「ペーパーレスドキュメントフローへの移行を実現するには、IT ソリューションの導入により、紙媒体でのサポート作業 (機器の購入とメンテナンス、消耗品、輸送および配達のコスト、保管および回収のコスト）。世界の専門家は、半数以上のケースで特定の ECM ソリューションへの投資の回収期間は 1 年半以内であると言っています。」このプロセスにおけるベンダーの本当の参加は、「紙を使わずに作業することは可能であり、収益性がある」という考えを促進すること、立法プロセスに参加すること、そしてクラウドモデルや SaaS の使用を含むソリューションのコストを削減することにあるかもしれません。

BED に乗り越えられない障壁はありませんが、解決できる、解決すべき問題はあります、とアーネスト・コレスニコフ氏は言います。明らかにポジティブな側面は、政府当局が国の自動化に多額の投資を行っていることであり、過去 10 年間で生活と仕事がはるかに快適になったと言えます。問題はありますが、それらは規制当局、開発者、顧客の共同の努力によって特定され、解決されます。「ある時点までに、社会の情報量は十分な量に達し、昔ながらの方法で文書を紙に表示するのは過去のものであることが誰もが理解するでしょう」と彼は確信しています。「今ではインターネットのない生活を想像するのは難しいですが、電子文書処理があれば状況は同じになると思います。」

「私たちは、企業自身が紙の流れに対処できなくなり、規制当局の要件を満たせなくなる『最後の決断』を待たないことをお勧めします」とアルテム・タナン氏はアドバイスする。 - どのようなタイプの取引/文書に対して、どの取引相手と BED を使用するかを今すぐ決定し、責任者を任命し、期限を設定する必要があります。必要に応じて、この分野で十分な能力を持つ専門家を関与させ、割り当てられたタスクの高品質な実装を確保します。方法論的または技術的な性質の問題が生じた場合は、BED 問題に関する作業グループの専門プラットフォームでの議論に持ち込んでください。 1 つの企業で BED に移行するときに特定のタスクを設定するだけで、他の市場参加者に理解できる成功体験を得ることができます。大企業と SF オペレーター、ソフトウェアベンダー、およびそのパートナーネットワークがこの経験を複製することが、BED テクノロジーを市場に流通させる最も効果的な方法です。」

私たちはすでに多くのことを行ってきたことを継続します。

チェルノムイルディン V.S.

少し前に、クライアントが再びよく知られた問題について私に相談してきました。彼の会社は 1C アップデートをインストールしました。そして、プログラムが正常に動作しなくなったため、作業が停止しました。プログラマーまたはユーザーとして 1C のソフトウェア製品に接したことがある人なら誰でも、この状況をよく知っていると思います。

もちろん、今回のケースでは、すべての問題をできるだけ早く解決するよう努めた結果、事務作業は正常に戻りました。しかし、このような状況でも、クライアントからは多くの否定的な意見を受けました。そして、なぜ 1C ソフトウェア製品でこれほど多くの問題が常に発生するのか、なぜクライアントから否定的な意見が多いのか、そしてなぜ 1C プログラマ自体が他のプログラマを含めて嫌われることが多いのかを考えました。

この記事では、そのような否定的な考えにつながる理由について、私なりの解釈を提示することにしました。文章ができるだけ多くの読者に理解できるように、特定の用語をできるだけ使用しないように努めます。

同時に、私自身もしばらくの間、もっぱら 1C プログラミングに従事していましたが、現在では仕事で 1C のソフトウェア製品を非常に積極的に使用しています。また、収入を得る機会を与えてくれたこの会社に非常に感謝しています。自分。

しかしその一方で、否定的な理由も理解する必要があると思います。少なくとも、すべてを直感や感情のレベルに終わらせないために。

1Cはどのようにして始まったのでしょうか？覚えておきましょう！

個人的には、バージョン 6.0 から 1C ソフトウェアを使い始めました。私の意見では、このプログラムは Excel スプレッドシートに保存されているさまざまな会計オプションよりも少し複雑でした。

これは、最も成功したリリースである 1C 7.7 を含む第 7 バージョンに置き換えられました。これはすでにかなり強力なソフトウェア製品であり、ソ連崩壊後の空間全体に非常に普及しました。この時点までに、ほとんどのユーザーは 1C の使用に慣れており、これらのプログラムを使用できることが会計士、さまざまな事務職員、マネージャー、店主などを雇用するための条件の 1 つになりました。

原則として、1C 7.7 はさまざまな種類の会計に関連する問題を非常にうまく解決しました。また、このソフトウェア製品は現在でも使用されているケースもあり、その人気の高さが伺えます。

このソフトウェアは、その機能の広さと同時にシステムの複雑さにも驚かされます。

現在、1C 社はクライアントにエコシステム全体を提供しています。

開発者向けの強力なプラットフォーム。
各種会計・分析を維持する環境
さまざまな業務用機器との接続が可能
パートナーの広範なネットワーク
Webサイト制作に最適な多機能CMS

同時に、このエコシステムのすべてのコンポーネントは、一緒に、または個別に、最適な方法で機能しません。多くの場合、問題が発生し、仕事で失敗し、追加の時間とお金が必要になり、もちろん拒否の原因になります。

1C アップデート: 仕組み

1C ファミリのソフトウェア製品が現在どのように動作するかを簡単に思い出していただきたいと思います。ほとんどの場合、ユーザーは 1 つ以上のソフトウェア製品を購入します。このソフトウェア製品は、プラットフォームとそのプラットフォーム上に記述されたアプリケーション (いわゆる構成) で構成されます。

次に、プログラマーは、選択した構成の動作を特定の企業のニーズに合わせて調整し、多くの場合、追加のプラグインをインストールし、特定のレポートを改良し、この企業の内部文書フローとして参加する新しい文書を作成します。

同時に、プラットフォームと構成の両方に、開発者によるかなりの数のバグがあります。そして、システム自体が非常に複雑で膨大なため、1C プログラマーの助けを借りてこれらのバグを修正することは非常に困難であり、最も重要なことに、エンドユーザーにとっては利益が得られません。さらに、プラットフォームと構成自体の両方が、モジュール性の欠如などの不愉快な性質によって区別されます。

その結果、バグを修正するにはアップデートをインストールする必要があります。この場合、プラットフォーム全体および/または構成は毎回更新されます。当然のことながら、そのような解決策には多くの時間がかかり、構成について話している場合、プログラマーが実行する設定、追加のプラグイン、その他の変更を再度行う必要がある可能性が高くなります。

しかし、これは 1C アップデートの状況において最も悲しいことではありません。最も悲しいことは、開発者の Web サイトには、アップデートが非常に頻繁にリリースされ、場合によっては月に 3 ～ 4 回リリースされることが示されていることです。場合によっては、重要ではないエラーが修正されることもあれば、システム全体の動作に関連する重大なバグが修正されることもあります。

新しいバージョンはそれぞれ機能の追加であり、以前のバージョンのバグに対する一種の「パッチ」であり、古いエラーが修正されますが、ほとんどの場合、新しいエラーが導入されます。したがって、更新プログラムのインストールは、ほとんどが予測不可能なプロセスになります。

モジュール性の欠如: なぜそれがそれほど重要なのか

まず、プラットフォームについて直接話しましょう。 1C プログラマーは、それがどれほど面倒になったかを知っています。モジュール性の欠如については上ですでに書きました。製品コードにはいわゆるサブシステムが含まれていますが、それらはモジュール性の要件を満たしていないため、コードを構造化しようとするある種の試みにすぎません。

私が個人的にモジュール性の欠如が問題だと思うのはなぜですか? 例を挙げて理解しましょう。貿易管理の運用を成功させるために必要ないくつかの機能を改良したり、残高を保存する方法を変更したりする必要があるとします。しかし、1C プラットフォームではすべてが相互接続されているため、給与や会計などを操作するために更新をドラッグする必要もあります。等々。

モジュール性がない場合、ほんの小さな変更を加えるためにも、アレイ全体、プラットフォーム全体を調査する必要があります。

同時に、1C プラットフォームは非常に大きくて扱いにくいです。現在では、その豊かな可能性のために、最初は感嘆さえ呼び起こすほど多くのものが含まれています。しかし、このプラットフォームを使用すると、その賞賛はすぐに薄れてしまいます。 1C の開発者は、プログラムを普遍的なものにするために、プラットフォームにさまざまな機能を追加しました。

そして、強力なツール、便利なビジュアルインターフェイスを同時に手に入れることができます... システムの複雑さによる多くの問題やバグ。

別の例を挙げましょう。私の仕事には貿易だけが必要だとしましょう。同社は、モバイルインターフェイス、会計、オンラインストア、その他のコンポーネントなど、他には何も使用していません。しかし、何があっても、更新を受け取ると、使用しないコンポーネントの操作に必要な機能を含むプラットフォーム全体を受け取ることになります。それらの。私はコマースを使用しており、アップデートは会計と連動するように設計されているにもかかわらず、プラットフォーム全体をダウンロードしてインストールする必要があります。

ライセンスポリシーとシステムのバグ

プラットフォームを更新すると、ユーザーはライセンスキーが機能しなくなるという事実に直面することがよくあります。このような状況に個人的に遭遇したことがない場合は、検索エンジンに「1C はアップデート後に動作を停止しました」と入力するだけで、この問題がどれほど広範囲に広がっているかがわかります。

そこで、状況を想像してみてください。たとえば30人を雇用している会社があります。更新後、プログラムはライセンスキーの受け入れを停止しました。会社の仕事は麻痺している。会社は損失を被ります。

重要な問題は、更新時のプラットフォームの動作が予測できないことです。

ライセンスが頻繁に失敗することに加えて、プラットフォームの更新後に新しい機能が含まれる可能性があり、それが正しく動作しなくなる可能性もあります。しかし、実際には、作業の品質をチェックし、プログラムの新しいバージョンの新しいバグを特定することしかできません。進行中。

プラットフォームは非常に大規模で扱いにくいため、プログラマーが短時間でテストするのは非現実的であることを思い出してください。そして、アップデートのたびにこれらすべてを考慮する必要があります。

したがって、プログラマの状況は次のようになります。

プラットフォームが完全に更新され、将来使用されないツールを削除したりインストールしなかったりする方法がないため、更新するたびに多くの混乱が生じます。
それでも、更新は必要です。これは、既知の、またはプログラマーによってまだ特定されていない現在のバグを「治す」唯一の機会だからです。
さらに、新しいアップデートには通常、次のバージョンで修正される新しいバグが含まれています。

したがって、円は閉じられます。そして、プログラマーは、新たな問題が発生するにもかかわらず、何度も新しいバージョンをインストールしなければなりません。

なぜこんなにバグが多いのでしょうか？

私の謙虚な意見では、バグが多い主な理由はシステムの複雑さです。 1C プラットフォームは、Windows 32 および 64 ビット、Linux、サーバーバージョン、モバイルなどで利用できるようになりました。メンテナンスの複雑さは非常に高く、実際に見てわかるように、1C 開発者はメンテナンスに対処することができません。

モジュール性の欠如により、すべてのエラーを特定し、このような面倒なソフトウェア製品をデバッグすることは事実上不可能であるため、さらなる困難も生じます。その結果、新しいアップデートが継続的にリリースされます。

バグが常に存在し、その状況が存在するもう 1 つの非常に重要な理由は、競争の欠如です。実際、1C は現在独占企業です。

もちろん、代替ソフトウェア製品も作成されており、その中には非常に優れた製品もあります。しかし、これまでのところ、それらはすべて特定の問題を解決できる応用ソリューションであり、1C はエコシステム全体です。

さらに、1C 社は非常に強力かつ積極的なマーケティングを特徴としており、このソフトウェアについては誰もが知っています。

だからこそ私は、現在、1C にはソ連崩壊後の領域において相応しい競争相手がいないと主張するのである。そして、競争の欠如は常に製品自体の品質の低下につながります。これは 1C の例で見られます。つまり、絶え間ない「生の」アップデート、絶え間ないバグ、アップデートに関する詳細なドキュメントの欠如などです。
したがって、私はすべてのクライアントに、絶対に必要な場合を除き、アップデートしないことを個人的にアドバイスしています。ちなみに、私自身も1Cの起源にある人から同じようなアドバイスを受けました。

もちろん、現在のバージョンには間違いなくいくつかのバグがありますが、問題なく作業できるのであれば、これらのバグは重要ではありません。新しいバージョンで何が起こるかを予測することは不可能です。したがって、更新プログラムは、業務上本当に必要になった場合にのみインストールする必要があります。

旗艦。一般的な構成

1C ソフトウェア製品ラインは標準構成に基づいています。 1C の Web サイトには、既製のボックス化されたソリューションが多数提供されています。

しかし、大多数のユーザーは次の 4 つの構成のみを使用します。

企業会計
貿易管理
製造工場管理
給与および人事管理

そして、それぞれの構成にはプラットフォームと同じ欠点があります。

モジュール性の欠如
かさばって不要な機能が多い
新しいバージョンの新しいバグ
予測できないアップデート結果

さらに、更新のたびに、正確に何が更新されたかを分析し、更新自体を実行し、構成を再構成する必要があります。しかし、構成の更新も頻繁に行われるため、それを理解するのが困難になります。

さらに、モジュール性が欠如しているため、変更が使用しない機能に影響を与える場合でも、更新が必要になることがよくあります。単純に、この機能のエラーが他のモジュールの誤動作につながる可能性があるためです。

貿易について話す場合、私の実践では、実際に人々がこのコンポーネントの全機能の 30% しか使用していないことがわかります。他の一般的な構成でも状況は同様です。開発者は、最大数の機能を実装することを追求して、すべてが相互接続された非常に扱いにくく複雑な製品を作成しました。そのため、不要な機能を無効にすることさえ常に可能であるとは限りません。

たとえば、Trade を更新するときに、開発者は新しいボーナスシステムを追加しました。クライアントはボーナスをまったく使用しません。彼にはそれらは必要ありません。ただし、これらのボーナスを無効にしようとすると、割引システムが誤って動作し始めます。私は実際にこの状況に遭遇しました。もちろん、この問題を解決するにはプログラマーの助けが必要でした。

最近、私はプロジェクトの完了後はすべてのクライアントにアップデートを一切行わないようにアドバイスするという結論に達しました。私は仕事に必要なすべてを構成し、クライアントとその従業員と一緒に構成をテストし、すべてがうまく機能することを確認しました。したがって、大きな変更が必要になるまで、構成を更新する必要はありません。

積極的なマーケティングとその成果

私のクライアントは私のアドバイスに反してアップデートをインストールすることがよくあります。なぜこうなった？

プログラマーのモチベーション

1C プログラマは、クライアントがソフトウェアをできるだけ頻繁に更新することに関心があります。それは彼らにとって単純に有益です。更新するたびに、構成を再構成する必要があります。したがって、アップデートの助けを借りて、文字通り何もないところから収入を得ることができます。

企業が更新を行わずに何らかの構成で落ち着いて確実に運用している状況を想像してください。しかし、たとえば、別のレポートを作成したり、追加の処理をインストールしたりする必要がありました。当然のことながら、この場合、彼らは専門家に頼ることになります。

次は何が起こる？ 1C プログラマーがやって来て、プログラムが長い間更新されていないことに気づきました。彼は、これがいかにひどいことであるかをクライアントに伝え、アップデートがなければ顧客が必要とするレポートを設定したり、他の作業を実行したりできないことを説明し、古いバージョンにある多数のエラーを見てクライアントを怖がらせます。等々。一般に、これはクライアントにアップデートを購入してインストールするよう説得します。

実際、ほとんどの場合、客観的には更新の必要はありません。しかし、プログラマーの仕事量は増加し、それに応じて報酬も大幅に増加します。ちなみに、多くのユーザーが 1C プログラマに対して否定的な態度をとっているのはこのためです。彼らの観点からすると、プログラマが働き始める前に完璧に動作していたものに対して、金額の 90% をプログラマに支払うことになります。同じ機能に対して何度も料金を支払う必要があります。

1Cからの攻めのマーケティング

1C 社自体も、ユーザーができるだけ頻繁に最新情報を入手できるようにすることに関心を持っています。その結果、ユーザーは新しいアップデートに関するリマインダーや、プラットフォームや構成をアップデートする必要があるという警告を受け取ることがよくあります。しかし同時に、このサイトには、アップデートの場合にユーザーが正確に何を受け取るのか、どのようなバグが修正されたのか、どのような機能が登場したかについて、十分に詳細な情報がありません。それらの。特定のアップデートをインストールする必要性を客観的に評価することは不可能です。その結果、多くのユーザーは安全を確保するためにアップデートを行っています。

サービスとフランチャイズのデメリット

1Cの会社には顧客サービスはほとんどないと思います。同社は販売面で優れた仕事をしており、非常に積極的で、確かに効果的なマーケティングポリシーを持っています。しかし、メンテナンスが必要な場合は、多くの困難に直面することになります。

1C Web サイトにはセクション全体があり、1C ソフトウェア製品のメンテナンスサービスを提供するお住まいの地域の認定パートナーを見つけることができます。これらのパートナーは認定されており、アフィリエイト料金を支払います。すべてが順調に進んでいるように見えます。

しかし実際には、1C 社はパートナーと協力することはほとんどありません。

企業がパートナーステータスを取得するには、認定スペシャリストをスタッフに配置するだけで十分です。
その後、繰り返しのチェックや試験を行う人はいません。したがって、認定プログラマーが唯一の専門家であり、まったく別の人がサービスを提供するようになるか、完全に辞める可能性がありますが、会社はパートナーの地位を失うことはありません。
1C は事実上パートナーと協力せず、トレーニングも提供せず、仕事の品質も管理しません。

このような政策の結果は多くの人に知られています。 1C パートナーのリストに特定の企業が含まれていても、高品質のサービスが保証されるわけではありません。

1C がエコシステム全体であることはすでに述べました。ある意味では、Apple と比較することもできます。そこには、ハードウェア、ソフトウェア、再販業者で構成されるシステム全体が構築されています。 1C にもプラットフォームがあり、構成があり、認定再販業者がいます。

しかし、Apple が生産からパートナーの仕事に至るまで、すべての段階で品質を非常に厳密に管理しており、最高の品質がこのブランドにとって重要な競争上の利点の 1 つである場合、1C 企業ではすべてが完全に異なります。ここには実質的にサービスがなく、パートナーの作業を管理する人もいないため、ソフトウェアの販売後の作業の品質は非常に低くなります。

1C 社がマーケティング活動を主に製品の消費者、つまり消費者に向けていることも興味深いです。ユーザーについて。そして、構成の操作は完全にプログラマーに集中しています。その結果、宣伝されているものは 1 つありますが、実際には購入者がまったく異なるものを受け取ったことが判明します。

そしてここには、1C プログラマとソフトウェア製品自体に対する否定的な理由も現れています。
1Cだけで仕事をするのをやめて、ビジネスコンサルティングをするようになったとき、仕事でさまざまなソフトウェア製品を使い始めました。これらは Drupal 上のサイトと、ZOHO CRM、ATOL RMK、Redmine、その他多くのシステムのようなシステムでした。また、これらのサービスやプログラムのほとんどすべては、継続的かつ頻繁な更新を必要としません。そして、アップデートする際には、それほど多くの問題はありません。

一方、1C 社は販売と継続的なアップデートという 2 つの方向で収益を上げています。しかし、クライアントはそれと何の関係があるのでしょうか？他に選択肢がないため、彼は料金を支払ってアップグレードすることを余儀なくされました。さらに、企業内で使用されるすべての製品を同時に更新する必要があります。

たとえば、Trade を使用している場合、関連するいくつかのバグを修正する非常に便利なアップデートがリリースされています。Accounting も必ずアップデートする必要があります。データ交換は同一の構成バージョン間でのみ可能であるためです。更新せずに会計を終了することにした場合、取引から会計へのドキュメントのアップロードは機能しなくなります。

その結果、クライアントは常に故障するシステムを使用し、それを修復するために定期的に料金を支払うことを余儀なくされます。当然、お客様は消極的になってしまいます。しかし、他のソフトウェア製品に切り替えることはできません。価値のある代替品が見つからないだけです。

はい、我が国には他にも会計システムがあり、そのいくつかは機能の点で徐々に 1C に追いつきつつあります。でもマーケティングってすごいですね！したがって、顧客は代替案を見つけることができず、常に否定的な状況にもかかわらず、別の支払いを行います。

1C: Bitrix - 困難、機能、マーケティング

伝統的に 1C ラインの一部として分類されているもう 1 つの製品は、1C-Bitrix Web サイト管理システムです。同時に、多くのユーザーは、Bitrix を購入すれば十分であり、サイトとデータを 1C に統合する際の問題はすべて解決されると確信しています。

1C ソフトウェア製品を購入し、1C-Bitrix で Web サイトを注文するユーザーは、共通のブランドを見て、これらが同じラインの製品であり、常に問題なく連携できると確信します。
実際、CMS Bitrix は 1C 社とは何の関係もない専門家によって開発された別の製品です。その後、このCMSに1Cライン製品との統合ツールが追加され、新たな名称「1C-Bitrix」が登場しました。これは、1C 社が Bitrix の株式を大量に購入し、この CMS をソフトウェアとともに使用することにしたために起こりました。

結果はどうなりましたか?

オンラインストアデータベースと 1C ソフトウェア製品の統合は実際に提供されます。しかし、これは非常に複雑で、専門家の助けがなければデータ交換を設定することはほぼ不可能で、変更することも非常に困難です。

さらに、1C をセットアップしたプログラマーは、Bitrix をインストールして構成することはできません。ここでは、Web プログラマー、つまり Bitrix スペシャリストが必要になります。この統合は、一部は 1C プログラマーによって構成され、一部は Bitrix スペシャリストによって構成されます。また、ユーザーが誰に連絡すればよいのかまったくわからない場合もあります。

たとえば、こんな状況がありました。最新の更新後、クライアントとサイトとのデータ交換が機能しなくなってしまいました。私は 1C の専門家に相談しましたが、彼は問題は Bitrix 側にあると考えていたため、私たちを助けることができませんでした。私たちは Bitrix プログラマーに相談しました。彼はまた手を上げて、おそらく問題は依然として 1C 側にあると述べた。約2週間ほどサイトとのデータ交換ができなくなりました。クライアントは価格と残高を手動でダウンロードし、Web サイトから注文をアンロードする必要がありました。結局のところ、私たちは幸運でした。私は Bitrix と 1C の両方に精通しているプログラマーに連絡し、交換モジュールをセットアップしてくれました。

Bitrix と 1C: 異なるシステム、共通の欠点

Bitrix の最新バージョンに精通している Web 開発者なら、私のことを理解できるでしょう。 1C ソフトウェア製品と同様に、Bitrix の最新バージョンは非常に強力になり、広範な機能を備えていますが、同時に不必要に複雑になっています。現在では、Bitrix の管理者 (Web プログラマー) の助けがなければ、ユーザーはほとんどの場合、製品カタログに新しいカテゴリを設定することさえできません。これは、インテリジェントな検索を組織するには、製品の種類ごとに独自のパラメーターを設定する必要があるためです。

同時に、Web サイトと 1C プログラムを保守するにはさまざまな専門家が必要です。結局のところ、これらは異なる製品です。これらはさまざまな目的で使用され、さまざまなプラットフォームを備えており、それらを使用するにはさまざまなテクノロジーの知識が必要です。

履歴書の代わりに

それでは、まとめてみましょう。 1C ラインのソフトウェア製品は、次の理由から専門家の間で否定的な印象を与えます。

システムの複雑さの高さ
モジュール性の欠如
すべてのアップデートにバグがある
アップデートに関する詳細なドキュメントが不足している
更新プログラムのインストールによる予期しない結果

これはすべて、プラットフォームとあらゆる 1C 構成の両方に当てはまります。

ユーザーからの否定的な意見は次のような原因によって引き起こされます。

更新プログラムのインストールによる予期しない結果。プログラムはいつでも動作を停止する可能性があります。ただし、以前のバージョンにはバグがあるため、アップデートが必要です。
1C 会社とプログラマーの両方がアップデート料金を支払う必要があります。同時に、ユーザーに見える利点はほとんどの場合重要ではなく、新しいバージョンをインストールした後にプログラムの機能を復元するためにコストのほとんどを支払わなければなりません。

1C プログラマに対する否定的な態度も明らかになります。

ユーザーはプログラムに関する否定的な意見の一部を専門家に伝えます。結局のところ、アップデートのインストールと構成のセットアップに対して支払いを受け取るのは 1C プログラマーです。
他の分野で働くプログラマーは、1C を専門とする同僚が、本質的には「空気を売る」目的でお金を受け取っていることが多いことを理解しています。これは、スペシャリスト自身によってクライアントに更新が適用される場合に特に顕著です。
1C 側の管理能力の欠如により、無作為の人々がソフトウェア製品のサービスに従事することになりますが、これも良いイメージには寄与しません。

これらは私が個人的に出した結論です。おそらく私は何かについて完全に正しいわけではなく、何かを見逃しているのかもしれません。いずれにせよ、私がこの記事を書くことにしたのは、それ自体を批判するためではなく、どのような理由でクライアントが 1C ラインプログラムや 1C プログラマーに対して否定的な態度をとるのかを理解するためです。

タグ: タグを追加する

取引相手のステータスが悪い 1 秒です。 ペーパーレス電子文書フローへの移行: 経験、問題点、展望

新機能と変更点

バージョン 1.3.7 からバージョン 1.3.8 への移行

バージョン1.3.7

新機能と変更点

バージョン1.3.6

新機能と変更点

バージョン 1.3.5 からバージョン 1.3.6 への移行

バージョン1.3.5

新機能と変更点

バージョン 1.3.4 からバージョン 1.3.5 への移行

バージョン1.3.4

新機能と変更点

バージョン 1.3.2、1.3.3 からバージョン 1.3.4 への移行

ExchangeCounterparty モジュールの変更点

「銀行との取引」サブシステムの変更点

サービスモードで動作するための変更

その他の変更点

バージョン1.3.3

新機能と変更点

バージョン1.3.2

新機能と変更点

バージョン 1.2.7、1.3.1 からバージョン 1.3.2.19 への移行

バージョン1.3.1

新機能と変更点

バージョン 1.2.6、1.2.7 からバージョン 1.3.1 への移行

ExchangeWithBanksOverridable:

取引相手との交換サーバー上で作成される場合:

バージョン 1.3.6 からバージョン 1.3.7 への移行

新機能と変更点

バージョン 1.3.7 からバージョン 1.3.8 への移行

バージョン1.3.7

新機能と変更点

バージョン 1.3.6 からバージョン 1.3.7 への移行

バージョン1.3.6

新機能と変更点

バージョン 1.3.5 からバージョン 1.3.6 への移行

バージョン1.3.5

新機能と変更点

バージョン 1.3.4 からバージョン 1.3.5 への移行

バージョン1.3.4

新機能と変更点

バージョン 1.3.2、1.3.3 からバージョン 1.3.4 への移行

ExchangeCounterparty モジュールの変更点

「銀行との取引」サブシステムの変更点

サービスモードで動作するための変更

その他の変更点

バージョン1.3.3

新機能と変更点

バージョン 1.2.7、1.3.1 からバージョン 1.3.2.19 への移行

BED への移行との関連性は何ですか

ペーパーレス電子文書管理への移行実践

BEDに向かう途中に障害物がある

何をするか？

1Cはどのようにして始まったのでしょうか？ 覚えておきましょう！

1C アップデート: 仕組み

モジュール性の欠如: なぜそれがそれほど重要なのか

ライセンスポリシーとシステムのバグ

なぜこんなにバグが多いのでしょうか？

旗艦。 一般的な構成

積極的なマーケティングとその成果

プログラマーのモチベーション

1Cからの攻めのマーケティング

サービスとフランチャイズのデメリット

1C: Bitrix - 困難、機能、マーケティング

結果はどうなりましたか?

Bitrix と 1C: 異なるシステム、共通の欠点

履歴書の代わりに

取引相手のステータスが悪い 1 秒です。ペーパーレス電子文書フローへの移行: 経験、問題点、展望

1Cはどのようにして始まったのでしょうか？覚えておきましょう！

旗艦。一般的な構成