2015-04-14

ファイル起動時にFileMakerからMySQLに投げられるクエリ

FileMaker Pro をフロントエンド、MySQLを バックエンドにしたアプリを起動する時には、以下のようなクエリが投げられるんですね。 
(FileMaker Pro 13使用時)

SET NAMES utf8 [参考URL]

SET NAMES indicates what character set the client will use to send SQL statements to the server. Thus, SET NAMES 'cp1251' tells the server, future incoming messages from this client are in character set cp1251. It also specifies the character set that the server should use for sending results back to the client.

A SET NAMES 'charset_name' statement is equivalent to these three statements:
SET character_set_client = charset_name;
SET character_set_results = charset_name;←A
SET character_set_connection = charset_name; 

SET character_set_results = NULL [参考URL]


If you want the server to perform no conversion of result sets or error messages, set character_set_results to NULL or binary:  

SET SQL_AUTO_IS_NULL = 0 [参考URL]

If this variable is set to 1 (the default), then after a statement that successfully inserts an automatically generated AUTO_INCREMENT value, you can find that value by issuing a statement of the following form:
SELECT * FROM tbl_name WHERE auto_col IS NULL
If the statement returns a row, the value returned is the same as if you invoked the LAST_INSERT_ID() function.

つまり、INSERT直後、 AUTO_INCREMENT値は存在するにもかかわらず、IS NULL として認識されるというもろ刃の剣。

SET AUTOCOMMIT=0  [参考URL]

The autocommit mode. If set to 1, all changes to a table take effect immediately. If set to 0, you must use COMMIT to accept a transaction or ROLLBACK to cancel it. By default, client connections begin with autocommit set to 1. If you change autocommit mode from 0 to 1, MySQL performs an automatic COMMIT of any open transaction.

set @@sql_select_limit=DEFAULT  [参考URL]

The maximum number of rows to return from SELECT statements. The default value for a new connection is the maximum number of rows that the server allows per table, which depends on the server configuration and may be affected if the server build was configured with --with-big-tables. Typical default values are (232)–1 or (264)–1. If you have changed the limit, the default value can be restored by assigning a value of DEFAULT.
If a SELECT has a LIMIT clause, the LIMIT takes precedence over the value of sql_select_limit.
sql_select_limit does not apply to SELECT statements executed within stored routines. It also does not apply to SELECT statements that do not produce a result set to be returned to the client. These include SELECT statements in subqueries, CREATE TABLE ... SELECT, and INSERT INTO ... SELECT. 
※うちのDEFAULTは、 (264)–1=18446744073709551615 でした。こんなん返されても困るわ。

SET SQL_MODE='STRICT_ALL_TABLES' [参考URL]

For transactional tables, an error occurs for invalid or missing values in a data-change statement when either STRICT_ALL_TABLES or STRICT_TRANS_TABLES is enabled. The statement is aborted and rolled back.

SELECT TABLE_NAME, TABLE_COMMENT, TABLE_TYPE, TABLE_SCHEMA FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA LIKE 'easyinv15' AND ( TABLE_TYPE='BASE TABLE' OR TABLE_TYPE='VIEW' ) AND TABLE_NAME LIKE '郵便番号'

INFORMATION_SCHEMA から、アプリで使用さているビューを含むテーブル情報を取得。


select database()

接続中のデータベース名を返す

describe `郵便番号`

当該テーブルのコラム情報を取得

SHOW KEYS FROM `easyinv15`.`郵便番号`

プライマリ等キー情報を取得、Cardinality ってここにあるのね。


