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

バーコード

会計機能を作る前にもう少し、入力の補助なんかを・・・。
バーコードは既に使っている人も多くいるかと思います。
ＰＯＳレジでは、商品の決済時も使う事がありますが、在庫、棚卸とか発注（今回は作りません）とかではよく使いますので知っておくと便利です。

製造など外食では、バーコードは使わないかもしれませんが、
うちのお店では、棚にバーコードを貼って「ピ、数量」とかやってます。
主に発注で使っています。
番号は、オリジナルで大丈夫です。
（今回はＵＵＩＤのうちの12桁を商品バーコードにしています。重複しません）
物販業はＪＡＮコードなどありますから、仕入れ業者からデータをもらって商品マスタにインポートしておけばいいですよね。

ＰＯＳレジのボタン数で間に合う場合は、そのボタンでいいのですが、一般販売業などは商品アイテムが多く、そもそもボタンを探してられない場合などに便利ですよね。
（商品アイテム1万以上の場合は次回別の方法も紹介します）

今はＱＲコードもありますが、A4シールに印刷して気軽に利用するなら通常のバーコードでぜんぜんOKです。（なるべく資材にもお金かけたくないですしね～）
独自の番号をシールなどで印刷して、下敷きやメニュー、棚に貼って「ピ」でも使えます。
で、そのバーコードなのですが、ＰＣの場合はバーコードフォントというのがあって、一般的にはそれを使います。ですが、そのままでは使えません。というかバーコードリーダーが読み込んでくれません。

上の画像の右がフォントで表示されたコード39というバーコードなのですが、開始と最後にアスタリスクを付けないと読み込んでくれません。
また、印刷した状態にもよるとは思うのですが、幅が広く高さが無いので、読み込んでくれたり、読まなかったりでけっこうトラブルがありました。

そこで今回はＪQuery Barcodeを使ってちょうどいい大きさで、しっかり読み込んでくれるバーコード生成ファイルを外部ファイルで結んで使用する事にしました。
だんだんJavaScriptとか使う頻度が増えそうですよねぇ・・・。

受注画面で商品を選ぶので、この外部ファイルを受注側のグローバルフィールドで結びます。使用する分には単純で難しくはないので（javascriptの中身じゃないですよｗ）、今回ダンロードファイルに一緒に入れておきます。在庫とか、発注なんかにでも使ってください。

バーコードのボタンを押すと「Lady Go!」と表示されます。
プレースホルダテキストに次の計算式を入れ
Case(Get ( アクティブフィールド名 ) = "g_バーコード読込結果";"  Lady Go!";"")
フィールドをフォーカスし（水色）、条件付き計算で
$$barcode_keycnt = 0　　（ピンク色）
設定しただけです。

バーコードリーダーを使用すると、

トリガが発動します。

バーコードを発動させ読み込むスクリプトはけっこう人によって違うかな・・・
僕が紹介する複雑なものより、単純に商品を拾うというロジックで構わないと思います。
調べて好みのスクリプトを使用してください。

商品が決定されるとピンクになり、明細に商品が記載されます。




FileMakerPro17(Win)
ダウンロード

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

今回は、消費税別の集計。

１０％は幾ら、
８％は幾ら・・・というところ

受注側のテーブルに繰返し（２か３）のg_税率というグローバルフィールドを作ります。
受注明細テーブルはTOを２つ作ります。

受注明細と受注明細をg_税率と受注idで結びます。sys_D受注_D受注明細_税率集計でポータル内の１０％と８％の合計を計算

受注と結ぶ、sys_D受注_D受注明細_税率でポータル内の１０％と８％の合計を繰返しに表示

賛否はあるかと思いますが、フィールドの計算値が後の利用度が低く、他に極端に影響を与えない特性のものであれば、繰返しフィールドを使用しています。
僕的には、ここで繰返しを使用しないで何処で使うか・・・みたいな感じですかｗ

特に特別な計算式はありません。

商品明細の横に「＊」アスタ表示

今回の軽減税率は、

●商品ごとに通常増税１０％と、お米など軽減税８％を表す区分

●もうひとつは外食産業の様にイートイン１０％は通常、テイクアウェイ８％は軽減税という２つの特性があり、これらは同じではありません。

しかし、今回僕が作るシステムの計算上は％の違いで合計計算をしています。

（第一段階の軽減税率はこの程度で、2023年からの第二弾でこの辺のところは変わって来るかと思います）ですので、自社マスタ（システムマスタ）で変更に対応できるように作る事が要求されるでしょう。

また、現場で入力する際、請求と違い、現金商売なのでお客様をなるべく待たせない。

いわゆる商品ごとの税の特性については商品マスタであらかじめ事前設定する事が必須になるでしょう。明細側で「これは、軽減税率対象品だから・・・」なんて考えたり調べたりしている場合ではありません。

入力画面では、ポータルの上に、明細のデフォルト値が反映されるように一般商材（通常増税、軽減税）、E（イートイン）、T（テイクアウェイ）が選択できるようになっています。ポータルの明細内でも、Eか、Tの変更、混在が可能です。また、ファミリーレストランの様にカウンター越しに物販などある場合は、おもちゃは”一般”を選択すれば１０％、お米の販売があったとしても”一般”を選択すれば、商品マスタ側で事前に設定されている８％で計算されるというものです。一般とは、一般商材という意味です。（商品マスタ側で事前設定できます。消費税マスタもよく確認してみましょう）

たぶん、これらがクリアされていれば問題はないでしょう。

2023年からインヴォイス形式に代わります。

これ等は明細上で税率表記が義務ずけられるというものですが、システム的には今回からそのように作らないと、８％と１０％を分ける事は出来ません。
更にクーポンや割引きです。以前は明細ごとの構成比を出し、値引き額を構成比ごとに按分させていいく方式で説明しました。（実際、納品しているPOSのほとんどがそれ　//明細が汚くなりますけど）

しかし、今回は、％ごとの構成比でOKなので、１０％と８％の金額の構成比を算出し、値引き額を算出します。

正直、2023年がどうなるか分かりません。もしかしたら、ほんとうに明細ごとに算出しなくてはいけなくなるかもしれません。

（でも、そんなに難しくないです。　ごちゃごちゃして汚いですけど）

今回も特に特別な計算式、スクリプトはありません。

（FileMakerPro17 win)

ダウンロード

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

iPadやiphoneを使用したPOSシステムについて
今回のＰＯＳレジはiPad様には作っていません。
でも、使用は可能です。

2013年くらいから、ipad miniを使ったＰＯＳレジを作りましたが
自分のお店含めて導入したお店など、現場をリサーチしてみて感じた事は
どの程度ipad側に働かせるか！？だと思います。

FileMakerに限った事ではありません。
逆にFileMakerで開発したほうがiPadの運用には向いてるかと思います。



POSレジとして、成立しないとか働かないのではなく、現場でトラブったとき、どういう対応を考えているか！？につきます。トラブルというのはVPNを含めたWiFiなどの回線トラブル（計上されていない）や、操作ミスなどで違うアプリを開いてしまった（そのようには作っていなくても、現場ではそうなる）場合、即座に現場が対応できる代案を用意した上でのシステムなのかどうかという事です。

現場の販売員さんたちは、皆iPad POSを使いこなせているわけではないですし、ネットワークなどに詳しいわけでもありません。

何よりも、打ち直しなどで、お客様を待たせてしまう事は大罪です。
これが一番の問題。
これが解決できないなら、止めた方がいい。

オーダーを受ける受注だけiPadを使用するとか、会計や集計はPC側で行うとか、役割を決めずに全てiPadなどのタブレットで処理を行うのは気持ちはわかりますが危険としかいいようがありません。

自分のお店でも使っていたのですが、接客サービスとして問題が多いので止めました。
ほとんどが、システム的な問題ではありませんでした。

・オーダーを取るのに使うにも、ゴツくて大きくて女の子には持ちずらい。（iphoneでは役不足）
・キャッシャー台の高さにもよるのですが常に接客姿勢が下向き加減
（これが嫌でしたね～。品が無いんです。優秀な子が駄目な子に見えてしまう。台が高すぎるとお客様に失礼すぎるし、普通だと下向き加減、PCに戻すとそうはならないですから）
・回線ですよねー。「少々お待ちください」というのが悔しい！というか、もう駄目です。VPNを使ってもそうなので、結果、LANになりますでしょ。ならPCの方がトラブルは無いですから。
・作業中、他のアプリを開く。これが致命的ですね、6人のお客様の別々の会計中とかに別のアプリを開いてしまうとか、最悪です。

居酒屋さんとか、LANでテーブルに置いてメニューオーダーするとかならいいかもしれませんね。ちゃんと役割を考えて導入しないと現場は忙しいのに別な事にイライラするだけです。


iPadは、病院の問診票とか美容室の顧客登録とか勤怠の打刻とかにいいですよ。アパレルでお客様と一緒に不在商品の画像を確認したりするにも最高です。

飲食のiPadPOSはね～、結局どうなったかというと、POSを止めて発注に使ってます。
これが便利！整理された棚別ではなく、倉庫やウォークイン冷蔵庫の中を、人が歩く順番、見る順番で商品在庫の発注数を入れられるようにしています。早いんです！あとは勝手に取り扱い業者が複数選択され、安い方の卸の方の発注枠にデータが入り、店長が承認すると発注となります。承認しないと発注されないので、回線に問題があれば、承認もできない。逆にそういう作りの方がいいわけです。　それと厨房へのオーダー（時間で点滅します）、製造原価計算に使っています。適材適所です(笑)

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

今回はこのぐらいまで進めばいいかな・・。


うちのワンコの事情で全然進んでなかったです。すみません・・。

今までまったく触っていなかった受注テーブルを触ります。
分類と商品のグローバルフィールドを作っておきます。

更に、
受注テーブルのTo（テーブルオカレンス）と受注明細のToを受注idで繋ぎます。

更にもう一つ明細のToを作って受注idの他に、
受注側はグローバルフィールドのg_商品id、明細側は商品idを照合させます。
通常、売掛請求のような、データ入力に休みがある場合は、個数などの数字を入力しても問題はありませんが、現金商売の場合は、お客様を待たせることが出来ません。
しかし、sys_D受注_D受注明細２の意味は
商品のボタンを押したら、自動的に明細のポータル内に数量が1個入力されているような仕様にならなくてはいけません。更に、別の商品を入力した後、先に入力した商品を追加した場合、新たな行を追加するのではなく、その商品の明細に+1が入力されなくてはいけません。そのために受注テーブル側のg_商品id(グローバル）と明細側の商品idを追加で照合させます。



商品のボタンは、「雑貨」とか「日用品」分類で変わるように
受注テーブル側のｇ_分類id（グローバル）と、商品マスタのTo（sys_受注_M商品ボタン）で照合させます。
サンプルのファイルは、複雑にするために外食産業の分類データを入れています。
それについては、自由に設定してください。

受注のレイアウトは元々あったレイアウトとは別に複製させて
受注入力用の画面を作ります。
テーブルは設定_D受注ではなく、sys_D受注（こういうのは自由ですが、システムが複雑になってくると、どんなテーブルと繋がってるか、分かり易いし、説明しやすいので、規則的な名称を使用します）に変更し、フィールドも全てそのように変えます。FM17からは左にフィールド、オブジェクトのガイドが出るので随分と楽になりました。

sys_D受注_D受注明細（受注と繋がった明細）のテーブルをポータル化します。
デザインとかは、自由に好きにカスタマイズしてください。

その右横にsys_D受注_D受注明細_M商品（明細と繋がった商品マスタ）のポータルを置きます。同じポータルをコピーして、横にペーストしていきます。

ポータルフィルタで列を数値で分けるように設定していきます。
ポータルの中には商品マスタの画像と、表示用の商品名の２つが表示されるようにします。

ポータル枠と同じような図形ツールにボタン設定をして商品マスタ側の引数を入れます。
受注テーブルと商品マスタをグローバルフィールドで繋げているテーブルから参照させます。


分類は、そのままグローバルフィールドを繰り返しにして使用してもいいですし、
サンプルの様にボタンで反応させるのも有りかと思います。
ただ、分類が増えるようでしたら、タブやスライドなどを使うのも手かと思います。
※スーパーのように商品が多い場合は、こういうボタンではとても対応しきれません。その場合はバーコードリーダーに対応させるか、部品屋さんのなどは、PC-POSの強みとなる、品番のキー入力、グローバル検索、もしくはインクリメント検索などで瞬時に絞込み商品を選択するような仕様になるのかと思います。



スクリプトの説明は省きますが（下のサンプルをダウンロードして見てください）
受注側の税区分（一般、E、T)
一般的な商材、外食産業などのイートイン、テイクアウェイなどで明細の初期値の税率が変わるようになっています。明細ごとに変更が可能です。
（実際にイートインとテイクアウトは会計時に混在します）

また、商品のボタンを押すと、既に明細にある商品は数量が増え、無いものは明細のレコードが追加されます。


特に、今回のは基本動作だけなので簡単です。
次回は会計画面です。



FileMakerPro17　Win
ダウンロード

あ～

ちょっと関係ない話でごめんなさい

最近、ずっとワンコの病院
毎日元気だった子がSRMAという病気にかかってしまった。
ステロイド反応性髄膜炎動脈炎（steroidresponsive myelitis/arthritis : SRMA）
まだ1歳7か月なのに・・・。

元気に「あははは！」と言って走ってるように見えたのが2秒後には
地獄に落ちたように伏せて、ハァハァ苦しむって感じ。
CRT値が上がり、熱もガンガン上がる。
この2日間、夜中まで病院。

原因不明の病気って多いですね～
今はステロイドで少し良くなってきたかも。

頑張れ！マックス

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

特売の設定（販売休止にも対応）

基本のテーブルが若干出来たので、今のうちに商品マスタテーブルと特売テーブルを繋いでおきます。（完成した後に特売の設定というのはしんどいですからね）

簡単です。いつから、いつまで（開始、終了）の日付と商品情報、特売価格。
ついでと言ってはなんですが、販売休止なんかも設定できるようにしましょう。

その日だけ仕入商品が間違って入荷した、ですとか、本部指示でいつから、いつまで販売をストップするような時に対応します。
売場の販売員さんがPOSレジのボタンに「販売休止」と記されているだけで助かりますよね～。

実際、ケーキ屋さんの製造業でも、小売りの販売業でも何度もありました。
原材料が３日間入って来ないときとか、範囲指定で設定できるからいいですよね。

特売テーブルは対象期間を示すテーブルオカレンス（以降　TO)と、履歴が見れるTOをそれぞれ商品と照合させます。

商品マスタ側で個別に設定する方法。

◆本日に該当するポータルにデータがあれば、特売単価が拾え、範囲外になればNullになります。手間なのですが、構造が分かり易いのであえて２つに分けています。
◆本日該当しようがしまいが、過去に設定した履歴のポータル。




（実際にユーザーが触るUIではないです。開発者用の裏画面です）
どんどんフィールドが追加されていきますねぇ～(笑)


--------------飛ばしていいです-----------------

特売は考え方がいくつもあります。

①商品に対し、割引を表示するのも特売。
（軽減税率後は、１商品に対しての割引表示は難しいです。全体の構成比で割引されますので、もうひとつ同じ商品のレコードを作ってマイナス単価で入力します。他に値引きが無いという条件ですが）①の「マイナス表示」はやらない方がいいですよね～。
お店側は効果があると思いがちです「こんなに、割引してあげたんだよ！」みたいな。
お店側にとってもお客様にとってもそんなに効果はありません。
「ラッキー！」と「ありがたい」は違うので、やるなら「ありがたい」方を選びたいですね。ラッキー！と思われるのは損です。

②スーパーのお茶のように通常は１２０円だけど、レシートには８８円で表示。
「割引き」とか「マイナス表示」など記載はされていない。でも、チラシを見て来店してるので効果は出てるわけです。（やるなら、特売表示か、方法によってはレシートに２つ表示させることは可能）
やるならこれですかね～「特」表示はいいかもしれません。
何事も「さらっと、、」ですね。


③掛率で設定する方法。昔の問屋さんみたいですが、仕入れ先が幾つもあったり、製造販売の場合、原材料や利益率など商品によってさまざまですから、掛率での特売は止めた方がいいかもです。仕入れの交渉が掛率なのでどうしても売価まで掛率設定したくなる気持ちは分かります。パソコンで掛率設定すると見直さない。電卓でひとつひとつ掛率計算して価格で打込むと、ちゃんと売価を考えるようになるんですね。

掛率売価は後の分析しても、なぜ特売にしたかのか理由付けもデタラメになりがちになります。僕的には掛率はやりたくないので、やる場合は個別にカスタマイズしてください。


実際、割引にしても、なぜ割り引いたのか、割り引いた期間、どれだけの集客効果があったのか、後の認知にどれだけ影響を与えたのかを答えられる経営者の方は少ないです。
ポイント割引、百貨店側で用意されたイベント割引、地域でのイベント、催事の出品など
も同じです。
ですが、特売にしても、一種のイベント的な要因があって短期間で損得勘定で測れない効果もあるのは事実です。

僕的には、「特売＝値下げだけではない！」と考えてます。ひと手間ひと工夫を加え値上げする期間であってもいいわけです。

余計な事まで書いてしまいました、、、
----------------------------------------------------------

特売テーブルのレコード

特売テーブル側でも商品ガイドか何かで複数選択で来て、期間入力して、それぞれ価格を一覧で設定する事も出来ますよね～
でも、今回はしません。カスタマイズしてください(笑)


支店、拠点別の商品の特売設定
たぶん、これは多いかと思います。
商品設定も支店、拠点別になるでしょうし、品番も拠点別に変わるでしょう。
特に、販売休止は全店同じ場合もありますが、拠点別で違うのが普通です。


今回はやりませんが、ご自身で作ってみてください。

ヒントは、商品マスタに拠点id、拠点名を作ります。
（このサンプルでは支店という名称）
それを拠点TOと照合させ、拠点別に商品を登録できるようにします。
（検索で絞り込んで、登録）
あとは、拠点別に特売が設定できたらいいだけです。

もし、分からなければ質問してください。


話を戻します。



ルックアップ
ついでと言ってはなんですが、FileMakerには昔から素晴らしいルックアップという機能があります。僕は頻繁に使っているのですが、開発同業者の中で、ルックアップは怖いと仰る方も居ます。

たとえば、参照元がフラグとかで、１か空欄（Null）の場合は、内容が空欄の場合コピーしないのチェックを付けたままにすると、データを打ち直した時（上書き）変更されません。データが以前のままになっているはずです。
ここだけ気を付ければ影響はありません。

また
◆オプションの計算式で
Lookup ( D受注明細設定_M商品::販売休止 )
上書き出来て索引設定できる。

※例　受注明細と商品マスタを照合

◆計算タイプで
Lookup ( D受注明細設定_M商品::販売休止 )
ルックアップの上書きはされますが、フィールド上書きできず、索引設定できる

◆Evaluate("D受注明細設定_M商品::販売休止";[休止_Evaluate])
という方法もあります。


POSシステムの場合、明細修正という動きはめったに発生しません。
（見積、売上、請求とは違いますよね）
削除、打ち直しが圧倒的に多いです。
お客様を待たせるのが罪となるシステムでは、明細側を計算式にするより、簡単に上書きできる通常オプションのルックアップを選びます。

明細画面（裏画面）

休止した場合

この辺を今、ちゃんと作っておけば、後はけっこう楽かと思います。
受注時の商品ボタン、データ打込み画面、お会計画面を作って、割引やカード、商品券（釣銭あり、なし）、スマホ決済などが入ってくると更に明細テーブルのフィールドがいっぱい追加されます。

今回作らないですけど、iPadでの受注なんか作るにも、先に商品マスタと明細をしかり作っておけば、助かります。





今日はここまで。

FileMakerPro17
ダウンロード
（Win)

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

こんにちは。
前回（その１）の続きです。

今回は、初回なのでさわりだけ実際に作ってみましょう。
データベースの管理で、テーブルとフィールドの設定を行います。
外食産業、一般小売両方使えるようにしましょう。

実際の仕事の場合はお客様との打合せ資料、開発設計書やフローを元に作りますが、
今回は、目的が違うのでそういうのは省きます。

ざっくり！テーブル名称の前にDとかMとかありますが、データベースとかマスターの略ですので、好きに付けてください。

完成までには、まだまだテーブル、フィールドは増えてきます。
ちなみに、ファイルも売上データ用に別に作りますが、それは後日。
今の段階では「こうしたほうがいい」「ああしたほうがいい」までは考えると進まなくなるので、注意するところだけ書いておきますね。



受注

受注テーブルのフィールド

ということは、受注と計上した後、売上に振り分けるのかな・・・？？
ダイレクトに売上でもいいのですが、今回は受注と売上を分けます。

POSレジというのは、基本が現金商売です。
同じフロアに１０台～１００台ある事もありますし、拠点や支店間で一斉に受注が発生します。秒間隔ではなく、0.01秒間隔で売上が上がってきます。

注意すべき事は、
受注idなどのkeyには、なるべく計算式は持たせない事です。
このサイトでもシリアルの事は書いてますが、請求などの売掛業務なら問題はありませんが、拠点がある現金商売の場合は間違いなく衝突しますし、僕のユーザーでは、衝突後データが消えましたので、

これに変えました。↑これがいいです。最高！です(笑)
これに変えてからなんにも問題ありません。
新宿店が001で渋谷店が002でも構わないんです。
そこに「分けなきゃ駄目」、「普通、分けるでしょ」と
言い続けている間は、話が前に進みません。


自己リレのシリアルフィールドのオプション計算
SerialIncrement ( "001" ; Max ( D受注_シリアル::シリアル))
これは現金商売には向きません、駄目、衝突します。
売掛系には、ほぼ全て使ってますが・・・。

