Submitter calendar can accept duplicates by db design, but non functional in use cases. Business logic / queries need to adjust to that.
The key fields in submitter_calendar are submitter_id, data_period_start.
Submitter_id is distinct for each submitter (org, payor_code). There is no other information in submitter_calendar to derive uniqueness. With the current db design, it is safe to assume the data_period_start should be unique per submitter_id.
If any of the business logic needs to change, that will require db design change.
Overview
Submitter calendar can accept duplicates by db design, but non functional in use cases. Business logic / queries need to adjust to that. The key fields in submitter_calendar are submitter_id, data_period_start. Submitter_id is distinct for each submitter (org, payor_code). There is no other information in submitter_calendar to derive uniqueness. With the current db design, it is safe to assume the data_period_start should be unique per submitter_id. If any of the business logic needs to change, that will require db design change.
Related
WP-483
Changes
Testing
select calendar_item_id, submitter_id, data_period_start, expected_submission_date from submitter_calendar;
Screenshot with no duplicates in UI.
Also, navigation took to the dashboard
UI
Notes