メニュー
無料で
登録
家  /  ほくろ/ 一括会計に関する主な質問。 バッチ アカウンティングに関する主な質問 1s 8.3 でバッチ アカウンティングを有効にする

バッチ会計に関する主な質問。 バッチ アカウンティングに関する主な質問 1s 8.3 でバッチ アカウンティングを有効にする

最新の 1C リリースでは、倉庫内で商品を操作できるようになり、受領バッチごとに商品の記録を保持する機能を使用できます。 それが何であるか、いつ必要になるか、そして 1C 8.3 でバッチ アカウンティングを設定する方法を見てみましょう。

1C のバッチ会計は、プログラム内の各バッチに受領伝票が割り当てられ、プログラムに新しいサブ勘定科目「バッチ」が表示される、倉庫内の商品の会計処理方法です。

実際、特定の商品単位には、独自の購入価格、サプライヤー、その他の領収書の詳細があります。 これは、たとえば、賞味期限が限られている商品や医薬品の場合、またはバッチの 1 つで欠陥製品が発見された場合に必要となる場合があります。 この場合、サプライヤーに返す価格を決定できます。 さらに、バッチ会計は、経営上の意思決定を行い、販売効率を向上させるための分析ツールとしても機能します。 また、バッチごとに記録を保持することで、税務および会計報告を調整できます。

バッチ記録の保持は商品原価の計算に影響します。1C では、次のいくつかの方法で計算できます。

    すべてのバッチの平均コストの計算。 このようにして、一括会計が維持されていない場合の原価が計算されます。 この場合、この商品のすべての購入商品の合計金額を数量で割ります。

    FIFO (最初に購入されたバッチが最初に販売されます)。 この償却および原価計算の方法は 1C で利用できます。 ほとんどの典型的な状況で頻繁に使用され、論理的に正当化されます。

    LIFO (最後に購入されたバッチが最初に販売されます)。 この方法は、価格の急騰時、激しいインフレ率の上昇時、その他企業にとって税務会計に一定の結果を示すことが有益な場合に適用可能です。

    RAUZ は、企業のコスト構造を高精度に分析できる高度な分析原価計算です。 1C では、このツールも選択できます。 このオプションを取り付ける場合、費用は別のドキュメントで計算されます。

企業がバッチごとに記録を保持していない場合、新しい会計方法に切り替えるときは、1C で必要な設定を行う必要があり、商品の受領書と償却の文書を再転記することをお勧めします。

でこれを行う方法を見てみましょう。 設定を含むメニュー項目は、プログラムのメイン ページの設定セクションにあります。 ここでは「組織」を選択します。

データベース内の組織のリストを開いた後 (たとえば、会計を別の会社にアウトソーシングしている場合、組織が複数ある場合もあれば、1 つだけである場合もあります)、新しい会計方法がインストールされている組織を選択する必要があります。上記のリンクを使用して、アカウンティング ポリシー設定に移動します。 次に「会計方針」を選択します。 ここで「MPZ の評価方法」セクションに興味があります。

ここで在庫を評価する方法が確立されます。企業で使用される方法を確立し、文書に書き留めて文書を閉じる必要があります。

物理学者は永久機関を持ち、錬金術師は賢者の石を持ち、1C 建築家は常に最新のバッチ会計を持っています。 これはバッチ分散アルゴリズムの実装であり、シーケンス境界を復元する必要がなく、バッチ分散は文書に対する遡及的な変更にも関連したままになります。

このテーマに関して非常に多くのコピーが破られてきましたが、理想的なものはまだ見つかっていません。 このトピックの魅力をさらに高めるのは、そのメソッドが存在するに違いないという直感的な感覚です。

それで、私はついにこの古くからの問題に対する解決策を思いついたように思えます。 残念ながら、このアイデアをコードで実装することはできません。なぜなら... 自由な時間はありません。 したがって、私はパフォーマーの栄誉を他のプログラマーに譲り、自分自身はイデオロギーのインスピレーション者としての控えめな役割を残しています。

このアルゴリズムは、通常のバッチ アルゴリズムよりも複雑であることが判明しましたが、桁違いではなく数倍複雑であり、野心的な開発者にとっては実装が十分に可能です。

このアイデアは、1s8 で登場した新しいメカニズムによってのみ実装が許可されました。 これらは情報のレジスターであり、データベース内のレコードのセットを通じて操作します。

使用するレジスタ

この図は、バッチ会計に使用される 2 つのレジスタ (従来のものと提案されたもの) を示しています。

デモの例

新しいバッチ会計の原理が明らかになる実証例を考えてみましょう。 製品の移動履歴をいくつか見てみましょう。

1.06 請求書 PNK1 に従って 100 個が到着しました

2.06 委託ノートRNA1を使用して20個販売

PNK1 から 20 個が償却され、PNK1 の残高は 80 個になります。

3.06 PNK2 の送り状に従って 30 個を受け取りました

4.06 RNA2 委託ノートを使用して 20 個販売

PNK1 から 20 個が償却されました。PNK1 の残高は 60 個です。

4.06 RNA3 委託ノートを使用して 70 ユニットが販売されました

PNK1 から 60 個が償却され、PNK1 の残高は 0 個です。

PNK2 から 10 個が償却されました。PNK2 の残高は 20 個です。

蓄積レジスタを使用した古典的なアプローチでこの償却がどのように実行されるかは誰もが知っているため、その兆候はありません。

デモをレジスターに反映

提案されたアプローチでは、情報レジスタのエントリは次のようになります。

日付

日付

書類

文書の転記

量

残り

1.06

2.06

PNK1

PNK1

2.06

4.06

RNA1

PNK1

3.06

PNK2

PNK2

4.06

4.06

RNA2

PNK1

4.06

4.06

RNA3

PNK1

4.06

RNA3

PNK2

Nomenclature、Warehouse、Cost の各フィールドは、表示しやすさを考慮して考慮されていません。

転記伝票はバッチ伝票です。

ドキュメントとは、動きが発生するドキュメントです。

数量は書類に記載されている数量です。 プラスが収入、マイナスが支出です。

残りは、移動後のロットの残りです。

日付 - 移動の日付と時刻。

終了日は、残高が有効な日付と時刻です。 無限大とは、01/01/3000 などの大きな日付を指定することができます。

レジスタデータの解釈

特定の日付/時刻 D のレジスタ残高を取得するには、条件に従って情報レジスタ P のすべてのレコードを取得するクエリを構築する必要があります。

研究日>=D&D

1C では 1 つの日付に複数のドキュメントが存在する可能性があるという事実を考慮して、選択条件についてより慎重に検討する必要があるかもしれません。

したがって、指定された日時にバッチの残高を反映する一連の登録エントリを受け取ります。

アルゴリズムの実行

特定の文書を日付 D で転記するには、D より後の移動日にあるすべてのレコードを再計算する必要があります。これは、受信または送信のすべての文書に当てはまります。 受領文書により利用可能なロット数が増加するため、償却パターンが変化します。

文書がキャンセルされた場合も同じことが起こります。

「このアルゴリズムの何が新しいのですか?」という質問があるかもしれません。 結局のところ、通常の場合、文書を投稿した直後に順序境界を復元できます。 確かに、時間がかかるので誰もこれを行いません。

その考え方は、1 回のレコードの読み取りセットで現在のドキュメント以降のすべての動きを選択し、それらをメモリ内ですばやく再計算し、レコードセットの 1 回の書き込み操作でデータベースに書き込むことができるということです。

情報レジスタのエントリは、1 回の読み取り操作で読み書きできます。

  1. クエリを使用すると、並べ替えとグループ化を実行できます。 これは、複数の製品に対して 1 つのリクエストを実行する場合に特に当てはまります。
  2. クエリは、すべてのデータをメモリにロードしない選択を使用して走査できるため、任意の大きな動きのセットを処理できます。

読み取られたレコードはバッチ分配アルゴリズムによって処理され、新しい分配、新しい残高、および有効期限が計算されます。

レコードはレコードセットに順番に書き込まれます。 レコードのセットが非常に大きいことが判明した場合は、部分的に記録できます。

アルゴリズムは高速であることが判明しました。 ドキュメントの移動後の移動のみが再計算されます。 以前の動きは変更、読み取り、または上書きされません。 文書の転送が過去に遡るほど、パーティの配布状況を復元するのに時間がかかります。 ただし、依存性は指数関数的ではなく、速度の差は非常にゆっくりと増加します。 読み取りおよび書き込みが可能なレコード セットは常に 1 つあります。

結論

私は同僚にアルゴリズムについて意見を述べるよう依頼しています。 私の意見では、これは非常に効果的なアルゴリズムです。

1C におけるバッチ会計の基本原則

バッチ会計では、特定の引当金が個別のバッチの形式で提供されることを前提としています。
つまり、この埋蔵量は不均一ですが、異なる特性を持つ異なるバッチで構成されています。
したがって、リソースを使用する場合は、リソースを指定するだけでは十分ではなく、このリソースのバッチも指定する必要があります。
最も単純な例は商品の受け取りです。
同じ製品の各バッチでも、サプライヤー、賞味期限、購入価格、配送料などが異なる場合があります。
バッチ リソースを消費する場合、バッチを指定するための次のモデルが可能です。

  • バッチ表示 - 使用したバッチが直接表示されます。
  • LIFO - 残りのすべての出荷が識別され、受領日ごとに分割され、その順序で使用されます。
  • FIFO - 残りのすべてのバッチが識別され、到着日によって分割され、その順序で使用されます。
  • 平均による - バッチの一部のプロパティ (購入価格など) の平均を取得することによって、バッチ リソースが 1 つのバッチ リソースに変換されます。 この特性の平均値が取られ、リソースが反転されたときにこの特性が示されます。

一括会計の例
バッチ会計の基本的なニュアンス。
次のセクションでバッチの記録を保持しましょう: 製品、バッチ = 数量、金額
このレジスタの残りの部分に次のバッチを含めます。

コニャック PNK-01 10本 100r
コニャック PNK-02 50本 600 RUR
コニャック PNK-03 20本 260 RUR
ミネラルウォーター PNK-04 30本入 600RUR
ミネラルウォーター PNK-05 20本入 500RUR

文書番号が大きくなるほど、入力された日付も大きくなります。
さまざまなアルゴリズム (FIFO、LIFO、平均) でコニャックの 40 ポジションとミネラルウォーターの 30 ポジションを償却することを考えてみましょう。

FIFOによる消込

コニャック PNK-01 10個 100 (バッチ全体が残ります)
コニャック PNK-02 30本 600/50*30=360
ミネラルウォーター PNK-04 30本 600（全量お任せ）

LIFO償却

コニャック PNK-02 20本 600/50*20=240
コニャック PNK-03 20個 260 (全バッチ出発)
ミネラルウォーター PNK-04 10本 600/30*10=200
ミネラルウォーター PNK-05 20本 500（全量お任せ）

平均による償却
平均で償却する場合、同じ構造のレジスターを取得できますが、Batch フィールドのみが入力されていないため、商品の残高は折りたたまれます。

コニャック 80 個、(10*100)+(50*600)+(20*260)\80=452.5r
ミネラルウォーター 50個、(30*600)+(20*500)\50=440r

したがって、償却する場合、価格は製品の金額を数量で割ったものとなります。

一括会計の秘密

実際、バッチ レジスタは次のような構造になっている可能性があります。
ディメンション (倉庫、バッチ) => リソース (数量)。
実際、バッチ ディレクトリを保持する場合、金額をバッチ レジスタに保存する必要はありません。 バッチコストとバッチ価格はバッチディレクトリに保存されます。 すべての動作は定量的な観点からのみ実行されるため、アルゴリズムは簡素化されており、コストはレポートの生成段階でのみ追加されます (バッチ ディレクトリから取得されます)。

1C 8.3 でバッチアカウンティングを設定するには、次のことを行う必要があります。

1. 会計パラメータ設定で: 管理 – – 勘定科目表の設定、在庫会計で、バッチ別 (受領伝票) チェックボックスをオンにします。

2. 会計ポリシー設定: メイン – 会計ポリシーの [在庫] タブで、在庫の見積り方法 (FIFO による) を設定します。 この方法は、商品が別々のバッチで受け取られ、1 つの製品の各バッチが別々に会計処理されることを前提としています。

