2019年6月1日土曜日

FileMaker ラベルシールの開始位置と、枚数指定をできるようにしちゃう!

5月29日の「ラベルシールの開始位置を設定しちゃう」
の追加版

枚数の指定も出来るようにしちゃうよぅ!


前回のラベルシールの開始位置設定に、少し機能追加しました。

発行枚数を指定できるようにした画面。
これは、顧客のラベルシールに限らず、例えば同じ商品を何枚も出したい商品の賞味期限原材料表示シールなんかにも応用できますね。
ケーキ屋さんで、マドレーヌ10個作って売りたいのに、全商品1枚ずつのラベルシールじゃ使い物にならないでしょうし・・・。
また、病院などの採血。患者さんによって採血の本数が違うので、患者さんにごとにラベルシールの発行枚数を指定したいときなどに使います。
お預かりのある業態などにも使えますね。

あらゆる現場で、使う頻度は高い方だと思いますので覚えた方がいいです。




ね!?山田さん3枚、川村さん4枚
更には開始位置も指定できちゃう!


顧客情報が入る別のテーブルMove(名前はなんでもいいですよ)というのを作って、顧客idで結びます。そこに
「山田さん3枚・・・、川村さん4枚・・・、開始位置3なので空レコード2つ!
印刷したら、Moveレコードは全部削除!」


データをMove送り込んで、終わったら全部削除。元のテーブルには傷をつけない方法で、いたって単純な作りです。


注意するところは、Move側の顧客idにユニーク設定をしない。というだけです。
更に、TOPの一覧に検索機能を付けていないので、検索できるように使うといいです。
ただし、それをやるのならスクリプト「発行枚数対応印刷」の中の



全レコード表示を削除してください。
デフラグとか気にされる方はやらないほうがいいかも(笑)





FileMakerPro17
(Win)






なぜ、仕事にデータベースが必要なのか、あらためて考える

POSレジは準備しておりますので、少々お待ちくださいね。
その前に、なぜデータベースを奨めているのか、少しだけお話しします。

僕の場合は、仕事柄外食産業・製菓製造業、百貨店と関わることが多かったせいか、意外とすんなりとデータベースをチョイスし、すぐに効果が現れました。

たとえば、賞味期限シールなんですが、パッケージ化された焼菓子などに貼ってある、原材料、賞味期限、製造元、販売元などの表示されている「あれ」です。市販のソフトは印刷だけが目的であって、管理までは出来ないんですねー。


店の店長
お菓子屋さんが作る焼菓子は、1年を通してまったく変化が無いわけではなく、四季や旬の素材を活
かして製造しますので、よく変わります。さらに次の時はグレードUPしたり、流行りそうなレシピを用いてオリジナルの商品が製造されます。
ですから、印刷だけを目的とした賞味期限シールですと、種類も数も多く、商品データを探す前に、何年の何月頃のファイルを探して、開いてみて「えーーっ、いったいどこにあるの?」というようなことが頻繁に起こるんです。忙しい時こそ必要なのに、フォルダやファイルを探して印刷というのは、正直使い物にならないのです。

また、毎回原材料を打込むにしても、原材料というのは表示するための決まり事があります。原材料の使用量順、食品添加物と分けて記載、アレルギー表示を記載をしなくていけません。商品ごとに全て違いますから、新商品ができたら、全て変えなくてはならないのです。


①商品ごとに違う
②同じ商品でも季節によって違う
③表記する内容が多い
④表記ルールがある
⑤中身のデータは更新される事が前提

あと付け加えるなら「法令を厳守しなくてはいけない」という事です。
このような前提条件があるにもかかわらず、印刷目的だけのソフトウエアやプリンタ一体型の機械があるというのは、そもそも現場を無視したリサーチから開発されたとしか考えられません。



FileMakerなどのデータベースなら

①ファイルは1つで間に合います。(探さなくていい)
②商品を、包装ごと、内容量ごとに、原材料、添加物、アレルギー管理が出来ます。
(ワープロ打ちの書き換えではなく、データとして更新します)
②商品を検索しやすいように分類分けします。
(探しやすい)
③同じ商品名でも、コード番号にハイフンを付けて季節や材料違いの種類まで管理できるようにします。
(間違いを無くす)
④今、印刷したいものだけ、検索させ、この商品20枚、この商品10枚というようなラベルシール印刷が可能になります。
(紙が無駄にならない。コンピューターらしい)


今までの様なワープロ書き換えではなく、データとして更新ができるのです。
その商品開発の過去から現在の流れ、いきさつが上書きされるのではなく、別途データが更新されるわけですから、遡った管理までできちゃうんです。

突然のお客様の要望に答えられる準備というのは、絶対条件ですよね。

病院の採血に使用するラベルも同じですよね、Aさんという患者さんには6本分、Bさんは8本分のシールを印刷します。患者さんごとは1レコードずつですが、必要な枚数分を印刷する。これもデータベースの技ですよね。何時、誰が、何枚発行したか履歴が残りますよね。


賞味期限シールに限ってのことではなく、
野暮ったいデザインのものを、自分のお店の特色を活かしたデザインの販売シール。
お客様にお渡しする予約明細、預かり票、幼稚園や保育所で使う、お誕生日のお祝い関連のシールや包装、カード、お使物関連データ・・・
販促以外では、マーチャンダイジング(MD=商品化計画)、マーケティング、全てにおいてデータベースが活躍していました。
特にMDは過去データや予測データを元に企画を練るので、各店の正しいデータがないと、お話しにならないわけです。
勤怠は一般的ですが、スタッフのスキル・ステータス管理も重要です。

写真(うちの店)の店長は、商品ごとのセールストークデータベースなんか作ってましたね。スタッフ全員が、商品ひとつひとつ自分の言葉で格好つけずに素直に書くらしいです。他の人のトークを見て学ぶと言ってましたね。

たぶん、ブックシートやワープロは非常に少なかったように思います。


もう、データベースが無いと、辛いですね、考えられないです。





2019年5月31日金曜日

余談

少し余談。
昔、MACをMacintoshと呼んでいた頃、確かシステム6?漢字トーク?(漢字なかった気が)で、まだゴマトークとかいう日本語パッチでハイパーカードと、クラリスFileMakerProⅡを動かして、世界が変わるんだ!って本気で思いました。90年だったかと思います。

当時は某ファーストフードをやっていまして、各店舗のマネージャーやスタッフの成長管理、今でいうスキル・ステータス管理みたいな事をするためにハイパーカードを使っていました。売上管理は日通工のPOSレジがありましたし、現実に引き戻されますから家では別のものを作ってました・・・遊びですよ。

でも、夢というか、この先何か起こるんだ!
あー、この辺から時代は変わるんだ!って感じましたねぇ。

仕事を終えて、夜中にいろんなスタッグとかをアメリカオンラインでしたっけ?日本ではアスキーとかニフティなどパソコン通信でダウンロードし、外人さんが作られたスタッグを真似して開発をしていました。もの凄い数が公開されていたんです。

FileMakerのランタイムかなぁ・・・。ハイパーカードより、データベースっぽいソフトが配布されていて、辞書で訳して「開発はハイパーカードより簡単で、ど素人でも作れるぞ!」みたいな事が書いてあって、お医者さん関係のカルテ管理や薬剤DBテンプレート(英語版)が多かったので、多分、若い大学病院のドクターは、同じ経験をしているのではないでしょうか。FM買って、テンプレ、ダウンロードして触ってあまりの簡単さに感動しましたよね・・・。

