Reference · built on requestOperator by FibricHospitality & guests

Minibar Restock

Reconciles minibar postings against attendant counts and stock on hand, and proposes restock lists and posting corrections.

Request accessPricing ↗

About

Minibar revenue leaks in two directions: items consumed and never posted, and items posted to a guest who did not take them. Minibar Restock reads the minibar postings on each folio, the consumption the attendant recorded for the room, and the stock the storeroom carries, and compares the three room by room.

It proposes the restock list per floor for the next shift, a posting for a consumption that never reached the folio while the guest is still in house, and a correction where a posting has no count behind it. The front office manager approves postings and corrections; the housekeeping lead approves the restock list.

This is a reference listing. It documents what Fibric would read from Minibar Restock and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Minibar postings by transaction code on each folio, through getPostBillingCharges and getFinancialPostings in the OPERA Cloud csh module
  • Product orders on a Mews reservation and items on its bill, through bills/getAll and products/getAll, with each product's ChargingMode and PostingMode
  • apaleo folio events charge-posted and balance-changed, read after each webhook to see what was billed and when
  • The attendant's recorded consumption per room, from the closed task or service order, or from a count sheet entered in the operator
  • Stock on hand and storeroom issues in your inventory system, per item and location
  • Checkouts as they happen, through the Mews reservation state Processed or apaleo checked-out events, so an unposted consumption is caught before the folio closes
  • Guest disputes about minibar charges arriving as conversations in Kustomer or tickets in Zendesk

Proposed actions

  • Target capability: propose a posting for recorded consumption that has no folio line, through postBillingCharges in OPERA Cloud or Add reservation product in Mews
  • Target capability: propose a correction for a posting with no count behind it, through adjustTransactions in OPERA Cloud, with the attendant's record beside it
  • Target capability: propose the restock list per floor and item for the next shift, as a Mews task or a message to the housekeeping channel
  • Target capability: propose a storeroom issue or a purchase in your inventory system when an item falls below the par you set
  • Target capability: propose a reply note on a dispute in Kustomer or Zendesk, quoting the posting and the count it rests on

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Post what the attendant counted before checkout

    The attendant's closed Mews task records items taken; bills/getAll shows nothing posted. Minibar Restock proposes an Add reservation product for the missing items while the guest is still in house, for the front office to approve.

    With Mews

  • Correct a posting nobody can account for

    An OPERA Cloud folio carries a minibar line for a room whose count shows no consumption. The operator proposes an adjustment through adjustTransactions, with the count sheet beside it, before the guest sees the folio.

    With Oracle OPERA Cloud

  • Restock the floor from real counts

    Overnight consumption across a floor is totalled against the storeroom balance in your inventory system. The operator proposes the pick list per item and a storeroom issue for the morning shift.

    With inFlow Inventory, Zoho Inventory

  • Answer the disputed charge with the record

    A guest writes in Kustomer disputing a minibar charge. Minibar Restock proposes a note on the conversation quoting the posting, the attendant's count, and the time, and leaves the refund decision to your agent.

    With Kustomer, Oracle OPERA Cloud

Requirements

  • A property management connector with folio read and posting write: Oracle OPERA Cloud with the csh module, Mews, or apaleo
  • A recorded consumption per room, from your housekeeping system's closed task or a count the attendant enters
  • An inventory connector holding minibar items with stock on hand per storeroom, or a par list maintained in the operator
  • A minibar transaction code or product identified to the operator, so other charges are never touched
Authentication
Minibar Restock keeps no credentials. Folios, product orders, checkouts, and tickets are read through the connectors you have connected; postings, corrections, and tasks are written through the same connectors after approval.

Limits

  • Where consumption is not recorded per room, the operator reconciles postings against stock at floor level only, not per guest.
  • Corrections go through adjustTransactions in OPERA Cloud. On Mews and apaleo a correcting line is proposed as the PMS allows, never a deleted posting.
  • It does not read minibar sensors or automated minibar controllers; the counts it uses are recorded by people.
  • A dispute is answered with a proposed note, not a refund. Refunds stay with your cashiering process.

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Minibar Restock ↗

Questions and answers

Who approves what?
Each posting, each correction, and each restock list, separately. A posting card shows the room, the items counted, the folio as it stands, and the line that would be added. The front office manager approves postings and corrections; the housekeeping lead approves restock lists and storeroom issues.
What is kept for each posting or correction?
A receipt: the folio lines read, the count they were compared with, the stock balance, who approved, the write the PMS or inventory system accepted, and how to reverse it. Weekly variance per floor is built from the same receipts.
Does it ever post or correct a charge on its own?
No. It reads postings, counts, and stock and proposes. A charge is posted or adjusted only after approval, once, through the PMS connector. It never deletes a posting and never issues a refund.
Ask about Minibar Restock

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy