- संसाधन: खरीदारी के लिए उपलब्धता
- संसाधन
- दोहराव
- ScheduleException
- DurationRequirement
- SchedulingRuleOverrides
- ConfirmationMode
- तरीके
संसाधन: उपलब्धता
व्यापारी/कंपनी/कारोबारी की सेवा के लिए उपलब्धता स्लॉट, जिसमें समय और स्पॉट की संख्या दिखती है.
जेएसओएन के काेड में दिखाना |
---|
{ "startTime": string, "duration": string, "spotsTotal": string, "spotsOpen": string, "availabilityTag": string, "resources": { object ( |
फ़ील्ड | |
---|---|
startTime |
अपॉइंटमेंट स्लॉट के शुरू होने का समय. RFC3339 यूटीसी "ज़ुलु" फ़ॉर्मैट में एक टाइमस्टैंप, जिसमें नैनोसेकंड रिज़ॉल्यूशन और नौ फ़्रैक्शनल अंक तक हो सकते हैं. उदाहरण: |
duration |
अपॉइंटमेंट स्लॉट की अवधि सेकंड में अवधि, जिसमें नौ भिन्नात्मक अंक हो सकते हैं और जो ' |
spotsTotal |
इस उपलब्धता के कुल स्पॉट और खुले स्पॉट की संख्या. उदाहरण:
ध्यान दें: अगर नीचे दिए गए, उपलब्धता कंप्रेस करने के फ़ॉर्मैट का इस्तेमाल करके अनुरोध भेजे जाते हैं, तो इन दो फ़ील्ड का अनुमान लगाया जाएगा.
|
spotsOpen |
खाली जगहों की संख्या. |
availabilityTag |
इस उपलब्धता स्लॉट की पहचान करने के लिए एक वैकल्पिक स्ट्रिंग. सेट करने पर, इसे अपॉइंटमेंट बुक/अपडेट/रद्द करने के अनुरोधों में शामिल किया जाएगा. |
resources |
जब सेवा में अलग-अलग तरह के स्टाफ़ सदस्य या कमरे शामिल होते हैं, तब उपलब्धता की इस जगह को दूसरे लोगों से अलग करने के लिए, वैकल्पिक संसाधनों का इस्तेमाल किया जाता है. उदाहरण के लिए, एक ही योगा क्लास, जिसमें दो दो ट्रेनर हों:
|
paymentOptionId[] |
पेमेंट के विकल्पों के बारे में बताने वाले आईडी की सूची, जिनका इस्तेमाल इस स्लॉट के पेमेंट के लिए किया जा सकता है. पेमेंट के असल विकल्प, व्यापारी/कंपनी/कारोबारी के लेवल पर तय किए जाते हैं और इन्हें कई व्यापारियों/कंपनियों/कारोबारियों के साथ भी शेयर किया जा सकता है. यह फ़ील्ड, सेवा मैसेज में दिए गए सभी payment_option_ids को बदल देता है. इसी तरह, यहां बताए गए pay_option_ids का, सेवा मैसेज में मौजूद होना ज़रूरी नहीं है. हालांकि, इसे व्यापारी/कंपनी के लेवल पर तय किया जाना चाहिए. |
recurrence |
उपलब्धता के लिए बार-बार होने की जानकारी, जो एक से ज़्यादा शुरुआत के समय दिखाती है. दोहराव में एक कामकाजी दिन के अपॉइंटमेंट शामिल होने चाहिए. |
scheduleException[] |
वे समय जब इस सेवा को शेड्यूल नहीं किया जा सकता. शेड्यूल अपवाद मैसेज की संख्या सीमित करने के लिए, साथ में दिए गए अपवादों को जोड़ें. |
deposit |
इस उपलब्धता के लिए, रकम जमा करना ज़रूरी नहीं है. अगर सर्विस डिपॉज़िट तय किया गया है, तो सर्विस डिपॉज़िट को बदलता है. |
noShowFee |
उपलब्ध होने पर, शो का शुल्क नहीं लगेगा. अगर सेवा न दिखाने का शुल्क दिया गया हो, तो इस सेवा को बदल देता है. |
requireCreditCard |
यह बताता है कि उपलब्धता के इस स्लॉट को बुक करने के लिए उपयोगकर्ता को क्रेडिट कार्ड देना ज़रूरी है या नहीं. अगर वैल्यू को सेट नहीं किया जाता है, तो सेवा के लेवल पर वैल्यू सेट करने पर, वह उससे इनहेरिट की जाती है. (ज़रूरी नहीं) |
ticketTypeId[] |
इससे पता चलता है कि इस स्लॉट के लिए कौनसे टिकट टाइप इस्तेमाल किए जा सकते हैं. अगर नीति सेट नहीं है, तो पैरंट सेवा के तहत उपलब्ध सभी तरह के टिकट, इस स्लॉट के लिए उपलब्ध होंगे. ध्यान दें कि इस फ़ील्ड की वैल्यू, पैरंट सेवा में तय होनी चाहिए. उदाहरण:
हफ़्ते के कामकाजी दिनों में इन्वेंट्री दिखाने के लिए:
यह बताने के लिए कि इस टाइम स्लॉट के लिए तीनों टिकट टाइप उपलब्ध हैं, (ज़रूरी नहीं) |
durationRequirement |
स्लॉट की अवधि और/या खत्म होने का समय दिखाने की शर्त. अगर स्लॉट उपलब्ध नहीं है, तो इस फ़ील्ड को अनदेखा कर दिया जाएगा. 'क्या-क्या करें' वर्टिकल में इस्तेमाल नहीं किया गया. (ज़रूरी नहीं) |
schedulingRuleOverrides |
उपलब्धता शेड्यूल करने के नियम. अगर फ़ील्ड में जानकारी अपने-आप भर जाती है, तो वे सेवा के लेवल पर शेड्यूल करने के नियमों पर लागू होने वाले शेड्यूल से जुड़े नियमों को बदल देंगी. |
confirmationMode |
बुकिंग की उपलब्धता की पुष्टि करने वाला मोड. इसका इस्तेमाल किया जाएगा. पुष्टि करने वाले मोड के साथ बुकिंग की उपलब्धता की पुष्टि करने की कोशिशों की तुरंत पुष्टि या अस्वीकार की जानी चाहिए. पुष्टि करने वाले मोड के साथ, उपलब्धता के लिए बुकिंग बनाने की कोशिशों को तुरंत अस्वीकार किया जाना चाहिए या उनकी स्थिति 'मंज़ूरी बाकी है' के तौर पर सेट की जानी चाहिए. |
संसाधन
संसाधन का इस्तेमाल, उपलब्धता स्लॉट को एक-दूसरे से अलग करने के लिए किया जाता है. ऐसा तब किया जाता है, जब सेवा में अलग-अलग स्टाफ़ सदस्य या रूम शामिल होते हैं. अलग-अलग संसाधन होने पर, एक ही सेवा और समय अंतराल के लिए कई स्लॉट एक साथ मौजूद हो सकते हैं.
जेएसओएन के काेड में दिखाना |
---|
{ "staffId": string, "staffName": string, "roomId": string, "roomName": string, "partySize": integer } |
फ़ील्ड | |
---|---|
staffId |
सेवा देने वाले स्टाफ़ के सदस्य के लिए वैकल्पिक आईडी. इस फ़ील्ड पर, सभी व्यापारियों/कंपनियों/कारोबारियों, सेवाओं, और खरीदारी के लिए उपलब्धता के रिकॉर्ड में, स्टाफ़ के सदस्य की पहचान की जाती है. इसे समय के साथ स्थिर बनाए रखना होगा, ताकि पुरानी बुकिंग से जुड़ी जानकारी मिल सके. अगर स्टाफ़ का नाम मौजूद है, तो यह फ़ील्ड होना चाहिए. |
staffName |
सेवा देने वाले स्टाफ़ के सदस्य का नाम देना ज़रूरी नहीं है. यह फ़ील्ड, बुकिंग करने वाले उपयोगकर्ताओं को दिखेगा. साथ ही, यह ओपेक आइडेंटिफ़ायर की जगह ऐसा होना चाहिए जिसे इंसान पढ़ सकें. स्टाफ़ आईडी मौजूद होने पर यह फ़ील्ड मौजूद होना चाहिए. |
roomId |
उस कमरे के लिए एक वैकल्पिक आईडी जहां सेवा मौजूद है. इस फ़ील्ड की मदद से, सभी व्यापारियों/कंपनियों/कारोबारियों, सेवाओं, और खरीदारी के लिए उपलब्धता के रिकॉर्ड के हिसाब से कमरे की पहचान की जाती है. इसे समय के साथ स्थिर बनाए रखना होगा, ताकि पुरानी बुकिंग से जुड़ी जानकारी मिल सके. अगर RoomName मौजूद है, तो यह फ़ील्ड मौजूद होना चाहिए. |
roomName |
उस कमरे के लिए एक वैकल्पिक नाम जहां सेवा मौजूद है. यह फ़ील्ड, बुकिंग करने वाले उपयोगकर्ताओं को दिखेगा. साथ ही, यह ओपेक आइडेंटिफ़ायर की जगह ऐसा होना चाहिए जिसे इंसान पढ़ सकें. (ज़रूरी नहीं, लेकिन रूम आईडी मौजूद होने पर) डाइनिंग के दौरान, कमरे का नाम सिर्फ़ बार या बाहर खुले में बैठने की जगह (पैटियो) के लिए इस्तेमाल किया जाना चाहिए. इसका इस्तेमाल, तय कीमत वाले मेन्यू, खास गतिविधियों या कमरे के अलावा कोई दूसरी कीमत (जैसे कि बुकिंग या डिनर) के लिए नहीं किया जाना चाहिए. हमारी सलाह है कि बैठने की डिफ़ॉल्ट जगह के साथ कोई कमरा न जुड़ा हो. |
partySize |
यह सिर्फ़ डाइनिंग के लिए लागू होता है: पार्टी का साइज़, जिसमें इस टाइम स्लॉट के दौरान लिया जा सकता है. एक रेस्टोरेंट को एक ही समय के लिए कई स्लॉट के साथ जोड़ा जा सकता है, जिसमें हर एक अलग पार्टी का आकार तय करता है, अगर उदाहरण के लिए 2, 3 या 4 लोग बुकिंग के साथ बैठ सकते हैं. |
बार-बार होने वाला
बार-बार होने वाले मैसेज का इस्तेमाल करना ज़रूरी नहीं है. हालांकि, इनकी मदद से, उपलब्धता स्लॉट को लगातार दोहराया जा सकता है. आम तौर पर, वे दिन के काम का शेड्यूल दिखाते हैं. इसके बाद,ScheduleSchedule की सुविधा से जुड़े मैसेज का इस्तेमाल, कामकाजी दिन में बुक की गई या उपलब्ध न होने वाली समयसीमाओं को दिखाने के लिए किया जाता है.
ज़रूरी बातें:
- उपलब्धता स्लॉट या बार-बार होने की वजह से एक जैसे स्लॉट नहीं बनाने चाहिए. अगर आईडी, startTime, अवधि, और संसाधन मेल खाते हैं, तो स्लॉट को एक जैसा माना जाता है.
- किसी एक सेवा के स्लॉट में मानक उपलब्धता फ़ॉर्मैट और दोहराव को आपस में न मिलाएं. बार-बार होने वाले अपॉइंटमेंट की सुविधा देने वाले व्यापारियों/सेवाओं को फ़ायदा मिलता है. यह स्टैंडर्ड फ़ॉर्मैट, उन कारोबारियों या सेवाओं के लिए है जिनके लिए नियमित रूप से क्लास शेड्यूल की जाती हैं.
- पुनरावृत्ति 24 घंटे से ज़्यादा नहीं होनी चाहिए.
जेएसओएन के काेड में दिखाना |
---|
{ "repeatUntil": string, "repeatEvery": string } |
फ़ील्ड | |
---|---|
repeatUntil |
ज़्यादा से ज़्यादा यूटीसी टाइमस्टैंप, उपलब्धता को दिखाता है. RFC3339 यूटीसी "ज़ुलु" फ़ॉर्मैट में एक टाइमस्टैंप, जिसमें नैनोसेकंड रिज़ॉल्यूशन और नौ फ़्रैक्शनल अंक तक हो सकते हैं. उदाहरण: |
repeatEvery |
लगातार उपलब्धता वाले स्लॉट के बीच के समय को तय करता है. उदाहरण: 20 मिनट की अवधि, हर 30 मिनट में दोहराने, सुबह 9:00 बजे शुरू होने का समय, और सुबह 11:00 बजे तक दोहराने की सुविधा के साथ सुबह 9-9:20 बजे, सुबह 9:30 से 9:50 बजे, 10 से 10:20 बजे, सुबह 10:30 से 10:51.5 बजे, सुबह 10:30 से 10:50 बजे तक के स्लॉट मिलेंगे: (ज़रूरी) सेकंड में अवधि, जिसमें नौ भिन्नात्मक अंक हो सकते हैं और जो ' |
ScheduleException
शेड्यूल अपवाद मैसेज, कामकाजी दिन में बुक की गई/उपलब्ध नहीं है समय सीमाएं दिखाते हैं, जो ऊपर बताए गए बार-बार होने के अपवाद हैं. टाइम स्लॉट बुक होते ही, अपवादों की सूची अपडेट की जानी चाहिए, ताकि उन नई समयसीमाओं के बारे में पता चल सके जो उपलब्ध नहीं हैं. दोहराव को संशोधित नहीं किया जाना चाहिए.
जेएसओएन के काेड में दिखाना |
---|
{
"timeRange": {
object ( |
फ़ील्ड | |
---|---|
timeRange |
अपवाद की समय सीमा. बार-बार होने वाले लेन-देन के हिसाब से, इस समयसीमा के खत्म होने की तारीख को ओवरलैप करने वाले स्लॉट को, उपलब्ध नहीं माना जाएगा. उदाहरण: अगर दोहराव 20 मिनट की अवधि, 30 मिनट के लिए दोहराने, सुबह 9:00 बजे शुरू होने का समय, और सुबह 11:00 बजे तक दोहराने की अवधि तय करता है, तो 9:45 बजे से 11:00 बजे तक टाइमरेंज के साथ शेड्यूल अपवाद, सुबह 9:30 से सुबह 9:50 बजे, सुबह 10 से 5 बजे से 10:10:20 बजे तक उपलब्ध नहीं होगा ध्यान दें कि समयसीमा पूरी न होने की वजह से, सुबह 11 बजे के स्लॉट पर कोई असर नहीं पड़ेगा. |
DurationRequirement
इस ईनम से पता चलता है कि अनुरोध किए गए स्लॉट के कुल समय/खत्म होने के समय को स्वीकार करने या देखने के लिए, उपयोगकर्ता को किन शर्तों का पालन करना होता है.
Enums | |
---|---|
DURATION_REQUIREMENT_UNSPECIFIED |
खत्म होने के समय की जानकारी नहीं दी गई है. यह डिफ़ॉल्ट रूप से होता है. |
DO_NOT_SHOW_DURATION |
उपयोगकर्ता को खत्म होने का समय नहीं दिखाया जाता है. |
MUST_SHOW_DURATION |
अपॉइंटमेंट लेने से पहले, उपयोगकर्ता को खत्म होने का समय दिखाया जाना चाहिए. |
SchedulingRuleOverrides
उपलब्धता लेवल को शेड्यूल करने के नियम.
जेएसओएन के काेड में दिखाना |
---|
{ "lastBookableSec": string, "firstBookableSec": string, "lastOnlineCancellableSec": string } |
फ़ील्ड | |
---|---|
lastBookableSec |
वह आखिरी समय (सेकंड में) जब यह स्लॉट बुक किया जा सकता है. इस टाइमस्टैंप को स्लॉट के शुरू होने के समय से पहले का होना चाहिए (अगर उपयोगकर्ता शुरुआत के समय के बाद बुकिंग कर पाएं, तो सेवा स्तर Schedule Schedule ScheduleSchedules.min_booking_before_end_time का इस्तेमाल करें). अगर यह मौजूद है, तो संबंधित सेवा के समय-निर्धारण नियमों के min_booking_buffer में तय किसी भी चीज़ को ओवरराइड कर देगा. |
firstBookableSec |
पहली बार (सेकंड में) जब यह स्लॉट बुक किया जा सकता है. यह टाइमस्टैंप, स्लॉट के startSec या अगर lastBookableSec तय किया गया है, उससे पहले होना चाहिए. |
lastOnlineCancellableSec |
अगर यह नीति सेट हो जाती है, तो यह आखिरी समय (Unix epoch के बाद के सेकंड में) तय होगा और 'Google से रिज़र्व' से इस खास अपॉइंटमेंट स्लॉट को रद्द किया जा सकता है. यह फ़ील्ड, सेवा स्तर के रद्द करने के किसी भी नियम को बदल देगा. (ज़रूरी नहीं) |
ConfirmationMode
बुकिंग की उपलब्धता की पुष्टि करने के लिए इस्तेमाल किए जाने वाले मोड.
Enums | |
---|---|
CONFIRMATION_MODE_UNSPECIFIED |
पुष्टि मोड बताया नहीं गया था. सिंक्रोनस पुष्टि को मान लिया जाएगा. |
CONFIRMATION_MODE_SYNCHRONOUS |
बुकिंग की उपलब्धता की पुष्टि समय के साथ की जाएगी. |
CONFIRMATION_MODE_ASYNCHRONOUS |
इस सुविधा की उपलब्धता के लिए बुकिंग की पुष्टि एसिंक्रोनस तरीके से की जाएगी. |
तरीके |
|
---|---|
|
खास एग्रीगेटर के ज़रिए मैनेज किए जाने वाले व्यापारी/कंपनी के मौजूदा Service के Availability को बदलता है और इसे लौटाता है. |