PythonでLinuxのキャッシュレジスタとデータを交換するためのIceCash 2.0 WebキャッシャーAWSおよびAIS

どういうわけか彼らは私に尋ねた： 「なぜすでに何度も書かれたものをより専門的なレベルで書くのか？ あなたがしていることは故意に悪化し、有能なサポートを欠くでしょう。」 それから私は単純に答えました。「Linuxが欲しいので、コードは無料です。 ドライバーがレジのために買わないように 。 "



はい、 GPLの下でのLinuxボックスオフィス 。 これらの言葉で、実際には、この工芸品の正確な説明があります。 これは完全に無料のコードであり、その一部を開発で簡単に分離して使用できます。 2番目のバージョンは、小売業のすべての革新に対する答えでした。 今、私たちは、興行収入がこれらすべての新しい要件を満たし、自己記述コーディングの代替スペースに存在し続けていると言うことができます。

ヤギの屠殺はどうですか？

一般的に、もちろん、「なぜ？」は非常に重要な質問です。 事前に困惑する必要があります。 何かを書く前に、あなた自身が後で気分を害さないように、必要性、有用性を評価する必要があります。 それから、なぜ私がこのプロジェクトを行ったのかを何度も評価し、巧妙な説明を見つけましたが、実際には... Linuxの下で、そしてコードが無料になるように。 まあ、そしてもちろん、財政装置のドライバーは私にはあまり理解されていないビジネスです。



それで、私はレジの仕事場の基礎を作りたいと思っていました。 好むと好まざるとにかかわらず、多くの人が「自分のために」レジを練っています。 キャッシュデスクはLinuxのWebブラウザで動作するはずであり、そのサーバー部分は理論的にはどこにでも配置できます。 現在、会計レジストラは既に「ほぼ」ネットワークインターフェイスを持つ義務を負っています。つまり、サーバー側はどこにいてもかまいません。 自宅のラズベリーのナイトスタンドで。 これはもはやニュースではなく、興行収入は変化しています。 キャッシュデスクインターフェースは、タブレットや携帯電話に搭載されています。



一般的に、ほぼ無料とほぼ無料のレジソフトウェアを見つけることができます。 何かが完全に無料であるとは限らず、常に無料で、かさばらず、独自のシステムから分離することもできません。 単純なプロジェクトが複雑になり、独自の環境を作成することが頻繁に発生します。この環境から、後でプロジェクトを切り離すことはできません。 Webインターフェースで適切なソフトウェアを見つけることができませんでした。 それで、私は袖をまくり、1か月後に目を閉じました...そして、コードリーの地獄が私の前に現れました。

最初のバージョン。 野生の目とman病な勤勉さで。

最初のバージョン、私はすぐに作りました。 それについて、私はhabrに関する記事を一度書いた。 はい、たくさんのバグとひどいコードがありました。 しかし、当時、これは最小限の作業でした。 当初、それはPHPの軽くて弱い（ほぼHTML）サイトであり、Pythonのいくつかのユーティリティでした。 MySQLのデータベース、真珠スクリプトによるデータ転送。 バックオフィスには、小切手と派生レポートを表示するサイトもあります。 特定のエンコーダーによって書かれたBarcode-Mの無料ドライバーは、私のシステムに貼り付いていました。 公平を期すために、このドライバーが基礎として機能し、それなしでは何も出てこなかったと言う方が正しいのです。 そのとき、私は自己記述式のフリーキャッシュレジスタソフトウェアの主な問題を理解しました。PRKには無料のドライバはありません。



私はいつものように、リファクタリングが遅れてサイトを追加し続け、コードはすでに複雑なcallocodeで大きくなりすぎていました。 これは、コンセプトがどのように、そしてどこまで進むのかが明確でないときに起こります。 そして、彼はそれを子供っぽくはなく異なる方向に投げました。 さまざまなプロモーション、ボーナス、賞品システム。 複雑さが増し、プロジェクトを内部からエントロピー化した。 我慢できなくなったシステムの欠点により、最終的にすべてを書き直しました。 コード内の順序を復元することに加えて、チェックアウト時に、既に互いに結合し始めているすべてのサブシステムを分割し、カオスを増加させる必要がありました。

EGAISは私たち全員に来ました！ だけでなく..

第二版の執筆が成熟する頃には、彼らはすでに普通の財政装置の世紀が長くないことをすでにrumpっていた。 過去2年間で、小売会計の分野で法律が大幅に変更されたことを思い出させてください。 そして長い間、この分野の不変の状況は、多くの革新によってひどく揺さぶられませんでした。 最初はEGAISでした。 はい、私の組織はビールとアルコールを取引していました。 他の組織の同僚と私たちは、「喜び」を持って、単一の電子文書フローに出会いました。 このシステムの欠陥について泣き言を言うつもりはありません。 現在、すべてが多少なりとも正常です。 もちろん、実装の瞬間は常に特に明るく思い出に残る日と夜です...すべてがいつも通りでした-狂った締め切り、通常のテストの不可能性、登録の複雑さ、技術サポートの欠如、新年）。 今では、私たちがやったのは、ある種の非現実的なコメディーだけだったようです。



一般に、この要件を満たすために、かなりの数のソリューションが市場に登場しました。 ただし、各チケットオフィスでJaCartaキーを配布し、このドキュメントがUTM（Universal Transport Module）プログラムを介して流れるようにする必要がありました。 実装時には、通常そうであるように、ソフトウェアはWindows専用でした。 したがって、このビジネスのイノベーターがどのような素晴らしい計画を立てたとしても、すべてのシステムがどのように簡単でシンプルになるのか、実際には少し間違っていることがわかりました。



一般的に、期限までに、小売店にEGAIS用の新しいソフトウェアシステムを装備することができませんでした。 しかし、率直に言って、50のサイトでソフトウェアを変更したくはありませんでした。 JaCartaのキーだけが一度にまともなお金を投げなければなりませんでした。 しかし、その後多くの人がアルコール取引を完全に放棄しました。 カブをひっかいた後、私たちは昔ながらの方法でやりました。 領収書が検証された小売店で、UTMの1つのコピーと多数のアカウントとやり取りするWebサービスがすぐに展開されました。 50個のjaCartaキーが、特別に訓練された従業員に渡されました。 彼女は、マストデイと必要なソフトウェアを備えたコンピューターを受け取りました。 キーを毎日（6か月間）ドラッグし、サイト上のマウスを正しい場所に突っ込むと、フリーランスの新しいフリープロバイダーEGAISAはドキュメントを交換しました。 私たちはこの馬鹿げた人たちだけではない、と思う人もいます。



アルコールの販売には、各小切手の販売時にEGAISと協力する必要があり、これにはすでにキャッシュレジスタソフトウェアの改良が必要でした。 導入前は、わずか6か月でした。 そのため、EGAIS文書を受信するための簡単な一時的な小屋に取り組んで、すぐにチケットオフィスの2番目のバージョンの作成を開始しました。

風水で書きます。

したがって、開発のための半年はたくさんあります。 欠点は、開発者が本質的に1人であることです。 システム管理者のみが彼を助けます。 まあ、誰も私たちを現在の仕事から解放しませんでした。 しかし、私は本当に新しいバージョンを作りたかったので、私は再び貪欲にスキップし始めました。 これで、プロジェクトがどの独立した部分で構成され、どのようにこれらの部分を実装するかについての理解がすでにありました。

そこで、次のスキームに決めました。

ドライバーサーバー

Barcode-Mの既存のドライバーに加えて、FPRINT（Atol）のドライバーとサーマルプリンターのドライバーを実装する必要がありました。 これらすべてのドライバーを同じ印刷方法と単一のチェックデザインで統合します。



一般に、私たちが大量に所有していたサーマルプリンターも接続するというアイデアは、成功したように思えました。 2年後には、財政データオペレーターによってオンラインで確認された、更新されたPRKに財政領収書のみを印刷できるようになることは知りませんでした。 後になりましたが、サーマルプリンターがPRK + OFDのふりをしようとして真剣に取り組んでいたオプションは、財政が破綻したときに便利であることが判明しました。



ESCPOSプロトコルをサポートする会計レストランおよびサーマルプリンターの管理は、別のWebサービスを介して行われるべきでした。 つまり、機器との相互作用に関連するすべてのものは、XMLプロトコルを使用して実行されるべき相互作用を行う個別の独立したアプリケーションに分離されます。







これらはすべて数か月で記述およびテストされました。 注文する同様のタスクを書いてラッキーだった。 つまり、XMLを使用したサーマルプリンターでの印刷の実装は、前日に実装されました。 Atolドライバーを作成し、小切手とそのコピーの同じ印刷で動物園テクノパーク全体を何らかの形で統一することだけが残っていました。 結果は、 DTPrintと呼ばれる別のサービスです 。 彼には、PRKを詳細に設定するための小さなサイトもありました。 後で、サービスにアクセスし、必要なパラメーターを指定して印刷するためのテキストファイルを送信できるコンソールスクリプトを作成しました。 そこで、仕事中にサーバーからメッセージのFAXログを取得し、サーバーからすべての管理情報を印刷しました。 その後、彼はpidgin jabberクライアントからのメッセージを複製しました。 一般的に、私は創造的なブレークスルーのブレークスルーの過程で自分自身を否定しませんでした）。 そうそう、fprintドライバーは、zレポートを削除した後、帝国の3月のビープ音も鳴らしました。

現金事務所のサイト

最初のバージョンと同様に、基本はWebサイトである必要があります。 現在、ApacheとPHPのみのPythonはありません。 キャッシャーのインターフェースはより使いやすくなるはずです）。 データや他のユーティリティの交換を初期化するために、管理機能をインターフェースおよびサービス機能にねじ込む必要もありました。

もちろん、Webボックスオフィスは、ドライバーサーバー、データ交換サービス、ボーナスサーバー、および他の多くのバックオフィスサービスと対話する必要がありました。



また、データをMySQLに保存することも決定しました。 トランザクションストレージシステムを残すことにしました（Shtrikh-Mと同様）。 これで、チェック全体がデータベースに保存されました。 ヘッダーフィールド値またはチェックの内容の形式で解決されたチェック付きの操作に関するすべての必要な追加データ。 私はこれを長い間やりたかった。 このようなデータベースのサンプルはシンプルで簡潔でした。 zetレポートの計算は透過的で、問題はありません。



プログラムサイトの構造は、サブタスクのオブジェクトを含む個別のモジュールに内部的に最大限に分割されます。 EGAISモジュール、ボーナスモジュール、小切手処理モジュール、クエリデータベースモジュールなど



重要な追加はEGAISの実装でした 。 第一に、到着の受領と確認の観点から、第二にアルコールの販売の観点からです。 一般的に、EGAISは後にさまざまなドキュメント、リクエスト、および更新の大規模で無限のストリームであることが判明しました。 今、私はそれをUTM上の別のモジュールで選び出します。 UTMプログラム自体は常に変化しており、プロトコルも変化していました。 最近（2017年7月1日）、2番目のバージョンが導入されました。 JaCartaトークンのキー更新は便利ではありませんでした。 現在、多くの組織がこれをリモートで行うことを提案していますが、Linux + JaCartaの場合はまだ複雑です。 そのため、 Windowsを使用してラップトップに接続してキーを更新します 。 この部分は完成できると思いますが、そうでなければ面倒です。



私は、チェックのアンロードを実装する方法について長い間heしていました。 簡単に言えば、質問は「興行収入にはどれくらいのオンラインが必要ですか？」でした。 彼女はオンライン、オフラインモードを持っていますか、交換はどうなりますか？ その結果、レジは交換機能とは別に実装されました。 サイトは、チェックのダウンロード、レポートの報告、またはサーバーからのデータのダウンロードのためのコマンドに応答します。 crontabから適切な頻度で開始された交換プロセスは、レジの動作に影響しません。 接続はありません-表示方法は関係ありません。欠けた小切手の累積データはなくなり、価格は更新されます。



実践が示しているように、最も複雑なノードはチェック処理です。 そして、これは印刷物であるだけでなく、主に一貫したチェック計算です。 ここで、さまざまなプロモーション、ボーナス、および抽選のロジックに対するあらゆる種類の改善により、最初のバージョンのチェックの計算がまったく理解できないブラックホールになりました。 したがって、新しいバージョンでは、可能な限りチェックを決定し、オブジェクトメソッドに美しく分解するためにすべてを決定しました。







コードが書かれた、それは私には、非常によく思えます。 もちろん、いつでも良くなることができます。 しかし、長い間行われたことは、混oticとしたコード（ G-CODE ）に移行することを恐れることなく、プロジェクトを安定して複雑にするのに十分でした。 もちろん、いくつかのさがあります。 そのため、javascriptと対話するさまざまな方法があります。 サーバー側でのテンプレートの開発から始まり、jsonの読み込みと、より複雑なクライアント側のJavaScript関数で終わりました。 もちろん、ドライバーサーバーとやり取りするためのXMLは、jsonに置き換える方が良いでしょう。 しかし、それをリサイクルする時間はありませんでした。 そして、もちろん、私のデザイナーは出生時に亡くなったので、私はデザインを節約しました。



色の毒性に関するシステム管理者Vovkaのコメントに、いくつかの異なるCSS色を書くことに大騒ぎしました。 しかし、最終的に、もう1つだけが追加されました-グレー、それがメインになりました。 そして、毒は管理者になりました。 これは、興行セッションで混乱しないようにするために役立ちました。







プラスの点は、すべてが最も独立したプログラムモジュールに分割され、メインコードに影響を与えずに安全に書き換えられるということです。 一般的に、このアプローチは非常に正しいように思えました。 このコードのモザイクを使用すると、相互作用プロトコルのみに焦点を当てて、さまざまなデザインを組み立てることができます。 ただし、重要な点が1つあります。最初にプロトコルを十分に検討する必要があります。そのため、後で簡単に変更でき、基礎を変更することはできません。



チェックアウトサイトでのさまざまなユーザーによる同時作業により、トレーディングフロアのさまざまなデバイスからの取引が可能になりました。 後で、ファーストフードカフェのキューを提供するスタイルで注文を処理できるように、チェックアウトのモジュールを完成させました。 すべてが簡単に変更可能でスケーラブルであることが判明しました。



また、レジの現在のインターフェースにすばやく接続し、実際にブラウザを介してオンラインで行動を監視するか、列に並ばないように遅延チェックを自分自身に入力することも有用であることが判明しました。







一般に、管理の速度は大幅に向上しました。 電話のブラウザから（VPN経由で）支払い、設定、ドライバー管理のプロセスに介入することが可能になりました。 VNCとsshはキャンセルされませんでしたが、すべてのツールが積極的に使用されました。 一部の設定はグローバルで、キャッシュデスク自体がサーバーから設定を取得し、同時に自身に関する情報（重要な設定、IPアドレス、接続時間、ソフトウェアバージョン）を送信しました。 時間が経つにつれて、豊富なcrontabと自己診断のスクリプト、およびチェックアウト時に形成されたサーバーへのレポートの送信。 しかし、自慢することは何もありません、誰もがそれをします。

現金管理サーバー

キャッシュデスクを効率的に管理するには、実際にレジ管理サーバーを作成する必要がありました。 少なくとも、キャッシュデスクからのすべての領収書はそこに集められ、ソフトウェアの更新はそれを通して行われるべきです。 実践が示しているように、これは自作プロジェクトの非常に重要なタスクです。



実際、別のWebサービスおよびサイトでした。 主なディレクトリは、組織、価格、商品グループ、キャッシュデスク、および価格のタイプに入力されている必要があります。 キャッシュデスクは、組織（ブランチ）で分割する必要がありました。 後に、ここにアクションシステムが追加されました。これは、興行収入のプロモーションスクリプトの作成と配布です。 まあ、これらの同じ行動の私自身の言語のようなものが発明されなければなりませんでした。







このサーバーの最初の重要な機能は、新しい価格を受け取り、チケットオフィスに配布することです。 価格は興行収入に結び付けられるべきでした。 つまり、サーバー自体で、利用可能なものからの価格表を各チケットオフィスに示します。 レジ係は、単にその識別番号でサーバーに連絡します。 応答として、サーバーはzipアーカイブのダウンロードに青信号を出します。 ダウンロードが成功した場合、サーバー自体がこのクライアントの最後のダウンロードの時刻をマークし、価格を提供しなくなります。 もちろん、新しい価格がサーバー自体にアップロードされるまでは。

また、サーバーへのファイルのアップロードも通常のPUT HTTP操作であり、ブランチの識別子と価格自体を指定する必要があるだけです。 その後、私のシステムの一部を職場で紹介した友人が、価格表をサーバーに直接アップロードするために必要な処理を1Cで作成しました。 同時に、彼は同じサーバーからJSON zetレポートをダウンロードする処理を作成しました。







2番目の重要な機能は、キャッシュデスクからのデータの収集です。 Zetのレポートとチェック。 一般的に、レジでチェックアウト時にZetレポートを生成し始めたという結論に達しました。 つまり、既製、製品ごとにグループ化され、必要な合計で、Zetレポートがデータベースにあります。 また、Webインターフェースで詳細に調べることができます。 レジの作成の初期段階では、データ収集サーバーなしですべてを実装したため、レジとサーバーには、外部からの要求に応じてレポートとチェックを発行するための同一の機能が含まれています。 必要に応じて、サーバーがなくても、キャッシャーから直接データを要求することができます。 そのため、レジ係は、リクエストに応じて、jsonに2つのデータストリーム（アップロードされていないzet-reportsのストリームとアップロードされていないチェックのストリーム）を生成します。 データはサーバーにアップロードされ、そこからリクエストに応じて1Cにアップロードされます。 オプションとして、ZetレポートをBarcode-Mファイルなどの特殊なテキストファイルにアップロードするスクリプトが作成されました。







サーバーインターフェイス自体から、領収書を表示することができました。 しかし、この機能は不便で強力ではありませんでした。 したがって、後で、別のサイトを作成しました。このサイトを通じて、小切手のデータベースからさまざまなサンプルを作成することができました。 以前のバージョンのIceCash向けの既存の動作中のWebアプリケーションに関するzetレポートおよびその他の開発を表示する機能を追加して、このサイトを開発する予定でした。 しかし、悲しいかな、これには十分な時間がありませんでした。これは1つのレポートのサイトのままでした。











また、サーバーにはレジソフトを更新する機能が割り当てられました。 アップデートには、システムアップデートとプログラムアップデートの2種類がありました。 更新はすべてバージョン追跡から始まります。 運用するバージョン（prod）は、単にサーバー上のグローバル変数によって設定されます（ updateおよびupgrade ）。 すべてのサーバー変数は、興行収入に自動的に配布されます。 これには、一定の複製を必要とするすべてのキャッシュデスクで関心のあるグローバルパラメータも含まれます。 たとえば、私の気温はこんな感じです。 各ブランチには独自の変数と値のセットを設定できるため、天気は地域ごとに分散されます。 これは楽しみには必要ありませんでした。 そのような行動がありました-天気によると、割引式は温度に基づいていました。



そのため、ここでは、更新プログラムのインストール用に規定されているバージョンも、地域ごとに変数によって配布されます。 これは、ステップテストに便利です。 最初に1つのチェックアウトで、次に小さなブランチで、翌日-大きなブランチで。 まあ、それが風水に関するものなら、最初は一貫性のないバージョンのロールオーバーに関連する噂がしばしばありました。



プログラムを更新すると、実際には目的のバージョンがダウンロードされ、古いバージョンが置き換えられ、サービスが再起動されます。 作業プログラムのバージョン。プログラムはコード内の定数から認識します。 サーバー上で、作業バージョンよりも大きい値を設定すると、レジがそれを取得します。

システム更新は、必要なファイルとbash更新スクリプトを含むtbzアーカイブです。 これらの更新は順次実行されます。 サーバー上のすべてのアーカイブは、レジ係が順次アーカイブをインストールし、ステータスを必要なものに更新できるようにするために必要です。







事実は、作業システムのダンプを展開することでキャッシュデスクを確立することです。これは、常にではありません...または、常に十分ではありません。 したがって、アプリケーションとランタイムの間の競合を避けるために、新しく解凍されたイメージはシステムの更新を順次ロールします。



これらのタスクに加えて、最終的に、 ストックスクリプトを作成、保存、および配布するためのシステムが作成されました。 現代の小売はこれらのプロモーションなしでは生きられません。 どれだけ必要なのかはわかりませんが、小売プログラマーにとっては、特別な場所があります-アクションシステムです。 株式は常に対立しています：

1. 自分で。
2. ボーナスシステム付き。
3. 価格ベースの制限システム。
4. すべてのシステムがチェックで動作します。

株は気まぐれで危険です。 さらに、彼らは常にマネージャーによって高く評価されており、ディレクターは必然的にその有効性の詳細な分析を要求し、そこから脳が沸騰します。 それだけではありません。シェアは同じになりたくないだけです。 それぞれが他の人のようになりたくないので、この感染を理解してテストするために、あなたの注意の余分な時間を奪うよう努めます。 そして、はい、実際の作業期間を設定することを忘れないことが重要です。







一般に、最初のバージョンで株式を作成するプロセスを自動化する私の試みは、時間と神経の浪費以外の何にもつながりませんでした。 そのため、次のプロモーションでは最初の100万個のチェックマークが必要になるため、2番目のバージョンでは、マネージャー用の100万個のチェックマークを含むWebフォームの作成を完全に拒否しました。 代わりに、これらの株のミニ言語を実装する別のモジュールを作成しました。 そして、すでにこの言語を使用して、スクリプトで各アクションを一貫して説明しました。 条件、選択、グループ化、交換、ポジションの追加などを確認します。







時にはスクリプトを少し変更する必要があり、時にはコマンドを追加する必要がありました。 しかし、今ではすべてのマネージャーとそれらのインターフェイスはフォレストを通過しました。 神経のコストは確実に減少し、これがどのように機能するかが明らかになりました。 しかし、私はマネージャー向けのインターフェースを作成することに同意しませんでしたが、冗談めかして株の言語を学び、それにスクリプトを書くことを申し出ました。

追加サービス

Python + Mysqlのサービスの形で、独自のボーナスシステムをすでに開発しています。 したがって、それと対話するモジュールのみが追加されました。 また、賞品抽選システムがありました。 これはサーバーでの宝くじのようなもので、各小切手は小切手を支払った後に抽選を開始します。 このために別のモジュールも作成されました。 そして、その時点での賞金システムは、特定のアクションに含まれていました。



メインExchangeサーバーを含むこれらのサービスはすべて、openvpnネットワークにラップされていました。これは、システムを保護する最も簡単な方法でした。 さらに、興行所で彼のファイアウォールを働いた。

OPENVPNキャッシュレジスタキーは、特定のアドレスに正確に割り当てる必要がない場合は、単独で使用できます。 すでに生成されたキーのプール全体と、それらに割り当てられたアドレスを使用して、触れませんでした。 しかし、理論的には、データ交換サーバーは、どのアドレスで、どのチケットオフィスが接続されているかを常に認識しています。

財政データ演算子

はい、できました。 しかし、まだ創造的な操作の余地は十分にありました。 すべてを美しくカットする時間はほとんどありません。 しかし...第二の変化の波が来ました。 FZ-54の要件に精通している人は説明する必要はありません。 最初に、税務当局からの恐怖物語が始まりました。 道に沿って、彼らはいつものように嘘をつき 、その結果、PRKの運用は以前よりも安くなることを保証した。 それから、財政レジストラのメーカーからの約束は、すべてが時間通りになることを保証します。 それから、いつものように、誰も準備ができていなかったことが判明しました...集会の組織は3対1でした。



ビジネスはゆっくりと不満にいびきをかき、予想された費用の苦い後味を吐き出し、ビストロ自動機からの未熟な果物を味わった。 そして、私たちはシベリアの雪の吹きだまりを悲しげに見て、苦笑しました-夏まで、私たちは時間を過ごす何かをしました。



これらすべての大規模な変更について最も不愉快なことは、彼らがすべて私たちのような開発者に唾を吐きたかったということです。 ドキュメントはゼロで、締め切りはきついです。 テストできるのは白人のみです。 新しいPRKをすぐに感じることはできませんでした。 そのため、いくつかのオプションがありました。

1. 新しいATOL
2. ニューバーM
3. 古いShtrikh-Mと一連の改善。

理論的には、財政装置の製造業者は財政ドライブでEKLZを交換し、データをOFDに送信してインターネット通信チャネルと対話する能力を財政に提供する必要がありました。 しかし、何百万もの方法で同じタスクを達成できます。 そして、もちろん、結果として少なくともそれらのいくつかがあります。 そのため、LANジャックのない財政関係者がいました。 特別なドライバーを使用すると、 USBを介してLANを作成し、窓の下にいる場合や長い時間を過ごしている場合に人生を楽しむことができます。 しかし、私はこの時間を持っていませんでした。 そのため、Barcode-M RETAIL-01の新しい安価なクラフトは放棄されなければなりませんでした。



しかし、一連の改善されたオプションは非常に適していました。 彼らは財政へのシャントを作り、新しい頭脳とLAN出力を挿入しました。 ただし、バーコードはネットワークプリンターとしては機能せず、2つのテールに接続されていました。 1つは以前と同様にコンピューターに、もう1つは（LAN）ルーターに。 したがって、彼は独立してOFDにデータを送信し、通常の方法でドライバーと協力しました。 しかし、ドライバーを少し変更する必要がありました。



Atolの決定はより興味深いものでした。 一般に、プリンタはネットワーク化され、キャッシャーからLAN経由でアクセスできます。 ここでは、ドライバーもいくつかの改善を行う必要がありました。



ドライバーのすべてのテストと改善は、私の仕事の変更と別の地域への移行と一致したと言わなければなりません。 しかし、これは災害にはなりませんでした。ドライバーをリモートでファイナライズしましたが、今ではすべてが50個のオブジェクトでかなりうまく機能しています。確かに、OFDの導入前に私がIceCashに移した1つの組織は、それでも私との協力を継続することを拒否し、おそらく他のソフトウェアにジャンプしました。



新しい財政装置を導入することの魅力はすべて私にも触れませんでした。私の前のパートナーであるVovkaはこの幸福を最大限に飲みました。したがって、新しいPRKの登録と設定に関する詳細はわかりません。しかし、これについては多くのことが書かれています。

見た、修羅、私は気にしません。

大企業でプログラマーとして働いているので、IceCashキャッシュデスクが導入された地域からはほど遠いです。私は何かを追加していますが、時間の経過とともにひどい緊張を感じます。また、ソフトウェア要件もまだ維持されておらず、EGAISが開発中であり、新しいドキュメントフローが出現しています。突然、別の小売チェーンが存在しなくなり、それとともにプロジェクトが終了するのは残念です。おそらく誰かがこのクラフト、その部分、モジュール、コードを気に入るでしょう。多分、サポート、プロジェクトの開発、または良い分岐を作成できます。



サードパーティの開発者がプロ​​ジェクトの任意の部分を取り、自由に分離し、その背後に発明された機能の動物園全体をドラッグすることなく簡単にできるように、私はすべてをしようとしました。一般的に、誰もがうなずく;）

参照資料

git GIT ICECASH2 GIT ICESERV Wiki

共有サーバーのIceCash2コードを次に示し ます

。これは追加しませんでした：WIKI