1.「中小企業共通EDI」の導入目的はIT化による業務効率化だけではありません。

中小企業共通EDIは、「中小企業が抱える受発注業務のIT化に係る問題を解決するとともに、①業務効率アップでコスト削減②人的ミスを軽減③過去現在の取引データの検索の簡素化を実現できます。」(中小企業庁HPより)とされてます。
https://www.chusho.meti.go.jp/keiei/gijut/edi.htm

これに加えて、「中小企業の資金繰り改善」
(=大企業から中小企業への速やかな支払い)
が期待できるのです。

中小企業の資金繰り

サプライチェーンにおいて、大企業から中小企業に発注を行い、中小企業は納品の翌月末に支払を受けるケースが殆どです。納品後の代金回収までの間、原材料費や労務費の資金繰りは中小企業にとって厳しいものになってます。
納品後速やかに支払がされれば、中小企業の資金繰り改善が期待できるのです。

また、大企業にとっては、中小企業共通EDIの導入により、支払業務の効率化が図れるということになりますし、「早く支払ってくれる会社」のイメージアップになります。

「中小企業共通EDIとは」については、つなぐITコンソーシアムのサイトをご覧ください。(当社は、つなぐITコンソーシアムの正会員です。)
https://tsunagu-it.com/cons/about_edi/

投稿者:systemkanri 投稿日時:

2.「中小企業共通EDI」の導入で請求書(書面)は不要にできる?

中小企業共通EDIでは、下記の図の通り、請求メッセージもサポートされてます。

出典:中小企業共通EDIの取引プロセスとメッセージ体系
「中小企業共通EDIガイドブック ver.3」(ITコーディネータ協会)

支払を速やかに行うために、検収を行ったのち、検収の情報をもとに支払を行うことができると考えられます。そうなると、支払を受ける側は書面での請求書の発行または共通EDIの請求メッセージ送信が不要になるのでは?と考えられます。


請求書は無くても良いのか?

そもそも、請求書なくても支払ことについて、問題ないのかという疑問があります。

結論から言うと、取引内容を証明できれば、支払をおこなっても問題ないのです。

そもそも「請求書」を発行する意味、また、「請求書」」を受け取る意味は何か。

請求書を発行する側は、
「この取引内容について、この金額を請求します。」
という通知連絡であり、

請求書を受け取る側は、
「取引内容と金額」について、自分が把握している事実と一致していること
を確認するために使っているのです。
※補足:取引内容については、納品書や作業完了報告書の提示を利用する場合あります。

共通EDIで、発注、受注、納品、検収のやり取りが記録されていれば、
月締め処理において上記の確認は不要になると言えます。

また、税務調査があった場合に、支払の証明として証憑の提示が求めらます。
共通EDIで発注、受注、納品、検収の取引を行っていれば、
「取引内容の証明」は、共通EDIで担保できますので、
請求書がなく支払しても問題ないということになります。

支払を受ける側としても、取引内容が共通EDIに記録されてますので同様です。


月の取引量で割り引く場合

一方で、1ヶ月の取引金額に応じて割引するケースがある場合は、月締め処理にて月の取引金額を合計して、割引金額を算出し、これを差し引いた請求金額で取引先に請求書として発行することになります。このようなケースの場合は、請求書が必要になってきます。

なお、請求書(書面)の廃止については、一度、顧問税理士に確認することをお勧め致します。

投稿者:systemkanri 投稿日時:

3.「中小企業共通EDI」とインボイス制度(適格請求書等保存方式)との関係

2023年10月1日よりインボイス制度(適格請求書等保存方式)が導入されます。
※2023年9月30日までは、「区分記載請求書等保存方式」になります。

請求書の電子化

適格請求書とは

適格請求書とは、「売手が、買手に対し正確な適用税率や消費税額等を伝えるための手段」とされている。
これは、買手側が仕入税額控除を行うための要件になりますので、大手企業から受注している中小企業(売手)においては、適格請求書の発行が必須になってくると考えて良いのです。なお、適格請求書を発行(交付)するには、「適格請求書発行事業者」として登録を受ける必要があります。

これを踏まえると、請求書を発行する必要があるということになるのですが、

  1. 電磁的記録でもOK
  2. 仕入明細もOK(相手方の確認を受けたもの)

とされてます。


電磁的記録

「電磁的記録」は、中小企業共通EDIを提供するプロバイダー側が担います。プロバイダー側でEDIデータが改ざんされることなく保存され、かつ検索が可能であれば「電磁的記録」に該当すると言えます。

中小企業共通EDIでは、メッセージ仕様ver.2 で適格請求書に記載が必要な情報項目が追加されております。


請求発行処理も不要になると期待

つまり、中小企業共通EDIを利用することで、紙面はもちろん、PDFファイルでの作成も、請求発行処理も不要になると期待できます。

ご参考:国税庁「消費税の仕入税額控除の方式として適格請求書等保存方式が導入されます(リーフレット)(平成30年4月)(令和2年1月改訂)」https://www.nta.go.jp/taxes/shiraberu/zeimokubetsu/shohi/keigenzeiritsu/pdf/300416.pdf
※2ページ目に「書面での交付に代えて、電磁的記録により提供することもできます。」と記載があります。

投稿者:systemkanri 投稿日時:

4.中小企業共通EDIと全銀EDI(ZEDI)の連携で究極の業務効率化へ

業務の効率化には、中小企業共通EDIと全銀EDI(ZEDI)の連携が重要になります。


「商流EDI」と「金融EDI」

中小企業共通EDIは、受発注や出荷検収のやり取りが中心であり「商流EDI」とも呼ばれております。一方で、ZEDIは、振込情報や入金情報の伝達であり「金融EDI」とも呼ばれております。
商流EDIで検収した注文番号をZEDIの振込情報に付加することで、振込まれた取引先では入金情報の注文番号を元に、消込が確実に行えるものになります。もちろん、自動消込も可能になります。


取引とお金の紐づけ

取引とお金の流れが紐づくことで、営業部門が行う販売管理・在庫管理と経理部門が行う請求・支払・入金業務の一気通貫するデータ連携が実現し、究極の業務効率化が可能になるのです。

商流EDIと金融EDI
商流EDIと金融EDI
投稿者:systemkanri 投稿日時:

5.販売管理・在庫管理と中小企業共通EDIとZEDIと会計が連携するオールクラウド®の姿

中小企業共通EDIの導入により、データ入力の手間削減や書類ファイリング等のタスクが不要になるなど、業務に費やす時間を6割近く削減できたと報告されております。
一方で、中小企業共通EDIの導入における課題も挙げられています。


中小企業共通EDIの導入における課題

それは、社内業務システムとの連携です。

参考資料:中小企業庁の委託事業として、特定非営利活動法人 IT コーディネータ協会が実施した「平成 28 年度 経営力向上・IT 基盤整備支援事業(次世代企業間データ連携調査事業)」
平成28年度経営力向上・IT基盤整備支援事業調査報告書
https://www.chusho.meti.go.jp/keiei/gijut/2019/190403ed101.pdf

中小企業共通EDIと社内業務システムとの情報連携が不十分なため、十分な効果が得られないということです。


中小企業の社内業務システム

社内業務システムとは、販売管理・在庫管理・生産管理システムです。

販売管理・在庫管理・生産管理システムは、汎用パッケージを利用する場合が多いですが、自社の業務に合せるとなると、カスタマイズが発生します。また、そもそも自社の業務に合うパッケージが無いなどで、スクラッチ開発(すべて開発)されるケースもあります。


中小企業は独自の業務フローで成り立っている

中小企業は独自の業務フローで成り立っているケースが多いため、自社に合わないパッケージを無理に利用し、エクセルなどで独自業務領域をカバーするなどで対応されいてるようです。

この状態が、社内業務システムと中小企業共通EDIの連携を難しくしているのです。


サイボウズ社kintoneを中心にオールクラウド®

そこで、弊社ではサイボウズ社kintoneを中心にオールクラウド®による基幹業務システムをご提案しております。

特に販売管理「販売9」と在庫管理「在庫10」は、サイボウズ社kintone上で動作するアプリでご提供しております。このアプリは、導入企業様にて自社業務に合せてフィールドの追加が可能になっております。
また、中小企業共通EDIとの連携アプリも合せてご利用頂けます。
クラウド会計についても、会計freeeへの連携プラグインで連携が可能です。ZEDIでの連携については、今後、会計freeeの支払機能がZEDIに対応してくれることを期待します。

販売管理・在庫管理と中小企業EDIとZEDIと会計が連携するオールクラウド®の姿

投稿者:systemkanri 投稿日時:

1 Salesforceからkintoneへのデータ移行

1-1 データ移行する際の基本的な考え方

 データ移行する際にSalesforceからデータをダウンロードしてきた際には、オブジェクト単位となっています。Salesforceでいうところの1オブジェクトに対してkintoneの1アプリを作成することになります。今回のデータ移行後の運用は販売9を想定していますが、販売9へデータ移行する内容はマスタ系データのみとし、トランザクション系データは販売9へ移行しません。では、過去のデータはどうするかというと一旦Salesforceのデータを全てkintoneアプリにし、マスタ系のデータは、そこから販売9への移行対象としますがトランザクション系データは移行の対象とせず、kintoneアプリ内でデータを見られるようにしておきます。そうすれば、過去のトランザクション系データもkintone内で確認できるようになります。こういった考え方でデータ移行を進めていきます。

1-2 SalesforceユーザIDとkintoneユーザIDの紐づけを諦める

 Salesforceでデータをダウンロードするとユーザ名ではなく、ユーザIDとなってしまいます。ユーザIDのままkintoneへ移行しても、何の情報だかわかりませんから、データを移行する前にユーザIDをユーザ名に置き換えます。その置き換えた後のデータをkintoneへデータ移行します。SalesforceとkintoneそれぞれのID同士を紐づけておいて、と考えたくなるところですが、Salesforceとkintoneのユーザ管理はそれぞれありますので、運用が大変複雑になってしまいます。データ移行の際は、名称に置き換えてデータ移行し、ID同士の紐づけは諦めることが大切です。

1-3 SalesforceからCSV出力した際の日本語表記へ変換

 Salesforceからデータをダウンロードすると、いわゆるヘッダー部分がすべて英語表記となっています。このまま移行すると分かりにくいので、日本語の項目名にヘッダーを変換する作業が必要となります。すべての項目において日本語名が存在するわけではないので、日本語名が存在する項目のみ英語表記からヘッダーに変換します。

1-4 Salesforce各オブジェクト毎の紐づけ

 Salesforceではオブジェクト毎にIDで紐づけがされています。よってkintoneのアプリにおいても、アプリ間で紐づけを行うことが必要になります。SalesforceのIDで紐づけが行われている内容を紐解いて、必要に応じてkintoneアプリの標準機能である関連一覧やルックアップ機能を使って紐づけを行っていきます。

1-5 kintoneの50項目制限についての注意

 SalesforceからダウンロードしてきたCSVをkintoneにアップロードする時に、新規でアプリを作成する場合は、項目が50項目以内でなければならないというkintoneの制限を受けることになります。。Salesforceからダウンロードする内容は入力項目以外のSalesforceシステム内部で持っている項目が多く含まれていますので、50項目を超えることが多くなります。この50項目制限に注意してkintoneアプリを作成していくことになります。
(※ただし弊社ツールを使えば50項目制限なく新規アプリを作成できます)

投稿者:systemkanri 投稿日時:

2 Salesforceから販売9へ移行

2-1 販売9について

 Salesforceからkintoneへ移行する際に弊社の販売9のアプリパッケージをベースに開発を行います。この販売9をベースにすることでよりスムーズにそしてスピーディーに移行を進めることができます。販売9は案件管理・見積受注管理・顧客管理・請求管理など販売管理に関する機能が詰まった弊社開発のアプリパッケージとなります。

2-2 マスタ系アプリとトランザクション系アプリの考え方

 販売9には、9つのアプリから構成されています。データ移行の際に重要になる考え方がマスタ系アプリとトランザクション系アプリに分けて販売9へのデータ移行はマスタ系アプリのみとするという点です。販売9は、案件アプリ・受注明細アプリ・請求アプリ・発注明細アプリ・発注アプリ・販売商品アプリ・仕入商品アプリ・取引先台帳・仕入先台帳のアプリから構成されていますが、販売9のアプリへのデータ移行は、マスタ系アプリ(販売商品・仕入商品・取引先台帳・仕入先台帳)とします。それ以外のトランザクション系データは販売9にデータ移行せず、別にアプリを作成し、データの中身は見られるようにしておきます。

2-3 仕入商品と販売商品の紐づけ

 販売9は仕入商品と販売商品と別々のアプリで管理できるようになっています。よって仕入商品Nに対して販売商品Nを設定できるようになっています。しかしながら仕入販売等のビジネスモデルであれは、仕入商品Nに対して販売商品Nの関係性は必要なく、仕入商品1に対して販売商品1という関係性が概ね成り立つというパターンが多いと思います。その場合は、仕入商品と販売商品を紐づけておいて仕入商品を登録した際に販売商品も同時に登録できるようにすることができます。また案件を受注した際に販売商品を受注明細に展開すると同時に、仕入商品も発注明細に展開することも可能です。(いずれも有償オプション)こうしておくと販売商品を登録するだけで仕入商品も発注明細として作成されますので、2重入力を回避することができます。

2-4 販売9のメリット

 Salesforceのデータ移行をする際にイチからkintoneのアプリを作成するとなると、かなりの開発工数がかかってしまいます。弊社ではSalesforceからkintoneへ乗り換えをする際には販売9を前提に進めますので、販売9をベースに貴社の業務フローやFIT&GAPを打合せさせていただくことで、スピーディーに乗り換えすることが可能です。販売管理システムは企業の根幹のシステムになりますので、乗り換えに要する期間はできるだけ短くしたいものです。弊社の販売9をベースにしたSalesforeceからkintoneへの乗り換えをご検討の方は是非お問い合わせください。

投稿者:systemkanri 投稿日時:

kintoneを活用したサブスクリプション継続請求管理セミナー(2019年4月25日)受付終了

kintoneを活用したサブスクリプション継続請求管理セミナー4月25日開催

煩雑化する請求業務に2つの解決策!

~データ管理とその後の請求業務~

kintoneサブスクリプション請求管理

アイティーフィットで開発したkintoneアプリパッケージである
サブスクリプション請求管理を使って請求に関するデータを管理できます。

クロネコ掛け払い

kintoneで管理した請求データが確定した後の、
与信から請求書発行、集金、入金管理および督促、未回収リスクまでを
ヤマトクレジットファイナンスがすべてを引き受けます。

 

概要説明

消費者の動向として所有から利用へと変化している中で、近年注目されているビジネスモデルが「サブスクリプション」モデルです。多くの企業が「サブスクリプション」のビジネスモデルを導入するなかで、業務煩雑化の要因となるのが請求管理となります。
一般的な売り切りの商品と合わせて、以下のような管理項目が必要になります。

  • 継続有無(継続対象かどうか)
  • 契約期間(いつからいつまで)
  • 契約単位(月単位か年単位か)
  • 自動更新有無(自動更新かどうか)
  • 解約日(いつ解約なのか)

これらの管理項目を正確に管理して、正しい請求をしなければいけません。
アイティーフィットで開発したkintoneアプリパッケージである「kintoneサブスクリプション継続請求管理」は上記の管理項目を管理して、継続請求、継続支払の管理を行うことが可能です。

現在、請求管理業務でお困りのサブスクリプションモデルを導入されている事業者さま、また導入を検討されている事業者さまに対してお役に立てる情報を提供致します。

セミナー概要

日程 2019年4月25日(木)
時間 14:00~16:30(開場13:30~)
タイトル kintoneを活用したサブスクリプション継続請求管理セミナー(参加無料)
主催 株式会社アイティーフィット
共催 サイボウズ株式会社、ヤマトクレジットファイナンス株式会社
場所 サイボウズ株式会社東京オフィス(日本橋)
東京都中央区日本橋2丁目7−1 東京日本橋タワー27階
定員 40名

登壇

・サイボウズ株式会社
・株式会社アイティーフィット
・ヤマトクレジットファイナンス株式会社

当日のスケジュール

セクション 時間 タイトル 登壇
第一部 14:00~14:15 最新のkintone利用動向について サイボウズ株式会社
14:15~15:30 kintoneサブスクリプション請求管理について 株式会社アイティーフィット
休憩
第二部 15:40~16:00 請求業務のアウトソース「クロネコ掛け払い」について ヤマトクレジットファイナンス株式会社
16:00~16:30 個別相談

 

投稿者:systemkanri 投稿日時:

1 工事台帳でみんな悩んでる?実行予算とクラウド会計freeeの二重入力

工事台帳システムとクラウド会計freeeへの二重入力

工事台帳は工事請負事業者にとって欠かすことのできない管理簿になります。工事現場で管理している実行予算書(工事台帳)への入力と、経理が入力しているクラウド会計freeeへの入力を行うのです。どうして工事台帳とクラウド会計freeeのどちらも同じような内容なのに何度も入力しないといけないのか?こんなことを思われた方は多くいらっしゃるのではないでしょうか。また工事台帳システムとクラウド会計freeeの互いのシステムが連動していないために、数字が合わない場合は互いのシステムの内容をチェックしなければならず多くのチェック作業が発生してしまいます。工事台帳システムとクラウド会計freee互いのシステムが連動していれば楽になるのに、と思いながらもどうしたらシステムが連動するのか、解決の糸口が見つけられず、長い間頭を悩ませられている問題です。

なぜ二重入力が起きてしまうのでしょうか。

問題が起きる原因を探るには、実行予算に関する業務の流れを確認する必要があります。

<実行予算の流れ>

    ①実行予算を組む
    ②発注をする
    ③発注した工事に対して査定をする
    ④支払をする

※見積書作成のため受注前に実行予算を組むケースも多いと思いますが、今回は受注したあと、着工前に実行予算を組む想定で話を進めます。

おおまかな流れとしては上記の流れで行われているのではないでしょうか。③の査定をしていない会社ですと、請求書が来た内容を工事担当者に確認してOKであれば、④の支払業務を行うといった簡便的なやり方を行っているケースもあると思います。実務であれば簡便的なやり方の方が多いのが実情でしょうか。

この流れを見ただけでも多くの人やシステムが介在することになります。ここでわかり訳すするために各業務に対して誰がどのシステムを入力しているかという観点から記述していきます。(一般的な場合のみです)まず①の実行予算を組むですが、工事担当者が原価管理システムに入力します。次に②の発注をするですが、発注内容を工事担当者が原価管理システムに入力します。発注書が発行できるものが多いですが、そうでない場合は別のシステムで発行しなければなりません。③発注した工事に対して査定をするですが、2つの業務が存在します。工事担当者が原価管理システムに実績を入力する業務、経理がクラウド会計freeeに費用を入力する業務です。④支払いをするですが、経理が査定を行った内容と請求書等を突合してクラウド会計freeeで支払業務を行います。ただし支払業務が複雑な場合はクラウド会計freeeとは別のシステムで管理して支払業務を行っている場合もあると思います。

このように大まかな流れを見ただけでも、業務の流れが複雑で、手間の掛かる事であることが分かりましたでしょうか。こういった業務を一つ一つ整理しなくては業務効率の糸口を見つけることはできません。まずはここが「はじめの一歩」となります。この業務の整理ができた後の、次の一歩については次節以降を読み進めていただければと思います。

投稿者:systemkanri 投稿日時:

2 「予算」の管理はできるのに「実績」の管理ができなくなってしまう不思議

実行予算を組んだ段階での予算の原価は管理しているけど、工事が終わったあとの実績の原価が管理できていない。こういった状況になってしまっていないでしょうか?もしくは、工事毎に都度都度の実績管理ができていないので、決算を締めてみないと実績の粗利が分からないといった状況になってしまっていないでしょうか。こういった問題を抱えたまま業務を進めてしまうと、原価管理という面で大きなリスクを伴うことになります。リスクとしては大きく点あります。一つ目は予算と実績の比較ができないために工事が終わったあと検証ができないという点、二つ目は工事の途中で予算と実績に大きな乖離があった場合、そのシグナルが工事途中段階で見える化されないという点です。とくに後者については会社の業績に大きく影響しますので、この問題は是が非でも解決しておきたいものです。

なぜ予算は管理できているのに、実績が管理できなくなるのか。

これは実績を入力するタイミングが大きく影響しています。先ほどの実行予算の大まかな業務の流れをご覧ください。

<実行予算の流れ>

    ①実行予算を組む
    ②発注をする
    ③発注した工事に対して査定をする
    ④支払をする

本来であればこちらの流れで業務の流れが行われていると思います。この時に③発注した工事に対して査定をするという業務ですが、この時に発注に対しての査定が行われますので、多くの場合このタイミングで債務が確定します。要は実績が決定するわけです。この時必要な業務は工事担当者が原価管理システムに実績を入力する、経理担当者がクラウド会計freeeに費用を入力するといった2つの業務が必要になります。この2つの業務というのがミソで、会計業務は必須ですから必ず行われると思いますが、同じような業務を原価管理システムでも行わなければならないため、この時にやらなくなってしまうといったケースが多くあります。
また③の査定をしていない会社ですと、請求書が来た内容を工事担当者に確認してOKであれば、④の支払業務を行うといった簡便的なやり方を行っているため、なおさら工事担当者がその実績を原価管理システムに書き写すという業務が行われなくなってしまうというケースが多いようです。

こういったメカニズムで、「予算」の管理はできるのに「実績」の管理ができなくなってしまう、といった問題が生じているのです。

クラウド工事台帳とクラウド会計freeeのすすめ

上記の問題を解決する方法として、アイティーフィットではクラウド工事台帳とクラウド会計freeeによって、原価管理システムと会計システムの連携をご提案させて頂いております。システム連携により、クラウド工事台帳に実績を入力することによって、会計の仕訳が生成され、そのデータがクラウド会計freeeに連携されますので、重複する業務を減らすことが可能です。また実績管理が容易になりますので、工事途中であっても予算と実績の比較が容易にでき、また工事完成後の検証も行うことが出来ます。

投稿者:systemkanri 投稿日時:

3 案件を締めた後に支払の請求書が届いてびっくり!にならないための発注管理

発注管理で気を付けるべきこと

次に注意をしなくてはならない点が発注管理です。発注を行う場合、工事担当者もしくは購買を一元管理している場合は購買担当者となると思います。多くの場合は工事担当者でしょうか。発注を管理するうえで気を付けないといけないことは、発注残の管理です。実行予算に対して、これからまだ発注しなければならないのが発注残です。この発注残を管理しておかないと、予算に対して費用が超過しているのか否かを工事の途中段階の発注段階で把握することが出来なくなってしまいます。つまりは発注管理が出来なくなってしまうのです。工事担当者が現在発注しているものは予算から超過しているのか、いないのかが、発注段階で見える化されていなければ経営判断の指標としては不十分です。

発注管理を怠るとこんなケースが・・・

発注管理が行われていない場合にはこんなケースも考えられます。
決算月に案件をすべて締めて、利益が確定したかたと思った後に、業者から請求書がきて予想した利益を下回ってしまった。こういった経験はありませんでしょうか。

発注管理はクラウド工事台帳で解決!

こういった問題を解決するために、クラウド工事台帳では、予算の入力、発注の入力、発注書の発行などを一元管理しており、発注残の情報が見える化されています。また査定の情報や請求書の情報なども入れられますので、まだ査定が終わっていない発注や請求書が来ていない発注などを見ることも可能です。

会社の利益管理に関わる問題は経営判断に大きな影響を与える問題となりえます。発注管理を行い正しい経営判断に活かせるよう整備することが望まれます。

投稿者:systemkanri 投稿日時:

4 手間の掛かる振替作業がクラウドで一発解決

振替作業に関する問題

次にご紹介するのが振替作業に関する問題です。こちらについては、建設業の経理実務を行った方が経験することが多い問題です。

まずは費用の面からみていきましょう。通常まだ工事が完成していない状態で発生する費用に計上に関しては、2つのパターンで未成工事支出金の計上と振替を行っていると思います。

パターン①

一つ目のパターンは、①未完成時の費用を費用科目で計上し、期末段階でまだ未完成の場合は、その工事に関わる費用を未成工事支出金に振り返えます。その後完成した場合はその未成工事支出金の金額を完成工事原価に振り返るパターンです。

パターン②

二つ目のケースは、②未完成時の費用を未成工事支出金で一旦すべて計上して、完成した場合に、未成工事支出金を各費用科目に振替処理をするパターンです。

おそらく実務上では前者のパターン①を取られている場合が多いと思います。なぜなら、後者のパターン②に比べて非常に簡便であるからです。

パターン②のメリットとデメリット

