F³: How Free Configuration Changes the Approach to 1C
The F³ project introduces a fundamentally new configuration format for the 1C platform, built on open-source code, stable architecture, and genuine attention to business needs. Unlike standard solutions, F³ eliminates dependency on frequent updates and enables long-term use of information systems without being tied to annual legislative changes.
Conceptual Foundations of the Project
The main issue with standard 1C configurations is their focus on rapid responses to legislative changes while ignoring user needs. F³ addresses this through:
- Fully documented and modular code
- Abstraction of legislative changes
- Support for older platform versions (starting from 8.3.16)
A key element is the GNU3 model, which guarantees complete code freedom. This prevents 1C from acquiring rights and shutting down the project, as happened with UNF. The architecture is designed to abstract legislative changes via parameterization rather than hard-coding dates and rules.
Functional Capabilities
The implemented functionality covers key business processes:
- Sales and procurement management with full mutual settlements
- Warehouse accounting with batch tracking and sequence restoration
- Integration with trade equipment (Shtrih-M, Atol) via TOL
- Support for labeling and receipt printing
- Flexible access rights system without using standard 1C roles
Special attention has been given to print forms—generation is handled for individual objects using structured data, which simplifies customization. All service data (drivers, classifiers) is stored in a separate repository rather than the database, boosting system portability.
Development Principles
Architectural Decisions
JSON takes priority over XML wherever technically feasible. Parameterization replaces hard-coded dates in the code—all settings are historized and controlled via checkboxes in the interface. The Fixin function library fully replaces BSP, ensuring code transparency and testability.
A critically important decision was basing it on the 8.3.16 platform. This enables migration even for outdated configurations, sparing businesses the costs of a full system overhaul. Developers deliberately opted out of the "rat race" for new platform versions.
Access Rights System
Implemented via programmatic restrictions with five basic roles:
- Administrator
- Regulator
- Full Access
- View
- External Code
Access control is handled through:
- Checks on form opening
- Programmatic filters in lists
- Modifications to SQL queries
Unlike standard configurations, there are no checkbox-based roles. Menu access is managed via functional options, allowing flexible interface customization for specific tasks.
Features of Inventory Accounting
Classic batch accounting with sequence restoration was chosen as the most practical for trade operations. This approach eliminates the need for monthly period closing, simplifying work with overdue goods and batches. Batch accounting extends to mutual settlements, providing end-to-end analytics across all operations.
Support for RIB (regulated infobases) is implemented via the configuration version update mechanism. This preserves data integrity during migrations between versions without losing historical records.
What Matters
Long-term stability: The configuration core doesn't require annual replacement, reducing the TCO of the accounting system
Open code: Full access to sources on GitHub under GNU3 license
Legacy support: Compatible with platform 8.3.16 and above without losing functionality
Flexible rights: Rejects standard 1C roles in favor of programmatic access control
Savings on updates: Cuts costs for adapting to legislative changes through parameterization
— Editorial Team
No comments yet.