Almacenamiento de datos

• Uso de atributos de tipo Cadena
• Longitud de códigos y números de objetos de configuración
• Nombre, sinónimo y comentario
• Entrega de datos en paquetes de configuración
• Consejos y comprobaciones de llenado
• Reflejar la naturaleza de los objetos de metadatos utilizando atributos
• Manejo de objetos inactivos
• Atributo de comentario de documentos
• Eliminación de objetos de metadatos obsoletos de las configuraciones
• Autosuficiencia de registros
• Principios de almacenamiento de datos genéricos
• Uso de elementos predefinidos
• Uso de la propiedad Activo de registros de registro
• Requisitos de publicación de documentos
• Limitaciones para el uso de atributos de tipo compuesto

Uso de atributos de tipo Cadena

Este artículo describe los estándares que se aplican a los atributos de tipo Cadena. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1.1. Para los atributos de tipo Cadena, especifique el tipo de longitud Variable en la propiedad Longitud permitida, y especifique la longitud máxima de la cadena. Evite usar el tipo de longitud Fija a menos que sea absolutamente necesario (la longitud fija se puede mantener agregando espacios al final de la cadena).

1.2. Si la longitud máxima de la cadena está predefinida (en estándares, documentos normativos, etc.), especifíquela en la propiedad Longitud, o en la propiedad Longitud de descripción del atributo estándar Descripción. Por ejemplo, la longitud del atributo SSN del catálogo Empleados debe ser de 9 caracteres.

1.3. Calcule la longitud de una cadena concatenada sumando las longitudes de todos sus segmentos. Por ejemplo, calcule la longitud de la presentación de la dirección sumando las longitudes de las líneas de dirección.

1.4 Si la longitud de una cadena no está regulada por ningún estándar, establezca la longitud que sea suficiente para almacenar datos en la mayoría de los casos. Por ejemplo, un nombre completo de contratista generalmente ocupa hasta 250 caracteres, un nombre de archivo en la mayoría de los sistemas de archivos ocupa hasta 260 caracteres, un nombre completo de una persona ocupa hasta 100 caracteres, y así sucesivamente.

2. Se permite el uso de cadenas de longitud indefinida en los siguientes casos:

2.1. Un atributo de cadena está destinado a almacenar texto definido por el usuario que puede tener una longitud significativa. Un ejemplo común es un campo de formulario que permite la entrada de múltiples líneas de texto. Por ejemplo, un gerente puede almacenar todo el historial de comunicación con el cliente en el campo Información adicional de un pedido de cliente; un usuario puede almacenar un texto arbitrario que contiene múltiples líneas en el campo Comentario, y así sucesivamente.

2.2. Un atributo de cadena almacena datos técnicos generados por la aplicación, que en su mayoría no están destinados a ser vistos por los usuarios, sino a ser utilizados en algoritmos de procesamiento de datos. Por ejemplo, documentos XML o encabezados de mensajes de correo electrónico.

3. Al utilizar cadenas de longitud indefinida, recuerde las siguientes limitaciones del lenguaje de consulta:

3.1 Al comparar, agrupar o seleccionar valores distintos, debes convertirlos en cadenas de longitud fija. De lo contrario, el resultado del cálculo podría ser incorrecto.

Recomendamos que utilices la siguiente sintaxis de consulta:

CAST AS STRING(1000)

3.2. En informes basados en esquemas de composición de datos, especifica el parámetro Tipo de Valor para esos campos (en la pestaña Conjuntos de Datos).

Ten en cuenta que la conversión frecuente de longitud no definida a longitud fija en consultas e informes basados en esquemas de composición de datos podría indicar que el diseño de la aplicación no es óptimo. En ese caso, se recomienda rediseñar a favor de la longitud fija.

3.3. En todos los demás casos, puedes utilizar libremente cadenas de longitud no definida en consultas.

4.1. Si una cadena se muestra en un campo de formulario de impresión, asegúrate de que nunca se corte, independientemente de la longitud de cadena declarada. Cortar una cadena podría llevar a la pérdida de datos significativos, como números de edificio y apartamento en una dirección de entrega.

Longitud de códigos y números de objetos de configuración

Este artículo describe los estándares que se aplican a la longitud de códigos o números de objetos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

Nombre, sinónimo y comentario

Este artículo describe los estándares que se aplican a los nombres de objetos, sinónimos y comentarios. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1.1. Un Sinónimo de objeto debe describir el objeto de manera concisa, reflejando el propósito del objeto. Un sinónimo es obligatorio para cada objeto.

Esto es necesario porque los sinónimos están presentes en la interfaz de usuario (en formularios, informes, interfaces de comandos, etc.), y por lo tanto deben describir los objetos de manera correcta, clara y coherente. Además de los objetos de metadatos, este requisito también se aplica a los atributos de objetos de metadatos, secciones tabulares, atributos de secciones tabulares, dimensiones de registros, recursos y cualquier otro objeto de configuración que tenga sinónimos.

1.2. Recomendamos que no utilices abreviaturas para los sinónimos. Puedes hacer una excepción para las abreviaturas que son conocidas por la audiencia objetivo (como Suma, TIN o SSN).

1.3. El significado de todos los términos utilizados en los sinónimos de objetos debe ser claro para los usuarios, al igual que cualquier mensaje mostrado a los usuarios. No utilices jerga, nombres informales de productos o empresas, palabras en inglés escritas en alfabeto extranjero, palabras extranjeras escritas en alfabeto inglés, etc.

1.4. Especifica sinónimos para los atributos estándar de los objetos de metadatos en función de su significado real en tu aplicación.

1.5. Para los atributos estándar Padre y Propietario, siempre cambie sus sinónimos predeterminados. Por ejemplo, una configuración contiene el catálogo Archivos, que tiene un atributo estándar Propietario de tipo CatalogRef.FileFolders.
Incorrecto:

• Deje el sinónimo predeterminado “Propietario” del atributo estándar Propietario.

Correcto:

• Defina el sinónimo que refleje el significado del objeto, como “Carpeta” o “Directorio”.

Para algunos catálogos está bien dejar el sinónimo predeterminado “Descripción” del atributo estándar Descripción. Para el catálogo Archivos, puede elegir el sinónimo “Nombre de archivo”, y para el catálogo Individuos, puede elegir el sinónimo “Nombre completo”.

1.6. Si tiene dos o más objetos de metadatos similares, asegúrese de que sus sinónimos los describan completamente.

Sinónimos incorrectos de catálogos:

• Cuentas bancarias
• Cuentas bancarias de contrapartida

Correcto:

• Cuentas bancarias de la empresa
• Cuentas bancarias de contrapartida

Los nombres deben describir explícitamente los objetos. De lo contrario, los usuarios preguntarán: “Si el catálogo Cuentas bancarias de contrapartida almacena las cuentas bancarias de las contrapartes, ¿en qué catálogo se almacenan las cuentas de los bancos?”

Este requisito también se aplica a los sinónimos de los objetos de metadatos subordinados (atributos, secciones tabulares, dimensiones, recursos, etc.).
El siguiente ejemplo describe los sinónimos de los atributos de la sección tabular Artículos del documento Recuento de inventario.
Incorrecto:

• Recuento
• Recuento (desde contabilidad)

Correcto:

• Recuento (disponible)
• Recuento (desde contabilidad)

El siguiente ejemplo describe los sinónimos del atributo estándar Descripción y otro atributo del catálogo Artículos.
Incorrecto:

• Descripción
• Descripción extendida

Correcto:

• Descripción para visualización
• Descripción para impresión

2.1. Recomendamos que cree el objeto Nombre basado en su sinónimo (eliminando espacios y otros caracteres no permitidos en los nombres y capitalizando la primera letra de cada palabra). Ejemplos:

• el catálogo Conjuntos de datos y atributos adicionales tiene el sinónimo “Datos adicionales y conjuntos de atributos”.
• el comando Archivos adjuntos tiene el sinónimo “Archivos adjuntos”.

Puede usar nombres más cortos donde se omita una o varias palabras del sinónimo. Ejemplos:

• TiempoDeRespuestaDelServidor tiene el sinónimo “Tiempo de respuesta del servidor (seg)”
• NúmeroDeUnidades tiene el sinónimo “Número de unidades de medida”
• NombreDeAtributo tiene el sinónimo “Nombre de atributo (propiedad)”

Al crear nombres a partir de sinónimos, omita los artículos. También puede omitir preposiciones y conjunciones. Por ejemplo, el atributo ValorDescuentoRecargo tiene el sinónimo “Valor de descuento o recargo”.

Por otro lado, puede usar sinónimos más cortos donde se omitan una o varias partes “técnicas” del nombre.

Este requisito garantiza que los objetos de configuración y sus presentaciones en la interfaz de usuario sean fácilmente reconocibles. Ayuda en la etapa de implementación porque los desarrolladores generalmente no participan en este proceso, dejándolo en manos de especialistas en implementación.

Consulte también: Nombres de objetos de metadatos en configuraciones

2.2. Los objetos de metadatos con el prefijo Eliminar son una excepción a esta regla.

Tampoco cambie el nombre de los objetos de metadatos, sus atributos, formularios, etc., si los objetos deben cumplir con los requisitos de compatibilidad con versiones anteriores. En particular, las diferentes versiones de la biblioteca dentro de una sola revisión deben ser compatibles entre sí.

2.3. Los nombres de los objetos de metadatos de nivel superior (catálogos, documentos, etc.) no deben exceder los 128 caracteres.

2.4. Recomendamos que los nombres de los objetos de metadatos subordinados (atributos, dimensiones, recursos, etc.) no sean idénticos a los nombres de los objetos principales. Por ejemplo, la dimensión Usuario (que tiene el tipo CatalogRef.Usuarios) del registro de información EjecutoresDeTareas tiene un nombre incorrecto; debería llamarse Ejecutor para reflejar su significado.

