@שמואל-ש
למרות הנוחות שבדבר
אני דוקא בעד שלא לאפשר את זה
כך יש צורך להכנס לפוסט
ומופיע כמות הצפיות
שזה אינדיקציה רלוונטית לשואל / עונה
@שמואל-ש
למרות הנוחות שבדבר
אני דוקא בעד שלא לאפשר את זה
כך יש צורך להכנס לפוסט
ומופיע כמות הצפיות
שזה אינדיקציה רלוונטית לשואל / עונה
@אבי-203 כתב באימות גוגל בסמס לבעלי טלפון כשר:
בקשר מול גוגל ומשרד התקשורת.
הם שוקלים לאשר לפחות כאשר הסיסמא נכונה למרות שזה כניסה ממקום חדש לבנתיים
אני לא מצפה שהם יאשרו
אלא שהם ישלחו את הקוד בהודעה קולית
[יש לי מספר חשבונות גימייל
ובחלקם אני מקבל את האימות דרך הודעה קולית (בזכות הגדרות ישנות שהיה ניתן להגדיר בזמנו)
ובחלקם תקוע בגלל הנ"ל]
דרך אגב
זה לא רק עניין חרדי
אלא עניין בסיסי של נגישות לכבדי ראיה
@חוקר
שורש הדבר נעוץ באימות הזיהוי
הזיהוי האמיתי והייחודי של הלקוח בחברה ובבתי משפט
הינו הת.ז. / ע.מ. / ח.פ.
(תתאר לך שבצעת העברת בעלות/חשבון דרך שיחה במוקד 103
והינך דובר אידיש-אמריקאית ואמרת ששמך 'גוטשטיין'
הנציגה האדיבה שאיננה שומעת עברית בצורה מלאה
הקלידה את שם משפחתך 'גולדשטיין'
ולא שלמת את חובך
האם לא יוכלו לתבוע אותך בגלל שהשם בחשבונית אינו השם המדויק?)
השם המופיע בחשבונית הינו לצורכי נוחות בלבד
ולכן אותו הם משנים בקלות רבה
הסיפור המרכזי הינו שינוי המספר מזהה
ספציפית אצלך שהע.מ. הינו המספר ת.ז.
שינוי השם אכן הווה פתרון מושלם
אבל במידה ותנסה לשנות את הת.ז. למספר אחר של ח.פ.
תצטרך להביא את כל המסמכים
@dovid
נכון, אם כי יש פה עניין של זמינות, עלות, ונוחות
אינני יודע כמה אנשי הטמעה מקצוענים שמכירים הרבה סוגי מערכות לעומק
ויכולים לעזור לך לשבת ולהגדיר ולסדר את המערכות הגדולות לפי הצרכים שלך
(אנשי הדרכה לתוכנה ספציפית, יש, אבל הם נעולים על המוצר שלהם)
לעומת זאת ישנם בשוק עשרות אלפי מתכנתים/ות
שיש להם ידע מעולה בתכנות (האם יש הבדל בין מומחה לאקסס שבונה לך מערכת, או מתכנת שבונה לך בריאקט+ MYSQL)
הקלות והגמישות של מתכנת שיכול לגשר לך על הפער בין התוכנה החשבונאית (פריורטי / חשבשבת / ריווחית)
לבין הצרכים והאפיונים של התהליכי העבודה שלפעמים ייחודיים רק אצלך
אם ניקח את הדוגמא שלי של הניהול סניפים
ברור שניתן לבצע ניהול של זה בתוכנה חשבונאית (שזה מה שאני עושה כיום)
אבל שאני רוצה לקבל התראה מייל אוטומטי
חודש לפני פקיעת חוזה שכירות
או שבועיים לפני פקיעת הטסט
אני כבר צריך די להזיע בשביל להגיע לתוצאות האלו
במקום העצלן והקטן שלי
יותר נוח ליישם השלמה ואינטגרציה למערכת הגדולה
שתהיה פשוטה וקלה רק לדברים האלו
ואז אני מקבל מעלה נוספת
שכל עובד חדש שמגיע, יכול לתפעל ולהבין בקלות
כי זה מוצג בצורה נגישה ומובנת
(זה כמו ההבדל בין המערכות קופה האישיות/מסופונים שיש כיום בסופר-מרקטים,
לעומת התוכנת קופה הותיקה שעל מחשב המוכר
שאת המוכר אתה צריך להעביר הדרכה והכשרה קצרה,
ובמערכת הלקוח - בגלל שאין אפשריות ובגלל שהכל פשוט, זה זורם)
--
נ.ב.
פריוריטי זה שלד מערכתי שכמעט כל מי שמשתמש בו בנפח מעל X
מבצע פיתוחים בעצמו, שזה שוב זהה לפיתוח חיצוני
@yossiz כתב בעזרה בהגדרות חומת אש לשרת:
זה הרשימה המלאה?
נטפרי למשל לא מופיעים שם (1,2)
וכן הכתובות הקבועה/פרטית שלי (מתחיל ב89.208)
@OdedDvir
בהמשך לדבריך
רק להאיר זווית נוספת
יש לחלק בין מסד נתונים של מידע אינפורמטיבי
לבין מידע עסקי
אני עובד ברשת סיטונאית וקמעונית גדולה
ויושב על מגוון מערכות מידע של החברות תוכנה הנחשבות והנפוצות בשוק
ופעמים רבות אני יושב מתוסכל עד עמקי נשמתי
למה אין תיעוד ושמירת היסטוריה לכל שינוי
(דוגמא אמיתית: לא נשמר היסטוריית מחיר עלות
והדוחות בתוכנה מבוססים על ההפרש בין המחיר במסמך המכירה למחיר עלות מכרטיס המוצר
ואז שמגיע שנות האינפלציה ויש שינוי במחיר עלות,
אתה שובר ת'ראש בקיר איך להוציא דוחות על רבעונים קודמים)
ה-מ-ו-ן מידע עסקי מתפספס ונמוג בעקבות חוסר בנתונים היסטוריים
כולל ובפרט כל מיני שינויים במערכת (החל מהגדרות, וכלה באכמ"ל..)
שבסופו של יום
אם היה תיעוד פשוט של רשומות לפני ואחרי החיים היו יותר קלים
יש לי אינספור דוגמאות חיות למידע שחסר
(גילוי נאות: מכאן מגיע הפרנויה שלי במערכות שאני כותב (מידע עסקי)
לשמור ולתעד את כל הרשומות ששונו, למה? כי יבוא יום שיהיה לזה משמעות)
כך שהסברא שנפח הנתונים עשוי לגדול בצורה מעריכית הינו נכון
ולכן לדוגמא במסד נתונים של פורום כלשהו
יש פחות הגיון לשמור כל שינוי של המשתמש
כי מה שחשוב זה הפוסט המוצג לגולש
ופחות רלוונטי ויש מה לעשות עם ערימת הטיוטות של המשתמש
אבל כאשר מדובר בנתונים עסקיים
גם כמות השינויים פר רשומה בדר"כ הינה פחותה
ואם יש שינוי - אז זה נתון חשוב שיש לו חשיבות לשמירה
(גם שדה טלפון וכתובת של לקוח, במידה וזה לא משתמש באתר
אלא לקוח שרכש ממך בהקפה, יכול להיות מידע מאוד רלוונטי כאשר הוא 'פורח' ואתה מנסה לאתר קצה חוט של איש קשר קודם)
@OdedDvir כתב בmssql - התייעצות כיצד לשמור שינויי עריכה בטבלאות:
במקרה האחרון מסתמא הייתי רושם את התיעוד ל-db אחר.
הסיבה היא שלרוב צד ה-db הוא צוואר הבקבוק במערכת, ולתיעוד ב-SQL יש מחיר גבוה.
מנסיון מהצד של משתמש במערכות שרשומות כמות רשומות נאה מאוד ביום
תמיד חפשתי דרך לשלוח טקסט מודגש/מעוצב בשורת הנושא (דחוף!!!!...)
פתאום נפל לי האסימון
שכמו שניתן לשלוח אימוג'י בשורת הנושא
ניתן גם לשלוח ככה טקסט עם תווי Unicode
אומנם בעברית התמיכה חלקית מאוד
אבל זה בהחלט עוזר לשפר את ההבעה
בהצלחה!
--
אהה
ואם מצאת 'ממיר' מוצלח או דרך נוספת - תשתף
ע"מ לקבל את המירב מהתשובה
אמנע הפעם מלהציג את לבטי מחשבותי
אלא אשאל 'שאלה פתוחה'
מסד נתונים: MS-SQL
כיצד הינך מנהל רישום היסטוריית שינויי עריכה לנתוני הטבלאות (DELETE
,UPDATE
,INSERT
)
אני מעוניין לרכוש דומיין לכתובת שאמורה להיות פרטית
(עומק כוונתי שזה לא אתר שפתוח לציבור, ולהופיע באינדקוס כלשהו, אלא אתר נעול לשימוש פנימי של עובדי המפעל)
@dovid כתב בDB של הזמנות:
לעיתים כן בוחרים לשמור בטבלה נפרדת כזה ערך, או בגלל שיקולי ביצועים (למשל את יתרת החשבון בעו"ש יש מצב שלא רוצים לחשב כל פעם מיום פתיחת החשבון
כתוספת:
כפי שראיתי בעבר במסדי נתונים של אי אלו תוכנות
הם שומרים גם את הסה"כ של המסמך בטבלת המסמך (בנידון דידן: עמודה עם ערך סה"כ הזמנה, בטבלת ההזמנות)
כך זה מאפשר להריץ דוחות על נתונים ללא צורך בתתי שאילתות
[ומאפשר לבדוק האם מישהו נגע בנתונים בטבלה המקושרת....]
@yossiz כתב ברכיב 'בורר מספרים' בעיצוב של 'בורר זמן':
האם רצית דוקא שני הבוררים באלמנט אחד?
לא,
בשני בוררים נפרדים
--
תודה על הקישורים, חוקר אותם
@Whenever כתב באתגר: יצירת לוח סילוקין לפי לוח שפיצר - לפי ריבית הפריים הרלוונטית לתאריך ההחזר:
לא היה לי עדיין את הפנאי ללמוד איך זה עובד, למרות שזה נראה מרתק:)
@yossiz כתב במיקום שמירת קבצי תוכנה:
הפתרון שאתה מציין (__COMPAT_LAYER=RUNASINVOKER) מריץ את התוכנה כמשתמש רגיל לא כמנהל, זה שימושי עבור תוכנות שחושבים שהם צריכים לרוץ כמנהל ולמען האמת הם רצים טוב בלי זה, אבל במקרה הזה שבאמת צריך הרשאות מנהל זה לא יעזור
כתבתי מנסיון אישי
אצלינו עובדים על שרת וינדוס סרבר עם ניהול הרשאות אגרסיבי (למשתמשים רגילים אין גישה לכל כונן C)
ויש לנו תוכנה בProgram Files שמצריכה הרשאות קריאה-כתיבה לכונן c
וכך אפשרנו ספציפית לכל המשתמשים להפעיל אותה כמנהל
לא עברתי כעת על כל הקומבינציה
כך שיתכן שיש פה עוד פרט כלשהו (ולכן שמתי בתשובתי את החיפוש בגוגל, ולא כתשובה בפני עצמה)
אבל זה אפשרי
ע"מ לשפר ביצועים באקסל
(יותר מדוייק, למנוע איטיות/תקיעות...)
בנוסחאות רגילות
ניתן לבצע בנוסחאות>אפשריות חישוב>ידני
ואח"כ לבצע בנוסחאות>אפשריות חישוב>חשב כעת/חשב גליון
וזה אכן פתרון יעיל
שמונע מכל שינוי ערך בתא, לתקוע את הגליון
האם יש פתרון דומה ל'עיצוב מותנה'?
משהו שאוכל לשמור על כללי העיצוב הקיימים
להשהות
ואחרי עדכון הנתונים, לחשב את העיצוב מחדש
מכיר את זה שאתה מעוניין להעביר למן-דהו
שרשור מיילים
ובביצוע 'העברה' דרך האפשרות המובנית בגיימיל
כל שרשור ההודעות מופיע בסדר כרונולוגי הפוך (מהודעה האחרונה > לראשונה)
מה שיוצא כמשהו שקשה לקריאה והבנה (בפרט ל...)
אני מעוניין לבצע העברת שרשור מיילים
בצורה קריאה וברורה
ובסדר הכרונולוגי
איך ניתן לבצע את זה?
--
עריכה:
בפרט שניתן לבצע 'הדפסה' מראש השרשור
ואז זה מוצג תקין
רק שזה בקובץ PDF
ואני מעוניין לקבל את זה בגוף המייל
@חנון-המרבה כתב בתוכנה לניהול תשלומים:
יש לך משהו ספיציפי שאתה יודע ?!
לפי תיאורך
יתכן שמספיק לך 'אקסל לניהול תזרים' (יש ה-מ-ו-ן בגוגל, תחפש)
הכי בשל ואיכותי וחינמי
למה שבקשת בשאלה המקורית זה האקסל של 'אוטוגמח' (autogmach@gmail.com)
כי הוא מאפשר לך גם הזנת מספר תשלומים ודוחות וכו'
אני רוצה לפרסם קישור להורדה של קובץ תוכנה (exe)
אבל גם מעוניין שאוכל לעדכן ולהחליף את הקובץ
ללא שינוי בכתובת הקישור שפרסמתי
אשמח למידע באיזה מהפלטפורמות הקיימות
ניתן לעלות קובץ כזה, ולקבל קישור קבוע לפי שם הקובץ
(שגם אם אמחק את הקובץ הראשון, ואעלה קובץ שני באותו שם, הקישור יעבוד רגיל)
@חוקר כתב בניהול תקבולים ממשלם אחד לכמה סניפים:
הוא יישמח לדעת בדיוק כמה עלה לו התוספת לסניף הזה וכמה הוא עדיין חייב על זה
למיטב הבנתי/ידיעתי/נסיוני
מומלץ לפצל את זה לשלוש נושאים
בהפקת דוחות פר X
הנקודה הרלוונטית זה סעיף החיוב
גם מצידך שתרצה לבחון כמה הינך מרוויח מכל מודול
וגם מצד הלקוח שרוצה לבדוק כמה הוציא בעבור כל סניף
וזה כמובן אתה יכול להוציא כבר כעת חיובים עם פירוט מסודר לפי הסניף
כמה הלקוח חייב
ממה שהבנתי: זה אתה יכול לבדוק גם כעת
כמה הלקוח חייב על זה
זה אכן מצריך שיוך מסודר של כל תשלום לחיוב
ומצריך אופרציה בפני עצמה
הערה כללית
לגבי סגירת התשלום/יתרת חוב
נקודת המוצא היא: שכל חיוב שהופק יש לשלם (או לזכות)
ולכן לא עוקבים בדוחות על התשלומים כסעיף הוצאה
אלא ההתייחסות אליה זה כ'טיפול בחובות' / סגירת כרטיסים
וזה משהו גלובלי פר הלקוח
כל זמן שאין משמעות לסגירת גבייה מול תת לקוח / סעיף חיוב