Opciones funcionales. Principio de funcionamiento y ejemplo de uso. Opciones funcionales (1Cv82) 1c cómo habilitar una opción funcional

Las opciones funcionales son un objeto de metadatos ubicado en el grupo "General":

Las opciones funcionales son parte del mecanismo de opciones funcionales, que permiten habilitar o deshabilitar algunas funcionalidades en la solución de la aplicación según las necesidades del usuario, sin modificar la configuración en sí.
Por ejemplo, no todas las organizaciones pueden utilizar la contabilidad de almacén. Si no se utiliza la contabilidad de almacén, entonces tiene sentido eliminar el campo de almacén de todos los documentos, directorios y registros; ahí es cuando las opciones funcionales nos ayudan.

Veamos un ejemplo:

Creemos una opción funcional " Contabilidad por Almacenes".
Almacenamiento: se indica el campo que almacena el valor.
Puede seleccionar una constante, un atributo de directorio o un recurso de registro de información.
Usaremos una constante.

Creemos una constante " Llevar cuentas de almacenes" y selecciónelo en el campo de almacenamiento. Esta constante será la encargada de habilitar y deshabilitar la opción funcional. Marque la casilla "Modo privilegiado al recibir". Esta casilla significa que los valores de la opción funcional se recibirán en modo privilegiado. :

Actualizamos, lanzamos 1C Enterprise. Establezca el valor de la constante = Verdadero:

Como resultado tenemos:

Al establecer la constante = False, obtenemos:

¿Tiene alguna pregunta o necesita ayuda de un consultor?

Entonces, hemos creado una opción funcional que controla campos del tipo DirectoryLink.Warehouse

Veamos ahora un ejemplo del uso de parámetros de opciones funcionales.
Agreguemos una nueva opción funcional " Contabilidad de divisas"
Almacenamiento: Directorio.Organización.Detalles.Contabilidad de divisas

Agreguemos a la composición del documento los detalles "Configuración de precios de artículos" - "Moneda"

En forma de Documento en los procedimientos "Cuando se crea en el servidor" y "Organización cuando se cambia"
Agreguemos el siguiente código:

Actualizamos la configuración y la lanzamos.
Creamos dos Organizaciones y para una de ellas marcamos la casilla “Contabilidad de divisas”

¿Qué obtenemos como resultado? Como resultado del uso de los parámetros de la opción funcional, recibimos control paramétrico del campo "Moneda" en el documento "Configuración de precios de artículos". Aquellos. para la organización "Alfa" se mostrará el campo "Moneda" y para la organización "Beta" no se mostrará el campo "Moneda".
Asegurémonos de esto. Abra el documento e intente cambiar el campo "Organización".
Al configurar Organización = "Alfa", se muestra la moneda; cambiar a "Beta" - se elimina la moneda

.
"1C:ERP Enterprise Management" es una solución innovadora para construir sistemas de información complejos para gestionar las actividades de empresas multiindustriales, incluidas aquellas con producción multiproceso técnicamente compleja, teniendo en cuenta las mejores prácticas nacionales e internacionales en automatización de grandes y medianas empresas. medianas empresas.
Algunas infografías:

A día de hoy (marzo de 2016), más de 900 empresas se han convertido en usuarios de 1C:ERP y su número está creciendo. Al mismo tiempo, varias docenas de proyectos, desde el punto de vista de los desarrolladores, recibieron el estatus de "piloto", es decir. Estas empresas y organizaciones participan principalmente activamente en el desarrollo de nuevas funciones y brindan comentarios rápidamente.
Aquí están los logotipos de algunos usuarios de 1C:ERP:


Una característica interesante de la solución 1C:ERP es que estamos desarrollando una solución- 1C:ERP – y de sus fuentes obtenemos automáticamente cuatro soluciones(al “recortar” la funcionalidad y cambiar las opciones funcionales):


Al ampliar el negocio o aumentar las necesidades de automatización de la empresa, el aumento de la funcionalidad del sistema se puede realizar por etapas, pasando de la configuración "Gestión Comercial" a la configuración "Automatización Integral" y luego a "ERP Enterprise Management 2". Debido al alto grado de unificación de soluciones, dicha transición se lleva a cabo rápidamente, los datos acumulados en la base de información se guardan y no es necesario volver a capacitar a los usuarios: continúan trabajando en el entorno familiar de software e información.

Cómo se escribe 1C:ERP

¿Cómo convertimos una decisión en cuatro?

El desarrollo se realiza en una sola sucursal (ERP). Se automatiza el proceso de formación a partir de la solución ERP insignia "más liviana", con automatización integrada funcionalmente limitada (en adelante, KA para abreviar) y dos tipos de gestión comercial (en adelante, UT y UT Basic).
Los cambios de ERP a configuraciones "derivadas" (KA, UT, UT Basic) se transfieren automáticamente, utilizando un mecanismo para comparar y fusionar configuraciones. Inicialmente, este mecanismo está destinado a automatizar el proceso de transición a nuevas versiones de soluciones de aplicaciones para aquellos usuarios que cambian/amplian la funcionalidad de la solución de aplicaciones por su parte. El mecanismo de comparación y fusión de configuraciones realiza una fusión semántica de tres vías basada en el análisis de tres configuraciones:

• configuración antigua del proveedor
• nueva configuración del proveedor
• configuración de usuario actual (configuración anterior del proveedor más cambios realizados por el usuario)

Como resultado, obtenemos una nueva configuración actual que combina nueva funcionalidad (introducida por el desarrollador) y conserva las modificaciones (personalizaciones) realizadas por el usuario.
En nuestro caso, el papel de la configuración actual lo desempeñan alternativamente KA, UT, UT Basic, y el papel de las configuraciones antiguas y nuevas del proveedor lo desempeñan las versiones antigua y nueva del ERP, respectivamente. Aquellos. Creemos que las configuraciones funcionalmente limitadas (KA, UT, UT Basic) son versiones personalizadas (principalmente eliminando objetos no utilizados) de ERP.


Uno de los pocos objetos que se escriben manualmente para cada solución son los planes de intercambio, que definen las reglas para integrar esta solución con otras soluciones 1C (por ejemplo, con 1C: Document Flow) o, por ejemplo, con equipos externos. Pero, gracias a la transición gradual en el intercambio de datos a un único estándar EnterpriseData, estamos reduciendo la cantidad de planes de intercambio exclusivos de una solución específica e intentando utilizar un único código de intercambio de datos.
Hay una característica interesante en este enfoque. La solución completa se escribe una vez, en la rama ERP; pero la mayor parte del código, formularios, scripts, informes, etc. se utiliza en cuatro soluciones, y en otras muy diferentes: ERP se implementa en empresas con miles de usuarios y UT Basic está diseñado para atender a empresarios individuales. Intentamos prestar mucha atención a la usabilidad de nuestro producto.
La norma internacional ISO 9241-11 define usabilidad como:

el grado en que se puede utilizar el producto ciertos usuarios en un determinado contexto de uso para alcanzar determinados objetivos con la debida eficiencia, productividad y satisfacción

Intentamos escribir la aplicación de tal manera que sea fácil y conveniente trabajar con ella incluso para un usuario sin experiencia.

Funciones de desarrollo

Al desarrollar un ERP, siempre debemos recordar que la funcionalidad que se está desarrollando se puede utilizar en una o más soluciones derivadas de un ERP (KA, UT, UT Basic). Para habilitar/deshabilitar fácilmente la funcionalidad, utilizamos ampliamente el mecanismo de opciones funcionales, creado originalmente para tales tareas. Las opciones funcionales le permiten seleccionar funcionalidades en una solución de aplicación que se pueden activar o desactivar durante la implementación sin cambiar la solución de aplicación en sí. Las opciones funcionales son configuraciones de solución, casillas de verificación que, cuando están desactivadas, hacen que todas las funciones asociadas no estén disponibles. En primer lugar, las opciones funcionales se utilizan para ajustar el programa a las necesidades de una implementación específica. En ERP, utilizamos este mecanismo (además de su propósito principal) para "eliminar" configuraciones derivadas del ERP. Por ejemplo, en una solución ERP existe una opción funcional "Gestión empresarial", a la que están asociadas todas las funciones responsables de la gestión de la producción: crear un cronograma de producción, contabilizar los costos de producción, informes relevantes y mucho más. Esta opción está habilitada solo en la solución 1C:ERP y deshabilitada en las soluciones “derivadas” KA, UT, UT Basic. En total, 1C:ERP utiliza alrededor de 600 opciones funcionales.
Otro mecanismo de plataforma que facilita el trabajo de un desarrollador de 1C:ERP es el . Los subsistemas son una forma de dividir la funcionalidad de una solución en bloques; Cada objeto de la solución (directorio, documento, informe, etc.) debe estar incluido en al menos un subsistema. En particular, la solución ERP cuenta con tres subsistemas que facilitan la construcción de soluciones derivadas de ERP:

1. Los “objetos UE, UT, KA” son objetos incluidos en todas las soluciones de aplicaciones: Gestión Comercial, Automatización Integrada, Gestión Empresarial (nombre ruso ERP).
2. “Objetos UE, CA”: objetos que se relacionan únicamente con las configuraciones de Automatización Integrada y ERP.
3. “Objetos PM”: objetos relacionados únicamente con la solución ERP

Cualquier objeto de aplicación en una solución ERP debe pertenecer SÓLO a UNO de estos tres subsistemas. Esta condición se verifica analizando estáticamente el código de la solución ERP (ver más abajo).

Números después del punto decimal

La versión de un producto ERP consta de cuatro números separados por puntos. Por ejemplo: 2.1.3.117.

• El primer número (edición) de la versión cambia muy raramente (por ejemplo, KA 1.x.x.x y KA 2.x.x.x están separados por casi 8 años).
• El segundo número (subedición) cambia aproximadamente una vez al año. Se lanza una nueva funcionalidad en la nueva versión subeditada. El lanzamiento de dichas versiones a menudo se programa para que coincida con el comienzo del año calendario, de modo que los usuarios tengan tiempo suficiente para "migrar" a la nueva versión.
• En las versiones con un nuevo tercer número (lanzamiento), se desarrolla la funcionalidad existente; sale una nueva versión aproximadamente cada dos o tres meses.
• Las versiones con un cuarto número actualizado (builds de corrección) contienen únicamente correcciones de errores y actualizaciones para cumplir con la legislación vigente. Salen cada dos semanas.

Podemos tener hasta 3 versiones de un producto en desarrollo a la vez, por ejemplo:

1. 2.1.3.X: versión compatible de la subedición anterior. Se producirá hasta finales de 2016. Esta versión contiene únicamente correcciones de errores y cambios para cumplir con la legislación vigente.
2. 2.2.1.X – Versión actual de la subedición actual. Tiene una nueva funcionalidad de subedición. Se lanzarán compilaciones correctivas antes del lanzamiento de 2.2.2.X.
3. 2.2.2.X – Desarrollo de la funcionalidad de la subedición actual. Esta versión se está desarrollando activamente.

Teniendo en cuenta que de cada rama de ERP, además de ERP, se obtienen 3 soluciones más - KA, UT y UT Basic - obtenemos 12 versiones de productos ubicadas en 12 repositorios diferentes.
Durante el desarrollo tenemos hasta 4 horizontes de planificación, por ejemplo:

1. 2.1.3 (compatible), decidimos qué errores se corregirán, qué proyectos relacionados con cambios en la legislación implementaremos. Sólo se implementarán aquellos cambios que entren en vigor en 2016. Horizonte – hasta finales de 2016
2. 2.2.1 (compatible): se corrigen errores "externos" + cambios legislativos que entran en vigor antes del lanzamiento de 2.2.2. Horizon: hasta el lanzamiento de 2.2.2.
3. 2.2.2 (en desarrollo activo): se corrigen errores "externos" + errores que encontramos + se implementa nueva funcionalidad. Horizonte - hasta la versión 2.2.3
4. 2.2.3 (previsto). Si el proyecto es grande, se puede desarrollar inmediatamente para esta versión (y no se incluirá en la anterior). Horizon: hasta el lanzamiento de 2.2.4 o hasta finales de 2017.

Uso del producto “1C: Sistema de diseño de soluciones de aplicaciones” en el desarrollo de ERP

Como ya se mencionó, en 1C intentamos seguir el principio Come tu propia comida para perros, utilizando nuestros propios productos en nuestros procedimientos internos. En particular, en el desarrollo de ERP utilizamos ampliamente el producto "1C: Sistema de diseño de soluciones de aplicaciones" (abreviado como SSPR). DSS, como su nombre indica, ayuda a diseñar soluciones de aplicaciones en la plataforma 1C:Enterprise y le permite realizar las tareas del ciclo completo de desarrollo de software: recopilación de requisitos, control de cambios, documentación, seguimiento de errores, etc.
El DSS le permite crear dos tipos de elementos: errores (que deben corregirse) y requisitos (solicitudes de nueva funcionalidad). Todo está más o menos claro con los errores, consideremos crear un nuevo requisito.
El motivo para crear un requisito puede ser:

1. Solicitud de un socio o cliente. Recopilamos dichas solicitudes, en particular, en seminarios de socios; Al votar entre socios, destacamos los de mayor prioridad.
2. Durante un proyecto piloto puede surgir una solicitud para introducir una nueva versión si el cliente tiene un deseo importante.
3. Una solicitud de nuestro servicio de soporte técnico (más precisamente, una solicitud de un socio o cliente que pasó por nuestro soporte técnico), una solicitud de nuestro foro de socios o de nuestro gerente de cuenta (que acompaña a un cliente/clientes que es importante para nosotros) .
4. Solicitud del equipo de desarrollo de la plataforma 1C:Enterprise. El equipo de la plataforma solicita al equipo de desarrollo de ERP (y otras configuraciones estándar) que utilicen nuevas funciones de la plataforma, por ejemplo, la interfaz Taxi, el rechazo de ventanas modales, el rechazo de llamadas sincrónicas, etc.
5. Refactorización, optimización de arquitectura, mejora de usabilidad.

El motivo de la refactorización (elemento 5) pueden ser cambios arquitectónicos graves (por ejemplo, una revisión de las órdenes de envío, cuando comenzaron a utilizarse órdenes en lugar de facturas).

El producto DSS se suministra como parte del ERP (pero también se puede adquirir por separado). La solución ERP se puede iniciar en modo de integración con el DSS; en este caso, en cada formulario habrá un botón “Abrir modelo funcional”, al hacer clic se abrirá una descripción de la funcionalidad del formulario en el DSS.


Esto es lo que se abre: este es el modelo de lugar de trabajo en IDEF0:


Puedes hacer lo contrario: estudiar el modelo funcional y descubrir las formas de trabajo a partir de él. Este modo se puede utilizar al estudiar cómo funciona el programa.
Un punto importante es que no es el DSS el que abre, abre un formulario dentro del ERP, donde se cargan los datos del DSS. Aquellos. la integración es “perfecta” (el usuario no la ve). Esta técnica se utiliza cuando se integra con otros productos. Por ejemplo, con 1C: Document Flow (puedes trabajar sin salir de ERP con correo, tareas, procesos de negocio que funcionan en otra base de datos).

Cómo desarrollamos ERP: 6 hitos del proyecto

Entonces, se decidió implementar un nuevo requisito para cambiar la funcionalidad. Requisitos similares se combinan en proyectos técnicos. Como parte de una nueva versión de ERP, normalmente se implementan de 100 a 150 proyectos técnicos, cada proyecto tiene entre una y varias docenas de requisitos. El proyecto técnico se ingresa al DSS; Durante la implementación, el proyecto pasa por 6 puntos de control, cada uno de ellos queda registrado en el DSS.
Un poco sobre la división en equipos dentro de la división ERP. El líder del equipo (líder del equipo) participa en el diseño y, por regla general, participa en el desarrollo. El equipo suele incluir también probadores. Los equipos de desarrollo son estáticos; se les asignan varias áreas temáticas. Si el proyecto involucra áreas relacionadas, los miembros del equipo relevante participan durante la implementación del proyecto. No todo el equipo puede estar involucrado en el proyecto.
La persona responsable del proyecto es el desarrollador principal o el líder del equipo. Es responsable del control de procesos:

• Diseño de alta calidad, teniendo en cuenta todos los escenarios posibles, combinándolos con bloques adyacentes.
• Plazos
• Calidad de arquitectura, interfaz de usuario.
• Redacción de un certificado, diseño de un proyecto, incl. desarrollo de un modelo funcional

Punto 1. Abrir un proyecto

El líder del equipo ingresa proyectos técnicos en el DSS con una lista para su publicación. Cada proyecto describe objetivos e indica los requisitos a implementar. La lista se analiza con el director de desarrollo antes de comenzar a trabajar en el lanzamiento. En realidad, al abrir un proyecto, no se llevan a cabo reuniones; el proyecto simplemente se envía al DSS para su apertura.
El equipo del proyecto comienza a desarrollar el concepto.

Punto 2. Coordinación del concepto

Para acordar el concepto se realiza una reunión online u offline, en la que participan el responsable del proyecto, el líder del equipo, el responsable de desarrollo y los especialistas involucrados en el proyecto. Generalmente, en esta etapa, el responsable del proyecto tiene listo un concepto de “gran bloque”, que se ultima durante la reunión. También se analizan (y se escriben en el DSS) escenarios y una descripción de la interfaz de usuario. Si el requisito surgió de una solicitud de socios o clientes, entonces los materiales del proyecto (conceptos, guiones, interfaz de usuario) se pueden enviar al socio/cliente para evaluar la solución.
Durante la reunión, se acuerda la intensidad del trabajo necesario para crear un prototipo (normalmente la creación de un prototipo lleva hasta 5 días hábiles). El equipo comienza a crear un prototipo.

Punto 3. Coordinación de prototipos

Se lleva a cabo una reunión durante la cual se revisan los prototipos ya preparados, se discuten los detalles de implementación (en particular, qué objetos se agregarán y cambiarán), se prueban hipótesis, se aprueban formularios de prototipos, etc. Para las pruebas de usabilidad más serias, los prototipos se lanzan en el modo más "duro": en el cliente web, en la interfaz Taxi, en monitores de baja resolución.
El modelo funcional del proyecto en notación IDEF0 se desarrolla y almacena en el DSS.
En esta etapa, el equipo del proyecto debe estimar los costos laborales para implementar el proyecto con la mayor precisión posible, de modo que todos los aspectos del proyecto se discutan (y se documenten en el DSS):

• Acordar la exactitud de la descripción del proyecto en el DSS (en particular, se controla que se hayan completado todas las tareas en los hitos anteriores del proyecto).
• Qué nuevos objetos de metadatos (directorios, documentos, etc.) se agregarán a la solución
• ¿Qué cambios se realizarán en los objetos de metadatos existentes?
• Coordinación de planes de intercambio de datos con otras soluciones (si los datos nuevos o modificados participarán en el intercambio de datos con otras aplicaciones y, de ser así, cómo exactamente)

Si todos están satisfechos con los costes laborales, se realiza una presentación (basada en los materiales del proyecto del DSS) de todo lo que se ha hecho para el proyecto, con el fin de identificar tantos matices como sea posible antes de comenzar el desarrollo.
¡Y comienza el desarrollo!

Punto 4. Aprobación de la solución desarrollada

Se ha desarrollado la solución y se ha preparado una presentación (en formato PowerPoint). A menudo se lleva a cabo una reunión cara a cara con una demostración "en vivo" de la solución desarrollada.
Si el proyecto es público (publicado en la lista de planes disponibles para los socios en el sitio web de 1C), la presentación se publica en el foro de socios en la sección ERP para que todos los socios interesados ​​puedan familiarizarse y expresar sus comentarios.

Punto 5. Pruebas y auditoría del proyecto.

Una vez finalizado el desarrollo principal, se ejecutan pruebas funcionales manuales. Los evaluadores, como miembros de pleno derecho del equipo, participan en todos los puntos de control del proyecto y comprenden la funcionalidad y los escenarios de trabajo del proyecto. Los evaluadores también evalúan la nueva funcionalidad comparándola con nuestros estándares de usabilidad. Estos estándares (incluidos los estándares de codificación y los estándares de desarrollo de interfaces) se publican en un recurso disponible para socios y usuarios registrados en el sitio web de 1C.
El código del proyecto pasa por el procedimiento de revisión del código. Las revisiones de código en ERP las llevan a cabo miembros de otro grupo de proyecto; La revisión del código es una responsabilidad que todos los desarrolladores del equipo de ERP se turnan para realizar. Si se encuentran problemas en el código, se registran errores en el DSS, que deben corregirse antes de pasar el punto 5.
Se está comprobando que la actualización sea una nueva versión con la anterior (la última versión publicada actualmente).
Entonces, el proyecto está listo, las pruebas han sido pasadas, es hora de cargar el código en el repositorio principal (antes de eso, todo el desarrollo se lleva a cabo en un repositorio separado del proyecto técnico). En esta etapa también finaliza la redacción de materiales de referencia sobre la nueva funcionalidad (la referencia se almacena en el DSS).
Al final de la etapa (se han superado las pruebas y los materiales de referencia están listos), el proyecto se carga en el repositorio principal; A esto le siguen pruebas de regresión aleatoria en áreas relacionadas para asegurarnos de que no rompamos ninguna funcionalidad existente.

Punto 6. Fin del proyecto

Cerramos el proyecto en el DSS y le asignamos el estado “Completado”.

Versión de lanzamiento

Aproximadamente un mes antes del lanzamiento de una nueva versión, se impone una moratoria sobre la carga de nuevos proyectos al repositorio principal (el desarrollo en los repositorios de proyectos técnicos continúa); aquellos proyectos que no finalizaron en ese momento se transfieren a otra versión.
Durante este mes se realizan pruebas de regresión; Se permiten cambios en el código únicamente para corregir errores introducidos en esta versión. Los errores no introducidos (aquellos que también se reprodujeron en versiones anteriores) generalmente se solucionan casi todos al inicio de las pruebas de regresión; los mismos errores que quedan se trasladan a la siguiente versión. El objetivo principal de las pruebas de regresión es garantizar que la calidad del producto no se deteriore.
Como ya se mencionó, el mismo DSS se utiliza como rastreador de errores.

Asambleas correccionales

Cada dos semanas publicamos versiones corregidas para las versiones; hoy es 2.1.3.x, después del lanzamiento de 2.2.1, se lanzarán 2 conjuntos correctivos: 2.1.3.x y 2.2.1.x. Nos lleva menos de dos semanas desde que informamos un error hasta que aparece en una versión corregida; Nuestras estadísticas muestran que el tiempo promedio desde que un cliente contacta al soporte con un error en ERP hasta el lanzamiento de su solución en la versión del parche hoy es de 9 días.

Desarrollo ramificado

En el trabajo grupal sobre ERP, intentamos utilizar las herramientas que nos proporciona la plataforma 1C:Enterprise. Las configuraciones se almacenan en un repositorio de configuración y, cuando se registra una nueva funcionalidad en una sucursal, se utiliza el mecanismo estándar de entrega y soporte. Todas las operaciones están automatizadas al máximo; Si los objetos se cambiaron sólo por parte del desarrollador, el código se fusiona sin la participación del programador. Si se necesita la intervención del desarrollador para fusionar fuentes, normalmente utilizamos las capacidades integradas de la plataforma. Pero también existe la posibilidad de llamar a herramientas de comparación/fusión de terceros desde las herramientas de la plataforma (por ejemplo, o Araxis). Por cierto, esta característica (llamar a herramientas de comparación/fusión de terceros) se agregó a la plataforma a pedido del equipo de desarrollo de ERP.

Misceláneas

Al desarrollar nuevas funciones, utilizamos la versión de la plataforma que estará disponible en el momento del lanzamiento de la nueva versión del ERP (hoy es la plataforma 8.3.8).
Esto es posible debido al hecho de que la plataforma utiliza activamente el modo de soporte para compatibilidad con versiones anteriores. Tan pronto como aparece una nueva plataforma, cambiamos a ella, pero la desactivación del modo de compatibilidad no ocurre de inmediato. Esto se debe a tres razones:

1. Queremos "sorprender menos" a los usuarios, por lo que intentamos desactivar el modo de compatibilidad durante los períodos "tranquilos" y no cuando todos los usuarios, por ejemplo, están enviando informes.
2. Normalmente, la desactivación de la compatibilidad está asociada con varios cambios de configuración. Es necesario planificarlos y llevar tiempo implementarlos.
3. ERP es una configuración que actualmente incluye 10 bibliotecas. Puede desactivar la compatibilidad sólo cuando todas las bibliotecas también lo hagan.

Puede escribir sobre bibliotecas por separado. Una biblioteca es una configuración especialmente escrita que incluye funciones que deberían funcionar de la misma manera en nuestras diversas soluciones de aplicaciones finales. La integración de bibliotecas se lleva a cabo utilizando el mecanismo ya mencionado de la plataforma "Configuration Delivery". Las bibliotecas se dividen en publicadas (aquellas que publicamos y que los desarrolladores externos pueden utilizar en sus soluciones de aplicaciones) e internas (que no publicamos por separado, solo como parte de las soluciones de aplicaciones). La gran mayoría de las bibliotecas están publicadas.
El ERP incluye 10 bibliotecas desarrolladas por otros equipos. Los desarrolladores del equipo ERP no modifican su código.

Lista de bibliotecas

1. Biblioteca de subsistemas estándar.
   Funcionalidad básica: derechos de acceso, impresión, correo, etc. Incluido en la mayoría de las soluciones de aplicaciones.
2. en ERP
3. Biblioteca de soporte al usuario de Internet.
   Informar sobre el lanzamiento de actualizaciones, contactar con el soporte técnico. soporte, descarga e instalación de actualizaciones
4. Biblioteca de gestión de documentos electrónicos.
   Intercambio de documentos electrónicos con contrapartes (incluido EDI legalmente significativo), DirectBank (intercambio directo con bancos), intercambio con sitios web (CMS).
5. Biblioteca para integración con EGAIS.
   Intercambio con el Sistema de Información Automatizado del Estado Unificado para la contabilidad de transacciones minoristas de alcohol.
6. Biblioteca de contabilidad regulada.
   “Pieza” 1C: Contabilidad en ERP. En general, la contabilidad regulada en ERP en la parte metodológica (con algunas pequeñas excepciones) es similar a 1C: Contabilidad, pero su implementación es diferente y se realiza de forma independiente. Desde 1C:Accounting tomamos informes contables y sobre algunos impuestos.

Cómo probamos 1C:ERP

Después de crear tres soluciones de ERP (KA, UT, UT Basic) para verificar la exactitud de las cuatro soluciones, realizamos un análisis estático y dinámico de las configuraciones resultantes.
El análisis estático parcial se lleva a cabo cada vez que las configuraciones KA, UT, UT básica se crean desde el almacenamiento del ERP y se cargan en sus propios almacenamientos (este proceso se realiza dos veces al día).
Se realiza un análisis estático más detallado utilizando la configuración 1C: Verificación automática de configuración (1C: APK). En particular, 1C:APK comprueba:

• Composición de roles. Por ejemplo, verifica que los derechos de lectura para todas las constantes estén incluidos en la función de Derechos básicos.
• Cumplimiento del código con estándares aceptados. Para una gran cantidad de estándares de desarrollo de aplicaciones (de los cuales tenemos varios cientos), se han escrito procedimientos para analizar el código para verificar su cumplimiento. Por ejemplo, que las combinaciones completas no se utilicen en las consultas o que las cadenas que se muestran en la interfaz estén localizadas correctamente.
• Comprobaciones específicas relacionadas con las funciones de desarrollo de ERP.
  Por ejemplo, comprobar que cada objeto de aplicación esté incluido en solo uno de los subsistemas “Objetos UT, SC, UE”, “Objetos CA, UE” u “Objetos UE”.

El análisis de código dinámico incluye, en particular, pruebas de regresión, dentro de las cuales se ejecutan las siguientes operaciones (y los resultados de las operaciones se comparan con la última prueba anterior exitosa):

• Abriendo todos los formularios
• Intercambio de datos con otras soluciones de aplicaciones (por ejemplo, con 1C: Enterprise Accounting)
• Reflejo de documentos cumplimentados en contabilidad. Se verifica que luego de la contabilización del documento en la base de datos de referencia, el resultado de su reflejo en contabilidad no haya cambiado.
• Y etc.

Para las pruebas de regresión utilizamos de 10 a 20 bases de datos de varios tamaños (de 15 GB a 70 GB) y diferentes contenidos específicos.
Utilizando las mismas bases de datos, probamos la actualización a una nueva versión de la anterior, para asegurarnos de que la actualización se realiza a) correctamente yb) en un tiempo razonable.
Al actualizar una base de datos 1C, se distinguen dos etapas esenciales:

1. El tiempo principal es la actualización de datos en modo multiusuario. La solución de la aplicación prepara los datos para la actualización en segundo plano; los usuarios pueden continuar trabajando con el sistema, pero el rendimiento del sistema puede verse reducido y algunas funciones pueden funcionar de manera limitada. Normalmente, la actualización a una nueva versión se realiza los fines de semana (cuando la actividad del usuario es mínima).
2. Tiempo mínimo - actualización en modo exclusivo. Cuando todos los datos estén preparados en segundo plano, es hora de cambiar la estructura de la base de datos. Para ello, la base de datos se transfiere al modo exclusivo, cuando los usuarios no pueden trabajar con el sistema. La velocidad de actualización es extremadamente importante para nuestros usuarios.