パターン②の場合一旦未成工事支出金で計上しますので、わざわざ完成したときに費用科目別に振替処理を行わなければなりません。未成工事支出金の相手勘定科目をすべて振り返って振替伝票を作成する必要があるのです。これは大きな手間となります。しかしながら、②についてはメリットも存在します。それは月次試算表の損益が比較的正確に把握できます。なぜなら①の場合未完成時にも費用として計上されてしまいますので期中で大赤字となってしまうことが多いと思いますが、②の場合は未成工事支出金として資産計上されているため、費用計上されません。よって期中の試算表が比較的正確に把握できます。さらに、完成工事原価の詳細がきちんと費用科目ごとに把握できますので、原価管理をより詳細に記載できます。

パターン②のデメリットをクラウド工事管理とクラウド会計freeeで解決!

パターン②のケースを採用して人の手で行おうとすると、とても大変な作業となりますが、クラウド工事台帳とクラウド会計freeeによって、一発解決することが可能です。通常実行予算書には、費用の詳細が記載されています。その費用ごとに会計の費用科目を紐づけさせておくことで、完成時に振替伝票を自動で作成することが可能です。またその自動で作成された振替伝票をクラウド会計freeeに連携すれば一発で未成工事支出金の振替を行うことができます。

こういったクラウド連携の恩恵を利用することで高度な会計処理を行うことが可能となります。

投稿者:systemkanri 投稿日時:

5 もっと広がるクラウド工事台帳とクラウド会計freeeの可能性~入出金自動消込~

クラウド工事台帳とクラウド会計freeeの可能性

ここまで様々な問題に対してクラウドの有効性を述べてきましたが、もっと広がるクラウド工事台帳とクラウド会計freeeの可能性について触れたいと思います。
クラウド会計freeeは、銀行口座明細をAPI経由で自動取込して、さらに、AIを使って消込のマッチングまで行ってくれます。
こういった機能を利用してクラウド工事台帳と連携することによって、実際に入出金があったかどうかの情報を持たせることが可能です。
つまり実行予算書の収益に対しての実際の入金状況や、費用に対しての実際の出金状況などを把握することが可能です。
これにより、経理に確認するまでもなく、工事担当者は入出金の状況をクラウド工事台帳で確認することが可能となります。

こういった機能をもつシステムを構築するためには、今まで多くのIT投資が必要でした。しかしながら現在は、多くのクラウドサービス台頭により、クラウド機能の恩恵を大いに活用することが可能です。賢くクラウドサービスを活用し、より高収益体質の企業を目指しましょう。

投稿者:systemkanri 投稿日時:

1 経験と勘による在庫管理

「在庫管理は、倉庫責任者に任せているから、システム化は必要ないかな?」

表面上は上記の通り、現場に任せれば何とかなるように思われがちですが、適正な在庫管理をしないことによるデメリットがあります。

  • 倉庫責任者に聞かないと在庫が分からない。
  • 第三者による判断がない。
  • 突発的な欠品により、商品が用意できない。
  • 過剰在庫によりスペースが確保できていない。
  • 管理工数が削減できない。
  • 正しい売上原価が計算できない為、利益が分からない。
  • トラブル対応時に、商品のトレースができない。
  • 会計システムへの適切な登録ができていない。
  • 在庫管理システムはあるが、クラウド型ではないから外出先で見れない。

上記の中でも、適正な在庫管理を行わないことによって発生することが多い過少在庫、過剰在庫のデメリットは以下です。

■過少在庫によるデメリット

  1. 販売機会の損失
  2. 欠品によるクレーム

■過剰在庫によるデメリット

  1. 在庫を維持する為の費用増(倉庫代、光熱費、人件費)
  2. 商品の陳腐化(賞味期限、消費期限)による商品価値の低下
  3. 資金繰りの悪化(回収までの期間増)によるキャッシュフローの減少
投稿者:systemkanri 投稿日時:

2 欠品による機会損失の防止

欠品による機会損失を防止する為には、現場以外の部門でもリアルタイムで在庫数を把握できる仕組みと、適正な発注をする必要があります。

前述の通り、クラウド在庫管理を導入せず、倉庫責任者に一存してしまうと、営業が確度の高い商談をしている時でも、都度倉庫責任者への問い合わせが必要となります。最悪の場合、連絡がつかず、在庫が把握できなかったが為に、商談が破綻してしまう可能性もあります。

クラウド在庫管理の導入による可視化が必要

改善するには、現場の人に一存せず、クラウド在庫管理の導入による数値化、可視化が必要となります。

また、肌感覚や勘、ノウハウに頼って発注を行うと、営業側の受注見込みとの差による販売機会の損失や、発注漏れにより過少在庫になってしまいます。

調達期間(リードタイム)や発注量、発注点、また営業側の受注状況等をクラウド販売管理やクラウド在庫管理で数値化して、管理を行う必要性があります。

尚、基本的な発注として、以下の2方式が挙げられます。

・定期発注
 発注時期に在庫数を把握し、必要数量を定期的に発注する。

・定量発注
 ある一定数量を下回ると発注する。

欠品を防止するため、(安全な)在庫数を把握し、発注を行うことが肝要となります。

一方で、過剰在庫とならないために、「3 適正在庫による在庫圧縮/保管費の削減」の観点が必要となります。

投稿者:systemkanri 投稿日時:

3 適正在庫による在庫圧縮/保管費の削減

在庫圧縮並びに保管費の削減をする為には、倉庫内の整理、責任者の明確化と合わせて、商品の受注状況の把握(売れる商品と売れない商品の把握を含む。)や適正な理論在庫、実在庫の把握が必要となります。

1 経験と勘による在庫管理」でも申し上げた通り、過剰在庫による影響は各種保管費が増えるだけでなく、商品の品質低下により適正価格で販売する事ができなくなり、商品入荷時の支払いから販売して入金されるまでの期間経過によるキャッシュフローの悪化まで起きてしまいます。

上記を改善するには、物理的な対策、体制・運用での把握と合わせて、クラウド在庫管理による在庫回転率の計算やクラウド販売管理との連携などを実装する方法があります。

尚、在庫の量を判断する指標として、在庫回転率が挙げられます。

在庫回転率(回) = 出庫金額(年間の売り上げ) ÷ 在庫金額(棚卸資産)*1

*1:(期首在庫+期末在庫)/2



在庫回転率が低いものは現金化するまでに時間が掛かっているものと判断できる為、在庫回転率が低い商品の在庫数量を削減することにより、在庫圧縮/保管費の削減を実現することができます。

投稿者:systemkanri 投稿日時:

4 トレーサビリティを実現し顧客満足度向上

トレーサビリティとは

トレーサビリティとは、特定のロットの商品が、いつどこでどのようにしたのかを入荷、製造から納品、廃棄まで追跡できる仕組みを指します。

トレーサビリティの管理ができていないと、リコールなど万が一の事態が発生した際に、どのお客様に影響があるのか、原因はどこにあるのかといったことが迅速に対応できなくなってしまいます。
場合によっては、影響範囲が分からず、全ての商品を回収する必要があります。

トレーサビリティの実装

リスク回避と共に顧客満足度を向上する意味でも、クラウド在庫管理によるトレーサビリティの実装は必然と考えます。

トレーサビリティを実現する為には、以下2点による双方向からトレースする機能を備えたクラウド在庫管理の導入が必要となります。


・トレースフォワード
 製品自体に問題が発生した際、どこで問題が発生をしていたのか、原因はどこにあるのかといったものを特定する為に、製造段階まで遡ること。


・トレースバック
 製品の出荷後、製造物の元となるもの(パーツや原材料など)に問題がある事が分かった際、その元となるものが使われた製品を特定、回収すること。

また、ロット番号による記録、管理をしておく事により、上記トレーサビリティが円滑になり、また賞味期限の管理や先入れ先出しを行っている場合に、出荷先の特定が詳細かつ迅速に可能となります。

尚、適正なトレーサビリティを実現する大前提として、正確な検品作業が必須です。

クラウド販売管理と連動した上で、受注伝票から出荷指図書を生成し、出荷指図書に基づき、ピッキング(出荷処理)を行います。
また、発注伝票から入荷指図書を生成し、入荷指図書に基づき、ピッキング(入荷処理)を行います。

また、検品を行う際にはバーコードリーダーの導入、スキャン項目の精査、作業区分や動線の見直しなどを行う事により、作業効率化並びにミスの防止を行えます。

投稿者:systemkanri 投稿日時:

5 クラウド在庫管理とクラウド会計freee

クラウド在庫管理で管理する在庫データは、クラウド販売管理との連動だけでなく、クラウド会計freeeとも関わります。
在庫の会計処理は思っている以上に複雑なので、定義や各種数値の集計・評価方法などを理解した上で、適正なクラウド在庫管理を導入しましょう。

会計上の在庫とは

会計上の在庫とは、主に以下の3つを指します。

  1. 製品または商品
  2. 仕掛品
  3. 原材料

会計上の処理を行うには、前提条件として、これらの定義を理解した上で、各種マスタや在庫ステータスの管理をクラウド在庫管理で行う必要があります。

売上原価の原則的な算出方法

売上原価の原則的な算出方法は、以下の通りです。


売上原価 = 期首商品棚卸高 + 当期商品仕入高 - 期末商品棚卸高


期首並びに期末に棚卸結果を会計へ報告をするのが一般的ですが、プロジェクト単位での売上原価を正確に算出するには、入荷並びに出荷のタイミングで、プロジェクトと紐づけたデータを、クラウド在庫管理とクラウド会計freeeで連動する必要があります。

但し、上記運用を行うには、出荷をする度に仕分け処理を行う必要がある為、当機能を備えたクラウド在庫管理と、クラウド会計freeeへの連携を意識したシステム構築が必須となります。

投稿者:systemkanri 投稿日時:

はじめに

顧客管理、名刺データ化、案件や引き合い管理、受注や売上や請求などの販売管理、財務会計、そして、勤怠や給与計算など、業務に役に立つクラウドサービスが続々と登場してきました。今までは、自社でデータベースサーバなどのハードウェアを設置したり、パッケージソフトをインストールしていましたが、その構築作業は不要となり、利用料を支払えばすぐにインターネット上で利用することができるようになります。
また、これらの業務系クラウドサービスは、他のクラウドサービスと連携できる機能も有しており、中にはプログラミング不要で、データ連携できるクラウドサービスもあります。

IT技術者の確保が難しい企業にとっては、こうしたクラウドサービスの利用は大きなメリットがあると言えます。

しかしながら、自社の業務をクラウドサービスで実現させるためには、複数の業務系クラウドサービスを利用することになります。顧客データや案件データ、売上データ、請求データ、入金データ、会計データをどのように、結び付けて業務系クラウドサービスを連携させれば良いのか、これが難しいのです。

例えば、クラウド型販売管理サービスに売上データを登録したとします。同時に会計クラウドに売掛の仕訳レコードが登録されます。売上に対して請求書を発行し、指定銀行口座に入金があったとします。営業マンは、入金あったことをいつも利用しているクラウド型販売管理で通知を受けたいと考えるし、経理部はクラウド会計でネットバンキングによる入金データを取得するでしょう。クラウド会計からクラウド型販売管理へ入金情報を連携すれば実現はできますが、入金が前月の未払い分と合算されていたら、どうでしょうか。売掛残高をクラウド型販売管理とクラウド会計の両方で管理することになり、データと機能が重複することなります。さらに、両クラウドでの残高突合も必要になり、業務も複雑になります。

クラウド型販売管理とクラウド会計の間での機能のすみわけ、そして、アナログで残る業務、これらをうまく設計する必要があるのです。

弊社のクラウド導入経験をもとに、クラウド型販売管理とクラウド会計を中心した、業務系クラウドサービス導入の勘所をまとめました。

業務系クラウドサービスをご検討中の企業様の一助になれば幸いです。
(随時、更新しております。)

※一般的な会計システムをこのWebサイトでは「クラウド会計」と記載しております。読み替えて、お読み頂いても結構です。

株式会社アイティーフィット 小沢広文

 

販売・請求管理kintoneアプリ「販売9」とfreee連携kintoneプラグイン

kintone販売・請求管理アプリ「販売9」アプリは、無料でお使い頂けます。
会計freeeへの連携も「freee連携kintone」プラグインを導入することで可能になります。

kintone「販売9」アプリについては、こちらをご覧ください。

freee連携kintoneプラグインは、こちらをご覧ください。

投稿者:systemkanri 投稿日時:

1-1 見積から入金の流れ

1-1 見積から入金の流れ

顧客登録→案件→見積→受注→納品→請求→入金→売掛消込

