DataMatrix או כיצד לתייג נכון נעליים

החל מ-1 ביולי 2019, הוכנס ברוסיה תיוג חובה של קבוצת מוצרים. החל מה-1 במרץ 2020, נעליים היו אמורות להיות תחת החוק הזה. לא לכולם היה זמן להתכונן, ובשל כך ההשקה נדחתה ל-1 ביולי. למודה הוא בין אלה שהכינו אותו.

לכן, אנו רוצים לחלוק את הניסיון שלנו עם מי שטרם הספיק לסמן בגדים, צמיגים, בשמים וכו'. המאמר מתאר מספר תקנים בתעשייה, כמה תיעוד רגולטורי וניסיון אישי. המאמר מיועד בעיקר לאינטגרטורים ומפתחים שעדיין לא הבינו את הפרויקט הזה.

שימו לב שהתקנות משתנות בתדירות גבוהה ולא ניתן למחבר לעדכן כל הזמן את החומר. לכן, בזמן שתקראו אותו, ייתכן שחלק מהמידע כבר לא מעודכן.

המחבר צבר ניסיון אישי הן כחלק מהעבודה על פרויקט Datamatrix בלמודה, והן בעת ​​פיתוח אפליקציית התיוג החינמית שלו BarCodesFx.

מאז 1 ביולי 2019, חוק על תיוג חובה בתוקף ברוסיה. החוק אינו חל על כל קבוצות הסחורות, ומועדי כניסתו לתוקף של סימון חובה לקבוצות מוצרים משתנים. נכון לעכשיו, טבק, מעילי פרווה, נעליים ותרופות כפופים לתיוג חובה. יוצג בקרוב עבור צמיגים, ביגוד, בשמים ואופניים. כל קבוצת סחורות מוסדרת על ידי החלטה ממשלתית נפרדת (GPR). לכן, ייתכן שהצהרות שנכונות לגבי נעליים אינן נכונות לגבי קבוצות מוצרים אחרות. אבל אנחנו יכולים לקוות שהמרכיב הטכני לא ישתנה מאוד עבור קבוצות מוצרים שונות.

סימוןהרעיון העיקרי של תיוג הוא שלכל יחידת סחורה מוקצה מספר אישי. באמצעות מספר זה ניתן לעקוב אחר ההיסטוריה של פריט סחורה ספציפי מרגע הייצור או הייבוא ​​לארץ, ועד לרגע ההשלכה בקופה. זה נשמע יפה, אבל בפועל זה מאוד קשה ליישום.המושג מתואר ביתר פירוט באתר הרשמי של השלט הישר.

מונחים ומושגים נפוצים

UOT - משתתף במחזור הסחורות.
CRPT - מרכז לפיתוח טכנולוגיות מבטיחות. חברה פרטית, המדינה היחידה קבלן לפרויקט הסימון. היא פועלת תחת תכנית שותפות פרטית ציבורית (PPP). לצערנו, אין מידע על משתתפים נוספים במכרז לפרויקט וכן על המכרז עצמו.
TG - קבוצת מוצרים. נעליים, ביגוד, צמיגים וכו'.
GTIN - בעצם, מאמר המתחשב בצבע ובגודל. מונפק ב-GS1 או בקטלוג הארצי לכל יבואן או יצרן למוצר שלו. על היצרן או היבואן לתאר תחילה את המוצר.
PPR - צו של ממשלת הפדרציה הרוסית. לנעליים - 860.
KM - קוד סימון. קבוצה ייחודית של תווים שהוקצו לפריט מוצר ספציפי. עבור נעליים, הוא מורכב מ-GTIN, מספר סידורי, קוד אימות וזנב קריפטו.
GS1 הוא ארגון בינלאומי המנפיק מספרי GTIN. הם גם המהדרים של מספר תקני תיוג.
קטלוג לאומי - אנלוגי של GS1, שפותח על ידי CRPT.
זנב קריפטו - אנלוגי של חתימה דיגיטלית המאשרת את חוקיות ה-CM. חייב להיות במטריצת הנתונים על החותמת. אחסון בצורת טקסט אסור. לאחר ההדפסה יש להסיר את החותמות בהתאם להסכם עם ה-CRPT. לא ידוע על מקרים של שימוש בפועל.
CPS - תחנת ניהול הזמנות. המערכת שבה מזמינים KMs לסחורות.
EDI - ניהול מסמכים אלקטרוניים.
UKEP - חתימה אלקטרונית מוסמכת משופרת.

מונחים ומושגים במסגרת מאמר זה

ЧЗ - סימן כנה.
ЛК - אזור אישי.
לסמן - קוד סימון מודפס.

התהליך הוא כדלקמן: ראשית, המשתתף (UOT) מנפיק חתימה אלקטרונית (UKEP), נרשם בסימן כנה (CH), מתאר את המוצר בקטלוג הלאומי או GS1, ומקבל GTIN עבור המוצר. שלבים אלה מתוארים בפירוט באתר שלט הושר, כך שלא נתעכב עליהם.

הזמנה וקבלה של קודים

לאחר קבלת GTIN, המשתתף (UOT) מבצע הזמנה של קודים (KM) במערכת ה-CPS.
חשוב, אבל לא מובן מאליו.

1. אתה יכול לבקש קודים עבור עד 10 מספרי GTIN בהזמנה אחת. באופן עקרוני, מגבלה בלתי מובנת. יבואן עם 14 GTIN צריך ליצור 000 הזמנות.
2. ניתן לבקש לכל היותר 150 קודים לכל הזמנה.
3. יש מגבלה של 100 הזמנות בתהליך. כלומר, לא ניתן לעבד יותר מ-100 הזמנות בו-זמנית. אם יש יותר מ-100, ה-API יתחיל להחזיר שגיאה במקום רשימה של הזמנות. הדרך היחידה לתקן שגיאה זו היא לסגור כמה הזמנות דרך ממשק האינטרנט. ה-API אינו מספק פרמטר לתצוגה חלקית של הזמנות.
4. יש הגבלה על מספר הבקשות - לא יותר מ-10 בקשות בשנייה. לפי המידע שלי, הגבלה זו אינה מופיעה במסמכים, אך היא קיימת.

מניסיון אישי בעבודה עם הזמנות של קודי סימון KM דרך ה-API של מערכת CPS.

1. יש לחתום על הבקשה (ה-json עצמו) בחתימת GOST. זה עובד עם קריפטופרו. עליך לוודא בזהירות שהמסגרת או הספרייה שבה נעשה שימוש לא ישנו את ה-json המקורי אפילו על ידי בייט. אחרת, החתימה תפסיק מיד להיות תקפה.
2. חתימת הזמנה. ניתן לחתום על ההזמנה בכל חתימה של כל לקוח. אם החתימה תקפה, מערכת CPS תקבל אותה. במהלך האינטגרציה, ניתן היה לחתום על הבקשה בחתימה של מישהו אחר שהונפקה ב-CA הבדיקה. מעגל הלחימה של מערכת הבקרה עיבד את הפקודה והוציא קודים. לדעתי זה חור אבטחה. המפתחים הגיבו לדוח הבאג ב"נראה". אני מקווה שזה תוקן.

   לכן, היזהר מאוד אם יותר מישות משפטית אחת עובדת במקום עבודה אחד. פרצופים. היום CPS יקבל את הבקשות הללו, ומחר הבקשות ייבדקו מחדש ומחצית מהקודים יבוטלו עקב חתימה של מישהו אחר. ובאופן עקרוני, פורמלית הם יהיו צודקים.

