הגדרת יחידות מידה ב-Bitrix: היכן החשבונאות נשברת
יחידות מידה ב-Bitrix קיימות בשלושה מקומות בלתי תלויים: מדריך הקטלוג, סל הקניות וההזמנה, והחלפה עם 1С. כל עוד הערכים תואמים, אין סטיות נראות לעין.
ברגע שבקטלוג מופיע "ק"ג" עם מקדם, ובאותה עת ב-1С אותו מוצר מיוצא ב"ג", ההזמנה יוצאת עם כמות 0.5 במקום 500 — ומשם זה נמשך דרך החשבונית, המשלוח ומסמכי הסגירה.
הסיבה הנפוצה ביותר לתקלות היא עיגול הכמות. בהגדרות הקטלוג נקבעת רמת הדיוק, והיא אינה תואמת את רמת הדיוק ש-1С מצפה לה בעת הייצוא. פריט עם כמות עשרונית או מעוגל לשלם ומאבד את השארית, או יוצא עם ספרות מיותרות ושובר את התאמת הפריטים.
מקור שני — אי-התאמה של קודי ОКЕИ: מדריך היחידות ב-Bitrix והמסווג ב-1С ממולאים ידנית וסוטים לפי הקוד, ולא לפי השם.
תקלה שלישית — היחידות בהזמנה ובקטלוג נפרדו לאחר עריכת הכרטיס. הזמנות שכבר בוצעו שומרות על הערך שלהן, חדשות לוקחות את העדכני, ובדוחות אותו פריט נספר באופן שונה. זוהי שגיאת חשבונאות שמבחינים בה לא ברגע היווצרותה, אלא בהתאמה — כאשר הסטייה כבר הצטברה.
הרביעית — 54-ФЗ: הקבלה נוצרת לפי היחידה מההזמנה, ואם היא אינה תואמת לזו שיוצאת ל-1С, הפריט בקבלה ובחשבונאות סוטה. אנו מנתחים כיצד הגדרת יחידות מידה ב-Bitrix נסגרת ברמת המדריך, העיגול וכללי הייצוא ל-1С, כך שהחשבונאות תתאם ללא תיקונים ידניים.
מה נותן מדריך יחידות מידה אחיד
יחידות מידה ב-Битрикс קיימות בשני מקומות: מדריך בקטלוג ומדריך ב-1С. כל עוד הם אינם מקושרים, כל פריט נומנקלטורה חדש דורש השוואה ידנית — המנהל בוחר קוד מהרשימה, בעוד הייצוא ממערכת החשבונאות מביא ערך משלו.
אי-ההתאמה צפה לא מיד: הסחורה נמכרת, היתרה נמחקת, ורק בעת השוואת יתרות במחסן מתברר ש«упак.» ו«упаковка» הם שני רשומות שונות על אותה סחורה.
מדריך יחידות מידה אחיד מסיר סוג שגיאות זה ברמת הנתונים. אנו מביאים את הקודים לקטגוריה הכל-רוסית, משווים את רשומות הקטלוג ו-1С פעם אחת ומקבעים את ההתאמה בהגדרות ההחלפה — מכאן הסנכרון עובר ללא מעורבות ידנית. נומנקלטורה חדשה מגיעה עם יחידה כבר מלאה, ולא עם שדה ריק שמישהו צריך לסגור.
מה זה משנה במספרים. תיקונים ידניים ביחידות מידה יוצאים מהעבודה היומיומית של המנהלים — חלקם יורד למקרים בודדים, כאשר באמת מופיעה יחידה חדשה. יתרות הסחורות מפסיקות «להיכפל»: המחיקה והקבלה עוברות לפי רשומה אחת, ולכן המלאי בפועל במחסן תואם את הנתונים במערכת. דיוק ההזמנות עולה בזכות כך שהכמות במסמך ובקבלה נספרת מאותה יחידה.
אפקט נפרד — קבלות תקינות. ציוד קופה לפי 54-ФЗ מדפיס את השם ואת מידת הכמות מהמדריך, ואם קוד היחידה אינו מותאם, לקבלה יוצא ערך ברירת מחדל. לאחר סידור המדריך, מידת המידה בקבלה תואמת לזו המצוינת בכרטיס הסחורה, ואי-התאמות בבדיקה אינן מתעוררות.
ההגדרה אורכת פחות זמן מהשוואת היתרות שלאחר מכן: העבודה העיקרית — התאמה חד-פעמית של קודים ובדיקת ההחלפה על ייצוא בדיקה. מכאן מדריך יחידות המידה מתחזק את עצמו, והתיקונים הידניים מצטמצמים להשלמת הקטגוריה בפריטים חדשים.
מקדמי המרה ודיוק הכמות
היחידה הבסיסית היא זו שבה המערכת שומרת את היתרה במלאי. יחידת המסחר היא זו שבה המוצר נמכר ונכנס למסמכים: אריזה, קרטון, משטח. ביניהן מוגדר מקדם המרה, וכאן בדיוק לרוב אובד הדיוק.
אם היחידה הבסיסית היא יחידה בודדת, והיחידה המסחרית היא אריזה של 12 יחידות, המקדם חייב להיות שלם. ברגע שמופיע שבר (בסיסית — קילוגרם, מסחרית — אריזה של 0,435 ק"ג), מתחילה הצטברות של שגיאת עיגול.
המלאי מחשב את היתרה ביחידות בסיסיות, המסמכים — ביחידות מסחריות, ובכל המרה הלוך ושוב המערכת מעגלת לפי דיוק הכמות שהוגדר. לאחר מאה פעולות הפער בין מרשם היתרות לבין המלאי בפועל הופך למורגש, וספירת מלאי הופכת לחקירת סיבות.
1С ו-Bitrix שומרים את הכמות ברזולוציה שונה: בהחלפה דרך CommerceML הערך נשלח עם מספר הספרות שהוגדר בייצוא. אם הדיוק בקטלוג ובמערכת החשבונאית אינו תואם, בעת הסנכרון הכמות "מתפצלת" — 0,999 במקום 1, והפריט יורד למינוס כשהיתרה formally חיובית.
כלל מעשי: מקדם ההמרה נעשה שלם בכל מקום שבו הדבר אפשרי, ודיוק הכמות מוגדר זהה בכל המעגלים — בכרטיס המוצר, בהגדרות ההחלפה ובמערכת החשבונאית. עבור מוצר נשקל, היחידה הבסיסית נלקחת כגרם ולא כקילוגרם: אז שברים בהמרה אינם נוצרים כלל.
דרכים לניהול יחידות מידה: השוואת גישות
ניתן לנהל יחידות מידה ב-Bitrix בארבע דרכים, והבחירה משפיעה על האופן שבו יתנהגו הייצוא ל-1С, הקבלות והדוחות. להלן השוואה לפי הקריטריונים המרכזיים עבור הלקוח: מתי הגישה מתאימה והיכן היא מתחילה להפריע.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ספר עזר אחיד של ОКЕИ לכל האתרים | קטלוג אחד, נומנקלטורה משותפת, ייצוא ל-1С יוצא ממקום אחד | כל שינוי בקוד יחידה משפיע על כל האתרים בבת אחת — נדרשת בדיקת רגרסיה על קבלות והחלפת נתונים |
| ספרי עזר נפרדים לפי אתרים | ריבוי אתרים עם שווקים שונים וקודים שונים של ОКЕИ לאותו מוצר | כפילות נתונים, חוסר סנכרון בעת החלפת נתונים, אנליטיקה מסכמת מורכבת יותר |
| הזנה ידנית בכרטיס | פריטים חד-פעמיים, שירותים, יחידות לא סטנדרטיות | שגיאות הקלדה וכתיבים שונים של אותה יחידה שוברים דוחות וייצוא |
| מקור חיצוני (1С כמאסטר) | 1С היא מערכת החשבונאות, האתר הוא רק חלון ראווה | האתר תלוי בזמינות החלפת הנתונים; בעת תקלה יחידות חדשות לא מופיעות |
ההבדל מתגלה בנקודות החיבור: ב-1С היחידה נשמרת לפי מסווג, בקבלה עבור 54-ФЗ נדרשים קוד נכון ומקדם המרה, ובאתר — שם מובן ללקוח. אם ספרי העזר לפי אתרים אינם תואמים, אותו מוצר עובר למערכת החשבונאות עם קודים שונים, וההחלפה מתחילה להתלונן על אי-התאמה של נומנקלטורה.
אנו בדרך כלל ממליצים על ספר עזר אחיד של ОКЕИ כמקור מאסטר, ואת ההבדלים בין האתרים לסגור באמצעות קישור להצעות מסחריות, ולא באמצעות ספר עזר שני. כך ריבוי האתרים לא הופך למציאות חשבונאית נפרדת, והייצוא והקבלות נשארים צפויים.
סדר היישום: מביקורת ועד מסירה
את העבודה מתחילים בביקורת: מייצאים את כל ערכי יחידות המידה שכבר הצטברו בקטלוג, בהזמנות, במלאי המחסן ובמסמכים. בשלב זה רואים היכן הקטלוג סטה ממערכת החשבונאות — כפילויות של "יח'" ו"יחידה", פריטים ללא קוד ОКЕИ, יחידות שאינן קיימות במסווג.
לאחר מכן מתכננים את הקטלוג היעד: משווים כל פריט לקוד ОКЕИ, קובעים עבור אילו יחידות נדרשת אריזה חלקית ועבור אילו — ערכים שלמים בלבד.
- ביקורת הקטלוג. מאחדים את היחידות מהקטלוג, מההזמנות, מהמחסן וממערכת החשבונאות לטבלת התאמות אחת, מתעדים אי-התאמות וכפילויות.
- תכנון הקטלוג. מאשרים את רשימת היחידות עם קודי ОКЕИ, כללי העיגול והדיוק המותר עבור פריטים נשקלים ונפחיים.
- הגדרת הסנכרון. מגדירים את התאמת היחידות בין האתר למערכת החשבונאות, כך שבעת ייצוא הפריטים וייצוא ההזמנות הערך לא יוחלף ולא יאבד.
- בדיקה על הזמנות אמיתיות. מריצים את ביצוע ההזמנה, התשלום והעברת ההזמנה לחשבונאות, כולל פריטים בכמות חלקית ומוצרים עם מספר יחידות.
- התאמה לדרישות הקבלות. בודקים שבלקבלה נשלחים שם ויחידה תקינים, ושחישוב הכמות תואם להזמנה.
- מסירת הנהלים. מוסרים את טבלת ההתאמות, הוראות להוספת יחידות חדשות וסדר הפעולות במקרה של אי-התאמות.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח: לאחר הביקורת — טבלת התאמות מאושרת, לאחר הגדרת הסנכרון — הזמנת בדיקה שעוברת את כל המסלול ללא תיקונים ידניים. סדר כזה מאפשר לשנות את הקטלוג באתר פעיל: הזמנות ישנות שומרות על ערכים היסטוריים, והחדשות מבוצעות כבר לפי הכללים המאושרים.
מה הלקוח מקבל לידיו לאחר ההגדרה
הגדרת יחידות המידה אינה מסתיימת ב"סימון וי בממשק הניהול", אלא בסט של תוצרים שלפיהם המערכת ממשיכה לפעול בלעדינו. כל סעיף להלן הוא מה שבאמת נשאר אצל הצוות שלכם: ניתן לפתוח אותו, לבדוק אותו ולהעביר אותו למהנדס חדש.
- ספר יחידות מלא — טבלה עם קודי ОКЕИ, סימונים לאומיים ומקדמים ליחידת הבסיס עבור כל פריט בקטלוג. בלי "יח'", "חב'", "סט" בערבוביה: פריט אחד — יחידת אחסון אחת, והשאר מנוהלים כאריזות עם מקדם מפורש.
- כללי המרה — לוגיקה קבועה של המרה בין יחידות אחסון, רכש ומכירה: היכן המקדם מוחל באופן מיידי, והיכן נשמר רשומה נפרדת. זה מסיר אי-התאמות כאשר הסחורה מגיעה בקרטונים ונמכרת ביחידות בודדות.
- הגדרות סנכרון — תצורת ייצוא הקטלוג והמסמכים בין האתר, מערכת הנה"ח ומערך הקופות: אילו שדות של יחידות יוצאים, באיזו צורה חוזרים, ומה קורה כאשר יש אי-התאמה בקודים.
- סכמת התאמה — מפה שבה רואים איזו יחידת אתר מקושרת לאיזו יחידת ניהול ואיך זה בא לידי ביטוי בקבלה בהתאם לדרישות 54-ФЗ. שימושי בעת הוספת קבוצות מוצרים חדשות.
- תיעוד — תיאור הספר, כללי ההמרה ונקודות הסנכרון בשפת הצוות שלכם: מה ניתן לשנות באופן עצמאי, ומה דורש תיקון בשילוב עם מערכת הנה"ח.
- נוהל תמיכה — סדר הפעולות בעת הוספת יחידה חדשה או שינוי מקדם: מי מאשר, באיזה סדר מתקנים את הספר, ואיך בודקים שההמרה לא השתבשה במסמכים שכבר נסגרו.
- פרוטוקול בדיקה — סט של פעולות בקרה: ייצוא לבדיקה, השוואת יתרות ביחידות שונות, הרצת קבלה. לפיו אתם מקבלים את העבודה וחוזרים על הבדיקה לאחר כל תיקון.
סט זה מספיק כדי שיחידות המידה יפסיקו להיות נקודה שבה האתר, המחסן והקופה אינם מתואמים. תארו את מערך המערכות שלכם — נחזור עם הערכה ותוכנית עבודה לספר ולסנכרון.
במה שונה יחידת אחסון מיחידת מכירה?
יחידת אחסון היא היחידה שבה הסחורה מאוחסנת במחסן ונרשמת ביתרות: קופסה, משטח, גליל, אריזה. יחידת מכירה היא היחידה שבה הלקוח רוכש אותה: יחידה, מטר, קילוגרם, מנה.
בקטלוג Битрикс מדובר בשני שדות שונים, ואסור לבלבל ביניהם: לפי יחידת האחסון המערכת מחשבת את המלאי, ולפי יחידת המכירה — את שורת ההזמנה ואת המסמך.
ההבדל מתגלה ברגע ביצוע ההזמנה. הלקוח מזמין 3 יחידות, ובמלאי רשומה קופסה אחת של 10 יחידות — ללא המרה היתרה תיגרע באופן שגוי, והסחורה או "תיתקע" או תיכנס למינוס. לכן בין יחידת המלאי ליחידת המסחר מוגדר מקדם המרה: הוא מקשר בין הכמות בהזמנה לכמות ביתרות ובמסמכי הקבלה.
ב-1С הקשר הזה מתקיים במדריך הפריטים: לפריט יש יחידת אחסון בסיסית ויחידה למכירות, וההמרה מתבצעת לפי המקדם. Битрикс מקבל את היתרות כבר ביחידת האחסון וממיר אותן ליחידת המסחר בעת ייצוא ההזמנה.
אם המקדמים בשתי המערכות לא יתאימו, היתרות יתחילו "לצוף": האתר יציג מלאי שאינו קיים, והסנכרון יתעד פער.
ההמרה לא נדרשת תמיד. כאשר הסחורה נמכרת ומאוחסנת באותה יחידה — יחידה מול יחידה — די בערך אחד, ושדות מיותרים רק מבלבלים את המנהלים. ההמרה מופעלת במקומות שבהם המחסן פועל באריזות, והלקוח קונה ביחידות בודדות: חומרי בניין, מטראז', משקל, נוזלים, סחורה בקופסאות ובמשטחים.
עבור 54-ФЗ חשובה יחידת המכירה: היא זו שנכנסת לקבלה כיחידת מידה לפי ОКЕИ. אם בהזמנה רשומה "קופסה", ובקבלה צריכה להיכנס "יחידה" עם הקוד הנכון, ההמרה חייבת להיות מוגדרת לפני רגע הפיסקליזציה — אחרת הקבלה אינה תואמת את המכירה בפועל.
הבדיקה פשוטה: קחו פריט עם המרה, בצעו הזמנה ביחידת המסחר ועקבו אחרי המסלול — היתרה במחסן, המסמך ב-1С, השורה בקבלה. אם הכמות תאמה בכל שלושת השלבים, יחידות האחסון והמכירה מוגדרות כראוי.
מקרה בוחן: סדר ביחידות מידה באתר פעיל
הלקוח — ספק סיטונאי של חומרי בניין על 1С:Управление торговлей ואתר על Битрикс. הקטלוג — כמה אלפי פריטים, חלק מהמוצרים נמכרים במטרים, חלק באריזות, וחלק ביחידות עם מכפלה. יחידות המידה בכרטיסים הוזנו במשך שנים על ידי עובדים שונים: במקום אחד «м», במקום אחר «метр», במקום אחר «пог. м», וב-1С לאותו פריט עמדה אריזה. ההזמנה יצאה לשריון בכמות שהמחסן לא יכול היה לספק.
מה היה לפני
שיעור ההזמנות שבהן המנהל תיקן ידנית את הכמות לאחר השלמת ההזמנה עמד על 18-22%. כל תיקון — שיחה ללקוח, חישוב מחדש של השורה וייצוא חוזר ל-1С; טיפול בסל אחד ארך בין 15 ל-40 דקות.
אי-התאמות בין האתר למערכת החשבונאית צפו בממוצע 60-80 פעמים בחודש, וכמעט כל אחת מהן גררה תיקון ידני של מסמך.
מה שינו
איחדו את ספר יחידות המידה לסט אחיד של קודים והצליבו אותו עם המסווג שבו משתמשת 1С. עבור פריטים עם מכפלה הוגדר מקדם המרה, כך שהאתר פעל ביחידת הבסיס, ולמערכת החשבונאית נשלחה הכמות שבאמת נשלחת בפועל.
הוספה בדיקה בשלב השלמת ההזמנה: אם יחידה בכרטיס אינה מותאמת לספר של 1С, המוצר לא נכנס להזמנה — במקום שגיאה שקטה המנהל רואה פריט קונקרטי. בנפרד עברו על כרטיסים היסטוריים ותיקנו אי-התאמות שהצטברו לפני ההטמעה.
מה נהיה
שיעור ההזמנות עם תיקון ידני של כמות ירד מ-18-22% ל-2-3% — אלה המקרים שבהם הלקוח עצמו משנה את הנפח כבר בסל. הזמן לטיפול בסל אחד הצטמצם מ-15-40 דקות לכמה דקות, ואי-ההתאמות מול 1С בכמות — מ-60-80 למקרים בודדים בחודש, וכל אחד מהם מטופל לפי פריט קונקרטי, ולא בחיפוש בכל הקטלוג. המנהלים הפסיקו להיות חיץ בין האתר למחסן.
ספקות טכניים נפוצים בנוגע ליחידות מידה
יחידות מידה הן הנקודה שבה נפגשים הקטלוג, ניהול המלאי והמעגל הפיסקלי. לכן הספקות כאן הם בדרך כלל לא לגבי "איזה קוד לבחור", אלא לגבי תאימות למערכת שכבר פועלת: המאגר העצמי, כמויות עשרוניות והחלפה עם 1С. להלן ניתוח של מצבים אופייניים שאיתם מגיעים לפני ההתחלה.
כבר פרוס אצלנו מאגר יחידות מידה עצמאי — האם צריך לשנות הכול?
לא. תחילה ממפים: אילו קודים משמשים בכרטיסים, אילו נשלחים ל-1С, ואילו מגיעים לקבלות. לאחר מכן משווים אותם למסווג ОКЕИ ומוסיפים פריטים חסרים, בלי לגעת במה שעובד.
החלפה מלאה נדרשת רק במקום שבו המאגר מנוהל ידנית והקודים אינם תואמים בין המערכות — אז ההגירה מתבצעת לפי טבלת התאמה, ולא "בכוח".
כיצד להתמודד עם כמויות עשרוניות — 0.5 ק"ג, 1.25 מ'?
כמות עשרונית מחייבת שהדיוק יהיה מתואם בכל הרמות: בכרטיס המוצר, בהגדרות המחסן ובכללי העיגול בעת הייצוא ל-1С. אם במקום כלשהו מוגדר עיגול למספר שלם, הזמנה של 0.5 ק"ג תהפוך ל-1 ק"ג או ל-0 — וזה יצוף כבר בפערים במלאי. אנו מגדירים דיוק אחיד ובודקים אותו על הזמנות בדיקה לפני ההפעלה.
האם ההחלפה עם 1С תישבר לאחר התיקונים?
ההחלפה נשברת לא בגלל יחידות המידה עצמן, אלא בגלל אי-התאמה של קודים ומכפלות. לפני השינויים מתעדים את ההתאמות הנוכחיות, מריצים ייצוא בדיקה ומשווים נומנקלטורה, כמות ומחירים בשני הצדדים.
אם קוד יחידת המידה בקטלוג וב-1С אינו תואם, המוצר או שלא ייוצא, או שיוצא עם כמות שגויה — לכן ההשוואה נעשית לפני, ולא אחרי.
מה עם קבלות ו-54-ФЗ?
במסמך הפיסקלי יחידת המידה והכמות חייבות להיות מתואמות עם מה שנמכר בפועל. כמות עשרונית בקבלה מותרת, אבל רק אם הדיוק והעיגול מוגדרים באופן זהה בקטלוג, במחסן ובקופה. אחרת הקבלה תסתור את ההזמנה, וזו כבר שאלה לא של האתר, אלא של הדיווח.
אם המצב שלכם לא נכלל ברשימה — תארו כיצד בנויים כעת המאגר וההחלפה, ונחזור עם הערכה ותוכנית הגירה.
בואו נדון במשימה שלכם בנושא יחידות מידה
הגדרת יחידות מידה ב-Bitrix לעיתים רחוקות היא מטרה בפני עצמה — בדרך כלל היא עולה כשהקטלוג כבר חי, והמחירים, המלאי והקבלות לא מתיישבים בין האתר, המחסן והקופה. אם יש לכם מצב כזה, תארו אותו כמו שהוא: אילו יחידות מוגדרות כרגע, מאיפה מגיעים הנתונים, ואיפה בדיוק נשברת ההמרה. זה מספיק כדי להבין את היקף העבודה ולחזור עם הערכה ותוכנית.
כדי שהשיחה תהיה עניינית, כדאי לאסוף מיד את הנתונים הראשוניים:
- אילו יחידות מידה משמשות בקטלוג וכמה יש — יחידות, מטרים, קילוגרמים, אריזות, שירותים;
- האם יש מוצרים עם כמות חלקית ואיך הם נמכרים — ביחידות, לפי משקל, בכפולות של אריזה;
- מאיפה מגיעה הקטלוג — מ-1С, ממחירוני ספקים, מוזן ידנית;
- איך היחידות קשורות למקדמי המרה בין יחידת הבסיס ליחידת המחסן;
- מה מודפס בקבלות ובתעודות משלוח והאם זה מחייב התאמה ל-ОКЕИ;
- אילו דוחות וייצוא תלויים ביחידות — מלאי, מכירות, עלות;
- איך מוגדרים עיגול הכמות והמחיר, כדי שלא יופיעו אגורות ו"שאריות" בפריטים.
לפי התשובות האלה אפשר לראות אם נדרשת הגדרה נקודתית של ספר היחידות או בנייה מחדש של החיבור בין הקטלוג, המחסן והחלפה עם מערכת הנה"ח. נחזור עם הערכת עבודה, תוכנית בשלבים ורשימה של מה שיידרש מצדכם — הרשאות גישה, סביבת בדיקה, איש קשר מצד הנהלת החשבונות או המחסן. נדון במשימה — ומשם אתם מחליטים אם להתחיל בעבודה או קודם לבדוק את ההשערה על מדור אחד בקטלוג.