---

   

Objetos aplicados

• Cuándo usar referencias, consultas, selecciones y objetos
• Eliminación directa de objetos sin marcas de eliminación y verificación de integridad de referencia
• Uso del campo DeletionMark de un objeto de base de datos
• Uso del campo Posted y el proceso de publicación
• Uso de tipos de datos para manipular objetos de base de datos
• Uso de tipos para manipular datos no objeto
• Desarrollo de una estructura de registro de información periódica
• Uso de herramientas de script para trabajar con objetos aplicados
• Consejos para elegir entre un catálogo subordinado y una sección tabular
• Datos predefinidos: solución de problemas
• Numeración automática
• Numeración automática para colaboración
• Uso de tipos de características para implementar el almacenamiento de valores relacionados con objetos de la base de datos
• Secuencias de documentos

Cuándo usar referencias, consultas, selecciones y objetos

1C:Enterprise 8 proporciona varios métodos para obtener datos. Las referencias, consultas, selecciones y objetos se pueden utilizar para leer datos de entidades de objetos (es decir, catálogos, documentos, etc.). Para obtener una descripción detallada de las diferencias entre una referencia, selección y objeto, consulte la sección Uso de tipos de datos para manipular objetos de base de datos. Este artículo contiene recomendaciones sobre cómo elegir el método de acceso a los datos.

Por lo general, una consulta es la forma más eficiente de leer datos. Especifica explícitamente cómo seleccionar registros y qué campos deben leerse. Por lo tanto, cuando se ejecuta una consulta, solo se seleccionarán los datos que se requieren de una base de datos y se transferirán a la computadora del cliente. Si utiliza consultas, no es necesario leer campos y secciones tabulares que no se requieren en su caso específico.

Otra ventaja de una consulta es la capacidad de leer todos los datos requeridos de varias tablas interconectadas a la vez. Por lo tanto, si necesita leer datos de varios objetos u obtener datos de otras tablas conectadas con los objetos, el uso de consultas sería más eficiente que realizar varias llamadas a diferentes datos. Tenga en cuenta que desde el punto de vista del rendimiento, también es importante el número de llamadas a la base de datos, no solo el volumen de datos que se lee, ya que cada llamada se suma a los costos generales.

Sin embargo, la consulta leerá datos de una base de datos con cada llamada. Por lo tanto, si llama a los mismos datos varias veces, se leerán varias veces. Puede evitar esto llamando a propiedades de referencia. En este caso, se utiliza el almacenamiento en caché de objetos y no se realizará una lectura repetida si se llama repetidamente a los datos del objeto dentro de un período de tiempo definido. Sin embargo, debe tenerse en cuenta que cuando se llama a cualquier campo a través de una referencia, se lee el objeto completo (incluidos todos los campos y todas las secciones tabulares). Por lo tanto, una referencia se puede utilizar para múltiples llamadas si la lectura del objeto completo no puede ralentizar significativamente la ejecución. Por ejemplo, si desea obtener la propiedad Publicado de un documento a través de una referencia, se leerá el documento completo (incluida su sección tabular). Si una sección tabular de un documento puede contener varias cientos de filas, es mejor utilizar una consulta.

Por supuesto, si necesita llamar al mismo campo dentro del mismo algoritmo varias veces, es mejor leer los datos, almacenarlos en la memoria como una variable y llamar a los datos ya leídos. Sin embargo, si obtiene datos a través de una referencia, el sistema puede mostrar los datos que ya se han leído anteriormente, incluso si se leyeron en otra llamada desde el script de 1C:Enterprise, ya que los datos se almacenan en caché para toda la sesión del cliente.

También vale la pena mencionar la opción de almacenamiento en caché de presentaciones. Si, por ejemplo, necesita obtener una presentación de un elemento de catálogo, es mejor transformar una referencia en una cadena en lugar de llamar al nombre a través de una referencia. En este caso, se utilizará una función especial para obtener presentaciones (como en el caso del almacenamiento en caché) y, si la presentación del objeto aún no está en caché, no se leerá el objeto completo: en su lugar, solo se leerán los campos necesarios para obtener la presentación.

Si necesita obtener una lista de objetos para mostrar en la pantalla o enviar a imprimir, es mejor utilizar el objeto Consulta para crear una presentación en lugar de esperar que la presentación se cree automáticamente cuando una referencia se transforma en una cadena. Por ejemplo, si imprime un informe de ventas en un documento de hoja de cálculo, es muy fácil ralentizar enormemente el rendimiento si imprime referencias a productos en su documento. El informe será correcto ya que el sistema transforma automáticamente las referencias en cadenas. Sin embargo, si tiene varias cientos o miles de cadenas, esto puede ralentizar enormemente el proceso de creación del informe. En este escenario, recomendamos que obtenga las presentaciones directamente en la consulta e incluya las presentaciones obtenidas en un documento de hoja de cálculo como cadenas.

Un caso similar es cuando necesita mostrar los resultados de una consulta en el formulario mediante la volcado de datos a una tabla de valores o un árbol de valores. Si las celdas de una tabla muestran columnas con referencias, esto puede ralentizar la visualización de una tabla de valores en escenarios de múltiples usuarios. Esto también afectará negativamente la experiencia del usuario individual y el funcionamiento del sistema en su conjunto. Recomendamos que obtenga tanto las referencias como sus presentaciones con la ayuda de una consulta y que los datos se muestren en una tabla de tal manera que el texto de la celda se tome de las columnas que contienen solo tipos primitivos.

Sin embargo, tenga en cuenta lo siguiente: cuando un usuario ve una tabla de valores, las presentaciones de referencia se llaman a medida que se muestran las filas; y cuando se utiliza una consulta para obtener presentaciones, estas se obtendrán para todas las filas a la vez. Al mismo tiempo, si busca a través de una tabla de valores, se seleccionarán las presentaciones de todas las filas (por separado), lo cual es mucho menos productivo que obtener estas presentaciones con una consulta.

Cuando se procesa información (por ejemplo, cuando se publica un documento), recomendamos que utilice consultas para obtener campos de objetos en lugar de llamar a un gran número de objetos a través de referencias. Por ejemplo, si necesita obtener un atributo específico para todos los productos de la sección tabular del documento, es mejor ejecutar una consulta a través de la sección tabular y obtener este atributo para cada producto, en lugar de iterar a través de esta sección tabular y obtener un atributo para cada producto a través de una referencia.

Si utiliza una consulta, todos los datos que se leen se almacenan en la memoria RAM del equipo cliente. Si necesita procesar grandes volúmenes de datos, es mejor utilizar selecciones. Una selección no proporciona la flexibilidad para filtrar y ordenar información y lee todos los campos y secciones tabulares de los objetos. Sin embargo, lee los datos en porciones y, por lo tanto, se puede utilizar para procesar cualquier volumen de datos sin almacenarlos en la memoria RAM.

Cuando se obtienen objetos de una selección, no se vuelven a leer. Por eso, si necesita realizar modificaciones masivas de objetos, utilizar selecciones es más eficiente que leer referencias con una consulta y obtener objetos para cada referencia.

En lo que respecta a la búsqueda de objetos (búsqueda de referencias a objetos) con condiciones simples (por código, nombre, etc.), la implementación de la búsqueda utilizando consultas y métodos del administrador de objetos (FindByCode() y otros) no difiere mucho desde el punto de vista de la plataforma. Utilice los administradores para realizar operaciones de búsqueda individuales. La principal ventaja de los administradores es que se pueden escribir de forma muy breve en un módulo. Utilice consultas si necesita buscar con condiciones complejas o buscar varios objetos.

Eliminación directa de objetos sin marcas de eliminación y verificación de integridad de referencia

1C:Enterprise proporciona una función de verificación de integridad de referencia para eliminar objetos en dos etapas: primero, estableciendo una marca de eliminación y luego eliminando el objeto con verificación de integridad de referencia. Sin embargo, esta es una función de servicio y no es obligatorio utilizarla.

Las referencias a objetos que no existen no son un error desde la perspectiva de la plataforma. Por ejemplo, incluso si utiliza la función de verificación de integridad de referencia para objetos de base de datos, se pueden obtener referencias a objetos eliminados a partir de los valores guardados de la configuración de informe.

Puede utilizar las herramientas de script de 1C:Enterprise para marcar un objeto para su eliminación o eliminarlo directamente, sin una verificación de integridad de referencia. Por lo tanto, la experiencia interactiva del usuario admite tanto la marca de eliminación como las opciones de eliminación directa.

Para evitar errores, la acción estándar llamada desde la lista cuando se presiona la tecla Eliminar adjunta una marca de eliminación, mientras que Shift+Eliminar elimina directamente el objeto.

Para prohibir que un usuario final realice una eliminación directa, deshabilite el derecho de “Eliminación interactiva” para los objetos de configuración correspondientes. Tenga en cuenta que este derecho, al igual que todos los demás, está habilitado de forma predeterminada.

Por lo tanto, la opción de eliminación directa (sin verificación de integridad de referencia) debe ser introducida por el desarrollador de la configuración al establecer roles y por el administrador al asignar roles a los usuarios. En la mayoría de los casos, es una buena idea prohibir la eliminación interactiva por parte de los usuarios y así garantizar la integridad de referencia en todo momento. Sin embargo, la eliminación directa puede ser útil en algunos casos. Por ejemplo, puede habilitarla para los miembros del personal responsables de la población inicial de una base de datos de información (antes de que el sistema se ponga en funcionamiento) o para objetos que no son referenciados por otros objetos de configuración.

Uso del campo DeletionMark de un objeto de base de datos

Los objetos de base de datos de 1C:Enterprise contienen el campo DeletionMark. Este campo se utiliza cuando se eliminan objetos con control de integridad de referencia. Esta función ayuda a evitar la eliminación de un objeto por parte de un usuario si el objeto está referenciado desde otros datos almacenados en la base de datos.

Desde el punto de vista de la plataforma, la eliminación directa, es decir, la eliminación sin control de integridad de referencia, es posible, y la presencia de referencias a objetos faltantes en una base de datos no es un error. El alcance de uso de esta función está definido por el desarrollador de la configuración y el administrador. El desarrollador de la configuración puede controlar si los usuarios pueden llamar a la eliminación directa de ciertos tipos de objetos con la ayuda de la regla Eliminación interactiva. Por ejemplo, puede deshabilitar la eliminación directa para todos los usuarios o habilitarla para algunos usuarios. Este derecho solo influye en acciones interactivas llamadas con comandos del sistema estándar. Si se elimina un objeto utilizando las herramientas de script de 1C:Enterprise, puede verificar este derecho dentro del módulo. Por supuesto, la eliminación directa también es posible en algunos escenarios, si esto está en línea con la lógica de la tarea a resolver. Este es el caso cuando se eliminan datos en masa con un procesador de datos programado. En este caso, no se realiza la verificación de los derechos de usuario.

La eliminación con control de integridad de referencia es un servicio separado que, sin embargo, no afecta a otras características del sistema. Una marca de eliminación solo muestra que el usuario va a eliminar el objeto. El campo DeletionMark en 1C:Enterprise no difiere de otros campos del sistema de un objeto en su comportamiento. Se puede establecer asignando un valor a una propiedad del objeto, y el objeto se marcará para su eliminación después de que se escriba en el sistema.

También puedes usar el método SetDeletionMark() en lugar de establecer una marca de eliminación asignando directamente un valor a la propiedad del objeto y escribiendo este objeto. Este método establece la propiedad al valor especificado en el parámetro, escribe el objeto y realiza otras acciones adicionales dependiendo del tipo de objeto. Por ejemplo, un documento publicado se despublica, mientras que todos los elementos subordinados de un catálogo y los catálogos subordinados en un catálogo dado se marcan para su eliminación. Cuando un usuario establece la marca de eliminación utilizando un comando de interfaz de usuario, se realizan las acciones incluidas en este método. Sin embargo, cabe destacar que estas acciones son solo una forma estándar recomendada para establecer marcas de eliminación. No son obligatorias. Si se establece una marca de eliminación asignando un valor de propiedad y escribiendo un objeto, no se realizan acciones adicionales. Por lo tanto, el desarrollador puede implementar la configuración de una marca de eliminación sin ninguna acción adicional si es necesario.

