Purpose
This WS is designed registration of a new pharmacy's division
Specification
Logic
General
Each legal entity can manage its own divisions:
add new division
view existing divisions and its details
edit some information on existing division
deactivate division
Only users of this legal entity with specific scopes can manage divisions
Editable information on division:
name
addresses
phones
email
add the gps-coordinates attributed to the division
working hours
Note: Exclude legal_entity_id from Divisions Request Payload in Public API's. Legal_entity_id must be set by GW using user access token.
Note: Calculate mountain group for each new Divisions based on division address
Confluence: ERD
Acceptance criteria:
Configured Public GET, POST, PATCH methods on GW
Successful response with correct authorization and appropriate scopes
401 error on invalid authorization
403 error on invalid scopes
Legal entity id is missing in request
Legal entity id is set as header by GW
Created divisions saved to DB
Mountain group calculated
Request structure
Example:
Authorize
Verify the validity of access token
Check user scope (scope = 'division:write') in order to perform this action
In case error generate 401 response
Headers
Наприклад:
Content-Type:application/json
Request data validation
Validate location
Location is required for divisions related to legal entity with type PHARMACY
Check that location exists in request for legal entity with type PHARMACY
In case of error - generate 422 response
Validate addresses
Check that addresses.type exists in dictionaries.
In case error generate 422 response
Check that address exists in Uaddresses
in case error generate 422 response
Check mapping legal_entity_type, division_type and address_type and its obligation. See validation rules here: Validation rules on Divisions
in case error generate 422 response
Validate phone
Check that phone type exists in dictionaries. PHONE_TYPE required (MOBILE,LAND_LINE)
in case error generate 422 response
Check phone number is valid according to "^\\+38[0-9]{10}$"
in case error generate 422 response
Validate email
Check that email is valid according to "~r/^[\\w!#$%&'*+\\/=?`{|}~^-]+(?:\\.[\\w!#$%&'*+\\/=?`{|}~^-]+)*@(?:[A-Z0-9-]+\\.)+[A-Z]{2,6}$/i"
in case error generate 422 response
Validate type
Check that type exists in dictionaries.
in case error generate 422 response
Check mapping of legal_entity_type and division type. See validation rules here: Validation rules on Divisions
in case error generate 422 response
Processing
Create new division
Parameter | Source |
---|---|
action | `PUT` |
id | |
external_id | $.external_id |
name | $.name |
type | $.type |
mountain_group | |
addresses | $.addresses |
phones | $.type, $.number |
inserted_at | :timestamp |
Updated_at | :timestamp |
legal_entity_id | take from token |
Location | $.latitude, $.longitude |
status | ACTIVE |
is_active | true |
working_hours | $.working_hours |
Additional
Add new mapping for "division_type" & Legal_entity_type
Check that prm.legal_entities.status = active or suspended and prm.legal_entities.is_active = true for legal entity to which division is added
Add new validation for verification of usage division_type in Legal_entity_type at Create_division process.
There is no other specific logic for new division types.
Response structure
Example: