カテゴリー: ERP-BusinessExpress

テスト方針に必要な項目 タイトル はじめに(下記の概要、前提条件) 目的(主とする目的) 実施内容(確認する大項目、方法、実施するテストレベル) テスト担当実施者(担当する部署、チーム) テスト環境 開始条件 終了条件 テストの進め方 テスト結果対応

固定の目標金額を指定した契約
一定期間内に一定の合計金額の範囲内で得意先が製品やサービスを受け取る販売契約です。

カスタマイジングで「未処理基本契約メッセージ」の設定をしておけば、リリース発注を登録する前に、有効な金額契約があるかどうかを確認できる。

金額契約では、リリース発注に対して、以下の契約内容を反映させることができる
・特別価格契約
・リリースできる得意先の制約
・リリースできる品目の制約

請求プロックを解除することにより、クレジットメモ依頼または返品を承認することができる
クレジットメモ依頼の理由が明確でない場合、明細ごとに拒否理由を入力できる。これらの明細は請求伝票にはコピーされない
拒否理由で以下を制御
・明細を金額ゼロでコピーするかどうか
・明細を表示するかどうか

デビットメモも同じ方法

テーブルT052(支払条件)の現金値引情報を価格決定画面上に参考として読み込む。 金額は最も率の良い値引条件を参考表示。 条件カテゴリE:支払条件 SKTO

購買伝票を分類するためのIDです。
購買伝票カテゴリには、次のようなものがあります。
・見積依頼(RFQ)
・購買依頼
・購買発注
・購買契約
・分納契約

購買伝票カテゴリは、購買伝票タイプにさらに分割することができます。

consolidation 連結

調達タイプとは、品目が内部で生産されるか、外部から調達されるか、あるいはどちらでもかまわないかを決める分類のことです。

集団に於いて構成員が共通認識を抱く為に定める概念、術語の正確な意味・約束事をいう。広く一般に定着することにより、効力を発揮することが出来る。

プロジェクトで定義が曖昧だと、悲劇の始まりとなる。

たとえば、設計書に書くべき内容、構成。
これが各担当者の裁量に任されていると、
最悪「タイトルが○○設計書」で内容が大幅に不足していたりする。

しかも、お馬鹿な成果物でも難なく検収済みだったりもする。

作成者がリリースとなっていた場合
後から読んだ人間は理解不能のまま対応をしなければならない。

結果、工数が削減できない状況を作り出す。

間違ったロックコンセプト、またはロックコンセプトの間違った適用によって、共有データへのアクセスが妨害されること。

伝票ヘッダには、伝票全体(取引全般)に関するデータや、明細データの初期値が保存されている