SELECT TABLE NAME ~ から SHOW KEYS ~ (イタリック部)は、FileMaker ファイル内に登録されたすべてのMySQLシャドウテーブル(ビュー含む)に対して実行される(キリッ


(土屋) 

2015-02-09

ハードディスクの不良ブロックとメーカーサポート


Windows Server 2008 のイベントログに、イベントID:7、「デバイス \Device\Harddisk0\DR0 に不良ブロックがあります。」が記録されていることに気づいた。普段はでないのだが、毎金曜の真夜中に開始されるフルバックアップを実行する度に出ていた。

ググると、CHKDSK /F を行えとか、ディスクのプロパティを選択して、 ツール→エラーチェック を行え、とか書いてある。 CHKDISK単独ならエラーは出ない。 が、パラメータに /F や /R を付けると、サーバ稼働中は実行できない旨のメッセージが出る。サーバなので、そう簡単には落すわけにはいかぬ。
ネット上には、ハードディスクに問題がある可能性があるので交換したほうが良い、という書き込みも散見された。

ということで、メーカーのDELLのサポートに電話をかけるとすぐに繋がる。 DELLはいろいろ言われているが、"サーバ"のサポートはいつも良い。 担当に現象を説明すると、原因を精査するには、以下の3つの方法(いずれもプログラム)があると言う。
  1. Server Asministrator
  2. DSET
  3. Diagnostics
上記1と3はサーバを一旦は停止しなければならないため、 「2.DSET」(ディーセット、と読むらしい)という診断プログラムを送付してもらい、実行した。終了すると、ZIPファイルが出来上がるので、それを返送する。
夜も更けてきても電話が来ないので、こちらから電話をしてみると別の担当者が出て、送ったファイルを見てもらう。と、即「ディスクに異常がある」とのこと(ふーん、そんな簡単に解るのか!?)で、ディスク交換となった。

なにが言いたいかというと、重要なハードはやはりハード屋に任せるのが良いということ。トラブル発生時、イベントログをチェックし、CHKDSK を行い、ググる、位までのところはなんとかなる。 そこで見当をつけてHDDやらの部品を調達して交換とかも、クライアント機であればなんとかなる。が、ダウンタイムを最小限にしなければならないサーバとなると、ソフト屋には厳しい。オンサイト契約料は高いがケチってはいけないと、今日だけは改めて思ったのだった。


後日談(15/4/14追記)
ハードディスクを交換してもらって10時間位かけてリビルド、しかし上記のエラーは解消されず。
サポートにDSETを再度送ると、「(RAID1の)ディスクが両方壊れている」という。ちょっと待った! いまさらそれは反則だ。もしそうなら、全部再インストールすることになる。 とりあえず、前回交換しなかったもう一方のドライブだけ交換してもらうことになったが、同時に不吉な記事を見つける。

Double Faults and Punctures in RAID Arrays


とっとも厭な予感。いい予感はあたったことはないが厭な予感はとっても良く当たる。
数日後メンテの人が来てもう一方のドライブを交換、当然リビルド=10時間。で、やっぱりエラーは解消されない。 結局、一旦Windows Server Backup を実行し、ディスクを初期化後にリストア。以後2か月強、このエラーは発生していない。


(土屋)


【関連する土屋企画の講習】
FileMaker Server とバックアップ(対象者:中級、5時間×1日)

2015-02-04

MySQL 5.1 から 5.6 にデータベースを移行する際、source コマンドを使うとエラーが発生することがある

MySQL 5.1 のデータベースのバックアップを取り、別のサーバ機の MySQL 5.6 にインストールする際、source コマンドを使ってデータベースの復元を行うと、以下のようなエラーが発生することがあります。

ERROR 1146 (42S02): Table 'test.蜃コ蠎ォ' doesn't exist

この文字化けしたテーブル名は日本語表記になっており、データベースの文字コードは utf8 です。

このような場合は、source コマンドの代わりに  mysql コマンドでデータベースの復旧を試みると解決することがあります。


例:
mysql -uroot -ppassword  < test.sql


【注意点】

mysql コマンドを使って大規模データベースを復旧する際、以下のようなエラーが発生して処理が停止してしまうことがあります。

MySQL server has gone away.

これを回避するには、 my.ini(my.conf) の max_allowed_packet の数値を増やします。

max_allowed_packet = 64M
(デフォルトは 4M)


2015-02-03

Big Table Handling Model in FileMaker/MySQL Environment ― Tentative one


The ordinary FileMaker development model may be not effective for handling big SQL tables.
In this post, we will try to find out clues for handling big tables at a tolerable speed while avoiding the weird application behavior that is unique to SQL big tables.

Definition of terms

Big tables: MySQL tables with more than 10 mil. rows
FileMaker/MySQL development: development using FileMaker for frontend, MySQL for backend
Filemaker-alone development: development using FileMaker for both frontend and backend

Problems of FileMaker's common interface

FileMaker provides the common interface for both FileMaker-alone development and FileMaker/MySQL development, which make it possible that developers can use the almost same method in FileMaker/MySQL development as in FileMaker-alone development.

This is very nice, but as data of MySQL tables grow up, application users will notice a performance slowdown, the application's behavior will become so weird (FileMaker issues a lot of redundant and incomprehensible SQL queries), and operation may become almost impossible.

The following model is a tentative one for mitigating such problems:


Big Table handling model in FileMaker/MySQL Environment

The figure below illustrates how to handle database objects.
.


  1. On MySQL, duplicate big tables and rename them as rpl_originalTableName which are used for replicating records SELECTed by users from original big tables.
  2. In FileMaker relationship graph, place only small tables and Rpl. Tables (do NOT place any big tables as it causes slowdown).
  3.  Create stored procedures in MySQL to SELECT records in big tables and replicate them to Rpl. Tables, and INSERT/DELETE/UPDATE them whenever related records in Rpl.Table are inserted, deleted or updated. The stored procedures are executed from FileMaker's layout.

Common Model vs Big Table Handling Model

The following table indicates the comparison of the common model which is commonly used in FileMaker application development and the Big Table Handling Model(BTHM) based on the figure above.


Common Model BTHM Remarks
Fast development Yes No
Ease of operation Good No so good
Performance for big tables Very poor Good
Weird behaviors Many Minimum
Records order Weird OK Maybe detailed later

Note:
BTHM may not be appropriate for the found set of over 0.1 million, and may not be appropriate for the large number of simultaneous users.



The above two models plus 1 are illustrated in the following video.





N. Tsuchiya

2014-12-04

『FMEasy在庫』 のバックエンドを MySQL に変える(2) ― 在庫


 本稿では、リリース予定の『FMEasy在庫 on MySQL R1.5』(仮称)の商品画面の在庫に関して説明いたします。

 以下が商品画面となります。



 『FMEasy在庫 on MySQL R1.5』では、2つの方法で在庫を算出します。
 一つは「SQL Update方式」、もう一つは「FM計算方式」です。

 それではそれぞれに関して説明します。

SQL Update方式

※特徴
 この方式は“実行”ボタンをクリックすることにより、[在庫基準日]時点の全商品の在庫数を算出して記録します(技術仕様的には、入庫数計/出庫数計/在庫数を「upd在庫」という専用テーブルに記録します)。

 一旦記録されたデータは次に“実行”ボタンを実行するまで更新されません。
したがって、“実行”ボタンクリック時点には最新情報ですが、時間が経過するに従い、最新の在庫数とは異なる可能性が高くなります。

 “実行”ボタンクリック時に入出庫データが大量にある場合、処理に数秒~数十秒、1千万件を超えるような場合は数分かかる可能性がありますが、処理が終了してしまえば即座に数値を表示・印刷できます。
 「SQL Update方式」は、在庫表などで在庫情報をリスト形式で表示・印刷する場合、高速に処理することができます。

注:
 本機能はクライアント/サーバ環境に置いて、FileMaker ServerにODBC設定がされていれば、FileMakerクライアントにはODBCのインストール/設定は不要です。

※操作方法
 実行ボタン ― 任意の[在庫基準日]を指定して本ボタンを実行すると、[在庫基準日]時点の入庫数/出庫数/在庫数が算出・記録されます。

 当方のクライアント/サーバ環境下で、入出明細レコード170万件に対してこの処理を実行すると、30秒~1分程度の時間を要します。

 作成済在庫データ選択ウインドウ(FileMaker 13使用時のみ) ― 実行ボタン右横の黄色の部分をクリックすると、小さなウインドウ(下図)が表示されます。この時、プルダウンメニューをクリックすると、他のユーザ(アカウント)が作成した在庫データの一覧が表示されるので、ここでその内の一つを選択すると、以後、「SQL Update方式」には選択したアカウントが作成した在庫データが表示されます。

他のアカウント(admin/seminar/stockchecker)が作成した在庫データを照会できる。
アカウント右側の日付は、データ作成時に指定した[在庫基準日]



注:
 各ユーザ(アカウント)は[在庫基準日]を指定して“更新”ボタンを実行することにより、全商品の在庫データを作成・記録できます。
同アカウントが次に“更新”ボタンを実行すると、前回作成した在庫データは上書きされます。例えば、admin アカウント で[在庫基準日]に「2014/11/27」と指定して本ボタンを実行すると、全商品に対して[在庫基準日]時点の在庫データが作成されますが、次に adminアカウントが「2015/12/31」を指定して同操作を実行すると、「2014/11/27」時点のデータは上書きされます。

 尚、他のアカウントが作成した在庫データは上述の通り照会することはできますが、別のアカウントで上書きすることはできません。例えば、adminアカウントでログインしている場合、seminar が作成した在庫データの照会はできても、上書きすることはできません。

FM計算方式

※特徴
 この方式は旧来のFileMakerの計算式を使用した在庫算出方法(参考記事)です。この方法のメリットは、常時最新の在庫情報を表示される点です(下記注参照)。

 ディメリットは、入出庫明細にデータが多量にある場合、在庫情報の表示に時間がかかることがある点です。 例えば、入出明細レコードが170万件あり商品Aを含むレコードがその中に2万9千件ある場合、当方の低SPECなクライアント/サーバ環境下では商品Aの[在庫数]を算出するのに5秒強程かかります。

 商品画面で個々の商品情報を一つ一つ計算・表示する場合はまだいいのですが、複数の商品の[在庫数]をリスト形式で表示する場合はかなりのストレスを感じます。

注:
 ネットワーク上の他ユーザが照会中の商品の入出庫データを追加・更新した場合、“画面更新”をクリックすると、最新の在庫情報が表示されます。

※操作方法
 計算するチェックボックス ― チェックすると「FM計算方式」の在庫情報が表示されます。チェックを外すと在庫情報の計算を行わないので、画面表示が高速になります。

 尚、「FM計算方式」の出庫数計/入庫数計/在庫数のフィールドをレイアウト上に配置するだけで、システム起動後に初めて商品レイアウトを開く際に時間がかかります。
入出明細に170万件のレコードがある場合、当方の環境下では、1分前後の時間を要します。

 この詳しい理由については割愛しますが、簡単に言うと入出明細テーブルのビューに対して、DISTINCT句を含むクエリを発するためです。
「FM計算方式」が不要であればこれらの3フィールドはレイアウト上から削除して構いません。


以上

2014-12-01

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成

 前回の記事では、iPad のバーコード読み取りによる棚卸入力機能を実装するところまでをご紹介しました。

 『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

 棚卸作業をしてみると、システム上の在庫数と、棚卸在庫数(実在庫)が一致しない ― 誤差がでる ― ことはよくあることです。

FMEasy在庫 R1.0/R1.5 に在庫誤差調整伝票作成機能を実装する


 今回は『FMEasy在庫 R1.0/R1.5』をカスタマイズし、入庫/出庫の調整伝票を作成することにより在庫誤差調整を行う機能の作成方法をご説明します。

 前回と同様、以下の用語を使っていきます。

【用語解説】

在庫数 ― システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の[在庫数]。以下の[棚卸在庫]とは異なる可能性がある

棚卸在庫 ― 実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数(=[在庫数])とは異なる可能性がある



棚卸 ―  実際に存在する商品の数を(カスタマイズ後の)『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整 ―  「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能


 それでは、こちらの動画をご覧いただいたあとで、実際のカスタマイズ方法をご紹介します。





【開発レベル】
中級(レイアウト修正、テーブル修正、スクリプト修正について理解している)

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。


注意:
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。


1. 在庫誤差調整に必要なフィールドを準備

 以下のフィールドを EasyData15.fmp12(R1.0の場合、EasyData.fmp12) の商品テーブルに追加します。

 [c在庫誤差](計算) ― 在庫誤差、誤差がある場合、調整の対象となる
 式: If(棚卸在庫 = ""; 0; c在庫数 - 棚卸在庫)   //[棚卸在庫]が空欄(未入力)の場合、誤差は 無いものとみなす

 [c入庫数調整](計算) ― [c在庫誤差] がマイナスのときに、この誤差を入庫対象数とする
 式: If(c在庫誤差  <  0; Abs(c在庫誤差); 0)

 [c出庫数調整](計算) ― [c在庫誤差] がプラスのときに、この誤差を出庫調整伝票の対象とする
 式: If(c在庫誤差  > 0; c在庫誤差; 0)

 [gNo](数値型、グローバル) ― 入庫伝票No/出庫伝票No の入出明細取込用一時記憶フィールド、後述のスクリプトで使用


2. 在庫誤差調整伝票作成スクリプトを作成

 このスクリプトの仕様は以下の通りです。

1)  在庫基準日を本日の日付(棚卸作業実施日)にする。
2)  棚卸作業を行わなかった商品は調整対象から除外する。
3) [在庫数] - [棚卸在庫] の誤差がプラスの場合は 出庫伝票、マイナスの場合は 入庫伝票 を作成する。
4) [在庫数] - [棚卸在庫] が 0 になる商品については、調整伝票を作成しない。
5) 入庫伝票/出庫伝票 の[伝票区分]は [7:在庫調整](新設)とし、通常の伝票区分とは区別する。
6) 入出明細::備考フィールドに[棚卸担当ID]を記録。

 上記の条件に従ってスクリプトを記述すると、たとえばこのようになります。



 スクリプトの流れ上、入力チェックやウィンドウ切替などのステップも含まれていますが、基本的には上記の赤囲みの部分が押さえられていれば調整伝票を作成できるようになります。

