BabyShark

Hello 499 AE, Một trong hàng tỷ thứ liên quan đến vận hành trong ngành du lịch, có một việc khá đơn giản nhưng tốn khá nhiều thời gian cho bộ phận Tiền sảnh khi tác nghiệp. Đó là khi khách check in, các thông tin cơ bản như tên, ngày sinh, số ID, địa chỉ phải có đủ trên profile của khách trên các phần mềm PMS để phục vụ nhiều mục đích khác nhau như báo cáo xuất nhập cảnh, lưu trú... Quá trình gõ tay các thông tin trên mất chừng 2 phút - 4 phút tùy vào khả năng của mỗi bạn lễ tân. Nhóm khách 4 người là mất 8 phút minimum / một bạn lễ tân, sau đó mới tiếp các nghiệp vụ khác. Tuy nhiên, quá trình key in thông tin này tốn rất nhiều thời gian, khiến trải nghiệm nhận phòng của khách hàng mất vui. Các bậc tiền bối trước đây đưa ra một số giải pháp: 1. Khách tự check in, các thông tin này khách tự nhập, khách sạn sẽ không tốn thời gian cho việc này => Khách nhận phòng nhanh chóng => Đây là giải pháp Win - Win. 2. Bỏ qua thao tác gõ thông tin này, chỉ chụp hình cái pặc, rồi nhập sau => Đây là giải pháp nhanh nhưng còn tùy policy mỗi nơi, và các bạn lễ tân vẫn phải làm manual. 3. Sử dụng ứng dụng và thiết bị chuyên đọc thông tin này và đưa lên hệ thống PMS, thời gian xử lý tầm 5 - 10 giây / passport / ID Card... => Đây là giải pháp tốn tiền. Tạm bỏ qua giải pháp 1 và 2, xét về mặt em yêu khoa học, liệu chúng ta có thể tự làm một hệ thống như giải pháp thứ 3 được không? Chúng ta hãy cùng phân tích qua một số điểm disadvantages của giải pháp 3: 1. Giá thiết bị chuyên dụng đọc không hề rẻ 2. Ứng dụng đọc thông tin của khách Việt Nam không chuẩn xác. Nếu muốn chuẩn xác, đã có các đơn vị như FPT AI, VNPT AI ... đã build sẵn, tuy nhiên cái chi phí cũng không nhỏ. Tóm lại, vấn đề chính là chi phí , chỉ có một số khách sạn chuẩn quốc tế và có doanh thu tốt mới có thể triển khai. Còn các KS nhỏ thì tiền đâu mà làm? Với mong muốn có thể làm được một giải pháp thuần Việt ngon bổ rẻ, tôi tự hỏi liệu chúng ta có thể tự làm được không? "Có thể", người Việt chúng ta sáng tạo mà... Topic này là tóm gọn một số ý chính và quan trọng để làm được một hệ thống như vậy. Mời mọi người cùng theo dõi.

Một người bạn vừa mới chia sẻ: Mọi người nghĩ thế nào, có đúng hem?

Mình nghe nói là IE Tab hình như nó không an toàn lắm thì phải đó. Theo hướng dẫn của Oracle mà bác đính kèm sử dụng EDGE IE mode thấy thật là ngon đấy :D. Mình thì đang sử dụng 2 cách khác, ngoài 2 mode trên :D.

Tôi hí hửng báo cáo công trạng với em gái Revenue, nhằm múc đích xin xỏ và đòi hỏi thêm gì đó từ em. Em tuyệt nhiên không phản ứng gì dưới sự đòi hỏi của tôi, em chỉ lặng lẽ làm theo những gì tôi muốn... "Anh, sao cái Transaction Code thuế trên OPERA PMS nó lại không ghi nhận thuế cho nhóm hàng chịu thuế 10% nhỉ"? Em phản hồi sau khi tôi đòi hỏi em phải test xem trên OPERA PMS ghi nhận thông tin như thế nào. "Ơ, thế DOGE nào lại thuế của nhóm hàng 10% ghi nhận trên OPERA lại chạy vô doanh thu của nhóm khác ta? À toi, ta quên cấu hình mapping Interface từ POS lên OPERA rồi". Tôi nhăn mặt. Tùy theo cấu hình của mỗi nơi, mà doanh thu sau khi tính tiền trên hệ thống POS, thì sẽ được đẩy lên phần mềm OPERA PMS tự động hoàn toàn thông qua một cái gọi là INTERFACE. INTERFACE làm nhiệm vụ trao đổi thông tin giữa 2 hệ thống để làm sao cả 2 hệ thống ông nói gà thì bà cũng nói gà, chứ không thể có bà nói vịt ông gật đầu gà. Nhưng hệ thống cổ lỗ sĩ của tôi khá siêu việt, nói vịt thành gà, và gà thành vịt không thành vấn đề, vì tôi sẽ làm phiên dịch viên cho chúng nó! Từ POS doanh thu được đưa lên OPERA PMS, có thể là inclusive (bao gồm) hoặc exclusive (không bao gồm) thông tin SVC và VAT. Câu chuyện này tôi chờ VIC về bờ lại rồi sẽ tâm sự sau, vì VIC đang sập xuống 75k kể từ khi tôi mua "đáy", trong khi FLC đưa tôi ra đảo và lên đỉnh 2 lần. Trở lại câu chuyện, với 1000 đồng cho món hàng VAT 8%, nghiễm nhiên chạy đúng, vì trước đó, chỉ đơn giản là thay đổi cách tính Tax Rates. Còn món hàng chịu VAT 10% là mới khai báo thêm sau này. Do vậy, cần INTERFACE để khi có món hàng từ POS đưa thông tin sau lên OPERA PMS: - Base: 1000 đồng - SVC: 50 đồng - Tax: 105 đồng. - Tên khách: BabyShark - Phòng: 8888 - Độ tuổi: Mới lớn - Tên món: Gói Thăng Long loại dẹp Thì lập tức INTERACE sẽ post cái bill đó vô phòng 8888, của ông khách BabyShark. Trên OPERA PMS, cũng sẽ hiển thị cái bill này giống như ở hệ thống POS. Trong trường hợp này, cần một loạt các Transaction Codes (mã giao dịch, tạm dịch vậy) đặc trưng cho từng loại giao dịch, thông tin giao dịch được tạo trên hệ thống OPERA PMS, ví dụ: Transactions code: 2000: Doanh thu thuốc lá 8000: Phí phục vụ 9000: Thuế Vậy, sau khi bill đó được đưa lên OPERA PMS, báo cáo của OPERA ghi nhận như sau: Doanh thu: 1000 đồng Phí phục vụ: 50 đồng Thuế: 105 đồng cho một gói thuốc lá Thăng Long giá 1000 đồng. .... IPTV đang mất tín hiệu, và khách muốn xem kênh Cartoon HDD tôi phải đi hỗ trợ khách hàng thân yêu của tôi đã. (to be continued)

Vậy là, cuối cùng thì là, VAT đã tách chuẩn rồi. Việc lúc này khá đơn giản. Tạo các Menu Items Class tương ứng với nhóm ALCOHOL và TOBACO (nếu có sẵn rồi thì thôi). Cấu hình chuẩn: SVC -> NON VAT TAX CLASS -> ALL TAX -> Tax rates 8.4% và 10.5% MENU ITEM CLASS (ALCOHOL & TOBACO) -> TAX CLASS 10.5%. MENU ITEM CLASS (THE REST) -> TAX CLASS 8.4% SERVING PERIOD -> ALL TAX ORDER TYPE -> ALL TAX

Xin chào, lại là tôi đây mọi người ơi! Hôm nay trời hơi âm u, chắc công việc sẽ lu bu cả ngày. Quay trở lại lúc đó, tôi khá hoang mang VAT 8% tính đúng, còn VAT 10% tính sai. Nhưng với tinh thần dân điện lạnh mà đòi sửa WIFI, đã ăn khoai thì đừng nói chuyện củ sắn, tôi mò tiếp! Tôi mới nhìn lại một lượt thì thấy: Items set VAT đúng, món chịu thuế 8% thì set Tax Class 8%, món chịu thuế 10% thì set Tax Class 10%. SP và OT set VAT đúng, đều về ALL TAX FB. Tax Rates đúng, tính phần trăm không sai. Có mỗi phần phần tính SVC là chỉ trỏ về VAT 8%. Như vậy vấn đề nằm ở chỗ này. Tôi truy cập vào POS Config -> Sales -> Service Charges Rõ ràng là set 8%. Nếu mình chọn TAX CLASS là ALL TAX FB thì sao nhỉ? Tôi liền chuyển sang ALL TAX FB để cho em nó một cơ hội và fire một cái bill để xem thử kết quả như thế nào, ra làm sao. Với item 10%: Với item 8%: Oh, lúc này SVC tính đúng, VAT tính đúng, nhưng lại dư thêm 8 và 10% của SVC. Căng không? Với củ sắn và khoai ăn dặm của mình, tôi nhận ra là phải uống cà phê mới giải quyết được chỗ này. Sau khi làm ly cà phê Phố của Macoffee và chốt lệnh bắt đáy VIC ở vùng giá 96K, tôi quay lại với vấn đề này. Tôi nhận thấy, SVC đặt lớp TAX thì bị tính thuế riêng cho SVC mà không tính gộp luôn giá base. Nếu mình không tính thuế SVC, vậy thì khả năng dòng VAT tính thêm sẽ biến mất. Okay thử thôi. Items 10%: Items 8%: Chà, đúng như dự tính, mất 2 cái dòng thừa rồi. Cơ mà, sao tính sai VAT nhỉ, à sai là đúng, vì nó không tính VAT sau SVC và Base, mà chỉ tính VAT của base price. Eurowindow, tìm ra rồi. Sửa lại công thức tính VAT thôi. Thay vì 8% thì sẽ là 8.4%, thay vì 10% thì sẽ là 10.5%, 30% sẽ là 31.5% trên Tax Rates. Test lại phát cuối coi có ổn không nè. Ở một diễn biến khác, tôi có nên học thêm ACCA không nhỉ? Học để có kiến thức chém gió đúng không ta! Hurra, chuẩn man rồi. (to be continued)

Tôi tạo mới một Menu Items Class, tạm gọi là BEVERAGE10++, với Tax Class là VAT 10% như đã nói ở trên. Như vậy tới lúc này tôi đang có trong tay các thông tin và cấu hình: Serving Period -> ALL TAX FB class (gồm Tax Rate 8% và 10%) Order Types -> ALL TAX FB class (gồm Tax Rate 8% và 10%) Item thuộc nhóm chịu 10%, với Tax Class là VAT 10% (chỉ có Tax Rate 10%), như hình này: Tôi post và giật mình khi màn hình cashiering hiển thị như sau: WTF, VAT gì kỳ vậy ta, đáng lẽ PAYMENT phải là 1155 chớ ta? Sao thiếu 1 đồng? Trên MICROS RES 3700, có một nơi lưu lại JOURNAL của hệ thống (nếu có cấu hình), vị trí (tùy vào chỗ cài đặt) D:\MICROS\Res\Pos\Journals\JOURNALPRT.txt Tôi bèn mở ra xem vì sao nó tính thiếu 1 đồng? ây da, có vẻ là tính đúng SVC, nhưng VAT tính sai bét. VAT 8% = 4 là bằng 8% của SVC. Còn VAT 10% là 10% của base price. Mà sao cái này là items 10%, mà tự dưng tính 8% vô chi vậy ta. Thôi, kệ, thử test post với items chịu thuế 8% xem sao đã. Ủa kỳ nha, sao VAT 8% lại đúng mà 10% tính tầm pậy tầm pạ ghê.

... khách không cắm cái Key Card vô cái lỗ cắm Card, nên không có điện. Hoan nghênh tinh thần tiết kiệm điện muôn năm! Đó, cái chỗ chết tôi rồi là chỗ đó, Tax Class chỉ cho phép chọn 1, nhưng... à mà thôi, tôi đã có cái ALL TAX FB rồi: Tôi chọn Tax Class của Serving Period và Order Types là ALL TAX FB, với ALL TAX FB tích chọn Tax Rates 8% và 10%. POS CONFIG -> Serving Period POS CONFIG -> Order Types Rồi, lần này không được nữa dẹp luôn. Tôi thử post thử 2 cái items, mỗi cái có giá base là 1000 tương ứng với nhóm thuế 8 và 10, cấu hình 2 items này ban đầu như sau:

Xin chào 499 AE, Là tôi đây. Chuyện là vừa qua sau khi đổi thuế từ 10 về 7, thì giờ lại có yêu cầu mới áp dụng thuế 10% cho nhóm ALCOHOL và TOBACO. Còn lại thì áp dụng thuế 8%. Chuyện cũng chẳng có gì đáng nói nếu như nhà cung cấp không bận thu tiền khách sạn để làm việc này nên không có người làm, bên hóa đơn điện tử cứ lờ mờ lơ mơ, không kịp nắm bắt thông tin chủ động với khách hàng, công văn nhận ngày 28 âm, bắt áp dụng mùng 1, rồi accouting thì có chỗ áp dụng hết 8, có chỗ thì tách... blahblah. Cuối cùng thì, uh, tách, phải tách thôi, không chờ được nữa. Cái hệ thống chúng tôi tách là một hệ thống cổ lỗ sỉ nhưng vẫn hoạt động rất tốt, gồm combo thần thánh "Sun Systems, Opera PMS, và Micros RES 3700". "Em tạo transaction cho nhóm ALCOHOL và TOBACO với map về Sun System nhen, anh lo việc POS và PMS", em gái Revenue xinh đẹp nói với tôi như vậy. "Không anh không cho riêng tư đâu, anh làm hết cơ! Vụ chọt chọt này cái hồi còn trẻ trâu anh cũng chọt nhiều rồi, lâu quá không mò vô thôi". Tôi cười trơ tráo! "Anh làm nhanh nhanh cho em đẻ trước Tết nhé". Em gái Revenue nói tôi vậy. Tôi gật đầu cái rụp. "Oh cái này đơn giản mà" tôi thầm nghĩ. Đầu tiên, tôi vô cái POS Config -> Sales -> Tax Rates -> tôi tạo một cái TAX 10%, với Type là percent 10% và 8% tương ứng. Cái items nào trên POS áp dụng 8% thì sẽ dùng 8%, còn cái nào áp 10% thì sử dụng Rates 10%. Sau đó, tôi click Tax Classes, tạo 2 Tax Class là 10 và 8% và tích chọn Tax rates tương ứng cho nó. Xong, done kèo. Mèn đét ơi, nhưng chỗ tôi làm thì áp dụng cái kiểu breakdown doanh thu theo Serving Period và Order Types. Mà mấy chỗ đó chỉ cho phép chọn 1 Tax Class duy nhất. Thế giờ làm sao ta? Tôi khựng lại trong giây lát. Với tư duy kiểu làm nông của mình, tôi nghĩ "ủa, sao Tax Class nó cho tích chọn nhỉ"? Thôi, cứ thử làm bừa một cái xem sao? Tôi bèn tạo một Tax Class mới là ALL TAX FB, tích chọn 2 Tax Rates là VAT 8% và VAT 10%. .... khách mới gọi ổ cắm điện trong phòng sạc không được iPad, ngưng viết chút, tôi sẽ quay lại sau... (to be continued)

Hê nhô 500 tềnh iu, Hôm nay trời nắng ráo, lại tiếp tục cho chủ đề này, Cá Mập Bé Nhỏ thiết nghĩ nên viết luôn thành một topic để mọi người tham khảo và thực hiện luôn, qua đó nắm cách tạo được Simple Report. It's very simple, indeed! Bắt đầu thôi: Chẳng là có vài địa phương, yêu cầu một số khách sạn phải cập nhật thông tin khách quốc tế hoặc Việt Nam gì đó lên hệ thống xuất nhập cảnh (XNC). Opera phiên bản Thái Sing có sẵn một số tool cũng như interface với các hệ thống xuất nhập cảnh của các nước đó, nhưng chưa áp dụng với hệ thống XNC của ta được. Thời điểm đầu, các hệ thống XNC của ta chỉ cho phép gõ manual, rất mệt và tốn thời gian, khiến ngón tay búp măng xinh xinh của các bạn gái lễ tân chai sần vì gõ nhiều quá. Sau một vài cuộc họp với người làm du lịch, hệ thống XNC đã nâng cấp, cho phép các khách sạn tự up file dữ liệu của mình mà không phải mất công gõ lại nữa. Một sự nâng cấp đáng khích lệ, thấu hiểu cho ngành du lịch! Như vậy, bài toán lúc này đơn giản hơn. Chỉ cần xuất file XML hoặc EXCEL theo cấu trúc yêu cầu của hệ thống XNC và upload file lên là xong rồi. Topic này tập trung một số vấn đề sau: 1. Cách tạo simple report, có thể áp dụng luôn cho các simple report khác. 2. Một số câu SQL expression của Opera để lấy dữ liệu cần và đủ. 3. Chuyển định dạng qua lại từ Excel sang XML và ngược lại. Mong mọi người đón xem.

Nếu chúng ta có một hệ PMS online giả lập để mọi người vọc vạch, thì sẽ như thế nào?

Như vậy, phương án nào là do Kế toán trưởng đúng hông. 😏

@BAL cảm ơn bạn, vấn đề này mình cũng đang gặp phải chưa rõ làm sao, may quá. Bài viết hay lắm.

Xin chào 500AE, Trong series Opera Simple Report này, Cá Mập Nhỏ Bé muốn chia sẻ một trick để hiển thị ở trường ID Number hoặc Passport trên Simple Report. Ai cũng biết số ID hoặc Passport là thông tin nhạy cảm, cần phải được kiểm duyệt, nôm na gọi là "che". Vậy muốn có bản full không che trên Simple report thì phải "nàm thao"? Mặc định Opera sẽ che các trường này bằng b.id_number_str hoặc a.passport_str. Bỏ “_str” sẽ được không che. Câu SQL là: case when b.id_number is NULL then a.passport else b.id_number end Trick kế tiếp sẽ là "Hiển thị thông tin ngày sinh tháng đẻ trên Opera Simple Report". Kính mong quý "dị" đón xem!