データ転送のルール 1. オブジェクト変換ルールの例。大規模な情報ベースの転送

異なる構成間でのデータの移行は簡単な作業ではありません。いつものように、解決策はいくつかありますが、そのすべてが最適であるわけではありません。データ転送の微妙な違いを理解し、そのような問題を解決するための普遍的な戦略を選択してみましょう。

あるソリューションから別のソリューションへのデータ移行の問題 (ここでは純粋に 1C 社の製品について話しています) は昨日発生したものではありません。 1C 社は、開発者が移行を作成するときにどのような困難に直面するかを完全に理解しているため、ツールを使用してあらゆる方法で支援しようとしています。

プラットフォームの開発中に、同社はデータ転送を簡素化するテクノロジーだけでなく、多くの汎用ツールを導入しました。これらはすべての標準ソリューションに組み込まれており、同一構成間の移行の問題はほぼ解決されています。標準ソリューションの緊密な統合によって、勝利が再び確認されました。

非標準ソリューション間の移行では、状況は多少複雑になります。テクノロジの幅広い選択肢により、開発者は独自の観点から問題を解決する最適な方法を選択できます。

それらのいくつかを見てみましょう:

テキストファイルを介して交換します。
交換プランの使用。
等

それぞれに独自の長所と短所があります。要約すると、主な欠点はその冗長さです。移行アルゴリズムを独立して実装するには、長時間のデバッグプロセスだけでなく、多大な時間コストがかかります。そのような決定に対するさらなるサポートについては話したくありません。

サポートの複雑さと高額のため、1C 社はユニバーサルソリューションを作成するようになりました。開発と移行のサポートを可能な限り簡素化できるテクノロジー。その結果、このアイデアは別の構成である「データ変換」という形で実装されました。

データ変換 - 標準ソリューション、独立した構成。「ITS:Prof」サブスクリプションをお持ちのユーザーは、ユーザーサポートサイトまたは ITS ディスクからこのパッケージを完全に無料でダウンロードできます。インストールは、1C の他のすべての標準ソリューションと同様に、標準的な方法で実行されます。

ここで、このソリューションの利点について少し説明します。最も重要なこと、つまり汎用性から始めましょう。このソリューションは、特定のプラットフォーム構成/バージョンに合わせて調整されていません。標準構成でもカスタム構成でも同様に機能します。開発者は、新しい移行を作成するための普遍的なテクノロジーと標準化されたアプローチを持っています。ソリューションの汎用性により、1C:Enterprise 以外のプラットフォームでも移行を準備できます。

2 番目の大きな利点は視覚補助です。単純な移行はプログラミングなしで作成されます。はい、はい、コードを 1 行も書く必要はありません。このためだけでも、時間をかけてテクノロジーを一度学習し、貴重なスキルを繰り返し使用する価値があります。

3 番目の利点は、データ配布に制限がないことです。開発者自身が、データを受信側構成に配信する方法を選択します。すぐに使用できるオプションは 2 つあります。xml ファイルへのアップロードと、情報ベース (COM/OLE) への直接接続です。

建築を学ぶ

データ変換が驚くべき効果をもたらすことはすでにわかっていますが、技術的な利点が何なのかはまだ完全には明らかではありません。まず理解する必要があるのは、データ移行 (変換) は交換ルールに基づいているということです。交換ルールは、情報セキュリティからのデータがアップロードされる構造を記述する通常の XML ファイルです。データのアップロード／ダウンロードを行うサービス処理では、交換ルールを解析し、それに基づいてアップロードを行う。ロード中は、逆のプロセスが発生します。

「CD」構成は、開発者が交換ルールを作成するための一種のビジュアルコンストラクターです。データのダウンロード方法が分かりません。 CD 配布パッケージに含まれる追加の外部サービス処理がこれを担当します。それらはいくつかあります (ファイル名の XX はプラットフォームのバージョン番号です)。

MDXXExp.epf- 処理により、情報ベース構造の説明を XML ファイルにアップロードできます。構造記述は、さらなる分析と交換ルールの作成のために CD にロードされます。
V8ExchanXX.epf- 交換ルールに従って情報ベースからデータをアップロード/ダウンロードします。ほとんどの一般的な構成では、処理はすぐに使用できるようになります (「サービス」メニュー項目を参照)。処理は普遍的であり、特定の構成/ルールに拘束されません。

さて、上記のすべてに基づいて、新しい変換を開発する段階を定義しましょう。

タスクの定義。どのデータを (どの構成オブジェクトから) 転送する必要があるのか、そして最も重要なことに、それをどこに転送するのかを明確に理解する必要があります。
後で CD にロードするための構成構造 (ソース/シンク) の記述を準備します。この問題は、MDXXExp.epf を処理するサービスによって解決されます。
準備された構造の記述を情報セキュリティにロードします。
ビジュアル CD ツールを使用して交換ルールを作成します。
V8ExchanXX.epf処理を使用して、作成したデータ変換ルールに従ってアップロード/ダウンロードを行います。
交換ルールをデバッグします (必要な場合)。

最も単純な変換

デモンストレーションには、2 つの展開された構成が必要です。私は、「Trade Management」第 10 版と小規模な自作ソリューションというオプションを選択することにしました。タスクは、標準の「UT」構成からデータを転送することです。簡潔にするために、自分で作成したソリューションを「シンク」、取引管理を「ソース」と呼びます。「Nomenclature」ディレクトリから要素を転送して、問題の解決を始めましょう。

まず最初に、データ変換スキームを見て、実行する必要があるアクションのリストをもう一度読んでみましょう。次に、「ソース」構成を起動し、その中で MD82Exp.epf サービス処理を開きます。

処理インターフェイスには豊富な設定はありません。ユーザーは、構造の説明に含まれないメタデータオブジェクトのタイプを指定するだけで済みます。ほとんどの場合、これらの設定を変更する必要はありません。（例として）蓄積レジスタを使用したアンロード動作には特に意味はありません。

レシーバーに書類を保持しながら動きを形成する方が正確です。すべての移動は、転送後にドキュメント自体によって行われます。デフォルト設定を擁護する 2 番目の議論は、アップロードによるファイルサイズの削減です。

一部のドキュメント (特に標準構成) では、複数のレジスタにわたる動きが生成されます。これらすべてをアンロードすると、結果の XML ファイルが大きくなりすぎます。これにより、その後の輸送および受信機ベースへの積み込みが複雑になる可能性があります。データファイルが大きくなるほど、その処理に必要な RAM が増加します。練習中に、非常に大きなアップロードファイルに遭遇する機会がありました。このようなファイルは、標準ツールを使用して解析することを完全に拒否しました。

したがって、すべてのデフォルト設定をそのままにして、構成の説明をファイルにアップロードします。 2 番目のベースについても同様の手順を繰り返します。

CD を開き、メインメニューで選択します。 「ディレクトリ」→「構成」。このディレクトリには、変換の作成に使用できるすべての構成の構造の説明が保存されます。構成の説明を一度ロードすると、それを複数回使用してさまざまな変換を作成できます。

ディレクトリウィンドウで、「」ボタンをクリックします。追加」をクリックし、表示されるウィンドウで、構成を説明するファイルを選択します。「新しい構成にロードする」チェックボックスをチェックし、「ロード」ボタンをクリックします。 2 番目の構成の構造の説明と同様のアクションを実行します。

これで、交換ルールを作成する準備ができました。メイン CD メニューで、「ディレクトリ」→「変換」を選択します。新しい要素を追加します。新しい変換を作成するウィンドウでは、ソース構成 (UT を選択) と宛先構成 (「受信者」を選択) を指定する必要があります。次に、「詳細」タブを開き、次のフィールドに入力します。

交換ルールファイル名 - 作成された交換ルールはこの名前で保存されます。ファイル名はいつでも変更できますが、今すぐ設定することをお勧めします。これにより、将来的に時間を節約できます。デモ例のルールに「rules-ut-to-priemnik.xml」という名前を付けました。
name - 変換の名前。名前は何でも構いませんが、私は「Demo.」に限定しました。 UTから受信機へ。」

以上です。「OK」をクリックします。すぐにウィンドウが目の前に表示され、すべてのルールを自動的に作成するように求められます。このような魅力的なオファーに同意すると、マスターは、選択された構成の説明を自動的に分析し、交換ルールを独自に生成するコマンドが与えられます。

早速「i」に点を打ってみましょう。ウィザードは重大なものを生成できません。ただし、この可能性を無視すべきではありません。同一の構成間で交換を確立する必要がある場合、専門家のサービスが非常に役立ちます。この例では、手動モードが推奨されます。

「Exchange ルールの設定」ウィンドウを詳しく見てみましょう。インターフェイスは少しわかりにくいように思えるかもしれません。多数のタブにコントロールが詰め込まれています。実際、すべてはそれほど難しいことではありません。アプリケーションを数時間操作していると、この狂気にも慣れ始めます。

この段階では、「オブジェクト変換ルール」と「データアップロードルール」という 2 つのタブに注目します。まず、一致ルールを設定する必要があります。 2 つの構成のオブジェクトを比較します。 2 番目のステップでは、ユーザーがアップロードできるオブジェクトを決定します。

「オブジェクト変換ルール」タブの後半には、「プロパティ変換」と「 値の変換」 1 つ目は選択したオブジェクトのプロパティ (詳細) を選択し、2 つ目は事前定義された値 (たとえば、事前定義されたディレクトリ要素や列挙要素) を操作するために必要です。

わかりました。ディレクトリの変換ルールを作成しましょう。この操作は 2 つの方法で実行できます。オブジェクト同期ウィザード (「」ボタン) を使用するか、各オブジェクトの対応を手動で追加します。

スペースを節約するために、最初のオプションを使用します。ウィザードウィンドウで、グループ「」のチェックを外します。 ドキュメンテーション(ディレクトリのみに興味があります) グループを拡張します。 ディレクトリ」リストを注意深くスクロールして、比較できる参考書の名前を確認します。

私の場合、そのようなディレクトリは、Nomenclature、Organizations、Warehouses の 3 つです。 Clients というディレクトリもあります。これは「」と同じ目的を果たします。 取引相手「構成から」 ユタ州」確かに、マスターは名前が異なるため、それらを比較することができませんでした。

この問題は自分たちで解決できます。窓の中に見つけました。」 オブジェクトの一致" 参考書 " クライアント」を選択し、「ソース」列で「Counterparty」ディレクトリを選択します。次に、「タイプ」列のチェックボックスをオンにして「OK」ボタンをクリックします。

オブジェクト同期ウィザードは、選択したすべてのオブジェクトのプロパティを変換するためのルールを自動的に作成することを提案します。プロパティは名前で比較されますが、デモンストレーションにはこれで十分であることに私たちは同意します。次の質問は、アップロードルールの作成についての提案です。私たちもそれに同意しましょう。

交換ルールの基礎が完成しました。同期するオブジェクトを選択し、プロパティの変換ルールとアップロードルールが自動的に作成されました。交換ルールをファイルに保存してから、IB「ソース」(私の場合はUT)を開いて、その中でサービス処理を起動しましょう V8Exchan82.epf.

まず、処理ウィンドウで、作成した交換ルールを選択します。読み込みルールに関する質問には肯定的に答えます。処理では、交換ルールを分析し、アップロード可能な同じ名前のオブジェクトのツリーを構築します。このツリーでは、データを選択するために必要なノードを変更することで、あらゆる種類の選択をセットアップしたり、ノードを交換したりできます。完全にすべてのデータをダウンロードしたいので、フィルターをインストールする必要はありません。

