שקלולית ומשכורשת: ממשקים לכרטיסי עובד וקליטת נתוני שכר

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

כרטיס העובד הוא נתון אב, הקלט החודשי אינו

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

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

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

מה שקלולית קולטת

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

• ממשק עם תוכנות הנוכחות הנפוצות, שמתואר כייבוא נתוני הנוכחות של העובדים בלחיצת כפתור.
• ייבוא נתוני שכר ופרטי עובדים באמצעות אקסל.
• ממשק אוטומטי עם קופות הגמל, הפנסיה וקרנות ההשתלמות לדיווח הפרשות.
• ממשק שידור טופס 102 לרשות המסים, ושידור טופס 161.
• ייצוא דוחות ל-PDF ולאקסל, מחולל דוחות וטבלאות ציר.
• Shiklulit Up, פורטל עובד הכולל טופס 101, תלושים וטופס 106.

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

אפשר לטעון כרטיסי עובד למשכורשת בכמות?

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

מה שהוא כן מתאר הם שני מנגנונים שמצמצמים את העבודה הידנית בלי קובץ:

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

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

זה מול זה: מה נכנס ומה יוצא

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

למה החודש השני מתנהג אחרת מהראשון?

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

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

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

התוצר שאף אחד לא מתכנן: קובץ פקודת היומן

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

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

שלוש השלכות לכל מי שמבצע אוטומציה סביב זה:

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

כשהמערכת המקבלת היא סאמיט, ההתנהגות של הממשק שלה מתוארת במדריך האינטגרציה ל-API של סאמיט.

מקורות

• תוכנת השכר שיקלולית - ט.מ.ל
• משכורשת - קליטת משכורת לעובד
• משכורשת - פקודת שכר להנהלת חשבונות