रेकॉर्ड तयार करणे

फॉर्म, आवश्यक फील्ड्स, ड्रॉपडाउनचे पर्याय कुठून येतात आणि डॉक्युमेंटला त्याचा क्रमांक कसा मिळतो.

नवीन नोंदी स्वीकारणाऱ्या सूचीच्या टूलबारवर एक मुख्य बटण असते. ते उघडल्यावर एक फॉर्म दिसतो: ज्यामध्ये लेबल्स असलेली फील्ड्स, आवश्यक फील्ड्स चिन्हांकित केलेली असतात आणि जिथे एखादा नियम लेबलवरून स्पष्ट होत नाही तिथे सूचना दिलेल्या असतात.

• डीफॉल्ट मूल्य असलेले फील्ड नवीन रेकॉर्डमध्ये त्याच मूल्यापासून सुरू होते, त्यामुळे रिकामी जागा कशाप्रकारे सेव्ह केली जाईल हे तुम्हाला दिसते (उदाहरणार्थ, नवीन प्रशिक्षण कोर्स 'सेल्फ-पेस्ड, १ तास' या मूल्यापासून सुरू होतो) आणि सेव्ह करण्यापूर्वी तुम्ही त्यात बदल करू शकता. एडिट केलेल्या जागेला कधीही डीफॉल्ट मूल्य दिले जात नाही.
• रेकॉर्ड सेव्ह करताना, त्याच्या कोड आणि नावाच्या आधी व नंतर असलेल्या जागा काढून टाकल्या जातात, आणि दुसऱ्या रेकॉर्डमध्ये आधीपासून असलेला कोड (कोणत्याही अक्षर-केसमध्ये) नाकारला जातो, ज्यामुळे फील्ड आणि व्हॅल्यूचे नाव ठरते: “QA-TC-02 कोड असलेला प्रशिक्षण कोर्स आधीच अस्तित्वात आहे. वेगळा कोड वापरा.”
• पुष्टीकरणामध्ये रेकॉर्डचे नाव, त्याचा दस्तऐवज क्रमांक (किंवा ते काय आहे) आणि त्याचा कोड (“प्रशिक्षण अभ्यासक्रम QA-TC-06 तयार झाला.”) नमूद केलेला असतो.

आपोआप भरल्या जाणाऱ्या ओळी

मागणीपत्र, खरेदी आदेश, कोटेशन किंवा विक्री आदेशावर, ओळीवरील वस्तू निवडल्यावर तिचे एकक आणि सुरुवातीची किंमत आपोआप भरली जाते: वस्तूचे स्टॉकिंग युनिट, आणि खरेदीसाठी तिची प्रमाणित किंमत (किंवा जिथे सूची किंमत नाही तिथे सूची किंमत), तसेच विक्रीसाठी तिची सूची किंमत. दोन्ही संपादन करण्यायोग्य राहतात. वस्तूमध्ये बदल केल्यास, ते बदल आपोआप बदलले जातात — मात्र तुम्ही तुमचे स्वतःचे मूल्य टाईप केलेले असल्यास, ते तसेच ठेवले जाते.

ड्रॉपडाउनमधील पर्याय कुठून येतात

जेव्हा तुम्हाला आवश्यक असलेले मूल्य उपलब्ध नसते, तेव्हा हा फरक जाणून घेणे महत्त्वाचे आहे. एखादे कॉन्फिगरेशन मूल्य उपलब्ध नसणे हे प्रशासकाचे पाच मिनिटांचे काम आहे. लुकअप मूल्य उपलब्ध नसण्याचा अर्थ असा आहे की, ते ज्या रेकॉर्डकडे निर्देश करते, तो रेकॉर्ड अद्याप तयार झालेला नाही.

प्रत्येक ड्रॉपडाउनमध्ये फक्त तेच पर्याय दिसतात जे रेकॉर्डमध्ये प्रत्यक्षात असू शकतात. सेव्ह करताना नाकारला जाणारा पर्याय मुळातच दिला जात नाही, त्यामुळे यादीतून निवड करणे नेहमीच सुरक्षित असते.

लांब ड्रॉपडाउन शोधणे

आठपेक्षा जास्त पर्याय असलेल्या ड्रॉपडाउनमध्ये फॉर्मवर, कस्टम फील्डवर आणि फिल्टर बारच्या कॉलम निवडकामध्ये शोध घेतला जाऊ शकतो.

• टाईप करायला सुरुवात करा आणि तुम्ही टाईप केलेले पर्याय दिसतील इतकी यादी लहान होत जाईल.
• वर आणि खाली बाण उरलेल्या भागातून पुढे जातात; एंटर दाबल्याने हायलाइट केलेला पर्याय निवडला जातो; एस्केप दाबल्याने काहीही न बदलता यादी बंद होते.
• चौकटीतील × चिन्ह निवड रद्द करते.

लागू झाल्यावरच दिसणारी फील्ड्स

काही रकान्यांना दुसऱ्या उत्तरानंतरच अर्थ प्राप्त होतो आणि ते तेव्हाच दाखवले जातात. जे तुम्हाला भरण्याची आवश्यकता नाही, ते फॉर्मवर नसते.

जेव्हा एखादे मूल्य चुकीच्या स्वरूपात असते

एखाद्या फील्डमध्ये जे मूल्य टाकता येत नाही, त्याला त्या फील्डचे नाव आणि ते फील्ड काय स्वीकारते हे नमूद केले जाते — उदाहरणार्थ "ॲप्लिकेशन: "APL-000015" येथे वैध नाही — ते सूचीमधून एक पर्याय स्वीकारते" — आणि ते फील्ड फॉर्मवर चिन्हांकित केले जाते, जेणेकरून तुम्हाला कोणता रकाना दुरुस्त करायचा आहे हे कळते.

• ईमेल फील्डमध्ये पत्ता टाकला जातो: "हा ईमेल पत्ता वैध नाही. कृपया name@company.com सारखा दुसरा पत्ता टाका".
• फोन किंवा मोबाईल फील्डमध्ये फक्त फोन नंबर टाकला जातो: अंक, +, स्पेस, - ( ) . / ही अक्षरे आणि एक एक्सटेंशन.
• दुसऱ्या रेकॉर्डकडे निर्देश करणारे फील्ड, जसे की नवीन ऑफरवरील 'अर्ज', ही एक पिक लिस्ट आहे: त्याचा क्रमांक टाइप करण्याऐवजी रेकॉर्ड निवडा.

फॉर्मच्या आतील रेषांचे जाळे

हेडर आणि ओळींनी बनलेल्या दस्तऐवजांमध्ये निर्मिती फॉर्ममधील ग्रिड समाविष्ट असतो. ओळी जोडा, प्रत्येक ओळीसाठी खाते किंवा आयटम निवडा आणि तुम्ही टाइप करताच चालू एकूण बेरीज अद्ययावत होते. जोपर्यंत डेबिट आणि क्रेडिट समान होत नाहीत, तोपर्यंत जर्नल सेव्ह होण्यास नकार देईल — ही तपासणी स्क्रीनवर नसून पोस्टिंग सेवेमध्ये होते, त्यामुळे जर्नल जसे आले आहे, तसेच ते कायम राहते.

एखादे क्षेत्र काय घेईल

प्रत्येक फॉर्म आणि लाइन ग्रिडवरील प्रत्येक क्रमांक आणि तारीख, तुम्ही टाइप करत असताना ब्राउझरमध्ये आणि सेव्ह करताना पुन्हा सर्व्हरवर, नियमांच्या एका संचाच्या आधारे तपासली जाते. त्यामुळे रेकॉर्ड कोणत्याही मार्गाने आला तरी - मग तो कन्सोल, इम्पोर्ट, ASK किंवा पब्लिश्ड API असो - तो नियम लागू राहतो. नियम मोडणारे फील्ड लाल रंगाचे होते आणि त्याच्या खाली तो नियम लिहिलेला असतो, आणि जोपर्यंत ती चूक दुरुस्त केली जात नाही तोपर्यंत फॉर्म सेव्ह होत नाही.

नैसर्गिकरित्या चिन्हित असणारे आकडे — जसे की जर्नल रकमा, शिल्लक, तफावत, स्टॉक समायोजन, पुनर्मूल्यांकन, तापमान — त्यांचे चिन्ह कायम ठेवतात. डेटाबेसमध्ये यापैकी सर्वात महत्त्वाचे नियम स्वतःच साठवलेले असतात, त्यामुळे स्क्रीनच्या पुढे गेलेले मूल्यदेखील निर्बंधाच्या नावाऐवजी त्याच साध्या वाक्यासह नाकारले जाईल.

तुम्ही वर निवडलेल्या पर्यायांमुळे निवडी मर्यादित झाल्या आहेत.

दुसऱ्या फील्डवर अवलंबून असलेला ड्रॉपडाउन फक्त त्या फील्डशी संबंधित माहितीच दाखवतो. मागणीपत्रावर (requisition) एखादे स्थान (Location) निवडा आणि 'गोदामात वितरित करा' (Deliver to warehouse) पर्याय निवडल्यास फक्त त्या स्थानावरील गोदामांचीच यादी दिसते; एखादे गोदाम निवडल्यास, 'बिन' (bin) पर्याय निवडल्यास फक्त त्या गोदामातील बिन्सची यादी दिसते. प्रथम गोदाम निवडल्यास, त्याचे स्थान आपोआप भरले जाते. स्थान बदलल्यास, अस्तित्वात नसलेले गोदाम काढून टाकले जाते, त्यामुळे संस्थेकडे नसलेले संयोजन (combination) कोणत्याही रेकॉर्डमध्ये कधीही असू शकत नाही.

• संघटनात्मक साखळी: कंपनी → व्यवसाय विभाग → ठिकाण → गोदाम → साठा, मागणीपत्रे, खरेदी आदेश, दरपत्रके, विक्री आदेश, वितरण, मालाची हालचाल, चक्रगणना आणि गोदामाच्या स्क्रीन्स यांवर आधारित.
• खर्च आणि नफा केंद्रे, ठिकाणे आणि गोदामे ही नोंदीतील स्वतःच्या कंपनी आणि व्यवसाय युनिटमधून येतात. दुसऱ्या युनिटच्या मालकीचे असलेले खर्च केंद्र — उदाहरणार्थ, विद्यापीठाच्या दस्तऐवजावरील रुग्णालयाचे खर्च केंद्र — दोन्हीची नावे नमूद करून नाकारले जाते. अवरुद्ध किंवा बंद केलेले खर्च केंद्र देखील नाकारले जाते.
• निवडलेल्या ग्राहकाकडून आलेला संपर्क; निवडलेल्या पुरवठादाराची साईट, खरेदी आदेश किंवा करार; निवडलेल्या रुग्णाची भेट किंवा काळजी योजना; निवडलेल्या क्लायंटकडून आलेला जॉब ऑर्डर; निवडलेल्या प्रकल्पातील वर्क पॅकेज; निवडलेल्या आयटमचे रूटिंग किंवा बिल ऑफ मटेरियल्स.
• लाइन ग्रिडवर, एखाद्या लाइनचे वेअरहाऊस किंवा बिन त्याच्या वरील डॉक्युमेंटमुळे संकुचित होते.
• जेव्हा वरील पर्यायाशी काहीही जुळत नाही, तेव्हा स्पष्टीकरणाशिवाय रिकामी यादी दाखवण्याऐवजी ते तसे नमूद केले जाते.

रेकॉर्ड कोणत्याही स्क्रीन, इम्पोर्ट किंवा इंटिग्रेशनद्वारे आला असला तरी, सर्व्हर प्रत्येक सेव्हवर तीच चाचणी लागू करतो आणि कंपन्या किंवा व्यवसाय युनिट्स ओलांडणाऱ्या संयोजनास नाकारतो.

इतर नोंदींवर अवलंबून असलेल्या मर्यादा

काही नियम केवळ फॉर्मवरून ठरवता येत नाहीत, कारण ते आधीच काय घडले आहे यावर अवलंबून असतात. तुम्ही सेव्ह करता, पोस्ट करता किंवा मंजूर करता तेव्हा ते तपासले जातात, आणि नकारात मर्यादा काय आहे व ती किती फरकाने चुकली हे सांगितले जाते.

दस्तऐवज क्रमांक

तुम्ही नंबर टाईप करता की प्लॅटफॉर्म तो वाटप करतो, हे प्रत्येक दस्तऐवजाच्या प्रकारानुसार, प्रत्येक कंपनीसाठी असलेले कॉन्फिगरेशन आहे:

• प्रणालीद्वारे निर्मित — प्लॅटफॉर्म त्याला क्रमांक देतो आणि तुम्ही दिलेला क्रमांक नाकारतो.
• हाताने प्रविष्ट केल्यावर — तो नंबर फॉर्मवरील एक अनिवार्य फील्ड बनतो.
• एकतर तुम्ही टाकलेला नंबर जिंकतो; नाहीतर एक नंबर तयार केला जातो.

मास्टर डेटा मॅन्युअल एंट्री (आयटम, पुरवठादार, ग्राहक, कर्मचारी, रुग्ण, मालमत्ता, जीएल खाते) म्हणून आणि ट्रान्झॅक्शन डेटा सिस्टीमद्वारे तयार केलेला असतो. दोन्हीपैकी काहीही बदलता येते. क्रमांक प्रत्येक कंपनीसाठी अद्वितीय असतात, जागतिक स्तरावर नाहीत — प्रत्येक कंपनीची पहिली खरेदी ऑर्डर PO-000001 असते.

हा फॉर्म कंपनीच्या स्वतःच्या सेटिंगनुसार चालतो. जिथे रेंज सिस्टीमद्वारे तयार केली जाते, तिथे नंबर फील्ड विचारले जात नाही: ते फक्त वाचण्यायोग्य (read-only) दाखवले जाते, सेव्ह केल्यावर 'असाइन' (Assigned) असे दिसते आणि सेव्ह केल्यावर आपोआप भरले जाते. जिथे ते मॅन्युअली (हाताने) टाकले जाते, तिथे ते फील्ड आवश्यक असते. जिथे दोन्हीपैकी काहीही नसते, तिथे ते फील्ड ऐच्छिक असते आणि एका रिकाम्या फील्डला क्रमांक दिला जातो. ज्या कंपनीकडे एखाद्या डॉक्युमेंटसाठी अद्याप कोणतीही रेंज नाही, तिला त्या डॉक्युमेंटला पहिल्यांदा क्रमांक देताना, तिच्या पॅरेंट कंपनीकडून (किंवा दुसऱ्या कंपनीकडून) कॉपी केलेली एक रेंज दिली जाते, जिचा काउंटर १ असतो.

नोंद कोणत्या युनिटमध्ये येते

नवीन रेकॉर्ड डीफॉल्टनुसार टॉप बारमध्ये निवडलेल्या बिझनेस युनिटनुसार तयार होतो आणि रेकॉर्डवरील हे युनिट संपादित करता येते. जर तुम्ही बहुतेक वेळा एकाच युनिटमध्ये काम करत असाल, तर तुमच्या प्राधान्यांमध्ये (preferences) त्याला डीफॉल्ट म्हणून सेट करा आणि प्रश्नाचे उत्तर देणे थांबवा.