, במכלול ה-S4HANAמכרז להקמה והטמעת מודולים פיננסיים, מבוססי SAPבאוניברסיטת חיפה

נספח טכני

למסמך ג' למסמכי המכרז(1)נספח

Contents8................................................................................מבוא.18.......................................................................מבנה הנספח.29...........................................הנחיות כלליות, מתודולוגיה והטמעה.3

9................................................................................................................הנחיות כלליות.3.1

10..............................................................................................................ניהול הפרויקט.3.2

11......................................................................................פונקציונליות נדרשת של התוצר.3.3

12........................................................................................................ביצוע אפיון מפורט.3.4

13......................................................................................תהליך המסירה והעלייה לאוויר.3.5

15................................................................................................................הסבת נתונים.3.6

15.........................................................................................................חשבות.3.6.1

18......................................................................................................תקציבים.3.6.2

18.........................................................................גישת המציע– הסבת נתונים .3.6.3

Master Data....................................................................................................20טיפול ב.3.7

20..................................................................................................:מידע סטטי.3.7.1

21........................................................................................:מידע שאינו סטטי.3.7.2

21..................................................................................................................ייצוא נתונים.3.8

22............................................................................................הדרכות והטמעת המערכת.3.9

22.............................................................................................................אינדקס התיעוד.3.10

BASIS..............................................................................................................23תשתיות .3.11

23...............................................................................................תמיכה ,תחזוקה ואחריות.3.12

23........................................................................................................אחריות.3.12.1

24.......................................................................................כלי פיתוח ותחזוקה.3.12.2

25.......................................................................................רמת שירות נדרשת.3.12.3

27.................................ארכיטקטורת מערכות המידע באוניברסיטה.42

27..........................................................................ארכיטקטורת מערכות המידע הנוכחית:.4.1

29.........................................................................ארכיטקטורת מערכות המידע העתידית:.4.2

30.......הפעילות הנדרשת כמענה לאתגרים העסקיים באוניברסיטת חיפה.5FI...........................................................................................................30פיננסי – מודול .5.1

30....................................................................................................ספר ראשי.5.1.1

61..........................................................................................................גזברות.5.1.2

80.........................................................................................................ספקים.5.1.3

93.........................................................................................................לקוחות.5.1.4

97...................................................................................................רכוש קבוע.5.1.5

CO................................................................................................103– בקרה .5.1.6

118.........................................................................................................דוחות.5.1.7

128....................................................................................................ממשקים.5.1.8

SLCM.......................................................................................131מנהל תלמידים- מודול .5.2

131...........................................................................................................כללי.5.2.1

131...........................................................................................................רקע.5.2.2

132...................................................(פרופיט)ממשק לספר הראשי - מצב קיים .5.2.3

135........................................(FI)רישום לספר הראשי : תיאור מצב עתידי נדרש.5.2.4

140.........................................................................................................נמחק.5.2.5

140.........................................................................................................נמחק.5.2.6

SLCM...........................................................140פירוט דרישות עסקיות ממודול .5.2.7

148.....................................................(SLCMבית הספר הבינלאומי )חלק אינטגרלי ממודול .5.3

148...........................................................................................................רקע.5.3.1

148.........................................................................................תיאור מצב קיים.5.3.2

149........................................................................................תיאור מצב נדרש.5.3.3

151......................................פירוט דרישות עסקיות בנושא בית הספר הבינלאומי.5.3.4

3

154.............................................................(SLCMגורמים מממנים )חלק אינטגרלי ממודול .5.4

154.........................................................................................תיאור מצב קיים.5.4.1

155........................................................................................תיאור מצב נדרש.5.4.2

157..............................................פירוט דרישות עסקיות בנושא גורמים מממנים.5.4.3

159..................................................................................................מערכת לתכנון תקציב.5.5

159...........................................................................................................רקע.5.5.1

160.........................................................................................מטרות המערכת.5.5.2

160........................................................................................עקרונות מרכזיים.5.5.3

161.....................................................................................משתמשי המערכת.5.5.4

161........................................................................ארכיטקטורת מערכות מידע.5.5.5

162....................................................................................................ממשקים.5.5.6

163.............................................................................ישויות ורזולוציית התכנון.5.5.7

164................................................................מתודולוגיית תהליך בניית התקציב.5.5.8

171.......................................................................................................מודלים.5.5.9

192..........................................................................כללי- פונקציונליות נדרשת.5.5.10

194.........................................................................................תצורת המערכת.5.5.11

196.............................................................................................בסיס הנתונים.5.5.12

197.....................................................................................יכולות פונקציונליות.5.5.13

199...................................................פירוט דרישות עסקיות בנושא תכנון תקציב.5.5.14

245................................................ישויות ורזולוציית התכנון- נספח תכנון תקציב.5.5.15

FM.........................................................................................249בקרה תקציבית – מודול .5.6

249.................................................................................................סוגי תקציב.5.6.1

249.................................................................................בקרה תקציבית כפולה.5.6.2

250...............................................................................רמת הבקרה התקציבית.5.6.3

251...........................................................................................מעבר בין שנים.5.6.4

251...............................................................................מ"מע- בקרה תקציבית .5.6.54

FI-CA............................................................251 עם FMהערה הנוגעת לשילוב .5.6.6

252..............................................פירוט דרישות עסקיות בנושא בקרה תקציבית.5.6.7

259...................................................................................פירוט דוחות נדרשים.5.6.8

PM...................................................................................................................260מודול .5.7

260...........................................................................................................כללי.5.7.1

260.........................................................................................תיאור מצב קיים.5.7.2

262........................................................................................תיאור מצב נדרש.5.7.3

263.........................................................................................................נמחק.5.7.4

263.........................................................................................................נמחק.5.7.5

PM................................................................263פירוט דרישות עסקיות בנושא.5.7.6

HR...............................................................................................266משאבי אנוש- מודול .5.8

266...........................................................................................................כללי.5.8.1

266.........................................................................................תיאור מצב קיים.5.8.2

SAP HR:..........................................................267פירוט היישום הקיים במודול .5.8.3

273........................................................................................תיאור מצב נדרש.5.8.4

274.........................................................................................................נמחק.5.8.5

274.........................................................................................................נמחק.5.8.6

HR................................................................274פירוט דרישות עסקיות בנושא .5.8.7

282.........................................................................................ניהול מעונות- מודול מעונות.5.9

282...........................................................................................................כללי.5.9.1

282...........................................................................................................רקע.5.9.2

283.........................................................................................תיאור מצב קיים.5.9.3

284........................................................................................תיאור מצב נדרש.5.9.4

Study Abroad.........................................................285מעונות בהקשר לימודי .5.9.5

286.........................................................................................................נמחק.5.9.6

5

286.........................................................................................................נמחק.5.9.7

286...........................................................פירוט דרישות עסקיות בנושא מעונות.5.9.8

BI.........................................................................................................289בינה עסקית – .5.10

289.........................................................................................תיאור מצב קיים.5.10.1

BI..................................................................290פירוט דרישות עסקיות בנושא .5.10.2

GM..............................................................................................292רשות מחקר- מודול .5.11

292...........................................................................................................כללי.5.11.1

292.........................................................................................תיאור מצב קיים.5.11.2

293.........................................................................................................נמחק.5.11.3

293.........................................................................................................נמחק.5.11.4

GM...............................................................294פירוט דרישות עסקיות בנושא .5.11.5

MM......................................................................................................296רכש – מודול .5.12

296...........................................................................................................רקע.5.12.1

297.........................................................................................תיאור מצב קיים.5.12.2

300........................................................................................תיאור מצב נדרש.5.12.3

301..............................................................פירוט דרישות עסקיות בנושא רכש.5.12.4

315................................................................................................................ניהול פורטל.5.13

315...........................................................................................................כללי.5.13.1

316.........................................................................................תיאור מצב קיים.5.13.2

318........................................................................................תיאור מצב נדרש.5.13.3

320.........................................................................................................נמחק.5.13.4

320.........................................................................................................נמחק.5.13.5

320.........................................................................................................נמחק.5.13.6

320............................................................פירוט דרישות עסקיות בנושא פורטל.5.13.7

323................................................................................................................ניהול ספריה.5.14

6

323...........................................................................................................רקע.5.14.1

324.........................................................................................תיאור מצב קיים.5.14.2

325........................................................................................תיאור מצב נדרש.5.14.3

326...........................................................................................פירוט תהליכים.5.14.4

329...........................................................פירוט דרישות עסקיות בנוגע לספריה.5.14.5

330............................................................................................................ניהול הרשאות.5.15

330.........................................................................................תיאור מצב קיים.5.15.1

332........................................................................................תיאור מצב נדרש.5.15.2

333....................................................................פירוט דרישות בנוגע להרשאות.5.15.3

7

מבוא.1 למסמך ג' במכרז1( המהווה את הנספח הטכני )נספח SOW – להלן: Scope Of Workמסמך זה הינו הגדרת תכולת עבודה נדרשת )

40/2018.)

באמצעות המציע הזוכהTurn Keyמסמך זה יכלול את תיאור המצב הקיים וכן יתאר את מכלול הפרויקט העתידי אשר רובו ייושם כמכלול

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

כמו כן מכיל מסמך זה דרישות נוספות המוגדרות כאופציה למימוש על ידי המציע הזוכה.

מבנה הנספח.2.SOW מכיל הנחיות כלליות למענה ל-3סעיף

מתאר את ארכיטקטורת מערכות המידע באוניברסיטה. 4סעיף

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

תיאור המצב הקיים היום

תיאור המצב הנדרש

.הדרישות העסקיות עבור מודול זה

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

ומעלה.85%

.סיווג הדרישה העסקית לצרכי תמחור כמפורט בהמשך

8

הנחיות כלליות, מתודולוגיה והטמעה.3

הנחיות כלליות.3.1

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

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

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

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

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

למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(.1. כל המחירים ימולאו בנספח בנספח זה אין למלא מחירים.3.1.1.6

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

".לא נדרש תמחורדרישות עסקיות שייושמו באמצעות צוות המחשוב של האוניברסיטה יסומנו ב".3.1.1.7.1 " – דרישות אילו יגולמו על ידי המציענדרשדרישות עסקיות שהינן חלק אינטגרלי מהפרויקט יסומנו כ ".3.1.1.7.2

( של הפרויקט ואין לפרט עבורן תמחור פרטני בנפרד.Fix Priceכחלק מהתמחור הכולל ) " – עבור דרישות אילו המציעים נדרשיםאופציהדרישות עסקיות שמסווגות כאופציה למימוש יסומנו כ ".3.1.1.7.3

למימוש אותה דרישה עסקית. התמחורFix Priceלהציע במסגרת טופס הצעת המחיר תמחור פרטני ב- למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"( בשורה הרלוונטית בטבלה. שוב מובהר1יוצג בנספח

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

תיאור מפורט של המענה לדרישה העסקית..3.1.1.8.1 יתמוך בדרישה )ניתן להמליץ על מודולים נוספים שלא מצוינים במסמך זה(.SAPאיזה מודול .3.1.1.8.2

9

הפירוט נדרש גם בעבור המשימות המוגדר כ"אופציה". .3.1.1.8.3

ניהול הפרויקט.3.2

הפרויקט ינוהל על ידי מנהל פרויקט מטעם הספק..3.2.1.1

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

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

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

:3.2.1.4פרט כאן את המענה לסעיף

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

10

פונקציונליות נדרשת של התוצר.3.3

הכוללת מודולים חדשים )פיננסיים ולוגיסטיים( לצד מודולים ותיקיםS4HANA אינטגרטיבית מבוססת SAPהתוצר של מכרז זה יהיה מערכת .3.3.1.1 טרם פרויקט זה )להלן: "המערכת"(. S4HANAשהוסבו כבר על ידי צוות האוניברסיטה לתשתית

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

(. Unicodeנתוני המערכת יאפשרו שימוש במכלול שפות ).3.3.1.3

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

על המערכת להיות נוחה לתפעול, בעלת ממשק משתמש ידידותי בעבור משתמשים שאינם אנשי מערכות מידע. על ממשק המשתמש להיות.3.3.1.5 )אריחים(. Tiles מבוסס FIORIאחיד בכל חלקי המערכת. כלל מסמכי המשתמש שיוקמו על ידי המציע יהיו על בסיס ממשק משתמש

11

ביצוע אפיון מפורט.3.4

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

הכרת המצב הקיים, הכרת תהליכי העבודה הקיימים..3.4.1.1.1ביצוע .3.4.1.1.2 המוצעת, במערכת העבודה תהליכי של ואפיון Gapתיאור Analysisהמערכת את יציג המציע .

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

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

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

במסמך דרישות זה(. רשימת ותיאור מפורט של הממשקים הקבועים )מהות הממשק, מבנה השדות, תדירות, בדיקות לוגיות ובקרת.3.4.1.1.5

שגויים(. רשימת ותיאור מפורט של הממשקים חד פעמיים )מהות הממשק, מבנה השדות, תדירות, בדיקות לוגיות.3.4.1.1.6

ובקרת שגויים(. לביצוע הסבה כולל הגדרה של הנתונים המחייבים טיוב.

12

המסירה והעלייה לאווירתהליך .3.5

תהליך מסירת המערכת לאוניברסיטה יעשה בשלבים בהתאם לתכנית העלייה לאוויר, כולל תקינות ושלמות הממשקים עם מערכות הליבה של.3.5.1.1האוניברסיטה.

על המציע להגדיר תכנית עליה לאוויר שתאזן בין סיכונים לתועלות..3.5.1.2

המציע נדרש לפרט להלן את מתודולוגיית העלייה לאוויר בתצורה זו )סגירת.Big Bangהאוניברסיטה מעוניינת שהעלייה לאוויר תתבצע ב-.3.5.1.3( :Big Bangמכלול קיים והפעלת מכלול חדש בתהליך

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

על המציע להציג את נוהל מבחני המסירה המקובלים אצלו. בנוסף, על המציע להתחייב לביצוע בדיקות עומסים ברמת המערכת: התנהגות ה-.3.5.1.4Client-מול השרת והתנהגות השרת מול ה DB.

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

13

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

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

צרף כאן דוגמת פרוטוקול:

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

שיאושר ע"י האוניברסיטה.System Test Plan )מסמך )STPבמהלך היישום יידרש המציע הזוכה לבנות .3.5.1.6

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

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

– תקלות שחייבות להיפתר בטרם עלייה לאוויר.No Goתקלות .3.5.1.8.1 – תקלות שניתן לעלות איתן לייצור אעפ"י שטרם נפתרו. Goתקלות .3.5.1.8.2

14

הסבת נתונים.3.6

חשבות.3.6.1

15

AS400טיפול ב .3.6.1.1

שנים בהינתן ולאחר7המציע יידרש לתת מענה לשמירת היסטוריית המידע של האוניברסיטה למשך .3.6.1.1.1 לא תהיה שמישה. המידע נדרש ברזולוציה הקיימתAS400חצי שנה ממועד העלייה לאוויר מערכת ה

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

ארכיטקטורה של מצב קיים.3.6.1.2

באופן מצומצם על מנת לאפשר הפעלה של מודולים אחרים )כדוגמתFIבמצב הקיים הופעל מודול .3.6.1.2.1 נבנה באוריינטציה שלFI למערכת הפרופיט. מודול ה SAP( וכן כבסיס לממשק בין מערכת ה GMמודול

פרופיט, לרבות מספרי חשבון שהותאמו למספרי החשבון במערכת הפרופיט. (GM שנים תנועות בגין מחקרים )מתוך מודול 15 הקיים מכיל בין היתר תנועות היסטוריות- לדוגמא FIה.3.6.1.2.2ה .3.6.1.2.3 בין מערכת ומועבר מידע באמצעות ממשקים נוצרים רישומים אוטומטיים לבין מערכתFIכיום,

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

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

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

FIפקודות שיערוך מבוצעות בפרופיט בעבור מחקרים חיצוניים ואינם מועברים למודול ה .3.6.1.2.3.2GMולכן אינם משתקפים במודול

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

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

16

17

רזולוציית המידע שנדרש להסב.3.6.1.3

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

שהמערכת הנוכחית לא תהיה זמינה לאחר העלייה לאוויר.ההסבה מתייחסת לנתונים עבור שנה אוניברסיטאית ולא קלנדרית ) אוקטובר עד ספטמבר(.3.6.1.3.2 שנים לפני שנת העלייה לאוויר. עבור7: נדרש להסב מידע מלא )פקודות יומן( עבור חשבונות מאזניים.3.6.1.3.3

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

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

)כשלושה יידרש ממשק לטעינה במקביל של תנועות שיירשמו במערכת פרופיט במסגרת סגירת שנה חודשים(.

התוצאתיים .3.6.1.3.6 כל החשבונות עבור להסב subנדרש accountsכספיים דוחות הפקת לטובת הנדרשים ולטובת העבודה השוטפת. דוגמאות )רשימה חלקית!(:

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

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

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

וכו'(

18

תקציבים.3.6.2

מנהלים רק יתרותTM1בפרופיט מנהלים תנועות של העברות תקציביות ויתרות תקציב, התחייבויות וביצוע, ב .3.6.2.1של תקציב )תקציב מקורי ומעודכן(, התחייבויות וביצוע.

נתוני תקציב של שנתיים אחורה ממועד העלייה לאוויר- הסבה מלאה של כל תנועות התקציב לרבות העברות.3.6.2.2תקציביות על כל סוגיהן

נתוני תקציב מעל שנתיים אחורה לא יוסבו במערכת הפיננסית אלה ימשיכו להיות מופקים ממערכות תומכות.3.6.2.3 (. הנחת העבודה היא שהרזולוציה של שליפת מידע תקציבי היסטורי תהיה ברמת יתרות בלבד ולאTM1) כיום

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

שנים אחורה.7נדרשת יכולת להפיק דוחות תקציב מול ביצוע פר שנה )ברמת יתרה ולא תנועה( לתקופה של .3.6.2.4

SAPנדרש לבצע הסבת תקציב לשנה העוקבת ע"מ לאפשר בקרה תקציבית ב .3.6.2.5

הסבת נתונים – גישת המציע.3.6.3

המציע מתבקש להציג את גישתו בנושא הסבת נתונים, שתכלול את הנקודות הבאות:.3.6.3.1

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

לו"ז מסודר לביצוע ההסבה..3.6.3.1.2אפיון מפורט למבנה הקבצים לטעינה..3.6.3.1.3תכנון בדיקות הקבלה.3.6.3.1.4ושלמות.3.6.3.1.5 יעשה בשלבים בהתאם לתכנית העלייה לאוויר, כולל תקינות תהליך הקבלה באוניברסיטה

הממשקים עם מערכות הליבה של האוניברסיטה.

19

יש לפרט את הנדרש בסעיף זה לעיל, בשורות אלו:

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

20

Master Dataטיפול ב.3.7

מידע סטטי:.3.7.1

מידע שנדרש להסב:.3.7.1.1

חשבונות ומאפייני החשבון.3.7.1.1.1מיקום בדוחות רווח והפסד – לדוגמא, תרומות בארץ בדוח על הפעילות, דוח על השינויים..3.7.1.1.1.1מאפיין של חשבון – נדרש שיערוך או לא .3.7.1.1.1.2

3.7.1.1.2.Sub Accountsספקים .3.7.1.1.3 מנוהלים רק נתונים לוגיסטיים, יש להשלים נתונים פיננסיים כגון: חשבון בנק ספק , ניכוי מסSAPב .3.7.1.1.4

במקור חדשMM קיים לMMפריטים )=קטלוג( במידה ויידרש במסגרת הסבת .3.7.1.1.5 יש הרבה יותר לקוחות משום שלקוח פוטנציאליGM לקוחות קיימים בכספים. במודול 160לקוחות – כ .3.7.1.1.6

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

חשבונות(200חשבונות בנק וקופות )כ .3.7.1.1.7רכוש קבוע – בנוסף לחשבונות של רכוש קבוע יש להסב את כל נתוני הפריטים במערכת רכוש קבוע..3.7.1.1.8תקציבים סגורים, כ 350, כ מחקרים פנימיים1600 מחקרים חיצוניים, כ 1,000מרכזי עלות- כ .3.7.1.1.9 750

יחידות ארגוניות500תקציב רגיל, עד כ

21

מידע שאינו סטטי: .3.7.2

חשבות , לדוגמה :.3.7.2.1

3.7.2.1.1.POפתוחים חשבוניות פתוחות ספקים.3.7.2.1.2חשבוניות פתוחות לקוחות.3.7.2.1.3דפי בנק שלא הותאמו מול תנועות .3.7.2.1.4תנועות שלא הותאמו בהתאמת בנקים.3.7.2.1.5תנועות בקופות שטרם הופקדו.3.7.2.1.6

תקציבים.3.7.2.2

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

חדשים יסופררו בהתאם למתודולוגיה החדשהשמשקפים מחקר/מענק ימשיכו לשמש באותו מספר ב CCספרור מחקרים/מענקים: .3.7.2.2.2 SAP- החדש

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

ייצוא נתונים.3.8

וכדומה.PDF, XML, CSVעל המערכת לאפשר ייצוא נתונים אל אחד או יותר מהאפיקים הבאים: אקסל,

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

22

הדרכות והטמעת המערכת.3.9

בתחילת הפרויקט תינתן הדרכה לצוות הפרויקט )משתמשי מפתח וצוות מערכות מידע( לרבות הדרכות טכניות.3.9.1.1לצוות התשתיות.

תוגש תכנית להדרכה ותכולת ערכת ההדרכה לאישור האוניברסיטה..3.9.1.2

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

תינתן הדרכה מלאה ע"י המציע הזוכה לכל עובדי האוניברסיטה ..3.9.1.4

המציע הזוכה יבנה תכנית הדרכה למשתמש חדש )כולל חוברת או קורס מקוון( שתוכל להינתן ע"י מנהל הפרויקט.3.9.1.5או מי מטעמו למשתמשי המערכת ישנים / חדשים באופן שוטף.

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

הדרכה על מערכת הפעלה / בסיס נתונים הדרושים לתפעול המערכת.

אינדקס התיעוד.3.10

כל מרכיב במערכת אשר יתקבל מידי המציע הזוכה ילווה בתיעוד מלא..3.10.1.1

התיעוד הנדרש:.3.10.1.2

, ממשקים.Workflowsתיעוד המתייחס להתאמות שינויים, פיתוח דוחות, טפסים, .3.10.1.2.1כולל DBתיעוד מפורט של בסיס הנתונים )תיעוד של כלל ה-.3.10.1.2.2 ERD ,מבנה טבלאות, טריגרים ,Stored

procedures.)'וכו -.SAPתיעוד מפורט המתייחס להטמעה על בסיס ה.3.10.1.2.3-.SAPתיעוד מפורט למנהל המערכת על בסיס ה.3.10.1.2.4-.SAPמדריך מפורט למשתמש על בסיס ה.3.10.1.2.5

23

BASISתשתיות .3.11

)להלן: "איש ה-SAP BASISצוות הפרויקט מטעם המציע יכלול מומחה .3.11.1.1 BASIS-בעל היכרות עם תחום ה )"S4HANA.

שיידרשו על מנת לממש את התחייבויותיו בפרויקט. BASISבאחריות המציע לתת מענה כולל לכלל צרכי ה-.3.11.1.2

ייעוץ, מימוש שדרוגים טכניים, פתיחת BASISהמענה שיינתן על ידי איש ה-.3.11.1.3 יכלול תכנון, OSS מול SAPוכל בכדי לממש את התחייבות המציע. BASISפעילות הנדרשת בתחום ה-

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

יהיה זמין באופן מלא במהלך הפרויקט ויופעל על ידי מנהל הפרויקט מטעם המציע. BASISאיש ה-.3.11.1.5

תמיכה ,תחזוקה ואחריות.3.12

אחריות.3.12.1

חודשים לכל אחד מהפיתוחים במערכת. תקופת האחריות תתחיל ממועד קבלת12תקופת האחריות תהיה לפחות .3.12.1.1אישור מסירה של כל אחד מהפיתוחים.

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

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

תמיכת הספק תחול גם על כל השינויים והתוספות שבוצעו במערכת..3.12.1.4

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

24

________________________________________________________________________________________

כלי פיתוח ותחזוקה.3.12.2

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

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

25

רמת שירות נדרשת.3.12.3

תחזוקת המערכת תכלול:.3.12.3.1

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

התיעוד של המערכת בהתאמה. שינויים ושיפורים – ביצוע שינויים ושיפורים כתוצאה מדרישת המשתמשים. השינויים יכללו גם את.3.12.3.1.2

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

תיקון תקלות .3.12.3.1.4.1תמיכה בתשתיות המערכת למקסום הביצועים.3.12.3.1.4.2מענה טלפוני ואינטרנטי לבעיות תפעול באמצעות מוקד השירות..3.12.3.1.4.3. 7X24המציע הזוכה ייערך למתן תמיכה טלפונית לעזרה ופתרון בעיות בזמן אמת, .3.12.3.1.4.4 שעות2אחזקת תוכנה – תקלה הגורמת להשבתת המערכת תטופל על-ידי הספק תוך .3.12.3.1.4.5

שעות עבודה )יום8עבודה מרגע קבלת הקריאה ובאופן רצוף. תקלה אחרת תטופל תוך עבודה( מקבלת הקריאה ובאופן רצוף.

. במקרה והזמינות תהיה פחות מ99%המציע הזוכה מתחייב לזמינות שירות של לפחות .3.12.3.1.4.6, לא ישולמו דמי התחזוקה המגיעים בגין אותו חודש.95%

לטיפול בפניה על פי סטאטוסים וחומרת התקלה.SLAמוקד השירות יתחייב ל-.3.12.3.1.4.7תשובות.3.12.3.1.4.8 מתן למערכת. רלוונטיים בנושאים ויעוץ לשאלות ואינטרנטי טלפוני מענה

שעות עבודה.2לשאלות בקו חם לא יעלה על שירותי.3.12.3.1.4.9 במסגרת ללקוח המוצר לשדרוג יתחייב המציע – של התכנה גרסאות עדכון

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

26

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

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

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

27

ארכיטקטורת מערכות המידע באוניברסיטה.4

ארכיטקטורת מערכות המידע הנוכחית:.4.1

באוניברסיטת חיפה, בהקשר הפרויקט הנוכחי, מורכב משלושה מכלולים עיקריים:ERPמערך ה-.4.1.1.1

.SAPמכלול ה-.4.1.1.1.1 . יצויןAS400מכלול מערכות פיננסיות מבוססות "פרופיט" )לשעבר: "עידן"( ומערכות נוספות על גבי תשתית .4.1.1.1.2

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

משמש מספר יישומים עיקריים: SAPמכלול ה-.4.1.1.2

)מודול אקדמי ייעודי( .SLCMהמכלול האקדמי – מבוסס מודול .4.1.1.2.1.FI-CA וכן FI לצד יישום מינימלי של SLCMשכר לימוד – מבוסס מודול .4.1.1.2.2 )מודול ייעודי לניהול מענקי מחקר(. GMמכלול מענקי המחקר – מבוסס מודול .4.1.1.2.3.PMשירותי תחזוקה – מבוסס מודול .4.1.1.2.4.CO כולל יישום מינימלי של MMמכלול הרכש והמחסנים – מבוסס מודול .4.1.1.2.5. CO וכן שימוש ביישום המינימלי של ה-HRמשאבי אנוש – מבוסס מודול .4.1.1.2.6 )למשל: יישום לתפעול המעונות(. בנוסף, מיושמים שירותיםSAPכמו כן הוקמו יישומים מקומיים מבוססי .4.1.1.2.7

נוספים כגון: הרשאות וכד'. עלS4HANA מבוסס מסד נתונים אחוד. המערכת נמצאת בימים אילו בשלב מתקדם של תהליך שדרוג מלא ל- ERP מהווה SAPכלל מכלול ה-.4.1.1.3

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

ERP.של האוניברסיטה

, ואשר מקיימות ממשקים אל מולDB HANA נוספות, המוסבות במהלך התקופה הנוכחית ל-SAPבנוסף, קיימות באוניברסיטה מספר סביבות .4.1.1.4.SAP CRM וכן סביבת SAP BW 7.5, SAP PORTAL 7.5 המרכזי: ERPה-

28

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

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

קשרי מדע בינלאומיים וכד'.

, קיים מספר רב של ממשקים.SAPבין מכלול השירותים הפיננסיים ומכלול ה-.4.1.1.6

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

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

, הינה כיום מערכת עצמאית שאינה מקיימת ממשקים עם המכלולים האחרים.TM1המערכת לתכנון תקציבי, .4.1.1.8

מצורף תיאור סכמתי של ארכיטקטורת מערכת המידע הנוכחית. .4.1.1.9

29

.S4HANA לסביבת SAP ECC6 תושלם הסבת סביבת ה-2019כפי שצוין לעיל, בתחילת .4.1.1.10

ארכיטקטורת מערכות המידע העתידית:.4.2

בכוונת האוניברסיטה לסגור את המכלול הפיננסי הקיים )כולל מערכת התכנון התקציבי( ולשלב את התהליכים העסקיים הפיננסיים אל תוך.4.2.1.1 שהקמתו תושלם טרם כניסת המציע הזוכה לעבודה.S4HANA over HANA בסביבה של SAP( מבוסס ERPמכלול אינטגרטיבי מלא )

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

ההתאמה על ידי המציע הזוכה וזאת בשל היקף ההתאמות הנדרשות עד כדי אפשרות להקמה מחדש.

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

. הפרויקט מטעם המציע הזוכה

מצורף תיאור סכמתי של ארכיטקטורת מערכות המידע העתידית:.4.2.1.4

30

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

FIפיננסי – מודול .5.1

ספר ראשי.5.1.1

רקע - ניהול ספרים.5.1.1.1

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

( – לצורך ניהול תקציבי.Primary Ledgerספר כלכלי ).5.1.1.1.1.1( – לצורך הפקת דוחות כספיים.Secondary Ledgerספר פיננסי ).5.1.1.1.1.2

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

בספר הפיננסי יירשם נכס ויופחת על פני מס' שנים..5.1.1.1.2.1.1 בספר הכלכלי יירשם כהוצאה מלאה בעת הרכישה..5.1.1.1.2.1.2

פקודות סוף שנה:.5.1.1.1.2.2בספר הפיננסי יירשמו פקודות סוף שנה..5.1.1.1.2.2.1 בספר הכלכלי לא יינתן ביטוי לרישומים אלה..5.1.1.1.2.2.2

ניהול מטבעות.5.1.1.2

המערכת תאפשר לנהל חשבונות מסוימים בארבע סוגי מטבעות:.5.1.1.2.1(.TCמטבע הטרנזקציה ).5.1.1.2.1.1(.ILSמטבע פונקציונאלי ).5.1.1.2.1.2(.USDמטבע הקבוצה ).5.1.1.2.1.3מטבע החשבון..5.1.1.2.1.4

31

ישויות המדידה.5.1.1.3

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

אופן המדידה יעשה באופן הבא:.5.1.1.3.3פקולטה – נדרש הפקת דוח הכנסות והוצאות מפורט..5.1.1.3.3.1חוג/תכנית/קורס..5.1.1.3.3.2

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

המערכת תאפשר להפיק מידע ברמת חוג/תכנית/קורס ..5.1.1.3.5

32

פירוט דרישות עסקיות בנושא ספר ראשי .5.1.1.4

( 4.5% )משקל הדרישות העסקיות בנושא ספר ראשי בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש. הינן בקטגוריית "5.1.1.4.53 ועד 5.1.1.4.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישהעסקית

תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושא עליהם מתבסס בהצעתו(SAPלמודולי

כללי5.1.1.4.1

. תמיכה בהוראות ניהול ספרים לפי רשויות1המס – ומאושרת על ידי רשויות המס

 

. תמיכה ועמידה בתקנות כספים ומשק של2המדינה )תכ"מ(

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

. תמיכה בהקמת מבנה ארגוני היררכי בהתאם4לדרישות הארגון

דוחות כספיים5.1.1.4.2 . תמיכה בהפקת דוחות כספיים בהתאם לכללי1

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

 

33

. המערכת תתמוך כאשר חשבון בודד/קבוצת2 חשבון ביתרת חובה/זכות - מיון בדוחות הכספיים

בהתאם ליתרה. לדוג' כרטיסי חו"ז

. תמיכה בהגדרת מספר גרסאות לדוחות3הכספיים

. תמיכה בהפקת דוחות כספיים לפי שערים4שונים

. תמיכה בהפקת מאזנים לפי נתוני הצמדה5שונים של מדדים לפי טבלאות המדדים

. תמיכה בהפקת דוחות רווח והפסד לפי6מחלקה/יחידה/וכד'

. תמיכה בדיווח לפי מגזרי הפעילות של הארגון7

. אפשרות לייצוא קובץ מאזן בוחן מלא לרואה8החשבון המבקר

. המערכת תאפשר שליפה וייצוא נתונים לצורך9ביאורים בדוחות הכספיים, כולל:

א. שליפת יתרות של מספר חשבונות לצורךביאור

ב. שליפת יתרות לפי שדות מסוימים או נתוניםאחרים הקיימים בפקודה/נתוני אב

34

סגירת תקופה5.1.1.4.3ומעבר שנה

. אפשרות לסגירת ופתיחת תקופות לפי חודשים1או שנים, לפי כרטיסים שונים וחתכים שונים

 

. תמיכה בתקופות דיווח נוספות לצרכים לאחר2 סגירת הספרים – לדוג' פקודות יומן של רואה

חשבון מבקר

. תמיכה בניהול מערכת רב שנתית ומעברי3שנים

. העברה אוטומטית של יתרות סגירה של4תקופה ליתרות פתיחה בתקופה העוקבת

 המערכת תאפשר לנהל מספר חברות במערכתניהול חברות5.1.1.4.4

ניהול רישום5.1.1.4.5חשבונאי

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

 

ניהול ספר ראשי5.1.1.4.6וספר משני

המערכת צריכה לאפשר לנהל במקביל שני ספרים: ספר חשבונאי לצורך הפקת דוחות

כספיים וספר כלכלי לצורך ניהול התקציב והפקתדוחות תקציביים

 

35

רוב הרישומים יירשמו במקביל בשני הספרים אולם ייתכנו רישומים שונים הנובעים מדרישות

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

מודול רכוש קבוע וחלקם נובעים מפקודות ידניות.

דוגמאות: רכש של רכוש קבוע נרשם בדוחות הכספיים כנכס ) במודול נכסים( ומופחת לאורך

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

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

משפטיות- יירשמו רק בספר החשבונאי

אלוקציות שלא אמורות להשפיע על הדוחותהכספיים יירשמו רק בספר הכלכלי

36

ניהול ספר ראשי5.1.1.4.7וספר משני

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

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

Drill Downברמת ההפרש שיראה את פקודות היומן שגרמו להפרש

 

הקמת/תחזוקת5.1.1.4.8GLרשומת אב

. ניהול נתונים לחשבון, כגון:1

 

א. תיאור חשבון – במס' שפות

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

ג. קבוצת חשבון

ד. סטאטוס חשבון )חסום לרישום, פעיל וכד'(

ה. סוג חשבון – תוצאתי או מאזני

ו. כספי/לא כספי

ז. מטבע שערוך, סוג שערוך

ח. שיוך למיון בדוחות הכספיים

ט. תמיכה בהגדרת שדות מסוימים כשדותחובה

י. שדות נוספים לפי הגדרת הארגון

37

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

– חסום לרישוםGL. ניהול סטאטוסים לחשבון 3וכד'

שורות פתוחותGL. אפשרות לניהול חשבון 4)ביצוע התאמות(

לרישומיםGL. אפשרות לחסימת חשבון 5 שכר מסוימים ניתןGLמסוימים. לדוג' סעיפי

יהיה לרישום רק דרך ממשק שכר

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

אינדקס חשבונות5.1.1.4.9

. אפשרות לניהול אינדקס חשבונות לפי קבוצות1)כגון קיבוץ הוצ' הנה"כ(

  . תמיכה בשליפת דוחות של אינדקס חשבונות2

לפי קריטריונים שונים – קבוצת חשבון, סטאטוס,סוג חשבון וכד'

38

5.1.1.4.10account determination

שלchart of accountכחלק מכתיבה מחדש של ה האוניברסיטה- צריך להתייחס להשפעת השינוי

accountעבור כל מודול בהקשר של determination :מודולים ( MM,AA,SD,CM,FI-

CA,AP,AR)

 

שערי חליפין,5.1.1.4.11מדדים, ריביות

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

היסטוריה של נתונים אלה

 

. תמיכה בניהול שע"ח רבים למטבע אחד )שער2קניה, שער מכירה וכד'(

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

. תמיכה בעדכון ידני של שערי חליפין, מדדים4וריביות

. תמיכה בניהול מספר מדדים נבחרים )מחירים5לצרכן וכד'(

. תמיכה בניהול מדדים לפי בסיסים שונים6

. תמיכה בניהול מספר ריביות נבחרות )פריים7וכד'(

39

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

רכש וכד'(

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

ניהול שערוכים5.1.1.4.12

. תמיכה בביצוע שערוכים אוטומטיים לחשבונות1המוגדרים לשערוך

  . השערוך יבוצע לפי שע"ח המוזן בטבלאות2שערי החליפין והמוגדר בנתוני אב

. אפשרות להזנת שערי חליפין ידניים לשערוך3

ניהול מטבעות5.1.1.4.13תרגום ושערוכים

המערכת תאפשר לנהל מספר מטבעות ולבצע תרגום מלא ברמת הטרנזקציה לכל סוג מטבע

בהתאם לטבלת שערים מוגדרת מראש 

ניהול מטבעות5.1.1.4.14תרגום ושערוכים

המערכת תאפשר לבצע אילוץ לשער המטבע ע"ישלוש דרכי פעולה:

  - בחירת תאריך הערך הנדרש1

- קיבוע השער הנדרש2

- הזנת הסכום הנדרש במטבע3

40

יש להבחין בין שלושה סוגי אילוצים מבוקשים:

אילוץ שער ממטבע טרנזקציה למטבע מערכת

אילוץ שער ממטבע טרנזקציה למטבע הקבוצה)השונה ממטבע המערכת(

אילוץ שער ממטבע מערכת למטבע הקבוצה,ללא קשר למטבע הטרנזקציה

אילוץ שער ממטבע טרנזקציה למטבע החשבון

אחת הדוגמאות לצורך באילוץ: במידה ותרומה התקבלה במטבע השונה משקל יש לקבע את

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

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

לאלץ את שער המטבע לפי תאריך קליטת הכסףולא לפי תאריך הפקת הקבלה.

ניהול מטבעות5.1.1.4.15תרגום ושערוכים

המערכת תאפשר לנהל חשבונות מסוימים בארבע מטבעות:

. מטבע הטרנזקציה1

41

(ILS. מטבע פונקציונאלי ) 2(USD. מטבע הקבוצה )3. מטבע החשבון4

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

ממטבע התנועה למטבעות השקלי והדולרי) השערוך מתעלם בפועל ממטבע התנועה(

ניהול מטבעות5.1.1.4.16תרגום ושערוכים

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

בכל מטבע בנפרד ) גם בשקל וגם בדולר(.הפרשי השערוך ירשמו לסעיף מימון

 

42

ניהול מטבעות5.1.1.4.17תרגום ושערוכים

המערכת תאפשר לבצע שערוך אוטומטי של יתרת המחקרים ) הכנסות שהתקבלו עבור המחקר פחות ההוצאות שנוצלו בתקופה(:

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

תשקף את היתרה )היתרה משתקפת בחיבור של ולא יתרה של סעיף מאזני(P&Lשני סעיפי

במטבע המחקר לפי שער סוף תקופה

 

במקרה זה תבוצע פקודת יומן ) פקודת שיערוך( לתיקון היתרה השקלית כאשר מטבע המחקר

0הוא

דוגמא:

מנוהל באירו שבו נרשמו הכנסותXקיים מחקר , שער האירו ביום זה1.1.2018 אירו ב1000של . במועד קבלת ההכנסה בפרופיט נרשמה4הוא

פקודה

אירו השווים במועד ההכנסה1000חובה- בנק שקלים4000

,Xזכות-הכנסות מחקר

43

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

בפרופיט נרשמה הפקודה

השוויםX אירו הוצאות שכר מחקר 350חובה- שקלים1200במועד הפקודה

זכות- בנק

. כעת4בסוף החודש שער האירו עומד על מתבצעת בדיקה של ההכנסות מול ההוצאות

אירו650שווי היתרה באירו-

שווי היתרה בשקלים, לפני ביצוע שיערוך הוא שקלים בגין200 שקלים -נוצר פער של 2800

2600 שקלים זה 4 אירו כפול 650הפרשי שער ) שקלים זה1200 שקלים פחות 4000שקלים,

שקלים(2800

44

ניהול מטבעות5.1.1.4.18תרגום ושערוכים

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

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

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

 התשלום(

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

התנועה ) על מנת להימנע מתהליכי שיערוך שלסוף חודש( והן במטבע החברה

ניהול מטבעות5.1.1.4.19תרגום ושערוכים

: ביצועהמערכת תאפשר לבצע פקודות תיקון פקודת יומן במטבע נבחר תוך כדי בחירה שלא

יבוצע תרגום למטבע נוסף עבור פקודה זו ) כיום מבוצע באמצעות שדה ייעודי בפקודת היומן - סוג

התנועה(

 

45

ניהול מטבעות5.1.1.4.20תרגום ושערוכים

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

תתורגם למטבע הספק השונה ממטבע הקבוצה)לכל ספק מטבע ייחודי לו(

 

ניהול מטבעות5.1.1.4.21תרגום ושערוכים

צמודיםGLהמערכת תאפשר לנהל כרטיסי למטבע- המשמעות היא שכל טרנזקציה מול

תתורגם למטבע שהוגדר לכרטיסGLכרטיס ה) צמוד מטבע(

 

ניהול מטבעות5.1.1.4.22תרגום ושערוכים

ניהול מקדמות לספקים:

 

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

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

* המערכת תאפשר לנהל את רישום התחייבותבמטבע אחד מול תשלום במטבע אחר

46

ניהול מטבעות5.1.1.4.23תרגום ושערוכים

המערכת תאפשר לנהל קרנות צמודות למטבע- המשמעות היא שכל טרנזקציה מול הקרן תתורגם

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

המערכת תתרגם את התנועה מאירו לדולר. החל מרגע זה השערוך יהיה מהדולר למטבע

הפונקציונלי ) שקל(

 

ניהול מטבעות5.1.1.4.24תרגום ושערוכים

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

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

למשל שער שלא התקבל

 

ניהול מטבעות5.1.1.4.25תרגום ושערוכים

הפרשי שער בגין תהליכי שערוך ספקים בספריה יירשמו כהוצאה ולא בהוצאות מימון

מידוד5.1.1.4.26

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

קרנות אזילות וצמיתות, הפרשי המימון ירשמוכנגד סעיף הכנסות/ הוצאות מימון

 

47

פקודות יומן5.1.1.4.27

. תמיכה באפשרות לרישום פקודות יומן ממספר1מקורות:

 

א. פקודות יומן מורכבות ידניות

ב. פקודות יומן המתקבלות בממשק )ממשקשכר לדוג'(

(EXCEL,XML ג. פקודות יומן מקובץ חיצוני )

ד. פקודות יומן אוטומטיות )העמסות,שערוכים, תקופתיות וכד'(

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

. תמיכה בקליטת פקודות יומן אשר יכללו את2הנתונים הבאים:

. מרכז עלות, מרכז רווח, הזמנת פנימית,3פרויקט, קרן וכד'

. סעיף תקציבי, קרן תקציבית4

, נכס, לקוח, ספקGL. חשבון 5

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

. תמיכה ברישום פקודות יומן וביטולם אוטומטי7בתקופה העוקבת )הוצ' לשלם וכד'(

48

. תמיכה ברישום פקודות יומן עתידיות ופיצולם8לפי החלק היחסי בתקופה )לדוג' הוצ' מראש(

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

תרגום שע"ח וכד'

. אפשרות לחסימה פקודות יומן ורישומים10 לתקופות מסוימות לפי חשבונות שונים. לדוג'

1-6 מסוים לתקופה GLחסימת טווח חשבונות

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

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

החליפין

 המערכת תאפשר לנהל ולתחזק קודי מע"מניהול קודי מע"מ5.1.1.4.28

49

5.1.1.4.29Sub Accounts

שיאפשרSub Accountהמערכת תאפשר לנהל רישום ודיווח חשבונאי מפורט יותר מרמת

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

אליו ולבצע ניתוחים כגון: רישום מקור הכסף )גורם ציבורי – ממשלתי או מוסדי, פרטי וכו'(

DDבעת הזנת החו"ז בגין תרומות , בשלב ה Subיוחלט כיצד לממש את שדות העזר/

accountכגון: פתיחת חשבונות – אופציה( מועדפת, שימוש באובייקט תמחירי וכו'(, בכל

יש לבחון שניSub Accountמקרה של שימוש ב נושאים:

 

GL. האם הפקודה מגיעה מספרי העזר או ב 1

Sub Account. האם נדרש שהאכלוס של ה 2 יהיה ידני או אוטומטי )ע"ס לוגיקה שתוגדר

מראש(

50

5.1.1.4.30Sub Accounts

המערכת תאפשר להפיק דוחות לגורמים שונים Sub Accountשישלפו את החשבון עם ה

הרלוונטי ) לדוגמא: סוג הוצאה של רכב, מעמדשל עובד, מספרי רכב, מספר ת"ז של סטודנט(

 

5.1.1.4.31Sub Accounts

המערכת תאפשר לזהות את מקור המימון )הגורם המממן- פירות קרן צמיתה, תמיכת

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

sub accountsבנוגע לניהול

 

פתיחת כרטיסי5.1.1.4.32GL

המערכת תאפשר פתיחת כרטיסי הוצאה שונים ) ספרים, כתבי עת, השב"ס( על מנת שניתן יהיה

ברזולוציה מפורטת יותרSAPלייצג את המידע ב מאשר ברמת שורה בודדת ) דרישה של

הספרייה(

 

51

תקציבים פנימיים5.1.1.4.33

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

הפעילות לבין הדו"ח על השינויים. תירשם פקודת יומן ידנית על בסיס דוח "דו"ח ליצירת פק' יומן

להעברת יתרות מחקרים פנימיים" )קיימת דרישה מפורטת עבור דוח זה בפירוט הדוחות

המבוקשים(:

  CC * חובה- הכנסות )אין שיקוף של ההספציפי(

* זכות- נכסים נטו שקיימת לגביהם הגבלהזמנית

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

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

* חובה- נכסים נטו שקיימת לגביהם הגבלהזמנית

52

ספציפיCC * זכות- הכנסות +

ספציפיCC * זכות- הכנסות +

קקמ"ב5.1.1.4.34

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

 

- נדרשAS400מערכת קקמ"ב יושבת היום על ה:SAPלהעביר את כל התכולה שלה ל

קקמ"ב5.1.1.4.35 במטבעFUNDהמערכת צריכה לאפשר לנהל

הקרנות1,000 על כל אחת מFUNDדולר, הקיימות כיום ) קרן לכל עובד זכאי(

 

המערכת צריכה לאפשר העברה של יתרת הקקמ"ב5.1.1.4.36FUNDבין שנים  

קקמ"ב5.1.1.4.37 FUNDהמערכת צריכה לאפשר לבצע שיערוך ל ולכן הוא צריך להיות אובייקט כספי כנגד

הוצאות/הכנסות מימון 

53

קקמ"ב5.1.1.4.38

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

משקפת התחייבות במידה ולא מומשה )למשל טיסה שאושרה ועדיין לא נרכשה(- המערכת

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

 

קקמ"ב5.1.1.4.39

Master Dataהמערכת תאפשר לנהל סוג עובד ב של העובד בשדה ייעודי. עפ"י שדה זה יחולקו

העובדים לאוכלוסיות לפי דרישה לדוגמא: עובדים פעילים זכאים מראש, עובדים פעילים לא זכאים

 מראש, עובדים לא פעילים.

המערכת תאפשר לייצא דוח של נתוני העובדשיכיל את שדה זה

54

קקמ"ב5.1.1.4.40

חישוב הזכאות של איש הסגל מבוצע ע"י מל"מ, בגיןFIמצב זה יישאר. יש לייצר ממשק ממל"מ ל

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

 

קקמ"ב5.1.1.4.41

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

עתידית. המערכת תאפשר לפתוח התחייבות כנגד הקרן של המרצה ) בדומה למהFMידנית ב

(GMשקורה היום ב

 

-מעונותFIממשק 5.1.1.4.42

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

תשלומים ששולמו עבור שכ"ד- ולכן יש לייצר -מעונות ורישום אוטומטי בגין הוצאותFIממשק

אלו

 

ממשק חדש בגין החזרי שכר לימוד לילדים שלFI-HRממשק 5.1.1.4.43 (FI-HRעובדים ) ממשק

55

קליטת נתונים5.1.1.4.44מקובץ

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

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

סטודנטים, המידע100בניסוי לוקחים חלק עליהם מנוהל בקובץ אקסל ולאחר סיום הניסוי יש

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

 

גורם מממן5.1.1.4.45

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

מוסד זה מעביר את הכסף לשותפים (, יש מצבים בהם הגורם המממן והגורם המשלם אינו אותו

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

המערכת תאפשר להפיק דיווחים אל מול כל אחד מהגורמים בשרשרת עפ"י דרישת המשתמש ) בדוגמא דוח גיול מול אוניברסיטת תל אביב

וודוח הכנסות והוצאות מול משרד המדע(

 

56

ממשק שכר -נכנס5.1.1.4.46(SAP)

יש להקים ממשק שכר נכנס למערכת הפיננסית (, בהתאם לרזולוצייתFI-CO )מודול SAPב-

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

יחידה ארגונית/מרכז עלות, חלוקה לפי סוגי /הזמנות פנימיות, חלוקה לפיGLחשבונות

WBS-ים שונים ועוד, ועל בסיס התאמת מבנה ה GL -וה CCהקיימים במערכת ו/או אלו שיוקמו

במסגרת הטמעת המודלים הפיננסים של מערכתSAPה-

 

57

ממשק שכר -נכנס5.1.1.4.47(SAP)

על המערכת לאפשר ביצוע מספר בדיקות הן על תהליך ממשק השכר עצמו )העברת

הנתונים/קובץ ממערכת אחת לשנייה(, הן והןSAPבתהליך קליטת הקובץ לתוך מערכת ה-

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

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

לנטר ולבדוק תקלות הן ברמת כלל הנתונים והןברמת נתון בודד שעובר במסגרת ממשק זה

 

ממשק שכר -נכנס5.1.1.4.48(SAP)

על המערכת לאפשר בדיקה ואף חסימה )יוגדר בהמשך ע"י המשתמשים האם יש צורך בחסימה

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

הראשון או כל פתרון אחר לעדכון הפקודהשנקלטה כבר.

 

58

ממשק שכר -נכנס5.1.1.4.49(SAP)

על המערכת לאפשר, קליטה/זיהוי/המרה/הגדרת טבלאות ו/או כל פתרון אחר שיוצא לצורך המרת

מספרי חשבונות ישנים מהמערכת הפיננסית הישנה למספרי חשבונות חדשים במערכת ה-

SAPלטובת ממשק השכר וזאת בעקבות הסבת נתונים מהמערכות הישנות.

 

סגירת סעיף5.1.1.4.50הכנסות לקבל

רישום הכנסות לקבל בעת התשלום ) זיכוי ההכנסות לקבל( בגין סטודנט מעורב המשלם גם

עבור תקציב אקדמי וגם תקציבים סגורים:

  בעת צפי ההכנסה: יש רישום של הכנסות מול

הכנסות לקבל במיון לפי אקדמי או סגור

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

אקדמי או תקציב סגור

59

ניהול שבתונים5.1.1.4.51בחו"ל

במידה ונוצר הפרש שער צריך להעביר אותו אוטומטית לכרטיס של הוצאות שכר/מימון

( הסיבה שיכוליםDD) בהתאם להחלטה ב להיווצר פערי שער היא מכיוון שהסכום שמגיע

ממל"מ הוא דולרי והמרצים מבקשים לעתיםסכום שקלי

 

פורטל סגל- טופס5.1.1.4.52מלגות ממחקר

גדולה מגובהCM מ ACTבמידה ופקודת ה ACTההתחייבות המערכת תחסום את רישום ה

CMב  

5.1.1.4.53Functional area המערכת תדע לשייך אוטומטיתFunctional area  GL + Cost Centerלפי שילוב של כרטיס

ועד 5.1.1.4.54כל הדרישות העסקיות " ויש לתמחר אותן בנפרד מהתמחוראופציה הינן בקטגוריית "5.1.1.4.57 1 יש למלא בשורה המתאימה בנספח בגין כל אופציה בנפרד Fix Priceאת התמחור ( של הפרויקט. Fix Priceהכולל )

.בנספח זה אין למלא מחיריםלמסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(.

60

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

ניהול פקסים5.1.1.4.54

SAPלבצע קישור למערכת פקסים- לוודא ש- מתממשקת למערכת עידור הקיימת היום או

לכל תכנה שהאוניברסיטה תבחר לניהולפקסים

 

הרצת שערוך באופן5.1.1.4.55ידני

יש לאפשר הרצה ידנית של התכנית המבצעת על סמךCommitmentשיערוך/הצמדה של ה

שיקול דעת של המשתמש )ע"מ לאפשר לאלשערך כאשר הפרשי השער אינם מהותיים(

 

5.1.1.4.56 רישום הכנסות עבור תקציבים

מותנים

המערכת תאפשר לשייך הכנסות באופן ידני (GLליחידה ארגונית )פקודת יומן ידנית ב

DMיישום מודול 5.1.1.4.57

המערכת תאפשר הפקה של דוחות וורד עבור עמודים( ודוח תקציב30דוח כספי שנתי )כ עמודים( ומצגות100של אגף כלכלה )כ

עמודים(. דורש יישום של מודול15הנהלה )כ DM

 

61

גזברות.5.1.2

תיאור מצב קיים- כללי.5.1.2.1

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

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

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

חשבונות מרכזים ) אחד לכל בנק(:.5.1.2.1.2.3 בסוף כל יום מתבצעת העברת יתרות מתוך החשבונות הייעודיים לתוך החשבון.5.1.2.1.2.3.1

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

תשלומים תתבצע העברה של כספים מהחשבון המרכז אליו כחלק מהמהלך הלילישתאפס את היתרה

התנהלות כספית נוספת, למשל תקבולים מות"ת, תשלומים שונים.5.1.2.1.2.3.3כל ריצת תשלום צריכה לעבור אישור של מחלקת גזברות..5.1.2.1.3 ניהול הנכסים הפיננסיים של האוניברסיטה ) תיק ההשקעות ( מבוצע באמצעות מערכת חיצונית שנקראת.5.1.2.1.4

מערכת פריים.האוניברסיטה עובדת ע"ב מזומן..5.1.2.1.5

62

63

64

תיאור מצב קיים.5.1.2.2

ניהול בנקים והתאמות בנקים.5.1.2.2.1 המידע בנוגע לחשבונות הבנק של שכר הלימוד לא מתועד במערכת המידע ולכן אין אפשרות.5.1.2.2.1.1

ניהול באופן פרטני של חשבונות בנק שכר לימוד לרבות התאמות בנקים.בנקים.5.1.2.2.1.2 עמלות לרבות חשבונאי רישום )כולל לימוד שכר בהתנהלות הגזברות לדרישות

.CMוהתאמות בנקים( – ראה פירוט תחת פרק ניהול השקעות.5.1.2.2.2

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

כל תנועה שנוצרת בפריים מועברת בממשק לפרופיט..5.1.2.2.2.2התאמות הבנקים של חשבונות ההשקעה מתבצעות בתוך מערכת ההשקעות..5.1.2.2.2.3חלק קטן מההשקעות מתנהלות בחשבון המרכזי הראשי ולא בחשבון ההשקעות..5.1.2.2.2.4

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

בפועל שמשפיעות עליו.ניהול ערבויות שהאוניברסיטה מקבלת.5.1.2.2.4

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

ניהול ערבויות שהאוניברסיטה נותנת.5.1.2.2.5האוניברסיטה נותנת ערבויות לגורמים שונים כגון ערבויות למכס..5.1.2.2.5.1הגזברות מנהלת גם הוראות קיזוז המשמשות כתחליף לערבות..5.1.2.2.5.2הניהול של הערבויות והוראות הקיזוז מבוצע היום באופן ידני באקסל..5.1.2.2.5.3עבור ערבויות שהאוניברסיטה נותנת, יש רישום ידני של פקודות יומן בגין עמלות בנקים..5.1.2.2.5.4

ניהול הלוואות.5.1.2.2.6

65

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

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

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

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

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

עבור רכיבי הוצאה- נרשמת פקודת יומן אוטומטית..5.1.2.2.7.2.2עבור רכיבי מס- נרשמת פקודת יומן אוטומטית..5.1.2.2.7.2.3

סוגי תקבולים.5.1.2.2.8מערך הגזברות מנהל שני סוגים של תקבולים.5.1.2.2.8.1

תקבולים המתקבלים בקופה.5.1.2.2.8.1.1מזומן.5.1.2.2.8.1.1.1המחאות.5.1.2.2.8.1.1.2

תקבולים המתקבלים מהבנקים או מחברות אשראי.5.1.2.2.8.1.2העברה בנקאית.5.1.2.2.8.1.2.1כרטיסי אשראי.5.1.2.2.8.1.2.2

את התקבולים מהעברה בנקאית ניתן לסווג לשלושה סוגים:.5.1.2.2.8.2תקבול מבוסס חשבונית.5.1.2.2.8.2.1תקבול אל מול סטודנט או תורם מזוהה.5.1.2.2.8.2.2תקבול ללא מקור ידוע.5.1.2.2.8.2.3

66

ניהול קרנות.5.1.2.2.9 400האוניברסיטה מקימה קרנות צמיתות מתרומות עפ"י בקשת התורמים. ) כיום קיימות כ-.5.1.2.2.9.1

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

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

גם הקבלה לריבית השנתית שניתנה ) = הקבלת האוצר(, לכל קרן מנוהלים שני חשבונות: חשבון קרן וחשבון פירותGLכיום הקרנות מנוהלות ככרטיסי .5.1.2.2.9.3הקרנות צמודות למדדים/מטבעות שונים בעוד שחשבון הפירות של הקרנות הוא שקלי בלבד.5.1.2.2.9.4 האוניברסיטה משקיעה את הכספים שקבלה בשוק ההון ע"מ להשיג תשואה שתהיה לפחות.5.1.2.2.9.5

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

בפועל, האוניברסיטה תספוג הכנסות/ הוצאות מימון תיאור מצב נדרש.5.1.2.3

ניהול בנקים והתאמות בנקים.5.1.2.3.1 כל חשבונות הבנק של האוניברסיטה ינוהלו במערכת המידע הפיננסית . מחלקת גזברות תוכל.5.1.2.3.1.1

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

ניהול ההשקעות לרבות קליטת דפי בנק והתאמות בנקים במערכת הפריים ושיקוף פקודות.5.1.2.3.2.1.DD ברמה סיכומית שתוגדר ע"י הכספים בשלב ה FIהיומן במודל

ושם.5.1.2.3.2.2 בלבד הפריים במערכת יקלטו ההשקעה בגין חשבונות בנק דפי - חשבונות השקעה תתבצע התאמת בנקים )ללא שינוי מהמצב בנוכחי(.

ושםFIחשבון מרכז )המכיל גם פעילות השקעה ופעילות נוספת( – דפי הבנק ילקטו במערכת .5.1.2.3.2.3תתבצע התאמת בנקים.

ניהול תזרים מזומנים.5.1.2.3.3

67

ניהול תזרים מזומנים בפועל ינוהל במערכת- בהמשך יוחלט אם להשתמש במודול ייעודי של.5.1.2.3.3.1SAP.או בכלי חיצוני

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

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

רלוונטיים באוניברסיטה. לדוגמא תשאול אנשי רכש האם להמשיך ערבות מול ספק מסוים.ניהול ערבויות שהאוניברסיטה נותנת.5.1.2.3.5

ניהול תפעולי של הערבויות/הוראות קיזוז במערכת מידע. המערכת תאפשר לקשור בין הערבות.5.1.2.3.5.1לבין היחידה הארגונית המזמינה ) מרכז עלות(.

ניהול הלוואות.5.1.2.3.6 או בכליSAPהלוואות ינוהלו במערכת מידע, בהמשך יוחלט אם להשתמש במודול ייעודי של .5.1.2.3.6.1

חיצוני.ניהול שבתונים בחו"ל.5.1.2.3.7

התאמת ממשק מל"מ:.5.1.2.3.7.1 עבור רכיבי השכר בדולרים- פקודה אוטומטית לרבות מיון בין הוצאות לבין הוצאות.5.1.2.3.7.1.1

מראש.עבור רכיבי הוצאה- נרשמת פקודת יומן אוטומטית..5.1.2.3.7.1.2עבור רכיבי מס- נרשמת פקודת יומן אוטומטית..5.1.2.3.7.1.3

בגין רכיבי השכר בדולרים ממשק מל"מ ייצר הוראת תשלום שתכיל את פרטי הבנק של העובד.5.1.2.3.7.2בחו"ל ) ייתכנו מקרים שבהם יידרש שינוי פרטני של חשבון בנק העובד(.

סוגי תקבולים.5.1.2.3.8 המערכת צריכה לתמוך בכל אמצעי התשלום הקיימים היום ובנוסף באמצעי תשלום נוספים.5.1.2.3.8.1

PAYPALכגון FIהתקבולים ינוהלו במערכת .5.1.2.3.8.2

ניהול קרנות.5.1.2.3.9

68

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

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

מדד תשומות בניה – מדד ידוע ומדד בגין( השערוך יהיה כנגד הכנסות/ הוצאות מימון. קטגוריות( באופן5-10המערכת תאפשר לשייך את כל אחת מהקרנות לקטגוריה לפי מטבע ).5.1.2.3.9.3

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

פירוט דרישות עסקיות בנושא גזברות.5.1.2.4

( 4.5% משקל הדרישות העסקיות בנושא גזברות בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש הינן בקטגוריית "5.1.2.4.15 ועד 5.1.2.4.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

התאמות בנקים5.1.2.4.1

. אפשרות לביצוע התאמות בנקים1

 

. תמיכה בקליטת ממשק יומי של דפי הבנק2

. תמיכה בביצוע התאמות אוטומטיות בעת3 קליטת דפי הבנק לפי קריטריונים שיוגדרו

מראש

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

69

א. עמלות וריביות יירשמו לסעיפי הוצאה/הכנסההמתאימים

ב. תשלומים לספקים יירשמו לחשבונותהספקים המתאימים

ג. תקבולים מלקוחות יירשמו לחשבונותהלקוחות המתאימים

ד. ועוד

. אפשרות לביצוע התאמות בנק ידניות –5חלקיות או מלאות

. אפשרות לדוח המציג שורות מותאמות,6שורות פתוחות

. אפשרות לביטול התאמה שנעשתה.7

תקבולים5.1.2.4.2והתאמות בנקים

תירשם פקודתFIעל בסיס דף הבנק שייקלט ביומן

 

בעת קבלת התקבול: חובה- בנק שכר לימוד

זכות- הכנסות לקבל ) נדרשת הפרדה ביןתקציב סגור לאקדמי(

בגין שורות עמלה תירשם פקודה:

חובה- הוצאות עמלה זכות- בנק שכר לימוד

במהלך לילי תבוצע פקודת יומן נוספת

70

חובה- בנק מרכז זכות- בנק שכר לימוד

התאמות כרטיסי5.1.2.4.3אשראי

. אפשרות לביצוע התאמות כרטיסי אשראי1

 

. תמיכה בקליטת ממשק מחברות כרטיסי2 אשראי – כולל תקבולים ומיון לכרטיסים

המתאימים )עמלות, הכנסות וכד'(

. אפשרות לביצוע התאמות אוטומטיות בעת3קליטת הממשק לפי קריטריונים שיוגדרו מראש

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

. אפשרות לביטול התאמה שנעשתה5

בנקים5.1.2.4.4

המידע בנוגע לחשבונות הבנקים לרבות חשבונות בנק של שכר לימוד ישוקף במערכת

המידע. המערכת תאפשר לייצא דוחות עפ"י חתכים נדרשים

חיתוך עפ"י תאריכים:נתוני יתרות

נתוני תנועות

ניהול תשלומים5.1.2.4.5. תמיכה בביצוע תשלומים במגוון דרכים, כגון:1

  א. כרטיסי אשראי ב. שיקים

71

ג. מזומן ד. העברות בנקאיות

ה. הוראות קבע ו. הוראות העברה

ז. מס"בPAYPAL ח.

ט. תשלום לספקי חו"ל - כולל ממשק לבנקישראל לפי דרישות רגולטוריות

י. תשלומים לבנקים לרבות ממשק מס"ביהיו לפחות לכל הבנקים הקיימים כיום במערכת

. תמיכה בתשלומים מהסוגים הבאים:2

א. תשלום ידני

ב. תשלום כנגד חשבונית פיננסית/לוגיסטית

ג. תשלום כנגד קבלת טובין שנעשתה

ד. תשלומים לצד ג' )חברה שונה, עיקוליםוכד'(

ה. מקדמות לספקים ו. תשלומים לעובדים אשר אינם חלק

מהשכר הרגיל ז. ועוד

72

. יכולת לתשלום במטבע שונה ממטבע3 המסמך או מטבע הספק )המערכת תאפשר

ניהול תשלומים לפחות בכל המטבעותהמנוהלים היום באוניברסיטה(

 

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

לחסום שורות מסוימות לתשלום ולהוסיף שורותידנית

 

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

. חסימת תשלום לספק אשר אין לו אישור6ניהול ספרים בתוקף

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

היומן בהתאם

. אפשרות בהפקת מכתבי תשלום לספקים,8 בנקים ושאר גופים הקשורים לתשלום. הפקת

המכתבים תוכל להיעשות במייל, פקס, הדפסהלפי המוגדר בספק

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

73

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

מערכת תשלומים5.1.2.4.6לזכאים שונים

כיום מערכת תשלומים לזכאים שונים מושתתת . המערכת מאפשרת תשלומיםAS400על

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

CMקולטת קובצים ממודולים שונים כגון מודול ומאפשרת עיבוד של הקובץ )כגון מחיקות של

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

AS400מערכת ה

 

ניהול תשלומים5.1.2.4.7ברשת

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

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

: בנק מול הסעיףFIבטרנזילה יהיה אוטומטי בהתקציבי הרלוונטי

 

74

ניהול תקבולים5.1.2.4.8לא מזוהים

בעת קבלת תקבול לא מזוהה מהעברה בנקאית, לא תיווצר קבלה אוטומטית מתוך דף

הבנק והתאמת הבנק תהיה פתוחה בגין תקבולזה.

 

ניהול תקבולים5.1.2.4.9מזוהים

בעת קבלת תקבול מזוהה מהעברה בנקאית-תיווצר קבלה אוטומטית מתוך דף הבנק

 

המערכת תזהה את כרטיס ההכנסות המתאיםעפ"י סוג התקבול

פורמט הדפסה5.1.2.4.10לקבלות

פורמטי הדפסה2המערכת תאפשר לייצר לקבלות: כאשר מפיקים קבלה צריך גמישות

"- פורמט הדפסה46בנוגע להערה של "סעיף ייעודי לתורמים. כיום כל קופה הוקמה פעמיים-

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

 

75

ניהול קרנות5.1.2.4.11

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

חיצוני, לדוגמא הנחיות שמתקבלות מות"ת(

 

ניהול קרנות5.1.2.4.12

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

בגין( השערוך יהיה כנגד הכנסות/ הוצאות מימון

 

ניהול קרנות5.1.2.4.13

המערכת תאפשר לשייך את כל אחת מהקרנות קטגוריות( באופן5-10לקטגוריה לפי מטבע )

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

זו לשנה נבחרת

 

ניהול שבתונים5.1.2.4.14בחו"ל

המערכת תייצר רישום אוטומטי בגין ממשק על בסיס מצטבר:FIמל"מ ב

  פקודות היומן שהממשק צריך לייצר הן

חובה- הוצאות למרצה חובה- הוצאות מראש

76

חובה- מס הכנסה זכות- מרצים לשלם

זכות- מס הכנסה לשלם

ניהול שבתונים5.1.2.4.15בחו"ל

בגין תשלומים לחו"ל כגון: רכיבי שכר בדולרים למרצים בשנת שבתון, ממשק מל"מ ייצר

הוראת תשלום שתכיל את פרטי הבנק של העובד בחו"ל ) ייתכנו מקרים שבהם יידרש שינוי

פרטני של חשבון בנק העובד( 

לאחר אישור הוראת התשלום ייוצרו פקודותהיומן הבאות באופן אוטומטי:

חובה- מרצים לשלם חובה- מס הכנסה לשלם

זכות- בנק

77

" ויש לתמחר אותןאופציה הינן בקטגוריית "5.1.2.4.22 ועד 5.1.2.4.16כל הדרישות העסקיות בגין כל אופציה בנפרדFix Price( של הפרויקט. את התמחור Fix Priceבנפרד מהתמחור הכולל )

בנספח למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(.1 בנספח יש למלא בשורה המתאימה .זה אין למלא מחירים

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

5.1.2.4.16

העברת תשלום אוטומטי

לחשבונות בנקבחו"ל

המערכת תאפשר לבצע תשלום אוטומטי לחשבונות בנק בחו"ל )דומה למס"ב( עבור

זכאים שונים כגון: מרצים בשנת שבתון  

ניהול הלוואות5.1.2.4.17

• תמיכה בניהול הלוואות, כגון:

 

א. בנקאיות/חוץ בנקאיות במטבעות שונים

ב. הלוואות לעובדיםOn call ג. הלוואות

ד. הלוואות בלון

ה. הלוואות זמן קצר/זמן ארוך

ו. תמיכה בניהול הלוואות במטבעות שונים,שערים ומדדים

• אפשרות לניהול נתונים הבאים להלוואות:

א. סכום ההלוואה ב. תאריך קבלת הלוואה

78

ג. תאריך סיום ההלוואה ד. תאריכי פירעון

ה. צמוד מדד/מטבע – כולל פרטי הצמדה

ו. סוג ההלוואה ז. מטרת הלוואה

ח. אם הלוואה לעובדים – פרטי העובד

ט. מקור ההלוואה י. אחוז ריבית ההלוואה

יא. בטחונות שניתנו כנגד ההלוואה

יב. סיבת לקיחת ההלוואה

GL לרישומי הריבית, חשבון GL יג. חשבון לרישום פירעון ההלוואה

ניהול הלוואות5.1.2.4.18

תמיכה בהלוואה צמודה חלקית/מרובה

 

• תמיכה בחישוב לוחות סילוקין

• תמיכה בניהול סוגים שונים של ריביות להלוואות, תאריכי פירעון משתנים וסכומי

פירעון משתנים

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

בטבלה לצורך חישובים להלוואות

79

ניהול הלוואות5.1.2.4.19 הלוואות לעובדים – המערכת תאפשר לקזז

את החזר ההלוואה כנגד השכר שלו באופןאוטומטי

 

ניהול הלוואות5.1.2.4.20

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

לבין הגזברות(.CM) נדרש ממשק בין מודול זה צריך להתקיים באינטגרציה עם מתן

ההלוואה בפועל

 

ניהול ערבויות5.1.2.4.21

המערכת תבצע רישום אוטומטי של פקודת יומן בגין עמלות מתוך דף הבנק. הפקודה

 שתירשם היא

חובה- הוצאות מימון זכות- בנק

ניהול השקעות5.1.2.4.22

יש לייצר ממשק להעברת הנתונים ממערכת : הכספים יגדירו מה רמת הפירוטFIהפריים ל

הנדרשת שתעבור בהתאם לדרישות בדוח הכספי ) הרזולוציה הקיימת היום של העברת

כל תנועה ברמת שורה אינה רלוונטית(

 

80

ספקים.5.1.3

רקע.5.1.3.1

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

רישום מע"מ.5.1.3.2

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

מע"מ לרשויות המס בארץ.

חוק מוסר תשלומים.5.1.3.3

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

תנאי התשלום נגזרים מיום קבלת החשבונית..5.1.3.3.2

81

פירוט דרישות עסקיות בנושא ספקים.5.1.3.4

( 4.5% משקל הדרישות העסקיות בנושא ספקים בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש. הינן בקטגוריית "5.1.3.4.19 ועד 5.1.3.4.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

הקמת/תחזוקת5.1.3.4.1רשומת אב ספק

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

 

מרכזיםGL• תמיכה בהגדרת חשבונות לקבוצת ספקים

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

תוך התבססות על הרשאות וסבבי אישורים(WFלביצוע הפעילויות הנ"ל כולל )

אפשרות להשלמת נתונים ייעודיים על ידי מורשים בשלבים )ע"י משתמשים לוגיסטיים

ומשתמשים פיננסיים(

82

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

נדרשת האפשרות לחסום ספק לתשלום עדלסבב אישורים נוסף

• המערכת תאפשר לבצע הפרדה MASTERבאמצעות מאפיין/שדה ייעודי ב

DATAשל הספק כך שניתן יהיה להבדיל - בין ספקים שמוגדרים כזכאים לקבל תמורה

על בסיס פרופורמה לכאלו שלא

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

השינויים

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

אפשרות לחסימת פעולות בהתאםלסטאטוס

• תמיכה בעת פתיחת ספק להתריע/לחסום במידה וקיימת רשומה זהה, על בסיס מספר

ח.פ/ת.ז וכד'

 ניהול נתונים לספק, כגון: הקמת/תחזוקת5.1.3.4.2

83

רשומת אב ספק

א. נתונים כללים: שם ספק )במס' שפות(, , אישEMAILכתובת ספק, טלפון, פקס,

קשר וכד'

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

לפיננסי, ניכוי מס במקור, סוג ספק, מטבעספק

ג. נתונים לרכש: תנאי תשלום נפרדיםלרכש, הצמדות, אנשי קשר לרכש

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

ה. ניהול נתוני מקבל תשלום, מקבל הזמנהוכד'

, פקס,EMAILו. אופן שליחת דיוור לספק – דואר וכו'

ז. פרטי ביטוחיםח. ניהול נתוני המחאת זכות

ט. ניהול נתוני עיקול

י. סימון אפשרות לקבלת חשבונית עסקה

יא. סימון אפשרות לקבלת חשבונית עצמית

יב. צירוף מסמכים לספק כצרופה

יג. תמיכה בניהול טקסט חופשי לספק

84

יד. ספק המפיק פרופורמה/ללא פרופורמה

טו. תמיכה בהגדרת שדות מסוימים כשדותחובה

טז. שדות נוספים לפי הגדרה הארגון

הקמת/תחזוקת5.1.3.4.3רשומת אב ספק

חסימת האפשרות לשנות סטאטוס מסוים לספק כאשר קיימים מסמכים פתוחים לאותו ספק )לדוג' הזמנת רכש פתוחה,

חשבונית לוגיסטית פתוחה וכד'(

 

• אפשרות להצגת חלק מנתוני אב ספק בהזמנת הרכש ומסמכים נוספים )לדוג'

איש קשר יוצג בהזמנת רכש(

• אפשרות לניהול נתוני ניכוי מס במקור לפי סוגי תשלומים שונים )שכר עבודה, שירותים

וכד'(

• תמיכה בממשק מול שע"מ לעדכון נתוני ספק רלוונטיים – שיעור ניכוי מס במקור,

תוקף ואישור ניהול ספרים

• תמיכה בניהול מס' מטבעות לספקוהפקת דוחות בהתאם

• תמיכה בניהול האם הספק מנוהל לקליטת חשבונית לוגיסטית/חשבונית

פיננסית/חשבונית עסקה וכד'

85

הקמת/תחזוקת5.1.3.4.4רשומת אב ספק

MASTER DATAשל הספקים מנוהל כיום  בפרופיט- נדרש לבצע הסבה של הנתונים

דיווח לרשויות5.1.3.4.5

• המערכת תתמוך בדיווחים לפי דרישותהדיווח של הרשויות בארץ, בין היתר:

 

– דיווח מקוון למס856א. תמיכה בדוח הכנסה של ניכוי מס במקור כולל הפקת

הקבצים הנדרשים לקליטה

– תמיכה בדיווח דוח מע"מPCN874ב. מקוון והפקת הקבצים הנדרשים לקליטה

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

• עסקאות אקראי – תמיכה באפשרות לדיווח מע"מ של עסקאות אקראי, לדוג':

פעילות מסחרית חייבת במע"מ

• אפשרות לניהול שיעורי ניכוי ביטוח לאומילספק בהתאם לחוק

התאמות ספקים5.1.3.4.6

• אפשרות לביצוע התאמות בכרטיסי ספק

  • אפשרות לביצוע התאמה חלקית לשורה

)תשלום חלקי מול חשבונית לדוגמא(

86

• תמיכה במתן אפשרות לביצוע התאמותאוטומטיות לפי קריטריונים מוגדרים מראש

• תמיכה בהצגת דוח ליתרות סגורות,יתרות פתוחות, ויתרות מותאמות חלקית

• תמיכה בקליטת קבצים מספקים וגורמיםחיצוניים נוספים והתאמה אוטומטית

דוחות תשלומים5.1.3.4.7

. תמיכה בהפקת דוחות שונים:1

 

א. דוח ריצת תשלומים לפי תאריכים

ב. דוח תשלומים צפויים, כולל תאריכיפרעון

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

ניהול מע"מ5.1.3.4.8

המערכת תאפשר הגדרת שדות חובה בעתDDהקמת ספק- שדות אלו יוגדרו בשלב ה

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

נדרש להעביר מע"מ לרשויות המע"מ בארץעל אף שאינו מחייב מע"מ

87

ניהול מע"מ5.1.3.4.9

ספקים בארץ המותרים ושאינם מותרים בקיזוז מע"מ - שורת מע"מ תהיה מול סעיף

תוצאתי שהינו באותה קבוצת הוצאות של בשורת המע"מ יקבלCCשורת הפריט.

של שורת הפריטCCאת אותו

 

ניהול מע"מ5.1.3.4.10 ספקים בארץ שאינם מותרים בקיזוז מע"מ-

בעת עדכון המע"מ המערכת תעדכן את הCommitment

 

ניהול מע"מ5.1.3.4.11

נותני שירותים בארץ שאין להם ח"פ: מקרה שבו האוניברסיטה סופגת את

המע"מ עבור הפקת חשבוניות לאוכלוסיית ספקים שאינם מוכרים במע"מ-

האוניברסיטה נדרשת להעביר בגינם את המע"מ ) חשבונית עצמית(. המע"מ צריך

856להיות מדווח במסגרת טופס

 

88

ניהול מע"מ5.1.3.4.12

ספקים בארץ המותרים בקיזוז מע"מ: Commitmentהבקרה התקציבית תרשום

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

( בגובהActualכרטיס ההוצאה של המע"מ ) המע"מ בהתאם לחשבונית שנרשם בה

המע"מ

 

ניהול מע"מ5.1.3.4.13

ספקים בחו"ל שנדרש בגינם מע"מ לרשויות המס בארץ: עבור ספקים בחו"ל נדרש

להעביר מע"מ על אף שהספק מחייב ללא מע"מ. הבקרה התקציבית תרשום

Commitmentכולל מע"מ. נקודה זו רלוונטית אך ורק במידה ואין מעבר דרך

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

שמכילה בתוכה עלויות נוספות,40%של בין היתר מע"מ

 

89

ניהול מע"מ5.1.3.4.14

עבור רשות מחקר, ישנם מקרים בהם הגורם המממן לא מכיר במע"מ על אף

ששולם לספק: הבקרה התקציבית תרשוםCommitmentכולל מע"מ, הדיווח לגורמים

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

האוניברסיטה : דיווח של כלל ההוצאה. ) שורת ההוצאה בחשבונית תפוצל בין

ההוצאה לבין המע"מ(

 

פרופורמה5.1.3.4.15

המערכת תאפשר לבצע הפרדה באמצעות שלMASTER DATAמאפיין/שדה ייעודי ב

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

פרופורמה לכאלו שלא

 

פרופורמה5.1.3.4.16

המערכת תבצע בדיקה אל מול מאפיין הספק שבו הוגדר האם הוא "ספק

פרופורמה" או לא. עבור אוכלוסיית הספקים שעובדים עם פרופורמה אבל אינם

זכאים לכך המערכת תבצע הפרדהאוטומטית ברישום המע"מ:

 

(item ) שורת 100 חובה- הוצאה

90

) שורת מס(17 חובה- הוצאה

17 זכות- מע"מ תשומות מעבר

100 זכות- ספק

בתשלום כנגד פרופורמה יירשם:

100 חובה- ספק 100 זכות- בנק

בתשלום כנגד חשבונית המס:

17 חובה- מע"מ תשומות מעבר

17 זכות- ספק 17 חובה-ספק 17 זכות- בנק

ניהול חשבוניות ספק5.1.3.4.17

• אפשרות לקליטת חשבונית פיננסיתהמתקבלת מהספק ללא תהליך רכש

 

• אפשרות לקליטת חשבונית במסגרתתהליך רכש )חשבונית לוגיסטית(

• אפשרות לקליטה חשבוניות במטבעותשונים

• אפשרות לפיצול שורות בחשבונית לפי כרטיסים, לפי סוגי הוצאה, סעיפי תקציב

שונים, יחידות וכד'

• תמיכה בניהול סטאטוסים לחשבונית

• תמיכה בניהול מס' שיעורי מע"מ וסוגימע"מ

91

• אפשרות לצירוף מסמכים לחשבוניתכצרופה

• תמיכה בהפקת חשבונית עצמית, לפי ההגדרה המתאימה ברשומת אב ספק

)התראה/חסימה(

• בדיקה בעת קליטת חשבונית למוגדר בנתוני אב ספק וחסימה/התראה בהתאם.

לדוג' – אם ספק אינו מוגדר לקליטת חשבונית לוגיסטית ויש ניסיון לקלוט

חשבונית לוגיסטית

לאישורWorkflow• תמיכה במנגנון חשבוניות, לפי סכומים שייקבעו ולפי

הרשאות

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

לדוג' – מספר חשבונית זהה לאותו ספק

קליטת חשבוניות5.1.3.4.18

• אפשרות לקליטה חשבונית בממשק ממערכות חיצוניות ) לבצע קישור

לחשבונית דיגיטלית- יש לייצר ממשק שלSAP)מול קומסיין

 

• אפשרות לקליטת חשבוניות מקבצים שיתקבלו מגורמים חיצוניים )חברת חשמל,

בזק וכד'(

92

חוק מוסר תשלומים5.1.3.4.19

בעקבות חוק מוסר התשלומים בוצע פיתוח מקומי: תנאי התשלום צריכים להיות מיום

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

החשבונית באוניברסיטה - צריך להבחין בין תאריך החשבונית, תאריך הרישום, תאריך

הערך לתשלום שנגזר מיום קליטת החשבונית באוניברסיטה ולא מיום הפקת

 החשבונית ע"י הספק.

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

ולא עלSAP FIוהערך יהיו מבוססים על פרופיט

לקוחות.5.1.4

רקע.5.1.4.1

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

שהם גם ספקים ועוד.

93

פירוט דרישות עסקיות בנושא לקוחות.5.1.4.2

( 4.5% משקל הדרישות העסקיות בנושא לקוחות בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש. הינן בקטגוריית "5.1.4.2.4 ועד 5.1.4.2.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו(

הקמת/תחזוקת5.1.4.2.1רשומת אב לקוח

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

מכירות

 

מרכזיםGL. תמיכה בהגדרת חשבונות 2לקבוצת לקוחות

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

השינויים

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

אפשרות לחסימת פעולות בהתאםלסטאטוס

. תמיכה בעת פתיחת לקוח5 להתריע/לחסום במידה וקיימת רשומה זהה,

על בסיס מספר ח.פ/ת.ז וכד'

. ניהול נתונים ללקוח, כגון:6

94

א. נתונים כללים: שם לקוח )במס' שפות(, , אישEMAILכתובת לקוח, טלפון, פקס,

קשר וכד'

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

מטבע לקוח

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

,EMAIL ד. אופן שליחת דיוור ללקוח – פקס, דואר וכו'

ה. צירוף מסמכים ללקוח כצרופה

ו. תמיכה בניהול טקסט חופשי ללקוח

ז. תמיכה בהגדרת שדות מסוימים כשדותחובה

ח. שדות נוספים לפי הגדרת הארגון

חשבונית לקוח 5.1.4.2.2

תמיכה בהפקת חשבונית פיננסית ללקוח,הכולל:

  א. אפשרות להפיק לפי מטבע )דולר, שקל

וכד'(

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

 . אפשרות לביצוע התאמות בכרטיסי לקוח1התאמות לקוחות5.1.4.2.3

95

. אפשרות לביצוע התאמה חלקית לשורה2)תשלום חלקי מול חשבונית לדוגמא(

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

. תמיכה בהצגת דוח ליתרות סגורות,4יתרות פתוחות, ויתרות מותאמות חלקית

ניהול לקוחות5.1.4.2.4

יש לשייך אנשי קשרSAPלכל לקוח ב פנימיים באוניברסיטה המשקפים את

היחידות השונות לפי הצורך )יחיד או רבים(. בעת הפקת החשבונית המערכת תדע לשייך

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

תאפשר במקרים מסוימים להקליד את אישהקשר ידנית

 

96

רכוש קבוע.5.1.5

רקע.5.1.5.1

– דוחות כספיים של9האוניברסיטה נדרשת לנהל רכוש קבוע בהתאם לחוקי הרגולציה )תקן חשבונאות מס' .5.1.5.1.1מוסדות להשכלה גבוהה(.

באוניברסיטה קיימות מספר אפשרויות לרכישות/הקמות של נכסים:.5.1.5.1.2רכישת נכסים סטנדרטית..5.1.5.1.2.1השבחת נכסים קיימים ושיוכם לנכס אב..5.1.5.1.2.2

נכסים בהקמה/בהתהוות )פרויקטי פיתוח(..5.1.5.1.3פירוט דרישות עסקיות בנושא רכוש קבוע.5.1.5.2

( 4.5% משקל הדרישות העסקיות בנושא רכוש קבוע בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש. הינן בקטגוריית "5.1.5.2.15 ועד 5.1.5.2.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו(

כללי5.1.5.2.1

המערכת תאפשר להגדיר מס' אזורי פחת:

 . לצורך הדיווח בספרים1. לצורך מס הכנסה2 . לצורך האיחוד האירופי- ייתכן שאורך חיי הנכס3

שונה

המערכת תאפשר לנהל רכוש קבוע, לרבותכללי5.1.5.2.2 רישומים פיננסיים בנושאים הבאים:

97

רכישת נכסים )לרבות מבנים(, חישובי פחת,גריעות ותוספות במהלך השנה

הקמת/תחזוקת5.1.5.2.3רשומת אב נכס

• תמיכה בניהול קבוצות של רכוש קבוע, כגון:מחשוב, כלי רכב וכד'.

 

• ניהול נתונים לנכס, כגון: א. קבוצת הנכס ב. תיאור הנכס

ג. תאריך הפעלה, תאריך רישום

ד. שיטת חישוב פחת )קו ישר, פחת מואץוכד'(

ה. שיוך ליחידה ארגונית – מרכז עלות,הזמנת פנימית

ו. סעיף תקציבי ז. עלות רכישה ח. עלות הקמה

ט. עלויות תוספתיות י. היוון עלויות הוצאות שונות

יא. ערך גרט יב. תמיכה בהגדרת שדות מסוימים כשדות

חובה

יג. שדות נוספים לפי הגדרת הארגון

• תמיכה בניהול שיטת הפחת אחוז פחת ברמתקבוצת רכוש קבוע וברמת נכס בודד

98

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

במידת הצורך

• תמיכה בשינוי מאסיבי לקבוצת נכסים שלנתונים מסוימים )כגון אחוז פחת(

• תמיכה באפשרות לניהול תתי נכסים, להלן:

א. קביעת קשר בין הנכס בן לנכס האב

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

ג. תמיכה בניהול נכס בן ללא תלות בנכסהאב – לדוג' אחוז פחת שונה, מכירה בנפרד וכד'

• ניהול תאריכי השבתת נכס – בתקופה זו לאיחושב פחת על הנכס

מכירה/גריעה של5.1.5.2.4נכס

• בעת ביצוע פעולה לוגיסטית למכירת נכס, תתבצע גריעה אוטומטית לנכס לרבות ביצוע

פקודת היומן 

• אפשרות לביצוע גריעה/מכירה מלאה/חלקיתלנכס

99

• תמיכה בחישובים של רווח הון/הפסד הון בעתמכירת/גריעת נכס

ריצת פחת5.1.5.2.5

• תמיכה בריצת סימולציית פחת

 

• ריצת פחת תייצר פקודת יומן במערכת לפי:

א. מרכזי עלות/הזמנות פנימיות, כמוגדרבנכס

, סעיפים תקציבייםGL ב. חשבונות

• אפשרות לרישום פחת ידני לנכס

ניהול פרויקטים5.1.5.2.6 המערכת תאפשר לצבור עלויות של פרויקט

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

 

ניהול פרויקטים5.1.5.2.7

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

שאותו ניתן להוון לנכס בהקמה ולאחר מכן להווןלנכס סופי

 

 המערכת תאפשר לנהל מעגל רכוש קבועמעגל רכוש קבוע5.1.5.2.8

דרישות5.1.5.2.9רגולטוריות

המערכת תתמוך בדרישות רגולטוריות הנוגעותלרכוש קבוע כגון:

 

א. הרצת פחת שונה למס הכנסה ולספרים

100

ב. הפקת טופס י"א

ניהול נכסים5.1.5.2.10

₪ צריך50,000כל פריט ציוד בשווי החל מ- להיות מנוהל כנכס ולא כהוצאה ) השווי שממנו פריט ציוד צריך להיות מנוהל כנכס צריך להיות

מנוהל כפרמטר שניתן לשינוי ע"י משתמשמורשה(

 

cost centerהמערכת תאפשר לשייך נכס לרישום פחת5.1.5.2.11 לטובת רישום הפחת

Assetניהול 5.1.5.2.12Class)סוג נכס (

לפי סיווגasset classהמערכת תאפשר לנהל שהאוניברסיטה תגדיר. בנוגע לבניינים: יש לרדת

assetלרזולוציה של בניין ) ייתכן וכל בניין יוגדר כclass)

 

תת נכס5.1.5.2.13

המערכת צריכה לאפשר לייצר תת נכס בגיןשיפוץ.

  תת הנכס יוקם תחת הנכס ששופץ עם אפשרות

לאורך חיים שונה מהנכס עצמו בהיבטי פחת

ניהול ציוד ומבנים5.1.5.2.14 -inventarכיום רכש של ציוד ומבנים מנוהל כ

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

 

101

דוחות רכוש קבוע5.1.5.2.15

. אפשרות להפקת דוחות פחת לפי אזורי הפחת1השונים, הכולל:

 

א. יתרות נכסים, יתרות קבוצות

ב. לפי יחידה ארגונית/מרכז עלות

ג. לפי סעיפים תקציביים

ד. דוחות למס הכנסה )טופס י"א(

ה. דוח סימולציה לפי תקופה

. דוח שורות לנכס2

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

102

COבקרה – .5.1.6

רקע.5.1.6.1

הדרישה באוניברסיטה היא לאפשר מדידה של הכנסות והוצאות ברמת פקולטות אגפים ומחקרים.5.1.6.1.1- קורס  תנוהל היררכיה של פקולטה – תכנית – חוג SAPבמערכת ה- .5.1.6.1.2 כל רישום של הכנסות והוצאות במקור שניתן לרשום ישירות על פקולטה או על רמה נמוכה יותר )תכנית, חוג,.5.1.6.1.3

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

הוצאות על מנהל תלמידים שבעצמה תעמיס הוצאות על הפקולטותההעמסה תתבצע בהתאם למפתחות סדורים שיוגדרו.5.1.6.1.5מפתחות ההעמסה יהיו ניתנים לשינוי בהתאם לכללים סדורים שיוגדרו.5.1.6.1.6המערכת צריכה לתמוך באגף תקציבים בניהול שוטף של התקציב לרבות ניהול גרסאות.5.1.6.1.7

103

פירוט דרישות עסקיות בנושא בקרה תקציבית.5.1.6.2

( 4.5% משקל הדרישות העסקיות בנושא בקרה תקציבית בשלב בדיקת התאמת המענה: " ויש להכליל אותןנדרש. הינן בקטגוריית "5.1.6.2.34 ועד 5.1.6.2.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceבתמחור הכולל )

מס' דרישהעסקית

תיאור הדרישהנושא תיאור המציע את המענה )כולל

עליהם מתבססSAPהתייחסות למודולי בהצעתו(

5.1.6.2.1Master Data אחיד של מרכזי עלות עםData Masterניהול

, ניהול אחיד לכלSAPמספר היררכיות בתוך ה כולל היררכיות SAPהמודולים ב

 

5.1.6.2.2Cross Validation המערכת אפשרCross Validation rules  CC + GLלשילוב של

crossניהול 5.1.6.2.3validation rules

cross validation rulesהמערכת תאפשר לנהל / אובייקט תמחיריcost center לבין הGLבין הנוסף

 

במערכתCCניהול 5.1.6.2.4

מספר מאפיינים המערכת תאפשר להקים שמקימים: פקולטה, סוג תקציב )רגיל CC לכל

לימוד, מותנה(, סוג תקציב מותנה )תכניתאחר(

 

104

במערכתCCניהול 5.1.6.2.5

שיופעל החלCCהמערכת תאפשר להקים מתאריך מסוים )לדוגמא: החל משנת תקציב הבאה( ע"מ להימנע מרישומי תקציב וביצוע

לפני תאריך ההפעלה שהוחלט

 

בקרה תקציבית5.1.6.2.6 אוGLהבקרה התקציבית תתבצע ברמת סעיף

CC או שילוב של ( GL+CC ולא ברמת )sub account

 

ניהול אלוקציות5.1.6.2.7במערכת

המערכת תתמוך במנגנון אלוקציות שיאופיין ע"י של העמסות( עלCycles 3האוניברסיטה )עד

- מפתחותPCמנת לאפשר דיווח מלא ברמת ההעמסה יוגדרו ע"י האוניברסיטה

 

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

מחלקת הנדסה5.1.6.2.8

הוצאות של מחלקת הנדסה אינן מועמסות באופן שוטף במהלך התקופה, אלא בתהליך

סוף תקופה כאשר מפתח האלוקציה הוא ההוצאות ביחידה המזמינה )סך ההוצאות *

20%)

 

105

מזמין(CC חובה: הוצאות תקורה )

הנדסה( CC זכות: הוצאות תקורה )

תקציב פרויקט בינוי5.1.6.2.9

המערכת תאפשר לנהל תקציב פרויקט בינוי,SAPברמת פרויקט במערכת ה

  * התקציב צריך להיות רב שנתי

* המערכת תאפשר לבצע העברת תקציבית ביןcommitmentשנים, בגובה יתרת ה

תקציב פרויקט בינוי5.1.6.2.10

המערכת תאפשר לנהל בקרה תקציבית עבור פרויקט ברמת סך הפרויקט על אף שהתכנון

ברמת סעיף.BOTOM UPהתקציבי יהיה ) הבקרה התקציבית תהיה ברמת פרויקט כדי

לא לייצר העברות תקציביות מיותרות שנגרמותמשינויים שמתרחשים בפועל במהלך הפרויקט(

 

תקציבים סגורים5.1.6.2.11עבור פרויקטים

CCהמערכת תאפשר לשייך הכנסה והוצאה ל ע"מ לאפשר בקרה תקציבית במידה שלא

נרשמו הכנסות. גובה ההוצאה המקסימאלייהיה כגובה צפי ההכנסה

 

106

5.1.6.2.12Functional area

בדוחFunctional areaהמערכת תאפשר לנהל רווח והפסד )המכיל: הוראה ומחקר, שירותים

לסטודנט, הוצאות ישירות, גיוס תרומות, פרסוםושיווק, הנהלה(

 

5.1.6.2.13Derivation rule שלDerivation ruleהמערכת תאפשר לנהל

Functional areaלפי טווח של מרכז עלות או GLלפי חשבון

 

ניהול נתונים5.1.6.2.14סטטיסטיים

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

לאפשר דוחות בקרה של תקציב מול בפועל והקצאה לרבות תחשבים שיכפילו את הכמות

SAPבמחירון -מחיר תקן, מחיר התקן יגיע ל כנתון סטטיסטי

 

ניהול נתונים5.1.6.2.15סטטיסטיים

ניהול ממשקים של העברת נתונים סטטיסטיים - כמותHRממל"מ- כמות עובדים בפועל ,

עובדים מתוקננת , מערכת תכנון – כמותעובדים לפי תקציב

 

107

ניהול נתונים5.1.6.2.16סטטיסטיים

כמויותFI-COהמערכת תאפשר לנהל בתוך בתוך סעיפי תקציב/הוצאה- מידע סטטיסטי

לצורך הפקת דוחות ולצורך ניהול תקציב( BI) דרישה זו הגיע גם מה

 

חסימת כרטיס5.1.6.2.17לרישום

+CCהמערכת תאפשר לחסום לרישום )ברמת GLבשנה אחת ולאפשר רישום על אותו סעיף ) +CC בשנה הבאה בנקודת זמן מסוימת

 

תקצוב ברמת מרכז5.1.6.2.18עלות

המערכת תאפשר תקצוב ברמת מרכז עלות ברמת אב כללי )לדוגמא פקולטה כללי (

החסומה לרכש, ויוקמו מרכזי עלות ספציפיים )ברמת חוג לדוגמא( שעליהם תופעל בקרה

 תקציבית

המערכת תאפשר העברה של תקציבים ביןהכללי לספציפיים

5.1.6.2.19 העברת יתרות בין שנים בתקציבים

סגורים

בתקציבים סגורים קלאסיים , כאשר נדרשלהעביר יתרה לשנה הבאה :

  בשנה הנוכחית נרשמת פקודת יומן ח< הכנסות)ללא פירוט של מרכזי עלות( ז < קרן

בשנה העוקבת: ח< קרן ז< הכנסות עם פירוטלמרכזי העלות שונים

108

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

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

תמיכה בחיובי5.1.6.2.20תקורות ואלוקציות

המערכת תאפשר גמישות בחיובי תקורותואלוקציות באופן הבא:

 

. בעת רישום ההוצאות, התקורות )כגון1 ארנונה, חשמל, שכ"ד( ירשמו במרכז עלות

כללי כחלק מהוצאות המנהלה בתקציב הרגיל

. בסוף רבעון, התקציבים המותנים והסגורים2 מקבלים חיוב של תקורות ע"ס נוהל תקורות ,

מהלך זה מחייב סעיף הוצאות לתקציב מותנה או סגור ומזכה את התקציב במרכז עלות כללי

בסעיף "קיזוז תקורה"

. לצורך ניתוח דוח הכנסות והוצאות ברמת3 פקולטה, יידרש מהלך נוסף של אלוקציות

מרמת תקציב כללי לרמה של פקולטה, במהלך זה יש להתעלם מחיובי התקורות שבוצעו

2בסעיף

109

המערכת תאפשר הפקת דוחות בכל אחד(1+2+3, 1+2מהשלבים שהוצגו לעי"ל )

5.1.6.2.21 חיובי תקורות

בתקציבים סגורים,מותנים

חיובי תקורות בתקציבים סגורים ומותנים

 

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

מההוצאות )ע"פ נוהל תקורות(, המערכתתאפשר לשנות את האחוז באופן ידני

. האוניברסיטה מנהלת שני ספרים: ספר2 חשבות – לצורך הפקת הדוחות הכספיים וספר

תקציבים – לצורך ניהול התקציב והבקרה התקציבית באוניברסיטה. לעניין חיובי

התקורות, המערכת תאפשר חיוב שונה לצורך חשבות ולצורך התקציב )לדוגמא: בתקורות

מסוימות תהיה אלוקציה גם בחשבות וגם בתקציב – לדוגמא: במחקרים חיצוניים

ובאחרות האלוקציה תתבצע רק בתקציב ולאבחשבות – בתקציבים סגורים ומותנים(

110

. חיובי התקורות יבוצעו באופן הבא: מצטבר3 עד יום הדיווח פחות מצטבר לתקופת הדיווח

הקודמת

העמסות הוצאות בין5.1.6.2.22יחידות

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

שכר

  לדוגמא: כאשר חבר סגל אקדמי עובד על מחקר: מחייבים את המחקר ומזכים את

הפקולטה )שם נרשמות הוצאות השכר ממל"מ(

העמסה זו תתבצע במערכת באמצעות פקודתיומן ידנית

דוחות במטבע5.1.6.2.23השונה משקל ודולר

המערכת תאפשר להפיק דוח במטבע שונה משקל ומדולר עבור אובייקט )יחידה ארגונית

למשל( המנוהל בשקל. התרגום למטבע הנוסף )לכל מרכז עלות יכול להיות מטבע נוסף שונה (

יהיה לפי שער יום התנועה ולא תרגום נוחות )ממוצע( זאת במקרים שהאובייקט מנוהל שקל

והבקרה התקציבית מנוהלת בשקל

 

נדרש דיווח לתורמים ברמה מפורטת יותר מדיווח לתורמים5.1.6.2.24CC + GL כגון: סוגי תנועה מסוימים  

111

דיווח לתורמים5.1.6.2.25 נדרש לנהל תקציב ברמה המפורטת עבור

התורמים, אך לא נדרש לנהל בקרה תקציביתברמה הזו

 

ניהול מחקרים5.1.6.2.26פנימיים - דוחות

מחקרים פנימיים של רשות מחקר ופקולטה ישלפו בדוח אחיד ממקור אחד )כנראה במודול

( שיאפשר פילוחים שונים בפורמט אחיד.COה מאפשר לנהל תקציב פר תקופה,GMמאחר וה

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

 

דוחות תקציב מול5.1.6.2.27Off Lineביצוע

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

להפיק את הדוחות מול תקציב מקורי/תקציבמעודכן

 

5.1.6.2.28 דוחות עבור

תקציבים מותנים /סגורים

עבור תקציבים מותנים/ סגורים – הצגת דוח של הכנסות והוצאות לדוגמא: דוח הכנסות

והוצאות לתוכנית לימודים מסוימת  

דרישות והזמנות5.1.6.2.29פתוחות

המערכת תאפשר הפקת דוח של דרישות  GL ו CCוהזמנות פתוחות ברמת

112

5.1.6.2.30

בקרה תקציבית-דוחות

לצורך הפקת דוחות של תקציב מול בפועל - יפותח ממשק של נתוני בפועל ותקציב )כמויות

באופן הבא:BIוכסף( ל

 

תקציב מול ביצועOff Line1 + בפועל – ממל"מ + מערכת שבתון .SAP

. תקציב – שיגיע ממערכת תכנון תקציב )יכול2 (HRלהיות ממערכת תכנון ו

  הנתונים יועברו ברמת קיבוץ שתוגדר ע"י

האוניברסיטה )רזולוציית עובד בודד נמוכה מידי )

5.1.6.2.31

- מכיוון שסטודנט אינו מנוהלCMדרישה ל בקרה תקציבית-במערכת תכנון תקציב:

 

CMדוחות יש רישום ברוטוCMמלגות שכר לימוד - כיום ב

- נרשם שכר לימוד בסכום המלא + הוצאהעבור מלגה לאותו סטודנט

CMמלגות קיום – רישום של מלגה ב  

  המערכת תאפשר לנהל בקרה באמצעות דוח

של תקציב מול בפועל עבור מלגותCMמה לסטודנטים

בקרה תקציבית-5.1.6.2.32דוחות

לסעיפים בדוחותGL+ CCנדרש לשייך חשבון  ות"ת לפי:

113

לסעיף בדוח ות"ת אחדGL+ CCכל חשבון דוח ות"ת

  לשני סעיפים בדוחותGL+ CCפיצול חשבון

עםSAPות"ת – ייתכן שהפיצול ינוהל ב References שונים

5.1.6.2.33

בקרה תקציבית-דוחות

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

  הפקת דוחות לפי

חשבון נגדי

+ CCלדוגמא: הפקה של הוצאות/ הכנסות עם GLמסוים בפרמטר של הסעיף הנגדי ו/או

מספר הספק או מספר הלקוח

תשלומים ידניים של5.1.6.2.34החזרי הוצאות

settlement rulesהמערכת תאפשר להגדיר cost centerכדי לדעת לשייך את הנסיעה ל

הנכון ) יחיד או רבים( ) תחילת התהליך של החזרי הוצאות בגין תשלומים ידניים מתבצעת

בפורטל(

 

114

" ויש לתמחר אותןאופציה הינן בקטגוריית "5.1.6.2.41 ועד 5.1.6.2.35כל הדרישות העסקיות בגין כל אופציה בנפרדFix Price( של הפרויקט. את התמחור Fix Priceבנפרד מהתמחור הכולל )

בנספח למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(.1 בנספח יש למלא בשורה המתאימה .זה אין למלא מחירים

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו(

יתרה תקציבית לחוקר5.1.6.2.35

מבטים:2המערכת צריכה לאפשר

 

(, לצורךCO. בכספים )דוח שיופק מה 1 דוח על הפעילות בשנה הנוכחית – יש

להעמיד את ההכנסה בגובה ההוצאה, כך0שיעמוד על

(GM. בדוחות לחוקרים )המופקים מה 2 יש צורך לראות מבט של היתרה

התקציבית במצטבר

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

החוקר אמור לראות בשנה העוקבת את היתרה התקציבית שהועברה אליו משנה

קודמת

115

5.1.6.2.36HR COבעת פתיחת / שינוי מרכז עלות ב

נדרש ממשק אוטומטי למל"מ ) דרישה(HRשל

 

5.1.6.2.37HR

COבעת פתיחת / שינוי מרכז עלות ב נדרש ממשק אוטומטי לסינריון ) דרישה

, סינריון זה מערכת לדיווחיHRשל שעות(

 

רישום הכנסות עבור5.1.6.2.38תקציבים מותנים

:CMהכנסות שכר לימוד בממשק מה שישקףPCההכנסה תירשם גם ברמת ה

שישקף תכניתCCפקולטה וגם ברמת ה )בתקציב רגיל ברמת פקולטה בלבד(

 

רישום הכנסות עבור5.1.6.2.39תקציבים מותנים

ברישום הכנסות אחרות שאינן מגיעות )כגון תרומות( תהליך הרישוםCMמה

CCצריך לכלול אפשרות לציין את ה שישקף תכנית )לדוגמא: רישום הכנסות

(AR או SDמה

 

המערכת תאפשר להזין תקציב רב שנתיניהול תקציב רב שנתי5.1.6.2.40 - עבור כמה שנים קדימה

116

CCשיוך עובדים ל 5.1.6.2.41פעילים

במידה שבפקודת השכר ממשק מל"מ שאינו פעיל, ממשקCCנכנס נרשם

השכר ייפול והמערכת תדרוש לבצע תיקון CCידני של הנתון. התיקון יאפשר שיון ל

הנכון

 

117

דוחות.5.1.7

ככלל, שליפת הנתונים לדו"חות השונים נעשית בכמה אופנים והשילוב בין האופנים:.5.1.7.1

לפי תחום חשבונות..5.1.7.1.1לפי חשבון נגדי..5.1.7.1.2 לפי נתונים המוזנים בשדות שונים בעת הקלדת תנועה, כמו שדה: יעד, משימה, מוקד או לפי שדות הקבצה.5.1.7.1.3

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

תוך הימנעות, עד כמה שניתן,S4HANA המובנה של BIעל המציע הזוכה לעשות מאמץ לספק את מירב הדוחות באמצעות רכיב ה-.5.1.7.2. יישום בהתאם לאמור לעיל, יילקח בחשבון בעת ניקוד המענה לסעיף זה. או באמצעות קודBWמשימוש בשכבת

פירוט דוחות נדרשים:.5.1.7.3

( 1% משקל הדוחות בשלב בדיקת התאמת המענה: Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.1.7.55 ועד 5.1.7.1כל הדוחות

Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק ( של הפרויקט

תיאור הדוח/פרמטרים נדרשיםדרישהנושאמס' דו"ח

תיאור המציע את המענה )כולל התייחסות מפורשת

במקומות בהם המענה יינתן עם/בליBIבאמצעות דוחות

(BWשכבת

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

ח-ן, תאריך הוצאת ח-ן, תאריך פירעון,סכום, יתרה ופרטי תשלום

 

חיפוש ח-ןלקוחות5.1.7.2

         .דוחות נתוני אב לקוחות

           פרמטרים עיקריים: מספר חו"ז, שם חו"ז, שם נמען מספר ח-ן , תאריך ח-ן,

חשבון נגדי, יתרת ח-ן

118

מע"מ עסקאות לקוחות5.1.7.3

         דוח המפרט של המע"מ עסקאות של חודשים קודמים

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

לפני מע"מ, סכום המע"מ, סכום כוללמע"מ

מעקב חשבוניות לקוחות5.1.7.4

         .דוח מעקב חשבוניות ללקוחות

 

         ,פרמטרים עיקריים: קוד אסמכתא תיאור אסמכתא, מספר חו"ז, תיאור נמען,

מספר ח-ן, תאריך ח-ן, תאריך פירעון, פרטים, יתרה לפי מטבעות, מספר ימים

בפיגור

דו"ח גיול לקוחותלקוחות5.1.7.5

         .דוח גיול חובות לקוחות

 

         פרמטרים עיקריים: מספר חו"ז, שם + תיאור2הנמען, ח-ן נגדי, אסמכתא

האסמכתא )שם( מספר ח-ן, תאריך ח-ן,תאריך פירעון, פירוט פיגורים

         נדרשת אפשרות לייצוא נתונים במטבעות השונים המנוהלים

באוניברסיטה

גיול לקוחות בפיגורלקוחות5.1.7.6בלבד

         דוח המרכז את הפיגורים בתשלומים אשר טרם בוצעו ע"י הלקוחות.

 

         /פרמטרים עיקריים: תיאור פקולטה , מספר חו"ז,2יחידה, קוד אסמכתא

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

לפי מטבעות ובתוך המטבעות לפיתקופות.

לקוחות5.1.7.7 דוח גיול לפי מרכז

עלות מחקריםפנימיים וחיצוניים

פרמטרים עיקריים: מס' חשבונית, תיאור, תאריך, חשבון הנה"ח )חו"ז(, מטבע

הח-ן, יתרת חשבונית במטבע, סה"כ סכום חשבונית במטבע, סכום חשבונית

 

119

לחשבון בשקלים, יתרת חשבונית לחשבוןבשקלים

בקרת תשלומיםספקים5.1.7.8וחשבוניות לספקים

         דוח המציג חשבוניות תשלומים לספקים לפי שם משתמש.

           נדרש לבצע שליפה לפי המשתמש שביצע את ריצת התשלומים/קלט את

החשבונית.

פרמטרים לריצתספקים5.1.7.9תשלומים

         דוח המבצע סימולציה לריצת תשלומים.

           פרמטרים עיקריים: תאריך קובע לתשלום, אמצעי התשלום, הגבלת סכום

-במידה ורלוונטי, תחום חשבונות

דוח ניכוי מס במקורספקים5.1.7.10תקופתי

         857הפקת דוח

 

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

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

JOBשם ה

דוח ניכוי מס במקורספקים5.1.7.11שנתי

         856הפקת דוח

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

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

הפקת דוח כרטסת לספק/מס' ספקים לפיכרטסת ספקספקים5.1.7.12 תאריכים

תשלומים לזכאיםספקים5.1.7.13

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

התשלום, אופן התשלום )שיק/מס"ב(,מספר סידורי, תאריך פירעון

 

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

ספקים

מחשבון עד חשבון תקופה )חודש עבודה(, חשבון )מספרי ספק(, שם החשבון )שם

הספק(, אסמכתא )מספר חשבונית(,סכום בשקלים )סכום החשבונית(,

ספר ראשי –5.1.7.15דוח הוצאות רכביםרכבים

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

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

+מנהרות הכרמל, ליסינג תפעולי6

 

חשבוניות עסקהספקים5.1.7.16

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

פרמטרים עיקריים: שם משתמש -)קוד העובדת(, חשבון -)מספר ספק(, שם החשבון )שם הספק (, תקופה -חודש

רישום, תאריך-תאריך החשבונית, אסמכתא-מספר חשבונית עסקה, פקודת

יומן, שורה )שורה בפקודה(, פרטים )מהות התשלום(, שקלים-סכום

החשבונית עסקה

 

ניתוח מצב קבלניספקים5.1.7.17חצר

         ניתוח מצב קבלני חצר מתקופה עד תקופה.

 

         - פרמטרים עיקריים: חשבון ספק )מספר ספק(, שם החשבון )שם הספק(,

מספר חשבונית, תאריך החשבונית, אסמכתא מספר חשבונית, פרטים )מהות

התשלום(, סכום החשבונית, סכוםהתשלום, יתרת חשבונית

דוח פתיחתספקים5.1.7.18חשבונות ספקים

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

תאריך, חשבון-מספר ספק, שם החשבון)שם הספק (, תאריך פתיחת חשבון

 

דוח חשבוניות עסקהספקים5.1.7.19 דוח המרכז את חשבוניות העסקה

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

 

121

תקופה-חודש רישום בספרים, תאריך-תאריך החשבונית,

אסמכתא-מספר חשבונית עסקה, -מספר חשבונית מס, מספר2אסמכתא

פקודה, שורה )שורה בפקודה(, תאריך עדכון הפקודה, סכום בשקלים )סכום

החשבונית(.הדוח יאפשר גם הפקה וסינון לפי:

חשבונית עסקה אשר נקלטה בגינה      א.חשבונית מס

חשבונית עסקה ללא חשבונית מס      ב.

מיון קרנות לפיקרנות5.1.7.20גמישות

         .מיון קרנות לפי דרגת קשיחות 

         מיון ואיתור קרנות לפי דרגת הנזילות

קרנות5.1.7.21 יתרת קרנות

אזילות-יחידות עםפרוט

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

, יתרת סגירה של הקרן לחודש מסוים.

פעילות בקרנותקרנות5.1.7.22הגמישות

         -שנים. 3תמונת מצב ל

          קרנות אזילות פנימיות של הפקולטות

בלבד         ,פרמטרים עיקריים: יתרות פתיחה

יציאות ,כניסות, שערוך ויתרות סגירה

קרנות5.1.7.23 דוח פעילות בקרנות

הגמישות לפי מקורות

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

שערוך, יתרת סגירה

 

 דוח המפרט את התרומות שהתקבלו.דוח תרומות תרומות5.1.7.24         ,נדרשת שליפה לפי מקור התרומה

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

שייבחר )לדוגמא: תרומות שהתקבלובש"ח ויורו יוצגו בדולר(

122

         אפשרות להצגת סכומים במטבע התרומה

דוח ות"תקרנות5.1.7.25

         דוח ות"ת הוא בחלקו דוח קרנות סטנדרטי ובחלקו הוא דו"ח מיוחד

שמחשב ריבית על הקרנות

 

         פרמטרים: יתרת פתיחה, תנועות השנה, שערוך, יתרת סגירה

         המערכת תאפשר לבצע חישוב בהתאם ל למטבע החשבון של התנועות

בקרן, לתאריך הערך של התנועות ולפרמטרים שהוזנו )שערי המטבע ואחוזי הריבית( של שווי הריבית אליה זכאית כל

קרן.          המערכת תאפשר בחירה האם לייצר

פקודות יומן אוטומטית על שווי הריבית והקבלת האוצר או לא )מהלך החישוב

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

בתקציבים השונים וזאת, כדי לתכנן את תקציב ההוצאות של תקציבים שניזונים

מפירות קרנות לשנה העוקבת(         המערכת תאפשר לבצע רשום פקודת

יומן אוטומטית על בסיס הדוח על גובההריבית:

חובה- הכנסות מימון ) סך הריבית( זכות- חשבון פירות קרן ) עבור כל קרן

בנפרד(         המערכת תאפשר רישום פקודה

אוטומטית על סמך הדוח עבור הריבית בסוף השנה השוטפת שתירשם בפועל במהלך השנה העוקבת ) עד אז תהיה

בהקפאה( חובה- הכנסות מימון ) סך פירות כל

123

הקרנות( זכות- חשבון פירות קרן ) עבור כל קרן

בנפרד(         המערכת תאפשר לבצע רישום

פקודה אוטומטית על סמך הדוח עבור הקבלת האוצר )בסוף שנה שוטפת( –

הפקודה נרשמת במהלך השנה העוקבת חובה- ות"ת ) חו"ז( שורה אחת על סך כל

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

שורות, כל שורה עבור קרן בהתאםלסכום שלה

חישוב ריבית בגיןקרנות5.1.7.26קרנות אזילות

פרמטרים עיקריים: יתרת פתיחה, תנועות השנה, שערוך, יתרת סגירה.

דוח לרשםקרנות5.1.7.27ההקדשות

שליפת תנועות במבנה סטנדרטי של דיווח לרשם ההקדשות

דוח חישוב תקורהתרומות5.1.7.28לתרומות

דוח המציג את חישוב התקורה לפי תרומה

מיון שכר לימוד –גזברות5.1.7.29קופות ושונים

         שליפת תנועות לפי יעדי שכל לימוד           ,פרמטרים עיקריים: שנה אקדמית

חודש, חשבונות שכר לימוד

דוח הפקדותגזברות5.1.7.30

פרמטרים עיקריים: קופה, תאריך הפקדה )ברירת מחדל של היום הנוכחי(, הפקדה

מספר )אוטומטי(, הדפסה, סיכום לפיתאריך פירעון, יצירת קובץ לבנק

 

פרמטרים עיקריים: קופה, תאריך, פרוט,דוח סגירת קופהגזברות5.1.7.31 מספר עותקים

124

פרמטרים עיקריים: קופה, מתאריךדוח שיקים דחוייםגזברות5.1.7.32 פירעון, מוקפא, קפיצת דף

 דוח המציג התאמות בנקיםדוח התאמת בנקיםגזברות5.1.7.33

תקורות5.1.7.34 דוח חישוב תקורות מחקרים- פנימיים

וחיצוניים

         דוח המציג חישוב של תקורות מחקרים.

          ,פרמטרים עיקריים: מס' מחקר

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

חשבון בחיצוניים.

מחקרים5.1.7.35 בדיקת אסמכתא

להכנסות – מחקריםפנימיים וחיצוניים

         דוח המפרט את ההכנסות שנרשמו למחקרים.

           פרמטרים עיקריים: מס' ח-ן , שם החשבון, תקופה חשבון נגדי, שם החשבון

, פק' יומן,2הנגדי, אסמכתא, אסמכתא שורה, פרטים, ח/ז, סכום

העברת יתרותמחקרים5.1.7.36מחקרים

         דוח המציג את יתרת התקציב לסוף תקופה לצורך העברתה לתקופה

העוקבת.            ,פרמטרים עיקריים: מס' תקציב

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

, פרטים וסכום בש"ח2אסמכתא

העברות כספיותתחנות5.1.7.37בתחנות

פרמטרים עיקריים: מס' תחנה, תיאור תחנה, מספר העברה, תאריך פתיחת

העברה, תאריך העברה לתחנה, כתובתמייל

 

דוח מחקרים במימוןמחקרים5.1.7.38חיצוני

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

של שנה תקציבית, מחולק לפעילות 

125

תקופתית ופעילות מצטברת, לפי מטבעות וסה"כ שקל, מחולק לפי: הכנסות, הכנסות שונות, הכנסות

מהשתתפות האוניברסיטה, , הפרשי שער, סה"כ הכנסות, הוצ' שכר, רכישות,

שוטפות , תקורה, סה"כ הוצאות ויתרה

תרומות,5.1.7.39דוח ללמ"סמחקרים

המערכת תאפשר להפיק דוח ללמ"ס שיכיל מידע כגון: גובה התרומה לפי

טווחים, מקור התרומה 

שליפת תנועותגזברות5.1.7.40 אפשרות לשליפת תנועות לפי הפרמטרים

הבאים: אסמכתא ,פקודה, תאריך, נגדי,פרטים ,ח/₪ , ז/₪, יתרה/₪

 

מאזן בוחןספר ראשי5.1.7.41

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

חשבון, חתך לעיתים לפי יתרות או שורתסיכום בלבד

 

ספר ראשי5.1.7.42 דוחות לצורך

ביאורים בדוחותהכספיים

         דו"ח על הפעילות - שליפת תנועות לפי חתכים שונים לרבות סוגי תקציב

 

         דו"ח על השינויים -שליפת תנועות לפי חתכים שונים

         מאזן - שליפת תנועות לפי חתכים שונים

         מיון הכנסות - שליפת תנועות לפי חתכים שונים לרבות סוגי תקציב

כללי5.1.7.43 קרן אמריטוס – דוח

ניצול ודרישותפתוחות

פרמטרים עיקריים: מס' ח-ן , שם חשבון , ניצול $ , דרישות

דוח ניצול קרן קשריכללי5.1.7.44מדע מפורט

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

שקלים ודולר, הקצבה שקלים ודולר,יתרה שקלים ודולר

 

דוח ניצול קרןכללי5.1.7.45אמריטוס מפורט

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

126

שקלים ודולר, ניצול9שקלים ודולר, נגדי שקלים ודולר, יתרת שקלים ודולר

דוח גיול ליחידהיחידה ארגונית5.1.7.46ארגונית

המערכת תאפשר להפיק דוח גיול ליחידה ארגונית

קקמ"ב כולל יתרותקקמ"ב5.1.7.47לפי חשבון + ת.ז.

פרמטרים עיקריים: ח-ן בהנה"ח, חסום, ת.ז., שם חשבון ,יתרת פתיחה, תנועות

זכות, תנועות חובה, יתרה 

קקמ"ב דרישותקקמ"ב5.1.7.48פתוחות

פרמטרים עיקריים: מס' חשבון, שם חשבון, תאריך דרישה, מספר דרישה,

פרטים, סכום 

פקודת הקצבהקקמ"ב5.1.7.49קקמ"ב

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

זכות דולרים, פרטים, שם עובד, יעד 

פקודת שווי שי לחגשכר5.1.7.50 פרמטרים עיקריים: תאריך, אסמכתא,

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

 

מאזןקקמ"ב5.1.7.51 פרמטרים עיקריים: חשבון, פרטים, יתרת

פתיחה, , חובה, זכות , יתרת תקופה,יתרת סגירה

 

פקודת תשלומיםקקמ"ב5.1.7.52לקופות

פרמטרים עיקריים: תאריך , אסמכתא, חשבון חובה , חשבון זכות , חובה

שקלים , זכות שקלים, פרטים 

פקודת סכומיםקקמ"ב5.1.7.53שליליים

פרמטרים עיקריים: תאריך , אסמכתא, חשבון חובה , חשבון זכות , חובה

שקלים , זכות שקלים, פרטים 

דוח התאמה ספרספר ראשי5.1.7.54כלכלי-ספר חשבונאי

דוחות התאמה בין דוח כלכלי לדוח חשבונאי )בין שני ספרים(

Sub Accountsספרי ראשי5.1.7.55

המערכת תאפשר להפיק דוחות לגורמים Subשונים שישלפו את החשבון עם ה

Accountהרלוונטי ) לדוגמא: סוג הוצאה של רכב, מעמד של עובד, מספרי רכב,

מספר ת"ז של סטודנט(

 

127

ממשקים.5.1.8

להלן דרישות הממשקים הנדרשות:.5.1.8.1

2% משקל הממשקים בשלב בדיקת התאמת המענה: Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.1.8.18 ועד 5.1.8.1כל הממשקים

Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט

תיאור המציע את המענה דרישהנושאמס' ממשק

במבנה מוסכם מייצר פקודתFIקליטת קובץ דלק5.1.8.1 יומן אוטומטית

השכרת5.1.8.2רכב-ליסינג בלבד

במבנה מוסכם מייצר פקודתFIקליטת קובץ  יומן אוטומטית

במבנה מוסכם מייצר פקודתFIקליטת קובץ שטיפת רכב5.1.8.3 יומן אוטומטית

5.1.8.4 שע"מ )קליטת

אישורי מסאוטומטית(

במבנה מוסכם מייצר פקודתFIקליטת קובץ  יומן אוטומטית

 ממשק יוצא של תשלומים לבנקיםמס"ב5.1.8.5

חברות אשראי5.1.8.6) שב"א(

ממשק דו כיווני לניהול תשלומים באשראי )שבא(

ממשק בגין כספים שחוקר זכאי להם שהואבנק פועלים5.1.8.7 אוסף מנתב"ג

128

במבנה מוסכם מייצר פקודתFIקליטת קובץ חברת סלולר5.1.8.8 יומן אוטומטית

במבנה מוסכם מייצר פקודתFIקליטת קובץ ארנונה5.1.8.9 יומן אוטומטית

במבנה מוסכם מייצר פקודתFIקליטת קובץ מים5.1.8.10 יומן אוטומטית

במבנה מוסכם מייצר פקודתFIקליטת קובץ חשמל5.1.8.11 יומן אוטומטית

קליטת דפי בנק5.1.8.12 ממשק נתונים מסילברנט)סילברנט(

קליטת שערי5.1.8.13 ממשק נתונים מסילברנטמט"ח )סילברנט(

במבנה מוסכם מייצר פקודתFIקליטת קובץ הוט – הו"ק5.1.8.14 יומן אוטומטית

במבנה מוסכם מייצר פקודתFIקליטת קובץ בזק – הו"ק5.1.8.15 יומן אוטומטית

תיווך חשבוניות5.1.8.16דיגיטליות – הו"ק

במבנה מוסכם מייצר פקודתFIקליטת קובץ  יומן אוטומטית

129

מדדים5.1.8.17

- נדרש לפתח ממשקSAPהעברת מדדים ל מדדים עבור מדדים נדרשים )כגון: מדד

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

מדד שלא התקבל

 

ממשק שכר5.1.8.18

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

ממשק שכר יוצא - מפורט בדרישות העסקיות HRתחת מודול

130

SLCMמנהל תלמידים- מודול .5.2

כללי.5.2.1

תתבצע ברובה באמצעות צוות המחשוב של האוניברסיטה.SLCMפעילות היישום והפיתוח בתוך מודול .5.2.1.1

ל-.5.2.1.2 לגלמה כחלקSLCMהאחריות לממשקים ועליו הזוכה הינה באחריות המציע ידי המציע הזוכה על בתוך המודולים שיפותחו .( של הפרויקטFix Priceמהתמחור הכולל )

.פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה.5.2.1.3

רקע.5.2.2

באוניברסיטה מומשו שני מודולים לטיפול בשכר לימוד:.5.2.2.1

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

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

לפרופיט.FI-CA( ואין חיבור מובנה בין FIכיום, הניהול הפיננסי מנוהל במערכת פרופיט )שתוחלף ע"י מודול .5.2.2.1.3 הרישום של ההכנסות השוטפות במערכת פרופיט מבוצע ע"ב דפי בנק )בסיס מזומן( וההתאמה לבסיס

לפרופיט.SAP, ללא אינטגרציה מובנית ביןSLCMמצטבר מבוצעת בסוף שנה ע"ס דוחות שהופקו ל- מטפל במספר סוגים של שכר לימוד:SLCMמודול ה-.5.2.2.2

אקדמי – עבור סטודנטים ישראלים וזרים..5.2.2.2.1 תקציבים סגורים/ מותנים )כגון מכינות, קורסי אנגלית, לימודי חוץ, לימודי המשך שאינם לתואר( – עבור.5.2.2.2.2

סטודנטים ישראלים. - עבור סטודנטים זרים.Study Abroadלימודי חו"ל .5.2.2.2.3תשלומים נלווים )כגון אגודת הסטודנטים, אבטחה( – עבור סטודנטים ישראלים וזרים..5.2.2.2.4

131

מצב קיים - ממשק לספר הראשי )פרופיט(.5.2.3

שכר לימוד אקדמי – רישום בספרים על בסיס מזומן – רק בעת קבלת התקבולים מסטודנטים נרשמות הכנסות..5.2.3.1

(. קיים ממשק אוטומטי שעל בסיסו נרשמת בספרים פקודת יומןYTDשכר לימוד עבור תקציבים סגורים – רישום לפי צפי הכנסות )בסיס מצטבר .5.2.3.2של הכנסות.

)נפתח חשבון ייעודי( וחשבון מרכז בפרופיט )מדובר על חשבונותSLCMתקבולים - קיימים שני סוגי חשבונות בנקים מרכזיים- חשבון מקומי ב-.5.2.3.3(. SAPבנק פיסיים ולא רק חשבונות ב

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

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

2017שכר לימוד .5.2.3.5.12017תקציבים סגורים .5.2.3.5.22017לימודי חו"ל .5.2.3.5.32018שכר לימוד .5.2.3.5.42018תקציבים סגורים .5.2.3.5.52018לימודי חו"ל .5.2.3.5.6

היום: חשבון מרכז תלמידים, חשבון הכנסות משכר לימוד )לפי שנים, יש חלוקה לאקדמי וסגורים, חשבונותSLCMסוגי חשבונות מרכזיים ב-.5.2.3.6 בנקים של יחידות ואופני תשלום.

132

תיאור מצב קיים - עבור שכר לימוד אקדמי.5.2.3.7

133

תיאור מצב קיים - עבור שכר לימוד תקציבים סגורים.5.2.3.8

134

(FIתיאור מצב עתידי נדרש: רישום לספר הראשי ).5.2.4

עבודה על בסיס מצטבר גם עבור אקדמי וגם עבור תקציבים סגורים..5.2.4.1

.FI וסגירת )תקבול( במודול SLCMיצירת צפי ההכנסות שכר לימוד במודול .5.2.4.2

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

, מכיווןcost center )אך נדרש לטייבו( ע"י שימוש באובייקט SLCMיצוין שהמידע של שכר לימוד ברמת חוג/ תכנית או פקולטה קיים במודול ה .5.2.4.4.FI-CAשהרישום של הסטודנטים הוא ברמת חוג שמקושר לפקולטה. מידע זה אינו קיים ב

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

(.Account Determination )לרבות FICA היא דרך מודול SLCM עבור שכר לימוד המנוהל ב FI סטנדרט היכולת לבצע רישומים ב SAPב .5.2.4.6

בשל הסיבות הבאות:FI ל SLCM אלא לחבר את ה FI ל FICAעל אף האמור לעיל הוחלט לא להשתמש בצורה מלאה בחיבור המובנה בין ה .5.2.4.7

.FICAהעדר רזולוציה של חוג/תכנית/ פקולטה במודול .5.2.4.7.1 בשל העובדה שנושא שכר לימוד באוניברסיטה מהווה צינור עיקרי של ההכנסות ובשל מורכבות התחשיב של.5.2.4.7.2

והפיתוחים הרבים שבוצעו במודול.SLCMשכר לימוד במודול

135

תיאור ארכיטקטורה מומלצת – תקציב שכר לימוד אקדמי וסגור – הכנסות.5.2.4.8

136

תיאור ארכיטקטורה מומלצת – תקציב שכר לימוד אקדמי וסגור – תקבולים.5.2.4.9

137

חשבונות בנקים.5.2.4.10

ישנם שני סוגים של חשבונות בנקים )ראה הרחבה בפרק הדן בגזברות(:.5.2.4.10.1חשבונות שכר לימוד – אליהם מופקד הכסף מהסטודנטים עבור שכר לימוד ונלוות..5.2.4.10.1.1זורמים.5.2.4.10.1.2 ולשם לספקים תשלומים מתבצעים מהם האוניברסיטה של מרכזיים חשבונות

התקבולים מחשבונות שכר לימוד מידי לילה. SAPבארכיטקטורה המומלצת, כל חשבונות הבנק )הן בגין שכר לימוד והן החשבונות המרכזיים( ינוהלו ב .5.2.4.10.2

ויבוצעו עבורם התאמות בנקים. כדי לשייך תקבול לסטודנט )וזאת כדי לראות את יתרת חובFI-CAבמקביל דף הבנק המפורט ייקלט גם ל .5.2.4.10.3

הסטודנט המעודכנת( , אלא התקבולים יקלטו ישירות דרך דף הבנק )גם עבור בנק מרכזFI ל FI-CAלא יוגדר חיבור מובנה בין ה .5.2.4.10.4

וגם עבור שכר לימוד ספציפי(.טיפול בעמלות .5.2.4.11

- אינו כולל עמלות על מנת ליצור זיכוי מלא של הסטודנט בגין התשלוםSLCMקובץ התקבולים שייקלט .5.2.4.11.1ששילם.

- יוצגו העמלות בשורות נפרדות מתקבולי שכר לימוד, בגין העמלות תירשם פקודתFIבדף הבנק שייקלט ל.5.2.4.11.2יומן ע"ב דף הבנק:

חובה: הוצאות עמלה .5.2.4.11.2.1זכות: בנק שכר לימוד .5.2.4.11.2.2

138

אמצעי תשלום עבור שכר לימוד:.5.2.4.12

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

FI:ועל בסיסו תירשם פקודה חובה- מזומן.5.2.4.12.1.1.1זכות- הכנסות לקבל .5.2.4.12.1.1.2

תשלומים בכרטיסי אשראי:.5.2.4.12.2נרשם שהסטודנטSLCMמצב קיים: כאשר מתבצעת עסקת תשלומים בכרטיס אשראי, ב .5.2.4.12.2.1

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

תשלומים12 שקלים ב120בוצע תשלום באשראי של – בעת הרישום לאוניברסיטה ניתן להפיק ממודול ה-01.10ב SLCM.דוח של צפי הכנסות

בהתאם לדוח, תירשם פקודה בספרים: 120חובה - הכנסות לקבל

זכות - הכנסות שכר לימוד נדרש: שיוך לפקולטה

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

120חובה - הכנסות מכרטיסי אשראי לקבל* 120זכות - הכנסות לקבל

בגין כל תשלום בודד תירשם הפקודה בהתאם לתנועות בדף הבנק: שקלים10חובה- בנק

10זכות- כרטיסי אשראי לקבל תשלומים בשיקים דחויים:.5.2.4.12.3

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

139

מצב רצוי:.5.2.4.12.3.2דוגמא: סטודנט שילם בשיקים דחויים

(:XXעבור XX-1 – בעת הרישום לאוניברסיטה/ צפי הכנסות )שנה קלנדרית 01.10ב

חובה - הכנסות לקבל

: שיוך לפקולטה נדרש זכות - הכנסות

עם קבלת השיקים הדחויים תירשם הפקודה:

חובה- שטרות לקבל )קופה(

זכות - הכנסות לקבל

בעת פירעון השיק, בהתאם לתנועות בדף הבנק תירשם הפקודה:

חובה – בנק

זכות -שטרות לקבל

נמחק.5.2.5

נמחק.5.2.6

SLCMפירוט דרישות עסקיות ממודול .5.2.7

( 4% בשלב בדיקת התאמת המענה: SLCM משקל הדרישות העסקיות בנושא מודול תתבצע על ידי צוותי המחשוב של האוניברסיטה וחלקן בידיSLCMחלק מפעילות ההתאמה במודול

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

140

" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.2.7.12 ועד 5.2.7.1כל הדרישות העסקיות Fix Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

SLCM-FIממשק 5.2.7.1בגין שכר לימוד

במערכת הנוכחית יש ממשק פקודות יומן לפרופיט עבור שכר לימוד שלSLCMממודול

סטודנטים בתקציבים סגורים- נדרש להרחיב כךFI ל SLCMאת הממשק הקיים מה

שיכיל רזולוציה של פקולטה/חוג כולל פקודותהיומן הרצויות:

 

במועד צפי ההכנסה: ח< הכנסות לקבל ז<הכנסות*

במועד תשלום: ח: מזומן ז: הכנסות לקבל

* רישום ההכנסות יהיה ברזולוציה של פקולטה או תכנית/ חוג ויבוצע על בסיס

YTD פחות מה שנרשם YTD-1

2הממשק יעבוד על בסיס מצטבר ויכיל פקודות: ע"י הרצת מהלך של היפוך הפקודה

הקודמת ויצירה של פקודה חדשה

141

SLCM-FIממשק 5.2.7.2בגין שכר לימוד

לSLCMנדרש להרחיב את הממשק הקיים FIשיכיל את פקודות היומן הרצויות עבור

סטודנטים במסלול אקדמי.

  CCהממשק יכלול פקולטה/חוג המיוצג ע"י

ולא ברמת סטודנט.

2הממשק יעבוד על בסיס מצטבר ויכיל פקודות: ע"י הרצת מהלך של היפוך הפקודה

הקודמת ויצירה של פקודה חדשה

-FIאינטגרציה 5.2.7.3CA-FIבגין מלגות

בגין מלגות שכר לימוד ) מימון פנימי( נדרש עלFI לFI-CAלהפעיל את האינטגרציה בין ה

מנת שיתבצע רישום של פקודות היומןהרצויות:

  CCחובה-הוצאות מלגות מסוגים שונים בשתקצב את אותה מלגה

זכות- הכנסות לקבל גורם מממן

בנוסף נדרש לסגור התחייבות שנוצרהבאופן ידני ) למשל ע"י תרומה (

SLCM-FIממשק 5.2.7.4

מלגות שאינן קשורות לשכר לימוד כגון מלגות קיום במס"ב/המחאות- ממשק

SLCM-FI:הממשק ירשום את הפקודה . 

חובה- הוצאות מלגות

142

זכות- בנק

-FIהחזר שכר לימוד לסטודנטים- ממשק SLCM-FIממשק 5.2.7.5SLCM 

SLCM-FIממשק 5.2.7.6

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

שפיגר בתשלומים ,נלוות )אבטחה, אגודת סטודנטים, דמי הרשמה וכו'( ירשמו ע"ב

מצטבר כדלקמן:

 

במועד צפי ההכנסה: ח< הכנסות לקבל ז<הכנסות*

במועד תשלום: ח: מזומן ז: הכנסות לקבל

* רישום ההכנסות יהיה ברזולוציה של פקולטה או תוכנית/ חוג ויבוצע על בסיס

YTD פחות מה שנרשם YTD-1

בגיןFI ל SLCMכיום יש ממשק מה תקציבים סגורים, ייש לבצע הרחבה לממשק

זה

תקבולים5.2.7.7והתאמות בנקים

התקבולים בגין שכר לימוד ירשמו אוטומטית FI והן בFI-CAמתוך דף הבנק שנקלט הן ב FI ול FICA)הוחלט כי מקור הנתונים ל

לצורך התאמת הבנקים יהיה אותו מקור(

 

143

תשלום בכרטיס5.2.7.8אשראי

עבור עסקאות אשראי בתשלומים, בגין כל תשלום, המערכת תרשום על בסיס דף הבנק

את פקודת היומן הבאה: 

חובה- בנק

זכות- הכנסות מכרטיסי אשראי לקבל

תשלום בכרטיס5.2.7.9אשראי

לאחר שנוצרו במערכת צפי הכנסות לקבל (FIבגין סטודנט ) נרשמה פקודת יומן ב

ובוצע תשלום באמצעות כרטיס אשראיבתשלומים ) ללא קשר למספר התשלומים(

  המערכת תאפשר לרשום על בסיס דו"ח

)שיכיל את סך תשלומיFI-CAשיופק מההסטודנטים באשראי ( את הפקודה הבאה:

חובה- הכנסות מכרטיסי אשראי לקבל

זכות- הכנסות לקבל

תשלום בשיקים5.2.7.10דחויים

לאחר שנוצרו במערכת צפי הכנסות לקבל (FIבגין סטודנט ) נרשמה פקודת יומן ב

ובוצע תשלום באמצעות שיקים דחויים 

המערכת תאפשר לרשום על בסיס דו"ח )שיכיל את סך התשלוםFI-CAשיופק מה

בשיקים( את הפקודה הבאה

144

עם קבלת השיקים הדחויים -

חובה < שטרות לקבל )קופה(

זכות < הכנסות לקבלבעת פירעון השיק :

חובה < בנק זכות < שטרות לקבל

סגירת סעיף5.2.7.11הכנסות לקבל

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

לצורך מיון ביןFI ל FI-CAממשק מה חשבונות הכנסות לקבל שונים )אקדמי, סגור

וכדומה(

 

ניהול מקדמות5.2.7.12

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

הרישום החשבונאי הבא:

 

בשנה הנוכחית: ח < מזומן ז< הכנסות לקבל )ולא להכנסותXXלשנת התקציב הבאה

מראש(

בתקופת חתך, בדוח הכספי סעיף הכנסות יהיה שלילי ולכן נדרש בסוף שנה2018לקבל

למיין באופן ידני:

חובה < הכנסות לקבל לשנת התקציב(XXהבאה )

זכות < הכנסות מראש נרשמת פקודתSLCMבשנה העוקבת מה

FIיומן ל

145

XX חובה < הכנסות לקבל לשנת תקציב

זכות < הכנסות שכר לימוד

תירשם פקודת סטורנו:01.10.2018ב

2,500 חובה < הכנסות מראש

2018 זכות < הכנסות לקבל

2018רישום תקבולים בשנת 2018 חובה < בנק שכר לימוד

7,500 זכות < הכנסות לקבל

בשנה העוקבת: ח< הכנסות מראש ז:הכנסות

".לא נדרש מבוצעות בידי צוותי האוניברסיטה והינן בקטגוריית "5.2.7.15 ועד 5.2.7.13כל הדרישות העסקיות

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

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

146

מס' דרישהעסקית

תיאור הדרישהנושא

5.2.7.13

טיוב

מקושרת למרכז העלות/ פקולטה הנכונה SLCMיש לוודא שכל תכנית ב נתונים

5.2.7.14דוחות

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

אקדמי

לא אקדמי ) פיצול למכינות וכל השאר(

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

5.2.7.15

בקרה

תקציבית-

דוחות

דוחות

SLCM

שיכילו:SLCMהמערכת תאפשר הפקה של דוחות מפורטים מה

מספרי סטודנטים במתכונת דיווח למ"ס לפי תארים, פקולטות ותוכניות לימודים, משלמי שכר לימוד

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

147

(SLCMבית הספר הבינלאומי )חלק אינטגרלי ממודול .5.3

רקע.5.3.1

בית הספר הבינלאומי מנהל שני סוגים עיקריים של הכנסות:.5.3.1.1

אקדמיה - סטודנטים שמגיעים ללמוד תואר מלא, ההכנסות כוללות:.5.3.1.1.1שכר לימוד עבור תואר..5.3.1.1.1.1תשלומים נלווים - ביטוח, אבטחה, דמי שירותים..5.3.1.1.1.2מעונות..5.3.1.1.1.3

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

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

מטבע התשלום בבית הספר הבינלאומי הינו דולר..5.3.1.2

תיאור מצב קיים.5.3.2

.FatFishהרשמה של סטודנטים זרים מתבצעת דרך מערכת .5.3.2.1

ע"י ממשק.SLCM פותחת סטודנט ב-FatFishסטודנט מבצע תשלום ראשוני בהעברה בנקאית של דמי הרשמה, מערכת .5.3.2.2

- יש הפרדה בין סטודנטים ללימודי חו"ל לבין סטודנטים שאינם בלימודי חו"ל.SLCMברישום .5.3.2.3

מבחינת רישום חשבונאי אין הפרדה בין הכנסות משכר לימוד לבין הכנסות מנלווים - הן בנוגע לסטודנטים בינלאומיים והן בנוגע לסטודנטים.5.3.2.4בארץ )בעתיד נדרש פיצול של ההכנסות נלוות כגון ביטוח לכרטיס נפרד(.

חישוב שכר לימוד ונלווים עבור לימודים בינלאומיים מתבצע באותה שיטה כמו בלימודים אקדמיים רגילים, כאשר המטבע עבור הלימודים.5.3.2.5הבינלאומיים הינו דולר, ועבור הלימודים האקדמיים הרגילים הינו ש"ח.

148

תיאור מצב נדרש.5.3.3

תקבולים/ תשלומיםמועד רישום )צפי הכנסות(תרחיש סטודנט5.3.3.1

רגיל

רישום על בסיס מצטבר:

ח: הכנסות לקבל

ז: הכנסות *

* יהיה רישום ברמת פקולטה

אין פיצול של ההכנסות

משירותים נלווים- הכל נרשם

בהכנסות משכר לימוד

יש פיצול לתקציב סגור/לא

סגור

רישום התקבול : ח< מזומן ז<

הכנסות לקבל )ייגזר מחשבון

הבנק אליו מועבר הכסף(

סטודנט5.3.3.2

אקדמי

בתכניות

בינלאומיות

רישום על בסיס מצטבר: -

בדומה לסטודנט ישראלי

רישום ברמת פקולטה/ תכנית

ח: הכנסות לקבל שכר לימוד

כולל נלווים

ח: הכנסות לקבל ביטוח

ז: הכנסות שכר לימוד

)ברמת פקולטה(

ז: הכנסות שכר לימוד בגין

ביטוח

נדרש פיצול של סעיפי

הכנסות מסוימים )לדוגמא

ישנם מספר אמצעי תשלום:

שיק/מזומן/העברה

בנקאית/אשראי

תירשם פקודה כנגד הכנסות

לקבל:

ח: מזומן

ז: הכנסות לקבל – שכר

לימוד

ז: הכנסות לקבל – ביטוח

הכסף של הביטוח למעשה

נגבה ועובר במלואו לחברת

הביטוח- כאשר מתקבל תקבול

149

תקבולים/ תשלומיםמועד רישום )צפי הכנסות(תרחיש

ביטוח( לסעיף נפרד ולא

כחלק מהכנסות שכר לימוד

סכום זה יועבר לחברת ביטוח

ולכן נדרש ניהול של הסכום

בנפרד

נרשמת פקודה/ חשבונית

חובה- הכנסות שכר לימוד בגין

ביטוח

זכות- ספק

סטודנט חול5.3.3.3

study

abroad-

תקציבים

מותנים-

נקראים

סגורים

באוניברסיט

ה

הרישום מתבצע על פקולטה

שנקראת בית הספר

הבינלאומי

ח: הכנסות לקבל שכר לימוד

)כולל פעילות חברתית(

ח: הכנסות לקבל ביטוח

ז: הכנסות שכר לימוד

)ברמת פקולטה ותכנית(

ז: הכנסות שכר לימוד בגין

ביטוח

ישנם מספר אמצעי תשלום:

שיק/מזומן/העברה

בנקאית/אשראי

תירשם פקודה כנגד הכנסות

לקבל:

ח: מזומן

ז: הכנסות לקבל – שכר

לימוד

ז: הכנסות לקבל – ביטוח

הכסף של הביטוח למעשה

נגבה ועובר במלואו לחברת

הביטוח- כאשר מתקבל תקבול

נרשמת פקודה/ חשבונית

חובה- הכנסות שכר לימוד בגין

ביטוח

זכות- ספק

תקבול שמתקבל צריך לזכות ח: הכנסות לקבל שכר לימוד סטודנט5.3.3.4

150

תקבולים/ תשלומיםמועד רישום )צפי הכנסות(תרחיש

מעורב

תכניות

בינלאומיות

ולימודי חו"ל

Study

Abroad

– אקדמי

ח: הכנסות לקבל שכר לימוד

- מותנה

ח: הכנסות לקבל ביטוח

ז: הכנסות שכר לימוד –

אקדמי

ז: הכנסות שכר לימוד –

מותנה

ז: הכנסות שכר לימוד בגין

ביטוח

קודם כל את החוב שיש מול

הכנסותהתקציב המותנה )

,לקבל שכר לימוד – מותנה(

במידה ויש, ורק לאחר מכן את

החלק האקדמי

דמי שירותים מיוחסים תמיד

לאקדמי

פירוט דרישות עסקיות בנושא בית הספר הבינלאומי.5.3.4

( 2% משקל הדרישות העסקיות בנושא בית הספר הבינלאומי בשלב בדיקת התאמת המענה:

תתבצע על ידי צוותי המחשוב שלSLCMחלק מפעילות ההתאמה עבור בית הספר הבינלאומי במודול

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

בידי מנהל הפרויקט מטעם המציע.

151

Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.3.4.3 ועד 5.3.4.1כל הדרישות העסקיות

Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק ( של הפרויקט

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהםSAPהתייחסות למודולי

מתבסס בהצעתו(

תשלומים נלווים5.3.4.1

בגין תשלומים נלווים רצויים )כגון ביטוח, אבטחה( נדרש לפתוח חשבונות ייעודיים הן

בצד ההכנסות והן בצד ההכנסות לקבלעבור נלווים אלו.

 

ירשום פקודת יומןfi-caהממשק של ה לחשבון הייעודי הרלוונטי עבור תשלומים

נלווים אלו

תקבולים בגין תכניות5.3.4.2בינלאומיות

סטודנט מעורב תכניות בינלאומיות ולימודי - תקבול שמתקבל צריךStudy Abroadחו"ל

לזכות קודם כל את החוב שיש מול התקציבהמותנה ורק לאחר מכן את החלק האקדמי

 

תופעל אותה לוגיקה של רישום על סמךFI-CAחשבון הבנק ופיצול באמצעות דוח מה

מעונות5.3.4.3 כאשר מתקבל תשלום בדף הבנק המערכת

 תרשום את הפקודה הבאה:

חובה- מזומן

152

זכות- הכנסות לקבל

לא". המציע לא נדרש מבוצעות בידי צוותי האוניברסיטה והינן בקטגוריית "5.3.4.5 ועד 5.3.4.4כל הדרישות העסקיות

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

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

מס'דריש

העסקי

ת

תיאור הדרישהנושא

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

לבין המעונות על מנת לסגור את חוב הסטודנט במודול מעונותcmממשק בין ה

5.3.4.5 (PCהמערכת תתמוך ברישום בגין הכנסות בבית הספר הבינלאומי יירשמו ברמת בית הספר ) רישום

או ברמה נמוכה יותר ) ברמת חוג (

153

154

(SLCMגורמים מממנים )חלק אינטגרלי ממודול .5.4

תיאור מצב קיים.5.4.1

קטגוריות:3גורם מממן הינו גוף פנימי או חיצוני שנותן מלגות או פטורים לסטודנטים. ניתן לסווג את כל הגורמים המממנים ל .5.4.1.1

גורם מממן פנימי..5.4.1.1.1גורם מממן חיצוני שעבורו נדרש להפיק דרישת תשלום בלבד..5.4.1.1.2גורם ממן חיצוני שעבורו נדרש להפיק חשבונית..5.4.1.1.3

אין הבדל בין גורמים מממנים לבית הספר הבינלאומי והאקדמיה מלבד מטבע המימון..5.4.1.2

דוגמאות לגורמים מממנים:.5.4.1.3

אוניברסיטאות - גורם חיצוני - נדרש להפיק חשבונית..5.4.1.3.1בית הספר הבינלאומי - גורם פנימי..5.4.1.3.2מסע- גורם חיצוני - לא נדרש להפיק חשבונית, דרישת תשלום בלבד..5.4.1.3.3משרד החוץ - גורם חיצוני - נדרש להפיק חשבונית..5.4.1.3.4אגודת הידידים - לא נדרש להפיק חשבונית..5.4.1.3.5

155

תיאור מצב נדרש.5.4.2

ע"מ לשקף נכונה את יתרת הסטודנט לתשלום ולהפיק מסמכיםSLCMהדרישה היא להגדיר אינטגרציה בין הזכות למלגה/פטור לבין מודול ה .5.4.2.1לגורם המממן )הפקת חשבונית או דרישת תשלום(.

נדרש להבחין בין מלגות המשולמים/מתוקצבות ע"י גורמים מממנים לבין מצב של פטור מתשלום שכר לימוד:.5.4.2.2

במצב של מלגה - הכנסות שכר לימוד ירשמו בגישת הברוטו )רישום הכנסות משכר לימוד בסכום מלא(..5.4.2.2.1ב.5.4.2.2.2

מצב של פטור –שכר הכנסות ירשמו לימוד הנטו בגישת

)בניכוי הפטור(.סוגי2קיימים .5.4.2.3 מלגות:

מ.5.4.2.3.1לגות שכר לימוד

מ.5.4.2.3.2שכר שאינן לגות

לימוד. . SLCMבמידה וסטודנט זכאי למלגה מהאוניברסיטה מתבצעת בדיקה של יתרת הסטודנט ב-.5.4.2.4

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

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

1,000, פטור/ מלגה 10,000דוגמא: שכר לימוד: .5.4.2.7

156

פירוט דרישות עסקיות בנושא גורמים מממנים.5.4.3

( 2% משקל הדרישות העסקיות בנושא גורמים מממנים בשלב בדיקת התאמת המענה: " ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.4.3.4 ועד 5.4.3.1כל הדרישות העסקיות

Fix Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק ( של הפרויקט

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהםSAPהתייחסות למודולי

מתבסס בהצעתו(

הפקת דרישה5.4.3.1למימון מלגה

בעת אישור המלגה/המימון ע"י הגורם המממן נדרש להפיק דרישה למימון מלגה לגורם מממן

CM- אם חיצוני ואם פנימי דרך מודול

  במקביל תרשם פקודת יומן אוטומטית לרבותמספר סטודנט/מספר ח"פ:

חובה- הכנסות לקבל גורם מממן פנימי/חיצוני

זכות- הכנסות לקבל שכר לימוד

הפקת דרישת5.4.3.2תשלום/קבלה

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

ובמקביל תירשם הפקודה הבאה: 

חובה- מזומן

זכות- הכנסות לקבל גורם מממן

157

גורם מממן חיצוני5.4.3.3

בגורם חיצוני נדרש לעקוב אחרי קליטת התקבול וסגירת ההתחייבות ע"י ניתוח כרטיס

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

הפקודה הבאה 

חובה- לקוח זכות- הכנסות לקבל גורם מממן חיצוני + ציון

מס' ח"פ

ע"י כך יתאפשר ניתוח יתרות החובה של כרטיסהכנסות לקבל גורם מממן פנימי

גורם מממן פנימי5.4.3.4

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

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

 להזין מס' סטודנט

חובה- סעיף תקציבי זכות- הכנסות לקבל גורם מממן + ציון מס'

סטודנט

ע"י כך יתאפשר ניתוח יתרות החובה של כרטיסהכנסות לקבל מגורם מממן פנימי

158

מערכת לתכנון תקציב.5.5

רקע.5.5.1

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

יחידות הארגוניות השונות שישוקפו כמרכזי עלות..5.5.1.2

רזולוציה של אינדקס החשבונות שיוגדר..5.5.1.3

בעת תהליכי התכנון, רזולוציית התכנון משתנה בין אגף תקציבים )שמתקצב בעיקר ברמת פקולטה( לבין.5.5.1.3.1הפקולטות שמעוניינות לתקצב ברמה נמוכה יותר

159

מטרות המערכת.5.5.2

רק תקציב רגיל ומותנה, לא מנוהל תקציב מחקרים, סגורים ופיתוח )בינוי((TM1ניהול כלל התקציבים באוניברסיטה )כיום מנוהל ב- .5.5.2.1

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

(CC + אובייקט תמחירי )GL למערכת התקציב – שימוש ברזולוציה של כרטיס SAPיצירת שפה אחידה בין ה .5.5.2.3

שיפור וייעול תהליך תכנון התקציב.5.5.2.4

שיפור רמת השקיפות, זמינות ועדכניות הנתונים.5.5.2.5

אוטומציה מרבית והתערבות ידנית מינימאלית.5.5.2.6

תמיכה בבדיקות נתונים אוטומטיות והתראות על שגויים וחריגים.5.5.2.7

עקרונות מרכזיים.5.5.3

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

על המערכת לאפשר ניהול גרסאות תקציב, ביצוע ותחזיות שונות..5.5.3.2

על המערכת לאפשר שמירת מידע היסטורי והשוואתו למידע עדכני..5.5.3.3

על המערכת לתמוך בשליחת התראות אוטומטיות לביצוע פעולות..5.5.3.4

על המערכת לתמוך בהפצת מידע באופן אוטומטי..5.5.3.5

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

What If Analysisאפשרות תחקור וניהול תרחישים בזמן אמת – .5.5.3.7

160

משתמשי המערכת.5.5.4

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

משתמשים עפ"י החלוקה להלן:50סה"כ צפויים להשתמש במערכת ) בסיום ההטמעה( כ- .5.5.4.2

Adminשני משתמשי .5.5.4.2.1 מתכנני תקציב הינם עבור מרכזי עלות ספציפיים(35 מתכנני תקציב )מתוכם כ-5.5.4.2.2.45 קוראי דוחות.5.5.4.2.3.5

ארכיטקטורת מערכות מידע.5.5.5

המערכת תהיה מערכת עצמאית אך תהווה חלק ממערך מערכות המידע בארגון..5.5.5.1

מערכות המידע המרכזיות הקיימות באוניברסיטה ורלוונטיות לתהליך התקציב: .5.5.5.2

5.5.5.2.1.SAP-מערכת ה – ERP המרכזית מל"מ - מערכת ניהול השכר .5.5.5.2.2

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

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

161

ממשקים.5.5.6

הממשקים יבוצעו כתוכנית גזירה שתבוצע באופן ממוכן על פי דרישה. .5.5.6.1

המערכת תאפשר לבצע את הממשקים באמצעות פעולה יזומה או בתדירות אוטומטית כפי שתוגדר.5.5.6.2

ברזולוציה ובתדירות שתוגדרSAP, BIהמערכת תאפשר לבצע ממשקים ממערכת התכנון למערכת ה- .5.5.6.3

עבור הממשקים, כך שרק לאחר שיחידת בקרה ותקציב אישרה את הממשק, הנתונים שהתקבלו בממשק יתעדכנוWFהמערכת תאפשר לנהל .5.5.6.4במודלים השונים.

המערכת תאפשר לבצע שינוי בנתונים שהתקבלו בממשק מבלי לפגוע בנתוני המקור שהתקבלו..5.5.6.5

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

הממשק תהיה על פי הממדים המשותפים לכל המודלים ובמודלים הספציפיים על פי הממדים הקיימים במודלים הספציפיים.הרזולוציה של.5.5.6.7

162

ישויות ורזולוציית התכנון.5.5.7

ממדי התכנון והמדידה העיקריים המשותפים לכל המודלים )ראה נספח א עם רשימת ערכים מפורטת(:.5.5.7.1

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

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

ללא כמות(, שלבים אלו רלוונטיים לגרסה הראשונית של התקציב , בכל שלב תוקפא התצורה של התקציב.ההיררכיה של הממד תתעדכן באמצעות דלתאות וגם ב"סכום אפס".5.5.7.1.3.1בממד זה יהיו שלבים אשר לא יכנסו להיררכיה של השינויים .5.5.7.1.3.2ו/או.5.5.7.1.3.3 קודמות ו/או תקופות נתונים של תקופה קודמת יהיו נתוני הבסיס לחלק משלבי התכנון

שנים אחורה(3ממוצע של תקופות קודמות לפי בחירה )למשל ממוצע של many to many- מייצג את היחידות הארגוניות )כולל פקולטות ותוכניות לימוד(, קיים קשר של מרכז עלות .5.5.7.1.4

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

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

ובקרהממד זה צריך להיות דינמי.5.5.7.1.4.2

5.5.7.1.5.GL – הממד מייצג את רשימת החשבונות הפיננסיים – COA.מטבעות/הצמדות.5.5.7.1.6 קיימים ממדים נוספים שיידרשו למודלים ספציפיים כגון עובדים למודל שכר הכולל מעמד, דירוגים, דרגות.5.5.7.1.7

ודרג. יתכנו שינויים בממדים - כולל הוספה או גריעה של ממדים. הוספה או הגריעה לא תשנה מהותית את.5.5.7.1.8

המודל

163

מתודולוגיית תהליך בניית התקציב.5.5.8

1.2.3.4.5.

5.1.5.2.5.3.5.4.5.5.

5.5.1.5.5.2.5.5.3.5.5.4.5.5.5.5.5.6.5.5.7.5.5.8.

164

תפיסת התכנון הכללית.5.5.8.1

תדירות התכנון הינה שנתית.5.5.8.1.1על המערכת לאפשר:.5.5.8.1.2

רמת התכנון חודשית )פריסת נתונים שנתיים ע"פ מתודולוגיה סדורה(..5.5.8.1.2.1 רמת תכנון שנתית ואלוקציה לחודש, לפי מפתחות מובנים שיעברו בין שנים כברירת מחדל עם.5.5.8.1.2.2

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

המערכת תתמוך בתכנון במטבעות מקור או בסיסי הצמדה שונים.5.5.8.1.3על המערכת להיות גמישה בצורה מספקת בכדי לאפשר הוספת/עדכון מודלי תכנון שונים בעתיד..5.5.8.1.4 ( אשר ישפיעו על תוצאות החישוב הסופי, ללאAdjעבור כל מודל, המערכת תאפשר לבצע הזנות ידניות ).5.5.8.1.5

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

הכל כפי שיאופיין עלWFבכל מודל, המערכת תאפשר קיום של מסכי הזנה על ידי היחידות השונות וביצוע .5.5.8.1.6ידי יחידת תקציב ובקרה, )שלבי תכנון(

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

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

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

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

על המציע להציע פתרונות אשר יציגו את ההשפעה האמורה בזמן אמת של ההזנה באותו מסך שבו מבוצע.5.5.8.1.10השינוי

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

תאפשר לבצע אלוקציה אוטומטית לרמת הבנים.

165

166

לוח הזמנים של תהליך התכנון.5.5.8.2

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

בדיקות "בפועל מול תכנון" יבוצעו )הן כמות והן כסף( באופן חודשי..5.5.8.2.2 נתוני הביצוע שלעל המערכת לתמוך בהערכות תחזית לסיום השנה שיתבצעו באופן שוטף ויסתמכו על .5.5.8.2.3

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

167

גרסאות התכנון.5.5.8.3

גרסאות התכנון הנדרשות הינן:.5.5.8.3.1

פרטיםרזולוציהתדירות עדכוןגרסה

תכנון מלא של תקציב המאושר ע"י ההנהלהחודשיתשנתיתקציב5.5.8.3.1.1

5.5.8.3.1.2חודשיתחודשי/רבעוניביצוע

טעינה של נתוני הביצוע ממערכות המקור לצורך

ביצוע תחזיות

5.5.8.3.1.3

תחזית לסוף שנהRolling Forecastחודשיתחודשי/רבעוני

גרסה המשלבת נתוני ביצוע + תחזית עד לסוף

להיות יכולה שנה לסוף עד התחזית השנה.

ויכולה לשלב את מתוכננת כמו גרסת התקציב

נתוני הביצוע + נתוני התקציב עד לסוף השנה.

5.5.8.3.1.4

חודשיתחודשי/רבעוניתחזית

החודשים של הביצוע נתוני המשלבת גרסה

ו/או שנים קודמות )לפי נוכחית שהסתיימו שנה

עד הנותרים החודשים של תחזית + בחירה(

לסוף השנה אשר תתבסס על התקציב העדכני

+ שינויים.

5.5.8.3.1.5חודשיתמעת לעתסימולציות

שמירת גרסאות אד הוק של התקציב המתקבלות

ע"י שינוי פרמטרים במודל התכנון

168

גרסאות תכנון יכולות להיערך על בסיס גרסאות אחרות. לדוגמא: גרסת התקציב יכולה להוות בסיס לגרסה.5.5.8.3.2"תחזית לסוף שנה".

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

סוגי תקציבים.5.5.8.4

המערכת תאפשר לנהל את סוגי התקציב הבאים:.5.5.8.4.1תקציב שוטף )רגיל ומותנה(.5.5.8.4.1.1

תקציב רגיל.5.5.8.4.1.1.1יחידת תקציב ובקרה מתקצבת ברמת פקולטה.5.5.8.4.1.1.1.1 לאחר אישור התקציב על ידי הגורמים הרלוונטיים, הפקולטות השונות.5.5.8.4.1.1.1.2

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

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

המכינה האוניברסיטאית, בית הספר הבינלאומי וכו'תקציב סגור .5.5.8.4.1.2

תאפשר.5.5.8.4.1.2.1 המערכת בפועל. הכנסות ולא להכנסות הצפי גובה עד נרשמות הוצאות תקציב סגור בניהול רב שנתי.

תקציב מחקר )פנימי וחיצוני(.5.5.8.4.1.3אל מערכת התכנון באופןSAP GMתקציב מחקר פנימי וחיצוני יטען ממערכת ה- .5.5.8.4.1.3.1

שאופיין על ידי יחידת תקציב ובקרה GMנתוני הביצוע עבור תקציב מחקר פנימי – יתכן ויתקבלו מיחידת החשבות או מ-.5.5.8.4.1.3.2

SAPתקציב פיתוח - מודל הזנה פר פרויקט רב שנתי .5.5.8.4.1.4

169

ניהול גרסאות.5.5.8.5

העברת נתונים בין גרסאות – על המערכת לאפשר העברת נתונים )באופן כללי או ספציפי( בין הגרסאות.5.5.8.5.1השונות.

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

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

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

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

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

מהמודלים השונים המרכיבים את סעיפיו. לפני ואחרי אלוקציה.על המערכת לאפשר דוחות השוואה בין תקופות..5.5.8.6.5 ( אשר יכללו חישובים שונים ויושפעו בזמן אמת מכל שינויKPI'sעל המערכת לאפשר בניית דוחות מדדים ).5.5.8.6.6

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

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

דרישות כלליות.5.5.8.7

המערכת צריכה לאפשר לבנות מודל משולב:.5.5.8.7.15.5.8.7.1.1.Bottom Upלדוגמא: באזורים של שכר 5.5.8.7.1.2.Top Downכגון: תכנון פרויקט בניה

170

המערכת תאפשר לתכנן יתרות )"סכום אפס"( או דלתאות, ותאפשר צפייה גם ברמת דלתאות וגם ברמת.5.5.8.7.2יתרות )"סכום אפס"(

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

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

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

המערכת תאפשר לצרף מסמכים למודלי התכנון השונים, ו/או לשורה מסוימת במודל התכנון.5.5.8.7.6 בכל מודל ובכל שלב המערכת תאפשר למשתמש לרשום הערות במלל חופשי. על המציע לציין האם ניתן.5.5.8.7.7

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

המציג את השדות שלא תוקצבו, ברזולוציה של מרכז עלות. על המציע לציין את האפשרות הקיימת במערכת.5.5.8.7.9 בגין תוצאות שחושבו בכל מודל. drill throughעל המערכת לאפשר ביצוע .5.5.8.7.10 למערכת המקור - רמת הטרנזקציהdrill throughעל המציע לציין האם המערכת תומכת בביצוע .5.5.8.7.11

171

הרשאות.5.5.8.8

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

בממדmembersהמערכת תתמוך בהרשאות גישה )כתיבה/קריאה( לאלמנטים/ .5.5.8.8.2 המערכת תתמוך בהרשאות גישה לסגירת ופתיחת תקופה. כאשר תקופה נסגרה המערכת תחסום את.5.5.8.8.3

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

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

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

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

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

סימולציות.5.5.8.9

המערכת תתמוך בעריכת סימולציות.5.5.8.9.1המערכת תאפשר לבצע סימולציות, .5.5.8.9.2

לדוגמה: בחינת ההשפעה של תוספת סטודנטים על:.5.5.8.9.2.1הכנסות שכר לימוד.5.5.8.9.2.1.1הכנסות משכ"ד ממעונות.5.5.8.9.2.1.2

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

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

למשתמש קצה ובזמן אמת.172

המערכת תאפשר לבחון את רווחיות הפקולטה )ניתוח הכנסות/הוצאות פקולטה ועודף/גרעון(.5.5.8.9.4המערכת תאפשר ניהול של הרשאות יצירה, שינוי וצפייה בסימולציות.5.5.8.9.5

מודלים.5.5.9

5.5.9.

173

מודל הכנסות.5.5.9.1

המודל מבוסס על סוגי ההכנסות הבאים:.5.5.9.1.1הקצבות מות"ת.5.5.9.1.1.1הכנסות מסטודנטים.5.5.9.1.1.2הכנסות מתרומות.5.5.9.1.1.3הכנסות מקרנות חיצוניות )תרומות שנים קודמות(.5.5.9.1.1.4פירות מקרנות צמיתות.5.5.9.1.1.5הכנסות שונות.5.5.9.1.1.6שימוש בהשקעות מיועדות לפנסיה ופיצויים.5.5.9.1.1.7שימוש בקרנות למימון פרויקטים חד פעמיים.5.5.9.1.1.8שאר ההכנסות.5.5.9.1.1.9הקצבות מות"ת – מרכיב ההוראה )תקציב רגיל ומותנה(.5.5.9.1.1.10

הממדים במודל:.5.5.9.1.2מרכז עלות.5.5.9.1.2.1תחום - יכול להיות מקושר לפקולטה אחת או יותר.5.5.9.1.2.2תואר - ראשון, שני, דוקטורט ותעודת הוראה וכו'.5.5.9.1.2.3( וכו'6011, 6010סוג תלמיד - שכר לימוד רגיל, שכר לימוד גבוה, סמוכי גמר ).5.5.9.1.2.4סוג תכנית - לדוגמה חרדי.5.5.9.1.2.5

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

המודל

דוגמא למודל הכנסות – הקצבות מות"ת מרכיב ההוראה:.5.5.9.1.5

174

175

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

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

המודל יאפשר להזין פרמטרים שונים אשר יוזנו בכל שלב במודל אשר ישפיעו על תוצאות החישוב..5.5.9.1.8 ( אשר ישפיעו על תוצאות החישוב הסופי, ,ללא דריסת תוצאותAdjהמודל יאפשר לבצע הזנות ידניות ).5.5.9.1.9

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

שיוזן ידנית בגרסת התכנון או בגרסה אחרת.הקצבות מות"ת – מרכיב המחקר.5.5.9.1.11

ו/או ממוצע שנים.5.5.9.1.11.1 קודמות ו/או שנים קודמת המודל יאפשר להעתיק את הנתונים של שנה קודמות ולבצע בהם שינויים ידניים שישפיעו על התוצאה הסופית. השינויים שיבוצעו לא ידרסו

את הנתונים שהועתקו המודל יאפשר לבצע אלוקציה מתחום ו/או מרכיבי המחקר למרכז עלות לפי מפתח שיוגדר או.5.5.9.1.11.2

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

ו/או ממוצע שנים.5.5.9.1.12.1 קודמות ו/או שנים קודמת המודל יאפשר להעתיק את הנתונים של שנה קודמות ולבצע בהם שינויים ידניים שישפיעו על התוצאה הסופית. השינויים שיבוצעו לא ידרסו

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

מודל הכנסות - הכנסות מתרומות לתקציב רגיל ומותנה.5.5.9.1.13ו/או ממוצע שנים.5.5.9.1.13.1 קודמות ו/או שנים קודמת המודל יאפשר להעתיק את הנתונים של שנה

קודמות ולבצע בהם שינויים ידניים שישפיעו על התוצאה הסופית. השינויים שיבוצעו לא ידרסואת הנתונים שהועתקו

לחילופין, המודל יאפשר להזין ידנית את ההכנסות ברזולוציה של המודל.5.5.9.1.13.2

176

מודל הכנסות - הכנסות מסטודנטים - שכר לימוד.5.5.9.1.14הממדים במודל:.5.5.9.1.14.1

מרכז עלות.5.5.9.1.14.1.1תואר - ראשון, שני, דוקטורט ותעודת הוראה וכו'.5.5.9.1.14.1.2( וכו'6011, 6010סוג תלמיד - שכר לימוד רגיל, שכר לימוד גבוה, סמוכי גמר ).5.5.9.1.14.1.3סוג תכנית - לדוגמה חרדי.5.5.9.1.14.1.4

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

מהותית את המודלדוגמא למודל הכנסות מסטודנטים –שכר לימוד.5.5.9.1.14.5

177

FTEחישוב מקדמי .5.5.9.1.14.6

178

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

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

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

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

בממשקה- .5.5.9.1.14.11 ממשק ממערכת לבצע תאפשר לימודSAPהמערכת שכר של בפועל נתונים עבור

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

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

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

לימוד. המודל יאפשר לבצע ממוצע של שכר לימוד ברזולוציה של המודל כולל סוג תקציב, במסגרת.5.5.9.1.14.14

חישוב של עלות, באמצעות חלוקתFTEזו המערכת תאפשר ו/או מרכז סוג תקציב לפי הממוצע שחושב במודל בתעריף שנקבע מתעריפון שיוזן ידנית )למשל תעריף מל"ג(.

בסוגי תקציב ו/או במרכזי עלות מסוימים המערכת תאפשר להגדיר ברירת.5.5.9.1.14.14.1של FTEמחדל = שלב1 בכל מיוחדות(. לימודים תכניות )לדוגמה: .

.FTEהמערכת תאפשר לבצע שינוי ידני לברירת המחדל של ה- המודל יאפשר להזין פרמטרים שונים אשר יוזנו בכל שלב במודל אשר ישפיעו על תוצאות.5.5.9.1.14.15

החישוב. .WFבמידה והפרמטרים יוזנו על ידי היחידות השונות, המודל יאפשר לבצע תהליך של .5.5.9.1.14.16

179

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

שהתקבל במערכת.מודל הכנסות - הכנסות מסטודנטים - שכ"ד מעונות.5.5.9.1.15

הממדים במודל:.5.5.9.1.15.1מרכז עלות.5.5.9.1.15.1.1סוג מעון.5.5.9.1.15.1.2חדר.5.5.9.1.15.1.3

דוגמא למודל תכנון הכנסות שכ"ד-מעונות.5.5.9.1.15.2

180

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

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

מטבעות. יתכנו שינויים בממדים - כולל הוספה או גריעה של ממדים. הוספה או הגריעה לא תשנה.5.5.9.1.15.5

מהותית את המודלמודל הכנסות - הכנסות מסטודנטים - דמי הרשמה.5.5.9.1.16

אין ממדים ספציפיים למודל..5.5.9.1.16.1 עבור התקופה שנבחרה בפרמטריםCM SAPהמערכת תאפשר לבצע ממשק ממערכת ה- .5.5.9.1.16.2

)שנה אחת או יותר אחורה(. המודל יאפשר להזין ידנית את הנתונים של השנה הנוכחית, לחילופין המודל יאפשר להזין את.5.5.9.1.16.3

השינוי באחוזים ברזולוציה חודשית, בהתאם לכך, המודל יחשב את כמות הנרשמים שנהנוכחית.

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף..5.5.9.1.16.4 המודל יאפשר להזין פרמטרים שונים אשר יוזנו בכל שלב במודל אשר ישפיעו על תוצאות.5.5.9.1.16.5

החישוב.מודל הכנסות - מכינה ותלמידי חו"ל.5.5.9.1.17

אין ממדים ספציפיים למודל..5.5.9.1.17.1דוגמא למודל תכנון הכנסות תלמידי חו"ל/מכינה.5.5.9.1.17.2

181

182

המודל יאפשר להעתיק את הנתונים של שנה קודמת ולבצע בהם שינויים ידניים. השינויים.5.5.9.1.17.3שיבוצעו לא ידרסו את הנתונים שהועתקו.

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

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

מטבעות. יתכנו שינויים בממדים - כולל הוספה או גריעה של ממדים. הוספה או הגריעה לא תשנה.5.5.9.1.17.6

מהותית את המודלמודל הכנסות - הכנסות מסטודנטים -אחרות מוסדי תכניות לימוד מותנות.5.5.9.1.18

אין ממדים ספציפיים למודל.5.5.9.1.18.1המודל יאפשר להזין ידנית את תקציב ההכנסות המוסדי תכניות לימוד מותנות.5.5.9.1.18.2

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

אין ממדים מיוחדים במודל.5.5.9.1.19.1/ הזנות.5.5.9.1.19.2 ידניים ולבצע בהם שינויים המודל יאפשר להעתיק את הנתונים של שנה קודמת

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

הכנסות - שימוש בקרנות למימון פרויקטים חד פעמיים.5.5.9.1.20אין ממדים מיוחדים במודל.5.5.9.1.20.1/ הזנות.5.5.9.1.20.2 ידניים ולבצע בהם שינויים המודל יאפשר להעתיק את הנתונים של שנה קודמת

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

פטורים.5.5.9.1.21 המודל יאפשר להעתיק את נתוני הביצוע של שנה קודמת ו/או שנים קודמות ו/או ממוצע שנים.5.5.9.1.21.1

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

183

המודל יאפשר להזין ידנית מקדם אשר ישפיע על התעריף ו/או על הכמות..5.5.9.1.21.2המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף..5.5.9.1.21.3

הכנסות ברוטו-נטו.5.5.9.1.22 המודל יאפשר להציג את ההכנסות ברוטו לפי מרכיב ההכנסה ולפי מרכז עלות במודלים.5.5.9.1.22.1

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

מודל שכר.5.5.9.2

כללי.5.5.9.2.1הממדים במודל: .5.5.9.2.1.1

מרכז עלות.5.5.9.2.1.1.1סוג הוצאה - על פי סמלי שכר.5.5.9.2.1.1.2סוג עובד - מנהלי, אקדמי, שעתי וכו'.5.5.9.2.1.1.3מעמד - סגל אקדמי בכיר, תלמידי מחקר, עוזרי הוראה וכו'.5.5.9.2.1.1.4מהנדסים,.5.5.9.2.1.1.5 מח"ר, כמו: קיבוציים הסכמים עם דירוגים קיימים - דירוגים

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

התגמולים בגין דרגה, שעות נוספות ורכבעלות השכר לא תתוכנן ברמת עובד.5.5.9.2.1.2 יתכנו שינויים בממדים - כולל הוספה או גריעה של ממדים. הוספה או הגריעה לא תשנה.5.5.9.2.1.3

מהותית את המודל המודל יאפשר לבצע המרה של שעות ויחידות הוראה למונחים של משרות שנתיות , וזאת.5.5.9.2.1.4

באמצעות מקדם שיקבע לפי סוג העסקה, לדוגמה, תרגום של שעות מנהליות לאחוז משרה משרה )בהיקף שנתי(.1 שעות מנהליות = 2400יהיה:

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

184

185

מודל שכר - מנהלי ואקדמי.5.5.9.2.2דוגמא למודל שכר מנהלי ואקדמי.5.5.9.2.2.1

186

ה- .5.5.9.2.2.2 לבצע ממשק ממערכת כמותHRהמערכת תאפשר של וממל"מ הרקטור וממערכת משרות/שעות לפי הממדים במודל.

הממשק כולל משרות קיימות ותכנון כמות משרות/שעות הכולל תוספות ו/או.5.5.9.2.2.2.1גריעות ו/או שינויים

הממשק כולל שינויים בכמות המשרות/שעות..5.5.9.2.2.2.2 הרזולוציה של הממשק יכלול בין היתר: סוג תקציב, תקופה )חודש ושנה(,.5.5.9.2.2.2.3

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

הוראה, שעות עובדים שעתיים, שעות נוספות ועוד. . לאחר אישור הממשק, עבור מרכזיWFהמודל יאפשר לאשר/לדחות את הממשק באמצעות .5.5.9.2.2.3

עלות שיוגדרו - המערכת תאפשר לאפס את כמות העובדים בגרסה שתוגדר בשלב האפיוןהמפורט.

המודל יאפשר לבצע הזנה ידנית לכמות המשרות/יחידות הוראה/שעות ועוד הצפויות למרכזי.5.5.9.2.2.4עלות.

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

הכוללות.5.5.9.2.2.6 צפויות הוראה/שעות המשרות/יחידות כמות סה"כ את לחשב יאפשר המודל שבתון/ללא שבתון.

של: עלות שכר בפועלSAP FIהמערכת תאפשר לבצע ממשק ממערכת מל"מ וממערכת .5.5.9.2.2.7 וכמות לפי סוג הוצאה )סמלי שכר( ולפי הממדים במודל.

המודל יאפשר לחשב עלות ממוצעת ברזולוציה של: מרכז עלות, סוג הוצאה,.5.5.9.2.2.7.1סוג עובד, מעמד, דירוג, דרגה ודרג.

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

ולנתוני.5.5.9.2.2.9 )"תעריפון"( שחושב לנתוני התעריף הממוצע ידניים שינויים לבצע יאפשר המודל הכמות שהתקבלו בממשק. השינויים יכולים לכלול תוספת/שינוי/גריעה.

187

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

ידנית. במקרים בהם הדירוג והדרגה לא ידועים, המודל יאפשר לבצע הזנה ידנית או אלוקציה לפי.5.5.9.2.2.11

מפתח שיוגדר בחתך של הממדים. המודל יאפשר לבצע שינויים ידניים בגין האלוקציה שבוצעה..5.5.9.2.2.11.1

דירוג.5.5.9.2.2.12 כולל המודל יאפשר להציג ממוצע משוקלל ברמת פקולטה בחתך של כל הממדים ודרגה )ללא דרג(

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

כמות.5.5.9.2.2.14 ללא הכפלה של ביחידות מסוימות לתכנן את סה"כ הוצאות השכר יאפשר המודל בעלות

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

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

שהתקבל במערכתמודל שכר - הוצאות שכר שלא דרך המל"מ – לדוגמא שבתון.5.5.9.2.3

דוגמא למודל הוצאות שכר שלא דרך מל"מ – שבתון עבור סגל אקדמי בכיר .5.5.9.2.3.1

188

189

5.5.9.2.3.2.- יהיה חלק ממודל שכר ויוחלט שהוצאות שכר בגין שבתון, יתכן בשלב האפיון המפורט, מנהלי ואקדמי

ו/או מהסאפ, עבור:.5.5.9.2.3.3 המערכת תאפשר לבצע ממשק ממערכת השבתון או ממערכת מל"מ כמות עובדים קיימת בשבתון, עלות ממוצעת לעובד ברזולוציה של סוג ההוצאה )סמלי שכר(

מרכז עלות, סוג עובד, מעמד, דירוג ודרגה המערכת תאפשר לבצע ממשק ממערכת השבתון או ממערכת מל"מ, ו/או מהסאפ, עבור:.5.5.9.2.3.4

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

דירוג, דרגה ותקופהו/או מהסאפ.5.5.9.2.3.5 המודל יאפשר לבצע בקרת השוואה בין הכמות שהתקבלה ממערכת המל"מ

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

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

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

החישוב ( אשר ישפיעו על תוצאות החישוב הסופי, ,ללא דריסתAdjהמודל יאפשר לבצע הזנות ידניות ).5.5.9.2.3.9

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

190

דוגמא למודל הוצאות שכר משאבים רכים.5.5.9.2.3.10

191

של: עלות שכר בפועל ,SAP FIהמערכת תאפשר לבצע ממשק ממערכת מל"מ וממערכת .5.5.9.2.3.11ואיוש מתוקצב וכמות לפי סוג הוצאה )סמלי שכר(. עלות שכר בפועל ממוצעת, תקן גבוה במסגרת הממשק המערכת תאפשר לקבל בממשק את סך הכמויות וסך העלויות בגין כל סוג

הוצאההמערכת תאפשר לבצע חישוב לעלות שכר בפועל ממוצעת. .5.5.9.2.3.11.1 הממוצע והכמות יחושבו ברזולוציה של: מרכז עלות, סוג עובד, מעמד, דירוג,.5.5.9.2.3.11.2

דרגה ודרג המודל יאפשר להזין פרמטרים שונים )כמות/עלות/תוצאה( אשר יוזנו בכל שלב במודל אשר.5.5.9.2.3.12

ישפיעו על תוצאות החישובעודכנה.5.5.9.2.3.13 ו/או לנהל את העלות הממוצעת שהתקבלה בממשק או שחושבה יאפשר המודל

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

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

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

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

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

192

מודל שכר - קרן קשרי מדע.5.5.9.2.4דוגמא למודל הוצאות שכר שלא דרך המל"מ – קרן קשרי מדע.5.5.9.2.4.1

193

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

ו/או ממערכת המל"מ ו/או מהסאפ של כמותHRהמערכת תאפשר לבצע ממשק ממערכת .5.5.9.2.4.3העובדים הזכאים, ברזולוציה של: מרכז עלות, דירוג ודרגה, סוג עובד ומעמד

ו/אוHRהמערכת תאפשר לבצע ממשק של התעריף של קרן קשרי מדע ממערכת מל"מ ו/או .5.5.9.2.4.4 , מרכז עלות, סוג הוצאהGLסאפ, ברזולוציה של: תקופה )חודש ואו שנה ו/או רבעון וכו(,

)סמלי שכר(, מעמד דירוג ודרגהאת.5.5.9.2.4.5 יהוו שהתקבל התעריף בתוספת אשר לתעריף, ידניים שינויים לבצע יאפשר המודל

התעריף המחושב המודל יאפשר להזין פרמטרים שונים )כמות/תעריף/תוצאה( אשר יוזנו בכל שלב במודל אשר.5.5.9.2.4.6

ישפיעו על תוצאות החישוב הסופי המודל יאפשר לתכנן את הוצאות השכר - קרן קשרי מדע באמצעות הכפלה של כמות בתעריף.5.5.9.2.4.7

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

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

מודל שכר - תשלום פנסיה תקציבית.5.5.9.2.5המודל יאפשר קיום של מסכי הזנה הכוללים כמות ותעריף.5.5.9.2.5.1 המודל יאפשר לתכנן את הוצאות השכר - תשלום פנסיה תקציבית באמצעות הכפלה של.5.5.9.2.5.2

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

מלגות.5.5.9.3

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

המודל יאפשר לבצע שינויים ידניים או הזנות ידניות בנתונים שהתקבלו בממשק או בנתונים שהועתקו.5.5.9.3.2משנה קודמת. השינויים שיבוצעו לא ידרסו את נתוני המקור.

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף..5.5.9.3.3

194

הכנסות והוצאות אחרות.5.5.9.4

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

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

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

והממד הקובע את רזולוצית המודל. המסכים יאופיינו על ידי יחידת תקציב ובקרה בחלק מההכנסות/הוצאות גובה ההכנסה/ההוצאה תקבע באמצעות הכפלה של כמות בתעריף.5.5.9.4.6המודל יאפשר להזין ידנית את הנתונים של ההכנסה/הוצאה כסכום כולל. .5.5.9.4.7 .GL לסוג המודל ברזולוציה המפורטת יותר מכרטיס ה- GLבמודל תתוחזק טבלת המיפוי המקשר בין סעיף .5.5.9.4.8

לדוגמה, נוסף ממד נדרש והאם בתעריף הכמות של מכפלה ידנית, הזנה המודל: לסוג דוגמאות בניינים/סוגי שמירה.

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

המודל יאפשר לשנות ידנית את הנתונים שהוקצו למרכז עלות מבלי לדרוס אותם..5.5.9.4.10

195

– דוגמא לתעריפוןGLדוגמא למודל תפעול ותחזוקה ברזולוציה מפורטת יותר מכרטיס ה- .5.5.9.4.11

מחקרים.5.5.9.5

למערכת התכנוןSAP GMהמערכת תאפשר לבצע ממשק של הוצאות המחקר תכנון ובפועל ממערכת ה- .5.5.9.5.1 , מרכז עלות וסעיף הוצאה, והכל כפי שיאופיין על ידי יחידת תקציבGLברזולוציה של תקופה )חודש ושנה(,

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

ובקרה המודל יאפשר לבצע אלוקציה בממד מרכז עלות ) בין פרויקטים( בהתאם לטבלת מיפוי המשייכת עובד.5.5.9.5.3

מחקר לפרויקט

196

ארכיטקטורה כללית- קשר בין המודולים לתכנון התקציב.5.5.9.5.4

197

198

פונקציונליות נדרשת- כללי .5.5.10

5.5.10.

ו/או ממשק אקסלי אינטגרטיבי.webעל המערכת לתמוך בממשק .5.5.10.1

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

על המציע לציין את פלטפורמת תוכנת ההפעלה ואת תצורת הפלטפורמה והחומרה המומלצת על ידו. .5.5.10.3

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

199

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

על המציע לתאר בהיבט פונקציונאלי את התוכנות/ המודלים המוצעים. .5.5.10.5

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

( יהיו בבעלות בלעדית של האוניברסיטה. על ספק המידע להציג את המסמכים המוריםR\Tכל רישיונות וזכויות השימוש, לרבות רישיונות הרצה ).5.5.10.6זאת לנציג מטעם האוניברסיטה.

200

תצורת המערכת.5.5.11

5.5.11.

המציע יציג את פרטי תצורת המערכת באופן הטוב ביותר לדרישות המתוארות במסמך זה..5.5.11.1

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

המציע יתאר האם ואיך התצורה של המערכת מושפעת מעליה משמעותית במספר המשתמשים, מהתדירות של שאילתות משתמשי הקצה.5.5.11.2והמורכבות של המודלים המתוארים במסמך זה, וכו'.

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

201

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

האם המערכת מאפשרת עבודה על שרתים וירטואליים?.5.5.11.4

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

202

בסיס הנתונים.5.5.12

5.5.12.

, SQL Serverהמציע יתאר את המתודולוגיה המשמשת לניהול הנתונים וכיצד הנתונים מאוחסנים: רב ממדי )קוביה(, מסד נתונים רלציוני ).5.5.12.1Oracleבמידה וניהול הנתונים דורש מסד נתונים חיצוני אשר אינו חלק ממערכת התקציב, על המציע לציין זאת ולפרט את עלות הרישוי .) בגינו.

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

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

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

_________________________________________________________________________________________

203

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

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

יכולות פונקציונליות.5.5.13

5.5.13.

המציע יתאר את המתודולוגיה והטכנולוגיה של ייצוא הדוחות מהמערכת. כמו גם דוחות אחרים שהמערכת מציעה..5.5.13.1

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

המציע יתאר כיצד ניתן לבנות דוח חדש ללא תמיכה של המציע. .5.5.13.2

________________________________________________________________________________________

________________________________________________________________________________________

________________________________________________________________________________________

204

________________________________________________________________________________________

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

על המערכת לאפשר יכולות ניתוח בזמן אמת.5.5.13.4

על המערכת לתמוך במבנה הארגוני של האוניברסיטה - תמיכה בעץ ישויות מורכב וכן לאפשר סיווג, הוספה וניהול ישויות ע"י המשתמשים.5.5.13.5

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

על יכולות הניתוח להיות אינטואיטיביות, פשוטות לשימוש ובעלות יכולות ניתוח חוצות ממדי תכנון )כלומר: חיתוך אורכי ורוחבי של הנתונים לפי.5.5.13.7ממדי חיתוך נבחרים. טבלאות ציר וכדומה..(.

על המערכת לאפשר יכולת אגריגציה וחישובים מורכבים של הנתונים בזמן הזנתם..5.5.13.8

על המערכת לתמוך ביכולת תחקור חישובים לרמת הבסיס..5.5.13.9

על המערכת לאפשר מיון ע"פ רכיב בודד ורכיבים רבים.5.5.13.10

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

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

על המערכת לאפשר הפקת גרפים מסוגים שונים.5.5.13.13

על המערכת לאפשר הזנת הערות משתמש בתהליך התכנון בתא הרלוונטי להערה.5.5.13.14

חתימות בתהליך מוגדרWorkflowעל המערכת לאפשר תהליך .5.5.13.15

על המערכת לאפשר שליחת מיילים ו/או התראות מהמערכת באופן אוטומטי.5.5.13.16

205

פירוט דרישות עסקיות בנושא תכנון תקציב.5.5.14

( 20% משקל הדרישות העסקיות בנושא תכנון תקציב בשלב בדיקת התאמת המענה:

" ויש להכליל אותן בתמחור הכוללנדרש. הינן בקטגוריית "5.5.14.189 ועד 5.5.14.1כל הדרישות העסקיות

(Fix Price .של הפרויקט )תמחור נפרד לדרישות עסקיות אילו.אין לספק

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

עקרונות5.5.14.1מרכזיים

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

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

 

עקרונות5.5.14.2מרכזיים

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

עקרונות5.5.14.3מרכזיים

על המערכת לאפשר שמירת מידע היסטורי והשוואתו למידע עדכני.

עקרונות5.5.14.4מרכזיים

על המערכת לתמוך בשליחת התראות אוטומטיות לביצוע פעולות

עקרונות5.5.14.5מרכזיים

על המערכת לתמוך בהפצת מידע באופן אוטומטי

206

עקרונות5.5.14.6מרכזיים

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

פעילות, וכמות משתמשים 

עקרונות5.5.14.7מרכזיים

אפשרות תחקור וניהול תרחישים בזמן אמת –What If Analysis 

משתמשי5.5.14.8המערכת

לקוחות ומשתמשי המערכת הינם אנשי התקציבים והכלכלה באוניברסיטה

משתמשי5.5.14.9המערכת

סה"כ צפויים להשתמש במערכת )בסיום משתמשים עפ"י החלוקה50ההטמעה( כ-

8.5.4המפורטת בסעיף  

ארכיטקטורת5.5.14.10מערכות מידע

המערכת תהיה מערכת עצמאית אך תהווה חלק ממערך מערכות המידע בארגון

ארכיטקטורת5.5.14.11מערכות מידע

מערכות המידע המרכזיות הקיימות באוניברסיטהורלוונטיות לתהליך התקציב:

 SAP -מערכת ה – ERPהמרכזית

מל"מ – מערכת לניהול השכר

207

ארכיטקטורת5.5.14.12מערכות מידע

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

תתמוך ביכולת קליטת נתונים או בעדכון נתונים במערכות נוספות אשר יוטמעו בעתיד במערכות

האוניברסיטה

 

ארכיטקטורת5.5.14.13מערכות מידע

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

כנדרש.  

הממשקים יבוצעו כתוכנית גזירה שתבוצע באופןממשקים5.5.14.14 ממוכן על פי דרישה.

ממשקים5.5.14.15

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

כפי שמפורט במודלים הספציפיים. הרזולוציה של הממשק תהיה על פי המימדים המשותפים לכל המודלים ובמודלים הספציפיים על פי המימדים

הקיימים במודלים הספציפיים.

 

ממשקים5.5.14.16 המערכת תאפשר לבצע ממשקים ממערכת

ברזולוציה ובתדירותSAP, BIהתכנון למערכת ה- שתוגדר

 

208

ממשקים5.5.14.17

עבור הממשקים, כךWFהמערכת תאפשר לנהל שרק לאחר שיחידת בקרה ותקציב אישרה את הממשק, הנתונים שהתקבלו בממשק יתעדכנו

במודלים השונים.

 

המערכת תאפשר לבצע שינוי בנתונים שהתקבלוממשקים5.5.14.18 בממשק מבלי לפגוע בנתוני המקור שהתקבלו

ממשקים5.5.14.19 המערכת תאפשר לבצע את הממשקים

באמצעות פעולה יזומה או בתדירות אוטומטיתכפי שתוגדר

 

ישויות ורזולוציית5.5.14.20התכנון

מימדי התכנון והמדידה העיקריים המשותפים לכל המודלים )ראה נספח א עם רשימת ערכים

מפורטת( 

ישויות ורזולוציית5.5.14.21התכנון

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

ושנה.  

ישויות ורזולוציית5.5.14.22התכנון

גרסאות - גרסאות תכנון כגון: בסיס, עדכונים, גרסאות פקולטות, סופית לפני אלוקציות, סופית

אחרי אלוקציות, בפועל וכדומה  

   ישויות ורזולוציית5.5.14.23

209

התכנון

שלבי תכנון - שלבי תכנון כגון: שלב בסיס, שלב א – לאחר החלטת הנהלה, שלב ב – מידוד )עדכון מחיר ללא כמות(, שלבים אלו רלוונטיים לגרסה

הראשונית של התקציב , בכל שלב תוקפאהתצורה של התקציב.

ההיררכיה של המימד תתעדכן באמצעותדלתאות וגם ב"סכום אפס"

במימד זה יהיו שלבים אשר לא יכנסו להיררכיהשל השינויים

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

שנים אחורה( 3של

ישויות ורזולוציית5.5.14.24התכנון

מרכז עלות - מייצג את היחידות הארגוניות )כולל many toפקולטות ותוכניות לימוד(, קיים קשר של

manyלמימד תחום )במודלים הספציפיים שהמימד תחום קיים בהם(. קיים קשר לסוג

תקציב )מאפיין( – רגיל, מותנה וסגור וכו'

 

210

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

)גבוהה יותר(, כפי שיאופיין על ידי יחידת תקציבובקרה

מימד זה צריך להיות דינמי

ישויות ורזולוציית5.5.14.25התכנון

GLהמימד מייצג את רשימת החשבונות –  .COAהפיננסיים –

ישויות ורזולוציית5.5.14.26 מטבעות/הצמדות התכנון

ישויות ורזולוציית5.5.14.27התכנון

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

מהותית את המודל 

ישויות ורזולוציית5.5.14.28התכנון

קיימים מימדים נוספים שיידרשו למודלים ספציפיים כגון עובדים למודל שכר הכולל מעמד,

דירוגים, דרגות ודרג. 

5.5.14.29

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

 תדירות התכנון הינה שנתית.

5.5.14.30

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

על המערכת לאפשר:

  • רמת התכנון חודשית )פריסת נתונים שנתייםע"פ מתודולוגיה סדורה(.

211

הכללית

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

עם אפשרות לשינוי המפתח בין השנים

בכל שלב של תכנון המערכת צריכה לאפשר הזנות ידניות אשר ישפיעו על התוצאה הסופית

של התכנון.

5.5.14.31

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

המערכת תתמוך בתכנון במטבעות מקור או בסיסי הצמדה שונים

5.5.14.32

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

על המערכת להיות גמישה בצורה מספקת בכדי לאפשר הוספת/עדכון מודלי תכנון שונים בעתיד

5.5.14.33

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

עבור כל מודל, המערכת תאפשר לבצע הזנות ( אשר ישפיעו על תוצאות החישובAdjידניות )

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

במערכת או בגין ממשק שהתקבל במערכת

 

212

5.5.14.34

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

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

שיאופיין על ידי יחידת תקציב ובקרה, )שלביתכנון(

 

5.5.14.35

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

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

בבקשות שהוגשו על ידי היחידות. במידה ויבוצע שינוי על ידי יחידת תקציב ובקרה הוא יבוצע

בגרסה/אלמנט ייעודי וישפיע על התוצאה הסופי

 

5.5.14.36

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

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

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

והכל במועדים אשר יקבעו על ידי יחידת תקציבובקרה

 

מתודולוגיית5.5.14.37 תהליך בניית

התקציב - תפיסת התכנון

הכללית

oבכל שנוי שמבוצע על ידי המשתמש, המערכת תאפשר לראות את ההשפעה של השינוי על דוח

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

 

213

על המציע להציע פתרונות אשר יציגו את ההשפעה האמורה בזמן אמת של ההזנה באותו

מסך שבו מבוצע השינוי .

על המציע לתמחר פתרונות אלו בנפרד

5.5.14.38

מתודולוגיית תהליך בניית

התקציב - תפיסת התכנון

הכללית

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

לרמת הבנים.

 

לוח הזמנים של5.5.14.39תהליך התכנון

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

בסבבים

 

לוח הזמנים של5.5.14.40תהליך התכנון

בדיקות "בפועל מול תכנון" יבוצעו )הן כמות והן כסף( באופן חודשי.

לוח הזמנים של5.5.14.41תהליך התכנון

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

הביצוע של החודשים שהסתיימו שנה נוכחית ו/או שנים קודמות בתוספת תחזית של החודשים

הנותרים עד לסוף השנה אשר תתבסס על התקציב העדכני בתוספת שינויים

 

214

5.5.14.42

מתודולוגיית תהליך בניית

התקציב -גרסאות התכנון

גרסאות התכנון הנדרשות מפורטות במסמך ה-RFP . 

ניהול גרסאות5.5.14.43תקציב

גרסאות תכנון יכולות להיערך על בסיס גרסאות אחרות. לדוגמא: גרסת התקציב יכולה להוות

בסיס לגרסה "תחזית לסוף שנה". 

ניהול גרסאות5.5.14.44תקציב

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

בבדיקות שונות. 

5.5.14.45

מתודולוגיית תהליך בניית

 התקציב - ניהול גרסאות

העברת נתונים בין גרסאות – על המערכת לאפשר העברת נתונים )באופן כללי או ספציפי(

בין הגרסאות השונות. 

5.5.14.46

מתודולוגיית תהליך בניית

 התקציב - ניהול גרסאות

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

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

בצורה קלה וידידותית למשתמש.

 

215

5.5.14.47

מתודולוגיית תהליך בניית

 התקציב - ניהול גרסאות

שמירת מידע היסטורי – על המערכת לתמוך בשינויים של חלק מנתוני התכנון או ישויות התכנון

ללא השפעה על גרסאות היסטוריות ותוך מתן אפשרות להשוואה בין הגרסאות העדכניות

להיסטוריות.

 

5.5.14.48

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

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

המערכת לחשב ולהציג את ההפרשים ביןהגרסאות וכו'.

 

5.5.14.49

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

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

  במסגרת זו על המערכת לאפשר בניית דוחות

בקרה שונים כפי שיאופיינו על ידי יחידת תקציבובקרה.

216

5.5.14.50

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

על המערכת לכלול דוח על הפעילות מרכז ודוח על הפעילות למרכז עלות בכל הגרסאות אשר

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

 

5.5.14.51

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

  על המערכת לאפשר דוחות השוואה בין תקופות

5.5.14.52

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

(KPI'sעל המערכת לאפשר בניית דוחות מדדים ) אשר יכללו חישובים שונים ויושפעו בזמן אמת

מכל שינוי בכל מודל במערכת. 

5.5.14.53

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

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

לאחר הרצת תהליך חישוב כלשהו. 

5.5.14.54

מתודולוגיית תהליך בניית

 התקציב - דוחות ותוצרים

oעל המציע לציין האם קיימת אפשרות להפקת , ותוכנות אופיס בגרסהPowerPointמצגת ב- העדכנית

 

דרישות כלליות5.5.14.55

המערכת צריכה לאפשר לבנות מודל משולב:

  Bottom Upלדוגמא: באזורים של שכר

Top Downכגון: תכנון פרויקט בניה

217

דרישות כלליות5.5.14.56 המערכת תאפשר לתכנן יתרות )"סכום אפס"( או דלתאות, ותאפשר צפייה גם ברמת דלתאות וגם

ברמת יתרות )"סכום אפס"( 

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

כדי לעקוב אחר ההיסטוריה 

דרישות כלליות5.5.14.58 המערכת צריכה להיבנות בצורה אינטגרטיבית –

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

 

דרישות כלליות5.5.14.59

המערכת תאפשר לנהל וורסיות תכנוניות מקומיות )לדוגמא: משאבי אנוש(, לרבות

אפשרות בקרה של אגף תקציבים, כך שרק לאחר אישור האגף יעודכן התקציב הכולל והכל כפי

שיאופיין בשלב האיפיון המפורט.

 

המערכת תאפשר לצרף מסמכים למודלי התכנוןדרישות כלליות5.5.14.60 השונים, ו/או לשורה מסויימת במודל התכנון

218

דרישות כלליות5.5.14.61

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

 

דרישות כלליות5.5.14.62

על המערכת לאפשר מתן התראה באמצעות התראה אוטומטית למייל ו/או באמצעות הפקת

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

על המציע לציין את האפשרות הקיימת במערכת

דרישות כלליות5.5.14.63

בגיןdrill throughעל המערכת לאפשר ביצוע תוצאות שחושבו בכל מודל.

  על המציע לציין האם המערכת תומכת בביצוע

drill throughלמערכת המקור - רמת הטרנזקציה

סוגי תקציבים5.5.14.64

המערכת תאפשר לנהל את סוגי התקציב הבאים:

 תקציב שוטף )רגיל ומותנה(

         תקציב רגילo        יחידת תקציב ובקרה מתקצבת ברמת

פקולטה

219

o        לאחר אישור התקציב על ידי הגורמים הרלוונטים, הפקולטות השונות )ברובן( מפזרות

את התקציב לחוגים וסעיפי הוצאה

         תקציב מותנה )בהכנסות( הוצאות נרשמות עד גובה הצפי להכנסות ולא הכנסות בפועל –

המערכת תאפשר תקציב מותנה בניהול רבשנתי.

o          תכנית לימודים

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

בית הספר הבינלאומי וכו'

תקציב סגור

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

בניהול רב שנתי.

תקציב מחקר )פנימי וחיצוני(

         -תקציב מחקר פנימי וחיצוני יטען ממערכת הSAP GMאל מערכת התכנון באופן שאופיין על

ידי יחידת תקציב ובקרה

220

         – נתוני הביצוע עבור תקציב מחקר פנימי SAP GMיתכן ויתקבלו מיחידת החשבות או מ-

תקציב פיתוח - מודל הזנה פר פרויקט רבשנתי

הרשאות5.5.14.65 המערכת תתמוך בהרשאות גישה למימדים: כגון:

גרסאות, שלבי תכנון, פקולטה וחשבונות)ובשילובים שלהם(

 

המערכת תתמוך בהרשאות גישההרשאות5.5.14.66  במימדmembers)כתיבה/קריאה( לאלמנטים/

הרשאות5.5.14.67

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

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

 

הרשאות5.5.14.68

המערכת תאפשר את ניהולן של הרשאות גישה שונות )יצירה, שינוי, צפייה( לביצוע פעולות שונות

)הזנת נתונים, נעילת אזורים לשינוי, תחזוקת טבלאות, קביעת פרמטרים, ניהול גרסאות,

הרשאה לתהליכים התקציביים, הפקת וצפייהבדו"חות(.

 

221

הרשאות5.5.14.69

הרשאות ינוהלו ע"פ היררכיה, בהתאם למבנה הארגוני של האוניברסיטה באופן אשר יאפשר

הגדרת הרשאות הן בעבור קבוצות משתמשיםוהן בעבור המשתמש הבודד

 

הרשאות5.5.14.70

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

ויחידות עסקיות. 

יושם דגש רב על הרשאות על מודל השכר מאחרוהוא יכלול מידע רגיש

הרשאות5.5.14.71

oמנגנוני הגנה – מנגנונים אשר יאפשרו הגנה על נתוני התכנון משינויים לא מאושרים. על המערכת

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

התכנון, לתהליך תכנון ספציפי, מודל תכנוןספציפי או תהליך התכנון כולו

 

 המערכת תתמוך בעריכת סימולציותסימולציות5.5.14.72

סימולציות5.5.14.73

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

 

הכנסות שכר לימודהכנסות משכ"ד מעונות

222

דוגמה נוספת: בחינת ההשפעה שלתוספת/גריעה של תקן בשכר על: הוצאות השכר

סימולציות5.5.14.74

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

ההוצאות ו/או עודף/)גירעון(, באופן כזה שכל שבזמן ביצוע השינוי משתמש המפתח יראה במקביל את ההשפעה המתרחשת בעקבות

השינוי, והכל במסכים נוחים למשתמש קצהובזמן אמת.

 

המערכת תאפשר לבחון את רווחיות הפקולטהסימולציות5.5.14.75 )ניתוח הכנסות/הוצאות פקולטה )עודף/גירעון(

המערכת תאפשר את ניהול של הרשאות יצירה,סימולציות5.5.14.76 שינוי וצפייה בסימולציות

מודל הכנסות -5.5.14.77כללי

המודל מבוסס על סוגי ההכנסות הבאים:

 - הקצבות מות"ת

- הכנסות מתרומות- הכנסות מסטודנטים

- הכנסות מקרנות חיצוניות )תרומות שניםקודמות(

223

• פירות מקרנות צמיתות• הכנסות שונות

• שימוש בהשקעות מיועדות לפנסיה ופיצויים

• שימוש בקרנות למימון פרוייקטים חד פעמיים

• שאר ההכנסות         הקצבות מות"ת – מרכיב ההוראה )תקציב

רגיל ומותנה(

5.5.14.78 מודל – הקצבות מות"ת –מרכיב

ההוראה

המימדים במודל:

 

מרכז עלות תחום - יכול להיות מקושר לפקולטה אחת או

יותר

תואר - ראשון, שני, דוקטורט ותעודת הוראה וכו'

סוג תלמיד - שכר לימוד רגיל, שכר לימוד גבוה,(6011, 6010סמוכי גמר )

סוג תוכנית - לדוגמה חרדי וכו'

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

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

מהותית את המודל

224

5.5.14.79 מודל – הקצבות מות"ת - מרכיב

הוראה

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

ידי יחידת תקציב ובקרה.

 

5.5.14.80 מודל –

הקצבות מות"ת- מרכיב הוראה

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

 - יחס סטודנטים סגל

- הוצאת שורש מיחס סטודנטים סגל

- מכפלה בתעריף משוקלל המחושב ממוצע

5.5.14.81 מודל – הקצבות מות"ת - מרכיב

הוראה

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

החישוב 

5.5.14.82 מודל – הקצבות מות"ת - מרכיב

הוראה

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

להיות בגין חישוב שבוצע במערכת או ממשקשהתקבל במערכת

 

225

5.5.14.83 מודל - הקצבות מות"ת - מרכיב

הוראה

המודל יאפשר לבצע אלוקציה מתחום למרכז עלות לפי מפתח שיוגדר )יחס מספר סטודנטים(

או לפי סכום שיוזן ידנית בגרסת התכנון אובגרסה אחרת

 

5.5.14.84 מודל – הקצבות מות"ת - מרכיב

המחקר

המודל יאפשר להעתיק את הנתונים של שנה קודמת ו/או שנים קודמות ו/או ממוצע שנים

קודמות ולבצע בהם שינויים ידניים. שישפיעו על התוצאה הסופית. השינויים שיבוצעו לא ידרסו את

הנתונים שהועתקו

 

5.5.14.85 מודל – הקצבות מות"ת - מרכיב

המחקר

המודל יאפשר לבצע אלוקציה מתחום ו/או מרכיבי המחקר למרכז עלות לפי מפתח שיוגדר

או לפי סכום שיוזן ידנית בגרסת התכנון אובגרסה אחרת

 

5.5.14.86

מודל – הקצבות מות"ת -

הקצבות אחרות והקצבותייעודיות

המודל יאפשר להעתיק את הנתונים של שנה קודמת ו/או שנים קודמות ו/או ממוצע שנים

קודמות ולבצע בהם שינויים ידניים. שישפיעו על התוצאה הסופית.

לחילופין, המודל יאפשר להזין ידנית אתההכנסות ברזולוציה של המודל

226

5.5.14.87

מודל הכנסות - הכנסות

מתרומות לתקציב רגיל

ומותנה

המודל יאפשר להעתיק את הנתונים של שנה קודמת ו/או שנים קודמות ו/או ממוצע שנים

קודמות ולבצע בהם שינויים ידניים. שישפיעו על התוצאה הסופית. השינויים שיבוצעו לא ידרסו את

 הנתונים שהועתקו

לחילופין, המודל יאפשר להזין ידנית אתההכנסות ברזולוציה של המודל

5.5.14.88

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

המימדים במודל:

 

מרכז עלות

תואר - ראשון, שני, דוקטורט ותעודת הוראה וכו'

סוג תלמיד - שכר לימוד רגיל, שכר לימוד גבוה,( וכו'6011, 6010סמוכי גמר )

סוג תוכנית - לדוגמה חרדי

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

- במודל זה לא נדרש מימד של סטודנט

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

מהותית את המודל

227

5.5.14.89

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

של ממערכת ממשק לבצע תאפשר המערכת ו/או אקדמי לתכנון לכמותCMהיחידה

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

 

5.5.14.90

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

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

)תוספות/גריעות/שינויים( לפי תקופה ותואר , סוגתקציב, מרכז עלות, סוג תלמיד, סוג תוכנית

 

5.5.14.91

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

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

סוג תוכנית וסוג תלמיד לפי מפתח שיוגדר או לפיסכום שיוזן ידנית.

 

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

5.5.14.92

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

המערכת תאפשר לבצע ממשק ממערכת ה-SAPעבור נתונים בפועל של שכר לימוד בהתאם

לתקופה שתיבחר בפרמטרים, הממשק יבוצעברזולוציה של המודל

 

228

המערכת תאפשר שנתונים אלו שהתקבלו בממשק ישמשו לצורך חישוב ההכנסות שכר

לימוד במודל

5.5.14.93

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

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

לימוד. 

5.5.14.94

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

לימוד שכר של ממוצע לבצע יאפשר המודל ברזולוציה של המודל כולל סוג תקציב, במסגרת

של חישוב תאפשר המערכת סוגFTEזו לפי חלוקת באמצעות עלות, מרכזי ו/או תקציב שנקבע בתעריף במודל שחושב הממוצע

מתעריפון שיוזן ידנית )למשל תעריף מל"ג(.

 

o       מסויימים עלות במרכזי ו/או תקציב בסוגי FTEהמערכת תאפשר להגדיר ברירת מחדל של

לימודים מיוחדות(. בכל1 = )לדוגמה: תוכניות . שלב המערכת תאפשר לבצע שינוי ידני לברירת

. FTEהמחדל של ה-

  מודל הכנסות -5.5.14.95

הכנסות מסטודנטים -שכר לימוד

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

החישוב

 

229

במידה והפרמטרים יוזנו על ידי היחידות השונות,WFהמודל יאפשר לבצע תהליך של

5.5.14.96

מודל הכנסות - הכנסות

מסטודנטים -שכר לימוד

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

שהתקבל במערכת.

 

5.5.14.97

מודל הכנסות - הכנסות

מסטודנטים -שכ"ד מעונות

המימדים במודל:

 מרכז עלות

סוג מעוןחדר

5.5.14.98

מודל הכנסות - הכנסות

מסטודנטים -שכ"ד מעונות

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

בגרסה אחרת כך שנתוני המקור יהיו ללא שינוי

 

5.5.14.99

מודל הכנסות - הכנסות

מסטודנטים -שכ"ד מעונות

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף. לעיתים התעריף הוא במטבע זר אזי

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

מטבעות

 

230

5.5.14.100

מודל הכנסות - הכנסות

מסטודנטים -שכ"ד מעונות

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

מהותית את המודל 

5.5.14.101

מודל הכנסות - הכנסות

מסטודנטים -דמי הרשמה

 אין מימדים ספציפיים למודל

5.5.14.102

מודל הכנסות - הכנסות

מסטודנטים -דמי הרשמה

המערכת תאפשר לבצע ממשק ממערכת ה-SAP CMעבור התקופה שנבחרה בפרמטרים

)שנה אחת או יותר אחורה( 

5.5.14.103

מודל הכנסות - הכנסות

מסטודנטים -דמי הרשמה

המודל יאפשר להזין ידנית את הנתונים של השנה הנוכחית, לחילופין המודל יאפשר להזין את

השינוי באחוזים ברזולוציה חודשית, בהתאם לכך,המודל יחשב את כמות הנרשמים שנה נוכחית

 

5.5.14.104

מודל הכנסות - הכנסות

מסטודנטים -דמי הרשמה

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף

5.5.14.105

מודל הכנסות - הכנסות

מסטודנטים -דמי הרשמה

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

החישוב. 

מודל הכנסות -5.5.14.106 הכנסות

מסטודנטים - מכינה ותלמידי

 אין מימדים ספציפיים למודל

231

חו"ל

5.5.14.107

מודל הכנסות - הכנסות

מסטודנטים - מכינה ותלמידי

חו"ל

המודל יאפשר להעתיק את הנתונים של שנה קודמת ולבצע בהם שינויים ידניים. השינויים

שיבוצעו לא ידרסו את הנתונים שהועתקו 

5.5.14.108

מודל הכנסות - הכנסות

מסטודנטים - מכינה ותלמידי

חו"ל

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

החישוב 

5.5.14.109

מודל הכנסות - הכנסות

מסטודנטים - מכינה ותלמידי

חו"ל

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף. לעיתים התעריף הוא במטבע זר אזי

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

מטבעות

 

5.5.14.110

מודל הכנסות - הכנסות

מסטודנטים - מכינה ותלמידי

חו"ל

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

מהותית את המודל 

5.5.14.111

מודל הכנסות - הכנסות

מסטודנטים - אחרות מוסדי תוכניות לימוד

מותנות

 אין מימדים ספציפיים למודל

מודל הכנסות -5.5.14.112 הכנסות

מסטודנטים - אחרות מוסדי

המודל יאפשר להזין ידנית את תקציב ההכנסותהמוסדי תוכניות לימוד מותנות

 

232

תוכניות לימודמותנות

5.5.14.113

מודל הכנסות - הכנסות מקרנות

חיצוניות, הכנסות שונות,

שימוש בהשקעות המיועדות

לפנסיה ופיצוייםושאר ההכנסות

 אין מימדים ספציפיים למודל

5.5.14.114

מודל הכנסות - הכנסות מקרנות

חיצוניות, הכנסות שונות,

שימוש בהשקעות המיועדות

לפנסיה ופיצוייםושאר ההכנסות

המודל יאפשר להעתיק את הנתונים של שנה קודמת ולבצע בהם הזנות/שינויים ידניים / הזנות ידניות. השינויים שיבוצעו לא ידרסו את הנתונים

שהועתקו

 

5.5.14.115

מודל הכנסות - הכנסות מקרנות

חיצוניות, הכנסות שונות,

שימוש בהשקעות המיועדות

לפנסיה ופיצוייםושאר ההכנסות

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף

5.5.14.116

הכנסות - שימוש בקרנות למימון פרויקטים חד

פעמיים

 אין מימדים ספציפיים למודל

233

5.5.14.117

הכנסות - שימוש בקרנות למימון פרויקטים חד

פעמיים

המודל יאפשר להעתיק את הנתונים של שנה קודמת ולבצע בהם שינויים ידניים / הזנות ידניות.

השינויים שיבוצעו לא ידרסו את הנתוניםשהועתקו

 

5.5.14.118

הכנסות - שימוש בקרנות למימון פרויקטים חד

פעמיים

המודל יאפשר לבצע חישוב מכפלה של כמות בתעריף

פטורים5.5.14.119

המודל יאפשר להעתיק את נתוני הביצוע של שנה קודמת ו/או שנים קודמות ו/או ממוצע שנים

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

לא ידרסו את הנתונים שהועתקו

 

המודל יאפשר להזין ידנית מקדם אשר ישפיע עלפטורים5.5.14.120 התעריף ו/או על הכמות

המודל יאפשר לבצע חישוב מכפלה של כמותפטורים5.5.14.121 בתעריף

הכנסות5.5.14.122ברוטו-נטו

המודל יאפשר להציג את ההכנסות ברוטו לפי מרכיב ההכנסה ולפי מרכז עלות במודלים

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

 

234

מודל שכר -5.5.14.123כללי

המודל יאפשר לבצע המרה של שעות ויחידות הוראה למונחים של משרות

מודל שכר -5.5.14.124כללי

המימדים במודל:

 

מרכז עלותסוג הוצאה - על פי סמלי שכר

סוג עובד - מנהלי, אקדמי, שעתי, וכו'

מעמד - סגל אקדמי בכיר, תלמידי מחקר, עוזריהוראה וכו'

דירוגים - קיימים דירוגים עם הסכמים קיבוציים כמו: מח"ר, מהנדסים, הנדסאיים, מיקרוביולוגי

וקיים דירוג של חוזים אישיים וכו'

דרגות - מבנה היררכי של דרגות מזוטר ועד בכיר

דרג - טווח של דרגות המגדיר את מקום התפקיד בהיררכיה, מגדיר את התגמולים בגין דרגה,

שעות נוספות ורכב

עלות השכר לא תתוכנן ברמת עובד

 

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

מהותית את המודל

235

מודל שכר -5.5.14.125כללי

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

לדוגמה, תרגום של שעות מנהליות לאחוז משרה משרה )בהיקף1 שעות מנהליות = 2400יהיה:

שנתי(.

 

מודל שכר -5.5.14.126כללי

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

ופיצויים ומענקי פרישה.

 

מודל שכר -5.5.14.127מנהלי ואקדמי

HRהמערכת תאפשר לבצע ממשק ממערכת ה- וממערכת הרקטור וממל"מ של כמות

משרות/שעות לפי המימדים במודל.

  הממשק כולל משרות קיימות ותכנון כמות

משרות/שעות הכולל תוספות ו/או גריעות ו/אושינויים

הממשק כולל שינויים בכמות המשרות/שעות

236

הרזולוציה של הממשק יכלול בין היתר: סוג , מרכז עלות,GLתקציב, תקופה )חודש ושנה(,

סוג הוצאה, סוג עובד ומעמד דירוגים, דרגה ואולייידרש גם דרג.

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

שעות נוספות ועוד

מודל שכר -5.5.14.128מנהלי ואקדמי

המודל יאפשר לאשר/לדחות את הממשק באמצעותWFלאחר אישור הממשק, עבור מרכזי עלות שיוגדרו .

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

תקציב ובקרה תקבל בממשק את כל הכמויות לפני האפוס ורק לאחר מכן מהלך של איפוס לפי מרכזי

עלות מסוימים שיסומנו, יתבצע האיפוס.

 

מודל שכר -5.5.14.129מנהלי ואקדמי

המודל יאפשר לבצע הזנה ידנית לכמות המשרות/יחידות הוראה/שעות ועוד הצפויות

למרכזי עלות שסומנו  

237

מודל שכר -5.5.14.130מנהלי ואקדמי

המודל יאפשר לבצע שינויים ידניים לנתוני הכמות שהתקבלו בממשק, אשר ישפיעו על התוצאה

הסופית של הכמות המשרות/שעות/יחידותהוראה וכו'

 

מודל שכר -5.5.14.131מנהלי ואקדמי

המודל יאפשר לחשב את סה"כ כמות המשרות/יחידות הוראה/שעות צפויות הכוללות

שבתון/ללא שבתון 

מודל שכר -5.5.14.132מנהלי ואקדמי

המערכת תאפשר לבצע ממשק ממערכת מל"מ של: עלות שכר בפועלSAP FIוממערכת

ממוצעת וכמות לפי סוג הוצאה )סמלי שכר( ולפיהמימדים במודל.

 

מודל שכר -5.5.14.133מנהלי ואקדמי

המודל יאפשר לחשב עלות ממוצעת ברזולוציה של: מרכז עלות, סוג הוצאה, סוג עובד, מעמד,

דירוג, דרגה ודרג 

מודל שכר -5.5.14.134מנהלי ואקדמי

המודל יאפשר לנהל את העלות בפועל שהתקבלה ו/או את העלות הממוצעת שחושבה

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

 

238

מודל שכר -5.5.14.135מנהלי ואקדמי

המודל יאפשר לבצע שינויים ידניים לנתוני התעריף הממוצע שחושב )"תעריפון"( ולנתוני

הכמות שהתקבלו בממשק. השינויים יכוליםלכלול תוספת/שינוי/גריעה

 

מודל שכר -5.5.14.136מנהלי ואקדמי

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

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

הממוצעת בדירוג או לפי הזנה ידנית

 

מודל שכר -5.5.14.137מנהלי ואקדמי

במקרים בהם הדירוג והדרגה לא ידועים, המודל יאפשר לבצע הזנה ידנית או אלוקציה לפי מפתח

שיוגדר בחתך של כל המימדים.  

מודל שכר -5.5.14.137מנהלי ואקדמי

המודל יאפשר לבצע שינויים ידניים בגין האלוקציה שבוצעה.

מודל שכר -5.5.14.138מנהלי ואקדמי

המודל יאפשר להציג ממוצע משוקלל ברמת פקולטה בחתך של כל המימדים כולל דירוג

ודרגה )ללא דרג( 

239

מודל שכר -5.5.14.139מנהלי ואקדמי

המודל יאפשר לתכנן את הוצאות השכר באמצעות הכפלה של כמות בעלות בחתך של כל

המימדים 

מודל שכר -5.5.14.140מנהלי ואקדמי

המודל יאפשר לתכנן את סה"כ הוצאות השכר ביחידות מסויימות ללא הכפלה של כמות בעלות

מודל שכר -5.5.14.141מנהלי ואקדמי

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

החישוב 

מודל שכר -5.5.14.142מנהלי ואקדמי

(Adjבכל שלב המודל יאפשר לבצע הזנות ידניות ) אשר ישפיעו על תוצאות החישוב הסופי, ללא

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

ממשק שהתקבל במערכת.

 

5.5.14.143

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

בשלב האיפיון המפורט, יתכן ויוחלט שהוצאות שכר בגין שבתון, יהיה חלק ממודל שכר - מנהלי

ואקדמי 

240

5.5.14.144

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

המערכת תאפשר לבצע ממשק ממערכת השבתון השבתון או ממערכת מל"מ ו/או מהסאפ,

עבור: כמות עובדים קיימת בשבתון, עלות ממוצעת לעובד ברזולוציה של סוג ההוצאה )סמלי

שכר( מרכז עלות, סוג עובד, מעמד, דירוג ודרגה

 

5.5.14.145

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

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

דירוג, דרגה ותקופה

 

5.5.14.146

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

המודל יאפשר לבצע בקרת השוואה בין הכמות שהתקבלה ממערכת המל"מ ו/או מהסאפ במודל

שכר - מנהלי ואקדמי לעובדים שסומנו "שבתון"לכמות שהתקבלה ממערכת השבתון

 

241

5.5.14.147

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

המודל יאפשר לבצע חישוב של הפרשים בין חלק מהנתונים שהוזנו ו/או התקבלו בממשק, לדוגמההתקן לבין המתוקצב האיוש בין הפער חישוב

הגבוה

 

5.5.14.148

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

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

הוצאה )סמלי שכר( ברזולוציה של: מרכז עלות,סוג עובד, מעמד, דירוג ודרגה

 

5.5.14.149

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

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

החישוב 

5.5.14.150

מודל שכר - הוצאות שכר

שלא דרךהמל"מ - שבתון

(Adjבכל שלב המודל יאפשר לבצע הזנות ידניות ) אשר ישפיעו על תוצאות החישוב הסופי, ,ללא

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

ממשק שהתקבל במערכת.

 

242

מודל שכר -5.5.14.151משאבים רכים

המערכת תאפשר לבצע ממשק ממערכת מל"מ של: עלות שכר בפועל , עלותSAP FIוממערכת

שכר בפועל ממוצעת , תקן גבוה ואיוש מתוקצבבמסגרת שכר(. )סמלי הוצאה סוג לפי וכמות הממשק המערכת תאפשר לקבל בממשק את סך

הכמויות וסך העלויות בגין כל סוג הוצאה 

המערכת תאפשר לבצע חישוב לעלות שכרבפועל ממוצעת.

הממוצע והכמות יחושבו ברזלוציה של: מרכזעלות, סוג עובד, מעמד, דירוג, דרגה ודרג

מודל שכר -5.5.14.152משאבים רכים

המודל יאפשר להזין פרמטרים שונים )כמות/עלות/תוצאה( אשר יוזנו בכל שלב במודל

אשר ישפיעו על תוצאות החישוב 

מודל שכר -5.5.14.153משאבים רכים

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

למסכי הזנה

 

243

מודל שכר -5.5.14.154משאבים רכים

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

גבוה מהאיוש המתוקצב.

 

מודל שכר -5.5.14.155משאבים רכים

המודל יאפשר לתכנן את הוצאות השכר באמצעות הכפלה של כמות בעלות בחתך של כל

המימדים 

מודל שכר -5.5.14.156משאבים רכים

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

להיות בגין חישוב שבוצע במערכת או ממשקשהתקבל במערכת

 

מודל שכר - קרן5.5.14.157קשרי מדע

בשלב האיפיון המפורט, יתכן ויוחלט שהוצאות שכר בגין קרן קשרי מדע, יהיה חלק ממודל שכר -

מנהלי ואקדמי 

244

מודל שכר - קרן5.5.14.158קשרי מדע

HRהמערכת תאפשר לבצע ממשק ממערכת HRו/או ממערכת המל"מ ו/או מהסאפ של כמות

העובדים הזכאים, ברזולוציה של: מרכז עלות,דירוג, דרגה,

 

סוג עובד ומעמד

מודל שכר - קרן5.5.14.159קשרי מדע

המערכת תאפשר לבצע ממשק של התעריף של ו/אוHRקרן קשרי מדע, ממערכת מל"מ ו/או

סאפ, ברזולוציה של: תקופה )חודש ואו שנה ו/או , מרכז עלות, סוג הוצאה )סמליGLרבעון וכו(,

שכר(, מעמד דירוג ודרגה

 

מודל שכר - קרן5.5.14.160קשרי מדע

המודל יאפשר לבצע שינויים ידניים לתעריף, אשר בתוספת התעריף שהתקבל יהוו את התעריף

המחושב  

מודל שכר - קרן5.5.14.161קשרי מדע

המודל יאפשר להזין פרמטרים שונים )כמות/תעריף/תוצאה( אשר יוזנו בכל שלב במודל

אשר ישפיעו על תוצאות החישוב הסופי 

מודל שכר - קרן5.5.14.162קשרי מדע

המודל יאפשר לתכנן את הוצאות השכר - קרן קשרי מדע באמצעות הכפלה של כמות בתעריף

בחתך של כל המימדים 

245

מודל שכר - קרן5.5.14.163קשרי מדע

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

להיות בגין חישוב שבוצע במערכת או ממשקשהתקבל במערכת.

 

5.5.14.164 מודל שכר -

תשלום פנסיהתקציב

המודל יאפשר קיום של מסכי הזנה הכוללים כמות ותעריף

5.5.14.165 מודל שכר -

תשלום פנסיהתקציב

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

בתעריף בחתך של כל המימדים 

5.5.14.166 מודל שכר -

תשלום פנסיהתקציב

המודל יאפשר להזין ידנית את הנתונים של תשלום הפנסיה התקציבית כסכום כולל

מלגות5.5.14.167

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

קודמת ו/או שנים קודמות ו/או ממוצע שניםקודמות לפי רזולוציה שתאופיין .

 

246

מלגות5.5.14.168

המודל יאפשר לבצע שינויים ידניים או הזנות ידניות בנתונים שהתקבלו בממשק או בנתונים שהועתקו משנה קודמת. השינויים שיבוצעו לא

ידרסו את נתוני המקור.

 

המודל יאפשר לבצע חישוב מכפלה של כמותמלגות5.5.14.169 בתעריף

5.5.14.170 מודלים

הכנסות/הוצאותאחרות

המודל יתוכנן בהתבסס על: 

הזנת פרמטרים שונים, תחשיבים בתוך המודל

5.5.14.171 מודלים

הכנסות/הוצאותאחרות

במודל יהיו מימדים ספציפיים לסוגי הכנסות/הוצאות שונות וזאת כדי לאפשר תחזוקה

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

.GLמתוחזקים ב-

 

5.5.14.172 מודלים

הכנסות/הוצאותאחרות

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

של מימדים/אלמנטים לפי המודלים השונים.  

5.5.14.173 מודלים

הכנסות/הוצאותאחרות

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

247

5.5.14.174 מודלים

הכנסות/הוצאותאחרות

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

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

 

5.5.14.175 מודלים

הכנסות/הוצאותאחרות

בחלק מההכנסות/הוצאות גובה ההכנסה/ההוצאה תקבע באמצעות הכפלה של

כמות בתעריף 

5.5.14.176 מודלים

הכנסות/הוצאותאחרות

המודל יאפשר להזין ידנית את הנתונים של ההכנסה/הוצאה כסכום כולל

5.5.14.177 מודלים

הכנסות/הוצאותאחרות

במודל תתוחזק טבלת המיפוי המקשר בין סעיףGLלסוג המודל ברזולוציה המפורטת יותר

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

מימד נוסף לדוגמה, בניינים/סוגי שמירה

 

5.5.14.178 מודלים

הכנסות/הוצאותאחרות

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

כפי שיוגדר על ידי יחידת תקציב ובקרה. 

5.5.14.179 מודלים

הכנסות/הוצאותאחרות

המודל יאפשר לשנות ידנית את הנתונים שהוקצו למרכז עלות מבלי לדרוס אותם

248

מחקרים5.5.14.180

המערכת תאפשר לבצע ממשק של הוצאות SAP GMהמחקר תכנון ובפועל ממערכת ה-

למערכת התכנון ברזולוציה שלתקופה )חודש , מרכז עלות וסעיף הוצאה, והכל כפיGLושנה(,

שיאופיין על ידי יחידת תקציב ובקרה.

 

מחקרים5.5.14.181 עבור הוצאות המחקר, הפרויקט יהיה חלק

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

 

מחקרים5.5.14.182 המודל יאפשר לבצע אלוקציה במימד מרכז עלות

)בין פרויקטים( בהתאם לטבלת מיפוי המשייכתעובד מחקר לפרויקט

 

דוחות ותוצרים5.5.14.183

על המערכת לאפשר הפקת דו"חות השוואה לכמויות ולסכומים )כמויות וסכומים יופיעו בדוח אחד( בין גרסאות נתונים שונות כמו "בפועל מול

תקציב", "תקציב מול תחזית", בדוחות אלו על המערכת לחשב ולהציג את ההפרשים בין

הגרסאות וכו'.

 

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

249

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

ובקרה.

דוחות ותוצרים5.5.14.185

על המערכת לכלול דוח על הפעילות מרכז ודוח על הפעילות למרכז עלות בכל הגרסאות אשר

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

 

 על המערכת לאפשר דוחות השוואה בין תקופותדוחות ותוצרים5.5.14.186

דוחות ותוצרים5.5.14.187 (KPI'sעל המערכת לאפשר בניית דוחות מדדים )

אשר יכללו חישובים שונים ויושפעו בזמן אמתמכל שינוי בכל מודל במערכת.

 

250

נספח תכנון תקציב- ישויות ורזולוציית התכנון.5.5.15

5.5.14.5.5.15.

ממד שלבי התכנון.5.5.15.1

בממד ייצג עבודה בדלתאות ו/או ב "סכום אפס", מצורף תרשים לדוגמה:.5.5.15.1.1

251

ממד מרכז עלות.5.5.15.2

הממד יורכב מהיררכיות ויהיה בו קשר לסוג התקציב. .5.5.15.2.1סוגי התקציב: רגיל, מותנה, סגור ופיתוח. ואם מחקר ברמת סה"כ.5.5.15.2.2מצורף תרשים לדוגמה:.5.5.15.2.3

ממד תחום.5.5.15.3

קיים קשר בין ממד תחום לממד מרכז עלות. ראה דוגמה מצורפת.5.5.15.3.1

252

253

GLממד החשבון - .5.5.15.4

:SAP FIלהלן דוגמה לסעיפים המרכיבים את ממד החשבון כמו ב.5.5.15.4.1הדפסות.5.5.15.4.1.1צילומים .5.5.15.4.1.2הכנסות מתרומות מהארץ.5.5.15.4.1.3

סוגי הכנסות והוצאות אחרות .5.5.15.5

להלן דוגמה לסעיפי ההכנסות וההוצאות האחרות:.5.5.15.5.1הכנסות מהשכרות.5.5.15.5.1.1הוצאות עבור ייעוץ משפטי.5.5.15.5.1.2

יתר הממדים.5.5.15.6

ראה פירוט בתהליכים.5.5.15.6.1

254

FMבקרה תקציבית – מודול .5.6

סוגי תקציב.5.6.1

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

– תקצוב היחידה הארגונית ברמת כרטיסי הוצאה ובקרה תקציבית אל מול התקציבתקציב שוטף/רגיל.5.6.1.1.1 ללא קשר להכנסות:

מחלקת תקציבים מתקצבת ברמת פקולטה..5.6.1.1.1.1הפקולטות השונות )ברובן( מחלקות את התקציב לחוגים וסעיפי הוצאה..5.6.1.1.1.2

– זהה לתקציב רגיל, אולם מותנה בצפי הכנסות בעת התכנון בתחילת השנה.תקציב מותנה )בהכנסות(.5.6.1.1.2יחידת התקציבים מתקצבת את מרכז העלות ע"פ צפי ההכנסות במרכז העלות/רווח.

– דומה לתקציב מותנה, הוצאות נרשמות עד גובה הצפי להכנסות בשוטף )לדוגמא, כל עודתקציב סגור.5.6.1.1.3לא התקבלה תרומה לא ניתן לרשום הוצאה(.

.CO/FM ולא ינוהל ב GM - מנוהל במודול תקציב רשות מחקר.5.6.1.1.4

בקרה תקציבית כפולה.5.6.2

ברמה מפורטת.SAPהתקציב יופץ מרמת הפקולטה לרמת החוג/תכנית במערכת התכנון וייטען ל .5.6.2.1

הבקרה תקציבית הכפולה נדרשת לתת מענה גם לדרישות הבקרה התקציבית של אגף תקציבים )בקרה תקציבית ברמת פקולטה( וגם מענה.5.6.2.2לדוגמא: חוג/תכנית(, ברמת תקציבית )בקרה הפקולטות של התקציבית הבקרה לדרישות

₪, זאת על אף שברמת הפקולטה80 של שירותי ייעוץ תיחסם מכיוון שסך התקציב לחוג אחד הוא 1 ₪ עבור הזמנה בחוג 20הזמנה של הכלכלית(. המחלקה ע"י שנקבע )כפי הייעוץ תקציב סך ברמת חריגה אין

המערכת תבצע בקרה תקציבית לפי המחמיר בין רמת חוג לרמת הסעיף.

255

רמת הבקרה התקציבית.5.6.3

הבקרה התקציבית תיעשה בהתאם לתקציב אשר הועבר ממערכת תכנון תקציב..5.6.3.1

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

המערכת צריכה לתמוך בבקרה תקציבית ברמות הבאות:.5.6.3.3

ספציפי.GLברמת מרכז עלות + .5.6.3.3.1 ספציפי. GLקיבוץ מרכזי עלות שונים עבור .5.6.3.3.2 + מרכז עלות ספציפי.GLקבוצת .5.6.3.3.3 + מספר מרכזי עלות.GLמספר סעיפי .5.6.3.3.4תקצוב ברמת קבוצת חומר.5.6.3.3.5

256

מעבר בין שנים.5.6.4

במעבר בין שנים -במידה וישנה יתרת התחייבות פתוחה משנה קודמת:.5.6.4.1

ה .5.6.4.1.1 יתרת -תהיה העברה של עוקבת ה Commitmentשנה בגובה ועדכון התקציב Commitmentלשנה העוקבת.

: הורדה מתקציב היחידה והעברה לתקציבCommitmentשנה נוכחית – מיון התקציב באותו סכום של ה .5.6.4.1.2כללי )משחק סכום אפס( זאת ע"מ שהיחידות לא יראו את יתרת התקציב.

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

אוטומטי

בקרה תקציבית - מע"מ.5.6.5

ספקים בארץ.5.6.5.1

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

התקציבי בגובה המע"מ שקוזז.ספקים בחו"ל .5.6.5.2

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

FI-CA עם FMהערה הנוגעת לשילוב .5.6.6

, שהתגלו עקב הפעלת ה-FM-FI/CA. בכדי לעקוף בעיות בקשר GM בקסטומיזציה לצורכי הגדרות FM הופעל S4HANAבתהליך השדרוג ל- .5.6.6.1FM נכתב ,note ע"י SAP   -ויושם יישום מלא של הFM כולל הסבת נתונים, יבוצע במסגרת הפרויקט, תוך התייחסות לקשר עם ,FI/CA

257

פירוט דרישות עסקיות בנושא בקרה תקציבית.5.6.7

( 2.5% משקל הדרישות העסקיות בנושא בקרה תקציבית בשלב בדיקת התאמת המענה:

" ויש להכליל אותן בתמחור הכולל )נדרש. הינן בקטגוריית "5.6.7.15 ועד 5.6.7.1כל הדרישות העסקיות

Fix Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו(

ניהול גרסאות5.6.7.1תקציב

תאפשר ניהול גרסאות/ורסיותSAPמערכת שנות של תקציב )כגון: "תקציב מקורי" - תקציב

רגיל, גרסה שניה - תקציב מעודכן וכו(  

ניהול גרסאות5.6.7.2תקציב

תקציב מקורי יתוכנן במערכת התכנון ויועבר לSAP 

ניהול גרסאות5.6.7.3תקציב

במספר אופציות:SAPעדכוני תקציב יבוצעו ב העברת תקציב בסכום אפס, הגדלה או הקטנה

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

HRבניית תקציב ע"י יחידה ארגונית בוורסיה , נפרדת והעתקה של התקציב לאחר אישור

לוורסיה המעודכנת

 

258

ניהול גרסאות5.6.7.4תקציב

הבקרה התקציבית תנוהל מול הוורסיה התקציבית המעודכנת האחרונה

ניהול אומדן תקציב5.6.7.5 גרסאות אומדן3המערכת תאפשר לנהל

.3 ו- 1,2 של אומדן לסוף רבעון SAPתקציבי ב SAPהתכנון יהיה בכלי ייעודי של תכנון ויטען ל

 

ניהול תקציב קפוא5.6.7.6

המערכת תאפשר לנהל גרסאות "קפואות" של Q1 ,Q3, Q2 , Q4, Q4התקציב המעודכן לסוף

, הגרסאות הקפואות2 מעודכן Q4, 1מעודכן קפוא Commitmentיכללו תקציב קפוא ו

 

העברת תקציב5.6.7.7 המערכת תאפשר לבצע העברות תקציב )חובה

וזכות( מתקציב אחד לשני בסכום שיתאזן)משחק סכום אפס(

 

העברת תקציב5.6.7.8 המערכת תאפשר העברות של תקציב לפי

חוקים מסוימים כגון: תקציב לא יכנס לגרעון –לא ניתן להעביר תקציב ממקום שאין בו תקציב

 

העברת תקציב5.6.7.9

המערכת תאפשר תהליך העברת תקציב דושלבי:

  - בקשה להעברה תקציבית ע"י גורם אחד

- אישור הבקשה ע"י גורם אחר

259

עדכון תקציב5.6.7.10

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

אישורים שיכלול את מחלקת תקציבים )לאנדרש אישור להעברה בסכום אפס(

 

5.6.7.11

שריון בגין תשלומים ידניים

של החזרי הוצאות)מהפורטל(

כמו למשל אש"לPOסעיפים שאין להם ידני דרךcommitmentהמערכת תאפשר לייצר

) תחילת התהליך של החזרי הוצאותFMמודול בגין תשלומים ידניים מתבצעת בפורטל(

 

העברת תקציב בין5.6.7.12שנים

במעבר בין שנים -במידה וישנה יתרתהתחייבות משנה קודמת :

 

. שנה עוקבת -תהיה העברה של יתרת ה1Commitmentועדכון התקציב בגובה ה Commitment.לשנה העוקבת

. שנה נוכחית – מיון התקציב באותו סכום של2 : הורדה מתקציב היחידהCommitmentה

והעברה לתקציב כללי )משחק סכום אפס( זאתע"מ שהיחידות לא יראו את יתרת התקציב

. נדרשת תמונת ראי של צד ההכנסות – בשנה3 הנוכחית נדרש לייצר קרן הונית בגובה התקציב

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

להתבצע באופן אוטומטי

260

בקרה תקציבית5.6.7.13On Line

המערכת תאפשר בקרה תקציבית חוסמת או בצורה גמישה:ON-LINEמתריעה

  CC בודד ב GL. על סעיף 1

CC ב GL. על קבוצה של סעיפי 2

CC. על כל הסעיפים ב 3

בקרה תקציבית5.6.7.14On Line

-ONהמערכת תאפשר לבצע בקרה תקציבית LINE:בכמה רמות

  Project To DateYear To Date

Quarter To Date

העברה תקציבית5.6.7.15

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

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

מים, חשמל 

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

מדובר בסעיפי הוצאה שאינם קשיחים- בהתאםלנוהל העברה תקציבית

261

" ויש לתמחר אותן בנפרדאופציה הינן בקטגוריית "5.6.7.21 ועד 5.6.7.16כל הדרישות העסקיות

בגין כל אופציה בנפרד יש למלאFix Price( של הפרויקט. את התמחור Fix Priceמהתמחור הכולל )

בנספח זה אין למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(. 1בשורה המתאימה בנספח

.למלא מחירים

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

ניהול תקציב5.6.7.16בסוף שנה

במקרים בהם מסתיימת פעילות )לדוגמא הסתיים פרויקט( והאוניברסיטה אינה מעוניינת

לאפשר ניצול תקציבי נוסף, אך מאידך היא שיצאו -POמחוייבת אל מול ספקים בגין

המערכת תאפשר רישומי ביצוע על כרטיס פתוח )וקיים )POהוצאה רק אם יש כנגדה

Commitment ורישומים ידניים ב GLאו חשבונית פיננסית יחסמו לרישום על אף

שהבקרה התקציבית שהוגדרה היא מתריעהולא חוסמת

 

262

שערוך תקציב5.6.7.17

במסגרת יצירת הוורסיות הרבעוניות נדרש לשערך סעיפי תקציב שאינם מנוהלים בשקל

כך שהתקציב השקלי ישקף שער תקציבי מעודכן -דרישה אופציונאלית )מותנה בתכנון

תקציבי במטבעות שאינם שקל(

 

ניהול הרשאות של5.6.7.18תקציבים

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

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

אגף תקציבים לוורסיה נוספת שתהיה פתוחהלמשתמשים

 

סגירת התחייבות5.6.7.19 המערכת תאפשר סגירה אוטומטית של

התחייבות לפי חוקים כגון גובה יתרת מקורי REQ או POההתחייבות או אחוז מה

 

263

תקציבים מותנים5.6.7.20וסגורים

בתקציבים מותנים וסגורים יחידת תקציבים מאשרת הקצאה של כ"א בדרגות שונות וסוגי העסקה שונים, במועד אישור ההקצאה נדרש

לשריין תקציב )כמות וכסף( ע"מ להציג בדוחות הבקרה את השריון התקציבי אל מול

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

הביצוע

 

תקציבים מותנים5.6.7.21וסגורים

CCהמערכת תאפשר לשייך הכנסה והוצאה ל ע"מ לאפשר תקציב מותנה, כלומר ההוצאה

לא תעלה על גובה צפי ההכנסה.

  זהו נוהל עבודה פנימי של אגף תקציבים שבו

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

264

פירוט דוחות נדרשים.5.6.8

( 2.5% משקל הדוחות בנושא בקרה תקציבית בשלב בדיקת התאמת המענה: ( שלFix Price" ויש להכליל אותן בתמחור הכולל )נדרש הינם בקטגוריית "5.6.8.3 ועד 5.6.8.1כל הדוחות תמחור נפרד לדרישות עסקיות אילו.אין לספקהפרויקט.

תיאור הדוחשם הדוחסוג הדוחמס' דו"ח תיאור המציע את המענה )כולל התייחסות מפורשת במקומות בהם המענה יינתן באמצעות

(BW עם/בלי שכבת BIדוחות

5.6.8.1 דוחות תקציב

Offמול ביצוע Line

הפקת דוחות תקציבSAPמול ביצוע מ

       דוחות תקציב מול ביצוע יופקו מ SAP ברזולוציה שתתוכנן ב SAP  

              הפקת דוחות מול תקציב מקורי ו/או תקציב מעודכן

דוחות עבור תקציביםדוחות5.6.8.2מותנים /סגורים

עבור תקציבים מותנים/ סגורים – הצגת דוח של הכנסות והוצאות

לדוגמא: דוח הכנסות והוצאות לתוכניתלימודים מסוימת

 

5.6.8.3

דוחות תקציבמול ביצוע

דוחות שכר – תקציבמול ביצוע

לצורך הפקת דוחות של תקציב מול בפועל - יפותח ממשק של נתוני בפועל

באופןBIותקציב )כמויות וכסף( ל הבא:

 

בקרה תקציביתOff Line ב BI

בפועל – ממל"מ + מערכת שבתון         .1 +SAP

  תקציב – שיגיע ממערכת תכנון         .2

תקציב )יכול להיות ממערכת תכנון וHR)

  הנתונים יועברו ברמת קיבוץ שתוגדר

ע"י האוניברסיטה )רזולוציית עובד בודדנמוכה מידי(

265

PMמודול .5.7

כללי.5.7.1

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

בתוך המודולים שיפותחו על ידי המציע הזוכה הינה באחריות המציע הזוכה ויש לתמחרם.PMהאחריות לממשקים ל-.5.7.1.2

פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה.5.7.1.3

תיאור מצב קיים.5.7.2

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

)אחזקת מעונות(, אגף ממ"מ )אחזקת מחשבים( ועוד.

מופעל באוניברסיטה במספר נושאים:PMמודול ה .5.7.2.2

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

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

266

תרשים תהליך אחזקה שוטפת.5.7.2.3

267

תיאור מצב נדרש.5.7.3

תמשיך לעבוד במתכונתה הנוכחית. נדרשים מספר שינויים:PMמערכת ה .5.7.3.1

5.6.5.7.

5.7.1.5.7.2.5.7.3.5.7.4.5.7.5.

268

למרכזי העלות החדשים שיוקמו.PM - שיוך אובייקטי Master Dataשינויים ב .5.7.3.1.1PMניהול תקציב ורזולוציית רישום בפועל עבור פרוייקטי אחזקה המנוהלים ב .5.7.3.1.2

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

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

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

5.7.3.2.3.PO ב יסווגו האחזקה הזמנת שמוקמות מתוך SAPהוצאות חומר, הוצאות )למשל שונים לכרטיסים קבלנים(.

התקציב יהיה ברמת מרכז עלות ותהיה אופציה לתקצב בסעיף אחד או לפצל את התקציב בין חומר ועבודה.5.7.3.2.4)ע"פ החלטה של אגף תקציבים).

. או ברמה מקבצת של חומר + עבודהGLהבקרה התקציבית תהיה או ברמת כרטיס .5.7.3.2.5(PO שנותרה בהם יתרה תקציבית בסכום נמוך )בטרם נוצר PMסגירת אובייקטי .5.7.3.3

PM משווי התקציב המקורי, צריכה להתבצע סגירה אך ורק דרך ה10% שקלים או קטן מ-500 שסכום ההתחייבות קטן מ-PMכאשר יש אובייקט .5.7.3.4 באופן אוטומטי.COולבוא לידי ביטוי ב

269

נמחק.5.7.4

נמחק.5.7.5

PMפירוט דרישות עסקיות בנושא.5.7.6

(AA ובפרק על CO )פירוט דרישות עסקיות נוספות הנוגעות לניהול פרויקטים ונכסים מפורטות בפרק על ה

( 3% בשלב בדיקת התאמת המענה: PM משקל הדרישות העסקיות בנושא

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

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

Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.7.6.4 ועד 5.7.6.1כל הדרישות העסקיות

Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק ( של הפרויקט

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו(

הזמנת אחזקה5.7.6.1

בשלבCommitmentהמערכת תאפשר ליצור הקמת הזמנת האחזקה )ולא כפי שעובד היום – ה

commitmentנוצר לא בשלב הקמת ההזמנה אלא בשלב האישור התקציבי של מנהל היחידה

המזמינה(

 

סגירת5.7.6.2Commitment

- כאשרCommitmentהמערכת תאפשר לשערך  PMמטבע הזמנה שונה ממטבע אובייקט ה

270

שערוך5.7.6.3Commitment

המערכת תאפשר סגירה אוטומטית של הCommitmentבעת סגירה של פרויקט ב PM  

5.7.6.4 שיקוף נתונים

במערכתהפיננסית

שיקוף נתוני הוצאות אחזקה במודל הפיננסי )לא מדובר841בפרויקטי תחזוקה שוטפת

בתקציבי פיתוח(:

 

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

הדרישה היא שהנתונים יוצגו ברמה המפורטת)חומר, קבלן משנה ואחרות( ולא המרוכזת

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

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

במידה והעבודה מבוצעת פנימית- יש לבצעהפרדה ולהציג את הנתונים בכרטיסים מפורטים

271

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

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

מס' דרישהעסקית

תיאור הדרישהנושא

5.7.6.5בקרה

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

חודשים מיום פקיעת התוקף שלהם.

ניהול התוקף יהיה בתוך הזמנת האחזקה בשדה ייעודי

272

HRמשאבי אנוש- מודול .5.8

כללי.5.8.1

תתבצע באמצעות צוות המחשוב של האוניברסיטה .HRרוב פעילות היישום והפיתוח בתוך מודול .5.8.1.1

בתוך המודולים שיפותחו על ידי המציע הזוכה הינה באחריות המציע הזוכה ויש לתמחרם.HRהאחריות לממשקים ל-.5.8.1.2

פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה..5.8.1.3

תיאור מצב קיים.5.8.2

:HR של האוניברסיטה הוטמעו תתי המודולים הבאים של מודל ה- SAP ECCבמערכת ה- .5.8.2.1

מבנה ארגוני.5.8.2.1.1תיק עובד.5.8.2.1.2ניהול תהליכי קורסים /אירועים .5.8.2.1.3תהליכי הערכת עובדים.5.8.2.1.4

:SAP HRפירוט היישום הקיים במודול .5.8.3

45

5.85.8.5

273

מבנה ארגוני.5.8.3.1

המבנה ההיררכי.5.8.3.1.1 בוצע יישום של תת מודול ניהול מבנה ארגוני אשר באמצעותו מנוהל המבנה ההיררכי של.5.8.3.1.1.1

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

עבור היחידות המנהליות בהיררכיה הוגדרו יחידות ארגוניות עד רמת מחלקה ועבור היחידות.5.8.3.1.1.2האקדמיות הוגדרו יחידות עד רמת תכנית לימוד.

בחלק.5.8.3.1.1.3 כאשר עלות, מרכז הוגדר/שויך אקדמית( והן מנהלית )הן ארגונית יחידה לכל מהמקרים ישנם מרכזי עלות שונים אף ברמה פרטנית יותר )מעבר לרמת מחלקה/תכנית

לימוד( כלומר ברמת משרה. הקמה/שינוי של המבנה הארגוני.5.8.3.1.2

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

משאבי אנוש לביצוע השינויים הנדרשים.סוגרים את.5.8.3.1.2.2 אזי יחידה, אותה שינוי/צורך בסגירת מרכז עלות של בנושא של אם מדובר

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

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

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

הרשאות למבנה הארגוני.5.8.3.1.3סוגי הפעולות האפשריות.5.8.3.1.3.1 כל ישנה חלוקת הרשאות עבור בקרב משתמשי משאבי אנוש

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

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

274

שיוך עובדים למבנה הארגוני.5.8.3.1.4פירוט.5.8.3.1.4.1 )ראה עובד תיק מודול תת במסגרת במערכת מוקמים האוניברסיטה עובדי רק

בהמשך( והם אלו שישויכו ליחידות הארגוניות/משרות במבנה ההיררכי של האוניברסיטה. שיוך עובדים למשרה מתבצע על בסיס הקצאת משאבים/תקנים עבור כל משרה ועל כן ישנו.5.8.3.1.4.2

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

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

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

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

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

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

אנשי סגל שונים, סוגי הסכמי שכר ועוד( לצורך שיוכם הרלוונטי במנה הארגוני.

4.5.

5.8.5.8.5.

275

תיק עובד.5.8.3.2

נתוני העובד.5.8.3.2.1 במסגרת ניהול המידע עבור העובד בתיק העובד מנוהלים מגוון רחב של סוגי מידע שונים.5.8.3.2.1.1

ומבוצעות מגוון רחב של פעולות עבור תיק העובד.אוכלוסיית תיקי העובד.5.8.3.2.2

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

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

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

)ראה פירוט במסגרת תת מודול "פורטל"(.BPהעובד והן בתור במסגרת ניהול הנתונים עבור העובדים ישנם מקרים בהם עבור ת.ז אחת מנוהלים נתונים.5.8.3.2.2.5

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

תעריפים שונים וכו(הרשאות להקמת תיק עובד.5.8.3.2.3

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

עובד במערכת, עפ"י תפקידם.

276

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

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

המשתמש במספר הקמת המשך לצורך עוקבים תהליכים ישנם מספר לאותו משתמש עצמה, לדוגמא: עבור עובד אשר יש צורך להקיםSAPמערכות שונות וביניהם גם מערכת ה-

ה- למערכת שם משתמש גם )הקמת SAPעבורו SAP USER דרך SU01מועברים ) ( לצורך הקמת הנתונים הרלוונטיים ובסופו שלSAP BASISהנתונים שלו לאנשי התשתיות )

דבר אף מועברים חזרה נתונים אלו לאנשי משאבי אנוש לצורך הזנת שם המשתמש של אותו תקשורת-שם משתמש(.0105עובד בתיק העובד )סוג מידע

במסגרת ההרשאות הנתונות לחלק למשתמשי משאבי אנוש בכל הנוגע לנתוני תיקי העובד,.5.8.3.2.3.4 ישנה אף חלוקת הרשאות בין משתמשים אלו הן ברמת הפעולות האפשריות לביצוע עבור העובדים )כגון: יציאה לחל"ד/חל"ת, קליטת עובד, עזיבת עובד ועוד(, והן ברמת הפעולות האפשריות ברמת סוגי המידע השונים )הרשאות: יצירה, עדכון, צפייה וכו', עבור סוגי המידע

השונים של העובד: נתונים אישיים, פרטי בנק, הסכם נוכחות, השכלה, תקשורת ועוד(נתוני שכר/חיובים/זיכויים.5.8.3.2.4

במערכת .5.8.3.2.4.1 העובד בתיק המנוהלים הנתונים SAPבמסגרת HRהנתונים מנוהלים לא המספריים בכל הנוגע לשכר העובד ו/או גובה הזיכויים/חיוביים השונים הניתנים לו.

חיצונית בתוך האוניברסיטה אליה.5.8.3.2.4.2 נתונים מספריים/כספיים אלו מנוהלים במערכת שכר מועברים הנתונים הרלוונטיים מתוך תיק העובד ) למשל דרגה, שנ"ח(

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

מסוג מסוים ובעל דירוג/דרגה מסוימת אך לא יצוין גובה השכר שלו, בהעסקה שעתית מופיעתעריף שעתי בסוג מידע דירוג-דרגה.

ניהול מסמכים עבור תיק העובד.5.8.3.2.5 מסמכים רלוונטיים של העובד הקשורים לסוגי המידע השונים המנוהלים עבורו, מנוהלים.5.8.3.2.5.1

של המסמכים ניהול מודול ה- SAPבמסגרת )מודול DMSהעובד לתיק ומחוברים ) .0002באמצעות סוג המידע

277

278

ממשק למערכת השכר.5.8.3.2.6 כאמור, חישוב השכר ונתוני השכר של העובדים לא מנוהלים במסגרת תיק העובד במערכת.5.8.3.2.6.1

אלא הם מנוהלים במערכת השכר חיצונית בתוך האוניברסיטה אשר אמוניםSAP HRה- עליה אנשי מחלקת השכר של האוניברסיטה.

לצורך כך קיים ממשק אוטומטי המעביר את כלל הנתונים הרלוונטיים למערכת זו..5.8.3.2.6.2ניהול תהליכי קורסים /אירועים.5.8.3.3

קטלוג אירועים/קורסים.5.8.3.3.1ובו מגוון רחב של נתונים רלוונטיים לצורך.5.8.3.3.1.1 ניהול אירועים/קורסים הוגדר במערכת קטלוג

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

שונים ) בעיקר פלטים של משתתפים(של.5.8.3.3.1.3 והלוגיסטיות הפיננסיות למערכות זה מערך ניהול בין חיבור/ממשק קיים לא

האוניברסיטה

תהליכי הערכת עובדים.5.8.3.4

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

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

כתהליך בפני עצמו של המלצות והחלטות וועדות הקידום השונות ומשם מועתק לנתוני הדרגהSAPב והגמולים השונים של העובד בהתאם להחלטות

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

279

SAP ESS/MSSפורטל ארגוני .5.8.3.5

לצורך ניהול נתוני העובדים.SAP ESS/MSSלא קיים באוניברסיטה פורטל .5.8.3.5.1

ניהול נסיעות.5.8.3.6

לניהול תהליכי נסיעות של העובדים.SAPלא הוטמע במערכת מודול .5.8.3.6.1:מועברים הנתונים.5.8.3.6.2 וכו'( נסיעות/אש"ל )בגין עובד לקבלת/החזר הוצאות ו/או בקשת עובד נסיעת ניהול

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

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

ניהול שעון נוכחות.5.8.3.7

למערכת ניהול שעון הנוכחות של העובדים.SAP HRכיום אין חיבור בין מערכת ה- .5.8.3.7.1 כיום ניהול המידע עבור שעון הנוכחות של העובדים )יחד עם המידע על סוגי הסכמי השכר והשעות שלהם(.5.8.3.7.2

בשם חיצונית נוכחות במערכת בקבציםSDמנוהלים במייל )מועבר היא בממשק אף אשר מעבירה )סגירת השכר(( את הנתונים הרלוונטיים למחלקת - אחת לחודש יזומה המופקים מהמערכת בפעולה

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

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

280

תיאור מצב נדרש.5.8.4

ימשיך לעבוד במתכונת הנוכחית כמפורט לעיל, נדרשים מספר שינויים:HRמודול ה .5.8.4.1

.CO לרשימת מרכזי העלות שיוגדרו במודול HRהתאמת מרכזי העלות הקיימים במודול .5.8.4.1.1 המושפעים ממאפייני מרכז עלות יעברו התאמה רלוונטיתHR ב-WFתהליכי .5.8.4.1.2.IDMביצוע קסטומיזציה לממשקים קיימים כגון ממשק שכר, ממשק .5.8.4.1.3ביצוע קסטומיזציה לתכנית הקליטה ממל"מ..5.8.4.1.4 יש לבצע התאמה ברישום ההוצאות בפועל של עובדים שעתיים וזמניים )על בסיס ממשק מל"מ( . אופן.5.8.4.1.5

Detailed designביצוע ההתאמה יוגדר בשלב ה

281

נמחק.5.8.5

נמחק.5.8.6

HRפירוט דרישות עסקיות בנושא .5.8.7

( 3% בשלב בדיקת התאמת המענה: HR משקל הדרישות העסקיות בנושא תתבצע על ידי צוותי המחשוב של האוניברסיטה וחלקן בידי צוותיHRחלק מפעילות ההתאמה במודול

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

Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.8.7.2 ו- 5.8.7.1הדרישות העסקיות Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט

תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאמס' דרישה עסקית עליהם מתבסס בהצעתו(SAPלמודולי

השפעות שינויים ב5.8.7.1MASTER DATA

:master dataשינויים ב

 

*התאמת מרכזי העלות בHRלרשימת מרכזי העלות

SAPהחדשה שתוגדר ב COככל הנראה ישתנה ה

naming convention ויתווסף קוד החברה

למספר מרכז העלות.

282

עבורINFOSET*שינוי ישHRשאילתות ) ב

INFOSET100 יחיד ו דוחות כיום. יידרש עדכון ה

INFOSETוכניסה לכל הדוחות כדי לוודא תקינות

לאחר ביצוע ההתאמה(

5.8.7.2ממשק שכר יוצא

התאמה בממשק שכר- נדרש לשנות את הממשק ולהתאים למבנה הנתונים

+ SAP-CO )CCשל ה GL(היום הסעיף .

התקציבי הוא חיבור שלCC ו GLבעתיד יהיו שתי ,

)קוד אחרCCעמודות – GLמהקוד היום( ו

 

283

". המציעלא נדרש מבוצעות בידי צוותי האוניברסיטה והינן בקטגוריית "5.8.7.19 ועד 5.8.7.3הדרישות העסקיות

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

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

מס' דרישהעסקית

תיאור הדרישהנושא

5.8.7.3

שימור

המצב

הקיים

מספר תתי מודול אשר מנהלים מגוון רחב של תהליכיםSAP HRכיום, יושמו במערכת ה-

עסקיים. כלל תהליכים אלו יחד עם כל הממשקים השונים הקיימים אליהם ומתוכם בתוך

ואף למערכות אחרות צריכים ,לפחות, להמשיך ולהתקיים גם לאחר המעברSAPמערכת ה-

ואף לאחר הטמעת המודולים הפיננסים של מערכת ה-SAP HANAלשימוש בפלטפורמת

SAP.

5.8.7.4

שימור

המצב

הקיים

תהליכים עסקים הנוגעים ל: ניהול המבנה הארגוני, ניהולSAP HRכיום יושמו במערכת ה-

תיק עובד, ניהול תהליכי אירועים/קורסים, ניהול תהליכי הערכת עובדים. כלל תהליכים אלו

ואףSAP HANAצריכים ,לפחות, להמשיך ולהתקיים גם לאחר המעבר לשימוש בפלטפורמת

.SAPלאחר הטמעת המודולים הפיננסים של מערכת ה-

5.8.7.5

ממשק שכר

יוצא

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

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

SAP- FI/COלטובת ממשק השכר היוצא והן לטובת ממשק השכר הנכנס למערכת

5.8.7.6

ממשק שכר

יוצא

יש לבצע שינויים במבנה פקודת/ממשק/קובץ נתוני העובדים היוצאים בממשק השכר אל

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

SAP

284

5.8.7.7

ממשק שכר

יוצא

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

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

אל מערכת חישוב השכרSAP והשינויים שיידרשו בממשק השכר היוצא ממערכת ה- SAPה-

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

.SAPהחיצונית אל מערכת ה-

5.8.7.8

ממשק שכר

יוצא

אל מערכתSAPיש לבצע הסבות נתונים רלוונטיים לממשק השכר היוצא מתוך מערכת ה-

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

SAPב-

5.8.7.9

ממשק שכר

יוצא

,SAPהגדרת תכולות הסבות הנתונים האלו מהמערכות הפיננסיות הישנות למערכת ה-

יוגדרו בהמשך ע"י המשתמשים, בכל הנוגע ל: סוגי הנתונים שיוסבו, טווח היסטוריית הנתונים

שיוסבו, מבנה הנתונים, וכו' וזאת בהתאם לצרכי המערכת והפתרונות הטכניים שיסופקו ע"י

המציע.

5.8.7.10

ממשק שכר

יוצא

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

אל מערכת חישוב השכרSAPבאמצעותו ינוהל ויפעל ממשק השכר היוצא ממערכת ה-

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

.SAPב-

5.8.7.11

דוחות

מערכת

יש לבצע בדיקה, ובהתאם גם שינויים בכל הדוחות המכילים נתוני משאבי אנוש ובהם גם

שלMASTER DATAנתונים פיננסים אשר עתידים להשתנות בעקבות שינויים במבנה ה-

SAPהנתונים הפיננסים ו/או הוספת נתונים פיננסים חדשים במערכת ה-

5.8.7.12

התאמת

מערכת

/WF( work flowיש לבצע בדיקה, ובהתאם גם שינויים בכל: התכניות/ קסטומיזציה/ )

וכו'SAP NOTEיות/ Z/ טרנצקיות QUERY/ טבלאות/ דוחות BAPI /FUNCTIONפיתוחים/

, בכל הנוגע לשינויים אשר יידרשו בעקבות הטמעתSAPהרלוונטיות במערת משאבי אנוש ב-

SAPהמודולים הפיננסים ב-

285

5.8.7.13

מבנה

ארגוני

בהתאם למבנה הארגוני/מבנהGLעל המערכת לאפשר הקמת מערך/מבנה חשבונות

תקציבי/שיוך מרכזי עלות עבור יחידה ארגונית לצורך ריכוז נתוני התקציב ו/או השכר ברמת

יחידה ארגונית/עובד/מרכז עלות לצורך העברת הנתונים למערכות הפיננסיות )ובעתיד

( לצורך העברתם בהמשך בממשק השכר היוצאSAPלמודולים הפיננסים ב-

5.8.7.14

ממשק

שכר-

השפעות

שינויים ב

MASTER

DATA

התאמה של תכנית הקליטה של מל"מ )שוטף( והסבת נתונים במל"מ )פיתוח במל"מ(

5.8.7.15

השפעות

שינויים ב

MASTER

DATA

פורטלbapi’sהתאמה של

5.8.7.16

השפעות

שינויים ב

MASTER

DATA

המחוברים אליה מספר מערכות/פלטפורמות שונות.IDMכיום, ישנה מערכת לניהול זהויות-

מנהלת את מערך ההרשאות ואף נותנת את ההרשאות למשתמשים השוניםIDMמערכת ה-

עבור המערכות המנוהלות דרכה תוך ביצוע ממשקים דו-כיווניים אל מערכות אלו. על

המערכת לאפשר, לפחות, המשך תקין ורציף של מערך זה גם לאחר הטמעת פלטפורמת

SAP HANA -ואף לאחר הטמעת המודולים הפיננסים של מערכת ה SAPיש לבצע התאמה :

את תכנית הקליטה ולבדוקLDAP ( יכול להיות שיש לשנות ב- LDAP )ל- IDMבממשק

DBהסבת נתונים ושינוי מבנה ה-

286

5.8.7.17

שיוך עובד

לסעיף

משני

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

קשור לשכר )הגדרת סעיפים הקשורים לשכר בהתאם להגדרות האוניברסיטה(

5.8.7.18

שיוך עובד

לסעיף

משני

,HR . נדרש שינוי ב-Zכיום קיים קשר בין סוג מינוי לסעיף משני, אחד לרבים המנוהל בטבלה

. כמו כן נדרש לבצע הסבות נתונים מתאימותSAP STANDARDהשאיפה לעבוד באמצעות

5.8.7.19

ניהול

HRהמערכת תאפשר לבנות את ההרשאות לפי המבנה הארגוני ב הרשאות

287

בנפרד" ויש לתמחר אותן אופציההינן בקטגוריית " 5.8.7.22 ועד 5.8.7.20כל הדרישות העסקיות בגין כל אופציה בנפרד יש למלאFix Priceאת התמחור ( של הפרויקט. Fix Priceתמחור הכולל )מה

בנספח זה למסמך ב' במסמכי המכרז )"טופס הצעת המחיר"(. 1בשורה המתאימה בנספח .אין למלא מחירים

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

ניהול מידע נלווה5.8.7.20

המערכת תאפשר לתמוך גם בשיוך בעלתפקיד נוסף )כגון מאשר מקצועי(

 

נדרש לבצע הסבות נתונים עבור נתון זה

האוניברסיטה נמצאת בימים אלו בתהליךשעון נוכחות5.8.7.21 להטמעת מערכת ניהול שעון נוכחות של

, אשר עתידה לנהלTime Techחברת לביא בתוכה את המידע בגין: שעון הנוכחות של העובדים, מערך הסכמי השעות וההעסקה

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

SAPאוטומטיים דו-כיווניים הן למערכת ה- HRוהן למערכות הפיננסיות לטובת העברת

הנתונים הרלוונטיים של העובדים לצורך העברתם בסופו של דבר לממשק השכר

החיצוני. על כן לאחר המעבר לשימוש ואף לאחרSAP HANAבפלטפורמת

, עלSAPהטמעת המודולים הפיננסים ב- המערכת לתמוך בהמשך עובדה תקינה

ובביצוע ממשקים אוטומטיים דו כיווניים בין SAPמערכת הנוכחות ל: מערכת ה-

 

288

ולמערכות הפיננסיות ולמערכת השכר.

289

CCשיוך עובדים ל 5.8.7.22פעילים

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

חסום או לא פעיל המערכת תמנע את השיוך )המערכת תחסום שיוך שלHRבמודול ה

מרכז עלות חסום ליחידה ארגונית פעילה(

 

290

ניהול מעונות- מודול מעונות.5.9

כללי.5.9.1

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

האחריות לממשקים בתוך המודולים שיפותחו על ידי המציע הזוכה הינה באחריות המציע הזוכה ויש לתמחרם..5.9.1.2

פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה.5.9.1.3

רקע.5.9.2

קיימים שלוש אוכלוסיות שמנוהלות במודול המעונות:.5.9.2.1

סטודנטים שגרים במעונות..5.9.2.1.1תלמידי חו"ל..5.9.2.1.2חוקרים מחו"ל שמתגוררים במעונות/אורחים המגיעים ללינה קצרת טווח..5.9.2.1.3

291

תיאור מצב קיים.5.9.3

שעבורםSTUDY ABROADמודול מעונות אחראי על הפקת שוברי תשלום וגבייה עבור כל מי שמשתמש בשירותי המעונות מלבד תלמידי חו"ל .5.9.3.1התהליך מתנהל בתוך בית הספר הבינלאומי )ראה מידע נוסף בפרק על בית הספר הבינלאומי(.

אין העברת נתונים בין מודול מעונות לכספים/הנהח"ש. את העברת המידע, כגון יתרת חוב לסטודנט, המשתמשים מסיקים על בסיס הנתונים.5.9.3.2שהתקבלו בפועל )מתוך דף הבנק(.

רישום ע"ב מזומן..5.9.3.3

אין הפרדה ברישום של הוצאות נלוות בגין מעונות )חשמל, מים, אינטרנט(. הרישום נעשה לסעיף הוצאות שכ"ד..5.9.3.4

במהלך השנה - נרשמות פקודות שוטפות בגין הוראות הקבע:.5.9.3.5

חובה בנק .5.9.3.5.1זכות הכנסות שכ"ד.5.9.3.5.2

פיקדון שנתי ומקדמה:.5.9.3.6

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

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

היות וסכום זה בהגדרה אינו עובר בין שנים.תיאור הרישום:.5.9.3.6.3

במועד רישום הסטודנט נרשמת הפקודה הבאה )בגובה הסכום המצרפי של הפיקדון והמקדמה(:.5.9.3.6.3.1ח: בנק.5.9.3.6.3.1.1ז: הכנסות מראש .5.9.3.6.3.1.2

בתחילת השנה האקדמית נרשמת הפקודה הבאה:.5.9.3.6.3.2הכנסות מראשח: .5.9.3.6.3.2.1ז: הכנסות שכ"ד.5.9.3.6.3.2.2

292

תיאור מצב נדרש.5.9.4

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

במועד הרישום למעונות:.5.9.4.2

ח: הכנסות לקבל שכ"ד.5.9.4.2.1ח: הכנסות לקבל שכ"ד-נלוות.5.9.4.2.2ז: הכנסות שכ"ד.5.9.4.2.3ז: הכנסות שכ"ד- נלוות .5.9.4.2.4

במועד התקבול:.5.9.4.3

ח: בנק .5.9.4.3.1ז: הכנסות לקבל שכ"ד.5.9.4.3.2ז: הכנסות לקבל נלוות.5.9.4.3.3

הפקודות הנרשמות בגין פיקדון שנתי ומקדמה- ללא שינוי מהמצב הקיים..5.9.4.4

Study Abroadמעונות בהקשר לימודי .5.9.5

4.5.

5.9.5.9.7.

293

תיאור מצב קיים.5.9.5.1

עבור תלמידי אקדמיה: הגבייה והתשלום בגין מעונות מתבצעת מול יחידת המעונות עצמה..5.9.5.1.1:Study Abroadעבור תלמידי חו"ל .5.9.5.1.2

הגבייה בגין המעונות מתבצעת בפועל אצל הבית ספר הבינלאומי ולא ישירות מול המעונות כמו.5.9.5.1.2.1באקדמי בינלאומי וישראל.

על מנת שדרישת התשלום מהסטודנט תכלולCMהמידע בגין תשלום עבור המעונות מנוהל ב .5.9.5.1.2.2גם את רכיב המעונות וגם את רכיב שכר לימוד באותו שובר. במועד הרישום למעונות:

ח: מזומן .5.9.5.1.2.2.1ז: הכנסות )אין פיצול בין שכר לימוד לשכ"ד(.5.9.5.1.2.2.2

תיאור מצב נדרש.5.9.5.2

על מנת שדרישת התשלום מהסטודנט תכלול גם את רכיבCMהמידע בגין תשלום עבור המעונות ינוהל ב .5.9.5.2.1המעונות וגם את רכיב שכר לימוד באותו שובר.

במועד הרישום למעונות:.5.9.5.2.2ח: הכנסות לקבל )אין פיצול בין הכנסות לקבל משכר לימוד ומשכ"ד(.5.9.5.2.2.1ז: הכנסות משכ"ד )בגין החלק של המעונות( –ע"ס אובייקט חוזה שכ"ד..5.9.5.2.2.2ז: הכנסות משכר לימוד ) בגין החלק של השכר לימוד( - ע"ס אובייקט חוזה שכר לימוד..5.9.5.2.2.3

במועד התקבול:.5.9.5.2.3 ישויך התקבול לסטודנט.FI CAב .5.9.5.2.3.1 מאחר ומדובר באובייקט חוזה נפרד, יועבר ממשק למודול המעונות ע"מ לשקף את העובדה.5.9.5.2.3.2

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

ח: מזומן.5.9.5.2.3.3.1ז: הכנסות לקבל )ללא הפרדה בין שכר לימוד לשכ"ד(.5.9.5.2.3.3.2

294

נמחק.5.9.6

נמחק.5.9.7

פירוט דרישות עסקיות בנושא מעונות.5.9.8

( 2% משקל הדרישות העסקיות בנושא מעונות בשלב בדיקת התאמת המענה: חלק מפעילות ההתאמה במערכת המעונות תתבצע על ידי צוותי המחשוב של האוניברסיטה וחלקן בידי

צוותי המציע. כמפורט במסמכי המכרז, כל הדרישות העסקיות ינוהלו כחלק אינטגרלי בידי מנהלהפרויקט מטעם המציע. Fix" ויש להכליל אותן בתמחור הכולל )נדרש הינן בקטגוריית "5.9.8.2 ו- 5.9.8.1כל הדרישות העסקיות

Price .תמחור נפרד לדרישות עסקיות אילו.אין לספק ( של הפרויקט

תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאמס' דרישה עסקית עליהם מתבסס בהצעתו(SAPלמודולי

5.9.8.1

רישום ע"ב מצטבר

fiיש לייצר ממשק בין ה למודול מעונות בעקבות

המעבר לרישום ע"במצטבר:

 

במועד הרישום למעונות)נדרש(יירשם:

ח- הכנסות לקבל שכ"ד 

ח- הכנסות לקבל שכ"ד נלוות

ז- הכנסות שכ"ד ז- הכנסות שכ"ד נלוות המועד התקבול יירשם: ח- בנק ז- הכנסות לקבל שכ"ד 

295

ז- הכנסות לקבל שכ"ד נלוות

5.9.8.2

רישום ע"ב מצטבר

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

במועד קבלת השיק הדחוי/ גיהוץ בתשלומים בכרטיס

אשראי ירשמו הפקודותהבאות:

 

זכות: הכנסות לקבל)נדרש(

חובה: שטל"ק/ כרטיסי אשראי לקבל בהתאמה

 

במועד הפירעון של הצ'ק/ במועד החיוב של כרטיס האשראי ירשמו הפקודות

הבאותחובה: בנק 

זכות: שטל"ק/כרטיסי אשראי לקבל בהתאמה

296

". המציעלא נדרש מבוצעות בידי צוותי האוניברסיטה והינה בקטגוריית "5.9.8.4 ו- 5.9.8.3הדרישות העסקיות

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

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

מס' דרישהעסקית

תיאור הדרישהנושא

5.9.8.3

מדידה

ניהולית

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

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

DDבשלב ה

5.9.8.4

מדידה

ניהולית המערכת תאפשר לסווג סוגי ההוצאה כגון הוצאות לחוקרים על שימוש במעונות ) יש

חשיבות לצבוע את ההוצאה לפי פקולטה לצרכי ניתוח (

297

BIבינה עסקית – .5.10

תיאור מצב קיים.5.10.1

. המערכתSAP Business Objects ושכבת הנתונים האנליטית SAP-BW באוניברסיטת חיפה מבוססים על שכבת מחסן הנתונים BIיישומי ה .5.10.1.1משמשת לצורך דוחות ניהוליים וניתוחים אנליטיים של מידע משולב ממגוון מודולים.

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

קוביות המידע העיקריות הן:.5.10.1.3

5.10.1.3.1.Grant Managementניהול מענקים – תקציב מול ביצוע.5.10.1.3.1.1מחזור חיי מענק.5.10.1.3.1.2אחראים במענק.5.10.1.3.1.3ועוד.....5.10.1.3.1.4

5.10.1.3.2.HRמשאבי אנוש – מצבת כוח אדם.5.10.1.3.2.1מינויים.5.10.1.3.2.2מבנה ארגוני.5.10.1.3.2.3ועוד....5.10.1.3.2.4

5.10.1.3.3.CRMניהול קשרי לקוחות – לידים.5.10.1.3.3.1הזדמנויות.5.10.1.3.3.2פעילויות.5.10.1.3.3.3ועוד.....5.10.1.3.3.4

5.10.1.3.4.SLCM)ניהול חיי סטודנט בקמפוס )הפרויקט נמצא בראשיתו – מועמדויות.5.10.1.3.4.1הרשמה.5.10.1.3.4.2

298

רישום לקורסים.5.10.1.3.4.3הישגים וציונים.5.10.1.3.4.4ציוני קורסים, לרבות ציוני רכיבי הקורסים.5.10.1.3.4.5ועוד.....5.10.1.3.4.6

 

BI . הכלים הללו ישולבו במערכת הSAP S/4 Embedded Analytics יתבססו על BIמימוש פתרונות ה במסגרת יישום הפרויקט הפיננסי .5.10.1.4 ללא שימוש בשכבתSAP האינטגרליות של BIבכוונת האוניברסיטה לממש חלק גדול מהדוחות על סמך יכולות ההקיימת היום.

BW.

BIפירוט דרישות עסקיות בנושא .5.10.2

( 5% בשלב בדיקת התאמת המענה: BI משקל הדרישות העסקיות בנושא " ויש להכליל אותן בתמחורנדרש הינן בקטגוריית "5.10.2.4 ועד 5.10.2.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceהכולל )

תיאור הדרישהנושאמס' דרישה עסקית תיאור המציע את המענה )כולל התייחסות

עליהם מתבסס בהצעתו וכןSAPלמודולי או לא(BWהאם ייושם באמצעות שכבת

דוחות 5.10.2.1

הגוף המיישם נדרש לייצר , יתר הדוחותBI דוחות 30

יבנו ע"י האוניברסיטה- צריך לחלק את הדוחות

לפי עולמות התוכן

 

דוחות 5.10.2.2 עלBIלפתח קוביות

עולמות תוכן חדשים:FI,CO,FM,AA,MM, SD

 

299

דוחות 5.10.2.3

יש לאפיין את כל הדוחות הנוכחיים במערכת מבת-

כדי שניתן יהיה לבנות SAP על בסיס הBIאותם ב

ולא על בסיס פרופיט ) הפרדה בין דוחות ניהוליים לבין דוחות

שוטפים(

 

ממשקים5.10.2.4

המערכת צריכה לאפשר הצגת מידע שמגיע

ממקורות חוץ סאפיים- כ מהמידע יגיע מתוך ה80%SAPויתר הדוחות

ממקורות חיצוניים: מל"מ,TM1אקסלים ,

 

300

GMרשות מחקר- מודול .5.11

כללי.5.11.1

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

האחריות לממשקים בתוך המודולים שיפותחו על ידי המציע הזוכה הינה באחריות המציע הזוכה ויש לתמחרם..5.11.1.2

פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה.5.11.1.3

תיאור מצב קיים.5.11.2

(.GM )מחקרים של פקולטות אינם מנוהלים ב GMמחקרים של חוקרים, פנימיים וחיצוניים, מנוהלים ב .5.11.2.1

מחקרים חיצוניים.5.11.2.2

קיים גורם מממן חיצוני..5.11.2.2.1קיים דיווח לות"ת..5.11.2.2.2מנוהל במספר שלבים: הצעה, זכיה וכו'.5.11.2.2.3

מחקרים פנימיים.5.11.2.3

מימון פנימי ע"י האוניברסיטה..5.11.2.3.1מנוהל בשלב אחד בכלל: שלב הזכייה..5.11.2.3.2

קישור מענק למרכז עלות.5.11.2.4

כל מענק מקושר למרכז עלות )קשר אחד לאחד(..5.11.2.4.1 של המרכז עלות קיים שיוך למספר מענק.Master Dataב .5.11.2.4.2לא ניתן לשייך אותו מרכז עלות לכמה מענקים..5.11.2.4.3

ניתן להזין מטבע למענק..5.11.2.5

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

ניתן להגדיר קשר היררכי בין מרכזי עלות ובין מענקים..5.11.2.7

301

תקציב.5.11.2.8

– מנוהל תקציב רב שנתי מחולק לתקופות.מחקרים חיצוניים.5.11.2.8.1- התקציב מנוהל בתקופה אחת לכלל אורך חיי המחקר. היבט של התקציב, הרישוםמחקרים פנימיים .5.11.2.8.2

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

דוחות.5.11.2.9

– יש להעמיד את ההכנסה בגובה ההוצאה.דוח על הפעילות בשנה הנוכחית.5.11.2.9.1.1 – נדרש לראות את היתרה התקציבית המצטבר.דוח לחוקרים.5.11.2.9.1.2

נמחק.5.11.3

נמחק.5.11.4

302

GMפירוט דרישות עסקיות בנושא .5.11.5

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

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

מבוצעות בידי צוותי האוניברסיטה והינה5.11.5.1 -5.11.5.3בטבלה המצורפת, הדרישות העסקיות

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

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

הנכתבות באחריות המציע.

מס' דרישהעסקית

תיאור הדרישהנושא

5.11.5.1

הקמת גורם מממן

) לא נדרש

תמחור(

יאופייןdetail design- בשלב הFI צריכה לייצר באופן אוטומטי לקוח בGMהקמת גורם מממן ב

GMתהליך הקמת הלקוח באופן מלא ) אחת הבדיקות הנדרשות תהיה בהקמת גורם מממן ב

המערכת תציג את רשימת הלקוחות הקיימים על מנת לא לייצר כפילות(

.5.11.5.2

ניהול מחקרים

פנימיים שאינם

מנוהלים היום ב

GMלא נדרש (

תמחור(

מנוהלים חלק מהמחקרים הפנימיים. עלה צורך לנהל את כל המחקרים הפנימייםGMכיום ב

. כנראה שיידרש פיתוח על מנת לאפשר ניהול תקציב ברמהGM)בעיקר של הפקולטות( בתוך ה

שנתית )לרבות גלגול תקציב בין תקופות(, דוחות ייעודיים

דוח לגורם מממן )5.11.5.3המערכת תאפשר להפיק דוח לגורמים המממנים דו"ח הוצאות בפירוט של "סטאטוס ההוצאה"

* הוצאה שנרשמה בתקופת חתך לאחר סיום המחקר, אך שייכת לתקופה שבה המחקר היה פעיל )303

לא נדרש תמחור(

. החשבונית התקבלה2017 עבור מחקר שמסתיים ב 2017לדוגמא: התקבל שירות בדצמבר

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

יצא בתקופה שבה המחקר בתוקף/פעיל, ובמידה שהחשבוניתPO( המערכת תזהה אם ה2018

מסוג זה- היא תופיע בדוחPOשוויכה ל

* הוצאה שהגיעה בגינה חשבונית

* הוצאה ששולמה לספק )ייתכן שיידרש גם אישור מהספק שהתשלום התקבל(

304

MMרכש – מודול .5.12

רקע.5.12.1

של MMבאוניברסיטה קיים מודול .5.12.1.1 SAPאשר כולל את תהליך הרכש )דרישה, בל"מ, הזמנה, קבלה( הסכמי מסגרת, ניהול ספקים, תהליך , המחסנים, תהליך שריונים פנימיים, בקרת מצאי, חשבונית לוגיסטית, ניהול הקטלוג

אלא במערכת מקבילהSAP בוצעו שינויים רבים והתאמות, היות ועד היום המערכת הפיננסית לא התקיימה ב-MMבמודול .5.12.1.2

באוניברסיטה קיים מודול רכש, אשר כולל את שלב הדרישה – הזמנה – הסכם מסגרת..5.12.1.3

במודול קיים מערך הרשאות ובקרה תקציבית..5.12.1.4

305

תיאור מצב קיים.5.12.2

306

רכש למחסן.5.12.2.1

הבקרה התקציבית מבוצעת במחסן עבור רכש למלאי מחסן ) מול ספקים חיצוניים(.5.12.2.1.1התקציב של המחסן הינו תקציב סגור בסכום אפס..5.12.2.1.2רכישה למחסן - מקטינה את התקציב..5.12.2.1.3ניפוק מהמחסן ליחידות השונות - מגדיל את התקציב..5.12.2.1.4

ניהול קטלוג פריטים ומחירים.5.12.2.2

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

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

הנומרטור של מקטי הטובין הינו מספר רץ ללא לוגיקה מסוימת..5.12.2.2.5.1 מקט"י טובין.35,000במערכת מנוהלים כ .5.12.2.2.5.2ועבורם מחיר.5.12.2.2.5.3 מחיר העלות לא מנוהל בקטלוג הפריטים מלבד פריטים שמאוגדים בהסכם

העלות קבוע וניתן לשינוי ידני.קטלוג שירותים.5.12.2.2.6

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

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

ומשלוח חומרים. הנומרטור של מקטי שירות הינו ידני לפי קבוצת שירות..5.12.2.2.6.3

דרישת רכש.5.12.2.3

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

307

ידני אם כי כל שינוי בדרישה מאושרת מחייב הסרת האישורים שניתנו.5.12.2.3.3 ניתן לשנות את המחיר באופן (.sap standardלדרישה )לא

(. ההרשאותVPכל דרישת רכש עוברת מספר אישורים )מנהלי, תקציבי ובהתאם למק"ט גם מקצועי ו/או .5.12.2.3.4.sap standardלאישורים השונים הן בהתאם למרכז עלות ונקבעים בטבלה מיוחדת שאינה

.DMSניתן לצרף לכל דרישה מסמכים ב-.5.12.2.3.5הזמנת רכש.5.12.2.4

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

(.sap standardלהזמנה )לא .DMSניתן לצרף מסמכים לכל הזמנה ב-.5.12.2.4.3אין אפשרות לבצע הזמנה ללא דרישה..5.12.2.4.4 ₪ ברכש מצטבר לספק אחד ב-250,000קיים פיתוח עבור תקנות חובת המכרזים – התראה על סכום של .5.12.2.4.5

החודשים שקדמו להזמנה האחרונה.12 קיים פיתוח עבור חוק מוסר תשלומים – תשלום החשבונית על סמך תאריך קבלת החשבונית באוניברסיטה.5.12.2.4.6

ושליחת מייל לספק עם תאריך קבלת החשבונית.

308

תיאור מצב נדרש.5.12.3

309

פירוט דרישות עסקיות בנושא רכש.5.12.4

( 15% משקל הדרישות העסקיות בנושא רכש בשלב בדיקת התאמת המענה: " ויש להכליל אותן בתמחורנדרש הינן בקטגוריית "5.12.4.39 ועד 5.12.4.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceהכולל )

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

רכש מחסן5.12.4.1

המערכת תאפשר שתי רמות של בקרהתקציבית עבור רכש של המחסן המרכזי:

  .מול יחידה פנימית – בעת הוצאת ההזמנה1הפנימית - בדיקת תקציב היחידה

.מול ספק חיצוני - בקרה תקציבית של2המחסן - בעת הוצאת דרישה והזמנת רכש

הקמת/עדכון ספק5.12.4.2 המערכת תאפשר הרשאות נפרדות להגדרת/ עדכון של נתונים לוגיסטיים ופיננסיים בשלב

הקמת הספק או עדכון פרטי הספק 

הערכת ספק5.12.4.3 המערכת תאפשר לתמוך בתהליך הערכת ספק על מנת לתחזק נתונים איכותיים של

ספק" כגון: עמידה בלוחות זמנים וכו 

310

תדפיסים במודול5.12.4.4רכש

המערכת תאפשר פורמט עריכה/הדפסה שונה לתדפיסי רכש לכל סוג של הזמנה,

קבלות, ניפוקים עבור עברית ועבור אנגלית

 

תבניות שונות11כיום יש כ-

layoutהיום כל תדפיסי הרכש משתמשים ב- - יש דרישה להפסיק שימוש בו, )מצורף נספח

הקיימיםlayoutהמפרט את רשימת סוגי ה- במערכת(

SAPיש לבחון את הכלים החדשים יותר של standard כמו PDF

ארגון מלאי5.12.4.5

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

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

נפרדים עם קטלוג פריטים אחיד

 

בקרה תקציבית5.12.4.6 הבקרה התקציבית צריכה להיות על שווי

המחיר כולל המע"מ - דרישה ייעודית למלכ"רמשום שלא מזדכה על המע"מ

 

311

קטלוג פריטים5.12.4.7 לפשט את יכולת חיפוש המק"ט באמצעותמאפיינים מסוימים או שימוש בהיררכיות .

מול איזה מאפייניםdetailed designלבחון ב  

 יש לאפשר צירוף תמונות לקטלוג הפריטיםקטלוג פריטים5.12.4.8

קטלוג פריטים5.12.4.9

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

שלא היו קיימים 

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

קטלוג שירותים5.12.4.10

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

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

בעת רכש מחו"ל משלוחים, עמיל מכס,אספקה ואחסנה

 

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

התקציבית כבר בשלב הקמת הדרישה- בדיקהשל סך הסכום ולא של המק"ט הפיסי בלבד.

312

GL)אישור שורות דרישה כמכלול בהתאם ל- של הפריט בדרישה ולא כל שורה בנפרד(.

הסכם מסגרת 5.12.4.11

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

מהסכם המסגרת.

 

5.12.4.12Reservation ) )שריון

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

לייצר התחייבות תקציבית - בהתאםלסטנדרט

 

5.12.4.13Reservation ) )שריון

הבדיקה התקציבית של השריון צריכה להיות מול התקציב שאליו משויך סעיף ההוצאה

בהתאם למק"ט שהוזמן.  

דרישת רכש5.12.4.14

המערכת תאפשר לנהל בדרישה את מטבעהרכישה

  . כאשר הדרישה מתוך הסכם מסגרת -1

מטבע הדרישה יתקבל מההסכם.

. כאשר הדרישה אינה מקושרת להסכם –2יוגדר המטבע על ידי יוזם הדרישה

313

דרישת רכש5.12.4.15 המערכת תאפשר עבור שורה בדרישה, לחייב

מספר מרכזי עלות לפי אחוזים לאותו סעיףGL .

 

דרישת רכש5.12.4.16 בשלב הקמת דרישת הרכש, החשבון לדרישה

יתקבל מהפריט והמערכת תחסום את(GLהאפשרות לשינוי החשבון )

 

דרישת רכש5.12.4.17

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

 

ימופו שדות החובה. DDבשלב ה-

דרישת רכש5.12.4.18

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

בדרישה מספר מרכזי עלות המערכת תאפשר לשלוח את הדרישה לאישור הגורמים

הקשורים למרכז העלות 

SAP)השאיפה היא להיצמד כמה שיותר ל)standard

עםWFסבב אישורים של דרישות הרכש יכלול אפשרות של "אישור", "בדיקה", "דחיה"

314

בשלב האפיון המפורט – יש להגדיר את הבקרה שהמערכת תבצע

חוסמת/התראה/אישור לפי המאשר של מרכזהעלות

דרישת רכש5.12.4.19

SAPלכל דרישה ינוהלו הסטטוסים לפי ה- standard

  המערכת תאפשר לקניין לשנות את הסטטוס בדרישת הרכש ל "השלמת מידע" כולל הזנת

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

הדרישה הכולל את הסיבה לשינוי הסטטוס.דבר זה לא יגרור סבב אישורים נוסף

דרישת רכש5.12.4.20

המחיר לפריט בדרישה צריך להתקבל באופןהבא:

 מתוך הסכם מסגרת1.מתוך קטלוג פריטים2. המערכת תאפשר לדרוס את המחיר באופן3.

ידני

דרישת רכש5.12.4.21

המערכת תאפשר לבצע עדכון דרישה שאושרה, במקרה של עדכון שמשפיע על

מחיר של שורה או על המחיר של סה"כ הדרישה, המערכת תבטל את האישור של

הדרישה, ולאחר העדכון הדרישה תעבור סבבאישורים נוסף.

 

315

SAP)השאיפה היא להיצמד כמה שיותר לstandard)

דרישת רכש5.12.4.22

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

ליוזם הדרישה לשנות את סטטוס הדרישהל"סגור" גם אם לא כל הכמות נוצלה.

 

דרישת רכש –5.12.4.23מסוג מכלול

המערכת תאפשר הקמת דרישה מסוג מכלול.

 

מכלול - כאשר קונים רכיבים שכדי שהם יעבדוהם צריכים להישאר יחד

דרישה מסוג מכלול – תוקם ידנית ולא תהיה מהסכם מסגרת. יוזם הדרישה יבחר את

הפריטים שיכללו בדרישה, ויגדיר את הדרישהכדרישת מכלול.

•המערכת לא תאפשר לאשר שורות בדרישהאלא את הדרישה כולה

•המערכת תאפשר מסלול אישורים הכוללאישור מקצועי ואישור מנהלי

)לדוגמא: האישור המקצועי נדרש עבור אגף מחשוב במקרים שבמכלול קיים פריט של

תוכנה(

316

5.12.4.24 יצירת דרישה

אוטומטית ע"סMRPריצת

המערכת תתמוך ביצירת דרישת רכש.MRPאוטומטית ע"ס ריצת

 

המחסנים3לבדוק באפיון אם זה עבור

הזמנות רכש5.12.4.25 המערכת תאפשר ליצור הזמנות רכש

במסלולים שונים אשר יפורטו בשלב האפיוןהמפורט

 

הזמנות רכש5.12.4.26

המערכת תאפשר הפקה של הזמנת רכשמתוך דרישת רכש באופנים הבאים:

 

•המערכת תאפשר להפיק הזמנה מתוך שורהאחת או יותר בדרישה

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

•המערכת תאפשר לפצל כמות של שורה בדרישה ספציפית לספקים שונים בהזמנות

שונות.

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

הזמנות רכש5.12.4.27

, ו/אוPOבכל מקרה של שינוי המחיר ב- בחשבונית מחיר המוצר בקטלוג יתעדכן

 בהתאמה

SAP standardיש לבחון

317

הזמנות רכש5.12.4.28

המערכת תאפשר להגדיר שדות חובה שונים להזמנות בארץ ובחו"ל )כולל אלמנט של

ימופו שדות החובהDDביטוח(, בשלב ה- עבור כל סוג הזמנה.

 

הזמנות רכש5.12.4.29

המערכת תאפשר לפצל את מועד האספקה מועדי אספקה. לחילופין, המערכת2לשורה ל-

, בהתאם2תאפשר לפצל את השורה ל-  למועדי האספקה.

יש להיצמד כמה שיותר לסטנדרט

הזמנות רכש5.12.4.30

ההזמנה תהיה בסטטוס "סגור" כאשר היא נוצלה במלואה. המערכת תאפשר לבטל ידנית את יתרת ההזמנה במידה ותהיה )שינוי סטטוס

ל"סגור"(.

 

הזמנות רכש5.12.4.31

המערכת תאפשר לבצע שינויים בהזמנה changeשנשלחה לספק. השינויים ינוהלו כ-

order 

יישאר זהה ויהיה מלל שמצייןPO•מספר ה- שזה שינוי של ההזמנה הקיימת. עם עדכון

גרסאות.

318

השינויים שניתן לבצע בהזמנה שנשלחה לספק יאופיינוchange orderוהשינויים שינוהלו כ-

. DDבשלב ה-

אישור הזמנות רכש5.12.4.32

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

 

SAP)השאיפה היא להיצמד כמה שיותר ל)standard

בקרת מערכת: המערכת תאפשר לנהלToleranceעל ההפרש בין סה"כ הדרישה

לסה"כ ההזמנה מבחינת מחיר, במידה המערכתToleranceוהסכום עולה מעל ה

תפעיל מסלול אישורים להזמנה.

עםWFסבב אישורים של הזמנות הרכש יכלול אפשרות של "אישור", "בדיקה", "דחיה"

בשלב האפיון המפורט – יש להגדיר את הבקרה שהמערכת תבצע

חוסמת/התראה/אישור לפי הקניין וסכום

319

חסימה של הזמנות5.12.4.33רכש

•בהתאם לדרישת חוק חובת המכרזים - בשלב , המערכת תעשה ולידציהPOהוצאת ה-

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

  • המערכת תתריע כאשר הסכום המצטבר של הזמנות הרכש יהיה מעל סכום מסוים שיוגדר

ע"י האוניברסיטה ותחסום כאשר סכום ההזמנות המצטברות הינו מעל הסכום

שהוגדר לחסימה + סכום נוסף

•קיים פיתוח במערכת - בשלב האפיון המפורטיש לבחון את האפשרות להעתקת הפיתוח

5.12.4.34

הסכמים/ האוניברסיטה רוצה לבחון את האפשרות

לניהול הסכמים שאינם הסכמי מסגרת ו/אולניהול חוזים בתוך המערכת.

  במסגרת זו המערכת תאפשר לנהלחוזיםבהסכמים/בחוזים את הנתונים הבאים:

  תאריך תוקף ההסכם/החוזה – המערכת

תתריע ביצוע בעת יצירת תשלום ו/או שינוייםבחוזה אשר פג תוקפו.

320

  שינויים בהסכם/בחוזה – כל שינוי אשר יש לו

השפעה על סה"כ מחיר לשורה או לחוזה,יעבור סבב אישורים.

  שורות בחוזה – המערכת תאפשר שכל שורה תכלול מחיר וכמות או אבני דרך – המערכת

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

5.12.4.35הסכמים/

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

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

 

חוזים

מלאי5.12.4.36

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

מלאי.

  יקבע בהתאםAccount Determinationה לסוג התנועה הלוגיסטי

)כל זאת תחת ההנחה שהאוניברסיטה תנהלרישום של מלאי (

321

ניהול מחסנים5.12.4.37

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

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

את היחידה הארגונית

 

ניהול מחסנים -5.12.4.38מחסן דואר כמותי

בעת ביצוע הזמנה של יחידה ארגונית למחסן הדואר - על המערכת לבצע שחרור תקציב

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

ותקציב היחידה אינו חיובי

 

מתן שירותים של5.12.4.39יחידות תומכות

עבור היחידות התומכות, במקרים בהם ההוצאה אינה ידועה/צפויה, התקציב וההוצאות

בפועל ירשמו ביחידה התומכת ויועמסו עליחידות הקצה לפי מפתח שיקבע מראש

  במקרים אחרים בהם ההוצאה צפויה מראש

כגון : תיקוני רכב , התקציב והביצוע ירשמו עלהיחידה המקבלת

במסגרת האפיון המפורט יוחלט אילו הוצאותיהיו בכל קטגוריה

322

Fixתמחור הכולל )בנפרד מה" ויש לתמחר אותה אופציההינה בקטגוריית " 5.12.4.40הדרישה העסקית

Price .את התמחור ( של הפרויקטFix Price למסמך ב'1 יש למלא בשורה המתאימה בנספח

.בנספח זה אין למלא מחיריםבמסמכי המכרז )"טופס הצעת המחיר"(.

מס' דרישה תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאעסקית

עליהם מתבסס בהצעתו(SAPלמודולי

5.12.4.40

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

חוזים

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

סכומים כפי שיוחלט על ידי החברה.

  המערכת תבצע בקרה שסה"כ התשלומים בהסכם כולל תשלום המקדמה אינם יותר

גבוהים מערך ההסכם.

 

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

ויהיה צורך.

323

ניהול פורטל.5.13

כללי.5.13.1

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

האחריות לממשקים בתוך המודולים שיפותחו על ידי המציע הזוכה הינה באחריות המציע הזוכה ויש לתמחרם..5.13.1.2

פעילות זו הינה חלק אינטגרלי בפרויקט ותנוהל על ידי מנהל הפרויקט מטעם המציע הזוכה.5.13.1.3

רקע: עולמות תוכן בפורטל.5.13.1.4

הרשמה וסטודנטים – הרשמה לאוניברסיטה + רישומים של סטודנטים לתוכניות לימודים.5.13.1.4.1סגל – בעיקר הזנת טפסים בגין מחקרים.5.13.1.4.25.13.1.4.3. GM( לחוקרים- דוחות מענקים לחוקר, עדכון נתוני חוקר - HR)Share Point , מנוהל ב SAPניהול ציוד – לא קשור ל-.5.13.1.4.4תשלומים ידניים של החזרי הוצאות.5.13.1.4.5מערכת העברות כספיות.5.13.1.4.6

324

תיאור מצב קיים.5.13.2

פורטל הרשמה וסטודנטים:.5.13.2.1

.SAP CM ב-BAPIבפורטל מנוהל תהליך ההרשמה של הסטודנט + תשלום דמי הרשמה שמפעיל .5.13.2.1.1 אשר יוצר תנועה כספית בBAPIתשלום שכר לימוד והרישום לקורסי אנגלית ושומעים חופשיים מפעיל .5.13.2.1.2

SAP-CM.פורטל סגל:.5.13.2.2

לוגיסטי.5.13.2.2.1 יותר ידידותי למשתמש.GUIיצירה של דרישות ושריונים דרך הפורטל בגלל שה.5.13.2.2.1.1 ( נפתחים בפורטל ע"מ לאפשר שני סבבי אישורים ,GMהשריונים של מחקרים )שאינם ב .5.13.2.2.1.2

האחד – מנהלי, השני – כספים כלומר שתי תחנות אישורים .הצגת קטלוגים – ניתן לעדכן תמונות של פריטים )לא ניתן לעדכן מחיר(..5.13.2.2.1.3

SSOטפסים ובקשות: כניסה לפורטל .5.13.2.2.2טופס מלגות ממחקר/טופס נסיעה מתקציבי מחקר.5.13.2.2.2.1

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

, אך לא רואה אם יש יתרה תקציבית בגין אותםECCששייכים למחקרים מתוך ה מרכזי עלות.

בתחנת מאשר סעיפים של רשות המחקר בלבד הפורטל מציג את היתרה ויוצר.5.13.2.2.2.1.2SAP-GM מ/אל BAPIהתחייבות באמצעות

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

.CMשהרישום בפועל בספרים עובר דרך ה טופס שעות ארעיים - דיווח שעות לעובדים ארעיים ) לדוגמא, במחקר חוקרים שמעסיקים עובדים ארעיים.5.13.2.2.3

במחקר(:לטופס שעות ארעים יש שני סבבי אישורים..5.13.2.2.3.1.1

325

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

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

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

בספרים .טופס בקשה לניצול קקמ"ב.5.13.2.2.3.2

בקשה לניצול קקמ"ב )קרן קשרי מדע- תקציבים שמקבל איש סגל(, יש כאן טופס.5.13.2.2.3.2.1של בקשה לניצול התקציב.

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

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

) ע"י תכנית בפרופיט(AS400במערכת הבקשה של החוקר יוצרת התחייבות: ההתחייבות נוצרת דרך בפועל באמצעות.5.13.2.2.3.2.4

עבור כול הבקשות שאושרו מהפורטל. SAPממשק מתוך ה .AS400מערכת קקמ"ב יושבת על .5.13.2.2.3.2.5 במידה והחוקר מעוניין לקבל מזומן - עובר ממשק לבנק הפועלים שהחוקר יכול.5.13.2.2.3.2.6

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

:GMפורטל .5.13.2.3

הצגת דוחות מחקרים – תקציב מול בפועל..5.13.2.3.1קול קורא..5.13.2.3.2

תשלומים ידניים של החזרי הוצאות:.5.13.2.4

בקשה לנסיעה מוקמת דרך הפורטל..5.13.2.4.1הבקשה בפורטל היא מפורטת ברזולוציה נדרשת- כרטיס טיסה/מלון/ וכו'..5.13.2.4.2

326

אישור הבקשה בפורמט עובר את כל סבבי האישורים הנדרשים..5.13.2.4.3התקציב הוא ברמת יחידה ארגונית..5.13.2.4.4 היא מול התקציב הכולל ולא ברמת הוצאה פרטנית.actualהבדיקה של ה.5.13.2.4.5דוגמאות: רכישת עצמית, אש"ל לחו"ל..5.13.2.4.6

מערכת העברות כספיות:.5.13.2.5

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

הבקשות עוברות את מסלול התחנות והאישורים..5.13.2.5.2

תיאור מצב נדרש.5.13.3

פורטל הרשמה וסטודנטים:.5.13.3.1

FI ולכן לא יידרש שינוי מכיוון שהרישומים הפיננסים ל SAP CMהרישומים בפורטל סטודנטים ישפיעו על .5.13.3.1.1.CM ישירות - ראה מסמך שינויים ב CMמתבצעים דרך ה

לא יהיה שינוי בפורטל בכל מה שקשור לסטודנטים..5.13.3.1.2פורטל סגל:.5.13.3.2

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

במחקר(.לטופס שעות ארעים יש שני סבבי אישורים– לא נדרש שינוי..5.13.3.2.1.3 בעת אישור העסקת העובד הארעי נדרש לייצר התחייבות תקציבית בגין הסכום עבור התקופה.5.13.3.2.1.4

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

הוצאות השכר בפועל נרשמות רק בעת התשלום לעובד ולא נוצרת הפרשה בספרים – תהליך.5.13.3.2.1.5זה לא ישתנה.

טופס בקשה לניצול קקמ"ב.5.13.3.2.2

327

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

מהטבלה הזו ולפיה המערכת חוסמת או מאשרת את הבקשה לתקציב של החוקר - טבלה זו.SAPצריכה להשתנות לטבלת

.SAPהבקשה של החוקר יוצרת התחייבות, ההתחייבות צריכה להירשם ב .5.13.3.2.2.3 ולהפוך את ההתחייבות.ACTהרישום של ההוצאה צריך לרשום את ה .5.13.3.2.2.4יכול לקחת את.5.13.3.2.2.5 - עובר ממשק לבנק הפועלים שהחוקר במידה והחוקר מעוניין לקבל מזומן

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

328

:GMפורטל .5.13.3.3

הצגת דוחות מחקרים – תקציב מול בפועל..5.13.3.3.1.FIקול קורא – לא ישתנה ולא רלוונטי ל .5.13.3.3.2

תשלומים ידניים של החזרי הוצאות:.5.13.3.4

לנסיעה באמצעות אובייקט של הזמנה פנימית שתרכז את כל ההוצאות של.5.13.3.4.1 המערכת תאפשר להקים הנסיעה - הפורטל למעשה צריך להקים את האובייקט הזה. ניהול ההזמנה הפנימית יאפשר לראות בכל

רגע נתון את הסטטוס של כל סעיף בהזמנה.מערכת העברות כספיות.5.13.3.5

המערכת תאפשר לבצע קניות ומכירות פנימיות בין יחידות ארגוניות:.5.13.3.5.1היחידה המוכרת מקטינה הוצאה/רושמת הכנסה..5.13.3.5.1.1היחידה הקונה מבצעת פעולה הפוכה..5.13.3.5.1.2 שיטת החיוב דינמית ותלויה באופי השירות ) שעות שימוש באודיטוריום, שעות שימוש במעבדה.5.13.3.5.1.3

וכו'(. ישנם מצבים שבהם משתמשים בתקציב "רזרבה"- במצבים אלו אין העברת תקציב בפועל אלא.5.13.3.5.1.4

העברה פנימית: היחידה המקבלת מקבלת הכנסה אל מול הוצאה ביחידה המוכרת ) מתקייםבדר"כ בתקציב משק סגור ביחידה המקבלת(.

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

329

נמחק.5.13.4

נמחק.5.13.5

נמחק.5.13.6

פירוט דרישות עסקיות בנושא פורטל.5.13.7

( 4% משקל הדרישות העסקיות בנושא פורטל בשלב בדיקת התאמת המענה: חלק מפעילות ההתאמה בפורטל תתבצע על ידי צוותי המחשוב של האוניברסיטה וחלקה בידי

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

" ויש להכליל אותן בתמחורנדרש הינן בקטגוריית "5.2.7.12 ועד 5.2.7.1כל הדרישות העסקיות תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceהכולל )

תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושאמס' דרישה עסקית עליהם מתבסס בהצעתו(SAPלמודולי

קקמ"ב5.13.7.1

כאשר משתמש מזין בפורטל טופס בקשה

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

בקרן שלו

 

קקמ"ב5.13.7.2

בעת אישור בקשות לניצול תקציב של החוקר )כיום

מנוהל בפורטל סגל( ,SAPתיווצר התחייבות ב

שלACTרישום ה

 

330

ההוצאה תהפוך אתההתחייבות אוטומטית

, קקמ"בFIממשק פורטל-5.13.7.3

במידה והחוקר מעוניין לקבל מזומן - עובר ממשק

לבנק הפועלים שהחוקר יכול לקחת את המזומן

מנקודת איסוף שנבחרת מראש. בעת העברת הכסף לחוקר נרשמת

פקודת יומן לפרופיט בגין קבלת המזומן- פקודת

היומן שנרשמת היוםבפרופיט צריכה להירשם ב

FIנדרש ממשק פקודות ( (FIיומן פורטל-

 

פורטל סגל5.13.7.4

סבב האשורים של הטפסים בפורטל סגל

מתבסס כיום מול טבלאותZהדרישה היא –

להשתמש בסבב אישורים לטפסיםSAPסטנדרטי ב בפורטל סגל

 

". המציעלא נדרש מבוצעות בידי צוותי האוניברסיטה והינה בקטגוריית "5.13.7.6 ו- 5.13.7.5הדרישות העסקיות

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

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

331

מס' דרישהעסקית

נושאתיאור הדרישה

תיאור המציע את המענה )כולל עליהם מתבססSAPהתייחסות למודולי

בהצעתו( )נדרש/לא

נדרש לתמחר(

קקמ"ב5.13.7.5

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

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

SAPטבלה זו בטבלת

 

תשלומים ידניים5.13.7.6של החזרי הוצאות

המערכת תאפשר לראות בכל רגע נתון את הסטטוס של כל סעיף בהזמנה על בסיס ההזמנה

פתוח, האם התקבלPOהפנימית- האם יש תשלום, האם יצאה חשבונית וכו' ) תחילת

התהליך של החזרי הוצאות בגין תשלומים ידנייםמתבצעת בפורטל(

 

332

ניהול ספריה.5.14

רקע.5.14.1

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

הרלוונטיות.

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

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

קיימת סינרגיה בין ספריות בארץ- השאלה בין ספרייתית יש ניהול תקבולים וגבייה בהקשר זה..5.14.1.4

333

תיאור מצב קיים.5.14.2

מבנה ארגוני .5.14.2.1

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

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

המרכזי.ניהול שעות עבודה והוצאות בפועל של עובדים לפי שעות- נרשמים על מרכזי העלות המשניים ) היחידות(..5.14.2.1.3

תכנון תקציבי.5.14.2.2

מחלקת תקציב מתקצבת רכש ספרים כסכום מרכזי- הפיצול שלו מתבצע בעלמא..5.14.2.2.1 מחלקת תקציב מתקצבת את כל הסעיפים שאינם רכש ספרים כגון הוצאות שכר והוצאות אחרות )כל רכיבי.5.14.2.2.2

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

הספרייה מנהלת תקציבים סגורים- גובים הכנסות בגין קנסות, בגין השאלה בין ספרייתית ומוציאים בגובה.5.14.2.3.1ההכנסות לפי הצורך.

ניהול רכש.5.14.2.4

רכש ספרים מנוהל בעלמא- בהתאמה תקציב הרכש מנוהל בעלמא..5.14.2.4.1 –למשל קניית מחשבים.MMרכש של כל מה שאינו ספרים מבוצע ב.5.14.2.4.2

334

תיאור מצב נדרש.5.14.3

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

תכנון תקציבי.5.14.3.2

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

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

מחלקת תקציב מתקצבת רכש ספרים כסכום מרכזי- הפיצול שלו מתבצע בעלמא- מצב זה יישאר. .5.14.3.2.3 מחלקת תקציב מתקצבת את כל הסעיפים שאינם רכש ספרים כגון הוצאות שכר והוצאות אחרות- תקציב.5.14.3.2.4

וכך זה יישאר.SAPזה מנוהל רק ב

335

פירוט תהליכים.5.14.4

קייםP2Pתיאור תהליך .5.14.4.1

עלמא.5.14.4.1.1הזמנת רכש ספרים מאגרי מידע וכתבי עת שמוקמת יוצרת שריון תקציבי בעלמא..5.14.4.1.1.1מתבצעת קבלה במערכת, לא קורה בגינה שום תהליך רישומי פיננסי )יש ניהול לוגיסטי בלבד(..5.14.4.1.1.2 קליטת חשבונית מתבצעת במערכת היא מבטלת את השריון התקציבי ורושמת הוצאה. נסגרת.5.14.4.1.1.3

מול הזמנה ספציפית.ההוצאה נרשמת במועד קליטת התשלום ולא במועד ביצוע ה"קבלה" במערכת..5.14.4.1.1.4המאפשר בלחיצת כפתור לשנות את השנה במערכת.Rolloverכיום בעלמא יש תהליך של .5.14.4.1.1.5

הזמנות רכש שהוקמו בשנת שעבור הוא זה של מהלך כל2018אחת התוצאות ורשומות בעוד שיתר הנתונים נותרים ללא שינוי.2019במערכת, השנה מתעדכנת ל

5.14.4.1.2.SAP . הביטוי מגיע רקSAPתהליך הרכש של ספרים מאגרי מידע וכתבי עת לא בא לידי ביטוי ב.5.14.4.1.2.1

בשלב התשלום - בו נרשמת ההוצאה והתשלום )ח< הוצאה ז< בנק(

336

337

338

פירוט דרישות עסקיות בנוגע לספריה.5.14.5

( 1% משקל הדרישות העסקיות בנושא ספרייה בשלב בדיקת התאמת המענה: " ויש להכליל אותן בתמחורנדרש הינן בקטגוריית "5.14.5.3 ועד 5.14.5.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceהכולל )

מס' דרישהתיאור הדרישהנושאעסקית

תיאור המציע את המענה )כולל עליהםSAPהתייחסות למודולי

מתבסס בהצעתו(

שליחת מכתבי גבייה5.14.5.1 Dunning letterהמערכת תאפשר לבצע הפקת

)מכתבי גבייה( אוטומטיים ללקוחות הספרייהSAPמתוך ה

 

לקוחות שהם גם5.14.5.2ספקים

Contraהמערכת צריכה לאפשר תשלום בchargingחשבוניות לקוחות יוצאות על הסכום :

ברוטו אבל התשלום הוא על ההפרש נטו 

תקציב מול ביצוע5.14.5.3

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

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

CO ודו"ח זה יופק מה SAPכמרכזי עלות ב

 

339

ניהול הרשאות.5.15

תיאור מצב קיים.5.15.1

מבנה מערך ההרשאות.5.15.1.1

על בסיס אובייקטי ההרשאה הסטנדרטיים של ה-SAP ECCכיום, מנוהל מערך ההרשאות במערכת ה- .5.15.1.1.1SAP:קרי שימוש בין השאר ב ,

5.15.1.1.1.1. SAP Roles: Single Role, Composed Role, Master and Derived/Son Role5.15.1.1.1.2.Organization Level Values5.15.1.1.1.3.Authorization Object5.15.1.1.1.4.SAP Transactions5.15.1.1.1.5.User Profiles5.15.1.1.1.6.User Parameters

בנוי: SAP Rolesמערך ה- .5.15.1.1.2 עבור עובד מחלקת התקשרויות המכילRole עבור עיסוק/פרופיל עסקי, כדוגמת Roleבחלקו כ- .5.15.1.1.2.1

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

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

מחלקה אשר יש לו צורך במסגרת תפקידו לאשר דרישות רכש. חלק ממערך ההרשאות מושתת על הרשאות מבניות )פרופיל מערכת/פרופיל עסקי(, כלומר איחוד/קיבוץ.5.15.1.1.3

נתוני הרשאה לכדי פרופיל עסקי המגדיר בתוכו את הבדלי ההרשאות הרלוונטיים בין המשתמשים השונים וכו'(.OOSP, OOSB. )כדוגמת שימוש בטרנזקציות: SAPהעושים שימוש באותם הרשאות

(.zfcc הרשאות מערכת אלא מנוהל בטבלה מקומית )rolesכיום הרשאות ברמת מרכז עלות אינו מנוהל ב-.5.15.1.1.4 בנושאים לוגיסטיים ולהכיל התייחסות למרכזי עלות.rolesנדרש לשנות

340

שיוך הרשאות למשתמשים.5.15.1.2

יכולה להגיע מכמה מקומות, כגון:SAPהקצאת ההרשאות למשתמש במערכת ה- .5.15.1.2.1 משויך בתוך המבנה האירגוני/היררכי של האוניברסיטה על בסיס המבנהSAP Rolesמערך ה- .5.15.1.2.1.1

.SAP HRהאירגוני הקיים במודול השיוך במבנה הארגוני במערכת מתבצע בכמה רמות, הן ברמת יחידות ארגוניות והן ברמת.5.15.1.2.1.2

משרות, וכאשר עובד משויך לאותה יחידה ארגונית ו/או משרה הוא יורש את מכלול ההרשאותששויכו לאותה יחידה ארגונית ו/או משרה.

יכול לקבל בנוסף להרשאות שקיבל על בסיס המבנה הארגוני אליו הוא שויך אף.5.15.1.2.1.3 משתמש מסוים )כדוגמא שיוךSAP Role נוספים ע"י חיבור ישיר של המשתמש ל- SAP Rolesהרשאות/

(.SU01דרך משתמש יכול לקבל הרשאות על בסיס ההרשאות המבניות/פרופיל מערכת/פרופיל עסקי. .5.15.1.2.1.4 חלק מהמשתמשים מקבלים הרשאות דרך כל אחד מהדוגמאות שצוינו לעיל וחלק מקבלים.5.15.1.2.1.5

הרשאות דרך אחד או כמה דרכים מאלו שצוינו לעיל.SAPסוגי משתמשים במערכת ה- .5.15.1.2.2

עובדי האוניברסיטה .5.15.1.2.2.1 לאחר הקמת עובד במערכת ע"י משתמשי משאבי אנוש, והיה ויש צורך לתת.5.15.1.2.2.1.1

SAP, מועברים הנתונים לאנשי ה- SAPלאותו עובד גם הרשאות במערכת ה- BASIS( לצורך הקמת משתמש מערכת SAP USERוהקצאת ההרשאות ) עבורו.

סטודנטים.5.15.1.2.2.2 דרך הפורטל, מוקם עבורו בצורה אוטומטית, גםBPלאחר הקמת הסטודנט כ- .5.15.1.2.2.2.1

( ומקצה עבורו ההרשאות הרלוונטיות.SAP USERשם משתמש במערכת )עובדים שאין להם קשרי עובד מעביד.5.15.1.2.2.3

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

.SAP GMהרלוונטיות לצורך שימוש במודול ה- משתמשי הפורטל.5.15.1.2.2.4

341

לא לכל מי שיש לו הרשאות לשימוש בפורטל יש בהכרח גם הרשאות במערכת.5.15.1.2.2.4.1.SAPה-

(System/Communication/Serviceמשתמשי מערכת אוטומטיים )משתמש מסוג .5.15.1.2.2.5 ישנם מספר משתמשי מערכת אוטומטיים שנועדו לצורך ניהול מערך ההרשאות.5.15.1.2.2.5.1

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

כו'.GMהפורטל/סטודנטים, משתמש מערכת לצורך מתן הרשאות למודל SOLMAN: Solution Managerמערכת/סביבת .5.15.1.3

ה- .5.15.1.3.1 במערכת הקיימות הסביבות ה-SAPבמערך במערכת/מודול שימוש ישנו באוניברסיטה הקיימת Solution Manager -אך הוא אינו משמש לניהול מערך ההרשאות של מערכות ה SAP.

)SSO )Single Sign Onחיבור ישיר/יחידני למערכת .5.15.1.4

ישנו חיבור בין המערכות השונות לצורך ביצוע התחברות והזדהות מול המערכות השונות באמצעות מזהה.5.15.1.4.1אחד.

זיהוי המשתמשים הנכנסים למערכות דרך הפורטל מתבצע ע"י הזנת ת.ז..5.15.1.4.2

תיאור מצב נדרש.5.15.2

מבחינת ניהול ההרשאות מרבית המודולים משתמשים בסטנדרט ולא יידרש שינוי משמעותי כלשהו בעקבות הטמעת המודולים הפיננסיים.5.15.2.1.Fioriמלבד התאמות שיידרשו במודולים שיעברו לשימוש ב-

342

פירוט דרישות בנוגע להרשאות.5.15.3

( 4% משקל הדרישות העסקיות בנושא הרשאות בשלב בדיקת התאמת המענה: " ויש להכליל אותן בתמחורנדרש הינן בקטגוריית "5.15.3.19 ועד 5.15.3.1כל הדרישות העסקיות

תמחור נפרד לדרישות עסקיות אילו.אין לספק( של הפרויקט. Fix Priceהכולל )

מס' דרישהעסקית

תיאור המציע את המענה )כולל התייחסותתיאור הדרישהנושא עליהם מתבסס בהצעתו(SAPלמודולי

כללי5.15.3.1

SAPכיום, מנוהל מערך הרשאות למערכת ה- ECCאשר דרכו ניתנות ההרשאות לכל

המשתמשים הרלוונטיים. מערך הרשאות זה מאפשר לכלל המשתמשים הרלוונטיים שימוש

לביצוע הפעולות העסקיותSAPבמערכת ה- שלהם על פי תחום אחריותם במסגרת התהליכים

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

המשכיות עסקית תוך שמירה על הפרדתההרשאות הקיימת כיום למשתמשי המערכת.

 

343

ניהול מערך5.15.3.2ההרשאות

מערך ההרשאות שיוקם בעקבות הטמעת צריך לאפשר מתןSAPהמודולים הפיננסים ב-

הרשאות דומות למשתמשים הרלוונטיים במערכת בהתאם להרשאות שהיו להםSAPהפיננסית ב-

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

 

משתמשים פעילים בפרופיט50- היום יש כFIשיצטרכו לקבל הרשאות מקבילות מתאימות ב

במספר, שיש550- קיימים משתמשים נוספים, כ להם הרשאות צפייה במערכת הפיננסית הנוכחית

ויידרשו להרשאות צפייה במודולים הפיננסייםFI-CO-FMהחדשים

משתמשים שאין250- האוניברסיטה צופה שכ להם היום נגיעה במערכת הפיננסית החיצונית

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

344

ניהול מערך5.15.3.3ההרשאות

על המערכת לאפשר ניהול הרשאות על בסיס SAPהמבנה הארגוני המוגדר במערכת במודול ה-

HR 

ניהול מערך5.15.3.4ההרשאות

על המערכת לאפשר ניהול מערך הרשאות על בסיס הרמות השונות במבנה הארגוני הקיים

, כגון: הרשאות על בסיסSAP HRבמודול ה- יחידה ארגונית, הרשאות על בסיס משרה ועוד

 

ניהול מערך5.15.3.5ההרשאות

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

מגוון הרשאות שונות לבעל תפקיד מסוים תוך מתן אפשרות לביצוע הפרדת הרשאות בין המשתמשים

השונים.

 

ניהול מערך5.15.3.6ההרשאות

על המערכת לאפשר תהליכי הורשת הרשאות מרמות שונות במבנה הארגוני למשתמש, כגון:

הורשת הרשאות מהרמה הישירה )משרה-יחידה ארגונית ישירה, הורשת הרשאות מרמת יחידה

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

 

345

ניהול מערך5.15.3.7ההרשאות

על המערכת לאפשר ניהול הרשאות למשתמש בצורה ישירה שלא דרך המבנה הארגוני

ניהול מערך5.15.3.8ההרשאות

על המערכת לאפשר ניהול הרשאות למשתמש מכמה מקומות/דרכים בו זמנית )כגון: שיוך

הרשאות למשתמש גם דרך המבנה הארגוני וגםבחיבור ישיר למשתמש(.

 

ניהול מערך5.15.3.9ההרשאות

על המערכת לאפשר ניהול מערך הרשאות הן בהיבט של עיסוק/פרופיל עסקי )כגון: הקמת מערך

הרשאות לנציג התקשרויות אותו ייתנו לכל נציג התקשרויות(, והן בהיבט של פעולות עסקיות )כגון:

הקמת מערך הרשאות לאישור דרישת רכש אותו ייתנו לכל גורם/בעל תפקיד אשר נזקק להרשאות

אלו(.

 

346

ניהול מערך5.15.3.10ההרשאות

על המערכת לאפשר ניהול של מספר סוגי/פלטפורמות מערכי הרשאות לצורך ניהול כלל

SAP ופלטפורמת SAP ECCהרשאות מערכת ה- HANAוזאת לצורך המשך הפעילות העסקית של ,

משתמשי המערכת במודולים השונים, כאשר חלק SAPמהמודלים עדיין יהיו על בסיס מערכת ה-

ECC -חלק יהיו דרך ה ,SAP HANAחלק יהיו דרך , SAP FIORIה-

 

ניהול מערך5.15.3.11ההרשאות

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

כספי לאישור, סוגי חריגים שונים לאישור, פתיחת תקופות פיננסיות ו/או לוגיסטיות ועוד יוגדרו

בהמשך ע"י המשתמשים ובהתאם לתהליכים העסקיים והפתרונות הטכניים אשר יסופקו ע"י

המציע במהלך ביצוע האפיונים.

 

347

ניהול הרשאות5.15.3.12MM

המערכת תאפשר ניהול הרשאות באופן כזה שהמשתמש שמקים את דרישת הרכש יוכל להקים

דרישה אך ורק ליחידות הארגוניות אליו הואמורשה, ומטה- הבדיקה תהיה ברמת משתמש

 

ניהול הרשאות5.15.3.13MM

על המערכת לאפשר ניהול מערך הרשאות עבור הקטלוגים של מק"טי חומר ו/או שירות ברמות

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

אליה ועוד.

 

348

ניהול הרשאות5.15.3.14HR

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

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

)קליטה, עזיבה, יציאה לחל"ד וכו'(. מערך זה של הרשאות צריך, לפחות, להישאר גם לאחר השימוש

ואף לאחר הטמעתSAP HANAבפלטפורמת .SAPהמודולים הפיננסים של מערכת ה-

 

349

ניהול הרשאות5.15.3.15HR

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

חלק ממחלקת משאבי אנוש גישה לנתונים המופיעים בתיקי העובד ואף לבצע פעולות )יצירה,

עדכון, צפייה וכו'( ופעילויות )הקמת עובד, עזיבה, יציאה לחל"ד וכו'( שונות וזאת בהתאם למשימות

הניתנות להם במסגרת תפקידם.

 

ניהול הרשאות5.15.3.16BI

SAPהצגת נתונים למשתמשים מתוך מערכת ה- יתבססו על מערךBIאשר יופיעו בדוחות ה-

, ובהתאם לכךSAPההרשאות הקיים במערכת ה- יציגו/לא יציגו נתונים למשתמשים, לדוגמא: אם

לצפייה בנתוןSAPלמשתמש אין הרשאה ב- שמציג, בין השאר, נתוןBIמסוים- והיה ויפעיל דוח

זה- הוא לא אמור לצפות בו.

 

350

ניהול הרשאות5.15.3.17BI

ניהול מערך ההרשאות למשתמשים עבור שימוש ינוהל במערכת אחת מרכזית.BIבדוחות ה-

ולא מהBI)ההגדרה איזה משתמש רואה איזה דוח מופיע בתוך הדוח(

 

ניהול הרשאות ב5.15.3.18S4HANNAביצוע התאמות נדרשות בעת המעבר לS4HANNA  

ניהול הרשאות ב5.15.3.19FIORI

ביצוע התאמות נדרשות בכל המודולים שיעבדו בFIORI 

351