2.5. Recomendamos que no utilice nombres idénticos a los nombres de las tablas del lenguaje de consulta (Documento, Catálogo, RegistroDeInformación, etc.). Tales nombres pueden causar errores durante la ejecución de la consulta, dificultar el uso del generador de consultas y disminuir la claridad del texto de la consulta. Por ejemplo, esta consulta devuelve un error:

SELECT
Información.Información
FROM
RegistroDeInformación.Información AS Información

3.1. Especifique el Comentario solo cuando necesite dejar una nota sobre el objeto para otro desarrollador. Ejemplos de comentarios para un atributo de catálogo son “Se implementa la indexación para la optimización de informes filtrados por contraparte” y “Se utiliza en la contabilidad en moneda extranjera”.

3.2. Comience su comentario con mayúscula. Use puntos solo en abreviaturas.

Ver también

• Información y comprobaciones de llenado

• Atributo Comentario en documentos

Entrega de datos en paquetes de configuración

Este artículo describe los estándares que se aplican a los datos incluidos en el paquete de entrega de configuración. Todas las recomendaciones mencionadas son obligatorias a menos que se indique lo contrario.

Si desea incluir algunos datos en su paquete de entrega de configuración (por ejemplo, datos para llenar catálogos, configuraciones de informes, reglas de intercambio de datos, etc.), le recomendamos que utilice formatos diseñados para la transferencia de datos (como XML) y que utilice la plantilla “Documento de texto” o la plantilla “Datos binarios”.

No utilice la plantilla “Documento de hoja de cálculo” para incluir datos en un paquete de entrega de configuración.

Información y comprobaciones de llenado

Este artículo describe los estándares que se aplican a la redacción de información y al uso de la opción de comprobación de llenado. Todas las recomendaciones mencionadas son obligatorias a menos que se indique lo contrario.

1.1. Propiedad Información. Cada objeto de metadatos tipado (atributo de objeto, atributo de sección tabular, dimensión o recurso de registro) debe tener una información que explique el propósito del objeto a los usuarios finales.

Los atributos estándar Código, Descripción, Padre, Propietario y Período (para registros de información periódica) también deben tener información. Los demás atributos estándar generalmente no requieren información.

Mantenga la información limpia de mensajes “basura” como copias de objetos de metadatos o sinónimos de atributos. No se requiere información en los siguientes casos:

• El sinónimo del objeto o atributo explica claramente su propósito. Por ejemplo, el sinónimo del atributo NombreCompleto del catálogo Monedas explica claramente que el atributo almacena el nombre completo de la moneda.
• El valor del atributo nunca se verá ni se editará desde la interfaz de usuario (en particular, nunca estará disponible en los campos del formulario). Por lo tanto, nadie verá la información.

2.1. Propiedad Comprobación de llenado. Para todos los objetos de metadatos tipados, atributos estándar y secciones tabulares que deben llenarse según la lógica del objeto, establezca sus propiedades de “Comprobación de llenado” en “Mostrar error”.

En algunos casos, no tiene sentido contabilizar un documento con atributos o secciones tabulares vacías. Por ejemplo, un documento de Pedido de cliente representa la solicitud de un cliente para comprar una cierta cantidad de artículos. Un pedido sin clientes o una sección tabular de Artículos vacía no tiene sentido, por lo tanto, el campo Cliente y la sección tabular Artículos deben tener sus propiedades de “Comprobación de llenado” establecidas en “Mostrar error”.

2.2. Al especificar el valor “Verificar llenado”, recuerde que todas las limitaciones y verificaciones deben describirse de la manera más completa posible en los metadatos de la configuración. Por lo tanto, si al menos un escenario requiere llenar el atributo, establezca “Verificar llenado” en “Mostrar error”. Si otros escenarios no requieren llenar el atributo, refleje esto en el controlador de eventos del módulo de objeto FillCheckProcessing.

No utilice el método inverso cuando “Verificar llenado” se establece en “Sin verificación” y el controlador FillCheckProcessing incluye verificaciones de llenado adicionales. Esto dificulta el análisis de la lógica de la configuración.

2.3. Si la verificación de llenado es condicional, le recomendamos que utilice la apariencia condicional del formulario para alternar la propiedad “AutoMarkIncomplete”. Desactívela si el estado actual del objeto no requiere realizar verificaciones de llenado.

Ver también

• Nombre, sinónimo y comentario

Reflejar la naturaleza de los objetos de metadatos utilizando atributos

Este artículo describe los principios de reflejar los propósitos y funciones de las entidades de lógica empresarial en los objetos de metadatos y sus atributos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Al diseñar la estructura de la aplicación, utilice diferentes tipos de objetos para representar diferentes entidades. Por ejemplo, utilice el catálogo Empresas para empresas y el catálogo Departamentos para departamentos.

