You are currently browsing the category archive for the ‘ファイルメーカー’ category.

固定長ってなんですかという向きもございましょうから、ちと説明しますか。
データベースのフォーマットにもいろいろありますが、様々なデータベースで共通で使えるフォーマットというものがあります。文字情報に限りますが。有名なのはCSVですね。カンマ区切り値ですね。
例えば氏名・住所・電話番号というフィールドがあるとして、
hh,シリア,090-xxxx-xxxx
というように、カンマでフィールドを区切ったテキスト形式のデータベースのことを言います。カンマの代わりにtabを使うとタブ区切り。
で、固定長と言うのは、書いて時のごとく「フィールドあたりの文字数を固定する」ことです。上の例で言うと、例えば氏名が10文字、住所が10文字、電話番号が11文字であった場合、
hh        シリア       090xxxxxxxx
というテキストになります。

さて前置きが長くなりましたが…
ファイルメーカーはCSVやタブ区切りには対応していますが、固定長には対応していません。対して、MSのaccessは固定長に対応しております。
そして、全銀協フォーマットと呼ばれる、銀行との通信(総合振込データや口座振替請求・結果データ、税金等々)に用いるフォーマットは、ばっちり固定長なのです。
それから、ファイルメーカーからデータを書き出すとデータレコードしかできませんが、全銀協フォーマットにはヘッダ・トレーラ・エンドのレコードも要りま
す。ヘッダには委託者情報や振込・口座振替の実施日、トレーラには依頼件数や合計金額が書かれます。エンドレコードはただのダミーだな。
そんなこんなで、自分が所属する業界向けのソフトは、大方がaccessでできております。

というわけで、銀行との通信が必要なシステムをファイルメーカーで作るのであれば、固定長とヘッダ・トレーラ・エンドを解決しなければなりません。

