1C configuration and development services
1C development can automate local work, reduce repetitive operations, and produce a result that can be verified on a specific workstation or within a corporate environment. On DitWork, the client describes the workflow, attaches an anonymized example, and compares specialists by technology, relevant experience, schedule, deliverables, and support. Clear information about users, data, and the execution environment reduces compatibility risk after handover.
Tasks you can order
Within 1c development, clients can order customization of standard and industry configurations, reports, data processors, and print forms, website, CRM, bank, and service integrations, data migration and cleanup, configuration and platform upgrades and diagnosis of errors, locks, and performance issues. Separate the mandatory outcome from future ideas. For each workflow, state the input, user action, successful output, expected error message, and recovery path. This structure allows specialists to estimate not only coding but also testing, deployment, onboarding, and maintenance.
- customization of standard and industry configurations
- reports, data processors, and print forms
- website, CRM, bank, and service integrations
- data migration and cleanup
- configuration and platform upgrades
- diagnosis of errors, locks, and performance issues
Deliverables by stage
| Stage | Deliverable | What to verify |
|---|---|---|
| Diagnosis | Plan, technology, and risks | Limits, backup, and rollback are clear |
| Implementation | Working version with test data | Core workflow and errors are verified |
| Handover | Production-ready result and documentation | Files, instructions, tests, and rights are available |
What to include in the brief
Before work starts, provide configuration name and platform release, description of the current business process, user roles, a sample document or report, information-base size, data-exchange and external-system diagram and acceptance criteria and allowed downtime window. Share copies and test records rather than the only production file. When the task involves accounting, customer data, or commercial information, decide which fields can be anonymized. Access to a computer, server, or business system should be given only to the selected specialist and limited to the permissions required for the agreed task.
- configuration name and platform release
- description of the current business process
- user roles
- a sample document or report
- information-base size
- data-exchange and external-system diagram
- acceptance criteria and allowed downtime window
What to inspect before work starts
Before development or implementation, inspect whether the configuration is standard or modified, use of extensions, upgrade status, backup readiness, scheduled and background jobs, exchange queues and registration and technology logs. Diagnosis reveals whether a local change is sufficient or whether the task needs another product, architecture, or migration plan. Record the current software version, create a verified backup, and define how the working state will be restored. A critical workflow should be tested against a copy of the data and deployed during an agreed maintenance window.
- whether the configuration is standard or modified
- use of extensions
- upgrade status
- backup readiness
- scheduled and background jobs
- exchange queues
- registration and technology logs
Delivery workflow
A controlled workflow includes inspect the process and a test database, agree on an extension or configuration change, create a verified backup, develop and test roles, test exchanges and reporting, deploy to production and observe behavior after release. Every milestone should end with a verifiable deliverable rather than only a time report. For a complex task, separate the prototype, core behavior, error handling, and deployment. This validates the riskiest part early and avoids spending the budget on full interfaces before the technology has proved suitable.
- inspect the process and a test database
- agree on an extension or configuration change
- create a verified backup
- develop and test roles
- test exchanges and reporting
- deploy to production
- observe behavior after release
Technical requirements
The technical requirements should cover preservation of standard upgrade paths, separation of custom and vendor code, role and access control, transactions for critical operations, protection against duplicate imports, error logging, client and server compatibility and analysis of locks and long-running queries. Software must respond safely to empty input, unavailable files, lost connectivity, and repeated execution. Passwords, tokens, and personal paths should not be embedded directly in source code. Configuration belongs in a documented file or protected storage, while logs should support diagnosis without exposing secrets.
- preservation of standard upgrade paths
- separation of custom and vendor code
- role and access control
- transactions for critical operations
- protection against duplicate imports
- error logging
- client and server compatibility
- analysis of locks and long-running queries
What the specialist should deliver
At completion, request the extension, processor, or configuration changes, installation instructions, a list of objects and modules, upgrade sequence, verification scenarios, rollback plan and test results from a database copy. An executable-only delivery may be appropriate for licensed ready-made software, but custom development requires an explicit agreement about source-code access. The documentation should allow another specialist to install the solution, restore data, apply an update, and understand limitations without relying on verbal instructions from the original author.
- the extension, processor, or configuration changes
- installation instructions
- a list of objects and modules
- upgrade sequence
- verification scenarios
- rollback plan
- test results from a database copy
What affects the price
The price of 1c development depends on degree of existing customization, number of companies and users, database volume, number of integrations, reporting requirements, upgrade needs and urgency and permitted downtime. Compare proposals by included deliverables: diagnosis, migration, installer, testing, training, and a defect-correction period. A very low estimate prepared without reviewing examples often omits compatibility, error handling, and deployment on the real workstation.
- degree of existing customization
- number of companies and users
- database volume
- number of integrations
- reporting requirements
- upgrade needs
- urgency and permitted downtime
How to choose a specialist
When choosing a specialist for 1c development, review relevant projects and the quality of clarification questions. A responsible developer does not promise support for every version and platform without verification, request permanent administrator access by default, or hide limitations of the selected technology. Agree on the repository, progress reporting, demonstration schedule, and scope-change procedure before implementation.
How to accept the result
Before acceptance, verify documents post according to agreed rules, roles see only permitted data, exchanges do not create duplicates, reports match the control example, upgrades do not break the customization, logs contain no new critical errors and backup and rollback have been verified. Repeat the control operations on agreed workstations and user accounts with normal, empty, and invalid data. Record execution time and compare the output with the reference. When the solution changes files or a database, verify backup and restoration separately and test behavior after an interrupted operation.
- documents post according to agreed rules
- roles see only permitted data
- exchanges do not create duplicates
- reports match the control example
- upgrades do not break the customization
- logs contain no new critical errors
- backup and rollback have been verified
Access, security, and rights
A 1C technical requirement should be connected to the real business process. A request to add a field does not explain who enters it, when it is mandatory, where it is used, or whether it affects print forms, exchanges, and reports. Agree separately whether the change will be implemented as an extension or as a configuration modification because this affects upgrades, support, and long-term ownership cost.
In a 1c development project, the client is responsible for lawful use of software, libraries, data, and business systems. The specialist is responsible for the agreed scope, secure access handling, and clear delivery documentation. Third-party licenses, distribution restrictions, and source-code transfer rights must be recorded before work starts. Temporary passwords should be rotated after acceptance, and unnecessary remote access should be disabled.
How to post a task on DitWork
To order 1c development on DitWork, post a task with an anonymized control example, target systems, expected output, and acceptance criteria. State the mandatory minimum, target date, and permitted deployment window. Compare proposals by process understanding, diagnostic plan, technology, testing, delivered materials, and post-launch support terms.