また、
ExecuteSQL ( "SELECT
MAX ( \"受注id\" )
FROM \"D受注\"
";"";"") + 1

idのオプション計算でSQL。
こういうのも駄目ですねー、POSは衝突します。

MAXというのは何をどうしてもMAX値を探すわけですから、その計算が
クラウド環境下で複数拠点間で0.01秒以下で計算してくれる、そんな約束があったとしてもネット環境や、回線の影響を考えたら駄目ですよねー。
FileMakerがそうなのではなく、どの開発ソフトも一緒です。
Oracleだから大丈夫なんてことはありません。

それか、
UUIDで繋げるのもいいと思います。

受注のフィールドは、初回なのでこのくらいにしましょう。（後で増えます）


次に受注明細

受注明細
あー、なんだかフィールド多くて嫌ですよねー。
ゲ・ゲーです。
でも実際の１/５程度しか載せていません。
明細に負荷かけるなよー！みたいな・・・
ほんとそうですよね、国や国税に言ってください。
軽減税率は、商品マスタと受注明細、この２つに負荷がかかります。

軽減税率
今年の１０月からの軽減税率は明細までの税率表示規制はありません。明細には※マークをつけて、あくまでも小計後の税率を分けて表示するだけです。
２０２３年からはインボイス形式（めっちゃ適当な名称ですよねｗ）という表示義務が課せられます。ですので、今は合計に８％と１０％を分ければいいのですが、「そもそも明細上で分けないと、その計算ができないでしょ？」、「一緒やんけ！」、
「今回が大変だす」、「なに作戦？」
税制改革を２回に分ける意味が分かりませんし、誰が「そういうことにしよう！」と言ったのか笑い話にしかなりません。
中身はきっちりガッツリ作って、表面上は今年と２０２３年で分けましょう！みたいな感じになってます(笑)
今年、何処も値引きに対応できないんじゃないでしょうか、
困ったらこれ使ってください(笑)


POSレジのような売上よりも、実は仕入や会計の方が大変かもですよ！？
菓子屋の砂糖の仕入とか小麦粉、寒梅粉なんか、入出庫と仕入が別ならいいですけど
一緒の会社ならレスポンス悪くなって在庫管理止まっちゃうでしょ(笑)
事務的な思考を現場に持ち込むと大変な事になりますよねー。

会社で会議などで出前とった場合、８％ですし、
新聞なんかも８％でしょ？　
仕入管理やめて会計ソフトに頑張ってもらいますか！(笑)


話を戻します。


明細テーブルですが、
消費税マスタと繋ぎません！え？え？

理由は後程。



次、商品マスタ

商品マスタは

商品id あまり意味を持たせずに、今の時代は単純に１+1でいいかと思います。
同時に商品を登録し合って衝突する事は、あまりないと考えますから、
分類や支店で結び
自己リレのシリアルフィールドのオプション計算
SerialIncrement ( "001" ; Max ( M商品_シリアル::シリアル))
でもいいですよね。
（支店間で商品が違うのなら、支店ごとNoにシリアル+1つけないといけないですね）

バーコードとか使う方はJANコードや独自のコードがあればいいかと思います。


消費税の税率
軽減税率の設定は受注明細ではなく、商品マスタで行います。
だって、そうなんだもん。
明細側に税率を設定すると、都度摘要を調べるので、お客様を待たせてしまいます。
ですから、あらかじめ商品側で設定しておけば、受注時に調べる必要はありません。

商品の分類別に税率を設定すると考える方もいますが、税率がこれで決定したわけではないのです！今後も、何の商品に対して、どういう行為に対して税金が変化するのか分からないのですから、今は商品に対して設定するしかありません。



ひとつひとつフィールドの意味を説明するより、

商品マスタ（裏画面UI）

デモソフトを開いて、新規ウィンドウかなにかで商品マスタと消費税マスタ、受注明細マスタを同時に開いて、いじくりまわし動きを見てみましょう。

税率マスタです。
実際のユーザーインターフェイス（UI）とは別の裏で動かす画面です。
（僕が作るシステムはけっこうトリガなどレイアウトとかも記憶させちゃうので、それを動かすと、パフォーマンスが悪くなっちゃうんです。それで裏画面で動かすように仕込み、キッチリ整理して、後でシステム追加するときなどにも、必要以上に説明書きとか載せて何時見ても分かるようにしちゃいます）

税率マスタと商品マスタと結びます。
外食産業のように、イートインやテイクアウェイで税率が違う場合や、スーパーや小売、一般の業種・業態と分けられるようにしています。



受注明細（まだまだ、少ないです）

受注を飛ばしてダイレクトに受注明細を触っているのですが、商品idを入れて
税区分で一般、イートイン、テイクアウェイを選ぶだけなんですねー。

端数処理や内税か外税かは自社マスタで設定します。


データベースの親子を作る前に、ある程度
データベースと、マスタを設定してしまいます。


今回はここまで。

（FileMakerPro17)
ダウンロード
(win)

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

５月２９日の「ラベルシールの開始位置を設定しちゃう」

の追加版

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

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

発行枚数を指定できるようにした画面。

これは、顧客のラベルシールに限らず、例えば同じ商品を何枚も出したい商品の賞味期限原材料表示シールなんかにも応用できますね。

ケーキ屋さんで、マドレーヌ１０個作って売りたいのに、全商品１枚ずつのラベルシールじゃ使い物にならないでしょうし・・・。

また、病院などの採血。患者さんによって採血の本数が違うので、患者さんにごとにラベルシールの発行枚数を指定したいときなどに使います。
お預かりのある業態などにも使えますね。

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

ね！？山田さん３枚、川村さん４枚

更には開始位置も指定できちゃう！

顧客情報が入る別のテーブルMove（名前はなんでもいいですよ）というのを作って、顧客idで結びます。そこに

「山田さん３枚・・・、川村さん４枚・・・、開始位置３なので空レコード２つ！

印刷したら、Moveレコードは全部削除！」

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

注意するところは、Move側の顧客idにユニーク設定をしない。というだけです。

更に、TOPの一覧に検索機能を付けていないので、検索できるように使うといいです。

ただし、それをやるのならスクリプト「発行枚数対応印刷」の中の

全レコード表示を削除してください。

デフラグとか気にされる方はやらないほうがいいかも(笑)

FileMakerPro17

ダウンロード

（Win)

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

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

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

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

店の店長

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

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


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

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

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

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


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

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

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


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

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

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


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