今は個人でPCが売れない時代になり、スマホが中心となり、AIとか騒がれていますが、この時代、既にハイパーカードで「人口無能」とか皆作ってましたよ。
何が言いたいかというと、ターゲットがプログラマーやSEというプロではなく、素人の僕等に、間違いなく感動と、これからの希望を与えていました。

 Adobe Photoshopとか書いてあるフロッピーを1枚差し込み口に入れて「このソフト何に使うんだ?、Photoshopとか書いてあるけど・・・」「あぁ、フジカラーのフィルムとか現像できるんでねーべか?」とか「アルダス・ページメーカーってのは?」「デー・テー・ピーだべ?」何も知らないくせに借金してソフト買い込むくらい、夢と希望を与えていたんだと思うんですよ。

今はFileMakerのHPを見ると、いきなり「内製か、開発パートナーと協力するか」みたいな事が書かれています。時代的な背景と競争があるのでしょうがないんですけどね、でも、もっとこれからの子供たちや素人に興味を与えるようなコンテンツを考えるべきじゃないかと思うんですよ。ひとつの開拓時代が安定期に入ると、次に再び開拓しようと考えるか、安定を維持しようと考えるか、たぶん、分かれ道だと思うんです。
少子化と同じで開発者は減っているんです。
これからの子供が、学生が、研究者が、あの時のように素人が、どのようにしてFileMakerというソフトに興味を持って「開発じゃなくて、使おう!」と思わせることじゃないかなぁ。

 資格があろうが無かろうが、元請け下請け間では必要でしょうが、末端のお客様には興味もない関係の無い話なんですよ。バージョンが18に上がろうが関係ないんです。
目的は「美味しい料理を作りたい」という事なのに、高級な包丁や鍋、キッチンの道具を売り込もうとする。まるで「あなたのレベルでは、この包丁はちょっと・・・」と言わんばかり・・。家具を作りたいのに、電動ノコギリやドリルの話ばかり・・・。
作る楽しみを味わいたいのに、その辺はカット。難しい専門的な話ばかり。
夢、無いですよね。

業務ソフトであれば、お客さんからするとFileMakerだろうが、OracleだろうがMySQL、エクセルだろうがなんでもいいんですよ。

だって自分が開発すると思ってもないのですから、、
うちの会社の業務はFileMakerを使おう!なんて人いますか?
たぶん、そういう人は、
朝起きたら「あぁ、FileMaker・・・」
昼に「FileMaker・・・」寝言で「ファィ・・」

ほとんどが、"安い、早い、良いサポート"で選んでいる中、「うちのは凄くいいんですよ」は通用しないんです。専門用語は相手に共感されません。中身の説明ではなく、業務がどう良くなるかです。そこに電動ノコギリの日立です!、マキタですがぁ!はおかしな話なんです。



たぶんですが、分かりません。
AIが人に変わる時代になったとき、
今、普通に行っている請求書、そんなシステムも作っていますが、人工知能は「こういう仕事こそ無駄!」という答えを出すでしょう。


未収入金ッテナンダニ?売掛ッテナニ?
請求書ナンカ出スカラ、払ワナイノダロウ!
買ッタノナラ、スグ払エ!

で、締めに払うと取引停止。銀行も口座凍結!
相手のお金を回す資金繰りなんか無視するでしょうし、
取引関係、人間関係とか信用、先行投資とか
AIは関係ないでしょう。
福山さん演じる銀行の支店長のように
「彼の夢にかけるんです!」なんてAIは言いません。
AIは商売ではなく、単なる損得勘定の道具にしかなりません。
AIには人の温度がありません。


僕はね~思うんですよ~

AIが無駄と判定、評価する事、拾っていかないと大変な事になるんじゃないかな。
今できている人の次元で考えるだけでなく、興味を持ってもらう事や希望を持ってもらうこと、夢を持ってもらう事って大事ですよね。

自分の身の回りの事、考えてる事、ソフトウェアとして置換え、
いずれ自分で作れるようになると、もっといいアイデアが生まれるんじゃないかな。
潜在市場が、素人だからいいんだと思うんですけどねぇ・・・。
下手でもオンボロでもルール無視でもいいじゃないですか。

夢や希望というのは人の温度ですからね。








2019年5月30日木曜日

