Field Flow Cross-Reference
Items appearing in 2+ gap analyses — where each shared field/concept lives across crm.lead → sale.order → res.partner
Governing Items (8 items across 3 gap analyses)
Data Flow
Resolution — All Three Analyses Agree
The Authorization tab does NOT belong on crm.lead. Client explicitly said "Do not build this tab in CRM.lead, move to Sale.order." The pre-auth tab on crm.lead is removed (AU-B) after its fields relocate to the main form (PA-F, PA-G) and sale.order header (AH-1). The res.partner gets a view-only kanban tab (AUTH-B) showing linked sale.orders when partner_type = 'person_support'. The existing editable fields on the partner Authorization tab (AUTH-A) are removed — their data moves to sale.order.line fields.
PS-B Impact — Deferred Partner Creation
Client disagrees with creating res.partner on lead conversion. Partner creation is deferred until services are accepted. This means the view-only Authorization tab on res.partner only becomes relevant after partner creation. The crm.lead → sale.order flow may need to work without a linked res.partner existing yet. Current sync logic (lead → partner on conversion) needs redesign.
Governing Items (4 items across 3 gap analyses)
Data Flow — Payer Migration
Conflict — API Reads payer/payer_program from res.partner
Sandata and PROMISe APIs currently read payer and payer_program from res.partner. AUTH-A removes these as editable fields. SL-9 puts them on sale.order.line. The APIs need a migration plan — either (a) keep a computed/readonly copy on res.partner that reads from the active sale.order, or (b) update API integrations to read from sale.order.line directly. The is_need_to_update flag on res.partner also triggers on payer/payer_program changes — this logic needs updating.
Conflict — LOV Size Discrepancy
Current payer has 15 selection values. Auth spec shows only 2 (PAODP, PAOLTL). This is not actually a reduction — the Auth spec is filtered by company (PA ODP/OLT programs). The full LOV stays, but sale.order.line may filter by company_id at display time.
Open Question 1 — API Source After Migration
After payer/payer_program move to sale.order.line, where do Sandata and PROMISe APIs get these values? Blocks AUTH-A and SL-9 implementation. Options: (a) computed field on res.partner from latest active sale.order, (b) direct API read from sale.order.line.
Open Question 2 — payer_program LOV Expansion
Auth spec includes "BASE" and "Private Pay" as payer_program values. Are these new additions to the existing LOV, or renamed versions of existing values? Blocks SL-9 field definition.
Governing Items (4+ items across 2 gap analyses)
Data Flow — Service Type
Resolution — Aligned Across All Analyses
Same 16 product.template records serve both crm.lead and sale.order.line. CRM should use Many2one → product.template (not Selection) so the field type matches sale.order.line.product_id. When the "Activate Authorization" button creates a sale.order, it defaults each line's product_id from the crm.lead's service_type. Procedure code auto-populates from the product.template record. Client confirmed: "Each code needs to be listed separately even if the name of the service appears the same."
Implementation Note
PA-C currently defines service_type as a Selection field. It should be refactored to Many2one → product.template before implementation to ensure compatibility with SL-1/SL-2. The ST-1 through ST-10 items define the product.template structure (rates, EVV checkbox, diagnosis code pointer, etc.) — these are Auth-only items but the underlying records are shared.
Governing Items (3 items across 2 gap analyses)
Data Flow — Funding Source
Open Question 3 — Funding Source Definition
The Auth spec shows this field as "PA PROMISe ???" — the question marks are in the original spec. It's unclear whether this is a static value ("PA PROMISe"), a selection field, or something else. AUTH-E on the Contact form says to move it from partner-level to per-service-line, which SL-11 also implies. But without knowing the field's purpose and possible values, implementation is blocked. OQ-2 in the Auth gap analysis asks the same question.
Current State
funding_source exists on both crm.lead and res.partner today as a synced field. The sync copies it on conversion. If it moves to sale.order.line, the sync logic needs updating and the crm.lead copy may become a default value rather than the authoritative source.
Governing Items (5 items across 3 gap analyses)
Data Flow — 3 Levels
Resolution — Aligned Across Analyses
Three clean levels: CRM captures at intake (PA-G), sale.order.line allows per-service overrides (SL-7/SL-8), res.partner displays for reference (AUTH-D). Auto-populate logic (county → region via ODP Appendix H) applies at all levels. Important distinction: County of Residence (partner header, H-H) ≠ County of Service (this overlap area). They are separate concepts and separate fields.
Open Question 5 (OQ-5/OQ-6) — County List Completeness
Does via.res.county contain all 67 PA counties? H-H is BLOCKED because we don't know what field on via.res.county holds the region for auto-population. Blocks PA-G, SL-7, SL-8, H-H, and AUTH-D. Also: the region key mismatch (western → west) noted in PS-D applies here — must be resolved before auto-populate logic is built.
Governing Items (4 items across 2 gap analyses)
Data Flow — Conflicting Models
Conflict — via.isp Model vs. Flat Fields
The existing system has a via.isp model with One2many records that are moved (not copied) from crm.lead to res.partner on conversion via partner_id reassignment. The Auth spec defines ISP as 7 free-text fields directly on sale.order (no separate model). These are fundamentally different architectures. Client said they're "not familiar" with the ISP Data tab on crm.lead (AU-C disagree), which suggests the existing via.isp model may be unused or unknown to them.
Open Question 4 — via.isp: Replace or Coexist?
Does the existing via.isp model get replaced by the flat fields on sale.order, or do both coexist? If replaced, existing via.isp records need migration. If coexist, which is authoritative? Blocks AU-C and ISP-1/2/3.
Open Question 5 (OQ-10) — One or Multiple Outcomes?
Auth spec ISP-1 shows 7 text fields (outcome, strategies, current status, etc.). Is this one outcome per authorization, or can there be multiple outcomes? If multiple, the flat-field approach on sale.order doesn't work — it would need a One2many sub-model. This is a fundamental architecture decision.
Governing Items (2 items across 2 gap analyses)
Current State
Conflict — Field Homelessness After AUTH-A
AUTH-A removes editable fields from the partner Authorization tab, including sc_phone_no. PA-D is deferred — client wants to explore the existing Studio method. But if AUTH-A removes the field's current home and PA-D hasn't determined the new home, sc_phone_no has nowhere to live on the partner form. The SC phone on crm.lead syncs to res.partner today — if the partner field is removed, the sync target disappears.
Open Question 7 — SC Phone Location
Where does sc_phone_no live after AUTH-A removes it from the partner Authorization tab? Options: (a) move to Person Supported Details tab on res.partner, (b) keep on partner form outside the Authorization tab, (c) derive from a future SC Many2one record. Blocks AUTH-A cleanup and PA-D planning.
Items Needing Gap Analysis Updates
Items whose gap analysis descriptions need revision based on cross-reference findings.
| Item | Source | Status | Update Needed |
|---|---|---|---|
PA-C |
CRM | Not Started | Field type should be Many2one → product.template (not Selection) to match sale.order.line.product_id |
D-C |
CRM | Not Started | Scope revised: button validates starred fields only (Service Type, County/Region, Last Name, First Name, MA Number, Internal ID). No billing validation on crm.lead. Button launches sale.order creation. |
AUTH-A |
CONTACT | Not Started | Needs specific field list with destinations: payer → SL-9, payer_program → SL-9, sc_phone_no → TBD (Open Q 7), authorized_date → sale.order header, etc. Plus API migration note for payer/payer_program. |
AUTH-B |
CONTACT | Not Started | Data source confirmed: linked sale.orders. Kanban card fields defined by Auth SL items. Visibility only when partner_type = 'person_support'. |
AUTH-D |
CONTACT | Not Started | Region/County source = sale.order.line SL-7/SL-8. Eligibility = PROMISe integration (OQ-1 pending). |
AUTH-E |
CONTACT | Not Started | Confirmed: funding_source moves to sale.order.line per SL-11. Pending OQ-2 resolution for field definition. |
PA-E |
CRM | Complete | Divergence note: client said rename date_referral, code created new inquiry_date field. Both exist. Needs reconciliation — not a cross-reference issue but flagged here because it affects the D-A waterfall logic. |
Open Questions Blocking Implementation
Questions that must be resolved before cross-form items can be implemented. Ordered by impact scope.
| # | Question | Blocks | Overlap Area |
|---|---|---|---|
| 1 | Where do Sandata/PROMISe APIs get payer/payer_program after migration to sale.order.line? | AUTH-A, SL-9 |
2 — Payer |
| 2 | Are "BASE" and "Private Pay" new payer_program LOV values or renamed existing ones? | SL-9 |
2 — Payer |
| 3 | What is funding_source? Static value, selection field, or something else? What are its possible values? | SL-11, AUTH-E, OQ-2 |
4 — Funding Source |
| 4 | Does via.isp get replaced by flat sale.order fields, or do both models coexist? | AU-C, ISP-1/2/3 |
6 — ISP Data |
| 5 | One ISP outcome per authorization, or multiple? (Determines flat fields vs. One2many sub-model) | ISP-1, OQ-10 |
6 — ISP Data |
| 6 | Does via.res.county have all 67 PA counties? What field holds the region for auto-populate? | PA-G, SL-7, SL-8, H-H |
5 — Region/County |
| 7 | Where does sc_phone_no live after AUTH-A removes it from the partner Authorization tab? | PA-D, AUTH-A |
7 — Support Coordinator |
Sale.order Future Scope (from Approved Plan)
Items explicitly pushed to sale.order by VIA's client responses.
| Field/Concept | Pushed By | Client Said |
|---|---|---|
authorized_date |
PA-F (agree) | Will be in the sales.order |
project_auth_date |
PA-F (agree) | Should also move to sales.order |
payer, payer_program, plan_tier |
PA-J (agree, COMPLETE) | Will be moved to sale.order |
| Activate Authorization button destination | D-C (disagree) | Billing fields entered in sales.order, button launches sale.order creation |
| Authorization tab | AU-A (disagree) | Build on sale.order; view-only on res.partner for Person Supported |
Known Divergences & Implementation Notes
Items where implementation differs from client instruction, or where special handling is needed.
| Item | Issue | Impact |
|---|---|---|
PA-E |
Client said rename date_referral → Inquiry Date. Code created new inquiry_date field alongside date_referral. Both exist. |
Two date fields triggering two different stages (Inquiry and Discussion). Needs reconciliation. |
PA-I |
Client said disagree, discuss further. Code implemented form unification anyway (merged). | Smartsheet shows COMPLETE. May have been resolved in lost Cowork session. No action unless client raises. |
PS-B |
Client disagrees with partner creation on conversion. Current sync logic creates/links partner on quotation. | Entire sync architecture affected. crm.lead → sale.order flow may run without res.partner. Fundamental redesign of conversion flow. |
PA-J |
COMPLETE in Smartsheet — fields hidden from CRM form. First draft incorrectly listed as needing update. | No action needed. Confirmed complete. |
YAML Export
Field Flow Cross-Reference
Items appearing in 2+ gap analyses — where each shared field/concept lives across crm.lead → sale.order → res.partner
Governing Items (8 items across 3 gap analyses)
Data Flow
Resolution — All Three Analyses Agree
The Authorization tab does NOT belong on crm.lead. Client explicitly said "Do not build this tab in CRM.lead, move to Sale.order." The pre-auth tab on crm.lead is removed (AU-B) after its fields relocate to the main form (PA-F, PA-G) and sale.order header (AH-1). The res.partner gets a view-only kanban tab (AUTH-B) showing linked sale.orders when partner_type = 'person_support'. The existing editable fields on the partner Authorization tab (AUTH-A) are removed — their data moves to sale.order.line fields.
PS-B Impact — Deferred Partner Creation
Client disagrees with creating res.partner on lead conversion. Partner creation is deferred until services are accepted. This means the view-only Authorization tab on res.partner only becomes relevant after partner creation. The crm.lead → sale.order flow may need to work without a linked res.partner existing yet. Current sync logic (lead → partner on conversion) needs redesign.
Governing Items (4 items across 3 gap analyses)
Data Flow — Payer Migration
Conflict — API Reads payer/payer_program from res.partner
Sandata and PROMISe APIs currently read payer and payer_program from res.partner. AUTH-A removes these as editable fields. SL-9 puts them on sale.order.line. The APIs need a migration plan — either (a) keep a computed/readonly copy on res.partner that reads from the active sale.order, or (b) update API integrations to read from sale.order.line directly. The is_need_to_update flag on res.partner also triggers on payer/payer_program changes — this logic needs updating.
Conflict — LOV Size Discrepancy
Current payer has 15 selection values. Auth spec shows only 2 (PAODP, PAOLTL). This is not actually a reduction — the Auth spec is filtered by company (PA ODP/OLT programs). The full LOV stays, but sale.order.line may filter by company_id at display time.
Open Question 1 — API Source After Migration
After payer/payer_program move to sale.order.line, where do Sandata and PROMISe APIs get these values? Blocks AUTH-A and SL-9 implementation. Options: (a) computed field on res.partner from latest active sale.order, (b) direct API read from sale.order.line.
Open Question 2 — payer_program LOV Expansion
Auth spec includes "BASE" and "Private Pay" as payer_program values. Are these new additions to the existing LOV, or renamed versions of existing values? Blocks SL-9 field definition.
Governing Items (4+ items across 2 gap analyses)
Data Flow — Service Type
Resolution — Aligned Across All Analyses
Same 16 product.template records serve both crm.lead and sale.order.line. CRM should use Many2one → product.template (not Selection) so the field type matches sale.order.line.product_id. When the "Activate Authorization" button creates a sale.order, it defaults each line's product_id from the crm.lead's service_type. Procedure code auto-populates from the product.template record. Client confirmed: "Each code needs to be listed separately even if the name of the service appears the same."
Implementation Note
PA-C currently defines service_type as a Selection field. It should be refactored to Many2one → product.template before implementation to ensure compatibility with SL-1/SL-2. The ST-1 through ST-10 items define the product.template structure (rates, EVV checkbox, diagnosis code pointer, etc.) — these are Auth-only items but the underlying records are shared.
Governing Items (3 items across 2 gap analyses)
Data Flow — Funding Source
Open Question 3 — Funding Source Definition
The Auth spec shows this field as "PA PROMISe ???" — the question marks are in the original spec. It's unclear whether this is a static value ("PA PROMISe"), a selection field, or something else. AUTH-E on the Contact form says to move it from partner-level to per-service-line, which SL-11 also implies. But without knowing the field's purpose and possible values, implementation is blocked. OQ-2 in the Auth gap analysis asks the same question.
Current State
funding_source exists on both crm.lead and res.partner today as a synced field. The sync copies it on conversion. If it moves to sale.order.line, the sync logic needs updating and the crm.lead copy may become a default value rather than the authoritative source.
Governing Items (5 items across 3 gap analyses)
Data Flow — 3 Levels
Resolution — Aligned Across Analyses
Three clean levels: CRM captures at intake (PA-G), sale.order.line allows per-service overrides (SL-7/SL-8), res.partner displays for reference (AUTH-D). Auto-populate logic (county → region via ODP Appendix H) applies at all levels. Important distinction: County of Residence (partner header, H-H) ≠ County of Service (this overlap area). They are separate concepts and separate fields.
Open Question 5 (OQ-5/OQ-6) — County List Completeness
Does via.res.county contain all 67 PA counties? H-H is BLOCKED because we don't know what field on via.res.county holds the region for auto-population. Blocks PA-G, SL-7, SL-8, H-H, and AUTH-D. Also: the region key mismatch (western → west) noted in PS-D applies here — must be resolved before auto-populate logic is built.
Governing Items (4 items across 2 gap analyses)
Data Flow — Conflicting Models
Conflict — via.isp Model vs. Flat Fields
The existing system has a via.isp model with One2many records that are moved (not copied) from crm.lead to res.partner on conversion via partner_id reassignment. The Auth spec defines ISP as 7 free-text fields directly on sale.order (no separate model). These are fundamentally different architectures. Client said they're "not familiar" with the ISP Data tab on crm.lead (AU-C disagree), which suggests the existing via.isp model may be unused or unknown to them.
Open Question 4 — via.isp: Replace or Coexist?
Does the existing via.isp model get replaced by the flat fields on sale.order, or do both coexist? If replaced, existing via.isp records need migration. If coexist, which is authoritative? Blocks AU-C and ISP-1/2/3.
Open Question 5 (OQ-10) — One or Multiple Outcomes?
Auth spec ISP-1 shows 7 text fields (outcome, strategies, current status, etc.). Is this one outcome per authorization, or can there be multiple outcomes? If multiple, the flat-field approach on sale.order doesn't work — it would need a One2many sub-model. This is a fundamental architecture decision.
Governing Items (2 items across 2 gap analyses)
Current State
Conflict — Field Homelessness After AUTH-A
AUTH-A removes editable fields from the partner Authorization tab, including sc_phone_no. PA-D is deferred — client wants to explore the existing Studio method. But if AUTH-A removes the field's current home and PA-D hasn't determined the new home, sc_phone_no has nowhere to live on the partner form. The SC phone on crm.lead syncs to res.partner today — if the partner field is removed, the sync target disappears.
Open Question 7 — SC Phone Location
Where does sc_phone_no live after AUTH-A removes it from the partner Authorization tab? Options: (a) move to Person Supported Details tab on res.partner, (b) keep on partner form outside the Authorization tab, (c) derive from a future SC Many2one record. Blocks AUTH-A cleanup and PA-D planning.
Items Needing Gap Analysis Updates
Items whose gap analysis descriptions need revision based on cross-reference findings.
| Item | Source | Status | Update Needed |
|---|---|---|---|
PA-C |
CRM | Not Started | Field type should be Many2one → product.template (not Selection) to match sale.order.line.product_id |
D-C |
CRM | Not Started | Scope revised: button validates starred fields only (Service Type, County/Region, Last Name, First Name, MA Number, Internal ID). No billing validation on crm.lead. Button launches sale.order creation. |
AUTH-A |
CONTACT | Not Started | Needs specific field list with destinations: payer → SL-9, payer_program → SL-9, sc_phone_no → TBD (Open Q 7), authorized_date → sale.order header, etc. Plus API migration note for payer/payer_program. |
AUTH-B |
CONTACT | Not Started | Data source confirmed: linked sale.orders. Kanban card fields defined by Auth SL items. Visibility only when partner_type = 'person_support'. |
AUTH-D |
CONTACT | Not Started | Region/County source = sale.order.line SL-7/SL-8. Eligibility = PROMISe integration (OQ-1 pending). |
AUTH-E |
CONTACT | Not Started | Confirmed: funding_source moves to sale.order.line per SL-11. Pending OQ-2 resolution for field definition. |
PA-E |
CRM | Complete | Divergence note: client said rename date_referral, code created new inquiry_date field. Both exist. Needs reconciliation — not a cross-reference issue but flagged here because it affects the D-A waterfall logic. |
Open Questions Blocking Implementation
Questions that must be resolved before cross-form items can be implemented. Ordered by impact scope.
| # | Question | Blocks | Overlap Area |
|---|---|---|---|
| 1 | Where do Sandata/PROMISe APIs get payer/payer_program after migration to sale.order.line? | AUTH-A, SL-9 |
2 — Payer |
| 2 | Are "BASE" and "Private Pay" new payer_program LOV values or renamed existing ones? | SL-9 |
2 — Payer |
| 3 | What is funding_source? Static value, selection field, or something else? What are its possible values? | SL-11, AUTH-E, OQ-2 |
4 — Funding Source |
| 4 | Does via.isp get replaced by flat sale.order fields, or do both models coexist? | AU-C, ISP-1/2/3 |
6 — ISP Data |
| 5 | One ISP outcome per authorization, or multiple? (Determines flat fields vs. One2many sub-model) | ISP-1, OQ-10 |
6 — ISP Data |
| 6 | Does via.res.county have all 67 PA counties? What field holds the region for auto-populate? | PA-G, SL-7, SL-8, H-H |
5 — Region/County |
| 7 | Where does sc_phone_no live after AUTH-A removes it from the partner Authorization tab? | PA-D, AUTH-A |
7 — Support Coordinator |
Sale.order Future Scope (from Approved Plan)
Items explicitly pushed to sale.order by VIA's client responses.
| Field/Concept | Pushed By | Client Said |
|---|---|---|
authorized_date |
PA-F (agree) | Will be in the sales.order |
project_auth_date |
PA-F (agree) | Should also move to sales.order |
payer, payer_program, plan_tier |
PA-J (agree, COMPLETE) | Will be moved to sale.order |
| Activate Authorization button destination | D-C (disagree) | Billing fields entered in sales.order, button launches sale.order creation |
| Authorization tab | AU-A (disagree) | Build on sale.order; view-only on res.partner for Person Supported |
Known Divergences & Implementation Notes
Items where implementation differs from client instruction, or where special handling is needed.
| Item | Issue | Impact |
|---|---|---|
PA-E |
Client said rename date_referral → Inquiry Date. Code created new inquiry_date field alongside date_referral. Both exist. |
Two date fields triggering two different stages (Inquiry and Discussion). Needs reconciliation. |
PA-I |
Client said disagree, discuss further. Code implemented form unification anyway (merged). | Smartsheet shows COMPLETE. May have been resolved in lost Cowork session. No action unless client raises. |
PS-B |
Client disagrees with partner creation on conversion. Current sync logic creates/links partner on quotation. | Entire sync architecture affected. crm.lead → sale.order flow may run without res.partner. Fundamental redesign of conversion flow. |
PA-J |
COMPLETE in Smartsheet — fields hidden from CRM form. First draft incorrectly listed as needing update. | No action needed. Confirmed complete. |