REST Resource: inventory.partners.merchants.services.availability

संसाधन: उपलब्धता

कारोबारी या कंपनी की सेवा की उपलब्धता का स्लॉट, जिसमें समय और स्पॉट की संख्या दिखती है.

JSON के काेड में दिखाना 
{
  "startTime": string,
  "duration": string,
  "spotsTotal": string,
  "spotsOpen": string,
  "availabilityTag": string,
  "resources": {
    object (Resources)
  },
  "paymentOptionId": [
    string
  ],
  "recurrence": {
    object (Recurrence)
  },
  "scheduleException": [
    {
      object (ScheduleException)
    }
  ],
  "deposit": {
    object (Deposit)
  },
  "noShowFee": {
    object (NoShowFee)
  },
  "requireCreditCard": enum (RequireCreditCard),
  "ticketTypeId": [
    string
  ],
  "durationRequirement": enum (DurationRequirement),
  "schedulingRuleOverrides": {
    object (SchedulingRuleOverrides)
  },
  "confirmationMode": enum (ConfirmationMode)
}
फ़ील्ड
startTime

string (Timestamp format)

अपॉइंटमेंट स्लॉट के शुरू होने का समय.

आरएफ़सी3339 यूटीसी "ज़ुलु" में टाइमस्टैंप फ़ॉर्मैट, नैनोसेकंड रिज़ॉल्यूशन और ज़्यादा से ज़्यादा नौ फ़्रैक्शनल अंकों के साथ हो सकता है. उदाहरण: "2014-10-02T15:01:23Z" और "2014-10-02T15:01:23.045123456Z".
duration

string (Duration format)

अपॉइंटमेंट स्लॉट की अवधि

सेकंड में कुल नौ दशमलव अंक, जो 's' पर खत्म होते हैं. उदाहरण: "3.5s".
spotsTotal

string (int64 format)

इस उपलब्धता के लिए उपलब्ध कुल स्पॉट और ओपन स्पॉट की संख्या. उदाहरण:

  • 10 स्पॉट की योग क्लास, जहां तीन बुकिंग हैं: availability {spotsTotal: 10, spotsOpen: 7 ...}
  • चेयर मसाज का सेशन पहले ही पूरी तरह बुक हो चुका है: availability {spotsTotal: 1, spotsOpen: 0 ...}

ध्यान दें: अगर नीचे दिए गए, उपलब्धता कंप्रेशन फ़ॉर्मैट का इस्तेमाल करके अनुरोध भेजे जा रहे हैं, तो इन दो फ़ील्ड का अनुमान लगाया जाएगा.

  • बार-बार होने वाले टास्क में spotsTotal=1 और spotsOpen=1 शामिल हैं.
  • ScheduleOnce का मतलब spotsTotal=1 और spotsOpen=0 होता है.
spotsOpen

string (int64 format)

खाली जगहों की संख्या.
availabilityTag

string

उपलब्धता के इस स्लॉट की पहचान करने के लिए एक वैकल्पिक ओपेक स्ट्रिंग. अगर यह नीति सेट की जाती है, तो इसे अपॉइंटमेंट बुक करने/अपडेट करने/रद्द करने के अनुरोधों में शामिल किया जाएगा.
resources

object (Resources)

जब अलग-अलग स्टाफ़ या कमरा सेवा का हिस्सा होता है, तब उपलब्धता के इस स्लॉट को दूसरों से अलग करने के लिए इस्तेमाल किए जाने वाले वैकल्पिक संसाधन.

उदाहरण के लिए, एक ही योग क्लास, जिसमें दो दो ट्रेनर हैं:

availability { resources { staffId: "1" staffName: "Amy" }
               spotsTotal: 10 spotsOpen: 7 }
availability { resources { staffId: "2" staffName: "John" }
               spotsTotal: 5 spotsOpen: 2 }
paymentOptionId[]

string

इस स्लॉट के लिए पेमेंट करने के लिए इस्तेमाल किए जा सकने वाले पेमेंट के विकल्पों के बारे में बताने वाले आईडी की सूची. पेमेंट के असल विकल्प, व्यापारी/कंपनी/कारोबारी के लेवल पर तय किए जाते हैं और इन्हें कई व्यापारियों/कंपनियों/कारोबारियों के साथ शेयर भी किया जा सकता है.

