Restaurant POS

Private

Project *AFC ai genetic for beach sales APPFORSOLARArrow LogisticsArtificial Intillegence  » Algo Trade Automation  » Algo Trade Manual  » Bulk mail Automation with web interface  » Bulk Mail Service For Bench Sales  » Code Generation Tool  » Cold Emailing Automation (AI-Driven)  » Invoice Inventory Automation  » invoice to inventory for evergreen  » Test Automation  » What's app Bulk messaging with AI agents  » Zelle Payment for evergreenAsk RideBowls&blendsCharan Technologies _ DevelopmentEver green Farms USA (static website)Evergreen farms (pos)Evergreen React ApplicationFinwareHackthonLucky BraidsMy Produce StandNexPumpNexZen Printer AgentNoxa_JewelleryOffice Requirments  » Daily Tasks For Madhu  » Employees requirements  » Recruitment senior mern stack developer  » Red MIne Speed  » Senior Mern Stack DeveloperOPT - (USA) UpdatesQA TestersRare FruitsRegal SolarRegal Solar DMRegal Solar Energy_ ReactReliance Home Builders_ reactRemit2AnyRestaurant POSRSVPRushi GardensRV_ EngraverSoloar AppSri Farms _ DMSri_FarmsSuthra OneSuthra QNova LabsTech FourceTechnical RequirementsTechy_DevelopmentTechy_POS Travel Matex

Tracker *Bug Feature Support Testing

Subject *

Description Edit 1. Available coupon codes on the global ordering page Added eligible coupon codes as tappable chips below the "Enter Coupon Code" field in the global page cart, matching the existing POS cart behaviour Filtered the list to only what the cart actually qualifies for — order type, minimum bill amount, and for item-specific offers, whether a qualifying item is in the cart Sourced the codes from the existing /public/orders/offers endpoint (the other coupons feed deliberately withholds codes), so no backend change was needed Added getPublicOffers to the API service; capped the list at 5 chips and hid it once a coupon is applied 2. Per-store usage view for Superadmin Added a new GET /superadmin/tenants/:id/usage endpoint, role- and permission-guarded in line with the other tenant routes Reused the existing subscription-limits service so Superadmin sees the same figures the tenant sees, resolved by store ID instead of from the caller's token Extracted the usage meters into a shared UsageBreakdown component, so the tenant dashboard and Superadmin views stay visually identical Built a new per-store usage page with plan and subscription-status chips plus a refresh action Added a "Plan Usage" tile to the store details screen and registered the new route 3. Verification Backend typecheck passes clean Frontend typecheck passes clean Frontend production build passes 4. SaaS tax code (30070) missing from tax code search — RESOLVED Investigated why searching 30070 in the Tax Code search bar returned no results. Root cause: the record simply did not exist in the tax engine database (152 records, all F&B-oriented). The search itself was working correctly. Added 30070 — Software as a Service (SaaS) to the tax_engine_be tax categories collection. Confirmed it's a valid, official TaxJar code. Built a reusable, idempotent seeder script (npm run seed:tax-categories) so future codes can be added safely without duplicates. Verified live: searching 30070, saas, or software now returns the record. 5. Test item showing $0 tax — NOT A BUG Added a taxcheck menu item with the SaaS code; POS showed $0 tax. Verified end-to-end (POS → backend → tax engine → TaxJar). The chain is working correctly. Reason: our restaurant's tax address is Cumming, GA, and Georgia does not tax SaaS. Same order with a food code (41000) correctly returns 7%. Confirmed the code does produce tax in other states — NY $26.63, WA $31.65, AZ $27.30, PA $18.00, TX $19.80 (TX applies its 80% rule correctly). CA and OH are also exempt. Note: POS taxes at the restaurant's location, not the customer's address — so changing the customer address won't change the rate. This is intended behaviour. 6. Plan name on subscription invoices & emails — DONE Plan name now appears on: the invoice detail page (new "Plan" row), the invoice PDF, the invoice email body, and the email subject line. New invoices also carry the plan name in the line item description (e.g. "Max Plan - Subscription Payment") across both Stripe and PhonePe payment flows. Added a fallback so existing/historical invoices also display the plan name, even though they were saved with a generic description. Backend and frontend both typecheck clean; rendering verified for both new and legacy invoices. 7. "Resend Email" reporting success but no email received — INVESTIGATED Checked the email logs: the emails were sent and accepted by SMTP (status SENT, no errors). Most likely cause of non-delivery: the test recipient is a Yopmail disposable address, which commonly drops mail sent from Gmail. Recommend retesting with a real mailbox. Separately, I found and fixed a genuine bug: resend reported "success" even when the email was never actually sent (e.g. unconfigured transport or exhausted email quota). It now returns a proper error instead of failing silently. Worth flagging: this tenant hit 100% of its monthly email quota on 24 Aug — that's exactly the scenario that was previously being hidden. 8. Deployed latest code in staging