私の意見では、事前定義された要素を使用したプログラムによる作業というアイデア自体は非常に正しいです。 作業時に考慮する必要があるニュアンスがあります。

まず、構成には事前定義された要素があり、情報ベース (IS) にも事前定義された要素があることを自分自身で明確に理解する必要があります。 技術的には、事前定義された情報セキュリティ要素はディレクトリの最も一般的な要素であり、「事前定義されたデータの名前」属性は、それらがどの事前定義された構成要素に対応するかを示します。 これらは通常の要素と何ら変わりません。 したがって、通常の情報セキュリティ要素を事前定義することも、事前定義された要素を通常にすることもできます。 これを行うには、属性に目的の値を入力するだけです。 「事前定義されたデータ名」。

場合によっては、このプロパティには開発者が意図したものではない値が含まれることがあります。 その結果、1Cの動作にエラーが発生します。 基本的に作業が不可能なクリティカルから、アルゴリズムのロジックが中断されるノンクリティカルまで。

条件付きで区別できる 3 種類のエラー:
1. 「事前定義された要素がデータ内にありません」;

3. 事前定義要素の指定が間違っている。

1. 「事前定義された要素がデータにありません」 - o情報セキュリティデータの設定に事前定義された要素が記述されていない。

これは、デバッグと修正が最も簡単なタイプのエラーです。 そのシンプルさは、プラットフォームがこの状況「事前定義された要素がデータに欠落している」ことを正確に報告し、それを修正する方法が非常に明確であるということです。

コード内の欠落要素「ディレクトリ.連絡先情報の種類.連絡先担当者の電子メール」にアクセスすると、メッセージが表示されます。

リクエスト「VALUE(ディレクトリ.連絡先情報の種類.連絡先担当者の電子メール)」の要素にアクセスすると、次のメッセージが表示されます。

このエラーは、要素が構成に記述されているが、その要素がデータベース内でその要素に関連付けられていない場合に発生します。

まず、この状況が必ずしも間違っているわけではないことを明確にしましょう。 ほとんどのユーザーにとっては使用されない可能性がある、ある種のプログラム ロジックで事前定義されたデータを使用することは十分に可能です。 この場合、構成のすべてのユーザーのディレクトリが乱雑にならないようにするために、事前定義された要素を構成内に定義するのが論理的ですが、それらの要素をすべての情報セキュリティ システムに作成するのではなく、必要な情報セキュリティ システムに対してのみ作成します。必要な構成ロジックが使用されます。 この場合、プログラマはディレクトリに「定義済みデータを更新しない」プロパティを指定し、モジュール機能にアクセスするときにプログラムで要素を作成できます。 または、ユーザーが事前定義されたモジュール要素を既存の通常の要素に個別にバインドできるようにします。

また、RIB モードで作業する場合、事前定義された要素の自動作成は使用されません。 新しい要素は中央データベースから転送する必要があるため、異なる UID を持つノードで作成することはできません。

それらの。 エラーは、そのような要素自体の存在ではなく、一致しない要素への参照である場合があります。

要素が作成されなかった理由を分析する必要があります。 おそらく、何らかのプログラムモードが実行されるときに作成されるはずです。 たとえば、RIB での交換が完了した後などです。 あるいは、単に誤って削除されただけかもしれません。

事前定義された要素を自動的にではなく別のモードで入力するロジックの場合は、名前によるアクセスを使用する前に、 ディレクトリ.連絡先情報の種類.連絡担当者の電子メール「例外的な状況を防ぐために、要素がすでにデータベースに存在することを確認することをお勧めします。要素が欠落している場合は、そのことをユーザーに通知し、要素を埋めるためにどのモードを実行する必要があるかを説明します。そのようなチェックのために、データクエリを実行できます。

リクエスト = 新しいリクエスト; Request.Text = "SELECT | 連絡先情報の種類。リンク | FROM | ディレクトリ。連絡先情報の種類 HOW 連絡先情報の種類 | WHERE | 連絡先情報の種類。事前定義データの名前 = ""電子メール連絡先担当者

"""; 項目が MissingInData = Query.Execute().Empty();これでもデータベース データのエラーである場合は、情報セキュリティ要素の事前定義された要素にバインドする必要があります。 それらの。 プログラムコードがこの名前でどの情報セキュリティ要素にアクセスするかをシステムに説明する必要があります。 技術的には、バインディングは単に「プロパティ」に事前定義された要素の名前を指定するだけです。事前定義されたデータ名

2. 「事前定義された要素が一意ではありません」 - h二重の事前定義要素:

この状況は、複数の情報セキュリティ要素が 1 つの事前定義された要素に関連付けられているということです。 この場合、事前定義された名前にアクセスすると、要素はランダムに選択されます。 この状況は常に間違っています。 問題は、プラットフォームがそれをまったく報告しないことです。 アルゴリズムが誤って動作し始めるだけです。

プラットフォームは、重複した要素を編集しようとした場合にのみ、「事前定義された要素が一意ではありません」というエラーを報告します。

要素を編集する必要がない限り、誰もエラーについて知ることはありません。

たとえば、ディレクトリに RIB が使用されており、事前定義データのプロパティで「自動的に更新」モードが指定されている場合、このような複製が作成される可能性があります。 この場合、交換を実行すると、構成が更新されるときに事前定義データのインスタンスが 1 つ作成されます。 同じ名前を持つ事前定義された要素の 2 番目のインスタンスが、交換中に中央データベースから転送されます。

また、異なる情報セキュリティ要素が異なるデータベース内の事前定義された要素に対応する場合、構成間で交換処理を使用するときにこれらの重複が発生します。 この場合、定義済みデータの 1 つのコピーがデータベースにすでに存在しており、2 つ目のコピーは、別の UID でデータをロードするときに作成されます。 データ転送を実行する場合は、どのデータベース要素をプライマリとみなし、従属データベースで使用するかを決定する必要があります。 従属データベースでは、古い要素の使用をメイン データベースの要素に置き換える必要があります。

データベース内のこのようなエラーは、次のようなクエリで特定できます。

SELECT 連絡先情報の種類.事前定義されたデータの名前, QUANTITY(連絡先情報の異なる種類.リンク) AS 事前定義された FROM ディレクトリの数.連絡先情報の種類 AS 連絡先情報の種類 GROUP BY 連絡先情報の種類.事前定義されたデータの名前 HAVING QUANTITY (tactInformation.Link の異なるタイプ) > 1

このクエリは、複数の情報セキュリティ要素が関連付けられている事前定義された要素のリストを返します。

このような要素が存在する場合は、そのうちの 1 つに対して事前定義された要素との接続を削除する必要があります。 それらの。 この名前を使用する場合、プログラム コードがどの情報セキュリティ要素を参照するかをシステムに対して明確に決定する必要があります。これを行うには、コードを実行するだけです。

3. 事前定義要素の指定が間違っています。

エラーは、事前定義された要素がプログラム ロジックによって提供されていない要素に対応していることです。 このようなエラーは診断が最も困難です。 最初の 2 つのタイプとは異なり、これらのエラーについて構成を自動的にチェックすることはできません。 それらは、作業ロジックを分析することによってのみ特定できます。 疑わしい場合は、正しい要素が使用されているかどうかを確認できます。

これを行うには、コマンドの 1 つを実行するだけです。

//必要な事前定義済み通知にリンクされる情報セキュリティ要素を定義します (ディレクトリ.連絡先情報の種類.連絡先担当者の電子メール) //選択した通知が添付される事前定義済み要素を定義します (事前定義済みの要素.名前にリンクします)データ）

このようなエラーが特定された場合は、古い要素との誤った接続を削除し、新しい要素との接続を追加する必要があります。 オペレーション コードは、最初の 2 種類のエラーを修正するためのコードと似ています。

さて、プログラム作業中またはコンフィギュレーター モードでのエラーについて簡単に説明します。

「事前定義された要素は以下に属しません<Имя справочника>" - コンフィギュレータ内の名前と一致しない名前で事前定義された要素を書き込もうとするとエラーが発生します.

「事前定義されていないオブジェクトには、事前定義されたサブコント ビュー レコードを含めることはできません」 - 事前定義された勘定科目表の要素を事前定義解除しようとすると、エラーが発生します。 エラーを排除するには、各要素のサブコンタクト ラインから「事前定義済み」フラグを削除する必要があります。

「事前定義されていないオブジェクトには、主要な計算タイプの事前定義されたレコードを含めることはできません」- 計算タイプの計画の事前定義要素を事前定義解除しようとすると、エラーが発生します。 エラーを排除するには、要素の先頭の計算タイプの各行の「事前定義済み」チェックボックスを削除する必要があります。

「事前定義された要素は一意ではありません」- 8.3.4 との互換モードなしで構成リリースの情報ベースを更新すると、コンフィギュレーターでエラーが生成されます。 更新する前に重複をチェックし、重複を削除する必要があります。

「事前定義された要素の名前が一意ではありません」 - プラットフォームに更新するときに、構成内に同じ名前の事前定義された要素が複数ある場合、エラーが発生します。8.3.6.2332 以降。 構成内の重複を排除する必要があります。

事前定義されたデータを操作するには、処理することをお勧めします。 事前定義されたデータを使用して任意のアクションを実行でき、すべての情報セキュリティ オブジェクト (ディレクトリ、勘定科目表、PVC、PVR) に最初の 2 つのタイプのエラー (要素の重複および欠落) が存在するかどうか、構成全体をチェックすることもできます。 。

1C の更新は、レポートやドキュメントを送信するためのフォームを改善するために必要な手順です。 現在の法律には常に革新が現れており、経済分野では計算方法が定期的に変更されています。 したがって、すべての変更に完全に準拠するには 1C 構成を更新する必要があります。

1C 社は、会計士や起業家が自社のソフトウェアをできるだけ簡単に操作できるように努めています。 最初の適切な機会に、ソフトウェア製品に対する高品質のアップデートをリリースします。 正しく正確に取り付ける必要があります。

多くの人は、1C の更新は専門家の仕事だと信じています。 彼らは、この手順を自分の手で実行することは不可能だと言います。 これは誤解です。 更新の難しさは、標準データベースと変更データベースのどちらを使用しているかによって異なります。 また、コンピューターにインストールされている構成も異なります。

ベースが標準の場合 (つまり、プログラマが何も追加または変更していない場合)、更新には 15 分から最大 3 時間かかります。 この手順はユーザーモードで実行されます。 ベースが変わるとさらに時間がかかります。

アップデートが正しくなく、品質が低い場合、 データは失われ、以前に完了した変更はすべて失われます。 それで

エラー 1: 「事前定義された要素の名前が一意ではありません」

これは、エラーの本質がプログラム プラットフォーム自体にあることを意味します。 最新バージョン 1C で誤って更新されました。 これを修正するには、プログラムのバージョンを以前のバージョンにダウングレードする必要があります。 コンピュータに以前のリリースがインストールされていない場合は、公式 Web サイトからダウンロードできます。 前のバージョンをインストールした後、データ構成の更新を再度開始できます。

エラー 2: 「ファイルには利用可能なアップデートが含まれていません」

これは、構成が一致しなかったことを意味します。 標準構成と非標準構成があります。 おそらく、ダウンロードされたファイルは 1 つの構成に属していても、別の構成がコンピューターにインストールされている可能性があります。 問題の解決策: 空の標準構成データベースが作成されて .cf ファイルに保存され、そのファイルは標準でなくなった構成を更新するために使用されます。 標準バージョンを入手するには、構成がサポートされている必要があります (つまり、黄色の立方体が表示されている必要があります)。

エラー 3: 「事前定義された要素がデータ内にありません。」

エラー 4. 「ストリーム形式エラー」

最もよく起こるのは、ローリング アップグレードに固執せず、構成を取得して配信ファイルと比較することです。 彼らは時間を短縮するためにこれを行います。 プロセスの本質: 配信ファイルと構成が開かれ、それらの慎重な比較が始まります。 気づいた変更はすべてテキスト エディタに書き込まれます。 その後、それらは構成に追加されます。 それはしないほうがいいです。 一貫した更新を行うにはさらに時間がかかります。 しかし、なぜ 1C プログラムがクラッシュし、ストリーム フォーマット エラーが表示されるのかを座って困惑することはできません。

エラー 5. 「事前定義された要素の名前は一意ではありません。」

これは、構成が以前のプラットフォームで更新されておらず、現在更新されたプラットフォームでは、事前定義された要素の名前が一意であるとはみなされないことを意味します。 以前の 1C プラットフォームに戻り、そこで構成を更新する必要があります。 次に、新しいプラットフォームをインストールします。 エラーは消えます。

エラー 6. 「世界の国を書き込んでいるエラー」および「コンテキスト メソッドの呼び出しエラー」。

これは、既存の構成が著しく破損している場合に発生します。 画面には、次の図が表示されます。プログラムは、ある時点まで構成を更新しますが、その後、単純にクラッシュするか、明らかな理由もなく、更新プロセスを最初からやり直します。 行う必要があること: 開発者から更新ファイルを入手します。 私たちは、これこれのアップデートがインストールされ、既存のバージョンを置き換えるという情報を読みました。 「OK」をクリックすると、構成内で正確に何が変更されたかについての通知が表示されます (何も変更されていない場合もあります)。 「変更を受け入れる」をクリックします。 新しい構成に従ってデータベース全体を更新するかどうかを尋ねるウィンドウが表示されます。 私たちはこの手続きに同意します。 一貫性を保つことが非常に重要です。 プログラムにすべてのアクションを順番にゆっくりと実行させます。

エラー 7. 「プロファイルの記録中にエラーが発生しました。 そのようなプロフィールはすでに存在します。」

ユーザープロファイルのディレクトリに移動して分析する必要があります。 おそらくそこには重複があるでしょう。 たとえば、会計士や管理者のいくつかのプロフィール。 見つかった場合は、不要なプロファイルを削除し、1 つは残してください。 この後、エラーはコンピュータ画面から消えます。

上記のエラーをすべて排除するには、1c プログラムの経験と専門的なスキルが必要です。 エラーに詳しくなく、エラーの説明 (解決方法) を完全に理解していない場合は、専門家に連絡する必要があります。

一部の種類のエラーでは、専門家が現場に立つ必要はありません。 非常にシンプルなので、電話で解決策を説明できます。 より複雑なエラーを排除するには、専門家の直接の参加が必要です。

緊急にレポートを準備し、計算を行い、文書を生成する必要があるが、エラーを解消する方法が見つからない場合は、お問い合わせください。

事前定義されたディレクトリ要素はコンフィギュレータ モードで作成されます。 「1C:Configurator」モードでは、事前定義された要素の名前が決定されます。 データベースに保存される要素自体は、1C:Enterprise モードで作成されます。 したがって、事前定義要素はメタデータ (事前定義要素の名前) とデータ (ディレクトリ要素自体) です。

1C:エンタープライズ8.2

1C:Enterprise 8.2 では、コンフィギュレータで追加または削除された事前定義要素は、データベースで自動的に追加または削除されます。

1C:エンタープライズ8.3

このバージョンのプラットフォームでは、各ディレクトリに標準属性「事前定義されたデータの名前」が含まれています。 事前定義された名前を保存するように設計されており、プログラムで変更できます。 コンフィギュレーターで新しい要素を追加する場合、この要素はデータベース内に作成できるかどうかは、ディレクトリのプロパティ「事前定義されたデータの更新」によって決まります。 値が「自動的に更新」に設定されている場合、コンフィギュレーターで作成された事前定義要素がデータベースに自動的に追加されます。 プロパティが「自動的に更新しない」に設定されている場合、項目はデータベースに追加されません。 この場合、それらを自分で作成し、「事前定義されたデータの名前」属性を設定してプログラムでディレクトリの事前定義された要素にバインドする必要があります。

良い一日。

今日は、事前定義された要素に関するプラットフォーム 8.3 の革新について説明します。

導入

実際に、事前に定義された名前を見つけるためにディレクトリ要素を調べたいと思うことがよくあったことを思い出してください。 たとえば、2 つの事前定義された取引相手を作成し、IPSidorov と OOOMeteor という名前を付けたとします。 そして彼らはそこにいくつかのロジックを縫い付けました。

すべてがデバッグされ、解決されたとき、タスクは逆に提起され、LLC には個人起業家向けのロジックが必要であり、個人起業家には LLC のロジックが必要であることが判明しました。 「問題ありません」と言い、エンタープライズ モードで要素の名前を変更します。 結局のところ、コードに入るのははるかに困難です。 1 年が経過し、IP Sidorov 用にさらにロジックをセットアップするという新しいタスクが与えられます。 コンフィギュレーターにアクセスしてロジックを作成し、チェックを開始しても何も機能しません。なぜなら... IPSidorov コンフィギュレーター、およびエンタープライズ - OOOMeteor。 脳が壊れているので、この熊手を破壊したいです。 最も単純かつ明白なことは、事前定義された要素の名前をリストの形式で表示することです。 ここに問題があります。8.2 では、このメソッドを使用して事前定義された名前しか取得できません。 ただし、このメソッドには、リクエストでは取得できないという独自の不都合があります。 それらの。 最初の不便な点は、ディレクトリへの参照から事前定義された名前を取得することです。

2 番目の不便な点は、ディレクトリ要素がすでにあり、それを事前定義する必要がある場合です。 事前定義された要素を作成し、ディレクトリ内に 2 つの要素を取得します。 1 つは事前定義されており、もう 1 つは運用可能であり、すべてのドキュメントで参照されています。 リンクを置き換えることは確かに役立ちますが、データベースが大きい場合は困難です。

さて本題へ

1 つ目は、ディレクトリに「事前定義データの更新」プロパティが追加されたことです。

この分野は私たちに何を与えてくれるでしょうか？ 「自動的に更新しない」に設定されている場合、事前定義された要素を追加しても、その要素はディレクトリにすぐには表示されません。 それらの。 メタデータはデータとは何の関係もありません。 また、ディレクトリ内にファイルを作成しないと、ディレクトリ マネージャーを通じてその名前でアクセスすると構文エラーが発生します。

とても興味深いのですが、なぜでしょうか？ ディレクトリ内に要素を作成するにはどうすればよいでしょうか? 必要に応じて作成することも、既存のものにリンクすることもできます。 これで、ディレクトリには「事前定義データの名前」という属性が追加されました。 通常どおり、「Directories.Accounts.CreateElement()」を通じてプログラムでディレクトリ要素を作成し、事前定義された要素の名前と同じ属性「PredependentDataName」を入力します。 または、要素がすでに存在する場合は、そのオブジェクトを取得し、「事前定義されたデータの名前」を再度入力します。 全て。

そして最後にシロップを少々

この新しい属性は、読み取りと書き込みに使用できるだけでなく、リクエストでも使用できます。 このようにして、クエリで条件を課し、事前定義されているかどうかを判断できます。

ご清聴ありがとうございました。