2. Para precisar el propósito del objeto, puede agregar atributos al objeto, de modo que su significado y comportamiento cambien según los valores de los atributos. Por ejemplo, el catálogo Empresas puede almacenar tanto empresas regulares como subsidiarias, y el catálogo Empleados puede almacenar tanto empleados actuales como antiguos.

Recomendamos que en estos casos cree atributos dedicados que identifiquen de manera única el tipo o estado del objeto. Pueden ser atributos Booleanos o enumeraciones que almacenen los tipos de objeto. No determine el tipo de objeto por características indirectas, en particular, verificando si alguno de sus atributos está lleno.

Incorrecto:

• El catálogo Empresas tiene un atributo EmpresaPadre, y el valor del atributo define si es una empresa regular o una subsidiaria.

Correcto:

• Además del atributo EmpresaPadre, el catálogo Empresas tiene un atributo Booleano Subsidiaria. El valor de este atributo (Verdadero o Falso) define explícitamente el tipo de empresa y si es necesario llenar el atributo EmpresaPadre.

3. Al mismo tiempo, si el catálogo Empleados tiene los atributos FechaContratación y FechaDespido, no es razonable agregar un par de atributos Booleanos Contratado y Despedido. Es una buena práctica crear un único atributo de enumeración para entidades que pueden tener múltiples estados. Por ejemplo, un atributo puede tener estados “trabaja” y “despedido”, y se pueden agregar más estados según sea necesario.

Manejo de objetos inactivos

Este artículo describe los estándares que se aplican a los objetos inactivos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

Procedure ChoiceDataGetProcessing(ChoiceData, Parameters, StandardProcessing)
 Si No Parameters.Filter.Property("Inactivo") Entonces
  Parameters.Filter.Insert("Inactivo", Falso);
 FinSi;
FinProcedure

Procedure FormGetProcessing(FormType, Parameters, SelectedForm,
                            AdditionalInformation, StandardProcessing)
 Si FormType = "ChoiceForm" Entonces 
  ParameterChanged = Falso;  
  Si No Parameters.Property("Filter") Entonces
   Parameters.Insert("Filter", New Structure("Inactivo", Falso));
   ParameterChanged = Verdadero;
  Sino Si No Parameters.Filter.Property("Inactivo") Entonces
   Parameters.Filter.Insert("Inactivo", Falso);
   ParameterChanged = Verdadero;
  FinSi;
  
  // Este código utiliza los valores de parámetro cambiados
  Si ParameterChanged Entonces  
   StandardProcessing = Falso;
   SelectedForm = "ChoiceForm"; // Pasando el nombre del formulario de selección
  FinSi;
 FinSi;
FinProcedure

Atributo de comentario de documentos

Este artículo describe los estándares que se aplican al atributo Comentario de los documentos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

Eliminación de objetos de metadatos obsoletos de las configuraciones

Este artículo describe los estándares que se aplican a la eliminación de objetos de metadatos obsoletos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Al cambiar la estructura de los metadatos de la configuración, al eliminar un objeto de metadatos (atributo, dimensión, recurso, etc.) relacionado con los datos de la base de datos de información, debe decidir si simplemente elimina sus datos o los migra a otras estructuras de datos. Recomendamos seguir estas recomendaciones al migrar los datos del objeto:

1.1. No elimine permanentemente los objetos y atributos de metadatos obsoletos. En su lugar, márquelos como obsoletos agregando el prefijo Eliminar a sus nombres. Ejemplo: cambie el nombre de AcuerdoPrincipal a EliminarAcuerdoPrincipal. Recomendamos agregar el prefijo (no utilizado) al sinónimo del objeto o atributo, por ejemplo: (no utilizado) Acuerdo principal. Si un atributo estándar se vuelve obsoleto, también agregue el prefijo (no utilizado) a su sinónimo.

1.2. Una vez que haya cambiado la estructura de los metadatos, transfiera los datos de los atributos obsoletos a la nueva estructura de metadatos. Si el objeto de metadatos que se va a eliminar es un documento que genera registros de registro y los registros relacionados no se eliminan junto con el documento, asegúrese de que los registros de registro se conserven. Recomendamos hacer lo siguiente para preservar los registros de registro generados por objetos de documento obsoletos:

• Deshabilite la generación de registros de registro para documentos de este tipo.
• Deshabilite la eliminación de marcas de eliminación para documentos de este tipo.
• Para todos los registros de registro generados por documentos de este tipo, reemplace el registrador por uno o varios documentos de reemplazo. Estos pueden ser documentos universales existentes o documentos desarrollados específicamente para fines de migración, por ejemplo, DataTransfer o Operation.
• Marque todos los documentos de este tipo para su eliminación.

1.3. Dado que el uso de objetos y atributos de metadatos obsoletos después de cambiar la estructura de metadatos no es un procedimiento adecuado, reemplace todas las apariciones de llamadas a objetos obsoletos llamando a los nuevos en toda la configuración.

1.4. Ordene los objetos y atributos de metadatos obsoletos en el árbol de metadatos según los requisitos comunes de la configuración.

Seguir estas reglas garantiza que los registros de la base de datos de información existentes ya no estén relacionados con objetos de metadatos obsoletos y evita la generación de nuevos registros de la base de datos de información relacionados con estos objetos.

2. Cuando se lance una nueva versión de la configuración, elimine permanentemente los objetos y atributos de metadatos obsoletos marcados con el prefijo Eliminar si se cumple al menos una de las siguientes condiciones:

• Los usuarios siempre realizan actualizaciones de configuración secuenciales, con una actualización obligatoria a la versión donde se implementa la transferencia de datos desde los objetos y atributos de metadatos obsoletos.

  Ejemplo: en la versión de configuración 1.1, el atributo MainAgreement está marcado como obsoleto. La actualización de la versión 1.0 a la versión 2.0 siempre es secuencial: primero, actualizar a la versión 1.1 y luego actualizar a la versión 2.0. Actualizar directamente de 1.0 a 2.0 es técnicamente imposible (esta opción no está disponible).

• Las posibilidades de que alguien todavía use la versión antigua de la configuración son insignificantes.

Autosuficiencia de registros

Este artículo describe los estándares que se aplican a la estructura del registro. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

Al desarrollar la estructura del registro, recuerde que el registro debe mantenerse lógicamente independiente de los registradores. Cualquier lógica basada en los datos del registro y cualquier informe sobre el registro no debe acceder a los campos del registrador; todos los datos requeridos deben estar ubicados en el propio registro.

Acceder a los campos del registro utilizando . (punto) conduce a conexiones implícitas con tablas adicionales. Además, una base de datos distribuida podría no tener un registrador si los registros del registro se transfieren entre nodos pero los registradores no lo hacen.

Principios de almacenamiento de datos genéricos

Este artículo proporciona pautas para elegir los tipos de objetos de metadatos óptimos para almacenar datos en su configuración.

1. En la etapa de diseño de la solución, es muy importante seleccionar correctamente los tipos de objetos de metadatos que almacenarán los datos comerciales. Elecciones incorrectas pueden afectar la eficiencia de la solución aplicada y las opciones de desarrollo futuro, y dificultar la adaptación a posibles cambios en las tareas comerciales cubiertas por la solución aplicada.

2. Recomendamos que elija los tipos de objetos de metadatos en función del siguiente diagrama:

* Las flechas representan dependencias de datos (referencias cruzadas).

El diagrama contiene los siguientes bloques:

1. Datos convencionalmente estáticos. Esto incluye datos que se ingresan normalmente una vez, rara vez se cambian y se acceden regularmente. Ejemplos: clasificadores, configuraciones, listas, registros y regulaciones.

2. Eventos relacionados con procesos comerciales, que tienen marcas de tiempo y pueden generar o modificar datos al registrarse. Ejemplos: flujo de documentos de la empresa, contabilidad, registro de pedidos o llamadas.

3. Datos recopilados e indicadores comerciales, que describen el estado actual del área de aplicación y los procesos actuales. A diferencia de los datos descritos en los párrafos 1 y 2, estos datos no tienen naturaleza de objeto y no describen entidades independientes que pertenecen al área de aplicación. Ejemplos: historial de ventas de artículos, saldos de almacén, saldos de cuentas actuales, historial de tipos de cambio de divisas.

El último bloque representa herramientas de análisis, procesamiento e informes de datos. Utilizan datos de los otros bloques pero no almacenan datos ellos mismos.

2.1. Por lo tanto, debe asignar cada entidad del área comercial a uno de estos bloques según el siguiente algoritmo:

• Si necesita almacenar datos que rara vez cambian y no tienen marcas de tiempo, use el bloque de datos convencionalmente estáticos (1).

• Si necesita registrar eventos documentados que tienen marcas de tiempo, use el bloque de eventos relacionados con procesos comerciales (2).

• De lo contrario, use el bloque de datos recopilados e indicadores comerciales (3).

Criterios detallados de selección de bloques:

2.2. Luego seleccione un tipo de objeto de metadatos específico dentro del bloque seleccionado:

2.2.1. Para datos convencionalmente estáticos:

1. Para almacenar un plan de cuentas para contabilidad de doble entrada, utilice el objeto de metadatos Plan de cuentas.
2. Para almacenar un plan de tipos de cálculo para calcular devengos y retenciones, utilice el objeto de metadatos Plan de tipos de cálculo.
3. Para almacenar un valor único que puede ser editado por los usuarios (generalmente por el administrador que realiza la configuración del sistema) y no requiere referencias de otros datos, utilice el objeto de metadatos Constante.
4. Para definir una lista fija de valores que no pueden ser editados por los usuarios y no tienen atributos adicionales, utilice el objeto de metadatos Enumeración.
5. Para almacenar la lista de características (propiedades) donde tanto los tipos de características como su contenido son definidos por los usuarios, utilice el objeto de metadatos Plan de tipos de características.
6. En la mayoría de los otros casos, puede utilizar el objeto de metadatos Catálogo.

