अशी कोणतीही बिल्ड फेज नाही, ज्यात ग्राहक डोळे झाकून वाट पाहतो. प्रत्येक वर्किंग सेशन ग्राहकाच्या स्वतःच्या टेनंटमध्ये, ग्राहकाच्या सॅम्पल डेटासह प्रत्यक्ष स्क्रीनवर, एकाच लूपचे अनुसरण करते: फिट लेजर लाइन दाखवा, ती लाइव्ह आणि नो-कोड पद्धतीने कॉन्फिगर करा, ग्राहक बदल घडवून आणतो, सॅम्पल डेटासह त्याची पडताळणी करतो, त्याची नोंद करतो आणि लाइनवर टिक करतो.
जर ग्राहक सत्रात नसेल, तर सत्र होत नाही. T-14 नुसार मुख्य वापरकर्त्यानेच संचालन केले पाहिजे; जर TRANXACT T-13 वर अजूनही कीबोर्डवर असेल, तर स्टँडअपमध्ये हा एक अवलंबन धोका म्हणून मांडा.
सात दिवस, व्यवहारांपूर्वीची रचना (प्रस्तावित डिफॉल्ट)
| टी-डे | लक्ष केंद्रित करा | कॉन्फिगर केलेले |
|---|---|---|
| टी-१७ | रचना | संस्था, लेखांचे तक्ते, आर्थिक दिनदर्शिका, परिमाणे |
| टी-१६ | पैसा आणि अनुपालन | चलन आणि परकीय चलन, कर संहिता, दस्तऐवज क्रमांक, बँका |
| टी-१५ | लोक आणि प्रवेश | भूमिका आणि परवानग्या, SSO गट, मंजुरी पदानुक्रम |
| टी-१४ | मास्टर डेटा | ग्राहक, विक्रेते, वस्तू, कर्मचारी — एक्स्ट्रॅक्ट्समधून मोठ्या प्रमाणात तयार करण्यासाठी ASK |
| टी-१३ | प्रवाह आणि नियम | मंजुरी प्रवाह, पोस्टिंग, जुळवणी आणि किंमत निश्चितीचे नियम |
| टी-१२ | मॉड्यूल तपशील | CRM पाइपलाइन, पुरवठा साखळी खर्च, HR वेतन घटक, मॉड्यूल टॉगल |
| टी-११ | एकीकरण आणि रांगा | एपीआय क्लायंट्स, बँक / कर / वेतनपट एंडपॉइंट्स, प्रत्येक भूमिकेनुसार रांगा |
फिट लेजरमध्ये फरक असला तरीही क्रम कायम ठेवा: 'स्ट्रक्चर फर्स्ट' म्हणजे T-15 पासून मायग्रेशन मॅपिंग सुरू होऊ शकते, आणि ज्या GL मॅपिंगवर बाकी सर्व काही अवलंबून असते ते मास्टर डेटाच्या आधी अस्तित्वात असते.
ASK कष्टाचे काम करतो
एका एक्स्ट्रॅक्टमधून विभागानुसार पेमेंटच्या अटींसह २,४०० ग्राहक मोठ्या प्रमाणात तयार करा; माल स्वीकारणाऱ्या वेअरहाऊसच्या कॉस्ट सेंटरनुसार फ्रेट स्प्लिटसाठी पोस्टिंग नियमाचा मसुदा तयार करा; एक AP क्लर्क तयार करा जो १०,००० पेक्षा जास्त इनव्हॉइस नोंदवू शकतो पण मंजूर करू शकत नाही; फॉलबॅक अप्रूव्हरशिवाय प्रत्येक मंजुरी प्रवाहाची यादी करा. ASK हे मानवी क्लिकप्रमाणेच त्याच परवानग्या आणि ऑडिट लॉग अंतर्गत करते, आणि ओळ टिक करण्यापूर्वी मुख्य वापरकर्ता प्रत्येक निकालाचे पुनरावलोकन करतो.
कोडसारख्या वाटणाऱ्या विनंत्या
| आम्हाला गरज आहे...” | त्याचे उत्तर देणारी रचना |
|---|---|
| आमची अद्वितीय मंजुरी प्रक्रिया | रक्कम, घटक आणि परिमाण नियमांसह बहु-स्तरीय मंजुरी प्रक्रिया |
| सानुकूलित इनव्हॉइस लेआउट | प्रत्येक घटकासाठी फील्ड्स, लोगो आणि भाषेसह एक दस्तऐवज टेम्पलेट |
| अस्तित्वात नसलेले क्षेत्र | कोड-रहित सानुकूल फील्ड, जे अहवाल आणि नियमांमध्ये वापरता येते. |
| आमचा वारसा अहवाल जसाच्या तसा | रिपोर्ट बिल्डर किंवा डॅशबोर्ड — मांडणीला आव्हान द्या; अनेकदा "गरज नसते" |
| बँक किंवा एमईएससाठी एक इंटरफेस | मर्यादित भूमिका असलेला एक API क्लायंट; आवश्यकतेनुसार फाईलची देवाणघेवाण. |
| X घडल्यावर सूचना मिळते | भूमिका-जागरूक कृती रांग नियम |
घड्याळावरील एकीकरण (प्रस्तावित डीफॉल्ट)
T-18 पर्यंत यादी आणि मालक; T-13 पर्यंत API क्लायंट आणि भागीदार चाचणी एंडपॉइंट्स; T-10 पर्यंत एकीकरण चाचण्या (पेरोल T-9, BI T-6; T-17 पर्यंत SSO, कारण सरावासाठी त्याची गरज आहे); T-3 ला ड्राय रनमध्ये एंड-टू-एंड; T-0 ला प्रोडक्शन स्विच.
जो भागीदार T-13 द्वारे टेस्ट एंडपॉइंट देऊ शकत नाही, तो एका मॅन्युअल अंतरिम पायरीसह ते इंटिग्रेशन T-Plus वर हलवतो — ज्यात मॅन्युअल बँक फाईल अपलोड, फायनान्सद्वारे पोर्टल अपलोड आणि जर्नल इम्पोर्टसह लेगसीमध्ये पेरोल रन यांचा समावेश असतो. SSO मध्ये कोणतीही अंतरिम पायरी नसते: सरावासाठी ते आवश्यक असते.
कॅल्डरवुडची बँक आपला टेस्ट एंडपॉइंट वेळेवर उपलब्ध करून देते; T-13 ला सुद्धा त्यांच्या टॅक्स पोर्टलचा सँडबॉक्स दिला जात नाही. टॅक्स इंटिग्रेशन ही एक T-Plus लाइन बनते, आणि फायनान्स विभाग पहिल्या काही आठवड्यांसाठी पोर्टलवर ई-इनव्हॉइसेस हाताने अपलोड करतो — ज्याची इतर सर्व गोष्टींप्रमाणेच T-1 ला तालीम केली जाते.
हे वापरून पहा T-12 वर एक प्रमुख वापरकर्ता व्हेंडर-इनव्हॉइस स्क्रीनवर जुन्या सिस्टीममध्ये असलेले एक फील्ड दाखवण्यास सांगतो. हा कोड आहे का?
नाही — हे फॉर्मवरील एक नो-कोड कस्टम फील्ड आहे, जे रिपोर्ट्स आणि रूल्समध्ये वापरता येते. याला एक फिट लेजर लाइन मिळते, मुख्य वापरकर्ता चालवत असलेल्या सेशनमध्ये ते कॉन्फिगर केले जाते, सॅम्पल डेटासह सत्यापित केले जाते, कॉन्फिगरेशन वर्कबुकमध्ये लॉग केले जाते आणि टेस्ट प्लॅनमध्ये त्याची कॉन्फिगरेशन तपासणी केली जाते.