Source: http://www.fiebdc.es/fiebdc-32016/
Timestamp: 2019-02-19 23:03:33+00:00

Document:
FIEBDC-3/2016 - fiebdc.es
DEFINICIÓN DEL FORMATO DE INTERCAMBIO ESTANDAR DE BASE DE DATOS DE CONSTRUCCION
FIEBDC – 3/2016
FIEBDC-3/2016
-entrada en vigor a partir del 01/01/2016-
La siguiente DEFINICION del Formato de Intercambio ESTANDAR de Bases de Datos de CONSTRUCCION, recoge las especificaciones aprobadas hasta el Acta 22 de la CTP inclusive (celebrada el 6 de mayo de 2015) y ratificadas por la JD y ASAMBLEA de la asociación FIEBDC.
Entrada en vigor el día 1 de enero de 2016, como VERSIÓN 3/2016.
Para facilitar su lectura, se indica en letra de color azul aquellos párrafos nuevos o modificados respecto a la especificación FIEBDC-3/2012.
Este documento se pone a disposición de usuarios y empresas, con la única condición de que cualquier implementación informática del presente formato debe recoger tanto la entrada como la salida de datos.
Este formato pretende abarcar toda la INFORMACION contenida en las actuales bases de datos de CONSTRUCCION. No todos los desarrolladores de bases de datos necesitarán utilizar todas las posibilidades del formato; así como tampoco todos los programas de mediciones y presupuestos harán uso de toda la INFORMACION suministrada.
Se prevé además, dentro del propio formato, la posibilidad de ampliación; manteniendo en lo posible la compatibilidad entre versiones en el caso de tratar nuevos contenidos que se prevean en un futuro.
FORMATO FIEBDC-3. ESPECIFICACIÓN
Toda la INFORMACIÓN necesaria para reconstruir completamente una base de datos u obra en soportes físico y lógico distintos a aquellos en los cuales se produjo la INFORMACIÓN es el objetivo del formato FIEBDC, Formato de Intercambio ESTÁNDAR de Bases de Datos de CONSTRUCCIÓN.
La INFORMACIÓN de una base de datos, obra o certificación se dispondrá en cualquier número de archivos en formato FIEBDC, con la extensión “.BC3”, teniendo en cuenta que estos archivos ordenados alfabéticamente contengan la INFORMACIÓN en el orden deseado.
La única limitación de tamaño de cada archivo será la máxima que permita el soporte físico utilizado para su transporte. Si se utiliza algún tipo de compresor de archivos, se deberá incluir en el mismo soporte el descompresor o utilizar un formato autodescomprimible.
El juego de caracteres a emplear en los campos CODIGO será el definido por MS-DOS 6.0, incluyendo A-Z, a-z, 0-9, ñ, Ñ, < . > (ASCII-46), < $ > (ASCII-36), < # > (ASCII-35), < %> (ASCII-37), < & > (ASCII-38), < _ > (ASCII-95). Excluyendo cualquier otro carácter como espacio, tabulador, etc.
El fin de línea será el ESTÁNDAR de los archivos MS-DOS (ASCII-13 y ASCII-10). El fin de archivo se marcará según el mismo ESTÁNDAR (ASCII-26). El único carácter de control adicional que se permitirá será el tabulador (ASCII-9).
Cada archivo estará compuesto de registros, zonas de texto entre el carácter de principio de registro < ~ > (ASCII-126) y el siguiente principio de registro o fin de archivo. Los archivos deberán contener registros completos, es decir, la división de archivos se deberá realizar al comienzo de un registro (carácter < ~ >).
Cada registro estará compuesto de campos separados por caracteres < | > (ASCII-124). Todo campo con INFORMACIÓN tendrá que finalizar con el separador de campos y el registro deberá contener todos los separadores de campos anteriores, aunque no contengan INFORMACIÓN. No es necesario disponer de finalizadores de los campos posteriores al último con INFORMACIÓN.
Cada campo estará compuesto de subcampos separados por caracteres < \ > (ASCII-92). El separador final, entre el último dato de un campo y el fin de campo es opcional.
El primer campo de cada registro es la cabecera de registro, una letra mayúscula que identifica el tipo de registro.
Se ignorará cualquier INFORMACIÓN entre el último separador de campos de un registro (carácter < | >) o el comienzo del archivo y el comienzo del siguiente registro (carácter < ~>).
Se ignorarán los caracteres blancos (32), tabuladores (9) y de fin de línea (13 y 10), delante de los separadores < ~ >, < | > y < \ >.
No se podrán actualizar parcialmente campos de segundo orden (subcampos). Deberá actualizarse la INFORMACIÓN completa de un campo en cualquiera de los registros
La disposición de registros dentro de un archivo es completamente libre, pero se garantizará la lectura secuencial de los mismos para evitar ambigüedades en las sustituciones de INFORMACIÓN.
Los campos vacíos se considerarán SIN INFORMACIÓN, no con INFORMACIÓN nula, esto permite producir archivos de actualización que contengan únicamente la INFORMACIÓN en alguno de sus campos y, por supuesto, el CÓDIGO de referencia.
Para anular un campo numérico deberá aparecer explícitamente el valor 0 (cero).
Para anular un campo alfanumérico deberá aparecer explícitamente el ROTULO NUL.
Con el fín de permitir la transferencia desde las bases de datos en Internet a las aplicaciones en ordenadores locales utilizando FIEBDC, se indica que al hacer drag&drop en el icono del FIE sobre una aplicación, la aplicación en el evento drop recibe una url que finaliza con el id_concepto con la extensión .bc3, a la cual el programa tendrá que hacer una petición que le devolverá un bc3.”
CONVENIO DE NOTACIÓN
[a] Indica nada o “a”
{a} Indica cero o más ocurrencias de “a”
Indica una o más ocurrencias de “a”
(c) Tamaño máximo en número de caracteres del campo
Todos los valores numéricos irán sin separadores de miles y con el carácter punto ‘.’ entre la parte entera y la decimal.
REGISTRO TIPO PROPIEDAD Y VERSIÓN
Este registro se utiliza para documentar la procedencia y el formato de los archivos y, cuando exista, se dispondrá al comienzo del primer archivo.
~V | [ PROPIEDAD_ARCHIVO ] | VERSION_FORMATO [ \ DDMMAAAA ] | [ PROGRAMA_EMISION ] | [ CABECERA ] \ { ROTULO_IDENTIFICACION \ } | [ JUEGO_CARACTERES ] | [ COMENTARIO ] | [ TIPO INFORMACIÓN ] | [ NÚMERO CERTIFICACIÓN ] | [ FECHA CERTIFICACIÓN ] | [ URL_BASE ] |
PROPIEDAD_ARCHIVO: Redactor de la base de datos u obra, fecha…
VERSION_FORMATO: VERSION del formato del archivo, la actual es FIEBDC-3/2016.
DDMMAAAA: DD representa el día con dos dígitos, MM el mes y AAAA el año. Si la fecha tiene 6 ó menos dígitos, el año se representará con dos dígitos (AA), interpretándose con el criterio “80/20”. Esto es, cualquier año que sea igual o superior a 80 corresponderá al siglo XX y cualquier año que sea menor de 80 corresponderá al siglo XXI. Si la fecha tiene menos de 5 dígitos representa mes y año únicamente (MMAA), si tiene menos de tres, solo el año (AA). Si se identifica la fecha con un número impar de dígitos, se completará con el carácter cero por la izquierda. Para representar una fecha sin un día o mes específico, se utilizará un doble cero en cada caso.
12062000 12 de junio de 2000
120699 12 de junio de 1999
00061281 junio de 1281
061281 6 de diciembre de 1981
401 abril de 2001
PROGRAMA_EMISION: Programa y/o empresa que genera los ficheros en formato BC3.
CABECERA: Título general de los ROTULOS_IDENTIFICACION.
ROTULO_IDENTIFICACION: Asigna secuencialmente títulos a los valores definidos en el campo PRECIO del registro ~C, y los conjuntos de campos de números de decimales del registro ~K, que tal como se indica en su ESPECIFICACION, puede representar distintas épocas, ámbitos geográficos, etc., estableciéndose una relación biunívoca entre ambos. Véanse los anexos 5 (Ámbitos territoriales) y 6 (Divisas).
En el caso de que en el registro ~V existan más campos ROTULO_IDENTIFICACION que campos PRECIO en el registro ~C o que conjuntos de campos de decimales en el registro ~K, se entenderá que el PRECIO y los conjuntos de campos de decimales de dicho resto serán iguales al último definido.
JUEGO_CARACTERES: Asigna si el juego de caracteres a emplear es el definido para D.O.S., cuyos identificadores serán 850 ó 437, o es el definido para Windows, cuyo identificador será ANSI. En caso de que dicho campo esté vacío se interpretará, por omisión, que el juego de caracteres a utilizar será el 850 por compatibilidad con versiones anteriores.
COMENTARIO: Contenido del archivo (base, obra…).
TIPO INFORMACIÓN: Índice del tipo de información a intercambiar.
Se definen los siguientes tipos:
2 Presupuesto.
3 Certificación (a origen).
4 Actualización de base de datos.
NÚMERO CERTIFICACIÓN: Valor numérico indicando el orden de la certificación (1, 2, 3,…) Solo tiene sentido cuando el tipo de información es Certificación.
FECHA CERTIFICACIÓN: Fecha de la certificación indicada en el campo número certificación. Solo tiene sentido cuando el tipo de información es Certificación. La fecha se definirá con el mismo formato que el campo DDMMAAAA de este registro.
URL_BASE: Url a partir de la cual se encontrarán los documentos y los gráficos.
REGISTRO TIPO COEFICIENTES.
Indica el número de decimales en cada campo numérico. Cuando el campo numérico aparece con signo negativo, indica número máximo de decimales. En caso contrario indica número exacto de decimales.
Cuando en un archivo FIEBDC aparece una cantidad con más cifras decimales de las correspondientes según el registro ~K, se debe especificar como error, ya que lo que se exporta debe coincidir con el registro ~K.
Cuando en un archivo FIEBDC no exista este registro, se recomienda aplicar los decimales por defecto establecidos en el formato.
~K | { DN \ DD \ DS \ DR \ DI \ DP \ DC \ DM \ DIVISA \ } | CI \ GG \ BI \ BAJA \ IVA | { DRC \ DC \ \ DFS \ DRS \ \ DUO \ DI \ DES \ DN \ DD \ DS \ DSP \ DEC \ DIVISA \ } | [ n ] |
Este registro incluye el campo 1 por compatibilidad con versiones anteriores del formato, aunque los programas deben leer el campo 3 por ser más completo y en su defecto el campo 1.
Unidad de obra: Cualquier elemento simple o elemento compuesto, con o sin costes indirectos, que se utiliza en un presupuesto.
Elemento compuesto: Todo elemento constructivo que contiene una descomposición y que no es ni raíz ni capitulo.
Elemento simple: Todo elemento constructivo que no contiene una descomposición y que no es ni raíz ni capitulo.
DN Decimales del campo número de partes iguales de la hoja de mediciones. Por defecto 2 decimales.
DD Decimales de dimensiones de las tres magnitudes de la hoja de mediciones. Por defecto 2 decimales.
DS Decimales de la línea de subtotal o total de mediciones. Por defecto 2 decimales.
DR Decimales de rendimiento y factor en una descomposición. Por defecto 3 decimales.
DI Decimales del importe resultante de multiplicar rendimiento x precio del concepto. Por defecto 2 decimales
DP Decimales del importe resultante del sumatorio de los costes directos del concepto. Por defecto 2 decimales
DC Decimales del importe total del concepto. (CD+CI). Por defecto 2 decimales
DM Decimales del importe resultante de multiplicar la medición total del concepto por su precio. Por defecto 2 decimales
DIVISA Es la divisa expresada en el mismo modo que las abreviaturas utilizadas por el BCE (Banco Central Europeo), que en su caso deberán coincidir con las del registro ~V. En el Anexo 6 se indican las actuales.
CI Costes Indirectos, expresados en porcentaje.
GG Gastos Generales de la Empresa, expresados en porcentaje.
BI Beneficio Industrial del contratista, expresado en porcentaje.
BAJA Coeficiente de baja o alza de un presupuesto de adjudicación, expresado en porcentaje.
IVA Impuesto del Valor Añadido, expresado en porcentaje.
DRC Decimales del rendimiento y del factor de rendimiento de un presupuesto, y decimales del resultado de su multiplicación. Por defecto 3 decimales.
DC Decimales del importe de un presupuesto, de sus capitulos, subcapitulos, etc. y líneas de medición (unidades de obra excluidas), y decimales de los importes resultantes de multiplicar el rendimiento (o medición) total del presupuesto, sus capitulos, subcapitulos, etc. y líneas de medición (unidades de obra excluidas) por sus precios respectivos. Por defecto 2 decimales.
DFS Decimales de los factores de rendimiento de las unidades de obra y de los elementos compuestos. Por defecto 3 decimales.
DRS Decimales de los rendimientos de las unidades de obra y de los elementos compuestos, y decimales del resultado de la multiplicación de dichos rendimientos por sus respectivos factores. Por defecto 3 decimales.
DUO Decimales del coste total de las unidades de obra. Por defecto 2 decimales.
DI Decimales de los importes resultantes de multiplicar los rendimientos totales de los elementos compuestos y/o elementos simples por sus respectivos precios, decimales del importe resultante del sumatorio de los costes directos de la unidad de obra y decimales de los costes indirectos. Decimales de los sumatorios sobre los que se aplican los porcentajes. Por defecto 2 decimales.
DES Decimales del importe de los elementos simples. Por defecto 2 decimales.
DS Decimales del total de mediciones. Por defecto 2 decimales.
DSP Decimales de la línea de subtotal de mediciones. Por defecto 2 decimales.
DEC Decimales del importe de los elementos compuestos. Por defecto 2.
Ejemplo de una base de precios que facilita importes de 2 ámbitos territoriales en 2 divisas (Se indican en negrita los campos afectados):
~V | PROPIEDAD_ARCHIVO | VERSION_FORMATO \ DDMMAA | PROGRAMA_EMISION | [ Precios de diferentes ámbitos territoriales en diferentes divisas ] \ { B-eur \ T-eur \ B-usd \ T-usd } | JUEGO_CARACTERES | [ TIPO INFORMACIÓN ] | [ NÚMERO CERTIFICACIÓN ] | [ FECHA CERTIFICACIÓN ] |
~C | { CODIGO \ } | UNIDAD | RESUMEN | { 120 \ 108 \ 102,8 \ 92,52 } | { FECHA \ } | TIPO |
~K | { DN \ DD \ DS \ DR \ DI \ DP \ DC \ DM \ DIVISA \ } | CI \ GG \ BI \ BAJA \ IVA | { DRC \ DC \ DFS \ DRS \ DUO \ DI \ DES \ DN \ DD \ DS \ DSP \ DEC \ eur \ DRC \ DC \ DFS \ DRS \ DUO \ DI \ DES \ DN \ DD \ DS \ DSP \ DEC \ eur \ DRC \ DC \ DFS \ DRS \ DUO \ DI \ DES \ DN \ DD \ DS \ DSP \ DEC \ usd \ } [ n ] |
Esquema aclaratorio
Capítulo raíz (##) DC (2)
Concepto interviniendo en una línea de descomposición:
Concepto Factor Rendimiento FR Factor*Rend Precio Importe FR*Precio
Presupuesto unitario DRC(3) DRC(3) DRC(3) DC(2) DC(2)
Capítulo(#) DC(2)*
Unidad de obra DFS(3) DS(2) DS(2) DUO(2) DC(2)
Elemento compuesto DFS(3) DRS(3) DRS(3) DEC(2) DI(2)
Elemento simple DFS(3) DRS(3) DRS(3) DES(2) DI(2)
* El importe del Capítulo (#) será el sumatorio de los importes de sus componentes.
Cálculo precio de una unidad de obra
Unidad de Obra Coste directo Coste indirecto Precio Coste directo + Coste indirecto
Elemento compuesto DI(2) DI(2) DUO(2)
Elemento simple DI(2) DI(2) DUO(2)
Mediciones Cantidad Dimensiones Subtotal Total
Líneas de medición DN(2) DD(2) DSP(2) DS(2)
Se ha añadido los decimales que se ponen por defecto según el formato después de cada término.
REGISTRO TIPO CONCEPTO.
Este registro contiene la INFORMACIÓN básica de un concepto de cualquier tipo, material, auxiliar, partida, capítulo, entidad, documento, etc., tanto en su VERSIÓN paramétrica como DEFINICIÓN tradicional.
~C | CODIGO { \ CODIGO } | [ UNIDAD ] | [ RESUMEN ] | { PRECIO \ } | { FECHA \ } | [ TIPO ] |
CODIGO: CODIGO del concepto descrito. Un concepto puede tener varios CODIGOs que actuarán como sinónimos, este mecanismo permite integrar distintos sistemas de clasificación. Puede tener un máximo de 20 caracteres.
Para distinguir el concepto tipo raíz de un archivo, así como los conceptos tipo capítulo, se ampliará su CODIGO con los caracteres ‘##’ y ‘#’ respectivamente; quedando dicha NOTACION reflejada obligatoriamente en el registro tipo ~C, siendo opcional en los restantes registros del mismo concepto.
Las referencias a un CODIGO con y sin # y/o ##, se entienden únicas a un mismo concepto.
Únicamente puede haber un concepto raíz en una base de datos u obra.
Si un código cuenta con un carácter ‘#’ intercalado, se entenderá que corresponde al conjunto CODIGO_ENTIDAD # CODIGO_CONCEPTO definido en el registro de Tipo Relación Comercial (registro ~O) o en la función BdcComercCodigo.
UNIDAD: Unidad de medida. Existe una relación de unidades de medida recomendadas, elaborada por la Asociación de Redactores de Bases de Datos de CONSTRUCCION. Véase el Anexo 7 sobre Unidades de Medida
RESUMEN: Resumen del texto descriptivo. Cada soporte indicará el número de caracteres que admite en su campo resumen. Se recomienda un máximo de 64 caracteres.
PRECIO: Precio del concepto. Un concepto puede tener varios precios alternativos que representen distintas épocas, ámbitos geográficos, etc., definidos biunívocamente respecto al campo [CABECERA \ {ROTULO_IDENTIFICACION\} del registro ~V. Cuando haya más de un precio se asignarán secuencialmente a cada ROTULO definido; si hay más ROTULOS que precios, se asignará a aquellos el último precio definido. En el caso que el concepto posea descomposición, este precio será el resultado de dicha descomposición y se proporcionará, de forma obligatoria, para permitir su comprobación. En caso de discrepancia, tendrá preponderancia el resultado obtenido por la descomposición, tal como se indica en el registro Tipo Descomposición, ~D, y complementariamente se podría informar al usuario de dicha situación. Esto se aplica también a los conceptos tipo capítulo y concepto raíz de una Obra o Presupuesto. Como excepción a esta regla está el intercambio de mediciones no estructuradas (véase la descripción del registro Tipo Mediciones, ~M).
FECHA: Fecha de la última actualización del precio. Cuando haya más de una fecha se asignarán secuencialmente a cada precio definido, si hay más precios que fechas, los precios sin su correspondiente fecha tomarán la última fecha definida.
Las fechas se definirán en el formato DDMMAAAA: DD representa el día con dos dígitos, MM el mes y AAAA el año. Si la fecha tiene 6 ó menos dígitos, el año se representará con dos dígitos (AA), interpretándose con el criterio “80/20”. Esto es, cualquier año que sea igual o superior a 80 corresponderá al siglo XX y cualquier año que sea menor de 80 corresponderá al siglo XXI. Si la fecha tiene menos de 5 dígitos representa mes y año únicamente (MMAA), si tiene menos de tres, solo el año (AA). Si se identifica la fecha con un número impar de dígitos, se completará con el carácter cero por la izquierda. Para representar una fecha sin un día o mes específico, se utilizará un doble cero en cada caso.
TIPO: Tipo de concepto. Inicialmente se reservan los siguientes tipos:
0 Sin clasificar
2 Maquinaria y medios auxiliares
4 Componentes adicionales de residuo
5 Clasificación de residuo
También se permite (y aconseja) utilizar la clasificación indicada por el BOE y la CNC en índices y fórmulas polinómicas de revisión de precios así como los aconsejados por la Asociación de Redactores de Bases de Datos de la Construcción. En el Anexo 4 aparecen los tipos actualmente vigentes.
REGISTRO TIPO DESCOMPOSICIÓN
Este registro contiene la descomposición de un concepto en otros a través de una o dos cantidades. El mismo registro lo emplearemos para definir la descomposición de un concepto tipo unidad de obra en conceptos tipo materiales, mano de obra, maquinaria y auxiliares y para la descomposición de un concepto tipo capítulo en conceptos tipo unidad de obra o subcapítulo.
Si se define como concepto derivado un concepto que no posee partes variables en su definición (no es un paramétrico) ni es un capítulo, entonces, un concepto derivado sólo puede contener en su descomposición a conceptos derivados.
~D | CODIGO_PADRE | < CODIGO_HIJO \ [ FACTOR ] \ [ RENDIMIENTO ] \ > | < CODIGO_HIJO \ [ FACTOR ] \ [ RENDIMIENTO ] \ {CODIGO_PORCENTAJE ; } \ > |
Este registro incluye el campo 2 por compatibilidad con versiones anteriores del formato, aunque los programas deben leer el campo 3 por ser más completo y en su defecto el campo 2.
CODIGO_PADRE: CODIGO del concepto descompuesto.
CODIGO_HIJO: CODIGO de cada concepto que interviene en la descomposición.
FACTOR: Factor de rendimiento, por defecto 1.0
RENDIMIENTO: Número de unidades, rendimiento o medición, por defecto 1.0
Cuando un capítulo interviene en una línea de descomposición, este no se ve afectado ni por el factor ni por el rendimiento. Estos campos se intercambian con el valor por defecto 1.0 en dicha línea de descomposición.
Cuando el CODIGO_HIJO incluye el carácter ‘%’ o el carácter ‘&’ es un porcentaje sobre las líneas anteriores de la descomposición. El código de los porcentajes tiene tres partes:
1) Prefijo, que forma una máscara indicando sobre qué elementos se aplica el porcentaje. Si el prefijo es nulo, el porcentaje se aplica a todas las líneas anteriores.
2) Un carácter, que puede ser ‘&’ (porcentaje acumulable), o ‘%’ (porcentaje no acumulable).
3) Una serie de caracteres libres que permite diferenciar un porcentaje de otro.
Ejemplo: OP%N0001
OP: Sobre todas la líneas anteriores cuyo código comience por OP.
%: Porcentaje no acumulable
N0001: Código diferenciador.
El rendimiento será el porcentaje que se aplica sobre las líneas anteriores a la actual y que queden afectadas por la máscara.
Ejemplo de una línea de descomposición: O%N0001 \\0.03\
Esta línea representa un porcentaje del 0.03 por uno (3%) de todas las líneas anteriores a la actual, incluso porcentajes, cuyo código comience por O y cuyo texto estará en la definición del código ‘O%N0001’.
Ejemplo: ~C | O%N0001 | % | Medios auxiliares |
A efectos de cálculo de precios compuestos los porcentajes acumulables y no acumulables se comportan de la misma forma. La diferencia entre ellos únicamente se manifiesta en el cálculo de cantidades de simples que hay en un presupuesto, para ello se consideraran los acumulables (‘&’) como porcentajes de perdidas, roturas u otros casos que impliquen una mayor cantidad de los recursos en líneas superiores. Los no acumulables (‘%’) se pueden referir a pequeño material u otros casos que no impliquen una mayor necesidad de recursos en líneas superiores.
La existencia del factor en líneas de descomposición y el uso casi nulo que se ha hecho de los porcentajes acumulables (‘&’) hace que éstos se mantengan por razones históricas pero se desaconseja su uso.
CODIGO_PORCENTAJE: CODIGOS de concepto porcentaje que se aplican a esta línea de descomposición. Tiene codificación libre ya que el código no se utiliza para determinar sobre que lineas aplicar el porcentaje separados con el carácter < ; > (ASCII-59) . Cuando en un descompuesto aparece explícitamente el código porcentaje en las líneas sobre las que se aplica estas determinarán de forma unívoca la aplicación del porcentaje y será preciso que en el descompuesto aparezca otra línea con el código porcentaje en el campo CODIGO_HIJO. En este caso no se aplican las reglas sobre composición del código de los porcentajes y si las que se usan para el resto de los conceptos. El porcentaje se aplicará a las suma de las líneas que la preceden y que lleven el CODIGO_PORCENTAJE. No puede aparecer un concepto porcentaje en la posición CODIGO_PORCENTAJE después de aparecer en CODIGO_HIJO. Se pueden aplicar más de un concepto porcentaje sobre la misma línea.
En el caso que el importe de un concepto se pueda obtener mediante el campo precio del registro ~C y también mediante el registro ~D, será el importe obtenido de este último el que primará sobre el importe del primero.
REGISTRO TIPO AÑADIR DESCOMPOSICIÓN
Con este registro se pueden añadir líneas de descomposición, el registro tipo ~D cambia la descomposición completa. Para añadir conceptos nuevos a una base de datos, además de definir los registros ~C, ~T, ~L, ~D,… deberíamos posicionar los nuevos conceptos en el capítulo o capítulos donde queramos situarlos, para ello, es necesario un registro que nos permita añadir una o varias líneas de descomposición por cada capítulo donde queramos posicionar un nuevo concepto.
~Y | CODIGO_PADRE | < CODIGO_HIJO \ [ FACTOR ] \ [ RENDIMIENTO ] \ > | < CODIGO_HIJO \ [ FACTOR ] \ [ RENDIMIENTO ] \ { CODIGO_PORCENTAJE ; } \ >|
Todos los campos tienen el mismo significado que en el registro tipo ~D.
REGISTRO TIPO DESCOMPOSICIÓN DE RESIDUOS
Este registro sirve para asignar los componentes que generan residuo a un concepto y adicionalmente para proporcionar propiedades que dependen de la relación padre-hijo.
~ R | CODIGO_PADRE | { TIPO_DESCOMPOSICION \ CODIGO_HIJO \ { PROPIEDAD \ VALOR \ [UM] \ } | } |
CODIGO_PADRE: Código del concepto, contenido en la base de datos.
TIPO_DESCOMPOSICION: Tipo de componentes en los que se puede descomponer un concepto. Inicialmente se definen los siguientes:
0 Residuo de componente de colocación.
1 Residuo de componente de demolición.
2 Residuo de componente de excavación.
3 Residuo de componente de embalaje.
CODIGO_HIJO: Código del concepto que interviene como componente de CODIGO_PADRE en la relación TIPO_DESCOMPOSICION, contenido en la base de datos.
PROPIEDAD: Información técnica de CODIGO_HIJO relacionado con CODIGO_PADRE. En el cálculo del residuo utilizaremos dos propiedades:
r Rendimiento.
rp Factor de residuo. Porcentaje total de residuo de colocación. Se utilizará rp cuando CODIGO_HIJO corresponda a un residuo de colocación.
VALOR: Valor alfabético o numérico de la propiedad.
UM: Unidad de medida. En el caso de que los valores de la propiedad sean numéricos se indicará de acuerdo con el Sistema Internacional de Unidades de Medida (ver anexo 7).
Cálculo de residuos.
Para calcular los residuos en conceptos descritos como discretos utilizaremos los registros ~R y ~X. Para conceptos descritos con descripciones paramétricas compliladas en DLL utilizaremos BdcNumProp, BdcPropValString, BdcNumComponentes, BdcCodigoComponente, BdcNumPropComponente y BdcComponentePropValString.
Un elemento (material, elemento unitario…) puede generar uno o varios residuos.
Cada residuo tiene que tener definido una clasificación LER, un volumen (m3) y una masa (kg).
Un residuo, aparte de por LER, también se puede clasificar por otros sistemas de clasificación.
El residuo obtenido se calcula en la unidad de medición del elemento.
Residuo de un elemento simple.
El residuo de un elemento simple se obtiene de valores directos obtenidos del campo CODIGO_IT del registro ~X (propiedades: ler, v, m).
LER del residuo de un elemento.
Clasificación LER del residuo (lista europea de residuos, según Orden MAM/304/2002).
El LER del residuo de un elemento puede ser un valor directo escogido de la lista LER o bien el listado acumulado de valores LER obtenidos de sus componentes. En los elementos simples el LER es siempre un valor directo.
[ ].ler = valor directo, o
si [ ].ler = nulo, [ ].ler = acumulación de LER de sus componentes
Volumen del residuo de un elemento.
Volumen que ocupa el elemento en el espacio.
El Volumen puede ser un valor directo o bien calcularse a partir de la suma del volumen de cada componente por la cantidad de cada componente en el elemento (Qobra). En los elementos simples el volumen es siempre un valor directo.
Cálculo del volumen de un elemento (m3 por ua, unidad de medición):
[ ].v = valor directo, o
si [ ].v = nulo, [ ].v = suma ( [C].v * [ ].[C].Qobra (ua) )
– C = componente
– Qobra (cantidad de cada componente en el elemento) = Rendimiento*Factor – Residuo
Masa del residuo de un elemento.
La masa puede ser un valor directo o bien calcularse a partir de la suma de la masa de cada componente por la cantidad de cada componente en el elemento (Qobra). En los elementos simples la masa es siempre un valor directo.
Cálculo de la masa de un elemento (kg por ua, unidad de medición):
[ ].m = valor directo, o
si [ ].m = nulo, [ ].m = suma ( [C].m * [ ].[C].Qobra (ua) )
– Qobra = Rendimiento*Factor – Residuo
Residuo de un elemento compuesto.
El residuo de un elemento compuesto se obtiene en el registro ~R del sumatorio de los residuos de sus ‘componentes de residuo’.
Los ‘componentes de residuo’ inicialmente definidos son:
– ‘Componentes de colocación’: Su residuo es el material que se tira en el proceso de formación de la obra.
Estos componentes deben existir en el registro ~D.
Se tipifican en el registro ~C con el TIPO: 0, 1, 2 o 3.
Para calcular el residuo de un ‘componente de colocación’ (C), aparte del ‘Rendimiento’ y el ‘Factor’, que se obtienen del registro ~D, necesitamos una nueva variable que es el ‘Factor de residuo’ (rp), que si existe se obtiene del registro ~R.
El residuo de un ‘componente de colocación’ (C) es:
[ ].[C].Residuo = [ ].[C].Rendimiento*Factor * [ ].[C].Factor de Residuo
donde, Factor de Residuo es el porcentaje total de residuo de colocación.
– ‘Componentes adicionales de residuo’:
– Componentes de demolición: Su residuo es el que se genera de la actividad de derribo de un elemento constructivo.
– Componentes de excavación: Su residuo es el que se genera de la actividad de excavación de un elemento constructivo.
– Componentes de embalaje: Su residuo es el que se genera del embalaje en el que vienen envueltos los materiales de un elemento constructivo.
Estos componentes no aparecen incluidos en el registro ~D.
Se tipifican en el registro ~C con el TIPO: 4.
Para calcular el residuo de un ‘componente de residuo’ (R) se necesita su rendimiento, que se obtiene del registro ~R.
El residuo de un ‘componente adicional de residuo’ (R) es:
[ ].[R].Residuo = [ ].[R].Rendimiento
Es decir, el residuo de un ‘componente adicional de residuo’ (R) en un elemento es la cantidad de componente de embalaje, excavación y demolición en el elemento.
Esquema-ejemplo del cálculo del residuo de un elemento compuesto:
Padre: “Demolición de pared y posterior construcción de pared de ladrillo con mortero…”
Hijo1: “Demolición 1 …….” (~C tipo 4) = LER (010407)
Masa unit (7) * rendimiento (3) = masa
Volumen unit (20) * rendimiento (3) = volumen
Hijo2: “Demolición 2 …….” (~C tipo 4) = LER (010502)
Masa unit (8) * rendimiento (1.5) = masa
Volumen unit (21) * rendimiento (1.5) = volumen
Hijo3: “Ladrillo …….” (~C tipo 3) = LER (010301)
Masa unit (9) * rendimiento * factor * rp (1.3) = masa
Volumen unit (22) * rendimiento * factor * rp (1.3) = volumen
Hijo4: “Mortero …….” (~C tipo 3) = LER (010702)
Masa unit (10) * rendimiento * factor * rp (1.5) = masa
Volumen unit (23) * rendimiento * factor * rp (1.5) = volumen
Hijo5: “Embalaje 1 …….” (~C tipo 4) = LER (010801)
Masa unit (11) * rendimiento (7) = masa
Volumen unit (24) * rendimiento (7) = volumen
Hijo6: “Embalaje 2 …….” (~C tipo 4) = LER (010903)
Masa unit (12) * rendimiento (8.2) = masa
Volumen unit (25) * rendimiento (8.2) = volumen
Donde los valores ‘LER’, ‘masa unit’ y ‘volumen unit’ se obtienen del registro ~X.
Los ‘hijos’, ‘rp’ y los ‘rendimientos’ de los ~C tipo 4 se obtienen del registro ~R.
Su expresión sería:
~R | Padre | 1 \ Hijo1 \ r \ 3 \ \ | 1 \ Hijo2 \ r \ 1.5 \ \ | 0 \ Hijo3 \ rp \ 1.3 \ \ | 0 \ Hijo4 \ rp \ 1.5 \ \ | 3 \ Hijo5 \ r \ 7 \ \ | 3 \ Hijo6 \ r \ 8.2 \ \ | |
~X | Hijo1 | ler \ 010407 \ m \ 7 \ v \ 20 \ |
~X | Hijo2 | ler \ 010502 \ m \ 8 \ v \ 21 \ |
~X | Hijo3 | ler \ 010301 \ m \ 9 \ v \ 22 \ |
~X | Hijo4 | ler \ 010702 \ m \ 10 \ v \ 23 \ |
~X | Hijo5 | ler \ 010801 \ m \ 11 \ v \ 24 \ |
~X | Hijo6 | ler \ 010903 \ m \ 12 \ v \ 25 \ |
Un residuo, aparte de por LER, también se puede clasificar por otros sistemas de clasificación como por ejemplo:
– Tipo de residuo, según Directiva 1999/31/CE: inerte, no peligroso, peligroso.
– Fracciones mínimas, según Real Decreto 105/2008: hormigón, tejas y materiales cerámicos, madera, plástico, envases de papel y cartón, etc.
Una vez obtenido el LER del residuo, para obtener la clasificación según otras categorías utilizaremos los registros ~C y ~D. Para identificar a las categorías y a los conceptos incluidos en dichas categorías en el registro ~C se usará el TIPO de concepto: 5. Para cada clasificación este valor se totaliza transformado en m3 y kg.
REGISTRO TIPO TEXTO
Este registro contiene el texto descriptivo de un concepto
~T | CODIGO_CONCEPTO | TEXTO_DESCRIPTIVO |
CODIGO_CONCEPTO: CODIGO del concepto descrito
TEXTO_DESCRIPTIVO: Texto descriptivo del concepto sin limitación de tamaño. El texto podrá contener caracteres fin de línea (ASCII-13 + ASCII-10) que se mantendrán al reformatearlo.
REGISTRO TIPO DESCRIPCIÓN PARAMÉTRICA
Este registro contiene la descripción paramétrica, bien en formato tradicional bien en formato API para DLL, que incluye la DEFINICION de parámetros, descomposiciones, comentario de ayuda a la selección de parámetros, resúmenes, textos, pliegos, claves e INFORMACION comercial, en función de tablas, expresiones y variables, para una familia de conceptos.
Este registro puede adoptar dos formas:
~P | | [ DESCRIPCION_PARAMETRICA ] | [ NOMBRE.DLL ] |
Cuando CODIGO_FAMILIA está lleno, o bien DESCRIPCION_PARAMETRICA está llena, o bien DESCRIPCION_PARAMETRICA está vacía. En éste último caso se accede a la descripción paramétrica de la familia a través del archivo NOMBRE.DLL.
~P | CODIGO_FAMILIA | [ DESCRIPCION_PARAMETRICA ] |
Cuando CODIGO_FAMILIA está vacío, se refiere al paramétrico global.
Si DESCRIPCION_PARAMETRICA está llena, el paramétrico global se establece a partir de ésta. Si DESCRIPCION_PARAMETRICA está vacía y NOMBRE.DLL está lleno, se establece a partir de éste. Si DESCRIPCION_PARAMETRICA y NOMBRE.DLL están llenos a la vez, tan solo es válida DESCRIPCION_PARAMETRICA.
CODIGO_FAMILIA: CODIGO del concepto tipo familia descrito. Si se utiliza un modelo de codificación dependiente de los parámetros (ver Anexos 2 y 3), este código debe poseer un carácter ‘$’ en su séptima posición, y los conceptos en los que se deriva tendrán como código los seis primeros caracteres del mismo más un carácter adicional por cada parámetro que posea.
DESCRIPCION_PARAMETRICA: Ver Anexo 2.
NOMBRE.DLL: Ver Anexo 3.
REGISTRO TIPO PLIEGOS
Este registro contiene las diferentes secciones y textos del pliego de condiciones de un concepto. El pliego de condiciones se estructura de forma jerárquica con el Sistema de Clasificación por Codificación y de forma facetada en varias secciones de distinto contenido.
Secciones de los pliegos.
Cuando el primer campo del registro ~L está vacío, el registro define los CODIGOs de las SECCIONES de cada pliego y sus ROTULOs correspondientes. Este registro es único para una base de datos u obra.
~L | | < CODIGO_SECCION_PLIEGO \ [ ROTULO_SECCION_PLIEGO ] \ > |
CODIGO_SECCION_ PLIEGO: CODIGO que define cada SECCION o faceta del pliego.
ROTULO_SECCION_PLIEGO: DEFINICION del ROTULO asociado a cada CODIGO correspondiente de cada SECCION o faceta del pliego.
Ejemplo de las secciones de los pliegos definidas para la Base de Datos de CONSTRUCCION de la Comunidad de Madrid y la Base de Datos de CONSTRUCCION de la Comunidad Valenciana, indicando CODIGO y ROTULO de la SECCION:
~L | | DES \ DESCRIPCION Y COMPLEMENTOS AL TEXTO
\ PRE \ REQUISITOS PREVIOS A LA EJECUCIÓN
\ COM \ COMPONENTES
\ EJE \ EJECUCION Y ORGANIZACION
\ NOR \ NORMATIVA
\ CON \ CONTROL Y ACEPTACION
\ SEG \ SEGURIDAD E HIGIENE
\ VAL \ CRITERIOS DE VALORACION Y MEDICION
\ MAN \ MANTENIMIENTO
\ VAR \ VARIOS \ |
Modelo 1 de textos de los pliegos.
Cuando el primer campo del registro ~L no está vacío, identifica a un concepto determinado. Puede haber un registro de este tipo por cada concepto de una base de datos u obra.
~L | CODIGO_CONCEPTO | { CODIGO_SECCION_PLIEGO \ TEXTO_SECCION_PLIEGO \ } |
{ CODIGO_SECCION_PLIEGO \ ARCHIVO_TEXTO_RTF \ } | { CODIGO_SECCION_PLIEGO \ ARCHIVO_TEXTO_HTM \ } |
CODIGO_CONCEPTO: CODIGO del concepto descrito, contenido en la base de datos.
CODIGO_SECCION_PLIEGO: DEFINICION del CODIGO asociado a cada pliego.
TEXTO_SECCION_PLIEGO: Texto asignado a cada faceta o SECCION del pliego de condiciones del concepto.
El pliego de condiciones de cada concepto estará dividido con caracteres ‘\’ en varias secciones o facetas, pensadas para imprimirse juntas o por separado.
Los fines de línea de cada SECCION del pliego se tratarán como en el REGISTRO TIPO TEXTO.
ARCHIVO_TEXTO_RTF: Es el nombre del archivo que contiene el texto en formato RTF asignado a cada SECCION del pliego del concepto. Dicho archivo deberá ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia.
ARCHIVO_TEXTO_HTM: Es el nombre del archivo que contiene el texto en formato HTM asignado a cada SECCION del pliego del concepto. Dicho archivo deberá ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia.
Modelo 2 de textos de los pliegos.
Otra opción permite asignar el Pliego mediante párrafos de texto asociados a conceptos, utilizando el siguiente esquema de registros, como forma alternativa a la anterior:
~Q | < CODIGO_CONCEPTO \ > | { CODIGO_SECCION_PLIEGO \ CODIGO_PARRAFO \ { ABREV_AMBITO ; } \ } |
~J | CODIGO_PARRAFO | [ TEXTO_PARRAFO ] | | [ ARCHIVO_PARRAFO_RTF ] | [ ARCHIVO_PARRAFO_HTM ] |
CODIGO_CONCEPTO: CODIGO del concepto descrito, contenido en la base de datos. Será único para cada registro ~Q.
Este registro es de sustitución de la INFORMACION, no es de acumulación.
CODIGO_SECCION_PLIEGO: DEFINICION del CODIGO asociado a cada pliego. Corresponde al definido en el registro de cabecera de pliego ~L.
CODIGO_PARRAFO: CODIGO del texto asociado a cada sección del pliego.
ABREV_AMBITO: Identificador del ámbito geográfico de la sección del pliego. Se define en un registro propio.
TEXTO_PARRAFO: Texto que define el contenido de los pliegos que se asocian a un concepto y se identifica con CODIGO_PARRAFO.
TEXTO_PARRAFO_RTF: Texto que define el contenido de los pliegos que se asocian a un concepto y se identifica con CODIGO_PARRAFO, con formato RTF, de forma opcional, siendo siempre obligatorio el campo TEXTO_PARRAFO.
ARCHIVO_PARRAFO_RTF: Es el nombre del archivo en formato RTF que define el contenido de los pliegos que se asocian a un concepto y se identifica con CODIGO_PARRAFO. Dicho archivo deberá ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia.
ARCHIVO_PARRAFO_HTM: Es el nombre del archivo en formato HTM que define el contenido de los pliegos que se asocian a un concepto y se identifica con CODIGO_PARRAFO. Dicho archivo deberá ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia.
REGISTRO TIPO ÁMBITO GEOGRÁFICO
Establece el ámbito geográfico correspondiente a los Pliegos de Condiciones asociados a la Base de Datos. No necesariamente deberá corresponder al campo CABECERA definido en el registro ~V.
~W | < ABREV_AMBITO \ [ AMBITO ] \ > |
ABREV_AMBITO: Nombre abreviado que identifica el territorio geográfico al que se refiere. (Comunidad Autónoma, Provincia, Región, Comarca, Localidad, etc.). El identificador < * > (ASCII – 42) indica AMBITO_GENERAL, y representa todo el territorio nacional.
AMBITO: Nombre completo del territorio geográfico.
Existe una relación de abreviaturas recomendadas, elaborada por la Asociación de Redactores de Bases de Datos de CONSTRUCCIÓN, que se puede consultar en el Anexo 5.
REGISTRO TIPO INFORMACIÓN GRÁFICA
Este registro contiene el/los archivos gráficos asociados a un concepto. Todos los archivos externos pueden ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia o bien en la url que se indique.
~G | CODIGO_CONCEPTO | < ARCHIVO_GRAFICO.EXT \ > | [URL_EXT] |
CODIGO_CONCEPTO: CODIGO del concepto descrito en la base de datos y contenido en ella.
ARCHIVO_GRAFICO.EXT: Nombre del archivo que contiene la INFORMACION gráfica. Se usarán como referencia programas estandarizados de uso general, para chequear y verificar el contenido del fichero. Estos programas serán:
URL_EXT: es un campo opcional. En el caso de no estar vacía, es la url a añadir a la URL_BASE para encontrar el gráfico. URL_BASE se define en el registro ~V. El comportamiento es: primero se busca el gráfico en el directorio local y si no está se busca en URL_BASE + URL_EXT + ARCHIVO_GRAFICO.EXT.
REGISTRO TIPO ENTIDAD
Define las entidades suministradoras de documentación técnica, tarifas de precios y especificaciones de los conceptos contenidos en la Base de Datos.
~E | CODIGO_ENTIDAD | [ RESUMEN ] | [ NOMBRE ] | { [ TIPO ] \ [ SUBNOMBRE ] \ [ DIRECCIÓN ] \ [ CP ] \ [ LOCALIDAD ] \ [ PROVINCIA ] \ [ PAIS ] \ { TELEFONO ; } \ { FAX ; } \ { PERSONA_CONTACTO ; } \ } | [ CIF ] \ [ WEB ] \ [ EMAIL ] \ |
CODIGO_ENTIDAD: CODIGO del SCc que define a la entidad (empresa, organismo, etc.).
RESUMEN: Nombre abreviado de la entidad
NOMBRE: Nombre completo de la entidad.
TIPO: Se definen los siguientes:
C Central.
D Delegación.
R Representante.
SUBNOMBRE: Nombre de la delegación o representante en caso de que sea distinto de la central. Normalmente estará vacío.
DIRECCIÓN \ CP \ LOCALIDAD \ PROVINCIA \ PAIS: Dirección postal de la entidad con todos sus datos, existiendo una dirección por cada subcampo tipo, de forma ordenada y secuencial.
TELEFONO: Números de teléfono de la entidad, de forma ordenada y secuencial respecto al subcampo tipo, separados con el carácter < ; > (ASCII-59). Se indicará con nueve caracteres numéricos, incluido el prefijo de la provincia.
FAX: Números de fax de la entidad, con las mismas especificaciones que el campo anterior.
PERSONA_CONTACTO: Nombre de las personas de contacto con la entidad y cargo que desempeña, podrá haber varias asociadas a cada subcampo tipo, de forma que estén separadas por el carácter ASCII-59.
CIF: Código de Identificación Fiscal de la empresa.
WEB: Página web de la empresa.
MAIL: Dirección de correo electrónico de la empresa.
REGISTRO TIPO RELACIÓN COMERCIAL
Este registro establece los vínculos entre los conceptos de una Base de Datos General ( BDG ) con los productos comerciales de una Base de Datos Específica ( BDE ), y/o viceversa.
Así una Base de Datos ( BD ) podrá contener CONCEPTOS genéricos de una BDG, CONCEPTOS referentes a productos comerciales de una BDE, o ambas a la vez.
~O | CODIGO_RAIZ_BD # CODIGO_CONCEPTO | | < CODIGO_ARCHIVO \ CODIGO_ENTIDAD # CODIGO_CONCEPTO \ > |
CODIGO_RAIZ_BD # CODIGO_CONCEPTO: Identificador de un concepto de una BD, donde:
CODIGO_RAIZ_BD: Se refiere a la identificación del CODIGO de la entidad que elabora la BD. Este CODIGO debe ser facilitado por la entidad que elabora la BD, para evitar ambigüedades. Se recomienda que éste sea el propio CIF de la entidad.
CODIGO_CONCEPTO: Se refiere a un concepto que pertenece a CODIGO_RAIZ_BD, y empleado por ésta en su sistema de clasificación por codificación.
CODIGO_ARCHIVO: Se refiere al nombre del archivo que, de existir, indica el lugar donde se encuentra la INFORMACION referente a CODIGO_ENTIDAD # CODIGO_CONCEPTO. Sin embargo si dicho CODIGO_ARCHIVO no existe, entonces indica que CODIGO_ENTIDAD # CODIGO_CONCEPTO se encuentra en la misma BD.
CODIGO_ENTIDAD # CODIGO_CONCEPTO: Identificador de un concepto de una BD, donde:
CODIGO_ENTIDAD: Se refiere a la identificación del CODIGO de la entidad a la que se le asocia INFORMACION. Este CODIGO debe ser facilitado por la entidad que elabora la BD, de acuerdo con su sistema de clasificación, para evitar ambigüedades. Se recomienda que éste el propio CIF de la entidad.
CODIGO_CONCEPTO: Se refiere a un concepto que pertenece a CODIGO_ENTIDAD, y empleado por la entidad que elabora la BD en su sistema de clasificación por codificación.
Cuando CODIGO_CONCEPTO se refiera a un producto comercial, dicho CODIGO deberá ser facilitado por el fabricante, y CODIGO_ENTIDAD#CODIGO_CONCEPTO no podrá coincidir nunca con la designación de CODIGO_RAIZ_BD, CODIGO_ENTIDAD o CODIGO_CONCEPTO, cuando éste se refiere a un concepto genérico. Al tener dicho producto comercial un tratamiento de CONCEPTO, éste puede utilizar todos los registros existentes en el formato para especificar su INFORMACION asociada (precio, INFORMACION gráfica, etc.). Para poder utilizar los registros mencionados, el código identificador del concepto será CODIGO_ENTIDAD#CODIGO_CONCEPTO.
REGISTRO TIPO INFORMACIÓN TÉCNICA
Este registro contiene la ESPECIFICACION de otros datos referentes al concepto, como por ejemplo, peso específico o nominal, características físicas, cuantías geométricas, propiedades físico-mecánicas, etc.
Estos datos podrían emplearse en otras utilidades, como el cálculo de los coeficientes de transmisión térmica, aislamiento acústico, etc.
El registro tipo INFORMACION Técnica puede adoptar dos formas:
Si el primer campo está vacío, éste sirve como diccionario de términos de INFORMACION Técnica a los cuales se les podrá asociar una descripción y una unidad de medida.
~X | | < CODIGO_IT \ DESCRIPCION_IT \ UM \ > |
Si el primer campo identifica a un concepto, la INFORMACION que se especificará a continuación serán la/las parejas de términos de INFORMACION técnica con sus respectivos valores.
~X | CODIGO_CONCEPTO | < CODIGO_IT \ VALOR_IT \ > |
CODIGO_IT: CODIGO de la INFORMACION Técnica descrita.
Se definen los siguientes:
ce Coste energético (MJ)
eCO2 Emisión de CO2 (kg)
ler Código ler de la lista europea de residuos
m Masa del elemento (kg)
v Volumen (m3)
DESCRIPCION_IT: Texto descriptivo de la INFORMACION Técnica, sin limitación de tamaño.
UM: En el caso que los valores de la INFORMACION Técnica sean valores numéricos, se indicará su Unidad de Medida, de acuerdo con el Sistema Internacional de Unidades de Medida.
CODIGO_CONCEPTO: CODIGO del concepto descrito, contenido en la base de datos. Será único para cada registro ~X.
VALOR_IT: Valor alfabético o numérico de la INFORMACION Técnica.
Cálculo de coste energético y emisión de CO2.
Para calcular el coste energético y emisión de CO2 en conceptos descritos como discretos utilizaremos los registros ~R y ~X. Para conceptos descritos con descripciones paramétricas compliladas en DLL utilizaremos BdcNumProp y BdcPropValString.
El coste energético unitario de un elemento compuesto se obtiene del sumatorio del coste energético de los componentes de la justificación de precios (que se obtiene de rendimiento * coste energético unitario del componente). El coste energético de los elementos simples es un valor directo.
La emisión de CO2 unitaria de un elemento compuesto se obtiene del sumatorio del coste energético de los componentes de la justificación de precios (que se obtiene de rendimiento * emisión de CO2 unitaria del componente). La emisión de CO2 de los elementos simples es un valor directo.
Para el cálculo del coste energético y de la emisión de CO2 de un elemento compuesto tendríamos que aplicar el siguiente cálculo (Se usan todos los decimales. Los cálculos y los totales se realizan sin redondeos):
[ ].ce = suma [C].ce
[ ].eCO2 = suma [C].eCO2
C = componente
Coste energético y emisión de CO2 de un componente de la justificación de precios [C] en un elemento compuesto:
[ ].[C].ce = [C]. ce * [ ].[C].Cantidad
[ ].[C].eCO2 = [C]. eCO2 * [ ].[C].Cantidad
donde [ ].[C].Cantidad = [ ].[C].Rendimiento * [C].Factor
Para describir la UM del coste energético y de la emisión de CO2 pondríamos:
~X| | ce \ coste energético \ MJ \ eCO2 \ emisión de CO2 \ kg \ |
Para definir el ‘ce’ y ‘eCO2’ de los elementos simples pondríamos:
~X | B5221FM0 | ce \ 5.4 \ eCO2 \ 0.41 \ |
REGISTRO TIPO MEDICIONES
En este registro figuran las mediciones (cantidades), en que interviene un concepto de un presupuesto en la descomposición de otro de mayor rango.
En el intercambio de archivos de presupuestos, deberá figurar siempre este registro, exista o no desglose de mediciones.
Cuando se trate de intercambiar una relación de registros ~M que recogen un listado de mediciones no estructurado, no es necesario la disposición de un CODIGO raíz ni los registros ~D complementarios. El operador indicará en estos casos cual es el destino de la medición.
~M | [ CODIGO_PADRE \ ] CODIGO_HIJO | { POSICION \ } | MEDICION_TOTAL | { TIPO \ COMENTARIO { # ID_BIM } \ UNIDADES \ LONGITUD \ LATITUD \ ALTURA \ } | [ ETIQUETA ] |
CODIGO_PADRE: CODIGO del concepto padre o concepto descompuesto del presupuesto.
CODIGO_HIJO: CODIGO del concepto hijo o concepto de la línea de descomposición.
Este campo es opcional en el caso de intercambiar mediciones no estructuradas, es decir, que no pertenecen a la estructura general y completa de un presupuesto.
POSICION: Posición del CONCEPTO_HIJO en la descomposición del CONCEPTO_PADRE, este dato permite identificar la medición cuando la descomposición del concepto padre incluye varios conceptos hijo con el mismo CODIGO, la numeración de las posiciones comenzará con el 1.
El campo POSICION deberá especificarse siempre en intercambio de presupuestos cuando éste sea completo y estructurado, e indicará el camino completo de la medición descrita en la estructura del archivo. Por ejemplo 3 \ 5 \ 2, indicará la medición correspondiente al capítulo 3 del archivo; subcapítulo 5 del capítulo 3; y partida 2 del subcapítulo 5. En mediciones no estructuradas este campo es opcional.
MEDICION_TOTAL: Debe coincidir con el rendimiento del registro tipo ‘~D’ correspondiente.
Incorpora el sumatorio del producto de unidades, longitud, latitud y altura o el resultado de expresiones de cada línea, al leer este registro se recalculará este valor.
TIPO: Indica el tipo de línea de medición de que se trate. Usualmente este subcampo estará vacío. Los tipos establecidos en esta VERSION son:
‘1’ Subtotal parcial: En esta línea aparecerá el subtotal de las líneas anteriores desde el último subtotal hasta la línea inmediatamente anterior a ésta.
‘2’ Subtotal acumulado: En esta línea aparecerá el subtotal de todas las líneas anteriores desde la primera hasta la línea inmediatamente anterior a ésta.
‘3’ Expresión: Indicará que en el subcampo COMENTARIO aparecerá una expresión algebraica a evaluar. Se podrán utilizar los operadores ‘(‘, ‘)’, ‘+’, ‘-‘, ‘*’, ‘/’ y ‘^’; las variables ‘a’, ‘b’, ‘c’ y ‘d’ (que tendrán por valor las cantidades introducidas en los subcampos UNIDADES, LONGITUD, LATITUD y ALTURA respectivamente); y la constante ‘p’ para el valor Pi=3.1415926. Esta expresión será válida hasta la siguiente línea de medición en la que se defina otra expresión. Solo se evalúa la expresión y no se multiplica por las unidades. Las expresiones fórmulas utilizan los criterios definidos en el anexo 2.
COMENTARIO: Texto en la línea de medición. Podrá ser un comentario o una expresión algebraica.
# ID_BIM: Es opcional, surge de la necesidad de transmitir el o los identificadores de los elementos constructivos en el modelo BIM hacia los programas de presupuestos para el intercambio bidireccional de información entre ambas plataformas. Dichos identificadores puede aparecer en diferentes líneas de medición de otros conceptos del presupuesto ya que un mismo elemento constructivo puede tener asociadas más de un concepto. En caso de incluir dichos identificadores el número de ellos debe coincidir con el número expresado en el campo UNIDADES.
UNIDADES, LONGITUD, LATITUD, ALTURA: Cuatro número reales con las mediciones. Si alguna magnitud no existe se dejará este campo vacío.
ETIQUETA: Es opcional, surge de la necesidad de transmitir un identificador de los conceptos (capítulos, subcapítulos o partidas). Este identificador lo imprimen, diversos programas, en los listados de mediciones o presupuesto de una Obra (por ejemplo, ‘2.10’, ‘A-27b’, ‘001001’,…); siendo único para cada concepto (capítulo, subcapítulo o partida) y, en general, diferente de la codificación de la base de datos empleada para confeccionar el presupuesto (El ‘CODIGO_HIJO’ muchas veces no aparece en los listados mencionados).
Para transmitir la etiqueta de un capítulo, o subcapítulo, del presupuesto, también se utilizará este registro. En ese caso, el campo MEDICION_TOTAL, habitualmente, será 1 y los campos TIPO, COMENTARIO, UNIDADES, LONGITUD, LATITUD y ALTURA no existirán:
~M | [ CODIGO_PADRE \ ] CODIGO_HIJO | { POSICION \ } | 1 | | [ ETIQUETA ] |
REGISTRO TIPO AÑADIR MEDICIONES
Igual que el registro tipo ~M pero añade las líneas de medición de este registro a las ya existentes en vez de sustituir toda la medición como hace en aquel.
~N | [ CODIGO_PADRE \ ] CODIGO_HIJO | { POSICION \ } | MEDICION | { TIPO \ COMENTARIO { # ID_BIM } \ UNIDADES \ LONGITUD \ LATITUD \ ALTURA \ } | [ ETIQUETA ] |
REGISTRO TIPO CLAVES
Este registro establece la relación entre CODIGOs y descriptores del tesauro, para permitir la búsqueda de conceptos mediante términos clave.
~A | CODIGO_CONCEPTO | < CLAVE_TESAURO \ > |
CLAVE_TESAURO: Términos clave relacionados con el concepto. Los términos compuestos (hormigón armado, cartón-yeso, mortero mixto) se identificarán unidos mediante < _ > (ASCII – 95), (hormigón_armado, cartón_yeso, mortero_mixto…). No está permitido el empleo del espacio en blanco.
REGISTRO TIPO CAMBIO DE CÓDIGO
Con este registro se posibilita el cambio o anulación de los CODIGOs de los conceptos, única unidad de INFORMACION que no se podía modificar con los registros definidos anteriormente.
~B | CODIGO_CONCEPTO | CODIGO_NUEVO |
CODIGO_CONCEPTO: CODIGO del concepto a cambiar o anular. Debe existir y pertenece a un concepto contenido en la BD.
CODIGO_NUEVO: Nuevo CODIGO para CODIGO_CONCEPTO, no debe existir previamente. Si este campo está vacío, se entiende que hay que eliminar CODIGO_CONCEPTO.
REGISTRO TIPO DOCUMENTO ADJUNTO.
Este registro permite asociar a un concepto archivos con diferentes tipos de información.
~F | CODIGO_CONCEPTO | { TIPO \ { ARCHIVO.EXT ; } \ [ DESCRIPCION_ARCHIVO ] \ } | [URL_EXT] |
CODIGO_CONCEPTO: Código del concepto descrito en la base de datos y contenido en ella al cual se le asocia una información en forma de archivo.
TIPO: Código del tipo de información que contiene el archivo.
Inicialmente se consideran los siguientes:
1 Características técnicas y de fabricación.
2 Manual de colocación, uso y mantenimiento.
3 Certificado/s de elementos y sistemas.
4 Normativa y bibliografía.
5 Tarifa de precios.
6 Condiciones de venta.
7 Carta de colores.
8 Ámbito de aplicación y criterios selección.
9 Cálculo de elementos y sistemas.
10 Presentación, datos generales, objetivos, etc. de empresa.
11 Certificado/s de empresa.
12 Obras realizadas.
13 Imagen.
ARCHIVO.EXT: Nombre del archivo con extensión que contiene información de CODIGO_CONCEPTO.
Un archivo (principal) puede contener archivos vinculados, separados con el carácter < ; > (ASCII-59), siendo el principal el primero que se muestre. Todos los archivos (incluso los vinculados) pueden ubicarse en el mismo directorio donde se hallen el/los archivos con extensión BC3 que incluyen su referencia o bien en la url que se indique.
Además de las extensiones permitidas en los registros ~G, ~L y ~J, se añaden los siguientes usando como referencia programas estandarizados de uso general, para chequear y verificar el contenido del fichero:
Extensión .PDF Acrobat Reader v.5
Extensión .AVI Media Player v.7
Extensión .PPT Power Point v.10
DESCRIPCION_ARCHIVO: Breve descripción de la información contenida en el archivo.
URL_EXT: es un campo opcional. En el caso de no estar vacía, es la url a añadir a la URL_BASE para encontrar el documento. URL_BASE se define en el registro ~V. El comportamiento es: primero se busca el gráfico en el directorio local y si no está se busca en URL_BASE + URL_EXT + ARCHIVO.EXT.
FORMATO FIEBDC-3. RESUMEN
~K | { DN \ DD \ DS \ DR \ DI \ DP \ DC \ DM \ DIVISA \ } | [ [ CI ] \ [ GG ] \ [ BI ] \ [ BAJA ] \ [ IVA ] ] | { DRC \ DC \ DFS \ DRS \ DUO \ DI \ DES \ DN \ DD \ DS \ DSP \ DEC \ DIVISA \ } | [ n ] |
~L | CODIGO_CONCEPTO | { CODIGO_SECCION_PLIEGO \ TEXTO_SECCION_PLIEGO \ } | { CODIGO_SECCION_PLIEGO \ ARCHIVO_TEXTO_RTF \ } | { CODIGO_SECCION_PLIEGO \ ARCHIVO_TEXTO_HTM \ } |
~E | CODIGO_ENTIDAD | [ RESUMEN ] | [ NOMBRE ] | { [ TIPO ] \ [ SUBNOMBRE ] \ [ DIRECCIÓN ] \ [ CP ] \ [ LOCALIDAD ] \ [ PROVINCIA ] \ [ PAIS ] \ { TELEFONO ; } \ { FAX; } \ { PERSONA_CONTACTO ; } \ } | [ CIF ] \ [ WEB ] \ [ EMAIL ] \ |
Anexo 1. Cambios respecto a versiones anteriores: 3/2012, 3/2007, 3/2004, 3/2002, 3/98 y 3/95.
Resumen de los cambios de la versión 3/2004 con respecto a 3/2002:
Especificación: Se incluye la notación para campos opcionales.
~V Registro tipo VERSIÓN: Nuevo campo COMENTARIO.
~K Registro tipo COEFICIENTES: Se establece los decimales por defecto, modificaciones de algunos campos decimales.
~D Registro tipo DESCOMPOSICION: Se establece el valor por defecto para el rendimiento.
~C Registro tipo CONCEPTO: Modificaciones de los campos CÓDIGO y PRECIO.
~M y ~N Registro tipo MEDICION y AÑADIR MEDICION: Nuevo campo ETIQUETA.
Registros actualizados con las notaciones para definir campos obligatorios y opcionales: ~V, ~D, ~Y, ~T, ~L, ~Q, ~W, ~G, ~O, ~X, ~A y ~B.
Nuevo registro ~F tipo DOCUMENTO ADJUNTO.
Cambios de la API estándar para descripciones paramétricas compiladas:
Nueva función BdcTipoDescripcion().
Nueva función BdcInvalidos().
Aclaración de la función BdcPliego().
Modificación de los parámetros de la función BdcComercCodigo().
Nuevo mensaje de error BDCERR_PARÁMETRO_INCORRECTO.
Nuevas funciones BdcDocNumero() y BdcDocCodigo() relacionadas con el registro ~F tipo documento adjunto.
Clasificación en tipos de los conceptos:
Nuevo tipo Presupuesto Unitario.
Resumen de los cambios de la versión 3/2007 con respecto a 3/2004:
Especificación: Aclaración sobre la prohibición de usar espacios en blanco en los códigos de los conceptos: “incluyendo A-Z, a-z, 0-9, ñ, Ñ,” … “Excluyendo cualquier otro carácter como espacio, tabulador, etc”.
~V Registro tipo VERSIÓN: Nuevos campos TIPO INFORMACIÓN, NUMERO CERTIFICACIÓN y FECHA CERTIFICACIÓN.
~K Registro tipo COEFICIENTES: Se suprimen los campos DRO Y DFO. Se añaden los campos DSP y DEC.
~C Registro tipo CONCEPTO: Limitación del código a 20 caracteres. Recomendación de 64 caracteres como máximo para el resumen.
~D Registro tipo DESCOMPOSICIÓN: Eliminar factor y rendimiento de los capítulos.
~M Registro tipo MEDICIÓN: Aclaración sobre el uso de expresiones.
Anexo 4: Aclaración sobre que el tipo Presupuesto Unitario no debe usar la # del tipo capítulo.
Resumen de los cambios de la versión 3/2012 con respecto a 3/2007:
~V Registro tipo VERSIÓN: Nuevo campo URL_BASE donde suministrar documentos y gráficos asociados a conceptos en una url.
~C Registro tipo CONCEPTO. Ampliación de los TIPO de conceptos ‘4’ y ‘5’.
~D Registro tipo DESCOMPOSICIÓN. Nuevo campo 3.
~Y Registro tipo AÑADIR DESCOMPOSICIÓN. Nuevo campo 3.
Nuevo registro ~R tipo DESCOMPOSICIÓN DE RESIDUOS.
~G Registro tipo INFORMACIÓN GRÁFICA y ~F Registro tipo DOCUMENTO ADJUNTO. Nuevo campo URL_EXT para añadir a la URL_BASE donde suministrar documentos y gráficos asociados a conceptos. En el registro ~F se añade el documento TIPO ‘13’.
~O Registro tipo INFORMACIÓN COMERCIAL. Aclaración del campo CODIGO_ENTIDAD # CODIGO_CONCEPTO.
~X Registro tipo INFORMACIÓN TÉCNICA. Se especifican los tipos ‘ce’, ‘eCO2’, ‘ler’, ‘m’ y ‘v’ de CODIGO_IT y se adjunta el sistema de cálculo de coste energético y emisión de CO2.
Anexo 4: Se añaden los tipos de concepto 4 y 5.
Nueva función BdcUsos.
Nueva función BdcDesCodigoPorcentaje.
Función BdcDocCodigo. Se añade que los archivos pueden contener una URL_EXT.
Nueva función BdcNumProp.
Nueva función BdcPropValString.
Nueva función BdcNumComponentes.
Nueva función BdcCodigoComponente.
Nueva funcióm BdcNumPropComponente.
Nueva función BdcComponenteValString.
Resumen de los cambios de la versión 3/2016 con respecto a 3/2012:
Especificación: Se especifica el modo de transferencia de información desde bases de datos en Internet a las aplicaciones en ordenadores locales utilizando FIEBDC.
~K Registro tipo COEFICIENTES: Se aclara que hacer cuando se reciben cantidades con más cifras decimales que las especificadas en el registro ~K de un archivo FIEBDC, y por otra parte que hacer en el caso de recibir un archivo FIEBDC sin el registro ~K.
~M Registro tipo MEDICIONES y ~N Registro tipo AÑADIR MEDICIONES: Se especifica como transmitir el o los identificadores de los elementos constructivos en el modelo BIM hacia los programas de presupuestos para el intercambio bidireccional de información entre ambas plataformas.
Anexo 2: Modificación de los conceptos paramétricos en el modelo de codificación dependiente de los parámetros, tenga DLL o no, para poder tener más de cuatro parámetros.
Anexo 4: Se desdoblan los tipos de conceptos obtenidos de los índices y fórmulas polinómicas de revisión de precios del BOE, entre los del RD 1359/2011 y los anteriores a dicho RD.
Anexo 7: Actualización de la normativa que regula las unidades de medida.
Anexo 8: Actualización de la definición de los tipos de presupuesto PEM y PEC, así como añadir el sistema de cálculo de las unidades de obra, de acuerdo a lo indicado en el Real Decreto 1098/2001 Reglamento General de la Ley de Contratos de las Administraciones Públicas.
A continuación se indica la lista de apartados y registros del FIEBDC 3/2016 afectados por ampliaciones y/o modificaciones:
Apartado 3/2012 3/2007 3/2004 3/2002 3/98 3/95
PRESENTACION. X X X X X X
FORMATO FIEBDC-3. ESPECIFICACION. X X X X X
~V. Registro tipo PROPIEDAD Y VERSION. X X X X X
~K. Registro tipo COEFICIENTES. X X X X X
~C. Registro tipo CONCEPTO. X X X X X
~D. Registro tipo DESCOMPOSICION. X X X X X
~Y. Registro tipo AÑADIR DESCOMPOSICION. X X X X
~R. Registro tipo DESCOMPOSICIÓN de RESIDUOS. X
~T. Registro tipo TEXTO. X X X
~P. Registro tipo DESCRIPCIÓN PARAMETRICA. X
~L. Registro tipo PLIEGOS. X X X
~Q. Registro tipo PLIEGOS. X X X
~W. Registro tipo AMBITO GEOGRAFICO. X X X
~G. Registro tipo INFORMACION GRAFICA. X X X X
~E. Registro tipo ENTIDAD. X X
~O. Registro tipo RELACION COMERCIAL. X X X X
~X. Registro tipo INFORMACION TECNICA. X X X X
~M. Registro tipo MEDICIONES. X X X X X
~N. Registro tipo AÑADIR MEDICIONES. X X X X
~A. Registro tipo CLAVES. X X X
~B. Registro tipo CAMBIO DE CODIGO. X X X
~F. Registro Tipo DOCUMENTO ADJUNTO. X X X X
Anexo 2. Descripción paramétrica: Formato ESTANDAR. X
Anexo 3. Descripción paramétrica: API ESTANDAR para descripciones paramétricas compiladas en DLL. X X X X
Anexo 4. Clasificación en tipos de los Conceptos. X X X X X X
Anexo 7. Unidades de medida. X
Anexo 8. Definiciones de diferentes tipos de Presupuestos. X
Anexo 2. DESCRIPCIÓN PARAMÉTRICA: Formato ESTANDAR.
Un concepto paramétrico es el que define su CODIGO, resumen, texto, pliego, descomposición e INFORMACION comercial de forma paramétrica, esto es, de una forma variable mediante tablas y expresiones aritméticas y lógicas función de parámetros.
En la descripción paramétrica se encuentran las siguientes sentencias:
Se definen las variables:
%A %B %C %D %F %G %H %I %J %K: Parámetros seleccionados del concepto de “a” a “z” ~ 1 a 26
%O %P %Q %R %S %T %U %V %W %X: Parámetros seleccionados de la obra de “a” a “z” ~ 1 a 26
%E: Variable que define las condiciones de error.
$A $B $C $D $F $G $H $I $J $K: Textos de los parámetros seleccionados del concepto.
$O $P $Q $R $S $T $U $V $W $X: Textos de los parámetros seleccionados de la obra.
$E: Variable que define los textos de error.
De forma equivalente las variables %O a %X y $O a $X tomarían el valor correspondiente a los valores de los parámetros generales de la obra.
Cualquier variable de la ‘A’ a la ‘Z’ tanto numérica (%) como alfanumérica ($) se puede definir o redefinir con cualquier número de dimensiones para ser utilizada posteriormente en expresiones.
Se definen las constantes de la ‘a’ a la ‘z’ con los valores numéricos del 1 al 26 respectivamente, para permitir referenciar los parámetros de forma nemotécnica. Para la utilización de otro tipo de caracteres, se determinará en el texto de la opción del parámetro seleccionado el carácter de sustitución que se desea utilizar, anteponiéndole un carácter especial ‘ ! ‘ .Si dicho carácter no existe la sustitución se realiza relacionando el carácter con la posición que ocupa.
Ejemplo: PBPO.2$ M3 Hormigón $B $A
\ CONSISTENCIA \ plástica \ fluida \ blanda \
\ RESISTENCIA \ H-125 \ H-150 \ H-175 \ H-200 \
El derivado PBPO.2aa sería: M3 Hormigón H-125 plástica
Con el carácter especial:
\ CONSISTENCIA \ !p plástica \ !f fluida \ !b blanda \
\ RESISTENCIA \ !2 H-125 \ !5 H-150 \ !7 H-175 \ !0 H-200 \
El mismo derivado sería: PBPO.2p2 M3 Hormigón H-125 plástica.
Las variables numéricas deben permitir valores reales en coma flotante de doble precisión (64bits) y las variables alfanuméricas deben poder almacenar textos de cualquier tamaño.
Cualquier variable puede definirse, en la misma asignación, con cualquier número y tamaño de dimensiones (hasta 4), en la DEFINICION de dimensiones tendrán que hacerse explícitas todas las dimensiones.
%U =…… # define una variable con un dato numérico
$X(8) =….. # define una lista de 8 datos alfanuméricos
%V(3,4) = ….. # define una tabla con 3 filas y 4 columnas de datos n.
Las variables %E y $E son especiales para devolver errores producidos por selecciones de parámetros no coherentes. En una evaluación secuencial de expresiones, si en una expresión la variable %E adopta un valor distinto de 0, ha habido algún error, se interrumpe la evaluación de expresiones y se presenta el contenido de la variable $E donde se almacena el texto del error producido.
Pueden haber múltiples asignaciones de %E, cada una de ellas precedida de su correspondiente texto de error, asignación de $E.
Las constantes alfanuméricas se definirán entre comillas ($I=”incluida parte proporcional”).
En la descripción paramétrica podemos encontrar los siguientes tipos de sentencias:
SENTENCIA DE ROTULOS DE PARAMETRO:
\ \ { \ }
Los parámetros definidos, hasta 10, se irán asignando a las variables ABCDFGHIJK en el orden que se encuentren.
SENTENCIA DE ASIGNACION NUMERICA:
SENTENCIA DE ASIGNACION ALFANUMERICA:
SENTENCIA DE RENDIMIENTO (CONCEPTOS DESCOMPUESTOS):
: [ : ] Se pueden definir uno u opcionalmente dos rendimientos, el defecto del rendimiento opcional es 1.
SENTENCIA DE MEDIOS AUXILIARES:
%: (en tanto por cien)
%%: (en tanto por uno)
SENTENCIA DE PRECIO (CONCEPTOS SIMPLES):
En caso de figurar conjuntamente un juego de sentencias de rendimiento a modo de descomposición y una sentencia de precio, tendrá prioridad la sentencia de precio, ignorando las sentencias de rendimiento.
SENTENCIA DE COMENTARIO:
\ COMENTARIO \ ó \ C \ \
Si existe texto de comentario, se presentará como ayuda a la selección de parámetros junto a las opciones de éstos.
SENTENCIA DE SUSTITUCION:
\ RESUMEN \ ó \ R \ \
\ TEXTO \ ó \ T \ \
\ PLIEGO \ ó \ P \ { \ }
\ CLAVES \ ó \ K \ { \ }
\ COMERCIAL \ ó \ F \ { \ \}
Se considera que una sentencia contínua en la línea siguiente si:
– Acaba en un operador
– Acaba sin cerrar comillas ‘”‘
– Comienza con ‘\’ y no acaba con ‘\’
PI, números, “texto” …
ABS( ), INT( ), SQRT( ) …
[$%] [A-Z] [(dimensión{,dimensión})]
Son aquellas que dan como resultado un número en función de constantes y variables numéricas, expresiones lógicas, funciones y operadores.
por ejemplo: %I= %A + 3.17*(1+%B) + ABS(%P+3.15*%Q)/12000
Son aquellas que dan como resultada un texto en función de constantes y variables alfanuméricas, operadores y funciones numéricas.
Una expresión alfanumérica puede incluir expresiones lógicas.
por ejemplo: $I=”parte proporcional”+” de perdidas”*(%A>a)
añadir ” de perdidas” a $I si el valor actual de %A es mayor que ó 1.
Son aquellas que dan como resultado VERDADERO o FALSO. En expresiones numéricas el verdadero se considera como 1 y el falso como 0, en alfanuméricas el falso se considera suprimir texto.
%I = 323*(%A=a) + 345*(%A=b) + 1523*($I=$A & $J=$B)
$I = “blanco”*(%C=c) + “negro”*(%C=d)
En los textos de sustitución la INFORMACION es un texto constante (sin comillas) con variables embebidas en él. Se consideran variables los caracteres $ y % inmediatamente seguidos por una letra de la A a la Z.
En los textos de sustitución, las variables alfanuméricas se sustituyen por sus contenido de texto correspondiente, las numéricas se sustituyen por las constantes de la “a” a la “z” correspondientes al valor numérico de su contenido.
En la expresión del rendimiento, la primera parte de la sentencia es un texto de sustitución que una vez sustituidas las variables será el CODIGO del concepto al que le corresponde la expresión numérica de la segunda parte de la expresión como rendimiento. Si el resultado es 0, se ignora la sentencia y no se considera ese componente o línea de descomposición.
CONVENIOS DE NOTACION (EBNF):
[a-b] Indica cualquier valor desde “a” a “b” inclusivas
[abc] Indica cualquiera de los valores a, b ó c
Indica descripción informal
abc Indica símbolo terminal
%[A-Z] Variable numérica
$[A-Z] Variable alfanumérica
Variables predefinidas:
[%$][ABCDFGHIJKLM] Parámetros del concepto
[%$][OPQRSTUVWX] Parámetros de la obra
[%$]E Variable especial para reportar errores
[%$][A-Z][(dim{,dim})] Variables definibles
# Comentarios (el texto comprendido entre este carácter y el siguiente final de línea exclusive, no se tiene en cuenta)
, Separador de datos
: DEFINICION de rendimiento
:: DEFINICION de precio
%: DEFINICION de medios auxiliares en tanto por cien
%%: DEFINICION de medios auxiliares en tanto por uno
OPERADORES NUMERICOS (De menor a mayor precedencia):
^ Operador elevado a
OPERADORES LOGICOS (De menor a mayor precedencia):
@ Operador lógico O
& Operador lógico Y
! Operador lógico NO
FUNCIONES — VALOR RETORNADO:
ABS(n) Valor absoluto de “n”
INT(n) Parte entera de “n”
ROUND(n,d) Redondeo de “n” a “d” decimales
SIN(n) Seno (grados sexagesimales)
COS(n) Coseno (grados sexagesimales)
TAN(n) Tangente (grados sexagesimales)
ASIN(n) Arco seno (gs)
ACOS(n) Arco coseno (gs)
ATAN(n) Arco tangente (gs)
ATAN2(x,y) Arco tangente con dos parámetros “x” e “y”
SQRT(n) Raíz cuadrada de “n”
ATOF(a) ConVERSION de alfanumérico “a” a numérico
FTOA(n) ConVERSION de numérico “n” a alfanumérico
Cada instrucción irá en distinta línea, a menos que la instrucción acabe en un operador en cuyo caso se considera que sigue en la siguiente línea.
Si una línea acaba sin haber cerrado las comillas ‘”‘ o delimitador ‘\’, se considerará que sigue en la línea siguiente. Los caracteres fin de línea (ASCII-13 + ASCII-10) contenidos en las descripciones paramétricas se mantendrán al reformatear.
CONTROL DE ERRORES DE SELECCION.
Es frecuente encontrar un gran número de combinaciones de parámetros posibles pero tener pocas de ellas resueltas. Para evitar que el operador del sistema pruebe distintas combinaciones de parámetros consiguiendo en todas ellas un mensaje de error, el sistema debe ser capaz de guiarle en la selección de combinaciones correctas.
Cada vez que el operador define un parámetro, el sistema evaluará todas las sentencias posibles y en las sentencias del tipo: %E= …, función de parámetros.
Si todos los parámetros intervinientes en la expresión son conocidos, se evaluará ésta y si el resultado fuera de ERROR se presentará la previa DEFINICION de $E con el mensaje del error.
Si todos los parámetros menos uno son conocidos, se irá dando valores al parámetro desconocido y evaluando la expresión hasta recorrer todos los valores válidos del parámetro. De alguna forma, el sistema “marcará” los valores que producen ERROR del parámetro estudiado en la pantalla de selección, para ayudar al operador a seleccionar las combinaciones correctas.
Cada vez que se defina o redefina un parámetro el sistema actualizará todos los valores marcados en pantalla, por ejemplo pondrá en “medio brillo” los ROTULOs de las opciones cuya selección no sería compatible con los parámetros seleccionados previamente.
Este sistema de control de errores de selección es sencillo de implementar en cualquier soporte, pero obliga a los redactores de los descompuestos paramétricos a definir explícitamente las combinaciones de parámetros incorrectas, ya que con este método no se podrían encontrar combinaciones no permitidas cuando en la descomposición paramétrica se llama a otros descompuestos o precios paramétricos.
PROCEDIMIENTO DE LECTURA DE DESCRIPCIONES PARAMETRICAS.
Recorrer la descripción paramétrica ejecutando los siguientes pasos:
1. Eliminar desde el carácter ‘#’ inclusive hasta el siguiente cambio de línea exclusive.
2. Cambiar tabuladores (9) por caracteres ‘ ‘ (32)
3. Eliminar caracteres ‘ ‘ (32) delante y detrás de los caracteres ‘\’
4. Unir líneas, eliminando el fin de línea, en líneas que comienzan con ‘\’ y no acaban con ‘\’, que terminan con un operador y en la separación de datos de una variable matricial.
5. Eliminar todos los caracteres ‘ ‘ (32) en zonas no entrecomilladas (“…”) o delimitadas (\…\)
6. Eliminar líneas vacías.
7. Leer y evaluar secuencialmente las sentencias de la forma:
Si la sentencia comienza con ‘\’ leer el ROTULO hasta el siguiente ‘\’, si el ROTULO es:
COMENTARIO ó C- Palabra o carácter reservado que identifica el siguiente ROTULO entre ‘\’ como comentario a la selección de parámetros.
RESUMEN ó R- Palabra o carácter reservado que identifica el siguiente ROTULO entre ‘\’ como el texto de sustitución del resumen del concepto.
TEXTO ó T- Palabra o carácter reservado que identifica el siguiente ROTULO entre ‘\’ como el texto de sustitución del texto descriptivo del concepto.
PLIEGO ó P- Palabra o carácter reservado que identifica los siguientes ROTULOs entre ‘\’ como los textos de sustitución de las distintas secciones del pliego.
CLAVES ó K- Palabra o carácter reservado que identifica los siguientes ROTULOs entre ‘\’ como los textos de sustitución de los términos claves asociados al concepto.
COMERCIAL ó F – Palabra o carácter reservado que identifica los siguientes ROTULOs entre ‘\’ como los textos de sustitución y tarifas de la INFORMACION comercial del concepto.
Cualquier otro ROTULO identificará el nombre del siguiente parámetro y los siguientes ROTULOs entre ‘\’ como los ROTULOs de las opciones de dicho parámetro.
Si la sentencia comienza con ‘::’ el resto de la misma debe ser una expresión numérica indicadora del Precio, sólo en familias de conceptos simples (sin descomposición) y sólo puede haber una sentencia de este tipo.
Si la sentencia comienza con ‘%:’ el resto de la misma debe ser una expresión numérica indicadora del Porcentaje de Medios Auxiliares, sólo puede haber una sentencia de este tipo.
En otro caso si la sentencia contiene el carácter ‘:’ la parte anterior a él es un texto de sustitución del CODIGO de una línea de descomposición y la posterior una expresión numérica, o dos separadas por ‘:’, indicadoras de el o los rendimientos de dicha línea de descomposición.
En aquellos casos donde pueda aparecer un carácter ’%’ seguido de un carácter alfabético que se considere como tal y no como una variable de sustitución, deberá emplearse ’%%’, para evitar la ambigüedad que se puede producir entre una variable numérica que deba ser sustituida, una sentencia de medio auxiliar o un texto.
El resto de sentencias deberán ser de asignación de la forma variable/s = expresión/es
RESUMEN DE TIPOS DE SENTENCIAS.
Después de realizado el filtro descrito arriba, cada línea, tira de caracteres acabada en (ASCII-13)(ASCII-10), será una sentencia de alguno de los siguientes tipos:
{ \ ROTULO_parámetro \ { opción_parámetro \ } (13)(10) }
{ variable = expresión (13)(10) }
{ CODIGO : rendimiento [ : rendimiento ] (13)(10) }
[ %: ó %%: medios_auxiliares (13)(10) ] % (tanto por cien) %% (tanto por uno)
[ :: expresión_precio (13)(10) ]
[ \ COMENTARIO \ ó \ C \ texto_comentario \ (13)(10) ]
[ \ RESUMEN \ ó \ R \ texto_resumen \ (13)(10) ]
[ \ TEXTO \ ó \ T \ texto_descriptivo \ (13)(10) ]
[ \ PLIEGO \ ó \ P \ { texto_faceta_pliego \ }(13)(10) ]
[ \ CLAVES \ ó \ K \ { término_clave \ }(13)(10) ]
[ \ COMERCIAL \ ó \ F \ { CODIGO_producto_comercial \ tarifa \ } (13)(10) ]
Anexo 3. DESCRIPCIÓN PARAMÉTRICA: API ESTANDAR para descripciones paramétricas compiladas en DLL
Debido a la necesidad expuesta por los desarrolladores de bases de datos paramétricas de ampliar las posibilidades del lenguaje de descripción paramétrica, poder compilar éste por eficiencia y protección de datos y posibilitar la protección contra copia de bases de datos paramétricas, se establece la siguiente ESPECIFICACION.
En este documento se definen los componentes necesarios para el desarrollo de descripciones paramétricas en cualquier lenguaje de aplicaciones para Windows (C, C++, Pascal, Fortran, etc.) y sin ninguna limitación. Se incluye la DEFINICION de un API ESTANDAR en C, un ejemplo de base de datos en formato DLL de 32 bits desarrollado en C++ y un ejemplo de aplicación con la implementación del interfaz con el API en C, definidos ambos en Microsoft Visual C++. Se podría implementar el interfaz con el API para otros compiladores y lenguajes para acceder a las mismas DLL.
Es decir; es posible construir una base de datos que cumpla este API utilizando para ello cualquier lenguaje de programación que permita desarrollar librerías de enlace dinámico Windows (DLL). Asimismo, es posible construir un programa que lea cualquier base de datos de estas características utilizando lenguajes de aplicaciones para Windows.
El juego de caracteres utilizado en los textos devueltos por las funciones del API será el especificado en el registro ~V.
ARCHIVOS QUE DEBE CONTENER UNA BASE DE DATOS.
Una base de datos que se desee distribuir con las definiciones paramétricas compiladas en DLL, debe contener los siguientes archivos:
base.dll En este archivo, único para cada base de datos y de nombre cualquiera pero extensión ‘.DLL’, se encuentran las funciones del API que la base de datos ofrece a las aplicaciones para que éstas obtengan la INFORMACION que contiene la base.
base.bc3 Archivo o archivos ASCII de la base de datos en formato FIEBDC-3/98. Los registros ~P de los conceptos cuya descripción paramétrica se acceda a través del archivo ‘base.dll’, tendrán el campo DESCRIPCIÓN_PARAMÉTRICA vacío. El CODIGO del concepto de este registro deberá coincidir con el CODIGO del registro ~C correspondiente y con el CODIGO utilizado en las llamadas a las funciones del API, incluida(s) la(s) posible(s) almohadillas (‘#’). Ejemplo: ~P|ABCD12$| |
El registro ~P correspondiente al paramétrico global, tendrá el campo DESCRIPCIÓN_PARAMÉTRICA vacío, y tendrá un tercer campo con el nombre del archivo DLL en el que se encuentren las funciones del API de la base. Ejemplo: ~P| | | BASE.DLL |
La DEFINICION paramétrica de los conceptos implementados de esta forma podrá estar en el mismo archivo que las funciones del API (el archivo ‘base.dll’) o situado en otro u otros archivos cualesquiera, conforme desee el desarrollador de la base de datos. Las aplicaciones sólo accederán a las funciones del API incluidas en el archivo ‘base.dll’, y éstas serán las encargadas de acceder a la INFORMACION en la forma que el desarrollador de la base implemente.
DEFINICION DEL API: FIEBDC.H
Único archivo que define el ESTANDAR. En este archivo se define el API en C, que las descripciones paramétricas en DLL ofrecen a las aplicaciones. Se recomienda incluir en las Bases de Datos todas las funciones del API, aunque no se utilicen todas por la misma. Este interfaz permite definiciones paramétricas de ilimitado número de parámetros e ilimitadas opciones por parámetro. Se soportan dos modelos de codificaciones:
Un modelo de codificación independiente de parámetros, en el que el CODIGO de un concepto paramétrico es completamente libre y el número de caracteres del CODIGO es independiente del número de parámetros. En este modelo, los códigos de las familias paramétricas no tienen por qué tener el carácter $.
Un modelo dependiente de los mismos. Es el modelo que definía FIEBDC-3/95 y en el que el CODIGO de un concepto paramétrico debe tener un símbolo ‘$’ en su séptima posición y en el que se asigna de la ‘a’ a la ‘z’ las opciones 0 a 25 de cada parámetro, ampliándose en esta VERSION con los rangos ‘A’ a ‘Z’ y ‘0’ a ‘9’ para que el número de opciones por parámetro en este modelo de codificación pase a 62 (de 0 a 61).
Para que los programas puedan determinar si una base de datos responde a uno u otro modelo, se ha definido la función BdcCodificacion(), que se especifica más adelante y que indica si el sistema de codificación usado en la base de datos es dependiente o independiente.
Si se adopta el primer modelo, no es posible averiguar ‘a priori’, a partir de un CODIGO ‘ABCDEFGHIJ’ de concepto, si éste es un derivado paramétrico ni de que concepto paramétrico procede o con qué valores de sus parámetros. Por ello, es establece el siguiente criterio de búsqueda:
Si el concepto existe con este CODIGO en la base, se escogerá dicho concepto.
En caso de no existir, se intentará localizarlo en la base de datos como perteneciente a un concepto paramétrico ‘al estilo’ FIEBDC-3/95. En el ejemplo, se intentará buscar el concepto paramétrico ‘ABCDEF$’ y pasarle los parámetros ‘GHIJ’ (que implica pasarle a sus cuatro parámetros valores ‘31’, ‘32’, ‘33’ y ‘34’ respectivamente).
En caso de no existir, se intentará localizarlo en la DLL. Si ésta posee un modelo de codificación dependiente, se utilizará el mismo criterio que en el punto anterior: en el ejemplo, buscar el concepto paramétrico ‘ABCDEF$’ y pasarle los parámetros ‘GHIJ’. Si la base posee un modelo independiente, se utilizará la función ‘BdcDecodifica()’, tal como se especifica más adelante.
Si no se cumplen ninguna de las condiciones anteriores, se supone que el concepto no existe en la base.
Vea en el archivo ‘fiebdc.h’ adjuntado la definición del API.
ESPECIFICACION DE LAS FUNCIONES DEL API.
LONG EXPORTA BdcCodificacion (
Indica si la base de datos utiliza un modelo de codificación dependiente o independiente del número y valor de los parámetros.
Devolverá ‘0’ si la codificación sigue un modelo dependiente (al ‘estilo’ FIEBDC-3/95), y ‘1’ si sigue un modelo independiente.
LONG EXPORTA BdcTipoPliego (
Indica qué tipo o tipos de Pliegos de Condiciones están implementados en la base. Dichos modelos se especifican en el apartado ‘REGISTROS TIPO PLIEGOS’ de las especificaciones del formato.
Devolverá ‘0’ si no está implementado ningún tipo de pliego.
Devolverá ‘1’ si está implementado el modelo uno de textos de pliegos. Es este caso, se utilizará la función BdcPliego() para obtener los textos de los pliegos.
Devolverá ‘2’ si está implementado el modelo dos de textos de pliegos. En este caso, se utilizarán las funciones BdcCodigoParrafo() y BdcTextoParrafo() para obtener los textos de los pliegos.
Devolverá ‘3’ si están implementados tanto el modelo uno como el modelo dos.
LPCSTR EXPORTA BdcFecha (
Obtener la fecha de la Base de Datos.
Devuelve la fecha de la Base de Datos en formato DDMMAAAA, donde DD representa al día con dos dígitos, MM el mes y AAAA el año.
La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACIÓN sobre el error producido, llame a la función BdcError().
FUNCIONES REFERENTES AL PARAMÉTRICO GLOBAL.
2.1. Accesibles en cualquier momento.
2.1.1. Obtención de sus parámetros.
LONG EXPORTA BdcGloParNumero (
Obtener el número de parámetros de concepto paramétrico global.
Devuelve el número de parámetros. En caso de error, la función devuelve -1. Para obtener más INFORMACION sobre el error producido, llame a la función BdcGloError().
LONG EXPORTA BdcGloOpcNumero (
LONG par // número de parámetro del concepto
Obtiene el número de opciones de que consta el parámetro ‘par’.
par: Número del parámetro. Debe ser un valor entre ‘0’ y ‘n-1’, siendo ‘n’ el número de parámetros del concepto paramétrico global.
Devuelve el número de opciones del parámetro ‘par’. En caso de producirse un error, devuelve –1. Para obtener más INFORMACION sobre el error producido, llame a la función BdcGloError().
LPCSTR EXPORTA BdcGloParRotulo (
Obtiene el rótulo que identifica el parámetro ‘par’ del concepto.
Devuelve el rótulo que identifica el parámetro ‘par’ del concepto, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcGloError().
LPCSTR EXPORTA BdcGloOpcRotulo (
LONG par, // número de parámetro del concepto
LONG opc // número de la opción del parámetro
Obtiene el rótulo que identifica la opción ‘opc’ del parámetro ‘par’ del concepto.
opc: Número del parámetro. Debe ser un valor entre ‘0’ y ‘n-1’, siendo ‘n’ el número de opciones que posee el parámetro ‘par’ del concepto paramétrico global.
Devuelve el rótulo que identifica la opción ‘opc’ del parámetro ‘par’ del concepto, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcGloError().
2.1.2. Mensajes / CODIGOs de error.
LONG EXPORTA BdcGloError (
LPCSTR *err // mensaje de error devuelto
Obtiene el tipo de error producido. Una vez leído, se inicializa el CODIGO de error.
err: Puntero a un puntero constante ‘far’ a una cadena de caracteres. En él se almacena el mensaje de error referente al error producido. La función es responsable de asignar memoria al puntero. Si no existe un mensaje definido para el error existente, ‘*err’ apuntará a la cadena vacía “”.
Devuelve el CODIGO de error producido. Vea al final el apartado ‘CODIGOs de los mensajes de error’ para más INFORMACION.
2.1.3. Asignación de opciones a los parámetros.
BOOL EXPORTA BdcGloCalcula (
LPLONG opcl, // lista de opciones de los parámetros
Asigna los valores de los parámetros del concepto paramétrico global..
opcl: Puntero a un vector (array) de LONGs con las opciones que se desea fijar a cada parámetro. Las opciones se numeran empezando por cero.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcGloError().
3. FUNCIONES REFERENTES AL RESTO DE PARAMÉTRICOS.
3.1. Accesibles en cualquier momento.
3.1.1. Lectura de un concepto paramétrico.
HANDLE EXPORTA BdcLee (
LPCSTR cod // CODIGO del concepto
Lee el concepto paramétrico identificado por ‘cod’.
cod: Puntero constante ‘far’ a una cadena de caracteres con el CODIGO del concepto paramétrico a leer. Si se utiliza un modelo de codificación dependiente, se asume que dicho CODIGO tenga 7 caracteres y que el séptimo sea ‘$’. Dentro del CODIGO, los caracteres pueden ser cualesquiera salvo el 0x00 (que indica el final del CODIGO).
Si la función encuentra el paramétrico, retorna un HANDLE distinto de cero. En caso de error, o si no existe el paramétrico, la función devuelve cero.
3.1.2. Lectura de un concepto paramétrico a partir del CODIGO completo del derivado.
HANDLE EXPORTA BdcDecodifica (
LPCSTR cod, // CODIGO completo del derivado paramétrico
LPLONG opcl // puntero al espacio de memoria a rellenar con las opciones
Lee el concepto paramétrico al que pertenece el concepto de CODIGO ‘cod’. El HANDLE y las opciones ‘opcl’ devueltas se pueden utilizar directamente en una llamada a BdcCalcula().
cod: Puntero constante ‘far’ a una cadena de caracteres con el CODIGO del concepto del que se desea obtener el concepto paramétrico a la que pertenece. Dentro del CODIGO, los caracteres pueden ser cualesquiera salvo el 0x00 (que indica el final del CODIGO).
opcl: Puntero a un vector (array) de LONGs en el que la función devolverá las opciones a las que corresponda el derivado paramétrico. El array debe estar previamente dimensionado con al menos el número de parámetros del concepto. Las opciones se numeran empezando por cero.
Si la función encuentra el paramétrico, retorna un HANDLE distinto de cero. En caso de error, o si no existe ningún concepto paramétrico del que el concepto ‘cod’ es derivado, la función devuelve cero.
LPCSTR EXPORTA BdcFamilia (
LPCSTR cod) // CODIGO completo del derivado paramétrico
Lee el código del concepto paramétrico al que pertenece el concepto de CODIGO ‘cod’.
cod: Puntero constante ‘far’ a una cadena de caracteres con el CODIGO del concepto del que se desea obtener el concepto paramétrico al que pertenece. Dentro del CODIGO, los caracteres pueden ser cualesquiera salvo el 0x00 (que indica el final del CODIGO).
Si la función encuentra el paramétrico, retorna su código como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero.. En caso de error, o si no existe ningún concepto paramétrico del que el concepto ‘cod’ es derivado, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
3.1.3. Búsqueda de conceptos a partir de un texto o un código.
BOOL EXPORTA BdcUsos (
LPCSTR texto, // código o texto a buscar
LONG donde // lugar donde tengo que buscar el texto o código
LPCSTR *lcodigo // lista de códigos donde se está utilizando el texto/código
Obtiene una lista de códigos dónde se utiliza un texto o un código de un concepto.
Texto: Indica el texto o código que se quiere buscar.
Donde: Parámetro que le indica a la función si el texto es un código o bien un texto (que puede ser una cadena). Los valores posibles son 1: cuando el parámetro es un código, 2: cuando el parámetro es un texto.
lcodigo: Texto en formato texto plano que contiene la lista de códigos donde se utiliza el texto o código separados por el separador de campos ASCII 124.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, la función devuelve ‘-1’. Para obtener más INFORMACIÓN sobre el error producido, llame a la función BdcError().
Si el parámetro ‘donde’ es 1 el texto corresponde a un código del banco y la función devolverá la lista de conceptos donde aparece el código en la justificación directamente o bien en alguno de sus componentes. Si el parámetro ‘donde’ es 2 el primer parámetro corresponde a un texto y la función devolverá la lista de los conceptos que contienen el texto en la definición (resumen y completa).
3.1.4. Mensajes / CODIGOs de error.
LONG EXPORTA BdcError (
HANDLE h, // identificador del concepto
Obtiene tipo de error producido.
h: Identificador (HANDLE) del concepto, que debe ser obtenido en una llamada anterior a la función BdcLee().
3.2. Accesibles después de BdcLee.
3.2.1. Obtención de sus parámetros.
LONG EXPORTA BdcParNumero (
HANDLE h // identificador del concepto
Obtiene el número de parámetros de concepto paramétrico.
h: Identificador (HANDLE) del concepto paramétrico, que debe ser obtenido en una llamada anterior a la función BdcLee().
Devuelve el número de parámetros. En caso de error, la función devuelve -1. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LONG EXPORTA BdcOpcNumero (
par: Número del parámetro. Debe ser un valor entre ‘0’ y ‘n-1’, siendo ‘n’ el número de parámetros del concepto.
Devuelve el número de opciones del parámetro ‘par’. En caso de producirse un error, la función devuelve -1. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcParRotulo (
Devuelve el rótulo que identifica el parámetro ‘par’ del concepto, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcOpcRotulo (
Obtiene rótulo que identifica la opción ‘opc’ del parámetro ‘par’ del concepto.
opc: Número del parámetro. Debe ser un valor entre ‘0’ y ‘n-1’, siendo ‘n’ el número de opciones que posee el parámetro ‘par’ del concepto.
Devuelve el rótulo que identifica la opción ‘opc’ del parámetro ‘par’ del concepto, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError(). En caso de referirse a ámbitos territoriales y a divisas, véanse los anexos 5 y 6.
3.2.2. Obtención de un comentario.
LPCSTR EXPORTA BdcComentario (
Obtiene un texto de comentario del concepto paramétrico.
Devuelve el comentario del concepto, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
3.2.3. Asignación de opciones de los parámetros y validación o cálculo del derivado.
BOOL EXPORTA BdcValida (
Averigua si una determinada combinación paramétrica es correcta o no.
Devuelve ‘0’ si la combinación es correcta. En caso contrario, devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
BOOL EXPORTA BdcCalcula (
Calcula los datos correspondientes a un derivado paramétrico.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, o de que la combinación no sea correcta, devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LONG EXPORTA BdcValidos (
LPBYTE *opcl, // lista de opciones de los parámetros de todos los derivados válidos
Obtiene las opciones de cada parámetro de todos los derivados paramétricos válidos de la familia paramétrica. Si no se desea implementar esta función en una determinada familia, la función deberá devolver ‘0’. Está pensada para aquellas familias que posean un número elevado de combinaciones posibles, en las que el averiguar cuáles de ellas son válidas mediante sucesivas llamadas a las funciones BdcCalcula() o BdcValida() es muy costoso en tiempo. En una sola llamada a esta función es posible, en estos casos, obtener todas las combinaciones válidas.
opcl: Puntero a una matriz (array) bidimensional de BYTEs a rellenar por la función, en el que cada columna corresponde a un derivado paramétrico válido, y cada fila corresponde a los valores de cada uno de los parámetros. La matriz se devuelve al estilo de ‘C’; es decir, por columnas. Las opciones se numeran empezando por cero. La propia función es responsable de asignar memoria al puntero. La memoria asignada en bytes será el número de combinaciones válidas multiplicado por el número de parámetros.
Devuelve el número de derivados paramétricos válidos. En caso de que dicha información no esté disponible, devuelve ‘0’. En caso de error, devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
Las combinaciones válidas a devolver se ordenarán teniendo en cuesta que el primer parámetro tiene más precedencia que el segundo, éste que el tercero, y así sucesivamente.
Si una familia paramétrica tiene 3 parámetros, con 9, 10 y 11 opciones por parámetro respectivamente, el número total de combinaciones posibles es 9x10x11 = 990. Si son válidas sólo las siguientes cuatro (escritos en el orden especificado en el párrafo anterior):
1. Valores ‘0’, ‘5’, y ‘9’ de los parámetros uno al tres, respectivamente.
2. Valores ‘7’, ‘6’ y ‘5’ de los parámetros uno al tres, respectivamente.
3. Valores ‘8’, ‘2’ y ‘4’ de los parámetros uno al tres, respectivamente.
4. Valores ‘8’, ‘2’ y ‘10’ de los parámetros uno al tres, respectivamente.
Entonces la función devolverá los 4×3=12 bytes siguientes: 0, 5, 9, 7, 6, 5, 8, 2, 4, 8, 2 y 10.
3.2.4. Liberación de memoria.
LONG EXPORTA BdcInValidos (
LPBYTE *opcl, // lista de opciones de los parámetros de todos los derivados inválidos
Con el mismo propósito y parámetros que BdcValidos.
Esta función se implementará en lugar de aquella cuando no exista BdcValidos para un concepto paramétrico y viceversa.
BOOL EXPORTA BdcCierra (
Cierra el concepto paramétrico y libera la memoria asignada.
Devuelve ‘0’ si realiza la operación correctamente. En caso de error, la función devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
3.3. Accesibles después de BdcCalcula.
3.3.1. Obtención del derivado paramétrico.
LONG EXPORTA BdcDesNumero (
Obtiene el número de conceptos en los que se descompone el derivado paramétrico.
Devuelve el número de elementos de su descomposición. Un valor de cero indicará que el concepto no tiene descomposición. Es posible que un mismo concepto paramétrico posea derivados simples y compuestos. En caso de error, la función devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcDesCodigo (
LONG des // número del elemento de la descomposición
Obtiene el CODIGO del elemento número ‘des’ en el que se descompone el derivado paramétrico.
des: Número del elemento de la descomposición del concepto. Los elementos se numeran empezando por cero.
Devuelve el CODIGO del elemento número ‘des’ en el que se descompone el derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
BOOL EXPORTA BdcFactor (
LONG des, // número del elemento de la descomposición
double FAR *factor // factor a obtener
Obtiene el factor de rendimiento del elemento número ‘des’ en el que se descompone el derivado paramétrico.
*factor: Puntero en el que devolver el factor deseado, por defecto 1. El factor puede ser positivo, cero o negativo.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, el factor se asigna a cero y la función devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
BOOL EXPORTA BdcRendimiento (
double FAR *ren // rendimiento a obtener
Obtiene el rendimiento del elemento número ‘des’ en el que se descompone el derivado paramétrico.
*ren: Puntero en el que devolver el rendimiento deseado. El rendimiento puede ser positivo, cero o negativo.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, el rendimiento se asigna a cero y la función devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcDesCodigoPorcentaje (
Obtiene los CODIGO_PORCENTAJE aplicable al elemento número ‘des’ en el que se descompone el derivado paramétrico.
Devuelve los CODIGO_PORCENTAJE aplicables al elemento número ‘des’ en el que se descompone el derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Los CODIGO_PORCENTAJE van separados el carácter < ; > (ASCII-59) y puede ser que se devuelva la cadena vacía si no se aplica ningún porcentaje sobre la línea. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
BOOL EXPORTA BdcPrecio (
double FAR *pre // precio unitario a devolver
Obtiene el precio unitario en el caso de que el derivado paramétrico sea un simple. Es posible que un mismo concepto paramétrico tenga como derivados tanto simples como compuestos.
*pre: Puntero en el que devolver el precio unitario. Dicho precio puede ser positivo, cero o negativo.
Devuelve ‘0’ si se ejecuta correctamente. En caso de error, el precio se asigna a cero y la función devuelve ‘-1’. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcCodigo (
Obtiene el CODIGO del concepto.
Devuelve el CODIGO del concepto, como puntero constante ‘far’ a una cadena de caracteres. Si se ha calculado un derivado paramétrico (se ha llamado a BdcCalcula), este CODIGO será el del derivado paramétrico. En caso contrario, será el CODIGO del concepto paramétrico. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
Obtiene la unidad de medida del derivado paramétrico. Esta función permite que un concepto paramétrico pueda generar elementos derivados con distintas unidades de medición. Para que dicha función actúe, el registro ~C debe contener el carácter especial ‘*’ dentro del campo unidad de medida. Dicho carácter indica que la unidad de medida de los conceptos derivados los debe proporcionar el API. Si el redactor de la BD desea que la unidad de medida sea un valor a escoger por parte del usuario, deberá además añadirse la unidad de medida como una propiedad más del concepto paramétrico.
Devuelve el texto correspondiente a la unidad de medida del derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Si no existe definido un texto resumido, la función devuelve la cadena vacía “”. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcResumen (
Obtiene el texto resumido del derivado paramétrico.
Devuelve el texto resumido del derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Si no existe definido un texto resumido, la función devuelve la cadena vacía “”. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcTexto (
Obtiene el texto completo de descripción del derivado paramétrico.
Devuelve el texto completo de descripción del derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Si no existe definido un texto completo de descripción, la función devuelve la cadena vacía “”. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
VOID EXPORTA BdcTipoDescripcion (
LONG tipo // tipo de descripción
Indica qué tipo de descripción se va a obtener de un concepto derivado.
Tipo: Se refiere a las diferentes descripciones (obtenidas con BdcResumen y BdcTexto) que puede tener un concepto derivado en función de los diferentes contenidos de que trate la base de datos.
Valor ‘0’: Descripción por defecto de un derivado paramétrico.
Valor ‘1’: Descripción de un derivado paramétrico que contiene insertados uno o varios códigos de conceptos que intervienen en su descomposición. Dichos códigos aparecen indicados entre dólares ($). Esta opción sirve para que los programas puedan particularizar la descripción de un concepto derivado cuando se han proporcionado productos comerciales asociados a sus componentes (con BdcComercNumero y BdcComercCodigo, o con el registro ~O).
Ejemplo: BdcTexto del concepto derivado E612235K.
Devolución de BdcTexto con valor 0 para BdcTipoDescripcion: Inodoro con tapa.
Devolución de BdcTexto con valor 1 para BdcTipoDescripcion: Inodoro $B1234567$ con tapa $B7654321$.
LPCSTR EXPORTA BdcPliego (
LONG formato, // identificador del formato
LONG tipo, // especifica si el pliego a obtener es de la familia o del derivado
LPCSTR seccion, // código de la sección del pliego
LPCSTR ambito // abreviatura del ámbito
Obtiene el texto del pliego, según el modelo uno.
formato: Identificador del formato de texto. Se definen, por el momento, los siguientes formatos: ‘BDCFMT_ASCII’ (si se desea obtener el pliego en formato ASCII), ’BDCFMT_ANSI’ (si se desea obtener el pliego en formato ANSI), ‘BDCFMT_RTF’ (si se desea obtener el pliego en formato RTF) y ‘BDCFMT_HTM’ (si se desea obtener el pliego en formato HTM).
tipo: Especifica si se desea obtener el pliego común de la familia paramétrica (valor ‘BDCPLI_FAMILIA’) o el del derivado (valor ‘BDCPLI_DERIVADO’). En el primer caso, no es necesario haber realizado previamente una llamada a BdcCalcula().
seccion: Puede tomar como valor el código de la sección del pliego cuyo texto se desea obtener, en cuyo caso deberá ser una de las secciones especificadas en el registro ~L, según se indica en el apartado ‘REGISTROS TIPO PLIEGOS’ de la especificaciones del formato. Si no existen secciones definidas, el valor de este parámetro no es utilizado. Si por el contrario toma el valor NULL, la función devolverá los códigos de las secciones del pliego para los que el concepto posea texto del pliego, separados por el separador de de subcampos (‘\’).
ambito: Ámbito del cual se desea obtener el texto del pliego. Corresponde a uno de los campos ‘ABREV_AMBITO’ especificados en el registro ~W, según se indica en el apartado ‘REGISTRO TIPO ÁMBITO GEOGRÁFICO’ de las especificaciones del formato. Si no existen ámbitos definidos (no existe un registro ~W), el valor de este parámetro es ignorado. En ese caso, es posible que el ámbito sea un parámetro global de la base.
Si el parámetro sección contiene el código de la sección del pliego cuyo texto se desea obtener, la función devuelve el texto del pliego del derivado paramétrico en el formato solicitado, como puntero constante ‘far’ a una cadena de caracteres. Si no existe definido un texto de pliego, la función devuelve la cadena vacía “”.
Cuando el parámetro sección es NULL, la función devuelve los rótulos de los pliegos existentes asociados al concepto parámetrico en el formato {rotulo\}, si no hubiera rotulos asociados al concepto la función devuelve “”.
La propia función es responsable de asignar memoria al puntero. En caso de error (por ejemplo formato no soportado por la BDC), la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcCodParrafo (
Obtiene los códigos de los párrafos de pliego, según el modelo dos.
seccion: Código de la sección del pliego cuyos códigos de párrafo se desea obtener. Deberá ser una de las secciones especificadas en el registro ~L, según se indica en el apartado ‘REGISTROS TIPO PLIEGOS’ de la especificaciones del formato. Si no existen secciones definidas, el valor de este parámetro no es utilizado.
ambito: Ámbito del cual se desea obtener los códigos de párrafo. Corresponde a uno de los campos ‘ABREV_AMBITO’ especificados en el registro ~W, según se indica en el apartado ‘REGISTRO TIPO ÁMBITO GEOGRÁFICO’ de las especificaciones del formato. Si no existen ámbitos definidos (no existe un registro ~W), el valor de este parámetro es ignorado. En ese caso, es posible que el ámbito sea un parámetro global de la base.
Devuelve un texto con los códigos de párrafo del pliego del derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Si no existe definido ningún código de párrafo, la función devuelve la cadena vacía “”. En caso de error (por ejemplo ámbito no soportado por la BDC), la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError(). Los códigos irán separados con el separador de subcampos habitual, es decir, el texto devuelto tendrá la sintaxis
{ CODIGO_PARRAFO \ }
LPCSTR EXPORTA BdcTexParrafo (
LONG formato // identificador del formato
LPCSTR cod_parrafo // código del párrafo del pliego
Obtiene el texto del pliego del derivado paramétrico correspondiente al código de párrafo ‘cod_parrafo’, según el modelo dos. El código de párrafo se obtiene mediante una llamada a la función BdcCodParrafo.
formato: Identificador del formato de texto. Se definen, por el momento, los siguientes formatos: ‘BDCFMT_ASCII’ (si se desea obtener el pliego en formato ASCII), ‘BDCFMT_RTF’ (si se desea obtener el pliego en formato RTF) y ‘BDCFMT_HTM’ (si se desea obtener el pliego en formato HTM).
cod_parrafo Código del párrafo del pliego cuyo texto se desea obtener.
Devuelve el texto del párrafo en el formato solicitado, como puntero constante ‘far’ a una cadena de caracteres. La propia función es responsable de asignar memoria al puntero. Esta memoria se liberará en la siguiente llamada a esta función dentro del mismo proceso. Si no existe definido un texto de pliego con este código de párrafo, la función devuelve la cadena vacía “”. En caso de error (por ejemplo formato no soportado por la BDC), la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcClaves (
Obtiene las claves de tesauro del derivado paramétrico.
Devuelve las claves de tesauro del derivado paramétrico, como puntero constante ‘far’ a una cadena de caracteres, con el mismo formato que el registro ‘~A’, es decir, ‘{CLAVE_TESAURO\}’. La propia función es responsable de asignar memoria al puntero. Si no existen definidas claves del tesauro, la función devuelve la cadena vacía “”. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LPCSTR EXPORTA BdcTipo (
Obtener el tipo del concepto.
Devuelve el tipo del concepto, como puntero constante ‘far’ a una cadena de caracteres. Si se ha calculado un derivado paramétrico (se ha llamado a la función BdcCalcula) este tipo será el del derivado paramétrico. En caso contrario, será el tipo del concepto paramétrico. La propia función es responsable de asignar memoria al puntero. En caso de error, la función devuelve NULL. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError(). Corresponde al campo TIPO del registro ~C.
LONG EXPORTA BdcComercNumero(
LPCSTR codigo_raiz_BD // identificador de la entidad que elabora la BD
Obtener el número de conceptos vinculados a un concepto que pertenece a codigo_raiz_BD y empleado por ésta en su sistema de clasificación por codificación.
h: Identificador (HANDLE) del concepto paramétrico.
Devuelve el número de conceptos vinculados. Si se ha calculado un derivado paramétrico (se ha llamado a la función BdcCalcula) este número será el del derivado paramétrico. En caso contrario, será el número del concepto paramétrico. Un valor de cero significa que no tiene conceptos vinculados. En caso de error la función devuelve ‘-1’ . Para obtener más INFORMACIÓN sobre el error producido, llame a la función BdcError().
BOOL EXPORTA BdcComercCodigo(
LONG comerc // número del concepto vinculado
LPLCSTR *Codigo_archivo // nombre de archivo a devolver
LPLCSTR *Codigo_Entidad // identificación del código de la entidad a la que se
// asocia la información a devolver
LPLCSTR *Codigo_Concepto // concepto que pertenece a Codigo_Entidad a devolver
Obtener el código de archivo que indica el lugar donde se encuentra la información referente a codigo_entidad#codigo_concepto, o bien el codigo_entidad y el codigo_concepto que se encuentra en la misma BD.
comerc: Número del concepto vinculado. Los conceptos vinculados se numeran empezando por cero.
codigo_archivo: Se refiere al nombre del archivo que, de existir, indica el lugar donde se encuentra la información referente a codigo_entidad#código_concepto. Si el valor es nulo los campos código entidad y código concepto deberán existir. La propia función es responsable de asignar memoria al puntero.
codigo_entidad: Se refiere a la identificación del CODIGO de la entidad a la que se le asocia INFORMACION. Este CODIGO debe ser facilitado por la entidad que elabora la BD, de acuerdo con su sistema de clasificación, para evitar ambigüedades. Se recomienda que éste sea el propio CIF de la entidad. La propia función es responsable de asignar memoria al puntero.
codigo_concepto: Se refiere a un concepto que pertenece a CODIGO_ENTIDAD, y empleado por la entidad que elabora la BD. Cuando CODIGO_CONCEPTO se refiera a un producto comercial, dicho CODIGO deberá ser facilitado por el fabricante, y no podrá coincidir nunca con la designación de CODIGO_RAIZ_BD, CODIGO_ENTIDAD o CODIGO_CONCEPTO, cuando éste se refiere a un concepto genérico. La propia función es responsable de asignar memoria al puntero.
Al tener dicho producto comercial un tratamiento de CONCEPTO, éste puede utilizar todos los registros existentes en el formato para especificar su INFORMACION asociada (precio, INFORMACION gráfica, etc.). Para poder utilizar los registros mencionados, el código identificador del concepto será CODIGO_ENTIDAD # CODIGO_CONCEPTO.
LONG EXPORTA BdcDocNumero (
Obtener el número de archivos asociados a un concepto.
h: Identificador (HANDLE) del concepto.
Devuelve el número de archivos asociados. Un valor de cero significa que no tiene archivos asociados. En caso de error la función devuelve ‘-1’ . Para obtener más INFORMACIÓN sobre el error producido, llame a la función BdcError()
BOOL EXPORTA BdcDocCodigo (
HANDLE h, // identificador del concepto.
LONG num, // número del archivo asociado.
LONG * tipo // clasificación del tipo de información del archivo.
LPCSTR * archivo, // nombre del archivo que contiene información del concepto.
LPCSTR * descripción // descripción de la información que contiene el archivo.
Obtener el archivo asociado a un concepto así como su clasificación temática y su descripción asociada. El comportamiento sería igual al discreto, primero se buscaría el archivo en el directorio local, y si no estuviera, en URL_BASE+archivo. URL_BASE se define en el registro ~V.
num: Número del archivo asociado al concepto. Se numeran empezando por cero.
tipo: Devuelve el código de uno de los tipos enumerados en el registro ~F.
archivo: Devuelve el nombre del archivo con extensión que contiene información del concepto. El archivo puede contener una URL_EXT. Las extensiones permitidas son las que se especifican en el registro ~F. En el caso que se devuelvan varios archivos, el primero de los archivos es el principal y el resto son vinculados. En este caso el formato del string sería el siguiente: “archivo 1 | … | archivo n | ”
descripción: Devuelve una breve descripción de la información contenida en el archivo. devuelve NULL si no hay ningún texto descriptivo asociado.
LONG EXPORTA BdcNumProp (
LONG uso // aplicación para la que se requiere el número de propiedades
// técnicas
Obtiene el número de propiedades técnicas que hay definidas para un concepto para el uso que se solicita. Inicialmente se define el uso 0 para el cálculo del coste energético, emisión de CO2 y/o residuos.
Uso: Número que indica qué cálculo se está definiendo.
Número de propiedades técnicas definidas para el concepto paramétrico para ese uso.
BOOL EXPORTA BdcPropValString (
LONG uso, // aplicación para la que se requiere el número de propiedades
LONG nprop, // número de propiedad
LPCSTR *propiedad, // puntero al nombre de la propiedad
LPCSTR *valor, // puntero al valor de la propiedad
LPCSTR *um // puntero a la unidad de medida de la propiedad
Obtiene el nombre de la propiedad técnica, su valor y la unidad de medida.
nprop: Número de propiedad. Se numeran empezando por cero.
propiedad: Puntero al CODIGO_IT de una de las propiedades enumeradas en el registro ~X.
valor: Puntero al valor de la propiedad que puede ser alfabético o numérico.
um: Puntero a la unidad de medida de la propiedad. En el caso que los valores de la propiedad sean valores numéricos se indicará de acuerdo con el Sistema Internacional de Unidades de Medida (ver anexo 7).
Devuelve ‘0’ si se ejecuta correctamente. Para obtener más INFORMACION sobre el error producido, llame a la función BdcError().
LONG EXPORTA BdcNumComponentes (
LONG tipo // tipo de descomposición
Obtiene el número de componentes de un concepto para cada tipo de descomposición.
tipo: Número del tipo de descomposición descrito en el campo TIPO_DESCOMPOSICION del registro ~R.
Devuelve el número de componentes de la relación tipo.
Si el valor devuelto = 0, el concepto no tiene componentes de este tipo.
Si el valor devuelto = -1, el concepto tiene la información incompleta.
BOOL EXPORTA BdcCodigoComponente (
LONG tipo, // tipo de descomposición
LONG ncomp, // número del componente de la descomposición tipo del
// concepto
LPCSTR *codigo // puntero al código del componente
Obtiene el código de los componentes de un elemento (número ‘ncomp’) para cada tipo de descomposición.
ncomp: Número del componente de la relación tipo del concepto. Se numeran empezando por cero.
Codigo: Puntero al código del componente.
LONG EXPORTA BdcNumPropComponente (
LONG ncomp // número del componente
Obtiene el número de propiedades del componente para cada tipo de descomposición.
Número de propiedades de la relación.
BOOL EXPORTA BdcComponentePropValString (
LONG ncomp, // número de componente
LONG nprop, // número de la propiedad
Obtiene el nombre de la propiedad ‘nprop’, el valor y la unidad de medida.
propiedad: Puntero al nombre de la propiedad de la relación.
4. MENSAJES DE ERROR.
Los CODIGOs de error se almacenan en un LONG (entero de 32 bits) de manera que cada error corresponde a un bit. De esta forma, es posible definir hasta 32 CODIGOs de error que pueden producirse de forma aislada o conjunta. Las llamadas a las funciones BdcGloError() y BdcError() eliminan los CODIGOs de error producidos anteriormente.
Por ejemplo, para saber si un determinado error se ha producido con el concepto ‘Concepto’, se debe utilizar la sintaxis:
const char *Mensaje;
LONG cod_err = BdcError ((HANDLE)Concepto, &Mensaje);
if (cod_err & BDCERR_BASE_DATOS) {
// Se ha producido el error ‘BDCERR_BASE_DATOS’
4.1. CODIGOs de los mensajes de error.
BDCERR_CORRECTO	No hay error.
BDCERR_BASE_DATOS	Existe un mensaje de error. Es el caso en el que la DEFINICION paramétrica se indica una combinación inválida y se devuelve un mensaje de error explicativo.
BDCERR_PARAMETRO	Se pasó a BdcCalcula o BdcGloCalcula un parámetro inexistente.
BDCERR_OPCION	Se pasó a BdcCalcula o BdcGloCalcula una opción inexistente.
BDCERR_MAX_OPCIONES	Se definieron más de 62 opciones en un determinado parámetro.
BDCERR_NO_LEIDO	Se intentó utilizar BdcCalcula() antes que BdcLee().
BDCERR_NO_CALCULADO	Se intentó acceder a datos de un derivado paramétrico antes de utilizar BdcCalcula().
BDCERR_DESCOMPOSICION	Se intentó acceder a un elemento de la descomposición inexistente.
BDCERR_SIN_CODIGO	No existe CODIGO definido.
BDCERR_SIN_MEMORIA	Memoria insuficiente.
BDCERR_CONCEPTO_NULO	Se pasó un HANDLE nulo.
BDCERR_FMT_NO_SOPORTADO	El formato de texto solicitado no está soportado por la BDC
BDCERR_NO_COMBINACION:	A la llamada BdcValida o BdcCalcula se le pasó una combinación inexistente.
BDCERR_NO_BANCO_PRECIOS:	No existe ningún Banco de Precios.
BDCERR_PARAMETRO_INCORRECTO “El programa pidió un parámetro incorrecto”
1. BASE DE DATOS EJEMPLO: BASE.DLL
En los archivos que acompañan a este documento (y que pueden encontrarse en la página web de la asociación, ‘http://www.fiebdc.es’), se suministran tanto los archivos que constituyen la base como los fuentes necesarios para construirla (compilarla).
El ejemplo construido posee las siguientes características (no todas las bases que se realicen conforme a este formato deben tener estas mismas características):
1.	Se ha utilizado un modelo de codificación independiente de los parámetros.
2.	Se ha utilizado el modelo uno de textos de pliegos.
3.	Existe un paramétrico global, si bien el valor de su único parámetro sólo es utilizado en el concepto ‘SBRG.1$’.
4.	Existe un concepto (‘Esp$’) que no responde a los criterios de FIEBDC-3/95: posee más de cuatro parámetros y el código de la familia sólo tiene 4 caracteres.
5.	Todos los conceptos paramétricos poseen un CODIGO terminado en ‘$’, si bien el formato no lo exige.
6.	Existe un concepto (‘SBRG.1$’) cuyos derivados poseen un código que no responde a los criterios de FIEBDC-3/95. Para la asignación de código se ha seguido la técnica de definir una tabla de sinónimos: así, el concepto que resulta de escoger el primer valor del único parámetro que posee, en lugar de poseer el código ‘SBRG.1a’ posee el código ‘SBRG.1_18’.
7.	Los textos de los pliegos sólo están definidos en formato ASCII y para los derivados paramétricos. No están divididos ni en secciones (facetas) ni en ámbitos.
1.1. Archivos para la distribución de la Base de Datos.
Para distribuir la base datos que se construyera con este ejemplo, se deberían proporcionar los siguientes archivos:
base.dll	DLL que contiene las descripciones paramétricas y el interfaz ESTANDAR con aplicaciones (API).
base.bc3	Archivo ASCII de la base de datos en formato FIEBDC-3/98. En el ejemplo, la base incluye en esta DLL el paramétrico global de la base, así como las descripciones paramétricas de los conceptos “ABPH.1$”, “SBRG.1$”, “EADR.3$” y “Esp$”, por lo que al menos debe contar con los siguientes registros:
~P| | | BASE.DLL |
~P| ABPH.1$ | |
~P| SBRG.1$ | |
~P| EADR.3$ | |
~P| Esp$ | |
1.2. Archivos necesarios para la CONSTRUCCION de la Base de Datos.
Este ejemplo está preparado para compilarse con Microsoft Visual C++ VERSION 2.2 o posterior como DLL de 32 bits. Sin apenas modificaciones, sería posible compilarlo como DLL de 16 bits o utilizar el compilador Borland C++.
Para construir la DLL, son necesarios los siguientes archivos:
fiebdc.h	Archivo que define el formato.
base.h	DEFINICION de variables y defines útiles para la definición de las descripciones paramétricas.
interfaz.cpp	Implementación de las funciones del API.
aplicat.cpp	Implementación de las funciones de la descripción paramétrica.
base.cpp	Implementación de las descripciones paramétricas de la base de datos en formato C++. Es la única parte que escribirían los redactores de las bases de datos. Se ha utilizado una sintaxis similar a la descripción paramétrica del formato FIEBDC-3/95, para facilitar así el intercambio entre ambos formatos.
base.def	DEFINICION de las funciones de exportación del API.
2. APLICACION EJEMPLO: PROGRAMA.EXE
En los archivos que acompañan a este documento (y que pueden encontrarse en la página web de la asociación, ‘http://www.fiebdc.es’), se suministran tanto el ejecutable (‘Programa.EXE’) como los fuentes necesarios para construirlo (compilarlo).
Esta sencilla aplicación, lee los conceptos que se incluyen en el propio fuente de la base BASE.DLL (en una aplicación real, los conceptos se definen en los registros ~P de base.bc3), y escribe en el archivo ‘SALIDA.TXT’ los rótulos de todos sus parámetros así como todos los datos de todas sus combinaciones paramétricas.
Los fuentes son fácilmente modificables para poder probar con el programa cualquier base de datos que utilice paramétricos compilados en DLL de acuerdo con el API establecido en este documento.
2.1. Archivos necesarios para la CONSTRUCCION del programa ejemplo.
Este ejemplo está preparado para compilarse con Microsoft Visual C++ VERSION 2.2 o posterior como aplicación Windows 95 de 32 bits en modo consola. Sin apenas modificaciones, sería posible compilarlo como aplicación de 16 bits o utilizar el compilador Borland C++.
Para construir la aplicación, son necesarios los siguientes archivos:
program.h	Declaración de variables y funciones.
program0.c	Funciones auxiliares de apertura y cierre de la base de datos y tratamiento de los mensajes de error.
program.c	Programa ejemplo.
Anexo 4. Clasificación en tipos de los Conceptos
1) Tipos 0, 1, 2, 3, 4 y 5.
Estos tipos corresponden a los vigentes en el formato FIEBDC-3/2016.
2) Tipos obtenidos de los índices y fórmulas polinómicas de revisión de precios del BOE según índices oficiales del RD 1359/2011.
Esta clasificación proviene del BOE (Boletín Oficial del Estado: www.boe.es), según índices oficiales del Real Decreto 1359/2011 de aplicación para contratos de obras públicas adjudicadas a partir de 1 de agosto de 2013 para obras para la administración pública, para fijar los índices de variación de precios mediante sus respectivas fórmulas polinómicas.
B Materiales bituminosos
C Cemento
E Energía
F Focos y luminarias
L Materiales cerámicos
O Plantas
P Productos plásticos
R Áridos y rocas
S Materiales siderúrgicos
T Materiales electrónicos
U Cobre
V Vidrio
X Materiales explosivos
A los anteriores se añaden los siguientes:
% Medios auxiliares
1 Se refiere al tipo 1 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”.
2 Se refiere al tipo 2 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”.
A, B, C, E, F, L, M, O, P, Q, R, S, T, U, V, X y 3, se refieren al tipo 3 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”. Dicha clasificación de materiales se corresponde con la de los índices de revisión de precios de las obras oficiales, a los que se añade el tipo M para aquellos materiales que no se puedan asociar a ninguno de los anteriores.
% Se refiere a un nuevo tipo que se corresponde con los medios auxiliares que pueden aparecer en una justificación de precios.
3) Tipos obtenidos de los índices y fórmulas polinómicas de revisión de precios del BOE según índices oficiales anteriores al RD 1359/2011 y de la de la CNC.
Esta clasificación proviene del BOE (Boletín Oficial del Estado: www.boe.es) según índices oficiales del Real Decreto 1359/2011 de aplicación para contratos de obras públicas adjudicadas hasta 31 de julio de 2013 para obras para la administración pública, y de la CNC (Confederación Nacional de la Construcción: www.cnc.es), que la utilizan para fijar los índices de variación de precios mediante sus respectivas fórmulas polinómicas.
H Mano de obra
MC Cemento
MCr Cerámicas
MM Maderas
MS Siderúrgicos
ME Energía
Mcu Cobre
Mal Aluminio
ML Ligantes
M Otros materiales
Q Maquinaria
H Se refiere al tipo 1 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”.
MC, MCr, MM, MS, ME, MCu, MAl, ML y M, se refieren al tipo 3 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”. Dicha clasificación de materiales se corresponde con la de los índices de revisión de precios de las obras oficiales, a los que se añade el tipo M para aquellos materiales que no se puedan asociar a ninguno de los anteriores.
Q Se refiere al tipo 2 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”.
4) Tipos obtenidos de la Asociación de Redactores de Bases de Datos de la Construcción.
Estos tipos sirven para desarrollar el tipo 0 de la clasificación “Tipos 0, 1, 2, 3, 4 y 5”.
EA Elemento auxiliar
EU Elemento unitario
EC Elemento complejo
EF Elemento funcional
OB Obra
PA Partida Alzada
PU Presupuesto Unitario
Elemento auxiliar: Elemento constructivo formado por una combinación de elementos básicos ( mano de obra, materiales y maquinaria ) que intervienen en la formación de una unidad de obra.
Ejemplos: Hormigón H-250 de consistencia plástica elaborado en obra; Acero AEH-400 S elaborado en obra; etc.
Elemento unitario: Elemento constructivo formado por un conjunto de elementos básicos y/o auxiliares que configuran una unidad de obra y que lo realiza un mismo grupo de especialistas.
Ejemplos: Tabique de ladrillos cerámicos huecos sencillos de 25x12x4 cm, tomados con mortero de cemento de dosificación 1:6; Hormigón H-250 en soportes; etc.
Elemento complejo: Elemento constructivo formado por un conjunto de elementos básicos, auxiliares y/o unitarios que constituye un conjunto constructivo y que lo realiza uno o varios grupos de especialistas.
Ejemplos: Hormigón H-250 armado con 120 kg de acero AEH-400 S y encofrado con placas metálicas, en soportes…; Cerramiento de fachada formado por dos hojas cerámicas con aislamiento en cámara de aire…; etc.
Elemento funcional: Elemento constructivo formado por un conjunto de elementos básicos, auxiliares, unitarios y/o complejos que constituye un conjunto constructivo con una función completa dentro de la obra.
Ejemplos: Estructura de hormigón armado; Cocina formada por…; etc.
Obra: Elemento constructivo formado por un conjunto de elementos funcionales, complejos, unitarios, auxiliares y/o simples que configuran la totalidad de elementos que constituyen una construcción.
Ejemplos: Rehabilitación de fachada…; Edificio de viviendas plurifamiliar…; etc.
Partida Alzada: Unidad de obra a justificar.
Ejemplo: Partida alzada a justificar del 1% del PEM, para gastos de acción cultural.
Presupuesto Unitario: Concepto que se refiere a un presupuesto parcial que se compone de unidades de obra. Se asimila a Elemento Funcional (EF) pero un comportamiento diferente en su aplicación. Su comportamiento es que puede aparecer como una unidad de obra en un presupuesto a la que se le asigna una medición; y en cambio se comporta como un subcapitulo de presupuesto en cuanto a que no se le han de aplicar costes indirectos (los costes indirectos, en su caso, ya los contemplan las unidades de obra de su composición) y no aparece en los cuadros de precios 1 y 2.
Anexo 5. Ámbitos Territoriales
Como abreviaturas de Ámbitos Territoriales correspondientes a provincias y CCAA del estado español, para su posible uso el campo ROTULO_IDENTIFICACION del registro ~V y/o el campo ABREV_AMBITO del registro ~W, se establecen las siguientes:
AND Comunidad Autónoma de Andalucía
CO Córdoba
CA Cádiz
MA Málaga
ARA Comunidad Autónoma de Aragón
AST Comunidad Autónoma del Principado de Asturias
BAL Comunidad Autónoma de las Islas Baleares
PM Baleares
CAN Comunidad Autónoma de Canarias
CBR Comunidad Autónoma de Cantabria
CLM Comunidad Autónoma de Castilla-La Mancha
CAL Comunidad Autónoma de Castilla y León
AV Ávila
LE León
CAT Comunidad Autónoma de Cataluña
EXT Comunidad Autónoma de Extremadura
CC Cáceres
GAL Comunidad Autónoma de Galicia
OR Ourense
MAD Comunidad de Madrid
MUR Comunidad Autónoma de la Región de Murcia
NAV Comunidad Foral de Navarra
PVA Comunidad Autónoma del País Vasco
VI Álava
BI Bizkaia
SS Guipuzkoa
RIO Comunidad Autónoma de La Rioja
VAL Comunidad Valenciana
CS Castellón
Anexo 6. Divisas
Como abreviaturas de las Divisas (campo DIVISA del registro ~K), se establecen las especificadas por el BCE (Banco Central Europeo, www.ecb.int), que son las siguientes:
Unidad Monetaria Unión Monetaria Europea
ATS Chelin Austriaco
DEM Marco Alemán
ESP Peseta Española
FIM Marco Finlandés
GRD Dracma Griega
IEP Libra Irlandesa
ITL Lira Italiana
LUF Franco Luxemburgués
NLG Florín Neerlandés
PTE Escudo Portugués
Moneda no UME Resto
EEK Corona Estona
ROL Leu Rumano
SIT Tolar Esloveno
SKK Corona Eslovaca
TRL Lira Turca
Anexo 7. Unidades de Medida
“El Sistema Legal de Unidades de Medida obligatorio en España es el sistema métrico decimal de siete unidades básicas, denominado Sistema Internacional de Unidades (SI), adoptado por la Confederación General de Pesas y Medidas y vigente en la Comunidad Económica Europea”. RD 2032/2009, de 30 de diciembre, por el que se establecen las unidades legales de medida.
Según este real decreto se acuerda adoptar la nomenclatura de las unidades siguientes:
cm3 Centímetro cúbico
Por similitud con dicho real decreto, y provenientes de la Asociación de Redactores de Bases de Datos de la Construcción, también se acuerda adoptar las siguientes:
mu Mil unidades
cu Cien unidades
Anexo 8. Definición de diferentes tipos de Presupuestos.
Se denomina PRESUPUESTO al sumatorio de las cantidades obtenidas en la medición de las unidades de obra por sus respectivos precios organizados según una estructura (ejemplo: raíz, capítulos, subcapítulos y partidas).
PRESUPUESTO DE EJECUCION MATERIAL (PEM).
Artículo 131 del Reglamento General de la Ley de Contratos de las Administraciones Públicas:
“Se denominará presupuesto de ejecución material el resultado obtenido por la suma de los productos del número de cada unidad de obra por su precio unitario y de las partidas alzadas.”
Artículo 130. Cálculo de los precios de las distintas unidades de obra:
“1. El cálculo de los precios de las distintas unidades de obra se basará en la determinación de los costes directos e indirectos precisos para su ejecución, sin incorporar, en ningún caso, el importe del Impuesto sobre el Valor Añadido que pueda gravar las entregas de bienes o prestaciones de servicios realizados.
2. Se considerarán costes directos:
a) La mano de obra que interviene directamente en la ejecución de la unidad de obra.
b) Los materiales, a los precios resultantes a pie de obra, que quedan integrados en la unidad de que se trate o que sean necesarios para su ejecución.
c) Los gastos de personal, combustible, energía, etc. que tengan lugar por el accionamiento o funcionamiento de la maquinaria e instalaciones utilizadas en la ejecución de la unidad de obra.
d) Los gastos de amortización y conservación de la maquinaria e instalaciones anteriormente citadas.
3. Se considerarán costes indirectos:
Los gastos de instalación de oficinas a pie de obra, comunicaciones, edificación de almacenes, talleres, pabellones temporales para obreros, laboratorio, etc., los del personal técnico y administrativo adscrito exclusivamente a la obra y los imprevistos. Todos estos gastos, excepto aquéllos que se reflejen en el presupuesto valorados en unidades de obra o en partidas alzadas, se cifrarán en un porcentaje de los costes directos, igual para todas las unidades de obra, que adoptará, en cada caso, el autor del proyecto a la vista de la naturaleza de la obra proyectada, de la importancia de su presupuesto y de su previsible plazo de ejecución.
4. En aquellos casos en que oscilaciones de los precios imprevistas y ulteriores a la aprobación de los proyectos resten actualidad a los cálculos de precios que figuran en sus presupuestos podrán los órganos de contratación, si la obra merece el calificativo de urgente, proceder a su actualización aplicando un porcentaje lineal de aumento, al objeto de ajustar los expresados precios a los vigentes en el mercado al tiempo de la licitación.
5. Los órganos de contratación dictarán las instrucciones complementarias de aplicación al cálculo de los precios unitarios en los distintos proyectos elaborados por sus servicios.”
Artículo 154. Partidas alzadas:
“1. Las partidas alzadas se valorarán conforme se indique en el pliego de prescripciones técnicas particulares. En su defecto se considerarán:
a) Como partidas alzadas a justificar, las susceptibles de ser medidas en todas sus partes en unidades de obra, con precios unitarios, y
b) Como partidas alzadas de abono íntegro, aquéllas que se refieren a trabajos cuya especificación figure en los documentos contractuales del proyecto y no sean susceptibles de medición según el pliego.
2. Las partidas alzadas a justificar se valorarán a los precios de la adjudicación con arreglo a las condiciones del contrato y al resultado de las mediciones correspondientes. Cuando los precios de una o varias unidades de obra no figuren incluidos en los cuadros de precios, se procederá conforme a lo dispuesto en el artículo 146.2 de la Ley, en cuyo caso, para la introducción de los nuevos precios así determinados habrán de cumplirse conjuntamente las dos condiciones siguientes:
a) Que el órgano de contratación haya aprobado, además de los nuevos precios, la justificación y descomposición del presupuesto de la partida alzada, y
b) Que el importe total de dicha partida alzada, teniendo en cuenta en su valoración tanto los precios incluidos en los cuadros de precios como los nuevos precios de aplicación, no exceda del importe de la misma figurado en el proyecto.
3. Las partidas alzadas de abono íntegro se abonarán al contratista en su totalidad, una vez determinados los trabajos u obras a que se refieran, de acuerdo con las condiciones del contrato y sin perjuicio de lo que el pliego de cláusulas administrativas particulares pueda establecer respecto de su abono fraccionado en casos justificados.
Cuando la especificación de los trabajos u obras constitutivos de una partida alzada de abono íntegro no figure en los documentos contractuales del proyecto o figure de modo incompleto, impreciso o insuficiente a los fines de su ejecución, se estará a las instrucciones que a tales efectos dicte por escrito la dirección, a las que podrá oponerse el contratista en caso de disconformidad.”
(anteriormente denominado Presupuesto de ejecución por contrata PEC).
“El presupuesto base de licitación se obtendrá incrementando el de ejecución material en los siguientes conceptos:
1. Gastos generales de estructura que inciden sobre el contrato, cifrados en los siguientes porcentajes aplicados sobre el presupuesto de ejecución material:
a) Del 13 al 17 por 100, a fijar por cada Departamento ministerial, a la vista de las circunstancias concurrentes, en concepto de gastos generales de la empresa, gastos financieros, cargas fiscales, Impuesto sobre el Valor Añadido excluido, tasas de la Administración legalmente establecidas, que inciden sobre el costo de las obras y demás derivados de las obligaciones del contrato. Se excluirán asimismo los impuestos que graven la renta de las personas físicas o jurídicas.
b) El 6 por 100 en concepto de beneficio industrial del contratista.
Estos porcentajes podrán ser modificados con carácter general por acuerdo de la Comisión Delegada del Gobierno para Asuntos Económicos cuando por variación de los supuestos actuales se considere necesario.
2. El Impuesto sobre el Valor Añadido que grave la ejecución de la obra, cuyo tipo se aplicará sobre la suma del presupuesto de ejecución material y los gastos generales de estructura reseñados en el apartado 1.”
El Impuesto sobre el Valor Añadido puede variar dependiendo de la zona geográfica, en cuyo caso se aplicará el que corresponda, por ejemplo, Impuesto General Indirecto Canario (IGIC).
En obras privadas los porcentajes de gastos generales de la empresa y beneficio industrial del contratista pueden ser distintos de los especificados anteriormente.
PRESUPUESTO DE LICITACION (PL).
Importe que sirve de base para formular las ofertas económicas de las empresas que concurren a una licitación de obra.
PRESUPUESTO DE ADJUDICACION (PAD).
Se denominará así al importe correspondiente a la proposición económica de la empresa que resulta adjudicataria de la obra. Puede ser coincidente con el Presupuesto de Licitación, inferior a éste si se produce baja, o superior a éste si se produce alza.
Se recomienda que el alza o la baja se apliquen sobre el Presupuesto de Ejecución Material, puesto que la cantidad resultante será la misma y sin embargo no se reflejarán modificaciones en la imputación del IVA.

References: Real Decreto 
 Real Decreto 
 Real Decreto 
 Real Decreto 
 real decreto 

Artículo 131

Artículo 130

Artículo 154
 artículo 146