3. חתימה אוטומטית של הזמנות היא פונקציונליות שאינה זמינה עוד ב-KMS. כדי שזה יעבוד, היה צורך להעלות את החלק הפרטי של המפתח בחשבון האישי של השלט הישר. זוהי פשרה של המפתח. ולפי החקיקה הנוכחית, במקרה של פשרה של חתימה אלקטרונית מוסמכת משופרת, הבעלים חייב ליידע את מרכז האישורים שלו (CA) ולבטל את ה-ECEP. אם הפונקציונליות הזו מוחזרת, היזהר לוודא שהחלק הפרטי של המפתח לא יוצא מהמחשב.
4. בפברואר, המרכז לפיתוח טכנולוגיות מתקדמות (CRPT) הציג בשקט הגבלה על מספר הבקשות ל-CPS API. לא יותר מבקשה אחת בשנייה. ואז, באותה מידה בלתי צפויה ושקטה, הוא הסיר את ההגבלה הזו. לכן, אני ממליץ שהמערכת תהיה מובנית ביכולת להגביל את מספר הבקשות ל-CRPT API במקרה של הישנות. כעת יש מידע על מגבלה של 10 בקשות לשנייה.
5. כמו כן בפברואר, התנהגות ה-API של CPS השתנתה באופן משמעותי ללא אזהרה. ל-API יש בקשה לקבל את סטטוס ההזמנות. הסטטוס הצביע על המאגרים ומעמדם. GTIN אחד = מאגר אחד. זה גם ציין כמה קודים זמינים לקבל מהמאגר. יום בהיר אחד, מספר כל המאגרים הפך ל-1. הייתי צריך להשתמש בשיטה נפרדת כדי לשאול את המצב של כל מאגר בנפרד. במקום בקשה אחת, הייתי צריך להגיש אחת עשרה.

מבנה קוד

אז, הקודים הוזמנו ונוצרו. ניתן להשיגם דרך ה-API בצורת טקסט, ב-pdf כתוויות להדפסה וכקובץ csv עם טקסט.

ה-API כבר נכתב למעלה. לגבי שתי השיטות האחרות. בתחילה, מערכת הבקרה אפשרה לך לאסוף קודים פעם אחת בלבד. ואם נלקח קובץ pdf, אז ניתן היה להשיג את הקודים בצורת טקסט רק על ידי סריקה מחדש של כל מטריצות הנתונים מה-pdf. למרבה המזל, הם הוסיפו את היכולת לאסוף קודים מספר פעמים, והבעיה הזו נפתרה. הקודים עדיין זמינים להורדה מחדש תוך יומיים.

אם אתה לוקח אותו בפורמט csv, אז לעולם, בשום פנים ואופן, לא תפתח אותו באקסל. ואל תתן לאף אחד. לאקסל יש תכונת שמירה אוטומטית. בזמן השמירה, Excel יכול לשנות את הקודים שלך בדרכים הכי לא צפויות. אני ממליץ להשתמש ב-notepad++ כדי להציג את הקודים.

אם אתה פותח קובץ מה-CMS ב-notepad++, אתה יכול לראות שורות כאלה. הקוד השלישי אינו חוקי (אין לו תוחמי GS).

השותפים שלנו נתנו לנו קודים לתיוג המוצרים שלהם. בעין בלתי מזוינת ניתן לראות אילו קבצים נוצרו באמצעות אקסל - עד 5% מהקודים היו לא חוקיים.

אני ממליץ בחום לקרוא על תקנים GS1. תיאור התקן מכיל תשובות לשאלות רבות הנוגעות להיווצרות DataMatrix.

קוד הזיהוי מורכב מ-GTIN ומספר סידורי. לפי תקן GS1, אלה תואמים למזהי יישומים (AI) 01 ו-21. שים לב שמזהי יישומים אינם חלק מה-GTIN ומהמספר הסידורי. הם מציינים שמזהה האפליקציה (UI) מלווה ב-GTIN או מספר סידורי. זה חשוב במיוחד בעת תכנות תוכנת קופה רושמת. כדי למלא תג 1162, אתה צריך רק את ה-GTIN והמספר הסידורי, ללא מזהי אפליקציה.

עבור UTD (מסמך העברה אוניברסלי) ומסמכים אחרים, להיפך, לרוב אתה צריך את כל הרשומה עם מזהי יישומים.

תקן GS1 קובע של-GTIN יש אורך קבוע של 14 תווים והוא יכול להכיל רק מספרים. למספר הסידורי יש אורך משתנה והוא מתואר בעמוד 155 של התקן. יש גם קישור לטבלה עם סמלים שעשויים להופיע במספר הסידורי.

מכיוון שלמספר הסידורי יש אורך משתנה, מפריד ה-GS מציין את סוף המספר הסידורי. בטבלת ASCII יש לו קוד 29. ללא מפריד זה, אף תוכנית לא תבין באיזה שלב הסתיים המספר הסידורי והחלו קבוצות נתונים אחרות.

פרטים נוספים על קוד הסימון (KM) ניתן למצוא ב תיעוד רשמי.

עבור נעליים, המספר הסידורי קבוע ל-13 תווים, עם זאת, ניתן לשנות את גודלו בכל עת. עבור קבוצות מוצרים אחרות (TG), אורך המספר הסידורי עשוי להיות שונה.

יצירת DataMatrix

השלב הבא הוא להמיר את הנתונים לקוד DataMatrix. צו ממשלת רוסיה 860 מציין GOST, לפיו יש צורך ליצור DataMatrix. כמו כן, PPR 860 מפרט את השימוש החובה במזהי יישומים. שימו לב שלתקן DataMatrix אין את המושג "מזהי אפליקציה". הם זמינים רק בתקן GS-1 DataMatrix. מסתבר ש-PPR 860 מחייב באופן מרומז את השימוש ב-GS-1 DataMatrix. למרבה המזל, הסטנדרטים דומים. ההבדל העיקרי: ב-GS-1 DataMatrix, התו הראשון חייב להיות FNC1. סמל ה-GS לא אמור להופיע ראשון ב-DataMatrix, רק FNC1.

FNC1 לא יכול להיות פשוט להוסיף לקו כמו GS. יש להוסיף אותו על ידי התוכנית המפיקה את ה-DataMatrix. יש כמה פוסטים על משאבי Alliance Forts אפליקציות ניידות, שבאמצעותו תוכל לבדוק את נכונות קודי ה-DataMatrix שנוצרו.

זה חשוב. אפליקציית ה-Host Sign מקבלת DataMatrix לא חוקי. אפילו קודי QR. העובדה שהמותג הוכר והוצג מידע על המוצר אינה מעידה על כך שה-DataMatrix נוצר כהלכה. גם כאשר הזנב הקריפטו הוחלף, אפליקציית ChZ זיהתה את המותג והציגה נתונים על המוצר.

מאוחר יותר שוחרר ChZ הֶסבֵּר, כיצד ליצור קודים בצורה נכונה. בשל המספר הגדול של קודים עם שגיאות, הם זיהו קודים ללא FNC1 כתקפים, אך עדיין ממליצים ליצור GS-1 DataMatrix.

למרבה הצער, אחוז גדול למדי ממטריצות נתונים משותפים הגיעו עם שגיאות. הודות להסברים של ChZ, השאלה "האם אפשר לסחור במוצר כזה אחרי 1 ביולי או לא?" נפתרה לחלוטין. ספוילר - אתה יכול.

הדפסה

שימו לב לאופן הדפסת הבולים. בהדפסה במדפסת תרמית, החותמת דוהה במהירות ולא ניתן יותר למכור את המוצר. חותמת בלתי ניתנת לקריאה היא הפרה של PPR 860. הדבר מוביל לתפיסת סחורות, קנסות ואחריות פלילית.

השתמש בהדפסת העברה תרמית. במקרה זה, המותג אינו כל כך רגיש לדהייה. חומר התווית גם קובע עד כמה המותג רגיש לנזק מכני. אם לא ניתן לקרוא את הקוד עקב נזק מכני, זה בגדר היעדר מותג עם כל ההשלכות הנובעות מכך.

בחר מדפסת מתוך נפחי ההדפסה המתוכננים שלך. מדפסות שולחניות אינן מיועדות להדפיס 100 תוויות ביום.

עצירה והתחלת הדפסה מגבירה את הבלאי במדפסת. תוכניות מסוימות שולחות עבודת הדפסה אחת בכל פעם. עדיף לא להשתמש בתוכנות כאלה.

עבודה עם מסמכים

לאחר הדפסת והדבקת הבולים, כל העסקאות הנוספות איתם מתבצעות באמצעות מסמכים או החשבון האישי של השלט הישר.

בעבודה עם מספר רב של קודים, ניתן ליצור קבצי xml המכילים את הקודים הנדרשים ולהעלות קבצים אלו דרך ה-API או ממשק האינטרנט של החשבון האישי שלכם.

ניתן להוריד את ערכת ה-XSD בקטע "עזרה" של ChZ LC.

שימו לב לנקודות הבאות.

1. סכימות Xsd ב-LC ChZ מכילות שגיאות באימות TIN והגבלות על אורך השורה. רק לאחר תיקון שגיאות אתה יכול להשתמש בתרשימים. למרבה המזל, הטעויות ברורות, אז זה לא קשה לעשות.
2. הסכימה מורכבת לרוב משני חלקים - משותף לכל סוגי המסמכים ונפרד לסוג מסוים. הסכימה הכללית מתווספת באמצעות ייבוא ​​לסכימה הספציפית. שני הדיאגרמות מתפרסמות בחלק העזרה של ChZ LC.
3. כללי הבריחה עבור CM שונים מאלה המקובלים בדרך כלל עבור XML, זה כתוב בתיעוד הרשמי של ChZ, שימו לב לכך. כאן כאן כל הכללים נמצאים בעמוד 4.
4. אל תנסה להכניס 150 קודים למחזור בקובץ אחד. לפי עדי ראייה, בדרך כלל עוברים תיקים של יותר מ-000.
5. ניתן לעטוף קובץ Xml עם השגיאה "שגיאת אימות XML", וחמש דקות לאחר מכן ניתן לקבל את אותו קובץ ללא בעיות.
6. אם הקובץ מכיל קוד שכבר הוכנס למחזור, סביר להניח שקובץ ההוצאה למחזור לא יתקבל.
7. משלוח וקבלת מסמכים משמשים כפתרון זמני. בעתיד הם מתכננים לבטל אותם ולעבור ל-UPD בהתאם ל-PPR 860.
8. המיתוס על 60 יום. יש דעה שקודים שלא מועברים למחזור "שורפים" לאחר 60 יום. זהו מיתוס, מקור לא ידוע. תוקף הקודים פג רק אם לא אספת אותם ממערכת הבקרה תוך 60 יום. תוחלת החיים של קודים שנאספו היא בלתי מוגבלת.

מסקנה

בעת פיתוח אפליקציית התוויות החינמית שלי BarCodesFX, נעשתה בתחילה אינטגרציה עם ה-API של CPS. כאשר סימן כנה שינה באופן בלתי צפוי את ההיגיון של ה-API בפעם השנייה, היה צורך לנטוש את האינטגרציה. אני מקווה שבעתיד ChZ יוכל לייצב את הפיתוח ואת ה-API, כי עבור מוצר לא מסחרי, מאוד יקר לי לבדוק כל יום שוב האם חלו שינויים ב-API ולשפר אותו מיידית.

בעת הטמעת סימונים, קרא בעיון את התיעוד הרגולטורי עבור קבוצת המוצרים של TG שלך, הדפיס את GS1-DataMatrix בצורה נכונה והיה מוכן לכל שינוי בלתי צפוי מצד סימן ChZ הוגן.

ה-Fort Alliance יצרה מרחב מידע (ויקי, חדרי צ'אט בטלגרם, סמינרים, סמינרים מקוונים), שם תוכל למצוא מידע שימושי ורלוונטי על תיוג בכל הענפים.

מקור: www.habr.com