データをファイルにアップロードするプロセスが完了したら、「IB」に進みます。 受信機」その中でオープン加工も行っております V8Exchan82.epf, 今回のみ「データ読み込み」タブに移動します。データファイルを選択し、「ダウンロード」ボタンをクリックしてください。以上で、データは正常に転送されました。

現実世界の問題

最初のデモは誤解を招く可能性があります。すべてが非常にシンプルかつ論理的に見えます。実はこれは真実ではありません。実際の仕事では、視覚的な手段だけを使って（プログラミングなしで）解決するのが難しい、またはまったく不可能な問題が発生します。

テクノロジーにがっかりしないように、実際の問題をいくつか用意しました。職場で必ず遭遇するでしょう。これらはそれほど単純なものではなく、データ変換を新しい角度から見ることができます。提示された例を注意深く検討し、実際の問題を解決する際のスニペットとして自由に使用してください。

タスクその1。不足している詳細を入力してください

ディレクトリを転送する必要があるとします。 取引相手」受信機には、この目的のために同様の「Clients」ディレクトリがあります。データストレージには完全に適していますが、小道具もあります。組織」というもので、組織に所属することで取引相手を分けることができます。デフォルトでは、すべての取引相手は現在の組織に属している必要があります (これは同じ名前の定数から取得できます)。

この問題にはいくつかの解決策があります。詳細を記入するオプションを検討します。」組織「データベースに直接」 受信機”、つまりデータロード時。現在の組織は定数に保存されるため、この値を取得するのに障害はありません。物体変換ルール（以下、PKO）を開こう』 クライアント」 (オブジェクトをダブルクリック) し、ルールセットアップウィザードの [イベントハンドラー] セクションに移動します。ハンドラーのリストには「 ダウンロード後”.

現在の組織を取得し、詳細に割り当てるコードを記述します。「ロード後」ハンドラーがトリガーされた時点では、オブジェクトは完全に形成されていますが、まだデータベースには書き込まれていません。私たちの裁量でそれを変更することを誰も禁じていません。

Object.ThisGroup ではない場合、Object.Organization = Constants.CurrentOrganization.Get(); endIf;

詳細を入力する前に」組織「属性の値を確認する必要があります」 このグループ」参考書については「 クライアント『階層機能が設定されているため、グループの確認が必要です。同様の方法で詳細を入力します。他のハンドラーオプションについてはヘルプを必ずお読みください。 ロード後」たとえば、その中に「」というパラメータがあります。拒否」値「True」を割り当てると、オブジェクトはデータベースに書き込まれません。これにより、ロード時に書き込めるオブジェクトを制限することが可能となる。

タスクその2。情報登録の詳細

ディレクトリ内に「 取引相手「UT 構成、詳細が入手可能」 買い手" そして " プロバイダー」どちらの詳細もタイプ「 ブール値」と取引相手の種類を決定するために使用されます。 IBでは「 受信機「」ディレクトリにある「 クライアント「同様の詳細はありませんが、情報の記録はあります。」 クライアントの種類」これは同様の機能を実行し、1 つのクライアントに対して複数の属性を保存できます。私たちの仕事は、詳細の値を情報レジスタの個別のエントリに転送することです。

残念ながら、ここでも視覚的な手段だけでは対処できません。小さなことから始めましょう、情報記録用の新しいソフトウェアを作成しましょう」 クライアントの種類」出典として何も引用しないでください。アップロードルールを自動的に作成しないようにします。

次のステップでは、アップロードルールを作成します。適切なタブに移動し、「」をクリックします。追加」アップロードルールを追加するウィンドウで、次のように入力します。

サンプリング方法。「任意のアルゴリズム」に変更します。
変換ルール。情報登録「クライアントの種類」を選択します。
ルールのコード（名前）。これを「クライアントタイプのアンロード」として書き留めます。

次に、アップロードするデータを選択するコードを記述する必要があります。パラメータ「 データサンプリング」準備されたデータセットを含むコレクションを配置できます。パラメータ「 データサンプリング」は、クエリ結果、選択、値のコレクションなど、さまざまな値を取ることができます。これを、クライアントとクライアントタイプの 2 つの列を持つ値のテーブルとして初期化します。

以下はイベントハンドラーのコードです。 加工前」パラメータを初期化します。 データサンプリング” に続いてディレクトリからデータを入力します” 取引相手」ここで、「」欄の記入に注意する必要があります。 クライアントの種類」「UT」では、属性は「ブール」タイプであり、受信者は列挙型です。

この段階では、それらを必要な型に変換できない (UT にない) ため、今のところは文字列の形式のままにしておきます。これを行う必要はありませんが、ソース内の欠落している型にキャストする方法をすぐに示したいと思います。

DataFetch = 新しい ValueTable(); DataSelection.Columns.Add("クライアント"); DataSelection.Columns.Add("ClientType"); SelectingDataFromDirectory = Directorys.Accounts.Select(); While SelectingDataFromDirectory.Next() ループ If SelectingDataFromDirectory.ThisGroup then Continue; endIf; Directory.Buyer からのデータ選択の場合、NewRow = Data Selection.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewRow.ClientType = "顧客"; endIf; DataFetchFromDirectory.Supplier の場合、NewRow = DataFetch.Add(); NewRow.Client = DataFetchFromDirectory.Link; NewString.ClientType = "サプライヤー"; endIf; エンドサイクル;

データアップロードルールを保存して「」タブに戻りましょう オブジェクト変換ルール」情報登録に追加しましょう」 クライアントの種類」プロパティ変換ルール: クライアントとクライアントタイプ。ソースを空のままにして、「アンロード前」イベントハンドラーに次のように記述します。

//「クライアント」プロパティの場合、Value = Source.Client; //プロパティ「ClientType」の場合 If Source.Client = "Buyer" then Expression = "Enumerations.ClientTypes.Buyer" ElseIf Source.Client = "Supplier" then Expression = "Enumerations.ClientTypes.Supplier"; endIf;

リストでは、選択したデータサンプルに基づいて詳細が入力されます。クライアントをリンクとして渡し、パラメータにクライアントのタイプを書き込むだけです。表現」このパラメータのデータは受信側で解釈され、実行されると、プロパティには列挙型からの正しい値が入力されます。

以上で、交換ルールの準備が整いました。検討した例は非常に普遍的なものであることがわかりました。 7.7 プラットフォームで作成された構成からデータを移行する場合にも、同様のアプローチがよく使用されます。この顕著な例は、定期的な詳細の転送です。

タスクその3。テーブルパーツを使ったトリック

1 つのテーブルセクションから複数のテーブルセクションに行を転記する必要があるタスクに遭遇することがよくあります。たとえば、初期構成ではサービスと商品が 1 つの表形式の部品に登録され、受信側ではこれらの実体のストレージが分離されます。繰り返しますが、この問題は視覚的な手段では解決できません。ここで、2 番目の問題の解決策を基礎として利用すると便利です。

データをアンロードするためのルールを作成し、任意のアルゴリズムを指定し、「アンロード前」ハンドラに表形式部分からデータを取得するリクエストを記述します。

スペースを節約するために、リクエストのコードは提供しません (いつでもソースを参照できます)。これには何も異常はありません。結果の選択結果を並べ替えて、並べ替えた結果をすでにおなじみのパラメーターに配置します。 データサンプリング」値のテーブルをコレクションとして使用すると、やはり便利です。

DataFetch = 新しい ValueTable(); //ここに別のテーブル部分があります Data Selection.Columns.Add(“Products”); //ここには表形式の部分もあります Data Selection.Columns.Add(“Services”); SelectionData.Columns.Add(“リンク”);

タスクその4。オペレーションへのデータの転送

組織が複数の会計システムを使用している場合、遅かれ早かれ、その後の世代のトランザクションでデータを移行する必要が生じます。

設定では「血圧「普遍的な文書がある」手術」とより多くの配線を形成するのに最適です。問題が 1 つだけあります。この文書は巧妙に作成されており、データはそう簡単には転送できません。

このような変換の例は、この記事のソースコードにあります。コードの量がかなり多くなったので、記事と合わせて公開する意味がありません。もう一度言っておきますが、再アップロードでは、データのアップロードのルールにある任意のアルゴリズムが使用されます。

タスクNo.5。複数の詳細にわたるデータの同期

すでにいくつかの例を見てきましたが、移行中のオブジェクトの同期についてはまだ説明していません。取引相手を転送する必要があり、その一部がおそらく受信者のデータベースにあると想像してみましょう。データを移行して重複が発生しないようにするにはどうすればよいですか? この点に関して、CD は、転送されたオブジェクトを同期するいくつかの方法を提供します。

1 つ目は一意の識別子によるものです。多くのオブジェクトには、テーブル内での一意性を保証する一意の識別子があります。たとえば、ディレクトリ「 取引相手同じ識別子を持つ 2 つの要素は存在できません。 CD はこれに対して計算を行い、作成されたすべての PCO に対して、識別子による検索がデフォルトですぐに有効になります。 PCO の作成中に、オブジェクト名の横にある虫眼鏡の画像に注意を払う必要がありました。

一意の識別子を使用した同期は信頼できる方法ですが、常に適切であるとは限りません。ディレクトリを結合するとき」 取引相手（いくつかの異なるシステムから）それはあまり役に立ちません。

このような場合、いくつかの基準に従ってオブジェクトを同期する方がより正確です。 INN、KPP、名前で取引相手を検索するか、検索を複数の段階に分割する方が正確です。

データ変換は、開発者による検索基準の定義を制限しません。抽象的な例を見てみましょう。ディレクトリを同期する必要があるとします。 取引相手」をさまざまな情報ベースから入手します。 PKO を準備し、オブジェクト変換ルールの設定で「 受信側オブジェクトが識別子で見つからない場合は、検索フィールドの検索を続行します」このアクションにより、一意の識別子とカスタムフィールドによる 2 つの検索基準がすぐに定義されました。

私たちには自分たちで分野を選ぶ権利があります。 TIN、KPP、および名前をチェックすると、すぐにいくつかの検索基準が示されます。快適？かなりですが、これでも十分ではありません。検索条件を変更したい場合はどうすればよいでしょうか? たとえば、最初に TIN+KPP の組み合わせを検索し、何も見つからない場合は、その名前で運試しを始めます。

このようなアルゴリズムは十分に実装可能です。イベントハンドラ内で「 検索フィールド最大 10 個の検索条件を指定し、それぞれに対して独自の検索フィールドの構成を定義できます。

SearchOptionNumber = 1 の場合、SearchPropertyNameString = “TIN, KPP”; それ以外の場合、SearchOptionNumber = 2 thenSearchPropertyNameString = “名前”; endIf;

解決策は常に複数あります

どのタスクにも複数の解決策があり、異なる構成間でのデータ転送も例外ではありません。各開発者には独自のソリューションパスを選択する権利がありますが、複雑なデータ移行を常に開発する必要がある場合は、「」に注意することを強くお勧めします。最初はトレーニングにリソース (時間) を投資する必要があるかもしれませんが、最初の多かれ少なかれ深刻なプロジェクトでは十分に報われます。

私の意見では、1C 社はデータ変換の使用に関する話題を不当に無視しています。このテクノロジーが存在していた間、このテクノロジーに関する本は 1 冊だけ出版されました。「1C: Enterprise 8. データ変換: アプリケーションソリューション間の交換」です。この本はかなり古いもの (2008 年) ですが、それでもよく理解しておくことをお勧めします。

プラットフォームに関する知識は依然として必要です

"は汎用ツールですが、これを使用して 1C:Enterprise 7.7 プラットフォーム用に開発された構成からデータ移行を作成する場合は、組み込み言語に慣れるまでに時間を費やす必要があります。この言語の構文とイデオロギーは大きく異なるため、学習には時間を費やす必要があります。それ以外の場合、原則は同じままです。