Nuestros planes inmediatos incluyen ampliar el área de autotesting para cubrir el máximo número de escenarios.

Conclusión

ERP es uno de nuestros productos más importantes. Intentamos utilizar técnicas modernas y avanzadas en su desarrollo, así como crear nuevas técnicas y herramientas para, por un lado, desarrollarlo rápidamente y, por otro, garantizar la alta calidad de la solución desarrollada.

Etiquetas:

Agregar etiquetas

Con el lanzamiento de la plataforma 1C:Enterprise 8.2, apareció un nuevo objeto en el árbol de configuración: "Opciones funcionales". Se utiliza activamente en todas las configuraciones estándar basadas en formularios administrados y sirve para simplificar el proceso de visualización de detalles y objetos individuales en la interfaz. Por ejemplo, en su configuración hay un módulo para intercambiar con servicios web externos. Este módulo utiliza una serie de detalles en documentos, registros y componentes individuales en subsistemas. El módulo es opcional y no necesario para todas las empresas. Es lógico que, dado que no todo el mundo necesita un módulo, tampoco siempre es necesario mostrar todos los elementos/campos asociados a él.

En versiones anteriores de la plataforma, resolver este tipo de problemas requería escribir código adicional, que debía ejecutarse en todas las áreas dependientes. Por ejemplo, si necesitábamos ocultar ciertos detalles del formulario (según el valor de configuración), entonces necesitábamos llamar al código correspondiente al abrir el formulario. Esto no fue muy conveniente y en la mayoría de los casos los desarrolladores abandonaron tales cosas.

Es bueno si solo necesitas ocultar campos en forma de documentos, pero también podemos tener formularios de registro con los que también es posible la interacción del usuario. Escribir una función de control de visualización universal es bastante difícil y requerirá tiempo adicional, que nunca es suficiente.

Las opciones funcionales están diseñadas para resolver esta y muchas otras dificultades asociadas con la visualización de elementos de la interfaz/la composición de los objetos disponibles en la interfaz de usuario. En esta nota, no consideraré ejemplos del uso del propósito principal de las opciones funcionales, pero llamaré la atención sobre su uso de forma no estándar. Puede que a muchos desarrolladores avanzados les resulte familiar, pero llegué a este método por pura casualidad. Más precisamente, se inspiró en la práctica de la programación en JavaScript.

Caso No. 1: una opción funcional como contenedor sobre otros objetos

La primera característica no estándar de las opciones funcionales es la capacidad de crear contenedores. Veamos el ejemplo más simple: las constantes. Por ejemplo, agrega una nueva constante a una configuración con una gran cantidad de roles de usuario. Para que los usuarios puedan acceder al valor de una constante, es necesario establecer derechos de lectura para los roles apropiados. Si no se establecen los derechos, los usuarios no podrán obtener su valor. Si hay muchos roles y no se heredan del rol base, tendrá que dedicar tiempo a marcar las casillas correspondientes.

Una opción de función puede resolver este problema de manera más elegante. La idea es esta: crear una constante (por ejemplo,). No le asignamos derechos. Cree una opción funcional con el mismo nombre e indíquela en la propiedad "Almacenamiento" indicar una constante "Posibilidad de guardar datos". También ponemos la bandera. "Trato privilegiado al recibirlo".

Eso es todo, ahora en cualquier parte del código donde necesite hacer referencia a una constante escribimos así:

Como hemos configurado la opción en modo privilegiado, no necesitamos especificar ningún derecho adicional para la constante. Por supuesto, no es necesario aplicar esta técnica en todas las situaciones imaginables e inconcebibles. Recuerde, la asignación adecuada de derechos es la clave para la tranquilidad. Utilice el truco sólo en casos realmente necesarios.

Caso No. 2. Nivel adicional de abstracción

No sé cómo llamar más correctamente a este método, pero en mi opinión suena exactamente así. Veamos el ejemplo anterior. Seguimos teniendo la misma constante "Capacidad de guardar datos". Trabajamos con él utilizando la opción funcional del mismo nombre como contenedor.

Ahora imagine que quisiéramos deshacernos de la constante y pasar a utilizar un directorio. Un escenario típico para resolver un problema de este tipo (si utilizamos sólo una constante) sería ejecutar una herramienta de búsqueda global para detectar el acceso a la constante. Permítanme recordarles que si no utilizamos una opción funcional como contenedor, entonces deberíamos tratar la constante así:

Constantes.Capacidad paraSaveData.Get();

Encontramos todas las llamadas y las reemplazamos con la ruta al nuevo objeto de almacenamiento. De acuerdo, esto es bastante inconveniente. Si usamos el caso anterior (usando una opción funcional como contenedor), entonces para “mover” solo necesitamos ir a las propiedades de la opción funcional y cambiar la propiedad "Almacenamiento". Por ejemplo, indique allí "Directorio" o "Registro de información". No se requieren juegos con búsqueda global. El código para acceder al valor de una constante a través de una opción funcional seguirá siendo el mismo:

GetFunctionalOption("Capacidad de ahorro de datos");

Objeto 1c "Opciones funcionales" - están destinados a resaltar la funcionalidad en una solución de aplicación que se puede activar (desactivar) durante la implementación sin cambiar (junto con los subsistemas, forman la interfaz de cliente ligero 1C). Son parte del mecanismo de opciones funcionales.

Mecanismo de opciones funcionales. incluye dos objetos de metadatos:

1. Opción funcional;
2. Parámetros de opciones funcionales.

Más detalles

Opción funcional representa un objeto de metadatos que puede influir directamente en la composición de la interfaz de la aplicación (si la opción funcional almacena su valor en un atributo booleano). Al utilizar objetos de este tipo, puede ocultar elementos relacionados con funciones no disponibles. Por ejemplo, la opción Contabilidad de moneda puede ocultar Monedas, el campo Moneda de y la columna Importe de moneda de los informes.

La fuente del valor de una opción funcional es el objeto de metadatos seleccionado como propiedad de Almacenamiento, por ejemplo podría ser.

Si el valor de una opción funcional se almacena en un atributo o recurso de directorio, se requiere información adicional que indique exactamente cómo seleccionar el valor de la opción. Para ello, se proporciona un objeto de metadatos independiente: Parámetros de opciones funcionales.

Podemos decir que los parámetros de las opciones funcionales son los ejes de coordenadas del espacio de valores de las opciones funcionales. Además, un parámetro de opciones funcionales puede determinar el valor de "su" eje de coordenadas simultáneamente para muchas opciones funcionales.

[colapsar]

Las opciones funcionales pueden tener un impacto:

1. a la interfaz de usuario:
   • global ;
   • detalles (incluidas columnas de detalles del formulario como Tabla de Valores o Árbol de Valor);
   • formar comandos;
2. sobre informes implementados utilizando un sistema de composición de datos;
3. a algoritmos escritos en un lenguaje integrado: es posible obtener los valores de las opciones funcionales del lenguaje integrado y utilizarlos en diversas condiciones, por ejemplo, para reducir la cantidad de cálculos (ver, por ejemplo, ).

¡ATENCIÓN! Si la aplicación cliente funciona con la versión del archivo de la base de datos a través del servidor web, cambiar la opción funcional cambiará la interfaz de usuario solo después de reiniciar el servidor web (reiniciar la aplicación cliente no cambiará la interfaz de usuario).

Propiedades de las opciones funcionales 1C.

• El almacenamiento es un campo en el que debe seleccionar un objeto de tipo booleano. Normalmente se utilizan constantes.
• al recibir, la bandera es responsable de la capacidad de recibir el valor de una opción funcional en modo privilegiado.
• Composición: una lista de objetos y detalles de objetos, cuya visibilidad se activa/desactiva cuando se activa/desactiva una opción funcional (se controlará mediante un formulario administrado).

Por ejemplo, dependiendo de las condiciones de una implementación particular, es posible deshabilitar la contabilidad de mercancías por almacén para que al registrar documentos para la entrada de mercancías, el campo Almacén no se muestre en el formulario del documento.

Características del uso de opciones funcionales 1C:

1. Las opciones funcionales pueden tener valores de cualquier tipo (no necesariamente booleanos).
2. Al agregar una nueva constante para usar una opción de función, asegúrese de incluirla en el subsistema apropiado y asignarle permisos.
3. Trabajar con opciones funcionales está disponible desde el lenguaje integrado, gracias al cual el desarrollador puede crear sus propios algoritmos para los valores de las opciones funcionales.
4. El comando de la interfaz de comando se excluirá de la interfaz de comando si la opción funcional está deshabilitada:
   • un atributo que es un parámetro de comando;
   • tipo de parámetro de comando (si el tipo de parámetro de comando es compuesto, entonces el comando deja de estar disponible cuando todos los tipos de parámetros están deshabilitados).

¡ATENCIÓN! Las opciones funcionales y sus parámetros no afectan la composición de la base de datos: todas las tablas y campos están presentes en la base de datos independientemente del estado de las opciones funcionales.

Influencia de las opciones funcionales en los detalles y comandos del formulario:

1. tipo de formulario administrado<Вид>Un objeto ( DirectorioObjeto, DocumentObject, etc.) se desactivará si el objeto correspondiente está desactivado mediante la opción funcional. Sólo se analizan aquellas opciones funcionales que no tienen parámetros.
2. Atributos básicos de un tipo de formulario administrado Lista dinámica se deshabilitará si la opción funcional deshabilita el objeto de configuración que se especifica como la tabla principal de la lista dinámica. Sólo se analizan aquellas opciones funcionales que no tienen parámetros.
3. El atributo de formulario de un tipo de referencia está deshabilitado si el objeto de configuración que forma este tipo está deshabilitado mediante una opción funcional. El atributo de formulario de un tipo compuesto está deshabilitado si las opciones funcionales deshabilitan todos los tipos de constituyentes.
4. Una tabla de formulario se deshabilitará si muestra datos de atributos de formulario que están deshabilitados por una opción funcional.
5. No hay tipos en el cuadro de diálogo de selección de tipo (por ejemplo, para campos de entrada asociados con atributos de un tipo complejo) si los objetos de configuración que forman estos tipos están deshabilitados mediante una opción funcional. La información sobre los tipos deshabilitados por las opciones funcionales se almacena en caché en el lado del cliente y se borra después de 20 minutos o durante una llamada a un método. ActualizarInterfaz().

¡ATENCIÓN! A diferencia de la interfaz de comando, los valores de los parámetros de opciones funcionales se establecen solo para una instancia específica del formulario.

Crear un parámetro de opciones funcionales

Un parámetro de opción funcional se crea utilizando el objeto de configuración 1C "Parámetros de opción funcional".

[colapsar]

Esto se puede hacer en la ventana de configuración agregando un nuevo objeto.

Propiedades de los parámetros de opciones funcionales:

• Uso: configura un conjunto de objetos cuyos valores determinarán cómo se debe seleccionar el valor de una opción funcional. La lista de objetos disponibles incluye directorios y dimensiones de registro de información. Para cada parámetro de opciones funcionales en esta lista, puede seleccionar un directorio (de la lista completa de directorios) y una dimensión de cada registro de información.

¡ATENCIÓN! No puede utilizar el mismo objeto de metadatos en varios parámetros de opciones de función.

Casi todas las soluciones estándar en la plataforma 1C:Enterprise 8.x utilizan el mecanismo de opciones funcionales. Le permite administrar la funcionalidad de configuración bloque por bloque.

Por ejemplo, la opción "Usar pedidos internos" (ver captura de pantalla a la derecha) le permite poner este documento a disposición del usuario para su uso en modo 1C:Enterprise, y también incluye ramas separadas de algoritmos relacionados con esta funcionalidad.

