Vendors / Open source & self-hostable
POS Awesome
POS Awesome (ERPNext POS)
The highest-starred project in this batch (510 stars) and the deadest: the last release is Version-6-2-0 published 2024-02-09, the default branch's last commit is the same day, and the README still advertises ERPNext Version 14 support — roughly two and a half years stale with no successor fork showing meaningful traction, so listicles calling it a live ERPNext POS are wrong.
scored unknown legacy rubric
- Claims in scope
- 278
- Scored
- 45
- Assessed
- 44
- Unknown
- 234
- Not applicable
- 36
- Values challenged
- 0
unknown, never as no.Identity
- Owner
- ucraft-com / original author's project (GPL-3.0). Not a Frappe Technologies product — a third-party ERPNext app.
- Parent
- Frappe/ERPNext ecosystem
- Who it is for
- Existing ERPNext/Frappe deployments — mostly retail, pharmacy and small hospitality, heavily used in East Africa and the Middle East — wanting a faster POS front end than stock ERPNext POS
- Site
- https://github.com/ucraft-com/POS-Awesome
Pricing
transparency: unknown · unit: free app (GPL-3.0); cost is inherited from the underlying ERPNext hosting · processor lock-in: no
- Software
- Free and open source under GPL-3.0 as a Frappe app installed onto an existing ERPNext site. No published pricing of its own; total cost is whatever the ERPNext hosting or Frappe Cloud plan costs.
Capabilities
Every claim is binary and checkable. Grades: A primary documentation · B product documentation · C pricing or feature page · D marketing claim · E third-party reporting · F inference with no source. A yes on a differentiator claim requires A or B.
Order capture & FOH workflow
Provides a graphical floor-plan editor where an operator can draw sections, place tables of varying shape/capacity, save multiple floor-plan layouts per location, and assign sections to servers.
order-capture-floor-plan-editor
Not scored by this record.
Order lines can be tagged to a seat number at entry, and the check can be split by seat afterward without re-keying items.
order-capture-seat-level
Not scored by this record.
Items can be assigned to courses and held, with a fire-next-course action available from a handheld or terminal that releases only that course to the kitchen.
order-capture-coursing-hold-fire
Not scored by this record.
Supports splitting a check by item, by seat, by even N-way, and by arbitrary dollar/percentage amount, and merging checks or tables back together, including after partial payment.
order-capture-split-merge
Source (HEAD a86fd29): there is no check, table or seat model anywhere — a sale is a single ERPNext Sales Invoice cart, and the only order-holding constructs are held Drafts and Sales Orders. No operation divides one invoice by item, seat, N-way or amount, and none merges invoices or tables; every 'split'/'merge' hit in the code is String.split or bundled-library internals. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Opens a bar tab against a card pre-authorization with a configurable auth amount, supports incremental re-auth as the tab grows, and auto-closes stale tabs at end of day. differentiator
order-capture-bar-tab-preauth
Not scored by this record.
An open check can be transferred between servers, tables, and devices, and the transfer is recorded in an audit log naming both employees.
order-capture-transfer-audit
Not scored by this record.
Ships a first-party handheld ordering app running natively on the handheld device (not a remote/mirrored desktop session) that can send to kitchen and take a card payment tableside.
order-capture-native-handheld
Not scored by this record.
With the internet down, terminals and handhelds can still create orders, apply modifiers, send to kitchen, and tender cash, and the vendor publishes what does and does not work offline.
order-capture-offline-order-entry
Source (HEAD a86fd29, 2024-02-09): the Vue client has no offline layer — no service worker, no IndexedDB, no local order queue; invoice save/submit and item/customer lookups are live frappe.call requests to the ERPNext server, and the posa_local_storage toggle only caches item/customer lists for search speed. Order entry survives a WAN outage only when the ERPNext site is self-hosted on the local network, and the project publishes no statement of offline scope. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Guest QR at-table ordering writes items onto the same open check as server-entered items, rather than creating a separate order ticket. differentiator
order-capture-qr-same-check
Not scored by this record.
Offers a first-party self-order kiosk that renders the same menu and modifier tree as the POS with no separate menu build, and the vendor documents ADA/accessibility conformance for it. differentiator
order-capture-kiosk-first-party
Not scored by this record.
Supports drive-thru-specific order flow: order-point/pay-window/pickup-window separation, order sequencing or tandem-lane assignment, and pull-forward or parking-spot assignment.
order-capture-drive-thru
Not scored by this record.
Captures and reports drive-thru speed-of-service timers by segment (order, total, window) tied to individual orders.
order-capture-drive-thru-timers
Not scored by this record.
Vendor ships a first-party AI voice ordering agent for phone and/or drive-thru that injects orders directly as POS orders, or publishes a documented API partner program for third-party voice AI. differentiator
order-capture-voice-ai
Not scored by this record.
Supports order throttling: per-channel capacity limits per time slot with automatic quote-time extension when kitchen load exceeds a configured threshold. differentiator
order-capture-throttling
Not scored by this record.
Accepts future-dated/scheduled orders with a per-channel lead time and automatically injects them into the make queue at a computed fire time rather than on receipt.
order-capture-scheduled-orders
Future-dated capture exists: a posa_delivery_date custom field on the invoice and, when the POS Profile enables posa_allow_sales_order, before_submit maps the cart to a submitted ERPNext Sales Order carrying that delivery date (invoice.py create_sales_order/make_sales_order). The shortfall is everything after capture: the product has no make queue at all (no KDS or kitchen printing exists), no per-channel lead time, and no computed fire time — the future order just sits as an ERPNext Sales Order document until someone acts on it. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Provides a distinct catering order flow with quotes, deposits, balance-due tracking, and a delivery/event schedule separate from the standard order queue.
order-capture-catering
Not scored by this record.
Pushes an order-ready signal back to third-party marketplaces (e.g. DoorDash) from POS or KDS state, rather than requiring a tablet tap. differentiator
order-capture-order-ready-signal
Not scored by this record.
Voids, comps, and discounts require a reason code and can be gated behind role-based manager approval, with all instances recorded in an exception report.
order-capture-void-comp-controls
Not scored by this record.
Menu, modifiers & pricing engine
Payments & money movement
The POS operates with third-party payment processors of the merchant's choosing (documented list of supported processors/gateways) rather than requiring the vendor's in-house processing. differentiator
payments-processor-choice
Not scored by this record.
Vendor publishes card-processing pricing publicly (a specific flat rate or interchange-plus markup) rather than quote-only. differentiator
payments-published-rates
Not scored by this record.
Native dual-pricing / cash-discount mode stores two prices per item and prints both cash and card totals on the guest check and receipt. differentiator
payments-dual-pricing
Not scored by this record.
Surcharging engine automatically excludes debit and prepaid cards via BIN/product-code detection, enforces the network percentage cap, and can be enabled or disabled per location. differentiator
payments-surcharge-guardrails
Not scored by this record.
All first-party payment terminals accept EMV chip and NFC contactless including Apple Pay and Google Pay.
payments-emv-nfc
Software-only ERPNext app with no first-party terminals; README lists Mpesa mobile payment and cash as tender modes. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Accepts contactless payments directly on a phone (Tap to Pay on iPhone and/or Android tap-to-pay) with no separate card reader. differentiator
payments-softpos-tap-to-pay
Not scored by this record.
Vendor ships a handheld that takes EMV/NFC payment at the table, including tip prompt and check splitting, without carrying the card away.
payments-pay-at-table
Not scored by this record.
Guest can scan a QR code on the printed check or table tent to view and pay the check from their own phone, with the payment closing the check in the POS automatically. differentiator
payments-qr-guest-pay
Not scored by this record.
Supports both pre-auth-then-tip-adjust and on-device tip prompt flows, with a documented batch/adjust window and a manager screen for unadjusted tips.
payments-tip-adjust
Not scored by this record.
Configurable tip pooling and distribution rules (by hours worked, sales, role percentage, or points) that produce a per-employee tip allocation exportable to payroll. differentiator
payments-tip-pooling
Not scored by this record.
Card payments can be captured while the internet is down via store-and-forward, with configurable per-transaction and cumulative offline limits. differentiator
payments-offline-store-and-forward
Not scored by this record.
Vendor publicly documents who bears the loss when a stored offline transaction declines on reconnect, and surfaces a post-reconnect report of failed offline payments. differentiator
payments-offline-decline-liability
Not scored by this record.
First-party gift cards with real-time balance tracking, redeemable across every location in the group and through the online-ordering channel.
payments-gift-cards
No stored-value gift card exists in POS Awesome at commit a86fd29. The only construct named 'Gift Card' is a POS Coupon type (pos_coupon.json coupon_type options 'Promotional\nGift Card'). pos_coupon.py autoname gives it a random 10-character code (L22-L23); validate() forces 'self.maximum_use = 1' and throws 'Please select the customer.' when no customer is set (L26-L29); it must link a POS Offer flagged coupon_based (L30-L36), so its value is whatever discount that offer applies; check_coupon_code() rejects any other customer with 'Sorry, this coupon code cannot be used by this customer' (L117-L120) and any other company (L122-L123). create_coupon_from_referral() mints these automatically from Referral Codes (L44-L81). The doctype's complete field list (coupon_name, coupon_type, customer, coupon_code, pos_offer, valid_from, valid_upto, maximum_use, used, description, company, campaign, one_use, customer_name, mobile_no, email_id, referral_code) has no amount, value or balance field, and there is no redemption ledger. It is a single-use, customer-bound discount code, not a gift card: no issued value, no balance, and no online-ordering channel exists in the app to redeem it through. The same construct in core ERPNext (Coupon Code, 'Promotional'/'Gift Card') is scored no on the erpnext-pos record. TWO STORED BALANCES DO EXIST, AND NEITHER IS A GIFT CARD: (1) 'Use Customer credit' in Payments.vue lets the cashier redeem per-customer credit that posapp.py get_available_credit(customer, company) (L814-L860) builds from that customer's submitted Sales Invoices with negative outstanding_amount and Payment Entries with unallocated_amount, applied through a journal entry (redeeming_customer_credit, L698-L748); the wiki calls these credit notes. It is a named-customer account balance scoped to one company, not a card or code that can be sold or given. (2) 'Redeem Loyalty Points' in Payments.vue uses ERPNext's Loyalty Program. CONTROLS, tokenised whole-word over all 135 text files at the commit plus the 11-page wiki: giftcard, wallet, prepaid and stored 0. gift 12, all in the POS Coupon doctype, PosCoupons.vue, customer.py and posapp.py coupon creation. voucher/vouchers 14, all ERPNext accounting voucher_type/voucher_no. balance 19, all M-Pesa, opening/closing shift balance_details or translations. redeem/redeemed 52, all customer credit or loyalty points. POISON: 'Gift Card' labels a referral discount coupon, so a word-match reader would score yes. SCOPE: this covers POS Awesome's own coupon and tender surface; ERPNext core ships no stored-value gift card either (see erpnext-pos). https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_coupon/pos_coupon.py#L25-L29 · retrieved 2026-09-15 adversarially verified
House/on-account tabs with per-account credit limits, running balance, and periodic statement or invoice generation.
payments-house-accounts
Not scored by this record.
A single check can be settled with multiple tenders and split by seat, by item, by even shares, or by arbitrary amount, with no hard cap below eight ways.
payments-split-tender
Not scored by this record.
Voids, refunds, discounts, and no-sales require role-based authorization (manager PIN or approval) and write to an immutable audit log identifying the approver.
payments-refund-void-controls
README documents returns from POS as cash or customer credit; role-gated void approval with an immutable approver audit log is not documented. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
In-product dispute/chargeback dashboard that lists open disputes and allows evidence submission assembled from the POS transaction record. differentiator
payments-chargeback-tooling
Not scored by this record.
Tokenized card-on-file for a guest profile, reusable across online ordering, phone orders, and in-store, with no PAN stored by the merchant. differentiator
payments-card-on-file
Not scored by this record.
Vendor publishes its deposit schedule and offers a next-day or same-day/instant funding option. differentiator
payments-payout-timing
Not scored by this record.
Vendor provides point-to-point encryption and a current PCI DSS 4.x Attestation of Compliance / P2PE listing available to merchants on request.
payments-p2pe-pci4
Not scored by this record.
Kitchen & production
Items route to specific KDS stations by item, category, order type, or revenue center, with routing rules configurable per location without vendor involvement.
kitchen-station-routing
The complete doctype list (POS Opening/Closing Shift, POS Offer, POS Coupon, Delivery Charges, Referral Code, Mpesa doctypes) and the full Vue component list contain no KDS, kitchen-printer, station or routing artifact; 'kitchen' and 'kds' appear nowhere in the source. The only print path opens a browser window on the ERPNext Sales Invoice /printview, so there is nothing to route. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
An expo screen consolidates items from multiple prep stations into a single order view and only marks the order complete when every contributing station has bumped its items.
kitchen-expo-consolidation
No expo or kitchen display surface exists anywhere in the source — the product ships no kitchen screen of any kind (consistent with this record's hardware-kds: no), so there are no stations to consolidate and no bump state to track. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Items can be assigned to courses and held, then fired to the kitchen on demand from a server terminal, handheld, or expo screen. differentiator
kitchen-course-firing
Not scored by this record.
Per-item cook times are configurable and the KDS staggers item start/display times so that all items on an order finish simultaneously. differentiator
kitchen-prep-time-pacing
Not scored by this record.
Kitchen load throttling automatically paces or delays release of incoming digital orders, or extends quoted prep times, once a configurable order-volume or ticket-time threshold is crossed. differentiator
kitchen-order-throttling
Not scored by this record.
Pausing a store or 86ing an item from the POS/KDS propagates the pause or availability change back to connected third-party marketplaces (DoorDash, Uber Eats, Grubhub) automatically. differentiator
kitchen-channel-pause-propagation
Not scored by this record.
Bumping an order ready on the KDS sends an order-ready status event back to the third-party marketplace so couriers are dispatched on actual readiness. differentiator
kitchen-order-ready-callback
Not scored by this record.
KDS supports physical bump bars or programmable keypads in addition to touchscreen interaction, with documented supported models.
kitchen-bump-bar-hardware
No KDS of any kind ships — 'bump', 'kds' and 'kitchen' appear nowhere in the source (consistent with this record's hardware-kds: no) — so there is no kitchen screen for a bump bar or keypad to drive, and no supported-models documentation exists. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
An all-day view aggregates outstanding quantities per item (and per modifier) across all open tickets on the station.
kitchen-all-day-counts
Not scored by this record.
Configurable target cook times per station or order type, with visual color escalation and/or audible alert when a ticket exceeds target.
kitchen-sla-alerts
Not scored by this record.
If a KDS screen or kitchen printer goes offline, tickets automatically fail over to a designated backup printer or screen with no ticket loss. differentiator
kitchen-printer-fallback
Not scored by this record.
KDS continues to receive and display tickets from on-site POS terminals when the internet or cloud backend is unreachable. differentiator
kitchen-offline-operation
Not scored by this record.
Station screens can display item-level build/assembly detail (recipe steps, portioning, or full modifier breakout) rather than only the ticket line text. differentiator
kitchen-item-build-screens
Not scored by this record.
Sectioned/fractional topping placement (halves, quarters, specific sections) is rendered visually and unambiguously on the make-line screen or ticket. differentiator
kitchen-pizza-fractional-display
Not scored by this record.
A bumped ticket can be recalled/unbumped, and an individual item can be refired or reprinted without re-entering the order.
kitchen-recall-refire
Not scored by this record.
Edits made in the POS to an order already displayed in the kitchen visually flag the added, changed, or removed items on the live ticket. differentiator
kitchen-order-modification-alerts
Not scored by this record.
Bumping an order ready triggers a guest-facing notification — SMS/text, app push, or an order-status display board — without a separate product purchase. differentiator
kitchen-guest-ready-notification
Not scored by this record.
Waste, spoilage, and remakes can be logged directly at the kitchen/KDS screen with reason codes, and the entry depletes inventory.
kitchen-waste-logging
Not scored by this record.
Reports actual ticket and per-station times (average and percentile) sliced by daypart, station, and order channel, exportable to CSV or an API.
kitchen-speed-of-service-reporting
Not scored by this record.
Generates prep lists or predicted prep quantities from historical sales and forecast demand, surfaced to kitchen staff as a daily prep task list.
kitchen-prep-forecasting
Not scored by this record.
Delivery, dispatch & third-party channels
Product includes a native in-house driver module: drivers are first-class entities with clock-in/out, assignment state (in-store / on-run / returning), and per-driver run history reportable from the POS itself (not via a third-party add-on).
delivery-driver-roster
'driver', 'dispatch' and 'courier' appear nowhere in the source. The product's entire delivery footprint is the Delivery Charges doctype (a fee attached to the invoice) plus the posa_delivery_date field; there is no driver entity, no clock-in/out, no assignment state and no per-driver run history. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Provides a dedicated dispatch/expo screen showing undispatched orders, driver availability, and elapsed time per order, with multi-order run batching (assigning 2+ orders to one driver as a single run).
delivery-dispatch-board
The complete Vue surface (Navbar, Pay, ClosingDialog, Customer, Drafts, Invoice, ItemsSelector, Mpesa-Payments, NewAddress, OpeningDialog, Payments, Pos, PosCoupons, PosOffers, Returns, SalesOrders, UpdateCustomer, Variants) is cashier screens only — no dispatch or expo board, no undispatched-order view, no driver availability, no elapsed-time display and no run batching exist anywhere in the source. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Dispatch includes a live map view with geocoded stops and system-generated route sequencing (turn order optimization) for a multi-stop run, not just a static address list. differentiator
delivery-route-map
Not scored by this record.
Captures live driver GPS position from a driver-facing mobile app and surfaces it back to the dispatch screen. differentiator
delivery-driver-tracking
Not scored by this record.
Delivery areas can be defined as arbitrary map polygons or by drive-time isochrones, not solely as a radius or a ZIP/postcode list. differentiator
delivery-zones-polygon
Not scored by this record.
Each delivery zone carries its own independently configurable delivery fee, order minimum, and quoted promise time, applied automatically from the validated customer address.
delivery-zone-pricing
Source code at commit a86fd291 (retrieved 2026-09-15). POS Awesome has no delivery-zone object: 'zone', 'zones', 'radius' and 'geocode' occur 0 times as whole words across the repo and its 11-page wiki, and the only 'pincode' hit is a plain address field (api/posapp.py L1358). What it has is a named 'Delivery Charges' doctype (delivery_charges.json: label, company, default_rate, disabled, shipping_account, cost_center, a POS Profiles child table whose 'rate' overrides the default per profile). A custom Link field 'Delivery Charges' on the ERPNext Address doctype (fixtures/custom_field.json L989-L1012, Address-posa_delivery_charges) lets each customer address be tagged to one charge record by hand, so a set of addresses can share a separately priced charge. That is the only conjunct met, and only as a manually tagged address group rather than geography. get_applicable_delivery_charges (L58-L63) collects the charge tagged on every address linked to the customer and L89-L98 returns its profile rate or default_rate. If none of the customer's addresses is tagged, the name filter is never added (L69-L70) and every enabled charge for the company is returned. SHORTFALLS: (1) no per-charge order minimum, since the doctype has no minimum field; (2) no quoted promise time. posa_delivery_date is a cashier-entered delivery date on the order, not a per-zone promise; (3) no address validation or geography, because the address-to-charge link is a manual field; (4) not applied automatically at the POS. Invoice.vue L2846-L2874 only loads the applicable list for the selected customer, and L2881-L2886 sets delivery_charges_rate from the charge the cashier picks in the dropdown. The only automatic fill is fetch_from shipping_address_name.posa_delivery_charges on the desk Sales Invoice form (custom_field.json L4226), not the POS screen. POISON: 'minimum' hits are POS Offer qualifiers, not a delivery minimum. https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/delivery_charges/delivery_charges.py#L32-L100 · retrieved 2026-09-15 adversarially verified
Address entry is validated/geocoded against a mapping service at order time and rejects or flags out-of-zone addresses before the order is accepted.
delivery-address-validation
Not scored by this record.
Tracks per-delivery driver compensation inputs — mileage or distance driven per run, per-delivery flat reimbursement, and driver-retained tips — and exports them to payroll as separate reimbursement vs. wage lines. differentiator
delivery-driver-comp
Not scored by this record.
Provides a driver cash bank / settle-up flow that reconciles cash collected, orders assigned, and tips owed at end of shift, producing a per-driver over/short figure.
delivery-cash-reconcile
Not scored by this record.
Can hand a first-party order to an on-demand courier marketplace (DoorDash Drive, Uber Direct, Nash, Relay or equivalent) natively from the POS, with the courier quote and status returning into the order record.
delivery-daas-dispatch
Not scored by this record.
Supports hybrid dispatch: rules that automatically overflow an order to a DaaS courier when no in-house driver is available, out of zone, or past a wait threshold. differentiator
delivery-daas-fallback
Not scored by this record.
Offers direct, first-party certified API integrations with DoorDash, Uber Eats, and Grubhub marketplaces (vendor-owned, not solely resold through Otter/Deliverect/Chowly/ItsaCheckmate middleware). differentiator
delivery-3p-direct-integration
Not scored by this record.
Third-party marketplace orders inject automatically into the POS as normal tickets that fire to KDS/printers without tablet re-keying or manual accept.
delivery-3p-injection
Not scored by this record.
Marking an item or modifier 86'd in the POS pushes item-level out-of-stock status to connected third-party channels in near real time, and restores it on availability (DoorDash requires item and item-option 86ing of new POS partners).
delivery-86-sync
Not scored by this record.
Store can be paused/deactivated on each connected third-party marketplace from inside the POS with a timed auto-reactivation, rather than only from each marketplace's own tablet or portal.
delivery-store-pause
Not scored by this record.
Produces a third-party reconciliation report matching marketplace payout deposits to POS-recorded 3P sales, itemizing commission, marketing fees, refunds/adjustments, and identifying missing or unpaid orders. differentiator
delivery-3p-reconciliation
Not scored by this record.
Vendor exposes integration health to the operator — failed/rejected order injections, connection status per channel, and alerts on failure — rather than failing silently. differentiator
delivery-injection-error-visibility
Not scored by this record.
Guests receive a branded order status / driver tracking page or SMS link on the restaurant's own domain for first-party delivery orders, driven by real order and driver state.
delivery-tracking-page
Not scored by this record.
Quoted delivery promise times adjust dynamically from current kitchen load, driver availability, and zone drive time, rather than a fixed per-store constant. differentiator
delivery-promise-time
Not scored by this record.
Vendor documents explicit offline behavior for delivery: whether cash delivery orders, driver assignment, and driver settlement continue during an internet outage.
delivery-offline-behavior
Not scored by this record.
Digital ordering & guest-facing channels
Vendor ships a first-party, commission-free web ordering site on the restaurant's own branding/domain that writes orders directly into the POS with no per-order marketplace commission.
digital-first-party-web
The only web surface the app ships is the /posapp cashier page (posawesome/posawesome/page/posapp); templates/pages is empty. There is no guest-facing ordering site of any kind in the product — no cart, checkout or menu page a customer could reach — so no first-party web ordering exists to be commission-free or branded. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Vendor offers a branded native iOS and Android ordering app (published under the restaurant's own brand in the App Store/Play Store), not only a mobile web page or a shared multi-restaurant marketplace app. differentiator
digital-native-app
Not scored by this record.
Guests can create an account with saved addresses, saved (tokenized) payment methods, and one-tap reorder of a previous order across first-party channels.
digital-account-saved-payment
No guest-facing channel exists for an account to live on, and the source contains no tokenization or card-on-file construct ('tokeniz', saved-card and reorder constructs appear nowhere); tender is cashier-side cash, Mpesa and ERPNext payment modes. Customer addresses exist only as cashier-entered ERPNext Address records (NewAddress.vue), not a guest self-service account. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Digital checkout presents configurable or algorithmic upsell/cross-sell suggestions (rules-based add-ons or personalized recommendations from order history), with attach-rate reporting on those suggestions. differentiator
digital-upsell-engine
Not scored by this record.
Supports future/scheduled orders with per-daypart throttling — capacity limits on orders or items per time slot that automatically close slots when the kitchen is saturated.
digital-scheduled-pacing
Not scored by this record.
Single digital ordering flow supports pickup, curbside (with arrival check-in), dine-in/QR table ordering, and delivery, with mode-specific fees and prep timing.
digital-fulfillment-modes
Not scored by this record.
Supports guest-facing QR scan-to-order and/or scan-to-pay at the table that opens or attaches to the existing POS check, including splitting and tipping.
digital-qr-table
Not scored by this record.
Vendor ships a self-order kiosk running the same menu and modifier logic as the POS, with accessibility-compliant UI and unattended EMV payment. differentiator
digital-kiosk
Not scored by this record.
Supports group ordering: a shareable link where multiple participants add their own items to one order under a per-person or total spend cap, with split or single payment.
digital-group-ordering
Not scored by this record.
Offers a distinct catering ordering flow with separate catering menu/minimums, lead-time rules, quotes or proposals, deposits, and invoice/house-account or ACH payment terms. differentiator
digital-catering-portal
Not scored by this record.
Vendor offers AI voice phone ordering (native or a named certified partner) that answers inbound calls and injects the completed order into the POS without staff transcription. differentiator
digital-voice-ai-phone
Not scored by this record.
Supports AI voice ordering at the drive-thru lane, integrated with the POS menu/modifiers and with escalation-to-human handoff.
digital-drivethru-ai
Not scored by this record.
Supports conversational SMS or chat ordering/reordering (text-to-order or text-a-link) that lands in the POS.
digital-sms-ordering
Not scored by this record.
Supports Order with Google — the restaurant's direct ordering link is provisioned to the Google Business Profile as an ordering option (ideally set as 'Preferred by Business'), rather than leaving marketplace links as the only choice. differentiator
digital-google-order
Not scored by this record.
Supports Apple Business Connect ordering placement — an 'Order Food' custom action on the Apple Maps place card pointing at the vendor's first-party ordering flow.
digital-apple-business-connect
Not scored by this record.
Loyalty accrual and redemption work inside the first-party digital ordering flow using the same guest identity as in-store, not as a separate post-purchase enrollment.
digital-loyalty-attach
Not scored by this record.
Supports guest subscription / membership programs (recurring billing for a delivery-fee waiver, a per-period item entitlement, or a paid loyalty tier) managed in the platform.
digital-subscriptions
Not scored by this record.
Discounts, coupon codes, and loyalty offers are defined once and honored identically across POS, kiosk, and first-party digital channels, with channel eligibility controls.
digital-promo-parity
Not scored by this record.
Vendor documents that the operator owns and can export first-party guest records (email, phone, consented marketing status, order history) in bulk, without a fee or vendor approval. differentiator
digital-guest-data-ownership
Not scored by this record.
Digital checkout uses vendor-hosted fields or a hosted payment page so card data never touches the restaurant's page, with the vendor publishing PCI DSS 4.0 compliance (including the client-side script-integrity requirements effective March 2025) and supporting 3DS.
digital-checkout-pci-sca
Not scored by this record.
Digital channels support the same service-fee / dual-pricing / card-surcharge configuration as the POS, with the required guest-facing disclosure and correct handling of jurisdictions and card brands where surcharging is prohibited. differentiator
digital-surcharge-transparency
Not scored by this record.
Guest data, loyalty & marketing
Maintains a single guest profile that automatically merges transactions from in-store POS, first-party web/app ordering, and kiosk under one identity (phone or email match), with documented dedup/merge behavior.
guest-loyalty-unified-profile
The product has exactly one channel — the in-store cashier page — so there are no first-party web/app or kiosk transactions to merge. Guest identity is the host site's ERPNext Customer record selected by the cashier, and no dedup or merge behavior exists anywhere in the source or README ('dedup'/customer-merge constructs absent). https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Orders arriving from third-party marketplaces (DoorDash, Uber Eats, Grubhub) attach to a native guest profile with usable guest identity rather than landing as anonymous tickets. differentiator
guest-loyalty-thirdparty-identity-attach
Not scored by this record.
Supports at least two of points-per-dollar, visit/punch-count, and spend-tier accrual as configuration, without custom development or a bolt-on loyalty vendor.
guest-loyalty-accrual-models
README documents customer loyalty points plus POS Offers and coupons; only one accrual model is evidenced, not two. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Supports status tiers with automatic promotion and demotion driven by rolling-window spend or visit counts. differentiator
guest-loyalty-tiers
Not scored by this record.
Documents explicitly what loyalty lookup, accrual, and redemption do when the POS loses connectivity (queue-and-reconcile vs blocked). differentiator
guest-loyalty-offline-behavior
Not scored by this record.
Offer/discount engine exposes explicit stacking and precedence rules (exclusive vs combinable, order of application) as configuration. differentiator
guest-loyalty-offer-stacking-rules
Not scored by this record.
Offers can be issued to a dynamically defined audience (rules over recency, frequency, spend, or items purchased) rather than only broadcast to the whole list. differentiator
guest-loyalty-targeted-offers
Not scored by this record.
Automatically computes recency/frequency/monetary or equivalent lifecycle segments (new, regular, at-risk, lapsed, VIP) without the operator building the queries. differentiator
guest-loyalty-rfm-segmentation
Not scored by this record.
Ships triggered lifecycle automations (birthday, first-visit thank-you, lapsed win-back) as configurable always-on campaigns rather than one-off manual sends.
guest-loyalty-lifecycle-automation
The app stores a posa_birthday custom field on Customer, but nothing consumes it beyond returning it in the customer-info panel, and the app ships no guest messaging capability at all — no email/SMS send anywhere in the source, and hooks.py's scheduler_events block is commented out, so no triggered job of any kind runs. The 'campaign' references are ERPNext Campaign attribution on coupons/referral codes, not lifecycle sends. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Sends both email and SMS campaigns natively from the platform, not solely by handing the list to a third-party ESP. differentiator
guest-loyalty-native-email-sms
Not scored by this record.
Captures per-channel marketing consent with timestamp and source of consent, and honors revocation received by any reasonable means (not just the STOP keyword) across all channels.
guest-loyalty-consent-management
Not scored by this record.
Handles or explicitly documents A2P 10DLC brand and campaign registration required for the operator to send SMS through the platform.
guest-loyalty-10dlc-registration
Not scored by this record.
Reports redemption and incremental sales attributable to a specific campaign or offer, tying redeemed offers to actual check totals. differentiator
guest-loyalty-campaign-attribution
Not scored by this record.
Provides self-serve export of the full guest list and transaction history, including contact PII, via CSV or API, without a vendor fee or support ticket. differentiator
guest-loyalty-data-export-portability
Not scored by this record.
Triggers post-transaction feedback requests and routes responses by score, sending low scores to private service recovery and high scores toward public review sites. differentiator
guest-loyalty-review-capture-routing
Not scored by this record.
Includes a native referral mechanic with per-guest codes or links, attribution of the referred guest's first order, and two-sided rewards.
guest-loyalty-referral-program
Not scored by this record.
Issues an Apple Wallet or Google Wallet loyalty pass with push-updatable balance, as an alternative to requiring a branded app download. differentiator
guest-loyalty-wallet-pass
Not scored by this record.
Provides admin tooling to fulfill guest data access and deletion requests (CCPA/CPRA-style) including deletion propagation to loyalty and marketing records.
guest-loyalty-privacy-rights-tooling
Not scored by this record.
Enforces loyalty fraud controls such as redemption velocity limits, manager approval on manual point adjustments, and flagging of employee self-redemption, with an audit log.
guest-loyalty-redemption-fraud-controls
Not scored by this record.
Vendor documents AI/ML-generated recommendations for offer content, target audience, or send timing (claim-level; verify it is a shipped product feature, not a roadmap statement). differentiator
guest-loyalty-ai-offer-recommendation
Not scored by this record.
Offers native stored-value/gift card balances tied to the same guest profile and redeemable across all locations of the brand.
guest-loyalty-stored-value-gift
Not scored by this record.
Labor & workforce
Employees clock in and out at the POS terminal using a PIN, badge, or card, with no separate time-clock hardware required.
labor-clock-in-at-pos
No employee clock-in/out at the POS Awesome terminal. At commit a86fd291 the app's complete doctype set is delivery charges, M-Pesa C2B/payment register, POS Opening Shift and POS Closing Shift (with details and taxes), POS Coupon, POS Offer, payment entry reference, referral code and sales invoice reference. It has no timecard, attendance or employee entity. The POS terminal is a fixed set of Vue components (Navbar, Pos, Invoice, Payments, OpeningDialog, ClosingDialog, Customer, Returns, SalesOrders, Variants and others) with no time-clock screen. The only timestamped per-person record is POS Opening Shift. It links `user` (label 'Cashier', a Frappe User and not an Employee) with a Period Start Date datetime, an opening cash balance per mode of payment and a Draft/Open/Closed status. It is a cash-drawer session, not a time punch: there is no PIN, badge or card and no hours or payroll output. Its Period End Date is a date only, and the wiki's End-of-Shift-Day page describes the closing as a per-payment-mode cash count, with an optional manager close and an unclosed shift 'still continues, even till the next day'. A tokenised whole-word census of all 145 tracked files in the repo plus the 11-page wiki found 0 each for clock, clockin, clockout, timeclock, checkin, checkout, attendance, timesheet, employee(s), punch, hrms, hr, pin, rfid, hours, wage and payroll, and 0 for the phrases 'employee checkin' and 'shift type'. 'shift' (311) is the drawer session, 'card' (167) is payment/gift-card/card-view, 'login'/'logout' are Frappe account session links and 'badge' is a UI component. hooks.py declares no required_apps, so Frappe HR is not part of the product. An operator can install HRMS separately and record Employee Checkin from the Frappe desk or HR app, but that is outside POS Awesome's terminal. This contrasts with URY, where HRMS is a mandatory install. https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_opening_shift/pos_opening_shift.json#L28-L37 · retrieved 2026-09-15 adversarially verified
Captures a photo at punch (or performs facial verification) attached to the timecard entry, with a photo-only mode available that stores no biometric template. differentiator
labor-photo-punch-verification
Not scored by this record.
Records time punches while the POS is offline and reconciles them on reconnect without loss or duplicate entries, with the behavior documented. differentiator
labor-offline-time-punch
Not scored by this record.
Permissions are grantable per discrete action (void, comp, discount, refund, drawer open, price change, report access) per role and per location, not limited to fixed cashier/manager/admin tiers.
labor-granular-rbac
Discrete-action gates exist, but as POS Profile custom fields — posa_allow_delete, posa_allow_return, posa_allow_user_to_edit_rate, posa_allow_user_to_edit_item_discount, posa_allow_user_to_edit_additional_discount, posa_max_discount_allowed, posa_allow_credit_sale, posa_allow_print_draft_invoices — which are per-profile booleans applying uniformly to every user of that profile, not per-role grants; doctype and report access falls back to Frappe's fixed role list. No comp, void-approval or drawer-open permission exists. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Manager overrides and approvals are attributed to the individual approver and written to an immutable audit trail queryable after the fact.
labor-manager-override-audit
The source contains no override or approval flow of any kind — searching for override/approve/supervisor/PIN constructs finds none. Restricted actions are simply enabled or disabled in advance per POS Profile, so there is no individual approver to attribute and no override event to audit; Frappe's generic document versioning is not an override trail. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Builds and publishes employee shift schedules inside the same platform that holds the timekeeping data, rather than requiring a third-party scheduling app. differentiator
labor-native-scheduling
Not scored by this record.
Generates recommended staffing levels or labor hours by daypart from the operator's own POS sales history, not just a static template. differentiator
labor-demand-labor-forecast
Not scored by this record.
Displays labor cost as a percentage of sales in real time during service on a manager view or POS, not only in end-of-day or next-morning reports. differentiator
labor-realtime-labor-percent
Not scored by this record.
Warns or blocks at clock-in when an employee is approaching or would cross a configured overtime threshold, before the overtime is incurred. differentiator
labor-overtime-prevention
Not scored by this record.
Configures meal and rest break rules per state or jurisdiction, prompts required break attestation, and flags missed breaks for premium pay. differentiator
labor-break-compliance-by-state
Not scored by this record.
Enforces minor-labor restrictions (age-based maximum hours, prohibited time windows, school-day limits) at both scheduling and clock-in.
labor-minor-labor-rules
Not scored by this record.
Computes tip pooling and tip-outs automatically per shift from configurable rules (percentage of sales, hours worked, points, or role), rather than requiring a manual spreadsheet.
labor-tip-pooling-rules
Not scored by this record.
Retains a per-shift, per-employee record of tips received, amounts contributed to the pool, and amounts distributed from the pool, exportable for audit.
labor-tip-distribution-audit-trail
Not scored by this record.
Payroll export separates cash from charged qualified tips and carries a Treasury tipped-occupation code, supporting the W-2 Box 12 code TP and Box 14b reporting required for tax year 2026. differentiator
labor-qualified-tips-w2-reporting
Not scored by this record.
Vendor processes payroll itself as a first-party product (tax filing and direct deposit), as opposed to exporting to a third-party payroll provider only. differentiator
labor-native-payroll
Not scored by this record.
Exports timecards, wages, and tips in documented formats or via direct integration for at least two major payroll providers (e.g. Gusto, ADP, Paychex, QuickBooks).
labor-payroll-export-formats
Not scored by this record.
Employees can request shift swaps or claim open shifts in a self-service app, subject to a manager approval workflow that enforces overtime and role eligibility. differentiator
labor-shift-swap-workflow
Not scored by this record.
Reports per-employee sales performance metrics (average check, items or category attachment rate, void and comp rate) by server or cashier. differentiator
labor-server-performance-metrics
Not scored by this record.
Inventory, purchasing & cost control
Supports multi-level recipe/BOM costing where a recipe can contain sub-recipes (prep items) and plate cost recalculates automatically when any component ingredient's cost changes.
inventory-recipe-bom-costing
CLAIM: multi-level recipe/BOM costing with sub-recipes, plate cost recalculating automatically when a component cost changes. VERDICT: unknown -> partial/A. HOST-PLATFORM CREDIT, same basis as this record's verified extensibility-webhooks-push and extensibility-oauth-partner-apps (partial/A credited to Frappe v14). Org slug confirmed via api.github.com/repos/ucraft-com/POS-Awesome: fork:false, default branch develop = a86fd291; branch version-14 (f0a7e229, the branch the README installs) is 1 merge commit ahead, 0 behind, with ZERO changed files (compare API), so a86fd291 is the shipped tree. POS Awesome census: git tree API truncated:false, 194 blobs, 134 text blobs fetched from raw.githubusercontent.com; README feature 1 is "Supports Erpnext Version 14". Host trees read: frappe/erpnext branch version-14 head bd7e5b3e and frappe/frappe version-14 head be2f6245. EVIDENCE (host, ERPNext v14): manufacturing/doctype/bom/bom.py L28 "class BOMTree" and L55-56 "if item.bom_no: child = BOMTree(item.bom_no, ...)" -- a BOM line can itself carry a BOM, so sub-assemblies (sub-recipes) nest; bom.py update_cost() L415-424 "# update parent BOMs ... select distinct parent from `tabBOM Item` where bom_no = %s ... update_cost(from_child_bom=True)" -- a child cost change propagates to parents; manufacturing_settings.json L110-113 field update_bom_costs_automatically, label "Update BOM Cost Automatically", description "Update BOM cost automatically via scheduler, based on the latest Valuation Rate/Price List Rate/Last Purchase Rate of raw materials", default 0; hooks.py L462-464 registers bom_update_tool.auto_update_latest_price_in_all_boms under scheduler "daily_long", which (bom_update_tool.py L37-39) acts only if that setting is on. SHORTFALLS (why partial): (1) POS Awesome itself has no recipe/BOM surface -- tokenised word-boundary controls over its 134 text blobs: bom 0, "bill of materials" 0, recipe 0, stock_reconcil* 0; the one valuation_rate hit (api/posapp.py L1755) is a generated test value; (2) the host feature is a MANUFACTURING BOM in the ERP desk, not a menu recipe tied to the POS item; (3) recalculation is a once-daily scheduled job, OFF by default, not an immediate recompute on cost change. Retrieved 2026-09-17. https://raw.githubusercontent.com/frappe/erpnext/bd7e5b3e0589db07e45e49cbe1b250b62ad868d3/erpnext/manufacturing/doctype/manufacturing_settings/manufacturing_settings.json · retrieved 2026-09-17 adversarially verified
Stores purchase unit, recipe unit, and count unit per item with explicit conversion factors, plus a yield/waste percentage applied to raw-to-usable conversion.
inventory-unit-conversion-yields
README documents UOM-specific barcode and pricing plus weighted/scale product sales; yield and waste percentages are not documented. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Produces a theoretical-vs-actual usage variance report per item for a defined count period, showing theoretical usage from POS sales times recipe, actual usage from counts plus receipts, and the variance in both units and currency. differentiator
inventory-theoretical-vs-actual
Not scored by this record.
Depletes ingredient on-hand quantities in near real time as orders are fired at the POS, including depletion driven by modifier selections, not only in an end-of-day batch. differentiator
inventory-realtime-depletion
Not scored by this record.
Automatically 86s (marks unavailable) menu items on the POS, online ordering, and connected third-party delivery menus when a component ingredient hits zero or a configured threshold. differentiator
inventory-86-auto-sync
Not scored by this record.
Supports full physical inventory, ad-hoc spot counts of a subset, and scheduled recurring cycle counts, with each count's variance recorded as separate history rather than overwriting prior counts.
inventory-count-modes
CLAIM: full physical counts, ad-hoc spot counts of a subset, scheduled recurring cycle counts, each count's variance kept as separate history. VERDICT: unknown -> partial/A (matches erpnext-pos, partial/A on v16). HOST-PLATFORM CREDIT, same basis as this record's verified extensibility-webhooks-push and extensibility-oauth-partner-apps (partial/A credited to Frappe v14). Org slug confirmed via api.github.com/repos/ucraft-com/POS-Awesome: fork:false, default branch develop = a86fd291; branch version-14 (f0a7e229, the branch the README installs) is 1 merge commit ahead, 0 behind, with ZERO changed files (compare API), so a86fd291 is the shipped tree. POS Awesome census: git tree API truncated:false, 194 blobs, 134 text blobs fetched from raw.githubusercontent.com; README feature 1 is "Supports Erpnext Version 14". Host trees read: frappe/erpnext branch version-14 head bd7e5b3e and frappe/frappe version-14 head be2f6245. EVIDENCE (host, ERPNext v14 stock_reconciliation.json): L54-58 "fieldname": "purpose", "options": "\nOpening Stock\nStock Reconciliation", reqd 1; free-form items table with scan_barcode/scan_mode (L22, L162), per-document difference_amount (L124) and expense_account (L106); "is_submittable": 1 (L184) -- a full count of a warehouse or a count of any subset is its own submitted document with its own variance posting, i.e. separate history, not an overwrite. SHORTFALL: no scheduled recurring cycle count -- the doctype has no schedule field and "allow_auto_repeat" occurs 0 times in stock_reconciliation.json, so Frappe Auto Repeat is not enabled on it out of the box; and POS Awesome itself ships no count surface (tokenised controls over its 134 text blobs: stock_reconcil* 0, stocktake 0, "stock count" 0, cycle 0; physical 6, all in license.txt GPL text -- POISON). Retrieved 2026-09-17. https://raw.githubusercontent.com/frappe/erpnext/bd7e5b3e0589db07e45e49cbe1b250b62ad868d3/erpnext/stock/doctype/stock_reconciliation/stock_reconciliation.json · retrieved 2026-09-17 adversarially verified
Provides a mobile/tablet counting app supporting barcode or QR scanning that continues to accept counts with no network connectivity and syncs on reconnect.
inventory-mobile-count-offline
Not scored by this record.
Ships pre-built electronic vendor catalog and order-transmission integrations with named broadline distributors (e.g. Sysco, US Foods, Performance Food Group) that send purchase orders and receive invoices electronically rather than by emailed PDF. differentiator
inventory-vendor-catalogs-edi
Not scored by this record.
Ingests supplier invoices from photo, PDF, or email and extracts line-item detail (item, quantity, unit, price) into the inventory ledger without manual line entry. differentiator
inventory-invoice-ocr
Not scored by this record.
Tracks per-item purchase price history across invoices and alerts when a received price exceeds the prior or contracted price by a configurable threshold. differentiator
inventory-price-change-alerts
Not scored by this record.
Maintains par levels per item per location and generates suggested purchase order quantities from on-hand versus par, with at least one mode driven by a sales forecast rather than a static par. differentiator
inventory-par-auto-suggest
Not scored by this record.
Provides a structured waste/spoilage logging workflow with reason codes that debits inventory and reports waste cost separately from usage variance.
inventory-waste-logging
Not scored by this record.
Tracks expiration or use-by dates on received and prepped items and surfaces an expiring-soon report or alert before spoilage.
inventory-shelf-life-expiry
Not scored by this record.
Supports partial-bottle liquid inventory by weight (scale integration) or by bottle fraction for bar and beverage counting.
inventory-bar-partial-bottle
Not scored by this record.
Exports period COGS and accounts-payable invoice detail in a named accounting system's import format (e.g. QuickBooks, Sage Intacct, NetSuite) with GL account mapping configurable per item category.
inventory-cogs-gl-export
Not scored by this record.
Inventory and recipe costing are delivered natively by the POS vendor rather than requiring a separately-contracted third-party product (e.g. MarginEdge, MarketMan, Restaurant365) to function. differentiator
inventory-native-not-partner
Not scored by this record.
Reporting, BI & data access
Provides a live sales dashboard reflecting transactions within minutes of the sale, accessible from both a browser and a mobile app off-premise.
reporting-realtime-dashboard
The app ships zero report or dashboard artifacts of its own (no report/ or dashboard/ directory in the package). Sales post immediately as standard ERPNext Sales Invoices, so the host ERPNext site's browser-based reports and dashboards reflect them in real time from anywhere the site is reachable — but there is no first-party live sales dashboard, no mobile app, and the posa_allow_submissions_in_background_job option defers invoice submission to a queue. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Generates a daily close-out/EOD report reconciling gross sales, net sales, tax, tips, discounts, refunds, tender types, and expected cash deposit in one document.
reporting-eod-closeout
POS Awesome's POS Closing Shift (source at commit a86fd29, v6.2.0) is a per-cashier shift close document. make_closing_shift_from_opening (L138-L266) takes every submitted Sales Invoice linked to the shift's POS Opening Shift and adds up grand_total, net_total and total_qty (L180-L182). It groups taxes by account_head and rate (L184-L201). It builds one expected_amount per mode of payment, starting from the opening balance, subtracting change from the cash mode (L216) and adding received Payment Entries (L231-L259). The POS Closing Shift Detail child table (pos_closing_shift_detail.json) has mode_of_payment, opening_amount, closing_amount, expected_amount and difference, and validate() sets difference = closing_amount - expected_amount (L45-L54). In ClosingDialog.vue the cashier types a Closing Amount for each tender; the POS Profile flag hide_expected_amount can hide the expected and difference columns for a blind close. The wiki's End-of-Shift-Day page says: 'The Cashier is required to key in the actual amount she has in hand for each payment mode in the "Closing Amount" column.' closing_shift_details.html prints Sales Summary (Grand Total, Net Total, Total Quantity), Mode of Payments and Taxes. So tax, tender types and expected vs counted per tender are met. Shortfalls: (1) There is no gross sales before discounts. Grand Total is ERPNext's invoice total after discounts and including tax, and Net Total is after discounts and before tax. (2) There is no discount total. The closing doctype's fields are period dates, posting date, company, POS profile, cashier, POS transactions, payment reconciliation, grand total, net total, total quantity, taxes, opening shift and POS payments, and no discount token appears in any pos_closing_shift* file or in ClosingDialog.vue. (3) Refunds are not reported separately. Returns do exist (Returns.vue sets is_return = 1 against an original invoice), but get_pos_invoices (L97-L114) selects every submitted invoice in the shift without filtering on is_return, so returns are netted into the totals and tenders without a line of their own. (4) There are no tips: tip, tips and gratuity have zero word-level hits in the repo and wiki, and the only raw 'tip' match is a binary PNG. (5) Scope is one cashier's opening-to-closing shift (validate() rejects a second closing per user and opening shift), not a store-wide daily close across terminals. A store-level daily view would come from ERPNext desk reports, which are not credited here. https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_closing_shift/pos_closing_shift.py#L138-L266 · retrieved 2026-09-15 adversarially verified
Provides a product mix (PMIX) report at individual menu item AND modifier level with quantity, gross and net sales, filterable by daypart and revenue center.
reporting-pmix-modifier-level
Modifier-level PMIX is structurally impossible here: the app has no modifier data model and ships no reports at all. Item-level sales analysis exists only through generic ERPNext Sales Invoice reports, which carry no daypart or revenue-center dimension of POS Awesome's making. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Produces an audit report of comps, voids, discounts, and price overrides attributed to the employee who applied them and the manager who approved them, with reason codes and timestamps.
reporting-comps-voids-audit
Not scored by this record.
Reports cash over/short per drawer, per shift, and per employee, comparing counted cash to expected cash from tendered transactions and paid-outs.
reporting-cash-over-short
Not scored by this record.
Reports sales per labor hour and labor cost as a percentage of sales by hour, by department, and by employee, using actual clocked hours from the POS time clock.
reporting-labor-productivity
Not scored by this record.
Reports per-server metrics including average check, items per check, attachment rate for named categories, and tips as a percentage of sales. differentiator
reporting-server-scorecards
Not scored by this record.
Reports revenue and margin by fulfillment channel — dine-in, direct online, first-party delivery, and each third-party marketplace separately — net of marketplace commission fees. differentiator
reporting-channel-profitability
Not scored by this record.
Supports scheduling any report for automatic recurring delivery by email or to a shared destination on a defined cadence and recipient list.
reporting-scheduled-delivery
Not scored by this record.
Publishes a documented public REST or GraphQL API covering orders, payments, menu, and labor data, with self-service developer credentials obtainable without a signed partner agreement. differentiator
reporting-public-api
Not scored by this record.
Emits outbound webhooks for order and payment lifecycle events to a customer-supplied endpoint, with documented retry behavior and payload signature verification. differentiator
reporting-webhooks
Not scored by this record.
API and raw-data access are included in the standard subscription rather than gated behind an additional per-location fee, revenue share, or enterprise-only contract. differentiator
reporting-api-not-upcharged
Not scored by this record.
Core reporting beyond basic sales summaries — labor vs sales, PMIX, comps/voids audit, multi-location comparison — is available on the entry-level paid plan rather than requiring a higher tier or an add-on analytics SKU. differentiator
reporting-tier-paywall
Not scored by this record.
Documents a historical retention window of at least 24 months of transaction-level detail queryable in the reporting UI, with no silent truncation or archive retrieval fee. differentiator
reporting-history-retention
Not scored by this record.
Sends proactive push or email alerts when an operator-configured metric breaches a threshold or deviates from its historical pattern (e.g. void spike, sales below forecast, discount rate anomaly). differentiator
reporting-anomaly-alerts
Not scored by this record.
Offers a natural-language query or AI assistant that answers ad-hoc questions against the operator's own sales and labor data and returns a figure or chart, not a generic help-article response.
reporting-nl-query
Not scored by this record.
Reports guest-level analytics including new versus returning guest counts, visit frequency, and lifetime spend cohorts tied to identifiable guest records from loyalty or online ordering. differentiator
reporting-guest-cohorts
Not scored by this record.
Produces a forward sales forecast at daypart or hourly granularity from the location's own history, exposed in the reporting UI and consumable by scheduling or ordering workflows. differentiator
reporting-sales-forecast
Not scored by this record.
Generates payroll- and tax-ready tip reporting: declared versus charged tips per employee, tip pool distribution detail, and a tax liability summary by jurisdiction.
reporting-tip-tax-compliance
Not scored by this record.
Multi-location, franchise & enterprise governance
Supports a named organizational hierarchy of at least three levels (e.g. enterprise > region/group > location) as a first-class object that reporting and permissions can be scoped to, not just a flat list of locations.
multi-location-org-hierarchy
CLAIM: named hierarchy of >=3 levels as a first-class object that reporting and permissions can be scoped to. VERDICT: unknown -> partial/A. HOST-PLATFORM CREDIT, same basis as this record's verified extensibility-webhooks-push and extensibility-oauth-partner-apps (partial/A credited to Frappe v14). Org slug confirmed via api.github.com/repos/ucraft-com/POS-Awesome: fork:false, default branch develop = a86fd291; branch version-14 (f0a7e229, the branch the README installs) is 1 merge commit ahead, 0 behind, with ZERO changed files (compare API), so a86fd291 is the shipped tree. POS Awesome census: git tree API truncated:false, 194 blobs, 134 text blobs fetched from raw.githubusercontent.com; README feature 1 is "Supports Erpnext Version 14". Host trees read: frappe/erpnext branch version-14 head bd7e5b3e and frappe/frappe version-14 head be2f6245. EVIDENCE: erpnext v14 setup/doctype/company/company.json -- is_group Check (L130-132), parent_company Link (L150-154), lft/rgt/old_parent nested-set fields (L99-101): Company is an arbitrarily deep tree. PERMISSIONS: frappe v14 core/doctype/user_permission/user_permission.py L110-113 "if meta.is_nested_set() and not perm.hide_descendants: decendants = frappe.db.get_descendants(perm.allow, perm.for_value) ... add_doc_to_perm(perm, doc, False)" -- a User Permission on a group Company cascades to every descendant. That reaches POS Awesome: its opening dialog (api/posapp.py L36-45 get_opening_dialog_data) lists Company and POS Profile via frappe.get_list, which applies user permissions, and POS Profile carries company (L43). REPORTING: erpnext v14 accounts/report/consolidated_financial_statement/consolidated_financial_statement.js L127-131 filter accumulated_in_group_company, label "Accumulated Values in Group Company". SHORTFALLS: (1) the hierarchy nodes are LEGAL-ENTITY Companies with their own books, so enterprise > region > store means one Company per store; (2) POS Awesome's own reporting (per-cashier POS Closing Shift) has no hierarchy roll-up -- rollup exists only in ERPNext desk financial reports; (3) POS Awesome adds no hierarchy object of its own (company 284 hits are the flat Company link; is_group 6 hits are Item Group / Customer Group / Territory filters, e.g. UpdateCustomer.vue L228, L246 -- POISON). Retrieved 2026-09-17. https://raw.githubusercontent.com/frappe/frappe/be2f6245febabc75f48196c250938d733aa9054f/frappe/core/doctype/user_permission/user_permission.py · retrieved 2026-09-17 adversarially verified
Supports price tiers/zones so one menu item carries different prices per location group, per order channel, and per daypart without duplicating the item record.
multi-location-price-zones
README documents customer and customer-group price lists and batch-based pricing; per-location, per-channel and per-daypart tiers are not documented. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Provides above-store reporting that aggregates sales, labor, discounts, voids, and item mix across any selected set of locations in one view, with store-vs-store ranking and variance flags.
multi-location-consolidated-reporting
Not scored by this record.
Gift cards issued at one location are redeemable at any other location in the brand, with a reported outstanding-liability balance and inter-store settlement/redemption reconciliation between owners.
multi-location-cross-location-giftcard
Not scored by this record.
A single customer loyalty profile, balance, and stored order history is shared across all locations in the brand rather than being per-location.
multi-location-cross-location-loyalty
Not scored by this record.
A single location/terminal can operate two or more distinct brands or virtual brands with separate menus, receipts/branding, and separately reportable revenue, on the same hardware and drawer. differentiator
multi-location-multi-brand
Not scored by this record.
Tax configuration is per-location with support for multiple simultaneous tax rates, jurisdiction-specific rules (e.g. prepared-food vs grocery, inclusive vs exclusive tax), and per-location tax exemptions.
multi-location-multi-tax-jurisdiction
Not scored by this record.
Labor rules (overtime, break enforcement, predictive-scheduling compliance) are configurable per location or location group and enforced at the terminal, not just reported after the fact.
multi-location-central-labor-policy
Not scored by this record.
Hardware & physical footprint
The POS software runs on commodity off-the-shelf hardware (standard iPads, Android tablets, or PCs) that the operator can buy from a third party, rather than only on vendor-supplied proprietary terminals. differentiator
hardware-commodity-devices
Not scored by this record.
Vendor documentation names the specific client operating systems supported (iOS/iPadOS, Android, Windows, Linux/web) and states minimum OS versions and device specs.
hardware-os-platforms
The claim asks whether the documentation names supported client operating systems and states minimum OS versions and device specs. POS Awesome's documentation, all of it, is README.md at commit a86fd291 plus an 11-page GitHub wiki at wiki commit 9f122813. It names no client OS, browser or browser version, and no device spec. Its only platform statement is README L12, '1. Supports Erpnext Version 14', which is a server-app dependency. The install section (L54-L59) is bench commands for the server only. POS Awesome is a Vue/Vuetify page inside the Frappe desk, so it runs in a web browser. But no browser is named, which is the difference from opensourcepos (partial, names Firefox 34+ / Chrome 40+) and odoo-pos (partial, names Chromium 142+ browsers). It matches peers URY (no/B) and erpnext-pos (no/B), which are also browser apps whose docs name only server requirements. Checks: I searched the README, the wiki and the non-license source as whole words, ignoring case. chrome, chromium, firefox, safari, android, ios, ipad, windows, linux, macos, ubuntu and tablet each have zero hits. False positives found: 'browser' appears only as the 'Use Browser Local Storage' POS Profile setting (custom_field.json L4459, its pt.csv translation, wiki Understanding-POS-Profile L55), which is a caching switch, not a list of supported browsers. 'mobile' is always a customer phone-number field or 'Mpesa mobile payment'. 'requirements' is 'bench setup requirements' and the GPL text. The README shortcut notation 'CTRL or CMD + S' (L94-L98) mentions the Mac key but does not say macOS is supported. https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/README.md#L12 · retrieved 2026-09-15 adversarially verified
Offers a purpose-built handheld ordering device with an integrated card reader (not a phone case add-on), with published drop rating and IP ingress rating.
hardware-handheld-purpose-built
Not scored by this record.
The handheld supports hot-swappable or field-replaceable batteries, or the vendor publishes a rated battery life for a full shift. differentiator
hardware-handheld-battery-swap
Not scored by this record.
Handhelds support cellular/LTE connectivity as a documented fallback when store Wi-Fi drops, either built into the device or via a vendor-supplied failover.
hardware-handheld-lte
Not scored by this record.
Terminals continue to take orders, print to kitchen, and record cash sales with the internet down, and the vendor documents explicitly which functions degrade (card auth, loyalty lookup, refunds).
hardware-offline-mode
The browser client has no offline layer — no service worker, no IndexedDB, no queued orders; posa_local_storage only caches item/customer lists for search. Order taking, cash sales and receipt printing survive an internet outage only when the ERPNext site is self-hosted on the local network (a deployment topology, not a terminal capability); kitchen printing does not exist in the product at all, and the vendor publishes no statement of which functions degrade offline. Those are the shortfalls carrying the partial, consistent with this record's order-capture-offline-order-entry. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Sells or supports a dedicated kitchen display system with bump-bar or touch input, station routing, and course/fire timing, as a first-party product rather than an integration-only dependency.
hardware-kds
The README enumerates 29-plus features with no kitchen display; it is a retail-oriented POS front end for ERPNext. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Offers a self-order kiosk running the same menu and modifier engine as the POS, in both countertop and freestanding form factors, with integrated payment and accessibility (ADA) compliance documented. differentiator
hardware-kiosk
Not scored by this record.
Supports drive-thru-specific hardware: outdoor digital menu boards, order confirmation displays, and speaker/headset integration, with a documented timer/speed-of-service measurement.
hardware-drive-thru
Not scored by this record.
Works with standard ESC/POS thermal receipt and kitchen printers from more than one manufacturer (e.g. Epson and Star), including LAN/Ethernet printers, rather than only vendor-branded printers.
hardware-printer-compatibility
Not scored by this record.
Supports the standard peripheral set — cash drawers (including multi-drawer per terminal), barcode scanners, scales for by-weight items, and customer-facing displays — with a published compatibility list.
hardware-peripherals
Not scored by this record.
Card entry happens on a PCI-listed PTS device using validated point-to-point encryption, so the POS application and tablet stay out of PCI scope; the vendor states the merchant's SAQ type.
hardware-p2pe-terminal
Not scored by this record.
Supports contactless acceptance directly on a commodity phone or tablet (Tap to Pay on iPhone / Tap to Pay on Android) with no separate reader. differentiator
hardware-tap-to-phone
Not scored by this record.
Hardware prices are published per SKU on the vendor's public site, rather than quote-only. differentiator
hardware-pricing-transparency
Not scored by this record.
Hardware can be purchased outright (owned) as an alternative to a mandatory lease or subscription-bundled rental, and the vendor states which. differentiator
hardware-ownership-vs-lease
Not scored by this record.
Vendor documentation confirms whether hardware purchased from the vendor remains usable with other software after cancellation, i.e. it is not software-locked or remotely bricked. differentiator
hardware-usable-after-churn
Not scored by this record.
Publishes a hardware warranty term and a replacement/advance-exchange SLA with a stated turnaround (e.g. next-business-day depot swap). differentiator
hardware-rma-sla
Not scored by this record.
Staff can run the ordering or payment app on their own personal phone (BYOD) with a documented permission and security model.
hardware-byod
Not scored by this record.
Provides a remote device-management console showing each terminal, printer, and KDS as online/offline, with remote reboot, software-version visibility, and staged rollout of updates. differentiator
hardware-remote-device-management
Not scored by this record.
Integrates with specialty beverage hardware — self-pour tap walls, flow meters, or liquor pour spouts — such that pours post to a POS tab automatically.
hardware-selfpour-scales
Not scored by this record.
Supports inbound caller ID hardware or a telephony integration that pops the customer record and order history at the POS on an incoming call.
hardware-callerid-integration
Not scored by this record.
Integrations, API & extensibility
Public, self-serve API reference documentation is readable without a signed partner agreement, NDA, or sales call.
extensibility-public-api-docs
Full GPL-3.0 source is public and it inherits Frappe's public REST API, but POS Awesome publishes no API reference of its own. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
API access is included in the base subscription at no additional per-location fee, surcharge, or upgraded plan requirement. differentiator
extensibility-api-access-cost
Not scored by this record.
A free sandbox or test environment with seeded data is available to developers without owning a paid production account. differentiator
extensibility-free-sandbox
Not scored by this record.
Third-party apps authenticate via OAuth 2.0 with scoped, operator-granted, individually revocable permissions (not shared static API keys or credential sharing).
extensibility-oauth-partner-apps
Credited to the host platform: POS Awesome adds no OAuth of its own (its only OAuth reference, m_pesa.py, is POS Awesome acting as a client-credentials CLIENT of Safaricom M-Pesa), but it runs inside Frappe v14, whose OAuth 2.0 provider authenticates bearer requests into every whitelisted method, POS Awesome's included. At commit be2f6245, frappe/integrations/oauth2.py serves authorize, get_token, revoke_token and introspect_token endpoints, and the OAuth Client doctype offers the Authorization Code and Implicit grants. authorize() shows an Allow/Deny 'Confirm Access' page listing the requested scopes. Each OAuth Bearer Token records client, user and scopes, with status Active/Revoked (this field is read-only on the form). OAuthWebRequestValidator.revoke_token sets one token or its refresh token to Revoked, and validate_bearer_token rejects tokens that are Revoked or expired, so grants are individually revocable. SHORTFALLS: (1) scopes are not permissions. frappe/api.py validate_oauth takes required_scopes from the token's OWN scopes field and passes them to verify_request. validate_bearer_token only checks that those scopes are a subset of the client's scopes, which always holds, and then frappe.set_user(token user) runs the request with that user's full role permissions. No resource-level scope is enforced anywhere, and the client default is 'all openid'. (2) Consent can be skipped: an OAuth Client with skip_authorization bypasses the Allow/Deny page. So does OAuth Provider Settings 'Auto' whenever ANY Active bearer token exists on the site, because that query is not filtered by client. (3) There is no partner directory or app marketplace, and POS Awesome documents none. https://github.com/frappe/frappe/blob/be2f6245febabc75f48196c250938d733aa9054f/frappe/integrations/doctype/oauth_bearer_token/oauth_bearer_token.json#L68-L73 · retrieved 2026-09-15 adversarially verified
The platform pushes real-time webhooks for order lifecycle events (created, modified, paid, voided, refunded) rather than requiring polling.
extensibility-webhooks-push
Push webhooks come from the host platform, not from POS Awesome. POS Awesome's README says it 'Supports Erpnext Version 14' and installs from `branch version-14`. On that Frappe branch (version-14 head be2f6245, release 14.101.1), the Webhook doctype can target any DocType. Its Doc Event options are after_insert, on_update, on_submit, on_cancel, on_trash, on_update_after_submit and on_change (webhook.json L59-L63). Each webhook also takes a request URL, an optional condition expression (L71-L75) and an optional HMAC secret (enable_security/webhook_secret, L148-L158; sent as the X-Frappe-Webhook-Signature header). Document.run_method calls run_webhooks for every document method (model/document.py L948). Matching webhooks are queued and flushed with frappe.enqueue(..., enqueue_after_commit=True) (webhook/__init__.py L101-L107), so the HTTP request is pushed after the transaction commits and no polling is needed. A POS Awesome sale is a standard ERPNext Sales Invoice: on_submit covers created/paid, on_cancel covers voided, and a return invoice can only be caught if the operator writes a condition such as doc.is_return. SHORTFALLS: POS Awesome ships no webhook, event catalogue or order-lifecycle contract of its own ('webhook'/'webhooks' 0 tokens across its repo). The events are generic document hooks, not named order events; refunded is not a distinct event. At this commit a webhook set to on_update_after_submit never fires, because run_webhooks' accepted event_list (L41-L46) omits it and adds before_update_after_submit instead, so edits to a submitted invoice can only be caught through on_change. Everything must be configured by hand. https://github.com/frappe/frappe/blob/be2f6245febabc75f48196c250938d733aa9054f/frappe/integrations/doctype/webhook/webhook.json#L59-L63 · retrieved 2026-09-15 adversarially verified
Webhooks are cryptographically signed (e.g. HMAC) AND documented to retry with backoff, with a replayable event log for missed deliveries. differentiator
extensibility-webhook-reliability
Not scored by this record.
A public write API accepts externally originated orders into the POS as first-class tickets that fire to KDS/printers and land in reporting.
extensibility-order-injection-api
Not scored by this record.
The vendor is a named DoorDash Preferred Integration Partner (DPIP) under the 2026 program requirements. differentiator
extensibility-doordash-preferred
Not scored by this record.
Direct, first-party certified integrations exist with DoorDash, Uber Eats, and Grubhub without requiring a paid middleware layer (Otter/Chowly/Deliverect/Checkmate). differentiator
extensibility-first-party-delivery-integrations
Not scored by this record.
The POS is a supported endpoint for at least two major aggregation middleware platforms (Deliverect, Chowly, Otter, Checkmate, ItsaCheckmate).
extensibility-middleware-compatibility
Not scored by this record.
Native, vendor-maintained connectors exist for QuickBooks Online and at least one other GL/accounting system, with mapped journal entries rather than CSV-only export.
extensibility-accounting-connectors
Not scored by this record.
Labor hours export natively to at least two named payroll providers (e.g. Gusto, ADP, Paychex, Paylocity) without manual re-keying.
extensibility-payroll-export
Not scored by this record.
The vendor operates a public integrations marketplace listing named third-party apps that operators can browse and self-install.
extensibility-app-marketplace
Not scored by this record.
The vendor supports a headless/embedded mode where a third-party UI (kiosk, web ordering, drive-thru) drives the POS transaction engine via API.
extensibility-headless-embedded
Not scored by this record.
A complete historical data export (orders, customers, menu, payments metadata) is available to the operator on demand, in a documented machine-readable format, at contract end. differentiator
extensibility-data-portability-exit
Not scored by this record.
Reliability, offline & operations
Order entry, ticket routing, and check printing continue on-terminal when the internet connection is lost.
reliability-offline-order-entry
Nothing continues on-terminal: every invoice save/submit and lookup is a live frappe.call to the ERPNext server, and check printing is a browser window on the server-rendered /printview. Order entry and receipt printing therefore survive a lost internet connection only when the ERPNext site is self-hosted on the LAN; ticket routing does not exist in the product in any connectivity state. Server-dependence and the absent routing are the named shortfalls. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
Card payments can be accepted while offline via store-and-forward, not just cash-only fallback. differentiator
reliability-offline-card-auth
Not scored by this record.
The vendor publicly documents who bears the loss when a store-and-forward transaction declines after connectivity returns, and states any per-transaction or cumulative offline cap. differentiator
reliability-offline-decline-liability
Not scored by this record.
Multiple terminals continue to share a single check/table state over the local network while the internet is down (LAN-only degraded operation, not per-terminal islands). differentiator
reliability-lan-degraded-multi-terminal
Not scored by this record.
The vendor documents a local/on-premise transaction engine or edge server (not purely cloud-hosted request/response) for the ordering path. differentiator
reliability-local-transaction-engine
Not scored by this record.
Kitchen display and/or kitchen printer routing continues to function while offline.
reliability-offline-kds-printing
There is no kitchen display and no kitchen printer routing in the product at all — 'kitchen' and 'kds' appear nowhere in the source and the only print path is the browser /printview receipt window — so no kitchen output path exists to keep functioning offline. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
The system automatically fails over to a backup printer or KDS station when a configured kitchen printer is unreachable, and alerts staff.
reliability-printer-fallback
No printer management layer exists: printing is window.open on the ERPNext /printview URL with trigger_print — browser receipt printing only. There are no configured kitchen printers, no printer-reachability monitoring, and no failover or alert logic anywhere in the source. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-04
The vendor documents its conflict-resolution behavior for edits made on two devices during a network partition (e.g. last-write-wins, merge, or operator prompt).
reliability-sync-conflict-handling
Not scored by this record.
The vendor publishes an explicit list of which features are unavailable offline (gift cards, loyalty lookup, refunds, manual card entry, text-to-pay).
reliability-offline-feature-matrix
Not scored by this record.
A public, per-component status page exists showing current and historical incident state without a login.
reliability-public-status-page
Not scored by this record.
24/7/365 live human support by phone is included in the base subscription, not sold as a premium support tier.
reliability-247-live-support
Not scored by this record.
The vendor offers in-person on-site installation and go-live support (first-party or certified dealer network), not remote-only self-install. differentiator
reliability-onsite-install
Not scored by this record.
A hardware replacement/advance-exchange program with a stated turnaround time is included or purchasable.
reliability-hardware-replacement-sla
Not scored by this record.
The vendor publishes a current PCI DSS v4.0/4.0.1 Attestation of Compliance or equivalent (e.g. validated P2PE listing) covering the post-March-2025 future-dated requirements.
reliability-pci-dss-4-attestation
Not scored by this record.
Multi-factor authentication is enforceable on back-office and POS administrative logins, with role-based permissions.
reliability-mfa-role-based-access
Not scored by this record.
A public, free training library (video/LMS) and a practice/training mode on the terminal exist for staff onboarding.
reliability-self-serve-training
Not scored by this record.
Any terminal can assume the master/server role automatically if the designated primary terminal or local server fails. differentiator
reliability-failover-terminal-role
Not scored by this record.
Terminals support an automatic cellular/LTE failover for connectivity, first-party or documented.
reliability-cellular-backup
Not scored by this record.
Commercial, compliance & data ownership
Vendor publicly offers a month-to-month subscription with no minimum multi-year term commitment for its core POS software tier. differentiator
commercial-month-to-month-contract
Not scored by this record.
Vendor's published terms of service or MSA state no early termination fee / no liquidated damages for cancelling the software subscription before term end. differentiator
commercial-no-early-termination-fee
Not scored by this record.
The auto-renewal term and the required cancellation notice window (e.g. 30/60/90 days) are stated in publicly accessible contract terms rather than only in a signed quote.
commercial-autorenew-terms-published
NEW SURFACES, still unknown (there is no subscription contract for the claim to test, so not a no). (1) The README's install link frappecloud.com/marketplace/apps/posawesome 308-redirects to cloud.frappe.io/marketplace/apps/posawesome (200, 329,788 bytes; cloud.frappe.io/robots.txt empty): "Publisher Ucraft, Inc", "Supported versions Version 15, Version 14, Version 13, Version 12, Nightly", "Categories Free Featured Retail", and "For paid support please get in touch with me at youssef@totrox.com" -- no plan, price or term on the listing; two user reviews (dated 4 and 2 years ago) complain of a past "$50 per month" price, so a paid plan once existed and its terms are not published there. (2) Frappe Cloud terms (docs.frappe.io/legal/terms/frappe-cloud-terms.md, 36,045 bytes): 10.1.3 lets the customer terminate hosting "without providing prior written notice ... effective at the end of the then-current billing period", but the third-party clause (line 525 of the .md) says of marketplace apps "Frappe does not endorse or control such third parties ... Use of any third-party service is at the Customer's sole risk", and 5.2.4 excludes "marketplace or external applications not developed by Frappe" from support -- those are Frappe's hosting terms, not POS Awesome's. The app is GPL-3.0 and free; its only commercial offer (paid support by email) publishes no term. Retrieved 2026-09-17. || 330th: NEW SURFACE (330th): THE AUTHOR'S OWN COMPANY SITE, censused to 100% -- the prior pass reached the Frappe Cloud listing and Frappe's hosting terms but never opened the one commercial party the listing names ("For paid support please get in touch with me at youssef@totrox.com"). totrox.com is live (200, 28,862 bytes, robots.txt allows all: only /wp-admin/ is disallowed) and is WordPress. Its whole content set was read through the REST API: /wp-json/wp/v2/types returns exactly four types (post, page, attachment, wp_block -- no custom legal/pricing type), /wp/v2/pages?per_page=100 returns 34 pages and /wp/v2/posts?per_page=100 returns 9 posts, i.e. 43/43 documents, 40,320 characters of stripped text, EN and AR. Tokenised, word-boundary, case-insensitive controls over that 43-document census: `renew(al|ed|s|ing)` 0/43, `auto-?renew\w*` 0/43, `subscriptions?` 0/43, `cancel(lation|led|s)?` 0/43, `notice` 0/43, `agreements?` 0/43; positive controls fire (`support` 4/43, `terms` 1/43, `contracts?` 1/43, `licen[cs]\w*` 1/43, `pric(e|es|ing)` 1/43, `month(ly|s)?` 1/43), so the extractor works. The site has no /terms, /pricing, /legal or /eula page of any kind; it is an ERPNext implementation consultancy (pages: Our Service, Technical Support, Installation & Implementation ERPNext, ERPNext, About us, Blog). Control `pos\s*awesome` = 0/43: the author's company site does not mention the product at all, so no POS Awesome commercial offer is published there. Also probed: posawesome.com, www.posawesome.com and posawesome.org do not resolve (NXDOMAIN), so there is no product site to hold terms. REPO STATE (api.github.com only; github.com pages and cloning avoided): the repository has MOVED ORGS -- api.github.com/repos/yrestom/POS-Awesome 301s to ucraft-com/POS-Awesome (matching the marketplace listing's "Publisher Ucraft, Inc"), license GPL-3.0, 513 stars, last push 2024-08-12, homepage field EMPTY, latest release Version-6-2-0 (2024-02-09); the 233-file tree holds only license.txt and README.md as legal/commercial documents. VERDICT: held unknown, not a `no`. Across the three parties that could publish a contract for this product (the GPL-3.0 project itself, the publisher/author's company totrox.com, and the Frappe Cloud marketplace), there is no subscription offer whose auto-renewal term or cancellation-notice window could be stated, so the claim has nothing to test rather than being answered in the negative. Retrieved 2026-09-18. adversarially verified
The POS software can be purchased and operated with a third-party payment processor of the operator's choice (no mandatory in-house processing lock). differentiator
commercial-processing-not-bundled
Not scored by this record.
Vendor publishes an interchange-plus (cost-plus) processing rate option with the markup stated as a specific bps + per-transaction figure, rather than only blended/flat card-present rates. differentiator
commercial-interchange-plus-published
Not scored by this record.
The processing agreement caps or prohibits unilateral vendor-initiated rate increases outside of pass-through interchange/network changes, or grants penalty-free exit on any increase. differentiator
commercial-rate-increase-clause
Not scored by this record.
Per-location and per-additional-terminal software pricing is published as specific dollar figures on the vendor's public site (not 'contact sales' only).
commercial-pricing-published
Unambiguously free: GPL-3.0 licensed ERPNext app with no commercial tier; hosting cost is separate and external. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Individual modules (online ordering, KDS, loyalty, inventory, payroll, marketing) can be purchased à la carte and cancelled independently without repricing the base POS subscription. differentiator
commercial-module-unbundling
Not scored by this record.
All required terminals, KDS screens, and printers can be purchased outright at a published price, with no mandatory multi-year hardware lease or rental.
commercial-hardware-purchase-outright
No first-party hardware sold, so no mandatory lease; operators supply their own terminals, scales and printers. https://github.com/ucraft-com/POS-Awesome · retrieved 2026-08-01
Vendor documents support for at least one non-proprietary/third-party hardware option (e.g. standard iPad, Epson/Star ESC/POS printers, generic cash drawer) rather than requiring vendor-only devices. differentiator
commercial-hardware-not-locked
Not scored by this record.
Operators can self-serve export their full transactional history (orders, line items, payments, labor) to CSV or a documented API without contacting support or paying a fee.
commercial-data-export-self-serve
Not scored by this record.
Guest/customer records, loyalty balances or point ledgers, and gift-card liability balances are exportable in machine-readable form by the operator. differentiator
commercial-export-customer-and-loyalty
Not scored by this record.
Contract or documentation specifies a post-termination data retrieval window (a defined number of days during which the operator can still export their data) rather than immediate cutoff. differentiator
commercial-post-termination-export-window
Not scored by this record.
Published terms explicitly state the merchant owns its transaction and customer data, and constrain the vendor's right to use or resell that data (beyond aggregated/de-identified use) for its own products or marketing. differentiator
commercial-data-ownership-clause
Not scored by this record.
Vendor documents validated P2PE or hardware-encrypted card entry plus tokenization such that the merchant's PCI scope is reduced to SAQ A / SAQ P2PE-HW, and names the applicable SAQ.
commercial-pci-p2pe-tokenization
Not scored by this record.
Vendor documents PCI DSS v4.0.1 future-dated controls in effect since 31 Mar 2025 — notably MFA for all access to the cardholder data environment including POS and back-office logins, and (for hosted ordering pages) payment-page script integrity monitoring per Req 6.4.3/11.6.1.
commercial-pci-dss-4-controls
Not scored by this record.
Product provides in-app tooling for CCPA/CPRA and GDPR data-subject requests — locating, exporting, and deleting an individual guest's records — plus a published DPA the operator can execute.
commercial-privacy-dsar-tooling
Not scored by this record.
Vendor publishes an accessibility conformance report (VPAT/ACR) claiming WCAG 2.1 AA (or later) for its self-order kiosk and consumer web-ordering surfaces, including a documented tactile/audio non-visual access mode on kiosks. differentiator
commercial-wcag-kiosk-accessibility
Not scored by this record.
POS supports card-network-compliant dual pricing / cash discount or surcharging with automatic exclusion of debit and prepaid cards from any surcharge, and required receipt and menu-board disclosure of the fee. differentiator
commercial-dual-pricing-compliant
Not scored by this record.
Adversarial verification
An independent pass was instructed to refute this record, defaulting to downgrade when uncertain. It challenged 0 values — 0 upheld, 0 downgraded, 0 upgraded. It separately resolved 32 previously unknown values. This is published in full because a reader who can see which values were contested, on what evidence, and which way they moved has something no affiliate-funded comparison offers.
Capability claims
| Claim | As first scored | Verdict | What the verifier found |
|---|---|---|---|
| order-capture-offline-order-entry | unknown, grade F — "No public documentation located during the 2026-08-01 research pass." (placeholder; cell never examined) | resolve-to-partial | Read the full source at HEAD a86fd29: no service worker, no IndexedDB, no local order queue — every invoice save/submit is a live frappe.call to the ERPNext server; posa_local_storage only caches item/customer lists. Continuity through a WAN outage exists only when the ERPNext site is self-hosted on-LAN, and no offline scope is published — that named shortfall is the partial. source |
| menu-pricing-modifier-price-by-parent-size | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source: no modifier doctype, component or field exists anywhere ('modifier'/'topping' appear nowhere); customization is ERPNext item variants, which substitutes a different item code. A modifier price matrix cannot exist without a modifier model. source |
| menu-pricing-topping-quantity-tiers | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source: no modifier/topping construct and no quantity-tier or per-tier multiplier logic; quantity is the plain invoice line qty. source |
| kitchen-station-routing | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source: the full doctype and Vue component inventory contains no KDS, kitchen printer, station or routing artifact; the only print path is a browser window on the Sales Invoice /printview. source |
| kitchen-expo-consolidation | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source: no kitchen display surface of any kind ships, so there are no stations to consolidate and no bump state; consistent with the existing hardware-kds: no. source |
| labor-granular-rbac | unknown, grade F — placeholder rationale, cell never examined | resolve-to-partial | Source shows real discrete-action gates (posa_allow_delete, posa_allow_return, posa_allow_user_to_edit_rate, item/additional discount toggles, posa_max_discount_allowed) but they are per-POS-Profile booleans applying uniformly to all users of the profile, not per-role grants; no comp, void-approval or drawer-open permission exists. Named shortfall carries the partial. source |
| labor-manager-override-audit | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source: no override/approval flow exists anywhere — restricted actions are pre-enabled or disabled per POS Profile, so there is no approver to attribute and no override event to write to any audit trail. source |
| reporting-realtime-dashboard | unknown, grade F — placeholder rationale, cell never examined | resolve-to-partial | The app ships no report or dashboard artifacts of its own, but sales post immediately as standard ERPNext Sales Invoices visible to the host site's browser reporting in real time. Shortfalls named: no first-party dashboard, no mobile app, and the background-job submission option defers invoice submission. source |
| reporting-pmix-modifier-level | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: modifier-level PMIX is structurally impossible in a product with no modifier data model and no shipped reports; item-level analysis exists only via generic ERPNext reports with no daypart/revenue-center dimension. source |
| reliability-offline-kds-printing | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: there is no KDS and no kitchen printer routing at all in the source, so no kitchen output path exists to continue functioning offline. source |
| reliability-printer-fallback | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: no printer management layer exists — printing is a browser window.open on /printview with trigger_print, with no configured kitchen printers, no reachability monitoring and no failover or alerting logic. source |
| order-capture-split-merge | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence from complete source at HEAD a86fd29: no check/table/seat model exists — a sale is one Sales Invoice cart, order-holding is Drafts or Sales Orders, and no operation splits an invoice by item/seat/N-way/amount or merges invoices; all 'split'/'merge' hits are String.split or bundled-library code. source |
| order-capture-scheduled-orders | unknown, grade F — placeholder rationale, cell never examined | resolve-to-partial | Future-dated capture is real: posa_delivery_date plus the posa_allow_sales_order profile flag makes before_submit map the cart to a submitted Sales Order carrying the delivery date (invoice.py). The named shortfall is that no make queue, per-channel lead time or computed fire time exists — the product has no kitchen output at all, so the order just sits as an ERPNext document. source |
| kitchen-bump-bar-hardware | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: no KDS ships ('bump'/'kds'/'kitchen' appear nowhere in source), so there is no screen for a bump bar to drive and no supported-models documentation; consistent with the record's hardware-kds: no. source |
| delivery-driver-roster | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: 'driver'/'dispatch'/'courier' appear nowhere in source; the delivery footprint is the Delivery Charges fee doctype and posa_delivery_date — no driver entity, clock-in/out, assignment state or run history. source |
| delivery-dispatch-board | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: the complete Vue component inventory is cashier screens only; no dispatch/expo board, undispatched-order view, driver availability, elapsed-time display or run batching exists anywhere. source |
| digital-first-party-web | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: the app's only web surface is the /posapp cashier page and templates/pages is empty — no guest-facing ordering site, cart, checkout or menu page exists in the product. source |
| digital-menu-single-source | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Structural absence: with no first-party digital ordering channel in the product, no digital menu exists to be generated from the Item catalog and no channel exists for an edit to propagate to. source |
| digital-account-saved-payment | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: no guest-facing channel for an account to live on, and no tokenization or card-on-file construct anywhere in source; addresses are cashier-entered ERPNext Address records, tender is cash/Mpesa/ERPNext payment modes. source |
| guest-loyalty-unified-profile | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: the product has one channel (the cashier page), so there are no cross-channel transactions to merge; identity is the cashier-selected ERPNext Customer record and no dedup/merge behavior exists in source or README. source |
| guest-loyalty-lifecycle-automation | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Positive absence: posa_birthday is stored on Customer but nothing consumes it beyond display; the app has no email/SMS send anywhere, hooks.py's scheduler_events block is commented out so no triggered job runs, and 'campaign' references are ERPNext Campaign attribution on coupons/referrals, not sends. source |
| multi-location-central-menu-publish | unknown, grade F — placeholder rationale, cell never examined | resolve-to-no | Structural absence: the catalog is the single ERPNext site's shared Item/Price List masters with no per-location menu instances, so edits are instantly live site-wide; no publish action, location targeting or push/version history exists anywhere in the app. source |
| hardware-offline-mode | unknown, grade F — placeholder rationale, cell never examined | resolve-to-partial | Same substrate finding as order-capture-offline-order-entry: no client offline layer (no service worker, IndexedDB or order queue), continuity only under LAN self-hosting, no kitchen printing in the product, and no vendor documentation of offline degradation. Those named shortfalls carry the partial. source |
| reliability-offline-order-entry | unknown, grade F — placeholder rationale, cell never examined | resolve-to-partial | Every save/submit and lookup is a live frappe.call and check printing is the server-rendered /printview, so nothing continues on-terminal; order entry and receipt printing survive internet loss only with a LAN-hosted ERPNext site, and ticket routing does not exist in any connectivity state. Server-dependence and absent routing are the named shortfalls. source |
| labor-clock-in-at-pos | unknown, grade F | resolve-to-no | Re-opened the clone at a86fd291 myself. hooks.py (every non-comment line read) has app metadata, doctype_js, doc_events and fixtures but no required_apps, and neither the repo nor the wiki mentions hrms. My own census (145 files, tokenised camel/snake split) agrees with the proposal's zeros and adds the synonyms checkin/checkout/timeclock/hrms/hr/pin/rfid/hours/wage/payroll plus the phrases 'employee checkin' and 'shift type', all 0. The substring traps are recorded: shift, card, login, badge. Conjunct test on Opening/Closing Shift: it meets 'at the POS terminal' and gives a per-user start timestamp. It fails 'employee', 'PIN/badge/card' and clock-out-as-time: end is a Date, the shift can run past midnight and the only output is a cash reconciliation. So it is not a partial. Bounding question: the claim is scoped to the POS terminal, and the POS UI is this repo's own closed component set with no route to Employee Checkin, so a co-installed HRMS does not put clock-in at this terminal. The absence rests on a complete enumeration of the product's own source, which is positive evidence rather than a failed search. It matches the peer nexopos no (PIN login plus per-cashier register sessions, no timecard entity), and URY's partial is distinguished by its mandatory HRMS dependency. Grade A is correct for source code. I amended the note to name the Period Start Date datetime, the User-not-Employee link, the census size and the poison tokens, and to drop the closing-shift line reference in favour of the opening-shift fields I verified (pos_opening_shift.json L28-L37, L92-L95). source |
| reporting-eod-closeout | unknown, grade F | resolve-to-partial | Re-opened the clone at a86fd29 and confirmed pos_closing_shift.py L138-L266 line by line, plus L45-L54 and L97-L114, pos_closing_shift.json, pos_closing_shift_detail.json L24-L55, closing_shift_details.html, ClosingDialog.vue and the wiki quote at End-of-Shift-Day.md L15. The value (partial) and grade (A, source code) stand. The note is amended in three places. (a) The proposal's 'gross' conjunct is overstated: grand_total is the discounted total including tax, not pre-discount gross sales, so it is moved to the shortfalls. (b) The refunds shortfall is sharpened: returns are a real feature (Returns.vue, is_return) and are netted silently into the shift totals. That makes this a missing breakdown, not a missing feature, so the proposal's 'refund 0' control shows only that the vendor's word is 'return'. (c) The proposal's 'discount 328' figure is dropped as reader-dependent; my tokenised count differed. Only the invariant is kept: zero discount tokens in the closing files. Tip: zero word-level hits; the single raw hit is a binary PNG and no substring like 'tooltip' is involved. The partial is not self-refuting, because tax, per-tender expected vs counted and tender types are really met. Peer scoring is consistent: 36 peer partials, and cake is partial/B for a fuller Z report. source |
| payments-gift-cards | unknown, grade F | resolve-to-no | Every quote checked at a86fd29 (the clone HEAD): pos_coupon.py L22-L23, L26-L29, L30-L36, L44-L81, L117-L120 and L122-L123, plus the pos_coupon.json field list. The verdict holds and matches peers: erpnext-pos scores the same Coupon Code 'Gift Card' no/B, and nexopos scores house-account credit no. My re-run of the census found two misses in the proposal. (a) The customer-credit redemption surface (Payments.vue 'Use Customer credit'/'Redeem Credit', posapp.py get_available_credit and redeeming_customer_credit, and the wiki's 'redeem as many credit notes as required') is a stored per-customer balance used as tender. The proposal never mentioned it, and a reader could argue it meets the balance conjunct. It is an account credit from returns and advances, bound to a named customer and one company, with no card or code that can be issued or sold, so it is not a gift card. (b) Loyalty-point redemption is ERPNext Loyalty Program, not a gift card. The proposal also said loyalty points were among the balance hits; my tokenised count puts all 19 balance hits in M-Pesa, shift or translation files, none in loyalty files. The note is amended to name both surfaces and correct the counts. Does the Gift Card coupon meet any conjunct? It carries the name and redeems at any POS profile in the company. It has no balance, a use cap of 1 and no online channel. That is a homonym, not a partial gift card, so partial would refute itself. Grade A is right for source code. The no rests on an enumerable doctype schema with no value or balance field, not just on a zero-hit. source |
| menu-pricing-nested-modifiers | unknown, grade F | resolve-to-no | Upheld as no/A with the note amended. I re-read Variants.vue L10-L28 and L85-L95, README L32 and ItemsSelector L332 at a86fd291, and every quoted line holds. My own tokenised census covered 145 files over the repo and wiki and included synonyms the proposer skipped (extra/extras, option/choice, combo, bundle, nested, required/mandatory, ingredient, side, upsell, kit). Every modifier-family token was 0 and every non-zero hit resolved to an unrelated construct. The amendment adds one trap the proposer missed: the wiki's 'unlimited level of attributes' could be misread as nesting depth, but it means several flat attribute pickers side by side, and the note now says so. It also adds the single-select chip-group detail and binds the scope to the ERPNext constructs the UI surfaces. This is a positive absence and not a mere zero-hit: the one option construct is structurally flat and has no bounds fields. Grade A fits because the evidence is source code. Peers agree: erpnext-pos no/B, ury no/B, floreant no/A. source |
| extensibility-oauth-partner-apps | unknown, grade F | resolve-to-partial | I re-opened the code at the cited commit instead of relying on the proposer, who admitted not tracing enforcement. I fetched frappe/oauth.py, frappe/integrations/oauth2.py, frappe/api.py and auth.py from raw.githubusercontent.com. Authorization-code grant, the consent screen (oauth2.py L91-L118) and per-token revocation (oauth.py L240, L260-L275) are confirmed. The trace also shows the scopes conjunct fails harder than the proposer claimed. The failure is structural, not just a coarse default: api.py L233-L237 validates a token against its own scopes, so scope checking is tautological, and the session is set to the granting user (L240). I kept partial rather than no because OAuth 2.0 with consent and individual revocation is real, and the claim's contrast case (shared static keys) is avoided. Grade A stands: it is source code. Platform credit is consistent with this record's extensibility-public-api-docs (partial, inherits Frappe REST) and with the Frappe peers (URY partial/B, erpnext-pos yes/B on the same facility). Partial is the more defensible of those two peer scores given the traced enforcement. The record's multi-location-org-hierarchy cell declined substrate credit, but that was over a data model POS Awesome does not use, whereas here the bearer auth path directly gates POS Awesome's own whitelisted API. I amended the note to state the traced enforcement, the consent-bypass paths and the missing partner directory, and to drop the inference-based wording. source |
| hardware-os-platforms | unknown, grade F | resolve-to-no | Checked the claim wording in data/taxonomy/restaurant.yaml: it is about what the documentation publishes (named client OSes plus minimum versions and specs), not about being locked to one platform. So 'no' means the docs publish nothing, and that absence is measured here, not just 'I didn't find it'. The two local clones match the cited commits (repo a86fd291, wiki 9f122813). I read the whole README and ran my own whole-word searches over the wiki and repo. Every OS and browser name returned zero; the only hits were false positives (browser = local-storage setting, mobile = phone fields, CTRL/CMD shortcut). Does 'runs in a browser' make this partial? No. Peers set the rule: opensourcepos and odoo-pos got partial only because they name browsers and versions; URY and erpnext-pos, also browser apps with only server requirements documented, are no/B. Scoring POS Awesome partial on an unnamed browser would break that consistency. Value and grade upheld. The note is rewritten to publish the zero result rather than per-word counts: the proposal's 'browser 4' did not reproduce (I got 3 occurrences) and does not change the verdict. The CMD-key false positive is added. source |
| extensibility-webhooks-push | unknown, grade F | resolve-to-partial | Re-opened webhook.json, webhook/__init__.py, webhook.py and hooks.py from .cache/q310-pos-awesome/frappe14raw. I also fetched model/document.py at be2f6245 myself and confirmed the local Frappe clone's HEAD is be2f6245 on origin/version-14. Upheld: the event options, the condition field, the HMAC secret and the post-commit enqueue are all present in code. Platform credit matches how this record already scores extensibility-public-api-docs ('inherits Frappe's public REST API'), and it matches peers URY (partial/B) and erpnext-pos (yes/B) on the same doctype. The v14 pin is real: README L12 says 'Supports Erpnext Version 14' and L54 says 'branch version-14'. AMENDED because the proposal mapped 'modified' to on_update_after_submit and cited __init__.py L23-L41 as the firing path. The code refutes that: event_list (L41-L46) holds on_update, after_insert, on_submit, on_cancel, on_trash, plus on_change and before_update_after_submit, and never on_update_after_submit. document.py L1120 does run that method, but the equality check at L58 can never match it, so only on_change reaches edits to submitted documents. The proposal also cited L84 for the condition field; that line is the HTML examples block and the field itself is L71-L75. Value stays partial against the claim's conjuncts: push delivery is met, but there is no vendor order-event contract and no distinct refunded event. Grade A is kept because the evidence is source code at a pinned commit. source |
| delivery-zone-pricing | unknown, grade F | resolve-to-partial | I re-opened the code at a86fd291 in the local clone and confirmed every cited line: the py L32 def, L58-L63 address lookup, L89-L98 rate resolution and L100 return; the Invoice.vue L2846 and L2881-L2886 manual dropdown; custom_field L989/L1012 on Address and L4226 fetch_from on Sales Invoice; and the 'rate' field in the POS-profile child table. My whole-word census also found 0 hits for zone, radius and geocode. The proposer's wording 'works as a zone' overreaches. The charge record has no geography and must be hand-tagged on each Address, and the proposer missed that untagged customers fall through to every enabled charge (L69-L70). So I rewrote the note to call it a manually tagged address group. Why partial, not no or unknown: the fee conjunct is really met by a named charge record keyed to addresses. Peer precedent scores that shape partial: focus-pos zones carry a fee only and are tied to customers, and digital-dining's fee is assigned per customer. `no` would need positive evidence that per-area fees are absent, and here they are present. `unknown` would ignore grade-A source code that settles every conjunct. Grade A stands because this is source code. source |
Sources
Every URL this record cites. 12 in total.
- https://github.com/ucraft-com/POS-Awesome
- https://github.com/ucraft-com/POS-Awesome
- https://github.com/ucraft-com/POS-Awesome/wiki
- https://github.com/ucraft-com/POS-Awesome
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_opening_shift/pos_opening_shift.json#L28-L37
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_closing_shift/pos_closing_shift.py#L138-L266
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/pos_coupon/pos_coupon.py#L25-L29
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/public/js/posapp/components/pos/Variants.vue#L12-L26
- https://github.com/frappe/frappe/blob/be2f6245febabc75f48196c250938d733aa9054f/frappe/integrations/doctype/oauth_bearer_token/oauth_bearer_token.json#L68-L73
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/README.md#L12
- https://github.com/frappe/frappe/blob/be2f6245febabc75f48196c250938d733aa9054f/frappe/integrations/doctype/webhook/webhook.json#L59-L63
- https://github.com/ucraft-com/POS-Awesome/blob/a86fd291ab18a655b3f6d58882b01ecad81fe6af/posawesome/posawesome/doctype/delivery_charges/delivery_charges.py#L32-L100