Shoukath Ali

Tuhund supports Excel upload as a controlled convenience feature, not as a replacement for normal system driven work. This distinction is fundamental to how the system preserves accuracy, accountability and operational discipline.

Excel upload exists to accelerate specific tasks where data already exists in structured form. It does not represent how work is intended to be performed inside Tuhund.

1. Excel is a data entry accelerator, not a business process

Regular work in Tuhund enforces

• validations at every step

• real time calculations

• permissions and role checks

• workflow and approval sequencing

• audit trail creation

Excel upload bypasses the interactive process layer and injects data at a defined entry point. For this reason, it cannot and must not replace daily transactional work. If Excel were used as a primary interface, the system would lose its ability to control, validate and explain transactions.

Excel is therefore positioned as a helper, not a workflow.

2. Where Excel upload is available and widely used

Excel upload is enabled only in functions where its use is safe, logical and does not weaken downstream controls. In most cases, this means pre approval, non transactional or reference stage data.

Bulk enquiry entry

Enquiries are non financial and non stock affecting.

Excel upload is widely used when enquiries are received from exhibitions, distributors or marketing campaigns or during data migration.

The system remains safe because

• no commitment is created

• validations and duplicate checks still apply

• workflows only begin after enquiry creation

Excel accelerates intake without bypassing any business logic.

Bulk lead creation

Leads represent potential business, not confirmed activity.

Excel upload is commonly used for

• marketing sourced lead lists

• imports from external CRMs

• legacy system transitions

Safety is maintained because

• leads remain inactive until worked inside Tuhund

• assignment, ownership and status changes follow normal rules

• conversion to enquiry or opportunity requires system actions

Excel speeds up onboarding while sales discipline remains intact.

Purchase order items before purchase order approval

Before approval, a purchase order is only a draft.

Excel upload is used when

• vendors provide quotations in spreadsheet form

• large BOM based orders are prepared

• multiple pricing scenarios are consolidated

System integrity is protected because

• approval is mandatory

• taxes, totals and pricing are recalculated by the system

• budget and permission checks occur at approval

Excel helps preparation, approval protects the system.

Sales order items before approval

Unapproved sales orders do not allocate stock or recognise revenue.

Excel upload is useful when

• customers submit orders in Excel

• large repeat orders are placed

• contract pricing is applied in bulk

Controls remain intact because

• validations re run after upload

• credit limits and pricing rules apply at approval

• dispatch and invoicing remain locked

Excel improves speed, approval enforces control.

Bulk entry of contact forms

Contacts are reference data.

Excel upload is widely used for

• trade fair and exhibition data

• website form exports

• third party database imports

It is safe because

• there is no financial or stock impact

• duplicates and mandatory fields are validated

• contacts only become active through user action

Excel reduces clerical effort without system risk.

Attendance upload (temporary or exceptional use)

Attendance data may originate outside the system.

Excel upload is allowed

• before biometric or device integration

• during device failure

• for exceptional historical correction

Strict controls apply because

• uploads are role restricted and time bound

• verification or approval is required

• payroll and compliance logic still runs normally

Excel acts as a bridge, not a workflow.

3. Why Excel cannot replace regular work

Many core Tuhund functions depend on live system state such as

• current stock levels

• batch and serial rules

• costing and valuation timing

• approval hierarchies

• inter module dependencies

Excel contains static values. It cannot react to real time conditions. Allowing Excel as a substitute would lead to incorrect valuations, broken stock integrity and silent rule violations.

For this reason, Excel upload is disabled wherever system state and cascading effects are critical.

4. Auditability, security and accountability

Regular transactions in Tuhund automatically generate

• timestamps

• user attribution

• traceable references

• system derived values

Excel files are external artefacts. Overuse would weaken audit trails, blur responsibility and increase reconciliation effort. Excel upload is therefore restricted to areas where accountability remains clear and verifiable.

5. Design principle summary

Excel upload in Tuhund follows a consistent rule set

• it is optional, never mandatory

• it is allowed only where misuse cannot damage system integrity

• it is commonly enabled before approvals, never after

• it complements workflows, it does not replace them

In short, Tuhund is a process driven ERP, not a spreadsheet driven system. Excel is supported to improve efficiency but control, validation and governance always remain inside the system.

Where the recruitment journey truly begins

In most organisations, recruitment does not begin with a job post. It begins much earlier, at the point where a department realises the need for an additional resource. Tuhund addresses this critical but often loosely managed stage through its Resource Request Module, a dedicated submodule within the Recruitment module.

This module ensures that every hiring requirement is structured, traceable, approved and auditable from the very first step.

Who can raise a resource request

Any department head or authorised user with the required access rights can raise a resource request. This flexibility allows organisations to decentralise demand creation while still maintaining complete governance through system driven approvals.

The person raising the request can clearly define the need without being forced to finalise recruitment decisions upfront.

What information can be specified

While raising a resource request, the requester can specify:

• Purpose of hiring

• Required attributes such as skills, experience, location or role expectations

• Number of candidates required

The requester may or may not specify:

• Type of hiring such as permanent, contractual or temporary

• Recommended salary range

This optionality is deliberate. In many organisations, salary structure, hiring model and final role definition are refined later in consultation with HR and management.

All relevant supporting documents can be attached directly to the request, ensuring context is never lost during approvals.

Structured approval workflow

Once submitted, the request enters a preliminary HR approval stage.

During this stage, HR staff can:

• Validate and update all relevant details

• Refine role attributes

• Adjust or confirm salary ranges if required

• Update the number of candidates approved

This is the last stage where edits are permitted.

After HR pre approval, the request moves through subsequent approvals which may include functional approval, management approval and budget approval depending on organisational policy.

Approvers at this stage can only:

• Approve

• Reject with reasons

No data modification is allowed beyond this point, preserving audit integrity.

Query based approvals and iterative clarification

Tuhund recognises that approvals are not always binary.

An approver can raise a query instead of approving or rejecting. This allows clarification, discussion and justification to happen without breaking the workflow. These discussions may go through several rounds before a final decision is taken.

If a request is rejected, it flows back to the pre approval stage. At this point, the request can either be modified or taken up for further discussion with the rejecting authority.

From request to job position in one click

Once fully approved, the resource request can be elevated to a job position with a single click.

At this stage, the system can automatically:

• Create a job position

• Publish it on the organisation’s public career portal

• Post it to configured job portals

While the job position workflow is outside the scope of this article, it is important to note that the entire recruitment trail begins at the moment the resource need is raised, not when resumes start arriving.

Part of a larger recruitment ecosystem

The Resource Request Module is a submodule of Tuhund’s Recruitment module, designed to support different operational models.

1. Hiring for your own organisation

You use both the Resource Request Module and the Recruitment Module end to end, from internal approval to onboarding.

2. Outsourcing recruitment to agencies

You use the Resource Request Module internally. Instead of elevating the request to a job position, the approved request is forwarded to recruitment partners. This can be done through hard copies, automated emails or APIs.

3. You are a recruitment agency

In this case, you may not use the Resource Request Module at all. Job requirements come directly as job profiles, either entered manually or received through APIs. Recruitment then starts directly from the job position stage.

Why this matters

By formalising the resource request stage, Tuhund ensures:

• Clear justification for every hire

• Budget alignment before recruitment begins

• Zero ambiguity during audits

• Complete traceability from demand to deployment

Most importantly, it ensures that recruitment is driven by organisational need, not ad hoc urgency.

Approval workflows are often treated as a checkbox in ERP systems. You may get a simple “approve” button or a single-stage authorisation. In practice, business processes are rarely that simple. Real-world approvals involve multiple roles, time limits, escalation rules and notifications across different channels. If these are not handled properly, the system creates more bottlenecks than it solves.

Tuhund was built to change this. Our approval engine is not just a feature — it is a full framework that adapts to your organisation’s needs.

Creating and Applying Approval Rules

Approvals in Tuhund start with approval rules. These rules are completely configurable and allow you to define what needs approval, under what conditions, and by whom. You can set rules for any kind of transaction — purchase requisitions, indents, orders, expense claims, HR requests, project activities and more.

Rules are not hardcoded. They can be created and modified by authorised users, giving flexibility without compromising control. For example:

• A purchase above a certain value may need finance approval

• A new vendor addition may require compliance and procurement sign-off

• An expense claim may route through department managers before reaching finance

Once defined, these rules are automatically applied by the system. The moment a transaction meets the conditions, it enters the approval workflow.

Multi-level and Multi-stage Approvals

Real approvals often require more than one layer of review. Tuhund allows you to design multi-level and multi-stage approval flows with ease.

• Multi-level approvals: A request can move upwards in hierarchy — first to a supervisor, then to a department head, then to finance or top management.

• Multi-stage approvals: Different aspects of the same request can be reviewed separately. For example, a purchase order might go through technical approval, then commercial approval, then budget approval.

Each stage can include one or multiple approvers. Approvals can be sequential (all must approve in order) or parallel (any can approve, or majority must approve). This ensures that processes match your real business practice.

Escalation and Elevation

Approvals cannot be allowed to get stuck. Tuhund includes built-in escalation mechanisms:

• Deadline-based escalation: If an approver does not act within the defined timeframe, the request is automatically elevated to the next manager.

• Manual elevation: Approvers themselves can escalate a request to higher authority if they feel it requires additional review.

This prevents bottlenecks and ensures that decisions move forward without unnecessary delays.

Approvals on the Homepage

One of the most powerful aspects of Tuhund’s approval system is visibility. Approvals appear right at the top of the homepage, above all other tasks. This keeps them impossible to ignore and makes it clear where attention is needed.

Every user sees the requests that require their action the moment they log in, without searching through menus or waiting for reminders.

Notifications Across Multiple Channels

Approvals are not limited to the ERP screen. Tuhund pushes notifications across multiple channels so that approvers never miss an important request:

• Email notifications for formal communication

• SMS alerts for quick reminders

• On-screen alerts inside the ERP for active users

• WhatsApp messages for instant reach and convenience

This multi-channel approach ensures that even if a manager is on the move, travelling or away from their desk, they remain connected and can take action in time.

Why This Matters

Weak approval systems create frustration. Requests pile up, managers chase each other manually, and employees lose trust in the process. Instead of ensuring control, approvals become a bottleneck.

Tuhund’s approval engine ensures that workflows remain smooth, timely and transparent. It balances control with efficiency — keeping decision-making in the right hands without slowing down the organisation.

Conclusion

Approvals are a critical part of business governance. But for them to actually work, the system must handle complexity, escalation and communication seamlessly. Tuhund’s approval framework delivers exactly that:

• Flexible rule creation

• Multi-level and multi-stage workflows

• Automatic escalation and manual elevation

• Prominent visibility on the homepage

• Multi-channel notifications

The result is an approval system that supports the organisation instead of slowing it down.

📦 The Scenario

After completing a job order, some material remains unused on the production floor. Users often ask:

"Why doesn't this leftover material automatically go back to the store it came from?"

This expectation, while common, indicates a misunderstanding of how materials are legally and operationally handled in Tuhund.

⚖️ Legal and Physical Ownership

When material is allocated from a store to a job order, there is a legal and physical handover of that material. This is not just a digital operation — it's documented through valid instruments like an Inter-Store Delivery Note (ISDN). Once issued, the material is no longer in the issuing store. It is in your Production Store or Production Floor — both physically and legally.

Thus, expecting the leftover material to fly back to the original store automatically is neither logical nor legal. It is now owned by the production floor, and further movement must be explicitly transacted.

🚫 The Risk Behind the Expectation

If users expect leftover material to return on its own without a transaction, it indicates a serious misuse of the ERP system. This points to:

❌ Passive Bookkeeping Instead of Operational Control

• Users are treating Tuhund as a reporting system rather than a live control system.

• Real-time inventory and ledger accuracy gets compromised.

• Regulatory and compliance obligations (especially in manufacturing and tax environments) may be violated.

🔥 Consequences

• Stock mismatches between system and physical inventory.

• Audit and enforcement risks due to undocumented material lying on the floor.

• Loss of traceability and accountability for material usage and reuse.

• Tendency to treat ERP as a "back office system" instead of a decision-driving tool.

✅ Proper Process Expectations

Tuhund expects every stock movement — whether issue, consumption, return, or scrap — to be a legitimate transaction. Leftover material must be accounted for and explicitly transferred. The system cannot — and should not — assume or guess what happens to physical material.

🔁 How to Return Material: Recommended Operational Process

When leftover material is lying on the production floor after job completion, it is typically not practical or desirable to return it order-by-order. Here's why:

• Leftover quantities per job order are usually small and scattered.

• The financials for each job order are already closed, including consumption accounting.

• The same material types may have been issued across multiple job orders.

• Certain materials (e.g., clamps, bolts, reusable packaging) are expected to be reused and rarely returned.

✅ Recommended Return Process: Inter-Store Delivery Note (ISDN)

Instead of returning materials job order by job order, the preferred method is to accumulate unused material by type and volume, and periodically return them using a Return Inter-Store Delivery Note.

Steps:

1. Physically collect and classify leftover materials on the production floor.

2. Segregate reusable vs. returnable material.

3. Prepare a Return Inter-Store Delivery Note in Tuhund:

   • Source: Production Store (or Floor)

   • Destination: Chosen store for restocking

   • Reference: Mark as Material Return

4. Transport the material accordingly.

5. Complete the digital transaction to ensure stock accuracy.

🚧 When Job-Order Based Returns Are Justified

Although Tuhund supports direct return of material from a job order, this is not recommended as the primary process unless:

• The leftover quantity is large or expensive.

• There is an audit or after-delivery adjustment.

• The material is owned or tracked per job (e.g., customer-supplied).

In such cases, material can be returned directly using a job reference, but it must be a manual and intentional action, not an automated one.

📝 Summary

• The system reflects legal and operational truth — not user expectations or shortcuts.

• Material must always move through legal transactions.

• The Production Floor is a Store, both physically and legally.

• Use Return ISDN as the standard method for sending unused material back to stores.

• Avoid the mindset of ERP as a passive system — treat Tuhund as a live operational partner.

Inventory is often seen as one of the most complex and error-prone modules in any ERP system. But in mature platforms like Tuhund, the system itself is rarely the source of trouble. Over years of experience working with customers in industries dealing with machines and spare parts, one insight has become abundantly clear:

"99% of inventory issues are human mistakes — not software limitations."

Despite Tuhund’s real-time stock tracking, multi-location store management, and deep integration with sales, service, procurement, and financials, inventory still causes problems when users treat the ERP like a book-keeping system rather than a live operational platform.

Let’s break down why inventory remains tricky — and how to eliminate most of the problems through discipline, design, and awareness.

⚠️ The Core Problem: Book-Keeping Mentality vs Operational Discipline

The most common and impactful mistake? Doing the work somewhere, and logging it elsewhere — later, by someone else.

• A technician uses parts at a customer site but doesn’t log them until the end of the day.

• Goods are received and stocked, but the entry is made based on the delivery challan the next morning.

• A sales user issues material from one branch but enters it under a different store.

These aren’t system issues. They’re workflow discipline issues. And they result in:

• Wrong stock levels

• Parts showing “out of stock” when they’re lying in a store

• Lost sales

• Duplicate purchases

• Service delays

• Financial mismatches

Tuhund is designed for real-time, actuals-based operations — not for post-facto data entry.

🧍‍♂️ Common Human Errors That Disrupt Inventory

Here are the most frequent mistakes — all avoidable — that lead to incorrect inventory data:

1. Skipping Transactions

Users forget to log a stock transfer, material issue, or part return.

2. Wrong Store or Location Selection

Users pick the wrong store or default to an old one without checking.

3. Manual Adjustments or Shortcuts

Stock is manually adjusted instead of being properly issued or received.

4. Incorrect Quantities, Units, or Items

Confusion between units (box vs piece), wrong variant, or wrong item selected.

5. No Discipline in Returns

Returned or rejected material is not recorded back into inventory.

6. Wrong Product Stock-In

Simulated Story
A store executive stocked in a shipment of sensors but accidentally selected an older model code. Later, the system showed the actual model as out of stock, resulting in a lost order and urgent re-purchase — for items already lying in the store.

Fix: Enforce barcode scanning and product image verification during stock-in.

7. Working Outside the System

Staff maintain Excel sheets, mental notes, or WhatsApp groups to track parts.

8. Disconnected Actions and Entries

Simulated Story
A technician completes a motor replacement, consumes three parts but reports only two over the phone to the coordinator. The system stock shows one extra part. Another job is booked assuming availability — only to discover the stock doesn’t exist.

Fix: Use Tuhund’s mobile app or in-field entry features. Train users to log actions as they happen.

✅ Common Recommended Workflows (but not the only ones)

Tuhund supports every practical workflow — standard, industry-specific, and even company-specific. The system is built to enforce discipline without forcing rigid structures.

Below are some recommended and widely used workflows, but Tuhund supports many more combinations based on your operational needs.

🛒 Procurement Workflows

🔹 Common Standard Flow:

1. RFP (Request for Purchase) – Purchase need is recorded and justified (indent, service job, stock).

2. RFQ (Request for Quotation) – Sent to multiple vendors.

3. Quote Comparison – Based on price, lead time, terms, etc.

4. Purchase Order (PO) – Issued to selected vendor.

5. Goods Receipt Note (GRN) – Created on physical receipt.

6. Purchase Invoice – Matched with PO and GRN.

🔹 Import-Specific Flow:

• Purchase Invoice may be entered before GRN due to advance documentation and payment requirements.

🔹 Other Supported Variants:

• Direct PO → GRN (no RFQ for urgent/known items)

• FRP → PO → GRN → Invoice

• GRN first (for unknown vendors), followed by retroactive PO and invoice

Tuhund adapts to procurement models across geographies, urgency levels, and vendor types.

💼 Common Sales Workflows

🔹 Common Domestic Sales Flow:

1. Inquiry → Quotation → Sales Order → Delivery Note → Invoice

🔹 Commercial or B2B Flow:

1. Inquiry → Quotation → Sales Order → Invoice → Delivery Note

🔹 Indent Flow:

1. Inquiry → Quotation → Sales Order → Indent Order → Installation

🔹 FMCG Sales Flow:

1. Sales Order → Delivery Trip → Invoice → Delivery

🔹 Production-Driven Sales:

1. Inquiry → Quotation → Sales Order → Job Order (production) → Delivery Note → Invoice

Every workflow is fully traceable and tied to inventory, financials, and documentation — automatically.

✅ How Tuhund Helps Prevent These Issues

Tuhund isn’t just an ERP — it’s a workflow enforcer and real-time operation tool. Here's how it minimizes errors when used properly:

• Store-level permissions to ensure users see and touch only what they’re responsible for

• Barcode and QR support for accurate item recognition

• Mobile access to record data where the work actually happens

• Audit trails and alerts to catch skipped steps or mismatches

• Workflow validation — e.g., no invoice without confirmed delivery

• Drill-down reports that trace every movement and transaction

🧠 Final Advice: Discipline Over Data

ERP systems like Tuhund are extremely powerful — but their true strength comes when people use them the way they’re meant to be used: as operational control systems, not as post-facto recorders.

If you use the system as an afterthought, it becomes inaccurate. If you use it as your guide, it becomes your single source of truth.

Encourage your teams to:

• Enter data at the point of action

• Avoid working outside the system

• Take ownership of accuracy

• Trust the system to guide operations, not just document them

The fewer the gaps between what happens and what is entered — the fewer the errors.

🔍 Tuhund Helps Catch and Correct Mistakes — But Only to a Point

Tuhund has inbuilt mechanisms to identify and flag discrepancies, including:

• Stock mismatches

• Duplicate entries

• Invalid workflows

• Out-of-sequence documentation

• Suspicious data patterns via AI-powered insights

In many cases, the system can also suggest or initiate corrections, such as:

• Auto-adjusting GRNs based on actual delivery

• Notifying users of probable human error

• Blocking transactions that violate business rules

However, there is a critical threshold beyond which even the most intelligent system — including AI — can no longer help.

Once data entered into the system is too inconsistent, delayed, or wrong, no system can fix it without human intervention.

Tuhund can guide, protect, and assist — but ultimately, it relies on timely, accurate input from its users to deliver the clean, reliable data that powers good decisions.

📣 For Teams Using Tuhund:

"Don't treat Tuhund as a ledger. Treat it as the shop floor, the service site, the warehouse, the field — because that’s what it is."

And always remember:

“When you respect the data, the system will always have your back.”