PrefSuite 2016.1 - Novedades › documents › Spanish › PrefSuite 2016... · 1. Planificador A continuación detallaremos las novedades para esta versión del módulo del planificador

Ronda Guglielmo Marconi, 9 Parque Tecnológico 46980 Paterna, Valencia (Spain)

T (+34) 96 338 99 66 [email protected] www.preference.es

Preference, S.L. NIF B96251988 Registro Mercantil de Valencia, Tomo 4770, General 2080 Folio 145 Hoja V-31996, Inscripción 1ª, Fecha 15/02/1994 Por favor,

recicle

PrefSuite 2016.1 Novedades Noviembre de 2015

PrefSuite 2016.1 | Novedades | 2

Contenidos 1. Planificador ____________________________________________________ 4

1.1. Límites compartidos __________________________________________________ 4

1.2. Nuevo plazo medio de entrega de materiales _______________________________ 5

1.3. Nuevo tiempo de producción para materiales _______________________________ 6

1.4. Definir los valores del punto 1.2 y 1.3 para un grupo de materiales ______________ 7

1.5. Cálculo del planificador “Comercial” ______________________________________ 7

1.6. Ajustes en el calendario del planificador ___________________________________ 8

1.7. Cambios de información al cargar un lote __________________________________ 9

1.8. Huella del tipo de producción __________________________________________ 10

2. Producción: Modelos pendientes de producir _________________________ 13

2.1. Cambios en la vista de modelos pendientes de producir _____________________ 13

2.2. Prevenir la carga en espera de la producción sin filtro _______________________ 13

3. Configuraciones de color _________________________________________ 14

3.1. Migración a las configuraciones de color _________________________________ 14

3.1.1. Migración de estructura de la BD ______________________________________________ 14

3.1.2. Tablas modificadas por el Kernel ______________________________________________ 15

3.1.3. Modificaciones en tablas de usuario ___________________________________________ 16

3.2. Migración de código _________________________________________________ 16

4. Evento OnPDistance ____________________________________________ 18

5. Variables y campos en plantillas ___________________________________ 19

5.1. Datos de la empresa _________________________________________________ 19

5.2. Base imponible en Doc. Ventas ________________________________________ 20

5.3. EAN13 en el informe de material _______________________________________ 21

5.4. Etiqueta para el informe de cortes ______________________________________ 21

6. “Perfil Receptor” en reglas de mecanizado ___________________________ 22

7. Buscar documentos de compra por referencia ________________________ 23

8. Bloquear la edición de campos desde la bandeja ______________________ 24

9. Ventana de mensajes ____________________________________________ 25


10. PrefTSClient en equipos x64 _____________________________________ 26

11. Perfiles compuestos y componentes _______________________________ 27

11.1. Configuración de materiales __________________________________________ 27

11.2. Componentes en las necesidades de material ____________________________ 29

11.2.1. Cambios en la interfaz _____________________________________________________ 29

11.2.2. Documentos de compra desde las necesidades _________________________________ 30

11.2.3. Ensamblado de perfiles ____________________________________________________ 30

12. Informes de agrupación de vidrios _________________________________ 32


1. Planificador A continuación detallaremos las novedades para esta versión del módulo del planificador.

1.1. Límites compartidos La opción de límites compartidos mejora la versatilidad de la herramienta del planificador, añadiendo la

posibilidad de definir un límite compartido para múltiples líneas.

Hasta ahora, cada límite era asignado solo a una línea de producción. De esta manera, cada línea de producción

tenía sus propios límites definidos, y el planificador no podía comprobar la capacidad usada para otras líneas

diferentes de la línea que estaba comprobando.

Los límites compartidos añaden la posibilidad de compartir puestos de trabajo entre múltiples líneas de

producción, sin tener que aplicar un porcentaje fijo de la capacidad de trabajo de cada una de estas líneas.

Es muy sencillo definir un límite compartido. El usuario tiene que abrir el dialogo de definición de límites (en

el menú superior “Varios” > “Producción”, y dentro de este, seleccionar “Limites de producción”). En la

columna “Lista de producción” de la ventana “Limites”, al pinchar el botón “…”, permitirá seleccionar varias

líneas de producción (antiguamente, aparecía un desplegable, de forma que solo se podía seleccionar una línea

de producción por limite definido). Lógicamente, el usuario puede seguir seleccionando una única línea de

producción para el límite a establecer.

Figura 1. Ventana “Límites”.


Figura 2. Seleccionar líneas de producción en la ventana “Límites”.

Una vez que los límites son definidos, la herramienta del planificador asignara a cada una de las líneas

seleccionadas en esta ventana su correspondiente limitación de carga.

1.2. Nuevo plazo medio de entrega de materiales Se ha definido en las propiedades de los materiales un nuevo campo: Tiempo promedio de compras. Este

tiempo promedio de compras será el que utilizará la herramienta del planificador para calcular la fecha de

compra y entrega del material (tomará el mayor valor de todos los materiales).

Este tiempo promedio de compras no depende de ningún proveedor, o unidades de compra determinada por

las necesidades de material. Es un valor medio que dependerá únicamente de la referencia final. Se almacena

como un número entero, y hace referencia a días.

Figura 3. Propiedades de material. Tiempo promedio de compras.


Además, existen algunos materiales que no tendrán un valor constante en este tiempo. Este valor dependerá

del material. Este escenario suele surgir comúnmente en los materiales de tipo vidrio.

Estos materiales podrán ser marcados con el check “personalizado” (ver imagen anterior), para indicar que

tendrán un tiempo de compras dinámico. Cuando este check es marcado, el programa llama a una función SQL

llamada “Material_GetCustomAverageDeliveryTime”, que devolverá el número de días. Esta función tiene la

siguiente estructura:

CREATE FUNCTION [dbo].[Materials_GetCustomAverageDeliveryTime]

(@strReference nvarchar(25), @number int, @version int, @position int, @glassId int)

RETURNS smallint

AS

BEGIN

-- Description: Returns a custom average delivery time in days. This is intended to be

customized, typically for glasses. By default returns 0

RETURN 0;

END

Esta función está vacía en el kernel (siempre devuelve 0), y deberá ser programado por el usuario para

establecer sus casos personalizados.

1.3. Nuevo tiempo de producción para materiales Todos los materiales tienen ahora un nuevo campo llamado “Tiempo extra de producción”. Además, es posible

indicar cuando aplicar este tiempo extra, según lo seleccionado en el campo justo debajo de este, llamado

“Posición tiempo extra”. Sirve para seleccionar si el tiempo extra de producción se debe aplicar antes después

o al mismo tiempo que el tiempo de producción para el resto de la ventana. El tiempo extra de producción

deberá ser indicado en días, mediante un número entero. De esta forma, cuando el planificador calcule el

tiempo de producción, no solo lo hará sobre los tipos de producción de los modelos, sino también en base a

los materiales incluidos en el mismo.

Figura 4. Propiedades del material. Tiempo extra de producción y posición del tiempo extra.


1.4. Definir los valores del punto 1.2 y 1.3 para un grupo de materiales El usuario puede crear un filtro en la lista de materiales (en PrefGest, dentro de Artículos > Materiales), y

aplicar los valores explicados en el punto 1.2 y 1.3 simultáneamente para todos los materiales filtrados. Para

hacer esto, una vez aplicado el filtro deseado, pulsaremos botón derecho sobre la bandeja de materiales. Esta

acción hará que se presente un menú contextual, del cual elegiremos la opción “Actualizar varios registros”.

En la segunda pantalla, aparecerán los nuevos campos para ser editados.

Figura 5. Actualización masiva de materiales con los nuevos campos.

1.5. Cálculo del planificador “Comercial” En los documentos de venta, ahora es posible marcar una fecha de entrega prevista “para clientes” o “fecha de

entrega comercial”. Está basado en datos comerciales, y no en la logística, capacidades o las cargas de trabajo.

En la bandeja de ventas, este campo se llama “CommercialDeliveryDate”. El cálculo de esta fecha se basa

principalmente en los nuevos campos para materiales definidos en el punto 1.2 y 1.3 descritos anteriormente

en este documento: Plazo medio de entrega de materiales y tiempo de producción.

Este campo calculará la mejor fecha de entrega posible, incluso desde el presupuesto o en un pedido de ventas

sin confirmar. Para hacer esto, el usuario pulsará el botón que se encuentra al lado de la fecha (ver siguiente

imagen).

Lógicamente, esta fecha nunca interferirá en el cálculo del planificador, ya que su uso es puramente comercial.

Figura 6. Fecha de entrega comercial.


1.6. Ajustes en el calendario del planificador El calendario del planificador muestra todos los Pedidos programados distribuidos en el día correspondiente

del calendario. Cuando la cantidad de un pedido es demasiado grande, es difícil visualizar la carga en los

distintos días donde ha sido planificado. En esta imagen se muestra el modo anterior a los cambios:

Figura 7. Vista del calendario del planificador en versiones anteriores.

Para solucionar esto, se ha establecido un nuevo modo de visualización de esta información, llamado “Modo

resumen”. En el calendario, únicamente se muestra la carga total para ese día, y en la nueva ventana “Pedidos

de la fecha seleccionada”, se muestra el detalle de los pedidos que forman parte de éste.

Figura 8. Vista del calendario del planificador en PrefSuite 2016.1.

Se han incluido colores en la suma de la carga total del día para que sea fácil reconocer el estado de la carga

actual, para ese día. Al hacer clic en una fecha o en un total, o la selección de un grupo de ellos, los pedidos

que pertenecen a la selección se mostrarán en la nueva ventana.


Los pedidos que están dentro de la ventana “Pedidos de la fecha seleccionada”, se comportan igual que como

cuando antiguamente estaban en el calendario. Es decir, al seleccionar uno de ellos se muestra la información

y la carga en el resto de ventanas de conexión ya existentes.

1.7. Cambios de información al cargar un lote Actualmente PrefGest muestra el número de submodelos para la producción de carga pendiente y el lote

seleccionado. Ahora es posible modificar esto, de forma que se muestre el valor de la variable seleccionada

como variable de carga para el planificador.

Figura 9. Información al cargar el lote.

La variable seleccionada como variable de carga también se puede definir como “Para producción”, en el editor

de variables del modelo (En PrefGest, desde el menú superior “Varios” > “maestro de variables de modelo…”).

Si no es así, se seguirá mostrando el número de submodelos cargados al rellenar un lote.


Figura 10. Variables del modelo. Columna “Para producción”.

1.8. Huella del tipo de producción Con las últimas mejoras, la herramienta de planificación hace que la carga de producción encaje mejor con las

capacidades de producción para todos los días.

Cada tipo de producción tiene una duración definida (en días), pero en las versiones anteriores de la

planificación toda la carga se controlaba en función de la capacidad definida para el primer día. La duración

de producción sólo se utilizaba para calcular la fecha de salida de taller. Este enfoque ha funcionado bien

cuando toda la distribución de la carga era uniforme para todas las ventanas producidas en una línea de

producción.

Pero este escenario cambia si los diferentes tipos de producción que se produce en una línea de producción

tiene una secuencia diferente de los centros de trabajo de producción, lo que llamamos la "huella del tipo de

producción".

Si para un tipo de producción el corte se realiza el primer día, se pinta el segundo día, y finalmente montamos

las ventanas el tercer día; la carga para cada uno de estos centros de trabajo se compara con la carga de la fecha

de producción inicial propuesta más el día asignados a cada centro de trabajo dentro del centro de producción.

Para definir la "huella" para cada tipo de producción, el usuario debe abrir el diálogo de definición Tipos de

producción en PrefGest, en el menú superior “Varios” > “Producción”.


Figura 11. Proceso del tipo de producción.

En el botón de puntos suspensivos (…) que se encuentra en la columna “Proceso” muestra un nuevo cuadro

de dialogo donde se puede definir la huella para ese tipo de producción. El usuario seleccionará en qué día se

realizará cada operación.

Figura 12. Detalle de días de producción para el tipo de producción.

Esta interfaz de usuario mostrará a la izquierda una lista de las variables (centros de trabajo) utilizados en las

definiciones de límite de producción. También habrá una columna para cada día de duración del tipo de

producción seleccionado.


El usuario podrá seleccionar sólo un día para cada variable (centro de trabajo). El día elegido será el utilizado

para comprobar la capacidad actual cuando se planifique la producción para un modelo o parte de un pedido

con el tipo de producción seleccionada.

Esto significa, en el ejemplo de la imagen, que si la herramienta de planificación está tratando de comprobar

la capacidad de producción para hoy, solo comprobará si hay suficiente capacidad para los marcos de hoy. Si

hay disponibilidad, entonces se comprueba la pintura (que podría ser un límite común, tal como se explica en

el punto 1.1.) El día hábil siguiente, y luego los vidrios y las hojas en el tercer día. Si todo encaja, la producción

pedido será programada para hoy. Si no, igual que ha hecho siempre el planificador, comprobarla los siguientes

días con el mismo algoritmo.

Si el usuario no selecciona o no quiere seleccionar los días para las variables, la herramienta de planificación

funcionará como lo hace hasta ahora: se considerará el día 1 para todas las variables.


2. Producción: Modelos pendientes de producir

2.1. Cambios en la vista de modelos pendientes de producir Cuando un usuario ejecuta por primera ver PrefGest en su equipo, y abre el apartado “Planificador”

>”Producción”, esta pantalla puede tardar un poco en cargarse, porque se muestran todos los modelos

pendientes de producir. Esto ha sido cambiado, de forma que cuando se accede por primera vez a este apartado

de PrefGest, está establecido en el campo “Mostrar” el valor “Nada” De esta forma, el usuario pude aplicar un

filtro primero.

Figura 13. Campo “Mostrar” en producción.

2.2. Prevenir la carga en espera de la producción sin filtro Relacionado con el punto anterior, el usuario será advertido de que es posible que el programa tarde en mostrar

todos los modelos pendientes de producir, si intenta mostrar esto sin establecer ningún filtro, mediante un

mensaje por pantalla. El usuario podrá seguir cargando los modelos pendientes de producir pulsando el botón

“Si”, o cancelar la operación pulsando el botón “No” y crear un filtro primero.

Figura 14. Mensaje de advertencia al modificar el campo “Mostrar”.


3. Configuraciones de color Una configuración de color es un grupo de datos que define un color, que puede ser aplicado a un material en

PrefGest. Cada uno de esos grupos contiene:

Un entero que identifica inequívocamente la configuración de color

Un campo de 50 caracteres donde se indica el color principal

Un campo de 50 caracteres donde se indica el color interior

Un campo de 50 caracteres donde se indica el color exterior.

Los tres campos de texto pueden tener valor nulo, representando un color sin capas interiores/exteriores, o un

material sin color asociado si los tres campos tienen valor “NULL”. Esta última configuración es un caso

especial que se podrá dar en todas las BDs PrefSuite, por lo que PrefDBmanager por defecto creará esta

configuración concreta con código “0”. Las otras configuraciones de color podrán ser incluidas dependiendo

de los distintos colores usados durante el uso regular de la aplicación.

ConfigurationCode ColorName InnerColor OuterColor

0 NULL NULL NULL

1 Black NULL NULL

2 BicolorRAL 6005 6006

Figura 15. Ejemplos de configuración de color almacenados en la BD.

El campo “ConfigurationCode” se usará como clave externa para las tablas que contenga información del

material + información del color. De esta forma, con solo 4 bytes, tendremos toda la información relacionada

con el color del material, ahorrando espacio en disco en tablas de importante tamaño como MaterialesPAF o

PredCAMPieces. También permite disponer de los datos del bicolor automáticamente en cada tabla,

incluyendo el código de configuración de color. Es por eso por lo que desde la actualización, tablas como

Stock, MaterialNeeds o PurchasesDetail, podrán manejar materiales bicolores, por lo que también se podrá

hacer en las correspondientes partes del programa.

No obstante, hay el unas pocas características en el programa que no están usando esta configuración de color.

Sobre todo, las que usan como clave la referencia del material. Por ejemplo, el precio de compra ponderado o

los niveles de stock de los materiales. Si alguien quiere añadir distintos niveles de material de stock para un

color especial, o mantener un precio medio separado según el color, no podrá hacerlo mediante genéricos, sino

que necesitará una referencia final por cada uno de los colores.

3.1. Migración a las configuraciones de color

3.1.1. Migración de estructura de la BD

Todos los campos de configuración de control serán añadidos por el kernel, cuando ejecutemos en

PrefDBManager la opción de actualizar la base de datos. Esto incluye la generación en la tabla

“ColorConfigurations” los códigos para cada color usados en esas tablas del kernel y remplazando los viejos

textos basados en los campos color con el correspondiente código de configuración. Sin embargo, pueden

surgir problemas inesperados al migrar una BD, ya que es un gran cambio. Por tanto, hacer una copia de

seguridad previamente, es muy recomendable.


Obviamente, las tablas de usuario no serán migradas por el kernel si existiera en estas alguna información

relativa al color, así como la migración debe ser aplicada también a la DLL de usuario, si por ejemplo en

alguna parte del código se obtuviera el color mediante sentencias SQL. El usuario deberá realizar las

modificaciones oportunas.

3.1.2. Tablas modificadas por el Kernel

Este es un listado de todas las tablas en las que se ha modificado uno o más campos, para adecuar su

información a la nueva configuración de color:

InventoryControlsDetail

MaterialesOptimizaciones

MaterialesPAF

MaterialNeeds

ParametrosOptimizaciones

ProdCAMPieces

ProdCAMRods

ProdGenericGlasses

ProdGenericGlassChambers

ProdGenericGlassLites

ProdGenericGeorgianBars

ProdGenericRollerBoxBlades

ProdGenericSticks

ProductionLotRodLengths

PurchasesDetail

Stock

StockHistory

TempGeneratedMaterials

WarehouseDocumentsDetail

PrefDocuments.PDGenericGlases

PrefDocuments.PDGenericGlassChambers

PrefDocuments.PDGenericGlassLites

PrefDocuments.PDGenericGeorgianBars

PrefDocuments.PDGenericPieces

PrefDocuments.PDGenericRollerBoxBlades

PrefDocuments.PDGenericSticks

Production.AdditionalItems


Production.OptimizationRods

Production.PackagesDetail

3.1.3. Modificaciones en tablas de usuario

Si hay tablas creadas o ampliadas por la DLL de usuario a través de los eventos del módulo DataManager y

alguno de los campos tiene un significado de “color”, en caso de que dicho campo enlace con un campo que

ahora es de tipo “configuración de color”, podría ser correcto cambiar también ese campo de usuario para que

sea una “configuración de color”. Por ejemplo, cualquier tabla que guarde información de color para materiales

en un contexto de producción es muy probable que se represente mejor con una configuración de color que

con un nombre de color. Cuando se trate de uno de esos campos, para que la tabla sea exportada correctamente

por PrefBackup el XML de PrefDatabase debe incluir la siguiente información:

<Table Schema="dbo" Name="Stock" DVType="Normal" PDEScope="None" Description="">

<Columns>

<Column Name="Id" Type="int" AllowNulls="0" Identity="1" Description=""/>

<Column Name="Warehouse" Type="smallint" AllowNulls="0" Description=""/>

<Column Name="Reference" Type="nchar" Length="25" AllowNulls="0" Description=""/>

<Column Name="ColorConfiguration" Type="int" AllowNulls="0" DefaultValue="0"

Description="Points to the ColorConfigurations table to keep track of the color

configuration"/>

…

</Indexes>

<PrefBackupExtraInfo>

<LinkedTable Schema="dbo" Name="ColorConfigurations">

<LinkedKey>

<Column Name="ColorConfiguration" ReferencedColumn="ConfigurationCode"/>

</LinkedKey>

</LinkedTable>

</PrefBackupExtraInfo>

<Security>

…

Figura 16. XML a añadir a la definición de la tabla

Aquí vemos tras “Indexes” que un nuevo nodo “PrefBackupExtraInfo” ha sido añadido. Este nodo indica que

tenemos una columna “ColorConfiguration” que enlaza con otra columna “ConfigurationCode” perteneciente

a la tabla “ColorConfigurations”. Esto ayudará a PrefBackup a procesar correctamente la exportación de los

códigos de color de una base de datos a otra.

3.2. Migración de código Los programas de kernel que podrían verse afectados por estos cambios como PrefCIM, PrefGest y PrefWeb,

se han modificado para consultar el uso de los nuevos campos, en lugar de los antiguos. Pero cualquier otro

código de acceso a través de una consulta SQL a los viejos campos necesita ser actualizado. Eso incluye, por

ejemplo, a los listados y etiquetas personalizadas, listados generados por SQL Server Reporting Services,

formularios de usuario, sentencias SQL, herramientas externas para consultar nuestra BD, etc.

Por eso, a continuación veamos un ejemplo acerca de cómo modificar una consulta para adaptarse a la nueva

configuración de color. Esta es una consulta que accede a los datos de StockHistory:


SELECT SH.*, MB.Descripcion, MB.TipoCalculo as Kind, MB.Clase as Class, MB.Familia as Family,

M.Color as RealColor,

MB.CodigoProveedor as SupplierCode, P.Nombre as SupplierName, OPT.Reference AS LotReference

FROM StockHistory SH

LEFT OUTER JOIN Materiales M ON SH.Reference = M.Referencia

LEFT OUTER JOIN MaterialesBase MB ON M.ReferenciaBase = MB.ReferenciaBase

LEFT OUTER JOIN Proveedores P ON MB.CodigoProveedor = P.CodigoProveedor

LEFT OUTER JOIN Optimizaciones OPT ON OPT.Numero = SH.RO_FromProductionLot

Figura 17. Formato de sentencia SQL antiguo.

Esta sentencia SQL devuelve todos los campos de StockHistory, incluyendo el campo “Color” que ahora ha

sido eliminado.

La versión correcta (y actualizada) de esta sentencia SQL, usando las configuraciones de color seria:

SELECT SH.*, ISNULL(CC.ColorName, N'') AS Color, ISNULL(CC.InnerColor, N'') AS InnerColor,

ISNULL(CC.OuterColor, N'') AS OuterColor, MB.Descripcion, MB.TipoCalculo as Kind, MB.Clase as

Class, MB.Familia as Family, M.Color as RealColor, MB.CodigoProveedor as SupplierCode,

P.Nombre as SupplierName, OPT.Reference AS LotReference

FROM StockHistory SH

INNER JOIN ColorConfigurations CC ON CC.ConfigurationCode = SH.ColorConfiguration

LEFT OUTER JOIN Materiales M ON SH.Reference = M.Referencia

LEFT OUTER JOIN MaterialesBase MB ON M.ReferenciaBase = MB.ReferenciaBase

LEFT OUTER JOIN Proveedores P ON MB.CodigoProveedor = P.CodigoProveedor

LEFT OUTER JOIN Optimizaciones OPT ON OPT.Numero = SH.RO_FromProductionLot

Figura 18. Formato de sentencia SQL Nuevo.

Ahora, en el texto que aparece en negrita, podemos ver que estamos uniendo la tabla “ColorConfigurations”,

y que utilizamos esta tabla para devolver “ColorName” como la columna de color que ya no existe en la tabla

StockHistory (SH.* ahora devuelve una nueva columna de “ColorConfiguration”). También hemos añadidos

dos nuevas columnas, una para el color interior y otra para el color exterior.


4. Evento OnPDistance El evento OnPDistance, disponible desde el módulo ModelModule, tiene en esta versión 2 nuevos parámetros:

bApplySlaveDistance: Parámetro de tipo booleano. Activa el descuento del esclavo.

slaveDistance: Parámetro de tipo double. Indica el valor del descuento del esclavo.

Estos parámetros pueden ser usados para cambiar el descuento del esclavo en un descuento de tipo Mecanizado

Interior/Mecanizado Exterior.

public void OnPDistance(Interop.PrefCAD.Modelo model, Interop.PrefCAD.Tramo master,

Interop.PrefCAD.Tramo slave, Interop.PrefCAD.TipoDescuento type, ref double distance, ref

double zDistance, ref double zAngle, ref bool bApplySlaveDistance, ref double slaveDistance )

Figura 19. Evento OnPDistance.


5. Variables y campos en plantillas Se han incluido campos y variables nuevos en varias plantillas de list&label.

5.1. Datos de la empresa En PrefGest, dentro de Archivo > Opciones, es posible indicar los datos de la empresa, en el apartado Programa

> Datos de la empresa.

Figura 20. Datos de la empresa, en las opciones de PrefGest.

Esta información está disponible en las siguientes variables, dentro de la etiqueta de producto terminado, y en

las plantillas de Doc Ventas (en Documentos Principales > Presupuestos - Albaranes - Facturas):

Shop.Name: Campo “Nombre” en las opciones de PrefGest.

Shop.TaxIdNumber: Campo “N.I.F.” en las opciones de PrefGest.

Shop.Telephone: Campo “Teléfono” en las opciones de PrefGest.

Shop.Address1: Primera grid del campo “Dirección” en las opciones de PrefGest.

Shop.Address2: Segunda grid del campo “Dirección” en las opciones de PrefGest.

Shop.PostalCode: Campo “C.Postal” en las opciones de PrefGest.

Shop.City: Campo “Localidad” en las opciones de PrefGest.

Shop.County: Campo “Provincia” en las opciones de PrefGest.

Shop.Contry: Campo “País” en las opciones de PrefGest.


Figura 21. Variables Shop.xxx en las plantillas.

5.2. Base imponible en Doc. Ventas En las plantillas de Doc Ventas (en Documentos Principales > Presupuestos - Albaranes - Facturas), existe una

nueva variable llamada “Totals.PriceBeforeTaxes”. Esta variable indica la base imponible del documento

editado.

Figura 22. Variable “Totals.PriceBeforeTaxes”.


5.3. EAN13 en el informe de material Se ha añadido, en la plantilla “Informe de material” un campo nuevo llamado "Material.EAN13". Este campo

envía a la plantilla el valor del EAN13 del material.

Figura 23. Campo "Material.EAN13" en el informe de material.

5.4. Etiqueta para el informe de cortes Se ha incluido en la etiqueta para el informe de cortes variables con el número de barra (RodNumber), el

número de pieza (PieceNumber), y la descripción del material (MaterialDescription).

Figura 24. RodNumber, PieceNumber y MaterialDescription en la etiqueta para el informe de cortes.


6. “Perfil Receptor” en reglas de mecanizado Las reglas de mecanizado, sirven para generar piezas cuando se unen dos perfiles. El funcionamiento y uso es

el mismo que en las versiones anteriores. Este campo indicará si la pieza se coloca en el perfil maestro o en el

esclavo de la unión.

Figura 25. Campo “Perfil Receptor” en las reglas de mecanizado.


7. Buscar documentos de compra por referencia Ahora, desde la bandeja de documentos de compra, al pulsar el botón “Buscar”, el programa permite también

realizar esta operación por la referencia asignada al documento.

Figura 26. Campo “Referencia” al buscar documentos de compra.


8. Bloquear la edición de campos desde la bandeja A partir de esta versión, se ha incluido una variable global nueva, disponible desde la tabla VariablesGlobales.

Esta nueva variable se llama "ListViews.Readonly". Según su valor en esta tabla, aplicará el siguiente

funcionamiento:

A 1, significa que las bandejas son de sólo lectura.

A 0, que no lo son.

Esta variable global afecta a todas las bandejas de PrefGest, salvo a algunas de ellas que sobrescriben este

valor:

CMS,

Materiales

y Personal

En estas, siempre han sido de sólo lectura y así permanecen.

Por otro lado, la bandeja de ventas seguirá tomando el valor de la variable global "EditableLV.Sales", sea cual

sea el valor de "ListViews.ReadOnly".


9. Ventana de mensajes PrefGest muestra una ventana Mensajes, que aparece tras Aceptar la ventana de propiedades del modelo, en

los documentos de venta. Esta ventana temía un tamaño fijo. Esto se ha modificado, de forma que ahora es

posible ampliar su tamaño para así poder leer los mensajes de una forma más cómoda.

Figura 27. Ventana “Mensajes” en un PAF de ventas.


10. PrefTSClient en equipos x64 Se ha generado un nuevo MSI para PrefTSClient x64. Este MSI servirá para trabajar con PrefSuite por terminal

server, cuando el equipo cliente tiene un sistema operativo de 64 bits.

Es decir, no será necesario aplicar configuraciones en el fichero MSTSC. Al instalar este MSI para equipos de

64 bits, ya se enviará automáticamente la información de la licencia a la aplicación PrefSuite instalada en el

servidor.


11. Perfiles compuestos y componentes En esta versión, el programa permite gestionar los componentes (subperfiles) que forman parte de un perfil

compuesto, y relacionarlos entre sí. Veamos el uso y configuración de esta mejora en los siguientes puntos.

11.1. Configuración de materiales El primer paso para configurar los materiales, será indicar qué perfiles de los insertados en la base de datos

son perfiles compuestos, así como su composición. No existe una interfaz en el programa para establecer esta

información, por lo que se deberá aplicar directamente mediante sentencias SQL, sobre la base de datos.

En la tabla “Perfiles” es necesario activar el campo “Composite” a 1, para aquellas referencias cuyo perfil está

compuesto de varios subperfiles.

Por ejemplo:

UPDATE Perfiles SET Composite=1 WHERE ReferenciaBase='PP_Perfil_Comp'

A continuación, en la tabla “ProfileComponents”, se deberá definir los subperfiles que se incluyen en el perfil

compuesto. Esta tabla tendrá los siguientes campos:

MakerId: El MakerId indicado para esa referencia base en la tabla MaterialesBase

ProfileBaseReference: La referencia base del perfil compuesto

ComponentCode: Orden para diferenciar registros similares. Ira de 1 a N

ComponentBaseReference: la referencia base del subperfil

ComponentSide: Posicionamiento para el color. Sus valores serán:

1: Perfil interior

2:Perfil interno (normalmente poliamida)

3: perfil exterior

PositionInProfile: la secuencia para mostrar la lista de componentes para un perfil específico cuando se

muestra en una interfaz de usuario.

Por ejemplo:

INSERT INTO ProfileComponents (MakerId, ProfileBaseReference, ComponentCode,

ComponentBaseReference, ComponentSide, PositionInProfile)

VALUES

('007FB357-8311-48FB-833C-5C13808064AD', 'PP_Perfil_Comp', 1,'PP_SubPerfil_Int', 1, 1)

Figura 28. Subperfiles definidos en la tabla “ProfileComponents”, para el perfil compuesto “PP_Perfil_Comp”.

Para los perfiles con el campo ComponentSide=2 (perfil interno), el programa entiende que es un perfil sin


color. Por esto, irá a buscar en las referencias finales de este perfil aquella que no tenga color alguno asignado.

Para perfiles con valor 1 o 3 en ComponentSide, el programa buscará las referencias finales del mismo color

(o con el color simple de las capas en caso de que el color asignado al perfil compuesto fuera un color bicolor).

Se debe tener en cuenta que, si los componentes tienen precio en tarifa, el programa añade ese precio a lo que

puedan costar el propio perfil compuesto (por su peso, porque también se le ha puesto precio a la referencia

del compuesto, por la pintura, etc.). Esto ha de tenerse en cuenta a la hora de diseñar cómo se quiere calcular

el precio del material: solo del compuesto, solo los componentes, o la suma de ambos.

Siguiendo el ejemplo comentado anteriormente, en nuestro caso, tenemos el perfil “PP_Perfil_Comp” sin

importe aplicado en tarifa.

Está compuesto por el subperfil interior “PP_SubPerfil_Int” (10€/ml), la poliamida “PP_Poliamida_Subp”

(5€/ml) y el perfil exterior “PP_SubPerfil_Ext” (20€/ml).

Figura 29. Precio en tarifa para el perfil compuesto y sus componentes.

Al diseñar un modelo con el perfil “PP_Perfil_Comp”, el importe presentado es la suma de sus componentes.

Figura 30. Precio calculado del perfil compuesto, en función de sus componentes.


11.2. Componentes en las necesidades de material Una vez definido el perfil compuesto, en las necesidades de material se intentará incluir sus componentes

(dependiente de la definición “Incluir en las necesidades”, establecida en las propiedades del material en

PrefWise).

Los colores de los componentes se aplicarán en función del campo “ComponentSide” en la tabla

“ProfileComponents” comentada en el punto anterior. En concreto:

Los perfiles internos (valor 2) tomarán el color vacío.

Los perfiles interiores (valor 1) tomarán el color interior del color de perfil compuesto.

Los perfiles exteriores (valor 3) tomarán el color exterior del color de perfil compuesto.

Los colores asociados a los componentes deben ser colores simples, pero estos colores pueden hacer referencia

a un color con materia prima para hacer un pedido de cambio de color.

Para la gestión de perfiles componente, se han incluido cambios en las necesidades materiales, documentos de

compra y movimientos de almacén. Trabajan de esta manera:

11.2.1. Cambios en la interfaz

Cuando se generan necesidades de material que incluyen perfiles compuestos, se añade un conjunto de

necesidades de material extra que agrupa todos los componentes de esos perfiles compuestos. La interfaz se

muestra con algunas nuevas mejoras.

Figura 31. Nuevos campos en las necesidades de material, para identificar los perfiles compuestos y componentes.


11.2.2. Documentos de compra desde las necesidades

Los documentos de compra generados desde estas necesidades de material incluirán aquellos perfiles

compuestos con la check ‘Pedir Componentes’ desactivada. También incluirán los componentes de aquellos

perfiles compuestos que tengan marcada la check ‘Pedir Componentes’. Lógicamente, estos materiales tienen

que estar configurados para ser añadidos a los documentos de compra: con proveedor, marcado como pedir

bajo demanda, etc… El check ‘Pedir componentes’ en necesidades de material se marca por defecto con el

valor del campo ‘OrderComponents’ en la tabla ‘Perfiles’, pero una vez en las necesidades de material esa

inicialización por defecto puede ser modificada. También la cantidad a pedir puede ser modificada, aunque se

debe de tener en cuenta que este valor dependerá de la cantidad de perfil compuesto calculado desde las

necesidades, y el stock del perfil componente.

Figura 32. Edición de la cantidad a pedir de un componente.

Es decir si, por ejemplo, se necesitan 5 barras del perfil compuesto, sus componentes tendrían que tomar por

defecto la cantidad de 5. Pero el usuario puede querer más o menos según su stock, luego puede rebajar la

cantidad de ese componente de 5 a 3. Este es el comportamiento estándar de PrefGest. También se puede

modificar la cantidad del perfil compuesto (por ejemplo, de 5 a 4 porque ya tenemos en stock un perfil

ensamblado). Esto hará que las necesidades de material de los componentes de ese perfil compuesto también

cambien de 5 a 4, o, en el caso de la ya reducida a 3, se cambiaría de 3 a 2.

11.2.3. Ensamblado de perfiles

En las necesidades de material ahora se puede crear movimientos de almacén, en concepto de ensamblado de

los perfiles. Esto significa que para aquellos perfiles que tienen marcado “Pedir Componentes” en las

necesidades de material, los componentes serán descontados del stock (a través de un movimiento de almacén

de salida) y los perfiles compuestos se añadirán al stock (mediante un movimiento de almacén de entrada).

Tendrán tantos documentos de entrada y salida como almacenes establecidos para los perfiles. Esto se hará

seleccionando la opción de menú “Necesidades” > “Ensamblar componentes”.


Figura 33. Ensamblar componentes en las necesidades de material.

Después de la generación, se presentará en pantalla un diálogo, el cual informará al usuario sobre el resultado:

Figura 34. Movimientos de almacén al ensamblar componentes. Dialogo informativo.


12. Informes de agrupación de vidrios A partir de esta versión, existen disponibles dos nuevas plantillas que totalizan la información de vidrios.

Dichas plantillas son:

Informe de material simple vidrios agrupados: a asociar en el informe de material. Incluye también

el área.

Listado de vidrios simples agrupado con subtotales: a asociar en el listado no gráfico de vidrios.

El objetivo de estas plantillas es agrupar los vidrios de la misma referencia y mostrar totales para estos, además

de incluir información del área en el Informe de material:

Figura 35. Informe de material simple vidrios agrupados.

Figura 36. Listado de vidrios simples agrupado con subtotales.