iCount עם Make או API ישיר: איך בוחרים ובודקים בלי להפיק מסמך

האם טופס Google Forms יכול ליצור או לעדכן לקוח ב־iCount ולהודיע לי לפני הפקת מסמך?

התשובה הכנה היא שהתיעוד שבדקנו אינו מספיק כדי לאשר את התהליך המלא. פעולות על מסמכים מתועדות במודולים הייעודיים של Make וב־API הישיר. Make an API Call הוא מסלול ביניים אפשרי, אבל הכיסוי שלו ל־iCount עדיין טעון אימות:

יצירה ועדכון של לקוח מתועדים גם במחבר של Make וגם במודול client של ה־API. חיבור של טופס Google Forms, התאמת השדות ושליחת התראה לפני הפקת מסמך הם חלקים נפרדים שעדיין דורשים אימות.

תרחיש Google Forms כאן הוא דוגמה היפותטית בלבד. הוא לא נוסה, ואין לו תוצאה שנצפתה.

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

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

1. מודול ייעודי ב־Make: אחת מפעולות המסמכים המתועדות באפליקציית iCount של Make.
2. הפעולה Make an API Call: קריאה כללית ל־API מתוך Make.
3. חיבור API ישיר: קוד או כלי שאתם מתחזקים ומתחברים בו ישירות ל־API של iCount.

מה בדקנו ומה עדיין לא נוסה בחשבון

ב־21 באוקטובר 2026 טייגר מדיה הריצה בדיקת תיעוד ממוקדת. הבדיקה השוותה בין מחבר iCount המתועד ב־Make לבין ה־API הישיר. היא אימתה את מלאי הפעולות המתועד בשני המסלולים, לרבות פעולות חיפוש וקריאה שיכולות לשמש לבדיקת חיבור בלי ליצור מסמך חשבונאי.

זו הייתה בדיקת תיעוד בלבד:

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

מקורות iCount נבדקו ב־22 באוקטובר 2026. דף התיעוד של Make מציג עדכון מ־21 באוקטובר 2026, ומלאי המודולים שלו עשוי להשתנות. לכן כדאי לבדוק מחדש את הרשימה לפני שמחליטים.

• לא נעשה שימוש בפרטי התחברות או בחשבון לקוח.
• לא בוצעה קריאת API מאומתת מול חשבון.
• לא נוצר, לא בוטל ולא נשלח מסמך חשבונאי.

שלושה מסלולי חיבור שכדאי להשוות

הטבלה משווה את שלושת המסלולים לפי מה שמתועד. כל תא שמסומן "טעון אימות" הוא שאלה פתוחה. הוא לא מעיד על חסר ב־Make או ב־API.

אין כלל שאומר שכל פעולה שחסר לה מודול ייעודי מחייבת לצאת מ־Make. כשחסר מודול, Make an API Call הוא מסלול שצריך לבחון. הוא לא מבטיח פתרון, ואין ראיה שהוא נכשל.

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

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

האירוע שמתחיל את התהליך.

המידע שעובר בין המערכות.

התוצאה שמותר לתהליך לבצע.

דוגמה לשימוש בטבלה, על התרחיש ההיפותטי מהפתיחה:

1. כתבו את האירוע המפעיל במשפט אחד. למשל "נשלח טופס" או "מתבצע שינוי בסטטוס עסקה". אל תכתבו את שם הכלי, רק את האירוע.
2. סמנו אם האירוע קורה מחוץ ל־iCount או בתוכו. מחבר Make שנבדק אינו מציג מודול טריגר. באינדקס ה־API של iCount מתועד מודול webhook, אבל האירועים שהוא מכסה והתאמתם לתרחיש שלכם עדיין דורשים בדיקה.
3. פרטו את הישות. הפרידו בין לקוח לבין מסמך. הם שתי ישויות עם שאלות שונות. פעולות יצירה ועדכון של לקוח מתועדות ב־Make וב־API, אבל התאמת השדות וההרשאות לחשבון דורשת אימות.
4. רשמו את השדות שחייבים לעבור. לכל שדה כתבו מאיפה הוא מגיע ולאן הוא נכנס.
5. רשמו אילו נתונים אסור שיעברו. סיסמאות, טוקנים ותוכן לקוחות לא נכנסים למסמך התכנון.
6. הגדירו את הפעולה המותרת. קריאה בלבד, חיפוש, או גם כתיבה. כל פעולה שיוצרת, מבטלת או שולחת מסמך צריכה בקרה מפורשת, והיא מחוץ לבדיקות במדריך הזה.
7. כתבו תנאי הצלחה. מה צריך לקרות כדי שתגידו "זה עובד", ומה עדיין לא יוכיח זאת.
8. סמנו לכל רכיב אם יש ראיה או שדרוש בירור.