Una marca de eliminación es un campo cuyo valor se utiliza durante la eliminación con control de integridad de referencia, pero establecer y eliminar una marca de eliminación no es un proceso separado y dedicado desde el punto de vista del objeto. Por eso no hay un controlador especial que acompañe al establecimiento y eliminación de esa marca. Al igual que para cualquier otro campo de un objeto, el valor del campo DeletionMark se puede analizar en los controladores BeforeWrite() y OnWrite() para realizar ciertas comprobaciones u otras acciones. Si solo necesita analizar el valor escrito, es suficiente con verificar el valor del campo. Si necesita determinar si se escribió el valor cambiado, debe leer el valor de este campo de una base de datos y comparar el valor obtenido con el actual en el controlador BeforeWrite().

Tenga en cuenta que las extensiones de campo tabular contienen los eventos BeforeSetDeletionMark. Sin embargo, estos eventos solo acompañan la llamada de marca de eliminación con la ayuda de un comando estándar. Por eso, estos eventos solo se pueden utilizar para manejar la llamada interactiva de una marca de eliminación en formularios específicos. Si necesita manejar tareas comunes que incluyan el control de este valor de campo o realizar cualquier acción relacionada con la marca de eliminación, utilice los eventos del propio objeto.

Si el documento está marcado para su eliminación, este documento no se puede publicar. Sin embargo, un documento marcado para su eliminación puede tener registros de registro, ya que el concepto de publicación en 1C:Enterprise no está estrictamente relacionado con esos registros. Por ejemplo, esto se utiliza para documentos destinados a la edición manual de registros de registro. Si dichos documentos están marcados para su eliminación, no se deben eliminar registros de registro en ellos, ya que el usuario puede eliminar una marca de eliminación y los registros no se perderán. Puede utilizar herramientas de script de 1C:Enterprise en la configuración para desactivar la actividad de los registros de registro cuando se establece una marca de eliminación para dicho documento. Esta sería un enfoque metodológico que combina una marca de eliminación y la desactivación de la actividad de los registros de registro.

Uso del campo Publicado y el proceso de publicación

Los documentos de 1C:Enterprise 8 admiten la función de publicación, que se implementa a nivel metodológico del sistema. Refleja eventos comerciales descritos en el documento en los registros contables del sistema. El mecanismo de publicación minimiza el esfuerzo requerido por el desarrollador en escenarios estándar y al mismo tiempo proporciona la flexibilidad para cambiar la metodología estándar.

Esta función proporciona un atributo especial del documento que muestra que está publicado, y también hay procesos de publicación y despublicación.

El atributo es el campo de sistema Publicado. El objetivo principal de este campo es distinguir los documentos que ya se reflejan en el sistema contable de los documentos que se han guardado pero aún no deben afectar ningún registro contable. Estos documentos son una especie de “borradores”. Por ejemplo, un operador aún no ha ingresado todos los datos requeridos pero necesita salir del programa por alguna razón. Puede escribir el documento sin publicarlo y volver a él más tarde. Los documentos que están publicados y no publicados se muestran en la lista de documentos con diferentes iconos.

Publicación y despublicación en 1C:Enterprise 8 son instancias particulares de un escenario de escritura de documentos. El atributo que muestra si se debe aplicar la publicación o despublicación al escribir un documento se establece en los parámetros de la llamada al método Write(). Por lo tanto, el documento se puede escribir de la manera habitual, publicar o despublicar. Si un documento se publica, se establece Verdadero en el campo Publicado, y se llama al controlador Publicación() además de las acciones regulares realizadas durante la escritura. Si un documento se despublica, se llama al controlador Despublicación() y se establece Falso en el campo Publicado.

El uso del campo Publicado y el proceso de publicación es solo una metodología propuesta por el sistema.

Puede cambiar el valor en el campo Publicado sin publicar o despublicar el documento. Todo lo que tiene que hacer es cambiar el valor del campo y escribir un documento. Esto puede resultar en un documento despublicado con registros. Tenga en cuenta que si se cambia el campo Publicado de esta manera, no se llamarán los controladores Publicación() y Despublicación(). Estos controladores acompañan a los procesos de publicación y despublicación iniciados explícitamente, y no al hecho de que se haya cambiado el campo Publicado.

Los registros del documento se pueden crear fuera de la publicación del documento. Además, pueden ser creados por un objeto distinto al documento. Para ello, todo lo que tiene que hacer es escribir un conjunto de registros de registro con un filtro por este documento.

Esta metodología predeterminada es la forma más sencilla de gestionar un documento y sus registros en el escenario en el que un documento contiene información sobre un determinado evento que tuvo lugar en la empresa, y los registros reflejan estos eventos en varios registros contables. Si la propiedad RegisterRecordsDeletion se establece en AutoDelete en los metadatos del documento, los registros existentes se eliminan automáticamente antes de la publicación o durante la despublicación. Por lo tanto, si se utiliza una metodología estándar, el desarrollador solo necesita implementar la creación de nuevos registros en el controlador Publicación().

Por otro lado, la flexibilidad del campo Publicado y el proceso de publicación permite implementar escenarios de publicación más complejos si es necesario. Por ejemplo, puede crear un documento en el que algunos registros se creen en el proceso de publicación y otros sean ingresados manualmente por el usuario.

El campo Publicado y el proceso de publicación solo tienen sentido para los documentos que se pueden publicar (aquellos que tienen la propiedad Publicar en los metadatos establecida en Habilitar). Algunos documentos nunca deben ser publicados. Tienen la propiedad Publicar establecida en Deshabilitar en los metadatos. Estos son, por ejemplo, documentos que no afectan los registros contables de ninguna manera. Además, los documentos destinados a la entrada manual de registros tampoco deben ser publicados. Estos documentos tendrán registros, pero no es necesario dividir dichos documentos en publicados y despublicados. Esto se debe al hecho de que toda la información (atributos y registros) se ingresa cuando se ingresa el documento, sin distinguir entre la información inicial y la obtenida durante la publicación.

Tenga en cuenta que los documentos que no deben ser publicados tienen un icono similar al de un documento publicado en la lista de documentos. Esto se debe a que el usuario debe primero notar los documentos que deben ser publicados pero aún no se han publicado. Es menos importante diferenciar los documentos que no deben ser publicados de aquellos que ya han sido publicados.

Uso de tipos de datos para manipular objetos de base de datos

El modelo 1C:Enterprise para el desarrollo de soluciones aplicadas utiliza un enfoque basado en objetos para la manipulación de datos para algunas entidades de un área temática. Estas entidades se describen en la configuración con la ayuda de los siguientes objetos de metadatos: Catálogo, Documento, PlanDeTiposDeCaracterísticas, PlanDeCuentas y PlanDeTiposDeCálculo. Desde el punto de vista del modelo de datos 1C:Enterprise, una base de datos almacena objetos para estas entidades. Por supuesto, el lenguaje de consulta proporciona acceso a estas entidades, así como a cualquier otro dato, a través del modelo de tablas relacionales. Sin embargo, el acceso con objetos de script especializados destinados a manipular dichos datos se proporciona a través de una metodología basada en objetos.

Veamos los tipos utilizados para manipular estas entidades en la configuración. Revisaremos los tipos y su uso con el ejemplo de un catálogo. Se utiliza una estructura de tipos similares para los otros objetos de metadatos mencionados.

El tipo CatalogsManager está destinado a acceder a los administradores de catálogos específicos. Además, proporciona el método AllRefsType() para obtener el valor TypeDescription que contiene los tipos de referencia de todos los catálogos en la configuración. Por ejemplo, puede utilizar este valor (a través del método ContainsType()) para verificar si el tipo de un determinado valor es un tipo de referencia de algún catálogo.

El tipo CatalogManager proporciona acceso a acciones comunes para un catálogo específico. Sus métodos se utilizan para realizar actividades relacionadas con un catálogo, no con sus objetos específicos. Por ejemplo, sus métodos se pueden utilizar para crear un nuevo objeto o para encontrar un objeto por código. El administrador es un punto de entrada específico a un catálogo específico dentro de un modelo de objetos del script de 1C:Enterprise.

Tenga en cuenta que el sistema puede contener un solo objeto del tipo CatalogsManager y un solo objeto del tipo CatalogManager.

Ahora revisemos los tipos CatalogRef y CatalogObject con más detalle. La siguiente figura muestra cómo se almacena un catálogo en una base de datos.

El catálogo se almacena en una tabla. Las entradas de la tabla definen un objeto de base de datos, es decir, un elemento de catálogo. El objeto de base de datos incluye una entrada en la tabla principal del catálogo y las entradas de todas las secciones tabulares del catálogo que se relacionan con este objeto. Por lo tanto, el objeto de base de datos es una entrada que consta de la tabla principal y las filas de la sección tabular.

Un campo Ref se incluye en una tabla de catálogo para almacenar valores que definen explícitamente objetos (elementos de catálogo) en la base de datos de 1C:Enterprise. Si necesita hacer referencia a un objeto de base de datos en cualquier otra tabla, el campo de esta tabla almacenará el valor del campo Ref.

Se utilizan dos tipos principales para manipular el catálogo en el script: CatalogRef.???? y CatalogObject.????, donde ???? es el nombre de metadatos del catálogo. Es importante tener en cuenta que hay tipos distintos para cada catálogo que se crean en el sistema cuando se crea un catálogo en los metadatos. Por lo tanto, los tipos de referencia de dos catálogos diferentes serán diferentes.

Los propósitos de los tipos CatalogRef y CatalogObject son notablemente diferentes. Un valor de tipo CatalogRef almacena una referencia que identifica un objeto en una base de datos, mientras que un valor de tipo CatalogObject se utiliza para leer y escribir datos de objetos.

Un valor de tipo CatalogRef se utiliza en todas partes donde se debe almacenar una referencia a un elemento. En realidad, el valor CatalogRef solo almacena el identificador interno (el mismo que se almacena en el campo Ref de una tabla de catálogo). Este valor se almacena en los campos de otras tablas de base de datos, se selecciona en el cuadro de entrada y se especifica en los parámetros de consulta cuando se busca datos a través de una referencia, y así sucesivamente. Es importante que un valor del tipo CatalogRef siempre se pueda comparar con otros valores del tipo CatalogRef y los valores siempre sean iguales si se trata de las referencias al mismo objeto de base de datos (independientemente del método utilizado para obtener el valor y su origen).

Un valor de tipo CatalogObject se utiliza principalmente para crear nuevos objetos o para modificar o eliminar los existentes. Además, el tipo CatalogObject se utiliza para mostrar y editar todos los datos del elemento de catálogo en forma de un elemento. CatalogObject también se utiliza para editar las filas de la lista de catálogos (CatalogObject no se utiliza para mostrar las filas de la lista). Puede obtener varios objetos de tipo CatalogObject para un solo elemento de catálogo. Estos valores solo son iguales si estamos hablando del mismo objeto de script. Dos objetos de script obtenidos para un elemento de catálogo no serán iguales, incluso si leen el mismo objeto de base de datos y todos los datos del objeto son iguales.

Puedes utilizar un administrador de catálogos para crear un objeto. En este caso, se crea un nuevo objeto que aún no está incluido en una base de datos. Si lo escribes, aparecerá un nuevo objeto en la base de datos. Puedes obtener un objeto a partir de una referencia. En este caso, se lee el objeto existente referenciado a través de una referencia desde la base de datos. También puedes obtener un objeto a partir de una selección (CatalogSelection). A continuación, los datos del objeto se llenan con los datos leídos de la selección.

CatalogObject optimiza el proceso de escribir cambios en una base de datos. Por ejemplo, si no has cambiado los atributos del objeto en sí, solo se escribirá la información mínima sobre los cambios. Si no has cambiado ninguna fila de una sección tabular, no se escribirá la sección tabular. Si solo has cambiado o agregado algunas filas, solo se escribirán las que se modificaron o agregaron. Sin embargo, si has eliminado filas o cambiado el orden de las filas, se escribirán todas las filas de una sección tabular.

Se aplica un bloqueo optimista a los objetos, es decir, el objeto no se puede escribir si se ha cambiado en una base de datos después de la lectura. Esta característica garantiza la integridad lógica de los objetos modificados. Cualquier persona que modifique un objeto puede estar seguro de que sus cambios no sobrescribirán los cambios introducidos por otros usuarios (en otras sesiones) o por otros objetos de la misma sesión. Este tipo de bloqueo no impide que otras sesiones o la misma sesión cambien el objeto. Sin embargo, el objeto no se escribirá si se ha cambiado en la base de datos después de la lectura y antes de la escritura.

Además, existe un mecanismo de bloqueo pesimista que prohíbe cambios dentro de esta u otras sesiones antes de que este objeto de script elimine el bloqueo. Utiliza el método Lock() para activar este mecanismo. En general, se utiliza para bloquear objetos que se están editando en el formulario. La extensión de un formulario de elemento de catálogo activa automáticamente el bloqueo para asegurarse de que el usuario pueda escribir el objeto una vez que comience a editarlo.

Tanto CatalogReference como CatalogObject proporcionan acceso a los datos del objeto (valores de campos de tabla) a través de propiedades. Dado que el propósito y el uso de estos tipos difieren significativamente, estos escenarios también se implementan de manera diferente. El valor de CatalogObject almacena las propiedades directamente en el objeto de script. Cuando se lee el objeto existente, sus propiedades se llenan con los valores de la base de datos y las propiedades del nuevo objeto se inicializan con valores predeterminados. El valor de CatalogRef lee los datos de una base de datos cuando se accede a las propiedades. Sin embargo, para eliminar la necesidad de leer datos cada vez que se acceden a las propiedades, los datos del objeto se almacenan en caché. Si accedes a las propiedades de un objeto de base de datos dado a través de referencias, los datos solo se leen cuando accedes a las propiedades por primera vez y después de que el sistema desalmacena el objeto. Los datos del objeto se almacenan en caché durante aproximadamente 20 minutos, pero si han pasado al menos 20 segundos y luego se accede al objeto, el sistema verifica si el objeto de la base de datos se ha modificado y actualiza los datos en caché si es necesario. Si el objeto se escribe dentro de esta sesión, se actualiza inmediatamente en la caché. El número de objetos que se pueden almacenar en caché es limitado. Ten en cuenta que el sistema utiliza cachés separadas para cada transacción, por lo que cuando accedes a los datos del objeto a través de referencias, obtienes datos actualizados.

El tipo CatalogSelection se utiliza para la iteración dinámica a través de elementos de catálogo. El mecanismo de selección de tabla de objetos no difiere mucho de las selecciones de otras tablas. Ten en cuenta que los elementos leídos en la selección se pueden obtener como valores de CatalogObject. En este caso, no se leerán nuevamente desde la base de datos. La selección siempre lee los datos del objeto en su totalidad (todos los campos y todas las secciones tabulares).

El tipo CatalogList se utiliza para crear una vista dinámica de los datos del catálogo en el control de Tabla. Puedes configurar la estructura de los campos (columnas) que se leen, así como configurar el filtrado y la ordenación. La lista lee los datos en porciones a medida que el usuario navega por una tabla.

El catálogo también define varias extensiones de controles y formularios que se pueden utilizar para ingresar y ver datos de catálogo de forma interactiva. Las extensiones no son tipos de datos. Básicamente, agregan algunas propiedades, métodos y eventos específicos a los objetos correspondientes. Además, las extensiones definen cualquier comportamiento inusual de los formularios y controles cuando un usuario configura el sistema e interactúa con él.

Uso de tipos para manipular datos no objeto

Todas las entidades que son compatibles con el modelo de desarrollo 1C:Enterprise 8 y se almacenan en una base de datos se pueden dividir en entidades objeto y no objeto. Dado que estas entidades difieren por naturaleza, la manipulación de estas entidades utilizando 1C:Enterprise o herramientas de script también difiere en gran medida. Para obtener información sobre la manipulación de entidades objeto, consulte la sección Uso de tipos de datos para manipular objetos de base de datos. Esta sección proporciona información sobre la manipulación de entidades no objeto.

Las entidades no objeto son registros (registro de información, registro de acumulación, registro de contabilidad y registro de cálculo), y secuencias y recalculos de registros de cálculo. Las constantes también son entidades no objeto, pero no se revisan en esta sección, ya que la base de datos almacena un valor para cada constante y no son difíciles de manejar. Revisaremos las entidades no objeto en el ejemplo de un registro de acumulación y un registro de información. Tenga en cuenta que un registro de información es el único registro que se puede utilizar sin un grabador, por lo que su modelo de uso es más amplio en comparación con otros grabadores, y su uso con el grabador es en su mayoría similar a otras entidades no objeto.

Modelo de almacenamiento de datos

Desde el punto de vista del modelo de datos de 1C:Enterprise, una base de datos almacena registros para entidades no objeto. Un registro no es un objeto de base de datos. No se admite ningún identificador interno para él. Un registro se puede describir por completo con los valores de sus campos. Por lo tanto, si elimina un cierto registro y luego escribe uno nuevo con exactamente los mismos valores de todos los campos, obtendrá el mismo estado de la base de datos desde el punto de vista de la lógica de la solución aplicada. Esta es una diferencia fundamental entre un registro y un objeto como parte de entidades objeto, ya que un objeto de base de datos tiene un identificador interno y no se puede crear el mismo objeto dos veces.

Por ejemplo, si tiene un registro de acumulación que almacena los movimientos del stock desde la perspectiva de los productos y los almacenes, cada registro está completamente definido por el tipo de producto, un almacén y la cantidad especificada. De hecho, desde el punto de vista de la lógica de la solución aplicada, dicho registro describe el movimiento de una cierta cantidad de un cierto producto a lo largo de un cierto almacén. Puede crear un segundo registro como este y los dos no serían diferentes a menos que los valores de los campos difieran. Un objeto que representa a una persona física puede tener algunas características personales que no dependen de los valores de los campos. Esta persona puede cambiar el nombre, el apellido y los datos del pasaporte, pero la persona sigue siendo el mismo objeto.

Registros únicos

Una consecuencia importante de las características de las entidades no objeto descritas anteriormente es la incapacidad de escribir referencias a estos registros en los campos de la base de datos. Sin embargo, cabe señalar que hay una clave única para cada entidad en 1C:Enterprise. Esta plataforma utiliza la clave única para manejar diversas tareas. Por ejemplo, puede apuntar a un cierto registro en una tabla. Para todas las entidades no objeto que tienen un grabador, la clave única incluye un grabador y un número de línea. Se utiliza un número de línea para garantizar que el registro sea único y para ordenar los registros dentro del grabador. Una combinación de dimensiones y el período (si el registro es periódico) funciona como una clave única para registros de información que no son subordinados a grabadores.

Si un registro de información es subordinado a un grabador, su carácter único también es compatible con una combinación de campos: un grabador, un número de línea, dimensiones y un período. El primero está definido por su subordinación al grabador, mientras que su lógica aplicada básica (almacenar valores de recursos mediante una combinación de valores dimensionales y el período) define el segundo. Si establece que la periodicidad del registro está definida por la posición del grabador en la línea de tiempo, la clave de dimensión única incluye también un grabador para garantizar un detalle de período adicional dentro de un segundo.

Subordinación a un grabador

La subordinación de registros a un grabador es obligatoria para todos los registros, excepto para los registros de información. La subordinación de registros también es obligatoria para secuencias y recalculaciones. Los registros que están subordinados a un determinado grabador se llaman registros de registro.

La subordinación de registros de registro al grabador define la vida útil de estos registros desde el punto de vista de la lógica aplicada. El grabador (documento) se considera que define si estos registros existen o no. Por regla general, los registros de registro se crean mediante el documento con la ayuda de las herramientas de script de 1C:Enterprise en el proceso de publicación. Los registros que hacen referencia al grabador se pueden crear sin un grabador, pero estos registros aún se consideran subordinados al grabador. No se puede escribir un registro sin especificar un grabador. Si elimina un grabador, también se eliminan los registros subordinados.

A diferencia de las secciones tabulares, los registros de registro están subordinados al grabador, pero no forman parte de él. Cuando se lee un documento, no se leen los registros de registro subordinados, y cuando se escribe, no se escriben automáticamente. Sin embargo, cuando se elimina un grabador, también se eliminan sus registros. Puede hacer que los registros se eliminen automáticamente cuando se publican o despublican objetos. Esta opción de servicio se establece en las propiedades del documento como parte de la configuración. Por lo tanto, los registros de registro no forman parte de un objeto, sino que le son subordinados.

En 1C:Enterprise 8, la disponibilidad de registros de registro subordinados al documento (grabador) no está estrictamente relacionada con el estado Publicado del documento o con la marca de eliminación. Los documentos que no se han publicado o que se han marcado para su eliminación también pueden tener registros. Por ejemplo, esto se utiliza para documentos destinados a la entrada directa (entrada manual) de registros de registro. En este escenario, el usuario introduce registros de registro directamente, por lo que el concepto de publicación no tiene sentido. Si se modifica directamente el campo Publicado o MarcaDeEliminación (sin utilizar el método EstablecerMarcaDeEliminación() o el evento DeshacerPublicación), los registros de registro no se eliminan.

Por lo tanto, las conexiones entre registros de registro y documentos son bastante flexibles. Por otro lado, garantizar la integridad lógica de las conexiones entre documentos y sus registros de registro requiere cierto esfuerzo por parte del desarrollador de la configuración. Por ejemplo, es más complicado editar registros de documentos en el formulario que editar secciones tabulares (que son una parte integral del documento). El uso más simple de registros es la creación de registros de registro en el momento de la publicación. En este caso, solo es necesario asegurarse de que los registros de registro se escriban en el controlador de publicación, y la plataforma admite automáticamente otras conexiones lógicas.

Tipos de datos utilizados para manipular objetos en el script de 1C:Enterprise

El tipo AccumulationRegistersManager proporciona acceso a los administradores de registros específicos. Puede utilizar la propiedad de contexto global AccumulationRegisters para llamar a este tipo.

El tipo AccumulationRegisterManager proporciona acceso a acciones comunes que se relacionan con un registro de acumulación específico. Puede utilizar sus métodos para realizar acciones aplicables al registro y no a sus registros específicos. Por ejemplo, los métodos de este administrador se pueden utilizar para crear un objeto para manipular registros (RecordSet), para obtener una selección de registro y así sucesivamente. El administrador es una especie de punto de entrada a un registro específico en el modelo de objeto de script de 1C:Enterprise.

El administrador de registro también proporciona un conjunto de métodos para realizar acciones relacionadas con el propósito principal del registro. Puede obtener saldos y movimientos para un registro de acumulación u obtener fragmentos de los primeros o últimos registros de un registro de información. Tenga en cuenta que estos métodos son útiles para realizar estas acciones solo en escenarios simples. Los datos similares se pueden obtener a través de tablas de consulta virtual. Las consultas son más flexibles. Desde el punto de vista del rendimiento del sistema, llamar a consultas y llamar a métodos de administrador no difieren mucho.

Tenga en cuenta que el sistema puede contener un solo objeto del tipo AccumulationRegistersManager y un solo objeto del tipo AccumulationRegisterManager.XXXX para cada registro (donde XXXX es un nombre de registro).

Un conjunto de registros es el tipo principal utilizado para modificar los datos de entidades no objeto. Se debe utilizar el tipo AccumulationRegisterRecordSet para leer, modificar y eliminar registros de registro. Un conjunto de registros siempre opera un conjunto de registros filtrados por algún criterio. Para describir estos criterios, utilice la propiedad Filtro de un conjunto de registros. Los registros que están subordinados al grabador siempre están filtrados por el grabador.

En la práctica, un conjunto de registros es una colección de registros que se pueden leer y escribir. Un conjunto de registros proporciona solo un método para modificar datos: Write(). A diferencia de la metodología utilizada en la manipulación de entidades de objeto, no hay un concepto de eliminación para entidades no objeto. Un conjunto de registros solo se puede escribir. Al mismo tiempo, todos los registros existentes que satisfacen el criterio de filtrado actual se reemplazan con los registros que se almacenan en el conjunto. Por lo tanto, para eliminar un conjunto de registros, es necesario establecer el filtro y luego escribir el conjunto sin agregar ningún registro.

También se puede escribir un conjunto sin reemplazar sus elementos. Esto se controla mediante el parámetro del método Write(). Escribir sin reemplazar significa que se agregan nuevos registros a la base de datos sin eliminar los existentes. Tenga en cuenta que los números de línea se ajustan para garantizar la numeración secuencial de los registros dentro de un grabador. Por lo general, se utiliza la escritura sin reemplazo cuando se necesita escribir un gran volumen de registros de registro.

No es necesario leer un conjunto de registros para escribir datos (lo que marca la diferencia con operaciones de objeto similares).

No se puede aplicar un concepto de bloqueo a los datos de entidades no objeto (por supuesto, no estamos hablando de bloqueos de transacción). Por lo tanto, cuando se escribe un conjunto, los datos que se han modificado en otra sesión o en otro conjunto en esta sesión después de leer un conjunto de registros pueden sobrescribirse. Recuerde esto al usar conjuntos de registros para edición interactiva.

También merecen atención los registros de información que no son subordinados a grabadores. Puede utilizar filtros con diferentes combinaciones de dimensiones y períodos para conjuntos de registros de registros de información que no son subordinados a grabadores. La imagen a continuación muestra algunos filtros posibles.

Tenga en cuenta que un conjunto se puede leer y escribir sin filtrar datos por ningún campo. En este caso, se leerán y, por lo tanto, se escribirán todos los registros del registro. Si se comete un error en un módulo (por ejemplo, falta la lectura de un conjunto de registros o la aplicación de un filtro), escribir un conjunto puede resultar en la eliminación completa de un registro, ya que escribir sin un filtro en realidad reemplaza todo el registro con el contenido de un conjunto de registros.

Los registros en conjuntos de registros de registro de acumulación tienen el tipo AccumulationRegisterRecord. Este tipo solo se utiliza para escribir datos en un conjunto de registros. Este valor nunca se utiliza por separado de un conjunto de registros.

Además de un conjunto de registros, también se proporciona el tipo InformationRegisterRecordManager para un registro de información que no es subordinado al grabador. Este tipo se utiliza para leer y escribir un solo registro de registro. En primer lugar, se utiliza para editar un solo registro en el formulario. Con este tipo, también puede leer un registro con ciertos valores de campo clave, modificar los campos (incluidos los clave) y luego escribir el registro.

Este es un tipo auxiliar. Utiliza dos conjuntos de registros para trabajar con un registro (con filtros que corresponden a los campos clave del registro que se está leyendo y escribiendo respectivamente). Por lo tanto, mediante la implementación de controladores en un módulo de conjunto de registros, puede controlar completamente la modificación de datos del registro, incluidos los escenarios en los que los datos se modifican con la ayuda de un administrador de registros.

El tipo AccumulationRegistersRecordKey se puede utilizar para la identificación única de un registro de registro. Por ejemplo, se utiliza para identificar filas de una caja de tabla que representa una lista de registros. Puede activar cualquier fila que necesite. Las propiedades clave están definidas por los campos que forman una clave de registro única. Estas son dimensiones, un período y un grabador para registros de información (el grabador solo se incluye si se utiliza la periodicidad por la posición de un grabador en la línea de tiempo). Se utiliza un grabador y un número de fila para otros registros. Se puede crear una clave para un registro de registro con la ayuda de un administrador.

El tipo AccumulationRegisterSelection se puede utilizar para la iteración dinámica de registros de registro. Una característica de selección de tablas no objeto no difiere mucho de la de tablas de referencia. Tenga en cuenta que una selección siempre lee los datos del registro en su totalidad (se leen todos los campos).

El tipo AccumulationRegisterList se puede utilizar para ver dinámicamente los registros de registro en el control TableBox. Puede configurar la estructura de los campos (columnas) que se leen, así como configurar el filtrado y la ordenación. La lista lee los datos en porciones a medida que el usuario navega por una tabla.

El registro también define varias extensiones de controles y formularios que se pueden utilizar para ingresar y ver datos de registro de forma interactiva. Las extensiones no son tipos de datos, simplemente agregan propiedades, métodos y eventos específicos a los objetos correspondientes. Además, las extensiones definen cualquier comportamiento inusual de formularios y controles cuando un usuario configura el sistema e interactúa con él.

También se admite una extensión para editar un solo registro en un formulario para registros de información, junto con las extensiones que muestran una lista y un conjunto de registros en el formulario. En este caso, el administrador de registros de información actúa como atributo principal del formulario.

Desarrollo de una estructura de registro de información periódica

Uno de los casos de uso más comunes para los registros de información periódica es almacenar el historial de cambios de algunos datos relacionados con objetos. Cuando se diseñan registros de información,  la pregunta más complicada es cómo reflejar los datos de un área temática determinada en la estructura de estos registros.

El registro de información de 1C:Enterprise 8 puede contener múltiples dimensiones, recursos y atributos. Una pregunta común es cuántos registros de información se necesitan para almacenar varios valores que cambian con el tiempo. Puede crear un solo registro con varios recursos para almacenar todos los valores a la vez, o puede crear varios registros, cada uno con un solo recurso que almacena un solo valor.
Cada registro de información es una tabla independiente. Cada entrada de un registro periódico contiene información sobre los valores de ciertos recursos por una cierta combinación de dimensiones dentro de un cierto período de tiempo. Cada valor de recurso se registra explícitamente y tiene efecto en el momento especificado. Un registro no puede indicar que el valor no ha cambiado. Cuando se solicita una sección de un registro (un conjunto de valores de recursos en un cierto momento), la plataforma busca las últimas entradas por una combinación de dimensiones y devuelve los valores de recursos que se encuentran.

No hay una regla uniforme sobre cómo diseñar registros, es decir, “crear un registro” o “crear muchos registros”. Cuando diseña un registro periódico, parta del supuesto de que cada entrada debe reflejar el hecho de que los valores de todos los recursos en un momento específico se han establecido en una base de datos. Tenga en cuenta que la entrada del registro reflejará el hecho de que el usuario ha establecido valores para todos los recursos, independientemente de sus valores anteriores.

Cuando diseña un registro, debe analizar cómo cambian los valores con el tiempo y desarrollar un modelo para reflejar estos cambios de valor en una base de datos. Es muy importante que el usuario comprenda cómo se refleja un área temática en un registro de información. Esto determina si se utiliza correctamente un registro.

Veamos un ejemplo muy común de un registro que almacena tasas de cambio. Necesitas almacenar la tasa de cambio y el factor de conversión para cada moneda. Puedes crear dos registros: uno para almacenar el historial de cambios de la tasa de cambio, y otro para almacenar el historial de cambios del factor de conversión. Por otro lado, puedes crear un solo registro donde cada entrada almacena tanto la tasa de cambio como el factor de conversión. Obviamente, el factor de conversión cambiará con mucha menos frecuencia. Un solo registro es más fácil de implementar y es más amigable para el usuario. Ambas opciones son posibles. En la primera opción, establecer la tasa de cambio y establecer el factor de conversión se tratan como acciones separadas. Por supuesto, se pueden editar en un solo formulario y escribirse como un solo documento, pero debes asegurarte de que un usuario que vea las listas del registro entienda que los historiales de cambios se almacenan por separado. En el segundo escenario posible, establecer la tasa de cambio y establecer el factor de conversión se tratan como una sola acción. Cuando se establece una nueva tasa de cambio, también se debe establecer un nuevo valor de factor de conversión. Por supuesto, puedes implementar el llenado del factor de conversión con el valor anterior durante la creación del registro, para que los usuarios no tengan que ingresarlo cada vez. Es importante asegurarse de que los usuarios que crean registros o ven la lista de registros entiendan que cada entrada establece ambos valores y que tienen efecto en el momento especificado.

En algunos escenarios, varios valores están estrechamente relacionados entre sí y no hay razón para mantener historiales de cambios separados. Por ejemplo, como regla general, todos los datos del pasaporte (serie, número, fecha de emisión, etc.) cambian al mismo tiempo. Los valores incluidos en el historial de cambios se pueden unir para reducir el número de historiales almacenados de forma independiente (como es el caso de la tasa de cambio y el factor de conversión). Recomendamos que unifiques los historiales cuando necesites almacenar un gran número de valores. Es una buena idea agrupar los valores según su significado. También es muy importante presentar visualmente este agrupamiento al usuario. Por ejemplo, si creas un registro de información periódica para almacenar el precio de un artículo y un descuento estándar, el formulario de edición del registro (o el formulario utilizado para editar el documento que genera los registros del registro de información) debe indicar que un nuevo precio y un nuevo descuento entran en vigencia en la fecha especificada.

Ten en cuenta que agrupar varios valores en un solo registro de información tiene sentido, y no solo porque reduce el número de tablas y aumenta el rendimiento. En general, es más conveniente tratar con una sola acción de cambiar varios valores que con múltiples historiales.

Otro aspecto a considerar al diseñar registros de información es la capacidad de introducir nuevas dimensiones. Por ejemplo, si almacenas precios de bienes en un registro de información periódica, posteriormente puedes introducir una nueva dimensión (es decir, un tipo de precio) para almacenar varios precios con tipos definidos por el usuario. Sin embargo, debes tener en cuenta esta opción al diseñar la estructura del registro. En particular, esto se puede utilizar como un criterio que define si varios historiales de cambios se pueden agrupar en un solo registro. Si la introducción de nuevas dimensiones requiere dividir el registro, tiene más sentido crear dos registros desde el principio. Por ejemplo, unir precios y reserva mínima de stock en un solo registro no es la mejor opción.

Dado que un registro de información es una sola tabla en una base de datos, es muy fácil evaluar las ventajas y desventajas de diferentes estructuras de registro desde la perspectiva del rendimiento.

Un gran número de registros de información puede afectar el rendimiento en escenarios donde necesitas obtener datos de objetos y datos de registros periódicos relacionados con ese objeto y que tienen una marca de tiempo específica. Es obvio que puedes obtener una sección de un solo registro con un gran número de recursos mucho más rápido.

Escribir un solo registro con múltiples recursos también es más rápido que escribir en varios registros de información.

Si esperas un gran número de registros que reflejen cambios frecuentes de un solo valor de recurso, la base de datos crece más rápido cuando el registro tiene múltiples recursos. Esto puede afectar significativamente el tamaño de la base de datos, especialmente si uno de los recursos es un almacenamiento de valores que almacena una imagen u otros datos binarios. Recomendamos que almacenes esos datos en un registro separado.

Usar herramientas de script para trabajar con objetos aplicados

Trabajar con objetos aplicados (objetos de configuración) es similar a trabajar con otros objetos, ya que ambos procesos tienen ciertos principios en común. Al comprender estos principios, puedes aprender rápidamente a gestionar todos los objetos aplicados, ya sean catálogos, plan de cuentas, documentos, registros u otros objetos aplicados.

Esta sección es teórica, pero para desarrollar con éxito en 1C:Enterprise, necesitas comprender cómo se clasifican los objetos. La siguiente tabla enumera los tipos de objetos de script de 1C:Enterprise con ejemplos prácticos, una breve descripción de cada tipo, sus propiedades y métodos típicos (los que son comunes para diferentes objetos):

Tipo de objeto	Descripción	Propiedades y métodos típicos
Administrador de objetos aplicados de tipo específico Ejemplos: CatalogsManager DocumentsManager ConstantsManager AccumulationRegistersManager ReportsManager DataProcessorsManager	Un objeto de este tipo proporciona acceso a los administradores de un objeto aplicado específico. Por lo general, estos objetos se acceden a través de propiedades de contexto global, por ejemplo, Catalogs.Employees, Documents.Account, InformationRegisters.CurrencyRates, y así sucesivamente. Estos objetos son colecciones de valores que se pueden utilizar para iterar a través de sus elementos utilizando el bucle Para Cada.	Las propiedades corresponden a los nombres de los objetos aplicados y son ellos mismos objetos de tipo “administrador de objeto aplicado”.
Administrador de objeto aplicado Ejemplos: CatalogManager DocumentManager ConstantManager AccumulationRegisterManager ReportManager DataProcessorManager	Este es el objeto central del modelo de objetos que se puede utilizar para obtener cualquier otro objeto, como referencias, selecciones, objetos a cambiar, conjuntos de registros, y así sucesivamente (consulte la sección “Interconexión de objetos” más adelante en este artículo). Un objeto de este tipo proporciona acceso a un objeto aplicado como un conjunto de elementos. Los métodos de este objeto se pueden utilizar para buscar datos, obtener selecciones, crear nuevos registros o llamar a formularios y plantillas del objeto aplicado.	Propiedades típicas (para catálogos y gráficos): <nombre de un elemento predefinido> Métodos típicos: Select() FindByCode() FindByAttribute() EmptyRef() CreateItem() CreateRecordSet() GetTemplate() GetForm()
Ref Ejemplos: CatalogRef DocumentRef ChartOfAccountsRef ChartOfCalculationTypesRef	Este objeto identifica de manera inequívoca un objeto de base de datos (por ejemplo, un elemento de catálogo o un documento) y se puede utilizar para acceder al objeto en modo de solo lectura. Puede utilizar propiedades y métodos de este objeto para leer los atributos de un elemento o acceder a sus secciones tabulares. Las referencias se almacenan en los atributos que hacen referencia a los elementos del objeto aplicado. Por ejemplo, el atributo Employee del documento Recruitment almacena la referencia al elemento específico del catálogo Employees. Tenga en cuenta que los registros de registro no tienen referencias. Para cambiar un objeto de base de datos (como un elemento de catálogo o un documento), debe obtener el objeto mismo utilizando el método GetObject().	Propiedades típicas: <atributo> <sección tabular> Marca de eliminación Fecha Predefinido Ref Métodos típicos: IsEmpty() GetObject() GetForm() Metadata() Copy()
Selección Ejemplos: CatalogSelection DocumentSelection DocumentJournalSelection AccumulationRegisterSelection	Puede utilizar este objeto para iterar a través de objetos de base de datos. Por ejemplo, puede iterar a través de elementos de catálogo o a través de documentos dentro de un diario. Tenga en cuenta que este objeto no es una colección de valores, por lo que no puede iterar a través de sus elementos utilizando el bucle Para Cada.	Las propiedades son similares a las propiedades de objetos del tipo Ref. Métodos típicos: Next() GetObject()
Objeto Ejemplos: CatalogObject DocumentObject ChartOfAccountsObject ReportObject DataProcessorObject	Proporciona acceso a un elemento con la opción de escribir los cambios en la base de datos. Este objeto tiene métodos que pueden cambiar el elemento en la base de datos, como Write y Delete. Este objeto se utiliza principalmente para generar informes o ejecutar procesadores de datos. Si un módulo de objeto aplicado (no confundirlo con el módulo de formulario) tiene algunas variables de módulo exportadas o procedimientos o funciones, estos se agregan a las propiedades y métodos de este mismo objeto. No existe tal objeto para registros. Los cambios de datos de registro siempre se realizan a través de un conjunto de registros (consulte más adelante en este artículo).	Las propiedades son similares a las propiedades de objetos del tipo Ref. Métodos típicos: Write() Delete() Lock() Unlock() IsLocked() Copy() GetForm() GetTemplate() Metadata()
Lista Ejemplos: CatalogList DocumentList DocumentJournalList ChartOfAccountsList AccumulationRegisterList FilterCriterionList	Este objeto se utiliza para administrar una lista de elementos en un campo de tabla. Se puede utilizar para administrar columnas, así como para filtrar y ordenar elementos de la lista. Este objeto no se puede crear utilizando el script de 1C:Enterprise, en su lugar se crea automáticamente cuando se agrega un campo de tabla a un formulario. Por supuesto, puede crear un campo de tabla en un formulario de pantalla utilizando el script de 1C:Enterprise, y luego se crea automáticamente un objeto de este tipo.	Propiedades típicas: Columnas Filtro Orden Métodos típicos: Refresh()
Conjunto de registros Ejemplos: InformationRegisterRecordSet AccumulationRegisterRecordSet AccountingRegisterRecordSet CalculationRegisterRecordSet SequenceRecordSet	Un conjunto de registros se puede utilizar para manejar varios registros de un objeto aplicado (por lo general, un registro) al mismo tiempo. Puede leer un conjunto de registros completo de una base de datos, luego agregar algunos registros nuevos o cambiar los existentes y luego escribir el conjunto de registros en una base de datos (en una sola transacción). Los documentos tienen la propiedad Records, que es una colección. Proporciona acceso a conjuntos de registros de cada registro seleccionado en la pestaña Registros de registro. Los registros de registro de documentos generalmente se crean a través de esta propiedad cuando se publica el documento.	Propiedades típicas: Filtro EsteObjeto Métodos típicos: Add() Delete() Clear() Write() Read() Count() Unload() Load()
Registro Ejemplos: InformationRegisterRecord AccumulationRegisterRecord AccountingRegisterRecord CalculationRegisterRecord	Este objeto proporciona acceso a un solo registro de un conjunto de registros para definir sus dimensiones, recursos, y así sucesivamente. Este objeto es devuelto por métodos de otros objetos, por ejemplo, por el método Add del objeto AccumulationRegisterRecordSet. Un objeto del tipo Registro no es un identificador constante para un registro de registro específico (a diferencia del objeto Ref para catálogos y documentos). Los registros de registro de registro de información no tienen identificadores que nunca cambian con el tiempo; cada registro de registro se define de manera inequívoca por los valores de sus dimensiones (incluidas las dimensiones del sistema, como Period, Recorder y LineNumber).	Propiedades típicas: <dimensión> <atributo> <recurso> Activo Periodo Grabador Número de línea Tipo de registro Métodos típicos: PuntoEnElTiempo()
Clave de registro Ejemplos: InformationRegisterRecordKey AccumulationRegisterRecordKey AccountingRegisterRecordKey CalculationRegisterRecordKey	Este objeto se utiliza para identificar un registro de registro en un campo de tabla (por ejemplo, en un conjunto de registros de un documento grabador o en una lista de todos los registros de registro). Se utiliza para posicionarse en un registro de registro específico de una lista de registros.	Propiedades típicas (excepto el registro de registro de información): Número de línea Grabador Propiedades de registro de registro de información: <nombre de dimensión> Periodo Grabador

Objetos específicos

Algunos de los objetos importantes que no se ajustan a la clasificación anterior son:

Tipo de objeto	Objeto aplicado correspondiente	Descripción
Gestor de registros de registro de información	Registros de información	Este objeto se utiliza para realizar operaciones en un solo registro de un registro de información. Solo los registros de información independientes (los que no están subordinados a un grabador) pueden tener este objeto. Tenga en cuenta que incluso si los registros se editan utilizando un gestor de registros, aún se utiliza un conjunto de registros de registro en la capa inferior: cuando se guardan o eliminan registros, se activan los eventos del módulo de conjunto de registros de registro.
Tipos de dimensión externa de PlanDeCuentas Fila de Tipos de dimensión externa de PlanDeCuentas	Planes de cuentas	Este objeto se utiliza para trabajar con una lista de tipos de dimensión externa adjuntos a una cuenta.
Dimensiones externas de RegistroContable	Registros contables	La propiedad ExtDimensions del objeto RegistroContableRegistro es un objeto de este tipo. Este objeto es una colección de valores y se puede utilizar para gestionar valores de dimensión externa para un registro de registro contable específico.
Conjunto de constantes	Constantes	Este objeto es similar a los objetos ConjuntoDeRegistros en la forma en que permite leer/escribir valores de múltiples constantes desde/hacia una base de datos en una sola transacción. El conjunto de sus propiedades y métodos no es similar al de los conjuntos de registros, y por eso se incluye entre otros objetos específicos.
Gestor de procesadores de datos externos Procesador de datos externos	Procesadores de datos externos	El gestor de procesadores de datos externos es similar a los gestores de otros objetos aplicados. Su método Create(<nombre de archivo>) se puede utilizar para crear un objeto de tipo ProcesadorDeDatosExterno. Este objeto, a su vez, es similar a los objetos de tipo ObjetoDeInforme y ObjetoDeProcesadorDeDatos. Proporciona acceso a los atributos y secciones tabulares del procesador de datos externo para el procesamiento de datos o para pasar parámetros de generación de informes. Si un módulo de procesador de datos externo (no confundir con el módulo de formulario) contiene variables de módulo exportadas o procedimientos o funciones, se agregan al conjunto de propiedades y métodos del objeto ProcesadorDeDatosExterno.

Interconexión de objetos

A continuación se muestra una descripción de las interconexiones entre los objetos de 1C:Enterprise, que son típicas para los objetos con referencias (se utilizan los catálogos como ejemplo).

NOTA: El diagrama no muestra todos los objetos e interconexiones posibles. Por ejemplo, el método Copy() puede pertenecer tanto a los objetos CatalogRef como a los objetos CatalogObject. Además, el objeto CatalogManager tiene los métodos FindByDescription() y FindByAttribute() que son similares al método FindByCode() y devuelven una referencia a un elemento o una referencia vacía si el elemento no se encuentra. Los diagramas tampoco muestran objetos específicos ni objetos de tipo List.

Y ahora procedamos a otra interconexión que es común para los registros (se utilizan los registros de acumulación como ejemplo):

Como puedes ver, las partes izquierdas de estos diagramas son muy similares, mientras que las partes derechas son diferentes. No debes pensar que el objeto RecordKey es similar a los objetos Ref, o que los objetos RecordSet y Record son similares a los objetos Object, aunque hay cierta similitud entre ellos.

• El objeto RecordKey se asemeja al objeto Ref en el sentido de que es el identificador más preciso de un registro de registro específico posible (aunque no es tan absoluto como el objeto Ref). Siempre debes recordar que los registros de registro particulares no tienen referencias, en otras palabras, no hay identificadores únicos que diferencien un registro de otro y lo hagan inmutable en el tiempo y el espacio.
• Un objeto RecordSet y un objeto Record se asemejan al objeto Object solo por el hecho de que los datos en una base de datos se modifican a través de estos objetos.

Resumen

• Trabajar con cualquier objeto aplicado tiene mucho en común con trabajar con otros objetos aplicados, ya que se organiza utilizando varios objetos de 1C:Script, cada uno de los cuales tiene su propio propósito y un conjunto típico de propiedades y métodos. Sin embargo, el conjunto de propiedades y métodos de un objeto aplicado puede variar del típico.
• Puedes usar ciertas propiedades y métodos para obtener varios objetos de 1C:Enterprise a partir de otros objetos de 1C:Enterprise.
• Se pueden distinguir dos grupos de objetos aplicados: aquellos que contienen referencias (elementos de catálogo, catálogos y documentos) y aquellos que no las contienen (generalmente relacionados con registros).
• Algunos objetos de 1C:Enterprise no encajan en el patrón general y se describen por separado.

Consejos para elegir entre un catálogo subordinado y una sección tabular

1C:Enterprise admite la creación de una o más secciones tabulares para un catálogo. Puedes usar esta opción para representar datos que están relacionados con este elemento pero no tienen naturaleza de objeto (si los datos tienen naturaleza de objeto, se recomienda crear un catálogo subordinado). Por ejemplo, puedes crear la sección tabular UnitsOfMeasure para el catálogo Goods.

Ten en cuenta que si se utiliza una sección tabular, no podrás hacer referencia a las filas de una sección tabular, es decir, no podrás crear un atributo que coincida con la entidad “fila de sección tabular”. Por ejemplo, si creas la sección tabular Education (en lugar de un catálogo subordinado) para el catálogo Employees, no podrás seleccionar un tipo como “graduado de” para los atributos del documento. Esto debe tenerse en cuenta al elegir entre un catálogo subordinado y una sección tabular.

Si es posible que necesites hacer referencia a objetos subordinados en el futuro (por ejemplo, para crear atributos de documentos u otros catálogos que los referencien), es mejor crear un catálogo subordinado desde el principio. Si una referencia a esos datos no tiene sentido y nunca puede ser un tipo de cierto atributo, puedes crear una sección tabular.

A continuación se muestra una lista de casos y factores a tener en cuenta para elegir entre un catálogo subordinado y una sección tabular. Estudia detenidamente estos casos para evitar errores al tomar tu decisión.

---

Caso 1

Necesitas almacenar una lista de cuentas de liquidación de cada contratista en la base de datos. Es probable que debas especificar no solo el nombre del contratista, sino también su cuenta de liquidación en todos los documentos de pago. Estos datos definitivamente tienen naturaleza de objeto y se pueden identificar como una “cuenta de liquidación”.Solución: un catálogo Contractors y un catálogo subordinado SettlementAccounts con los campos Bank, Number y Account.

---

Caso 2

Necesita almacenar una lista de unidades de medida para cada producto en el catálogo de Mercancías y especificar un factor de conversión para recalcular cada unidad en la unidad básica de medida. Estos datos se recopilan del catálogo UnidadesDeMedida que almacena todas las unidades de medida disponibles. Cada fila de esa lista subordinada no tiene una naturaleza de objeto propia, solo se necesita para recalcular desde una cierta unidad de medida a la básica.Solución: un catálogo de Mercancías y una sección tabular UnidadesDeMedida con los campos UnidadDeMedida y FactorDeConversion.

---

Caso 3

La función de derechos de usuario predeterminada no es suficiente para trabajar con aplicaciones específicas. A menudo se necesita un sistema que permita a diferentes usuarios aprobar documentos. En este caso, necesita almacenar una lista de documentos que un cierto usuario (empleado) puede aprobar, y para eso se puede utilizar la sección tabular DocumentosParaAprobacion del catálogo Empleados. Estos datos no están basados en objetos, simplemente conectan un documento y un empleado, por lo que probablemente nunca tenga que crear referencias a ellos.Solución: un catálogo de Empleados y una sección tabular DocumentosParaAprobacion con el campo Documento y la casilla de verificación Está aprobado. Tenga en cuenta que esta tarea también se puede resolver con la ayuda de registros de información.

---

Caso 4

Necesita almacenar datos familiares de empleados en el catálogo de Empleados, que incluye miembros de la familia y sus relaciones con el empleado (esposo, esposa, hijo, hija, etc.). Por lo general, estos datos se pueden representar como una lista completamente subordinada al elemento del catálogo de Empleados, y se puede considerar la creación de una sección tabular. Sin embargo, si lo pensamos de nuevo, estos datos definitivamente tienen una naturaleza de objeto y se pueden identificar como un “miembro de la familia”. En algunas aplicaciones, es posible que necesite crear referencias a los miembros de la familia del empleado. Se observa una situación similar con la educación del empleado y la experiencia laboral anterior.Solución: la elección entre un catálogo subordinado y una sección tabular depende del propósito de su configuración. Si necesita crear referencias a ciertos datos en el futuro, es posible que desee crear los siguientes catálogos subordinados: MiembrosDeFamilia, Educacion y ExperienciaLaboral.

---

¡Importante! Recuerde que cuando llama a un elemento del catálogo, se lee de la base de datos en su totalidad, junto con todas las secciones tabulares. Si una sección tabular contiene un gran número de filas, esto puede dificultar el rendimiento del sistema.

Por lo tanto, se debe utilizar una sección tabular si no es necesario almacenar referencias a elementos y la cantidad de elementos es limitada.

Datos predefinidos: solución de problemas

Mientras trabaja con datos predefinidos, puede encontrar los siguientes problemas:

• Un intento de acceder a un elemento predefinido conduce al siguiente error: “No se encuentra el elemento predefinido en los datos de la base de información”. Posibles razones:
  • Es un nodo subordinado y los elementos de datos predefinidos disponibles en el nodo central aún no se han cargado.
  • Los datos de la base de información se inicializaron cuando la actualización de datos predefinidos estaba desactivada para toda la base de información o para un objeto de metadatos específico.
  • Se eliminaron los datos predefinidos.
  • Se borró el valor del atributo PredefinedDataName de los datos predefinidos.
• Se detectan elementos duplicados de datos predefinidos (dos o más registros de datos tienen el mismo valor de la propiedad PredefinedDataName). Posibles razones:
  • Se crearon elementos de datos predefinidos con DataExchange.Load establecido en Verdadero. Por ejemplo, esto puede ocurrir en escenarios con bases de información distribuidas.

Solución de problemas

Se recomienda habilitar la grabación de eventos de nivel “Información” en el registro de eventos en todo momento.

No se encuentran los elementos de datos predefinidos

Filtre el registro de eventos por objeto de metadatos cuyos datos faltan y por los siguientes tipos de eventos:

• Datos:
  • Modificar datos predefinidos
  • Eliminar datos predefinidos
  • Establecer inicialización de datos predefinidos
• Base de información:
  • Actualizar datos predefinidos
  • Establecer actualización de datos predefinidos

Los eventos en la lista pueden mostrar por qué no se encuentra el elemento predefinido.

Si el registro contiene un evento de tipo Data.Modify datos predefinidos, que tiene una cadena vacía como nombre de datos predefinidos, significa que un usuario o un fragmento de script de 1C:Enterprise borró el nombre de datos predefinidos, lo que hace que el elemento no sea predefinido. Para restaurar el elemento, devuelva el valor anterior a la propiedad PredefinedDataName. Se recomienda corregir la configuración para evitar esta situación en el futuro (por ejemplo, cambiar los derechos de acceso o modificar el fragmento de script).

Si el registro contiene un evento de tipo Data.Delete datos predefinidos, significa que los datos predefinidos fueron eliminados por un usuario o desde un script de 1C:Enterprise. Para corregir esto, cree el elemento predefinido que falta. Se recomienda corregir la configuración para evitar la eliminación de datos predefinidos que se utilizan en los algoritmos de la aplicación.

Si el registro contiene un evento de tipo Data.Set inicialización de datos predefinidos donde se establece una bandera de inicialización de datos predefinidos, significa que se intentó establecer la bandera desde un script de 1C:Enterprise pero algunos (o todos) los elementos predefinidos no se crearon. Se recomienda corregir la configuración (asegúrese de que se creen todos los elementos de datos predefinidos o que los elementos que faltan nunca se accedan).

Si el registro contiene un evento de tipo Infobase.Actualización de datos predefinidos que incluye el comentario “Actualización de datos predefinidos desactivada”, significa que la actualización de datos predefinidos está desactivada a nivel de infobase, nodo u objeto de metadatos. En este escenario, la plataforma no realiza la reestructuración de los datos predefinidos. Para identificar la fuente del problema:

• Asegúrese de que no sea un nodo subordinado. En un nodo subordinado, los datos predefinidos se cargan desde el nodo central. Por eso, su lógica de aplicación debe proporcionar la opción de cargar los cambios desde el nodo central antes del primer intento de acceder a los datos predefinidos.
• Analice los eventos de tipo Infobase.Actualización de datos predefinidos donde la actualización de datos predefinidos está desactivada. Si la actualización de datos predefinidos se desactivó antes de la actualización de la configuración, habilite la actualización automática de datos predefinidos utilizando el método SetInfoBasePredefinedDataUpdate (si se desactivó para toda la infobase) o el método SetPredefinedDataUpdate (si se desactivó para un objeto de metadatos específico). Se recomienda corregir la configuración para evitar esta situación en el futuro. Cree los elementos de datos predefinidos que faltan o elimine el script que accede a los elementos que faltan.
• Valide la configuración. Probablemente la propiedad del objeto de metadatos PredefinedDataUpdate está establecida en DontAutoUpdate. Si este es el caso, corrija este error.

Elementos de datos predefinidos duplicados.

Los duplicados pueden aparecer solo en el modo de carga de datos (DataExchange.Load establecido en Verdadero). En este escenario, la plataforma no verifica si los elementos de datos predefinidos son únicos.

Si el registro de eventos contiene registros de tipo Data.Add datos predefinidos con valores duplicados de PredefinedDataName, significa que se crearon duplicados de datos predefinidos desde un script de 1C:Enterprise, por ejemplo, se cargaron durante el intercambio de datos.

Si el registro de eventos contiene registros de tipo Data.Modify datos predefinidos con valores duplicados de PredefinedDataName, significa que se crearon duplicados de datos predefinidos por un usuario o desde un script de 1C:Enterprise, por ejemplo, se cargaron durante el intercambio de datos o el modo de carga especificado en el formulario del elemento es incorrecto y el usuario pudo especificar un nombre duplicado.

Para corregir el problema, primero decida cuál es el elemento correcto (por ejemplo, verificando las referencias a los elementos de datos predefinidos) y luego haga que el otro elemento sea regular (no predefinido) borrando el campo PredefinedDataName. Antes de eliminar el elemento, verifique si es necesario reemplazar las referencias a este elemento con las referencias al elemento correcto.

Directrices para trabajar con datos predefinidos

Si no planea administrar los datos predefinidos desde un script de 1C:Enterprise y asume que siempre están en la base de datos, haga lo siguiente:

• Restringir el acceso a los datos predefinidos, de modo que nadie pueda eliminar o borrar la propiedad PredefinedDataName.
• Avoidar la modificación de datos predefinidos en modo privilegiado.
• Avoidar la modificación de datos predefinidos en el modo de carga de datos (cuando la propiedad DataExchange.Load está establecida en True).
• No deshabilitar la actualización automática de datos predefinidos.

Recuerde que la plataforma no crea elementos de datos predefinidos en nodos subordinados. En su lugar, provienen del nodo central. Por lo tanto, al desarrollar aplicaciones que se ejecutan como bases de datos distribuidas, preste atención a la actualización de datos predefinidos en el primer inicio de la aplicación y asegúrese de que la aplicación no intente acceder a los datos predefinidos cuando aún no se hayan cargado desde el nodo central.

Autonumeración

Este artículo cubre los detalles de cómo funciona la autonumeración en el ejemplo de un catálogo.

Resumen de la autonumeración

La numeración automática de los elementos del catálogo proporciona códigos únicos para los nuevos elementos. A los nuevos elementos se les asignan códigos numéricos incrementales.

Las reglas de generación de códigos se basan en la configuración de series de códigos especificada para el catálogo.

• En todo el catálogo. Todos los códigos en el catálogo son únicos.
• Dentro del área de subordinación. Los elementos que tienen el mismo padre tienen códigos diferentes, mientras que los elementos que tienen padres diferentes pueden tener códigos idénticos.
• Dentro del área de subordinación del propietario. Los elementos que tienen el mismo propietario tienen códigos diferentes, mientras que los elementos que tienen propietarios diferentes pueden tener códigos idénticos.

La autonumeración emite nuevos códigos de acuerdo con la configuración de series de códigos del catálogo.

Abordemos un ejemplo de un catálogo jerárquico con jerarquía de elementos, series de códigos = dentro del área de subordinación, autonumeración habilitada.

Agreguemos el primer elemento al catálogo:

Se puede ver en la figura que la numeración automática de los elementos del catálogo comienza desde 000000001.

Agreguemos el segundo elemento al catálogo:

Agreguemos un elemento más que sea subordinado al segundo elemento:

Se puede ver en la figura que la configuración de la serie de códigos afecta la generación del código del nuevo elemento: el código del tercer elemento es único solo entre los elementos que son subordinados al segundo elemento.

Una de las peculiaridades de la autonumeración es el uso de ceros principales. Esto aumenta la eficiencia de la búsqueda y clasificación por código o por número. Para buscar o clasificar elementos, la plataforma utiliza el índice de la base de datos para el campo de código o número. Para utilizar la indexación de la base de datos, 1C:Enterprise agrega ceros principales a los nuevos códigos o números generados automáticamente.

Los ceros principales son necesarios para una clasificación adecuada de documentos y otros objetos que tienen números. Por ejemplo, sin ceros principales, un documento con el número “Doc3” va después de un documento con el número “Doc11”, lo cual es incorrecto.

Operaciones con prefijos de código

Agregar un prefijo a un código de elemento que se está generando solo tiene sentido si el código es una cadena.

Para agregar un prefijo a un nuevo código o número, puede utilizar el controlador de eventos On set new code. Este evento se dispara cuando comienza la generación del código (por ejemplo, cuando comienza la generación de un código de elemento de catálogo). La declaración del controlador tiene la siguiente sintaxis:

OnSetNewCode (<Procesamiento estándar>,<Prefijo>),

donde:

• <Procesamiento estándar> es una bandera que indica si se utiliza el procesamiento estándar. Si establece este parámetro en Falso en el cuerpo del procedimiento del controlador, se cancela la generación de código estándar.
• <Prefijo> es un prefijo que se utilizará para la generación de código.

Veamos un ejemplo de una configuración de base de datos distribuida donde los prefijos aseguran la unicidad de los códigos en cada nodo. El siguiente fragmento de script genera códigos únicos:

// Controlador de evento OnSetNewCode
// Cambia el prefijo del código al prefijo único definido en esta base de datos
//
Procedure OnSetNewCode (ProcesamientoEstándar, Prefijo)

    Prefijo=ObtenerPrefijoNúmero();

EndProcedure // OnSetNewCode (ProcesamientoEstándar, Prefijo)

donde ObtenerPrefijoNúmero es una función de módulo común exportada, que devuelve el valor de alguna constante. Cada nodo proporciona un valor único para esta constante:

// Devuelve un prefijo para un nuevo número
//
// Valor de retorno:
// String – prefijo para un nuevo número
//
Function ObtenerPrefijoNúmero() Export

    Return Constantes.PrefijoNúmero.Obtener();

EndFunction // ObtenerPrefijoNúmero()

En lugar del controlador OnSetNewCode, puede utilizar el método SetNewCode() del objeto catálogo. Puede pasar un prefijo como parámetro de este método, en este caso el método encuentra la parte numérica máxima entre los códigos que tienen este prefijo y genera un código con la parte numérica incrementada en 1. Si omite el prefijo, el método encuentra la parte numérica máxima entre todos los códigos disponibles en la base de datos y genera un código con el mismo prefijo y la parte numérica incrementada en 1.

Tenga en cuenta que para los catálogos que tienen códigos de tipo Número, se ignora el prefijo devuelto por el controlador OnSetNewCode.

Soporte de autonumeración por otros objetos de metadatos

Además de los catálogos, los siguientes objetos de metadatos admiten la autonumeración:

• Documento
• Plan de tipos de características
• Proceso empresarial
• Tarea

Para establecer números para documentos, procesos empresariales y tareas, utilice el controlador de evento OnSetNewNumber.

Para establecer códigos para planes de tipos de características, utilice el controlador de evento OnSetNewCode.

Autonumeración para colaboración

Los principios básicos de la autonumeración se describen en Autonumeración. Este artículo describe las peculiaridades de la autonumeración durante el trabajo simultáneo de varios usuarios.

Veamos este problema en el ejemplo de un catálogo (la autonumeración se implementa de la misma manera para otros tipos de objetos).

El algoritmo de autonumeración se basa principalmente en los datos del objeto almacenados en una tabla de base de datos. Para generar un código, 1C:Enterprise busca en el catálogo el código máximo con el prefijo especificado. Como siempre se admite la indexación para el campo “Código”, la búsqueda se realiza bastante rápido.

Tenga en cuenta que solo busca los registros existentes. Si se elimina un objeto que tenía el código máximo, 1C:Enterprise proporciona este código en la siguiente solicitud. Sin embargo, si se elimina algún objeto que no tenía el código máximo, o se omiten algunos códigos, 1C:Enterprise nunca proporciona los códigos faltantes para los nuevos objetos. Si desea que 1C:Enterprise proporcione los códigos faltantes, no utilice la función de autonumeración. En su lugar, implemente un algoritmo de numeración personalizado.

Tenga en cuenta que los códigos no se generan durante la creación del objeto. Algunos escenarios de creación de objetos en realidad no incluyen la entrada de nuevos datos. Por ejemplo, un objeto puede ser replicado desde otra base de datos o desde una fuente de datos externa, y en ambos casos viene con un código. En consecuencia, la generación de código en tales escenarios es solo una pérdida de tiempo porque el código generado se sobrescribe inmediatamente. Por eso, es necesario asignar un código explícitamente utilizando el método SetNewCode(). Sin embargo, cuando un usuario de la aplicación abre un formulario de un nuevo elemento, la extensión del formulario genera automáticamente un código de elemento. Esto es solo una operación de servicio admitida por la extensión del formulario, es similar a llamar al método SetNewCode() en el controlador de apertura del formulario.

Por lo tanto, un desarrollador de aplicaciones debe llamar al método que establece un código exactamente cuando sea necesario. De lo contrario, esto crearía una llamada innecesaria a la base de datos, lo que podría resultar en bloqueos no deseados. También recomendamos que preste atención al elegir el lugar óptimo para la llamada SetNewCode(). Llamar a este método en una transacción puede llevar a bloqueos no deseados.

Para garantizar la numeración correcta en aplicaciones multiusuario, 1C:Enterprise bloquea cada nuevo código desde el momento en que se emite hasta el momento en que se escribe un objeto (o cuando se elimina el valor de CatalogObject de la memoria).

Ejemplo:

//Fragmento 1
Object1 = Catalogs.Products.CreateItem();
Object1.SetNewCode();
Message(Object1.Code);  //4753
Object2 = Catalogs.Products.CreateItem();
Object2.SetNewCode();
Message(Object2.Code);  //4754

//Fragmento 2
Object1 = Catalogs.Products.CreateItem();
Object1.SetNewCode();
Message(Object1.Code);  //4753
Object1 = Undefined;
Object2 = Catalogs.Products.CreateItem();
Object2.SetNewCode();
Message(Object2.Code);  //4753

//Fragmento 3
Object1 = Catalogs.Products.CreateItem();
Object1.SetNewCode();
Message(Object1.Code); //4753
Object1.Write();
Object2 = Catalogs.Products.CreateItem();
Object2.SetNewCode();
Message(Object2.Code);  //4754

En el primer fragmento de script, la numeración automática emite un código a un objeto almacenado en la memoria y bloquea este código. Cuando emite un código al segundo objeto, se salta el código bloqueado.

En el segundo fragmento de script, se emite el mismo código a ambos objetos porque el primer objeto ya no está disponible cuando se emite el código al segundo objeto. Tenga en cuenta que este comportamiento se define configurando la propiedad de configuración Modo de numeración automática de objetos en Liberar automáticamente. Si esta propiedad no se establece en Liberar automáticamente, la numeración automática no reutiliza el primer código, establece el código 4754 para Object2.

En el tercer código, la numeración automática emite un código diferente al segundo objeto porque el primer objeto ya está escrito.

En general, la numeración automática busca el código máximo, genera el siguiente código basado en este, y verifica si este código está bloqueado. Si está bloqueado, genera el siguiente código y verifica si está bloqueado. Repite este paso hasta que encuentre un código libre. Luego establece este código en un nuevo elemento y lo bloquea.

Está claro que este algoritmo está principalmente destinado a la generación de códigos para la entrada de datos interactiva. Si un usuario comienza a ingresar un elemento en un formulario y luego otro usuario comienza a ingresar otro elemento, 1C:Enterprise asigna códigos diferentes a estos elementos.

Si un catálogo utiliza la numeración automática y su código está en blanco, 1C:Enterprise genera un código cuando se escribe el elemento del catálogo. Por lo tanto, no es necesario llamar al método SetNewcode() cuando se crea un elemento desde el script de 1C:Enterprise. Sin embargo, es posible que desee utilizar este método para excluir la generación de código de la transacción que escribe un elemento.

Usar gráfico de tipos de características para implementar el almacenamiento de valores relacionados con objetos de la base de información

Mientras diseña metadatos, es posible que deba decidir entre agregar atributos y usar un almacenamiento de datos adicional basado en un gráfico de tipos de características.

Supongamos que necesita agregar algunos datos que describen las propiedades del almacén a un catálogo de almacenes. Por ejemplo, necesita almacenar la dirección del almacén para agregarla a las guías de remisión entregadas a los agentes de transporte. Seguramente puede hacerlo agregando el atributo Dirección al catálogo de almacenes. Por otro lado, puede implementar un almacenamiento de datos adicional como un registro de información o una sección tabular de catálogo utilizando un gráfico de tipos de características.

Estas dos opciones son claramente muy diferentes, tanto en los detalles de implementación como en el uso potencial de las soluciones resultantes.

Agregar un atributo es la forma más directa posible. Esta es la coincidencia más cercana al modelo de almacenamiento de datos relacionales, garantiza el uso óptimo de los datos almacenados y satisface la mayoría de los requisitos de usabilidad. Usar un atributo no requiere ningún esfuerzo por parte del desarrollador. 1C:Enterprise “sabe” cómo trabajar con el atributo. Proporciona soporte para editar el atributo en formularios, mostrarlo en listas y acceder a él desde informes. La plataforma garantiza la eficiencia de las operaciones con el atributo, incluida la búsqueda por el atributo. Sin embargo, si agrega el atributo, deberá actualizar todos los formularios e informes donde desee que se muestre. Si agrega otro atributo más tarde, deberá actualizar los formularios e informes nuevamente.

Si utiliza un gráfico de tipos de características en su lugar, puede dar a los usuarios la opción de agregar más tipos de datos que describan almacenes. Sin embargo, este método requiere más esfuerzo por parte del desarrollador. En este escenario, los datos adicionales del almacén se almacenan en un registro de información o una sección tabular. Esto no coincide exactamente con el modelo de datos relacional. En realidad, en lugar de implementar campos adicionales, se utiliza una tabla. Uno de los campos de la tabla almacena los valores, mientras que otro almacena el tipo de dato (por ejemplo, dirección del almacén o tamaño del almacén). Como 1C:Enterprise no puede determinar automáticamente que estos datos están relacionados con los almacenes, es necesario implementar operaciones con estos datos. Esto también se aplica a los formularios de entrada de objetos, formularios de lista y cualquier informe basado en estos datos. Por ejemplo, es posible que necesite describir las relaciones entre tablas para crear un informe con un filtro por una característica. La principal ventaja de este método es la opción de agregar características de forma dinámica, sin cambiar la configuración.

Es difícil decidir qué método es mejor. Recomendamos que primero considere agregar un atributo. Utilice un gráfico de tipos de características solo cuando tenga una razón para hacerlo. Los principales argumentos para esta opción son:

1. Los usuarios necesitan agregar características sin cambiar la configuración.
2. El conjunto de características puede variar según la instancia del objeto.

El primer argumento está relacionado principalmente con soluciones estándar que se implementan en muchas empresas y a menudo requieren personalizaciones específicas de la industria. Por ejemplo, las características del producto a menudo dependen del tipo de producto.

El segundo argumento es relevante cuando diferentes instancias de objetos pueden tener propiedades diferentes (por ejemplo, si una empresa vende productos de diferentes tipos).

Teniendo en cuenta la complejidad de implementación del método que implica un gráfico de tipos de características, recomendamos que establezca un límite para el número total de veces que se utiliza en su aplicación. Utilice este método solo cuando sea necesario alcanzar un equilibrio entre aprovechar las capacidades de 1C:Enterprise y reducir los costos de soporte de la solución.

Secuencias de documentos

Visión general

El mecanismo de secuencia de documentos garantiza que los documentos interrelacionados se publiquen en el orden correcto. La idea principal de este mecanismo es que un procedimiento de publicación de documentos puede depender de ciertos datos almacenados en la base de datos de información. Para ser exactos, el procedimiento de publicación de documentos depende de los valores de datos que se almacenaron en la base de datos de información en el momento en que el documento se registró en la base de datos de información. Si estos datos cambian después de la publicación del documento, el documento debe volver a publicarse para actualizar sus registros de registro. Por ejemplo, si un documento lee los precios de los artículos de un registro de información, un cambio de precio invalida los registros de registro de este documento y el documento debe volver a publicarse para corregirlos.

Este mecanismo utiliza el siguiente algoritmo. Cuando se escribe un documento, se registra en una secuencia de documentos. Esto significa que el procedimiento de publicación de documentos se basa en ciertos datos almacenados en la base de datos de información, y el resultado de la publicación de documentos depende de los valores de datos que se almacenaron en cierto momento. Al final de la publicación de documentos, 1C:Enterprise verifica todas las secuencias en las que se registró el documento. Para cada secuencia, 1C:Enterprise verifica si todos los documentos registrados en la secuencia antes de este documento se publicaron en el orden correcto. Si se publicaron en el orden correcto, la publicación del documento se considera correcta. Si no se publicaron en el orden correcto, la publicación del documento se considera incorrecta y el documento debe volver a publicarse.

Cuando los datos que afectan la publicación de documentos cambian, 1C:Enterprise determina qué secuencias de documentos dependen de estos datos. Todos los documentos que se registran en estas secuencias después de que se haya escrito el cambio de datos obtienen la marca “pendiente de republicación”.

Los usuarios de la aplicación pueden saber qué documentos se publicaron correctamente y cuáles no. Pueden obtener estos datos como el punto en el tiempo, antes del cual todos los documentos se publican en la secuencia correcta. Todos los documentos publicados después de este punto en el tiempo se consideran publicados en un orden incorrecto. Sabiendo esto, un usuario puede decidir restaurar el orden correcto de la publicación de documentos. Esto incluye volver a publicar todos los documentos que pertenecen a la secuencia y se publicaron anteriormente.

Detalles de implementación

Cuando se desarrolla una aplicación, un desarrollador describe qué documentos se incluyen en una secuencia y qué datos afectan su registro. Todos estos datos se definen en el objeto de metadatos de secuencia. Un desarrollador especifica una lista de documentos que forman una secuencia y una lista de registros cuyos datos afectan el registro del documento. Tenga en cuenta que la plataforma monitorea los cambios de datos que afectan solo las secuencias de documentos en registros de acumulación, cálculo, contabilidad e información.

Una secuencia de documentos puede tener dimensiones. Puede utilizar dimensiones para dividir las secuencias de documentos en partes más pequeñas. Por ejemplo, si un procedimiento de registro de documentos implica precios de artículos almacenados en un registro de información, cambiar un solo precio de artículo inicia el registro de todos los documentos de ese tipo, incluso aquellos que no incluyen ese artículo específico. Para resolver el problema, puede agregar la dimensión de artículo a una secuencia de documentos. Cuando se registra un documento en una secuencia de documentos, su registro de registro incluye los artículos afectados por el documento. Cuando 1C:Enterprise restaura una secuencia de documentos, puede determinar qué artículos se cambiaron y, en consecuencia, qué documentos deben volver a registrarse.

El registro de documentos en una secuencia se puede realizar automáticamente. Primero, un desarrollador debe establecer una asignación entre los atributos del documento y las dimensiones de la secuencia de documentos. Si uno o varios atributos de una sección tabular se incluyen en la asignación, un documento se registra en una secuencia varias veces, una para cada combinación única de valores de atributo. Si los atributos de diferentes secciones tabulares se asignan a dimensiones de secuencia, el número de registros es el número de combinaciones únicas de estos valores de atributo de sección tabular. Si todas las secciones tabulares tienen combinaciones únicas de valores de atributo en todas las líneas, el número de registros es N1*N2…*Ni, donde Ni es el número de líneas en una sección tabular.

Para realizar un seguimiento automático de los cambios de datos desglosados por dimensiones de secuencia de documentos, especifique una asignación entre las dimensiones y atributos del registro y las dimensiones de la secuencia de documentos. Tenga en cuenta que los documentos no se registran automáticamente en secuencias al crear una secuencia de documentos o agregar un tipo de documento. Para registrar documentos en una secuencia, debe escribirlos o escribir un procesador de datos que registre documentos en una secuencia.

El mecanismo de secuencia de documentos utiliza dos entidades: registro de documentos en una secuencia y límite de secuencia. 1C:Enterprise crea una tabla de datos para cada entidad. Una tabla de registro almacena los detalles del registro de documentos en una secuencia. Ambas tablas se pueden acceder utilizando el lenguaje de consulta de 1C:Enterprise.

Una tabla de registro tiene los siguientes campos: período, registrador y dimensiones de secuencia. Una tabla de registro de documentos contiene registros con combinaciones de valores de dimensión que son únicos para un solo registrador. En otras palabras, una tabla de registro almacena un solo registro para una combinación específica de valores de dimensión dentro de un solo registrador, pero puede almacenar varios registros con el mismo conjunto de valores de atributo para diferentes registradores. Puede acceder a los datos de la tabla a través del conjunto de registros que describe los registros de documentos en una secuencia. Un objeto de documento tiene una colección de conjuntos de registros que describen su registro en secuencias de documentos. 1C:Enterprise utiliza los conjuntos de registros de esta colección para registrar documentos en secuencias cuando se están escribiendo los documentos. Tenga en cuenta que cuando se borra el registro, el registro en las secuencias de documentos no se borra. Sin embargo, un documento no registrado no participa en la restauración de la secuencia. En todos los demás aspectos, las operaciones con conjuntos de registros que describen los registros de documentos en secuencias son similares a las operaciones con cualquier otro conjunto de registros de registro.

Un límite de secuencia indica un punto en el tiempo (límite) después del cual los documentos se registran incorrectamente. La estructura de la tabla de límites es similar a la estructura de la tabla de registro, pero su contenido y significado son diferentes. A diferencia de las tablas de registro, las tablas de límites solo contienen registros que tienen conjuntos de valores de dimensión únicos. En otras palabras, solo hay un registro para una combinación específica de valores de dimensión. Un período y un registrador especifican el punto en el tiempo de un límite por dimensiones específicas. El contenido de una tabla de límites de secuencia solo se puede cambiar a través de un objeto de administrador de secuencia de documentos.

Procedimiento de escritura de documentos:

Iniciar una transacción

    Llenar los conjuntos de registros que describen el registro de documentos en una secuencia

    Llamar al procedimiento predefinido BeforeWrite()

    Escribir el documento

    Llamar al procedimiento predefinido OnWrite()

    Escribir conjuntos de registros de documentos que han cambiado pero aún no se han registrado

        Verificar y mover los límites de secuencia al punto en el tiempo de estos conjuntos de registros (esta acción se realiza en un conjunto de registros, no en un documento)

    Escribir conjuntos de registros que describan el registro del documento en una secuencia que ha cambiado pero aún no se ha registrado

Finalizar una transacción

Procedimiento de escritura de documentos con registro

Iniciar una transacción

    Llenar los conjuntos de registros que describen el registro del documento en una secuencia

    Llamar al procedimiento predefinido BeforeWrite()

    Escribir el documento

    Llamar al procedimiento predefinido OnWrite()

    Llamar al procedimiento predefinido Posting()

    Escribir conjuntos de registros del documento que han cambiado pero aún no se han registrado

        Verificar y mover los límites de secuencia al punto en el tiempo de estos conjuntos de registros (esta acción se realiza en un conjunto de registros, no en un documento)

    Escribir conjuntos de registros que describan el registro del documento en una secuencia que ha cambiado pero aún no se ha registrado

    Verificar y mover los límites de secuencia al punto en el tiempo de estos conjuntos de registros

Finalizar una transacción

Procedimiento de escritura de documentos con registro eliminado

Iniciar una transacción

    Llenar los conjuntos de registros que describen el registro del documento en una secuencia

    Llamar al procedimiento predefinido BeforeWrite()

    Llamar al procedimiento predefinido UndoPosting()

    Eliminar conjuntos de registros

        Verificar y mover los límites de secuencia al punto en el tiempo de estos conjuntos de registros (esta acción se realiza en un conjunto de registros, no en un documento)

    Escribir un documento

    Llamar al procedimiento predefinido OnWrite()

    Escribir conjuntos de registros que describan el registro del documento en una secuencia que ha cambiado pero aún no se ha registrado

Finalizar una transacción

Tenga en cuenta que el movimiento hacia atrás de un límite de secuencia (desplazamiento del límite) solo puede ocurrir cuando se escriben conjuntos de registros de registro con límites que son mayores (más tarde) que el tiempo del conjunto de registros. El movimiento hacia adelante de un límite de secuencia (restauración del límite) solo puede ocurrir cuando se publica un documento con límites que son menores (más temprano) que el tiempo del documento, y solo si no hay otros documentos pertenecientes a esa secuencia entre el límite de secuencia y el documento que se está publicando (para que no sea necesario volver a publicar documentos). En resumen, el desplazamiento automático del límite solo puede ocurrir cuando se cambian los datos del registro, independientemente del origen del conjunto de registros que cambia los datos (puede o no ser generado por el documento). Una secuencia se restaura automáticamente solo durante la publicación del documento. Escribir un documento, registrar un documento en una secuencia o publicar un documento no puede desplazar un límite de secuencia. Solo un cambio de registro puede desplazar un límite.

Los desarrolladores de aplicaciones pueden utilizar los métodos de script de 1C:Enterprise para establecer límites en puntos arbitrarios en el tiempo. También pueden obtener los límites de secuencia actuales, verificar si un límite de secuencia está desplazado, verificar si un documento pertenece a una secuencia y restaurar secuencias.