VIA Authorization Management — Gap Analysis Review
Comparing current Odoo 17 sale.order / product.template against VIA Authorization spec · Generated March 30, 2026 · Task 2dd405f0 · Parent: fe7887bf
How to use this document: Each change item shows what the spec asks for versus what currently exists. Click Agree (proceed with change) or Disagree (skip or modify). Add an explanation for any Disagree. When done, click Export YAML at the bottom — paste the output into a Claude chat to resume implementation planning.
0 of 0 items reviewed
78–110
Estimated Total Hours
34
Change Items
5
Sections + Open Questions
Section 1 — Authorization Dashboard (List View)
7 items · ~14–20 hrs
DB-1
Dashboard is view-only (no inline editing)
LOW
~1 hr
Spec Says
All authorizations listed in a read-only dashboard. Users can view and filter but cannot inline-edit from the list view.
Current State
Odoo's default sale.order tree view (sale.view_order_tree) allows inline editing of some fields. VIA has no custom tree view for sale.order — uses the stock Odoo list. Fields like partner_id are already renamed to "Person Supported" via via_sales_enhancement.
Planned Action
Create an inherited tree view with editable="false" (or simply remove any editable attribute). Set all list columns to readonly="1". The view should display the spec columns: Person Supported, Service Type, Start Date, End Date, Units, ICD-10, Region.
DB-2
All authorizations listed with user filtering
LOW
~1 hr
Spec Says
All authorization records are listed. User can apply filters to narrow results.
Current State
Odoo's default sale.order list already shows all quotations/orders with built-in search and filter capabilities. The existing search view provides filters for Status, Salesperson (renamed "Support Partner"), dates, etc.
Planned Action
Extend the search view to add Authorization-specific filters: by Person Supported, Service Type, Region, date range. Most filtering capability already exists via Odoo's standard search — this is mainly adding custom filter shortcuts.
DB-3
Default sort: Start Date, then alpha by Person Supported last name
LOW
~1 hr
Spec Says
Sort by Start Date ascending, then alphabetical by last name of Person Supported.
Current State
Default sale.order ordering is by id desc (newest first). No Start Date or Person Supported name-based sort. The current model has date_order (Order Date) but no dedicated "Authorization Start Date" field on the header.
Planned Action
Override _order on sale.order to sort by auth start date ascending, then partner name alphabetical. This requires either: (a) a stored field on sale.order for the earliest line's start date, or (b) a related field pulling from sale.order.line. The partner name sort should use the partner_id.name field.
Start Date is on
sale.order.line, not the header. If an authorization has multiple lines with different start dates, which date should drive the sort — the earliest line's start date?
DB-4
Selection checkbox for bulk actions (including duplicate)
LOW
~0.5 hrs
Spec Says
User uses the selection checkbox to the left of Person Supported to perform actions, including duplicating records.
Current State
Odoo's list view already has selection checkboxes by default. The standard "Action" dropdown includes "Duplicate" among other options. This is built-in behavior.
Planned Action
Minimal work needed — the checkbox and basic duplicate action already exist. The custom part is the date-override popup (see DB-5). May need to restrict available actions to only those relevant for authorizations.
DB-5
Bulk duplicate with date override popup
HIGH
~6 hrs
Spec Says
When duplicating multiple records, initiate a popup that asks for new Start and End dates to be applied to all duplicated records.
Current State
No bulk duplicate with date override exists. Odoo's default duplicate copies each record as-is with no popup for field overrides. The standard copy() method on sale.order duplicates the header and lines with original values.
Planned Action
Build a wizard model (sale.order.duplicate.wizard) with:
new_start_date: Date field (required)new_end_date: Date field (required)order_ids: Many2many → sale.order (populated from selected records)
Does this duplicate the entire authorization (header + all service lines), or should users be able to select individual lines? Also, should other line fields (units, amounts) be copied as-is, or reset?
DB-6
Remove Sales Order number from view
LOW
~0.5 hrs
Spec Says
Remove the Sales Order number from the dashboard and form views.
Current State
The name field (S00001, S00002…) is the primary identifier in both list and form views. It appears as the first column in the tree view and in the form header. The field cannot be removed from the model (it's used for internal references, invoicing, etc.), but can be hidden from views.
Planned Action
Hide name field from the tree and form views via invisible="1". The SO number will still exist internally for system operations but won't be visible to users. Alternatively, if VIA wants a custom identifier, we could add an "Authorization Number" field with a custom sequence.
Should we create a replacement "Authorization Number" with a custom sequence (e.g., AUTH-0001), or simply hide the SO number entirely?
DB-7
Rename "Sales Orders" to "Authorization" throughout
MEDIUM
~4 hrs
Spec Says
Change all references from "Sales Orders" to "Authorization" throughout the Odoo interface.
Current State
The labels_change module already renames "Sales Order" → "Service Order" and "Product" → "Service" across 200+ field descriptions via ir.model.fields data records. The module also renames "Salesperson" → "Support Partner" and "Sales Team" → "Support Team." So the current UI says "Service Order" — not "Sales Order" and not yet "Authorization."
Planned Action
Update the labels_change module (or create a new data file) to change "Service Order" → "Authorization" in all relevant ir.model.fields records. This includes: menu items, breadcrumbs, field descriptions, button labels, and window titles. Also update ir.model descriptions and ir.actions.act_window names. Estimated ~30-40 field description changes plus menu/action renames.
Section 2 — Authorization Form Header
3 items · ~6–10 hrs
AH-1
Header fields populated from crm.lead (Person Supported, MA Number, Internal ID)
HIGH
~4 hrs
Spec Says
The form header contains only: Person Supported (from crm.lead), MA Number (from crm.lead), Internal ID (from crm.lead). These are auto-populated when the authorization is created from a CRM lead.
Current State
via_sales_enhancement renames partner_id → "Person Supported" on the sale.order form. The partner_id is set when creating a quotation from CRM. However, ma_number and internal_id are on res.partner, not on sale.order directly. They would need to be displayed as related fields or added as stored fields on sale.order. The CRM → sale.order flow goes through action_sale_quotations_new() and _handle_partner_assignment() which syncs lead fields to the partner record.
Planned Action
- Add
ma_numberandinternal_unique_idas related fields onsale.orderpulling frompartner_id.ma_numberandpartner_id.internal_unique_id_code - Restructure the form header to show only these three fields (Person Supported, MA Number, Internal ID)
- Hide default sale.order header fields that aren't in the spec (date_order, validity_date, payment_terms_id, etc.)
- Ensure the CRM → Authorization creation flow populates partner_id correctly via the existing sync mechanism
The
ma_number field feeds PROMISe EDI (Medicaid claims). The internal_unique_id_code connects to HCSIS/iRecord. Changes to how these fields display on sale.order must not break the data flow from crm.lead → res.partner → sale.order.
AH-2
Model label reads "Authorization" (not "Sales Order")
LOW
~1 hr
Spec Says
The Odoo model label must read "Authorization" (not "Sales Order").
Current State
The sale.order model's _description is "Sales Order" in Odoo core. The labels_change module renames many field labels but doesn't change the model-level description. Window titles and breadcrumbs still show "Sales Order" or "Quotation."
Planned Action
Override _description = "Authorization" on the inherited sale.order model. Update ir.actions.act_window records for sale.order to use "Authorization" as the window title. Update menu item labels. This overlaps with DB-7 — can be done in the same pass.
AH-3
Remove Sales Order number from form
LOW
~0.5 hrs
Spec Says
Remove the Sales Order number field from the form view.
Current State
The name field appears at the top of the form in the oe_title div. It's auto-generated via sequence (SO001, SO002…). Same as DB-6 but for the form view specifically.
Planned Action
Add invisible="1" to the name field in the form view via inherited XML. Combined with DB-6 (list view), this fully hides the SO number from users while keeping it for internal Odoo operations.
Section 3 — Authorization Service Line (sale.order.line)
11 items · ~28–36 hrs
SL-1
Service Type populated from crm.lead with editable LOV
MEDIUM
~3 hrs
Spec Says
Service Type is populated from crm.lead with a list of values; user may edit. LOV includes 16 service types (W7096, H0043, W7060, etc.).
Current State
The existing sale.order.line uses product_id (Many2one → product.product) as the "Service" field. Products/Services are managed in product.template. On crm.lead, there is a service_ids field (Many2many → product.template) that tracks which services are associated with a lead. When a sale order is created from CRM, the line's product comes from what the user selects — not auto-populated per se. The 16 service types from the spec would be product.template records.
Planned Action
- Ensure all 16 spec service types exist as
product.templaterecords with correct names and codes - When creating an authorization from CRM, pre-populate available service types from the lead's
service_ids - Allow user to change/add service types on the order line (already possible with product_id field)
- Consider domain filter on
product_idto only show authorized service types for the person
SL-2
Service Type Code auto-populates from Service Type selection
LOW
~1 hr
Spec Says
Service Type Code auto-populates based on the selected Service Type using a defined code mapping (e.g., "IHCS" → W7060).
Current State
product.template has a default_code field (renamed "Program ID" by via_sales_enhancement). This is the standard Odoo "Internal Reference" field. When a product is selected on a sale order line, product_id.default_code is accessible as a related field. No separate "Service Type Code" field exists on sale.order.line.
Planned Action
Add a related/computed service_type_code field on sale.order.line that pulls from product_id.default_code. Ensure all 16 product templates have correct default_code values matching the spec's code table (W7096, H0043, etc.). Display as readonly on the order line.
SL-3
Authorization Start Date and End Date on each service line
MEDIUM
~2 hrs
Spec Says
Each service line has its own Authorization Start Date and Authorization End Date with calendar pickers.
Current State
Standard sale.order.line has no start/end date fields. Dates exist on the order header (date_order, validity_date) but not per-line. VIA's CRM lead has plan_start_date and plan_end_date which sync to the partner, but these are not on sale.order.line.
Planned Action
Add auth_start_date (Date, required) and auth_end_date (Date, required) fields to sale.order.line. These will be line-specific, allowing different authorization periods per service type. Default values could come from the CRM lead's plan dates. Display as calendar pickers in the inline tree.
SL-4
Authorized Units (editable numeric field)
LOW
~0.5 hrs
Spec Says
Authorized Units is a numeric field that allows manual editing.
Current State
sale.order.line has product_uom_qty (Quantity) — this is the standard ordered quantity field. It's already editable and numeric. The via_tab_service_lines module displays this on partner cards as authorized units. The labels_change module does not rename this field.
Planned Action
Reuse existing product_uom_qty field, renamed to "Authorized Units" via a view-level string attribute or via labels_change. Minimal work — field already exists and is editable.
SL-5
Total Authorized Amount (auto-calculated: Units × Rate)
MEDIUM
~2 hrs
Spec Says
Total Authorized Amount = Authorized Units × Unit Rate (from Service Type List / product.template).
Current State
sale.order.line already has price_subtotal (computed: product_uom_qty × price_unit). The price_unit is typically set from the product's list_price (renamed "Service Rate" by labels_change). This is essentially the same calculation the spec requires.
Planned Action
Reuse price_subtotal renamed to "Total Authorized Amount." Ensure price_unit auto-populates from the product's current active rate. If the spec's Rate History model (ST-3 through ST-6) changes how rates are stored, this computation may need adjustment to pull the correct rate based on the line's date.
The amount calculation feeds billing/invoicing. If the rate source changes from
list_price to a custom rate history model, the price_unit population logic must be updated accordingly.
SL-6
Remaining Units (auto-calculated: Authorized − Paid/Consumed)
HIGH
~4 hrs
Spec Says
Remaining Units is auto-calculated by deducting the number of units paid/consumed from Authorized Units.
Current State
sale.order.line has qty_delivered (delivered quantity) which is computed from timesheet hours (via _compute_qty_delivered). VIA's via_sales_enhancement overrides this with custom rounding: math.floor(mapping * 100 / 25) (converting hours to 15-min units). The via_tab_service_lines module shows "Used" vs "Units" on partner kanban cards with a progress bar.
Planned Action
- Add a computed
remaining_unitsfield:product_uom_qty - qty_delivered - The deduction source needs clarification: Is it from timesheet entries (current), Sandata EVV data, or invoice lines? Each source gives different numbers.
- Current
qty_delivereduses a custom rounding formula that converts timesheet hours to 15-min billing units — confirm this is the correct deduction mechanism
The "units paid" deduction source is ambiguous. Timesheet-based delivery (current) may differ from EVV-based (Sandata) or invoice-based consumption. This needs clarification before implementation — incorrect deduction logic directly impacts billing accuracy.
SL-7
Region of Service (from crm.lead, editable LOV)
MEDIUM
~2 hrs
Spec Says
Region of Service populated from crm.lead with LOV (Central, Northeast, Southeast, West). User may override.
Current State
Region exists on crm.lead as pre_auth_region (Selection field) and syncs to res.partner. It does NOT exist on sale.order.line. The via_tab_authorization module shows region on the partner's Authorization tab. The via_tab_service_lines module shows "Region of Service" in the service lines header on the partner form. However, this is partner-level, not per-line.
Planned Action
Add region_of_service Selection field to sale.order.line with values [Central, Northeast, Southeast, West]. Default from partner's pre_auth_region (which originated from crm.lead). Allow user override per line.
SL-8
County of Service (from crm.lead, editable LOV)
MEDIUM
~2 hrs
Spec Says
County of Service populated from crm.lead with LOV (all PA counties). User may override.
Current State
County exists on crm.lead as pre_auth_county_id (Many2one → via.res.county, a custom model defined in via_crm). Syncs to res.partner. Not on sale.order.line. The via_tab_service_lines module shows County on the partner service lines header.
Planned Action
Add county_of_service_id (Many2one → via.res.county) to sale.order.line. Default from partner's pre_auth_county_id. Allow override per line. The full PA county list already exists in the via.res.county model.
SL-9
Payer ID, Payer Program, ICD-10 Code, Modifier (LOV fields)
HIGH
~6 hrs
Spec Says
Four LOV fields on each service line: Payer ID [PAODP, PAOLTL], Payer Program [ODP, BASE, OLTL, OMAP, PHC, CHC, Private Pay], ICD-10 Code [F70-F79, F84.0, Other], Modifier [U6, U7, U7-HI, U8].
Current State
payer and payer_program exist on crm.lead and res.partner (Selection fields) — but NOT on sale.order.line. No icd10_code or modifier fields exist anywhere in the current codebase. These are billing-critical fields that currently live outside Odoo (likely in billing spreadsheets or Sandata).
Planned Action
Add four new Selection fields to sale.order.line:
payer_id: Selection [('paodp','PAODP'), ('paoltl','PAOLTL')]payer_program: Selection [('odp','ODP'), ('base','BASE'), ('oltl','OLTL'), ('omap','OMAP'), ('phc','PHC'), ('chc','CHC'), ('private_pay','Private Pay')]icd10_code: Selection [('f70','F70'), ('f71','F71'), ('f72','F72'), ('f73','F73'), ('f78','F78'), ('f79','F79'), ('f840','F84.0'), ('other','Other')]modifier: Selection [('u6','U6'), ('u7','U7'), ('u7hi','U7-HI'), ('u8','U8')]
Payer ID and Payer Program directly feed PROMISe EDI claims (837 transactions) and Sandata EVV. ICD-10 codes and Modifiers are required for billing. Adding these to sale.order.line is essential for the billing pipeline. Key mismatch risk: the crm.lead and res.partner payer fields have different technical keys — verify LOV values match exactly.
SL-10
Eligibility field (TBD)
LOW
~0.5 hrs
Spec Says
Eligibility field — marked as TBD. No data type, LOV, or requirements defined.
Current State
The via_tab_service_lines module has eligibility badge rendering on partner kanban cards, pulling from service_line_eligibility_json (computed from PROMISe 271 responses via the promise.service.type.mapping model). This is a read-only display of X12 271 eligibility data — not a user-editable field.
Planned Action
Defer until requirements are defined. The existing eligibility infrastructure (PROMISe 271 → mapping → badge display) may be what VIA actually wants here, just surfaced on the authorization form instead of only on the partner card.
Is this meant to be a manual entry field, or should it display the automated eligibility status from PROMISe 271 responses? The existing system already computes eligibility per service line from EDI data.
SL-11
Funding Source field ("PA PROMISe" — unclear requirements)
LOW
~0.5 hrs
Spec Says
"PA PROMISe" noted with "???" — unclear if this is a field, a default value, or informational.
Current State
A funding_source field exists on res.partner and is displayed on the via_tab_service_lines partner tab. The via_tab_authorization module does not show it. It's not on sale.order or sale.order.line. Current values and definition are unclear from the codebase.
Planned Action
Defer until VIA clarifies whether this is: (a) a new field on sale.order.line, (b) a display of the partner's existing funding_source, or (c) just a label/note. If it's always "PA PROMISe" for all PA authorizations, it may be informational only.
Is Funding Source a separate editable field on each authorization line, or is it inherited from the partner record? Is "PA PROMISe" always the value, or are there other options?
Section 4 — ISP Program Tab
3 items · ~4–6 hrs
ISP-1
Free-form text fields for ISP outcomes
LOW
~2 hrs
Spec Says
Seven text fields: Outcome Name, Outcome Statement, Reason for Outcome, How will we know progress is being made, Actions, Frequency and Duration, Comment. All free-form text, fully editable.
Current State
No ISP fields exist on sale.order. On product.template, there is an isp_description Html field (added by via_sales_enhancement) displayed on an "ISP Description" tab — but this is per-service-type, not per-authorization. No outcome tracking exists on the authorization/sale order level.
Planned Action
Add seven fields to sale.order: isp_outcome_name (Char), isp_outcome_statement (Text), isp_reason (Text), isp_progress_indicator (Text), isp_actions (Text), isp_frequency_duration (Char), isp_comment (Text). Display on a new notebook page "ISP Program" on the authorization form.
Can an authorization have multiple ISP outcomes? If yes, these should be a One2many (separate model with these 7 fields) rather than flat fields on sale.order. If only one outcome per authorization, flat fields are simpler.
ISP-2
ISP is a notebook page on the Authorization form
LOW
~1 hr
Spec Says
This tab is a notebook page on the Authorization (sale.order) form.
Current State
The sale.order form has a notebook with pages: Order Lines, Optional Products (hidden by via_sales_enhancement), and other standard tabs. No "ISP Program" page exists. The only ISP-related content is on product.template (the isp_description Html field).
Planned Action
Add a new notebook page via inherited view XML. Following the One Module One Tab pattern from the VIA tab architecture, this should be its own module (e.g., via_tab_isp_program) at priority 25+ on sale.order's notebook.
ISP-3
No LOVs or computed fields — purely narrative
LOW
~0.5 hrs
Spec Says
All fields are free-form text and fully editable. No dropdowns, no auto-calculations.
Current State
N/A — the tab doesn't exist yet.
Planned Action
Straightforward implementation — all fields are Char or Text type with no constraints, no required flags, no computed logic. This is the simplest section of the entire spec.
Section 5 — Service Type List (product.template)
10 items · ~26–38 hrs
ST-1
Remove Region and Service Team references from product.template
LOW
~1 hr
Spec Says
In the current product.template, remove the reference to Region and Service Team.
Current State
The standard Odoo product.template form links to projects (renamed "Programs") which have team_id. The via_sales_enhancement module's _timesheet_create_project_prepare_values method copies team_id and program_type from the product's project template. Region is not directly on product.template — it's on the partner/lead. Service Team may appear via the project linkage.
Planned Action
Hide or remove team/region-related fields from the product.template form view. These data points should come from the Person Supported's authorization (sale.order.line), not from the service type definition.
ST-2
One entry per Service Type; billing data from Authorization
MEDIUM
~3 hrs
Spec Says
There should be only one entry per Service Type. All other billing data points (region, modifiers, FY, etc.) should be pulled from the Person Supported's authorization.
Current State
Currently product.template records may have duplicate service types for different regions or configurations. The project template linkage embeds team/region at the service type level. This conflicts with the spec's "one entry per service type" requirement.
Planned Action
- Consolidate duplicate product.template records into single entries per service type
- Remove region/team/modifier fields from product.template
- These billing data points move to sale.order.line (SL-7, SL-8, SL-9)
- Product.template becomes a clean master list: name, code, unit rate, UoM, EVV flag
Consolidating product.template records affects existing sale.order.line references, project templates, and timesheet mappings. This must be data-migrated carefully — existing authorizations point to specific product IDs that may be among the duplicates being merged.
ST-3
One active unit cost at a time (no end date = active)
HIGH
~4 hrs
Spec Says
A Service Type cannot have more than one active unit cost at a time. The active rate has no End Date.
Current State
product.template has a single list_price (renamed "Service Rate") field. There is no concept of rate versioning, start/end dates on rates, or rate history. Changing the price simply overwrites the current value. No start_date or end_date fields exist on product.template.
Planned Action
Create a new model service.type.rate (or product.rate.history) with fields: product_tmpl_id (Many2one), start_date (Date, required), end_date (Date), unit_rate (Float/Monetary). Add constraint: only one record per product can have a blank end_date. The current "active" rate drives list_price on the product template.
Rate changes affect all future billing. The Sandata EVV integration sends unit rate data — ensure the rate lookup uses the correct active rate based on the service date, not just the latest rate.
ST-4
End-dating existing rate triggers new rate creation
MEDIUM
~3 hrs
Spec Says
To change the unit cost, the existing entry must be end-dated and a new record created with the new rate.
Current State
No rate versioning exists. Price changes are immediate overwrites of list_price.
Planned Action
Build an onchange or write override on the rate model: when end_date is set on the active rate record, prompt user (via wizard or auto-action) to create a new rate record with start_date = end_date + 1 day and blank end_date. Update product.template.list_price to reflect the new active rate.
ST-5
Prompt user to create new rate when existing is end-dated
MEDIUM
~2 hrs
Spec Says
Once an End Date is entered, prompt the user to create a new rate.
Current State
No rate transition workflow exists.
Planned Action
Build a confirmation dialog or wizard that appears when an end date is saved on the active rate. Options: (a) auto-open a new rate form pre-populated with start_date = old_end_date + 1, or (b) show a warning message with a "Create New Rate" button. Combined with ST-4.
ST-6
Rate History tab (searchable archive of ended rates)
MEDIUM
~3 hrs
Spec Says
All rates with an End Date are moved to the Rate History area and will be searchable.
Current State
No Rate History tab or model exists. Product.template has the "ISP Description" tab (from via_sales_enhancement) but no rate tracking.
Planned Action
Display the rate model (ST-3) as a One2many on a "Rate History" notebook page on product.template. The inline tree shows Start Date, End Date, Unit Rate. Records with end_date populated appear here; the active (no end_date) rate appears in the main form area. Optionally add search/filter capabilities.
ST-7
EVV checkbox (sends data to Sandata)
HIGH
~4 hrs
Spec Says
EVV checkbox: if checked, this data is sent to Sandata for Electronic Visit Verification.
Current State
The sandata_integration and sandata_integration_extension modules handle EVV data flow to Sandata. The integration works at the timesheet/attendance level, not the product level. No evv Boolean exists on product.template currently. The Sandata integration uses sale.order.line product references to determine what gets sent.
Planned Action
- Add
evv_enabledBoolean field toproduct.template - Modify Sandata integration to check this flag before sending EVV data for a service type
- This creates a clean opt-in mechanism: only service types with EVV checked send data to Sandata
- Requires review of existing Sandata integration code to find the correct insertion point for the flag check
Changing the EVV data flow to Sandata impacts real-time compliance reporting. Must be tested thoroughly in staging before production deployment. Incorrect EVV data can result in PA Medicaid audit findings.
ST-8
Diagnosis Code Pointer (default: 1)
LOW
~0.5 hrs
Spec Says
Diagnosis Code Pointer field on product.template with default value of 1.
Current State
No diagnosis_code_pointer field exists on product.template.
Planned Action
Add diagnosis_code_pointer Integer field to product.template, default=1. This is a billing/claims field used in X12 837 transactions to reference which diagnosis code on the claim applies to this service line.
ST-9
Procedure Qualifier (HC-HCPCS — needs confirmation)
LOW
~0.5 hrs
Spec Says
Procedure Qualifier field — marked with "??" — value appears to be "HC-HCPCS."
Current State
No procedure_qualifier field exists. The via_tab_service_lines module references HCPCS codes in the service type mapping (promise.service.type.mapping), but this is for eligibility matching, not a form field.
Planned Action
Add procedure_qualifier Char field to product.template. Default to "HC" (HCPCS). This is used in X12 837 claim SV1 segments. Needs VIA confirmation on whether this should be editable or always "HC."
Is the Procedure Qualifier always "HC" (HCPCS) for all VIA service types, or can it vary? If always HC, this could be a constant rather than an editable field.
ST-10
Rounding Algorithm ("15 mins rounding down" — needs full spec)
MEDIUM
~3 hrs
Spec Says
Rounding Algorithm field — marked with "??" — note says "15 mins rounding down."
Current State
VIA's via_sales_enhancement already implements rounding in SaleOrderLine._compute_qty_delivered(): math.floor(mapping * 100 / 25). This converts timesheet hours to 15-minute units using floor (round down). However, this logic is hardcoded in Python, not configurable per service type.
Planned Action
- Add
rounding_algorithmSelection field toproduct.template - Options could include: "15 min round down" (current behavior), "15 min round up", "15 min nearest", "hourly", "exact"
- Modify
_compute_qty_delivered()to read the product's rounding algorithm instead of hardcoded formula - Needs VIA to confirm the full list of rounding options needed
What are all the rounding algorithms VIA needs? Is "15 min round down" the only option, or do different service types use different rounding? The current hardcoded implementation applies the same formula to all service types.
Section 6 — Open Questions (from Spec)
11 questions
OQ-1
Eligibility field requirements undefined
LOW
Question
The Eligibility field on the service line is marked "TBD" — no data type, LOV, or requirements defined. Should this display the automated PROMISe 271 eligibility status, or is it a manual entry field? (See SL-10 for implementation context.)
OQ-2
Funding Source field purpose unclear
LOW
Question
"PA PROMISe" is noted with "???" marks. Is this a separate field on the form, a default value, or an informational note? A funding_source field already exists on res.partner — should it be displayed on the authorization form as well? (See SL-11.)
OQ-3
Procedure Qualifier value confirmation
LOW
Question
Procedure Qualifier is marked "??" with value "HC-HCPCS." Is this always the same for all VIA service types, or can it vary? If always HC, should it be a constant rather than an editable field? (See ST-9.)
OQ-4
Rounding Algorithm full specification
LOW
Question
"15 mins rounding down" is noted but the full spec is undefined. What are all the rounding options VIA needs? Do different service types use different rounding? The current hardcoded implementation (math.floor(mapping * 100 / 25)) applies the same formula to everything. (See ST-10.)
OQ-5
County of Service — full PA county list source
LOW
Question
The spec says "List of all PA Counties" but doesn't enumerate them. The via.res.county model already exists in the via_crm module — does it contain the full 67 PA counties? Should it be the source for the authorization line county field?
OQ-6
Region auto-population logic (Appendix H mapping)
LOW
Question
The spec notes Region "can be autopopulated, see ODP map Appendix H doc." Do we have the Appendix H county-to-region mapping? Should the region auto-set based on the selected county?
OQ-7
Remaining Units deduction source
HIGH
Question
"Deduct the number of units paid" — from what source? Current system uses timesheet-based delivery (qty_delivered). Other options: invoice lines, Sandata EVV confirmations, or manual entry. Each gives different numbers and timing. This is billing-critical. (See SL-6.)
OQ-8
Bulk duplicate scope (header + all lines, or individual lines?)
MEDIUM
Question
The bulk duplicate popup asks for new Start/End dates. Does this duplicate the entire authorization (header + all service lines), or should users be able to select individual service lines to duplicate? Should other line fields (units, amounts) be copied as-is or reset? (See DB-5.)
OQ-9
Duplicate Service Type names in LOV (Licensed Residential Habilitation)
LOW
Question
The Service Type LOV has multiple entries with similar names: "Licensed Residential Habilitation" (W9000, W9029), "Licensed Residential Habilitation—Ineligible" (W9001, W9030), plus W6093. Are all 5 distinct service types that should be separate product.template records? How should users distinguish between W9000 and W9029?
OQ-10
ISP Program — one per authorization or multiple outcomes?
MEDIUM
Question
Is there one ISP Program outcome per authorization, or can multiple outcomes be tracked? If multiple, this needs a One2many model instead of flat fields on sale.order. (See ISP-1.)
OQ-11
Unit of Measure LOV values
LOW
Question
The Service Type List mentions "List of Values" for Unit of Measure but provides no values. What are the valid UoMs? Options likely include: hours, 15-minute units, days, each. Odoo's uom.uom model already has standard units — which ones should be available for VIA service types?
Export Responses
Click to generate YAML for Claude ingestion. Paste into a new Claude chat to resume implementation planning.
VIA Authorization Management — Gap Analysis Review
Comparing current Odoo 17 sale.order / product.template against VIA Authorization spec · Generated March 30, 2026 · Task 2dd405f0 · Parent: fe7887bf
How to use this document: Each change item shows what the spec asks for versus what currently exists. Click Agree (proceed with change) or Disagree (skip or modify). Add an explanation for any Disagree. When done, click Export YAML at the bottom — paste the output into a Claude chat to resume implementation planning.
0 of 0 items reviewed
78–110
Estimated Total Hours
34
Change Items
5
Sections + Open Questions
Section 1 — Authorization Dashboard (List View)
7 items · ~14–20 hrs
DB-1
Dashboard is view-only (no inline editing)
LOW
~1 hr
Spec Says
All authorizations listed in a read-only dashboard. Users can view and filter but cannot inline-edit from the list view.
Current State
Odoo's default sale.order tree view (sale.view_order_tree) allows inline editing of some fields. VIA has no custom tree view for sale.order — uses the stock Odoo list. Fields like partner_id are already renamed to "Person Supported" via via_sales_enhancement.
Planned Action
Create an inherited tree view with editable="false" (or simply remove any editable attribute). Set all list columns to readonly="1". The view should display the spec columns: Person Supported, Service Type, Start Date, End Date, Units, ICD-10, Region.
DB-2
All authorizations listed with user filtering
LOW
~1 hr
Spec Says
All authorization records are listed. User can apply filters to narrow results.
Current State
Odoo's default sale.order list already shows all quotations/orders with built-in search and filter capabilities. The existing search view provides filters for Status, Salesperson (renamed "Support Partner"), dates, etc.
Planned Action
Extend the search view to add Authorization-specific filters: by Person Supported, Service Type, Region, date range. Most filtering capability already exists via Odoo's standard search — this is mainly adding custom filter shortcuts.
DB-3
Default sort: Start Date, then alpha by Person Supported last name
LOW
~1 hr
Spec Says
Sort by Start Date ascending, then alphabetical by last name of Person Supported.
Current State
Default sale.order ordering is by id desc (newest first). No Start Date or Person Supported name-based sort. The current model has date_order (Order Date) but no dedicated "Authorization Start Date" field on the header.
Planned Action
Override _order on sale.order to sort by auth start date ascending, then partner name alphabetical. This requires either: (a) a stored field on sale.order for the earliest line's start date, or (b) a related field pulling from sale.order.line. The partner name sort should use the partner_id.name field.
Start Date is on
sale.order.line, not the header. If an authorization has multiple lines with different start dates, which date should drive the sort — the earliest line's start date?
DB-4
Selection checkbox for bulk actions (including duplicate)
LOW
~0.5 hrs
Spec Says
User uses the selection checkbox to the left of Person Supported to perform actions, including duplicating records.
Current State
Odoo's list view already has selection checkboxes by default. The standard "Action" dropdown includes "Duplicate" among other options. This is built-in behavior.
Planned Action
Minimal work needed — the checkbox and basic duplicate action already exist. The custom part is the date-override popup (see DB-5). May need to restrict available actions to only those relevant for authorizations.
DB-5
Bulk duplicate with date override popup
HIGH
~6 hrs
Spec Says
When duplicating multiple records, initiate a popup that asks for new Start and End dates to be applied to all duplicated records.
Current State
No bulk duplicate with date override exists. Odoo's default duplicate copies each record as-is with no popup for field overrides. The standard copy() method on sale.order duplicates the header and lines with original values.
Planned Action
Build a wizard model (sale.order.duplicate.wizard) with:
new_start_date: Date field (required)new_end_date: Date field (required)order_ids: Many2many → sale.order (populated from selected records)
Does this duplicate the entire authorization (header + all service lines), or should users be able to select individual lines? Also, should other line fields (units, amounts) be copied as-is, or reset?
DB-6
Remove Sales Order number from view
LOW
~0.5 hrs
Spec Says
Remove the Sales Order number from the dashboard and form views.
Current State
The name field (S00001, S00002…) is the primary identifier in both list and form views. It appears as the first column in the tree view and in the form header. The field cannot be removed from the model (it's used for internal references, invoicing, etc.), but can be hidden from views.
Planned Action
Hide name field from the tree and form views via invisible="1". The SO number will still exist internally for system operations but won't be visible to users. Alternatively, if VIA wants a custom identifier, we could add an "Authorization Number" field with a custom sequence.
Should we create a replacement "Authorization Number" with a custom sequence (e.g., AUTH-0001), or simply hide the SO number entirely?
DB-7
Rename "Sales Orders" to "Authorization" throughout
MEDIUM
~4 hrs
Spec Says
Change all references from "Sales Orders" to "Authorization" throughout the Odoo interface.
Current State
The labels_change module already renames "Sales Order" → "Service Order" and "Product" → "Service" across 200+ field descriptions via ir.model.fields data records. The module also renames "Salesperson" → "Support Partner" and "Sales Team" → "Support Team." So the current UI says "Service Order" — not "Sales Order" and not yet "Authorization."
Planned Action
Update the labels_change module (or create a new data file) to change "Service Order" → "Authorization" in all relevant ir.model.fields records. This includes: menu items, breadcrumbs, field descriptions, button labels, and window titles. Also update ir.model descriptions and ir.actions.act_window names. Estimated ~30-40 field description changes plus menu/action renames.
Section 2 — Authorization Form Header
3 items · ~6–10 hrs
AH-1
Header fields populated from crm.lead (Person Supported, MA Number, Internal ID)
HIGH
~4 hrs
Spec Says
The form header contains only: Person Supported (from crm.lead), MA Number (from crm.lead), Internal ID (from crm.lead). These are auto-populated when the authorization is created from a CRM lead.
Current State
via_sales_enhancement renames partner_id → "Person Supported" on the sale.order form. The partner_id is set when creating a quotation from CRM. However, ma_number and internal_id are on res.partner, not on sale.order directly. They would need to be displayed as related fields or added as stored fields on sale.order. The CRM → sale.order flow goes through action_sale_quotations_new() and _handle_partner_assignment() which syncs lead fields to the partner record.
Planned Action
- Add
ma_numberandinternal_unique_idas related fields onsale.orderpulling frompartner_id.ma_numberandpartner_id.internal_unique_id_code - Restructure the form header to show only these three fields (Person Supported, MA Number, Internal ID)
- Hide default sale.order header fields that aren't in the spec (date_order, validity_date, payment_terms_id, etc.)
- Ensure the CRM → Authorization creation flow populates partner_id correctly via the existing sync mechanism
The
ma_number field feeds PROMISe EDI (Medicaid claims). The internal_unique_id_code connects to HCSIS/iRecord. Changes to how these fields display on sale.order must not break the data flow from crm.lead → res.partner → sale.order.
AH-2
Model label reads "Authorization" (not "Sales Order")
LOW
~1 hr
Spec Says
The Odoo model label must read "Authorization" (not "Sales Order").
Current State
The sale.order model's _description is "Sales Order" in Odoo core. The labels_change module renames many field labels but doesn't change the model-level description. Window titles and breadcrumbs still show "Sales Order" or "Quotation."
Planned Action
Override _description = "Authorization" on the inherited sale.order model. Update ir.actions.act_window records for sale.order to use "Authorization" as the window title. Update menu item labels. This overlaps with DB-7 — can be done in the same pass.
AH-3
Remove Sales Order number from form
LOW
~0.5 hrs
Spec Says
Remove the Sales Order number field from the form view.
Current State
The name field appears at the top of the form in the oe_title div. It's auto-generated via sequence (SO001, SO002…). Same as DB-6 but for the form view specifically.
Planned Action
Add invisible="1" to the name field in the form view via inherited XML. Combined with DB-6 (list view), this fully hides the SO number from users while keeping it for internal Odoo operations.
Section 3 — Authorization Service Line (sale.order.line)
11 items · ~28–36 hrs
SL-1
Service Type populated from crm.lead with editable LOV
MEDIUM
~3 hrs
Spec Says
Service Type is populated from crm.lead with a list of values; user may edit. LOV includes 16 service types (W7096, H0043, W7060, etc.).
Current State
The existing sale.order.line uses product_id (Many2one → product.product) as the "Service" field. Products/Services are managed in product.template. On crm.lead, there is a service_ids field (Many2many → product.template) that tracks which services are associated with a lead. When a sale order is created from CRM, the line's product comes from what the user selects — not auto-populated per se. The 16 service types from the spec would be product.template records.
Planned Action
- Ensure all 16 spec service types exist as
product.templaterecords with correct names and codes - When creating an authorization from CRM, pre-populate available service types from the lead's
service_ids - Allow user to change/add service types on the order line (already possible with product_id field)
- Consider domain filter on
product_idto only show authorized service types for the person
SL-2
Service Type Code auto-populates from Service Type selection
LOW
~1 hr
Spec Says
Service Type Code auto-populates based on the selected Service Type using a defined code mapping (e.g., "IHCS" → W7060).
Current State
product.template has a default_code field (renamed "Program ID" by via_sales_enhancement). This is the standard Odoo "Internal Reference" field. When a product is selected on a sale order line, product_id.default_code is accessible as a related field. No separate "Service Type Code" field exists on sale.order.line.
Planned Action
Add a related/computed service_type_code field on sale.order.line that pulls from product_id.default_code. Ensure all 16 product templates have correct default_code values matching the spec's code table (W7096, H0043, etc.). Display as readonly on the order line.
SL-3
Authorization Start Date and End Date on each service line
MEDIUM
~2 hrs
Spec Says
Each service line has its own Authorization Start Date and Authorization End Date with calendar pickers.
Current State
Standard sale.order.line has no start/end date fields. Dates exist on the order header (date_order, validity_date) but not per-line. VIA's CRM lead has plan_start_date and plan_end_date which sync to the partner, but these are not on sale.order.line.
Planned Action
Add auth_start_date (Date, required) and auth_end_date (Date, required) fields to sale.order.line. These will be line-specific, allowing different authorization periods per service type. Default values could come from the CRM lead's plan dates. Display as calendar pickers in the inline tree.
SL-4
Authorized Units (editable numeric field)
LOW
~0.5 hrs
Spec Says
Authorized Units is a numeric field that allows manual editing.
Current State
sale.order.line has product_uom_qty (Quantity) — this is the standard ordered quantity field. It's already editable and numeric. The via_tab_service_lines module displays this on partner cards as authorized units. The labels_change module does not rename this field.
Planned Action
Reuse existing product_uom_qty field, renamed to "Authorized Units" via a view-level string attribute or via labels_change. Minimal work — field already exists and is editable.
SL-5
Total Authorized Amount (auto-calculated: Units × Rate)
MEDIUM
~2 hrs
Spec Says
Total Authorized Amount = Authorized Units × Unit Rate (from Service Type List / product.template).
Current State
sale.order.line already has price_subtotal (computed: product_uom_qty × price_unit). The price_unit is typically set from the product's list_price (renamed "Service Rate" by labels_change). This is essentially the same calculation the spec requires.
Planned Action
Reuse price_subtotal renamed to "Total Authorized Amount." Ensure price_unit auto-populates from the product's current active rate. If the spec's Rate History model (ST-3 through ST-6) changes how rates are stored, this computation may need adjustment to pull the correct rate based on the line's date.
The amount calculation feeds billing/invoicing. If the rate source changes from
list_price to a custom rate history model, the price_unit population logic must be updated accordingly.
SL-6
Remaining Units (auto-calculated: Authorized − Paid/Consumed)
HIGH
~4 hrs
Spec Says
Remaining Units is auto-calculated by deducting the number of units paid/consumed from Authorized Units.
Current State
sale.order.line has qty_delivered (delivered quantity) which is computed from timesheet hours (via _compute_qty_delivered). VIA's via_sales_enhancement overrides this with custom rounding: math.floor(mapping * 100 / 25) (converting hours to 15-min units). The via_tab_service_lines module shows "Used" vs "Units" on partner kanban cards with a progress bar.
Planned Action
- Add a computed
remaining_unitsfield:product_uom_qty - qty_delivered - The deduction source needs clarification: Is it from timesheet entries (current), Sandata EVV data, or invoice lines? Each source gives different numbers.
- Current
qty_delivereduses a custom rounding formula that converts timesheet hours to 15-min billing units — confirm this is the correct deduction mechanism
The "units paid" deduction source is ambiguous. Timesheet-based delivery (current) may differ from EVV-based (Sandata) or invoice-based consumption. This needs clarification before implementation — incorrect deduction logic directly impacts billing accuracy.
SL-7
Region of Service (from crm.lead, editable LOV)
MEDIUM
~2 hrs
Spec Says
Region of Service populated from crm.lead with LOV (Central, Northeast, Southeast, West). User may override.
Current State
Region exists on crm.lead as pre_auth_region (Selection field) and syncs to res.partner. It does NOT exist on sale.order.line. The via_tab_authorization module shows region on the partner's Authorization tab. The via_tab_service_lines module shows "Region of Service" in the service lines header on the partner form. However, this is partner-level, not per-line.
Planned Action
Add region_of_service Selection field to sale.order.line with values [Central, Northeast, Southeast, West]. Default from partner's pre_auth_region (which originated from crm.lead). Allow user override per line.
SL-8
County of Service (from crm.lead, editable LOV)
MEDIUM
~2 hrs
Spec Says
County of Service populated from crm.lead with LOV (all PA counties). User may override.
Current State
County exists on crm.lead as pre_auth_county_id (Many2one → via.res.county, a custom model defined in via_crm). Syncs to res.partner. Not on sale.order.line. The via_tab_service_lines module shows County on the partner service lines header.
Planned Action
Add county_of_service_id (Many2one → via.res.county) to sale.order.line. Default from partner's pre_auth_county_id. Allow override per line. The full PA county list already exists in the via.res.county model.
SL-9
Payer ID, Payer Program, ICD-10 Code, Modifier (LOV fields)
HIGH
~6 hrs
Spec Says
Four LOV fields on each service line: Payer ID [PAODP, PAOLTL], Payer Program [ODP, BASE, OLTL, OMAP, PHC, CHC, Private Pay], ICD-10 Code [F70-F79, F84.0, Other], Modifier [U6, U7, U7-HI, U8].
Current State
payer and payer_program exist on crm.lead and res.partner (Selection fields) — but NOT on sale.order.line. No icd10_code or modifier fields exist anywhere in the current codebase. These are billing-critical fields that currently live outside Odoo (likely in billing spreadsheets or Sandata).
Planned Action
Add four new Selection fields to sale.order.line:
payer_id: Selection [('paodp','PAODP'), ('paoltl','PAOLTL')]payer_program: Selection [('odp','ODP'), ('base','BASE'), ('oltl','OLTL'), ('omap','OMAP'), ('phc','PHC'), ('chc','CHC'), ('private_pay','Private Pay')]icd10_code: Selection [('f70','F70'), ('f71','F71'), ('f72','F72'), ('f73','F73'), ('f78','F78'), ('f79','F79'), ('f840','F84.0'), ('other','Other')]modifier: Selection [('u6','U6'), ('u7','U7'), ('u7hi','U7-HI'), ('u8','U8')]
Payer ID and Payer Program directly feed PROMISe EDI claims (837 transactions) and Sandata EVV. ICD-10 codes and Modifiers are required for billing. Adding these to sale.order.line is essential for the billing pipeline. Key mismatch risk: the crm.lead and res.partner payer fields have different technical keys — verify LOV values match exactly.
SL-10
Eligibility field (TBD)
LOW
~0.5 hrs
Spec Says
Eligibility field — marked as TBD. No data type, LOV, or requirements defined.
Current State
The via_tab_service_lines module has eligibility badge rendering on partner kanban cards, pulling from service_line_eligibility_json (computed from PROMISe 271 responses via the promise.service.type.mapping model). This is a read-only display of X12 271 eligibility data — not a user-editable field.
Planned Action
Defer until requirements are defined. The existing eligibility infrastructure (PROMISe 271 → mapping → badge display) may be what VIA actually wants here, just surfaced on the authorization form instead of only on the partner card.
Is this meant to be a manual entry field, or should it display the automated eligibility status from PROMISe 271 responses? The existing system already computes eligibility per service line from EDI data.
SL-11
Funding Source field ("PA PROMISe" — unclear requirements)
LOW
~0.5 hrs
Spec Says
"PA PROMISe" noted with "???" — unclear if this is a field, a default value, or informational.
Current State
A funding_source field exists on res.partner and is displayed on the via_tab_service_lines partner tab. The via_tab_authorization module does not show it. It's not on sale.order or sale.order.line. Current values and definition are unclear from the codebase.
Planned Action
Defer until VIA clarifies whether this is: (a) a new field on sale.order.line, (b) a display of the partner's existing funding_source, or (c) just a label/note. If it's always "PA PROMISe" for all PA authorizations, it may be informational only.
Is Funding Source a separate editable field on each authorization line, or is it inherited from the partner record? Is "PA PROMISe" always the value, or are there other options?
Section 4 — ISP Program Tab
3 items · ~4–6 hrs
ISP-1
Free-form text fields for ISP outcomes
LOW
~2 hrs
Spec Says
Seven text fields: Outcome Name, Outcome Statement, Reason for Outcome, How will we know progress is being made, Actions, Frequency and Duration, Comment. All free-form text, fully editable.
Current State
No ISP fields exist on sale.order. On product.template, there is an isp_description Html field (added by via_sales_enhancement) displayed on an "ISP Description" tab — but this is per-service-type, not per-authorization. No outcome tracking exists on the authorization/sale order level.
Planned Action
Add seven fields to sale.order: isp_outcome_name (Char), isp_outcome_statement (Text), isp_reason (Text), isp_progress_indicator (Text), isp_actions (Text), isp_frequency_duration (Char), isp_comment (Text). Display on a new notebook page "ISP Program" on the authorization form.
Can an authorization have multiple ISP outcomes? If yes, these should be a One2many (separate model with these 7 fields) rather than flat fields on sale.order. If only one outcome per authorization, flat fields are simpler.
ISP-2
ISP is a notebook page on the Authorization form
LOW
~1 hr
Spec Says
This tab is a notebook page on the Authorization (sale.order) form.
Current State
The sale.order form has a notebook with pages: Order Lines, Optional Products (hidden by via_sales_enhancement), and other standard tabs. No "ISP Program" page exists. The only ISP-related content is on product.template (the isp_description Html field).
Planned Action
Add a new notebook page via inherited view XML. Following the One Module One Tab pattern from the VIA tab architecture, this should be its own module (e.g., via_tab_isp_program) at priority 25+ on sale.order's notebook.
ISP-3
No LOVs or computed fields — purely narrative
LOW
~0.5 hrs
Spec Says
All fields are free-form text and fully editable. No dropdowns, no auto-calculations.
Current State
N/A — the tab doesn't exist yet.
Planned Action
Straightforward implementation — all fields are Char or Text type with no constraints, no required flags, no computed logic. This is the simplest section of the entire spec.
Section 5 — Service Type List (product.template)
10 items · ~26–38 hrs
ST-1
Remove Region and Service Team references from product.template
LOW
~1 hr
Spec Says
In the current product.template, remove the reference to Region and Service Team.
Current State
The standard Odoo product.template form links to projects (renamed "Programs") which have team_id. The via_sales_enhancement module's _timesheet_create_project_prepare_values method copies team_id and program_type from the product's project template. Region is not directly on product.template — it's on the partner/lead. Service Team may appear via the project linkage.
Planned Action
Hide or remove team/region-related fields from the product.template form view. These data points should come from the Person Supported's authorization (sale.order.line), not from the service type definition.
ST-2
One entry per Service Type; billing data from Authorization
MEDIUM
~3 hrs
Spec Says
There should be only one entry per Service Type. All other billing data points (region, modifiers, FY, etc.) should be pulled from the Person Supported's authorization.
Current State
Currently product.template records may have duplicate service types for different regions or configurations. The project template linkage embeds team/region at the service type level. This conflicts with the spec's "one entry per service type" requirement.
Planned Action
- Consolidate duplicate product.template records into single entries per service type
- Remove region/team/modifier fields from product.template
- These billing data points move to sale.order.line (SL-7, SL-8, SL-9)
- Product.template becomes a clean master list: name, code, unit rate, UoM, EVV flag
Consolidating product.template records affects existing sale.order.line references, project templates, and timesheet mappings. This must be data-migrated carefully — existing authorizations point to specific product IDs that may be among the duplicates being merged.
ST-3
One active unit cost at a time (no end date = active)
HIGH
~4 hrs
Spec Says
A Service Type cannot have more than one active unit cost at a time. The active rate has no End Date.
Current State
product.template has a single list_price (renamed "Service Rate") field. There is no concept of rate versioning, start/end dates on rates, or rate history. Changing the price simply overwrites the current value. No start_date or end_date fields exist on product.template.
Planned Action
Create a new model service.type.rate (or product.rate.history) with fields: product_tmpl_id (Many2one), start_date (Date, required), end_date (Date), unit_rate (Float/Monetary). Add constraint: only one record per product can have a blank end_date. The current "active" rate drives list_price on the product template.
Rate changes affect all future billing. The Sandata EVV integration sends unit rate data — ensure the rate lookup uses the correct active rate based on the service date, not just the latest rate.
ST-4
End-dating existing rate triggers new rate creation
MEDIUM
~3 hrs
Spec Says
To change the unit cost, the existing entry must be end-dated and a new record created with the new rate.
Current State
No rate versioning exists. Price changes are immediate overwrites of list_price.
Planned Action
Build an onchange or write override on the rate model: when end_date is set on the active rate record, prompt user (via wizard or auto-action) to create a new rate record with start_date = end_date + 1 day and blank end_date. Update product.template.list_price to reflect the new active rate.
ST-5
Prompt user to create new rate when existing is end-dated
MEDIUM
~2 hrs
Spec Says
Once an End Date is entered, prompt the user to create a new rate.
Current State
No rate transition workflow exists.
Planned Action
Build a confirmation dialog or wizard that appears when an end date is saved on the active rate. Options: (a) auto-open a new rate form pre-populated with start_date = old_end_date + 1, or (b) show a warning message with a "Create New Rate" button. Combined with ST-4.
ST-6
Rate History tab (searchable archive of ended rates)
MEDIUM
~3 hrs
Spec Says
All rates with an End Date are moved to the Rate History area and will be searchable.
Current State
No Rate History tab or model exists. Product.template has the "ISP Description" tab (from via_sales_enhancement) but no rate tracking.
Planned Action
Display the rate model (ST-3) as a One2many on a "Rate History" notebook page on product.template. The inline tree shows Start Date, End Date, Unit Rate. Records with end_date populated appear here; the active (no end_date) rate appears in the main form area. Optionally add search/filter capabilities.
ST-7
EVV checkbox (sends data to Sandata)
HIGH
~4 hrs
Spec Says
EVV checkbox: if checked, this data is sent to Sandata for Electronic Visit Verification.
Current State
The sandata_integration and sandata_integration_extension modules handle EVV data flow to Sandata. The integration works at the timesheet/attendance level, not the product level. No evv Boolean exists on product.template currently. The Sandata integration uses sale.order.line product references to determine what gets sent.
Planned Action
- Add
evv_enabledBoolean field toproduct.template - Modify Sandata integration to check this flag before sending EVV data for a service type
- This creates a clean opt-in mechanism: only service types with EVV checked send data to Sandata
- Requires review of existing Sandata integration code to find the correct insertion point for the flag check
Changing the EVV data flow to Sandata impacts real-time compliance reporting. Must be tested thoroughly in staging before production deployment. Incorrect EVV data can result in PA Medicaid audit findings.
ST-8
Diagnosis Code Pointer (default: 1)
LOW
~0.5 hrs
Spec Says
Diagnosis Code Pointer field on product.template with default value of 1.
Current State
No diagnosis_code_pointer field exists on product.template.
Planned Action
Add diagnosis_code_pointer Integer field to product.template, default=1. This is a billing/claims field used in X12 837 transactions to reference which diagnosis code on the claim applies to this service line.
ST-9
Procedure Qualifier (HC-HCPCS — needs confirmation)
LOW
~0.5 hrs
Spec Says
Procedure Qualifier field — marked with "??" — value appears to be "HC-HCPCS."
Current State
No procedure_qualifier field exists. The via_tab_service_lines module references HCPCS codes in the service type mapping (promise.service.type.mapping), but this is for eligibility matching, not a form field.
Planned Action
Add procedure_qualifier Char field to product.template. Default to "HC" (HCPCS). This is used in X12 837 claim SV1 segments. Needs VIA confirmation on whether this should be editable or always "HC."
Is the Procedure Qualifier always "HC" (HCPCS) for all VIA service types, or can it vary? If always HC, this could be a constant rather than an editable field.
ST-10
Rounding Algorithm ("15 mins rounding down" — needs full spec)
MEDIUM
~3 hrs
Spec Says
Rounding Algorithm field — marked with "??" — note says "15 mins rounding down."
Current State
VIA's via_sales_enhancement already implements rounding in SaleOrderLine._compute_qty_delivered(): math.floor(mapping * 100 / 25). This converts timesheet hours to 15-minute units using floor (round down). However, this logic is hardcoded in Python, not configurable per service type.
Planned Action
- Add
rounding_algorithmSelection field toproduct.template - Options could include: "15 min round down" (current behavior), "15 min round up", "15 min nearest", "hourly", "exact"
- Modify
_compute_qty_delivered()to read the product's rounding algorithm instead of hardcoded formula - Needs VIA to confirm the full list of rounding options needed
What are all the rounding algorithms VIA needs? Is "15 min round down" the only option, or do different service types use different rounding? The current hardcoded implementation applies the same formula to all service types.
Section 6 — Open Questions (from Spec)
11 questions
OQ-1
Eligibility field requirements undefined
LOW
Question
The Eligibility field on the service line is marked "TBD" — no data type, LOV, or requirements defined. Should this display the automated PROMISe 271 eligibility status, or is it a manual entry field? (See SL-10 for implementation context.)
OQ-2
Funding Source field purpose unclear
LOW
Question
"PA PROMISe" is noted with "???" marks. Is this a separate field on the form, a default value, or an informational note? A funding_source field already exists on res.partner — should it be displayed on the authorization form as well? (See SL-11.)
OQ-3
Procedure Qualifier value confirmation
LOW
Question
Procedure Qualifier is marked "??" with value "HC-HCPCS." Is this always the same for all VIA service types, or can it vary? If always HC, should it be a constant rather than an editable field? (See ST-9.)
OQ-4
Rounding Algorithm full specification
LOW
Question
"15 mins rounding down" is noted but the full spec is undefined. What are all the rounding options VIA needs? Do different service types use different rounding? The current hardcoded implementation (math.floor(mapping * 100 / 25)) applies the same formula to everything. (See ST-10.)
OQ-5
County of Service — full PA county list source
LOW
Question
The spec says "List of all PA Counties" but doesn't enumerate them. The via.res.county model already exists in the via_crm module — does it contain the full 67 PA counties? Should it be the source for the authorization line county field?
OQ-6
Region auto-population logic (Appendix H mapping)
LOW
Question
The spec notes Region "can be autopopulated, see ODP map Appendix H doc." Do we have the Appendix H county-to-region mapping? Should the region auto-set based on the selected county?
OQ-7
Remaining Units deduction source
HIGH
Question
"Deduct the number of units paid" — from what source? Current system uses timesheet-based delivery (qty_delivered). Other options: invoice lines, Sandata EVV confirmations, or manual entry. Each gives different numbers and timing. This is billing-critical. (See SL-6.)
OQ-8
Bulk duplicate scope (header + all lines, or individual lines?)
MEDIUM
Question
The bulk duplicate popup asks for new Start/End dates. Does this duplicate the entire authorization (header + all service lines), or should users be able to select individual service lines to duplicate? Should other line fields (units, amounts) be copied as-is or reset? (See DB-5.)
OQ-9
Duplicate Service Type names in LOV (Licensed Residential Habilitation)
LOW
Question
The Service Type LOV has multiple entries with similar names: "Licensed Residential Habilitation" (W9000, W9029), "Licensed Residential Habilitation—Ineligible" (W9001, W9030), plus W6093. Are all 5 distinct service types that should be separate product.template records? How should users distinguish between W9000 and W9029?
OQ-10
ISP Program — one per authorization or multiple outcomes?
MEDIUM
Question
Is there one ISP Program outcome per authorization, or can multiple outcomes be tracked? If multiple, this needs a One2many model instead of flat fields on sale.order. (See ISP-1.)
OQ-11
Unit of Measure LOV values
LOW
Question
The Service Type List mentions "List of Values" for Unit of Measure but provides no values. What are the valid UoMs? Options likely include: hours, 15-minute units, days, each. Odoo's uom.uom model already has standard units — which ones should be available for VIA service types?
Export Responses
Click to generate YAML for Claude ingestion. Paste into a new Claude chat to resume implementation planning.