|
|
 |
|
Wiki | |
|
updated on 2004.06.23 |
||||
G/L SYSTEMのリカバリーについて | |||||||||
|
Q.年次繰り越し処理は、
という処理の流れを持つが、この中で、「④損益振り替えデータ」を作成し忘れ、「⑤損益振替えの転記更新」をしないまま、「⑥年次更新」以降の処理をしてしまった。どのようにすればいいのか。 Ans. 損益振替え転記更新は、当期未処分利益を集計するとともに、集計対象となった収益や費用を、次期会計年度用に、（振り替え操作により）ゼロに戻す作業ですので、これをしないわけにはいきません。（詳しくはマニュアル「損益勘定振り替えについて」を参照して下さい。） これを忘れた場合、年次更新（各勘定の年の繰り越し処理）や会計年月の繰り越し（現在何月分の処理をしているのかの判定基準の繰り越し）はすべて無意味なものになります。そこで、 ¨ 「③ホスト送信」まで戻す ¨ 「④及び⑤ 損益勘定振り替えの処理」をする ¨ 再び「⑥年次更新」をする ¨ 再び「⑦会計年月の繰り越し」をする というのが、リカバリーの大まかな処理の流れになります。 マニュアルの「データバックアップのタイミング」を見るとわかるように、年次更新におけるバックアップは処理の前に行われているので、「GLYEAR」とラベルの付いている磁気テープからデータを戻すことになります。 ここで気をつけるべきは、もし１２月の年次更新後（このデータを吸い上げた後）、新規にバウチャーを入力していると（例えば１月分の先行仕訳けなど）、バックアップを復元することで、それらも「年次更新の日に戻る＝データが消える」事になります。この影響が多いのか、少ないのかは、失われたデータと消したはずのデータが生き返る数により経理部の方に判断してもらいます。（再入力、再修正してもらう方が楽です。）この点に注意して作業を進めてください。 今回は、バウチャーのデータはその最新更新日を参照して、戻すことにしました。以下は、96/02/15の実際の作業のログです。 リカバリーの際の注意事項 12月最後の損益勘定用のバウチャーを作成する時のシステム番号と、翌期の1月分のバウチャーのシステム番号が重複しないように気を付けてください。この番号は、欠番や順番は関係なく、バウチャー１枚に対応する「識別」に使用されているため、重複はすべてのシステムをおかしくします。システム番号はG/Lシステム内で完全にユニークな15桁の連番の数字で、データエリアGLSYS#が管理しています。バウチャーを一件入力すると、このデータエリアの数字を取り出し、＋１して戻します。データの復元により、古いGLSYS#が復元されると、損益勘定用のバウチャーが自動作成されるときもこのGLSYS#を参照するため、翌期の1月分のバウチャーと同じシステム番号が付番されてしまいます。翌期1月分のバウチャーの最後のシステム番号（つまり、復元前のGLSYS#を）必ずどこかに残して、後で参照できるようにして下さい。 また、転記更新の度にバッチ番号がカウントアップします。これも、 G/Lシステム内で完全にユニークな15桁の連番の数字で、データエリアGLBATCHが管理しています。しかし、今回の例では、新たに転記更新をしていくので、GLBATCHの番号はなすがままにしておいて大丈夫です。
A) 年次更新を実施した日付を確認します。 今回の年次更新の実施日は1996/02/09。この日は、バウチャー入力をしていなかった（偶然）。この日のバックアップを戻すので、この日以降の追加バウチャーが消える運命にある。もし02/09にバウチャー入力してある場合は、年次更新後に入力されたバウチャーを探し出すか、若しくは、この日の分だけは、後で手入力してもらう。 B) 今入力されているバウチャーのプルーフリストを出力しておきます。年次更新のとき出る、リスト（磁気テープの内容印刷など）は印刷して手許に置いておきます。（これらは、リカバリーの際の検証に利用します。） C) 転記更新のアップデート選択があれば、選択画面で選択フラグをはずして未選択に戻します。 バックアップするファイルに更新選択フラグがついたたま、となってしまうため。 D) 先行仕訳けが、仕訳け月到来となっているはずなので、これを戻します。これを行うプログラムは正規のシステムには存在しません。 GLVCHTPのG5JAV2がYならば、G5JAVにYを付けて、G5JAV2を空白にする。（GLU070参照）。尚、この時、これを解決するために、GLU999を作成した。 E) リカバリー前のバウチャーファイルを本番以外のライブラリーへバックアップします。重要！ GLVCHTP (PF) GLVCDTP (PF) GLVOUMP (PF) GLSYS# (DTAAARA) GLBATCH (DTAARA) をオンラインで（誤って更新用にプログラムが参照しないように）名前を変えて、バックアップする。今回、各ファイルやデータエリアの名前の、頭２バイトを取り除いた名前をバックアップ用に使った。この方がわかリやすいと思う。 EX) CPYF GLDBFD/GLVCHTP temp/VCHTP CRTFILE(*YES) F) GLDBFDHST(現行業務では参照しないが、年単位に履歴として保管しているファイルのライブラリー)の中の以下のファイルを削除します。これらは、年次更新の中で作成されます。ファイル名は、1995年の年次更新の際ならば、xxx1995といなっています。仮に、1996年の年次更新のならば、xxx1996となります。後で、年次更新を再びするので、これらのファイルは不要です。 今回は1995年の年次更新で作成されたものを削除するので、ファイル名はGLDBFDHST / xxx1995です。 DLTF GLDBFDHST/GLACTM1995 DLTF GLDBFDHST/GLBATM1995 DLTF GLDBFDHST/GLJRHM1995 DLTF GLDBFDHST/GLJRHM1995 DLTF GLDBFDHST/GLU0401995 DLTF GLDBFDHST/GLVOUM1995 G) ライブラリーGLDBFDとGLMSTを磁気テープGLYEARより復元します(RSTLIB)。 これで、年次更新前の全データが復元されるが、年次更新後のバウチャーの変動は消えてなくなってしまう。また、システム番号も年次更新前に戻ってしまうことに注意。本来、このまま更新して、年次更新後のバウチャーは再度入力してもらえばいいのだが、翌期分の先行仕訳けがかなり多かったので、これをなんとかしたかった。 H) E)で作成したバックアップのデータ中、最新更新日付（日付はこれしかなかった）を元にデータを追加して複写する。これで、システム番号は最新になり、新規のバウチャー（損益振り替えも含む）の追加が可能となります。 CPYF temp/VCHTP GLDBFD/GLVCHMP MBROPT(*ADD) INCREL(G5UDAT *GE 19960209) CPYF temp/VCDTP GLDBFD/GLVCDMP MBROPT(*ADD) INCREL(G6UDAT *GE 19960209) CPYF temp/VOUMP GLDBFD/GLVOUMP MBROPT(*ADD) ERRLVL(*NOMAX) .. このファイルはUNIQUEキーなのでこれでよい。 GLSYS#は上記のファイルと整合性を取るように、番号をアップデートしておく (CHGDTAARA)。 （E)でバックアップとして作成したGLSYS#の内容と同じ番号を本番のGLSYS#にセットする） I) 95/12月の最終T/Bと、画面で照会出来る総勘定元帳の内容が一致しているか検査します。仮勘定を利用すれば早く確認できます。これが違うと、損益振り替えもおかしくなります。 違っている場合 ファイルをそのまま復元しているので、違うとすれば、復元がうまくいっていないか（エラーなのにうまくいったと勘違いしている）、又は参照するT/Bが古いもの（T/B出力後、転記更新をしなおして、新しいT/Bを印刷していない。）か、どちらかのはず。T/Bを再度現状から出力して、食い違う部分を再度洗いなおす。合うまで、先に進めてはならない。 これで、年次更新前の状態で、かつ、最新のバウチャー（ここでは先行仕訳）が入力されたことになる。但し、後に述べるように、年次更新の後で、バウチャーの削除などをしても、削除された時点よりも前の状態が復元されるので、これらは生き返ってしまう。 J) 損益振り替え作業を通常どおり行う。損益振り替えバウチャーからの未処分利益とT/Bの値を比較する。 違っている場合は、T/Bのリストが古いはず。この損益振り替えのデータは総勘定元帳からバウチャーを作成しているので違うはずがない。現状のT/Bを再度出力して食い違いを検査する。これが完了するまで、損益振り替えの転記更新をしてはならない。（損益振り替え用バウチャーは何度でも再作成できる。但し、不要となった損益振り替え用のバウチャーは削除すること。） K) 損益勘定振り替え更新をする。（通常の転記更新の手順とおなじ。） L) 1995年12月の年次更新をする。 M) 95/12から96/1への会計年月の繰り越しをする。 N) 繰り越されたら、96/1（新しい期）のバウチャーの内容検査をする。 96/1のバウチャーをすべて出力して、検査する。最初に出したバウチャーのプルーフリストとここで出したプルーフリストは同じものになるはず。リストの最後に出てくる、合計金額や明細行数を照らし合わせると楽です。但し、G/Lシステムにとってバウチャーは重要なデータですので、念には念を入れて検査すべきです。経理の人に検査してもらうべきでしょう。 実は今回ここだけが狂っていた。ここで出したプルーフリスト上に、重複するバウチャーが出て来た。また、バウチャー入力者が、削除したはずのバウチャーが生き返っていた。 これは、96/02/09以降に削除されたデータが、復元操作で復元され、これを削除することなく、データの追加のみをしたため、重複したり、生き返ったりしてしまった為である。 これらすべてのデータは、先に述べたGLSYS#により、たとえバウチャー番号が重複していても、一個一個識別可能なので、プルーフリストの右端のシステム番号を見て、（プルーフリストに削除のマークをつけておくと後で役立つ）、DFUでGLVCHTPとGLVCDTPの該当レコードを削除する。（GLSYS#に欠番があってもいっこうに構わない。） さらに、GLVOUMPの中のエントリーで、削除したはずのものが存在したら消すこと。重複を許さないファイルなので、バウチャー番号がこのファイルの中に２つ以上あることはない。しかし、削除されたはずのものはバックアップ復元で元に戻ってしまうので、これを削除せねばならない。このファイルは、使用済みバウチャーの番号が入るファイルなので、バウチャーを削除するときは、このファイルのレコードもメンテナンスしなくてはならない。なぜなら、これをしなければ、削除されたはずのバウチャー番号をもう一度入力しようとした時に、データ上に存在しないのに、既に使用中のバウチャーとして、入力エラーとなってしまうことになるからである。 尚、メンテナンスは、DFUでなくとも、バウチャーエントリで消せるはず（メンテナンスプログラムでは、レコード削除のキーはバウチャー番号ではなく、SYSTEM番号だから。）だが、開発時にこのテストはしていないので、敢えてDFUで行った。 O) 最終的に、経理の人にバウチャーリストを検査してもらい、過不足は入力／修正／削除してもらう。それがよければ、96/01の処理を再開する。 以上 |
|
You are at K's tips-n-kicks of AS/400
|
| SEO | [PR] 爆速!無料ブログ 無料ホームページ開設 無料ライブ放送 | ||