Criterios detallados para la selección de objetos de metadatos:

2.2.2. Para eventos relacionados con procesos comerciales:

1. Para registrar eventos únicos que tienen ejecutores (usuarios, empleados, grupos o roles) y no requieren publicación una vez que se completan, use el objeto de metadatos Tarea.
2. Para registrar la creación y el progreso de un proceso repetido que se puede dividir en un conjunto de acciones (eventos), use el objeto de metadatos Proceso comercial. Para registrar acciones (eventos) que forman un proceso, use el objeto de metadatos Tarea.
3. En la mayoría de los otros casos, puede usar el objeto de metadatos Documento.

Criterios detallados para la selección de objetos de metadatos:

2.2.3. Para datos recopilados e indicadores comerciales:

1. Para almacenar datos contables para la contabilidad de partida doble, use el objeto de metadatos Registro de Contabilidad.
2. Para almacenar acumulaciones y retenciones calculadas, use el objeto de metadatos Registro de Cálculo.
3. Para almacenar el historial de cambios de indicadores (ingresos y gastos, giros y saldos para un período específico), use el objeto de metadatos Registro de Acumulación.
4. En la mayoría de los otros casos, puede usar el objeto de metadatos Registro de Información.

Criterios detallados para la selección de objetos de metadatos:

3. Ejemplo de selección de tipo de objeto de metadatos:

Una empresa ofrece servicios de encuestas. Cada cuestionario incluye una fecha y un conjunto de preguntas, un cuestionario completado también incluye un conjunto de respuestas. La entidad “cuestionario” tiene una marca de tiempo y genera datos estadísticos (las respuestas).

Utilicemos el algoritmo descrito en este artículo:

• Completar un cuestionario es un evento que tiene una marca de tiempo y genera valores de parámetros. Pertenece al segundo bloque: eventos relacionados con procesos comerciales.
• Según la tabla que describe este bloque, un cuestionario que genera datos (las respuestas) está representado por un objeto Documento.

Usando elementos predefinidos

Estas recomendaciones se aplican a 1C:Enterprise versión 8.3.3 o posterior (excepto configuraciones donde el modo de compatibilidad está configurado en Versión 8.2 o anterior). Son obligatorias a menos que se indique lo contrario.

1.1. Tiene la opción de crear elementos predefinidos en catálogos, planes de cuentas y planes de tipos de cálculo, tanto automáticamente como mediante script de 1C:Enterprise.

1.2. En la mayoría de los escenarios recomendamos que los elementos predefinidos se creen automáticamente porque se necesitan en todo momento y porque esto simplifica su llamada desde el script de 1C:Enterprise. Ejemplos de tales escenarios son el elemento predefinido USA en el catálogo Países y el perfil de grupo de acceso predefinido Administrador.

Para la creación automática, haga lo siguiente:

• Establezca el valor de la propiedad PredefinedDataUpdate del catálogo, plan de cuentas o plan de tipos de cálculo en Auto (valor predeterminado) y asegúrese de nunca llamar al método SetPredefinedDataUpdate para esos objetos (este método establece el valor de la propiedad).
• Asegúrese de que los usuarios no puedan eliminar elementos predefinidos deshabilitando los siguientes derechos para todos los usuarios (estos derechos están deshabilitados de forma predeterminada):  
  • Eliminación interactiva de objetos predefinidos
  • Marca de eliminación interactiva en objetos predefinidos
  • Eliminación interactiva de la marca de eliminación de objetos predefinidos 
  • Eliminación interactiva de objetos predefinidos marcados

1.3. Los nodos subordinados de las bases de datos distribuidas son una excepción a esta regla. En tales nodos no se deben crear ni actualizar elementos predefinidos automáticamente. En su lugar, deben replicarse desde el nodo principal junto con los cambios de configuración.

En este caso, asegúrese de lo siguiente:

a) La configuración carga un mensaje de intercambio a un nodo subordinado antes de la ejecución del script que accede a los elementos predefinidos recuperados del nodo principal.

b) La lógica aplicada de carga de datos desde el nodo principal (por ejemplo, el controlador OnReceiveDataFromMaster y las reglas de registro de objetos) no incluye el acceso a los elementos predefinidos porque no se puede asegurar que ya se hayan cargado desde el mensaje de intercambio.

c) El script del controlador de actualización de la base de datos que procesa los elementos predefinidos no se ejecuta en los nodos de la base de datos subordinados:

If ExchangePlans.MasterNode() = Undefined Then
    // llenar elementos predefinidos
    // …
EndIf;

1.4. Recomendamos que para las tablas con elementos predefinidos que no están incluidos en el plan de intercambio de la base de datos distribuida (y no son referenciados por otras tablas incluidas en el plan de intercambio) se establezca la propiedad PredefinedDataUpdate en AutoUpdate.

Si utiliza el modo de compatibilidad con la versión 8.3.3, en el primer inicio de un nodo subordinado (justo después de su actualización de configuración) establezca la actualización automática de datos utilizando el siguiente script:

Catalogs.<CatalogName>.SetPredefinedDataUpdate(PredefinedDataUpdate.AutoUpdate);

2. En algunos casos no es necesario crear automáticamente elementos predefinidos. Esto incluye casos en los que la disponibilidad de elementos predefinidos depende de alguna condición (valores de opciones funcionales, modo de aplicación, etc.).

Por ejemplo, la disponibilidad de elementos predefinidos en el gráfico de tipos de cálculo de Acumulaciones puede depender de los valores de las siguientes opciones funcionales: UseHourlyWorkTimeRecords, UsePieceworkWages, etc.

Si este es el caso, haga lo siguiente:

• Establezca la propiedad PredefinedDataUpdate de un catálogo, gráfico de cuentas o gráfico de tipos de características en No actualizar automáticamente.
• Escriba el script que crea elementos predefinidos dependiendo de la lógica empresarial (y los marca como inactivos), por ejemplo:

Si GetFunctionalOption(“UseHourlyWorkTimeRecords”) Then
    AccrualObject = ChartsOfCalculationTypes.Accruals.CreateCalculationType();
    AccrualObject.PredefinedDataName = “HourlyPayment”;
    // …
    AccrualObject.Write();
EndIf;

• Cuando escriba algoritmos de script, tenga en cuenta que los elementos predefinidos pueden no estar disponibles (acceder a un elemento no disponible genera una excepción):

  … = ChartOfCalculationTypes.Accruals.HourlyPayment;
  … = PredefinedValue(“ChartOfCalculationTypes.Accruals.HourlyPayment”);

Uso de la propiedad Activo de los registros de registro

Este artículo describe los estándares que se aplican al establecer la propiedad Activo de los registros de registro. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

Si su configuración incluye funcionalidad que cambia la propiedad Activo de los registros de registro (por ejemplo, puede usar esto para la corrección manual de registros), recomendamos lo siguiente:

1. Todas las consultas a los registros de registro y los informes basados en esos registros deben tener en cuenta el valor de la propiedad Activo. Utilice la siguiente condición para filtrar los registros inactivos:

WHERE Activo = TRUE

Si su consulta selecciona registros de tablas virtuales vinculadas a registros de registro, 1C:Enterprise siempre recupera solo registros activos (porque las tablas de registro virtuales solo contienen registros activos).

2. En particular, la propiedad Activo de los registros de registro debe tenerse en cuenta en informes universales (y en la lógica empresarial universal en general) que utilizan datos de varios registros de configuración porque esos registros pueden almacenar registros inactivos.

3. Cuando se desanota un documento que permite la corrección manual de registros de registro, no elimine sus registros, haga que sean inactivos en su lugar. Ejemplo de dicho documento es la Entrada de Libro Mayor (este documento está destinado para la adición manual de entradas de libro mayor).

Véase también:

• Requisitos de publicación de documentos
• Escritura de registros de registro

Requisitos de publicación de documentos

Este artículo describe los estándares que se aplican a la publicación de documentos. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

1. Los documentos están destinados a ingresar datos fuente relacionados con eventos que afectan los registros contables. Por ejemplo, en la automatización de la actividad empresarial esto incluye registros de contabilidad de la actividad empresarial, mientras que en la automatización de la actividad de fabricación esto incluye registros de fabricación.

2.1. Registrar un evento (agregar sus datos a los registros contables) se realiza mediante la publicación de un documento. La mayoría de los documentos deben ser publicados (su propiedad Publicación debe establecerse en Habilitar).

Desde el punto de vista lógico, un documento no contabilizado es un “borrador” que no afecta los registros contables. Dichos documentos se pueden guardar incluso si no están completamente llenos o no están llenos en absoluto, no están sujetos a ninguna verificación o restricción de lógica empresarial (como verificaciones de llenado o restricciones de cambio de fecha). Sus datos no se incluyen en los informes.

Y un documento contabilizado es uno aprobado, está completamente lleno, procesado e incluido en los registros contables.

2.2. Si el ciclo de vida de un documento incluye varias etapas de procesamiento, se pueden crear estados de documento adicionales para reflejar estas etapas. Por ejemplo, un documento de Pedido de Cliente puede tener los siguientes estados: “abierto”, “pendiente” y “cerrado”. Un documento de Factura puede tener los siguientes estados: “abierto”, “facturado” y “pagado”.

En estos escenarios, la primera contabilización crea un registro contable inicial, mientras que los estados del documento afectan los detalles del registro.

Si un documento está contabilizado, cambiar su estado puede requerir llenar datos específicos del documento y pueden aplicarse verificaciones de llenado y restricciones de lógica empresarial específicas del estado. Si un documento aún no está contabilizado, el sistema no realiza ninguna verificación específica del estado y no aplica ninguna restricción.

Ejemplos de comportamiento de documento específico del estado:

• Un Pedido de Cliente contabilizado en el estado “abierto” no crea registros de registro adicionales.
• Un Pedido de Cliente contabilizado en el estado “pendiente” escribe registros de registro que almacenan la cantidad de bienes que aún deben entregarse.
• Un Borrador de Factura en el estado “abierto” no requiere llenar el campo “Fecha de vencimiento”.
• Una Factura contabilizada en el estado “facturado” requiere llenar el campo “Fecha de vencimiento”.

2.3. Los siguientes documentos son excepciones a la regla de “La mayoría de los documentos deben ser contabilizados”:

• Documentos que no están destinados a generar registros contables. Estos son documentos que registran eventos con marcas de tiempo: mensajes entrantes, llamadas, reuniones, etc.
• Documentos cuyo procedimiento de contabilización es muy diferente del procedimiento de contabilización estándar de 1C:Enterprise, pero desde la perspectiva del usuario esto debería parecer una contabilización estándar. Ejemplos de tales documentos son Entrada de Libro Mayor (este documento está destinado a la adición manual de entradas de libro mayor) y Ajuste Manual (este documento está destinado a correcciones manuales de registros contables y solo está disponible durante las pruebas de la solución aplicada).

Tales documentos nunca se contabilizan.

2.4. Cuando un usuario necesita registrar un evento y generar los registros contables correspondientes en una sola operación, debe crear un documento y guardarlo en modo de contabilización.

No se permite implementar esto de otra manera. En particular, no se permite desactivar la contabilización.

3.1. Para reflejar un evento en los registros contables, es posible que deba generar datos “secundarios” que tengan relaciones complejas con puntos en el tiempo, períodos u otros objetos del sistema. Estos datos deben almacenarse en registros. Los registros de registro deben generarse durante la contabilización (automáticamente o manualmente).

Si selecciona la generación automática de registros de registro, los usuarios registran los datos del evento en el documento y los registros de registro se generan durante la contabilización del documento. Por ejemplo, las transacciones contables generan registros de registro automáticamente.

Si selecciona la generación manual de registros de registro, los usuarios pueden registrar datos directamente en los registros utilizando documentos denominados operaciones manuales. Pueden usarlos para ingresar saldos iniciales o para registrar actividades comerciales que no se pueden describir mediante documentos de actividad comercial estándar disponibles en la configuración.

3.2. En casos raros, puede utilizar un documento separado para generar registros de registro. Esto tiene sentido en escenarios donde varios tipos de documentos requieren un procesamiento similar, se involucra el procesamiento masivo de documentos o partes de procesos comerciales complejos requieren diferentes derechos de usuario. En estos escenarios, una serie de eventos se puede implementar como una cadena de documentos, un documento basado en otro, en lugar de un solo documento que cambia de estado. Algunas partes de la cadena de documentos pueden no requerir contabilización.

Por ejemplo, se crea un Pedido de Cliente en el departamento de Ventas y no se puede cambiar durante la contabilización. En este escenario, el Pedido de Cliente es creado por un vendedor y nunca se contabiliza, mientras que un especialista en logística verifica que la cantidad solicitada de bienes esté disponible y crea el documento de Envío, que está destinado a generar registros de registro y se basa en el documento de Pedido de Cliente.

3.3. Los documentos no contabilizados y los documentos marcados para eliminación no deben tener registros activos.

3.4. Incluso si un documento no genera registros de registro, su publicación aún debe estar habilitada. Esto es necesario para hacer una diferencia visual entre los documentos en borrador y los documentos aprobados.

4. En la mayoría de los escenarios, se puede deshacer la grabación de datos contables (utilice la función de deshacer publicación proporcionada por la plataforma).

Ver también:

• Nombres de objetos de metadatos en configuraciones
• https://1ci.zendesk.com/hc/es/articles/360007971773Uso de la propiedad Activo de los registros de registro
• Autosuficiencia de los registros de registro

Limitaciones para el uso de atributos de tipo compuesto

Este artículo describe los estándares que se aplican al uso de atributos de tipo compuesto. Todas las recomendaciones enumeradas son obligatorias a menos que se indique lo contrario.

2.1. No utilice AnyRef, CatalogRef, DocumentRef y tipos compuestos similares para objetos de metadatos almacenados en la infobase. Especifique los tipos de objetos explícitamente.

Las excepciones a esta regla son los algoritmos universales destinados al procesamiento de objetos de referencia de varios tipos.

2.2. Si un tipo compuesto se utiliza ampliamente en objetos pertenecientes a un subsistema específico o en toda la configuración, recomendamos que utilice tipos definidos.