რესტორნის პროგრამული ინტეგრაციები და ვებჰუკები

ყველა რესტორანი ერთზე მეტ სისტემაზე დგას. POS-მა იცის, რა გაიყიდა, მომწოდებელმა იცის, რა ჩამოიტანა, ბუღალტერს ორივე თვის ხუთ რიცხვამდე სჭირდება, შუაში კი მენეჯერი ციფრებს ერთი ეკრანიდან მეორეზე გადააქვს. ინტეგრაცია ამ გზის შესამოკლებლად არსებობს.

ამ გზამკვლევში განვიხილავთ, რა კავშირებს გთავაზობთ Wox დღეს, რეალურად რა მონაცემებს გადასცემს თითოეული და როგორ ავაწყოთ ის, რომელიც ყველაზე ხშირად არასწორად ესმით: გამავალი ვებჰუკი, რომლითაც მომწოდებლები შეკვეთების შესახებ მოვლენებს იღებენ. ბოლოს მოცემულია მოკლე რუტინა, რომელიც ნებისმიერ ინტეგრაციას გაშვების შემდეგ გამართულს ინარჩუნებს.

დაიწყეთ მონაცემებით და არა ინსტრუმენტით

სანამ რამეს დააკავშირებთ, ერთი წინადადებით ჩაწერეთ, რა პრობლემას აგვარებთ. „ბუღალტერი ყველა ზედნადებს ხელით გადაბეჭდავს“ კარგი წინადადებაა. „ინტეგრაციები გვინდა“ არ არის. პირველი გეუბნებათ, რომელი მონაცემი უნდა გადავიდეს, საით და რამდენად სწრაფად. მეორეს ისეთ კავშირამდე მივყავართ, რომელსაც პატრონი არ ჰყავს.

საქართველოში რესტორნების უმეტესობისთვის ეს წინადადება საბოლოოდ შესყიდვის დოკუმენტებს ეხება. რეგისტრირებული მომწოდებლის ყოველი მიწოდება rs.ge-ზე ელექტრონულ ზედნადებად უკვე არსებობს და სწორედ ეს კავშირი აშორებს ყველაზე მეტ ხელით სამუშაოს.

rs.ge-სთან კავშირი

Wox უკავშირდება შემოსავლების სამსახურს და თქვენს ზედნადებებს იმპორტს უკეთებს. პირველი დაკავშირებისას ის თორმეტი თვის ისტორიას ტვირთავს, შემდეგ კი ყოველ ღამე სინქრონიზდება. ამ დოკუმენტებიდან Wox გთავაზობთ მომწოდებლებსა და პროდუქტებს, აკავშირებს მათ უკვე არსებულ ჩანაწერებთან და ქმნის მკაფიო ისტორიას: რა იყიდეთ, ვისგან და რა ფასად.

მარაგში არაფერი აისახება, სანამ ვინმე არ გადახედავს. მენეჯერი ამოწმებს შემოთავაზებულ მომწოდებლებსა და პროდუქტებს, აერთიანებს დუბლიკატებს და ადასტურებს. მხოლოდ ამის შემდეგ იცვლება რაოდენობები. იმპორტირებული ზედნადებების ფასები თითოეული პროდუქტის ფასების ისტორიაშიც ჩაიწერება, რეცეპტების თვითღირებულება კი სწორედ ამ ისტორიიდან ითვლება. დაყენების ეკრანები დაწვრილებით rs.ge ინტეგრაციის გვერდზეა აღწერილი.

მონაცემები ბუღალტრისთვის

ყველა ინტეგრაციას ცოცხალი კავშირი არ სჭირდება. Wox-ის რამდენიმე ანგარიში CSV ფაილად ექსპორტდება და ბუღალტერს ან ცხრილს ხშირად სწორედ ეს სჭირდება. ორგანიზაციის ჩანაწერების სრული ასლისთვის შეგიძლიათ მონაცემების ექსპორტი მოითხოვოთ: Wox ამზადებს JSON ფაილს და ელფოსტით აგზავნის ჩამოსატვირთ ბმულს, რომელიც შვიდი დღე მოქმედებს. რა შედის ექსპორტში, მონაცემების ექსპორტის გზამკვლევშია ჩამოთვლილი.

ყოველთვიური ექსპორტი, რომელსაც ვინმე მართლა ხსნის, უფრო მეტი ღირს, ვიდრე ავტომატური ნაკადი, რომელსაც არავინ ამოწმებს.

მომწოდებლის ვებჰუკები

ვებჰუკები საპირისპირო მიმართულებით მუშაობს. მათ მომწოდებელი აწყობს მომწოდებლის პორტალში, რათა მისმა სისტემამ შეკვეთის ცვლილების შესახებ მაშინვე შეიტყოს და ამისთვის ვინმეს შესვლა და შემოწმება არ დასჭირდეს.

მომწოდებელს შეკვეთის სამ მოვლენაზე გამოწერა შეუძლია: შეკვეთა შეიქმნა, შეკვეთა განახლდა ან შეკვეთა გაუქმდა. ყოველი მიწოდება არის HTTPS POST მოთხოვნა JSON სხეულით, რომელშიც არის მოვლენის უნიკალური იდენტიფიკატორი, მოვლენის ტიპი, მისი დრო და შესყიდვის შეკვეთის ასლი: ხაზები, ჯამები, სტატუსი და შემკვეთი ფილიალი.

მიმღები მხარის ამწყობისთვის რამდენიმე დეტალს აქვს მნიშვნელობა.

• მისამართი უნდა იყოს საჯარო HTTPS მისამართი. მისამართები, რომლებიც კერძო ან ლოკალურ ქსელზე მიუთითებს, უარყოფილია.
• ყოველი მოთხოვნა ხელმოწერილია HMAC-SHA256-ით საიდუმლო გასაღების გამოყენებით, რომელიც მხოლოდ ერთხელ, ვებჰუკის შექმნისას ჩანს. Wox მას ხელახლა ვერ გაჩვენებთ.
• მიმღებმა 30 წამში უნდა უპასუხოს. ხანგრძლივი დამუშავება მიმღებ მხარეს ფონურ პროცესში უნდა გადავიდეს.
• წარუმატებელი მიწოდება მეორდება 1 წუთის, 5 წუთის, 30 წუთის, 2 საათისა და 12 საათის შემდეგ. განმეორებითი მოთხოვნა შეიძლება იმ წარმატების შემდეგაც მოვიდეს, რომელიც მიმღებმა არ დაადასტურა, ამიტომ დუბლიკატები მოვლენის იდენტიფიკატორით გაფილტრეთ.

შეკვეთის მოვლენები მხოლოდ მაშინ იგზავნება, როცა შემკვეთი რესტორნის პაკეტი მომწოდებლის ვებჰუკებს მოიცავს, ეს კი Enterprise პაკეტის ნაწილია. ამასთან, Wox-ში მომწოდებლებთან შეკვეთა ჯერ ყველა რესტორნისთვის არ არის გახსნილი, ამიტომ შესაძლოა მომწოდებელმა ვებჰუკი ააწყოს და გარკვეული დროის განმავლობაში მხოლოდ სატესტო მოვლენები მიიღოს. ეს მოსალოდნელია და შეცდომას არ ნიშნავს.

როგორ ავაწყოთ მომწოდებლის ვებჰუკი

1. 1განსაზღვრეთ, შეკვეთის რომელი მოვლენები სჭირდება თქვენს სისტემას. მომწოდებლების უმეტესობას შექმნილი და გაუქმებული შეკვეთები სჭირდება; განახლებაც დაამატეთ, თუ რაოდენობები შეკვეთის შემდეგ ხშირად იცვლება.
2. 2მოამზადეთ მიმღები მისამართი საჯარო HTTPS მისამართზე, რომელიც JSON POST მოთხოვნებს იღებს.
3. 3მომწოდებლის პორტალში გახსენით ვებჰუკები, აირჩიეთ ვებჰუკის დამატება, შეიყვანეთ მისამართი და მონიშნეთ მოვლენები.
4. 4ხელმოწერის საიდუმლო გასაღები გამოჩენისთანავე დააკოპირეთ და შეინახეთ საიდუმლოებების მენეჯერში ან გარემოს ცვლადში. ის მხოლოდ ერთხელ ჩანს.
5. 5მიმღებმა ნებისმიერი დამუშავების წინ ხელმოწერა უნდა გადაამოწმოს დროის ნიშნულისა და მოთხოვნის დაუმუშავებელი სხეულის გამოყენებით.
6. 6ვებჰუკების გვერდიდან გაგზავნეთ სატესტო მოვლენა და დარწმუნდით, რომ მიწოდების სტატუსი წარმატებულით შეიცვალა.
7. 7პირველი რამდენიმე რეალური შეკვეთისას თვალი ადევნეთ მიწოდების ისტორიას და შეამოწმეთ დრო და შინაარსი.
8. 8ჩაიწერეთ მისამართი, გამოწერილი მოვლენები, სად ინახება საიდუმლო გასაღები და ვინ არის მიმღების პასუხისმგებელი.

ინტეგრაცია პასუხისმგებლის გარეშე მომავალი გათიშვაა, რომელზეც არავინაა დანიშნული.

საიდუმლო გასაღების შეცვლა შეფერხების გარეშე

ხელმოწერის საიდუმლო გასაღებს ადგილზე ვერ შეცვლით. თუ ის გაჟონა ან წავიდა დეველოპერი, რომელმაც ის იცოდა, ვებჰუკი ისე ჩაანაცვლეთ, რომ მიმღები ერთი წუთითაც არ დარჩეს მოქმედი გასაღების გარეშე.

1. 1შექმენით ახალი ვებჰუკი იმავე მისამართითა და მოვლენებით და შეინახეთ მისი ახალი საიდუმლო გასაღები.
2. 2მიმღები ისე განაახლეთ, რომ ძველი და ახალი გასაღებით შექმნილი ხელმოწერები ორივე მიიღოს.
3. 3დარწმუნდით, რომ ახალი ვებჰუკის მიწოდებები წარმატებულია.
4. 4წაშალეთ ძველი ვებჰუკი და მიმღებიდან ძველი გასაღები ამოიღეთ.

როგორ შევინარჩუნოთ ინტეგრაციები გამართული

ინტეგრაციების უმეტესობა ჩუმად ფუჭდება. სერტიფიკატს ვადა გასდის, სერვერი სხვაგან გადადის, პაროლი იცვლება და ერთი კვირა ამას ვერავინ ამჩნევს, რადგან არაფერი უჩივის. გამოსავალი იშვიათად არის მეტი ტექნოლოგია. გამოსავალი არის სახელი და კალენდარში ჩანაწერი.

• ყოველ ინტეგრაციას ერთი პასუხისმგებელი მიუჩინეთ, კონკრეტული ადამიანი და არა გუნდი.
• rs.ge-ს სინქრონიზაციის სტატუსი და ვებჰუკების მიწოდების ისტორია კვირაში ერთხელ, ერთსა და იმავე დღეს შეამოწმეთ.
• ნებისმიერ მხარეს ცვლილების შემდეგ გაგზავნეთ სატესტო მოვლენა და დარწმუნდით, რომ მივიდა.
• დაყენების ჩანაწერები იქ შეინახეთ, სადაც შემდეგი ადამიანი იპოვის, და არა ერთი ადამიანის საფოსტო ყუთში.

როცა რამე მაინც ფუჭდება, მიზეზს ჩვეულებრივ მიწოდების ისტორია გეუბნებათ: მიმღების დაბრუნებული სტატუს-კოდი, ვადის ამოწურვა ან უარყოფილი მისამართი. ნებისმიერ ცვლილებამდე იქიდან დაიწყეთ. კავშირის სხვა პრობლემების ხშირი მიზეზები პრობლემების მოგვარების გზამკვლევშია ჩამოთვლილი.