Module Configurations¶
Applies to: All subscriptions
Purpose¶
Configure each licensed module to the customer's business rules, and make clear which rules are theirs to choose and which are fixed by statute. Confusing the two produces either an unnecessary support ticket or a compliance failure.
Audience¶
Implementation consultants and the module's business owner on the customer side.
Prerequisites¶
- Installation Guide and Configuration Guide complete
- The module licensed and enabled for the relevant registrations — see Feature Flags
- Master data loaded
Steps¶
| Module | Page | Default state |
|---|---|---|
| e-Invoice | e-Invoice Module | On |
| e-Way Bill | e-Way Bill Module | On |
| Invoice Generation | Invoice Generation Module | Off |
| TDS | TDS Module | Licensed separately |
| Data Privacy | Data Privacy Module | Licensed separately |
Configure in this order¶
Modules depend on each other, and configuring them out of order produces work that has to be redone:
Master data
|
v
e-Invoice ------> e-Way Bill (a bill can be raised from an IRN)
|
v
Invoice Generation (produces documents that feed e-Invoice)
|
v
TDS, Data Privacy (independent)
What is yours to choose, and what is not¶
The single most useful distinction in this section:
| Fixed by statute — not configurable | Yours to configure |
|---|---|
| Which document types require an IRN | Whether to route additional types to IRN anyway |
| That an IRN is permanent and its number never released | Your own numbering scheme |
| The reporting window for your turnover band | Alert horizons and how you monitor them |
| e-Way Bill validity based on distance | When to warn about approaching expiry |
| That Part-B is required for movement | Who updates it, and by which process |
| The cancellation window | Your internal approval before cancelling |
| Return formats and validation rules | Your review and approval workflow |
When a customer asks for a change on the left-hand side, the answer is not a configuration change. It is an explanation, and this portal's job is to make that explanation available before it becomes a ticket.
Validation¶
For each licensed module:
| Check | Pass condition |
|---|---|
| Enabled on the right registrations | Present for every intended GSTIN |
| Roles can use it | A real user of the module can complete their normal work |
| Business rules configured | Thresholds and options match the customer's decisions, recorded |
| End-to-end tested | One real document through the module's full path, in the sandbox |
| Failure paths tested | A deliberate failure produces a specific, actionable message |
| Operational routine handed over | The module's daily and monthly checks are with the customer's operations owner |
Troubleshooting¶
| Symptom | Cause | Action |
|---|---|---|
| A module is entirely absent | Not licensed, or not enabled for that registration | See Modules and Licensing |
| Module present, controls greyed out | Role lacks the permissions | See Roles and Permissions |
| A statutory rule is challenged as a product limitation | The distinction above was not made | Use the table. A statutory constraint is never a support ticket |
| Configuration done out of order and repeated | Dependencies not followed | Follow the ordering diagram |
| A module works in test and not in production | Configuration drift, or production credentials never applied | Compare configuration between environments |
Related Articles¶
- Feature Flags — enabling modules
- Modules and Licensing — what each covers
- Implementation Programme — where module setup sits in an onboarding
- Operations Guide — running each module day to day