מי רשאי לעשות מה, ומה נשאר רשום

כל תפקיד במילים פשוטות

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

תפקידים שרואים את כל המשרד

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

תפקידים שרואים רק לקוחות משויכים

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

מחוץ לצוות המשרד

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

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

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

גישה לפי לקוח

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

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

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

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

הפרדת תפקידים, ומה ברירת המחדל

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

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

התיעוד: מי עשה מה ומתי

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

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

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

היסטוריית אחריות

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

מה התיעוד מגן עליו, ומה לא

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

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

הפרדת נתונים בין משרדים ובין לקוחות

בין משרדים: במסד הנתונים עצמו

כל טבלה שמחזיקה נתונים של משרד מוגנת בכלל של מסד הנתונים עצמו, שמסנן כל שורה לפי מזהה המשרד (Row-Level Security). כל בקשה קושרת את מזהה המשרד שלה לחיבור למסד הנתונים: בקשה של משתמש במשרד, בכל טרנזקציה שהיא פותחת; קישור ציבורי, כמו הפורטל של לקוח, טופס 101 או תלוש, לפי המשרד של הקישור. טרנזקציה שלא נקשר בה משרד לא מקבלת שורות של אף משרד. כך ההפרדה בין משרדים לא תלויה רק בקוד של האפליקציה: מסד הנתונים עצמו לא מחזיר לכם שורות של משרד אחר. בדיקות אוטומטיות מריצות את זה מול מסד נתונים אמיתי, עם משתמש שאינו יכול לעקוף את הכלל.

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

בין לקוחות של אותו משרד: בשרת, בכל בקשה

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

הצפנה, גיבויים ופרטיות

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

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

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

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