Residency Personal Portal with Dynamic Forms and 1C Integration

I developed a residency personal portal in conjunction with 1C, working alongside a 1C developer. On my side, I designed and implemented the web portion using Yii2, including a dynamic forms module, data storage, file circuit, admissions campaign settings, registry management, and data transmission back to 1C.

The key value of the project was that the forms and part of the business logic were not hardcoded into the interface. I implemented a universal mechanism that allowed receiving form structures from 1C in JSON format, storing them in the database, rendering them in the personal portal, validating entered data, and then sending the completed questionnaires and applications back to 1C in the expected structure.

A distinct part of my work was designing the integration layer between 1C and the personal portal. I designed the structure of JSON requests and responses, form behavior rules, the composition of transmitted entities, scenario logic, and prepared documentation for data exchange between 1C and the portal.

Project Context

The project addressed the task of digitalizing admissions campaign processes for residency:

applicant registration;
maintaining questionnaires and personal data;
filling out and accompanying applications;
moderator workflow with verification, comments, and statuses;
synchronization of registries, campaign stages, and settings from 1C;
file and document exchange between the portal and the external system.

In essence, this was not just a set of web forms, but an applied personal portal with its own dynamic forms platform built on top of 1C integration.

What has been implemented

Implemented the dynamicform module as a discrete application circuit for working with dynamic forms.
Designed API interaction between 1C and the portal at the level of request/response structures and user scenarios.
Prepared documentation for JSON structures through which 1C transmitted form schemas, registries, and settings, and received back questionnaires and applications.
Built a storage model for form structures via sections, forms, blocks, fields, element types, and events.
Implemented loading of dynamic form structures from 1C via an API with authorization, JSON parsing, and storage in a local DB.
Added a mechanism for form and event validity to ensure that updates from 1C did not break current logic and allowed for structure version management.
Created a unified DynamicFormWidget that rendered a form by name, section UID, or form UID, used in various portal scenarios.
Integrated dynamic forms into applicant registration, profiles, discrete block editing, application management, and modal windows.
Implemented saving of dynamic field values linked to the user, application, form session, block, row group, and table elements.
Supported table blocks and repeating data groups where a single form could contain several rows with identical field structures.
Implemented file storage within dynamic forms with a discrete file module, file metadata, and token-based API access.
Added server-side validation of dynamic fields based on form configuration and element type.
Implemented additional validators for applied attributes, including SNILS (Russian insurance number) and other identification data.
Developed uniqueness checks and access recovery scenarios via passport data through a link between the local DB and 1C API.
Upon new user registration, saved not only the account but also the applicant profile, personal data, and documents attached to the dynamic form.
Implemented collection and normalization of profile and application data before transmission back to 1C.
Assembled nested structures for 1C, preserving section UIDs, form UIDs, block UIDs, field UIDs, sorting, element types, tables, and row groups.
Supported discrete serialization of fields and table parts so that the web form could be correctly converted back into the 1C exchange format.
Added saving of debug JSON files to monitor the structure of outgoing data.
Implemented administrative scenarios for updating dynamic forms and registries from 1C via console commands and web interface triggers.
Added a discrete admissions campaign settings circuit: deadlines, stages, events, filters, mandatory flags, and specific user scenario behaviors.
Implemented moderator scenarios for application management: comments, block selection for verification, status changes, list viewing, and application tracking.
Connected registries and logs from 1C for value selection in dynamic fields and subsequent data decoding in the interface.
Implemented loading and updating of FIAS (Russian federal address system) data from 1C, including storage by region and export versioning.

Technical Highlights

Dynamic forms were detached from hardcoded HTML and assembled based on the structure received from 1C.
The integration layer was designed not as a set of scattered calls, but as a consistent API contract between 1C and the web application.
The same engine was used for different scenarios: registration, profile, application, discrete block editing, and modal forms.
Values were stored not as flat fields, but as a linked structure with section_uid, form_uid, block_uid, field_uid, group_uid, statement_uid, and session_uid.
For table parts, I used discrete row grouping logic and repeating blocks to maintain compatibility with the 1C data model.
Return transmission of an application to 1C was performed not at a primitive field array level, but with full reconstruction of the form structure and element sorting.
For exchange with 1C, I designed the composition of JSON packets, data serialization rules, and API behavior depending on the user scenario.
Validation was built dynamically based on field configuration and element type.
Form and registry updates were moved to discrete console scenarios to avoid tying 1C exchange solely to user actions.
For files, I implemented a discrete upload module and a secure API retrieval circuit.

What the project demonstrates

Experience with close collaboration with a 1C developer at the level of exchange structure, JSON schema, and applied logic.
Experience designing APIs and documentation for integration between 1C and a personal portal.
Ability to design not just forms, but a universal dynamic forms engine with schema and data storage.
Ability to translate 1C's external structure into a working web interface and back.
Experience building a complex data model for a personal portal involving users, profiles, applications, files, registries, campaign stages, and roles.
Experience working with portals for internal and external users where roles, moderation, statuses, and change history are critical.

Technologies

PHP
Yii2
MySQL
Bootstrap 5
JavaScript
jQuery
Yii HTTP Client
JSON API
SOAP
1C API Integration
FIAS

My role

My role was pivotal from the web development side. I participated in solution design alongside the 1C developer and implemented the web part of the personal portal: dynamic forms module, data storage and validation, user registration and application submission scenarios, file circuit, administrative settings, registry integration, and data transmission back to 1C. Additionally, I designed the API contract between 1C and the portal, worked out the JSON structure and behavioral scenarios, and prepared documentation for correct data exchange between the systems.

Practical value of the project

This project effectively demonstrates the creation of an applied platform on top of 1C integration rather than just a simple Yii2 portal:

design of a custom dynamic forms mechanism;
design of APIs and JSON contracts for integration between 1C and a web application;
bidirectional exchange of complex data structures with 1C;
work with table parts, files, registries, and campaign stages;
implementation of moderator and administrative scenarios;
construction of an expandable architecture for further portal development.