では、自分がどう解決したのかと申しますと。
まず、総合振込にせよ口座振替にせよ、それそのもののデータが入っているファイルからはデータを生成しません。別に全銀協用のファイルを作ります。必要な
フィールドは全銀協の仕様書を見ればわかります。まあ、最低限必要なフィールドと言えば、区分コード(ヘッダなら1、データなら2、トレーラなら8、エン
ドなら9)、金融機関コード、支店コード、預金種目(普通なら1、当座なら2)、口座番号、預金者名、金額、新規コードってとこですかね。口座振替なら結果コードも。
それから、全銀協用のファイルにはデータ読み書き用のテキストフィールドを一つ用意しておきます。
で、必要なデータが入っているファイルから、全銀協用のファイルにデータを書き出します。
次に、ヘッダレコードを生成しなければいけないんですが、これはデータ元のファイルで作ってコピーして、全銀協用のファイルで新規レコードを作って書き出し用のフィールドにペーストして、区分コードを1にします。
それからトレーラです。合計件数と合計金額です。ヘッダと同じ要領でレコードを作って書き出し用のフィールドにペーストして、区分コードを8にします。
エンドレコードは区分コードが9であれば後は適当でOKです。
肝心のデータレコードですが、これはデータ元のファイルから書き出したデータを元に、スクリプトを使って書き出し用のフィールドに固定長のテキストを挿入していきます。Loopを使ってもいいですし、全置換を使ってもいいでしょう。
いくつか注意点がありますが…
・預金者名は半角カナ30文字左詰めなので、式は例えば
「Left(((預金者名)&"        
                     
"),30)」って感じですかね。
・金額は右詰め10桁で左には0を入れます。100円なら0000000100です。
「Right(("0000000000"&NumToText(金額)),10)ってとこでしょう。
・あと件数が何桁だったか忘れたんですが(確か12桁)金額と同じ要領で右詰めにします。

最後に区分コードでソートして全銀協用フィールドの値のみタブ区切りで書き出せば(CSVだと""がついてしまうので)、全銀協フォーマットの出来上がりです。
スクリプト組むのがちょっとめんどくさいですけど。
全銀協フォーマットのデータをファイルメーカーに取り込みたい時は、まずは全銀協用のファイルで全銀協用のフィールドにデータを取り込んで、Middle関数を使ってファイルメーカー用に変換します。金額フィールドは左側の0が残ってしまうので、Int(金額)で全置換すれば0が取れます。委託者コードを
使っている場合は、請求データとの消し込みもできますね。

注意しておきたいのは…
全銀協フォーマットは、指標であって絶対ではないということです。
例えば、とある埼玉り○○銀行の口座振替は、全銀協フォーマットそのままでいけます。
しかし、クレジットのジャ○クスさんの場合、標準的な120バイト(半角120文字ね)ではなく、データレコードの末尾にやや拡張情報が加わって128バイトになります。しかも127、128バイトめは改行コードになるので、実質的には126バイトです。
アプ○スさんの場合は全銀協どころではなく、CSVです。
まあ、後の2ツは金融機関ではなくて信販会社ですけども。
(せっかくの共通フォーマットなのにスクリプトを共用しきれなくてコマル)

ああそれから、銀行や信販会社が提供する通信用のソフトやWebサイトはゲイツOSでないと使えません。いじわるです。セキュリティを謳うならMacに対応した方が聞こえがいいと思うんだけどな。

1回あたりの取引の件数がン千件、ン万件の場合はファイルメーカーどころではないと思いますけど、数百件程度までなら充分対応できます。

これ思いつくのに1週間くらいかかりました。あへあへ。

広告
いきなりカテゴリ作成。
社業そのものに触れない程度にファイルメーカーのことを書き残そうと思います。

ファイルメーカー社がファイルメーカーラインナップのバージョン8を発表したのが最近の話でした。
現在の弊社標準は5.5です。Pro 5.5とServer 5.5、それからPro 6 UnlimitedでWebにDBを公開しています。商品情報の検索と非会員制顧客からの問い合わせの受付です。
自分のPBG4には私物の5.5 Developerを入れてあります。
高かったけど、これがなければ基幹システムの開発なんてできやしませんでした。スクリプトデバッガ様です。

4→5の時のように、6から7になる時点でフォーマットの変更がありました。
予算の問題もあり、バージョンアップを見送っていたんです。年明けくらいに、と思っていたら8が発表…内容を見ていたら、これはバージョンアップしない手はないなと思ったわけです。

5.5は、Macで言うとOS X環境への最初の対応品でした。
そのうえ、Classic版もありました。でもcarbonではないです。別のアプリケーションです。
OS Xでのファイルメーカー5.5にはいくつかクリアされていない問題点がありまして、例えばツールバーがなかったりするんですが、Developer5.5は特にひどい。
まず、ファイルプレファレンスが開けない。開こうとするとアプリケーションプレファレンスになってしまう。
ファイルメーカーに電話して聞いたところ、「そういう現象は確認されていますが対応する予定はありません。スクリプトで対応して下さい」。ひでえな。
それから、Tigerではデータベースデザインレポートが使えない。メニューから選択すると必ずファイルメーカーが落ちます。これはファイルメーカー社には聞いていませんが、たぶん未対応でしょう。
君ら、Appleの100%子会社じゃなかったっけ。親会社にチクるぞ?

いずれにしても、このままでは開発のスピードがいまいち上がらないので、8への移行を決意しました。
ユーザー側にはそんなにメリットはないですけどね。
7以降は外部環境なしで関数を作れるのもありがたいです。
商売柄、ある売上金額を消費税と税引き後の売上に分解しなければいけないケースが多いのと、商品コード+売上の年月でリレーション用のキーを発行することが多いので、かなり開発がしやすくなります。

移行にあたっての心配な点は、
・リレーションや外部スクリプトのファイル参照の情報が崩れないか。
・Web公開で、cdmlが廃止でxmlとxsltを採用とのことだが、Server 8 Advancedに付属しているという変換ツールはうまく動くのか。
の2点ですな。事例を調査中及び評価版で試験中です。
ちなみに、「移行を検討しているがこういうところが心配」とファイルメーカー社に電話したら、「評価版で確認してくれ」だってさ。
噂に聞くMSほどではなくとも、どうも不親切ですなあ。

あと、Server 8 Advancedの評価版がないとWebへの対応をどうすればいいのかわからん。わからんですよ、xmlのことは。本買ってきたけど。

その次はシステムをWeb化します…。クライアントマシンの保守とファイルメーカーのライセンス料が、もうたまらんし。

gyoganなう

エラー: Twitter からの反応がありません。数分待ってページを再読み込みしてください。

アーカイブ

2017年10月
« 11月    
1234567
891011121314
15161718192021
22232425262728
293031  

最近の投稿