DPC用語集

一斉置換(イッセイチカン)

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

EDI(イーデーアイ)

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

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

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

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

運用をささえる3人(ウンヨウヲササエルサンニン)

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

SNS(エスエヌエス)

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

MRP(エムアールピー)

・資材所要量計画を参照してください
・資材所要量計画(しざいしょようりょうけいかく)とは工場などで使われる生産管理手法の一つ。
MRP(Materials Requirements Planning)とも呼ばれる。

・資材管理で生産を計画する手法のこと。
 その概念を発展させて
 資材以外の人員、設備など製造に必要なすべての資源を管理する仕組みをMRP2という。

 さらに、企業全体の在庫、決済、資産の管理を行うようにしたのがERP(企業資源計画)である。
 (以上出典:Wikipedeia)

①DPCでは「引当計画」として品目単位ではなく工程単位で(後工程から前工程に向かって)
MRP展開ロジックで使われる総所要量計算/先行計算/純所要量計算/計画取り纏め をLevel by Levelで常に実績在庫に立ち戻って運用する形で実装しています。

このためDPCにおいては品目途中の仕掛かり工程在庫を残したままの計画も立てられます。

管理単位(カンリタンイ)

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

関連する項目として「換算単位」「取引単位」があります

協力工場(キョウリョクコウジョウ)

①生産会社(工場)の一形態でDPC生産管理支援システムの適用対象社です。
というかDPCは協力工場様の運用に特化したシステムです。

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

③コンピュータ・システム的な観点から見直すと
    ”同一品目を繰り返し”ということは
        事前に「マスタ登録」が出来ることであり
        「個別受注生産システム」において、毎回異なる(似たようなものであっても)品目を取り扱うために
        受注入力時に「マスタ登録」も出来るようでないと機能しない枠組みとは違います。
    ”特定の取引先”ということは
        取引開始にあたって基本契約が締結されていたり、継続的な取引による信頼関係の上で
        本来ならば実取引の開始前には決定されているはずの[取引単価]が未定/仮であったり
        確定注文を受けてから諸段取り・生産の開始を行うはずなのに
        納期的には絶対間に合わない短納期の確定注文が通常なので
        内示で作って確定で出荷することになります・・・・このギャップ進捗を追いかけることが必須です
    ”定期的連続的”に受注データが送りこまれるということは
        1つの注文(納品出荷作業)に絡む注文データは1件・一回こっきりではなく
        大日程/能力検討のような数ヶ月先の月計予定から始まって
        2~3ヶ月先の三発内示(月計)、(週間内示)、日別内示ときて
        最終的に日別確定注文及び便別/時間指定の搬入指示と
        何回も繰り返し順次精度を上げながら注文データが送られてきます
        このために協力工場における「EDI受注処理」では
        単に受信データを取り込むだけでなく過不足ない最新状態にするための連続置換処理が必須です

構成展開(コウセイテンカイ)

①”物の移動”における4つのみなし取引のひとつを表すDPC語です。
 ある取引に伴い部品構成品完成工程の払出出庫を行います。
 同じ内容で材料変換がありますが次のように使い分けます。
    構成展開:親品目1対子品目nで管理単位が変わらない(親1個で子2個使用)
    材料変換:親品目1対子品目1で管理単位が変わる(親1個作るのに子(材料)を仕込重量で0.53kg使用)

工程連鎖(コウテイレンサ)

①”物の移動”における4つのみなし取引のひとつを表すDPC語です。
 工程連鎖の基本はある工程での取引(移動)が隣の工程の移動を励起させる動きです。
 工程連鎖には、ある工程で作業実績による出庫移動があったときに次工程へ入庫移動させる”後工程連鎖”と、支給入庫されたときに直前の在庫場所から払い出される(出庫)”前工程連鎖”があります。

材料変換(ザイリョウヘンカン)

①”物の移動”における4つのみなし取引のひとつを表すDPC語です。
 ある取引に伴い素材完成工程の払出出庫を行います。
 同じ内容で構成展開がありますが次のように使い分けます。
    構成展開:親品目1対子品目nで管理単位が変わらない(親1個で子2個使用)
    材料変換:親品目1対子品目1で管理単位が変わる(親1個作るのに子(材料)を仕込重量で0.53kg使用)

指示置換(シジチカン)

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

時間のある操作者(ジカンノアルソウサシャ)

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

実績把握(ジッセキハアク)

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

受注種別(ジュチュウシュベツ)

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

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

順次置換(ジュンジチカン)

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

力のある責任者(チカラノアルセキニンシャ)

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

置換key(チカンキー)

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

知識のある管理者(チシキノアルカンリシャ)

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

テクノシステム株式会社(テクノシステム)

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

URLは http://www.technosystems.co.jp/

DPC協力工場向け生産管理支援システムの系譜からいうと
    第八世代の「NEXUS8」・・・・NECのオフコンによるシステム
        1991年9月~1995年10月
    第九世代の「NEXUS9」(DPC)・・・・初めてのPC-CSSシステム
        1995年11月~2006年12月
    第十世代の「nexus21」(DPC2)・・・・.net FrameWork上のPC-CSSシステム
        2007年1月~
   上記3システムの版権保有開発会社になります
 

DPC(デーピーシー)

aily Production Control の略で協力工場向け生産管理支援システムの名前です。
DPCシリーズにはテクノシステム(株)からOEM供給を受けたDPC(NEXUS9:1995-2006)、DPC2(nexus21:2007-)とニッコウプロセスが版権を保有する自社開発によるDPC-Ⅲ(2012-)があります。
 最新シリーズであるDPC-Ⅲが含まれるDPCfamilyには規模によってμDPCDPCminiDPC-Ⅲと他の基幹システムとの連携を図るDPCessentialがあります。また外部取引先との連携や現場でのデータアクセスのためのWeb-DPCも構想されています。

②DPCはニッコウプロセスとの販売パートナであるコムエンジニアリングおよび電興社の頭文字を繋げた、という噂もあり。
 
 

DPC語(デーピーシーゴ)

①協力工場向け生産管理支援システム「DPC-Ⅲ」はじめDPCfamilyおよびその前進システム群で使われる概念およびそのことを表現する単語です。
 全くの新しく作られた言葉というのはほとんど無く、これまである言葉に新たなもしくは狭義の意味合いを込めた言葉であったり(例:途中工程)、複数の単語を組み合わせてある特定の意図を表現したりしたものです(例:工程連鎖)。
 これらの言葉は通常でも出てくる単語なので、意図/意味がずれて解釈されてしまって結果として正しく理解されないということもありえることと思います。このことに対するサポートの一部として『用語集』を作成しました。

取引単位(トリヒキタンイ)

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

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

内示区分(ナイジクブン)

①受/発注データの特性(精度)を表すDPC語です。
この精度を表すのに"1"から"9"まで想定していて、この精度は受注と発注のそれぞれにあります。(別のものです)

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


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

入出庫区分(ニュウシュッコクブン)

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

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

nexus(ネクサス)

①英単語"nexus"は、「連結」「連鎖」「繋がり」などを意味する名詞。

DPC-Ⅲに連なる協力工場向け生産管理支援システムの8世代目から10世代目のシステム名。
 nexusシリーズには、NECのオフコン上で動いたNEXUS8(1991/09~1995/10)、初めてPC上で動いたNEXUS9(1995/11~2006/12)、PC2世代目になるnexus21(2007/01~)の3システムがあり、いずれもテクノシステム株式会社の開発によるシステム。
 当システムは生まれた時から協力工場向けの専用システムとして育ってきたので、時と物の流れを追いかけてきました。このための前後(時と場所)の繋がりを非常に意識していてみなし取引においても工程連鎖という概念を導入しています。ここからシステム名に”nexus"と名付けました。

③ニッコウプロセスではテクノシステムとのOEM契約により、NEXUS9は「DPC」、nexus21は「DPC2」として
販売・導入支援・運用保守・顧客カスタマイズを行ってきました。

Google Nexus(グーグル ネクサス)は、Googleが、選定したハードウェアメーカーとの協力の上で発売しているAndroid搭載端末のブランドである。
 「純粋なAndroid」としてのユーザーエクスペリエンスを目指すことを目的として、さらなる発展やエンドユーザーによる改造を可能にするためにキャリアや製造元による改造やロックを解除できるブートローダーを自由にしている。(④出典:Wikipedeia)
 2012/06に7inタブレットNexus7ASUSより発表されました。

programID(プログラムアイデー)

①DPCにおけるプログラム1本1本の識別コードです。
 基本は8桁の構成で次のようになっています。
     P ② ③④ ⑤⑥ ⑦⑧
      P:DPC-Ⅲのプログラム
      ②:サブシステム識別
      ③④:連番(プログラム識別)
      ⑤:偶数(ex."0")は起動部
        奇数(ex."1")は本体部
      ⑥:設変番号(基本は"0")
      ⑦⑧:ユーザ識別・・・・DPC基本プログラムにはないので6桁になります
 ②のサブシステム識別は次のようになっています
      A:マスタ管理
      B:受注/出荷管理
      C:生産計画
      D:材料手配
      E:取引作成
      F:取引先管理
      G:在庫管理
      H:進捗管理
      J:ロット管理
      K:検収処理(売上照合)
      L:部門経費
      M:金型管理
      N:売上予測
      P:実績工数
      Q:不良管理
      R:原価管理
      S:スケジューラ
      T:汎用伝発
      V:マスタ移行
      W:システム保守
      X:システム・モジュール
      
      

みなし取引(ミナシトリヒキ)

 物の移動は取引に従って起きるものが多い。この時ひとつの取引で1回の移動が発生するのだが、移動の発生した地点でみると”移動元での出庫”と”移動先での入庫”という2つの事象が発生しています。また仕入先在庫や得意先在庫は管理できない(する必要もない)ので考慮しません。
 この結果「販売管理システム」では仕入=入庫、売上=出庫という一取引一移動があたりまえとして捉えられていますが、生産管理の在庫では加工現場において必ず一取引二移動があります。この時DPCシステム上の約束事として”ひとつの取引で直接発生させる物の移動についての事象はひとつ”と定義します。
 そうしたときに仕入/売上(納入)のような一取引一移動のような取引は問題ないが、支給/受入(検収)では一取引二移動になります。この二移動目の動きを表す取引(移動)を”みなし取引”としてシステムで発生させます。
 DPCではこのみなし取引は次の4種を定義、実装しています。
    ①工程連鎖
    ②実績把握
    ③構成展開
    ④材料変換

連続置換(レンゾクチカン)

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

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

換算単位(カンサンタンイ)

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

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

お困りのこと、ニッコウプロセスがお力になります!
メールフォームはこちら