① システム在庫を本日時点のものにする

 棚卸作業が終わった直後、つまり本日時点のシステム在庫と、棚卸在庫の差違をみるため、[在庫基準日1] に本日の日付を設定します(Get(日付))。

② [c入庫数調整] に値が入っている商品データを検索します。 
 このデータが入庫伝票作成対象となります。
 対象レコードがみつかった場合は、入庫伝票を新規作成し、その[入庫No]を [gNo]に一時記録します。

 次に、対象商品データを入庫明細として「入出明細」テーブルに取り込みます。
 その際、[入庫No] として[gNo]を取り込みます。
 取り込み順は以下のとおりです。

(商品テーブル)(入出明細テーブル)
商品ID商品 ID
g在庫基準日1入出庫日
単位単位
仕入単価仕入単価
JANJAN
棚卸担当ID備考
c入庫数調整入庫数量
gNo入庫No

 ※データ取り込みのデータ自動入力オプションはオンにします。

③[c出庫数調整] に値が入っている商品データを検索します。 
 このデータが出庫伝票作成対象となります。
 対象レコードがみつかった場合は、出庫伝票を新規作成し、その[出庫No]を [gNo]に一時記録します。

 次に、対象商品データを出庫明細として「入出明細」テーブルに取り込みます。
 その際、[出庫No] として[gNo]を取り込みます。
 取り込み順は以下のとおりです。

(商品テーブル)(入出明細テーブル)
商品ID商品 ID
g在庫基準日1入出庫日
単位単位
販売単価販売単価
JANJAN
棚卸担当ID備考
c出庫数調整出庫数量
gNo出庫No


 ※データ取り込みのデータ自動入力オプションはオンにします。

 ここまでできたら、一度スクリプトを実行してみましょう。
 調整伝票が作成されるとともに、商品の[在庫数]と[棚卸在庫]がぴったり一致していれば成功です。

【入庫調整伝票の例】



【出庫調整伝票の例】



【在庫の一致を確認(テスト段階)】



 何度かテスト実行して、問題がなければ、上記スクリプト内でコメントアウトされている[棚卸在庫]および[棚卸担当ID]の全置換クリアステップを有効にします。

 これにより、棚卸調整在庫が作成された後は、自動的に棚卸情報がクリアされますので、次回の棚卸作業時に[棚卸在庫]および[棚卸担当ID]フィールドがクリアされていないということがなくなります。

【在庫誤差調整伝票スクリプトの配置場所】

 在庫誤差調整伝票作成の実行ボタンは、ここでは商品一覧画面に配置してみます。
 赤囲みのところにご注目ください。
 [棚卸在庫]フィールドを[在庫数]フィールドの下に配置することで、調整伝票作成前に棚卸状況を確認できるようになっています。


 そして、“調整実行”ボタンをフッタ位置に配置し、ボタンクリックで調整伝票を一括作成することができます。

 “調整実行”ボタンについては、ユーザ権限による制御を追加するなど、誤操作防止策を検討してみてください。


【重要:在庫誤差調整伝票を作成するタイミング】

 システム在庫は常に変動しています。
 このため、棚卸作業開始~在庫誤差調整伝票作成完了までの間、一般ユーザによるシステムの使用や入出庫作業を禁止する必要があります。

 「禁止!」と言っているのにアクセスしてくる困ったちゃんがいる場合、FileMaker Server を停止し、サーバ上で本スクリプトを実行します。
 これにより、在庫の誤差がなくなることになります。

 なお、繰越処理(在庫や各種残高を繰り越す処理)を行っている場合、繰越処理の中に本スクリプトを組み込むのも Good!と思います。



(亀)

2014-11-26

『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(1) ―― 棚卸入力を実装する

 今回は、iPadによる棚卸入力モジュールの開発方法をご紹介していきます。

FMEasy在庫 R1.0/R1.5 に棚卸入力モジュールを実装する

 ここでは弊社製品 FileMaker 在庫管理テンプレート『FMEasy在庫 IWP/WD R1.5』に沿って解説を進めていきますが、『FMEasy在庫 R1.0』を利用することもできます。

Q. 棚卸入力モジュールを使うと、倉庫の商品のバーコードを iPad で読み取って商品個数を入力するだけで、素早く、簡単に棚卸作業が進められるようになるの?

A. (最初から期待を裏切ってしまうかもしれませんが)微妙です。
 皆様は棚卸作業の時、商品リストを印字して、倉庫に持っていき、一人が商品をカウントして読み上げ、もう一人が数量をリストに書き込む、というような作業をされいると思います。

 リスト上の商品が棚番でソートされているようであれば、カウントした商品数を素早くリストに書き込むことができ、リストに書き込んだ数値をExcelや在庫管理アプリに入力するというのも、立派なやり方と思います。

 ただ、棚番管理ができていない等の理由により、リスト紙ベースの棚卸がうまく機能していないようであれば、iPadなどの携帯端末による棚卸を検討されてはいかがでしょうか。 

 iPad/iPhoneによる バーコードスキャンは慣れが必要です。スキャンをすばやく実行できるようになれば、棚卸入力モジュールはかなり有望と思います(自画自賛><)。


 それでは、以下の2つの機能に分けて、その作成方法をご説明していきます。

 1. iPad および FileMaker Go 13 のバーコード読み取り機能による棚卸入力モジュール
 2. 上記で入力した棚卸在庫数とシステム上の在庫数の誤差を修正する調整伝票作成機能

  今回は 1. の棚卸入力モジュールにいて説明しますが、その前に少しだけ用語のご説明……


【用語解説】

在庫数 ― システム上の在庫数。『FMEasy在庫 R1.0/1.5』で入出庫登録を行った結果、算出・表示される商品画面上の[在庫数]。以下の[棚卸在庫]とは異なる可能性がある

棚卸在庫 ― 実際の存在する商品の在庫数、または『FMEasy在庫 R1.0/1.5』に入力されたその値。システム上の在庫数(=[在庫数])とは異なる可能性がある



棚卸 ―  実際に存在する商品の数を(カスタマイズ後の)『FMEasy在庫 R1.0/1.5』に入力すること

在庫誤差調整 ―  「システム上の在庫数」と「棚卸在庫」の誤差を入庫/出庫の調整伝票を作成することにより修正すること、またはその機能

iPadによる棚卸モジュールを作成する

まずは、こちらの動画をご覧ください。



 倉庫の商品棚のバーコードを iPad で読み取り、各々の商品の個数をタッチパネルで入力している様子です。

 操作手順は以下のとおり。
  1. 画面上部の[JAN]フィールドをタップしてカメラをアクティグにする
  2. バーコードにフォーカス。フォーカスが合うと、iPadが勝手に商品を検索してくれて、[棚卸在庫]がアクティブに。
  3. 値一覧(1~9)の数値をクリックするか、テンキーから実際の在庫数を入力。

    以下、1~3 を繰り返して、各商品の[棚卸在庫]を入力していきます。

 さて、ご覧のように、バーコードは棚に貼りつけておくと、素早くスキャンできると思います。

 この動画では、私が棚卸作業をしていますが、バーコード読み取り時にカメラのフォーカスを合わせたり、数値をスムーズに入力したりするには少々コツがいります。
 慣れればかなり速くスキャンができるようになると思います。

 商品をひとつひとつ手に取り商品上のバーコードをスキャンすることもできますので、どちらが御社に適しているのか、検討してみてください。

 それでは、この棚卸作業用の画面を開発してみましょう。

【開発レベル】
中級(レイアウト修正、テーブル修正、スクリプト修正について理解している)

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。


注意:
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。

1. 取扱商品の JAN コードを商品マスタに登録

 社内の取扱商品の JAN コードを商品マスタに登録しておきます。
 商品マスタへのJAN コードフィールドの配置方法と登録のしかたについては、こちらの記事をご参照ください。

 iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ


2. 商品テーブルに棚卸作業用のフィールドを追加

 棚卸作業をするにあたり、以下のフィールドを EasyData15.fmp12/EasyData.fmp12 の商品テーブルに追加します。

 [棚卸担当ID] (数値型) ― 棚卸担当の[社員ID]を入力するためのフィールド
 [棚卸在庫](数値型) ― 倉庫棚の在庫数を入力するためのフィールド



3. JANコード検索用のフィールドを UI テーブルに追加

 棚卸用バーコードスキャン用のフィールドを EasyApp15.fmp12/EasyApp.fmp12 の UI テーブルにグローバルテキストフィールドとして追加します。




4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加


 以下の 3 つの TO を追加します。

 1) 社員_棚卸担当ID (社員テーブル)
 2) self_棚卸担当ID (商品テーブル) 任意
 3) self_商品ID(商品テーブル) 任意


1) [棚卸担当ID]と社員マスタのリレーション

 商品TOの[棚卸担当ID] と社員_棚卸担当ID TO の[社員ID]を関連付けます。



 2) 同じ[棚卸担当ID]が過去に棚卸処理をした商品を調べるためのリレーション

 商品 TO の [棚卸担当ID] と self_棚卸担当ID TO の [棚卸担当ID] どうしを関連づけます。


 これにより、ある担当者が過去に実行した棚卸実績を閲覧できるようになります。
 棚卸機能としては必須のリレーションではありませんが、棚卸作業もれや棚卸ミスをチェックできますので、用意しておくと便利でしょう。

 3) 棚卸実績の[商品ID]からその商品の情報に移動するためのリレーション

 上記で用意した self_棚卸担当ID TO の[商品ID] と self_商品ID TO の [商品ID] フィールドを関連づけます。


 これにより、棚卸実績の中からその商品情報に移動(照会)できるようになります。
 棚卸機能としては必須のリレーションではありませんが、棚卸作業時には、商品情報照会の操作性がアップしますので、用意しておくと便利でしょう。

5. 棚卸作業用のレイアウトを追加

 EasyApp15.fmp12/EasyApp.fmp12 のレイアウトモードで新規レイアウトを作成します。
 FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。




 このとき、表示するレコードは「商品」、レイアウト名は ipad 用の棚卸画面とわかる名前を指定しておきます。

 また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。

 あとは上記で用意した TO とリレーションを使って、[棚卸担当ID]、[棚卸在庫]、[gJAN] (スキャン用)などのフィールドを配置していきます。

 たとえば、レイアウトの加工例はこのようになります。
 最低限のユーザ入力が必要になるフィールドには赤囲みを付けておきますので、参考にしていただけると幸いです。



 図中、「タップでスキャン開始」となっているフィールドは UI TO の [gJAN] フィールドになります。
 操作では、このフィールドをタップした瞬間にバーコード読み取りモードに移り、iPad のカメラが起動させるようにします。


7. バーコード読取スクリプトを編集(または作成)

 iPad からバーコードを読み取るためのスクリプトを用意します。
 スクリプトの作成方法の詳細については、こちらの記事をご参照ください。

 iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

たとえば、バーコード読取スクリプトの編集例はこのようになります。


8. JAN コードによる商品呼出スクリプトを追加

 ユーザが UI の [gJAN] フィールドにスキャンした JAN コードを使って商品検索を行うスクリプトを作成します。

 たとえば、以下の図のようになります。



9. [gJAN] フィールドにスクリプトトリガを実装

 [gJAN] フィールドを iPad でタップした瞬間(OnObjectEnter) にバーコード読取が実行されるようにスクリプトトリガを設定します。

 また、[gJAN]へのバーコード読み取りが終了した瞬間(OnObjectSave) に JAN コード検索が実行されるようにスクリプトトリガを設定します。

 たとえば、以下のようになります。



 ここまでできたら、iPad に FileMaker Go 13 をインストールして、棚卸入力テストを行ってみてください。

 本記事の棚卸操作のような動きになれば成功です。


【棚卸実績を表示させる】

 ここでは、画面右の棚卸実績ポータルの作り方について解説します。
 ご覧のように、同じ棚卸担当者(例:土屋)が行った棚卸実績が一覧表示されていると、棚卸在庫数とチェック漏れの確認ができて便利ですね。



 棚卸実績表示用のリレーションシップの設定については、前述の「4. 棚卸担当者の氏名情報と担当者の過去の棚卸実績を照会するためのリレーションを追加」をご覧ください。


 ポータル指定の際に使うリレーションは「self_棚卸担当ID」となります。


 
 このリレーションの参照先が商品テーブルとなっていますので、[商品名]と[棚卸在庫]を配置しておけばよいでしょう。

 本稿では省略しますが、“照”ボタンをクリックすることによって、その行の商品の詳細情報を別ウィンドウで表示させたりすると、より使い勝手がよくなるでしょう。



 在庫誤差調整機能については、次回の記事でご紹介したいと思います。

 「iPadでバーコードスキャンして、棚卸表ができました!」というだけでは「で?」と突っ込まれそうなので、入力した[棚卸在庫]とシステム上の在庫数の誤差を調整伝票を発行して修正する機能もつくりました。
 続きはこちらの記事をご覧ください。

 『FMEasy在庫』 とiPadによる棚卸と在庫誤差調整(2) ―― 在庫誤差調整伝票の作成 


(亀)

2014-11-25

『FMEasy在庫』 のバックエンドを MySQL に変える(1) ― 概要


 『FMEasy在庫 R1.0/R1.5』ではバックエンドに FileMakerデータベースを使用しています。
 本稿では、これを MySQL 5.1或は5.6に置き換える方法の概要を説明すします。なお、本稿は『FMEasy R1.5』に沿って解説を進めていきます。

はじめに

FileMaker によるアプリで、バックエンドを FileMaker から SQLデータベース(ESS、External SQL Source)に置き換えるとき、リレーションシップのウインドウで各TOをFileMakerテーブルからESSテーブルに貼り替えるわけですが、このときリレーション、レイアウト、スクリプトおよびびセキュリティ内のフィールド等が壊れてしまいます(詳細は後述)。
 この場合、壊れた設定をひとつひとつ手動で設定し直さなければならなくなります。実に無意味で苦痛な作業を強いられるわけですが、対策が記されたサイトがみつかりました。

FileMaker, mySQL, and ESS; A Little Known Secret, to Me Anyway

 上記を要約すると、ESSテーブルに貼り替える前に、「FileMakerのテーブルを作成日順でソートし、そのソート順にESSテーブルのフィールドを並び替えた後に、FileMakerのリレーションを張り替えろ」、というもの。
 小社でこの方法をやってみましたが、うまくいきませんでした(やはりフィールドのマッピングが壊れてしまう)。もし上記のリンクの方法で「旨くいったぜ」という方がいれば、一報頂ければ望外の喜びとなります。
 ということで、以下、無意味?で苦痛なバックエンドの変更手順を解説します。

開発環境


小社における開発環境は以下のとおり。


FileMaker Pro 12/13 Advanced
FileMaker Server 12/13 Advanced
MySQL 5.1/5.6
ODBC 5.1/5.2/5.3
MySQL Workbench 5.2/6.2

MySQL5.6で使用するODBCドライバは...
外部 SQL データソースに対してサポートされている ODBC ドライバ


注:
 FileMaker 12/13 による MySQL 5.5 の使用はビューが認識されない等の問題があるため、お勧めしません。

 MySQLの管理ツールはいろいろあります。あえてMySQLコマンドラインを使うならそれも良いですが、他にも以下のようなツールがあります。
で、どれがいいの、という議論は、
Workbench, Navicat, TOAD for MySQL?

 なお、MySQL Workbench 6.2 は 5.1/5.2 に比べるとかなり良くなってる印象です。

データベース及びテーブルを作成する

ツールが決まったらスキーマ(ここでは名称を easyinv15 とする)とテーブルを作成します。このとき、テーブル名とフィールド名は、『FMEasy在庫 R1.0/1.5』のデータ用ファイル EasyData15.fmp12 のテーブル/フィールド名と合致させるようにします。
 なお、計算フィールドについてはMysqlApp.fmp15 のシャドーテーブル(後述)で作成可能ですが、パフォーマンスが劣化するのでなるべく使用しないように設計します。また、グローバルフィールド(グローバル値を持つテキスト/数値/日付/タイムスタンプ/オブジェクトの各フィールド、ここでは計算フィールドを除く)はシャドウテーブル内では作成できないため、グローバルフィールドに関連する処理は再設計が必要となります。特に在庫関連機能の再設計は面倒なので、機会を改めて述べたいと思います。

さて、スキーマ/テーブルの作成が終了したら、右図のようにODBC設定を行います。














 

外部データソースの変更とリレーションキーの再設定

次にFileMaker側。まず、「FMEasy在庫 R1.5」の EasyApp15.fmp12 を複製して適当な名称を付けます(ここでは、MysqlApp.fmp12)。つぎのこのファイルを開きます。[ファイル]メニュー→[管理]→[外部データソース...]を選択し、下図のように設定します(名前は EasyODBC15 とする)。このとき、もともとあったFileMakerのデータソース EasyData15 は削除しておきます。


 つぎに「リレーションシップ」タグを開くと、元の EasyData15.fmp12 のテーブルによるリレーション設定は喪失して下記の図のようになっているので、個々のTOを上記で登録した EasyODBC15 のテーブルに正しく張り直します。
 この際、元の EasyApp15.fmp12のリレーションシップ画面またはその印字物を参考にします。



この時、TO名は元のママになるよう注意します。たとえば、「入出明細_入庫」TOを選択し直すと「入出明細」になってしまうので、張り直す直前にTO名をコピーし、張り直し後に「入出明細」になったらペーストして上書きすると良いでしょう。

 なお、この張り直し後に[テーブル]タブをクリックすると、今選択したMySQLのテーブルがイタリック(斜体)で表示されます。
 これらのテーブルは(MySQLの)シャドウテーブルと呼ばれます。このシャドウテーブル内では計算フィールドを作成することができますが、他のフィールドは作成できません。MySQLテーブルのフィールドを新設/変更/削除するには、MySQLコマンドライン等の他ツールを使用する必要があります。




レイアウトのフィールド張り替え

TOを張り替えてた時点で、レイアウト上のフィールドも誤ってマップされてしまうので、各レイアウトの各フィールドを一つ一つ、張り直す必要があります ― 絶望的に退屈だけど、間違えられない作業ですね。

TO張り替え後、壊れてしまった取引先レイアウト ― 一つ一つレイアウトを開き
不正なフィールドを一つ一つ張り替えていく

スクリプトはStandardのものを開いてコピペ

次はスクリプトです。MysqlApp.fmp12内のスクリプトに設定されているフィールド名もグチャグチャになっているので、元の「FMEasy在庫 IWP/WD R1.5」の正しいスクリプトをコピって、MysqlApp.fmp12側に貼ります。
 具体的には、MysqlApp.fmp12 とともに EasyApp15.fmp12を開き、双方のファイルの「スクリプトの管理」ウインドウを開きます。次に EasyApp15.fmp12 側のスクリプトを開いて中身をすべてコピーし(Cntrl+A → Cntrl+C)、対応する MysqlApp.fmp12 のスクリプトを開きペーストしていきます(Cntrl+A → Deleteキー → Cntrl+V)。

MysqlApp.fmp12 の壊れたスクリプト。フィールドに関するステップが壊れている。
MysqlApp.fmp12側で正しいスクリプトの中身をコピーし、上図でCntrl+A をしてスクリプトの中身を選択、
Deleteキーで削除、Cntrl+V で 正しいモノをペーストし直す。
  これを壊れてしまったすべてのスクリプトに対して繰り返し実行します。

値一覧の修正

値一覧も修正が必要になります。下図で赤枠は壊れてしまったモノです。青枠はMySQLでは数値フィールドに文字列を入力することが許容されないため修正を要するモノで、これらのフィールドがスクリプトに使用されている場合は、数値のみをセットするようにスクリプトも修正する必要があります。



その他


 「FMEasy在庫」では不要ですが、他のシステムではアクセス権限セットやカスタム関数についても修正が必要になる可能性があります。



 以上、やっていて実に虚しくなる作業ではあり、もうすこしスマートな方法があるのではないかと。

 ということで、次回は在庫算出についてご紹介します。
 FileMakerのリレーションを使用して、「FMEasy在庫 R1.0/R1.5」のように、

    前回繰越在庫+SUM(今回入庫数)-SUM(今回出庫数)

 とかやってしまうと、FileMakerバックエンドより時間がずーっとかかってしまうので、方法と、高速なMySQLの実力を発揮できそうな方法の2つをご紹介したいと思います。




(土屋)

2014-11-01

受注・受注残管理モジュールを作る(4) 受注残の算出― FMEasy在庫のカスタマイズ


 本稿では商品毎の受注残、可用在庫等をどのように算出するかを説明します。

在庫情報タブ

商品レイアウト上にタブオブジェクトを配置します。在庫情報タブには在庫及び受注残関連フィールドを配置します。


商品テーブルに追加するフィールド
フィールド名 計算式 解説
繰越受注残 数字 繰越処理実行時に、各商品の[繰越日付]時点の[受注残]を記録。尚、繰越処理は未実装。
受注数 計算(数字) Sum(受発注明細_商品::受注数量) [在庫基準日]までの[受注数]計。[受注数]は受注画面上の[数量]または[受注数]
納品数 計算(数字) Sum(入出明細_商品#納品数::出庫数量) [在庫基準日]までの[納品数]計。[納品数]は受注画面上の“出庫移行”ボタンにより出庫登録された商品の数
受注残 計算(数字) Case(IsEmpty(繰越情報::繰越日付) or  g在庫基準日1 < 繰越情報::繰越日付;0; 繰越受注残)
-納品数+受注数
[在庫基準日]の受注残(受注はしたが納品していない商品の数)
可用在庫 計算(数字) 在庫数-受注残 販売先(用途)が決まっていない自由に使用できる商品の数
gcKey1 計算(数字) 1(常に1) 入出明細レコードが受注明細と紐付されているかチェックするためのシステムフィールド。


リレーション


 上図の入出明細_商品#納品数で「gKey1≦受注明細ID」が「真」であれば、その入出明細レコード(出庫した商品)は“出庫移行”ボタンにより受注画面から出庫登録されたことになります。
 逆に「gKey1≦受注明細ID」が偽であれば、その入出明細レコードに対する受注登録がないことになります。

在庫情報の変化

 さて、右図上の在庫状況において、受注画面上で[商品ID]=1の商品明細の[移行数]に「10」を入力し“出庫移行”ボタンを実行する(右図中)と、在庫情報は右図下のように変化します。

 つまり、10 個の商品を出庫登録したのだから、[納品数]は10増えて「11」となり、[受注残]はその分減って「1」となります。

 このとき[出庫数]も 10 増えて「49」に、[在庫数]はその分減って「42」となります。






















以上


(土屋)

2014-10-23

受注・受注残管理モジュールを作る(3)受注残タブの実装― FMEasy在庫のカスタマイズ


 本稿では受注管理モジュールを作成します。受注レイアウトには受注品目入力用の「受注」タブと、受注残管理用の「受注残」タブを配置します。


仕上がりイメージ

受注残関連仕様

下表は上図の受注残関連オブジェクトの仕様になります。
オブジェクト タイプ 説明
伝票区分 数値FD レコード確定時、1:全残(納品した商品無)、2:残有(受注残の商品有)、3:過納(過剰納品した商品有)、4:完納(受注した商品を全て納品)の何れかの値がセットされる。
OnRecordCommitを使用しスクリプトを起動。尚、本フィールドを計算フィールドにすることもできるが、索引が設定できずレコードが増えるに従い検索速度が劣化してしまう。
Id 数値FD
(主キー)
「受発注明細」テーブルの主キー。“出庫移行”ボタン実行時、このキーの値を移行先のテーブルである「入出明細」テーブルの[受注明細ID]に貼り付け、納品数算出用のTO(入出明細_受注#注残)の外部キーとして使用。下表及び下のリレーション図参照。
受注数 数値 =受注タブの[数量]
納品数 計算FD(数値) 当該商品の出庫への移行数合計、下表及び下のリレーション図参照。
受注残 計算FD(数値) 受注数-納品数、本値が0以外(受注残がある)の場合、本フィールドの背面が赤くなるように条件書式を設定すと、受注残がある商品が一目で解る。
移行数 数値FD 当該商品を出庫移行する数量をユーザが指定する。
ボタン 上記[受注残]を[移行数]に貼りつける。
出庫移行 ボタン 各商品を[移行数]分、出庫へ移行・登録する。
FD:フィールド


EasyData15.fmp12 のテーブル定義

名称 タイプ 補足
■受注テーブ
伝票区分 数値 上表参照
■受発注明細テーブル
ID 数値(主キー) 上表参照
納品計 計算(数値) Sum(入出明細_受注#注残::出庫数量)、上表及び下表参照
受注残 計算(数値) 上表参照
移行数 数値 上表参照
■入出明細テーブル
受注明細ID 数値(外部キー) 上表及び下表参照

EasyData15.fmp のリレーション

受発注明細テーブルに、[納品数]=Sum(入出明細_受注#注残::出庫数量)、を作成

EasyApp15.fmpの出庫移行ボタンのスクリプト

出庫移行ボタンは[移行数]で指定した数量分の商品を出庫に移行します ― つまり、受注画面で入力されたデータの一部を出庫(出庫/入出明細テーブル)にコピーします。ポータルを含むデータを他のテーブルにコピーする場合、1.元のデータを一旦変数に格納して変数をコピー先のテーブルに貼りつける方法と、2.元のデータを格納するテーブルからコピー先のテーブルへ取り込む方法、の2つがありますが、後者の方が高速になります。

 以下は後者の方法を用いたスクリプト例です。
(当スクリプトは検証不十分です。利用は自己責任でお願いします。 m( _ _ )m




#
#事前チェック
#
スクリプト実行 [ 「gブラウズ以外実行不可-IwpWD」 ]
スクリプト実行 [ 「gレコード無CK-IwpWD」 ]
スクリプト実行 [ 「gレコード確定強制-IwpWD」 ]
#
#受注ヘッダ情報をUIのグローバルフィールドにセット(後でUIを取り込み、出庫ヘッダを作成する前処理)
#
フィールド設定 [ UI::gCompId; 受注::得意先ID ]
フィールド設定 [ UI::gDeptId; 受注::請求部署ID ]
フィールド設定 [ UI::gPicId; 受注::担当ID ]
フィールド設定 [ UI::gTaxRate; 受注::消費税率 ]
フィールド設定 [ UI::gDate; Get(日付) ]
変数を設定 [ $oriWinName; 値:Get ( ウインドウ名 ) //スクリプトの最後でこのウインドウに戻る為、記憶する ]
#
#移行する受注明細を抽出
#
関連レコードへ移動 [ テーブル: 「受発注明細_受注」; 使用するレイアウト: 「受注明細#取込」 (受発注明細_受注) ] [ 関連レコードのみを表示; 新規ウインドウ ]
変数を設定 [ $orderNo; 値:受注::受注No ]
検索実行 [ 指定された検索条件: レコードの検索; 条件: 受発注明細_受注::受注No: 「$orderNo」 AND 受発注明細_受注::移行数量: 「>-9999999999」 ] [ 記憶する ]
#
#UI→出庫取込
#

関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 37 のインポート 出庫::得意先ID ソースフィールド 38 のインポート 出庫::請求部署ID ソースフィールド 39 のインポート 出庫::担当ID ソースフィールド 40 のインポート 出庫::消費税率 ソースフィールド 41 のインポート 出庫::出庫日 ] [ ダイアログなし ]
変数を設定 [ $shipNo; 値:出庫::出庫No ]
#
#受注明細→出庫明細を取込
#
レイアウト切り替え [ 「出庫伝票」 (入出明細_出庫) ]
レコードのインポート [ ソース: 「file:EasyApp15_p」; ターゲット: 「入出明細_出庫」; 方法: 追加; 文字セット: 「シフト JIS」; フィールドデータのインポート順: ソースフィールド 2 のインポート 入出明細_出庫::商品ID ソースフィールド 3 のインポート 入出明細_出庫::販売単価 ソースフィールド 13 のインポート 入出明細_出庫::備考 ソースフィールド 14 のインポート 入出明細_出庫::単位 ソースフィールド 15 のインポート 入出明細_出庫::受注明細ID ソースフィールド 20 のインポート 入出明細_出庫::出庫数量 ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::出庫No; 計算で置き換える: $shipNo ] [ ダイアログなし ]
フィールド内容の全置換 [ 入出明細_出庫::入出庫日; 計算で置き換える: Get(日付) ] [ ダイアログなし ]
関連レコードへ移動 [ テーブル: 「出庫」; 使用するレイアウト: 「出庫」 (出庫) ] [ 関連レコードのみを表示 ]
ウインドウの調整 [ 収まるようにサイズ変更 ]
ウインドウを選択 [ 名前: $oriWinName; 現在のファイル ]
フィールドへ移動 [ 受発注明細_受注::移行数量 ]
#
#移行数FDはクリアしておく
#
Loop
  Exit Loop If [ 受発注明細_受注::Id = "" ]
  フィールド設定 [ 受発注明細_受注::移行数量; "" ]
  ポータル内の行へ移動 [ 次の; 最後まできたら終了 ]
End Loop
レコード/検索条件確定 [ ダイアログなし ]


以上


(土屋)

2014-10-08

iPad のバーコードスキャンで入庫伝票を作成 ― FMEasy在庫のカスタマイズ

FileMaker Go 13 を使ったバーコード読み取り機能について

 FileMaker Go 13 にはバーコード読み取り機能が付属しています。
 専用のバーコードリーダーをお持ちであれば、もともとデスクトップからバーコード入力できますが、バーコードリーダーをお持ちでなくても、iPhone や iPad のカメラ機能でバーコードを読み取れるようになったのは嬉しいですね。



 外回りが多い営業さんや、倉庫管理をする際にも、モバイル操作でバーコード読み取りができれば、適用範囲も広がりそうです。

 今回は、弊社製品『FMEasy在庫』をカスタマイズすることによって、iPad から商品バーコード(JAN)を読み取りながら、入庫登録ができるようにする方法をご紹介します。


【開発レベル】
中級(レイアウト修正、テーブル修正、スクリプト修正について理解している)

【用意するもの】
1. 『FMEasy在庫 R1.0』または『FMEasy在庫 IWP/WD R1.5』
『FMEasy在庫』はこちらからダウンロードできます。
2. iPad/iPad Mini
3. FileMaker Go 13 (iPad にインストール)
FileMaker Go 13 はこちらからダウンロードできます。


注意:
1. 作業を始めるまえに、必ず『FMEasy在庫』のバックアップをお取りください。
バックアップのしかたはこちらを参照
2. 作業の際、修正場所を間違えると、既存の機能が動作しなくなる可能性があります。細心の注意を払い、ご自身の責任で行ってください。

『FMEasy在庫』に JAN 読み取り機能を追加する

 今回は、『FMEasy在庫 IWP/WD R1.5』を使って説明を進めていきますが、『FMEasy在庫 R1.0』開発版をご利用の方も、操作は同様となります。

1. 商品レイアウトに [JAN] フィールドを配置

 『FMEasy 在庫』には、[JAN] という名前の予備フィールドがあらかじめ用意されていますので、FileMaker Pro 12/13 を起動して開発者パスワードで EasyApp15.fmp12/EasyApp.fmp12 を開き、下図のように、お好みの位置に [JAN] フィールドを配置してください。



2. iPad からのJAN コード読み取り機能を商品レイアウトに追加


 iPad からから上図の[JAN]フィールドをタップしたときに、バーコード読み取り機能が走るようにします。

 スクリプトエディタを開き、「デバイスから挿入」スクリプトステップを使って[JAN]フィールドにバーコードが挿入されるように指定します。




 このとき、FileMaker Go で [JAN] フィールドをタップしたときのみ、このスクリプトが実行されるようにしますので、一行目の If 文に PatternCount(Get ( アプリケーションバージョン ); "Go") が指定されているところに注目してください。

 バーコードの読み取りが終わったら、次のフィールドに移動するように設計しておくと、システム運用時に使いやすくなるでしょう。

 これをスクリプトトリガとして、商品画面の [JAN] フィールドに設定します。
 イベント発生のタイミングは、OnObjectEnter (タップ時)になります。



 ここまでできたらレイアウトを保存します。

 FileMaker Go 13 で商品レコードにアクセスし、[JAN] フィールドをタップするとカメラに切り替わりますので、JAN のバーコードを読み取ると、JAN コードが登録されます。



 同じ要領で、JAN コードを商品マスタに登録していきましょう。



3. 入出明細テーブルに [JAN] フィールドを追加

 EasyData15.fmp12/EasyData.fmp12 のフィールド定義を開き、入出明細テーブルに [JAN] フィールドをテキスト型で追加します。



4. 入出明細の [JAN] から商品マスタの [商品ID]を呼び出すためのリレーションを追加

 EasyApp15.fmp12/EasyApp.fmp12 のリレーション定義を開き、「入庫レイアウト TOG」のセクションに下図のようにリレーションを追加します。

 入庫_商品#JAN TO の参照テーブルは商品テーブルです。
 商品と入出明細の [JAN] を関連づけます。



5. iPad 用の入庫管理レイアウトを作る

 EasyApp15.fmp12/EasyApp.fmp12 のレイアウトモードで新規レイアウトを作成します。
 FileMaker Pro 13 では、下図のように視覚的にレイアウトを作成できます。

 このとき、表示するレコードは「入庫」、レイアウト名は ipad 用の入庫画面とわかる名前を指定しておきます。

 また、ここでは縦置きを前提にしたレイアウト選択を行っていますが、運用時に縦置きと横置きとでどちらが使い勝手が良くなるかを事前によく検討しておくと、後々のレイアウト調整の手間が省けます。



 レイアウトのテーマや体裁はお好みで結構ですが、明細部分に [入出明細_入庫::JAN] フィールドを配置するのを忘れないようにしてください。

 たとえば、できあがったレイアウトを FileMaker Go 13 で閲覧してみると、以下のようになります。


 上図のように、[商品ID]と[JAN]フィールドは両方配置してください。

6. [JAN] のバーコード読み取りスクリプトを作り、OnObjectEnter のスクリプトトリガとして動作させる

 前述「2. iPad からのJAN コード読み取り機能を商品レイアウトに追加」と同じ操作になりますので、ここでは説明を省略します。
 
7. [商品ID]/[JAN] 相互呼び出しのスクリプトトリガを追加する

 iPad入庫画面で、[商品ID] を入力したら [JAN] を自動的に呼び出し、また[JAN]を入力したら [商品ID]を自動的に呼び出すようにスクリプトを作成します。

 『FMEasy在庫』のような分離モデルを採用したシステムの場合、レコード未確定状態ではフィールド定義のルックアップが正常に動作しないことがありますので、このスクリプトを考慮されるとよいでしょう。

備考: [仕入単価]、[単位]の呼び出しも用意しておくとより確実でしょう。



 スクリプトができたら、iPad入庫画面の [商品ID] と [JAN] のそれぞれに、OnObjectSave のタイミングでスクリプトトリガを設定します。



 これで準備が整いました。


 以降はデモビデオで実際の操作感をご覧ください。

『FMEasy在庫』に iPad から入庫登録をするデモ動画

商品を仕入れたという前提で、iPad入庫画面で商品のバーコードを読み取って JAN コードを入力しているところです。

 

 JAN コードの入力のタイミングで、[商品ID] が自動入力されます。
[数量]を入力すると、制御が次の行に移ることによって[JAN] 読み取りのスタンバイ状態になりますので、連続的な操作でバーコード読み取りができます。


 実際にやってみてわかったことですが、カメラ機能のフォーカスを合せるのに少々コツがいります。
 今回は手ブレ対策として、このように鉄アレイで本体を固定してバーコード読み取りをしました。



補足:
 このような iPad スタンドを使ってみると作業しやすくなるかもしれません。
 鉄アレイに比べれば見た目もグーーーンとおシャレですし、何と言っても角度を変えられますから^^。



※『FMEasy在庫』をカスタマイズするには、開発版が必要となります。


参考記事:
FileMaker Go による iPad/iPhone 向けソリューションの開発ヒント集


『FMEasy在庫』カスタマイズ関連記事:
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (1)
受注・受注残管理モジュールを作る ― FMEasy在庫のカスタマイズ (2)



2014-10-07

土屋企画のソフトウェア販売サイトのご案内

 本稿土屋企画の製品購入サイトの説明となります。購入サイトをご利用いただくには、こちらをクリックして以下のページを表示します。


注:
本システムは FileMakerインスタントWeb(IWP)と SQL Server 2000 により開発・運用されています。


1. 新規購入と登録ユーザによる購入

上図のページで新規のお客様は“新規購入”ボタンをクリックしてください(以下、「2-A 新規購入」参照)。土屋企画製品の登録ユーザの方は“ログイン”ボタンをクリックし、次の画面で[アカウント名]と[パスワード]を入力して“ログイン”をクリックします(以下、「2-B 登録ユーザによる購入」参照)。

2-A. 新規購入

“新規購入”ボタンをクリックすると、下記のページが表示されます。

  1. まず「お客様情報」欄の各項目に必要な情報を入力してください。*が付いている項目は入力が必須です。
  2. 次に希望の商品を「買い物カゴ」タブに入れます。[新規購入]タブ内の商品の右端にある“カゴへ”をクリックすると、その商品が「買い物カゴ」タブ内に表示されます(以下、「3.買い物カゴ」参照)。

    注:
    [製品名]をクリックすると、製品の案内ページが表示されます。

2-B. 登録ユーザによる購入

ログインに成功する以下のページが表示されます。ウインドウ右上部にある“製品購入申込”ボタンをクリックします。

「購入/アップグレード ― 入力」のページに、お客様の情報が入力された状態で表示されます。
必要に応じて「お客様情報」欄の項目を変更してください。 本システムにログインするときに必要となる[アカウント名]および[パスワード]もこちらのページで変更が可能です。

本ページ下部には4つのタブがあります。
タブ 説明
アップグレード アップグレード可能な製品がある場合、表示される
新規購入 新規購入可能な製品が表示される
お得意様優待 優待販売がある場合、表示される
買い物カゴ 他の3つのタブ上にある“カゴへ”ボタンで選択された製品が表示される


■アップグレードタブ

[対象ライセンス]が複数ある場合、つまりアップグレード可能なライセンスが複数ある場合、
目的のライセンスをクリックして選択すると、右にアップグレード可能な製品が表示される

アップグレード可能な製品がある場合は、「アップグレード」タブ内にその製品が表示されます。アップグレードする製品の右にある“カゴへ”をクリックすると、その商品が「買い物カゴ」タブ内に表示されます(以下、「3.買い物カゴ」参照)。

注:
[対象ライセンス]が複数行ある場合、アップグレードするライセンスをクリックして選択してください。選択したライセンスに対するアップグレード可能な製品が右側に表示されます。

■新規購入タブ
上記「2-A 新規購入」参照。

■お得意様優待タブ
お得意様を対象とした優待販売製品が表示されます。製品の右にある“カゴへ”をクリックすると、その製品が「買い物カゴ」タブ内に表示されます(以下、「3.買い物カゴ」参照)。
注:
優待販売は期間限定の為、本タブには何も表示されないことがあります。

3. 買い物カゴ

上述の各タブにある“カゴへ”ボタンをクリックすると、その製品が[買い物カゴ]タブ内に移動します。他にも購入する製品がある場合は、適切なタブをクリックして購入する製品の“カゴへ”ボタンをクリックして、その製品を[買い物カゴ]タブへ移動します。購入する製品を登録し終えたら、“確認画面へ”ボタンをクリックします。 


項目説明

項目 説明 補足
クリックすると数量が1増す アップグレード製品の場合、本ボタンは動作せず
クリックすると数量が1減る アップグレード製品の場合、本ボタンは動作せず
× 製品を買い物カゴから削除する
確認画面へ 確認画面へ移動

4. ご注文確認ページ

 本ページで注文内容をご確認頂き、修正が必要であれば“前画面へ戻る”を、修正が不要であれば“注文を確定する”をクリックしてください。 “注文を確定する”をクリックすると、注文完了ページが表示されます。



5. 注文完了ページ

注文が完了しました。お客様には注文の確認のメールが自動送信されます。



以上



【IWP関連記事】

【IWP関連の製品・サービス】