ごくごく、一般的な掛売の流れになります。
一直線に業務が進んでいく流れになりますので、簡単なように感じます。

しかし、実際には、営業部、業務部、経理部など、複数の部署や担当者がこの一連の流れに関わることになります。見積と受注は営業部、納品は業務部、請求と入金と売掛消込は経理部といったケースが多いかと思います。
例えば、経理部では、納品が完了した受注がどれで、どの受注を請求して良いのか、を正確に把握する必要があるのです。案件から見積、受注、納品、請求、入金、売掛消込のそれぞれの業務において、状況を共有することが必要になるのです。

ところで、それぞれの業務において重要なデータ項目となるのは、金額と数量と日付です。
特に日付については、受注日、発送日、納品日、検収日、請求日、支払期日、入金日など様々な日付があります。これらの日付の意味を先ほどの部署間もしくは会社全体で認識を一致させることが重要です。

日付の「意味」というのは、例えば、クラウド会計に登録する際の「売上計上日」はいつでしょうか?ということです。あなたの会社は、発送日ですか?納品日ですか?それとも検収日でしょうか。

物販の場合には、売上計上日は、出荷基準、引渡基準、検収基準などがあります。

この「売上計上日」について正確にお答え頂かないと、販売管理システムを構築することができないのです。請求のタイミングにも関係します。もちろん、仕訳データそして決算にも影響します。

これと反対に、仕入については下記の通りです。

仕入先登録→発注→入荷→検収→請求(される)→支払

こちらも、仕入計上のタイミングは、入荷基準、検収基準などがあります。

クラウド型販売管理とクラウド会計では、それぞれの日付の意味が重要になります。

日付以外にも、受注残や発注残の考え方も重要です。これらについては、後の章で取り上げます。

 

投稿者:systemkanri 投稿日時:

1-2 もう一つの流れ「いきなり売上」

その場で販売(サービス提供)することで、売上が確定するケースです。店頭販売がこのケースですが、やや複雑なケースもあるのです。例えば出張修理サービスでは、修理作業費や提供部品を販売した場合で、後日、請求書発行にて請求を行う場合もあります。
この場合、見積や受注がその場で行われて、作業完了をもって売上が確定するのです。


売上 → 請求 → 入金 → 売掛消込


顧客マスタへの登録は行わず、1売上を1請求する流れになります。
前章のような一般的なクラウド型販売管理では、顧客マスタへの登録が必須になります。また、クラウド会計は、売掛を管理するために取引先として顧客マスタへの登録が必要になります。
しかし、いきなり売上する場合には、顧客登録の作業が業務負荷になったりするのです。
この場合、会計では取引先を売上に紐づけずに仕訳を行うなどの対応が必要になります。顧客情報はクラウド型販売管理側で保持することになります。なお、クラウド会計側では、仕訳データの摘要に顧客名や受注番号を付記することが多いようです。

このようにクラウド型販売管理とクラウド会計の導入においては、見積からスタートするケースか、売上からスタートするケースか、大きな違いがあるのです。

 

投稿者:systemkanri 投稿日時:

1-3 クラウド会計の範囲と限界

会計データ(仕訳)は、事後の世界。販売管理データは、現在過去未来。なのです。

例えば、クラウド会計への売上(収益)データの登録は、売上が確定した後になります。未来の日付で売上を登録するこはありません。なぜかというと、日本の会計基準では、収益(売上)は「実現主義」で認識するのが原則となっているからです。
受注した商品を出荷したことで会計の売上になります。「出荷した」は過去ですので、本日含めて過去日なのです。売上の確定をもって、クラウド会計に売上データを仕訳として登録することができるのです。(もちろん、クラウド会計でデータ入力制限が無い場合には、未来日で売上をデータ登録はできますが・・・)

クラウド型販売管理とクラウド会計の範囲は次のようになります。

 

案件

見積

受注

納品

売上

請求

入金

消込

クラウド型販売管理

クラウド会計

〇:機能をサポート、およびデータ保持
△:最近のクラウド会計ではサポートしている場合が多い。

 

特に、受注の欄に注目して頂きたいのですが、受注が確定するとクラウド型販売管理では受注データを登録しますが、クラウド会計には何もデータを登録することはできません。
受注したけど、まだ、売り上がっていないためです。

「今月の売上はいくらになる?」の答えは、クラウド会計には無いのです。
経営者は今月売り上がる予定の受注金額を含めた売上額として認識したいのですが、
そのデータは、クラウド型販売管理にしか存在しないのです。しかも、すでに売上がった金額と今月末までの出荷予定(売上予定日)の受注金額を合計する必要があるのです。

売上の予実管理もクラウド会計では難しいのです。
月別の売上目標を設定したとします。これが予算になります。
予実管理の実績は、売り上がった金額になるのですが、先ほどのように、受注が確定して出荷日(売上予定日)が決まった金額も実績として集計される必要があります。これ以外にも、年間契約によって毎月売り上がる保守サービスなどを実績として積んでおきたいのです。

こうして見ると、クラウド会計は事後の世界であり、クラウド型販売管理は現在過去未来である言えます。

 

投稿者:systemkanri 投稿日時:

1-4 簡単なようで難しい「請求」業務

売り上がった金額を請求する。いたってシンプルな考え方なのですが、これが意外と難しいのです。

 

顧客マスタとして一元管理しない場合

顧客を一元管理しない場合には、顧客マスタを持たずに、請求先の住所や氏名は請求書データに保持します。この場合は、同じ人が複数回取引(売上)を行った場合には、同じ住所・氏名の請求書データが保存されていることになります。売上高は管理できますが、顧客分析ができなくなります。

 

顧客マスタで一元管理する場合

初回の取引で、新規に顧客マスタに登録します。相手が企業であれば与信を行うなど、顧客マスタの登録にはいくつかのステップが存在します。相手が個人であると、同姓同名の場合もあるので、識別できる情報を付加して顧客マスタに登録することになります。
顧客マスタに登録した後に、売上データを登録し、その後、請求書データを作成する流れになります。この場合には、売上データをシステムに登録する前に、顧客マスタに登録する必要がありますので、業務の流れに縛りが発生し、煩雑にもなります。よって、いきなり売上のケースでは、顧客マスタの設置は難しいのです。

以下は、顧客マスタで一元管理する場合になります。

 

締め請求

「月末締めで、翌月月初に請求書を発行し、月末に入金」といったケースです。

7月10日に売上が10万円、7月20日に売上が20万円発生したとします。7月の売上合計が30万円ですので、翌月の8月に30万円の請求書を発行し、8月末までに入金して頂くといった流れになります。
ここまでは単純なのですが、取引先毎に締め日が異なったらどうでしょうか。A社は月末締めで、B社は20日締め、といったことがあるのです。しかも、入金して頂く支払期日も、A社は締め日の翌月末、B社は締め日の翌々月末となると、会社ごとに、締め日と支払期日が異なるのです。極端なことを言うと、毎日どこかの取引先が締め日で処理をすることになります。しかし、通常は「ごとうび」(五十日)が基本で、毎月の5日、10日、15日、20日、25日を締め日としています。なお、30日を締め日とする指定はなく、「月末」として扱う場合が多いです。
支払期日も「当月」「翌月末」「翌々月末」など指定することになります。これを支払サイトを呼んでます。
クラウド型販売管理では、取引先マスタに設定された締め日や支払サイトを判定しながら、締め請求の処理を行うことになります。

 

前払いの請求書

手付金などがこれで、100万円の商品を販売する前に、手付金として20万円を請求する場合です。まだ商品を出荷していないので、20万円の売上が立っていない状態で請求するのです。単純に20万円の請求書を印刷すれば良い?と考えますが、売上情報をもとに請求書を作成するロジックになっているクラウド型販売管理やクラウド会計ではこれができないのです。特に最近はクラウド会計で請求書を発行できるようになっておりますが、前払いについては、仮の売上データを登録するなどの工夫が必要になるのです。
さらに、商品を出荷し売上が確定し、その後、請求書を発行する際には注意が必要です。というのは、すでに、20万円を頂いてますから80万円の請求になります。ところが、クラウド型販売管理のデータや会計上は、出荷日での売上が100万円になっておりますので、通常のロジックで請求データを作成すると、二重請求になってしまうのです。
請求書発行をシステム化するのは、かなり難しいことが、ご理解頂けますでしょうか。

そして、さらに難しさの話は続きます。

 

支社からの受注を本社に請求

全国に支社が存在する取引先企業の場合、支社から受注し、支社に出荷納品するケースがあります。取引先企業のご希望に応じて、支社への請求を本社にまとめて請求して欲しいというご要望を頂くこともあります。この場合、取引先マスタに親子関係を持たせる必要があります。本社を親、支社を子にして、子の売上を親に請求するという機能です。
売上をそのまま取引先に請求するのではなく、請求先が別途指定できるということです。

 

未払いを合算して請求

前回まで請求した金額で、未払いがある場合に、未払い金額を今回の請求に合算するケースです。これは、前回の請求タイミングから今回の請求タイミングの間に、支払(決済)が必ず存在する場合です。分かり易いのがクレジットカードや口座振替です。前回の請求金額が未払いになったことが確実に把握できることが前提になるのです。ですので、振込みでは合算請求は難しいものになります。取引先の担当者と事前に連絡して合意している場合は、合算請求できますが、運用が手間になりますし、混乱のもとになります。
未払いを合算するのは、かなり難しい業務になりますので、月毎に請求して、請求書の単位に未払いの対応(入金フォローなど)を行うのが良いでしょう。

 

投稿者:systemkanri 投稿日時:

1-5 単月売上と期間売上

聞きなれない言葉かと思います。分かり易いように、私たちが定義した言葉ですので、ご安心ください。でも、この2つをきちんと識別することが重要なのです。

単月売上は、今までお話ししましたように、商品の出荷日で売上を計上する場合です。これに対して、1年間の役務(サービス)を提供する場合は、提供期間中の各月で売上を計上する必要があります。これを私たちは期間売上と呼んでいます。例えば、年間12万円のクラウド利用サービスを提供するとします。期間中は、毎月1万円を売上計上する必要があるのです。クラウド型販売管理は、単月売上か期間売上かを識別する必要があるのです。

 

さらに、クラウド会計に毎月の売上を計上する必要があります。1年間の契約を受注した時点で、12ヶ月先までの各月の売上が見込まれるのですが、クラウド会計は「事後の世界」ですから、未来の売上を受注のタイミングで計上することは、お勧めしません。
この場合は、クラウド型販売管理で、毎月の締めの時点で、売上データをクラウド会計に登録するという流れになります。

 

特にIT企業さんは、システム初期開発は単月売上ですし、導入後のシステム保守は期間売上になりますので、受注件数が多いアプリ開発業者さんは、それなりに複雑な請求業務を行うことになります。(弊社もそうなんです。)

 

さらにさらに、請求のタイミングいつでしょうか?。

  • (A)年払いの前払い
  • (B)月単位の前払い
  • (C)月単位の後払い

の3つのケースがあります。(年払いの後払いは考えられません。)

さらにさらにさらに、先ほどの締め日請求や本社へのまとめ請求などが絡んできますので、本当に請求って悩ましいのです。
 

投稿者:systemkanri 投稿日時:

1-6 入金消込と営業担当

入金消込は、経理部門の仕事であると考えている人も多いと思います。銀行口座の情報を参照できるのは、経理部門に限定されていたりするので、そう考えても無理はないでしょう。

しかし、入金があったことを営業担当も知りたいのです。お得意様に直接お会いする機会が多いのは営業マンです。お会いしたときには、「ご入金ありがとうございます。」の一言は早めにお伝えしたいでしょう。入金消込は、クラウド会計で行われるのが通例です。最近のクラウド会計(freeeさんやMFさんなど)は、銀行口座明細をAPI経由で自動取込して、さらに、AIを使って消込のマッチングまで行ってくれます。
しかし、営業マンはクラウド会計を利用する権限が無かったりしますので、入金情報を知ることができません。多くの営業マンは、経理部門に都度問合せをするなど行っているようです。

これを解決するためには、クラウド会計側で入金消込を行った情報をクラウド型販売管理側に戻せば良いのです。システム間の連携になるので難しい部分もありますが、クラウド型販売管理の売上データに該当する入金情報をクラウド会計側からクラウド型販売管理側に反映または、クラウド型販売管理側から取得すれば良いのです。

 

ただし、業務上の観点からして難しい点もあります。それは、取引先から振り込まれた金額が、複数の請求の合算であったり、または、振込手数料が差引かれている場合です。売上金額と入金金額が完全一致しないのです。その場合は、クラウド会計側で、入金金額を複数の売上に割り振ったり、振込み手数料を「支払手数料」として計上するなど、一つ一つの売上データを消し込む作業が必要になります。
これが、かなり面倒なのですが、最近のクラウド会計(特にfreee)では、AIを駆使して自動マッチングを行ってくれます。これは、ほんとうに嬉しい機能です。(弊社でも利用しております。)
クラウド会計側で、個々の売上データに対する消込を行うことにより、クラウド型販売管理側で保持している売上データに消込情報を反映できるようになるのです。

 

このように、クラウド型販売管理とクラウド会計がクラウド間で連携することで、営業マンは「ご入金ありがとうございます。」を言えるようになり、顧客満足度の向上につながるのです。

 

会計freeeからkintone販売管理への入金消込機能はこちらをご覧ください。

 

投稿者:systemkanri 投稿日時:

1-7 クラウド型販売管理とクラウド会計間での取引先マスタ連携

取引先の情報が最初に登録するのはクラウド型販売管理であり、その後、クラウド会計に登録する流れになることは、一般的に想像がつくことかと思います。クラウド型販売管理では案件登録する前に、取引先(顧客)のマスタ登録を行います。与信などを行って、社内承認を得るなどのワークフローが存在する場合もあります。その後、受注し売上が確定したタイミングでクラウド会計に売上データを登録する場合、クラウド会計側で事前に取引先を登録しておく必要あります。売上データ、つまり仕訳データに取引先コードを指定する必要があります。クラウド型販売管理側から売上データをクラウド会計に連携する場合には、クラウド会計で管理されている取引先コードを指定してあげる必要があります。

ところが、取引先の登録タイミングはクラウド型販売管理が先ですから、クラウド会計で取引先を登録し、かつ取引先コードが付与され、これをクラウド型販売管理側のマスタに反映させる必要があります。


クラウド型販売管理 → (1)処理 → クラウド会計 → (2)処理 → クラウド型販売管理


の連携になります。(1)はクラウド会計への新規登録で、付与された取引先コードを(2)の処理でクラウド型販売管理の取引先マスタを更新する必要があります。システム的なことを言うと、クラウド型販売管理の取引先マスタの更新キーが必要になるのです。(処理が煩雑になるのです。)

そなると、クラウド型販売管理側で取引先を登録するのと同時に、クラウド会計側でも取引先を登録してしまえば良いのでは?と考えるかもしれません。しかし、クラウド会計は「事後の世界」ですから、受注しなかった取引先をクラウド会計にマスタ登録をしたくないのです。せめて、受注が確定した段階で、クラウド会計に取引先を登録するという考えになるのです。

クラウド会計(freee)では、取引先登録のAPIが提供されていますので、クラウド型販売管理側の自由なタイミングでAPI経由で取引先を登録することができます。もちろん1回のAPI処理で、取引先コード(ID)も取得できますので、その後の売上データ登録で利用することができます。

取引先マスタの連携も、実は奥が深いのです。

 

投稿者:systemkanri 投稿日時:

2 クラウド型販売管理(個別受注型)

クラウド型販売管理のうち個別受注型に関して記載しております。例えば、IT企業のアプリ開発会社であれば、顧客のご要望に応じてアプリの仕様がことなりますので、見積してから受注し、受注後も開発プロジェクトがスタートし、開発を行ったアプリを納品して、顧客にて検収して頂くことになります。見積、受注、納品、検収、売上の流れになります。また、納品までには外注会社からのデザイン画像を受け入れる場合もあります。よって、受注残や発注残をきちんと管理する必要があるのです。

一方で一般消費者を対象に商品を販売するECサイト(ストアサイトやショッピングサイトとも呼ばれてます)は、ほぼシステムで自動処理されるのが通常です。クラウド型販売管理としてはECサイトで購入決定の受注から始まることになります。そして、商品を発送することで売上が立ちます。もちろん、商品の在庫がある前提で受注しますので、受注に対する発注残という考え方はないのです。(仕入に対する発注残の管理はあります。)

 

投稿者:systemkanri 投稿日時:

2-1 受注残とは

受注残とは

2-1

受注残とは

未だ顧客へ納品(あるいは出荷)していない注文のこと

 受注残とは、顧客から注文を受けた商品サービスについて、未だ顧客へ納品(あるいは出荷)していない注文のことを言います。例えば、単価100円のA商品を数量10個で注文を受けたとします。このとき、受注残は、数量10個(1,000円)になります。その後、販売者側の都合により、7個を納品したとします。このときの受注残は、数量3個(300円)になります。そして、受注残の数量3個を納品すれば、受注残は0になり、1つの受注に対して納品を完了したことになります。つまり、受注残は注文主である顧客に対する納品までの進捗状況を管理することができるのです。

なお、納品日と検収日を分けて受注を管理することもあります。納品後に顧客側での検収作業あり、検収基準で売上計上する場合です。この場合、受注残は納品日で消えますが、検収残として管理する必要が出てくるのです。受注残を検収日まで含めるのか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があるのです。
※「検収」という言葉は仕入にも使いますので、受注検収という言葉を使うことをお勧め致します。
クラウド型販売管理の受注残は、顧客単位、受注単位に受注残を一覧で参照したり、受注残のある顧客リストや受注一覧を表示することができます。顧客からの問い合わせ対応に役立つことになります。

「販売9」
freee連携kintoneプラグイン
統合型ワークフロー

投稿者:systemkanri 投稿日時:

2-2 発注残とは

発注残とは、自社の商品サービス等の仕入先への発注について、未だ自社に納品されていない発注のことを言います。例えば、仕入単価70円のA商品を数量10個で発注したとします。このとき、発注残は、数量10個(700円)になります。その後、仕入先の都合により、7個が分納されたとします。このときの発注残は、数量3個(210円)になります。そして、発注残の数量3個が納品されれば、発注残は0になり、1つの発注に対して仕入が完了したことになります。
つまり、発注残は、仕入先からの納品の進捗状況を管理することができるのです。

なお、納品日と検収日を分けて発注を管理することもあります。納品後に自社での検収作業があり、検収基準で仕入計上する場合です。この場合、発注残は納品日で消えますが、検収残として管理する必要が出てくるのです。発注残を検収日まで含めるか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があります。

※「検収」という言葉は受注にも使いますので、仕入検収おちう言葉を使うことをお勧め致します。

なお、クラウド型販売管理としては、仕入先を社内部門として位置付けることにより内作の管理に利用することもあります。

クラウド型販売管理の発注残は、仕入先単位、発注単位に発注残を一覧で参照したり、発注残のある仕入先リストや発注一覧を表示することができます。仕入先からの問い合わせ対応に役立つことになります。

投稿者:systemkanri 投稿日時:

2-3 受注残と発注残の関係

個別受注型では、基本的に在庫をもたず、1つの受注について都度仕入を行ったり、内作により商品サービスを提供するケースです。複数の仕入先が関係する場合もあり、1つの受注についてリードタイムが異なる発注をそれぞれの仕入先に行うことになり、業務管理が煩雑になります。

1つの受注について、この受注から発生する複数の発注を関連付けて管理できることがクラウド型販売管理に求められます。
例えば、受注一覧において受注残が見れることは当然ですが、同時に発注残もこの受注一覧に表示されるというものです。もちろん、1つの受注の参照画面でも、発注残を確認できるということです。

これにより、発注残が0になった受注は、仕入が完了しているので顧客への納品が可能であることが分かります。仕入担当と営業担当が分かれている企業の場合には、このような受注残と発注残の一元管理がとても重要な役割になります。

個別受注型では、受注残と発注残を一元管理できることが求められるのです。

 

投稿者:systemkanri 投稿日時:

2-4 何を根拠に、請求している?

請求することは、企業にとってはとても慎重になる業務です。二重請求はもっての外であり、請求漏れも企業の信頼を損ないます。皆さまの会社では、どのようなルールで請求業務を行っておりますか?

個別受注型では、納品あるいは受注検収がされたものを請求するというのが基本ルールになります。
クラウド型販売管理では、受注残が0になったタイミングで請求が可能になるというロジックになります。請求可能になった状態から実際に請求書を発行した際には、その受注について請求済みにする必要があります。そうすることで、二重請求を防ぐことができます。

聞きなれない言葉かもしれませんが、請求残という考え方があります。
10個の受注を受けて、その後に納品まで行ったとします。受注残は0になりますが、同時に請求残を10個とするのです。そして、請求書を発行した際には、請求残を0にするという考え方です。受注残、発注残と同様にクラウド型販売管理では、請求残のロジックを実装することができるのです。受注一覧画面では、受注残、発注残と請求残を同時に参照することができますので、受注から請求完了までを一つの画面で確認することが可能となります。

請求残の考え方を業務に組み込むことで、請求漏れや二重請求を防ぐことができるのです。
自社の請求関連業務を今一度見直ししてみてはいかがでしょうか。

 

投稿者:systemkanri 投稿日時:

2-5 売掛を管理できている?

請求書を発行したあとは、入金を待つことになります。
売掛つまり売掛金とは、「信用取引にて商品サービスを提供した代金を受け取る権利(およびその金額)」を言います。
クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを提供した」は、納品あるいは受注検収がされた日に、販売代金を売掛金にプラスします。
「受け取り権利」が消滅するのは、支払があった日、銀行口座に入金があった日に、入金額を売掛金からマイナスします。

こうしてみると簡単なロジックなのですが、実際にはもう少し複雑なのです。
売掛金は、取引先毎に管理するのが基本です。クラウド会計などの売掛金リストは、取引先単位でかつ月別の集計表で表示されるのが一般的です。さらに、商品サービスを提供した単位(これを取引と言います)、請求書を発行した単位に、入金を管理できることが求められます。これを入金消込と呼んでます。

請求書は、複数の取引を請求明細としてまとめて1つの請求書として発行することがあります。取引は日付が異なる場合があります。例えば、前月1日から末日までの取引をまとめて1つの請求書として発行するケースです。
前月10日に1万円、前月20日に2万円の取引があったとすると、請求書の請求額は3万円になります。その後、3万円の入金があったとすると、前月10日と20日の取引にこの3万円を割り当てて消し込みを行うと同時に、発行した請求書についても消し込むことになります。そして、売掛金をマイナスします。

売掛金の消し込みは、システム観点からしても意外と複雑なロジックになりますが、顧客や取引先との信頼関係に直結することですので、とても慎重に行う必要があります。

今どきのクラウド会計では、AIを駆使して入金消込を自動で行ってくれる会計システムもあります。お勧めなのが、会計freeeです。会計とう領域であるものの販売管理に近い「取引」という考え方を取り入れ、かつ、請求書を作成かつ郵送してくれます。銀行口座ともネット接続し、AIを駆使して入金消込も自動で行ってくれるのです。会計freeeは一度、お試しする価値はあります。

弊社では、kintoneと会計freeeを連携させるプラグインをご提供しております。業務効率化のお役に立てれば何よりです。

 

投稿者:systemkanri 投稿日時:

2-6 買掛金から振込ファイル(全銀ファイル)を作成

買掛は、売掛と同様に考えれば良いのですが、大きな違いとしては、支払を行い買掛金を消し込むことです。一般的に支払は、実際の振込日の数日前に行います。買掛金の消し込みは、実際に支払った日に消滅します。つまり、支払操作を行った日と買掛金が消滅する日にタイムラグがあり、支払操作を行ったことを記録しておき、二重振込等の間違いを起こさないようにシステムでロジックを組む必要があるのです。

そもそも、買掛金とは、「掛け取引によって、商品サービスを購入した代金を支払う義務(およびその金額)」を言います。

クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを購入」は、仕入の商品サービスが納品された、または検収した日に、仕入金額を買掛金にプラスします。
「代金を支払う義務」が消滅するのは、支払った日に、仕入金額を買掛金からマイナスします。

単純なロジックではありますが、この買掛金のプラスとマイナスの間には、請求書を受け取る、請求金額を確認する、支払操作をするという業務があります。これらの業務が煩雑な作業になっているのです。

まず、請求書を受け取り、請求金を確認するという業務では、仕入をした代金をいつ支払うのか?が問題になります。例えば、仕入を行った月の翌々月末払いのケースです。この場合は、今月末日に支払うのは、前々月の仕入金額の合計になります。この金額には、前月の仕入は含みません。でも、買掛金としての今現在の残高は前月分も含まれますので、注意が必要です。
これを管理するために、支払期日が必要になるのです。商品サービスを仕入れ、または検収した日を基準に、翌々月末など仕入先毎に異なる支払サイトに従って、支払期日を算出するのです。こうしておくことで、今月に支払いするべき金額を支払期日をもとに合計することができるのです。
仕入先から受領した請求書が、クラウド型販売管理やクラウド会計で計算した支払するべき金額と一致することで、請求書の確認できるようになるのです。

そして、次は支払です。クラウド会計を利用すると、支払期日で合計した金額をもとに、銀行振込ファイル(総合振込ファイル)を作成してくれます。これをオンラインバンキングで振込ファイルをアップロードすることで支払操作が完了します。しかし、注意が必要です。
オンラインバンキングで振込ファイルをアップロードした後、実際に振込みされるのは、数日後です。では、買掛金はいつ消し込むべきでしょうか?という疑問がでてきます。

  • (1)クラウド会計で振込ファイルを出力したタイミング
  • (2)実際に振込が完了した後の銀行明細をクラウド会計に取込んだタイミング

(1)では、未来の振込予定日に支払したことにして、買掛金を消し込むことになります。もし、振込が失敗したらどうなるのか?と懸念されます。(実際は手補正になります。)
(2)は、振込した事実に基づき買掛金を消し込みますので、振込み失敗の場合も対応が可能なのですが、(2)のタイミングまで買掛金が残っているので、振込ファイルを誤って二重作成してしまうことが懸念されます。この場合は、特に承認申請フローなどの業務ルールをきちんと作成しておく必要があります。

(1)と(2)は、利便性や業務フローの構築など、一長一短があります。どちらのケースでシステム化を行うかは、自社の業務レベルに合わせて検討されることをお勧め致します。

なお、クラウド会計の会計freeeでは、(1)と(2)のどちらでも対応が可能です。

 

投稿者:systemkanri 投稿日時:

【目次】クラウド販売管理とクラウド会計

<目次>

※今後掲載予定の章を含めて目次としております。リンクがある章が公開中になります。

 

はじめに

1.クラウド販売管理とクラウド会計

1-1 見積から入金の流れ

1-2 もう一つの流れ「いきなり売上」

1-3 クラウド会計の範囲と限界

1-4 簡単なようで難しい「請求」業務

1-5 単月売上と期間売上

1-6 入金消込と営業担当

1-7 クラウド販売管理とクラウド会計間での取引先マスタ連携

 

2.クラウド型販売管理(個別受注型)

2-1 受注残とは

2-2 発注残とは

2-3 受注残と発注残の関係

2-4 何を根拠に、請求している?

2-5 売掛を管理できている?

2-6 買掛金から振込みファイル(全銀ファイル)を作成

 

3.なぜエクセルを使うのか、なぜエクセルはダメなのか

3-1 なぜ、エクセルを使うのか

3-2 なぜ、エクセルはダメなのか

 

4.しっかりとした企業は、ワークフロー(申請承認)を導入している。

4-1 まずは、取引先の与信

4-2 受注、仕入の承認

4-3 経費の申請(事前)と清算(事後)

 

5.まだ丸投げですか?、記帳は難しくない ~ 今どきのクラウド会計freee

5-1 単式ライクな取引入力、自動仕分け

5-2 請求書も作れる、郵送までしてくれる

5-3 銀行口座と連携できる

5-4 仕訳もAIで推測

5-5 クラウドだから、税理士さんと共有できる

 

6.売上、仕入の計上

6-1 1年間の保守サービス料を開始前に請求している

6-2 建設業は必須の「未成工事支出金」

 

7.在庫の話し

 

8.IT導入は何から始める?失敗しないシステム導入とは

8-1 だれでも言う「使ってみないと、わからない。」&「自社に合ったシステムが欲しい。」これって、矛盾してない?

8-2 出来合いのアプリをまずは、無料で使ってみる

8-3 サイボウズ kintoneは何が良いのか

8-4 無料で使える「販売9」

8-5 例えば、こんなのはカスタマイズになる

 

9.まだまだある、ITで業務効率アップ。

9-1 勤怠管理とプロジェクト原価

9-2 契約締結もクラウドで出来る。しかも、印紙不要!

9-3 みんなEDIでらくらく(中小企業共通EDI、全銀EDI【ZEDI】)

 

10.オールクラウドで作る業務システム

10-1 いろんなクラウドサービスのご紹介

10-2 どうやってつなげる?APIがあるさ!

10-3 自社の業務データを整理して、クラウドを当てはめてみる。

 

投稿者:systemkanri 投稿日時:

kintoneで見積書PDF作成からメール送信まで【No.010】

【kintoneで見積書PDF作成からメール送信まで】 kintone JavaScript kintone REST API

エクセルの見積書作成から解放されました!

kintone画面上で完結する見積書作成業務がここにあります。kintone見積書PDF作成からメールURL発行

なんと、たったの3ステップ。

 

1.kintone画面で、取引先を選ぶ
2.kintone画面で、見積明細入れて、PDF作成のボタンを押す
3.kintone画面で、ダウンロードURL発行のボタンを押す

 

あとは、URLを電子メールに貼り付けて、送信するだけ。

 

もちろん、数量、単価から合計金額や消費税も自動計算されます。

商品マスタから単価をもってくれば簡単です。

メール先のお客様が、URLから見積書PDFがダウンロードされるとkintoneでプッシュ通知されます。

納品書や請求書もOKです。

すべて、kintone画面上で完結してますので、iPadでも見積書PDFの送付ができます。

見積書の作成が楽しくなりますよ。
じゃんじゃん、見積しちゃいましょう!

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneで在庫管理ができるようになった【No.009】

【kintoneで在庫管理ができるようになった】 kintone JavaScript kintone REST API

 

2014年4月のkintoneバージョンアップで、Webサイトで展開するネットショップと連携した在庫引当ができるようになりました。

ネットショップ(ECサイト)からkintoneの在庫情報と連携し、在庫引当が可能になるのです。

今までは、API経由でネットショップの在庫引当を実現すると・・・

  • AさんとBさんが同じ「黒ボールペン」をネットで購入しようとしています。
  • Aさんは1本を注文。Bさんは3本を注文。在庫は10本だとします。
  • Webサイトのプログラムでは、kintone在庫アプリデータの黒ボールペンの在庫数を取得し、在庫数から注文数を引いて、黒ボールペンの在庫数フィールドを上書きします。
  • AさんとBさんが同時に注文ボタンを押したとします。
  • Aさんのプログラムは在庫数を9本で上書きし、Bさんのプログラムは在庫数を7本で上書きします。
  • この場合、kintone在庫アプリへのデータ更新は後勝ちになりますので、在庫数が9本または7本のどちらかになります。これは、データレコードへの排他制御を行っていないためです。

正しくは、在庫数は6本ですね。

kintoneで在庫管理

 

今回のアップデートでは、APIを使ったkintoneアプリのデータレコードへの排他制御を実現するために、リビジョン管理機能がサポートされました。
さらに、2フェーズコミットを実現する「複数アプリへのレコード一括で処理する機能」もサポートされ、本格的なトランザクション処理が可能となりました。
例えば、在庫アプリの更新と同時に、受注アプリにレコード追加する処理の整合性を保証できることになります。

これはもう、ORACLEやSQL-Serverと同等なトランザクション処理系のシステム構築が可能となったと言えます。

ネット通販、在庫管理、チケット販売、ホテル予約などトランザクション系システムをフレンドリーなビジネスファストアプリkintone基盤を利用して構築することが可能になります。

 

kintone在庫管理とクラウド会計freeeのコラム

kintone在庫管理とクラウド会計freeeのコラムはこちらです。

 

kintone在庫管理アプリテンプレート発売予定

在庫管理の簡易機能を2アプリで実現したテンプレートです。

主な機能:

  1. 在庫引当て
  2. 出荷予定リスト
  3. 引当て済みからの出荷
  4. 初期在庫設定
  5. 入荷(仕入) ※予定仕入れは未対応
  6. 引当て可能在庫数と現在庫数
  7. 月末在庫と評価額 ※移動平均法

在庫管理kintoneアプリテンプレートに関するお問合せはこちらです。

 

バーコードでPi! バーコードでPi!(kintoneアプリストア掲載中)

バーコードスキャナのボタン一発で、読み取りデータをアプリに登録できます。在庫管理や生産管理の業務分野で利用可能です。また、固体番号でのトレーサビリティの実現が可能です。POSレジへ応用もできます。

詳しくは、こちらです。

 

kintoneバーコードでPi!

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneアプリとWeb問合せフォームを連携したい【No.008】

【kintoneアプリとWeb問合せフォームを連携したい】 kintone JavaScript kintone REST API

 

自社ホームページのWeb問合せフォームでお客様が入力された情報を、サイボウズ社kintoneアプリに自動連携したいというニーズがあります。

 

ニーズ・課題

  1. 自社Webページの問合せフォームで入力された顧客情報をkintoneアプリに自動登録したい。
  2. 問合せフォームに入力された情報を複数の担当メンバーで共有したい。
  3. 問合せフォームに入力された会社名や連絡先を見込み顧客リストに簡単にコピーしたい。
  4. イベントやセミナーの開催毎にkintoneアプリを作成するように、参加登録Webフォームを作りたい。
  5. 他社サービスのWebフォームサービスを使っているので、自社ドメインが使えない。
  6. WebフォームのページがSSLなのに、入力された顧客情報がメールの平文で飛んで来る。

解決策のご提案

kintoneのAPIを使って、kintoneアプリに連動するWeb問合せフォームページを作りましょう。

 

【ここがポイント!】

Web問合せフォームのみならず、イベントなどのセミナー参加登録のエントリーフォームにも活用したいですよね。

kintoneアプリに設定した項目が、そのままWeb入力フォームの項目としてページを自動生成できます。

 

問合せのみならず、セミナーベントの開催毎に、申込みエントリーページを作成できるようになります。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

【kintone使い方ヒント】通知設定したけど、メールが飛ばない!

こんにちは。ITFitのtkkrです。
今回はkintoneアプリの通知設定したけど、メールが飛ばない!という話題です。
先日、或るお客様と、「kintoneでメール通知する機能を使いたいのだけど使えていない。」と言う話になりました。
アプリ側での設定はしているようだったのですが、、、
ということで、設定のお話です。

メールで通知させるために、設定すべきところは4ヶ所あります。
(1) システムの設定
右上の歯車マーク→「kintoneシステム管理」→「その他」「利用する機能の選択」
ブログ_通知説明_システム・その他の設定01

(2) 個人のプロフィールのメールアドレス(E-mailの項)
右上の歯車マーク→「アカウント設定」→「プロフィールの変更」

(3) 個人の設定
右上の歯車マーク→「kintoneの操作と設定」→「個人設定」

ブログ_通知説明_個人の設定01

(4) アプリの設定
アプリの中の歯車マーク(その他の操作)→「このアプリの管理」→「通知の設定」

ブログ_通知説明_アプリの設定01
他には、「レコードの条件通知」もありますので、適宜、使い分けてください。

上記を設定すると、メールでの通知が飛びます。
多分、(1)と(2)と(4)の設定はなされていると思いますが、(3)の設定が抜けていることが多いのではないでしょうか?

皆様の業務にお役立ち致しましたでしょうか?

では、また。
 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

【kintone使い方ヒント】保存前に重複チェックをしたい!

こんにちは。ITFitのtkkrです。
今回は保存前に重複チェックをしたい!という話題です。
kintoneの設定画面で「値の重複を禁止する」を選択しているフィールドの重複チェックは通常、
保存アイコンをクリックした時に実施されます。
ところが、kintoneの画面で必須入力のフィールドなど保存する前に入力しなければならない項目を苦労して入れたのに、
保存の時にエラーが出ると悔しいですよね。
(折角入れたのにぃーって。)
そこで、JavaScriptにより、「保存前に重複チェックを行う」カスタマイズを行いました。
以下が実現イメージです。

 

ブログネタ20140302

 

実現方法として、JavaScriptによるカスタマイズで以下のような実装をしました。
・’app.record.create.show’や’app.record.edit.show’などの時に、
・チェックを行うボタンを配置、
・クリック時に自分自身のアプリに対し、REST APIを用いて検索、
・重複するレコードが存在するかを判断し、
・存在すれば「重複あり」、存在しなければ「重複なし」を表示する。
(ただし、更新時には更新しているレコードそのものの扱いをお忘れなく。)
以上のような流れで「保存前に重複チェックを行う」を実現しました。

 

皆様の業務に使えますでしょうか?

 

では。また。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

【kintone使い方ヒント】複合キーを設定したい!

こんにちは。ITFitのtkkrです。
今回は複合キーを設定したい!という話題です。
kintoneの設定画面では、単一項目の主キーの設定を行えますが、複数項目での主キーの設定は行えません。
そこで、JavaScriptによるカスタマイズを行いました。

 

以下が実現イメージです。
会社コード、契約番号、契約書Versionで主キーです。

ブログネタ複合キーin

既存のレコードで「再利用」アイコンをクリックして、そのまま「保存」アイコンをクリックすると、以下のエラーメッセージを表示するようにしました。

ブログネタ複合キーerr

実現方法として、JavaScriptによるカスタマイズで以下のような実装をしました。
・’app.record.create.submit’や’app.record.edit.submit’などの時に、
・自分自身のアプリに対し、REST APIを用いて検索し、
・同一キーのレコードが存在するかを判断し、
・存在すればエラー、存在しなければ保存する
(ただし、更新時には更新しているレコードそのものの扱いをお忘れなく。)
以上のような流れで複合キーによる制約を実現しました。

 

皆様の業務に使えますでしょうか?

 

では。また。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

【kintone使い方ヒント】ルックアップ項目に参照元で設定された値以外の値を登録したい!

こんにちは。ITFitのtkkrです。
今回はルックアップ項目に参照元で設定された値以外の値を登録したい!という話題です。
ルックアップ項目は非常に使いやすいアイテムです。が、参照元で設定された値以外の「適当な値」を入れようとしたら、値が入らない!という経験がありませんか?
kintoneのルックアップをそのまま使える訳ではないのですが、値を参照して入力したり、直接入力したりすることをJavaScriptによるカスタマイズで実現します。

 

以下の図がマスタ設定された値をプルダウンで設定するイメージです。

プルダウン

実現方法として、JavaScriptによるカスタマイズで以下のような実装をしました。
・’app.record.create.show’や’app.record.edit.show’の時に、
・REST APIでマスタアプリを検索し、
・該当する値をプルダウン(select/option)に設定・追加し、
・プルダウンで選択された値を該当項目に設定する
以上のような流れでルックアップの替わりになるプルダウンを実現しました。

 

皆様の業務に使えますでしょうか?

 

では。また。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneアプリの課題管理表を共有したい【No.007】

【kintoneアプリの課題管理表を社外と共有したい】 kintone JavaScript kintone REST API

 

kintoneアプリの課題管理表を社外の関係者と共有したいというニーズがあります。

 

ニーズ

  1. 最新の課題管理表をWebサイトを通じて、関係者と共有したい。
  2. メールで課題管理表ファイルを送信する手間を省きたい。
  3. kintoneへのログインユーザIDを持っていない人にも、参照させたい。
  4. 課題管理表は、WebサイトのURLを知っているだけに公開したい。もちろん、セキュリティの確保は必要。

解決策のご提案

kintoneのREST APIを使ってWebサイトと連携して、課題管理表の共有サイトを作りましょう。

kintoneの課題管理表アプリに保存されているレコードを、API経由でWebサイトに連携し、課題管理表をサイトに掲載する仕掛けです。ただし、このWebサイトを参照できる人を限定する必要があります。

 

【ここがポイント!】

Webサイトへのログイン/パスワードを管理する方法では、管理が煩雑になります。そこで、URLにハッシュコードを使ったアクセス制限を施すことで、参照できる人を限定することができます。

 

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneに保存したファイルをそのままメール送信したい【No.005】

【保存ファイルをそのままメール送信したい】 kintone JavaScript kintone REST API

 

ファイル管理アプリに保存したファイルを社外のお客様や取引先に送付したい場合、そのファイルをローカルフォルダにダウンロード保存して、メール添付する必要があります。複数ファイルの場合、ファイル毎にダウンロードして保存する手間があります。ローカルフォルダに保存されたファイルを消し忘れたりする危険性もあります。

kintoneアプリ内に保存添付されているファイルを、安全にかつ、セキュアな方法で、送信したいというニーズがあります。

 

kintone API で解決しよう No.005

ニーズ

  1. アプリに保存添付したファイルをそのまま、社外に送信したい。
  2. 特定の人しか見れないようにしたい。
  3. ログインIDやパスワードの払い出しが面倒だ。

 

解決策のご提案

kintoneのAPI、JavaScriptを使った、弊社ソリューション「悠々ファイル uuFILE for kinotne」をお勧めします。

 

uuFILE for kintoneサイボウズ社 kintone アプリストアに掲載中!

 

【ここがポイント!】

ファイルをダウンロードするためのセキュアURLを、レコード単位に自動生成します。そのセキュアURLのテキストをメール本文に貼り付けて送信することができます。

しかも、メール添付の最大サイズを気にする必要もありません。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneで専用ログインで情報公開したい【No.004】

【専用ログインで情報公開したい】 kintone REST API

 

ゲストスペースを作成することにより、メールアドレスでの認証と共有スペースが可能ですが、そのゲストスペースに参加している人みんなが、誰が参加しているか横並びで見えてしまう。

ユーザIDとパスワードを払い出して、その人だけに、特定のレコード情報を公開したいというニーズがあります。

 

ニーズ

  1. ログインにより、専用ページを作りたい。
  2. その人だけに、写真やコメント情報を見せたい。
  3. ログイン情報の1レコードを作成するだけで、設定を完了させたい。
  4. ログインに期限を設けたい。

 

解決策のご提案

kintoneのAPIを使った、弊社ソリューション「ステップサイト」をお勧めします。

 

【ここがポイント!】

ゲストスペースによる管理は不要。アカウントIDとパスワードをアプリのレコードとして作成するだけで実現可能です。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneで投票アンケートをしたい【No.003】

【投票アンケートをしたい】 kintone REST API

 

例えば、「りんご」「みかん」「ぶどう」のどれが一番好き?という情報を、ユーザあるいは、ゲストスペース参加者の意見を集めたい。誰が、どこに1票を入れたかも一覧で見れると良い。飲み会の日程調整に使いたいというニーズもある。

 

ニーズ

  1. 投票者1人が1レコードになる
  2. 何回でも更新できる。
  3. 締切期限を設定できる。

 

解決策のご提案

kintoneのAPIを使って、投票結果をアプリの取り込む機能を作りましよう。

投票アンケート項目をAPIで取得して、Webページでアンケートを作成します。回答結果をAPIを通じて、アプリに取り込みます。

 

【ここがポイント!】

投票者を認証する必要があります。【専用ログインで情報公開したい】を参考にしてください。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneで1写真1レコードの一括アップロードしたい【No.002】

【1写真1レコードで、一括アップロードしたい】 kintone JavaScript kintone REST API

 

1レコードに複数ファイルを一括添付することは出来ます。でも、1写真ファイルを1レコードで一括アップロードすることはできません。ひとつのファイル毎に、コメントを付けて保存したいとうニーズがあります。

 

ニーズ

  1. 写真ファイルやPDFファイルを一括アップロードしたい。
  2. アプリのレコードにそれぞれ、1ファイルで一括登録したい。

 

解決策のご提案

kintoneのAPIを使って、一括アップロード機能を作りましよう。

一括アップロード機能により、API経由で、ファイル毎に、アプリにレコードを新規作成しファイル添付します。

 

【ここがポイント!】

ファイルを1レコードに登録することは、難しくありません。しかし、自動生成するレコードの自動採番について、事前に検討する必要があります。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

kintoneでアプリとアプリのレコードを一度に見たい【No.001】

【アプリとアプリのレコードを一度に見たい】 kintone JavaScript kintone REST API

 

例えば、ワークスペースA(部門A)にインストールしたFAQアプリ(問い合わせ管理)と、ワークスペースB(部門B)にインストールしたFAQアプリにそれぞれ登録されたレコードを、全部門として一度に見たいというニーズがあります。

 

ニーズ

  1. アプリAとアプリBに登録されたレコードを、アプリC自動登録する。
  2. しかも、アプリAのレコードが更新されたら、アプリCでも更新されている。

 

解決策のご提案

kintoneのAPIを使って、クラウド上にバッチ処理を作りましょう。

アプリAとアプリBのレコードをアプリCに、自動連携します。

 

【ここがポイント!】

一番難しいのが、アプリAとアプリBのレコードに連番が付与されている場合、重複することになります。これを回避することが必要です。

 

kintoneアプリ作成・開発支援のお申込みフォーム
kintoneアプリ作成支援
投稿者:systemkanri 投稿日時:

02pオールクラウド®化への取り組み状況

スライド2

ページ2/17

クラウドを導入する理由(ワケ)

 

企業の活動には、様々なリスクが潜在します。情報流出リスク、災害リスク、システムリスクなどがあります。これらは、企業活動の継続に直接関係するリスクです。また、その企業のお客様に重大な影響を与えかねません。

 

クラウドを導入する前は、企業オフィス内に設定されたサーバやデスク上のパソコンに業務データが保存されております。このパソコン上でアプリケーションソフトを起動し、顧客情報を登録したり、見積もりや請求書を作成したりします。

顧客情報を含む、重要なデータがオフィスのパソコンに存在していることになります。

 

もしも、そのパソコンが盗難されたら?

もしも、地震でパソコンが破損したら?

もしも、パソコンが故障したら?

 

その時から、企業活動を継続することはできないのです。それは、それは、とても恐ろしいことです。企業活動が継続できなくなるだけではありません。

 

顧客情報流出となると、それはもう事件です。

投稿者:systemkanri 投稿日時:

03pオールクラウド®化への取り組み状況

スライド3

ページ3/17

 

 

企業活動を行う上で、お客様に影響あるリスクには、どのようなものがあるのでしょうか。大きくは、3つのリスクです。

 

情報流出リスクでは、パソコンの盗難や顧客情報の漏えい、また、情報の改ざん等が挙げられます。

災害リスクでは、地震や津波、そして天候不順による水害等の自然災害が挙げられます。

システムリスクでは、設備や施設の故障、サーバやパソコンなどの情報システムの故障、また、ウィルス侵入が挙げられます。

 

企業は、その活動を行う上で、このようなリスクにさらされているのです。

 

それでは、リスクを軽減するためには、どうしたら良いのでしょうか?

その答えが、クラウドサービスにあります。

 

投稿者:systemkanri 投稿日時:

04pオールクラウド®化への取り組み状況

スライド4

ページ4/17

クラウドサービスを導入すると、どうなるのでしょうか?

 

今まで、企業オフィスのパソコンに保存していた顧客リストや営業報告書、そして電子メールなどのデータは、データセンターに保存されることになります。

 

企業オフィスからは、インターネットを通じて、そのデータセンターにアクセスします。Webブラウザを起動し、ログイン画面でユーザIDとパスワードを入力することにより、利用者を認証します。その後は、Webブラウザにて、顧客リストの参照や登録ができるようになります。

 

データセンターでは、利用者からのアクセスに応えるために、広帯域の通信回線を敷設しています。また、データセンター内にあるコンピュータからの発熱に対応するため、空調設備が強化されています。電力供給の複数系統化や、建物の耐震構造も強化されています。コンピュータハードウェアも二重化され、コンピュータ故障時の対応もされています。

 

アプリケーションについても保守サポートされて、最新の状態でアプリケーションが利用できます。たとえば、給与計算アプリケーションの年末調整では、最新の法令規定がそのアプリケーションに組み込まれることになります。

 

企業では、情報システムの保守に関わる必要がなくなります。パソコンのハードディスク故障やアプリケーションプログラムの更新など、気にする必要が無くなりますので、本来の業務に社員を集中させることができるのです。

 

先にご紹介した3つのリスクを軽減するために、クラウドサービスの導入が有効であることがわかりました。

 

主観となりますが有名なクラウドサービスのロゴマークを図の下に載せております。

※2014年1月より、サイボウズ社kinotneでの構築をお勧めしております。

 

クラウドサービスは、様々なサービスがIT企業から提供されております。3つのリスクを軽減するために、クラウドサービスに求められる機能はなんでしょうか。

投稿者:systemkanri 投稿日時:

06pオールクラウド®化への取り組み状況

スライド6

ページ6/17

次に、当社におけるオールクラウド化へのステップを具体的に示していきます。

 

すべての企業で、このステップが適用できるかどうかは分かりませんが、参考にしていただければ幸いです。

 

Step1では、企業の業務を俯瞰し、業務機能を整理します。クラウドサービスを導入する場合、容易に導入できる業務機能とそうでない業務機能があります。まずは、それを確認します。

 

Step2では、容易にクラウドを導入できない業務機能について、業務イベントと情報を図式化します。図式化する理由は、業務に携わるスタッフの方々と認識を合わせるためです。この結果を利用して、クラウドサービスの選定が行えます。

 

Step3では、クラウドサービスの選定を行います。月額利用料金やセキュリティ面での評価を行います。

 

Step4では、クラウドサービスの利用するための業務手順書を整備します。どのような手順書が必要なのかを明確にします。

 

Step5では、クラウドサービスの本格運用に向けて、現行業務からの移行方法を確認します。既存顧客の情報をデータ移行する必要があります。

投稿者:systemkanri 投稿日時:

07pオールクラウド®化への取り組み状況

スライド7

ページ7/17

Step1の業務機能のコンポーネント化のイメージです。

当社では、コア機能、オフィス機能、通信手段、設備の4つの領域に分割しています。

 

コア機能は、もっともクラウド化が難しい領域です。それは、個々の企業がそれぞれ特徴ある活動をするためであり、業務手順が異なるからです。この領域については、Step2の業務イベントと情報の図式化を行います。

 

オフィス機能は、さまざまなクラウドサービスがIT企業から提供されている領域です。勤怠管理、スケジュール管理、人事給与、会計税務で、それぞれで異なるクラウドサービスを選択するケースもあるでしょう。

 

通信手段は、いまや情報インフラとまで言われている領域です。この領域では、公共性が高いので、最も利用されているクラウドサービスを選択するのが良いでしょう。

 

設備は、事務所の賃貸も含めております。“クラウド”からは外れますが、“所有から利用へ“という意味で、この領域に含めています。どうように、カタログや大量印刷ではネット注文印刷を利用しますので、これを指しています。単なるネット注文サービスかもしれませんが、当社では高価なカラーレーザープリンタは持てないので、ここに挙げています。

投稿者:systemkanri 投稿日時:

08pオールクラウド®化への取り組み状況

スライド8

ページ8/17

Step2の業務イベントと情報の図式化のイメージです。

コア機能の広告宣伝、仕入管理、販売管理、そして、請求入金管理までを図式化しています。

 

図式化に先だって、このコア機能に導入するクラウドサービスをSalesforceを前提にとしております。水色大きな枠がSalesforceの範囲を示しております。Saleforceのクラウドサービスでは、エディションがあります。月額料金により利用できるSalesforceの機能が異なるのです。

 

当社では、Contact Managerという低料金のエディションで実現できる範囲で構築することを目標としました。この魅力ある低料金で、当社の業務をどこまでカバーできるのか、オールクラウド化においてチャレンジするためです。

 

四角の箱は、情報のまとまりを示しています。これは、Salesforceでは、オブジェクトと呼ばれているもので、データベースでは「テーブル」と呼ばれているものに該当します。少し明るい水色の「取引先」と「取引先責任者」は、Saleforceで標準で作成されているものです。項目の追加はできますが、これ自体を削除することはできません。それ以外の情報は、当社コア業務に合わせて、作成するものです。

 

(1)から(8)は、業務イベントを示しております。数字は業務イベントの発生順序を示しています。業務イベントが発生すると、情報を作成したり、更新したりします。

“C”は、情報の新規作成を示しており、”U”は情報を更新することを示しています。

 

FAX受信や見積請求書、発注書は、物理的なデータファイルで管理します。今回は、エディションの関係で、Saleforceには保存しないことにしております。

これらのファイルは、Googleドキュメントで保存します。Saleforceの機能で、「見せ番コール見積設置」情報とFAX受信PDFを関連付けすることができます。

当社では、この関連付けを活用することにしております。

 

SaleforceのContracr Manager エディションでは、いくつかの制約がありますので、情報の図式化には、ちょっとしたノウハウが必要になります。

 ※弊社では2014年1月より、サイボウズ社kinotneでの構築をお勧めしております。

 

次に、情報のまとまりの内容、つまり、情報項目を決める必要があります。

投稿者:systemkanri 投稿日時:

09pオールクラウド®化への取り組み状況

スライド9

ページ9/17

当社の業務で、実際に利用している主要な情報項目です。

 

情報項目を決めるためには、業務イベントの流れをシミュレーションしてみると良いでしょう。

 

特に注意を払って頂きたいのは、「自動採番」の項目です。

 

当社では、取引番号、注文番号、アダプタのシリアル番号の3つの項目を自動採番することにしました。これらの自動採番項目は、見積書や注文書、アダプタに添付するシールに記載しますので、重要な項目となります。

 

情報の図式化において、慎重に検討したいものです。

 

また、情報の「ステータス」項目についても、うまく設定することが重要です。

取引ステータスでは、当社のお客様とのやり取りを記録するために設定を工夫しております。

 

ここまで、情報とその項目が整理できれば、あとは、Salesforceに設定するだけです。

投稿者:systemkanri 投稿日時:

10pオールクラウド®化への取り組み状況

スライド10

ページ10/17

Step3のサービス選定です。

当社が実際に導入し活用しているクラウドサービスです。(本当です!)

 

当社ではスモールスタートを目指しておりますので、とにかく価格重視のラインナップとなっております。 5ユーザで利用した場合の、1ユーザあたりの月額利用料は、記載の通りです。

 

クラウドサービスのメジャー所で、簡単に利用でき、導入実績が多いサービスを選定しています。

 

さらに、具体的に、当社の業務コンポーネントについて、クラウド化の状況を見ていきましょう。

投稿者:systemkanri 投稿日時:

11pオールクラウド®化への取り組み状況

スライド11

ページ11/17

当社のクラウドサービスの利用状況です。

 

コア機能、オフィス機能、通信手段、設備の4つの領域について、クラウドサービスを導入しております。それぞれのコンポーネントごとに、利用しているクラウドサービスを明示しておりますので、企業様にて導入される際に、参考になさってください。

 

こうして、業務コンポーネントを俯瞰すると、当社の人事給与、会計税務は、まだまだクラウド化が進んでいません。使い慣れている弥生様のシリーズが、クラウド対応される日を心よりお待ち申し上げております。(2011年12月現在)

※弊社では2014年1月より、サイボウズ社kinotneでの構築をお勧めしております。

 

共有フォルダについても、クラウドサービスはいくつも発表されているものの、

当社がビジネスで利用するには、まだまだ、満足しておりません。Yahoo!ボックスのような使い易さをGoogleドキュメントに求めたいですね。現状は、どのサービスも一長一短です。文書単位にアクセス権限を付与でき、セキュリティ面でも安心なので、Googleドキュメントを現状は採用しております。

投稿者:systemkanri 投稿日時:

12pオールクラウド®化への取り組み状況

スライド12

ページ12/17

ここからは、具体的な活用例をお伝えいたします。

 

今回お伝えするのは、Googleドキュメントのフォーム機能を活用したものです。

 

一つ目は、出退勤時間の記録とオフィス退出時の最終チェックを記録するものです。出勤時間、退勤時間を記録することができます。また、事務所の最終退出時に電源オフやカギ締めの実施記録を残すことができます。社員の手持ちのスマホから入力することでき、自動的にGoogleドキュメントに保存されます。また、タイムスタンプも自動記録されます。一般的なタイムカードよりも、高機能を実現できて、しかも、スマホでいつでもどこでも使い勝手抜群です。

 

二つ目は、ちょっと凝ったWebお問合せフォームを実現するものです。当社のホームページは、みんビズを利用しております。みんビズでは、簡単にお問合せフォームを実現することができるのですが、入力フォームの項目を自由に作成することができないのです。みんビズは「かんたん」を売りにしているので、自由度を上げると操作が難しくなるということで、致し方ないでしょう。

 

とは言え、入力フォームの項目を自由に設定したい、また、選択内容によって、次ページで入力項目を変えたい、などの要望は出てきます。当社でも、「お問合せ」と「見積依頼」では、入力してほしい項目は異なります。選択肢によって、入力ページを変えることが必要なのです。

 

これらは、Googleドキュメントのフォームを利用することで解決できます。

投稿者:systemkanri 投稿日時:

13pオールクラウド®化への取り組み状況

スライド13

ページ13/17

 

 

勤怠・オフィス退出チェック記録の利用イメージです。

 

Googleドキュメントのフォーム作成機能を活用しています。

 

社員さんがフォームを入力して送信すると、Googleドキュメントのスプレッドシートに、1行のデータが追加されます。タイムスタンプとユーザ名は、フォーム入力しなくてもGoogleが自動的に記録します。その他の項目を自由に設定することができます。

 

出勤時刻と退勤時刻を記録することで、勤務時間を自動計算することも可能となります。この情報を給与計算に反映することも可能でしょう。

 

投稿者:systemkanri 投稿日時:

14pオールクラウド®化への取り組み状況

スライド14

ページ14/17

当社が本当に使用している入力フォームです。

 

「出勤・退勤」は、次の3つから選択します。”出勤”、”退勤”、”退勤&オフィス最終退出確認”です。3つ目の”退勤&オフィス最終退出確認”を選択した場合は、オフィスの最終退出となった社員が、下記のチェックリストにも記録します。

※連動して、「オフィス最終退出チェックリスト」が必須入力にならないのが残念。

 

「出勤時刻」と「退勤時刻」は、リスト選択で時刻を指定します。先にご紹介したタイムスタンプで、出退勤時刻を判定しても良いのですが、フォームの送信忘れ等に対応するために、この項目を設けています。

 

「オフィス最終退出チェックリスト」は、実施後のチェックリストとして利用します。ドア施錠がありますので、オフィス退出後に、チェックリストに記録を残せるのがポイントです。

 

最後に、送信ボタンを押せば、入力した結果をGoogleドキュメントに記録することができます。入力結果のコピーが欲しい場合には、一番下のチェックボックスにチェックを入れると、自分のメールアカウントにコピーが送信されます。

 

スマホの活用により、Googleドキュメントだけで、ここまで出来るのは素晴らしいです。

 

Googleさん、ありがとう!

投稿者:systemkanri 投稿日時:

15pオールクラウド®化への取り組み状況

スライド15

ページ15/17

次は、ちょっと凝ったWebお問合せフォームです。

 

当社のホームページは、みんなのビジネスオンラインを利用して公開しております。見た目では、みんビズを利用しているとは、お気付きにならないでしょう。みんビズでは、他社様のホームページに見劣りしないビジネスで利用できるホームページを簡単に作成することができます。ほんとに便利です。ブログ掲載する感覚で、ホームページを更新できるのが気に入ってます。

 

さて、簡単便利なみんビズですが、お問合せフォームには、限界があるのです。

 

当社では、これを克服するために、Googleドキュメントのフォームを利用しております。

投稿者:systemkanri 投稿日時:

16pオールクラウド®化への取り組み状況

スライド16

ページ16/17

こんなWebお問合せページが欲しくなりませんか?

 

1ページ目で、お客様のお名前や連絡先メールアドレスなどを入力してもらいます。(図ではスペースの関係で割愛しています。)

そして、「お問合せ」か、「お見積り依頼」なのかを、選択して頂きます。続行ボタンを押して、2ページ目に移ります。

 

2ページ目では、1ページ目で選択された「お問合せ」か「お見積り依頼」の

どちらかを表示することができるのです。Googleドキュメントのフォーム機能では、1ページ目のラジオボタン選択の設定で、次に遷移するページを指定することができるのです。これにより、「お問合せ」フォームと「お見積り」フォームがお客様の選択により切り替えることができます。

 

最後に、3ページ目で、送信ボタンを押すことで、お客様にて入力して頂いた内容を送信することができます。入力して頂いた情報は、Googleドキュメントに保存されます。

 

このように、Googleドキュメントのフォーム機能を利用することで、みんビズの枠を超えた世界が広がるのです。

投稿者:systemkanri 投稿日時:

17pオールクラウド®化への取り組み状況

スライド17

ページ17/17

当社では、いくつかのクラウドサービスを有機的に結合させることによりオールクラウド化を実現しております。

 

※弊社では2014年1月より、サイボウズ社kinotneでの構築をお勧めしております。

 

当社のオールクラウド化への取り組みが、IT導入を検討されている企業様にとって

お役に立てば幸甚です。

 

今後も、ホームページにて続編を掲載してまいりますので、ご期待ください。

 

最後までオンラインセミナーをご覧いただき

誠にありがとうございます。

 

当社では、クラウド導入コンサルティングを行っております。

ご用命は、「お問合せフォーム」にてご連絡をお願い致します。

投稿者:systemkanri 投稿日時: