Solution certification





1C:Compatible

Requirements to applications which can been granted 1C:Compatible certification on 1C:Enterprise 8 platform.

1. General requirements

  1. The software product submitted for certification must be intended for mass market and must not be customized for a specific deployment case. In other words, the product can be sold or intended for selling to any business or individual willing to buy it, and it can be deployed and used without any help from the vendor specialists.
  2. The product must include documentation (a user guide).
  3. The user guide must explicitly describe the product interaction with 1C:Enterprise.
  4. The product must use only officially available and documented 1C:Enterprise features. Example:
    <application name> requires an installed 1C:Enterprise platform and valid licenses for it.
    Vendor: 1C Company
    site: http://1c-dn.com
    email: int@1c.com
    postal address: 123056, PO box 64, Russia, Moscow
    1C is a registered trademark of 1C Company (1C LLC).
  5. The product intended for end users must include installation tools. If installation tools are available, they must be described in the product documentation.
  6. Using the 1C logo in the software product design and using "1C" in the product name is only allowed with the permission of 1C Company (for example, when the product is developed jointly with 1C Company). If the certification is passed, the vendor can use the 1C:Compatible logo in the product design.
  7. If the vendor releases software updates due to legislation changes or bug fixes, the vendor is responsible for compliance of the updated product to the certification requirements. If any of the changes violate the certification rules, the 1C Company can suspend the certification. New revisions of certified products that include functionality changes require new certification.
  8. The application for certification must include a written guarantee that the product is developed by the company that sent the application and does not violate any third-party intellectual property rights or any other rights, with a director signature.

2. Requirements to configurations developed in 1C:Enterprise 8

2.1. General configuration information

  1. The configuration development language is English, module texts must be written in the English version of 1C:Enterprise script. Metadata object names can be given in a single customer language instead of English. Interface texts, such as metadata object synonyms or messages that are displayed to users, must be written in the customer language. If the product includes multiple interface languages or is intended for use in multiple countries, it is recommended that one of the product languages is English.
  2. Configurations releases have version and revision numbers.

    Versions include bug fixes and minor updates. During the installation of a new version, the user data must be preserved.

    Revisions include significant accounting changes that require data conversion. During the installation of a new revision, the user data must be preserved, or the documentation must describe the migration to the new revision (getting started, transfer of opening balances, and so on).

  3. The number of the next configuration revision is the next integer number after the current revision number. Usually the revision number is followed by the subrevision number with a period as a separator, for example: revision 1.5, revision 1.6, and so on. New configuration releases start from revision 1.0.
    All versions of the same subrevision (including alpha, demo, beta, and final versions) have sequential numbers. Version numbering starts with 1.
    The revision number, subrevision number, and version number are aggregated into the full configuration version number. It is specified in the "Version" property of the configuration and has the following structure:
    {R|RR}.{S|SS}.{V|VV}.{B|BB}
    where:
    R is the revision number (1 or more digits);
    S is the subrevision number (1 or more digits);
    V is the version number (1 or more digits);
    B is the build number (1 or more digits).
  4. The "1C Solution" term is only allowed for describing configurations developed by 1C Company or localized by 1C request.
  5. Applications submitted for certification must  be developed in the managed application mode. The certification application and the product documentation must state that the application supports managed mode.
  6. The product must meet the following requirements:
    1. The product is developed using managed forms and managed interface.
    2. The full product functionality is available in the thin client and web client.
    3. If the web client does not provide full client functionality, this must be described in the documentation.

2.2. Initial configuration setup

  1. The configuration must include the functionality that detects when the configuration is started for the first time and fills the infobase with the required minimum of data, as well as the functionality that detects when the new configuration release is started for the first time and performs required changes in the infobase.
  2. The initial filling of the infobase must be divided into mandatory actions (which are required for configuration functioning) and optional actions (which are not necessary but simplify users’ first steps in the product).
  3. Once the infobase is processed during the first start of the configuration or the first start of its new release, the report listing the infobase changes must be displayed to the user. If the infobase processing is not fully complete due to any reason, the configuration must handle this and display a warning to the user.
  4. Storing a part of logically integral infobase in a separate file is not allowed. Only data that is external to the configuration business tasks can be stored separately from the infobase.

2.3. Configuration object standards

  1. Always fill the metadata object synonym. The synonym must concisely describe the object purpose.
  2. Metadata object names and synonyms must be grammatically correct.
  3. Basic configuration objects (top-level metadata objects), which include Constants, Catalogs, Enumerations, Documents, Document journals, Reports, Data processors, Charts of characteristic types, Charts of accounts, Charts of calculation types, Exchange plans, Business processes, and Registers, are sorted in the configuration tree by name in the ascending order. Objects with the "Delete" prefix are an exception to this rule, they must be located at the end of the metadata object tree branch. The positions of subordinate metadata objects in the tree (attributes, dimensions, forms, and so on) are defined by the project logic.
    Common attributes are an exception, their order is defined according to the application logic.
  4. The configuration must not include unused objects, unused menu items, or unused toolbar buttons.
  5. If the configuration includes user access rights functionality, the administrator role must be defined. The administrator role provides full access to infobase data and infobase configuration. The role must be available for independent use. The role must include all available rights except "Interactive delete".
  6. If the configuration includes the setup of general infobase user access rights (such as "Thin client", "Thick client", or "Interactive open external data processors"), specific roles that grant these rights must be defined in the configuration. These roles are not intended for independent use, they must be assigned to users together with other configuration roles.
  7. The entire configuration and its core objects that have the "Help Content" property must have descriptions intended for end users. The help topics of these objects must include the following information:
    • object purpose;
    • object call methods (from the application menu or from other objects);
    • specifics of filling object data, including the filling order;
    • descriptions of the object attributes available to end users.
    The help topics of basic configuration objects must be included in the general configuration description.
  8. Data delivered with the configuration (for example, data used for filling catalogs, report settings, or data exchange rules) must be provided in formats suitable for data exchange (for example, XML) and must be stored in "Text document" or "Binary data" templates. Do not use the "Spreadsheet document" template for this purpose.
  9. Configurations must use the managed locks mode (the configuration property "Data lock control mode" must be set to "Managed") and they must comply with the specifics of this mode. If there is a weighty reason to use a different data lock type in this configuration, reflect this fact in the documentation together with the reason explanation.

2.4. Interfaces and forms

  1. The configuration documentation must include the recommended display resolution and font size. The recommended display resolution is 1024x768 px.
  2. If the product includes parts of configurations developed by 1C Company, the configuration parts developed by vendor must have the same coding and design style as the 1C configuration parts.
  3. Tooltips must be present for all dialog box items that presume user input. The "Tooltip" property must be filled for all standard attributes, such as Code, Description, Parent, Owner, Date, and Number, as well as for all typed metadata objects (the objects that allow specifying the type of data stored in the object, such as object attributes, tabular section attributes, dimensions, or register resources). The value of the "Tooltip" property must explain the object purpose to end users. It cannot be identical to the object or attribute synonym. Specifying the tooltip text is not required if the object or attribute synonym clearly describes its purpose to the end user. For example, the FullDescription attribute of the Currencies catalog has the synonym "Currency description", which clearly describes the attribute purpose. Attributes whose values are never available for viewing or editing from the user interface do not require tooltips.
  4. For all typed metadata objects and for all standard attributes that cannot be empty according to the object logic, either the "Fill check" property must be set to "Display error" or the developer must implement a similar check in the module.
  5. The product must comply with the following rules:
    1. The last interface section contains administration tools, settings, and service operations.
    2. The desktop is a mandatory section and cannot be hidden.
    3. The following form types are always available to end users in the "All functions" menu in 1C:Enterprise mode, regardless of their presence in the application command interface:
      • main list form;
      • main report form;
      • main data processor form.

2.5. General module formatting principles

  1. Each module line contains a single operator. Combining multiple operators into a single line is only allowed for assignment operations, for example: A = 0; B = 0; C = 0;
  2. The module text must be formatted with indents. Use tab characters for indents and do not use spaces to ensure that changing the tab character width will not ruin the formatting.
  3. The syntax check of configuration modules must not return any errors.
  4. The configuration check must not return any errors. The only exception is made for procedures and functions that are dynamically assigned to control event handlers from 1C:Enterprise script (using the "Action" object). Comments to such procedures and functions must describe their usage scenarios.
    Example:
    // The procedure is dynamically assigned to the action of the command bar button FormCommandBar.ActionButtons.Button
  5. All variables in the managed application module, session module, and external connection module, as well as all export variables must have comments. Each comment must describe a variable purpose in detail. Each comment must be located after the variable declaration, in the same line.
    Example:
    Var CatalogDialogBox; //Intended for catalog item management
  6. All procedures and functions in the managed application module, session module, and common modules, export procedures and functions, and functions intended for use from other subsystems must be preceded with headings. The heading is located before the procedure or function declaration, it explains the purpose of the procedure or function and its usage scenarios. The heading must have the following format:
    • The "Description" section contains the brief description of the procedure or function purpose and usage scenarios. This can be the only section for procedures that do not have parameters.
    • The "Parameters" section describes the procedure or function parameters. If the procedure or function has no parameters, omit this section. The section is preceded with the "Parameters:" line.
    • The "Returns" section describes the type and content of the value returned by the function. The section is preceded with the "Returns:" line. Omit this section for procedures.
  7. Complex algorithms must include comments. If a comment applies to the entire module, it must be located at the beginning of the module (the module heading). If the comment is related to an operator or an operator group, it must be located before the operator or the operator group. Long comments must start with a capital letter and end with a period. The comment text must not contain grammar or syntax errors. Long comments must be aligned with the left border of the operator being commented (or the first operator in the group). There must be a space after the "//" characters that mark the beginning of the comment. The comment lines must not exceed 120 characters, except for cases where a line cannot be broken.
  8. Comments must clearly describe the module or operator functionality. They must be written in the neutral tone, must not be emotional, and must not contain parts that are not related to the application functionality.
  9. Software modules must not contain unused or empty procedures or functions, or parts that are commented out.
  10. Variable names must not begin with "_" (underscore). Variable names cannot consist of a single character, except for loop iterators. Variables that describe flag states must be named by the "true" flag values, for example, UpdateIsRunning.
  11. The global context function PredefinedValue() must not be used in scenarios where applied object managers are available (outside the thin and web client code). In other words, it must not be used in object modules, record set modules, common modules that do not have the thin client compilation flag set, server procedures, form module functions, and so on. In all these modules, predefined data must be accessed using the object manager.
  12. The variable value type must be defined by comparing the value with a type; other methods are not allowed.
    Correct:
    If TypeOf (Ref) = Type("DocumentRef.GoodsReceipt") Then
    Incorrect:
    If Ref.Metadata().Name = "GoodsReceipt" Then
  13. For creating applied objects from 1C:Enterprise script, use the object manager methods CreateItem, CreateDocument, CreateRecordSet, and so on. Using constructors (the New operator in 1C:Enterprise script) for creating objects that have managers is not allowed.
    Correct:
    DocumentReceipt = Documents.GoodsReceipt.CreateDocument();
    Incorrect:
    DocumentReceipt = New("DocumentObject.GoodsReceipt");

2.6 Messages, warnings, and notifications

  1. All messages, warnings, and notifications must be informative and concise, and they must follow the language rules. It is recommended that the messages comply with Microsoft guidelines, both generic ones (Microsoft Manual of Style) and language-specific ones (http://www.microsoft.com/Language/en-US/StyleGuides.aspx).
    English names of configuration objects in messages, notifications, and warnings must have exactly the same spelling as they have in the user interface. Address the user directly as "you", "yours", and so on.
  2. The configuration must display detailed warnings before execution of potentially unsafe operations. These are operations that can be undone only by entering data manually or restoring data from a backup.
  3. The configuration must display detailed warnings before the execution of operations that might take a long time.
  4. Modal dialog boxes, questions, or warnings must not be called within write and post transactions.
  5. When the user is asked a question with a choice of answers, the default answer must start the operation that introduces the least risk to the infobase or provides the user with control over the operation execution.
    Example 1. If the user chooses between "Delete" and "Mark for deletion", the default answer must be "Mark for deletion".
    Example 2. If the user chooses between "Print without preview" and "Print with preview", the default answer must be "Print with preview".

2.7. Configuration documentation

  1. The configuration must be delivered with documentation. The documentation must include the following sections:
    • Contents.
    • Installation instructions. Initial configuration installation. End users should be able to install the product using these instructions. If the configuration uses a protection system, this section must include protection setup instructions.
    • Configuration concept. General description, approaches to accounting, and accounting methods, models, and assumptions used in the configuration.
    • Accounting instructions. Feature descriptions and configuration usage scenarios.
  2. The configuration description must list all basic objects and techniques inherited from 1C Solution configurations, with references to these 1C Solution configurations.
  3. If the configuration uses add-ins, their properties, methods, and usage options must be described in the documentation. If these properties and methods belong to protected code, listing them will be enough.
  4. Each new configuration release must include a list of changes. The full list of changes, which is intended for end users, must be provided in a TXT or HTML file.
  5. If the configuration is created on basis of another configuration, the documentation should contain on first pages information regarding the base configuration: name, version, vendor and copyright owner, and their contacts.
    <Application name> was developed by <Application vendor> based on <Base application name>
    and run on the 1C:Enterprise, a business applications platform.
    
    <Base application description and licensing summary>.
    Vendor: <Base application vendor name>
    site: <Base application vendor site>
    email: <Base application vendor contact email>
    postal address: <Base application vendor postal address>
    
    1C is a registered trademark of 1C Company (1C LLC).

    Example:

    XYZ ERP was developed by XYZ Company based on 1C:Small Business and run on the 1C:Enterprise, a business applications platform.

    1C:Small Business is a business software solution capable of automating most activities in any small company’s workflow, including purchases and sales, manufacturing, production, customer service, project management, and much more. 1C:Small Business, a free business application, is distributed by 1C Company "as is" and can be used as a basis to develop own applications.

    Vendor: 1C Company
    site: http://1c-dn.com
    email: int@1c.com
    postal address: 123056, PO box 64, Russia, Moscow

    1C is a registered trademark of 1C Company (1C LLC).

2.8. Configuration delivery

  1. To simplify infobase creation and update by end users, the configuration must be installed on the end-user computer in compliance with 1C recommendations: all templates must be stored in subdirectories of a predefined directory together with manifest files that describe the installed templates. Installation parameter names must be unique. To ensure that the installation parameters are unique, the vendor name must be registered at 1C Company.

    Installation of 1C:Enterprise applied solutions (configurations) must comply with the recommendations described in 1C:Enterprise Administrator Guide, section "Creating an infobase based on a template".

    According to these requirements, the full path to the directory that contains the configuration templates (Infobases) provided by the configuration vendor will look as follows:
    %APPDATA%\1C\1cv8\<vendor directory>\<configuration directory>\<version directory>
    For example, the "Small Business" configuration, version 8.10.1.1 of revision 10.1, will be installed to the following directory:
    %APPDATA%\1C\1cv8\tmplts\1c\trade\8_10_1_1\
    The version directory must contain the .mft manifest file, which describes the installed configuration templates (Infobases).

    Example:

    The following is the manifest file of the "Small Business" configuration, revision 10.1. The configuration installation includes two infobase templates: an empty (production) base and a demo base.
    Vendor = 1C Company
    Name = SmallBusiness
    Version = 8.10.1.1
    AppVersion=8.3
    [Main]
    Source = 1cv8.cf
    Catalog = 1C:Small Business/Small Business
    Destination = 1C\Trade
    [Demo]
    Source = 1cv8.dt
    Catalog = 1C:Small Business/Small Business (Demo)
    Destination = 1C\DemoTrd
    To avoid duplicate configuration names, which can cause naming conflicts in the infobase creation window, it is recommended that you do the following:

    In the Catalog line of the manifest file, include the vendor name into the configuration template name (the part of the template name before the "/" character). The vendor name can be placed anywhere in the template name, for example:
    1C:Small Business
    or
    Small Business (1C)
    In the Destination line, specify the default infobase directory in the following format:
    Destination = <vendor directory>\<infobase directory>
    The <vendor directory> must include the vendor name (adjusted to comply with directory naming restrictions).

    To avoid naming conflicts, the 1C Company registers two names for each applied solution (configuration) vendor: the name to be used in configuration templates and the name to be used in file paths. The vendor name is registered once and can be used in the installation and setup of all 1C:Enterprise applied solution templates provided by this vendor.

    The vendor name registration procedure is as follows.

    The applied solution vendor sends the following email message to int@1c.com:

    To the applied solution (configuration) development department of 1C Company
    Vendor name: <full name of the vendor company>
    Partner code (for 1C partners): <partner code>
    Please register the following vendor names:
    Name used in file paths: <vendor directory name>
    Name used in configuration templates: <vendor name>  
    The <vendor directory name> must not contain characters that are not allowed in file names. It is recommended that the <vendor directory name> does not exceed 11 characters.

    The <vendor name> must not contain backlashes \ or slash marks /.

    The email message must be signed by the head of the vendor company.

    Within a week after receiving the message, the 1C Company either informs the vendor company that the names are registered or declines the registration providing the reason and the recommendations for eliminating the issues that prevent registration.

    Once the applied solution gets the 1C:Compatible certificate, the 1C Company publishes the registered directory and vendor names at 1c-dn.com.

    Applied solution vendors cannot use names registered by other vendors.
  2. The configuration must be delivered with support enabled.
  3. The configuration must be delivered with a demo example, which is provided as a separate infobase and is a consistent example based on fictional company data. The example must not contain object names like "Test", "Item 1", "Counterparty 3", and so on. Filling document fields with data like "Purpose 1", "Content 1" is not recommended. The demo base data must match the specifics of the solution business area.
  4. The demo base must contain data that is reflected in its reports. Reports that only contain headings and do not contain data are not allowed.
  5. Configuration modules must not be protected with passwords. The product submitted for certification must contain the module source code. However, the delivery kit intended for end users must not contain all module sources.
  6. The configuration can have hardware or software protection. In this case it must meet the following requirements:
    • the description of the hardware protection setup must be included in the printed documentation;
    • the user guide must state that the product is not fully configurable, and it must list the configuration objects that cannot be changed by users;
    • since a protected configuration is not fully available for editing, the vendor takes responsibility for its maintenance and for compliance of the protected configuration parts to the certification rules;
    • 1C marketing materials can state that the product contains parts that cannot be changed during its customization for the needs of a specific company.
  7. If the documentation is delivered in electronic form, the product delivery kit must include the delivery description file with the following documentation details:
    • software required to read the documentation;
    • page size;
    • number of pages;
    • fonts used in the documentation;
    • list of authors.
    an example:
    1. Documentation can be read using the software "Adobe Reader" (http://www.adobe.com/products/reader.html).
    2. Page Size - A4.
    3. Number of pages - <page number>.
    4. Used fonts - Times New Roman (bold, italics).
    5. Authors - <authors>.

3. Requirements to 1C Solution add-ons developed in 1C:Enterprise 8

  1. This category of software products extends the capabilities of 1C Solutions. An add-on can include a 1C Solution configuration with new objects added, or it can include a set of objects to be added to the configuration.
  2. The add-on objects must comply with all of the requirements to configuration objects. The add-on documentation must include the descriptions of the new objects but it must not describe the entire configuration.
  3. The documentation must include the name of the 1C Solution for which the add-on is intended.
  4. The documentation must describe how to include the add-on in the configuration and migrate it to next configuration releases. If the migration description is too complex to include in the user documentation, the documentation can state that the vendor will release add-on updates for each 1C Solution release.
  5. The names of new objects and configuration attributes must include a prefix, which indicates that they do not belong to the 1C Solution configuration.
  6. In module texts, all parts that belong to the add-on must be marked with comments.
  7. Configuration add-ons must be installed to end-user computers in compliance with 1C recommendations: all templates must be stored in subdirectories of a predefined directory together with manifest files that describe the installed templates.
  8. Add-ons must be delivered with a demo infobase, which must be described in the documentation.

4. Requirements to service reports and data processor sets developed in 1C:Enteprise 8

  1. A set of service reports and data processors provides additional services for configuration users. Software products that belong to this category must comply with all of the configuration requirements related to product design and usage of 1C:Enterprise tools.
  2. If the set is intended for a third-party configuration, the configuration must have a valid 1C:Compatible certificate.
  3. The installation of the set of reports and data processors and their integration into the configuration must be described in the documentation.
  4. All module variables must have comments. Each comment must describe a variable purpose in detail. Each comment must be located after the variable declaration, in the same line.
  5. All procedures and functions must be preceded with headings. The heading is located before the procedure or function declaration, it explains its purpose and usage scenarios. The heading must have the following format:
    • The "Description" section contains the brief description of the procedure or function purpose and usage scenarios. This can be the only section for procedures that do not have parameters.
    • The "Parameters" section describes the procedure or function parameters. If the procedure or function has no parameters, omit this section. The section is preceded with the "Parameters:" line.
    • The "Returns" section describes the type and content of the value returned by the function. The section is preceded with the "Returns:" line.  Omit this section for procedures.

5. Requirements to 1C:Enterprise 8 add-ins

  1. Add-ins extend 1C:Enterprise 8 functionality. The add-ins must comply with the add-in creation rules provided by 1C Company. The rules describe add-in creation for operating systems of Windows and Linux families, as well as for the web client that runs in Microsoft Internet Explorer 6.0, 7, or 8 or in Mozilla Firefox version 3 (for Windows and Linux).
  2. The add-in must be provided for all operating system and client application types supported by the solution whose functionality is extended by the add-in. The supported operating system and client application types must be listed in the documentation.
  3. All component variants must be archived into a ZIP file with a manifest.
  4. If the add-in is intended for a third-party configuration, the configuration must have a valid 1C:Compatible certificate.
  5. All of the add-in properties and methods must be described in the documentation.
  6. The user guide must describe the integration of the add-on with 1C:Enterprise 8 with examples based on the 1C:Enterprise configuration.
  7. All configuration objects affected by the add-in must have descriptions that explain the add-in functionality. The descriptions must be included in the object help topics.
  8. In module texts, all parts that include add-in integration or its method calls must be marked with comments.

6. Requirements to products that interact and exchange data with 1C:Enterprise 8

  1. The product user guide must state the 1C:Enterprise version compatible with the product.
  2. If data exchange with a third-party configuration is allowed, the third-party configuration must be 1C:Compliant.
  3. Software products integrated with 1C:Enterprise must use only official and documented 1C:Enterprise features for interaction and data exchange.
  4. The user guide must describe the interaction between the software products with examples.
  5. The certification application must include a detailed instruction for reproducing interaction and data exchange scenarios.

Requirements are valid since June 1, 2013.

Comments
0
Add comment