בודקים אם המודול של Make מתאים לפעולה

ב־התיעוד של אפליקציית iCount ב־Make (נפתח בחלון חדש) רשומות תחת Docs ארבע פעולות מסמכים: Get a Document, Search Documents, Create a Document ו־Cancel a Document.

תחת Other מופיעה Make an API Call.

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

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

כדי לבדוק התאמה, עברו על הפעולות לפי הסדר:

חיבור המתועד ב־Make דורש חשבון iCount בתשלום, עם אפשרות להתחיל בניסיון חינם. החיבור משתמש בשדות Username, Company Identifier ו־Password.

1. סמנו איזו פעולה מתוך הרשימה מתאימה לפעולה שהגדרתם בסעיף הקודם.
2. אם אין פעולה מתאימה, בדקו אם Make an API Call הוא מסלול ביניים אפשרי (המשך בסעיף הבא).
3. רשמו מה צריך לבדוק בחשבון, ולא מה "כנראה" נכון.

מתי בוחנים קריאת API מתוך Make ומתי חיבור ישיר

Make an API Call הוא מסלול ביניים. כדי לבחון אותו, ענו על שלוש שאלות:

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

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

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

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

הסרטון הוא דוגמה כללית של צד שלישי. הוא לא מציג תוצאה שנבדקה ב־iCount, ולא נבדק במסגרת המדריך כמדריך להרשאות או למפתחות. הוא נטען רק בלחיצה (youtube-nocookie).

1. שיטה: האם אפשר לקרוא בעזרתה לשיטה שאתם צריכים?
2. שדות: האם אפשר להעביר את השדות הנדרשים, לפי החוזה הציבורי? לדוגמה, החוזה של doc/search מתאר שדות כמו client_id, custom_client_id, doctype, docnum, start_date ו־end_date.
3. אימות: האם האימות שהקריאה משתמשת בו מתאים להרשאות שהגדרתם?

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

How to Use the HTTP Module in Make.com (easy api calls)

מה צריך לברר על אימות והרשאות

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

הטבלה מפרטת מה מתועד, לפי מקור.

עוד פרט מתועד: כל נקודות הקצה של ה־API מקבלות בקשות POST עם גוף JSON ומחזירות JSON.

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

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

כדי לא להסתמך על תיעוד שמתאר שירות אחר, עברו לפי הסדר:

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

1. התחילו ב־Welcome to the iCount API (נפתח בחלון חדש). שם כתוב איך מתנהלות הבקשות ואילו שיטות אימות קיימות, לרבות מה שמתועד על הרשאות הטוקן ועל משך תוקפו של Session ID.
2. עברו אל האינדקס הציבורי של API v3 (נפתח בחלון חדש). מצאו את מודול doc וראו אילו שיטות מופיעות בו, ובהן search. שימו לב להפרדה בין שיטות קריאה לשיטות יצירה, ביטול ושליחה.
3. פתחו את חוזה השיטה המדויקת ב־doc method help (נפתח בחלון חדש). שם תראו את החוזה של doc/search.

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

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

אל תכניסו לגליון פרטי התחברות או נתוני לקוח.

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

1. שיטת האימות. איזו מבין השיטות המתועדות אתם מתכננים להשתמש בה, ולמה.
2. שיטת היעד. בבדיקה המוצעת כאן זו doc/search. כל נקודות הקצה מקבלות POST עם גוף JSON.
3. שדות הסינון. מתוך החוזה: client_id, custom_client_id, doctype, docnum, start_date, end_date.
4. גבולות הפלט. max_results מתועד כטווח 0 עד 1000 עם ברירת מחדל 100. limit מתועד עם ברירת מחדל 0, שפירושה ללא הגבלה. detail_level מתועד כטווח 0 עד 10 עם ברירת מחדל 1, וב־0 מוחזרים doctype ו־docnum. אלה פרמטרים מתועדים, לא הוכחה שהפלט הוגבל בחשבון.
5. תנאי הצלחה שעדיין טעונים בדיקה. כתבו אותם כשאלות, למשל "האם הבקשה מתקבלת?" ו"האם הפלט מוגבל כמצופה?", לא כתוצאות.

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

שימו לב: זהו מתווה בלבד. לא הרצנו אותו בחשבון, ואין לו תוצאה שנצפתה.

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

שתי הבהרות חשובות:

אם הבדיקה מתבצעת דרך Make, צריך לאמת בנפרד האם הפעולה Search Documents חושפת את אותם פרמטרים. זה לא מתועד בעובדות שבדקנו.

1. אישור בעל החשבון. קבלו אישור מפורש לבדיקה ולנתונים שייבדקו.
2. משתמש ייעודי ומוגבל. השתמשו במשתמש עם הרשאות מצומצמות. טוקן API יורש בדיוק את ההרשאות של המשתמש שאליו הוא מקושר, ולכן ההרשאות של המשתמש הן שקובעות מה אפשרי.
3. לקוח ידוע וטווח קצר. הגבילו את doc/search ללקוח בדיקה ידוע ולטווח תאריכים קצר.
4. הגבלת הפלט. max_results, limit ו־detail_level מתועדים בחוזה, אך לא נוסו בחשבון. הערכים כאן הם הצעת תכנון בלבד: max_results ל־1, limit ל־1 ו־detail_level ל־0, שמתועד כמחזיר רק doctype ו־docnum. צריך לאמת בחשבון שהפלט אכן מוגבל כמצופה.
5. שמירת מינימום. שמרו רק תוצאת מעבר או כשל ומזהי שגיאה נחוצים. אל תשמרו תוכן לקוחות.
6. מחוץ למסלול. אין להריץ doc/create, את Create a Document ב־Make, או קריאה כללית שממפה לפעולת כתיבה. אין שליחה של מסמך.

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

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

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

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

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

מה חייבים לפתור לפני הפעלה אוטומטית

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

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

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

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

הבחירה והנימוק.

המידע שחסר כדי להתקדם.

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

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

1. הפעולה: כתבו את האירוע, הישות והתוצאה המותרת מהסעיף "מגדירים את הפעולה לפני שבוחרים כלי".
2. המסלול המועדף: מודול ייעודי, Make an API Call או API ישיר.
3. הנימוק: נמקו לפי מה שאומת. מודול ייעודי מתאים כשהכיסוי אומת. Make an API Call מתאימה כשהשיטה, השדות והאימות נבדקו. API ישיר מתאים כשדרישות השליטה והתחזוקה מצדיקות אותו.
4. מקור הראיה: ציינו לכל נימוק אם הוא נשען על תיעוד רשמי או שהוא עדיין שאלה פתוחה.
5. בירור ההרשאות: שם החברה לשדה Company Identifier, זכאות המנוי והמשתמש הייעודי.
6. תוכנית הקריאה: מה בדיוק ייבדק, באילו שדות סינון ובאיזה גבול פלט, לפי הסעיפים "מתכננים בדיקה בלי להתחבר לחשבון" ו"מתווה שטרם נוסה".
7. תנאי מעבר: מתי מותר לעבור מבדיקת תיעוד לבדיקה בחשבון, ומתי מהבדיקה לבנייה.
8. חסמים: רשמו את הפערים הפתוחים מהסעיף "מה חייבים לפתור לפני הפעלה אוטומטית", כמו טריגרים, כפילויות, ניסיונות חוזרים ועלויות.
9. שם האחראי לבדיקה ולטיפול בתקלות.
10. מי מאשר את בדיקת הקריאה בחשבון.
11. מי מחליף טוקן ומי מטפל בשינוי הרשאות.

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

הבחירה בין המסלולים מותנית במה שאומת. מודול ייעודי ב־Make מתאים כשהכיסוי של הפעולה אומת מול החשבון והשדות וההרשאות נבדקו. Make an API Call מתאימה כשההתאמה לשיטה, לשדות ולאימות נבדקה. API ישיר מתאים כשדרישות השליטה והתחזוקה מצדיקות את האחריות הנוספת.

פעולות מסמכים בשני המסלולים וחוזה ציבורי ל־doc/search מתועדים. כל קריאה בחשבון לא נוסתה, ובדיקת התיעוד לא יצרה, ביטלה או שלחה מסמך. התאמת פעולות הלקוח לשדות ולהרשאות, אירועי webhook שמתאימים לתהליך, זכאות המנוי ל־API, כפילויות, ניסיונות חוזרים ועלויות Make עדיין פתוחים.

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

מקורות רשמיים

• iCount, Welcome to the iCount API (נפתח בחלון חדש), נבדק ב־22 באוקטובר 2026.
• iCount, API v3 public index (נפתח בחלון חדש), נבדק ב־22 באוקטובר 2026.
• iCount, API v3 doc method help response (נפתח בחלון חדש), נבדק ב־22 באוקטובר 2026.
• Make, iCount app documentation (נפתח בחלון חדש), עודכן ב־21 באוקטובר 2026 ונבדק ב־22 באוקטובר 2026.