CMS FAQ Management — Delivery Review v1.0.0.73

Source Document: Download original

Extension	FAQ Management (Epic 193)
Vendor	Sataware Technologies LLC
Solution Design Date	December 16, 2025
Review Date	March 6, 2026
Prepared by	Phil McCaffrey, ERP Specialist
Organization	Bestway (USA) Inc.

Executive Summary

Sataware Technologies LLC was engaged to build a Business Central extension that synchronizes fault-related master data from the FAQ API into BC (Epic 193). The approved Solution Design (dated 12/16/25) defines six tables in scope, five required fields per fault master table (20 total across four tables), three synchronization modes, and six deliverables --- including final source code delivery. The estimated effort was ~134 hours at $28/hr.

The delivered extension (v1.0.0.73) implements 1 of 20 required fields. Three of four fault master tables have zero table extensions. Source code has not been delivered despite five requests over eight days. The vendor has stated that source code is contingent on invoice payment; the Solution Design lists it as a standard deliverable.

This document recommends that UAT not proceed until: (1) source code is delivered and committed to the repository, (2) table extensions exist on all four fault master tables with all five required fields, and (3) the one-time migration is re-evaluated against the complete schema. These items should be discussed and resolved on the March 9 review call with Sataware.

1. Background

The CMS 1.0 Fault Detail Sync initiative (Epic 193) was established to synchronize fault-related master data from the external FAQ API into Microsoft Dynamics 365 Business Central. The goal is to ensure BC uses only valid, active fault codes for new transactions while preserving historical Service Orders and posted data.

Sataware Technologies LLC was engaged to design and implement the extension. The Solution Design document (dated 12/16/25) was authored by Sataware, reviewed by Bestway, and explicitly approved by Phil McCaffrey on December 16:

"This updated Solution Design appears to address and satisfy all of the acceptance criteria laid out. We are good to move forward from our side."

The Solution Design is the authoritative reference for evaluating what was delivered.

1.1. Project Timeline

Date	Event
Dec 2, 2025	Initial effort estimate shared by Sataware (~84 hours at $28/hr)
Dec 5, 2025	Bestway approves first 5 hours for Requirement Review and Solution Design
Dec 9, 2025	First draft of Solution Design delivered by Sataware
Dec 10, 2025	Bestway requests changes: automated sync, full rebuild approach, email notifications
Dec 12, 2025	Bestway confirms automated sync was always in scope; Rob Chowdhury (Director of IT) approves additional hours
Dec 16, 2025	Updated Solution Design delivered and approved (~134 hours total)
Dec 23, 2025	Sataware reports build errors (missing IWX/Innovia dependencies)
Feb 9, 2026	Sataware says corrections complete; demo call scheduled
Feb 12, 2026	Sataware submits Invoice #466051
Feb 26, 2026	Rob Chowdhury: testing not done; waiting for source code in repo
Feb 28, 2026	v1.0.0.58 installs successfully in sandbox
Mar 1-3, 2026	Versions 59-61 fail to install (BestwayUSA dependency mismatch)
Mar 5, 2026	v1.0.0.73 uploaded; source code withheld pending invoice payment
Mar 5, 2026	Bestway validates .app via symbol extraction; significant gaps identified
Mar 6, 2026	Review call scheduled for March 9

2. Solution Design Requirements

The following requirements are drawn directly from the approved Solution Design document (dated December 16, 2025). Section numbers reference that document.

2.1. Scope (Section 3)

Six BC tables are explicitly in scope:

1. Fault Area (Table 5915)
2. Symptom Code (Table 5916)
3. Fault Code (Table 5918)
4. Resolution Code (Table 5919)
5. Fault/Resolution Relationship (Table 5920)
6. Fault Area/Symptom Relationship

2.2. Deliverables (Section 4)

1. Updated BC extension logic to support FAQ API synchronization
2. One-time full rebuild synchronization capability
3. Automated incremental synchronization capability
4. Stakeholder notification summary for detected changes
5. Final source code delivery
6. Supporting technical documentation

2.3. Required Fields (Derived from Sections 7.1, 7.2, 8)

The synchronization behaviors described in the Solution Design require specific fields on each fault master table. These fields are the necessary implementation of the behaviors the document specifies.

Required Field	Derived From	Purpose
Status (Active/Inactive)	Sec 7.1: "All existing records will be marked Inactive"	Controls code availability
FAQ ID	Sec 7.1: "FAQ API identifiers will be persisted as primary reference"	Links BC records to FAQ API
Active (Boolean)	Sec 8: "Only Active values available for selection"	UI filtering for validation
Created in FAQ	Sec 7.2: "Maintain sync state across executions"	Tracks first sync timestamp
Last Modified in FAQ	Sec 7.2: "Detection of changes between API data and BC cache"	Change detection

20 required field implementations (5 fields x 4 fault master tables).

Note: The five required fields apply to the four fault master tables (Fault Area, Symptom Code, Fault Code, Resolution Code). The two relationship tables (Fault/Resolution Relationship and Fault Area/Symptom Relationship) serve as cross-reference mappings and are evaluated separately in the delivery analysis (Section 3.1).

2.4. Synchronization Approaches (Section 7)

2.4.1. One-Time Full Rebuild Sync

• All existing fault-related records will be marked Inactive
• A complete import will be performed from the FAQ API
• FAQ API identifiers will be persisted as the primary reference
• Historical and posted data will remain unchanged

2.4.2. Automated Incremental Sync

• Periodic unattended execution
• Detection of changes between API data and BC cache
• Insert new records; update modified records
• Mark records Inactive when removed from the API
• Maintain sync state across executions

2.4.3. Stakeholder Notification

• Configurable recipient list
• Summary of newly added, updated, and inactivated records

2.5. Estimated Effort (Section 10)

• ~134 hours (approximate) at $28/hr
• Covers core sync, one-time rebuild, automated incremental sync, and stakeholder notification

3. Delivery Analysis --- What v1.0.0.73 Contains

The compiled .app package for v1.0.0.73 was validated via symbol extraction on March 5, 2026. Source code was not available for review.

3.1. Table Extensions Delivered

BC Table	Table ID	Extension?	Fields Added
Fault Area	5915	Yes	Status (Option: true/false) --- Field ID 50000
Symptom Code	5916	NONE	---
Fault Code	5918	NONE	---
Resolution Code	5919	NONE	---
Fault/Resol. Relationship	5920	Yes	Status (Option) --- Field 65500; Source (Text) --- Field 65501
Fault Area/Symptom Rel.	---	NONE	---

Note: The Fault Area Status field was delivered as an Option type with true/false values (Field ID 50000). The Solution Design specifies an Active/Inactive status semantic. The delivered field type does not align with the specified behavior. The Fault Area/Symptom Relationship table, listed in scope (Section 3 of the Solution Design), has no table extension and no corresponding table ID was identified in the delivery.

3.2. Required Fields vs. Delivered

Required Field	Fault Area	Symptom Code	Fault Code	Resolution Code
Status	Present	Missing	Missing	Missing
FAQ ID	Missing	Missing	Missing	Missing
Active	Missing	Missing	Missing	Missing
Created in FAQ	Missing	Missing	Missing	Missing
Last Modified in FAQ	Missing	Missing	Missing	Missing

Result: 1 of 20 required field implementations delivered (Status on Fault Area only).

4. Gap Analysis

4.1. Missing Table Extensions (CRITICAL)

Symptom Code (5916), Fault Code (5918), and Resolution Code (5919) have no table extensions. Zero fields were added to these three tables.

Without Status, FAQ ID, or sync audit fields on these tables, the extension cannot:

1. Mark symptom codes, fault codes, or resolution codes as Inactive (Section 7.1)
2. Persist FAQ API identifiers on these tables (Section 7.1)
3. Detect changes for incremental sync on these tables (Section 7.2)
4. Filter inactive codes from UI selection on these tables (Section 8)

4.2. Missing Fields on Fault Area (HIGH)

Fault Area has a Status field but is missing FAQ ID, Active, Created in FAQ, and Last Modified in FAQ. Without FAQ ID, the rebuild sync cannot use the FAQ API identifier as the primary reference (Section 7.1). Without audit fields, incremental sync cannot detect changes on this table (Section 7.2).

4.3. Premature Migration Execution (HIGH)

The one-time full rebuild migration (Section 7.1) was executed against the sandbox before Bestway had an opportunity to capture a pre-migration baseline snapshot. This is a destructive, one-time operation.

Without a pre-migration baseline:

1. We cannot independently verify whether historical data was preserved
2. We cannot verify whether records were correctly marked Inactive
3. We cannot compare the before-state to the after-state
4. If the rebuild was incomplete or incorrect, there is no reference to restore from

4.4. Source Code Not Delivered (HIGH)

Source code has not been committed to the repository despite five requests over eight days (Feb 26, Feb 27, Mar 2, Mar 4, Mar 5).

Vendor position: "We normally provide the full AL source as part of the final delivery once the invoice for the completed development work has been settled."

Sections 4 and 11 of the Solution Design list source code delivery as a deliverable, not a post-payment conditional.

4.5. Deliverable Status Summary

Deliverable	Status
BC extension logic for FAQ sync	Partially delivered --- only 2 of 6 tables have extensions
One-time full rebuild sync	Executed but unverifiable --- no baseline, no source code
Automated incremental sync	Unknown --- cannot verify without source code
Stakeholder notification	Unknown --- cannot verify without source code
Final source code delivery	NOT DELIVERED
Supporting technical documentation	NOT DELIVERED

5. Vendor Response and Assessment

On March 5, 2026, Ashok Marimuthu (CEO, Sataware Technologies LLC) responded to the gap analysis:

"Based on our earlier discussions and the demos conducted during development, the implementation focused on adding the Status field to the Fault/Resolution table to support the inactive handling behavior required for synchronization. During those discussions, the approach was to manage the active/inactive validation through the Fault Resolution codes, since that table is the one referenced for UI validation in the service order workflow."

"From a design perspective, adding the same set of additional columns across all tables would introduce additional complexity and potential issues within the existing extension structure."

5.1. Assessment

1. The Solution Design is the agreed specification. It was authored by Sataware, reviewed by Bestway, and approved by both parties. It does not limit the scope to the Fault/Resolution table. Section 3 explicitly lists all six tables. Sections 7.1, 7.2, and 8 describe behaviors that apply to all fault-related data entities.

2. The "complexity" argument is not supported by the Solution Design. The vendor estimated ~134 hours of effort for the full scope. If the scope was always limited to two tables, the effort estimate does not reflect that limitation.

3. Verbal discussions do not override a written, approved Solution Design. The document's stated purpose is to "clearly define the approved scope, execution behavior, and boundaries for implementation" (Section 1). If the scope was narrowed during development, the Solution Design should have been updated and re-approved.

6. Additional Context

6.1. Invoice and Payment

Sataware submitted Invoice #466051 on February 12, 2026 for the full development effort. Source code delivery and further support are stated as contingent on invoice payment.

Bestway position (Rob Chowdhury, Feb 26): "Our team hasn't tested the task yet. Phil mentioned that he's waiting for you to push the code to the repository. Once everything is confirmed and moved to production, we'll inform our AP to proceed."

6.2. Source Code Request Timeline

Date	Channel	Response
Feb 26, 2026	Teams chat	Acknowledged
Feb 27, 2026	Teams chat	Acknowledged
Mar 2, 2026	Email	No response
Mar 4, 2026	Email (detailed request)	Acknowledged
Mar 5, 2026	Email (5th request)	Withheld until invoice paid

6.3. Effort Estimate History

Date	Estimate	Scope
Dec 2, 2025	~84 hours	Core sync functionality (manual trigger)
Dec 12, 2025	+40-50 hours	Automated sync + email notifications
Dec 16, 2025	~134 hours	Full scope per approved Solution Design

7. Open Questions for March 9 Review Call

The following items should be addressed on the call with Sataware:

1. Scope alignment: Does Sataware agree that the Solution Design (dated 12/16/25) is the specification for the delivered extension? If the scope was narrowed during development, why was the Solution Design not updated?
2. Missing table extensions: What is the plan to deliver table extensions for Symptom Code (5916), Fault Code (5918), and Resolution Code (5919)?
3. Missing fields: What is the plan to deliver FAQ ID, Active, Created in FAQ, and Last Modified in FAQ fields on all four fault master tables?
4. Migration verification: Can Sataware provide logs or evidence of what the rebuild migration did? What records were marked Inactive? What was imported?
5. Automated incremental sync: Has this been implemented? If so, how does it function without sync audit fields on the majority of the fault tables?
6. Stakeholder notification: Has this been implemented?
7. Source code: When will source code be committed to the repository? The Solution Design lists this as a deliverable, not a post-payment conditional.
8. Invoice reconciliation: The delivered extension does not implement the scope defined in the Solution Design. How should the invoice be reconciled against the actual delivery?

8. Next Steps

8.1. Before UAT Can Proceed

1. Source code must be delivered and committed to the repository. Without source code, Bestway cannot verify the implementation, troubleshoot issues, or maintain the extension.
2. Table extensions must exist on all four fault master tables. Symptom Code, Fault Code, and Resolution Code need table extensions with the fields required by the Solution Design.
3. All five required fields must be present on all four tables. Status, FAQ ID, Active, Created in FAQ, and Last Modified in FAQ.
4. Migration must be re-evaluated. If the rebuild ran against incomplete table extensions, the results may be incomplete or incorrect. A re-run may be required once the full schema is in place.

8.2. On the Call

1. Walk through this document section by section
2. Get explicit agreement on whether the Solution Design is the specification
3. Get a concrete remediation plan with dates for delivering the missing scope
4. Discuss invoice reconciliation in the context of the delivery gaps

Appendix A: Reference Documents

The following documents are maintained in Bestway's internal repository and are available upon request.

Document	Date	Location
Solution Design	Dec 16, 2025	V1_CSM_1_0_Fault_Detail_Sync_Solution_Design.pdf
FAQ API to BC Mapping	Dec 2025	FAQ API to BC Mapping.png
Epic 193 Requirements	Nov 2025	Epic - Sync Business Central with FAQ API.docx
This Delivery Review	Mar 6, 2026	CMS FAQ Management - Delivery Review v1.1.docx