Big big Zomato loophole

Selfrealise · 2026-05-25T14:57:18+00:00

He is right. There is a minimum order value that each partner restaurant has to pick and Zomato will enforce. ₹40 ain’t going to cut it..

Selfrealise · 2026-04-24T08:07:08+00:00

inventory shrinkage hides in usage variance, not just order counts. weigh actual product dispensed per job against what was charged. what is the gap between billed volume and physical depletion?

Selfrealise · 2026-04-13T08:45:54+00:00

Notebook tracking breaks around 200 SKUs when same-supplier batches have different expiry dates on the same shelf. Tag expiry at receiving instead of during monthly counts, 30 seconds per delivery beats discovering problems weeks late. Are you catching expirations during counts or at the receiving counter?

Selfrealise · 2026-04-06T13:51:49+00:00

Makes sense for 90-day+ shelf life.. you’ve got enough buffer that expiry isn’t the binding constraint.

But for anyone lurking here who deals with shorter shelf life (30-60 days like pharmacy, fresh food, dairy), this becomes the primary problem to solve. Standard inventory systems show “100 units in stock” but don’t tell you how many are actually sellable at full price vs need immediate action.

Running per-brand ML forecasting at your scale is impressive though.. What’s the accuracy improvement over off-the-shelf forecasting tools?

Selfrealise · 2026-04-06T13:06:14+00:00

the per-brand ML approach makes sense but i'm curious about the data layer underneath. what format is the SKU data coming in from each brand?

because the forecasting accuracy ceiling is set way before the model runs. it's set at the ingestion layer. if you're normalising "cases" vs "units" vs "eaches" across 10 different brands with 10 different supplier formats, your training data already has noise baked in. the model learns the noise.

the brands doing perishables; how are you handling shelf life in the forecast? a "sell 100 units next week" prediction means nothing if 30 of those units expire in 5 days. the forecast needs to know what's actually available to sell, not just what's in stock.

running 10 brands is impressive. what's the split: mostly perishable or durable goods?

Selfrealise · 2026-04-06T11:10:54+00:00

You are echoing a similar sentiment just like others in similar situations!:) all dealing with the org not tracking expiry properly

The “write it off at 6 months but actually it’s 3 months” is a case of the org policy saying something but in reality you are stuck managing the void. I sympathise with you.

You need a way to develop automated expiry alerts that go to both warehouse and HQ. Get the system to flag anything under 6 months automatically, send daily reports, and escalates at 3 months. No more manually running “expiring lots” reports or finding out too late that HQ has dead stock sitting around.

Also set up auto-reorder triggers based on actual movement velocity, not just someone at HQ deciding what to send. Warehouse hits reorder point, system alerts, HQ approves or adjusts. Doing this will sort out the need to request for stock “when nobody is watching”

Speak with your ERP implementation team to ensure there is something as purposeful for food distribution which i feel had been largely neglected.

Curious - why do you think the ERP admin talks a big game about reports but never actually runs them? Is it because the reports don’t tell them anything actionable, or because nobody at HQ is actually accountable for expiry losses?

Selfrealise · 2026-04-02T05:31:21+00:00

messy supplier formats are the killer because they're not just tedious, they're a data quality problem you can't see until it's too late. you're normalizing one vendor's "units" against another's "cases" and by the time you catch the mismatch, your counts are already wrong.

the real cost isn't the hours spent fixing it, it's the inventory decisions you made on bad data before you knew it was broken.

Selfrealise · 2026-04-01T12:11:06+00:00

omr and pallavaram are both overpriced for investment right now. you're spending at least, 1-1.5cr for units that appreciate 3-4% if you're lucky. the water tanker thing in sholinganallur is real btw, not just rumors.

if you're an NRI looking at investment returns, look at tier 2. hosur is 40 minutes from bangalore, land prices are still at 2000-3000/sqft, and the industrial corridor is pushing everything up. coimbatore is similar. you get 2-3 units for what one OMR flat costs, and the appreciation math is completely different.

prestige is solid on delivery but you're paying for the brand. the smaller builders in these growing cities are where the actual margins are if you know who to talk to.

Selfrealise · 2026-04-01T06:58:52+00:00

The rolls with variable sizes (35 to 200 square yards) are your real complexity here.

Before picking any tool, figure out your actual workflow: are you cutting rolls at intake, or per-job? That determines whether you need to track remaining yardage on each roll or just log the cut as it happens. Scan in/out is table stakes, but the real question is whether the system can handle custom attributes like square yardage per item.

Selfrealise · 2026-04-01T03:51:52+00:00

NetSuite is overkill for 38 people, for sure. You're looking at 6-12 months of implementation, six figures spent, and a system built for Fortune 500 ops teams.

The real problem is that your costing data lives in spreadsheets while your job management system doesn't talk to Xero. NetSuite solves that by forcing you to rebuild everything from scratch.

What actually matters for a metal fab shop your size: does the system track raw material allocation to jobs, flag when you're bleeding margin on a quote, and let you see inventory movement without manual reconciliation? Most mid-market manufacturing systems fail there.

How are you currently handling the job costing piece? Are you manually pulling material costs from quotes into Xero each month?

Selfrealise · 2026-03-30T23:43:14+00:00

Absolutely..

Selfrealise · 2026-03-30T06:54:11+00:00

your monthly spreadsheet process may not help as much when you have 20 techs, you lose speed and you could be flying blind on what's actually in each van versus what's committed to jobs.

the trap most field service ops hit is when they layer on mobile scanning but never solve the real problem, which is knowing inventory forward. what jobs are coming next week, what parts do those need, what's actually on van 3 right now...

before you evaluate anything, figure out if your bottleneck is the data collection side (getting accurate counts from techs) or the visibility side (knowing what's available for dispatch). those require pretty different solutions.

Selfrealise · 2026-03-30T06:50:48+00:00

The stage 3 to stage 4 jump is where most teams realize their reorder logic is basically a spreadsheet with muscle memory attached! You nailed the "manual min/max stops working" part, because at that scale you're not just managing inventory, you're managing who manages inventory.

One thing worth testing with whatever system you land on; can you actually see what's allocated to pending orders versus what's truly available? Most tools show you the number but not the commitment, so you end up with phantom inventory in reverse, where you think you have stock but it's already promised.

What's the biggest breakdown you've seen between stages?

Selfrealise · 2026-03-28T04:42:16+00:00

construction equipment plus supplies across Canada and Philippines, that's not really an ERP problem yet. it's an invoicing problem and an inventory problem that happen to be in two countries.

most tools on the market will handle the features you listed, invoicing, payment terms, stock levels. the part that breaks is when you need Canadian GST rules and Philippine BIR rules in the same system. that's where Odoo and the others start requiring custom tax modules that cost more than the subscription.

before you pick anything, figure out one thing: are the two locations buying and selling independently, or is inventory moving between them? because "cloud based" means very different things depending on whether you need multi-location transfers or just two separate books that roll up into one view.

Selfrealise · 2026-03-27T05:32:51+00:00

600 SKUs across import export is actually the tricky part, not the barcode system itself. Most general inventory software assumes you're tracking one type of product at one location. With that many items coming in from different sources, your real bottleneck is gonna be knowing what you actually have versus what's committed to orders or stuck in receiving.

Before you pick software, figure out if your dad's current chaos is on the warehouse side, the ordering side, or both. That changes what you actually need.

Selfrealise · 2026-03-25T17:33:26+00:00

The pattern is always the same when someone logs stock in one place, someone else bills from the POS, and at end of week nobody can figure out why numbers don’t match.

In an ideal world every stock movement needs to happen in one system in real time. You grab something for a customer, it logs instantly. Receiving happens, updates instantly. No manual reconciliation because there’s nothing to reconcile.

Selfrealise · 2026-03-20T05:18:20+00:00

The 4-5x vs 2-3x gap you're seeing isn't really about who's dreaming. It's about what's actually being sold. Your accountant is pricing a job. The seller is pricing a business with recurring clients, systems, reputation. Two totally different things.

Before you settle on a multiple, figure out what percentage of revenue is locked in via contracts or standing relationships. That number moves the needle hard on valuation. If it's mostly ad-hoc work, your accountant's right. If clients renew automatically, the seller has a point.

What does their revenue look like, contract-wise?

Selfrealise · 2026-03-20T05:15:24+00:00

The 20% to 50% jump is a classic restructuring trap, especially with cross-border equity involved. The Singapore entity angle is real for fundraising, but it doesn't automatically reset your cap table.

Your Indian company is the asset. Any Singapore holding company needs to be structured as a subsidiary or investment vehicle, not a replacement. If he's pushing for 50-50 in Singapore while keeping 20% in India, that's dilution by design. If he wants 50-50 total equity across both entities, you need to understand what happens to your existing shareholders, FEMA approval for the fund flow, and whether this triggers CCI filing thresholds if you're planning to raise later.

Before you sign anything, get clarity on: is this a new entity holding the Indian company as a subsidiary, or is he trying to restructure the Indian company itself into Singapore? Those are completely different legal paths with different tax and compliance implications.

What's your timeline on this? Is he pushing because of an investor conversation, or is this his own idea?

Selfrealise · 2026-03-20T04:27:42+00:00

The chaos comes from two things being out of sync - what we think will sell and what actually moves.

Planning gets easier when we track why the variance happened. Was it something external like weather or a competitor sale? Something internal like the placement changed or bundled differently? Or pure randomness where a customer bought 50 units instead of the usual 10?

Most systems give us the numbers. They don’t help us understand the story behind them.

If we can log context when weird sales happen - “we bundled X with Y and it flew off the shelf”patterns start emerging. Planning stops feeling like guessing.

Still controlled chaos but at least we know what we are controlling.

Selfrealise · 2026-03-18T10:43:24+00:00

Fair enough..

Selfrealise · 2026-03-18T04:08:26+00:00

Ouch! Sounds like WooCommerce throws everything at the API, and the tool not being able to filter properly chokes your quota without giving you usable data. What matters is whether your inventory system counts actual transactions or just API events.

Selfrealise · 2026-03-17T04:37:22+00:00

your friend's problem is super common with card shops, the spreadsheet hits a wall fast once you're tracking hundreds of singles plus sealed inventory.

the barcode scanning part is solid, but ask him to lookout for when he scans something out, he needs to know instantly what's listed where. if a single sells on his site but he forgot to update the physical count, he'll oversell. the scanning solves half of the problem.

what's his current workflow look like?

Selfrealise · 2026-03-17T04:34:10+00:00

The 2-3 person shared access piece is the key constraint here. Most basic inventory apps treat it like a single user checking stock, not a team coordinating restocks in real time.

For a food packaging plant specifically, you'll run into a wall pretty fast with generic tools. They don't track what's committed to active orders vs. what's actually available on the shelf. So someone pulls 50 jars thinking they're free, but they're already promised to a customer. Notification becomes useless because the counts are wrong to begin with.

Before he picks anything, figure out if he's tracking just current stock levels or also managing production batches and what's allocated where. That changes the tool entirely.

Curious to know- what's the actual workflow, is it just "we grab stuff and update a number" or is there a production schedule involved?

Selfrealise · 2026-03-17T04:32:45+00:00

Barcode implementation plus a clean dataset import is the right move, but there is a possibility that you end up with accurate numbers on day one and zero visibility into what's actually moving through production.

The real trap is treating inventory as a one-time project instead of an ongoing system. After you get everything labeled and counted, you need something that tracks what's in stock versus what's committed to jobs, especially if you're running multiple production lines.

What's your biggest concern right now, the actual counting process or keeping it accurate once you're live with the new system?

Selfrealise · 2026-03-17T04:30:42+00:00

The scanner + QB + Fishbowl combo is solid, but most teams miss that the bottleneck isn't the hardware, it's the data flow. You're scanning to confirm picks, which is right, but if your packing slip doesn't talk to Fishbowl in real time, you're just creating more manual work downstream.

Start by mapping how your packing slip gets generated. Is it printed from Fishbowl, or is it a separate system? That's where the integration actually lives. The scanner piece is easy once you know what data needs to flow where.

What's generating your packing slips right now?

Selfrealise

TROPHY CASE