プロセス参照モデル SCOR

　日経ビジネス　２０１１年２月１４日号（今のではない。先週のかな？）の
　Ｐ７４ページに、

「経営新潮流
　プロセス参照モデル
　業務を”共通言語”で可視化」

という記事があって、そこに、ＳＣＯＲ、ＤＣＯＲ、ＥＳＣＯＲなどが書かれている。

ＳＣＯＲとは、IT用語辞典バイナリによると(以下斜体はそこから引用）


SCORとは、サプライチェーンマネジメント（SCM）における共通のフレームワークやビジネスプロセスをまとめたモデルのことである。サプライチェーンマネジメントの普及・啓蒙を図る米国の団体SCC（Supply Chain Council）によって策定された。

SCORは生産品別に17項目の手順が設定されており、それぞれ計画プロセス（PLAN）、4段階の実行プロセス（SOURCE、MAKE、DELIVER、RETURN）、それらの実行を管理する手法（Enable）によって構成される。


だそうな。ほー・・・

サプライチェーンカウンシル日本支部
http://www.supply-chain.gr.jp/

に詳しく書いてあるらしい。

（サプライチェーンカウンシル日本支部＝ＳＣＣ日本支部については、上記日経ビジネスの記事中、７６ページ第一段「チャートは業務改善の地図」の３行下あたりから出てくるね
”９８年のＳＣＣ日本支部設立に参画したＮＥＣは、・・・”
のくだり）

Javaの画面表示－その１２：SWTによる画面表示(その２：１画面用のソース）

　シリーズJavaの画面表示のつづきです。
　現在は、ＳＷＴについてやっています。
　前回はＳＷＴとＡＷＴなどの違いについてと、インストール方法について書きましたので、今回は手順についてとソースと、問題点です。

　今回のは、あくまでも、第一画面のみを出す方法です。
　このとき、第二画面を出すと、おかしなことになります。

---

■手順
　ＳＷＴで、１画面だけ書く場合は、以下のような手順になります。

●はじめに(initAppData内）
１．DisplayとShellを取得します
２．各種部品を生成して、部品に対する設定をします
３．Shellをオープンします
４．表示されている間（isDisposed() ==false）以下のループをします
　　ディスプレイのreadAndDispatch()がfalseなら、スリープする
５．４の条件が成立しない（＝disposeされた）ら、ディスプレイもdisposeします
　　→これで終了する

●再描画（DispAppData）
　ＡＷＴのときと同じです

●終了（freeAppData）
　画面を消す場合は、disposeする

●内部クラスgamen1_HandleEvent（SelectionAdapterの拡張）
　　　のwidgetSelected(SelectionEvent e)
　ＡＷＴのactionPerformedとおなじ。

---

■ソース

　ということで、第一画面をまとめると、こんなソースになります。

import org.eclipse.swt.*;
import org.eclipse.swt.widgets.*;
import org.eclipse.swt.events.*;

import java.util.*;

public class gamen1 {
	
	//	共通領域
	public HashMap	map = null;

	//	モデル
	public Shori	shori = null;	
	//	画面項目項目
	Display		ff;
	Shell		f;
	Button		b1;
	Button		b2;
	Text		t1;
	
	int		seikai 	=	0;
	int		phaseNo	=	0;
	int		curno	=	0;

	/*
	 * 	生成
	 */
	public gamen1(HashMap map)
	{
		this.map = map;
		map.put("gamen1",this);

		this.shori = (Shori)map.get("shori");

		initAppData();
	}

	/*
	 * 	表示
	 */
	public void initAppData()
	{
		
		//	シェルを作成する		
		ff = new Display();
		f = new Shell(ff);
		f.setText("test");
		f.setSize(240,320);
		f.setLayout(null);

		//	アクションを作成する
		gamen1_HandleEvent al = new gamen1_HandleEvent();

		//	ラベル
		Label l1 = new Label(f,SWT.NULL);
		l1.setLocation(10,30);
		l1.setSize(100,30);
		l1.setText("早うちの練習");

		Label l2 = new Label(f,SWT.NULL);
		l2.setLocation(10,120);
		l2.setSize(150,30);
		l2.setText("これは、練習文です。");

		Label l3 = new Label(f,SWT.NULL);
		l3.setLocation(10,70);
		l3.setSize(100,30);
		l3.setText("以下の文を打とう！");
	
		//	テキスト
		t1 = new Text(f,SWT.NULL);
		t1.setLocation(10,160);
		t1.setSize(150,80);
		
		//	ボタン作成		
		b1 = new Button(f,SWT.NULL);
		b1.setLocation(120,70);
		b1.setSize(100,30);
		b1.addSelectionListener(al);
		b1.setText("挑戦する");

		//	ボタン作成		
		b2 = new Button(f,SWT.NULL);
		b2.setLocation(10,250);
		b2.setSize(100,30);
		b2.addSelectionListener(al);
		b2.setText("打ち終わった！");

		//	表示
		f.open();
		DispAppData();

	   	// ウィンドウが破棄されるまでループ
    	while (f.isDisposed() == false)
    	{
      		if (ff.readAndDispatch()	==	false)
      		{
        		ff.sleep();
      		}
	    }
    	ff.dispose();

	}

	/*
	 * 	再描画
	 */
	public void DispAppData()
	{
		//	画面間引数を受け取る		
		String rensyu = "";
		if ( map	!=	null )
		{
			rensyu	= (String)map.get("rensyu");
			if (rensyu	==	null )
				rensyu = "";
		}

		//	画面表示
		if ( t1 != null )
		{
			t1.setText(rensyu);
		}

	}
	
	/*
	 * 	終了
	 */
	public void freeAppData()
	{
		//	２度目にもとってきたときのため、初期化
		map.remove("rensyu");
		phaseNo	=	0;
		curno	=	0;

		String dis = (String)map.get("dispose");
		if ( dis == null )
			return;
		if ( dis.equals("yes")	==	true )
		{
	    	f.dispose();
			map.remove("gamen1");	
		}
	}
	
		
	/*
	 * 	イベントリスナー
	 */
	private class gamen1_HandleEvent 
			extends SelectionAdapter
	{

		/*
		 * 	ボタンが押されたときの処理
		 */
		public void widgetSelected(SelectionEvent e) 
		{

			Object o = e.getSource();

			if ( o.equals(b1)== true)
			{	//	挑戦する
				System.out.println("挑戦する");
				
				//======================//
				//	内容の取得     //
				//======================//
				map.put("rensyu",t1.getText());
				
				//======================//
				//	処理	      //
				//======================//
				if ( shori	==	null )
					return;
				shori.shori1();

				//======================//
				//	次の画面処理   //
				//======================//
				phaseNo	=	1;
				curno	=	1;
				DispAppData();
				return;
			}

			if ( o.equals(b2)== true)	
			{	//	打ち終わった！

				//======================//
				//	内容の取得     //
				//======================//
				map.put("rensyu",t1.getText());

				//======================//
				//	処理	      //
				//======================//
				if ( shori	==	null )
					return;
				shori.shori2();
				
				//======================//
				//	次の画面処理   //
				//======================//
				//	第二画面表示
				gamen2 g2 = (gamen2)map.get("gamen2");
				if ( g2 == null )
				{
					g2 = new gamen2(map);
				}
				else
				{
					//	再描画
					g2.DispAppData();
				}
				//	消す
				freeAppData();
			}
		}
	}
}

---

ただし、上記にも書いたように、これで、第二画面を出そうとすると、おかしくなります
（第二画面も、第一画面と同じ修正をしても、異常終了します）
それについては、次回のこのシリーズで。。。

経理システム開発のための財務諸表以外の業務処理－入金処理

シリーズ？「経理システム開発のための財務諸表以外の業務処理」の話、

１．資金繰り表

２．在庫

ときて、今回は、

３．銀行からの振込み

というか、一般的な入金処理の話について。

---

■入金の形態
入金は、
・現金を直接もらう
・銀行に振り込まれている
　　　手形が決済したもの
　　　だれかが振り込んだもの
・郵便振込み

なんていうかんじになるが、普通、お客さんが個人相手でなく、ＥＣなどをやっていなければ、現金でもらうか、銀行振り込みなので、問題はない。

　もんだいとなるのは、ＥＣの場合になる。

---

■ＥＣの場合の入金方法
ユーザーから見た入金方法は、こんなかんじ
・クレジットカード
・銀行振り替え
・郵便振替
・コンビニ決済
・代引き
・銀行引き落とし（会員制の場合）
・現金書留、郵便切手、現金為替（郵送して終わりのもの）


　これらを、ひとつひとつ対応してもかまわないが、普通は、集金代行会社（クオークなど）を利用する。

---

■いろんな集金方法のポイント
　前に一度まとめてるけど、もう一度

●銀行振り込み
　ただし、銀行振り込みの場合は、銀行のファームバンキングサービスを利用する場合もあるが、利用勝手（いつでもどこでも、なんかいでもファームバンキングで集金がみれるか、データフォーマットは電子化してくれるかなど）から、集金代行会社を利用することもある。

　なお、銀行振込みの場合、ぜんぜん関係のない人が振り込んできたり（会社の集金が個人名、親が振り込む、申し込む前に振り込んでしまっているなど）する場合があるので、仮に、番号をあたまに振って、それと一致させる形式の場合でも、一致しなかった場合のエラー処理は考える必要がある。


●郵便振替
　郵便振替は、自社でやる場合もある。
　このとき、郵便振替用紙を自社で印刷する場合なのだが、郵便局から、記入していない郵便振替用紙をもらって、その上に、金額などを印刷できた気がする。自信ない。詳しくは郵便局に聞いて！（大量の場合、すぐに用意できないと思った）


●コンビニ決済
　コンビニ決済の場合、用紙は業者が印刷してくれるケースと、自社でやる場合がある。
　自社の場合、バーコードに注意。プリンタによっては、１万枚くらいかなあ。。
　印刷していくと、直線が、じゃぎじゃぎになってくるやつがある。
　そーいうので印刷すると、バーコードは、おかしくなる可能性がないとはいえない。
　なんで、印刷してもらっちゃったほうがいいような気も。。。

●自動引き落とし
　銀行の自動引落は、自動引落していいよ！っていうのを書く紙があって（この紙に、銀行に出している印鑑をおすやつ）この紙をまず、お客さんに送り、お客さんが記入してもらったら、集金代行会社に送る。
　集金代行会社は、銀行にその用紙をおくり、銀行がチェックして初めて引き落としとなる。
　この間、１ヶ月以上かかる。したがって、１回きりの場合は、自動引き落としはつかえない。
　また、そうでなくても、１回目の集金の場合は、どうするかを考えないといけない。

●で、結局
　安全なのは、代引き、または、前金で受け取ってしまうものである。
　とくに、後払いで、ケータイなどだと、ケータイを変えられてしまうと、連絡が、郵便以外つかなくなってしまう（その郵便も、ホテルやウィークリーマンションで、住所かえられたらアウト）

---

■集金代行のポイント
　集金代行を使う場合、クレジットなどで、集金代行会社のサイトを呼び出すことになるが、その際、Perlでプログラムを組むとか、ＣＧＩで呼び出すだけとか、いろんなケースがあるので、それは、何社かきいてみて、比較すると良いかも。。。

　あと、集金代行を利用する場合、料金がちがう（売り上げに比例する部分と、固定的にかかる部分、いろんなケースがある）ので、それを比較する必要があるのと、個人事業主は利用できない（法人のみ）というケースがあるので、注意することかなあ。。

---

■注意すること

・返品の流れに注意する。
　返品した場合、集金してしまうと、相手が支払い拒否される形になる
　（このような場合、クレジット会社に支払い拒否というのが、できる。
　　返品したのに、回収すると、これが来る場合がある）
　で、これがおきると、何パーセント以上あると、集金代行会社があつかわないとか、ペナルティ金額が発生したりする場合がある。
　（なんていったっけーこれ。。忘れてしまった。ごめん）

　なので、返品された場合、お金を引き落としてしまうか（その場合には、あとから
銀行振り込みする）、こちらで、引き落としキャンセルできるかどうかを、はっきり
お客様につたえなきゃいけないことはもちろん、自社で、その管理がばっちりできないと
いけない。
　ＥＣでむずかしいのは、キャンセル処理だと思う。

・クレジットの場合の有効期間
　有効期間が過ぎたものは、洗い替えという方法を使って、引き落とすことができる
　（って、じゃあ、有効期間って何？っていうことになるが）。
　しかし、その洗い替えに対応しているかどうか、集金代行会社によってちがう。
　その点の確認はひつよう。
　→っていうのは、会員制で引き落としてしまう場合。
　　１回の場合は、有効なクレジットカード番号を入れてくれないと困るので、
　　（わざと無効なカードを言うようなやつはやばい）洗い替えの必要はない。　

・個人情報をどっちがもつか
　１回だけなら、カードを持っている人の情報を、会社側が持つ必要はない。
　なので会社側にカード情報を渡さない形で、集金代行会社のサービスを利用する

　ところが、会員制で、洗い替えをつかって、引き落とすビジネスをしている場合、
　カード番号などの情報は、会社でもつことになる。

　この、会社で、個人情報をもつか、持たないかで、サービスが違う場合があるので注意。
　問題を避けるため、１回で全額カードで支払うような場合は、会社に個人情報をもたない形のほうがいいかも。。

こんなかんじですかね。。

経理システム開発のための財務諸表以外の業務処理－その２、在庫

　シリーズものの、経理システム開発のための財務諸表以外の業務処理、その１の資金繰り表は終わったので今日は、在庫の話

　あ、そのまえに、トラックバックを削除しているので、みなさんには見えないと思うんですけど、資金繰り表の話を書いたら、「借金を一挙に返せる」みたいな話がトラックバックされたんですけど。。
　前回のお話は、「資金繰り」のお話ではなく、あくまでも、「資金繰り表」の内容と作り方のお話でした。はい。

---

　在庫って言うと、財務的な話より、在庫管理業務として独立した形になっていると思います。

　まず、在庫って言うと、

　　　・店頭在庫（お店に出ている在庫）
　　　・商品在庫（売り物の商品・製品が、倉庫に入っている状態の在庫）
　　　・資材在庫（製品を作るための部材の在庫）

　とあり、商業の場合は、店頭在庫と商品在庫の問題、
　工場（こうじょう、こうば、どちらでもＯＫです）では、製品在庫（＝商品在庫）と資材在庫が中心の話になると思います（ここで、商品とは、他社から仕入れたものを、そのまま売る場合で、卸・小売業に関係するもの、製品というのは自社で加工して売り物にしたものをさしています。一般に、そうじゃないかな？）。

　でも、経理の場合、処理はおなじなんで、これらをひっくるめて在庫としてしまいます。

　で，在庫にかかわるアクティビティは、こんなかんじ

日常業務
　・検品－入庫
　・ピッキング－出庫
　・試供品持ち出し（サンプル出荷）
　　→試供品として、商品そのものを、倉庫から営業が持っていくケースがある
　・試供品戻し（入庫）
　　→営業が持っていったサンプルをそのまま返しちゃうっていうケースもある
　・（売上）返品＝＞入庫
　・戻し（仕入れたものを仕入先に）
　　　→検品失格になったものの場合、入庫前に戻されるので関係ないが
　　　　委託販売で、期間が切れて戻す場合がある
　・破棄
　　　→本当に破棄したか、税務署に証明するため、写真が必要なこともある。
　・倉庫間移動

定期的
　・棚卸
　・棚卸減耗、評価損の計算
　・原価を求める

で、日常業務で、入出庫の数量がおさえられていると、あとは、仕入れ金額は仕訳からわかるので、仕入原価は、

・先入先出法
・後入先出法
・移動平均法
・総平均法
・売価還元法

　のうち、税務の場合は、どれをやるか決まりがあり、それ以外の方法でやるのであれば、届け出が必要になる。ので、税理士に聞けば、どの方法でやっているかは、答えてくれる。

　個数については、棚卸で、実地の数量をチェックし、棚卸減耗、評価損をもとめることになる。

　ただし、上記のように、商品を試供品として持っていっていかれて、それを渡しちゃったとしたら、その数量って言うのも把握しないと、試供品は仕訳が違うんでは。。。つー、はなしはある。
　また、移動平均の場合、随時求めることになるので、経理側で、仕入れ個数と原価を常に把握している必要がある。。。が、普通伝票に書いてあるけどね（＾＾）

　ただし、そこまで細かく考えないと、在庫システムがちゃんとしていてくれれば、仕入れ金額は仕訳していてわかるので、経理上は、あとは棚卸さえできれば、ＯＫっていうことになる。

---

　在庫システムの話になると、もっと奥は深い。
　数量だけ分かっててもダメで、場所がわかっている必要がある。
　そして、管理方法により
　　　・単品在庫管理（すべてのものにＮＯをふり、それで管理）
　　　・ロット別在庫管理（箱にいれたりして、ロットＮＯをふり、それで管理）
　　　・（等質のものとして）まとめて管理
　の場合がある。

　単品の場合は、そのものが、どこにあるか、
　ロットの場合は、そのロットが、どこにあるか、
　まとめて管理する場合、どこに、何個あるか
というふうに場所とむすびついてくる。

　なお、ロット管理の場合、ロット内のいくつかを出荷するというように、ロットの中まで管理できないといけないケースがある。

　また、場所（上記の「どこに」）については、
　　　倉庫レベル
　　　棚があって、棚の番号レベル
　　　コンテナ、パレットにいれ、コンテナ番号レベル
　と、いろいろなレベルがある。

　ただし、これは、一般論で、液体の場合（ジュース、お酒）は、ちと違うようだ。

---

　っていうことで、在庫の場合、着目点が
　経理システムだと、仕入れ単価と、数量
　在庫システムだと、数量と場所
　というように、ちと違っている。連携する場合は、全ての情報が必要で、この情報
　　　（仕入れ単価、数量、格納場所）
　の３つのデータが、連動して入手できるかどうかがかぎになる。
　（ただし、経理だけなら、場所は要らない。ないと、棚卸のとき大変だけど）。

経理システム開発のための財務諸表以外の業務処理－その１：資金繰り表

　前に書いたとおり、今回は、このシリーズ、資金繰り表について。

■目的

　資金繰り表は、将来、現金がたりるのかどうかを、確認するのに使う。
　たりなかったら、どっからか借りてくるか、なんかするか、会社を倒産するか。。
　てなかんじなので、銀行からお金を借りるときに必要なこともある。

---

■様式
　資金繰り表には、実績と、予定がある（なので、予測と実績の比較もできる）

　しかし、重要なのは、予定のほうで、実際予定しか作らない場合も多い。
　（過去を振り返らず、反省もしないつーことですな　＾＾；）

　で、様式は、予定も実績も同じで、４分法、６分法、８分法とある。。。とおそわるかもしれないけど、

　実際にはこのサイト

【　資金繰り表の雛型と作成実例　】
http://www.kvi.ne.jp/shikinguri12%20hinagata.html

　にあるように、

　営業上の現金受け取り＝現金で売上金をもらった、売掛金回収、手形回収など
　営業上の現金支払い　＝現金で仕入れた、買掛金支払い、手形決済、諸経費など

　と、

　営業以外の現金受け取り＝借金してお金が入った、自社株を売却した
　営業以外の現金支払い＝借金を返した、税金を払った

　に分けて書く方法が普通だと思います。

　このとき、お金の流れから見ますので、借金をすると、収入（借金してお金が増える）、借金を返すと支出になります。収入＝会社に良いものというわけではないので、注意です。

　それと，自社株を売却したのを売上に入れると、ホリエモンと同じになってしまいます。この手の仕訳違いは良くある話ですけどね。（銀行からの借金をしやすくするため、社長が、自分の資金（＝これもサラ金などから借りて手当てするっていう最悪のケースもあるが）を、資本金でなく、売上として組み入れるって言うのは良くある話だが、世間的に見ると、なんか、ホリエモンが極悪人になっているので、こーいうことをすると、極悪人になってしまうようだ。。。なお、サラリーマンのＳＥの人は、知らないかもしんないけど、こんなこと、日常茶飯事です）。

---

■つくりかた
　税理士に「作って」って言う。終了－
　なんだけど、それだと、石投げられそうな気がするので。。
　もちょっとまともに書くと。。

●実績
　実績は、簡単に作れる。
　総勘定元帳の「現金・預金」（あるいは「現金」と「普通預金」とわけてる？）や、「当座預金」をみると、そこに、現金と預金の出入りがあつまってるので、そいつを、上記の表にまとめて、いれてしまえばいい。
　仕訳から、総勘定元帳の作り方は、簿記の先生に聞くか、本を読むか（３級でやる）、ソフトがある場合は、マニュアルをみる（つーか、その前に、ソフトで資金繰り表がでないかどうか、確認してみる）


●予定
　こっちは、難しい。
１．まず、実績の最近のものと、１年前のものから、売上に関係しない項目を考える。

　　この項目は

　　・人件費（月給制、年俸制の分）
　　・家賃
　　・その他の経費＝＞通信費など
　　・受取、支払利息＝＞多少かわるので、５で補正する。
　　・（現状の）借入金返済
　　・税金
　　・その他、経費以外の支出

　このとき、最近２，３ヶ月のだけ見ると（税金や、お歳暮のように）、季節性があるのがぬけるため、注意する。

２．現状の売上に関する、資金の動き部分をチェック
　　もうすでに売上た分の売掛金の回収、手形回収や、売り上げるために仕入れた、買掛金の支払いや、手形決済、機械購入予定などをまとめておく（この値はあとで、記入する）

３．売上予測を立てる
　業種によって違うし、会社によって違うので、ここは、勝手に売上を想像（妄想？）してください。

４．売上予測から、その売上達成にかかる、もろもろのお金を出してくる
　売上たものの、現金収入、売掛、受け取り手形とその回収日、
　売り上げるために必要な仕入れと、買掛金、支払手形
　それと、人件費（時間制：パート・バイトなど）の分
　また、機械などの購入があれば、固定資産購入が変わる。

５．２と４を足して、うめる。また、売上に伴うほかの数字変化があれば、
　　変更する
　　受け取り利息など。

６．全部計算して、残高がマイナスになったらアウト。
　→借りてくる＝＞そうすると、借入金返済も変わってくるので修正
　　で、借りてくることになったら、どこから借りるか考える。。。などなど。
　　（それは、資金繰り表「作成」の範囲ではない）


なので、売上予測（目標ではなく、保守的に見て、これくらいという値）がでないと、これはつくれない。

経理システム開発のための財務諸表以外の業務処理

　まえに、経理、ＸＢＲＬシステム開発のための財務諸表作成業務の流れというのをやりましたけど、財務諸表には入らないけど、経理システムに関係してくるものがあるので、それについて、まずは、まとめてみます。

・資金繰り表
　中小企業などでつくるやつ。キャッシュフロー計算書と考え方はおなじかもしれないけど、実際のものは違う。

・在庫関連
　入出庫など。受発注にも関係するけど、棚卸で理論在庫と実地を比較し、財務諸表上に差分を反映する。

・手形関係
　わけて管理している場合もあるみたい

・入出金関係－銀行からの振込みなど
　現金出納帳がある場合もある。あ、それと、小口現金のインプレスト・システムのはなしもあるか。。
　でもそれより、銀行の通帳と、それと絡みで、銀行からの振込みで入金されたときのシステムについての話のほうが重要ですよね。

・セグメント別等の予算・実績管理
　個別ないし、総合原価計算と、差異分析の話なんだけど、対象業務によって、論点が違う。
　たとえば、工場なんかだと、総合原価計算になると思う。ここで、日商と全経で、労務費の扱いが違うわけで、日商は、バイトや派遣ベースの時給計算、全経は社員ベースなので。。ということがあるけど、そんなことは、たいした話ではない。

　で、ソフト業界なんかだと、個別原価計算になるわけなんだけど、そーすると、製造間接費の配賦基準の話なんかが問題になるかな。。とおもいます。

---

　あと、ＰＯＳのＡＢＣ分析は、販売のほうの話なんで、経理とは直接関係ないとして、今回はパス（経理の世界でＡＢＣというと、アクティブ・ベースド・コスティングの話があるんだけど、これもパスしておきましょ）。

　損益分岐点の話は、もう書いた。

　なんで、次は資金繰り表の話でも書いて、そのあと、在庫、銀行からの振込み、個別原価計算と製造間接費の配賦をソフトハウスを例になんていう感じで書いていきますかね。。

経理、ＸＢＲＬシステム開発のための財務諸表作成業務の流れ。

　最近、基本的なことを書いていたら、見る人が多くなった。
　ってことは、前にＸＢＲＬを取り上げたけど、もっと基本的な財務諸表をどうやって作るかという流れとか、そういうほうを書いたほうが、見てくれる人多いのかな？と思って、そっちを書いてみることにしました。

---

■まず、なにを出力するのか？から考える
　ってことが基本だと昔にブログに書いた記憶がある。

　そもそも、会計学は会社の管理資料を出す管理会計と、財務諸表などを出す会計とにわかれる。
　管理会計においては、会社の設備などの製造間接費をどういう風にプロジェクトに分けるか（製造間接費配賦）とか、プロジェクト、セグメントごとの会計とか、そーいう話題があるが、今回は管理会計の話題でないので、無視する。

　財務諸表をつくる会計は、相手先によって、まだまだ分かれる
　　　銀行さん＝財務諸表の貸借対照表、損益計算書のほかに、計算途中の試算表も
　　　投資家＝財務諸表、決算短信
　　　税務署＝所得税または法人税（財務諸表相当）、消費税

　投資家にだす、つまり、上場企業が出す、財務諸表＝有価証券報告書と呼ばれるものと、税務署に出す申告書は、ちと内容が違う。ただし、それは、元となる数字は同じで（同じじゃなきゃ困る。２つ帳簿があったら（＞＿＜！））、その表現の仕方（計算手法が）違うだけである。

　決算短信は、有価証券報告書の一部の数字を抜き出したもの。
　消費税の計算は、財務諸表とは関係ないものの、やはり、これも元となる数字は同じである。

---

■財務諸表の内訳
ふつうは
　・損益計算書（ＰＬ）
　・貸借対照表（ＢＳ）
　・キャッシュフロー計算書
　・利益処分計算書
からなります。このほかに計算書ではないけど、リスク情報をあげる。
また、上記は単体で、グループ会社の場合、連結したものを出すけど、
利益処分計算書に関しては、連結の場合、連結剰余金計算書という。
また、連結でくっつけちゃうと、全体しかわかんないので、セグメント情報を
ながす。

　このほかに、製造業だと、製造原価報告書っていうのがあって、これも付ける場合がある。

　ただし、税金の場合は、すこし項目が、違うケースがある。
　税金の場合、法人税は、別表４、５あたりに、これらの内容を埋めるので、そこを調べればいいことになる。

　個人事業主の場合、法人税になるが、白色と青色で異なる。白色は、ＰＬ相当しかいらない。青色はＢＳ，ＰＬ，どちらも必要。書く用紙があるので（１表と同時に添えるやつ。Ａ３を２つ折にしたようなやつ）、その用紙に従うことになる。

　会社も個人も、一定の基準を超えると消費税を払う。これは、また違う計算になる（本則と簡易課税でも異なる）。

---

■業務フロー

これらの計算は、いまでは仕訳を入れるとコンピューターがしてくれる。
なんで、中は、よくわかんなくていいが、昔は、こうやっていた

１．仕訳帳に日々の取引（仕訳）を書く
　　　（現金）１０，０００　（売上）１０，０００
　　などなど。。。

２．（大きな会社が手計算してた時代は）１日分の仕訳をまとめ仕訳日計帳に記入する
　→たぶん、今はしないんじゃあ。。（＾＾；）

３．総勘定元帳をつくる
　→ＸＢＲＬの世界では、これがＸＢＲＬ－ＧＬになる。

４．そこから、試算表をつくる
　→ＴＢといわれる。これは、コンピューターならすぐに作れるので、
　　銀行で、これを求められることがある。合計試算表、残高試算表の２種類あり

５．決算日のところでしめて（〆て）、財務諸表をつくる
　→まず繰延(くりのべ)・見越(みこし) 処理を行います
　　たとえば、１２月に買ったものは、翌月払いなら、まだ払っていません。
　　これらが未払いとして処理されます
　→ライブドアの総会で、この未払金の内訳は？と聞いていたやつが居たが、
　　そんなの、総会の時間で答えきれるわけねーだろ（＾＾；）
　　えーっと、文房具屋さんにいくら、電気代がいくらとか。。いうの。。。
　　そーいうのは、総会じゃないところでやってくれ！
　→あと、引当金処理とかして、単体の財務諸表をつくっていきます。
　→（１８：００追加）棚卸もします。
　　棚卸し処理のためには、入出庫の記録が必要な場合もあります

６．税務署の申告用紙を作る場合、各項目を埋めて（計算して）いきます
　→これはいまは、会計ソフトがやってくれるので、印刷するだけです。
　　たいてい毎年変わりますので、バージョンアップが必要です。
　　ちなみに、個人がやる場合は別表からつくって、最後に表紙に書き込む
　　という手順になります。
　　くれぐれもそのとき、用紙を折り曲げたまま、書かないように。
　　カーボン紙なので、不必要なところに写っちゃいますよ（＾＾；）

　→消費税の場合は、計算方法が違います。
　　本則の場合はいいんですけど、簡易課税の場合、何類かというのが問題に
　　なります。

７．大手企業の場合、単体の決算が全部出たら、連結の決算を出します
　→本支店処理といわれる処理をします。
　　これは、単体の合計をあわせた後、
　　アップストリーム（子会社から親会社への売り上げなど）、
　　ダウンストリーム（親会社から子会社への売り上げなど）
　　を消していく操作です

８．決算書をまとめ、株主総会にかけます
　　上場会社は、決算書を監査を受けて、株主総会にはかり、利益処分の承認
　　を得ます

９．決算短信を作ります
　　東証で発表されるときは、財務諸表は、有価証券報告書とよばれますが、
　　これが発表されるときに、決算短信というのをつくります。
　　→東証のＸＢＲＬのページ　http://www.tse.or.jp/listing/xbrl/
　　にあるＸＢＲＬの見本は、決算短信の１枚目です。
　　この１枚目の内容が、ロイターやブルームバーグなどですぐに報告され、
　　株式相場に影響。。。されるとは限りません。
　　なぜなら、株式相場終了後（３時以降）に決算報告する会社も多いからです。

---

■データ構造として分析するもの

　ということで、財務諸表関係で言えば、ふつうは、

　　税務署に出す財務諸表や消費税関係

　それにつけくわえ、上場企業は

　　東証で報告する財務諸表（連結も）や決算短信

　の構造を分析するのはもちろんですが、その入力となる仕訳、
銀行に見せる試算表、途中経過の総勘定元帳も分析しないと
いけないことになります。

---

■これをＸＢＲＬ的にみると、

　ところが、仕訳の内容で重要なのは、勘定科目です。
　この仕訳の勘定科目にもとづいて、総勘定元帳はできます。
　そして、総勘定元帳をもとに、試算表は計算できます。

　ということは、ＸＢＲＬ的にみれば、

　総勘定元帳のＸＢＲＬ＝ＸＢＲＬ－ＧＬと
　税金のためのＸＢＲＬや、
　証券市場用の財務諸表／決算短信のＸＢＲＬの

構造を調べ、ＸＢＲＬ－ＧＬからそれぞれ変換できるようにして、タクソノミを決めれば、
あとは、仕訳に勘定科目、金額、日付以外になにを備考として記入するか、
税務署に提出するのに、他に必要な事項は何か（これは、申告書をみれば書いてあるはず）
を分析するといいということになります。

ひえー、長い説明でしたけど、わかりましたあ（＾＾；）
　

日本版SOX法に向けた「内部統制対応文書作成ガイド」、マイクロソフトが公開してる

　マイクロソフトが、日本版SOX法に向けた業務プロセスの文書化を支援するための、「内部統制対応文書作成ガイド」を作成し、ダウンロード可能なように公開している。

　そのニュースリリースは、
ここ
●Microsoft(R) Office 2003活用ガイド「Visioで書く内部統制対応文書作成ガイド」の提供開始
～日本版SOX法対応に向けて業務プロセスの文書化を支援し、効率的な内部統制の確立を実現～
http://www.microsoft.com/japan/presspass/detail.aspx?newsid=2596

実際のダウンロードサイトについては、
ここ
http://www.microsoft.com/japan/office/visio/prodinfo/guide/sox/default.mspx
の一番下を見てください。

　「手順書ダウンロード」に「内部統制対応文書作成ガイド」があって、そのページからダウンロードできる。

　その下の、Visio 内部統制テンプレートは、公開準備中の予定らしい。

　で、ダウンロードしたファイルを（自己解凍形式のExeファイル）実行すると、ファイルとして、flow_diagram.docというＷｏｒｄファイルとサンプルのＡｃｃｅｓｓＤＢが入っている。

---

　そのflow_diagram.docにやり方が書いてある。
　よくみてないけど、Ａｃｃｅｓｓからの文書化手法になっている。

　ＳＯＸ法適用会社は、

・上場しているような会社
・大きな会社の子会社等、連結対象会社（中小もあり得る）
・将来、上場をめざすような会社

　ということで、ＡｃｃｅｓｓのＤＢとは限らないと思う（というか、そうでないほうが多い？？）。

　なので、その場合、既存ＤＢをＡｃｃｅｓｓにリンクしてやるということになるのかなあ？？？（詳しくは、わからん）

---

　ただ、中小企業でも、文書化したほうがいいわけであって、その場合、この手法を使うということは考えられる。その場合、中小企業は、ＡｃｃｅｓｓのＤＢにまず、帳票などの書類を落とし込んでということになるが、この手法に関しては、Ａｃｃｅｓｓでアジャイルで取り上げた手法（ここ、つづきはここ）が使えると思う。

　ただ、そーいうネタは、平日とりあげるような話なので、平日に、思い出したら、書きます。

会社の全システムの標準化、全体最適を求めるＥＡの導入理由を、ウィリアムのいたずら風に考える

そうそう、前回のブログでいきなりＥＡの話をしてしまったので、一応ＥＡとは何かのはなしから。

　ＥＡ（エンタープライズアーキテクチャ）について、こんなふうに定義されてますね。


　大企業や政府機関などといった巨大な組織(enterprise)の業務手順や情報システムの標準化、組織の最適化を進め、効率よい組織の運営を図るための方法論。あるいは、そのような組織構造を実現するための設計思想・基本理念(architecture)のこと。何らかのコンピュータシステムのアーキテクチャを示す用語ではない。


また、経済産業省のＥＡポータルサイトでの定義によると

　EAとは、「組織全体の業務とシステムを統一的な手法でモデル化し、業務とシステムを同時に改善することを目的とした、組織の設計・管理手法」です。政府の各府省、地方公共団体、独立行政法人での導入が進んでいるほか、民間企業でも活用されています

となってます。

つまり、簡単に言ってしまうと
・全社的な組織(enterprise)の業務手順や情報システムの標準化
・それによる組織の全体最適を目指す
っていうこと。

　ここで問題なのは、全社的にシステムを見渡して、標準化を行うということ。
　さらに、部門や、既存の現場の都合（効率化）で開発するのではなく、会社全体で、必要な仕事を考え、全体最適の立場に立って開発するもの。

　ウィリアムのいたずら的に考えると、いままでは、ＥＡは、経営戦略的な考えが中心だったと思うけど、今後は、個人情報漏洩の立場からも、ＥＡの導入は検討されると思う。

　つまり、全社的にデータを把握し、データ漏洩したとしても、すぐに、どこのデータが漏洩したかどうかがわかるようにする。さらに、データの全体最適を考え、どこの部署でデータを管理するのがいいのかを考える事が大事になると思う。
　中央で管理すれば、管理は便利。でも、漏洩したら、みーんなの分を補償。
　それならば、地域ごとに分散したほうが。。。とかね。

　で、もし、データ分散となれば、社内的にプログラムをあわせないと使えないし。。

---

　っていうことで、では、どのように導入したらいいのかということだけど、

　それはＥＡ導入ガイドラインに書いてある。

　そのサイトは、ここ

EAは、会社全体のモデルとして５つのモデルを考え（参照モデル）、このモデルにそって現状のＡｓＩｓモデルを作成し、またどうなるめきかのＴｏＢｅモデルを作成、そのＴｏＢｅに、どのようにしてなるかを考えていく。

　その参照モデルの５つのモデルとは、以下のとおり

1.業績測定参照モデル　（PRM：Peformance Reference Model）
　情報化投資の効果を客観的に評価するためのもの

2.政策・業務参照モデル（BRM：Business Reference Model）
　各府省の業務を横断的かつ機能的に、組織に依存せずに定義したモデル

3.データ参照モデル　　（DRM：Data Reference Model）
　業務で使用されるデータ/情報を各府省全体で総合的に定義したモデル

4.サービスコンポーネント参照モデル　（SRM:Service Component Reference Model）
　情報システム開発に利用可能なコンポーネントを分類したモデル

5.技術参照モデル　　　（TRM：Technical Reference Model）
　推奨する技術を分類したモデル

　前のＥＲ図は、「3.データ参照モデル」で利用することになる。

　ちなみに、それぞれのモデルにおける成果物は、ここに書いてあるが、詳しい説明や、実際の作り方についてのウィリアムのいたずらの考え方は、また別の機会に。

小売業や、サービス業における、標準的なエンティティ（その２：仕入れ側）

　今日は、以前、小売業や、サービス業における、標準的（通論的）なエンティティと分析方法のまとめ のなかで、販売側のイベントについて書いたので、今日は逆に、仕入れ側のエンティティを書きます。この２つをあわせると、小売、サービスの全体のエンティティになります。


その前に、昨日のアクセス数について
昨日９月１０日のアクセス数は、
１００３ＰＶ、６０９ＩＰで、アクセスランキングで１１９位でした！！
すごすぎ！なんで、こんなにアクセスが多かったんだろう。。。
それも、いつも、アクセス数のない土曜日に。。。
さっぱりわからん（？＿？）

---

　仕入れ側のイベント（業務）は、おおきく４つ考えれれます。
（１）新商品等の案内受け取り
（２）発注
（３）入荷・検品（仕入れ商品の）
（４）支払い（仕入れ商品の）

なぜ、４つといえるのか？というと、これは、民法からきています。
民法のたしか、契約のところだったと思うけど、売買契約というのは、申し入れ（この商品、買わない？）と、承諾（うん、買う、売って！！）というので、成立します。
　契約が成立すると、義務が発生します。売り手は、物やサービスを提供し、買い手はお金を支払います。これが、売買契約です。
　（１）が申し入れ、（２）が承諾で、契約成立、（３）が財サービスの提供で、（４）が支払いということになります（大体の区分であって、実態はちょっと違うことも多い）

---

　ちなみに、以前書いた、販売に、（１）の申し入れがない理由は、申し入れ部分は、システム化しないことが多いからです。
　たとえば、ラーメン屋さんの場合、（１）はメニューや、お店の前に出ているレプリカです。
　それって、あんまり変わんないし、システム化するようなものでもないです。
　お弁当屋さんもそうです。

　ただ、通販などにおいては、考えれれるのですが、日々の提携業務とは、別システムにすることが、多いと思います（カタログ作成は、普通、販売管理とは別）。

---

　で、リソースについてなのですが、またこんど書きます。

社長さんと、従業員のビジネスモデルの考え方の違いと、ソフト開発上の対応について

　土曜日のビジネスモデル的なお話が、意外と見てる人多かったので、今日は、その前提となる、

　社長さんと、従業員のビジネスモデルの考え方の違いと、
　ソフト開発上の対応について

を書きたいと思います
（ただし、社長さん＝管理者、従業員＝作業・プログラムする人と読み替えると、この業界の常駐派遣（請負？）につながる話でもあります）。

---

まず、実は、（自分でも、最近、放送大学大学院の番組を聴いて、気づいたんだけど）ビジネスモデルには、３段階あります。

（１）事業計画書などに書くような、何を売って、お金をどうやって、いつもらうというモデル
　　　→モノ（サービス）とカネの流れ、
　　　　ホリエモンみたいな人や買収話で出てくるところ。

（２）その事業を実現するために、誰が、なにをやるかという、業務モデル
　　　→ここで、ヒトと情報が付け加わる。
　　　　システムの業務分析は、ここ

（３）さらに、そのヒトに、いくら払ってという待遇などのインセンティブを決め、組織を作る
　　　→これ自体はビジネスモデルではない。
　　　　ただ、この部分がないと、ビジネスモデルが完成しない。

　で、社長さんなんかが決めるのは、まず、（１）の事業計画です。

　で、このあと、（２）をきめないことが多いと思います（あんまり、偉いヒトは、作業員のことなぞ、決めないというか、考えないのだよ。。）

　そこで、社長さんなどは、（３）の人集めに走ってしまいます。

　一方、一般に従業員が考え、実行するビジネスモデルっていうのは、（２）のことです。
　でも、事業のはじめに、（２）について、組み立てていないので（実は、ヒトが決まっていないので、組み立てられないということもあるが）、本当に、事業内容が、業務に落とせるかどうか、落とせたとしても、その人でできるかどうかは、わからないという状況にあります。

　逆に、既存の組織などで、（２）がしっかりしていると、同じ業種では、似通っているところも多いため、事業計画が多少変わっても、悪くても、売れてしまう（問題なくできてしまう）というところがあります。

---

　ということで、ベンチャー企業などでは、（いや、ベンチャーでなくてもそうなんだけどね）上層部が（１）をきめてから（３）にいってしまい、そこで満足しているため、（２）の業務内容はぼろぼろというところもあります。そうすると、システム開発側で、（２）の通論的な知識をもっていないと、話がゆらゆらゆれて、仕様が固まらないということがあります。

　アジャイルを好む企業は、実はこれ！なんていうことがあります。

　事業内容を組み替えても、必ずしもシステムを組み替えないといけないわけではなく、また、事業の詳細なコンポーネントは、不変なことが多いわけです（じゃないと、商奉行とか、弥生販売とか、成立しなくなってしまう）。だけど、（２）の部分が決まってないと、ゆれます。そうすると、仕様変更が頻繁に起こってしまいます。よくいう、「うち独自のやりかた」というのはなんてことはない「うち独自のごまかしかた」というケース（ただし、ごまかすとはいわれず、臨機応変に処理するとか、柔軟に処理するといわれる）

　ちなみに、じゃあ、開発では、（１）については、出てくるのかというと、出てきます。
　その店の商品構成とか、販売方法（支払い方法）などがそれにあたります。
　ヒアリングの中心は、（２）を聞くことですから、（１）に関しては、ヒアリング前に資料をもらって、調べておく必要があります（商品カタログと、帳票から調べられる）。

　そして、この内容は、用語集に載ります。

　なんとなく、とりとめのないはなしになってしまいました（＞＿＜！）
　なんで、とりあえず、ここまで。
　

小売業や、サービス業における、標準的（通論的）なエンティティと分析方法のまとめ

　ちょっと前のブログで、ER図を書くのに、通論をおさえておき、帳票などを見て、その通論にあるものないものをチェックして、それを付け足すと早いと書いた。

　その通論を導くのに、統一伝票って書いたけど、普通の人はやってられないと思う。ので、こんなかんじ！っていうのを、こっそり書いてみた。

　教科書ガイド的なもんなんで、こっそり見てね！

---

　小売など、消費者に対して、製品やサービスを提供する（いわゆる、ビジネス　とう　こんしゅーまーのBtoC）の場合、正規系の大きなイベントは、以下の３つ。

　　（１）注文（受注）
　　（２）受け渡し
　　（３）支払い

　なお、イベントとは、２つの判別法がある。
　　　１つは、はぶさんの書かれていた、「～する」といえるもの
　　　　（例：受注する、注文する、支払いする（支払う））、
　　　もうひとつは、佐藤正美（男性です）氏の方法で、「日時の属性をもてるもの」
　　　　（例：受注日、注文日、支払日OK）
　この２つは、たいてい一致する
　（一致しないものもある。　例：お茶　お茶する○　お茶日X：言葉があいまいだから）

　このほかに、細かいイベントとして、請求書発行などがあるが、はじめは、正規系だけで考え、ほかに必要なイベントが出てきたら、付け加える。

　異常系として、キャンセル／返品（返金）処理があるが、これは、正規系が決まらないとできないので、今回のせつめいからは、のぞく

---

　各イベントに対し、お店側の人間と、客側の人間がいる。したがって、エンティティは、

　　　　　受注者 -- 注文 --　発注者

　　　　　送り主 -- 受け渡し -- 受取人

　　　　　支払先 --- 支払い -- 支払い者

　と、そのイベントで取引される「モノ＝商品」と、それに対応する「おかね」となるはずだが、

　ここで、エンティティをまとめる際

　　（１）同一人物（同一カテゴリ）の場合、わざわざ、わけなくていい
　　（２）１対１で行われるイベントに対して（特に同時に行われるような一連の処理）、
　　　　　わざわざ、エンティティをわけなくてもよい。

　という特徴（傾向？サボり方）がある。

　また、匿名なものの場合や明らかに自明な情報は、システムに入ってこない。
　　　　その場合もエンティティがかかれないことがある。
　さらに、そのシステムにおいて、関心のないエンティティ（お金とか）は、かかれない。

この性質を使うと、実際には、以下のようになる。

---

＜＜飲食店や、お店の物売り＞＞

　注文と受け渡し、支払いが同時に行われる。
　したがって、分析結果が注文だけという形で書かれるケースもある。
　→この場合、エンティティ名は、「販売」のほうが、いいかもしれない。

　同時に行われない場合、エンティティを分けるケースもあるが、分けないで、注文エンティティの中にかかれることもある（お弁当の指定時刻受け渡しの場合、注文エンティティの中に指定時間とかかれることもある）。

　顧客に関しては、（ラーメン屋さんで、自分の名前を名乗らないように）匿名である場合がある（というか多い）この場合、顧客のエンティティを書かなくっても、問題はない。
　お店に関しては、自明なので、エンティティを書かないケースも多いが、（注文を受けた、受け渡した）担当者を記入することもある（レジなど）。

　たいていのケースは、
　　　　顧客＝発注者＝受取人＝支払い者であり、
　　　　お店＝受注者＝送り主＝支払い先である。
　そのため、エンティティは、お店と、顧客しか出てこない
　さらに、顧客が匿名の場合、顧客エンティティが、お店が自明な場合は、お店エンティティがかかれないこともある。その一方。受け渡しに関し、お店側の従業員名や、レジ番号が書かれることがある。

　これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。

　　　　お　み　せ　　　　　－　　販売（注文）　　－　　　　　　　お客　
　　　　｜　　　｜　　　　　　　　　　｜
　　　従業員　　レジ　　　　注文明細（＝注文ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　商　品

・レジのかわりに、飲食店だと、テーブルになったりする（テーブル番号）
・商品は、さらに、いろんなエンティティがつく
・商品の代わりにお金をうけとるわけだが、お金をエンティティとすることは少なく、その情報は、販売（注文）の中に入る。

---

　
＜＜通販／ECサイトなど＞＞

　注文、受け渡し、支払いがわかれるが、実際には、注文書の中に、受取人が違う場合の、受取人の場所を書かせたり、支払い方法を書いたりするので、販売というエンティティで１つにまとめてもかまわない。ただし、商品の分納や、支払いの分割を認めている場合には、エンティティを分けたほうが無難。

　注文の場合は、お店なので、省略されることもある。
　顧客が省略される可能性はかなり低い（届け先がわからない）。
　受取人は、省略されることもある。支払人は、省略されるケースとされないケースがある。
　（口座名義人の話とか、会社が支払うケースとか）

　支払い方法によっては、お店と、支払先が異なるので（支払先は、銀行とか）これが分かれることがあるが、送り主は、お客に明示しない（佐川か、ヤマトかセイノーか、いわないこともおおい）ので、エンティティとして出現しないことが多いとおもう。
　これらをまとめると、エンティティは、以下のケースを標準とし、場合によって、省略されることとなる。

　　　　お　み　せ　　　　　－　　販売（注文）　　－　　　　　　　お客　
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　注文明細（＝注文ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　　商　品
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　納品明細（＝納品ー商品対応表）
　　　　　　　　　　　　　　　　　　　｜
　　　　　　　　　　　　　　　　　納品（受け渡し）　－　　　　　（送付先）


　　　　支払先 －　　　　　　支払　　　－　　　（支払う人）　　　　

　なお、支払先は、クレジットカード会社、銀行などに分かれる場合もある。
　注文と受け渡し（納品）商品がまったく同じの場合には、納品明細はないが、分納の場合は、かならず（といっていいかな）ある。
　支払う人、送付先は、お客と同じビジネスモデルの場合は、これらのエンティティはあらわれない。

　納品（受け渡し）と、支払は、本来、販売にリレーションがひかれるが、絵の都合で引けなかったので、ひいてあるとおもってください。

---

　　

＜＜その他：一般的な考え方＞＞

一般的には、つぎのように考えていく

（１）イベントについて：
　　注文、受け渡し、支払いが、同時に起こる、もしくは一連のながれであり、
　　１対１に対応されるか？
　　→１対１なら、１つのエンティティでもかまわない。
　　　１対１でなければ、分けたほうが無難

（２）各イベントに対する登場人物に関して：
　　お店側の人間と、客側の人間にわかれる。
　　このとき、おなじ人は、省略可能。

（３）イベントにおいて、その登場人物間を介してやり取りされるもの：
　　ふつう、お金と商品、サービスだが、お金は省略される（金額以外の情報はあまり必要でないから）、ただし、これが商品券、チケットの場合は、そのエンティティは生成されることもある。
　商品のリソースと、注文のイベントを結びつけるため、商品ー注文対応表としての注文明細が発生する。
　なお、受け渡しと注文を沸けた場合、受け渡しー商品対応表としての、納品物明細が発生することもある。納品物明細と、注文明細は、かならずしも同じとは限らない（分納）
　さらに支払いエンティティを分けた場合は、支払い（うけとり）金額は必要だが、商品との明細はつけないほうがいい（つけると、物と金の関係が切りにくい）

　こんなかんじで考えていき、どの標準を使うかきめて、あとは帳票から、一致するところ、しないところを確認する。しないところは、本当に必要ないのか、たまたま抜けているのかを確認する。

---

　その後、標準的な属性の分析に入る。この属性にも、通論がある。

　その通論は、覚えていたら今度。。

ＥＣサイトの一般的なシステム構造と、考慮点をまとめたメモ

　昨日のブログで、通論の話をしたんで、ちょっとＥＣサイトの通論なんつーのを、今日はまとめてみました。

　まあ、昨日も書いたけど、今はオブジェクト指向全盛だから、この業界的に言うと、こういう内容をユーザーからヒアリングするっていう形が一般的であって、こういうノウハウを教える人たち、別の人たち（その一派がプチリタの人たちなのかあ？？）になるんだろうけど。。

　まあ、そんなうだうだ話は、さておき、ＥＣサイト通論
　メモなんで、抜け落ちてるところは、いっぱいあると思うよ。

---

ＥＣサイトは、だいたい以下の構造に分かれる

・Ｗｅｂ上の話
　　・ＤＢから、商品表示部分（ＤＢなければいらない）
　　・ショッピングカート
　　・決済（前払いのクレジットなどの場合）

・Ｗｅｂじゃない事務処理
　　・入金処理
　　・発送

・例外系
　　・キャンセル／返品／配送不能処理

ここで、考慮点は、
（１）ＤＢを持つか持たないか
　→持つ場合、商品表示部分はＣＧＩ：デザイナーを関与させるの大変
　　　持たない場合、ショッピングカートに商品名、価格を渡す。デザイン可能。
　　 →ショッピングカートの形式がかわる
　→ＤＢを使わない場合、直接ＧＥＴ型で、適当なデータを入れられるのに注意する

（２）集金方法
　昨日のブログに書いた。
　で、問題は、どのような集金代行会社を選ぶか。
　→個人の場合、使えない代行業者あり
　　ＣＧＩを呼び出すだけでＯＫな代行業者、ＣＧＩを作らないといけない業者
　　ざまざまあるので、ここの選び方で、開発方法が変わる

・継続の場合、クレジットの情報は、サイト側で管理することになる。
　この場合、ゼウスなど、契約が違うので注意
（ゼウスの一般的な使いかたは、サイト側に顧客情報を通知しない方法だか、
　この契約方法もある。契約の仕方が違う）。

　銀行口座から引き落としの場合、口座振替依頼書を送り、それを受け取ってからになる。第一回目の引き落としには、たいてい間に合わないので、第一回目の引き落としをどうするか、考える必要あり。

　コンビニ決済の場合、自社で、あの紙をだすと、バーコードが読み取れない危険あり

　なんで、宅急便、郵便の代引きがべんり。

　郵便振替用紙は、郵便局で、宅急便の送り状は、業者にいうと、くれた気がした
（自信ない。まちがってるかも）郵便振替は、電信と一般の違いに注意
　銀行口座に振り込んでもらうときには、馬鹿が多いのに注意
（なぜか、自分の口座名に振込先を書いてしまう馬鹿がいる。誰が振り込んだか、わからんだろう）

（３）キャンセルのワークフロー
　　代行業者との、集金のからみがある。

（４）訪問販売法など、法律のからみ
　・確認画面をだす
　・とくていなんとかなんとかにもとづくひょうじというのがある。
　・個人情報保護のからみ

（５）Ｗｅｂから事務処理のつなぎ
　・ここをつなぐと、自動化できる→するかどうか
　・ＤＢ直接書き込みにすると、サーバーは自社になる（たいてい）
　・メールでやるのであれば、サーバーはＣＧＩ（メール送信）
　　事務処理は自社（メール自動取り込み）という手もある。

（６）セキュリティ・バックアップ
　ＳＳＬでやる→ＣＡは？
　
その他
・発送に関しては、事務代行業者などもある。

次の業務を開始するタイミングと、実現方法のまとめ

　昨日のブログの最後「この場合は、ワークフロー制御を行うかんじでつくります。」について、その話の前に前提になる話。

　いくつかの業務がまとまってひとつの業務になっている場合、

　ある業務が終わったあと、次の業務を、いつ、どのように始めるかに関しては、大きく３つ考えられます（もっと、考えられるかもしれないけど、とりあえず）。

　・ある業務が終わったあとすぐに、次の業務を始める
　　→３つぐらい業務があったとき、最後の業務が終わったらすぐにというのも含めます。
　　　つまり、自動的に次の業務が起動されるというものです

　・ある一定時間が経過した後に、おこなう
　　→夜間にまとめて、今日の業務をどこかに転記するなどというケース
　　　通常、一定時間ごとに、バッチが動いて処理する形になる

　・業務の起動は、手動で行う
　　→業務の開始を行うための画面を作成し、そこから起動したり、
　　　該当のレコードを表示し、レコード中、選択したものに対して、実行する形などがある
　　　ＧＵＩまたはコマンドラインから、起動する

９０年代から今までのコンピューターの営業的キーワードは、いろいろ変わったが、同じこと言ってないか？

　前のブログで、情報化の効果として、「情報共有を密にできるようになった」というのが結構高い位置に来ている。

　で、考えてみると、ここ１０年間くらいのコンピューターの営業は、この情報の共有化という話題を、名前を変えただけで、いろいろいっている気がする。

　ということで、ものはためし、「９０年代から今までのコンピューターの営業的キーワードをならべ」てみましょう。

---

９０年代以前
　商業関係：汎用コンピューターによる処理（第三次オンなど）
　製造関係：ＦＡ

９０年代：オープンシステムという概念が始まる
　　→いまの日経システム構築が、日経オープンシステムという名前で創刊
　商業：ＳＩＳ
　製造：ＣＩＭ

その後
　商業：ＢＰＲ（ビジネスプロセスリエンジニアリング）
　　　　　↓
　　　　ＥＲＰ

２０００年ごろ
　いろいろ、細かいネタが出だす。ＣＲＭ、ＳＦＡ
　データ接続としてのＥＡＩ

最近
　ＥＡへ（ＩＴＩＬという話題もあるが）

もともとは技術なのに、こういうはやり文句の文脈でとらえられつつあるのが
　ＳＯＡ

---

　結局、手を変え品を変え、やろうとしていることは、情報の共有化。
　（ＳＯＡはちがうかもしんないけど）
　それを、（営業で売るためか）キーワードをつけて、はやり文句として、売っているのが現状かな？