AccessとLinux

中小企業での販売管理プログラムの作成についての所感

「でんさい」

2020年07月24日 21時50分19秒 | Weblog
最近、大分「でんさい」が普及してきたと思う。
銀行の人に聞くと、「扱い金額はまだまだです。」とのことだが、主に地銀や信用金庫で使われているので、金額より枚数(件数)の方が大事ではないかと思う。

「一括請求」で使っている。
支払手形の「請求」から使い始めた。毎年、得意先からの手形入金が紙手形から「でんさい」へ切り替わり、裏書手形払いに充てる枚数が乏しくなってきた。その対応として「でんさい」の「譲渡請求」を使い始めた。紙手形で裏書手形払いする場合、仕入先の請求金額と支払金額は一致しない。大抵、過払いになるように支払う。「でんさい」で「分割譲渡」すればピタリの金額で支払うことができる。

そんなこんなで「でんさい」払いの3パターン全て使うことになった。それに伴って販売管理プログラムも機能拡張した。
しかし問題もあった。
入金伝票入力時に受取手形明細を自動で作成していたのだが、入金処理して翌月とか(請求書発行後)に「分割譲渡」することになると、入金伝票と受取手形データが合致しなくなってしまった。
(原則、請求書郵送後、売掛金が変わるような処理はしたくないので。)
紙手形の場合は手形帳で手形1枚ごとに手形番号をつけていく。手形番号一つに顛末は一つだけだ。
「でんさい」の場合も紙手形同様に手形帳に記録して手形番号を付けていたのだが、分割するとなると1枚の手形が2枚にも、3枚にもなってしまう。それぞれ顛末が異なるので、分割した手形については手形番号を新たに振っていかなければならない。
結局、入金伝票と受取手形データの整合性がなくなってしまった。
「分割譲渡」は始めたばかりなのだが、当面この状態で運用していくつもりだ。

もちろん金額の合計は異ならないように分割するのだが、「分割譲渡」後、入金伝票を修正すると、分割した「でんさい」手形の明細が消えてしまう。請求書発行後に売掛金に影響がある入金伝票の修正処理はしたくない。間違える場合もある。間違えると、その月の売掛残が変わってしまい、月次そのものが変わってしまう。

「でんさい」は紙手形のように印を押したり、書留で送ったりといった作業がないので、便利だし安全だ。それでも、もう一つ普及していないのはそれなりの理由があるのではないかと思う。
大企業だと受取手形の枚数が月何百枚というところもあるだろう。紙手形は結局無くらないので、紙手形と「でんさい」両方で管理しなければならない。

自分の場合はそんな枚数は無いのでそういった苦労はないのだが、それでも多少不満がある。
「一括請求」で処理すると、「でんさい」画面から明細印刷が一切できない。
合計金額だけ表示された帳票が印刷される。明細をどうやって確認するかというと、電子データで「ダウンロード」して販売管理システムに取り込み、自分で明細表を作る。
「でんさい」導入当初、これには驚いた。販売管理システムを自作しているからいいようなものの、自分で明細表を作成できなかったら、明細確認が全くできない。
今になっても「でんさい」画面からの明細印刷ができないので、何かセキュリティ上の問題があるのかもしれない。
それにしても使いにくいシステムだと思う。

また、未決済分「でんさい」明細(手持ちの「でんさい」)の一覧表示ができない。受取りした「でんさい」一覧はデータ電子データで「ダウンロード」してくる。その際、未決済分だけでなく、何年分かわからないが、決済分も合わせてデータが落ちてくる。月15枚程度でも、何か月分も一度に落ちてくるので150枚とか、そんな件数分のデータだ。
販売管理システムに取り込んで、未決済分だけフィルターをかけて印刷するのだが、これもシステムがなければ管理できそうにない。

インターネットバンキングだと画面に明細が表示されたり、印刷したりできるのに、「でんさい」はこの辺りのユーザーインターフェースが全くなってないと思う。これじゃ、普及しにくいのも無理はない。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

サーバーの更新履歴

2020年07月08日 08時35分01秒 | Weblog
先日、YouTubeを見ていたらLinuxサーバーのディストリビューション別のシャアの説明があった。1位 Ubuntu、2位 CentOS、3位 Debianだった。
Debian系が1、3位に入っている。

これまで使って来たサーバーの履歴がどうなっているか調べてみた。

サーバーの更新履歴は下記の通り。

2003年10月 RedHat9.0  PostgreSQL7.3
2006年4月 VineLinux3.2  PostgreSQL8.1.3
2006年12月 Solaris10 6/06  PostgreSQL8.1
2011年12月 CentOS6.2  PostgreSQL9.1.2 (2013年2月、EUC_JPからUTF-8に変更)
2015年7月 CentOS7  PostgreSQL9.4.4
2020年6月 CentOS8.1  PostgreSQL12.3

ほぼ一貫してRedHat系を使っている。
この中でサーバーに適してないと思うのはVineLinux3.2だけで、8ケ月しか使っていない。
RedHat9.0からVineLinux3.2に更新したのは、RedHatが有償になってしまいDebianという選択肢もあったのだが、テストで使ったDebianの印象があまりにも悪かったのでVineLinuxにした。
実際、RedHat系とDebian系ではディレクトリ構成が随分違うので、抵抗があった。

VineLinux3.2が使えないと分かり、困ってしまいSolarisを使うことに。
RedHat9.0とVineLinux3.2以外はほぼ5年使っている。CentOSばかりだ。Solaris10も安定していて非常に良かった。ただ、Solarisの場合、ネット上の解説が少ない。

だいたい更新時には何等か不都合があって更新している。大抵、再起動すれば治るような症状のものなのだが、当時は9万円以下のPCをサーバーに使っていて、あっさりPCを更新した。
実際、PCを更新することで体感何割という感じで速くなった。
先月まで使っていたCentOS7にしても、不調の原因がSSDの破損だったので、OSそのものに問題があったわけではない。

PostgreSQLについては、導入当時は「バージョンの小番が上がったものを使った方が良い」というような話もあったが、完成度の高いデータベースなので、今となってはそんなことを考える必要もなさそう。

サーバーの更新履歴を調べるのに昔のブログを読み返してみると、当時は、販売管理プログラムが低速だったり、フリーズしたりと問題が山積していた。PC、OS、アプリケーションが32bitから64bitになったこともあるのか、最近はそんな苦労をすることもない。また、遠隔で使っているPCにしても、今ならリモートディスクトップ接続で済むのだが、当時はISDN接続でpcAnyWhereを使ったりしていた。今はVPN接続で運用して特に不満もない。

本当にいい環境になった。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

emergency mode

2020年07月06日 20時14分51秒 | Weblog
先代のサーバーを予備サーバーにしようと思い、CentOS8をインストールすると、
起動画面に16進のダンプリストが表示された後、

Welcome to emergency mode! After logging in, type "journalctl -xb" to view
system logs, "systemctl reboot" to reboot, "systemctl default" to try again
to boot into default mode.
Give root password for maintenance
(or type Control-D to continue):

と表示された。先代のサーバーはAccessのバッチ処理が終了しなかったり、と動作が妙だった。OSの一部が破損した程度に思っていた。
「emergency mode」が表示されてしまうのでは、そのまま使うわけにもいかない。

CentOS7 を CentOS8にアップデートしたのだが、フォーマッティングして全く新たにインストールして「emergency mode」になってしまう。元々、SSD、2枚挿しで使っていたので、起動ディスクになっているSSDを外して、PostgreSQLのデータ保存用にしていたSSDを起動ディスクにして(SSDを1枚だけにして)再インストール。今度は「emergency mode」にならなかった。要するに起動ディスクになっていたSSDは物理的に破損していた。

長年、Linuxをサーバーとして使っているが、ダンプリストが表示されたり、「emergency mode」になってしまったのは初めてだ。先々代のサーバーはHDDだったので、やはりSSDは壊れやすいのだろうか。

今回、更新してよかった。

--------------------------------------------------------------------------------------------------------------------------------------
Windows7(32bit)のDSPライセンスのPCにいきなりWindow10(64bit)をインストールした。
CentOSをインストールしていたので、SSDにはWindows7のカケラも残っていなかった。
インストール時にはLAN接続せず、インストール後にLAN接続してライセンス認証しようとしたら、
「デジタルライセンス認証されています」だって。
コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

計量器データRS232Cの取り込みとRasberry Pi シンクライアント

2020年07月04日 22時26分06秒 | Weblog
データベースをPostgreSQL12.3に更新後、計量器の計測データがデータベースに取り込めていないのに気が付いた。
計量器のデータはRS232Cで送られて来て、XP+VB6で取り込んで、データベースに書き込んでいた。PostgreSQLのODBCドライバーは確か9.*を使っていたと思うのだが、12.3に対応していなかった。ODBCドライバーをpsqlodbc_12_02_0000_x86.zipに更新したのだが、今度はVB6が対応していない様子で、結局XP+VB6はあきらめることになった。

新しい環境はWindows10(64bit)なのだが、VB6(32bit)をインストールしようとすると、エラーが表示される。無視してインストールして、psqlodbc_12_02の64bit版、32bit版をインストールして動作確認したところ、うまく動作しない。VB6を使うのもあきらめた。

今度は、Windwos10+Visual Studio 2019を試してみた。Visual Basic+psqlodbc_12_02_x64がどうゆうわけか動作しない。C#でやってもダメ。Accessだと動作するのによくわからない。どうもpsqlodbcのバグではないかと思う。

ODBC接続がダメなので、Npgsqlで試してみた。Visual Basicは動作せず、C#ならOK。
どういうことなんだ!

結局、Windows10 + C# + Npgsqlで製作することになってしまった。
C#は入門書を1冊読んだことがあるが初めて使う。Npgsqlも販売管理プログラムを作り始める時、検討に使ったことがある程度。まあ、今回は計量器のデータをデータベースにinsertするだけなのでSQLも簡単。

無料のVisual Studioでシリアルポートが扱えるのはラッキーだった。これが一番心配だった。計量器のデータ取り込みだけで開発ソフトを購入するわけにもいかない。無料のVisual Studioでシリアルポートを扱えるわけだからいい時代になったもんだ。

動作環境が決まってしまえば、後は作るだけ。だが、今回もデータ取り込みのところで苦労した。VB6では取り込みはchar型で行っていたのだが、今回は最初ReadLineを使おうとしたのが良くなかった。途中で取り込みが止まってしまう。NewLineを設定してもダメで、C#のchar型で取り込むと文字化けしてしまう。結局、Byte型配列に1バイトづつ読み込んで、固定長になっているフィールドをそれぞれString型に分割してEncodingした。Basicだと型変換で苦労することはないのだがC#はこの辺りが厳密で難しい。

どうもC#のchar型は半角も1文字、全角も1文字で1バイトというわけではないようだ、これがよくわかっていなかった。
(今、考えるとVB6でどうしても文字列の幅が揃わなくて苦労したのは、 VB6のcharもバイト数に関係なく、1文字だったのだろう。空白の半角&H20も全角&H2020もどちらも1文字で取り込まれてしまい、表示時には半角スペースになってしまったのが原因だったのかも。)

データの取り込み部分ができてしまえば、後はNpgsqlでinsertするだけで、これは簡単だった。

一応、計量器のデータをデータベースに書き込むところまで出来たのだが、従来このPCを現場でシンクライアント端末を使って画面表示させていた。現場にPCを持ち込むと、冬場に壊れてしまう。実際、2台PCをダメにした。
今度はこのシンクライアント端末がWinodows10のリモートディスクトップに対応していなかった。このシンクライアント端末はMintWave製で15年は使った。デスクトップPCだと冬場に壊れてしまうのだが、このシンクライアント端末は全く故障しない。非常にタフだ。
ネットでシンクライアント端末の価格を調べると3万円くらいする。さすがに購入する気になれず、どうしたものかと思っていたら、Raspberry Pi でシンクライアントできることがわかった。

元々、計量器用のシンクライアント端末は販売管理プログラムの端末として運用するつもりだったのだが、当時は動作が低速で使い物にならなかったため遊休化していたもの。なので、全く費用をかけていない。それで15年使ったのだからお得だった。
そういう経緯なので、今回もなるべく費用を掛けたくなかった。

すったもんだした挙句に結局、下記で完成した。

サーバー: Windows10 Pro
Homeからアップグレードした。Homeはリモートデスクトップのサーバーになれない。

シンクライアント端末:
Raspberry Pi 3 Model B 1G RAM
HDMI VGA 変換アダプタ hdmi vga変換ケーブル D-SUB 15ピンHDMI オス to VGA メス 1080P プロジェクター PC HDTV 用 HDMI - VGA 変換 アダプターPC DVD HDTV用
(HDMI → D-sub )

最新版はRaspberry Pi 4なのだが、当初使おうと思っていたRPi-TC3がPi4に対応していなかったので、少し古い型を購入した。また、Pi4は冷却ファンが要るようだったので面倒だった。

シンクライアントソフト: raspbian buster + freerdp

最初、RPi-TC3で試してみたのだが、使った遊休品のmicroSDカードが不調で原因が特定できないまま、新規に購入したSDカードはraspbianで試してうまく行ったので、結局、RPi-TC3は使わなかった。調べたところRPi-TC3もWindows10のリモートディスクトップには対応しているようだったので、少し残念だった。
ただ、Raspberry Pi 3 のディスプレイ端子がHDMIでD-subの14inchディスプレイ(1024x768)を使おうとしていたので、HDMIからD-subに解像度を落とさなければならなかった。raspbianならその設定が簡単そうだった。RPi-TC3だと、シンクライアント画面では解像度を落とすことができそうなのだが、設定画面そのものを1024x768にするのがよくわからなかった。その辺りの事情もあり、raspbianにした。多分、RPi-TC3でもできるのだとは思うのだが。

raspbianはインストール時、ローケール設定はしたが、OSの更新作業はしなかった。
ダウンロードにものすごく時間がかかり、再起動時、フリーズしているのかどうか判断できなかった。
後から考えると、一晩かけて更新すべきだったかもしれない。

rdesktopはWindow10に繋がらなかった。freerdpを使った。
rdesktopでは、Kerberos認証がどうのこうの、というエラーが出た。
freerdpだと一発でつながった。

freerdpの自動起動は試してみたが、うまくいかなかった。

https://linux-memo.net/company/rpitc3_update.html
RPi-TC3が詳しく説明してある。このページがわかりやすいので、当初RPi-TC3を使おうと思った。

http://blog2.zunbe.com/?p=7722
freerdpの説明

https://qiita.com/TsutomuNakamura/items/606cae1e8c944d716a02
freerdpをフルスクリーンで

https://qiita.com/karaage0703/items/ed18f318a1775b28eab4
自動起動の説明

<かかった費用概算>
Raspberry Pi 3 Model B 6,000円
HDMI → D-sub ケーブル  800円
microSDカード      1,100円
Raspberry Pi の電源、コネクター、カバーは持ち込み
           計 7,900円

これで10年とか保てば良いのだが、環境が劣悪なのでどうなることやら、、、



コメント
  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする