複数のオフィスと数十人の従業員を抱える会社の仕事を整理するという問題に直面している人にとって、ビジネスを制御するためのターンキーソリューションがシステム管理者と所有者の両方に大きな頭痛の種を作成することは秘密ではありません。
1C、Bitrix、Megaplan、またはさらに独立したソリューションであっても、特定のソフトウェアのインストール、VPNまたは他のソリューションを介したサーバーへのリモートアクセスの確立が必要で、ショッピングセンターやリモートオフィスでよく見られる悪い通信チャネルでは動作しません。自宅や出張からアクセスするための労働者の顕著なスキルが必要です。
それとは別に、パフォーマンスについても言えます：私にとって、負荷の高いデータベースシステムの開発者として、数秒ではなく数十分でレポートを生成することは常に奇妙でした。サーバーに。 MySQLでさえ、100万のドキュメントから作業期間全体の残りの倉庫を計算するような単純な操作には数秒かかることが明らかでした...
質問文
一般に、5つのリモートストア、倉庫、オフィスに会計システムを配置するという課題に直面したとき、既製のソリューションの選択肢は淡く見えました。 トレーニングセラー（コンピューターユーザーではなく、グッドセラー）のトレーニングについて考えた後、初めてマウスを見たとき、1Cを使用してネットワークをセットアップするための無限の旅、これが私たちの選択肢ではないことが明らかになりました...
次のものが欲しかった：
•タブレット、スマートフォンなど、あらゆるオペレーティングシステムから完全にリモートで使用
•通信チャネルの品質に厳しい
•使いやすいインターフェイスと使いやすさ
•速度-1秒以内のレポートとドキュメント
•高度な分析を埋め込む機能
解決策の1つは、車輪をゼロから再発明しないために、独自のサーバーに基づいて、最も単純なメカニズムと構造で動作するオンラインシステムを作成することでした。 命名法を説明する無限の表も冗長に見えます-各パラメーターのネームプレートが付いた十数個のフィールドはまだうまく機能します。
開発
サーバーには十分な電力があったため、最初のブートストラップであるPHPとMySQLの3晩で、在庫を保持し、倉庫の残高を数え、印刷されたフォームを備えた最も単純なプライマリアカウンティングドキュメントを持つプロトタイプを作成しました。
もちろん、最も興味深いのは、文書を作成するプロセスでした-すべての会計はそれに基づいています。 外観上の違いを除いて、ドキュメントはソースウェアハウスからレシーバウェアハウスに商品を移動します（場合によっては、これは倉庫ではありませんが、データ構造は変更されません）。
簡単に言うと、文書の保持とは、適切な倉庫に適切な量の商品またはサービスがあるかどうかをチェックし、実際に商品またはサービスを一方から他方に差し引くプロセスです。 その過程で、誤って予約済みの正しい価格、これらの操作に対するユーザーの権利、クライアントの信用限度などを誤って消さないように、商品の準備金を確認することをお勧めします。
別の関連タスクは、任意の時点での倉庫の状態を計算する方法です。 中間インデックスの写真の上に座った後、毎回すべてをゼロから読み取るために必要な操作の数がわかりました。 -そして、3つのデータベースクエリがこの問題を解決します。 実際、定期的に古くなり、関連性の要件を満たさない無限のインデックスを保存するよりも、すべての商品と倉庫を新しくカウントする方が、毎回安価です...
そのため、ドキュメントを投稿するたびに、ドキュメントに示されている商品のすべての残高を取得し、それらをゼロから検討し、すべてが問題なければ、償却操作を行います。 ご存じのように、適切に構造化されたテーブルからの数十から数千の行からの通常の量の10から20製品のサンプルは、ほんの一瞬です。 これまでのところ、負荷の高いアプリケーションでも、これはうまく機能します。
将来的には、このプロセスの当事者（病院の平均ではなく、トランザクションのマージンを正確に計算するためにこの製品がいつ、どのように配信されたか）、さまざまなタイプの価格、およびGTEなどの追加情報を考慮に入れるようシステムに教えました。
ちなみに、これらすべての考えは、1Cタイプのソリューションに対する私の最後の信仰をすべて私に殺しました。 データベースが少なくとも単純に「適切に」配置されている場合、会社のすべてのデータは数秒でカウントできます。 私はすべてを強調し、同時にすぐに強調します。 文書の転写やレポートの生成時にこのモンスターが何をするかは一般に不明です。 php-cgiを使用しない非常に遅いPHPスクリプト、特定のデータベースの最適化を行わないシンプルなMySQL、および他のプロジェクトを眼球にロードした場合でも、3年間の中間データを使用せずに倉庫のバランスを「ゼロから」計算しました。
同じ会社の1Cでの同じタスクは、同じ3年間で15分から20分かかりましたが、データベースにはそれぞれに5〜10個の商品を含む数千のドキュメントしかありませんでした...
15分で3万件のレコード...誰か、おそらく、それは速いようです。
実装
実装プロセスは単純で、mail.ruの使用方法を学習した後、気付かれることはありませんでした。 1週間以上熟成した売り手でさえ、すでに在庫残高を元気よく見て、売り上げを上げ、商品の実際の在庫状況へのコンプライアンスを監視できます。 最初の月には多くのニーズが明らかになりました。必要なレポートが完成し、ドキュメントが大幅に拡張され、多くのアクセス権が導入されました。
最も重要なことは、レポートがほんの数秒で生成され、別の都市の地下鉄に座っているときや車で運転しているときに、3.5インチのスマートフォンからレポートを開いて（そう、当時は通常の画面だった）、ビジネスのすべての数字を見たそれに興味がありました。
その結果、システムは完全にサーバー上にあり、2時間ごとにバックアップが行われ、高度なアクセス制御とログ記録が行われました。 このシステムは、Android向けのiPhone、スマートフォン、タブレットのどのブラウザーからもアクセス可能で、Opera、Firefox、Chromeでも同様に機能しました。 ほとんど変わらない形で、彼女は数年間働いた。
選択した倉庫へのアクセスを個々の取引先とディーラーに公開し、必要なすべての会計レポートをその場で受け取り、店舗には安価な3Gインターネットがあり、主任会計士は彼の仕事のためにワンクリックでデータをアップロードしました。
パートナー
かなり早く、パートナーと知人がアイデアを取り上げ始めましたが、最初の主要な商用実装の前に堅実な期間が過ぎました。 重要なタスクの信頼性についてシステムを実際にテストする機会は、さまざまな都市に多数の支店を持ち、関連する数十万の複雑な範囲を持つスペアパーツを販売する大企業によって提示されました。 この分野で既製のソリューションを想像することは不可能であったため、すべての活動は理想からかけ離れた自己記述のソリューションで実行されました。 クラスとしてのレポートはまったくなく、データベースは非常に紛らわしかった...
歌詞をスキップして、トレーニング、データのインポート、アクセス権、ビジネスモデルの微調整とともに、すべてのブランチをシステムに転送するのに3か月もかかりませんでした。 結果を生まないソリューションの開発に何年も費やし、会社の特定のタスクに固有の分析の開発と一緒に何ヶ月も実装しました。
パートナーの要求に基づいて、まずCRMモジュールを組み込み、少し後に委任を使用してタスクを設定および監視しました。 管理作業-コスト管理を伴う物流の分析と計画の可能性。 管理-予算計画、強力な分析レポート、その準備には手動で数週間かかりました。
現時点では、倉庫内の30万アイテム、10万アイテムを超える用語集のディレクトリ、カタログと価格に関連して、1日あたり数百の新しいドキュメントが処理に問題を引き起こすことはありません。
現在、システムはbmsys.orgにあります-現在そこで機能している機能とモジュールのリストについて読むこともできます。