Skip to content

Key and submit a bill

A user keys a bill header, saves it and submits it, after which the browser returns to the Inbox or, with Auto feed checked, the next queue bill loads.

Trigger and screens

Item Detail
Trigger User keys a new bill on the Bill entry screen and selects Submit
Screens Bill entry
Tables Not traced**

Steps

  1. The screen calls Entry.GetNewBill for an empty bill, or Entry.GetBillFromQueue when Auto feed is checked.
  2. GetNewBill calls IBillEntryService.GetNewBill; GetBillFromQueue calls IBillEntryService.GetNextClaimBillFromQueue, passing whether the user holds ConflictClaim.
  3. Each action reads the remaining queue count with IBillEntryService.GetClaimBillQueueRemainingCount, maps the bill to the entry view model and returns it as JSON.
  4. The user enters the SAIF claim number. The screen calls Entry.GetWorkerInformation to load the worker.
  5. The action calls IClaimInformationService.GetClaimId; a zero id returns "Invalid claim number".
  6. For a conflict claim without ConflictClaim access the action returns "This is a secured claim".
  7. The action calls IClaimInformationService.GetWorker and returns the formatted worker name and birth date.
  8. The user keys the header fields. Type of bill must be numeric (BR-SCR-007) and Admit type must be 1 to 5 or 9 (BR-SCR-008).
  9. The provider tax id is validated through Provider.ValidateProviderTin, and billing providers are chosen through Provider.GetBillingProviders.
  10. Leaving the page with unsaved edits shows a warning (BR-SCR-009).
  11. The user selects Save. The screen posts to Entry.SaveBill.
  12. The action maps the posted WorkerViewModel to a Bill with AutoMapper.
  13. The action calls IBillEntryService.SaveBill with the bill and a ModelStateWrapper. FluentValidation validators from the BillValidator assembly are registered in the composition root; whether SaveBill actually invokes them was not confirmed**.
  14. When the model state holds errors the action returns them as JSON; otherwise it maps the saved bill back to the entry view model with the queue count.
  15. The user selects Submit. The client requires at least one service line (BR-SCR-003) and asks for confirmation when Total Bill Amount differs from Services Total (BR-SCR-004).
  16. The screen posts to Entry.SubmitBill.
  17. The action maps the worker to a Bill and calls IBillEntryService.SubmitBill.
  18. Only when no errors are returned does the action call IBillEntryService.UpdateBillStatus with the mail id SYSTEM and the status ENT (BR-SCR-005).

Origin: Steps 1.1, 2.1–2.3 and 6.1–6.2 are the controller-side calls to IBillEntryService and IClaimInformationService in SAIF.SAIFCode.Core†. Per the Legends CLI RAG service, SAIF.SAIFCode.Core is a contracts-only library and these interfaces' implementations live outside it (most likely SAIF.Services) and were not traced by this run*. Step 4.2's validator registration is confirmed in the composition root (SAIF.DependencyMaps.Web.ClaimBillEntry/DependencyMap.cs:263-271), which scans the BillValidator assembly for FluentValidation validators; whether IBillEntryService.SaveBill invokes them internally was not confirmed**. 7. On success the client checks the Auto feed checkbox (ClaimBillEntry/js/ClaimBillEntry.entry.js:212-220). 1. When Auto feed is checked, the screen loads the next queue bill through getNextQueueBill and stays on Bill entry. 2. When Auto feed is not checked, the browser navigates to the Inbox screen.

Process flow

The diagram shows the main path and its decision points.

flowchart TD
    A["GetNewBill or GetBillFromQueue"] --> B["Key header fields<br>(type of bill, admit type)"]
    B --> C["SaveBill"]
    C --> D{"Has a service line?"}
    D -->|"No"| X["Submit blocked"]
    D -->|"Yes"| E{"Total equals<br>services total?"}
    E -->|"No"| F{"User confirms?"}
    F -->|"No"| X
    F -->|"Yes"| G["SubmitBill"]
    E -->|"Yes"| G
    G --> H{"Errors returned?"}
    H -->|"Yes"| Y["Show errors, status unchanged"]
    H -->|"No"| Z["Status ENT"]
    Z --> W{"Auto feed checked?"}
    W -->|"Yes"| V["Load next queue bill<br>(stay on Bill entry)"]
    W -->|"No"| U["Navigate to Inbox"]

Failure and edge-case behavior

  • Invalid type of bill or admit type shows the field message and is blocked on the client (BR-SCR-007, BR-SCR-008).
  • Submit errors are returned to the screen and the status is not changed (BR-SCR-005).
  • The endpoints have no anti-forgery validation; see Tech debt.

Note: Statements marked with † are derived from dependency library documentation via the Legends CLI. Statements marked with * were inferred from code structure or contextual evidence. Statements marked with ** could not be confirmed; treat as unknown until verified.

Sources

  • ClaimBillEntry/Controllers/EntryController.cs
  • ClaimBillEntry/Controllers/ProviderController.cs
  • ClaimBillEntry/js/ClaimBillEntry.entry.js
  • ClaimBillEntry/js/claimbillentry.entry.worker.js
  • ClaimBillEntry/Views/Entry/_Worker.cshtml