マーク、マーク、マーク。マーキングは簡単！？

今年は、新しい「オネストマーク」マーキングシステムの使用方法に関するいくつかの記事が一度に公開されました。それらは、パイロットプロジェクトの進捗状況と戦闘システムの立ち上げの最初の日についての彼らの見解を反映して、売上高に参加している企業のIT部門の「ITスペシャリスト」によって書かれました。例えば、こことそこ。

主にAPIの頻繁な変更、個人アカウントのバグ、一部のプロセスのホワイトスポットが原因で、システムはしばしば批判され、批判されました。

私たちは、最初ではありませんが、私たちが積極的に参加しているこの州の新しい野心的なプロジェクトについての私たちの経験と考えを公表することにしました。



記事がめちゃくちゃに見えるかもしれませんが、全体としてのラベリングはめちゃくちゃで、多くの側面が一箇所に集まっています。

私たちについて簡単に

Cleverensは、主にデータ収集端末（TSD）およびリタイアメントレコーダー（RV）の特殊機器向けに、モバイルワーカー向けのソフトウェアに取り組んでいます。



森、森の中に木、木の上にカブトムシがいて、カブトムシに微生物が住んでいるように見える人もいるかもしれません。TSDのソフトウェアのニッチは、カブトムシの微生物に関するものです。



これに対して、スタッフのモビリティは非常に大きな成長市場であり、既製のソフトウェアを備えた特別なハードウェアは、一般的に現在のすべてのハードウェアの未来であると答えることができます。結局のところ、本当に画期的なことは、狭いニッチでの長年の作業の結果です（モバイルYouTubeに関するAndrey Doronichevの有名なインタビューを参照してください）。



基本的に、Cleverence製品は、会計システムとの既成の統合で販売されます。会計システムは、私たち自身が作成およびサポートします（たとえば、Warehouse 15）。



私たちは、すべてのソフトウェアとハ​​ードウェアを実際の業界、倉庫、ショップなどで実行しようとしています。たとえば、靴のラベリングプロジェクトが始まったばかりのとき、私たちはビジネスプロセスをテストするために中国に行き、同時に彼らはそれについてのビデオを撮影しました。

ラベリングシステムと「フェアマーク」とは

大まかに言えば、これは商品のユニットの動きを完全に追跡するためのバーコードとRFIDに関する官民のインターネットです。



ラベリングシステムに関する情報はたくさんあります。主なリソースはHonestSignのWebサイトです。

ラベリングに対する市場参加者の態度

ラベリングに対する市場参加者の態度が二極であることは周知の事実です。「ロシア、フォワード！」より そして、「アイデアは良いですが、実装は私たちを失望させました」から「彼らは再び小さな子供たちを傷つけました」。



利点には、市場の白塗りとサプライチェーンの管理が含まれます。マイナスの-マークされた商品を取引する際のUTIIからの削除。



ラベリングのためのほとんどすべての大企業。美しく白で仕事をしたい小さな起業家は、ラベリングのためにも、これは灰色の市場に対する競争上の優位性です。

ほとんどの中小企業はラベリングに反対しており、これはすべて自分たちにとって不必要な負担であると考えています。

クレームは主に「中小企業が再び絞首刑にされている」または「お金と人が多すぎるので、これを行うことができた」、「そのようなビジネスプロセスはよく考えられていない」として定式化されます。主なお金が使われたのは中小企業とそのプロセスでしたが、これは参加者の個人アカウント、クラウドベースのコードエミッションレコーダーなどを備えたサイトです。



ITスペシャリストの立場についても、以下で言及する価値があります。



同時に、情報を公開する情報ポータル「オネストマーク」も大丈夫です。たとえば、英語の情報はどこにありますか？ここです。そして中国語で？ここです。

誰もが話していた起動時の問題

パイロットが歩いている間、システムには多くのバグがありました。基本的に、彼らは2020年7月1日までになんとか彼らを癒すことができました。



彼らは、EGAISが最初はより良く機能し、一般的に、サービスの可用性がより高いと約束しました。



