הכללים הנפוצים להתמודד עם הם כדלקמן:
1. לזהות באופן אוטומטי אם זה חלק סטנדרטי על פי הקוד
2. בהתאם להוראות ההשאלה המסומנות ברשימת השרטוט על השרטוט, הרכיב הוא פריט שאול. אם הפריט שאול כבר במערכת, התכונה, נתוני המבנה וקובץ התמונה המשויכים צריכים להיות מקושרים אוטומטית בהתאם לקוד.
3. לאחר שהרכיבים המיוחדים ילוו על ידי מוצרים אחרים, הם יוצגו ככרטיסי אשראי על מוצרים אחרים, ויש להבחין בין החלקים המיוחדים. כמו כן, כאשר מסכמים את רשימת המוצרים, הקפד לציין את מקור המוצר שאול. מכיוון שהחברה בדרך כלל אינה מייצרת שרטוטים עבור חלקים שאולצו, אם מחלקת התכנון אחראית על מתן שרטוטים, היא צריכה להשתמש בפרטי המוצר שנשאלו מתוך רשימת המוצרים כדי למצוא את רישומי המוצרים שאולצו (בדרך כלל כרוכים בספר שלם או בארון ), ולאחר מכן צריך (בעיקר בהתאם לסדנה יש רישומים המתאימים) כדי להחליט להדפיס את המפה, אם היא מפת מנהיג סדנה, יש צורך למצוא את מחלקת הקבצים על פי "רשימת מוצרים".
4. במקרה של ניהול ידני, יש צורך למצוא את הקשר המקורי ההלוואה עבור חלקים שאול, ולאחר מכן ידנית למלא את הרשימה המפורטת, וזה מאוד קל לעשות טעויות. זה לעתים קרובות לא ברור איזה מהם מושאל מן המוצר הלווה המקורי. אם המחשב יכול באופן אוטומטי למלא את עמודה הערות "לשאול קוד מוצר" על פי המוצר של החלק המיוחד המתאים הפריט הלווה, זה יכול לצמצם באופן משמעותי שגיאות שכפול של עבודה.
5, בנוסף לעשות פסק דין חשוב כי כאשר ישנם חלקים מרובים של אותו קוד במערכת, קודם כל, זה חייב להיות מובטח כי יכול להיות רק חתיכה מיוחדת ייחודית. אם חלק משותף מתאים לחלק מיוחד ייתכן שיהיה צורך לחקור.
.6 אם החלקים המושאלים מושאלים יותר ממספר מסוים של פעמים בסדרות מוצרים שונות, הם ניתנים להמרה אוטומטית לחלקים משותפים. כמה ארגונים יש דרישה זו וניהול.
7. חלקים כללי וחלקים סטנדרטיים ניתן לנהל בספרייה חלקים בסיסיים 3.X. לא ברור כיצד הבעיות לעיל מטופלות ב 4.0.
8. צריך להיות מסוגל לגלות אילו מוצרים או מבנים רכיב מושאל מ. נכון לעכשיו, התוצאה הסופית של עיצוב ממשק של כל פעולות השאילתה הוא רע מאוד.
