社内SEの徒然なる日記

最近の小型スキャナは高性能!(EPSON DS-310)


最近、会社でスキャナを購入しました。EPSONのDS-310です。
EPSONのスキャナ - 1

EPSONのスキャナ - 2

EPSONのスキャナ - 3

近々、会社の引越しがあるので、(無駄に)溜まりに溜まった紙文書を電子化しようと思ったのです。一応、会社の複合機にはスキャン機能がついているのですが、紙が大量にあるので、複合機を長々と占有するのもちょっと迷惑です。

ってことで、小型スキャナを購入することにしました。

小型と言うだけあって、ネットワーク対応は無しでUSB接続のみです。まぁ、スキャナの使い方を考えると、USB接続で特に問題を感じません。一応、WiFiに対応しているモデルもあるそうですが、別に、ね。

■ 外観とか

正面右側にあるバーを左側にスライドして持ち上げます。
EPSONのスキャナ - 4

EPSONのスキャナ - 5

EPSONのスキャナ - 6

こんな感じ。
EPSONのスキャナ - 7

用紙サイズは、ここで調整。ちと頼りない感じなので、雑に扱うと壊れそうなので、心持ち優しめに扱いました。
EPSONのスキャナ - 8

蓋の上側をつまんで引き上げれば、準備完了です。
EPSONのスキャナ - 9

■ 感想

サイズは、ティッシュペーパーの箱よりちょっと大きいくらいなので、それほど邪魔にはなりません。これが良いところ。速度も、200dpiならサクサク動きます。

ただ、やっぱり初期値の200dpiだと、スキャン結果が思わしくありません。そこで、インストールしたソフトで色々と設定を変更してスキャンします。

OCR、両面スキャンで白紙除去、傾き補正、文字の視認性向上、パンチ穴除去・・・・・・って言うか、最近のスキャナの補正機能って随分進化したんですね。色々と設定があって驚きました。

■ 後書き

そこそこ綺麗に見えるように設定変更してスキャンしたところ、紙の読み込み速度が結構遅くなりました。ま、そう言うものでしょう。

目的の電子化は成功したのですが、実は一番役に立ったのが、スキャナのインストールCDについていた名刺整理ソフト「やさしく名刺 ファイリングエントリー5」です。名刺の内容を自動的にOCRで読み取ってくれるので、整理がとても楽になりました。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

OracleのSQLの実行結果が何か変!

■ 機能追加

先日、勤め先の基幹システムに修正を行いました。伝票の明細を抽出する処理があったのですが、抽出する明細を選択できるように修正したのです。

その中で、Oracleに発行しているSQLの条件を追加しました。下記の赤字の部分が追加部分です(生の情報は出せないので、テーブル名、項目名は全て仮のものです)。
select
a.aa
,b.bb
,c.x
,c.y
,c.z
,d.name
from
a
,b
,c
,d
where
a.aa = b.aa
and b.aa = c.aa
and b.bb = c.bb
and b.x = c.x
and c.z <> 0
and (
(c.x = 1 and c.y = 1)
or
(c.x = 2 and c.y = 1)
)

and a.cdname = d.cdname(+)



明細の選択は、cテーブルのxとyの組み合わせで決定されるため、ちょっと嫌らしい条件になってしまいました。しかし、別に書式が間違っている訳ではないし、テスト環境では問題なく動いたので本番環境にリリースすることにしました。

■ 障害発生!

さて、本番環境にリリースして暫くは問題なかったのですが、半日くらい経過した辺りから、ポチポチと「明細を選択しているのに、抽出結果が出ない」と問い合わせが来るようになりました。

しかし、どう考えてもプログラムに問題はないし、発生原因が掴めません。

動作状況から、どうもSQLの抽出結果が取得できていないの原因っぽいのですが、データとSQLを見比べると、どう考えても抽出できる筈なのです。

どうしても原因がわからないので、問題になっているデータを本番環境から引っこ抜いて、開発環境に登録。開発環境で問題のSQLを実行したのですが、同じデータなのに、何故か抽出できてしまいました。

・・・な〜ぜ〜だ〜

さらに分からんのが、外部結合している dテーブルと結合しなかったり、抽出結果に関係ないはずの条件を消してみたら抽出できたりと、妙な動作をしています。

もしかして、Oracleのバグなのかね?

■ 対応

原因は不明でも、発生条件さえ分かればやりようはあります。SQLの修正箇所を消して、プログラム側(Java)で明細を選択する処理を追加して対応することにしました。

一応、これで解決ではあるのですが、どうも気持ち悪いです。今後も同じような問題が発生しては困るので、情報をまとめてサポートに問い合わせることにしました。

さて、どんな返答が返って来るのか楽しみです。

ちなみに、Oracleのバージョンは12c。開発環境はWindows、本番環境はSolarisです。

■ 後書き

現在の基幹システムは、Oracleが9iの時代に作られたものです。私が本格的にOracle(というか、データベース)に関わったのも、その辺りからです。