現在、このシステムはタバコと靴でいつでも利用できます。夕方の数時間の技術的な作業のためのまれなシャットダウンを除いて、すべてが迅速に機能します。







しかし、当初の大きな問題は「活用せずにはいられない」ということであり、99％の売上高参加者（数）がこのシステムを愚かに無視し、登録せず、負荷をかけず、判断の日を待ってから延期を要求した。

2019 «» , 10 , ( ). 10 .



, , .

誰もがこの問題を知っていて、準備をしていましたが、靴の締め切りが迫ったとき、それはまだ崩壊していました。一部のUOTは、残りの20年間、無料のコードを急いで書き出しました。これは、ピーク時にサーバーの負荷を40倍に増加させました。もちろん、そのようなゲームは無駄にはなりません。なぜなら、システムはデジタルであり、彼らが言うように、「すべての動きが記録される」からです。



残念ながら、マーキングのパイオニアも苦しみました。これらは、初日からマーキングパイロットに参加し、誠実に試みた企業ですが、最終的には延期も求めました。



ここで言わなければならないのは、州のシステムは販売初日から喜びをもたらすiPhoneではないということです。そして、その作成の目的は、ITスペシャリストからいいねを集めたり、「出てきたら、購入するかどうかを自分で決める」などのビデオレビューを撮影することではありませんでした。



何らかの理由で、人々は、システムが最初から5年間生産されているかのように機能することを期待しています。



一般に、この論理に従って待つ場合、すべてが完璧になると、火星の征服後、すべてが2030年、またはそれ以上に延期されます。

ITスペシャリストの立場

ITスペシャリストの立場は、「賛成」または「反対」ではなく、「与える」ことです。すべての変更を事前に発表する必要があり、より良いドキュメント、より多くのテストケース、サンドボックス、より少ない制限が必要です。

一般に、このプロジェクトにはさまざまなハードウェアと国際標準があり、従来のITスペシャリストに苦痛と苦痛をもたらすだけです。



ITスペシャリストは非常に腐食性が高く、インテリジェントな人々であり、あらゆる問題について独自の意見を持っています。また、APIに関する主張を除いて、ラベリングに関するコンセンサスはありません。一般的にはありません。



システムのAPIは、「作成して忘れる」シナリオで必要になるよりも頻繁に変更されます。同時に、グループパッケージ（集合体）を操作したり、認証を簡素化したりするために、APIに多数のメソッドを追加する必要があると考えられますが、これもAPIの変更を意味します。



私たちはIT担当者であり、APIにメソッドがないのと同じ二重の立場にありますが、APIは頻繁に変更されます。ここで、彼らが言うように、「旗は人種差別主義者ですが、これは私たちの物語です。」

一般に、APIを改善する必要がありますが、この1〜2か月前に警告し、システムに変更を加える時間を与えることをお勧めします。そしてそれは、テストループよりもタバコマーキング戦闘ループに新しいバージョンのAPIがあった時でした。

マーキングの技術的側面

ITプロフェッショナルが直面する技術的な課題は、基本的に次のリストに要約されます。

• UKEPに関するSysadminの質問。これは、オペレーティングシステムとブラウザのバージョンによる断片化がある限り、これまでも今後も続くでしょう。
• オープンソースソフトウェアを使用しているにもかかわらず、システムが新しくてユニークであるため、StackOverflowをグーグルで検索しても解決できないコーディングの問題
• 「オンラインバーコードジェネレーター」または「キーボードブレーカー」を使用する場合の実装に関する質問、そしてなぜナンセンスが出てきたのか疑問に思う

ほら、ここにJava、Reactive（RxJava）、Spring、さらにはNetflixがあり







ます。あなた自身の意見を形成するために、カートでテクノチャットを読むことができます。

承認

IS MPでの承認は、2段階で行われます。



まず、特定の疑似ランダム「キー」を要求する必要があります。これは、署名してURL「/ api / v3 / auth / cert /」に送信する必要があります（この記事の執筆時点では、URLの末尾にスラッシュ「/」を付ける必要があります。そうしないと機能しませんでした。奇妙に見えます）。



「キー」の取得は次のとおりです（目的のホストを置き換える必要があります。サンドボックスか戦闘用か、衣服か何かに応じて、さまざまなホストがあります）。

//   /api/v3/auth/cert/key “”  ,   
var uri1 = new Uri("< >/api/v3/auth/cert/key")
var randomDataResponse = REST.Invoke<RandomDataResponse>(uri1, "GET", timeout);

次に、選択したCEPを使用してこの疑似ランダム「キー」に署名し、それをGIS MTに送信して、応答として認証トークンを受信する必要があります。



これを行うために、ユーザーが選択した指紋（certificateThumb）のCEP証明書を探しています。この場合、証明書はローカルマシンの「パーソナル」にあります。また、証明書コンテキストはキーペアストアに関連付けられている必要があります（このような証明書は、Windowsスナップインの証明書のリストでキーアイコンでマークされています）：







署名を生成するためのコードで証明書を取得します。

X509Certificate2 cert = null;
using(store = new X509Store(StoreName.My, StoreLocation.LocalMachine))
{
    store.Open(OpenFlags.ReadOnly);
    cert = from c in store.Certificates where string.Compare(c.Thumbprint, certificateThumb, true) == 0 select c;
}

この方法でサインインします。

//   
var content = new ContentInfo(randomDataResponse.Data);
var signedCms = new SignedCms(content, false);

//    ,  
var signer = new CmsSigner(SubjectIdentifierType.IssuerAndSerialNumber, cert);
signer.SignedAttributes.Add(new Pkcs9SigningTime(DateTime.Now));

//  
signedCms.ComputeSignature(signer, false);
var sign = signedCms.Encode();

署名されたCMSメッセージ（sign）は、Base64形式に変換された後、承認のために送信する必要がある検証署名です。

var tokenRequest = new TokenRequest();
tokenRequest.UUID = randomDataResponse.UUID;
tokenRequest.Data = Convert.ToBase64String(sign);

//    /api/v3/auth/cert/
var uri2 = new Uri("< >/api/v3/auth/cert/")
var tokenResponse = REST.Invoke<TokenResponse>(uri2, "POST", tokenRequest);

応答は、Base64でエンコードされたJWTトークンです。



ちなみに、送信されるドキュメントはその後同じ方法で署名され、いわゆる「切り離された」署名のみが形成されます。

var signedCms = new SignedCms(content, true);

ヘルパークラス（APIのXSDドキュメントスキーマと同じスキーマを使用）：

/// <summary>
///    GET /api/v3/auth/cert/key  .
/// </summary>
public class RandomDataResponse
{
    /// <summary>
    ///     ,  string
    /// </summary>
    [Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]
    public string UUID { get; set; }

    /// <summary>
    ///  ,  string
    /// </summary>
    [Newtonsoft.Json.JsonProperty(PropertyName = "data")]
    public string Data { get; set; }
}

/// <summary>
///     .
/// POST /api/v3/auth/cert/
/// </summary>
public class TokenRequest
{
    /// <summary>
    /// uuid -      /api/v3/auth/cert/key
    /// </summary>
    [Newtonsoft.Json.JsonProperty(PropertyName = "uuid")]
    public string UUID { get; set; }

    /// <summary>
    ///        base64
    /// </summary>
    [Newtonsoft.Json.JsonProperty(PropertyName = "data")]
    public string Data { get; set; }
}

/// <summary>
///     .
/// POST /api/v3/auth/cert/
/// </summary>
public class TokenResponse
{
    /// <summary>
    ///    base64-
    /// </summary>
    [Newtonsoft.Json.JsonProperty(PropertyName = "token")]
    public string EncodedTokenBase64 { get; set; }
}

ログインできた場合は、小さなクエストを完了しています。

バーコードの生成と読み取りに関する問題

マーキングシステムは、暗号化された部分を除いて、国際標準に基づいています。これは素晴らしく、称賛に値します。



残念ながら、平均的なITスペシャリストは標準を読んでおらず、何も研究していませんが、バーコードの生成、印刷、ビジネスプロセスなどに関する無料のコンポーネントから自転車をすぐに彫刻します。



最初の難しさは、デザインにラベリングバーコードを印刷することです。箱から出してすぐに「HonestSign」は無料のツールを提供しますが、1C / SAP / NAV / DAXには「オンラインバーコードジェネレーター」と組み込みのレポートエディターがあるため、もちろん誰もそれを扱い始めませんでした。



待ち伏せは、現代のバーコードが単なるシンボルのグラフィック表現ではないということです（これについては別の記事があります）。したがって、誰も知らず、すぐに理解したくないプレフィックス、セパレータ、エンコーディング、必須の印刷不可能な文字などの問題が表面化しました。



GS特殊文字（ASCII 29）の







例FNC1特殊文字（ASCII 232）の例







スクリーンショットは、チェックマークアプリケーションから取得されます。



これは、カメラによってスキャンされ、プラットフォームによって解析されたバーコードを解析するCheckmarkソースコードの一部です。

var km = BarcodeData.GS1;
if (km.Contains("01") && km.Contains("21"))
{
    if ((km.Contains("17") || km.Contains("7003")) && !km.Contains("10"))
    {
         = true;

        if ((km.GetValue("01").Length == 14) && (km.GetValue("21").Length == 7 || 
             km.GetValue("21").Length == 13) && (km.GetValue("17").Length == 6 || 
             km.Getvalue("7003").Length == 10) && (km.GetValue("93").Length == 4))
        {
              = true;
             MSG2 = " KM   .";
             if (km.GetValue("21").Length == 7)
                 MSG2 = "      .";
        }
        else
        {
             //        (EntriesRows)
             //    -     
             EntriesRows = I(EntriesRows, Al = 93, BarcodeData);
             MSG2Error = "   3!     .";
             Msg = "<b>#N005</b>" + Msg;
         }
    }
    else if (km.Contains("8005") || km.Contains("93"))
    {
          = true;

         if (km.GetValue("01").Length == 14 && km.GetValue("21").Length == 7 && 
             km.GetValue("8005").Length == 6 && km.GetValue("93").Length == 4)
         {
              = true;
             MSG2 = "    .";
         }
         else
         {
             EntriesRows = I(EntriesRows, AI = 8005, BarcodeData)
             EntriesRows = I(EntriesRows, Al = 93, BarcodeData)
             MSG2Error = "   3!     .";
             Msg = "<b>#N004</b>" + sg;
         }
    }
    else if (km.Contains("92") && km.Contains("92").Length > 66)
    {
         = true;
        if (km.GetValue("01").Length == 14 && km.GetValue("21").Length == 13 &&
            km.GetValue("91").Length == 4 && km.GetValue("92").Length == 88)
        {
            ... ( ..) ...

特別なキャラクターはどこから来たのですか？標準から。 「オネストサイン」は基準通りにすべてを行い、商品の売り上げの参加者も基準を読まなければなりませんでした。



ところで： DataMatrixコンテンツの正確さを確認するには、カメラでスキャンする必要があります（TSDからスキャンする場合でも、カメラにアクセスする必要があります）。すべてのバーコードスキャナーは、標準に従って、読み取ったものを1in1で返す必要がないため、少なくとも最初のFNC1文字を破棄する必要があります。一般に、スキャナーはスキャン時に重要なバーコードシンボルを追加または削除したり、設定に応じてブロックを所定の場所に再配置したりできます。これはすべて検証を妨げます。



なぜならシステム統合はプログラムではなく、人とその仕様の読み書き方法に関するものであるため、これらの特殊な文字の存在は、バーコードを交換するときにすぐにいくつかの不一致につながりました。



たとえば、仕様を実際に読まなくても、1つのASCII 232（FNC1）文字の代わりに4文字の文字列「FNC1」をバージニアに追加できます。それでも、サブシステム間で交換する場合、そのような文字はフィルタリングされて失われることが多く、通常のテキストエディタでは特別ですが、そのような文字なしで印刷されます。文字が表示されないことが多く、バーコードが一致しているのになぜ何かがおかしいのか疑問に思います。



同様に、シンボルFNC1を指定しない場合バーコードでは、一部のハードウェアまたはソフトウェアは、それが何であるか、およびそれを分解する方法を理解していない可能性があります。バーコードの先頭にあるこの記号は、これがGS1DataMatrix形式であることを示しています。



ほとんどの人が偶然見つけた最近の例の1つは、シリアル番号に括弧と句読点が表示されていることです。







括弧と句読点はシリアル番号のどこから来ていますか？標準外です！ GS1規格では、それらを使用できます。なぜならシリアル番号はわずか13文字で、マーキング用の商品がたくさんあるので、使用可能なすべての文字を使用する必要があります。



個別のlulze-シリアル番号の括弧。それらは標準で許可されていますが、誰もそれらを期待していませんでした。いわゆる人間が読める表記法（HID）では、括弧には特別な意味があります。括弧は、意味のある文字グループの数を構成します。たとえば、「（21）」は、シリアル番号がさらに下に行くことを意味します。



バーコードに文字列だけが含まれていると考えるのが単純な場合、「（21）abcd12（3）d（1、（91）」）の行では、シリアル番号は「abcd12」のように見え、「（1」に関する部分はまったくエラーのようです。



実際、ここでのシリアル番号は「abcd12（3）d（1」であり、コンマの後に読み取り不可能なGS記号があります。）そして重要なのは、シリアル番号を13文字にする必要があるということではありません（正式にはGS1DataMatrixのシリアルの長さが異なる場合があるため） 、およびタイヤでは、たとえば、20文字にすることができます）ポイントは正確に見えないところにあります考慮しなければならないGSは、どの会計システムのフィールドにも表示されませんが、入力は受け付けられず、通常は禁止されています（また、通常のメモ帳にも表示されず、表示されません。メモ帳++が必要です）。



このような特殊文字の存在は、バーコードデータの送信と保存に制限を課します。たとえば、Base64でスクリーニングまたはエンコードする必要があります。



ところで：文字列などのバーコードを保存および送信するための標準（ISO / IEC 15424-2018）がありますが、何らかの理由で誰もそれを使用していません。文字列として保存されるGS1DataMatrixバーコードデータは、「] d2」で始まる必要があります。



今ではほとんどの人がバーコード印刷コンポーネントを修正しています（おそらく）。しかし、とにかく誰が標準を読んでいますか？



検証のために、宿題：フィールドが固定長の場合はGSを挿入する必要はありませんが、長さが可変でフィールドの値が最大長でない場合は挿入する必要があるというトピックがあります。実際、これはこのルールが機能する方法ではありません。AIがこのテーブルの1桁の数字で始まる場合にのみ、特殊文字GSは挿入されません





。それ以外の場合はすべて挿入されます。バーコードの生成/解析コードは同じように機能しますか？



もう1つの問題は、「キーボードウェッジのスキャナー」などのラマーツールを使用したバーコードマーキングのスキャンです。ラベルを付ける前の最大の問題は、余分なゼロがどこかにカットまたは挿入されていることでした。新しいコードの導入により、スキャンされたlulzマーキングはまったく新しいレベルになります。



多くの場合、これらはスキャナー自体やその設定の問題ではなく、経験不足の問題であり、バーコードの原則を理解しています。



たとえば、スキャナーを「キーボードウェッジに」接続する場合（またはこのモードをエミュレートする場合）、およびスキャナーをHIDデバイスとして接続する場合、スキャンしたバーコードの一部の文字を他の文字に置き換えたり、特定の文字が消えたりする問題が発生する可能性があります。





スキャナーをキーボードブレークに接続するスキーム



指定されたモードで動作している場合、スキャナーはバーコードからの文字をコンピューターに送信しません（原文のまま！）が、キーボードでこのバーコードから文字を入力するために押す必要があるキーボードのキーストロークのコードを送信します。



同時に、レイアウト言語とモディファイアキー（Shift、Caps Lock、Alt、Ctrl）を押すことによって、複数の可能な文字が一度に1つのキーボードキーに対応する可能性があることは明らかです。



たとえば、キーボードの右下部分でこのキーを押すと、







結果は、選択したレイアウトと修飾子キーの使用に応じて、「？」、「/」、「、」、または「。」のいずれかの文字になります。入力される特定の文字は、スキャナーではなく、オペレーティングシステムのキーボード設定によって決まります。



このため、一部のシリアルではなく、まったく異なるシリアルがチェックアウト時にドロップアウトするか、コードがまったく見つかりません。



ちなみに、シリアルに小切手合計があり、最後の桁を使用してコードが正しいかどうか、コードが正しく読み取られたか入力されたかどうかを確認できれば、これらの問題は回避できたはずです。現在のアカウント、TIN、カード番号、EAN13の場合、最後の桁は確認のためのチェック金額であるため、人や車が入力時に間違いを犯すことはありません。







明らかに、ここで彼らはDataMatrixが自己チェックしていることを望んでいました、そしてクリプトテールがあります。しかし、1つはバーコード全体、セルフチェック、もう1つはシリアル付きのコードで、キーボードから入力できた可能性があります。



ITスペシャリストの個別の論争は、いわゆる「クリプトテール」によって引き起こされました。



「クリプトテール」はマーキングバーコードの必要な部分です。これにより、対称キーを使用して、アイテムのシリアル番号が指から吸い出されていないことを確認できます。







クリプトテールはバーコードのみにあり、マーキングデータベースには保存されないため、ハッカーがベースを壊して他の人のバーコードを印刷することはできません。



それら。これは一種のデジタル署名です。しかしそれ以来バーコードはゴムではありませんが、商品が多く、このデジタル署名の長さが短いため、誰でも利用できる暗号化キーを使用できません。



もちろん、すべてのシリアル番号はマーキングデータベースにありますが、オンラインで確認すると、インターネットに障害が発生すると、すべての倉庫と店舗がすぐに立ち上がるようになります。



Cryptotailはこの問題を解決することを目的としていますが、これまでのところ（2020年の夏）、完全に機能し始めていません。



事実、暗号化はロシア語であり、ハードウェアに関連付けられています。しかし、ロシアの陰謀に代わるものはまだありません。ロシアの国家システムは外国の陰謀を使用できません。それは穴になります。したがって、あなたはロシアのものに耐えなければならないでしょう、それは合理的で難しくありません。

一般的に、暗号化は非常に複雑なトピックです。多くの情報があり、特定の場合にデータに署名または暗号化する方法の説明を見つけることは非常に困難です。

ラベリングAPIと統合しようとしたすべての人がこれに直面しました。 「ログインしてみませんか？」「サインの仕方」「例を共有してください！」「サインは出ましたが拒否されたのはなぜですか？」などの質問がたくさんありました。と他の多く。



多くの場合、間違いは当たり前のことでした。たとえば、署名後にデータが変更されたり、スペースやなんらかの意味のない文字が失われたりしましたが、これは署名にとって重要であり、APIに送信した後、説明なしで拒否が受信されました。署名は検証されていません。



幸いなことに、チャットでは、彼らはほとんどの場合、そのような質問を助け、答えました。一般に、これらの問題はすべて、2020年7月1日までに処理されているか、すでに解決されています。

“ ” 1 2020 - , , . , .

Cleveranceでは、ソフトウェアの問題は主な問題ではないと考えています。さらに悪いことに、商品の流通の参加者はまだ変更の本質を理解していません。これは、ソフトウェアのバグよりもはるかに大きな問題です。



人々は、ラベリングを、1C / SAP / NAV / DAXのコンピューターに座って編集したり、修正したり、遡及的に変更したりできる別の会計レポートとして扱います。このタイプは会計士とロジスティクスによって使用され、ITスペシャリストはこれに必要なモジュールと処理を「カット」する必要があります。



クライアントの主な要求は、倉庫/中国語/ tetyamashaが何かをスキャンし、それを1C / SAP / NAV / DAXに「正しく」ロードすることです。そして、私たちはそれを成功させています。



しかし、これは明らかな間違いであり、企業がお互いのバランスを取り始め、州が元気になり始めたときに明らかになります。

実際のマーキングシステムは何ですか

製品ラベリングは、実際の動きを反映するためのシステムです。

実際のラベリングの問題

これは純粋に私たちの私見です。



オートマトンの実際の問題はすべて、マーキングシステムの実際の目的、つまり実際の動きを反映するシステムから発生します。



まず、動きの実際の会計処理は、すべてがSKU、バッチ、または平均によって会計処理される場合、チェーン全体を会計処理する現在の原則と矛盾します。振り返ってみると、削減して修正することが私たちのすべてです。



どの企業の会計システムも、100,500回の電話、修正、再投稿、エラーのクリーンアップの後にすべてがどれほど素晴らしいものになったのかについて、まとめて修正したおとぎ話です。



外国の大手医薬品販売業者での延長会議の1つで、1時間の話し合いの後、主任ロジスティクス担当者はついに目を転がし、「パックごとに異なるバーコードですか？」と言いました。そして、「ユニーク」、「シリアル番号」、「各コピー」、「すべてをスキャン」などの言葉が飛んできたようです。



第二に、実際の動きの説明は、現在の商慣行や懸念の分離の原則に反しています。



会社が大きく、従業員が一部のドキュメントを編集する権利を持っていない場合でも、電話番号がありますが、修正できる人に電話または手紙を書くことができます。



または、たとえば、ドキュメントは、草の根の従業員によってディレクターのCEPによって署名され、2要素認証がある場合は、SMSを介して署名されます。ラベリングシステムにはユーザーとその権利に関するブロックがあり、すべての人に個別のCEPを与えることができますが、人々はこれを急いで行う必要はありません。



これは明らかな問題であり、ラベル付けされた製品のすぐ隣にいる一般の従業員にますます多くの権利と会計ツールを提供することによって解決されます。



さらに、コスト価格の計算や会計システムの動きの会計処理のルールは、FIFO / LIFOや平均価格などの平均化と簡略化に基づいています。そして、生産から小売りまで何十年にもわたってどこでも適用されてきたこれらの会計原則は、これらの単純化に基づいており、ユニークなユニットの実際の追跡可能性に反しています。



このため、実際には、たとえば、商品はFIFO / LIFOによってマーキングシステムに送信されますが、実際に出荷されたのは出口に近いものです。



これは、仕事の性質上、コンピューターの前に座ることができない一般の従業員向けの特別な機器やソフトウェアによっても解決されます。



もう1つの問題は、「地球上でフクロウを引っ張る」試みと、すべての標準ERPドキュメントにマーキングコードを挿入して、会計士、ロジスティクス担当者、または責任あるマネージャーがそこでそれらを確認できるようにすることです。



彼はそれらを見るものは何もありませんが、それらを使って何もすることはできません。



確かに、会計士またはマネージャーとして、モニターを見ると、昨日そこの倉庫をスキャンしたこと、そして何千ものタバコのうち3つに赤で強調表示された不一致があるのはなぜでしょうか。



これは、必要なすべての情報にアクセスできる草の根の担当者向けのツールによっても解決されます。

まあそれは これらは一部のシステムの技術的な問題ではなく、一般に2020年7月1日までにすでに修正されていますが、新しいレールでの企業の作業を再構築する問題です。

結論

ラベリングの主な利点は、州がすべての人にデジタル署名と暗号化を使用したEDFへのデジタル化と切り替えを強制したことです。



「潮流はすべての船を引き上げます」、そして市場全体の共通のレールへの移行は大きな相乗効果をもたらします。



みんなハッピーオートメーション！