雑貨製造業向けの販売管理システムをリリースしました
Windowsフォーム→WPFに刷新して、空いた時間でコツコツ作っていた販売管理システムを、８月にリリースしました。他社利用も始まっており、後には戻れない〜。
技術的な話
フロントはWPF、バックエンドはPythonで、HTTPSでJSONのやり取りを行っています。
MVVMフレームワークに、Prism7.2を採用しています。PythonはFlask/SQLAlchemyで、Nginx+Gunicornのリバースプロキシ入り環境をDockerでコンテナ化してます。
WPFを選んだ理由は以下の通りです。Electronだと無理な要件が多かったため。
- グリッドのセル入力やセルのフォーカス制御など、グリッドの操作性の高さが必要だった
- 画面を切り替えても入力中データがローカルに残るため、利便性が高かった
- 帳票のダイレクト印刷が必要だった
- キーイベントの実装が簡単
機能的な話
物売りの商売で一番面倒で重要になるのは「残管理」です。
- 取置の残管理
- 出荷残管理(先納期、分納、納入待ち)
- 注文残(入荷分から出荷する)の管理
- 入荷の残管理(発注分の入荷予定の管理)
- 在庫の管理
この辺がいい感じに連動していている販売管理システムは、あまりないと思います。
販売管理システムの切り替えをご検討の方でこの記事をご覧の方が万が一おられましたら、下記の会社フォームまでお問い合わせを頂ければ。僕が代表なので。デモ版のご案内をさせて頂きます。
CASE-WHENでWhere句を動的に組み立てる
Flask with Vue.js
やっと話が見てきた。
Javascript弱者だったため、Vue.js や Vue-cli 並びにJavascriptの開発環境とか、色んなことがつながるまで少し時間がかかった。
Vue.js のコンポーネント化にはCLIが必要
拡張子がvueのファイルにHTML/CSS/Javascriptをまとめてコンポーネント化し、そいつをimport して使うみたいなやり方をするには、ビルドが必要になる。ここでいうビルドはブラウザが理解できる形で変換をかけること。ScssファイルがCSSファイルに変換されるようなアレだ。
Javascriptの言語仕様がPythonやJava等に比べて色々足りていないのを、パッケージマネージャやビルドツールを使って頑張っているのだなぁ。JSのビルドには内部的にJSを使っているため、Node.jsベースのパッケージマネージャであるnpmがあるわけやな。
Flask連携
Flask側は大したことやる必要なくて、ポイントはテンプレートフォルダと静的なファイルを置くフォルダをビルドされた環境に合わせるだけ。あとは、その内容をFlaskがレンダリングするというだけの話。
Vue.jsでSPA化したものをPWAで画像関係をキャッシュしてより高速にしたいものだ。
決算期で集計する場合は、決算月だけマイナスすればいい
3月決算の会社の場合、4月〜翌月3月までが1年という単位になる。これをCASE句でまとめるのはツライ。同じ年度であることさえわかればGroupByできる。
4月1日〜翌3月31日を1年としたいなら、現在の日付から３ヶ月マイナスすればやっていける。
2018年1月〜3月から3ヶ月引くと、2017年10月〜12月になるから、2017年。
2018年4月〜12月は、2018年1月〜9月になるから、2018年。
2019年1月〜3月は、2018年10月〜12月になるから、2018年。
2019年4月以降は・・・2019年！
12月決算以外は、決算月の数値だけNヶ月さかのぼるだけ良い。12月決算は1月1日〜12月31日だから、通常の年度でいいから別段なにもしなくてよい。
検証した
かんぺき。シカクいアタマをマルくしないと、生きていけない。
縦持ちの場合はこういうSQLになる
3月決算の場合です。3という固定値をプレースホルダーにすれば、どの決算月でもおｋ！
SELECT date_format(e.billdate, '%Y年%m月'), e.subtotal FROM earnings AS e GROUP BY YEAR(e.billdate - INTERVAL (3 % 12) MONTH), MONTH(e.billdate) ORDER BY date_format(e.billdate,'%Y%m' )
横持ち(つまり、12ヶ月分のカラムを並べる)の場合は、CASE-WHENで頑張るしか無いな・・・
SELECT CASE WHEN MONTH(e.billdate) = 4 THEN e.subtotal ELSE 0 END AS '4', CASE WHEN MONTH(e.billdate) = 5 THEN e.subtotal ELSE 0 END AS '5', CASE WHEN MONTH(e.billdate) = 5 THEN e.subtotal ELSE 0 END AS '6' -- 以下略 FROM earnings AS e GROUP BY YEAR(e.billdate - INTERVAL (3 % 12) MONTH), MONTH(e.billdate) ORDER BY date_format(e.billdate,'%Y%m' )
横持ちについては、縦で取得してPythonならPandasとか使ってそっちで集計して、画面に出すってのもありかも〜
PWAを覚えるぞ
販売管理システムのデスクトップアプリは、ほぼ出来上がってきた。日常業務をこなすには問題なく、あとは管理業務としての分析・帳票出力・権限管理などが控えているが、4月から試験導入予定。
次の課題がスマホアプリ。主要の販売管理システムはクラサバなので、そもそも外に出れなかったりする。クラウド対応みたいな所もあるだろうけど、ブラウザでレスポンシブになるんでみたいな所しかないと思う。作るのは、顧客との販売チャネルとしてのスマホアプリ。カタログ配信、プッシュ通知、ネット注文(予約も可能)、請求、注残の管理・・・みたいなのがいい感じ出来るもの。ECのようなもんね、簡単に言えば。お客さんが注文してくれて販売管理システムに連動して請求までできれば、最強。
僕が知る限り、雑貨の小売店の現場にはPCを置いてあることが少ない。本部バイヤーがいる所はまだしも、PC開いてカタログ開いてぺちぺちとキーボードを叩いて注文する時間も手間もかけられない。スマホならできるし、商品のバーコード読んだら商品詳細ページに飛ばすとか、やりたいよね。
このアプリをネイティブで作ったら死ぬ(iOS/Androidを各々作ったらすげー頑張っても半年かかる)ので、PWAで作る。デバイスが必要なのカメラだけだし。SNS連携とか一切いらないし。1ヶ月あれば、だいたいの実装はできそうな気がする。見えていないのはキャッシュのさせ方。動的なクエリのついたURLとか、商品データJSONとか、そういうのをオフラインでキャッシュさせたい。適切なタイミングで更新も必要だし。そのあたりが見えてくれば、あとは単なるWebアプリだし。イケそう。
やっていき。
WordPressの記事カテゴリを一括置換するSQL
プラグインとか入れるの面倒じゃないですか。
WordPressには「wp_terms」(wp_はご自身のWordPressのプレフィックスに読み替えて下さい)というテーブルがあります。ここに記事のカテゴリ等が全て格納されています。
記事のカテゴリと記事の紐付けは「wp_term_relationships」というテーブルにあります。「object_id」カラムがwp_postsの記事のIDです。「term_taxonomy_id」が「wp_terms」のterm_idと同じです。
なので、wp_termsテーブルのterm_idをメモしておいて、以下のSQLを投げると一括で記事のカテゴリを置換することができます。
UPDATE wp_term_relationships SET term_taxonomy_id = <変更後のカテゴリID> WHERE term_taxonomy_id = <変更前のカテゴリID>
IDベースではなくカテゴリ名称やスラッグベースで更新したい場合は以下のとおりです。
UPDATE wp_term_relationships AS tr JOIN wp_terms AS t ON t.term_id = tr.term_taxonomy_id SET term_taxonomy_id = ( SELECT term_id FROM wp_terms AS t2 WHERE t2.slug = 'after' ) WHERE t.slug = 'before';
beforeを置換前のカテゴリのスラッグ名称、afterを置換後のカテゴリのスラッグ名称にして下さい。
また、記事を置換しただけでは、wp_term_taxonomyのcountカラムが更新されません。置換前の件数が残ってしまうので、適宜UPDATEしてください。
販売管理システムのリリース間近
2017年10月頃からお話をもらっていた販売管理システム、MVPレベルでリリースできそうです。1次フェーズってやつですね。ファーストユーザである先方には圧倒的感謝。
自分が雑貨メーカーの中で業務を回していたこともあり、良くも悪くも細かい点に気がついてしまい、それらの例外処理パターンを整理整頓してルールに落とすこと、その(実は結構複雑な)ルールを画面からは感じさせずに、流れるように仕事ができること。そこに腐心しました。
販売管理は納品伝票が起こせたらあとは簡単。締め処理するだけ。問題は、そこに至るまで。注文をそのまま入力して出荷すればいい、とはいかないのです。
注文受けたらそのまま出荷できる以外のパターンが、代表的なものでこれだけある。
- 欠品(入荷次第納品希望なら注残になる)
- 分納(納期別 / 商品別)
- 取置
- 注残
分納には、納期別と商品別の2種類がある。納期別は、同じ商品で納期が違うもの。商品別は、全部で10の商品を注文してくれて、5つは即納、残り5つは二週間後になるもの。この場合、2週間後を待ち続けるとキャンセルを食らう可能性があるので即納分は先に出荷したい、とか。欠品なら次回入荷を自動で出して、注残であれば最短納期で一旦入荷予定の在庫から引き当てる、とか。色々なことが必要になります。
また、ほとんどのメーカーは中国やベトナムから輸入しているので、輸入事務のサポート、為替を絡めた原価計算など、その点も次のフェーズでやっていかねばなりません。営業マンに使ってもらう営業支援のスマホアプリ並びにお客様に使ってもらうスマホアプリの開発も控えております。
雑貨販売業がサブスクリプション制でずっと使いたいと思ってもらえる、販売管理を中心としたサービス展開をやりたい。販売管理が業務系パッケージで最もシェアが大きいし、硬直的で新しいシステムが全然ないので、チャンスだと思っている。自分が雑貨販売をやるかもしれないので、ま、ライフワークのようなものですね。空いた時間でやっていたから中々進まなかったけど、幹となる販売管理システムがリリースできれば、折り返し地点には来れた〜。
2018年は空いた時間全てこのリリースに注いでいたので、全然他の動きができなかった。2019年は体制強化の話も進められそうで、楽しみが多い1年です。予定納税などの恐怖が待ち構える創業3年目、やっていきだ。