1. はじめに。

2. 必要なもの: 1C 構成: データ変換 2.* およびパッケージからの処理。タスクの例として、構成 1C: Trade Management 11 および 1C: BP 3.* を考えてみましょう。

したがって、1C にデータをアップロードするためのルールを開発するには、1C 構成: オブジェクト変換 2 と、パッケージに含まれる処理が必要になります。

たとえば、変換データベースはすでにデプロイされ、起動されています。

1C:Trade Management 11 構成と 1C:Enterprise Accounting 3 構成の間の交換ルール (UT / ACCOUNT 交換ルール) の開発を記述します。

3. メタデータ構造をアンロードして交換するための処理が必要になります。

開発のために最初に取得する必要があるのは、メタデータ構造を持つファイルです。これは、オブジェクト変換パッケージに含まれるメタデータ構造をアンロードする処理を使用して行われます。

実際には、管理フォーム上の構成用の解凍された構成ディレクトリ内で、MD83Exp.epf の処理に関心があります。通常のフォームの構成からアンロードを行う必要がある場合は、MD82Exp.epf 処理が使用されます。これは、たとえば、1C: UT 10、1C: Manufacturing Enterprise Management 1.3、1C: Integrated Automation 1.1、1C: Zup 2.5 などの構成から構造を取得する必要がある場合です。

さらに、当社のルールを使用して 1C にデータをアップロードおよびダウンロードするには、1C: Trade Management 11.*、1C BP 3、1C: などの管理フォームの構成に対して「XML 形式のユニバーサルデータ交換」V8Exchan83.epf を処理する必要があります。 ERP 2. * および同様のもの。それに応じて、V8Exchan83.epf - 通常のフォームの構成用。

4. 構成 1C: Trade Management 11.3 および 1C: Enterprise Accounting 3.0.* のメタデータ構造のアップロード

まず、1C: Enterprise Accounting 3 構成からメタデータ構造をダウンロードします。
処理中のMD83Exp.epfを開いてみましょう

処理フォームには、レジスターと動きを 1C にアップロードするオプションを有効または無効にできる追加の設定があります。アップロードをどこで行うか、1C サーバー上か「クライアント上」かの選択もあります。データ構造をアップロードするファイルの名前を指定します。同様の方法で、Trade Management 11 構成のメタデータ構造をアンロードします。

次に、構成を変換データベースにアップロードする必要があります。この点には、構成のリストと変換のリストの両方から到達できます。デスクトップから起動してみましょう。

ダイアログボックスで、BP 構造体をロードします。

そして同様に、貿易管理の構造も同様です。

ダウンロードが完了すると、ダイアログボックスが表示され、任意の名前を指定できます。

6. タスクの具体例を使用して、1C で変換ルールを作成します。

次に、「オブジェクトルールの設定」に進み、新しい設定を作成します。
変換作成ダイアログボックスで、(以前にロードした)「ソース」構成と「宛先」構成を選択し、「OK」をクリックします。

この記事では「ゼロから」「ゴミなしで」作成することを計画したので、自動的に何かを作成するわけではないことを思い出してください。プロトタイプはありません。

このダイアログボックスでは何もせず、「閉じる」をクリックするだけです。

1 つのドキュメントを 1 つのドキュメントにアップロードするのではなく、1 つのタイプを別のドキュメントにアップロードするルールを作成しましょう。たとえば、UT 11 の「商品およびサービスの販売」ドキュメントを、必要な参考書とともに BP 3 の「商品およびサービスの受領」というドキュメントにアップロードします。

そこで、新しい PKO (1C でオブジェクトを変換するためのルール) を作成します。

ソースの「商品およびサービスの販売」と宛先の「商品およびサービスの受領」を選択し、「OK」をクリックします。
この場合、ダイアログボックスが表示され、PKS (プロパティ変換ルール) の自動作成を再度拒否します。次に必要なものだけを選択していきます。

しかし、DVP (データアップロードルール) を作成するという提案には、「はい」と答えます。

PVD が作成され、選択のためのユニバーサル XML 交換の処理に反映されます。

空のプロパティ変換ルールを含むデータ変換ルールも作成されます。

さらに、デフォルトでは、内部オブジェクト識別子によってソフトウェアを検索することが提案されていることは明らかです。これは、PCO の近くにある虫眼鏡で示されます。私たちは独自の検索を行い、その日の初めに文書番号と日付によって検索します。

UIO による検索を削除します。

次に、オブジェクトの必要なプロパティ (詳細) の比較を開始しましょう。これを行うには、「プロパティの同期」(画面上のラベル「1」)をクリックします。ルールの再帰的な作成を削除します (「2」)。マークされた詳細 (「3」) をすべて削除します。そして、必要なものを自分たちで選択していきます。

たとえば、必要なものを選択します。

カウンターパーティの PKS を組織にし、組織をカウンターパーティにし、名前が一致しないいくつかの詳細 (たとえば、「通貨」と「文書」) も比較することに注意してください。通貨"。

変換ルールがまだ存在しないことがわかります。

詳細を見て説明していきましょう。まずは先ほど書いたように文書検索を設定し、日付の先頭で文書をアップロードして検索し、番号付けを変更します。最初の 3 文字を接頭辞「UTB」に置き換えます。また、BP と UT の番号付けはそれぞれ 11 文字であるため、プレフィックスとソースからの 8 文字の合成番号を作成します。以下のスクリーンショットの例。

私たちは常に書類を降ろしたまま、動かさずにアップロードします。文書はユーザーによる確認後に受信機で処理されることを想定しています。

これを行うには、PKS を実行されないように設定し、0 または 1 をブール値として使用します。

例として通貨を使用して、PKS のオブジェクト変換ルールを作成します。同時に、両方のデータベースに通貨が存在し、コードによって同期される必要があると考えられます。したがって、通貨 PQS にすべての PKS を作成するのではなく、検索コードのみを追加します。それらの。オブジェクトの PKS を作成するという申し出は拒否します。

作成した変換ルールをドキュメントのPQRにPKSに置き換えます。また、デフォルトルール自体は一意の識別子によって提供されます。それを修正し、コードを検索し、新しいオブジェクトを作成しないようにプロパティを設定します。

結果として、次のオプションが得られます。

次に、類推により、残りの詳細について PKO と PKS を作成します。さらに、取引相手ごとに組織を検索したり、その逆に TIN ごとに組織を検索したりします。これは、最小限の詳細を含めたおおよその外観です (必要に応じて追加できます)。

PCO カウンターパーティ契約の場合、PKS カウンターパーティ、名前、所有者で検索します。

PKS の列挙型に必要な値を指定する方法を見てみましょう。たとえば、「操作の種類」属性です。ここでは、さまざまな条件を使用したり、値を代入したりできます。たとえば、「操作の種類」は常に「商品」をアンロードする必要があります。この場合、「額」行に必要な値を書き込むだけで十分です。

以下に、相互決済多重度、相互決済率、会計口座用の PCS を簡単にインストールする方法を示します。

PKO Nomenklatura については、内部の一意の識別子による検索を残します。ただし、自分のグループをどのように再定義できるかに注目してもらいたいと思います。たとえば、新しいアイテムが 1C: Trade Management 11 構成からアップロードされることに同意しますが、そのアイテムは特定のグループ「OurGroup」に収集される必要があります。

このタスクを実行するために、別の PKO を作成します。これを「NomenclatureParent」と呼び、変換ルールの親の PCS で指定します。

2 つの検索を設定します。名前による検索では、グループの名前を厳密に指定し、「This is a Group」属性の必須プロパティを true に設定します。

すべての項目がグループに分類されると判断したため、アンロード時に UT 11 からグループをアンロードする必要はありません。これを行うには、「アンロード前」イベントハンドラーの命名法ソフトウェアで、次のようなフィルターを設定します。グループ「失敗 = ソース。このグループ;」をアンロードする必要はありません。

製品およびサービスの販売に関する DRP (データアップロードルール) に、削除マークが付けられたドキュメントがアップロードされないようにフィルターを追加します。これを行うには、VDP の「Before Unloading」イベントハンドラーにフィルター「Failure = Object.DeletionMark;」を記述します。

作成したルールをファイルに保存しましょう。

7. 要約すると、開発されたデータ交換ルールを使用してデータをアップロードおよびロードします。

1C: Trade Management 11 で処理「XML 形式のユニバーサルデータ交換」V8Exchan83.epf を開きます。

アンロードが完了したので、同じ処理を使用して 1C: Enterprise Accounting 3 にロードします。

読み込みが完了しました。どのようにロードされたかを確認してみましょう。したがって、希望どおりにドキュメントがロードされます。私たちの組織が取引相手にロードされ、取引相手が組織にロードされます。会計アカウントはすべてダウンロードされ、インストールされます。その日の初めに、プレフィックスが付いた文書番号を取得しました。提供されたすべての詳細が入力されました。

商品の積載状況を確認させていただきます。すべてが計画どおりに進んだことがわかります。

意図したとおりに詳細を作成して記入しました。変換には多くの微妙な点があり、変換を正確に記述するのに役立つ単純だが必要なことがいくつかあります。これにより、エラーを最小限に抑え、既存のデータを損なうことなく、不要なゴミを取り除くことができます。これは最も単純な例の 1 つです。 1 つのオブジェクトを複数に変換したり、逆に複数のオブジェクトを 1 つに変換したりすることもできます。

現在はデータ変換 3 があり、他の問題も解決されています。したがって、変換 2 も必要です。皆さんの学習と習得に幸運を祈ります。

もちろん、あなたがプログラマーで、それが主な仕事である場合は、自分で変換を作成してみることもできます。しかし、そうでない場合は、自分の活動分野での時間を大切にし、専門家にこの作業を依頼する必要があります。

新しいプラットフォームや 1C 構成がリリースされたからといって、長年の労力をかけて収集したデータや重要なドキュメントが失われることがあってはなりません。これを防ぐために、データを転送することができます。

データ転送は、ある構成から別の構成への移行において最も重要な部分の 1 つです。

データを安全に転送するには、この作業を専門家に委託する必要があります。私たちのチームはすべての作業を効率的かつ時間通りに完了します。

転送ステージ

データ転送は 5 つの段階で構成されます。私たちはそれらをできるだけ詳細かつ明確に説明するよう努めました。

データ転送が優れているのはなぜですか?

一般的なデータ転送コスト

新しいプログラムのメンテナンス

すべてのデータが転送された後、プログラムのメンテナンスが必要になる場合があります。ご提供させていただく準備ができております。

1C 8.2 への移行

あるプラットフォームから別のプラットフォームへの移行の他の段階について詳しく学習してください。ライセンスのアップグレード、構成、トレーニング、サポート。当社のスペシャリストが、必要なあらゆるサポートを提供いたします。

なぜ私たちのほうが優れているのでしょうか？

注文転送

私たちのチーム

なぜ 1C 転送が優れているのでしょうか?

透明性

1C 8.2 ディレクトリとその他のデータを転送する前に、当社のスペシャリストが作業のすべての段階について詳しく説明します。データベースを当社にお任せいただくことで、何が行われ、どのような順序で行われ、作業の各段階にいくら支払ったのかを常に知ることができます。

個別のアプローチ

1C 7.7 から 1C 8.2 への移行に直接進む前に、当社の専門家がデータベースの詳細な分析を実施します。 1C の新しいバージョンには、必要な改良点がすべてすでに含まれている可能性が高くなります。いずれにせよ、快適な作業のために他に必要なものをお勧めします。

品質

転送の最も重要な段階の前に、当社のスペシャリストは常に 1C データベースの試行転送を実行して、起こり得るエラー、繰り返し、データ損失を特定します。しかし、引き渡し後であっても、品質に対するさらなる自信を得るために、すべてを必ずチェックします。

結果を求めて働く

1C 8 ディレクトリおよびその他のデータの転送が正しく実行されたことを確認し、その結果に満足した場合にのみ、作業は完了したとみなされます。私たちはクライアントを見捨てません！

ステージ 1. ソースデータベースの一般的な分析

どのような作業が行われているか:

ソースデータベースと同様の標準構成バージョンを取得します。

データ構造の変化の一般的な分析 (典型的な構成との比較)。

フォームおよび構成モジュールの変更の一般的な分析 (標準構成との比較)。

会計構成における非標準の会計アカウントの可用性の制御。

ソースデータベース内の会計の正確性に対する一般的な制御（「赤」残高、オープン期間、復元されていないシーケンスなど）。

ソースデータベースを標準転送ルールで必要なバージョンに更新します。

トライアルデータ転送;

1C 8 ディレクトリおよびその他のデータの転送用にソースデータベースを準備するための可能な推奨事項の準備。

何のために：

標準転送を使用する可能性を判断する。

改造の労働強度の評価と移転のための技術文書の準備（標準的な移転を使用できない場合）。

ソースデータベースの一般的な分析を実行した後、標準の手段を使用してデータを転送できることが確認できます。この場合、転送サービスの追加コストは、構成に応じて標準の転送価格表に従って決定されます。

正しい標準転送が不可能な場合は、構成、交換ルール、および非標準転送を最終決定するための作業コストを考慮して提案書が作成されます。

価格：2,000ラブ。

ステージ 2. 非標準転送のための技術文書の準備

どのような作業が行われているか:

ソースベースの標準構成に対する既存の変更の詳細な分析が実行され、これらの変更をバージョンが類似した標準構成および受信ベースの標準構成の最新バージョンと比較します。

特定された変更の必要性を確立し、変更を使用する方法を明確にし、変更を改善するための要望を収集するための顧客の責任者とのコミュニケーション (必要な場合)。

ソースデータベースの標準構成に対して利用可能な変更のリストが作成されます。

標準構成の標準機能を考慮して、受信ベースの標準構成に対する推奨変更のリストが作成され、合意されます (おそらく、受信構成に同様の標準機能がすでにある場合、変更を転送する必要はありません)。 ;

受信基地の構成を最終決定し、交換ルールを最終決定するための技術仕様草案、説明
非標準の転送手順（必要な場合）。

何のために：

1C データベースの非標準転送に関する作業の品質と透明性の保証。

正確なコスト見積もりと作業期間。

必要な品質レベルを確保しながら、フルタイムの 1C プログラマーの関与を得て移行作業を実行できる能力。

指定された一連の技術文書が利用できない場合、1C 構成間の非標準転送は 1 時間ごとにのみ実行されます。この場合、作業の費用と期間を事前に正確に保証することは不可能です。ただし、この場合、一連の文書を準備するための時間とコストをいくらか節約することが可能です。

価格：ソースデータベースの総合的な分析結果に基づいて決定されます。

ステージ 3. 受信機構成の最終決定

どのような作業が行われているか:

受信機ベースの標準構成は、技術仕様に基づいて、または顧客の指示（時間単位の作業の場合）に従って変更されます。

改善の予備テストが実行されます。

改善点は、標準構成への変更に関するレポートの形式で文書化されます (サービスエンジニアによるさらなる更新の可能性のために)。

ユーザーに対する改善のデモンストレーションが実行されます（作業の引き継ぎと受け入れ）。

変更のためのユーザーマニュアルが作成中です (必要な場合)。

何のために：

必要な変更が加えられた最新バージョンの構成を受け取ります。

さらに必要な変更に関する文書を受け取ります。
サービスエンジニアによるアップデート。

ステージ 4. 転送ルールの最終決定

どのような作業が行われているか:

1C からの標準転送ルールは、ソースデータベースの標準構成のデータ構造の変更と、ソースデータベースで使用される非標準の会計アカウントを考慮して最終決定されています。

変更を考慮して、転送の予備テストが実行されます。

何のために：

標準の交換ルールでは転送されないデータの正しい転送を保証します。

ソース構成に変更が含まれていない場合でも、標準ソリューションの方法論の観点からソースデータベースでのアカウンティングが正しく実行されなかった場合にも、転送ルールの変更が必要になる場合があります。

価格: 一連の技術文書に基づいています。

ステージ 5. データ転送

どのような作業が行われているか:

参照情報の転送（すべてまたはリンクによる）、特定の日付への残高の転送。

転送の正確性の制御 - ソースデータベースと宛先データベースのデータの比較。

(必要に応じて) 異なる構成での会計の特殊性を考慮して、受信側データベースの残高を調整するための可能な推奨事項を準備します。

何のために：

現在の残高を含む、すぐに使用できる新しいデータベースを受け取ります。

転送は、1C が開発した転送ルールを使用して実行され、顧客向けに特別に変更が加えられます。転送されるデータの構成は、構成のバージョンによって異なる場合があります。当社の専門家が、考えられる可能性についてアドバイスします。
転送機能。

現在、1C:Enterprise 7.7 から 8.3 (8.2 と同様) への移行は会計士にとって頭の痛い問題となっています。できるだけ早く、エラーなく行うことができます。あなたが 1C:Accounting プログラマで、これらのドキュメントを第 7 バージョンから第 8 バージョンに変換する必要がある場合は、この記事が最適です。

ほんの数ステップを実行するだけで、データ転送の問題は解決されます。この説明を最後まで読めば、その方法がわかります。まず、必要な操作を行うためにコンピューター上に作業場所を準備する必要があります。まず、ハードドライブは少なくとも 100 GB 必要です。残高の転送はマルチレベルであるため、これが必要です。また、いくつかの 7.7 構成を操作する必要があります。

1C Accounting 7.7 から 1C 8.3 への迅速かつ高品質な移行が必要な場合は、お問い合わせください。当社の平均ターンキーコストは 6,600 ルーブルです。

1C 7.7 から 1C 8.3 アカウンティング 3.0 へのデータの転送

したがって、バージョン 1C 8.3 へのデータの転送を行う前に、このデータをバージョン 7.7 で準備する必要があります。これを行うには、次のことを行う必要があります。コンピュータ上に「Accounting for an Enterprise」という実用的なデータベースがあり、会計士がそれを使用しているとします。 Export77 処理を使用して、必要なすべてのドキュメントをテキストファイルにアップロードすると、その瞬間からメインの作業データベースに戻る必要がなくなります。他の構成ではさらに操作が行われます。

最新のリリース 1C:Enterprise 7.7 を新しいディレクトリにインストールします。 (パッケージには、標準の空のバージョン (データなし) とデモバージョンが含まれています)。標準バージョンで作業します。次に、このデータベースを実行し、インポート 77 処理を使用して、メインデータベースからテキストファイルからデータをロードします。

データ変換の際、一部のドキュメントが処理できない場合があります。怖くないよ。標準データベースではメインの標準勘定科目表を使用するため、転送後にこれを簡単に修正できるのがポイントです。したがって、サブアカウントがどれほど高度であっても、転記されていない各ドキュメントにアクセスし、アカウントフィールドの設定にあるアカウントを変更することで、作業データベース内のこの問題を約 3 時間で簡単に修正できます。

当然のことながら、移管する前に、まず標準構成の勘定科目表を主な作業拠点の勘定科目表と一致させます。オプションは、組織の詳細に応じてまったく個別に異なります。この作業を完了すると、作業データベースからのデータが詰め込まれた標準構成を受け取ります。

次に、別のデータ転送を行う必要があります。これを行うには、標準のゼロ構成を新しいディレクトリに再度インストールします。そして、標準構成からデータをそこに転送すると、バージョン 8.2 に転送できる理想的なバージョン 7 データベースが得られます。

実際のところ、データは「手つかずの」標準バージョン 7.7 からのみ、8 番目のバージョンに直接転送されます。これで、そのような構成が完成しました。しかし、今は空ではなく、仕事用データが入っています。

全て！ 1C:Enterprise 8.2 をリリースします。「バージョン7.7からのデータ引き継ぎ」を選択します。プログラム自体が処理済みの 7.7 からデータを転送し、文書を転送し、バージョン 7.7 と 8.3 の貸借対照表の比較表を表示する方法をお楽しみください。

もちろん、100％の結果は得られません。ただし、70 ～ 80% で一致します。そうすれば、あなたの作業はバージョン 8.3 でのみ実行されます。

考えられる不正確さは簡単に修正できます。あと3～4時間です。文書仕訳帳に移動し、勘定科目またはフィールド (「契約書」または「メインレジ」など) を調整します。それはあなたの7.7ベースの差の程度によって異なります。スタンダードから。これらすべてのアクションの結果、バージョン 8.3 の作業構成では、貸借対照表を通じて理想的な形式の会計データを生成できるようになります。

移行後は、新しいプログラムでの作業方法を学ぶのに役立ちます。この目的のために、トレーニング 1C 会計 8.3 セクションを用意しました。

ところで！ 1C プログラムの変更が必要な場合は、お問い合わせください。

1C 7.7 データベースを 8.3 に転送するにはどうすればよいですか?

多くの標準 (および一部の業界固有) 8 コアソリューションには、7.7 からの組み込み転送ツール、またはテンプレートインストールディレクトリ内の追加ファイルの形式がすでに組み込まれています。

自分で転送する場合は、ITS ディスク (インターネット上の多くの場所と同様に、Google がサポートします) 上に「スプレッドシートドキュメントからの読み込み」処理があり、これにより、任意の表形式のデータをディレクトリ/ドキュメントに読み込むことができます。 /レジスタ。十分に高いレベルの資格があれば、特別な構成である「データ変換2」（3と混同しないでください）である戦闘砲を使用することができます。

このエラーが発生する理由を教えていただけますか? 1C のドキュメントでは、すべてが混乱しすぎて書かれています。結局のところ、給料を受け取らなければならないので、彼らの原稿を理解することはまったく不可能であり、戦争と平和は、複雑とは程遠いシステムの操作に関するチュートリアルよりも簡単です。

マキシム・クラフチェンコ、まあ、すべてロシア語で書かれています:)

私の経験では、最も一般的な理由は次のとおりです。

1) 7.7 との Exchange 設定で間違ったパスが指定されています。単にタイプミスがあるか、間違ったディレクトリへのパスが指定されています。または、コンピュータ上のローカルパスが指定されていますが、交換はエンタープライズ 1C サーバー側で行われ、当然このサーバーはパスに沿ったものを認識しません (よくある問題)。
2) 7.7 と通信しようとしているコンピュータ側 (ローカルまたはサーバー) には、7.7 プラットフォームが完全にインストールされていません。それらの。登録された COM オブジェクトはなく、7.7 ベースは従来、キーやシステムデータを必要としないハッキングされたプラットフォームのディレクトリを使用して接続されていました。
3) 7.7 ベースのディレクトリにはアクセス権がありません (rphost ワーカープロセスがサービスユーザーの下で実行され、7.7 ベースディレクトリが特定のユーザーに公開されているサーバー上で作業する場合に特に重要です)。

マキシム・クラフチェンコ、なぜIRCや人々の「クソ小さな通り」でのチャットを介さないのですか？ 🙂
いいえ、もう同じ熊手は踏みません。私はすでに恩知らずの人にSkypeを渡しましたが、彼は首をかしげました。

一般的な質問があり、その回答が他の人に役立つ可能性がある場合は、尋ねてください。一緒に良い行いをしましょう。秘密交渉はありません。

追伸人々がこのリソースについて回答したいという意欲を失わないように、たとえ直接役に立たなかったとしても、解決策をマークしたり、最も適切な回答に「いいね」ボタンをクリックしたりするとよいでしょう。

Maxim Kravchenko、純粋な 7.7 は自然界に存在しないため、FAQ は不可能です。標準/業界ソリューションのパレット全体があり、同じ特定の構成のさまざまなバージョンがありますが、このセットのどれもすぐに企業のニーズをカバーするものではなく、販売されたすべての 7.7 はインストール後何年もかけて完成しました。 7.7 の大量販売が 10 年以上前に終了したという事実を考慮すると、特定のデータベースには標準機能が何も残っていない可能性があります。

私の回答で書いた標準的な転送メカニズムを採用し、間違いの責任はあなたにあり、「女の子」を修正するために導入したすべての矛盾はあなたにあることを理解して転送するのと、それは別のことです。お金を払って専門家を雇うことはまったく別のことです。転送するすべての参考書籍、転送する情報の量 (記事、バーコード、TIN など)、不足している情報の入手先などを説明する必要があります。今はあなたのプロジェクトを引き受ける準備ができていません。このタスクをフリーランサーサイトに登録し、フリーランサーサイト間で入札を行うことをお勧めします。

転送ルール 1 秒 8

プログラム「1C: Accounting 8 rev.2.0」から「1C: Accounting 8 rev.3.0」へのデータの移行

主に変更された構成用に設計されています 1C:Accounting 8 エディション 2.0(インターネット上の可能性のある名前 BP 2.0 または BP 8.2) を、構成に転送するための独自のルールを開発するための基礎として使用します。 1C: Accounting 8 エディション 3.0(インターネット上の名前は BP 3.0 または BP 8.3)、もちろん、標準構成間でのデータ転送にも適しています。

エディション 2.0 から 3.0 に移行するための可能な戦略は、ここで見つけることができます。

からの移行 1C:Accounting 8 エディション 2.0の上 1C: Accounting 8 エディション 3.0前期間の定型業務終了後、新たな期間（年、四半期、月）の開始時に行うことをお勧めします。

データ転送は情報ベースからデータをダウンロードするユニバーサル処理により行われます。 1C:Accounting 8 エディション 2.0 XML 形式のファイルに変換します。結果のファイルは情報データベースにアップロードされます 1C: Accounting 8 エディション 3.0ユニバーサルデータロード処理を使用します。

データを転送するには次のファイルが必要です。

ACC20_30.xml - データ変換ルール。

情報ベースより BP2.0 V BP3.0転送されました:

情報ベース「1C: Accounting 8 rev. 2.0」の会計口座の当座預金残高情報（情報ベース変換日時点）

情報ベースのドキュメント BP2.0選択した期間

情報ベース「1C: Accounting 8 edition 2.0」から必要な参考情報

— 1C 情報ベースからのデータ 血圧8.2別のファイル (データファイル) にアップロードされます。

— 結果のファイルは 1C 情報データベースにアップロードされます 血圧8.3.

標準構成に組み込まれた処理を使用するため、インストールは不要です。 1C:Accounting 8 エディション 2.0そして 1C: Accounting 8 エディション 3.0.

(特殊な処理を使用する可能性については以下をお読みください)

番組内で 1C:Accounting 8 エディション 2.0処理を開く必要があります (メニュー: サービス — その他のデータ交換)、転送ルールが保存されているフォルダーを選択し (図 1 を参照)、交換ルールをダウンロードします。交換ルールは、処理開始時に自動的にロードされる場合でも、毎回強制的にロードすることをお勧めします。これを行うには、ルールファイルを再選択するか、ボタンをクリックする必要があります。 交換ルールをもう一度読んでください。すべての転送ルールを含める必要はありません。残高や書類の転送に必要なもののみを使用してください。すべての参考書籍は、必要に応じてリンクを介して転送されます。残高と書類に関係する人のみ。これにより、新しい情報ベースに「ゴミ」が存在しないことが保証されます。

年末、たとえば 2014 年 12 月 31 日の終わりに残高をアンロードする必要がある場合、つまり 2015 年の初めと言った方が正確です。その場合、荷降ろし期間は 01/01/2015 - XX.XX.XXXX となります。残高を記入するための書類 BP3.0日付は 2014 年 12 月 31 日になります。 2015 年 1 月 1 日から BP3.0現在の取引を反映する文書を作成する必要があります。残り物のみが必要な場合は、セクションからデータをダウンロードするためのルールを有効にする必要があります。 入金残高(図1を参照)。セクションからデータをダウンロードするためのルール ドキュメンテーションこの場合、無効にする必要があります (図 3 を参照)。たとえば、アップロード期間が 01/01/2015 ～ 01/31/2015 である場合は、2015 年 1 月のドキュメントが転送されることを意味します。セクションからデータをダウンロードするためのルール ドキュメンテーションこの場合は含める必要があります。

米。 1. データアップロードの処理

まず最初に、組織の会計ポリシー (ディレクトリ) を転送することをお勧めします。組織リンク経由で転送されます）。データ転送時にパラメータを追加設定することができます（図2を参照）。デフォルト値に戻すには、交換ルールを再ロードする必要があります。

図2 設定パラメータ

パラメータ VAT バッチ登録を無視するまず最初にそれが入力されるかどうかを決定します BP3.0残高を入力するとき在庫テーブル 受け取った請求書のデータ。サブコントの記入方法にも影響します パーティー：によるとブーまたはレジスターの残りの部分によって 購入した資産に対する VAT.

このパラメータを設定すると、組織の残高のアンロードを管理できるようになります。 簡易課税制度。会計実行時、登録データが一致しない場合 簡易課税制度に基づく経費会計レジスターにとっては、レジスターを考慮せずに、会計データのみに従って残高をアンロードする方が便利な場合があります。 簡易課税制度、多くのエラーが追加される可能性があります。この場合、初期残高を入力するための書類には、 BP3.0必要条件 簡易課税制度への反映そして フローステータスにはデフォルト値が入力されます。

パラメータを設定する場合はい文書と同時に、これらの文書に関連付けられた一連のレジスターも転送されます。それ以外の場合、文書の内容が転送され、移動を受信するには文書をデータベースに入力する必要があります。 BP3.0移転後。に存在するドキュメントのすべての移動が存在するわけではないことを理解する必要があります。 血圧8.3、に対応があります。 血圧8.2。したがって、移動を伴う伝票の転送オプションを選択した場合でも、伝票の種類によっては、必要な登録セットをすべて登録するために転記が必要になる場合があります。

図 3 BP 3.0 に転送されるドキュメントのリスト

転送する情報のディレクトリとレジスタのリストを図 4 に示します。このリストの拡張に興味がある人は、著者に連絡してください。多くのディレクトリのオブジェクトを転送するためのルールがあります。さまざまな参考書籍が多くの文書に存在し、したがってリンクを介してダウンロードされるため、これは当然のことです。これらからアンロードルールを作成するのは難しいことではなく、自分で行うことができます。リンクだけでなくディレクトリ全体を転送したい場合は、ディレクトリをアンロードするためのルールが必要です。

米。 4 移転情報のディレクトリおよびレジスターのリスト

アカウント 76.AB および 76.VA の残高を転送する機能

に設定するとはいパラメータ 取引相手との和解における誤った格付けを修正する会計上の間違いは修正することができます。リグレーディングとは何かは図 5.1 から明らかです。カウンターパーティの残高はゼロですが、2 番目のサブコントの金額はゼロではありません。残高は引き継がれません。

図5.1 残基での再グレーディング

に設定されている場合はいパラメータ メッセージの詳細、アップロード中に説明メッセージが表示されます (図 5.2 を参照)。

図 5.2 天びんの等級が間違っている場合のメッセージ

在庫口座の残高を転送する機能

残差のミスグレーディングなどのエラーを修正するアルゴリズムも同様に機能します。在庫。このアルゴリズムはパラメータを設定するときに機能します 在庫残高の誤った評価を修正する意味的にははい。例を図 5.3 に示します。アカウント 10.03 の会計処理は、品目、倉庫、およびバッチごとに実行されます。項目別の残り ガソリン AI-92の上 第4倉庫はゼロに相当しますが、残高をバッチごとに拡張すると、残高が大量に存在します。バッチごとの残高の代数的合計はゼロに等しく、これは再グレーディングです。これは明らかな間違いであるため、そのような残高は移すべきではありません。パラメータが設定されている場合は転送されません。

図 5.3 残基での再グレーディング在庫ソースデータベース内で BP2.0

バランスに関してはさらに悪いことに 第6倉庫。剰余はゼロではないため、ミスグレーディング修正アルゴリズムは機能せず、剰余が転送されます。どのように転送されるのか見てみましょう。和 -155,29 そのような剰余は転送に含まれないため、 BP3.0入力できません。ゼロ数量とゼロ以外の金額を入力することはできません。残高を入力するための文書は転記されないため、アップロードしません。その結果、 BP3.0残りの 2 つの金額は減少します (図 5.4 を参照)。残りはエラーのように転送されました。実際には、もちろん、ここには転送エラーはありませんが、会計エラーは存在します。

図5.4 転送結果 BP3.0

ミスグレーディングを修正するために説明されたアルゴリズムを使用するかどうかは、ユーザーの判断に任されています。金額がゼロの残高は決して転送されないことに注意してください。著者によれば、これは最も正しい動作であり、少なくとも残高を入力するための文書を入力して照合を開始することができます。残高の不一致位置をより迅速に検索するには BP2.0そして BP3.0移転の結果に基づいて、それに応じて貸借対照表を設定することにより、ソース内でそのような問題のあるポジションを選択することが推奨されます。これを行う方法については、図 5.5 を参照してください。

図5.5 数量がゼロのポジションの選択

荷降ろし完了後プログラムを実行する必要があります 1C: Accounting 8 エディション 3.0。ロードは、最初と、繰り返しのデータ転送または追加転送中の両方で、標準の処理を使用して実行する必要があります。 XML 形式での汎用データ交換(図 8.1 を参照)。メニューから開くことができます。 すべての機能 - 処理 - XML 形式でのユニバーサルデータ交換。メニューに項目がない場合 すべての機能、次に、に行く必要があります サービス - パラメータそしてボックスにチェックを入れてください 表示コマンドすべての機能.

データを 1C:Accounting 8 rev.3.0 データベースにロードした後、必要なすべての動きを取得するために、初期残高を入力するための文書を入力する必要があります。加工も使えます 書類のグループ転送(図 8.2 を参照) またはジャーナルに文書を投稿します (メニュー: すべての機能 - 伝票 - 残高の入力）。文書が移動せずに転送された場合 (パラメータ ドキュメントのアップロードの移動値に設定 いいえ）、取引や登記簿への記入を受け取るためには、書類を転記する必要があります。

データ変換技術.

必要に応じて、変換はいくつかの段階で実行できます。たとえば、最初は参考書、次に残高を入力するための文書、次にその他の文書です。情報の再転送が可能です。転送間では、転送されたデータを修正しないでください。 1C: Accounting 8 エディション 3.0そうしないと、転送を繰り返す間にこれらの修正が失われる可能性があります。

残高は書類によって転送されます 初期残高の入力.

残高を入力する方法の詳細については、1C 社の ITS Web サイトの記事を参照してください。

重要！期首残高を入力する前に、会計ポリシーのパラメータを設定する必要があります。組織の会計ポリシーのパラメータは、残高が入力された日の翌日に読み取られます。たとえば、残高を入力する日付が 2013 年 12 月 31 日の場合、2014 年 1 月 1 日に確立された会計ポリシーのパラメータが考慮されます。これにより、現在の会計ポリシーのパラメータを考慮することができます (例: 2013 年に組織が簡易課税制度を適用し、2014 年以降に一般課税制度に切り替えた場合、2013 年 12 月 31 日現在の残高を入力する際には、2014 年の会計方針パラメーターが考慮されます。そのため、上で述べたように、まず組織の会計ポリシーを移行することをお勧めします。

重要！で働き始めると決めたら 1C: Accounting 8 エディション 3.0残骸がそこに移送される前に、作業を開始する前にまずそれが必要です。 1C: Accounting 8 エディション 3.0ディレクトリを転送します。そうしないと、空ではないデータベースに残高を転送するときにエラーが発生する可能性があります。

重要：空ではないデータベースにロードするときの同期の問題、つまりオブジェクトのマッチングを解決することができます。

特殊なデータ転送処理を使用する方法.

処理はモードでのみ使用されます ファイル。処理 Transfer_Data_from_BP20_to_BP30.epfデータが転送される情報ベースで起動する必要があります。つまり、 V 1C 企業会計編 3.0。最初のウィンドウ (図 9 を参照) では、1C:Enterprise プラットフォーム上の情報ベースからデータをロードするためのオプションを指定する必要があります。

情報ベースからデータを直接ロードする

図9 データ転送処理の開始画面

次のウィンドウ (図 10 を参照) で、転送を構成する必要があります。

リストから情報ベースを選択します (リストはアプリケーションの起動時と同じです) 1C エンタープライズ).

ユーザー名とパスワードを指定する

どのような情報を転送するかを指定する

さらに、ソース内のデータをチェックして転送が正しいかどうかを確認できます。

ディレクトリを転送する場合、アップロードルールが存在する、選択したインフォベースのディレクトリからデータが転送されます。この場合、ディレクトリは完全に転送されます。チェックボックスがチェックされておらず、他の転送オプションが選択されている場合は、ディレクトリも転送されますが、転送されるトランザクションおよびドキュメントのデータを入力するために必要な範囲のみが転送されます。データを移行する場合、参考書や書類、残高などを年初に移行することができます。転送オプションは任意に組み合わせて選択できます。残高移行の際は、図1に示すルールに従って、選択した年の1月1日時点の口座残高データが移行されます。 1C:会計8では、選択した年の前年12月31日分の書類「初期残高入力」が作成されます。

図10 転送パラメータウィンドウ

データをチェックするオプションが選択されている場合、ロードする前にそのようなチェックが実行され、チェックの結果が画面に表示されます (図 11 を参照)。検証プロセス中にエラーが見つかった場合、エラーを修正できるように転送プロセスが一時停止されます。エラーがあってもデータをアップロードおよびダウンロードする必要がある場合は、チェックを外します ダウンロード前にデータを確認するまたはクリックしてください続く。チェックルールのリストは常に更新されます。

図11 ロード前のデータ検証結果

ソースから受信者にデータを転送するプロセス中に、現在の段階 (情報ベースへの接続、データのアップロード、データのロードなど) を示す画面上の画像が更新されます。また、その下には「データアップロード：書類(3 /3)」のように、より詳細な情報が線で表示されます。データのダウンロードが完了すると、ダウンロードした書類の投稿とダウンロードしたデータの確認が開始されます。文書処理またはデータ検証中にエラーが発生した場合、完了時にこれに関するメッセージがメッセージウィンドウに表示されます。ハイパーリンクをクリックすると、エラーメッセージを別のウィンドウで表示することもできます。 エラー情報(図12を参照)。

図12 データ転送処理の表示

エラーレコードを含むテーブルの一部を図 13 に示します。まず、テーブルにはドキュメントの投稿時に発生したエラーに関するメッセージが表示され、次に検証中に発生したエラーが表示されます。ダウンロードされたデータの確認では、ソースと宛先で残高が入力された日に生成された貸借対照表を比較します。いずれかのアカウントの残高が一致しない場合、これに関する記録が作成されます。エラーテーブル内のエントリをダブルクリックすると、問題のあるドキュメントを開いて修正したり手動で編集したりできます。メッセージウィンドウでも同じことができます。

図 13 エラーレコードを含むテーブルの一部

宛先データベースで修正を行った後、同じ情報をソースデータベースから再度転送することは意味がありません。再転送すると、このデータには再びエラーが記録されるためです。したがって、受信者ではなく送信者で修正を行うようにするか、同じ情報の送信を繰り返さないようにしてください。たとえば、初期残高を転送し、受信機に初期残高を入力するためのすべての文書を修正した後は、それ以降の転送のためにフラグを設定しないでください。 年初残高.

購入後6か月間はアップデートは無料です。無料アップデート期間が終了すると、有料でアップデートを受け取ることができます（価格は下記を参照）。同時に、複数のソフトウェア製品をセットの一部として、または個別に購入した場合、割引を期待する権利があります。割引制度について詳しく知ることができます。

ルールはテクノロジーを使って作られる データ変換：編集が簡単です。
完全にオープンであり、複製の禁止以外にライセンス制限はありません。

ファイル 転送デモ20_30.xml は、1C によって配布された BP 2.0 デモデータベースを BP 3.0 データベースに転送することによって得られたデータベースからのダウンロードです。 1C テンプレートから、または 1Cv8.cf 構成ファイルを使用して、空の BP データベース 3.0.44.94 を作成します。アカウンティングパラメータを次のように設定します。 勘定科目表の設定倉庫およびバッチごとの在庫会計。デモデータベースファイルをダウンロードする 転送デモ20_30.xml を使用した処理 XML 形式での汎用データ交換。デモデータベースには、2009 年 1 月 1 日現在の残高の転送と、2009 年 1 月 1 日から 2009 年 12 月 31 日までの期間の文書が表示されます。

ルールは新しいリリースに合わせて定期的に更新され、BP リリース 2.0.64.23 以降に適しています。転送ルールの目的のバージョンを検索して選択する必要はなく、指定された範囲内の任意の SOURCE リリースに適しています。以前のリリースのルールが必要な場合は、作成者にお問い合わせください。 RECEIVER リリースは次のとおりである必要があります。 まさにこのようにルールに従って。

2018/08/29 部門別天秤荷降ろしを別ルールとして定めました クレジットとローン(アカウント 66、67)、以前はその一部でした その他の会計口座

2018/08/20 2.0.66.59 および 3.0.64.48 へのアップデート

2018/06/03 書類の転送を追加しました 給与の規制会計への反映

2018/05/18 2.0.66.54 および 3.0.61.37 へのアップデート

2018/02/23 2.0.66.48 および 3.0.58.41 へのアップデート

2018/01/18 2.0.66.46 および 3.0.57.17 へのアップデート

2017/12/22 2.0.66.42 および 3.0.56.22 へのアップデート

2017/11/03 2.0.66.37 および 3.0.53.38 へのアップデート

2017/09/26 2.0.66.37 および 3.0.52.35 へのアップデート

2017/06/14 2.0.66.29 および 3.0.50.18 へのアップデート

2017/05/05 2.0.66.25 および 3.0.49.27 へのアップデート

2017/04/04 - BP 2.0 で番号と日付のみがある場合に受信した請求書の作成を追加しました。パラメータを設定する必要があります 請求書の変換(ソースに番号と日付のみが含まれている場合は、新しいソースを作成します)

2017/02/06 BP 3.0.47.23 へのアップデート

2017/01/26 書類転送を追加しました。 VAT未収額の反映そして VAT控除への反映

2017/01/11 BP 2.0.66.8 および BP 3.0.46.16 にアップデート。ケース転送は除く NDSpoOSiNMA。以前のバージョンでは、構成に含まれている場合、転送されません。

2016/12/14 BP 3.0.44.203 へのアップデート

2016/12/07 書類転送を追加しました。 債務調整

2016/12/01 パラメータを追加 簡易課税制度による登記簿費は考慮しない、これにより、簡易課税システムを使用する組織の残高の積み下ろしを管理できます。

2016/11/21 ディレクトリのダウンロードを追加しました。 ユーザー受信側での情報セキュリティユーザーの作成に関する別のルール (詳細はこちら)。 RS間での残高の転送を追加 団体の従業員(個人データ)。アカウント 76.AB および 76.BA の残高を転送する場合、2 番目のサブアカウントの誤った評価を確認して修正することができます。

2016/11/08 ドキュメントのリストが拡張されました。

2016/10/28 書類転送を追加しました。転送デモが追加されました。これは、BP 2.0 デモデータベースを転送した結果です。

2016 年 10 月 26 日口座残高がある場合に残高を入力するための空の文書の作成を修正しました。

2016 年 9 月 9 日 BP 3.0.44.102 へのアップデート

2016.03.23 受信した請求書データの転送改善（在庫残高転送時）

2016/01/11 個人の連絡先情報、市民権、パスポートデータ、障害に関する情報、個人のステータスの転送を追加しました。銀行口座と品目会計口座の移転に関するルールを追加しました。

2015/12/23 BP 3.0.43.29 にアップデート。取引相手とその担当者の連絡先情報の転送を追加しました。

2015/12/14 BP 3.0.42 のルールが作成されました

パッケージには以下が含まれます: 転送ルール 「ACC20_30」そして処理 BP20からBP30へのデータ転送。あなたの組織に作業を実行するフルタイムのプログラマがいない場合は、当社の専門家によるサービスを提供する準備ができています (プログラマは、リモート作業用の特別なプログラムを使用してインターネット経由でコンピュータに接続し、必要な作業を実行します) ）。可能であれば、作業拠点を提供してください 「1C: Accounting 8 エディション 2.0」、自分でデータを転送し、ファイルを転送できます。 1C: Accounting 8 エディション 3.0» 残高が移行されました。このサービスの費用はパッケージの合計費用には含まれません。

重要。すべてのドキュメントが転送されるわけではありません (古い BP 2.0 リリースとの互換性のため)。ご購入の前に、図 3 のリストをよくお読みください。

プログラム「1C: Accounting 7.7」および「1C: USN 7.7」から「1C: Accounting 8」へのデータの移行

標準構成からデータがどのように転送されるかについて少し説明します。会計"、1C のエディション 4.5:Enterprise 7.7 または構成 "" (以下、ソース構成と呼びます) を標準構成 " 企業会計"、1C:Enterprise 8 のエディション 3.0 (バージョン 3.0.52)、以下「受信機構成」と呼びます。

重要！設定からデータ転送が可能会計 1C:Enterprise 7.7 バージョン 7.70.569 以降、または構成からのエディション 4.5 簡易課税制度編 1.3» バージョン 7.70.219 以降。

前の期間の規制業務が完了した後、新しい期間 (年、四半期、月) の開始時にソース構成から宛先構成に切り替えることをお勧めします。

データ転送は、ソース構成情報ベースからデータを XML 形式のファイルにダウンロードする特殊な処理を使用して実行されます。結果のファイルは、ユニバーサルデータロード処理を使用して受信者の設定情報ベースにロードされます。

ACC_ACC8 .ert - 構成から外部ファイルにデータをアップロードする外部処理 会計、改訂 4.5»;

USN_ACC8 .ert - 構成から外部ファイルにデータをアップロードする外部処理 簡易課税制度編 1.3»;

ACC_ACC8 .xml - データ変換ルール。

USN_ACC8 .xml - データ変換ルール。

以下は、ソース構成情報ベースから受信者構成に転送されます。

- 情報ベースの変換日の時点での、ソース構成情報ベースの会計口座の現在の残高に関する情報。

- 情報ベースの変換日よりも古い日付を持つ現在の文書。

変換は次の 2 段階で実行されます。

— ソース構成情報ベースのデータは別のファイル (データファイル) にアップロードされます。

— 受信したファイルは、受信者の構成の情報ベースにロードされます。

データ移行処理をインストールするには、setup.exe インストールプログラムを使用する必要があります。プログラムを開始すると (1C:Enterprise インフォベースの数が多い場合は、しばらくしてから) ダイアログボックスが表示され、データ転送処理をインストールするインフォベースをマークする必要があります。ウィンドウは図 1 のようになります。情報ベースの数が 7 つを超える場合は、「上」および「下」ボタンを使用して移動します。複数の情報ベースが選択されている場合、「パス」行には最後に選択されたベースの位置のみが反映されます。この情報は補助的なもので、インストールプログラムの結果をユーザー側でさらに制御するためにオプションで使用されます。特別な注意を払う必要はありません。選択した情報ベースがどこにインストールされるかはプログラム自体が決定します。。

図1 インストール時にインフォベースを選択するウィンドウ

さらに、データ転送処理をインストールするフォルダーを指定することもできます。これを行うには、フォルダー選択ウィンドウ (3 つの点のボタンをクリック) を使用します。選択したフォルダーのフルパスが選択行に反映されます。 [インストール] ボタンをクリックすると、必要なファイルが選択したインフォベースおよび (または) 選択したフォルダーにインストールされます。完了後、「詳細」ボタンをクリックすると、どのファイルがどのフォルダに書き込まれたかなど、詳細なインストールログを確認できます。その結果、選択したフォルダーには次の図のような内容が表示されます (図 2 を参照)。

図2 選択したフォルダにインストールされたファイル

サブディレクトリへ 拡張フォーム処理と転送のルールが確立されています。アップロード処理に注意してください ACC_ACC8.ertデータアップロードルールは、標準の処理とルールを置き換えます。標準の移行メカニズムを維持したい場合は、新しい処理をインフォベースではなく別のディレクトリにインストールします。

インストールプロセスについては、レポートのインストール例を使用して詳しく説明します。 構成「1C: Accounting 7.7」のアカウンティングの高速チェック«.

番組では「 1C: 会計 7.7「追加オプションから処理を開く必要があります」 1C への移行: 会計 8 編 3.0」をクリックし、転送ルールが保存されているフォルダーを選択し (図 3 を参照)、交換ルールをダウンロードします。すべての転送ルールを含める必要はありません。残留物、または残留物と書類の転送など、必要なもののみを使用してください。たとえば、ディレクトリグループでは、すべてのディレクトリが必要に応じてリンクを介して転送されるため、単一のルールを含めることはできません。残高または文書に関係するもののみ。これにより、新しい情報ベースに「ゴミ」が存在しないことが保証されます。書類も全て揃える必要はありません。たとえば、一部のドキュメントがデータベースにない場合、または転送したくない場合は、このルールを有効にする必要はありません。

図3. データアップロードの処理

データファイル名を「C:\v77_v8\Exp77_80.xml」に設定することをお勧めします。これは、プログラムでデフォルトでよく使用されるフォルダーです。 1C: 会計 8「プラットフォーム上のプログラムからデータをダウンロードするとき」 1C:エンタープライズ7.7」。必要に応じて、パラメータを設定します。 オプション«.

構成からデータをダウンロードするプロセス中」 会計 7.7「さまざまなエラーが発生する可能性があります。ここで紹介する転送ルールは、データのアップロード段階で一般的なエラーを検索するという点で標準的なルールとは異なります。どのようなメッセージが表示されるかを考えてみましょう。

ゼロ数量およびゼロ以外の在庫品目。材料の数量がゼロに等しく、材料の原価見積がゼロに等しくないような方法で、受信設定に残高を入力することは不可能であり、これはエラーであるため、無意味でもあります。したがって、残高を転送する場合、そのようなポジション（数量がゼロ）は残高入力文書に含まれません。したがって、データ転送前にエラーが修正されない場合、残高転送時のデータのソースと宛先の金額が一致せず、照合がさらに困難になります。したがって、構成からデータをダウンロードする過程で、「 会計 7.7» 発生したエラーに関するメッセージが表示されます (図 4 を参照)。さらに、エラーを見つけるために、「会計保守のエクスプレスチェック」処理、つまり「材料の数量がゼロの場合に非ゼロの金額が存在しない」というルールを使用することをお勧めします。

図4.1 発生したエラーに関するメッセージ

第 2 (第 3) レベルのサブアカウントのゼロ以外の残高、最初 (2 番目) レベルの残高はゼロです。これは、誤った記録保持のかなり一般的な状況です。典型的な例を図 4.2 に示します。この状況は、分析会計における「再格付け」の結果として発生します。たとえば、キャッシュフロー書類には合意が示されているが資本化書類には合意が示されていない、またはその逆、または合意はあるがそれらが異なっているなどです。これらすべてのケースにおいて、相手方の残高がゼロであるにもかかわらず、契約上の残高はゼロではありません。同様の状況は、材料および命名規則の会計処理 (保管場所による合計会計処理が含まれる場合) にも発生する可能性があります。つまり、特に倉庫が財務責任を負っている場合、倉庫間の再グレーディングです。

図4.2 会計上の誤りの例

これが間違いであることは明らかであり、そのような残高を引き継ぐことが無意味であることは明らかです。この種の残高の転送を除外するために、「上位レベルに残高がゼロの場合は残高をアンロードしない」というパラメータがあります。このパラメータが 1 に設定されている場合、アップロード中に図に示すメッセージが表示されます。 4.3 (図 4.2 と比較)、そのような位置の天びんは降ろされません。さまざまな残高を転送するためのルールとこのパラメータのさまざまな組み合わせを使用できます。すべての残高を一度に転送するのではなく、会計セクションごとに転送する場合は、異なるパラメーター値を使用して、異なる会計セクションから残高を転送できます。

図4.3。エラーメッセージ

空の契約額または外国契約。この問題は上で説明したものと似ており、理由は同じです。契約の分析会計における格付けの誤りです (図 4.4 を参照)。ただし、取引相手の残高はゼロではないため、上記の検証ルールは機能しません。データ転送時、残高入力伝票の転記時にエラーが発生します。空のコントラクト値は許可されません。

図4.4 エラーを示すレポート

このようなエラーを転送前に排除するために、データのアップロード段階でエラーメッセージが発行されます (図 4.5 を参照)。同じ図は、別のエラーが発生したことを示しています。つまり、契約が取引相手に対応していません。契約の所有者は別の相手方です。このようなエラーは、修正されたものでよく見られます。非標準構成、またはずっと前に作成されたデータベースでは、標準構成であっても文書に記入する際に契約の遵守について十分に厳密なチェックが行われていませんでした。

図4.5 アカウンティングエラーメッセージ

パラメータ「」が 1 に設定されている場合、契約および他の人の契約の空の値のチェックが実行されます。 契約書に空の値がないか、取引相手とのコンプライアンスを確認する」。さらに、エラーを見つけるために、「会計保守の高速チェック」処理、つまり「契約の空の分析の不在」および「取引先と契約の遵守」のルールを使用することをお勧めします。

その他のエラーチェックもありますので、詳しくはお問い合わせください（ページ下部の連絡先）。

別のタイプのドキュメント、または選択したタイプのドキュメントの個々のコピーをアップロードする例を使用して、データ全体ではなく部分的に転送する方法を示します。データアップロードルールを 1 つだけマークしましょう。」 支払い命令」（図5を参照）。これにより、「」のようなドキュメントのみをアップロードできるようになります。 支払い命令」。これらのパラメータを使用して「」をクリックすると、 アンロード"、次に " タイプのすべてのドキュメント 支払い命令" との時間間隔にあります。 開始日" による " 有効期限」。ボタンをクリックしてください。 PVDのインストール"、その後の碑文" 支払い注文のデータの選択«.

図5 特定の種類のデータをアップロードするためのルールを設定する方法

次に、「条件の追加」ボタンをクリックすると、選択属性を選択できるようになります (図 6.1 を参照)。ほとんどの場合、それは「」です。 現在のドキュメントこれにより、このタイプのドキュメントのリストから別のドキュメントを選択できるようになります。他の選択の詳細を使用して、ドキュメントのグループごとに選択を取得することができます (たとえば、日付ごとにドキュメントを選択します)。すべての場合において、ドキュメントはパラメータで指定された時間間隔内で選択されます。 開始日" そして " 有効期限«.

図6.1 単一ドキュメントの選択方法

重要！ 「1C」)、一部の構成では、選択の詳細に従ってアップロードするときにドキュメントを選択できません。これは、標準ルールでは書類の選定が期間を定めずに申請によって行われるためである。このような要求は常に機能するとは限りません。

同様の方法で、ディレクトリ全体ではなく、詳細に従って選択してディレクトリをアップロードできます。まず、目的のデータアップロードルールを選択し、ボタンを続けて押します。 PVDのインストール" そして " 条件の追加」。たとえば、図 6.2 は、プログラムからの移行時に一緒にいた従業員だけをアンロードする方法を示しています。 1C：簡易課税制度編 1.3" の上 " 1C: エンタープライズ会計、エディション 3.0「（またはユーザーがよく言うように、会計 7.7 から 3.0 への移行）労使関係は確立されています。

図6.2 ディレクトリ要素のグループを選択する方法

重要！標準ルールの誤りは、データ転送に関するルール案で修正されました（会社より） 「1C」)、これにより、定期的なディレクトリの詳細を使用してアンロードするときに、ディレクトリ要素が誤って選択されます。異なる日付に異なる値が設定されているもの。これは、標準ルールではディレクトリ要素の選択がピリオドを指定せずにクエリによって実行されるためです。

ディレクトリの定期的な詳細に基づく選択は、パラメータ「日付」に行われます。 有効期限«.

データのアップロードルールと選択ルールを組み合わせて使用できます。選択が設定されているルールには「[SELECTION]」と表示されます。特定のデータアップロードルールの選択を表示または編集するには、ルールのリストでこのルールをダブルクリックするか、ルールを選択してボタンをクリックする必要があります。 PVDのインストール«.

重要！オブジェクトのアップロードが空または不完全であることが判明した場合は、同期モードが 1C:Accounting 8 で設定されているかどうかを確認する必要があります。この場合、転送後に変更されたオブジェクトのみがアップロードされます (ディレクトリ同期アカウンティングパラメータには、最後にアップロードされたドキュメントの位置パラメータが保存されます。このパラメータは、アップロード中に CheckFor Upload Possibility 関数によってチェックされます。同期モードでの完全な動作ができなくなります。同期モードは、交換ルールをロードした後にチェックされます。このモードがインストールされている場合、警告ウィンドウが生成され (図 6.5 を参照)、同期モードを無効にするように求められます。

米。 6.5 同期モード警告ウィンドウ

標準ルールとのその他の違い

古い領収書タイプの PT&U を転送する際のエラーを修正しました。文書「商品およびサービスの受領書」で領収書タイプが 2 (古い値) で、サプライヤー請求書がない場合、BP 3.0 でこの文書が誤って返品に変換されます。購入者からの文書が発生します。

Division のサブアカウントを持つ手動操作を BP の PROF バージョンに転送するときのエラーが修正されました。このような操作は BP に記録されず、「ディビジョンフィールドは空でなければなりません」というエラーが発生します。これは、ルールが CORP バージョンで動作するように設計されているためですが、PROF では、会計記録簿の DivisionDt および DivisionKt ディメンションが空である必要があります。

ディレクトリグループの重複を引き起こすバグを修正しました条約その結果、このディレクトリの要素が重複します (ロード中の検索は親を考慮して実行されるため)。これを図 6.6 に示します。

図6.6 ディレクトリ転送結果条約標準ルール

こちらのコラムで親(ディレクトリグループ) 名前付き 2015 同じ名前の異なるディレクトリグループが 2 つあるため (ソースには 1 つのグループのみ)、コントラクトが重複します。

ある当座預金口座から別の当座預金口座に送金する際の銀行書類の転送エラーを修正しました。で BP3.0この場合、ドキュメントが作成されます 当座預金口座からの引き落とし操作の種類で 組織の別のアカウントに送金する、内容が記入されていないため実施しておりません 受取人のアカウント。また、詳細が間違って入力されています。 アカウントそして 借方勘定。これは、55 と 51 のように異なる場合に表示され、交換する必要があります。詳細が入力されないエラーを修正 義務の種類税移転書類に記載されています。上記はすべてリリース 3.0.43.215 に適用されます。

小道具が転送されます 主契約ディレクトリ 取引相手.

ディレクトリのダウンロードルールが変更されました 命名法、現在、データ選択の方法は標準サンプリングになっており、詳細によってディレクトリの要素を選択できます (簡易課税システム 7.7 - BP 3.0 の標準規則では、これは不可能です)。ディレクトリを転送する場合 命名法、転送され、 アイテムの価格リンク経由、つまり名称の譲渡されたアイテムのみの価格。この機能を有効にするには、パラメータ値を 1 に設定する必要があります。 商品を降ろすときに価格をアップロードする.

取引相手との決済のために残高を転送する際の標準ルール「STS 7.7 - BP 3.0」のエラーが修正されました。契約のタイプは常に「」に設定されていました。他の。さて、会計セクションによると、残高の種類に応じて「 サプライヤーおよび請負業者との計算「契約タイプ = 」 サプライヤーと「会計課によると」 バイヤーと顧客との計算「契約タイプ = 」 購入者と"、その他の場合は、契約タイプ = " 他の«.

取引相手との決済の残高を転送する際の標準ルール「USN 7.7 - BP 3.0」のエラーが修正されました。相互決済の金額が、初期残高を入力するための文書の 2 つの詳細に記録されていました。和そして 金額Kt。このため、期首残高の入力伝票は転記されませんでした。

チェック購入者様と「（標準ルールでは）」他の")。属性「」の値が設定されます 支払い状態これは、受信者設定の銀行支払い文書で購入者への支払い用の請求書を正しく選択するために重要です。

「」形式の書類を転送する場合 支払い命令» 契約タイプは値に設定されます « サプライヤーと「（標準ルールでは）」他の«).

保管場所を転送する際の標準ルール「USN 7.7 - BP 3.0」のエラーが修正されました: 属性「が入力されていません」 倉庫タイプ«.

追加パラメータ「 規制当局とのやりとりも含む": 値が 1 の場合、プロパティ 管理当局との交換の種類ディレクトリ要素 " 組織" に設定されています " ユニバーサルフォーマットでの交換"、それ以外の場合は" Exchange無効「標準ルールと同様に。これは、EDI セットアップを損なわないように、繰り返し（定期的に）転送する場合に重要です。

ディレクトリ「」のダウンロードアイテムの検索ルールが変更されました 取引相手": 最初に検索が実行されます錫そして チェックポイント(これらの値が入力されている場合)、次によってのみ錫そして最後に名前。 3 つのケースすべてで、検索にはグループ属性 (ThisGroup) とグループ自体 (Parent) が含まれます。これは、ロード後に名前が変更されたカウンターパーティに重複が作成されないように、繰り返しの（定期的な）送金にとって重要です。

取引先を譲渡する場合は詳細を記入してください 国登録「ロシア」を意味します。これは、カウンターパーティのディレクトリをプログラムにロードした後、 「1C会計8」必要な詳細を手動で入力する必要がありませんでした 国登録。入力されていない場合は、ディレクトリ要素の形式で「 取引相手» 詳細は後日公開されます « 税番号" そして " 登録番号"とその詳細" 錫" そして " チェックポイント」が非表示になります。

転送ルール「USN 7.7 - BP 3.0」に、「社員」ディレクトリを転送するデータアップロードルールを追加しました（標準ルールでは個人ディレクトリのみ転送）。

転送ルール「USN 7.7 - BP 3.0」において、従業員の現行関税率情報登録の転送ルールが修正されました。

納税のための支払命令の転送の特徴

取引タイプのある支払い注文の場合 税の移転追加の詳細を入力する必要があります: KBK - 予算分類コード、コンパイラのステータスなど。これらの詳細の構造は次のとおりです。 ブフ 7.7 (USN 7.7)そして BP3.0一致しない。特に BP3.0これらの詳細の一部は別のディレクトリに含まれており、そのディレクトリへのリンクが支払い注文に含まれています。ディレクトリ 税金の種類と予算への支払いには、アカウンティングポリシーの編集時などに情報ベースに表示される、提供された多数の要素が含まれています。データを転送するとき、これらの要素はアカウンティングポリシーをロードするときにも表示されます。支払い注文をアップロードおよびダウンロードする場合、ディレクトリ要素 税金の種類と予算への支払い KBKを使用して検索し、支払い注文の詳細に置き換えます税。したがって、会計ポリシーを転送した後、必要な税金がすべてディレクトリに表示されているかどうかを確認し、必要に応じてそれらを補足することをお勧めします。支払い注文で KBK を比較 (同期) する場合、ソースと受信者は 4 つの KBK カテゴリ、カテゴリ 14 ～ 17、収入サブタイプコード (税金、罰金、罰金など) を考慮しません。ディレクトリ内 税金の種類と予算への支払いこれらのビットはゼロで埋められます。新しい要素をディレクトリに追加するときは、14 ～ 17 桁もゼロで埋める必要があります。

大規模な情報データベースの転送。

まず、大規模なインフォベースを転送する場合、データのダウンロードプロセスに非常に長い時間がかかることがあります。これは、商品残高など、1 つの会計セクションに多数の残高がある場合に発生します。アップロード時間を短縮するには、1 つのドキュメントを分割する手法を使用できます。 初期残高の入力「いくつかの場合。パラメータ値を設定すると、「 残高入力伝票の行数» ゼロとは異なる場合 (図 6.3 を参照)、1 つのドキュメントへのデータのアップロードは指定された値に制限されます。これにより、アンロード時間が大幅に (数倍) 短縮されます。

図6.3 原稿サイズ制限のあるデータ転送時のパラメータ設定 初期残高の入力»

注: パラメータ値により、1 つのドキュメントにアップロードされるトランザクションテーブルの行数が制限されます。 初期残高の入力" ドキュメント自体の行数を指定するのではなく、したがって、ドキュメントの行数はパラメータ値と異なりますが、これはエラーではありません。文書を分割するときは「 初期残高の入力」を複数の文書に対して使用すると、各文書のコメントの行末に「-1」、「-2」などの接尾辞が追加されます。

重要！ 1 つのドキュメントを分割するためのアルゴリズムについて説明します。 初期残高の入力「複数のファイルは、データのアップロード時間を短縮するためにのみ使用されます。すべてのドキュメントは 1 つのファイルにアップロードされます。つまり、データ転送は 1 ステップで行われ、コメント (接尾辞) は自動的に生成され、指定されるパラメーターは 1 つだけです。ただし、この手法では、後述するメモリ不足の問題は解決されません。

大規模なインフォベースを移行する場合、RAM が不足するという問題が発生することがあります。アンロードしようとすると、プログラムは対応するエラーメッセージを表示するか、メッセージを表示せずに終了します。コンピュータをより強力なものに交換しようとしても無駄です。この場合、データを部分的に分割してアップロードする必要があります。これには、指定されたモードをサポートする転送ルールが必要です。荷降ろしの方法を見てみましょう。まず、データ転送は 1 つのアップロードルールのみを使用して実行する必要があります (図 6.4 を参照)。 1 つのルールに従って転送が不可能な場合は、最初と最後の部分番号を示す部分に分割します。各部分には、製品残高など、特定の数の第 1 レベルの分析値に関する情報が含まれます。指定された口座残高値の数「41」。アカウントの分析の総量がわかれば、提供数を簡単に計算できます。一度にどのくらいのデータ量（1つの情報）を問題なく転送できるかは実験的に決める必要がありますが、口座残高をアップロードする場合、原則として残高が数千件以上になると転送に問題が発生します。ただし、会計セクションのすべての残高を一度にアップロードできる場合でも、データをアップロードする時間を節約するために、分割することをお勧めします。アップロード時間は、比例的または直線的ではなく、データ部分のサイズに依存します。したがって、たとえば 10,000 個の製品天秤を 1,000 分の 10 に分割することで、荷下ろし時間を数分の 1 に短縮できます。最初の部分を転送する場合、最初の部分の番号は示されない可能性があり、最後の部分を転送する場合、最後の部分の番号は示されない場合があります。

重要！データを部分的に転送する場合、パラメータに接尾語を指定する必要があります。これはドキュメントのコメントの形成に関与します。 初期残高の入力」部分範囲番号を変更するときは、接尾辞を忘れずに変更してください。そうしないと、受信者の構成にロードするときに、同じコメント (接尾辞) を持つドキュメントが上書きされます。データファイルの名前は特に重要ではありません。アンロード - ロード、アンロード - ロードなどの順次転送戦略を使用できます。この場合、データファイル名を変更する必要はありません。最初にすべてをアンロードし、次にすべてをロードするという戦術を選択できます。後者の場合、データファイルの名前は、アップロードするたびに変更する必要があります。もう 1 つの例。たとえば、会計セクションの残高 (商品など) の数が 10,000 の場合、それを 1,000 の部分に分割すると、10 個の部分が得られます。各部分には一意の接尾辞「-1」、「-2」、「-3」、「-4」が必要です。残りの商品をすべてアンロードしてからすべてをロードする場合、データファイルも一意である必要があります (例: 「41_1」、「41_2」、「41_3」、「41_4」)。パラメータ「開始部分番号」と「部分番号終了」は次の値を取る必要があります: 0、1000。 1001、2000; 2001、3000; 3001、4000。

解雇後に勤続期間が中断された場合 2007 年 1 月 1 日以降、国民の職歴の継続性を判断するために若干異なる手順が施行されています。これまでは、勤務地を移動する際に 3 週間が経過しなければ、勤務期間が中断されることはありませんでした。 2007年以来 […]
ANKO タンボフ法医学専門知識研究センター、ANO ANKO タンボフ法医学専門知識研究センター、ANO は Tambov, Rabochaya St., 37, office 40, 392008 に登録されています。自治非営利組織タンボフ法医学センターのディレクター [… 】
労働時間スケジュール上の注文労働時間スケジュール上のサンプル注文労働時間スケジュール上ロシア連邦労働法第 100 条、第 103 条、第 104 条、第 73 条および PJSC「組織」の内部労働規則に従って、順番に企業を最適に運営し、成長を […]
主治医が解雇されたエカテリンブルクの第20中央市立病院では、代理の医師が任命された。スヴェルドロフスク地方 | ウラル連邦管区アレナ・チュニス氏は、エカテリンブルク市中心部第20病院の主治医代理に任命された。特派員が報告しているように [...]
並列のオームの法則ホーム物理学を思い出してください: 7 年生 8 年生 9 年生 10 ～ 11 年生物理マルチメディアに関するビデオ 7 年生。マルチメディア8年生マルチメディア9年生マルチメディア10-11グレード。天文学テスト 7 級 8年生のテスト 9年生のテスト統一国家試験のデモンストレーションテーブル [...]
1991 年 3 月 22 日の RSFSR 法「商品市場における独占的活動の競争および制限について」N 948-1 (1992 年 6 月 24 日付けのロシア連邦法 N 3119-1、1992 年 7 月 15 日付けの N 3310 により修正) -1; 連邦法 1995 年 5 月 25 日付け N 83-ФЗ、1998 年 5 月 6 日付け N 70-ФЗ、2000 年 1 月 2 日付け N 3-ФЗ、日付 […]