Un principiante en las Artes Gráficas

Continuando con el curso, entro en detalle del modelado de sistemas de información utilizando UML. Os dejo la presentación en OpenOffice y PDF, bastante autoexplicativas.

• UML.odt
• UML.pdf

Es normal que se desconozca el sistema de impresión de libros. Un libro de un tamaño estandar (17×24 cms, o 15×21 cms…) por ejemplo no se imprime en su tamaño final, sino que en las máquinas de impresión offset se utilizan pliegos mucho más grandes (50×70 cms, 70×100 cms e incluso muchísimo mayores).

En ese pliego grande se imprimen varias páginas del libro… ¿y cómo se organizan para que después, el libro al ser encuadernado mantena la organización en la numeración de páginas? Se realiza mediante la imposición. La imposición es el nombre que recibe la configuración u organización en la que se colocan las páginas en la hoja de impresión de mayor tamaño.

Partamos desde el principio: Una hoja de un libro son dos páginas evidentemente, pero no es posible incluir una sola hoja en un libro si no es pegándola físicamente en un lugar cerca del lomo del libro.

¿Cómo se salva esto? Los trabajos de libros con varias páginas deben calcularse siempre para que generen un número de páginas múltiplos de 4, 8 o 16 páginas. ¿Porqué estos números? Porque son el número de páginas 17×24 que por ejemplo entran en un pliego 50×70. De hecho en un pliego de 50×70 (por geometría simple) entran 8 páginas de 17×24.

Cada pliego por tanto contendrá un núermo de páginas del libro (4, 8, 16…) que se plegará formando un cuadernillo. El conjunto de cuadernillos será el que se encuaderne. Sí, coged un libro, y mirarlo de perfil, ¿observáis los cuadernillos cosidos junto al lomo?

En la figura podéis ver cómo se distribuyen las diferentes páginas en un pliego grande, y la orientación de las mismas.

Imposición

Pensad una cosa: Si de esas 8 páginas, 7 van impresas a 1 color y sólo la página 1 va a 4 colores, todo el pliego se imprime a 4 colores. Esto es una limitación a tener en cuenta.

Ayer empecé a dar un curso sobre Diseño Orientado a Objetos, UML y C++. Para hacer las prácticas, he decidido escoger las librerías Qt porque, para aprender (y para su uso en general) creo que son ideales:

• Buena documentación
• Gran cantidad de ejemplos
• Abarca todas las tecnologías a mano (XML, SQL, OpenGL, protocolos de red, HTML…)
• API desarrollada utilizando patrones de diseño
• No se saltan demasiado el estandar C++, al menos los añadidos (moc, rcc y demás) son programas externos, con lo cual, el código de Qt se puede compilar con gcc, con Visual Studio, con mingw, con Borland C++ (no Builder)…

Mientras, os cuelgo la presentación sobre orientación a objetos… por si pudiera interesar. POO.odp: versión en OpenOffice y la versión en PDF.

Cuando uno trabaja con un ERP, y con AbanQ en particular, hecha de menos que el sistema formetee según la configuración las diferentes cifras con las que se trabaja. Veámoslo:

FLFieldDB sin formato aplicado

Vale, al menos a mí me pasa, si voy con prisas, si voy con bulla (¿os suena en el curro?), ¿Qué cifra pone ahí? ¿ trece mil o ciento treinta mil?. Veamos lo siguiente:

FLFieldDB visualizando la cifra con Locale.

Se ve un poco mejor, ¿no? Voy a explicaros cómo se programa este pequeño cambio en AbanQ.

Read more…

InfoSial publicó el 16 de Marzo una nueva versión del código fuente de AbanQ. He actualizado los cambios que hice en el fuente de AbanQ según esa versión. Los archivos que debéis bajaros para compilar con esos nuevos fuentes son:

• FLFormDB.cpp
• FLFormRecordDB.cpp
• FLFormSearchDB.cpp
• FLObjectFactory.h
• FLTableDB.h
• FLTableDB.cpp

Como ya sabéis los cambios son:

• Posibilidad de presentar en los componentes FLTableDB el resultado de una consulta.
• Guarda automáticamente los tamaños de los formularios, y los recupera. El usuario por tanto, decide el tamaño de los formularios.
• Los formularios aparecen centrados.

Desde InfoSial me han comunicado su intención de incluir estos cambios en su nueva versión del motor de AbanQ, así que espero poder colaborar con ellos para incluir estos cambios (que principalmente son de usabilidad).

Read more…

Calcular el coste hoja de un pliego offset (por ejemplo, en 50×70 o 70×100) a partir del coste en €/Tonelada que te proporciona un proveedor de papel, es un proceso de reglas de tres consecutivas. Muchos impresores, tras años de experiencia se saben la fórmula de memoria y la aplican mecánicamente en su día a día.

Aquí os traigo un pequeño desarrollo, hecho en Qt4, software libre con licencia GPL para que lo utilicéis libremente. Todos los campos son editables y el cambio en un de ellos, implica recálculo en el resto. Os dejo también una captura de pantalla.

La descarga podéis hacerla desde aquí. Eah, a disfrutarlo.

Calculadora de costes de pliegos offset.

Os dejo por aquí el código fuente de la librería flbase modificada, corrigiendo bugs para conseguir la funcionalidad mostrada en anteriores posts. Había múltiples bugs (algunos debidos a mi desconocimiento del código de AbanQ y otros a efectos no contemplados). Creo que esta versión es bastante más robusta que la anterior. Permite además, efectos muy chulos, por ejemplo, modificar desde QSA la query de visualización de una FLTableDB por lo que puedes, en una misma ventana cargar datos de diferentes consultas según las diferentes opciones que el usuario seleccione.

A ver qué os parece…

Recibo hoy una carta de una entidad de recobro de facturas, solicitándonos el pago de una deuda de 79,68 € … que no me consta en ningún lado. Así que presto, llamo a dicha compañía, Intrum Justita, y la conversación, cuando menos es esperpéntica.

En primer lugar, se niegan a decirme a quién le debo, supuestamente, el dinero… Claro, ante la pregunta, “oiga, ¿y cómo sé que no se están uds inventando la deuda?” no tuvo más remedio que decirme a quién le debíamos ese importe. Y bingo, ¡¡era una compañía Teleco!! Sí, las que según la OCU, son las que protagonizan el mayor número de quejas y consultas de los consumidores. Esto promete. Tenemos una reclamación puesta a la antigua Airtel, de (atención) 2001 ya que nos cobraron una línea y un móvil, que nunca nos dieron (con lo cual, evidentemente, en Airtel, hoy Vodafone, no tienen albarán ni ningún documento justificativo que indique que disfrutamos de ese servicio, ¡¡puesto que no lo disfrutamos!!).

Respuesta de la operadora: “¿Han reclamado uds?”. “Sí, lo hicimos”. “Bien, pues para reclamar, primero deben de pagar”. ¡¡¡OLEEEE!!! Me encanta la política de este país. Según esa regla de tres, ¡¡acabo de encontrar un modo de financiación estupendo!! Emito facturas falsas, por servicios no prestados, y total, como para “reclamar primero hay que pagar” acabo de conseguir financiación a corto plazo y sin interés… ¡¡alguno habrá que pague y que reclame, en un proceso de años!!

Le expongo a la operadora este punto de vista (por cierto, en ese momento pierde ella un poco los nervios) y con un tono de voz elevado, me indica que me harán la reclamación por vía judicial y me incluirán en el asnef y ese tipo de registros. Intento tranquilizar los ánimos, y le indico que, por favor, me envíen copias de los documentos que obran en su poder y justifiquen que realmente tengo esa deuda y que realmente prueban que recibí ese servicio… y su respuesta no tiene desperdicio “ni tenemos esa documentación ni la podemos enviar”. ¡¡Es genial!! Mi vía de financiación es cada vez más sólida: Hay empresas que se dedican al recobro sin siquiera verificar que lo que solicitan es real.

Si no fuera, porque uno quiere ser empresario y no un timador profesional, quizás vería viabilidad en esta fórmula.

De verdad que hay cosas a las que no doy crédito…

Quizás no quedó del todo clara la modificación que hice sobre AbanQ, y la mejor manera es un ejemplo práctico para mostrar qué se puede lograr.

Vamos a trabajar con el formulario “Regularización de stocks” del módulo de Almacén del Área de Facturación. Cuando entramos en este formulario, vemos lo siguiente.

Regularización de stocks antes del cambio

Bien. Vamos a suponer que queremos introducir una regularización de Stocks de, por ejemplo, el artículo Aditivo de Mojado. Bien, en este ejemplo, tenemos Referencias “autoidentificables”, con lo cual, no es complicado averiguar que CONSOFFADITMOJADO, se corresponde al artículo en cuestión… ¿De verdad no es complicado? Quizás para algunos usuarios sí, y para otros no. Veamos una solución con la modificación que realicé:

Read more…

Conseguido! Creo que ya tengo una versión más o menos estable del ejecutable de AbanQ para Windows con las siguientes modificaciones:

• He eliminado la paleta que incluía InfoSial y a que a mí personalmente, no me gustaba estéticamente
• He corregido algunos problemas con el centrado de los formularios en pantalla. Los únicos que no se centran son las ventanas de Áreas. Estoy trabajando en un tratamiento especial para estos.
• He agregado la propiedad qryVisualizacion a los componentes FLTableDB que se incluyen en QtDesigner. Esto permite, como ya he explicado, mostrar en este tipo de componentes el resultado de una query SQL en lugar de una tabla. Esto es útil, si queremos ver el valor de columnas (o campos) de otras tablas relacionadas y que no se incluyen de manera duplicada en la tabla que editamos (política general de los módulos de AbanQ).

La instalacion Quick para Windows la tenéis aquí.

La instalación normal para Windows está aquí.

Los ficheros fuentes modificados están aquí.

Voy a explicar brevemente cómo utilizar la última característica que he añadido. Vamos a hablar de la tabla artículos. En la definición de articulos.mtd tenemos el codfamilia, y esto es lo máximo que podremos ver en el componente FLTableDB cuando pinchamos en Almacén->Artículos. ¿Y si quisiéramos ver a qué familia pertenece ese artículo? Pues o nos sabemos a qué corresponde el código de la familia (útil para expertos en ERP) o bien entramos a editar el artículo para ver la familia (lo que hace la mayoría).

Esta solución permite un paso intermedio y nos va a permitir visualizar en masterarticulos.ui no la tabla articulos, sino una query con el nombre de la familia.

Read more…