何が言いたいかっていうと、上記でテーブル結合の条件の書き方が標準SQLと違う(結合条件をWhere句に書いている)のは、当時のOracle独自の方式が体に染み込んでいるからだって事です。

・・・いや、もちろん標準SQLでも書けますよ?どちらかと言うと、そっちの方がスマートだと思います。って言うか、そもそもOracle自体がそっちを推奨し始めているし(・・・Oracleの裏切り者め)。

基幹システムの膨大なSQLを書き換えるのは無理でも、せめて新しく追加する機能については考えた方が良いのかなって思う今日この頃です。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop

Windowsの画面キャプチャが進化していた


マニュアルを作るとか、私のようにブログに掲載したいというときに、画面を画像データとして保存したいという要件は多いと思います。

Windowsにも、一応は機能があって、PrintScreenキーで全画面、Altキーを押しながらPrintScreenキーを押すことでアクティブウィンドウを、クリップボードにコピーすることは出来ました。

なのですが、ここから先がよろしくない。矩形選択は出来ないし、クリップボードへのコピーなので、jpegなどの画像データにしようと思ったら一手間です。

結局、フリーソフトなどに頼っていたのですが、ふとWindows10の機能を確認していると、いつの間にか画面キャプチャが出来るようになっていたようです。

■ 矩形選択

画面上の一部分を取得したい場合、Winodwsキー + Shiftキー + Sキー の組合せで可能になりました。

用途がマニュアル作りなら、とっても便利になりました。

Officeの機能に「スクリーンショット」が付いた時に、最初からOS側で対応して欲しいと思っていたことが、ようやく出来るようになったって感じです。

■ Snipping Tool

Windowsの標準機能(アクセサリ)に、Snipping Tool というソフトが存在しています。

起動すると、小さなウィンドウが表示されます。
Windowsで画面キャプチャ - 1

領域選択も可能で、遅延キャプチャも出来ます。
Windowsで画面キャプチャ - 2

Windowsで画面キャプチャ - 3

数は少ないですが、多少はオプションも設定できます。
Windowsで画面キャプチャ - 4

フリーソフトに比べると不自由な所は目立ちます。例えば、画像データにするには、キャプチャした後で名前を付けて保存するという手順が必要だし、ウィンドウ自体が常に起動しっぱなしなので、地味にキャプチャがしにくかったりします。

なのですが、標準機能でここまで出来れば上出来ではないでしょうか。

■ 後書き

ちなみに、私のお気に入りの画面キャプチャソフトは「WinShot」です。必要な機能が一通りそろっていて使い勝手がよいので愛用しています。

ですが、Windows自身の画面キャプチャ機能が充実してきたので、普段は起動しないようにしています。個人的なこだわりで、標準機能で出来ることは、それを使うっていうのがありまして。

投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

SQL(Oracle)で日差を計算する

■ 単純な日差

OracleSQLで差日数を計算してみます。テストデータは、以前に作成した日付一覧(SQL(Oracle)で土日と祝日をそれっぽく考慮した日付一覧の作成)を使います。

2017年8月9日と、日付一覧の抽出結果の差日数を取得するSQLです。
SELECT
TO_DATE(日付, 'YYYYMMDD') AS 日付
,TO_DATE('20170809', 'YYYYMMDD') -
TO_DATE(日付, 'YYYYMMDD') AS 日差
FROM
(

・・・ 前回のサンプルSQLの抽出結果 ・・・

)
ORDER BY 1


注意ですが、上記のSQL文に単純に前の記事のSQLを埋めてもダメです。あれはWITH句をつかっているので、WITH句の部分をSQL文の先頭に移さないと動きません。

取得値を日付型に変換して減算するだけで差日数が取得できます。Oracleは日付型で減算すると差日数になってくれるので楽で良いです。

■ 土日祝日考慮の日差

今度は、もうちょっと複雑に行きます。

開始日が 2017年7月14日(金)。終了日が 2017年7月20日(木)とすると、単純な日差は、6日になります。

ですが、土日祝を考慮すると、2017年7月15日(土)、2017年7月16日(日)、2017年7月17日(月、海の日)の 3日間が抜けるので、差日数は 3日になります。

この結果を取得するSQLはこんな感じです。
SELECT
COUNT(*) - 1 AS 日差
FROM
(

・・・ 前回のサンプルSQLの抽出結果 ・・・

)
WHERE
日付 BETWEEN '20170714' AND '20170720'
ORDER BY 1


日付一覧を指定範囲で抽出して、COUNT関数で件数を取得します。COUNT関数だと同一日が 1 となるので 1 減算します。

■ 複数の日付範囲を指定した日差

上記は日付範囲が1件だけでしたが、複数の日付範囲の場合も作ってみました。日付一覧にぶつけるデータ、DUAL表とUNION ALL を使用して作成しています。
SELECT
A.番号
,A.開始日
,A.終了日
,COUNT(*) - 1 AS 日差
FROM
(
SELECT
1 AS 番号
,TO_DATE('20170714', 'YYYYMMDD') AS 開始日
,TO_DATE('20170720', 'YYYYMMDD') AS 終了日
FROM DUAL

UNION ALL

SELECT
2 AS 番号
,TO_DATE('20170701', 'YYYYMMDD') AS 開始日
,TO_DATE('20170704', 'YYYYMMDD') AS 終了日
FROM DUAL

UNION ALL

SELECT
3 AS 番号
,TO_DATE('20170724', 'YYYYMMDD') AS 開始日
,TO_DATE('20170728', 'YYYYMMDD') AS 終了日
FROM DUAL
) A
,(

・・・ 前回のサンプルSQLの抽出結果 ・・・

) B
WHERE
A.開始日 <= B.日付(+)
AND A.終了日 >= B.日付(+)
GROUP BY
A.番号
,A.開始日
,A.終了日
ORDER BY A.番号



テストデータ(上記の内部テーブルA)の開始日、終了日の範囲で、日付一覧(上記の内部テーブルB)を抽出します。

後は、その単位でCOUNT関数を発行すれば良しです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end --- スポンサードリンク

PageTop

未だにOCRを使おうという夢を見る人がいて困る

■ OCR

最近、会社では色々と企んでいるらしく、業務の見直しというか、チェック機能の強化を図ろうとしているようです。それは別に良いのですが、検討中の業務フローの中にOCRとかいう文字が見えます。

・・・ハァ?

何でも、取引先の発注書をOCRで読み取って、基幹システムにデータ連携させるとか。

いや、無理だから。検討する価値すらなく無理だから。発注書が完全に機械化されているなら可能性もあるけど、手書きだし、FAXだから文字も潰れるし、書式も違うし、入力欄に沿って書いてないし、どう考えても無理。

という話をしたのですが、どうしてもOCRを使いたいようなのです。

■ 電話受注を手書き&OCR

しばらく放置していたのですが、話はさらに妙な方向に進んだらしいです。

何でも、電話で受注したものについては伝票に手書きして、それをOCRで読み込んで基幹システムに登録しようと考えているらしいです。

ん?何いってんだ?って思って聞いて見ると、お客さんに納期、単価を回答するのに、手書伝票に書き込んでFAXするらしいです。だから、その伝票をOCRで読み込むんだって言っています。

社員みんなでペン習字でも習うのかな?

そもそも、勤め先は卸売業だから納期回答するためにはメーカーに発注しないとダメで、発注処理をするためには基幹システムに伝票入力しないとダメだし。

手書伝票からOCRで読めって言ったって、その時点で基幹システムに受発注データは出来ている訳でして、何を読み込めと?

納期回答が必要なら、受発注データから納期回答書を印刷できるようにすれば良いだけだし、実務を知らない人が机上の空論を話しているだけで、もう、疲れてきます。

■ システム化の思案

OCR、私が若い頃から存在していましたが、まともにシステム化出来たって話を聞きません。

そりゃ、判断する情報が少ない業種であれば、ある程度はハマると思いますけど、様々な取引先、膨大な商品種を扱う卸売業で機能するとは思えません。

なのですが、いつの間にかOCRを使うことが目的になっているらしく、何を言っても聞き入れません。そして、いつの間にか経営陣に説明して許可をもらったらしく、上から目線で「やれ」って感じでシステム化の依頼(実際には命令)が出て来ました。

・・・・・・・・・まぁ、サラリーマンだからやるけどさ。

うーん、どっちにしてもOCRの読み込み結果を画面表示して、人間が見て修正するって工程は必要なんだから、その辺りを全面的に押し出して、それっぽく見せ掛けようかな?

OCRで読み込んだ結果を表示する画面を用意。この画面からOCRで読み込んだ結果を取りに行って、画面上に表示する。ただし、別にOCRから読み込まなくても、全ての項目を手入力可能にする。

んで、新たに納期回答書を作って、この画面の入力データから印刷可能にする。手書きするって言っていた伝票にも、この入力データから印刷可能にする。

とりあえずOCRから連動できますよって感じの見た目にしておいて、実際にはOCRは使わないシステムにするってことです。

さらに、手書き伝票なんて馬鹿な話を潰すために、入力したデータから手書き伝票の帳票レイアウトに合わせた印刷も可能にする。当然、この入力データは基幹システムの受発注データと連動しているっと。

うん、この辺りが、現場に無駄な仕事を増やさず、OCR推進派の要望にも答えた(ように見せる)現実解かな?

■ 後書き

こういう言い方をすると何ですが、今回の話は銀行だの、どっかの大会社だのからやって来た余所者が関わっています。

それだけでもアレなのに、さらに社内の様々な立場の人が自分の思惑を付け加えて、もう訳がわからない状態になっています。

余所者が現場の実態も知らずに経営陣に耳障りの良い話をして、システム開発開始。現場から猛反発を受けて大失敗。良くある話ですけど、自分が関わるかと思うと気が重いです。

最新の記事:http://harikofu.blog.fc2.com/
投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end — スポンサードリンク

PageTop