DPC用語集「一覧」

受注データ取得時に連続置換を行う時の処理のひとつです。

　１件の月間計受注データに対して、より新しい同月の月間計であったり、当該月間を分割された日別データ等の新しい受注データ（群）で置き換えます。
この”置き換える”という処理は“削除＆挿入”という作業で行います。この削除するときにＥＤＩデータ発信者ないしは[ＩＤ]の特性により無条件に内示データを全品目削除して今回受信データを挿入するパタンと、読み込まれた受信データ個々ののグループ単位で削除してから当該データを挿入パタンがあります。（１社の中でＩＤによって切り替わることもあります）
　この時“グループ単位”の基本は[品番]ですが、多くは[品番/納入先]の単位で得意先での発注データの制御（担当者による作成）を行っているケースが多いです。
また得意先によってはさらに多くの項目を加えてグルーピングしていて、この単位で得意先の発注データ（ユーザにとっての受注）を置き換えていきます。このグルーピングする項目群が置換keyです。

1. 電子データ交換（でんしデータこうかん、EDI、Electronic Data Interchange）とは、 標準化された規約（プロトコル）にもとづいて電子化されたビジネス文書（注文書や請求書など）を専用回線やインターネットなどの通信回線を通してやり取りすること。 あるいはこうした受発注情報を使って、企業間の取引を行うこと。

   

経済産業省による定義では、 「異なる組織間で、取引のためのメッセージを、通信回線を介して標準的な規約を用いて、コンピュータ間で交換すること」となっている。　（以上出典：Wikipedeia）

  
 

2. 今多くの自動車メーカでのＥＤＩのプロトコルはＵＮ／ＥＤＩＦＡＣＴ準拠になってきています。
   本来、ＥＤＩＦＡＣＴプロトコルを使うことにより、それまで各社毎に個別に開発されていた協力工場側の「ＥＤＩ処理」を統一的処理できるようになり効率的なシステム保守が出来ることも狙いの一つのはずです。
   実際には各社の運用はそれぞれであり、それに伴って送られてくる「ＩＤ」「フォーマット」は当然のことながら違っています。これらを処理しやすいように一件一葉（一行）のデータに変換するのに「ＥＤＩＦＡＣＴトランスレータ」という仕組みがあります。この「ＥＤＩＦＡＣＴトランスレータ」の導入当初は環境整備のための費用負担をしても、その後のシステム変更に対しては親メーカによる費用負担ないしは自社で簡単にパラーメータが変更できるのなら、「ＥＤＩＦＡＣＴトランスレータ」を導入するそれなりの意味はあると思います。
   しかし現実は毎回のシステム変更の都度、協力工場自身での安くはない費用負担で「ＥＤＩＦＡＣＴトランスレータ」のサポート企業にたいして修正依頼をかけなければなりません。ここまででＥＤＩＦＡＣＴデータが読み出せるようになっただけですから、その上で更に実際の自社システムに取り込むための修正が必要となります。


3. というわけでＤＰＣでは、（特段のお客様からの要求がなければ）「ＥＤＩＦＡＣＴトランスレータ」をかまさずに、直接ＥＤＩＦＡＣＴデータを読み込んでＤＰＣの受注情報等に変換・取得してしまいます。また修正費用は（特にこの読みこみ部分は）当該親メーカ傘下の協力工場様に於いては全社共通ですのでユーザ各社で按分請求させていただきます。・・・・修正対象ははこの一本です。

コンピュータ・システムを活用するのに必要な要員（職務）を指します。

　事務処理のためのコンピュータ・システムは機械が勝手に動くものではなく、人が動かすものです。このためにコンピュータを操作することの出来る「時間のある操作者」がいなければ“動かないコンピュータ”になってしまいます。
　しかしコンピュータは火が入ってデータが入出力されればそれでよし、かというと問題があります。コンピュータ・システムが効果的に活用されるには自社（工場の）運営がどうあるべきで、いまどうなっているか、何が問題なのかが判っている「知識のある管理者」がいる必要があります。この時の「知識」とはコンピュータ知識もあることが望ましいですが、より必要なのは業務知識であり自社の運営知識です。
　さらにシステムを運用していくとある時点時点でいうと必ずしも全部署で“みんなよい”ということはあまりなく、ある部署では良くても他の部署では目の前の負荷が増えたりして賛成出来ない、といったことは往々にして発生します。この時「力のある責任者」がいないと方針が決定されず運用が崩れていきます。・・・・最終的に意志決定はトップダウンです。
　これらの３機能は必ずしも３人で分担するばかりでなく、実際の小企業では“権限と業務知識”を社長が、”コンピュータ知識と操作”を若い担当者が分担をして担うということはありだと思います。
　
　いずれにしてもこの３職務を“名目ではなく実質的に誰が担っているのか”が見えなければシステムは動きません！

Sequential Number Systemの略でＤＰＣにおいて累積進度管理として実装しています。
原型は戦時中に中島飛行機や三菱重工で零戦製造時の進捗管理技法として編み出された追い番管理に端を発します。

MRP(Materials Requirements Planning)とも呼ばれる。
 

• 資材所要量計画（しざいしょようりょうけいかく）とは工場などで使われる生産管理手法の一つ。
• 資材管理で生産を計画する手法のこと。

 

その概念を発展させて資材以外の人員、設備など製造に必要なすべての資源を管理する仕組みをMRP2という。 さらに、企業全体の在庫、決済、資産の管理を行うようにしたのがERP(企業資源計画)である。 　（以上出典：Wikipedeia）

 

1. ＤＰＣでは「引当計画」として品目単位ではなく工程単位で（後工程から前工程に向かって）ＭＲＰ展開ロジックで使われる総所要量計算/先行計算/純所要量計算/計画取り纏め　をLevel by Levelで常に実績在庫に立ち戻って運用する形で実装しています。
2. このためＤＰＣにおいては品目途中の仕掛かり工程在庫を残したままの計画も立てられます。

在庫を表す単位の一つで、「在庫情報」が捉えている数値を表している”管理単位”ではないもう一つの表現単位です。

　使い方としては２つあり、その一つは“見て分かる単位”としての使い方です。これは通常、部品・製品の在庫数は“個"で管理されることが多いですが、（特に小物は）“箱”や“袋”に定量の収容数で取り扱われることがあります。この時は実際の“目で見る管理”としては“何個ある”、よりは“何箱ある”の方が管理しやすくなります。このために「在庫表」での表現や「実棚処理」時の調査数は、”管理単位”の値でも換算単位の値でも両方が取り扱えるようになっています。
　もう一つの使い方が「取引」時（多くは受入）に取り扱う数量が[取引単価]のせいで、在庫移動に使われる”管理単位”の値でない時に、”換算単位”をこの時の単位として使います。（これを“取引単位”といいます）

【使用例】

1. 収容器による単位
   上記のように”管理単位”の“個”に対して、“箱”、“袋”、等
   液体やペレットのような素材重量の“KG"に対して、“缶”、“箱”、“袋”、等
2. 形態による単位
   定尺の鋼板/鋼材のような素材重量の“KG”に対して、“枚”、“本”、等
   この素材に関しては”管理単位”のところでも説明してありますが、”管理単位”と“換算単位”がひっくり返ることがあります。
   テープ等の巻物系の素材では“mm”に対して、“巻”、等
3. [取引単価]による単位
   小物メッキのように在庫上の”管理単位”は“個”だが、[取引単価]は“KG"あたりの重量単価
   鋼板/鋼材のような素材は、多くは[取引単価]は“KG”あたりの重量単価です。
   この時在庫も重量で管理していれば換算の必要がありませんが、在庫の”管理単位”が定尺品目で“枚”や“本”の時は、“換算単位/ 取引単位”として“KG”を使います。

ＤＰＣで在庫管理を行うときにシステムで把握される在庫数値が表している単位をいいます。

　多くの品目では“個”になると思いますが、鋼板/鋼材等の素材では“KG”が主体になります。ただ素材の内“定尺材”といわれるサイズの決まっている物については管理のしやすさから”本”や“枚”で表現することも多いです。
同様にプラスティック・ペレットのように定量の袋に梱包されているような物では“袋”というような単位が使われることもあります。　
　この時（特に素材の様に“KG”や“枚”という２種の単位が使える物の時）いずれの単位を使うのかは上位品目での構成比率の表現の仕方で固定されます。すなわち当該品目を構成材料として使う上位品目で“仕込重量”で表現するならば“KG”、“取数”で表現されるなら“枚/本”になります。（当然のことながら、当該材料においてはその全ての上位品目で統一されなければなりません。）
関連する項目として「換算単位」「取引単位」があります。

生産会社（工場）の一形態でＤＰＣ生産管理支援システムの適用対象社です。
ＤＰＣは協力工場様の運用に特化したシステムです。

ＤＰＣでは協力工場としての特性を次のように定義しています。
　　　　特定の得意先（親メーカ）から・・・・必ずしも１社とは限りません
　　　　定期的連続して
　　　　同一品目を繰り返し・・・・・・・・・・・・当然複数品目です
　　　　注文を受けて納入（受注生産）している生産会社をいいます。

コンピュータ・システム的な観点から見直すと

1. “同一品目を繰り返し”ということは

 

2. “特定の取引先”ということは

 

3. “定期的連続的”に受注データが送りこまれるということは

“物の移動”における４つのみなし取引のひとつを表す ＤＰＣ語 です。

　ある取引に伴い部品構成品完成工程の払出出庫を行います。
　同じ内容で材料変換がありますが次のように使い分けます。
　　　　構成展開：親品目１対子品目ｎで管理単位が変わらない（親１個で子２個使用）
　　　　材料変換：親品目１対子品目１で管理単位が変わる（親１個作るのに子（材料）を仕込重量で0.53kg使用）

“物の移動”における４つのみなし取引のひとつを表す ＤＰＣ語 です。

　工程連鎖の基本はある工程での取引（移動）が隣の工程の移動を励起させる動きです。
工程連鎖には、ある工程で作業実績による出庫移動があったときに次工程へ入庫移動させる”後工程連鎖”と、支給入庫されたときに直前の在庫場所から払い出される（出庫）”前工程連鎖”があります。

“物の移動”における４つのみなし取引のひとつを表す ＤＰＣ語 です。

　ある取引に伴い素材完成工程の払出出庫を行います。
同じ内容で構成展開がありますが次のように使い分けます。
　　　　構成展開：親品目１対子品目ｎで管理単位が変わらない（親１個で子２個使用）
　　　　材料変換：親品目１対子品目１で管理単位が変わる（親１個作るのに子（材料）を仕込重量で0.53kg使用）

受注データ取得時に連続置換を行う時の処理のひとつです。

　特に受注データが確定したときには通常個々の注文データを他と識別して特定する[注文番号]が付与されます。こうした中でその確定したはずの注文データも納期や数量の変更に取り消し等々注文変更が発生しています。
　この[注文番号]を特定しての変更処理が指示置換です。他の一斉置換や順次置換が既存データの削除と今回データの追加で処理しますが、指示置換での多くは削除＆追加ではなく更新処理になります。得意先によっては完結した変更データが来るのではなく、納期変更なら変更された[納期]のみ、数量変更なら変更された[指示数]のみが送られてくるケースもあります。

「運用をささえる３人」のうちの１人で、コンピュータ・システムを操作する時間の取れる人員をいいます。

　中小企業の場合なかなか専任のコンピュータ担当者を配置することは難しいです。当然システム導入時に担当者は決めるはずなのですが多くは現業との兼務になることも多いです。この場合兼務であってもコンピュータ操作の方が主業務でないと、現業の作業に引きずられてコンピュータ操作が後回しになります。そうするとコンピュータ・システムの運用が疎かになり結果として「動かないコンピュータ」になります。

“物の移動”における４つのみなし取引のひとつを表す ＤＰＣ語 です。

　実績把握の基本はある工程での取引（移動）に対して同工程のもう一方の動きを同数で発生させて常に在庫が変化しない（取れない）動きです。
工程によっては在庫移動の動きが入出庫の片方しか発生できないところがあります。例えば初工程は出庫移動になる実績入力はありますが、その品番での初工程入庫はありません。Ａ、Ｂ、Ｃの３構成品を使ってＤ製品を組み立てた時Ｄの組み立て報告（出庫）はありますが、“Ｄの入庫”はありえません。消費ないしは供給されるのはＡ，Ｂ，ＣであってＤという塊での加工場所への供給はないのです。
　すなわち常に出庫数（作業実績数）と同数の入庫数をみなし発生させることにより、常に在庫が“0”になってマイナス在庫になることはなくなります。“在庫が取れないならその処は管理しない”という考え方もありますが、全ての工程の出庫数はその処の実績数なので管理すべきと考えます。しかしながら出庫しか発生しなくて入庫がないとマイナス在庫になってしまうので実績把握という概念を導入して、在庫はとれないけれど実績は捉える処というものを作りました。

受注データの特性（精度）を表す ＤＰＣ語 です。

　協力工場での得意先からの確定注文（日別確定。通常期間単位の確定はない）の多くは注文をもらってからの生産では間に合わないくらいの短納期です。しかも納期の厳守は必達事項です。
こういう中で得意先も発注先に事前に準備してもらうために納期/数量の確定していない内示情報を事前に送ってきてくれます。
この内示も日別に指示される“日別内示”と期間（多くの場合は月間だが週間の時もある）単位での合計数を指示する“期間内示”に分かれます。

EDI受注データの取り込みでは置換keyグループ単位で、より新しい精度の上がったデータが来たときには、従前のデータを削除して、新たなデータを挿入します。（連続置換）
この時精度の基準がこの受注種別を細分した内示区分です。

受注データ取得時に連続置換を行う時の処理のひとつです。

　１件の月間計受注データに対して、より新しい同月の月間計であったり、当該月間を分割された日別データ等の新しい受注データ（群）で置き換えられるなら（一斉置換）問題ありません。
しかしながら１件の期間計データの一部に相当する日割りデータや、１件の確定注文（日別）に対して分割搬入指示が一度にではなく細切れに一部ずつ指示されるときには一斉置換することは出来ません。
なぜ一斉置換できないかというと、通常は新しいデータが来たときはそのデータに対応する既存の受注データは削除されて新しいデータが追加されるのですが、この新しいデータの内容が削除されるデータの一部に相当するならば本来の必要数より少なくなってしまいます。
もしくは元データの削除を当該期間の最終データが新たに来た時（翌期間のデータが来た時）に行うとすると（安全側には倒れますが！）期間最終近くでは本来の必要数の倍くらいになってしまいます。
　このため順次置換では単に元データを削除するのではなく、新たな細分データの[指示数]で元データの[指示数]を控除し、さらに元データの[納期]を細分データの[納期]の翌日にして、元データを更新します。
このとき細分データの指示数計が元データの指示数以上になったとき、そのまま引当無しで細分データを追加していくのか、もしくは次の期間の元データから引き落とすのかを決めなければなりません。
また元データのカバーしている期間が終了しても元データの指示数を引き落としきれなくて指示数が残っているとき、その段階で元データを無効にするのか、翌期間分の細分データも引き続き引き落としていって指示数が“0”になったら削除するのかを決めておきます。
　この決め方は個々の得意先の注文の出し方を検討した上での対応となります。

「運用をささえる３人」のうちの１人で、コンピュータ・システムを全社システムの一部に組み込み、その意味・方向性・レベルを認識して指示・指導・監査して最終的に責任を取る人です。

　実際の運用を行うには、人員再配置・職務変更・指揮命令等どうしても人のコントロールが伴うので同列の権限者のいないレベル以上の役職者でなければ実質的には難しいと思います。例えば総務部長を責任者にした場合、同じ部長職である製造部長や工場長がいたりしてなおかつその人たちが先輩・年長者だった時特に、指揮命令が充分に達せられないケースがままあります。（もちろん例外は多々あるとは思いますが！）
　すなわち社長・専務といった１人しかいない役職とか肩書きは別にして社長の子息（次期社長）といった方々が責任者になられて、単にお飾りでなるのではなく、熱い思いを持って責任者とともに二人三脚でシステムを引っ張らない限りシステムが定着して効果的に運用されていくことはないと思います。

受注データ取得時に連続置換を行う時に全品目削除＆追加ではなく、いま読み込まれた受信データによってどのデータが置換対象になるのかを特定する項目群を指します。

　この時”グループ単位”の基本は[品番]ですが、多くは[品番/納入先]の単位で得意先での発注データの制御（担当者による作成）を行っているケースが多いです。また得意先によってはさらに多くの項目を加えてグルーピングしていて、この単位で得意先の発注データ（ユーザにとっての受注）を置き換えていきます。このグルーピングする項目群が置換keyです。
例えばスズキs-netでは[品番/納入先]ですが、ホンダimpactでは[搬入場所/計画コード/色コード/搬入場所名6-13]といった内容になっています。
またこの置換keyのパタンを使って納期先行や子取引先の特定を行うための納入先情報を識別（特定）するためのパタンとしても使っています。（現在２３パタン）
連続置換で使うときは単に置換key単体で使われるのではなく、[親取引先/品番]と組み合わせてグルーピングされます。

「運用をささえる３人」のうちの１人で、コンピュータ・システムを主にお守りする人員をいいます。

　中小企業の場合なかなかコンピュータの運用知識（知見、ノウハウ）を持っている人を確保することは難しいです。操作する人がいれば“動かないコンピュータ”はなくなりますが、動いていれば使えているかというとこれは別問題になります。
当社の工場運営はどうあるべきで、今何が問題なのかを把握できる業務知識を持っている人がシステムの稼働を管理することが望まれます。この人がさらにコンピュータの知見も備えていると、人とコンピュータの使い分けが効果的に行えてコストを抑えながら効率的な運用が出来ることになります。

1984年10月に設立された中部ガスグループ（現サーラ・グループ）関連会社。
東三河にあるＦＡ系とＯＡ系の開発部隊を抱えるシステム・エンジニアリング会社。

ＵＲＬは　http://www.technosystems.co.jp/

 ＤＰＣ 協力工場向け生産管理支援システムの系譜からいうと
　　　　第八世代の「NEXUS8」・・・・NECのオフコンによるシステム
　　　　　　　　１９９１年９月～１９９５年１０月
　　　　第九世代の「NEXUS9」（DPC)・・・・初めてのＰＣ－ＣＳＳ
　　　　　　　　１９９５年１１月～２００６年１２月
　　　　第十世代の「nexus21」（DPC２）・・・・.net FrameWork上のＰＣ－ＣＳＳ
　　　　　　　　２００７年１月～
　　　上記３システムの版権保有開発会社になります

①物の取り扱うときの単位の一つで、「取引」時（多くは受入）に取り扱う数量が[取引単価]のせいで、在庫移動に使われる”管理単位”の値でない時に、”換算単位”をこの時の単位として使い、これを”取引単位”といいます。

【使用例】

1. 小物メッキのように在庫上の”管理単位”は"個"だが、[取引単価]は"KG"あたりの重量単価。
2. 鋼板/鋼材のような素材は、多くは[取引単価]は"KG"あたりの重量単価です。
   　　　この時在庫も重量で管理していれば換算の必要がありませんが
   　　　在庫の”管理単位”が定尺品目で"枚"や"本"の時は、”換算単位/取引単位”として"KG"を使います。

受/発注データの特性（精度）を表す ＤＰＣ語 です。

この精度を表すのに“1”から“9”まで想定していて、この精度は受注と発注のそれぞれにあります。（別のものです）

受注データでの[内示区分]は、受注種別のより細かな分類として設定されていて、
　　　　通常は内示区分＝“1”が　日別確定
　　　　　　　　内示区分＝“2”～“3”が　日別内示
　　　　　　　　内示区分＝“4”～“9”が　期間内示　として設定されます
　　　　この中で内示区分＝“4”は枠としては期間内示なのですが
　　　　　　特殊な使い方として“5”以降（通常は“5”）の期間内示を「受注分解」で日別データにしたときのコードとして使います。

協力工場での得意先からの確定注文（日別確定。通常期間単位の確定はない）の多くは注文をもらってからの生産では間に合わないくらいの短納期です。しかも納期の厳守は必達事項です。

　こういう中で得意先も発注先に事前に準備してもらうために納期/数量の確定していない内示情報を事前に送ってきてくれます。
この内示も日別に指示される“日別内示”と期間（多くの場合は月間だが週間の時もある）単位での合計数を指示する“期間内示”に分かれます。

品目/工程/管理部署別に把握される在庫場所の性格を表す区分。

　生産管理における在庫の移動は入出庫のパタンから「仕入」「支給」「検収」「納入」の４種あります。ところが実際の運用では買い取引である「仕入」と「検収」、売り取引である「支給」と「納入」の使い分けが難しい場面も考えられます。
　この時に“売り”と“買い”の指定だけで関与する在庫場所に対して入庫させるのか出庫させるのかを判定させる識別子です。この区分には次の３種類があります。
 

1. 社外在庫・・・・基本的には加工場所で“買い”で出庫される処です。
   　　　　　　　　　社外といっても外注先/仕入先のみでなく社内加工区も含まれます。
   　
2. 社内在庫・・・・基本的には加工を行わない処で製品倉庫や材料倉庫と中間留保と言われる工程間の
   　　　　　　　　　仕掛品置き場があります。
    
3. 実績把握・・・・初工程や支給を伴わない複数取引先のある中間工程等で基本は作業実績による出庫のみで
   　　　　　　　　　当該品番/工程では入庫データの発生がありえない処です。
   　　　　　　　　　出庫のみで入庫がなければマイナス在庫になってしまうのでシステムで自動的に同数の
   　　　　　　　　　反対移動を起こして常に在庫を“0”（在庫が取れない）にしてしまいます。

 

　物の移動は取引に従って起きるものが多い。この時ひとつの取引で１回の移動が発生するのだが、移動の発生した地点でみると“移動元での出庫”と“移動先での入庫”という２つの事象が発生しています。また仕入先在庫や得意先在庫は管理できない（する必要もない）ので考慮しません。
　この結果「販売管理システム」では仕入＝入庫、売上＝出庫という一取引一移動があたりまえとして捉えられていますが、生産管理の在庫では加工現場において必ず一取引二移動があります。この時ＤＰＣシステム上の約束事として”ひとつの取引で直接発生させる物の移動についての事象はひとつ”と定義します。
　そうしたときに仕入/売上（納入）のような一取引一移動のような取引は問題ないが、支給/受入（検収）では一取引二移動になります。この二移動目の動きを表す取引（移動）を“みなし取引”としてシステムで発生させます。
　ＤＰＣではこのみなし取引は次の４種を定義、実装しています。

1. 工程連鎖
2. 実績把握
3. 構成展開
4. 材料変換

ＤＰＣにおいてＥＤＩ受注データを日々取り込むときに、既存受注情報を今回受信データで過不足無く置き換えることを指します。

　すなわち受注情報は読み取り毎、ＩＤ毎に使うのではなく、すべてを一体のものとして新たなデータを取り込んだときには、それに伴って不要になるデータを削除し新たなデータを追加するか、新たなデータで既存のデータを更新します。
この新たなデータでの置換対象は[取引先/品番]での絞り込みは当然ですが、さらに[納入先]等から構成される[置換key]でグルーピングされた受注情報になります。
このことによって、受注情報を参照したときに最新の状態で本日から数日先までは精度の高い確定注文で、その先は日別内示、期間内示と順次精度が低くなりますが今受け取っている全受注情報を把握することが出来ます。

この連続置換するのには次の３つの処理があります
　　　　①一斉置換・・・・既存データを削除して、今回データを追加
　　　　②順次置換・・・・今回データを追加して、既存データを更新
　　　　③指示更新・・・・今回データで既存データを更新