אוטומציה חכמה של רישום תקבולי לקוחות דרך דפי הבנק
כיצד ניתן לצמצם קסטומיזציה, להעצים את המשתמש העסקי ולשפר את תהליך קליטת דפי הבנק?
אחד התהליכים הנפוצים במערכת SAP במודול ה FI הוא קליטת דפי בנק.
התהליך (באמצעות טרנזקציה FF.5) מאפשר לרשום באופן אוטומטי את תנועות הבנק לחשבונות ה GL (חשבון בנק ראשי מול תת-בנק). אולם רישום זה מתייחס רק לצד הבנקים. בנוסף, נדרש לבטא את התקבול בכרטסת הלקוח הרלוונטית (או התשלום, בכרטסת הספק- עפ"י מהות התנועה בבנק).
בארגונים רבים השיוך לחשבון הלקוח/ספק עדיין מבוצע באופן ידני, דבר היוצר עבודה כפולה ופוגע ביעילות התהליך.
במאמר זה נציג פתרון לרישום אוטומטי של תקבולים מלקוח (מסמך DZ) בגרסת SAP ECC , כבר במהלך טעינת דף הבנק, באמצעות שימוש במחרוזת הטקסט המופיעה בקובץ הבנק לצורך זיהוי הלקוח.
מעבר לאוטומציה עצמה, הפתרון שם דגש על עיקרון חשוב לא פחות – הפחתת התלות בעדכון קסטומיזציה עבור כל שינוי עסקי (CR) .
האתגר
כאמור, בעת טעינת דף הבנק באמצעות FF.5 מבוצע רישום אוטומטי לחשבונות GL של הבנקים בהתאם לPosting Rule שהוגדר ב-OT83.
בשלב נפרד, צוות הגבייה נדרש לבצע ידנית רישום התקבול (באמצעות טרנזקציה F-28).
התהליך הידני יצר מספר חסרונות:
עבודה חוזרת.
עיכוב בהתאמות לקוחות.
סיכון לטעויות אנוש.
תלות בפעילות ידנית של צוות הגבייה.
מערכת SAP מספקת פתרון סטנדרטי המבוסס על מנגנון Search Strings , אשר בשילוב Posting Rule מתאים מאפשר לזהות את אופי התנועה וליצור באופן אוטומטי מסמך נוסף עבור תקבול מלקוח.
הפתרון עובד, אך אליה וקוץ בה- חבוי בפתרון מגבלה תפעולית משמעותית.
כל הוספה או שינוי של טקסטים מחייבים בדרך כלל ביצוע Customizing והעברת Transport בין סביבות המערכת. בארגונים בהם מתווספים לקוחות חדשים באופן תדיר, משמעות הדבר היא עומס מיותר על צוות ה-SAP וזמן תגובה ארוך לעסק.
הרעיון מאחורי הפתרון
במקום שהידע העסקי יתוחזק ב- Customizing ע"י איש IT, נעשה שימוש בטבלה הניתנת לתחזוקה ע"י המשתמש העסקי. כך, כל שינוי עסקי אינו דורש מעורבות של צוות SAP או העברת Transport.
הטבלה תכיל שני שדות בלבד:
הטקסט הייחודי כפי שמופיע בקובץ הבנק.
מספר הלקוח (Customer Number)במערכת ה SAP
הטבלה זמינה גם באמצעות טרנזקציה ייעודית, כך שהמשתמש העסקי יכול לתחזק את ערכי המיפוי, להוסיף או לעדכן ללא צורך ב- Transport או במעורבות של צוות ה- IT.
כיצד הפתרון עובד?
במהלך עיבוד דף הבנק מופעל User Exit שבתוכו ניתן לכלול את הלוגיקה של איחזור מספר הלקוח מהטבלה ועדכון.
הפתרון מבצע את השלבים הבאים:
קורא את טקסט התקבול מתוך שורת דף הבנק.
מחפש התאמה בטבלת מיפוי הלקוחות
במקרה שנמצאה התאמה, מאחזר את מספר הלקוח.
מעדכן את נתוני המסמך לפני ביצוע הרישום.
סאפ יוצר אוטומטית מסמך מסוג DZ המזכה את חשבון הלקוח.
כל התהליך מתבצע כחלק מעיבוד FF.5, ללא התערבות המשתמש.
דוגמה ליישום
בקובץ הבנק מופיעה השורה:
Payment from ABC Technologies Ltd
בעת טעינת דף הבנק, המערכת רושמת בשלב הראשון, עפ"י הכלל רישום שהגדרנו, את התקבול :
חובה (Debit) - חשבון GL בנק ראשי ( Main Bank)
זכות (Credit ) – חשבון GL תת-בנק (Sub Bank)
במהלך עיבוד השלב הראשון מופעל גם ה- User Exit המבצע חיפוש של שם הלקוח כפי שמופיע בטבלת מיפוי הלקוחות בקובץ הבנק.
בשלב השני, במידה ונמצאה התאמה, המערכת שולפת את מספר הלקוח מהטבלה ויוצרת אוטומטית מסמך DZ. התקבול נרשם ישירות בכרטיס הלקוח.
חובה (Debit) - תת בנק Sub Bank
זכות (Credit ) – לקוח Customer
מבחינת המשתמש העסקי, אין צורך לבצע לאחר מכן רישום ידני באמצעות F-28 .
היתרונות העסקיים
הפתרון מספק מספר יתרונות משמעותיים:
קיצור זמן הטיפול בתקבולי לקוחות.
ביטול שלב עבודה ידני.
הקטנת הסיכון לטעויות הקלדה.
צמצום משמעותי במספר בקשות ה- Change Request .
העברת האחריות על תחזוקת הנתונים ליחידה העסקית.
תגובה מהירה לפתיחת לקוחות חדשים.
הפחתת עומס על צוות היישום והפיתוח.
מעבר לכך, הארכיטקטורה עצמה פשוטה וניתנת להרחבה בקלות גם לתרחישים נוספים של התאמות אוטומטיות.
מסקנות
לעיתים הערך האמיתי של פיתוח SAP אינו נובע מאלגוריתם מורכב, אלא מתכנון נכון של האחריות בין המערכת לבין המשתמש העסקי. במקום שכל שינוי קטן יעבור דרך מחזור פיתוח מלא, ניתן לבנות פתרון שבו הלוגיקה נשארת יציבה, בעוד שהנתונים העסקיים מנוהלים באופן עצמאי על ידי המשתמשים.
במקרה זה, שימוש בUser Exit , בשילוב טבלת תחזוקה עסקית אפשר אוטומציה מלאה של רישום תקבולי לקוחות, תוך שיפור משמעותי ביעילות התהליך, הפחתת עבודה ידנית ושיפור חוויית המשתמש.
לעיתים, הערך העסקי הגדול ביותר אינו בפיתוח מורכב, אלא בתכנון נכון המאפשר לעסק לנהל את עצמו, תוך הפחתת התלות בצוותי היישום והפיתוח.
לפרטים נוספים מוזמנים ליצור איתנו קשר דרך info@allegropro.co.il
תגובות