שינוי בהזמנה מאושרת מתחיל מתיעוד ההבדל בין הגרסה התקפה לבקשה החדשה. מפרידים את מה שכבר התקבל מהיתרה שעדיין מתוכננת, מבררים את ההשפעה על האתר ומקבלים את האישורים שנקבעו בתהליך. רק לאחר בירור ואישור מעדכנים את הגרסה ומוודאים שהספק והמקבל בשטח עובדים לפי אותו מידע.
1. מפרידים בקשת שינוי מהזמנה מעודכנת
הספק מבקש לדחות אספקה, השטח צריך כמות נוספת או שמתברר שהמפרט דורש בירור. בכל אחד מהמקרים רושמים תחילה בקשת שינוי עם תאריך, מבקש וסיבה. הודעה על שינוי רצוי עדיין אינה הוכחה שהשינוי אושר או שהספק קיבל אותו.
שמרו את פרטי הגרסה התקפה לצד הבקשה. אם משנים מיד את השורה בלי לשמור את ההקשר, המקבל בשטח עלול לראות כמות אחרת מזו שנשלחה לספק. הגדירו איזה מסמך תקף כל עוד הבקשה נבדקת ומי מוסמך לשנות את מצבה.
2. מתעדים לפני ואחרי ברמת השורה
טבלת ההשוואה צריכה להראות את השינוי עצמו, ולא רק סכום או כמות חדשים. שמרו לצד כל שדה את המקור, ההחלטה והגורם שמאשר. שדה שאינו משתנה נשאר מפורש כדי שאפשר יהיה לראות מה היקף הבקשה.
| מה בודקים | לפני ואחרי | מה מאמתים |
|---|---|---|
| פריט ומפרט | הפריט התקף והחלופה המבוקשת | מי בודק התאמה לדרישה בשטח |
| כמות ויחידה | הכמות המאושרת והכמות המבוקשת באותה יחידה | מה כבר התקבל ומה נותר לאספקה |
| מועד ומקום | המועד והאתר הקיימים מול השינוי המבוקש | מי באתר מאשר שיוכל לקבל את האספקה |
| תנאים ומסמכים | התנאים התקפים והעדכון שנשלח לבירור | אישור פנימי, תגובת ספק והגרסה שנמסרה |
3. לא משנים את העבר כדי להתאים לבקשה
דוגמה להמחשה בלבד: הוזמנו 80 יחידות, מתוכן התקבלו ואומתו 30. השטח מבקש להגדיל את הכמות הכוללת ל־90. לאחר בירור ואישור, היתרה המתוכננת תהיה 60 יחידות במקום 50. הכמות שכבר התקבלה נשארת 30; שינוי ההזמנה אינו הוכחה שהגיע משלוח נוסף.
אם הבקשה מתייחסת להחלפת פריט, אל תניחו שהיחידות שכבר התקבלו הפכו לפריט החדש. בדקו בנפרד מה נמצא באתר ומה הוסכם לגבי היתרה. תעדו כל החזרה או תיקון במקור המתאים, במקום למחוק את התיעוד הקודם.
4. סוגרים את ההעברה לספק ולאתר
לאחר ההחלטה רשמו מי אישר, איזו גרסה נשלחה ומה הספק אישר שקיבל. ודאו שהמקבל באתר יודע איזה פריט, כמות ומועד צפויים כעת. אם האישור חלקי או שיש סתירה בין התשובות, השאירו את הפער גלוי עם אחראי ומועד לבירור.
Microsoft מתארת ב־Dynamics 365 אישור מחדש לפי כללי ניהול שינויים ושמירת גרסאות אישור של הזמנות. זהו מקור מקצועי להבחנה בין בקשה, אישור וגרסה; הוא אינו מתאר יכולת שאומתה ב־NovaPro או חיבור בין המערכות.
מקורות להרחבה: Microsoft Learn — אישור ושינוי הזמנות רכש
5. בודקים את הגרסה גם בקבלה ובחשבונית
כשהמשלוח מגיע, מקשרים את הקבלה להזמנה ולשורה הנכונות ובודקים אותה מול הגרסה שאושרה. בהמשך, בבדיקת החשבונית, מציגים גם את השינוי ואת המסמכים שתומכים בו. לא מסיקים שחשבונית תקינה רק משום שהסכום הכולל דומה לסכום ההזמנה.
בהדגמת מערכת רכש בקשו לראות תרחיש של שינוי אחרי קבלה חלקית: איך נשמר התיעוד, מי יכול לאשר, מה המקבל רואה ומה קורה אם הספק לא אישר. בדקו אילו חלקים קיימים בפועל ואילו דורשים הגדרה או פיתוח לפני שמסתמכים על התהליך.
בהדגמה אישית נבחן את ההזמנה, הקבלה והחשבונית בהקשר של תהליך הרכש שלכם.
לתיאום הדגמת תהליך רכששאלות נפוצות
האם בקשת שינוי של הספק מעדכנת אוטומטית את ההזמנה?
לא מניחים כך. מפרידים בין בקשה שהתקבלה, החלטה פנימית, גרסה שנשלחה ואישור הספק. התהליך וההרשאות במערכת קובעים מי יכול לעדכן ואיזו גרסה תקפה.
איך מטפלים בכמות שכבר התקבלה?
שומרים את הקבלה המתועדת בנפרד מהכמות המבוקשת לעתיד. שינוי בהזמנה אינו משנה כשלעצמו את מה שאומת בשטח. החזרה או תיקון דורשים תיעוד נפרד לפי התהליך.
ממשיכים לקרוא
איך בונים תהליך רכש מסודר בפרויקט בנייה? ←