今から間に合う!一緒に、軽減税率対応のPOSレジを作りますかぁ? その1


うちでは4年前に外食向けの軽減税率対応のPOSレジを作り、実際に数十店(売りたくても僕一人なのでサポートできないんです)ほど使って頂いているのですが、政治家さん、なかなか軽減税率を実施されないし、
お店の負担も大きいので、商品ではなく、簡易的なPOSシステムを無償で一緒に作りますかぁ?でも、FileMakerくらいは、どこかで買ってくださいねー。


うちのPOSシリーズはあるのですが、そこまで作っちゃうと既存のお客様から叱られてしまいますから、いたって簡易的なPOSシステムを作って、あとは自由にお好きにカスタマイズすればいいかと思います。(ただ、ここで作ったシステムを売るとかは駄目ですよー。著作権とかより倫理的な問題。ザルかぁ・・・)

レシートプリンター(エプソンか、スター精密株式会社やカスタマーディスプレイ、キャッシュドロアーなんかもOPOS仕様ではなく、LANケーブルやUSBで接続するとかで十分動きます。FileMakerなら、OFSCなどの規格でなくても問題はありません。

(最近よくみかける大型の自動釣銭機には対応しません)

これは、うちのPOSシステムなのですが、そっくりそのまま作るわけにはいきませんので、左の明細箇所と入力ボタン・・・
商品アイテムが1万とかになったら、というより200以上あったらボタンなんて探してられないですし、バーコードスキャンでないと無理かもです。業種・業態によって違うということですね。



次に、お会計の画面・・・
明細を小さくして会計画面という手もあるのですが、軽減税率は明細が大事なのです。

画像はオーダーエントリーシステムなので、画面を分けているのですが、受注データを厨房に送るとか、オーダー票を持ってバーコードでスキャン会計とかなければ、実際に作るのはタブかスライドで一緒の画面にしてもいいですよね。


上の写真はカスタマ―ディスプレイ(ディュアル・ディスプレイ)で、打込んでいる最中にお客様側に明細を照会させるものです。だんだん以前の緑の背景に白い文字という時代からは変わってきましたよねー。
商品の訴求もできちゃったりします。

こういうのがサービスらしくていいですねー、軽減税率をきっかけに変えていくといいかもしれません。



さて、しかし一体、何処が軽減税率対応なのか・・・。
ある隠しボタンがございまして、そこを押すと
明細ごとに消費税率が見え、割引をしたとき、構成比から一行ずつ割引計算される優れものだったのです。(明細、汚いっすねー!)



こういう明細ごとの計算というのは業務中に見る事はほとんどありません。
とにかく現場の人も見えずらいですし、確認程度で良いかと思います。
問題は、軽減税率の計算がきちんと行われているかです。


たとえば、500円割引したとしましょう。


ここでは各明細の税率は8%ですが、ケーキはすべてお持ち帰り(8%)、イートインは飲み物(10%)だけ、なんていうこともあります。そういう場合、今までは合計に対しての割引で良かったのですが、軽減税率の計算ではそうはいかないんです。

理由は2015年にここで書いたように・・・

それの解決策


商品ごとの構成比を出して、そこに割引きを充てる。
スーパーや小売でも一度の会計で税率の違う商品が混ざる事を想定しなくてはいけません。間違っても合計から引いちゃいけないんですよ。

そんなことで、外食だけではなく、小売りでも使えるようなPOSレジが作れればいいですねー。

仕入や入出庫、発注は省きます。そこまでやったらお金頂かないと無理でーす。
難しくはないので自分で作りましょう!!
製造と販売の一体の場合はうちのPOSシリーズにありますから買って下さいw
半製品、製品、製造原価管理とかありますよ。

話は戻りますが、
集計は一般的な売上と、商品の順位表くらい?時間帯別順位とか。
ということで赤文字の箇所を中心に作っていきましょう。


8月中くらいまでに出来たら、いいっすよねぇ・・?
レシートプリンタとかドロアーとか揃えて9月・・・
事前登録する商品マスタだけ頑張れば
多分、軽減税率は間に合うでしょう。


(作り方は次回からですw)









2019年5月29日水曜日

FileMaker ラベルシールの開始位置を設定しちゃう


ラベルシールって結構使ってますよね。
FileMakerで開始位置を設定する方法ってのは、デフォルトには無いので自分で作るしかないんです。

方法はいろいろあるかとは思うのですが、あまり難しくする必要はないのかと思います。
対象レコードに対し
必要な数の空データを作って、削除する。
これだけです。

(これは位置表示だけのインフォメーション)


問題は、顧客などのデータが入ったテーブル内で、空レコードを作ったり、削除したりするのが怖い、関係の無いデータまで消してしまうのではないか、という不安がある。
とおっしゃる方も居ます。
そこで対象データを別テーブルに複製させ、別テーブルで空レコードを作り、別テーブルで印刷し、別テーブルで消せば元のデータにはなんら影響は無くなります。

でも、なんというか、判断はまかせます。僕的には、めんどくさいし、重たくなりますからね・・・。

空レコード増やして、空レコード削除するだけですから・・・。
外国ではデータの複製とかしてるみたいですけど、よく分からなかったです。


理屈は、見積書や請求書の印刷のように明細数が2,3行しか無くてみっともないときに、MAX20行表示で空レコードをLOOP処理で17個作っていい感じに見える方法となんら変わりません。空レコードを下にまとめるか、上にまとめるかだけです。

ラベルシールはコクヨとかで12とか24とかあれば、その12がMAX値で
対象レコードをどの位置から開始するかだけです。
開始位置が4であれば、空レコードを頭に3つ置くという事になります。





並べるためのポイント1
顧客マスタの場合は顧客idがあります。
空レコードを作成するということは、どうしても顧客idが付与されますので
消すたびにどんどん大きな数になっていくと、肝心な新規登録の時に連番に大きく開きが出てしまいます。


(いつも画像が汚くてすみません)

なので、シリアル番号は空レコードを消したときに、元の番号にする必要があります。
(顧客idでソートをかける場合)
今回は年ごとに+001が付番される自己リレーションを使用します。


難しくないですよね。


シリアルの計算値に
SerialIncrement ( "001" ; Max ( ラベルシール開始位置_シリアル::シリアル))
を入れます。

そうすると、顧客レコードを追加する度に19年&001+1が加算されるようになります。
これなら、複数の空レコードを何度作成して、削除しても元のidから始められますよね。


並べるためのポイント2

あとは、開始位置に4という数値を入れると、3つの空のレコードを作成しながら、同時に空レコードの顧客idを消し、空行フラグに1を入れ、最後は顧客idでソートをかければいいようにします。

スクリプト長いので省略



21行目に  g_開始行-1(グローバル)というのが、開始行です。

空行を作成する度に顧客idを消します(ソートで頭にくるように)
空行を作成する度に空行flgに1を入れます(空レコードだと分かるように)


そして、印刷後は、空行flgに1が入力されたデータだけまとめて削除すると
元に戻ります。


別スクリプト

という塩梅です。


既存の顧客コードを変えずに行う場合は、印刷したい対象レコードを別テーブル(同じように顧客と住所を持つテーブル)に複製(方法は任せます)して、
複製された側の別のコード(別フィールドのidを全置換で+1生成する)でソートをかけ、後は、上と同じように必要な分の空レコードを作って、戻るときは消します。作業を終えたら別テーブルのデータは全て消します。元々の顧客マスタのデータには影響を与えないように作成します。
上と比較すると、別テーブルに渡したり削除する分、時間はかかりますが、対象レコードが1000データ以内であればさほど気にならないかもしれません。
クラウドで1万とかは、ちときついかもです。


別な話ですが・・・。

開始位置をいじると、プリンターのヘッダーが擦り切れるとかいう方もいますが、
そういうのはよく分かりません(笑)






FileMakerPro17
(Winで作ってます)




後日投稿の


もあります!




2018年10月5日金曜日

7月のサンプル ダウンロード

マーカー付 スペース区切り複数ワード検索

アカウント admin
パス           123

ダウンロード

検索フィールド内は
バックスペースでインクれます。























FileMakerの集計は遅くないよ!

その前に。。

シリアルNOの初期値化と欠番

のダウンロードを再開しました。

が、注意が必要です。

SerialIncrement ( "001" ; Max ( シリアル初期化_自己リレ::シリアル ))
のように自己リレをして計算式でシリアルを生成する場合なのですが、私のお客様の会社で恐れていたことが何度か発生してしまいました。

クラウドサーバー仕様・10拠点のPOSシステムで、番号の衝突が起こってしまったのです。普通は、頻繁に起こる事は無いのですが、POSを使用するということは現金商売なので常に各拠点でレコードが動くわけです。Max値というのがくせ者で、自己リレだろうがMax値を探す(データをなめる)時間というものが発生し、拠点間でお互いに衝突をしてしまうのです。
当然、計算が変わってきてしまうので、丁重にお詫びして、修正し
この計算は表面上は残し、裏ではフィールドオプションのデフォルトのシリアルに変更しました。(僕はUUIDが嫌いなので・・・笑)

それからは衝突も無く、ちゃぁーんと動いています。




んで、本題の
FileMakerの集計は遅くないよ!

うちのお客さんのところは200万明細超えてもサクサク動いてます。
納品するシステムは商品ですから、ここに紹介するような内容とは、ちょっと違いますが・・・(笑)

重いという方、多分ですが、集計させる側のテーブルのフィールドの計算式が多過ぎなのではないでしょうか。
単純な単価×数量=金額程度でも5万明細を超えてくると、重くはなりますよ。
どうやったってCase分、Let関数やら再起処理なんか入ってくると、そりゃ集計なんかは明らかに遅くなります。これはFileMakerとか、そういう問題ではないです。



極力、集計する側のフィールドは計算式を止め、空の数字フィールドにスクリプトを使用して計算させるか、
見積、売上、請求なんかでも、そのままのテーブルで集計しないで、更新処理で計算式ゼロの別テーブルにデータ転送させ、そのテキストや数字フィールドだけ集まったテーブル側で集計すれば、相当早くなります。(必要の無い索引も外しましょう!)
特にExecuteSQLを使用しての集計は極端に処理が早く感じます。
繰返しフィールドを使用したクロス集計なんかも、違いは実感できます。

(別に分離開発を奨めているわけでもないです)
更新処理という単語が嫌いなお客様もいるので、集計処理とか、とにかく設計段階でいろいろ考えた方がいいかもです。

検索にしてもフィールドに索引が多過ぎると遅くなります。
アプリとデータを分けるファイルの分離というより、
お客様の運用上、見積や売上などのフロント側はいっぱい計算させて、請求時や、集計は計算式の無いデータで行うのが良いのかと思います。(ファイルは分けていますが、一般的に言われている分離とは違うかもです)


前月、前回の締に戻って修正出来るようにすると、自由度は高くなりますが、違うところで歪みが発生します。赤黒処理で対応するなど昔からの方法も悪くはありません。

FileMakerは複数人で開発するようには作られていないので、
あらかじめ、プレハブ建築の様に、各テーブル内フィールドの仕様、それにまつわるスクリプトなどSet化して、依頼によって組合せ調整して開発しています。

出来上がったシステムに更新処理を追加するのは正直しんどいのですが、最初からSetで用意しておけば、さほど開発には時間はかかりません。











Associatron (アソシアトロン)連想記憶

  なぜか、僕のブログの研究所側ではなく、FileMaker側にヒットするので アソシアトロン Associatron研究 リンクを貼っておきます。 研究と実験詳細 https://cside-associatron.blogspot.com/ 公開実験(JavaScriptのみ...