ＩＢＭ　ＡＳ４００とパソコンを愛するＳＥのブログ

第１話：合うわけないのを合わせろと・・・どうすりゃいいの？
第２話：合わないことの証明

そして今回

端数誤差が発生してしまう消費税
それを誤差が発生してしまう前の値・・・（つまり少数以下２桁までの数値）で記録していたらいいのに
整数だけで記録してしまっているお客様のシステム

なので、切り口（つまり集計期間）によって端数誤差の積算がことなり
１円合わないという事態になる

しかし、この１円の誤差は会計処理上許されるものではない
よって、合わせることが必須・・・だそうです

これで、今週はずーーーーっと頭を抱えてる

ほんと、文字通り( ´艸｀)

もう全く、何の問題も無い！
でも、２つの切り口で合わせようとするから・・・合わないはず
この誤差をどのように無くすか？

どうやってこの誤差とうまく付き合うか（笑）
うーん！　なかなか大変な命題

と、思いきや・・・少し見えた（笑）
金曜日（今週の最終日）・・・つまり今日（笑）
確認してみようと思う







人気ブログランキング

労働契約が、今年8月末日で切れる
基本的には１年契約で、自動更新なのだが
私の場合、当初の目的が会社都合で無くなった

このため、日々のお仕事をこなしてきたみたいな感じ

契約更新をしないと言う事で合意した
会社側にとっては、与えられる仕事が無い

私にとっては、当社の目的「基幹システムの再構築」が無くなったから
やりがいのない仕事ばかり
（いや、２月からの担当している顧客のシステムは可愛い（笑））

前職では、１９８６年４月から２０２３年８月末までずーーーっと同じ会社で勤務
もう、生き字引とまで言われるまでになっていたのに
（最近でも元部下から、あれはどうなっていましたか？　これはどうでしたか？と質問がきたりする）

転職サイトに登録したら・・・
忌まわしき前職の会社を紹介してきた
なんでもシステム部長として・・・とか

あんなところ、どれだけ積まれても嫌だ
魂を売り渡すつもりはさらさらないから〜〜

それでも、医療業界で働けたらなぁ・・・
門戸は狭いけど(笑)






人気ブログランキング

先日、合うわけないのを合わせろと・・・どうすりゃいいの？でお話しした件です
先週は、こうすれば合うと思うので検討しますと答えました

しかしながら、どうあがいても合わないことが確認できました

ただ、お客様に「どのようにしても合いません」とこれだけ伝えて
どんな反応をしめすでしょうか？

�@なーんだ！　合わせられないの？　ふーん！
�Aやっぱり、合わないんだ・・・残念
�Bそこをなんとかなりませんか？

さて、�@〜�Bのどれでしょうか？

その前に、どうして合わないのか？　それを納得してもらう必要があるでしょう
そのために、月曜日一日かけて資料を作りました
でも、結構難解になりましたので、結論だけをメールしました

ただ、

お客様：合わせてくれ
私：合うわけがないです
お客様：�@〜�Bのいずれかか、もしくは他（笑）

これで終わってしまったら
お客様に残るのは不満だけ・・・
それは私の望むところではないので

対策案を提示しました
できるだけコストのかからない方法で
普通なら有償になるんでしょうがね(笑)

でも、なんだかこうシステムの設計がよろしくないので
結構手を入れちゃってます
２００か所以上ですね(笑)

もう、なんだか、そこに転職して社内ＳＥとして
大改革したいなーって思って見たりして（笑）






人気ブログランキング

1989年(平成元年) 4月1日に消費税が導入されました
最初は 3% です。
数字は今の 10% に比べれば小さいですが、それでも大騒ぎでした

だって、私のようなシステムエンジニアにとっては大変でした・・・システム改修に

⇒消費税額計算　だけではない
⇒請求書への記載　（請求システム改変、基幹系システムデータベース変更、請求明細書・請求書レイアウト変更）
⇒消費税納税　（納税額計算）

書いてみるとこれだけですが、それでも
システム部門の全精力を傾けて半年かかりました

消費税導入の8年後、1997年(平成9年) 4月1日に 5% に引き上げ

この時は、システム変更に４か月ぐらいで済みました・・・
消費税導入時の改変で、システムの変更箇所が特定できていましたから
そして、ぶっちゃけ数字を 3 から 5 に変えるだけでしたから

ただ、日付管理もしなければなりませんから、その分で時間がかかりました

そして、2014年4月1日に 8%
このシステム改修はもっと楽でした

直近では、2019年10月1日に 10%
この時は、なんで年度切り替わりでは無く、こんな中途半端な日にするんだ？って憤っていました
この時は、システム改修に少し時間をかけました

最初は、税率の変更なんてそんなに行われないだろうと思っていましたから
消費税創設当初、3%より引き上げることはないって自民党が言ってたような（笑）

なので、消費税率マスタを新設して、消費税率が変更されても
マスタ変更一発で全システムの対応が完了する・・・ようにしました
よって、現在は税率変更に対応するためには、慣れていない人でも 30秒で対応完了です

さて、話を元に戻して、消費税が合わない、合うわけがない
それを合わせろとは・・・

担当するお客様のシステムは設計が素人（その会社のシステム担当の方がつくられたもの）
そして、考えが浅いんです
たぶん、ほとんどの中小企業で、同じような感じなのでしょう

少し、コンピューターに詳しい人が、独学で勉強して、システムを構築させられた・・・みたいな
（あっ！　言っときますけど、私も独学でプログラミングを学びました(笑)）

なので、消費税導入時に、請求の為だけに消費税額を記録しようと
あろうことか、消費税を格納するフィールドを整数にしちゃってたんです

つまり、常時端数誤差が発生しているわけです
どういうことかというと
具体例で、皆さんがスーパーで買い物をするとしましょう
（スーパーでは恐らく小数点以下切捨てでしょうね。　でもこの場合は企業間取引なので四捨五入で考えてみますね）
�@１３３円の商品を購入　本体￥１３３　税￥１３
�A２７４円の商品を購入　本体￥２７４　税￥２７

でも、レシートは、本体合計￥４０７　税￥４１
あれ？税額合計は ￥１３＋￥２７＝￥４０　なのに、レシートでは￥４１
合わない・・・なんで？って思う人はいないでしょう

でも、企業では会計上この１円の差が許されないんです
許してー（心の声）

これをどうすれば合うのか？
そんなこと、あるわけないじゃないですか・・・現行の整数フィールドだけでは
どうしても合わせようとすると・・・

顧客システムには、修正消費税って言う奇々怪々なフィールドがありました
一体これは何だろう・・・・消費税計算を是正するためのものか？

でも、整数フィールドしか持たないシステムだから、端数誤差を抹消するために
誤差分を足したり引いたりする情報が必要なんだと、分かりました

ほんと、めんどくさいことをするよなー

私が１から作っていたら、誤差なんか生み出さないシステムをしっかり作ります
簡単な話です・・・設計からできるなら

でも、今では作り上げられてるシステム
それを作り替えるほどの労力を￥１の差の為に実行するなんて
費用対コストの面から考えてあり得ないでしょう

ほんと、データベース設計は、運用の裏の裏まで考えないと・・・
そこにプロとアマの差が出てくるんですよね

さて・・・アマの設計したシステムで差が出ない様に・・・
この難題を解決するには、さすがの私でも
だって、ザルで水をすくう方法を考えるのと似てますからね(笑)





人気ブログランキング

一昨日、変更しテストしテストＯｋだと思ったプログラム
昨日、休みだけど、テストしてＯｋだったからリリースした
しかし

お客様からメールが届いており、
そのプログラムで不具合が発生していると



早速、急いで原因を追究し、改修し再テスト
あーーここかー！って分かった時には
やらかしたーって頭を抱えてしまった

直ぐに分かったからいいようなものの、
時間がかかっていたらと思うと、冷や汗たらたら

リリース可能状態となったので、お客様に連絡し、リモートツールを起動してもらう
リモートでリリース作業をし、確認してもらうようお願いした

ほどなく、連絡があり、無事復旧したと・・・

ＲＰＧサイクルっていう昔ながらの便利な方法だけど、奥が深い
それゆえ、少しの設定ミスでもその動作に大きくかかわる

何と言うか、現職で初めて扱うタイプのプログラミング技法
ＲＰＧサイクル・・・とかサイクルプログラミングとか言われる

具体的に言うと・・・Ｉ仕様書でプライマリーファイルのレコードＩＤ欄の標識の扱いでミスった
知ってる人は、バカだなーって思うような基本的な事
知らない人は、そもそもサイクルプログラミングってなんやねん？

私も２か月前まではなんやねん派だった（笑）
まぁ、何とか乗り越えられて良かった良かった(*^▽^*)





人気ブログランキング

事務系システムで印刷プログラムは欠かせない
電子化されてきてるとは言え、まだまだ紙に印刷する要件はごまんとある

皆さんのお宅にもガスや電気水道、通信量や税金などの請求書が山のように来るだろう

請求額を印刷するときには編集が必要
例えば
�@ 0000013579
�A 13579
�B 13,579
�C \13,579
さて、請求書にはどのように印刷されて入れ日読みやすい？

であろうと思われる
しかし帳票に円とか\が元々印刷されていれば
�Bの形式で印刷することになるだろう

もちろん、マイナスの請求額もある
そんな場合は
�B -13,579
と印刷すべきだろう

このように印刷する場合、形式を編集する機能を使用すると便利だ

と、思うようなコードが有った
マイナス数値の符号を数字の先頭に付けたいのだろうが
編集後のなかの符号を印刷させるべきところに
有ろうことか『ー』が入力されていた
本来なら『−』であるべきなのに

しかし、違和感があり、文字コードを調べると
長音記号だった………マイナスではなく
これには呆れてものも言えなかった

しばらくして笑い転げてしまった（笑）
その後、マグマが溢れてきた

こんな馬鹿なコーディングをしていて金取るのか？
あまりにもお粗末なプロの仕事………
最低や…………





人気ブログランキング

課題管理表をひっさげお客様のところに伺い
担当者とミーティングを行った

お客様担当の営業員が、忘れるので再確認をする必要があるため
それで、残課題の確認と対応策の協議の為に訪問

７月下旬からでないと、現在検討中の案件の仕様が検討できないと
そういう事なので、とりあえずシステムの改修及び要望対応は一時保留だと

私と同行した営業は・・・当グループの案件をしてもらったらいいよと
そして、７月下旬から検討に入るから、８月ぐらいからこちらのお客様の対応を再開

それは、正しい事を言っているかのようだが
開発・改修作業を行っているのが機械なら、効率よくそのような対応もできようが
私は、生身の人間であって、半月のブランクはかなりの悪影響を及ぼす

つまり頭の中に構築されているお客様のシステムの概要が
半月後には半減してしまっていると言う事

特に、お客様システムのデータベースのフィールド名は
Ｆ００６：得意先コード
Ｉ０２２：得意先コード
Ｉ００６：納品��
など、一文字の英字に３桁の数字

とても覚えにくいし、忘れやすい（笑）

開発・改修スピードは、どれだけＤＢ名やフィールド名を覚えているかに影響される
なので、半月何もせず忘却してしまうと
再開した時、かなりのスピードダウンとなる

丁度・・・・新幹線かな（笑）
駅に停車すると、３００ｋｍ／ｈに戻るまで時間がかかるってこと
開発をしてみて欲しい・・・いや、かじるだけでいいから




人気ブログランキング

午後０時３０分頃、事故渋滞に巻き込まれる
本当ならあと１５分程度の距離なのに

詰まった

結局、午後１時に出勤しなければならないのに
午後１時にインターを脱出・・・・間に合わない

公共交通機関ならその遅延により遅刻しても延着扱いで遅刻扱いにはならない
マイカー通勤の場合は、たとえ渋滞・・・ましてや事故渋滞で遅れようとも
それを見越して早く家を出ればいいだけのこと（社長談）

確かに、それはそうなんだけど

２〜３か月に１回ぐらいかな？　事故渋滞で３０分以上遅れるのは
そのために、毎日３０分以上も早く家を出発しなければならないの？

そして、普段は会社に早く着いても、始業時間まで時間つぶし？

複雑に入り組んだ高速道路網
普段は便利なのに、事故が発生すると途端に拘束道路になってしまう

昨日のような遅刻を回避するために、つまり遅刻という記録が為されないために
年次有給休暇を使用しなければらない
給与はそのままだけど、有給休暇日数が減ってしまう

なんとかならないのか？
先週金曜日（７月５日）にも事故渋滞のために１７分遅刻

神様・・・・渋滞予測を確実に行えるように予知能力を与えてください・・・
って祈ったらいいんだろうか？






人気ブログランキング

今週は、ある機能についてお客様の窓口となっておられる方とメールでやり取り
製造業では是非とも必要な機能なのに、ゆがんだ運用をしておられる

本当は効率よくなるはずの機能が、そのゆがんだ運用で効率が悪くなっている
その機能について私も勉強はしてみた
しかし、現行運用がゆがんでいるとしか思えなかった

そこで、意を決して現在の理由を尋ねてみた
もしかしたら藪蛇になるかも知れないと思いながら・・・

普段の質問に対してはさらっと端的な言葉でメールを返してくれる担当者

その時だけは、

と要約したらこのような内容だが、実際は
その時の想いが切々と語られ、読んでいるうちに
大変残念な想いがしたと・・・共感してしまった

私は、前職でも困難に立ち向かい解決することが
システムエンジニアとして楽しい領域の仕事と感じていた

それを伝えて、もし機会があれば、断念した機能を
フル実装したい旨を伝え・・・・たかった

今では、社内ＳＥではなく、コマーシャル企業の１ＳＥなので
勝手な事が出来ない・・・消化不良状態Σ(￣ロ￣lll)ｶﾞｰﾝ






人気ブログランキング

いや、どんなビジネスでも
原材料を仕入れて、加工して、販売する
つまり、時系列で気に考えると

原材料の仕入れ

製品に加工

製品を販売

の順番に行われるはずです

会計帳票で不可思議な事象が発生
まる二日がかりで原因を探して
お客様が原因となるデータを発見

そのデータは、６月２８日に製品を出荷
でも、その製品を製作するために使用した原材料は
７月３日に仕入れたものとなっていました

製品を出荷するには、そこに製品が無ければなりません
製品を製作するためには原材料がなければなりません

でも、６月２８日に出荷した製品は
７月３日に仕入れた原材料で作成されたもの

と、システムのデータベースにはそのように入力されていました

このようなあり得ない・・・いや、そのようなミス入力はなされてはならない
のに、受け容れてしまうシステムって・・・
ザルチェックですよねー

でも、そのプログラムも結構複雑なので
そのようなあり得ない入力をするとは
思えなかったんだと思います

なので、チェックしなかったんだと・・・・

いや、万一でも入力されては困るような値はエラーではじかなければ
事実は小説より奇なり！
これはＩＴの世界では良く起こりますから（笑）






人気ブログランキング