Hoy en el artículo veremos el funcionamiento de las opciones funcionales, su configuración y un pequeño ejemplo de su uso en una configuración de prueba. Comencemos viendo cómo funcionan.

Principio de funcionamiento

Como se mencionó anteriormente, una opción funcional le permite habilitar/deshabilitar la funcionalidad de configuración asociada a ella. Consideremos la secuencia de acciones para crear y configurar este objeto de configuración.

En la rama de configuración "General->Opciones funcionales" podemos crear un nuevo objeto o ver las propiedades de opciones ya creadas. En la configuración de prueba crearemos la opción funcional “EnableImportance”. Al principio, cuando el objeto aún no se ha configurado, la ventana con la lista de sus propiedades se verá así:

Las propiedades "Nombre" y "Sinónimo" tienen un propósito estándar. De particular interés son las configuraciones de "Almacenamiento" y "Composición".

En el campo "Almacenamiento", seleccione un objeto en la configuración del cual la opción funcional recibirá el valor. Normalmente, para estos fines se utilizan constantes booleanas. Según el valor de la constante, la plataforma determinará si habilitará la funcionalidad relacionada o no.

Las opciones de configuración asociadas con una opción funcional se configuran en la pestaña Contenido. La captura de pantalla anterior muestra una lista de objetos que se incluirán en su composición.

Si un objeto de configuración está incluido en varias opciones funcionales, se utilizará en la solución de la aplicación si al menos una de ellas está habilitada.

La opción "Modo privilegiado al recibir" le permite deshabilitar la verificación de derechos de acceso al recibir el valor de una opción funcional, lo que tendrá un impacto positivo en el rendimiento (se eliminarán las operaciones innecesarias de verificación de derechos de acceso) y reducirá la complejidad de futuras desarrollo (no es necesario configurar derechos para el objeto que almacena el valor de la opción funcional).

Ejemplo de uso

En nuestra configuración de prueba, crearemos la enumeración "Importancia", así como una constante

"Habilitar importancia". Los objetos creados se muestran en la siguiente captura de pantalla.

La constante está destinada a almacenar el valor de una opción funcional. La enumeración actuará como el valor del atributo de referencia en el documento de prueba, cuya disponibilidad estará determinada por la opción funcional.

El documento de prueba contendrá dos detalles:

• "Comentario" con tipo "Cadena".
• "Importancia" con tipo "EnumerationRef.Importance".

Agreguemos el atributo del documento "Importancia" a la opción funcional y luego consideremos el comportamiento de la plataforma en modo usuario.

Al iniciar el programa en modo 1C:Enterprise, abra un documento de prueba. No veremos el atributo “Importancia” en el formulario, ya que aún no hemos habilitado la opción funcional.

Para habilitar el uso del atributo "Importancia", debe establecer el valor de la constante "EnableImportance" en VERDADERO. Entonces el formulario cambiará de la siguiente manera:

La funcionalidad de las opciones funcionales se aplica a casi todos los objetos de configuración, con excepción de algunos de la rama "General", que realizan principalmente funciones de servicio. Por ejemplo, no puedes incluir otras opciones funcionales dentro de una opción funcional (y esto no tiene mucho sentido).

Veamos algunos aspectos interesantes de cómo funciona este objeto de configuración:

1. La configuración de opciones funcionales prácticamente no tiene ningún efecto en las consultas SQL generadas por la plataforma.

Por ejemplo, al abrir un documento con una opción funcional deshabilitada, la plataforma en cualquier caso recibe el valor de este atributo en la solicitud. La siguiente captura de pantalla muestra consultas SQL generadas con la opción habilitada y deshabilitada.

2. El elemento de formulario "Importancia" en el formulario, independientemente del valor de la opción funcional, siempre tiene los valores para las propiedades "Visibilidad" y "Accesibilidad" iguales a VERDADERO.

De hecho, tanto al crear un formulario en el servidor como al abrir el formulario, así como durante el trabajo posterior con él, la plataforma no establece automáticamente las propiedades "Visibilidad" y "Accesibilidad" en FALSO. Probablemente 1C:Enterprise 8.x haga esto detrás de escena.

3. Para obtener el valor de una opción funcional, la plataforma genera una consulta SQL al DBMS de acuerdo con el objeto de almacenamiento, es decir a una constante. En uno de los artículos anteriores, ya hablamos sobre la construcción de consultas SQL a constantes y el método para almacenarlas en la base de datos.

En nuestro ejemplo, la plataforma genera la siguiente consulta SQL:

En cuanto al momento de obtener el valor de una opción funcional, la plataforma se guía por el siguiente principio : La primera adquisición del valor de una opción funcional se produce al acceder al objeto/atributo incluido en su composición. Luego, la plataforma utiliza el valor almacenado en caché hasta que se cambia el valor del objeto que almacena este valor (en nuestro ejemplo, las constantes "EnableImportance") o se reinicia la sesión del usuario. El valor de la opción funcional se almacena en caché dentro de una sesión separada.

Todo lo anterior fue verificado experimentalmente. Todo lo que usé para los experimentos está en la configuración de prueba (enlace al final del artículo), con excepción de .

Conclusión

Las opciones funcionales son una parte integral de casi cualquier solución de circulación en la plataforma 1C:Enterprise 8.x. Es gracias a este mecanismo que puedes crear configuraciones con funcionalidad basada en bloques que se pueden activar/desactivar fácilmente al configurar el programa. En este caso, las capacidades del mecanismo se pueden ampliar utilizando parámetros de opciones funcionales, pero este es un tema para otro artículo.

Para tener experiencia con la plataforma, es muy raro utilizar opciones funcionales, ya que el cliente sabe exactamente lo que necesita. Y crear algún tipo de mecanismos universales, por los cuales tendrá que pagar más, además no es un hecho que se utilizarán, es muy raro cuando se finalizan soluciones estándar o se implementan en una empresa específica.

Archivos para descargar: