FAH:Create Accounting(会計の作成) Part1.

「会計の作成」は、コンカレント・プログラムで登録されているが、実体はXML PUBLISHERである。かつ、内部的にBusiness Event Systemを使用していて、会計プログラムを発行する手前（？）でキューイングしている。キュー表はXLAスキーマの「XLA_ACCOUNTING_QTAB」。

DB停止障害の初期調査

簡単に確認できることなので、停止障害時には最初の手順として 先ず組み入れること

1. インスタンスが起動しているかを確認
       ps -ef  | grep <Oracleプロセス>

2. ログインできるかを確認
　　　sqlplus <user>/<pass>

3. リスナーに接続できるかを確認
　　　tnsping <接続文字列> <試行回数>
　　　lsnrctl status

4. alert.log

PL/SQL階層プロファイラ

PL/SQL Profilerが進歩し、いつのまにかPL/SQL階層プロファイラになっているとは。。。恐るべきPL/SQL.....

PL/SQL階層プロファイラ

PPT Architect Vs Pragmatic Programmer

年齢が上になるに連れ、リーダーとして、コーディングや実作業をすることは少なく、進捗管理や課題、リスク管理、チーム内見積作業の管理系タスクが 多くなる。例えば、課題においては、一発でクライアントに理解してもらえるわかりやすいPPTを作成し、論理的に対応策、そのPROS/CONSを説明し、厳しい質問にも冷静に回答する。提案作業も同様。オブジェクト指向のモデリングの結果が如何にモデリングとして今後の保守性を踏まえ素晴らしいかではなく、今回のシステム構築によりPSI計画の考え方がどのように代わりに、クライアントにどのようなポジティブな変化が発生するのか？

一方、現実的に見てきた世界として、往々にしてコアな技術的な人ほど、いいことを言いたいはずなのに、説明は長く、資料も偏り過ぎており、ビジネスが見えていないことが多い。ただ、それは説明や絵ごころといったコアスキルが欠けているだけであり、コアスキルが欠けている中においても特殊性を発揮している人はいっぱい居る。

これは、どっちがいいという話ではない。

我々が目指すとことはPPT Architectであり、達人プログラマーであり、クライアントへのサービスマン（SIサービス事業、コンサルタント・サービス事業）という 3つの柱を両立させることに真摯に挑戦するということだと思う。あまりにも、ロールにこだわり、自分の仕事の範囲を自ら制限することが多くなったと思う。

もったいない。 可能性を追求することが面白いのに。

XLA_EVENTS/XLA_AE_HEADERS Status Code

XLA_EVENTS 

[EVENT_STATUS_CODE]
 I - 未完了(Incomplete)
 U - 未処理(Unprocessed)
 N - 未対応(No Action)
 P - 完了(Processed) 

[Process_status_code]

D - Draft (GLに転送しないドキュメントモード)

E  - Error （エラー)

I  -  Invalid （検証エラー)
P  - Processed （処理中）
R  - Related event in error 　
U  - Unprocessed (未処理）

XLA_AE_HEADERS

[GL_TRANSFER_STATUS_CODE]

 N - 未転送(Not transferred)
 S - 選択された転送(Selected for transfer)
 Y - 転送済(Transferred)

GL Import

「GL_INTERFACE」に格納された仕訳明細データをインポートし、仕訳明細データが正常に取り込まれた後、Truncateを実施するが、データがエラーだったり、他のデータが残る場合（例えばGROUP ID等でパラレル化している場合）、Delete文を発行する。

和暦変換

select to_char(sysdate,'eeyy/mm/dd','NLS_CALENDAR=''Japanese Imperial''') 
from dual;

忘れがちなので、とりあえず。

Zチャート

月々の売上、売上累計、移動年計の3つをあらわしたグラフ。売上げの微妙な変化（月間、季節要因）を分析することが可能である。