これらの設定後、新しい Batch サブアカウントが在庫アカウントに表示されます。

重要！ 領収書および販売伝票で VAT 率 0% および VAT なしを指定する場合、および 1C 8.3 会計プログラムで簡易課税システムを使用する場合、プログラムの設定に関係なく、バッチ会計が維持されます。

倉庫へのバッチの受け取り

商品および材料の受領に関する文書では、他のすべての受領と同様に、文書の記入内容は変更されず、標準のままです。

投稿内の分析のみが変更され、新しい Batch サブアカウントが入力されます。

重要！ バッチ記録を保持しない別の組織が 1C 8.3 データベースに入力されている場合、つまり、会計ポリシーが平均原価での償却を設定している場合、伝票では領収書もバッチ転記に反映されますが、書き込みは行われません。 -off は平均コストで発生します。

バッチ販売

販売や生産へのリリースなど、どのような方法であってもバッチの償却。 原価は FIFO から消去されます。

実装例を見てみましょう。

ドキュメントの表形式部分にバッチを反映するには、[詳細 – フォームの変更] ボタンを使用して、[領収書ドキュメント] 列を追加する必要があります。

デフォルトでは、1C 8.3 では転記伝票は自動的に入力されますが、手動で入力することもできます。

利用可能なパーティーをすべて表示するには、「生成」をクリックします。 期間の日付の時点で残高がある資本化ドキュメントが反映されます。

伝票転記では、原価価格は FIFO 原則に従って形成されます。

重要！ バッチ記録を保持しない別の組織が 1C 8.3 データベースに入力されている場合、つまり、会計ポリシーが平均原価での償却を設定している場合、償却文書にはコストと償却のための 1 つのエントリが存在します。その金額は平均して計算されます。 パーティー分析は入力されません:

重要！ 1C 8.3 でバッチ会計を使用する場合、原価は償却時にのみ形成され、「平均原価」方式と同様に月末には調整されません。

領収書書類の入力が遅れた場合

受領文書が適時に入力されない場合、バッチが FIFO 原則に従って償却されない状況が発生する可能性があります。 1C 8.3 でのバッチの消込の正確さを復元するには、文書を再転記する必要があります。 一連のドキュメントの復元は、[操作] セクションの [ドキュメントのグループ再投稿] コマンドによって実装されます。

または、月を締めるときに、その月のドキュメントの再転記処理を使用します。

バッチ情報

1C 8.3 のバッチに関する情報は、「レポート」セクションの「勘定科目貸借対照表」レポートで表示できます。

バッチをレポートに反映するには、1C 8.3 プログラムの設定で [バッチ] チェックボックスをオンにする必要があります。

どの文書や参考書がどこにあるのか、プログラムが自動的に実行するアクションと自分で実行する必要があるアクション、プログラムを「自分用に」カスタマイズする方法、プログラム内で適用される事務処理と規制報告の順序を把握できます。これらすべてを学ぶことができます。 コースの詳細については、次のビデオをご覧ください。


この記事を評価してください:

倉庫会計に関連する 1C 8.3 プログラムでは、受領バッチごとに製品残高を追跡することができます。 この機会は、1C でバッチ消込方法の変形を指定することによって実現されます。

次のオプションが利用可能です。

  • LIFO (後入れ先出し)。 現在では、使用されることはほとんどありません。 深刻なインフレの場合に効果的に使用されます。 コストは最初に購入された最後のバッチに適用されます。
  • FIFO (先入れ先出し)。 基本的に、最も論理的で最もよく使用されるオプションです。
  • 平均に基づいて計算。 最も単純な計算方法。以前は、この方法を選択した場合、一括会計は実行されませんでした。
  • 高度な分析原価計算 (RAUZ)。 ごく最近になって番組に導入されました。 このタイプの会計を選択した場合、コストはすぐには計算されません。 コスト金額は、「コストコスト計算」文書が完了して処理された後に表示されます。 これは、生産性を向上させ、ユーザーがドキュメントの順序を変える必要がないようにするために行われます。