The implemented xMatix e-way-bill entry point is the E-Way Bill action on an Invoice. It creates a Draft EWayBill row with a Part A payload and a link back to that Invoice. A separately configured integration must submit the payload and record the generated number and response before the row represents a generated e-way bill.
The domain model is broad enough to describe other source document types, but the reviewed runtime action always sets SourceEntityName to Invoice. Delivery orders, transfers and generic “movement documents” do not currently call this service. A blank New E-Way Bill form would therefore misrepresent the supported flow and is intentionally not shown here.
What Draft creation fills
The Invoice action supplies or defaults the following values:
| Field | Current behavior |
|---|---|
| Source | The Invoice ID and Invoice number |
| Document type | Tax Invoice |
| Supply / sub-supply | Outward / Supply |
| Value | Sum of active Invoice-line amount and tax amount |
| Distance | Optional action argument; defaults to 0 |
| Transport mode | Optional action argument; defaults to Road |
| Vehicle number | Optional |
| Transporter ID/name | Not populated by the Invoice action |
| Registration and branch | Resolved from the Invoice filing context |
| Status | Draft |
The service stores the Part A JSON on the EWayBill row. It does not call a provider from the Invoice handler.
What generation must add
EWayBillService.RecordGeneratedAsync is the domain writeback path. Given an EWayBill ID, provider-issued EWB number, generation date, optional Part B payload and raw response, it stores those values, calculates ValidUpto, and changes Status to Generated.
No EWayBill server-action handler currently exposes this method to an ordinary record screen, and no runtime caller was found outside the expected external integration flow. Before production use, implement or verify a bound flow that submits the Draft and invokes the writeback safely.
The service also contains register and “expiring soon” query methods, but no current handler or page calls them. The generic EWayBill entity list can display saved rows; it is not evidence that an expiry-monitoring workflow is running.
Procedure
Step 1 — Validate the Invoice and transport facts
Open the Invoice and confirm the issuing registration, recipient, document number/date, taxable value and tax. Determine the real route distance, transport mode and vehicle information required by your provider. The action does not require Approved or Posted status, so make document approval part of your operational control.
Do not accept the defaults without review. A zero distance still creates a Draft, transporter values remain blank, and the action hard-codes Tax Invoice and Supply. If the movement is job work, stock transfer, delivery challan or another subtype, the current Invoice action is not the correct complete payload builder.
Step 2 — Create one controlled Draft
Run E-Way Bill on the Invoice with the reviewed optional arguments. The action returns the new EWayBill ID and Draft status. Open that exact row from the entity list and compare its source link, Part A payload, value, registration, distance and transport data with the Invoice and dispatch evidence.
The current action has no duplicate-Draft guard. Check for an existing EWayBill linked to the Invoice before running it again, and do not create several Draft rows as a retry mechanism.
Step 3 — Submit through the configured integration
Allow the explicitly configured provider flow to consume the Draft. A successful flow must retain its provider request/response, obtain the EWB number, and call the generated-response writeback for the same EWayBill ID. Until that happens, Draft is not authority to move goods.
When writeback succeeds, verify EWB number, generated date, Part B response, status and calculated validity. The current service calculates one day for each 200 km or part, with a minimum of one day, from the generated date. Confirm the current statutory rule and the portal's returned validity rather than relying on documentation for a changing legal requirement.
Step 4 — Control the remaining lifecycle externally
The status taxonomy includes Cancelled and Expired, but the reviewed runtime provides no cancellation action, expiry transition or automatic expiry job. Portal cancellation, extension or replacement must follow your external statutory process, and any xMatix status update needs an explicitly designed, audited integration or product action. Do not infer cancellation merely from a date having passed.
Expected result
A single Invoice-linked EWayBill row progresses from Draft to Generated only after the configured external flow writes back a provider-issued EWB number. Its source, value, transport facts, response and validity agree with the Invoice and portal evidence. Other document types and cancellation/expiry automation are outside the current runtime action.
Common problems
The row remains Draft with no number
Draft creation succeeded but provider submission/writeback did not. Inspect the integration run. The current Invoice handler does not submit or poll the provider, and the generic record form does not complete generation.
Distance is zero or transporter data is blank
Those are current action defaults, not values derived from logistics data. Supply reviewed arguments or extend the mapping before dispatch; do not treat the Draft as complete.
Several Drafts exist for one Invoice
The action does not check for an existing EWayBill. Select the intended record under an approved cleanup/control process and prevent another invocation; generation should write back to one known ID.
A generated row passed its Valid Upto date but still says Generated
No automatic status transition marks it Expired. Use the portal as the statutory authority and treat expiry monitoring/status synchronization as an integration gap until a runtime action or job is implemented.