यह फ़ील्ड सेवा मैसेज में दिए गए किसी भी payment_option_ids को बदल देता है. इसी तरह, यहां दिए गए payment_option_ids को सेवा मैसेज में देना ज़रूरी नहीं है. हालांकि, इसे व्यापारी/कंपनी/कारोबारी के लेवल पर तय किया जाना चाहिए.
recurrence

object (Recurrence)

उपलब्धता के लिए बार-बार होने की जानकारी, जो एक से ज़्यादा प्रारंभ समय का प्रतिनिधित्व करती है. बार-बार होने वाले टास्क में, एक कामकाजी दिन के अपॉइंटमेंट शामिल होने चाहिए.
scheduleException[]

object (ScheduleException)

वे समय जब इस सेवा को शेड्यूल नहीं किया जा सकता. शेड्यूल अपवाद वाले मैसेज की संख्या सीमित करने के लिए, आस-पास के अपवादों को शामिल करें.
deposit

object (Deposit)

इस उपलब्धता के लिए वैकल्पिक जमा. अगर कोई सेवा जमा की गई थी, तो उसे बदल देता है.
noShowFee

object (NoShowFee)

इस उपलब्धता के लिए कोई शो न होने का शुल्क (ज़रूरी नहीं) अगर कोई सेवा शुल्क नहीं बताया गया था, तो उसे बदल देता है.
requireCreditCard

enum (RequireCreditCard)

यह बताता है कि उपलब्धता का यह स्लॉट बुक करने के लिए उपयोगकर्ता को क्रेडिट कार्ड देना ज़रूरी है या नहीं. अगर वैल्यू सेट नहीं है, तो इसे सेवा के लेवल पर सेट किया जाता है. हालांकि, ऐसा तब ही होता है, जब इसे सेवा के लेवल पर सेट किया गया हो. (ज़रूरी नहीं)
ticketTypeId[]

string

यह उपलब्धता इस स्लॉट के लिए इस्तेमाल किए जा सकने वाले टिकटों के टाइप की सूची दिखाता है. अगर यह नीति सेट नहीं है, तो इस स्लॉट के लिए पैरंट सेवा में मौजूद सभी तरह के टिकट उपलब्ध हैं. ध्यान दें कि इस फ़ील्ड की वैल्यू, पैरंट सेवा में तय होनी चाहिए. उदाहरण:

  • चार तरह के टिकट वाली सेवा: TicketType {ticketTypeId: "adult_1" ShortDescription: "वयस्क वीकडे"} टिकट टाइप {ticketTypeId: "adult_2" छोटा ब्यौरा: "वयस्क वीकेंड"} TicketType {ticketTypeId: "youth_1" ShortDescription: "Youth Weeks"} TicketType {ticketTypeId: "youth_2" ShortDescription: "युवा वीकेंड"}

सोमवार से शुक्रवार तक इन्वेंट्री दिखाने के लिए: availability {ticketTypeId: "adult_1" ticketTypeId: "youth_1"...}. छुट्टियों के दौरान इन्वेंट्री दिखाने के लिए: availability {ticketTypeId: "adult_2" ticketTypeId: "youth_2"...}.

  • तीन तरह की टिकटों की सेवा: TicketType {ticketTypeId: "adult" छोटा ब्यौरा: "adult"} TicketType {ticketTypeId: "युवा" ShortDescription: "Youth"} TicketType {ticketTypeId: "सीनियर" छोटा विवरण: "सीनियर"}

इस टाइम स्लॉट के लिए तीनों तरह के टिकट उपलब्ध हैं, यह बताने के लिए availability {ticketTypeId: "adult" ticketTypeId: "youth" ticketTypeId: "senior" ...} या `खरीदारी के लिए उपलब्धता {...}' का इस्तेमाल करें (इस स्लॉट में TicketTypeId सेट न करें).

(ज़रूरी नहीं)
durationRequirement

enum (DurationRequirement)

स्लॉट की अवधि और/या खत्म होने का समय दिखाने की ज़रूरी शर्त. अगर स्लॉट उपलब्ध नहीं है, तो इस फ़ील्ड को अनदेखा कर दिया जाएगा. 'क्या-क्या करें' वर्टिकल में इस्तेमाल नहीं किया जाता. (ज़रूरी नहीं)
schedulingRuleOverrides

object (SchedulingRuleOverrides)

खरीदारी के लिए उपलब्धता शेड्यूल करने के नियम. अगर फ़ील्ड में जानकारी अपने-आप भर जाती है, तो वे सेवा-लेवल पर शेड्यूल करने के नियम से जुड़े शेड्यूल करने के नियमों को बदल देंगे.
confirmationMode

enum (ConfirmationMode)

पुष्टि करने वाला मोड, जिसका इस्तेमाल इस उपलब्धता के लिए बुकिंग करते समय किया जाएगा. CONFIRMATION_mode_SYNCHRONOUS के पुष्टि मोड के साथ, अवेलेबिलिटी के लिए बुकिंग बनाने की कोशिशों की तुरंत पुष्टि या अस्वीकार कर दी जानी चाहिए. पुष्टि करने वाले मोड CONFIRMATION_Mode_ASYNCHRONOUS की, उपलब्धता के लिए बुकिंग बनाने की कोशिशों को तुरंत अस्वीकार किया जाना चाहिए. इसके अलावा, 'मंज़ूरी बाकी है' स्टेटस के साथ भी बुकिंग की जा सकती हैं.

संसाधन

जब सेवा का इस्तेमाल अलग-अलग स्टाफ़ या कमरे के लोग करते हैं, तब संसाधन उपलब्ध होने की उपलब्धता की समयावधि को एक-दूसरे से अलग करने के लिए इस्तेमाल किए जाते हैं. एक ही सेवा और समयावधि के लिए, अलग-अलग संसाधन होने पर एक साथ कई स्लॉट हो सकते हैं.

JSON के काेड में दिखाना 
{
  "staffId": string,
  "staffName": string,
  "roomId": string,
  "roomName": string,
  "partySize": integer
}
फ़ील्ड
staffId

string

सेवा देने वाले स्टाफ़ के सदस्य का वैकल्पिक आईडी. इस फ़ील्ड से सभी कारोबारियों, सेवाओं, और उपलब्धता के रिकॉर्ड में स्टाफ़ के सदस्य की पहचान होती है. यह भी ज़रूरी है कि यह समय के साथ एक जैसा हो, ताकि पिछली बुकिंग से जुड़ा जा सके. अगर स्टाफ़ का नाम मौजूद है, तो यह फ़ील्ड ज़रूर मौजूद होना चाहिए.
staffName

string

सेवा देने वाले स्टाफ़ के सदस्य का वैकल्पिक नाम. यह फ़ील्ड बुकिंग करने वाले लोगों को दिखाया जाएगा. इसकी जानकारी ओपेक आइडेंटिफ़ायर के बजाय, लोगों को आसानी से मिलनी चाहिए. अगर स्टाफ़ आईडी मौजूद है, तो यह फ़ील्ड मौजूद होना चाहिए.
roomId

string

उस रूम का वैकल्पिक आईडी जहां सेवा मौजूद है. यह फ़ील्ड सभी व्यापारियों, सेवाओं, और उपलब्धता रिकॉर्ड में कमरे की पहचान करता है. यह भी ज़रूरी है कि यह समय के साथ एक जैसा हो, ताकि पिछली बुकिंग से जुड़ा जा सके. अगर roomName मौजूद है, तो यह फ़ील्ड मौजूद होना चाहिए.
roomName

string

उस रूम का वैकल्पिक नाम जहां सेवा उपलब्ध है. यह फ़ील्ड बुकिंग करने वाले लोगों को दिखाया जाएगा. इसकी जानकारी ओपेक आइडेंटिफ़ायर के बजाय, लोगों को आसानी से मिलनी चाहिए. (ज़रूरी नहीं, लेकिन अगर roomId मौजूद है तो कमरे का नाम डालना ज़रूरी है) डाइनिंग में कमरे का नाम सिर्फ़ बैठने की जगह के लिए इस्तेमाल किया जाना चाहिए, जैसे कि बार या बाहर खुले में बैठने की जगह (पैटियो). साथ ही, तय कीमत वाले मेन्यू, खास गतिविधियों या कमरे के अलावा दूसरी तरह की सुविधाओं (जैसे कि बुकिंग या रात का खाना) के लिए भी इसका इस्तेमाल नहीं किया जाना चाहिए. यह सुझाव दिया जाता है कि डिफ़ॉल्ट रूप से सेट की गई बैठने की जगह के साथ कोई कमरा न हो.
partySize

integer

सिर्फ़ डाइनिंग के लिए लागू: पार्टी का वह साइज़ जो इस टाइम स्लॉट के दौरान रखा जा सकता है. किसी रेस्टोरेंट को एक ही समय के लिए, एक से ज़्यादा स्लॉट से जोड़ा जा सकता है. हर स्लॉट में अलग-अलग पार्टी साइज़ की जानकारी होती है. उदाहरण के लिए, दो, तीन या चार लोगों के बैठने की बुकिंग की जा सकती है.

बार-बार होने वाला

बार-बार आने वाले मैसेज भेजना ज़रूरी नहीं है. हालांकि, इससे उपलब्धता के स्लॉट का बार-बार इस्तेमाल किया जा सकता है. आम तौर पर, ये नतीजे एक दिन के काम करने के शेड्यूल के बारे में बताते हैं. इसके बाद, ScheduleOnce मैसेज का इस्तेमाल कामकाजी दिन में बुक की गई/नहीं मिल रही समय सीमाओं को दिखाने के लिए किया जाता है.

ज़रूरतें:

  1. उपलब्धता स्लॉट या बार-बार होने वाले अनुरोधों की संख्या में बढ़ोतरी किए जाने पर भी एक जैसे स्लॉट नहीं बनने चाहिए. अगर आईडी, startTime, अवधि, और संसाधन मेल खाते हैं, तो स्लॉट एक जैसे माने जाते हैं.
  2. एक ही सेवा के स्लॉट में मानक उपलब्धता फ़ॉर्मैट और बार-बार होने का नियम न जोड़ें. बार-बार होने वाली सुविधा से, अपॉइंटमेंट की सुविधा देने वाली कंपनियों या सेवाओं को फ़ायदा मिलता है. यह स्टैंडर्ड फ़ॉर्मैट, उन कारोबारियों या कंपनियों के लिए है जिनके क्लास नियमित तौर पर शेड्यूल की जाती हैं.
  3. दोहराव 24 घंटों से ज़्यादा नहीं होना चाहिए.
JSON के काेड में दिखाना 
{
  "repeatUntil": string,
  "repeatEvery": string
}
फ़ील्ड
repeatUntil

string (Timestamp format)

ज़्यादा से ज़्यादा यूटीसी टाइमस्टैंप के हिसाब से, उपलब्धता को दोहराया जाएगा.

आरएफ़सी3339 यूटीसी "ज़ुलु" में टाइमस्टैंप फ़ॉर्मैट, नैनोसेकंड रिज़ॉल्यूशन और ज़्यादा से ज़्यादा नौ फ़्रैक्शनल अंकों के साथ हो सकता है. उदाहरण: "2014-10-02T15:01:23Z" और "2014-10-02T15:01:23.045123456Z".
repeatEvery

string (Duration format)

लगातार उपलब्धता स्लॉट के बीच के समय के बारे में बताता है.

उदाहरण: सुबह 20 मिनट की अवधि, हर 30 मिनट में एक बार, सुबह 9:00 बजे शुरू होने का समय, और सुबह 11:00 बजे तक का दोहराव सुबह 9 से 9:20 बजे, सुबह 9:30 से 9:50 बजे, सुबह 10 से 10:20 बजे, सुबह 10:30 से 10:50 बजे, 10:30 से 10:50 बजे तक के समय पर चलेगा (ज़रूरी)

सेकंड में कुल नौ दशमलव अंक, जो 's' पर खत्म होते हैं. उदाहरण: "3.5s".

ScheduleException

शेड्यूल किए गए मैसेज, कामकाजी दिन में बुक की गई/उपलब्ध नहीं है की समय सीमाओं को दिखाते हैं. ये ऊपर बताए गए बार-बार होने के अपवाद हैं. टाइम स्लॉट बुक होने पर, अपवादों की सूची को अपडेट की जानी चाहिए, ताकि उपलब्ध न होने वाली नई समयसीमाएं दिखाई जा सकें. बार-बार होने वाले टास्क में बदलाव नहीं किया जाना चाहिए.

JSON के काेड में दिखाना 
{
  "timeRange": {
    object (TimeRange)
  }
}
फ़ील्ड
timeRange

object (TimeRange)

अपवाद की समयसीमा. अगर कोई स्लॉट इस क्लोज़्ड टाइम रेंज में बार-बार दिखता है, तो उसे उपलब्ध नहीं माना जाएगा.

उदाहरण: अगर यह दोहराव 20 मिनट की अवधि के बारे में बताता है, तो हर 30 मिनट में एक बार, सुबह 9:00 बजे के शुरू होने का समय, और सुबह 11:00 बजे तक का दोहराव, सुबह 9:45 बजे से 11:00 बजे के समय की रेंज के साथ शेड्यूल अपवाद, सुबह 9:30-9:50 बजे, 10 से 10:20 बजे, सुबह 10 से 10:20 बजे के स्लॉट उपलब्ध नहीं कराएगा

ध्यान दें कि समयसीमा खत्म होने की वजह से सुबह 11 बजे से शुरू होने वाले स्लॉट पर कोई असर नहीं होगा.

DurationRequirement

इस सूची से पता चलता है कि उपयोगकर्ता के लिए, अनुरोध किए गए स्लॉट की अवधि/खत्म होने के समय को स्वीकार करने या देखने के लिए कौनसी ज़रूरतें हैं.

Enums
DURATION_REQUIREMENT_UNSPECIFIED खत्म होने के समय को हैंडल करने के बारे में नहीं बताया गया है. यह डिफ़ॉल्ट रूप से होता है.
DO_NOT_SHOW_DURATION उपयोगकर्ता को खत्म होने का समय नहीं दिखाया जाता.
MUST_SHOW_DURATION अपॉइंटमेंट लेने से पहले, उपयोगकर्ता को खत्म होने का समय दिखाया जाना चाहिए.

SchedulingRuleOverrides

उपलब्धता के लेवल को शेड्यूल करने के नियम.

JSON के काेड में दिखाना 
{
  "lastBookableSec": string,
  "firstBookableSec": string,
  "lastOnlineCancellableSec": string
}
फ़ील्ड
lastBookableSec

string (int64 format)

वह आखिरी समय (सेकंड में), जब यह स्लॉट बुक किया जा सका था. यह टाइमस्टैंप, स्लॉट के startSec से पहले का होना चाहिए (अगर उपयोगकर्ता, शुरू होने के समय के बाद बुकिंग कर सकें, तो सेवा लेवल SchedulingRules.min_booking_before_end_time का इस्तेमाल करें). अगर यह मौजूद है, तो इससे जुड़ी सेवा के SchedulingRules के min_booking_buffer में तय की गई किसी भी चीज़ को बदल देगा.
firstBookableSec

string (int64 format)

वह पहली बार (सेकंड में) जब यह स्लॉट बुक किया जा सकेगा. यह टाइमस्टैंप, स्लॉट के startSec से पहले का होना चाहिए या अगर बताया गया है, तो lastBookableSec से पहले का होना चाहिए.
lastOnlineCancellableSec

string (int64 format)

अगर यह नीति सेट की जाती है, तो पिछली बार (Unix epoch के बाद के सेकंड में) इस अपॉइंटमेंट स्लॉट को Reserve with Google के ज़रिए रद्द किया जा सकता था. यह फ़ील्ड, सेवा-स्तर पर रद्द करने के सभी नियमों को बदल देगा. (ज़रूरी नहीं)

ConfirmationMode

बुकिंग की उपलब्धता के दौरान, पुष्टि करने के लिए इस्तेमाल किए जाने वाले मोड.

Enums
CONFIRMATION_MODE_UNSPECIFIED पुष्टि करने वाले मोड की जानकारी नहीं दी गई. सिंक्रोनस पुष्टि को माना जाएगा.
CONFIRMATION_MODE_SYNCHRONOUS इस उपलब्धता के लिए बुकिंग की पुष्टि एक साथ की जाएगी.
CONFIRMATION_MODE_ASYNCHRONOUS इस उपलब्धता के लिए बुकिंग की पुष्टि एसिंक्रोनस रूप से की जाएगी.

तरीके

replace

 किसी खास एग्रीगेटर से मैनेज किए जाने वाले व्यापारी या कंपनी के मौजूदा Service के Availability को बदलता है और उसे लौटाता है.