バージョンアップの統合テスト（２）

R/3で期をまたぐ処理は、メーカーであれば、生産する品目の原価の積み上げ計算が必要だ。

ところが、その前に、過去に痛い目にあった経験がある。

それが、「”年”またぎ」の処理である。

新年を迎えることができない年があった。

それは、R/3を導入した次の年の年始のことだ。

R/3のバグ修正は、NOTEという形でSAPから提供される。

不具合が見つかったら、SAPのサポートへ連絡を取り、「ああ、このNOTEを当ててください。」と言われて、「そうですか。」と自社のR/3に適用する。

それで、事足りるのだが、
困ったことに、NOTEを適用することで、NOTEそのものにバグがあって、別の不具合がでることもある。

言ってみれば、「薬の副作用」みたいなものがある。

その場合、不具合を解消するためのNOTEが出る。

つまり、ウィルスパターンみたいなもんだ。

・・・・・積もり積もって、数年経つと、NOTEだらけになって、わけがわからなくなる。

そこで、NOTEをまとめて、SAPから提供されているものがサービスパッケージというNOTEの塊だ。

R/3を導入した次の年、我々は、このサポートパッケージの適用を、年末年始の休みを利用して行おうと、企画した。

当社のR/3導入のパートナーは、2社で、その1社は、ユーザーベンダー（自社でもシステムにR/3を使っているベンダーさん）で、もう一社は、コンサルタント系のベンダーだった。

ユーザーベンダーの会社は、SP自体を自社に導入した経験がないという。

「自社のシステムに影響のある、必要なNOTEだけを当てればいい。」というスタンスである。

一方、コンサル系の会社から来ているコンサルは、当然、「SPは定期的に当てるべきだ。」と主張していた。

当社としては、やはり、きちんと、SP当てをやったほうがいいだろうと、いう結論になり、10月ごろから年末に向けてR/3のSP当ての準備してきた。

ほぼ、問題ないだろうということで、年末に、R/3の本番機へSPを当てて、年始からきれいな形で稼動させようと目論んだ。

で、・・・・・

失敗したのだ・・・・・。

原因は、出荷伝票だった。

商品を出荷すると、出庫転記という行為が行われて、在庫が減少する。

ところが、12月31日まで、問題なく出庫できていた処理が、新年を迎えたとたん、出庫操作ができなくなった。

つまり、年をまたぐ処理をR/3がやらせてくれないのだ。

新年の挨拶もそこそこに集まった情報システム部門は、1月3日に、皆、パニクっていた。

結局、SP当ては行わず、バックアップした、12月31日の状態いたにリストアすることにしたのだ。

・・・・・・・・・・・・・・・・・・

過去の経験から、R/3が新年を迎えることの重要性は、充分、認識している。

それで、今回のERP2005の統合テストでは、「期またぎ」以上に「年またぎ」が懸念事項だったのだ。