Impuesto Sobre La Renta (ISLR)

ISLR retenciones

El pasado 12 de mayo se cumplieron 20 años del Decreto Presidencial 1.808 el cual dicta las normas y procedimientos para las retenciones del Impuesto Sobre La Renta (ISLR). En todo ese tiempo hemos tenido dos Constituciones (enmienda incluida), varios Presidentes de la República, Congreso de Diputados y Senadores y luego una Asamblea Nacional Legislativa e infinidad de Ministros y Ministras ¿Cómo es posible que este decreto haya sobrevivido tanto tiempo?

Advertencia.
Advertencia.

Por supuesto que este artículo está dirigido a los venezolanos y venezolanas que hace muchísimos años nos retienen el Impuesto Sobre La Renta  “ISLR” en nuestro trabajo intelectual de servicios a las empresas privadas (nunca hemos laborado ni contratado con el sector público). No somos licenciados, ni contadores, mucho menos abogados, pero ya saben como reza el dicho “se puede desconocer la Ley pero la Ley no lo desconoce a usted” Y POR ESO ES MEJOR ESTUDIAR LA LEGISLACIÓN AL RESPECTO ya que estamos directamente involucrados. Vamos pues a este proceso de aprendizaje (o redescubrimiento, en realidad) de las Ciencias Sociales, rama Tributaria.

Impuesto Sobre La Renta (ISLR)
Impuesto Sobre La Renta (ISLR)

Antecedentes.

Acá hemos reportado sobre lo que es la Gaceta Oficial de la República, el Registro de Información Fiscal (ley de identificación incluída), las Normas de Emisión de Documentos, las retenciones de impuesto al valor agregado, la Unidad Tributaria y hasta un glosario tributario: todo esto, y aún más , “toca” y/o se ve relacionado con la Ley de Impuesto Sobre la Renta.

Las razones por las que a perdurado esta normativa tributaria fue debido a la quiebra del Banco Latino y que generó una seguidilla de quiebras a lo que llevó a la “crisis bancaria” de 1994 (esencialmente los dueños de los bancos usaron nuestros ahorros, compraron dólares estadounidenses en gran cuantía y se los llevaron a EEUU y otros paraísos fiscales para poner de rodillas al gobierno del Dr. Rafael Caldera -quien no es santo de nuestra devoción-).

Tenemos un artículo que trata sobre el tema, ya que lo que hacemos acá en Venezuela es vivir de la renta petrolera y al bajar los precios y los banqueros robarse las reservas internacionales con nuestros ahorros (teníamos cuenta en el Banco de Maracaibo y como iba a quebrar nos pasamos al Banco de Venezuela… el cual también quebró pero lo reflotaron, privatizaron y volvieron a nacionalizar y ahora es el primer banco del país) se descalabra la economía nacional toda.

Banco de Maracaibo libretas de ahorro 1994
Banco de Maracaibo libretas de ahorro 1994

Para no aburrirlos con nuestras historias que vivimos en carne propia acá una entrevista al Presidente (E) José Guillermo Andueza, padre del Decreto Presidencial 1.808 (el Dr. Rafael Caldera debido a su edad en su segundo mandato estaba muy aquejado de salud) ofrece declaraciones de lo que sucedía en el país para aquel entonces (cualquier similitud al dia de hoy NO es pura coincidencia, son los ciclos de altas y bajas de los precios del petróleo):

En 1997 con esa situación económica no solo se tenían que recaudar más impuestos sino que había que recortar “gastos” y aunque era el sector público el del problema, el sector privado también sufrió mucho por el aumento indiscrimidado de la divisa US$ así que el Doctor Rafel Caldera tuvo que echar marcha atrás en sus ideales (él es el padre de la Ley del Trabajo) y así lo anunciaba en ese mismo año 1997:

De aquella época guardamos los folletos que entregaba la Guardia Nacional, negocio por negocio, y recordamos la Ley de Remisión Tributaria que fue una ley de amnistías fiscal (si es que ese término existe) porque la evasión era espantosa, EXISTÍA MUY POCA CULTURA TRIBUTARÍA EN ESE PERÍODO PRESIDENCIAL pero afortunadamente DISIP y Guardia Nacional pudieron poco a poco enmendar el capote.

Impresión y emisión de factura y otros documentos LEY DE REMISIÓN TRIBUTARIA 1994
Impresión y emisión de factura y otros documentos LEY DE REMISIÓN TRIBUTARIA 1994
Máquinas fiscales 1994
Máquinas fiscales 1994
Disposición transitoria ICSVM 1994
Disposición transitoria ICSVM 1994

Volver al futuro: estamos en el año 2017, veinte años después.

Lo que era el Ministerio de Hacienda desapareció y vino el Ministerio de Finanza en sus distintos nombres pero lo que no ha cambiado su nombre es el Servicio Nacional Integrado de Administración Tributaria y Aduanera (SENIAT). Como ente encargado de la recolección de impuestos se ha modernizado mucho con el tiempo y de un tiempo a esta parte mantienen en línea un Portal Fiscal donde almacenan la información relevante y actualizada. Primero la Constitución, luego las Leyes, después los Reglamentos, Decretos, Resoluciones y Providencias (en ese orden y apenas “rasguñamos” la burocracia) es entonces que vamos a concentrarnos en los Reglamentos.

Enlaces para la descarga de los documentos.

Página web del SENIAT “Portal Fiscal”.

En este enlace del Portal Fiscal, sección “Tributos Internos-> Impuesto Sobre La Renta-> Leyes” aparece el «Decreto con Rango, Valor y Fuerza de Ley de impuesto sobre la Renta» vigente al momento de escribir este artículo.

En este otro enlace del Portal Fiscal, sección “Tributos Internos-> impuesto Sobre La Renta-> Reglamentos” aparecen el «Reglamento de la Ley de Impuesto Sobre la Renta» y el objeto de nuestro somero y humilde estudio de hoy, el «Decreto 1.808, Reglamento Parcial de la Ley de Impuesto Sobre la Renta en Materia de Retenciones».

Documentos en formato PDF.

No obstante vamos a colocar los enlaces directos de donde pueden descargar los ejemplares electrónicos de las Gacetas Oficiales primero primero desde el Portal Fiscal del SENIAT:

No, no están viendo mal, el Reglamento Parcial está de primero en orden cronológico, luego viene el Reglamento y de último y más reciente está la Ley. De hecho, el Reglamento reconoce en su artículo 220 que se derogan cualesquiera otras disposiciones reglamentarias que se opongan o colidan con el Reglamento.

Detalles acerca del Reglamento del ISLR.

Otros detalles del Reglamento, antes de comenzar con el Reglamento Parcial:

  • El artículo 27 especifica que se deben especificar por separado el pago a capital y el pago de intereses y de no hacerlo se considerará que todo el pago es a intereses lo cual genera tributo y los bancos se cuidan muy bien de ello.
  • El artículo 30 (Título II, Capítulo I) del Reglamento viene a ser copia del artículo 14 (Capítulo V) del Reglamento Parcial (por no decir que son idénticos).
  • El artículo 31 del Reglamento es el Parágrafo Único del artículo 14 del Reglamento Parcial.
  • El artículo 32 del Reglamento contienen los literales de la a) a la e) del artículo 14 del Reglamento Parcial.
  • El artículo 33 del Reglamento es el artículo 15 del Reglamento Parcial.
  • El Reglamento incluye una larguísima normativa sobre los ajustes de inflación los cuales se revirtieron con la útlima reforma de la Ley del Impuesto Sobre La Renta (si estamos equivocados: Twitter @ks7000).
  • El Título V, Capítulo I habla sobre las normas de facturación y que son ratificadas en la Providencia 00071 del SENIAT .
  • El Título V, Capítulo II versa sobre el movimiento y registro de los inventarios (“magnético” -léase computarizado- sí y sólo sí el SENIAT autoriza a la persona jurídica a llevarlo de esta manera el SENIAT NO CERTIFICA SOFTWARE NI APLICACIONES; al hacer una inspección fiscal ellos y ellas observan cómo funciona el sistema, los campos que llevan los informes impresos y dan luz verde para que soliciten el permiso de manera escrita por ante la oficina regional correspondiente).
  • El artículo 104 y 119 introducen el concepto de “procedimiento tradicional del costo de ventas” con el cual todos los contadores y contadoras con que hemos laborado nos piden constantemente (incluso tenemos una rutina automatizada para ello); es el famosísimo “…inventario inicial más las compras menos el inventario final.
  • El Título V, Capítulo III especifica la instauración y amntenimiento del Registro de información Fiscal el cual posteriormente es formalmente creado por la Providencia 0013 del SENIAT en el año 2006 y es modificada para adecuarla a los progresos en computación en la Providencia 0048 del SENIAT en el año 2013.
  • El Título V, Capítulo IV indica que el Registro Inmobiliario queda en manos del SENIAT y es por ello que allí registramos nuestra vivienda principal para asuntos de declaración de impuesto sobre la renta de cada año.
  • Todo lo relacionado con el ISLR en Venezuela, país petrolero, está íntimamente relacionado con empresas extranjeras en suelo patrio o de nuestros trabajadores en el exterior: por ello las tarifas y tratamientos son marcadamente diferenciados si se tratan de personas (naturales o jurídicas) residenciadas o no residenciadas en nuestro país, eso lo veremos en el Reglamento Parcial.
  • Para finalizar el somero estudio del Reglamento, se norma que cualquier reclamo en cuanto a errores de declaración del impuesto sobre la renta cada oficina regional del SENIAT será quienes diriman dichos asuntos, los cuales son variopintos.

Reglamento Parcial de la Ley De Impuesto Sobre La Renta en Materia de Retenciones.

Al final de esta entrada y como suplemento, próximamente, hallarán la transcripción de las Gacetas Oficiales lo cual haremos con ayuda del Tesseract OCR.

Artículo uno: sujetos obligados a retener.

Entrando en materia y al grano, son objeto de retenciones, básicamente:

  1. Ganancias fortuitas (loterías -juegos de azar- y caballos).
  2. Enajenación de acciones en la Bolsas de Valores.
  3. Sueldos y salarios (excluídos viáticos y alimentación).
  4. Honorarios Profesionales con las siguientes excepciones:
    • carpintería.
    • herrería.
    • latonería.
    • pintura.
    • mecánica.
    • electricidad.
    • albañilería.
    • plomería.
    • jardinería.
    • zapatería.
    • cualquier otro de naturaleza manual (…pues ¡ de haber comenzado por ahí ! ).
  5. Servicios cuando sean principales las obligaciones de hacer, excepto los siguientes:
    • suministro de agua.
    • electricidad.
    • gas.
    • telefonía fija o celular.
    • aseo domiciliario.
  6. Fletes en el territorio nacional.
  7. Primas de seguros y reaseguros.
  8. Cánones de Arrendamiento de bienes muebles e inmuebles.
  9. Intereses de Capitales.
  10. Comisiones de ventas de bienes muebles e inmuebles.
  11. Impuestos proporcionales.
  12. Rentas presuntas.
  13. Publicidad y Propaganda.

Artículo 21: plazos para enterar

En el caso número uno del artículo uno, se deben enterar (es decir, pagar al gobierno, al Tesoro Nacional) al día siguiente hábil de la retención (para poder pagar el premio se debe hacer primero la retención correspondiente).

En el caso número dos del artículo uno se deben enterar los siguientes tres días hábiles, esto es exclusivamente con las bolsas de valores.

Del tercer caso en adelante se hacen los tres primeros días hábiles del mes excepto si se es nombrado como “contribuyente especial” ya que tienen un calendario especial según el parágrafo único (nosotros ya hicimos una entrada al respecto por estos lares con respecto a retenciones de IVA y cuyo calendario coincide con lo del ISLR).

Artículos 2 al 8: retenciones de sueldos y salarios.

En el renglón tercero del artículo uno, lo correspondiente a retenciones de sueldos y salarios la materia es densa y delicada, por ello los remitimos a profesionales especializados que han hecho una guía práctica al respecto.

Artículo 9: tabla de retenciones.

Del renglón cuarto al séptimo son los más comunes, es por ello que nos enfocaremos más en esos casos.

Se debe prestar especial atención si la persona natural es residente o NO residente en nuestro país porque los porcentajes de retención que se aplican en el segundo caso son prácticamente los mismos establecidos en la declaración anual ISLR (34%), así que ojo con eso (igual sucede con las personas jurídicas domiciliadas). Hay un detalle en el artículo 3, parágrafo primero del Reglamento Parcial que estipula que si una persona natural demuestra que ha permanecido 180 días en el país (de manera contínua o no) se debe considerar RESIDENTE y se ha de tramitar un RIF de oficio con el SENIAT. Osea, el hecho de que tengan pasaporte no necesariamente es indicativo de que NO es residente, atención a esto.

 

Cuando aquí nombremos a “residentes” nos referimos a las “Personas Naturales Residentes en nuestro país”. Cuando acá nombremos a “domiciliadas”nos referimos a las “Personas Jurídica Domiciliadas en nuestro país”. Cuando escribimos “UT” nos referimos a “Unidad(es) Tributaria(s)”.

 

Los «beneficiarios de la remuneración» que son residentes tienen un porcentaje distinto de retención de la domiciliadas.

 

En el caso de los NO residentes y NO domiciliados los porcentajes de retención pueden ser varios debidos a los montos en función con cantidad de unidades tributarias. Por ejemplo especifican que hasta dos mil UT un 15%, desde dos mil hasta tres mil UT un 22% y para más de tres mil UT un 34%, Y ATENCIÓN si el pago OTRO EJEMPLO es por el equivalente a siete mil UT se debe retener 15% a las primeras 2000 UT, 22% a las próximas 1000 UT y 34% a las restantes 4000 UT. Es por ello que nuestra tabla de causales será un maestro y en otra tabla de detalles colocaremos los porcentajes de retención a todos los causales y con cada uno de sus condicionales en el caso de haber más de un procentaje de retención. OTRA COSA IMPORTANTE es que cada una de los “escalones” retenidos deberán ser informado al SENIAT en registros separados para cada monto (por supuesto, repitiendo los numeros de factura y los numeros de control para cada registro) POR ELLO DECIDIMOS REALIZAR PARA CADA REGISTRO UN NÚMERO DE COMPROBANTE DISTINTO E INDIVIDUALIZADO.

En el artículo 9°, parágrafo segundo, tuvieron un “gazapo”: en el monto mínimo de las retenciones a domiciliadas (cuando el porcentaje a retener es del 5% y 3%) COLOCARON LOS MONTOS DE MANERA ABSOLUTA (1250 y 750) , ES DECIR, NO EN FUNCIÓN DEL VALOR DE LA UNIDAD TRIBUTARIA. En 2007 se le aplicó, tal como establece la Ley de Reconversión Monetaria, estos montos quedaron en 1,25 (si el porcentaje de retención es del 5%) y 0,75 (idem 3%) LO QUE QUIERE DECIR, EN LA PRÁCTICA -Y DESDE HACE MUCHOS AÑOS- QUE SE RETIENE A TODO MONTO EN ESTOS CASOS (y se cumple con el espíritu del legislador ya que las retenciones con porcentaje del 3% y 1% es a todo monto por eso entrecomillamos la palarbra gazapo al principio de esta cita citable). ¡ATENCIÓN! La ley es la ley, así que cuando programamos debemos colocar este valor absoluto de 1,25 y 0,75, respectivamente en el código de nuestro programa, así signifique en la práctica que se retiene a todo monto a persona jurídica domiciliada en nuestro país.

Artículo 25: sistemas computarizados especiales.

Y ahora es que llegamos a la aparte de la programación, lo que se empeñan en llamar el “manual técnico”. En este artículo se establece, con visión de futuro, que el SENIAT (mejor dicho, la Administración Tributaria, cualquiera sea el nombre que tenga o tuviere en ese o este momento) colocará lineamientos generales o específicos y en este caso vaya que son bien específicos.

Todo deriva del manual vigente que a la fecha de escribir estas líneas tiene establecido el SENIAT en su Portal Fiscal. Lo primero que tenemos que aclarar es que vamos a generar un archivo en lenguaje XML que contendrá los datos de la retención pero que en realidad serán calculados por “los servidores web del SENIAT” y nos devolverá un valor con la suma de las retenciones. Nosotros lo vemos como un “doble ciego”: con el programa que hagamos calculamos y hacemos las retenciones oportunamente y su sumatoria ha de ser igual al cálculo -según los datos fidedignos que le enviemos- a los “servidores web” del SENIAT, ¿qué les parece?

Pero esperen, aún hay más: el propio SENIAT pone a nuestra disposición un XML con el que podemos comprobar los datos antes de enviarlos siempre y cuando tengamos un software confiable que realice dicha comprobación.

Es entonces que aparte del trabajo del XML y sus correspondientes tablas y campos en la base de datos, también debemos establecer otros datos que necesitaremos para cumplir con el artículo 24 que tratamos a continuación.

Artículo 24: de la obligatoriedad de entregar comprobantes de retención, entre otros datos.

Este artículo es el mejor de todos: los dos campos obligatorios son el monto de lo pagado y la cantidad retenida, tal cual. He aquí que se nos abre nuestra vena creativa siempre teniendo en cuenta las reglas de normalización de las bases de datos. Como abrebocas la tabla que contendrá al RIF:

  • El campo RIF, el cual será único según la ley respectiva, lo guardaremos en una tabla junto con un identificador autonumérico entero, indexado, y en otras tablas el resto de los datos de los “beneficiarios de la remuneración”.
  • Nombre o razón social en una tabla aparte, ya que los nombres de las empresas pueden cambiar con el tiempo y nuestros documentos deben ser fidedignos a como fueron impresos, esto se logra agregando un campo lógico verdadero/falso llamado “activo” y que será verdadero en el único caso del último cambio de razón social y válido para las nuevas retenciones; las anteriores retenciones van relacionadas con el nombre o razón social que tenían al momento de hacer el comprobante. También necesitaremos un campo autonumérico entero, indexado, para identificar el nombre o razón social que lleva el comprobante.
  • Dirección fiscal: igual al ítem anterior pero con algo añadido si la persona jurídica tiene sucursales, lo mejor es guardar cada dirección aparte para saber con quién “hicimos negocio” (de hecho las normas contables en una sucursal son las mismas como si fuera empresa independiente, la “pesadilla” es para los contadores y auditores que tienen que consolidar en la casa matríz o principal todos los días).
  • Teléfonos: pues los que sean necesarios, aunque no es un requisito de ley vaya que nos ahorramos problemas y malentendidos con una simple llamada telefónica.
  • Correo(s) electrónico(s): que a pesar que el ISLR ni sus reglamentos son obligatorios -a diferencia de las retenciones de IVA que si están claramente tipificadas el comprobante por vía electrónica- cumple el mismo papel de los números de teléfonos.
  • Cualesquiera de otros datos que consideremos necesarios: pues bien, creamos una tabla con el identificador numérico relacionado con la tabla que contiene los RIF, un identificador autonumérico entero, un campo lógico para indicar si está activo o no y el campo a guardar (fecha, texto, numérico, etc).

Manual técnico: descripción de los elementos del archivo.

Ya nos “apartamos” un poco del Reglamento Parcial y estamos de lleno con lo nuestro, la programación y los ordenadores. A diferencia de la sección anterior, artículo 24, el Manual Técnico ordena unos campos mínimos con características muy precisas que debemos colocarlas en nuestra base de datos sin más:

  1. RifAgente: <elemento raíz>, tipo cadena, 10 caracteres, primero una letra y luego dígitos que identifica al Agente de Retención.
  2. Periodo: <elemento raíz>, mes cuando se hizo la retención en el formato “AAAAMM” (año completo 4 dígitos y número de mes incluyendo cero a la izquierda de enero a septiembre ).
  3. RifRetenido: <elemento>, igual a (1) pero identifica al “beneficiario de la remuneración”.
  4. NumeroFactura: <elemento>, mínimo 1 caracter (cero si no es factura), máximo diez caracteres (los últimos 20 dígitos, de ser más largo el número de factura).
  5. NumeroControl: <elemento>, mínimo 1 caracter, máximo 10 (colocar “NA” si no es factura).
  6. FechaOperacion: <elemento>, campo fecha, que en el Manual Técnico NO APARECE porque fue a partir de septiembre de 2014 que lo implementaron para poder tomar el valor de la UT correcto (esto se requiere una vez al año, cuando aumenta la UT pero en teoría de programación -LEYES APARTE- serviría para cualquier aumento O MODIFICACIÓN del valor de la UT). Dicha fecha debe coincidir con el perído que se declara. No debemos confundir FechaOperacion con, por ejemplo, la fecha de una factura, son cosas distintas (entiéndase que es la fecha cuando hicimos el comprobante).  Para mayor información, descargar en el siguiente comunicado publicado el Portal Fiscal.
  7. CodigoConcepto: <elemento>, tabla tipificada por el SENIAT que analizaremos luego que consiste en dos dígitos (aunque acepta máximo tres caracteres ¿visión a futuro, números con mantisa o signo?).
  8. MontoOperación: <elemento>, el separador decimal es el punto con máximo dos posiciones decimales, el valor mínimo es cero, un caracter “0”.
  9. PorcentajeRetencion: <elemento>, mínimo cero, máximo cien, separador decimal el punto, dos posiciones decimales.

Para los sistemas informáticos del SENIAT no existen acentos ni caracteres especiales. Además, en el caso que permitan el separador decimal, éste siempre será el punto. Advertidos todos y todas.

Advertencia.
Advertencia.

En el Manual Técnico se asegura que es posible sumar y declarar todas las operaciones que tengan el mismo “CodigoConcepto” colocandole los datos  de una FACTURA CUALQUIERA (“NumeroFactura” y “NumeroControl”) DEL PERÍODO CORRESPONDIENTE, PERO EN LA PRÁCTICA NADIE HACE ESO debido a la sencilla razón de que uno, “el beneficiario de la remuneración” revisa por medio  de nuestra Clave de Usuario en el Portal Fiscal cada una de las retenciones, POR AQUELLOS DE QUE “CUENTAS CLARAS MANTIENEN AMISTADES (Y NEGOCIOS también)”.

 

Eso es lo que exige el SENIAT en los datos y campos a transferir pero para nuestro programa tenemos que agregar unos campos que consideramos necesarios ya que varían en el tiempo:

  • En una tabla aparte que llamaremos (¡qué original!) Unidad_Tributaria con un campo identificador autonumérico entero, valor monetario, fecha de inicio de vigencia, fecha de finalización (la unidad tributaria vigente finaliza el 31 de diciembre de 9999 nueve mil novecientos noventa y nueve y cambiará a un día antes de la fecha de entrada en vigencia de una nueva unidad tributaria -la cual generalmente cambia una vez al año en febrero-). Las restricciones de fecha son relativas  a otros registros, no en valores absolutos: la fecha de inicio de vigencia no podrá ser menor que la mayor fecha de inicio registrada y en cascada para la fecha de finalización.
  • Otra tabla llamada Unidad_Tributaria_Gaceta contendrá información tales como número, fecha y tipo de Gaceta Oficial donde se decretó el valor de la unidad tributaria y otra tabla llamada Unidad_Tributaria_Gaceta_Enlaces con las posibles direcciones web de donde descargar u obtener más información al respecto. Estas tablas puede esperar, no las definiremos ahora, no en esta entrada.

Diseñando la base de datos en MySQL y phpMyAdmin.

La base de datos que vamos a crear la llamaremos (pecando de originales) “ks7000_ks7000” con un ordenamiento de caracteres utf8_spanish_ci (ordena la eñe entre la ene y la letra o, y la che es una letra entre ce y de e igual la doble ele). El almacenamiento InnoDB (y en otra entrada hablaremos de MySQL con calma). Como comentario le colocaremos “Valores de la Unidad Tributaria a lo largo de los años”, veamos:

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE `Unidad_Tributaria` (
`UT_id` INT(10) UNSIGNED NOT NULL,
`UT_val` DECIMAL(10,0) NOT NULL DEFAULT '0',
`UT_fec_ini` DATE NOT NULL DEFAULT '1994-01-01',
`UT_fec_fin` DATE NOT NULL DEFAULT '9999-12-31'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci COMMENT='Valores de la Unidad Tributaria a lo largo de los años.';

ALTER TABLE `Unidad_Tributaria`
ADD PRIMARY KEY (`UT_id`);

ALTER TABLE `Unidad_Tributaria`
MODIFY `UT_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=1;

Volviendo al tema de los comprobantes de retención del ISRL, necesitamos el valor de la Unidad Tributaria actual para poder realizar el cálculo de la retención. Según el Manual Técnico, TODOS los datos son obligatorios y puede darse el caso que una “retención” no tenga monto, es decir, debido al monto de la remuneración no procede ningún monto a retener más sin embargo debemos informarle esto al SENIAT quienes de nuevo harán al cálculo para certificar que esto es cierto. Esto es análogo al caso de las retenciones de IVA y la caja chica pero éstas (facturas de caja chica) no debemos reportarlas en el txt a “subir” al SENIAT.

Atención: recordemos que los trabajos por labores manuales (carpintería, herrería, etc.) al igual que los servicios de agua, telefonía, etcétera, NO llevan retención ISLR alguna. NO LOS INCLUIREMOS EN EL XML (más si le haremos su respectiva retención de IVA si su monto es más de 20 UT).

Hemos visto el caso de empresas que retienen ISLR indebidamente (¡ups!), pues nada se le reintegra al “beneficiario de la remuneración” acompañado de una disculpa e incluso hay casos que expresan que le hagan una nota de crédito (nada que ver con IVA ni formas libres ni impresoras fiscales) en el estado de cuenta (CxP) para la próxima vez que cobren otro “trabajo”, que no sabemos cuando será pero eventualmente se producirá; así da gusto trabajar con la gente, que tomen las cosas con calma.

Creando la tabla que alojará los comprobantes de retención.

Dicha tabla la llamaremos de manera muy explícita ISLR_retenciones y contendrá los campos que anuncia el Manual Técnico y, según nuestro criterio, de manera adicional los siguientes campos:

  • ISLR_idNumeroComprobante: autonumérico, entero, indexado; como para cada documento hay una sola retención ISLR (a diferencia de las retenciones de IVA) este autonumérico puede funcionar como número de comprobante y al SENIAT le importa un pepino esto, ya que para ellos no es obligatorio sin embargo nosotros, maniáticos del orden y decoro es necesario para nosotros.
  • ISLR_UnidadTributariaValor: el valor en sí de la UT para nuestros memorias (los servidores web del SENIAT simplemente aplican el valor vigente de la UT a la fecha según el campo FechaOperacion y hacen el cálculo ¿Ven ahora por qué debemos llevar aparte en una tabla los valores históricos de la UT?). Como es un valor preferimos colocarlo, pero miren el próximo campo.
  • ISLR_idUnidadTributariaValor: aquí si podemos normalizar para los detalles que dijimos, número de Gaceta Oficial, enlaces web, etc.

Creando la tabla que alojará los causales de retención.

Estos causales están basados en el Manual Técnico sin embargo no es suficiente para nuestros usuarios de software, aquellos quienes pagan nuestras habilidades de programación.

Nuestra genialidad estriba en desarrollar software para que nuestros usuarios escojan rápidamente y de acuerdo a las restricciones los llevamos a un solo resultado, la realización de la retención. Es así que nuestros usuarios expresarán “¡QUÉ FÁCIL Y SENCILLO ES HACER RETENCIONES DE ISLR!”.

Como ya habíamos adelantado, tenemos una tabla maestra que llamaremos ISLR_RetencionesCausales:

  • idCausal: campo autonumérico para identificar cada causal.
  • El segundo campo lo llamaremos “Codigo” tipo CHAR de 4 caracteres que utilizaremos para especificar nuestros propios causales (que no generan ni retencion -ni su declaración informativa- de ISRL) a partir de mil en potencias de base dos (1002, 1004, 1008, etcétera) y para menores de mil los especificados en el Manual Técnico.
  • El segundo campo lo llamaremos “Actividad” y lo rellenaremos tal como lo describen en el Manual Técnico. Para nuestros causales mayores en código a mil le colocaremos “NA” tal como estila el Manual Técnico cuando “No Aplica”.
  • BaseExenta: monto a partir del cual podremos retener, puede ser un monto específico o un monto calculado dependiente de el valor de la Unidad Tributaria y una constante cuyo valor es 83,3334. Deberemos, a futuro, colocar un disparador cuando se agregue un registro (nuevo valor) de la Unidad Tributaria para recalcular dichos montos que dependan de la fórmula (ver siguiente campo). Si el valor es cero entonces es todo pago.
  • BaseExentaFormula: sirve para indicar si BaseExenta depende de una fórmula que debamos aplicar si se agrega un nuevo valor de la Unidad TRibutaria, por defecto cero, falso.
  • Sustraendo: es un monto que depende siempre de una fórmula, misma consideración que con BaseExenta pero no necesita un campo lógico adicional, el disparador actualizará automáticamente -según fórmula, UT multiplicada por el procentaje de retención y el resultado multiplicado por la constante de ley 83,3334.
  • BaseImponible: algunos causales especifican que NO es todo el monto al cual vamos a retener sino un porcentaje o del mismo al cual luego le aplicaremos el procentaje correspondiente de retención, esto es para no residente o no domiciliados, que son casos que consideramos “especiales”.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE `ISLR_RetencionesCausales` (
`idCausal` INT(11) NOT NULL,
`Codigo` CHAR(4) COLLATE utf8_spanish_ci NOT NULL DEFAULT '0000',
`Actividad` VARCHAR(255) COLLATE utf8_spanish_ci NOT NULL DEFAULT 'NA' COMMENT 'Así lo llama el Manual Técnico.',
`BaseExenta` DECIMAL(10,0) NOT NULL DEFAULT '0' COMMENT 'Monto mínimo para hacer retención ya sea valor o fórmula UT*83,3334',
`BaseExentaFormula` tinyint(1) NOT NULL DEFAULT '0' COMMENT 'Si BaseExenta depende de fórmula',
`Sustraendo` DECIMAL(10,0) NOT NULL DEFAULT '0' COMMENT 'Valor según fórmula UT*%ret*83,3334',
`BaseImponible` DECIMAL(10,0) NOT NULL DEFAULT '100' COMMENT 'Porcentaje del monto al cual aplicarle procentaje de retención'
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci;

ALTER TABLE `ISLR_RetencionesCausales`
ADD PRIMARY KEY (`idCausal`),
ADD KEY `Codigo` (`Codigo`);

ALTER TABLE `ISLR_RetencionesCausales`
MODIFY `idCausal` INT(11) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=1;

La acompañaremos de una tabla con los detalles de los porcentajes de retención y la llamaremos  ISLR_RetencionesPorcentajes:

  • idCausal: entero, que está relacionado con IdCausal de la tabla anterior.
  • Porcentaje: decimal, explícito.
  • Monto: en el caso que explicamos (no domiciliada) que se debe retener “en escalones” según las unidades tributarias pero colocamos aquí el monto “de una vez” y con el disparador al agregar un valor de la UT se multipilicará ese nuevo valor por el próximo campo NumeroUT.
  • NumeroUT: ver renglón anterior.
  • Ordinal: lo tendremos en cuenta para retribuir en el orden correcto de la base de datos los “escalones” a los cuales les haremos retenciones. Este campo cambia si y solo si modifican el Reglamento Parcial.

Rellenando los causales de retención.

 

Descripción completa de los causales de retención, según Manual Técnico.

Decidimos compartir con todos los venezolanos y venezolanas (y unos cuantos extranjeros tal vez les sea útil esta información) por medio de un repositorio en GitHub de manera pública en este enlace web. Lo publicamos en dos formatos diferentes, en lenguaje SQL y en XML, no obstante acá publicamos también ambos códigos:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
-- phpMyAdmin SQL Dump
-- version 4.5.4.1deb2ubuntu2
-- http://www.phpmyadmin.net
--
-- Servidor: localhost
-- Tiempo de generación: 24-06-2017 a las 16:14:24
-- Versión del servidor: 5.7.18-0ubuntu0.16.04.1
-- Versión de PHP: 7.0.18-0ubuntu0.16.04.1
-- Creado por: Jimmy Olano
-- Correo-e: olano@ks7000.net.ve
-- Códigos por concepto de retención de Impuesto Sobre La Renta
-- según Manual técnico SENIAT N° 60.40.40.039, Versión 2.3, enero 2017,
-- disponible en el Portal Fiscal en formato pdf en el siguiente enlace web:
-- http://declaraciones.seniat.gob.ve/portal/page/portal/MANEJADOR_CONTENIDO_SENIAT/05MENU_HORIZONTAL/5.3ANUNCIOS_CARTELES/5.3.2CARTELES_NOTIFICACION/CARTELES/MT_Retenciones%20ISLRV3.0_2014.pdf
-- Según artículo 25 del Reglamento Parcial de la Ley De Impuesto Sobre La Renta
-- en Materia de Retenciones publicado en la Gaceta Oficial N° 36.203,
-- de fecha lunes 12 de mayo de 1997.
--
-- Usted es libre de usar y/o distribuir esta información
-- según la siguiente licencia:
-- https://creativecommons.org/licenses/by-sa/3.0/ve/

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "-04:00";

&nbsp;

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;

--
-- Base de datos: `seniat-islr`
--

-- --------------------------------------------------------

--
-- Estructura de tabla para la tabla `seniat_codigo_concepto_retencion_islr`
--

CREATE TABLE `seniat_codigo_concepto_retencion_islr` (
`codigo` tinyint(4) NOT NULL,
`concepto` VARCHAR(1024) COLLATE utf8_spanish_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_spanish_ci COMMENT='Manual técnico SENIAT N° 60.40.40.039 Versión 2.3 enero 2017';

--
-- Volcado de datos para la tabla `seniat_codigo_concepto_retencion_islr`
--

INSERT INTO `seniat_codigo_concepto_retencion_islr` (`codigo`, `concepto`) VALUES
(1, 'Sueldos y Salarios'),
(2, 'Honorarios Profesionales No Mercantiles (PNR)'),
(3, 'Honorarios Profesionales No Mercantiles (PNNR)'),
(4, 'Honorarios Profesionales No Mercantiles (PJD)'),
(5, 'Honorarios Profesionales No Mercantiles (PJND)'),
(6, 'Honorarios Profesionales Mancomunados No Mercantiles(PNR)'),
(7, 'Honorarios Profesionales Mancomunados No Mercantiles(PNNR)'),
(8, 'Honorarios Profesionales Mancomunados No Mercantiles(PJD)'),
(9, 'Honorarios Profesionales Mancomunados No Mercantiles(PJND)'),
(10, 'Honorarios Profesionales pagados a Jinetes,Veterinarios, Preparadores o Entrenadores (PNR)'),
(11, 'Honorarios Profesionales pagados a Jinetes, Veterinarios, Preparadores o Entrenadores (PNNR)'),
(12, 'Honorarios Profesionales pagados por Clínicas, Hospitales, Centros de Salud, Bufetes, Escritorios, Oficinas, Colegios Profesionales u otra Institución Profesionales No Mercantiles a Profesionales sin relación de dependencia (PNR)'),
(13, 'Honorarios Profesionales pagados por Clínicas, Hospitales, Centros de Salud, Bufetes, Escritorios, Oficinas, Colegios Profesionales u otra Institución Profesionales No Mercantiles a Profesionales sin relación de dependencia (PNNR)'),
(14, 'Comisiones pagadas por la venta de bienes inmuebles (PNR)'),
(15, 'Comisiones pagadas por la venta de bienes inmuebles (PNNR)'),
(16, 'Comisiones pagadas por la venta de bienes inmuebles (PJD)'),
(17, 'Comisiones pagadas por la venta de bienes inmuebles (PJND)'),
(18, 'Cualquier otra Comisión distintas a Remuneraciones accesorias de los sueldos, salarios y demás remuneraciones similares (PNR)'),
(19, 'Cualquier otra Comisión distintas a Remuneraciones accesorias de los sueldos, salarios y demás remuneraciones similares (PNNR)'),
(20, 'Cualquier otra Comisión distintas a Remuneraciones accesorias de los sueldos, salarios y demás remuneraciones similares (PJD)'),
(21, 'Cualquier otra Comisión distintas a Remuneraciones accesorias de los sueldos, salarios y demás remuneraciones similares (PJND)'),
(22, 'Intereses de Capitales tomados en préstamo e invertidos en la producción de la renta (PNNR)'),
(23, 'Intereses de Capitales tomados en préstamo e invertidos en la producción de la renta (PJND)'),
(24, 'Intereses provenientes de préstamos y otros créditos pagaderos a instituciones financieras constituidas en el exterior y no domiciliadas en el país (PJND)'),
(25, 'Intereses pagados por las personas jurídicas o comunidades a cualquier otra persona natural, jurídica o comunidad (PNR)'),
(26, 'Intereses pagados por las personas jurídicas o comunidades a cualquier otra persona natural, jurídica o comunidad (PNNR)'),
(27, 'Intereses pagados por las personas jurídicas o comunidades a cualquier otra persona natural, jurídica o comunidad (PJD)'),
(28, 'Intereses pagados por las personas jurídicas o comunidades a cualquier otra persona natural, jurídica o comunidad (PJND)'),
(29, 'Enriquecimientos Netos de las Agencias Internacionales cuando el pagador sea una personas jurídica o comunidad domiciliada en el país (PJND)'),
(30, 'Enriquecimientos Netos de Gastos de Transporte conformados por fletes pagados a agencias o empresas de transporte internacional constituidas y domiciliadas en el exterior (PNNR)'),
(31, 'Enriquecimientos Netos de Gastos de Transporte conformados por fletes pagados a agencias o empresas de transporte internacional constituidas y domiciliadas en el exterior (PJND)'),
(32, 'Enriquecimientos Netos de Exhibición de Películas, Cine o la Televisión (PNNR)'),
(33, 'Enriquecimientos Netos de Exhibición de Películas, Cine o la Televisión (PJND)'),
(34, 'Enriquecimientos obtenidos por concepto de regalías y demás participaciones análogas (PNNR)'),
(35, 'Enriquecimientos obtenidos por concepto de regalías y demás participaciones análogas (PJND)'),
(36, 'Enriquecimientos obtenidos por las Remuneraciones, Honorarios y pagos análogos por Asistencia Técnica (PNNR)'),
(37, 'Enriquecimientos obtenidos por las Remuneraciones, Honorarios y pagos análogos por Asistencia Técnica (PJND)'),
(38, 'Enriquecimientos obtenidos por Servicios Tecnológicos utilizados en el país o cedidos a Terceros (PNNR)'),
(39, 'Enriquecimientos obtenidos por Servicios Tecnológicos utilizados en el país o cedidos a Terceros (PJND)'),
(40, 'Enriquecimientos Netos derivados de las Primas de Seguros y Reaseguros (PJND)'),
(41, 'Ganancias Obtenidas por Juegos y Apuestas (PNR)'),
(42, 'Ganancias Obtenidas por Juegos y Apuestas (PNNR)'),
(43, 'Ganancias Obtenidas por Juegos y Apuestas (PJD)'),
(44, 'Ganancias Obtenidas por Juegos y Apuestas (PJND)'),
(45, 'Ganancias Obtenidas por Premios de Loterías y de Hipódromos (PNR)'),
(46, 'Ganancias Obtenidas por Premios de Loterías y de Hipódromos (PNNR)'),
(47, 'Ganancias Obtenidas por Premios de Loterías y de Hipódromos (PJD)'),
(48, 'Ganancias Obtenidas por Premios de Loterías y de Hipódromos (PJND)'),
(49, 'Pagos a Propietarios de Animales de Carrera por concepto de Premios (PNR)'),
(50, 'Pagos a Propietarios de Animales de Carrera por concepto de Premios (PNNR)'),
(51, 'Pagos a Propietarios de Animales de Carrera porconcepto de Premios (PJD)'),
(52, 'Pagos a Propietarios de Animales de Carrera por concepto de Premios (PJND)'),
(53, 'Pagos a Empresas Contratistas o Subcontratistas domiciliadas o no en el país, por la ejecución de obras o de la prestación de servicios en base a valuaciones y ordenes de pago (PNR)'),
(54, 'Pagos a Empresas Contratistas o Subcontratistas domiciliadas o no en el país, por la ejecución de obras o de la prestación de servicios en base a valuaciones y ordenes de pago (PNNR)'),
(55, 'Pagos a Empresas Contratistas o Subcontratistas domiciliadas o no en el país, por la ejecución de obras o de la prestación de servicios en base a valuaciones y ordenes de pago (PJD)'),
(56, 'Pagos a Empresas Contratistas o Subcontratistas domiciliadas o no en el país, por la ejecución de obras o de la prestación de servicios en base a valuaciones y ordenes de pago (PJND)'),
(57, 'Pagos a los Arrendadores de los bienes inmuebles a los Arrendadores de los bienes inmuebles situados en el país (PNR)'),
(58, 'Pagos a los Arrendadores de los bienes inmuebles a los Arrendadores de los bienes inmuebles situados en el país (PNNR)'),
(59, 'Pagos a los Arrendadores de los bienes inmuebles a los Arrendadores de los bienes inmuebles situados en el país (PJD)'),
(60, 'Pagos a los Arrendadores de los bienes inmuebles a los Arrendadores de los bienes inmuebles situados en el país (PJND)'),
(61, 'Cánones de Arrendamientos de Bienes Muebles situados en el país (PNR)'),
(62, 'Cánones de Arrendamientos de Bienes Muebles situados en el país (PNNR)'),
(63, 'Cánones de Arrendamientos de Bienes Muebles situados en el país (PJD)'),
(64, 'Cánones de Arrendamientos de Bienes Muebles situados en el país (PJND)'),
(65, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito o Consumo por la Venta de Bienes y servicios, o cualquier otro concepto (PNR)'),
(66, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito o Consumo por la Venta de Bienes y servicios, o cualquier otro concepto (PNNR)'),
(67, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito o Consumo por la Venta de Bienes y servicios, o cualquier otro concepto (PJD)'),
(68, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito o Consumo por la Venta de Bienes y servicios, o cualquier otro concepto (PJND)'),
(69, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito por la venta de gasolina en las Estaciones de Servicios (PNR)'),
(70, 'Pagos de las Empresas Emisoras de Tarjetas de Crédito por la venta de gasolina en las Estaciones de Servicios (PJD)'),
(71, 'Pagos por Gastos de Transporte conformados por Fletes (PNR)'),
(72, 'Pagos por Gastos de Transporte conformados por Fletes (PJD)'),
(73, 'Pagos de las Empresas de Seguro, las Sociedades de Corretaje de Seguros y las Empresas de Reaseguros por las Prestaciones de Servicios que le son propios (PNR'),
(74, 'Pagos de las Empresas de Seguro, las Sociedades de Corretaje de Seguros y las Empresas de Reaseguros por las Prestaciones de Servicios que le son propios (PJD)'),
(75, 'Pagos de las Empresas de Seguro a sus Contratistas por la Reparación de Daños sufridos de sus Asegurados (PNR)'),
(76, 'Pagos de las Empresas de Seguro a sus Contratistas por la Reparación de Daños sufridos de sus Asegurados (PJD)'),
(77, 'Pagos de las Empresas de Seguros a Clínicas, Hospitales y/o Centros de Salud por la Atención Medica a sus Asegurados (PNR)'),
(78, 'Pagos de las Empresas de Seguros a Clínicas, Hospitales y/o Centros de Salud por la Atención Medica a sus Asegurados (PJD)'),
(79, 'Cantidades que se paguen por adquisición de Fondos de Comercio situados en el país (PNR)'),
(80, 'Cantidades que se paguen por adquisición de Fondos de Comercio situados en el país (PNNR)'),
(81, 'Cantidades que se paguen por adquisición de Fondos de Comercio situados en el país (PJD'),
(82, 'Cantidades que se paguen por adquisición de Fondos de Comercio situados en el país (PJND)'),
(83, 'Pagos por Servicios de Publicidad y Propaganda y la Cesión de la Venta de Espacios para tales fines (PNR)'),
(84, 'Pagos por Servicios de Publicidad y Propaganda y la Cesión de la Venta de Espacios para tales fines (PJD)'),
(85, 'Pagos por Servicios de Publicidad y Propaganda y la Cesión de la Venta de Espacios para tales fines (PJND)'),
(86, 'Pagos por Servicios de Publicidad y Propaganda y la Cesión de la Venta de Espacios para tales fines a Emisoras de Radio (PJD)');

--
-- Índices para tablas volcadas
--

--
-- Indices de la tabla `seniat_codigo_concepto_retencion_islr`
--
ALTER TABLE `seniat_codigo_concepto_retencion_islr`
ADD PRIMARY KEY (`codigo`);

--
-- AUTO_INCREMENT de las tablas volcadas
--

--
-- AUTO_INCREMENT de la tabla `seniat_codigo_concepto_retencion_islr`
--
ALTER TABLE `seniat_codigo_concepto_retencion_islr`
MODIFY `codigo` tinyint(4) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=87;
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

&nbsp;

Una vez hallamos creado esta tabla en nuestra base de datos nos valemos de dos archivos para conectar a ella y obtener mediante el identificador único de cada causal. Nosotros utilizamos una variable numérica autoincrementada, pero bien sabemos que los verdaderos causales son tipo cadena con ceros a la izquierda como relleno hasta completar una longitud de tres caracteres, así que recuerden hacer una función que realizar este ajuste de número a cadena de texto(y viceversa para consultar la base de datos, de cadena de texto a número).

El archivo principal que va a recibir una consulta tipo GET es el siguiente:


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
&lt;?php
  if ( $_GET['causal'] !='' )
   {
   // conectar($servidor , $usuario, $contra, $basedato) ¡usen sus propios valores!
   include("seniat-islr-conectar.php");
   $link=conectar( "localhost", $usuario, $contra, "ks7000ne_seniat-islr");

   if ( $_GET['causal'] !='' )
   {
   // conectar($servidor , $usuario, $contra, $basedato) ¡usen sus propios valores!
   include("seniat-islr-conectar.php");
   $link=conectar( "localhost", $usuario, $contra, "ks7000ne_seniat-islr");

   if ( !$link )
     {
       echo "ERROR Fallo la funcion conectar(ks7000ne_seniat).&lt;br&gt;";
     }

   if ( $link )
     {
       $sql = "SELECT * FROM `seniat_codigo_concepto_retencion_islr` WHERE `codigo` = ".$_GET['causal'].";";
       $result = mysql_query($sql, $link);

   if (!$result)
     {
       echo "ERROR Fallo la consulta de datos.&lt;br&gt;";
     }

   if ($result)
     {
       while($row = mysql_fetch_array($result))
         {
           printf(" %s ", $row['concepto'] );
         }
      mysql_free_result($result);
      mysql_close($link);
      }
    }
  }
?&gt;

Nos valemos de la siguiente función para conectar a la base de datos (nos gusta obtener siempre un mensaje para saber donde ocurre una excepción, de haberla):


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
&lt;?php
 function conectar($servidor , $usuario, $contra, $basedato){
   if (!($link=mysql_connect($servidor, $usuario, $contra)))
     {
       echo "Error conectando a la base de datos.&lt;br&gt;";
       return 0;
       //exit();
     }
   if (!($seleccion=mysql_select_db( $basedato, $link)))
     {
       echo "Error seleccionando la base de datos.&lt;br&gt;";
       return 0;
       //exit();
     }
   return $link;
   }
 ?&gt;

Así podemos consultar, por ejemplo, el código 77, de esta manera, prueben:

http://www.ks7000.net.ve/wp-content/uploads/2017/06/seniat-islr.php?causal=77

Seguimos

 

Fuentes consultadas (todas en castellano).

Copias de documentos almacenados en esta vuestra página web.

Marp a primera vista

Nos empeñamos en realizar tutoriales pero en este caso vamos a realizar una simple revisión a un software novísimo: Marp. Esta entrada viene a colación por un “tuit” del sr. Aitor León desde Sevilla, España donde hace un autorecordatorio sobre un software del cual nosotros no habíamos escuchado antes y que nos llamó la atención porque le aplicó la etiqueta #MarkDown:

Nosotros con mucho respeto le preguntamos qué era ese programa y amablemente nos respondió:

Ni tardo ni perezosos indagamos y he aquí lo que pudimos aprender, lo cual humildemente compartimos con el mundo entero de habla castellana.

Inicio y desarrollo de Marp.

Un paso para comenzar.

Ya bien dice el refrán que todo viaje, por muy largo que sea, comienza con un solo paso: el 11 de febrero de 2016 (hace una gran cantidad de tiempo en términos de ordenador japonés) se escribió el comienzo de Marp, el cual originalmente se llamaba MDSlide en su versión 0.0.1.

1
2
3
4
5
6
7
{
"name": "mdslide",
- "version": "0.0.0",
+ "version": "0.0.1",
"description": "Presentation writer with markdown",
"main": "main.js",
"scripts": {

Desarrollo: nace Marp.

En mayo de 2016, luego de duro trabajo, MDSlide se transforma en Marp y la numeración de versiones correlativo corresponde a V0.0.6; al cambiar de nombre nace un repositorio nuevo y de MDSlide no quedan rastros… dice uno porque bien sabemos que el protocolo Git es distribuido y por ahí en algún disco fijo debe haber una copia, je, je, je. El logotipo es el ahora conocido y la verdad ya estaba bastante maduro: soporte para emoji, ecuaciones matemáticas (eso nos impresiona) e imágenes (recordad que se basa en MarkDown: se trabaja con teclado).

Ruta de trabajo.

Para octubre de 2016 se retoma el desarrollo debido a que escuchando las sugerencias de los usuarios se replantea todo y liberan la versión 0.0.9 y se declara un plan de trabajo para liberar la tan ansiada versión 1.0 . También debemos tomar en cuenta que Electron, el entorno de programación utilizado, también ha sido actualizado y eso “empuja” a Marp en cierta medida y a pesar de suficientes “pull requests” (copias del código fuente modificado por terceros que lo devuelven mejorado y/o con sugencias) que recibe el sr. Hattori, él ratifica que sigue en las riendas del proyecto y espera mejorarlo mucho gracias a sus usuarios y colaboradores. Pero en este punto reconoce que el modo de presentación es la parte más difícil y es algo que aún no han logrado pulir, pues es esa la característica que estuvimos buscando nosotros y no vemos por ningún lado (más adelante mostraremos su uso con ejemplos en castellano). La “discusión” es viva y candente (en inglés) e incluso se le llega a comparar con software privativo que lleva décadas en el mercado.

Última versión a la fecha de escribir este artículo.

En noviembre de 2016 liberan la versión 0.0.1 que es la versión que descargamos y probamos pero al abrirlo nos encontramos con una versión compilada a lenguaje de máquina y con una extraña versión 1.3.8 ¿En qué momento nos perdimos… de algo? De todos modos no especulemos nada aún, en la parte del licenciamiento veremos bien si realmente es “software libre” o de “fuente abierta”.

Autoría.

Así nació Marp de las manos del Ingeniero de Software Web Yuki Hattori, graduado en « 公立はこだて未来大学 » (“Public Hakodate Future University”) y quien actualmente trabaja en la empresa “Speee, Inc.” en Tokio, Japón.

Ingeniero Yuki Hattori
Ingeniero Yuki Hattori

El Ingeniero Hattori maneja una gran cantidad de lenguajes de programación (vamos que desayuna PHP, merienda con CSS, almuerza con Ruby, la merienda de la tarde la pasa con Node y cena con Rails) y nosotros que pensábamos que algo programamos, pues nos quedamos cortos (44% en otros lenguajes de programación ¿cuáles serán? Acá hace algo con SVG dinámico y en este enlace lo podéis probar y modificar cortesía de Phil Maurer).

Yuki Hattori lenguajes de programación más utilizados
Yuki Hattori lenguajes de programación más utilizados

Licencia de uso.

El repositorio oficial de Marp lo podéis encontrar en este enlace, y de sus múltiples secciones hemos leído y analizado la información para el presente artículo, esparamos os sea útil en algún modo.

En junio de 2016 el proyecto tiene un mes con su nombre actual Marp y deciden colocar correctamente la licencia de uso que corresponde a la del Instituto Tecnológico de Massachusetts (MIT) la cual no puede ser un simple enlace web, se debe colocar el encabezado con el año y el nombre del autor para luego copiar fielmente la licencia de uso del MIT y luego, si se quiere, el enlace web correspondiente.

De hecho múltiples organismos conservan una copia de dicha licencia y la más socorrida es la de “The Open Source Initiative”; vale la pena recordar entonces que una cosa es software libre y otra cosa es código fuente abierto: para no ser puristas el software libre es más antiguo y solo tiene 4 reglas básicas (aunque ha evolucionado) y el código fuente abierto deriva su filosofía del software libre y tiene 10 reglas básicas.

En julio de 2016 se reconoce que el proyecto contiene un trabajo realizado con anterioridad y que también posee licencia de uso del MIT: Katex el cual está escrito en JavaScript y CSS para representar gráficamente las tediosas fórmulas matemáticas. Nosotros que estudiamos ingeniería mecánica y nos tocó estudiar matemáticas avanzadas damos fe del tremendo trabajo de presentar informes y no tener un software adecuado para ello. Da un poco de vergüenza decirlo pero era rapídisimo realizarlo de forma manuscrita y presentable en hojas blancas que lo horroroso que quedaban con las impresoras de matríz de punto y el software que disponíamos. Hemos progresado hasta el punto que hoy tenemos presentaciones en un lenguaje de marcación ligero y sencillo, que puede representar las matemáticas como son ¡y de paso se puede exportar a formato pdf, increíble!

En este mismo mes se decide retirar el anuncio de licencia de uso de underscore.js ya que no se sigue utilizando como componente.

Página web oficial de Marp.

En este enlace se tiene una presentación bien cuidada acerca del software y orientada a los usuarios normales, no programadores. Podemos ver su características, un enlace al repositorio, un enlace para descargarlo, una rápida introducción a su uso, una guía a ejemplos más avanzados y una declaratoria de licencia de uso. Lo que nos llama poderosamente nuestra atención es la inserción de dos objetos web que presentan por diapositivas a Marp, dichos objetos fueron hechos en Deckset -software hecho en Alemania-el cual está también basado en MarkDown… ¿casualidad? Bueno acá el software de fuente abierta supera al privativo, pues no exporta en formato pdf… y podremos agregarle funcionalidades que consideremos haciendole un “fork” y haciendo nuestro propio proyecto (conservando la licencia de uso del MIT, por supuesto).

“Instalando” Marp.

Pues que si llamamos “instalar” a descargar un archivo y descomprimirlo, vale, “cuela” como instalación. Esta entrada no es tan compleja como otras que hemos hecho que analizamos lo más a fondo que podemos su código fuente, pero no os preocupéis, no perderemos de vista a Marp en el futuro. Repetimos, el repositorio está en esta dirección.

Usando Marp.

Pilares fundamentales de Marp.

  • Escribimos en MarkDown las presentaciones (y también podemos ver el resultado del MarkDown).
  • Se pueden escoger temas y fondos de pantalla para las presentaciones.
  • Soporta caracteres UNICODE (mejor conocidos como emojis).
  • Se puden escribir ecuaciones matemáticas con hermoso estilo.
  • Se puede exportar a formato PDF.

Haciendo presentaciones en MarkDown.

Retrospectiva.

Admitámoslo: realizar presentaciones es tedioso para los que no tenemos el talento para los gráficos. Somos empedernidos usuarios de la ventana terminal y por eso nos agrada mucho el MarkDown y su simple sintaxis para obetener una apariencia básica del HTML… ¡Pero esperen, hay más!

Desde que Github popularizara el Git con su alojamiento gratuito para proyectos públicos (que de acuerdo a la licencia de uso que tengan tendrán diferentes clasificaciones) y agregaron el uso de MarkDown acompañando a los repositorios con su respectiva sección Wiki, que también utiliza cierto “sabor” de MarkDown, y ahora con una ligera variante podremos hacer presentaciones rápidamente sobre nuestro trabajo ya hecho pues… ¡BINGO! 🙌😎

Hala, manos a la obra.

Aunque entre las carpetas descomprimidas hay una llamada “locales” hay un archivo llamado es.pak cuyo contenido abrimos con gedit y está escrito en castellano, no hallamos opción para cambiar el idioma inglés. Revisando el código fuente no hallamos referencia a dichos archivos .pak (hay bastantes idiomas) lo que imaginamos es que son “paquetes”  o plantillas que se utilizan masivamente para internacionalizar nuestras aplicaciones… o simplemente será nuestra imaginación.

Dicho todo esto, os escribiremos en inglés las referencias que hagamos al programa Marp.

No nos afanéis buscando teclas de acceso directo -para hacer cualquier cosa- excepto las siguientes:

CTRL+NNew fileFichero nuevo
CTRL+OOpen...Abrir un fichero
CTRL+SSaveGuardar fichero
Mayús+CTRL+EExport slides as PDFExportar presentaciones a formato PDF
CTRL+WCloseCerrar programa
CTRL+ZUndoDeshacer acción
Mayús+CTRL+ZRedoRehacer acción
CTRL+XCutCortar selección
CTRL+CCopyCopiar selección
CTRL+VPastePegar selección
CTRL+ASelect allSeleccionar todo
F11Toggle full screenCambiar a pantalla completa

Marp, como es de esperarse, utiliza la misma extensión de fichero de los documentos MarkDown: .md (tal vez presentemos algún vahído porque estamos bien acostumbrados a que las presentaciones tienen sus propias extensiones según el software que las manipule).

Lo primero es abrir un archivo nuevo, vamos al menú desplegable “File” -> “New file” (o pulsamos las teclas CTRL+N). Sin más preámbulo se abre un “lienzo” de trabajo presto a escribir en el. En este lienzo a la izquierda escribimos nuestro código y a la derecha veremos inmediatamente nuestro trabajo de tres maneras distintas:

  • En modo de presentación, diapositiva por diapositiva (modo por defecto).
  • En modo de presentación, diapositivas en hilo o “carrousel”.
  • En modo MarkDown, tal como se vería al publicarla en la página web de GitHub, por ejemplo (¡interesante!).

Títulos y subtítulos.

Inician con un símbolo numeral “#” seguido de un espacio y el texto para título principal y agregando dos o más numerales juntos -sin espacios- los subtítulos correspondientes (hasta un máximo de seis subniveles):

Marp títulos y subtítulos.
Marp títulos y subtítulos.

Nota 1: Marp como buen intérprete del MarkDown “original” soporta el uso de “=” y “-” (uno o más) en la línea inmediatamente inferior del texto para mostrar un encabezado de primer y segundo nivel. Pero si necesitamos de un  tercer nivel necesitaremos tres numerales “###”… así que no vale la pena este método os aseguro.

Nota 2: Marp aplica a las imágenes un “realzamiento” su utilizamos numeral (es) delante de la declaración de imágenes, sin embargo “=” y “-” no funcionan en estos casos (no le busquen lógica a esto, por favor, no sabemos si es un “bug” o es algo hecho a propósito).

Realizando una segunda diapositiva.

Como véis el código MarkDown funciona y no es obejtivo de esta entrada mostraros su sintaxis por lo tanto vamos a enfocarnos en los comandos propios de Marp, que son apartes del MarkDown con el propósito de presentar nuestras diapositivas.

Tal como insertamos una línea horizontal en Markdown (tres guiones seguidos al principio de una línea) así agregaremos una segunda diapositiva, cuidando de dejar una línea en blanco antes y después:

Marp inserción de nueva diapositiva
Marp inserción de nueva diapositiva

Enumerando las diapositivas.

Para agregar el número de diapositiva en la esquina inferior derecha solo debemos agregar el siguiente código.

<!-- page_number: true -->

A partir de la diapositiva donde insertemos la orden serán numeradas hasta el final, si queremos que todas están numeradas la posicionaremos en la primera diapositiva; por el contrario, si queremos que una diapositiva en particular NO sea numerada modificaremos la directiva anterior agregandole un asterisco para indicar que se le aplique solo a esa diapositiva. Por supuesto, usaremos el valor verdadero o falso a nuestro gusto o necesidad.

Marp numeración de diapositivas
Marp numeración de diapositivas

Directivas globales y directivas locales.

Lo que acabáis de ver “encerradas” entre comentarios tipo HTML “<!— comentario —>” por supuesto no se visualizan en nigún navegador o intérprete de MarkDown sin embargo Marp obtiene sus instrucciones de allí en el formato de una instrucción por línea separadas por dos puntos “:”. Dichas instrucciones son llamadas directivas y como vimos serán globales -para todas las diapositivas, el documento completo- o solo para la diapositiva donde se encuentre la directiva que establezcamos siempre y cuando sean antecedidas por un asterisco.

Dado el caso que nos equivoquemos en la sintaxis pues simplemente Marp no las toma en cuenta ni ejecuta y no arroja ningún tipo de mensaje de excepción.

Directiva “$theme” y “template”.

Marp soporta plantillas predeterminadas para nosotros dedicarnos a lo valioso de escribir los datos en las diapositivas, lo demás son “adornos de repostería”. Al momento de escribir esto estaba disponible el tema gaia y de manera adicional con la directiva template:invert se tiene una inversión en los colores. Esto queda guardado en el documento de diapositivas para que Marp automáticamente la muestre al volver abrir el documento. Nota: si por el menú desplegable escogemos “View”->”Theme”->”default” -o cualquier otro tema que haya disponible- Marp obviará la directiva que hayamos establecida dentro de la diapositiva y mostrará la que le hayamos ordenado. Verbigracia:

Marp directiva theme y template
Marp directiva theme y template

Marp directiva “footer”.

Con esta directiva podremos establecer una frase en pie de página ya sea en todas las diapositivas o solo en la que le coloquemos la directiva, recordad el asterisco hace a la directiva local, mirad:

Marp directiva footer
Marp directiva footer

Directiva $size

Esta directiva puede ser confusa porque se refiere a tamaño sin embargo presenta también unos valores que indican proporción pero si buscamos la lógica ambas son excluyentes mutuas y explicamos por qué: todo depende si nuestra presentación será por pantalla (primera opción para el 99% de los casos, vamos que hablamos de presentaciones por diapositivas). El otro asunto es si necesitamos imprimir dichas presentaciones.

  • Para la proporción tenemos “4:3” predeterminado para monitores normales y la mayoría de proyectores traen este valor por defecto y “16:9” para monitores “multimedia” -llamados así porque las películas son grabadas en esa proporción panorámica-.
  • Para el tamaño  de papel tenemos desde A0 hasta A8 y B0 hasta B8, os adelantamos que el “tamaño carta” viene a ser A4 (mirad abajo en las fuentes consultadas el resto de los medidas de papel).
  • Por los dos puntos anteriores es que decimos que son mutuamente excluyentes.
  • Esta directiva solamente es global, recomendamos declararla al principio para un orden efectivo (hicimos pruebas y el asterisco lo que hace es inutlizarla).
  • Es indiferente que usemos mayúsculas o minúsculas en los tamaños de papel.
  • Marp lee de izquierda a derecha y el primer tamaño válido de papel o proporción lo aplica, el resto de los caracteres lo desecha (debería NO aplicar el formato o al menos indicar la excepción, pensamos).
  • No conseguimos hacer funcionar el prefijo documentado “-portrait”, recordad que aún es un software en desarrollo y sus gazapos tendrá.
Marp directiva $size
Marp directiva $size

Directivas $width y $height.

De necesitar un tamaño personalizado de papel, estas dos directivas son las adecuadas al caso y ambas heredan todo de la directiva $size por ello no os ponemos gif animado aunque si os podemos decir que si que funciona (¡vamos, animaros a descargar y probar Marp!) y las opciones disponibles son:

  • px: píxeles por defecto, no es necesario colocarle “px”.
  • Por la razón anterior las siguientes unidades debéis colocarla juntitas sin espacio(o)s o si no lo interpretará como píxeles.
  • cm: centímetros.
  • mm: milímetros.
  • in: pulgadas “inches”.
  • pt: puntos.
  • pc: picas.

En realidad dichas unidades son las utilizadas por CSS excepto em (tamaño de fuente) y “%”; abajo en “Fuentes consultadas” (en idioma portugués) tenéis un enlace si queréis aprender más por vuestra cuenta.

Directiva “$prerender”.

Antes de entrar de lleno con las imágenes os presentamos esta directiva especialmente hecha para indicarle a Marp que haga un preproceso de las imágenes de fondo en el caso de que éstas sean muy grandes, aligera el proceso con una carga previa de datos.

<!– prerender: true –>

Comando para mostrar imágenes.

Así como lo leeís, ya finalizamos las directivas y volvemos a los comandos de MarkDown en este caso os indicamos lo siguiente:

  • Para comenzar a insertar una imagen comenza por una línea en blanco donde colocareís ![]( “”) tal cual, incluyendo los paréntesis, son 8 caracteres en total.
  • Dentro de los corchetes rectos (paréntesis rectos) colocaréis el texto alterno si no se puede cargar la imagen, podéis dejarlo vacío pero el uso de los corchetes es obligatorio, de lo contrario no muestra imagen alguna.
  • Dentro de los paréntesis (curvos) pero fuera de las comillas dobles el nombre del fichero de la imagen (si reside en la misma carpeta de donde ejecutásteis Marp o una URL válida, local o internet).
  • La razón de utilizar una imagen desde internet es para mostrar los últimos valores o cifras relacionados con el tema de la presentación, de lo contrario llevad tus imágenes junto con el documento Marp
  • Entre la URL de la imagen y las comillas dobles debéis dejar un espacio -el mismo que consideramos al principio en el conjunto de 8 caracteres iniciales de declaración.
  • Dentro de las comillas dobles -que sí son opcionales- podemos colocar una breve descripción acerca de la imagen o una frase nemotécnica que podramos visualizar al pasar el puntero por encima de la imágen, tras lo cual al cabo de menos de un segundo se colocará una pequeña ventanita en blanco sobre negro con el texto que coloquemos.
Comando para mostrar imágenes de fondo.

Muchas personas querrán, en vez de utilizar o crear tema alguno, simplemente fijar una o más imágenes como fondo en las presentaciones. He aquí que Marp se toma la ligera licencia de tomar la sintaxis de las imágenes -en MarkDown– con la excepción que en los corchetes rectos colocamos el comando [bg]  y por supuesto la URL local o remota de la imagen en sí. Dentro de los corchetes rectos acompañando a “bg” más un espacio podemos colocar un procentaje para redimensionar la imagen e incluso podemos colcoar varias imágenes siempre y cuando los porcentajes sumen 100% para garantizar visibilidad completa de cada imagen. El comando “bg” no soporta mayúsculas, disfrutad nuestras pruebas:

Marp fondo de diapositiva
Marp fondo de diapositiva
Comandos para mostrar caracteres emoji.

Si se sorprenden por haber colocado los emoji como subsección de las imágenes preparaos a recibir una historia bien larga… vamos a tratar de resumirla lo mejor posible.

Por allá en los años ochenta cuando nosotros comenzamos a manipular computadoras y luego entramos a estudiar en la Universidad de Carabobo… ¡EA, ¿PARA DÓNDE VAÍS, QUEDAROS Y ESCUCHAD! 😈

…👴 os contábamos que apenas teníamos computadoras de 16 bits XT y luego vinieron las de 32 bits -286, 386, etc- y en los años 90 se populariza -y hay hardware para manejarlo- el UNICODE que no es más que la representación codificada y gráfica -dibujada con papel y lápiz- de unos 65 mil y pico de caracteres- de la mayor parte de los alfabetos ideados por la humanidad. Allí se tuvo previsión de crear unos símbolos que representaban caras con diferentes estados de ánimo y objetos comunes, el gran problema era dibujarlos por pantalla Y ESO AÚN HOY EN DÍA ES DIFÍCIL DE HACERLO ¿por qué decimos esto?

Está bien, los sistemas operativos modernos manejan los códigos extendidos de UNICODE, con tan “poderosos” aparatos que tenemos faltaba más, faltaba menos. Pero a nivel de hardware, de tarjeta madre, aún no hemos visto que tengan dicho UNICODE grabado en firmware, los asiáticos han hecho hermosos BIOS gráficos pero que en realidad lo que hacen es cargar en memoria un mini sistema operativo con interfaz gráfica para su idiomas basados en ideogramas: AÚN NO SUCEDE QUE EL CPU ENVIE A UN MONITOR CUALQUIERA EL CÓDIGO BINARIO DE UN CARACTER UNICODE (EXTENDIDO) Y EL MONITOR TENGA “MEMORIA” PARA SABER COMO SE DIBUJA ¿Nos seguís el hilo? {Nota: todo monitor e impresora de matriz de puntos tiene en memoria cómo dibujar los 255 caracteres ASCII originales, pero hasta allí llegan, e incluso las impresoras a inyección de tinta y láser ¡perdieron esa capacidad!}.

Más aún, la genialidad de Steve Jobs, el fundador de Apple Computer -hoy la empresa más poderosa del mundo, incluso por encima de Microsoft e IBM juntas- fue el poner en práctica el trabajo desarrollado por Xerox Palo Alto (empresa aliada mutua con Apple) de fuentes tipográficas: pequeñísimas imágenes que computadoras con la suficiente potencia pueden dibujar rápidamente en pantalla imágenes que nosotros identificamos como “letras”… ¿y todo este discurso para qué? 😕

Todo este discurso es para deciros que aún los sistemas operativos modernos NO POSEEN soporte nativo y por ende los navegadores web tienen que obtener de algún lado esas pequeñísimas imágenes que nosotros lamamos “letras” o,  para este caso, emoticons.

Repetimos, lo simplificamos lo más que pudimos, en serio, no somos licenciados en computación pero como nos tocó vivir esa experiencia en carne propia, la evolución de los ordenadores (y escribimos, que algo queda para la posteridad de las generacioens futuras) pero a ese nivel da este tema.

Volviendo al tema de los emoticons o emoticones para castellanizar el término, revisamos el código fuente de Marp y observamos que utiliza dentro de sus dependencias (a esto nosotros lo llamamos librerías dinámicas) algo llamado markdown-it-emojiy a su vez buscamos en el código fuente de ese software unos “comandos” que permitan especificar los emoji en Marp.

Para Marp un emoticon o emoji viene encerrado entre par de dos puntos “: :” y dentro, sin espacios viene la palabra clave con la cual se busca y se dibuja (imaginamos que al compilar Marp todas esas imágenes vienen a nuestro disco duro en el fichero ejecutable luego investigamos y nos dimos cuenta que a este proceso ELECTRON lo llama “Application Distribution“, con el archivo app.asar del cual podrán saber y entender su forma de almacenar la información en su propio repositorio).🤔

Ya para finalizar el tema de Marp y los emoticones, esos comandos o palabras claves (que no trae documentados cuántos ni cuales son) que os dijimos, los copiamos, encerramos entre “: :” y los pegamos en Marp para producir la siguiente captura (otra nota: los emoticones se ven afectados en tamaño si están precedidos como título “#”, notad eso):

Marb emoticon emoji
Marb emoticon emoji
:angry::blush::broken_heart:
:confused::cry::frowning:
:heart::imp::innocent:

---

:joy::kissing::laughing:
:neutral_face::open_mouth::rage:

---

:smile::smiley::smiling_imp:
:sob::stuck_out_tongue::sunglasses:

---

:sweat::sweat_smile::unamused:
# 😉

<!---
$size: A8
--->

Podéis obtener una lista ampliada, nemotécnica, en este enlace cuyo encabezado anuncia las páginas web y/o aplicaciones que utilizan esos emoji. Por ejemplo :cat: es más fácil de memorizar que U1F408, caracter unicode, y que funciona sin problemas con Marp. En dicha página hacéis click en el emoji que os guste y es copaido la palabra clave con su par de dos puntos, y pegáis en MArp. Un código que no veréis es el de GitHub :octocat: (combinación de pulpo con gato) así que no es una lista definitiva, por ahora.


Nota “final” sobre el tema🤓: estos emoticones que véis son los de WordPress, que Twitter tiene los suyos propios (acá está cómo enlazar el CDN a vuestras páginas web y/o aplicaciones web y acá un ejemplo de vista previa de las imágenes obtenidas que por curiosa coincidencia son los mismos del mapa de caracteres de Ubuntu 🤖 je, je, je)

 


Actualizado el domingo 11 de junio de 2017.

Una lista completa de los códigos nemotécnicos de Marp los encontraréis en esta dirección: https://github.com/markdown-it/markdown-it-emoji/blob/6a65f5183fe0145219805040988341bf76ade32e/lib/data/full.json

Ofrecemos disculpas por no haber investigado lo suficiente. Esa sí es una lista completa de los caracteres emoji y soportados por Marp porque forma parte de sus componentes y compilación.


Enlaces web.

Los enlaces web o hipervínculos en Marp los podemos declarar de forma implícita y explícita (forma recomendada):

  • De manera implícita: si escribís “http://” más un caracter cualquiera, Marp lo convierte de inmediato en un enlace a la derecha en la ventana de visualización. También cuela “www.” más al menos dos caracteres.
  • De forma explícita: como dicta el MarkDown: un par de corchetes rectos (opcionales) donde colocaremos el texto del enlace y un par de paréntesis (curvos) donde colocaremos el enlace web en sí mismo.
Marp enlaces web
Marp enlaces web

Antes de hablar de las ecuaciones matemáticas…

…debemos indicaros que si necesitamos mostrar el código fuente en MarkDown a nuestra audiencia debemos encerrarlas entre triple comillas simples y Marp los interpretará como texto simple, es decir, no lo “ejecutará”, no hará “parser”.

Marp mostrar código MarkDown a la audiencia
Marp mostrar código MarkDown a la audiencia

Ecuaciones matemáticas.

Y acá lo que nos apasiona de tanto en tanto: las matemáticas, especialment el cálculo infinitesimal. Para ello Marp tiene un suplemento que debemos ingresar entre par de símbolos de pesos (o lo que sería con el paso del tiempo como símbolo de dólar). Cualquier texto que escribamos lo representa tal cual pero si lo antecedemos de cierta sintaxis comenzaremos a escribir nuestras fórmulas (no os preocupéis, no nos extenderemos mucho a favor de vuestra paciencia).

Fórmula de Euler.
  • Claro, cualquier texto lo representa tal cual…
  • … pero si lo antecedemos con un “_” tendremos un subíndice.
  • Con “^” lo convertiremos en superíndice.
  • Para agrupar estos subíndices o superíndices los encerramos entre llaves “{}”
  • Para multiplicar términos: “\cdot”.
  • A “\cdot” le podemos agregar paréntesis para agrupar más términos.
  • Para mostrar tres puntos suspensivos: “\cdots”.
  • ¡También podemos combinar “\cdots()”!
  • Ya con esto podremos representar la famosa fórmula de Euler:
Marp formula de Euler
Marp formula de Euler

Nota: cada fórmula matemática debe ocupar una o más líneas completas, no podemos intercalar fórmulas en una línea, por ejemplo. Opinamos que debería hacerlo y hasta podemos clonar el repositorio y empezar a programar, para eso es el software libre.

Identidad de Euler.
Marp identidad de Euler
Marp identidad de Euler

Símbolos y signos.

Es una lista larga, larguísima como la matemática misma pero los más comunes símbolos matemáticos tienen sus propios códigos:

  • Para representar 𝛑 usamos “\pi”.
  • Para representar 𝚽: “\phi”-
  • Para 𝛉: “\theta”
  • Infinito: “\infty”.

Operadores matemáticos simples y avanzados:

  • División: “\div”.
  • Fracción: “\frac{}” -colocamos el numerador entre llaves y el denominador a continuación.
  • Sumatoria: “\sum” -la podemos combinar con superíndices y subíndices.
  • Raíz cuadrada: “\sqrt” más el número -o llaves, o paréntesis.
  • Paréntesis grandes, ideales para encerrar fracciones: “\Bigl(” y “\Bigl)”.
  • Para representar integrales simples: “\int”, dobles “\iint”, triples “\iiint”, integral de superficie “\oint”.

Fórmula de cálculo de la constante e.

Marp cálculo de constante e
Marp cálculo de constante e

Exportar a formato PDF.

Probamos la exportación de archivos a formato PDF y no tuvimos ningún tipo de problema, si acaso un detalle que “no recuerda” los últimos archivos abiertos o guardados, “archivos recientes” les decimos. Incluso los emoticones fueron exportados y hermosamente dibujados -claro si originalmente fueron hechos en SVG nunca pierde calidad alguna al “pasar” de un lado a otro.

Conclusiones.

El software se ve realmente prometedor y aunque tiene la opción F11 pra verlo a pantalla completa no es lo mismo que un programa de presentación que se precie como tal: debe ser capaz no solo de usar las flechas de dirección del teclado para avanzar diapositivas sino que le falta aún programador de tiempo, música y lo más importante, ser capaz de detectar -y escoger- los múltiples monitores y/o proyectores que tengamos conectados a nuestro ordenador.

Esperamos os haya sido útil este vuestro -y nuestro- trabajo para la ampliación de conocimientos y saberes. 😉

Fuentes consultadas:

En idioma castellano:

En idioma inglés:

En idioma portugués:

En idioma japonés (nos disculpáis cualquier “fe de errata” al traducir):

PHP Simple HTML DOM Parser

Para abrir el mes de junio seguimos el hilo en nuestros artículos que buscan difundir el conocimiento libre del Patrimonio Tecnológico de la Humanidad. En anterior oportunidad estudiamos PHP curl, una herramienta basada en cURL y por ende en libcurl (¡ea, esto último no lo mencionamos allá!). Como en ese caso obtuvimos un método para descargar páginas web enteras, incluso si hay que pasarle datos con el método POST y/o hay que introducir usuario y contraseña. Esta entrada busca extraer, analizar e incluso modificar dichos datos ¡vente con nosotros!

PHP Simple HTML DOM Parser.

Presentación.

Buscábamos una “parser” o analizador código HTML y aunque PHP tiene su modelo establecido nos decantamos por algo más fácil pero con el inconveniente que debemos apoyar la licencia de uso del Instituto Tecnológico de Massachusetts (“MIT license”) y que NO viene integrado al lenguaje PHP. Lo bueno es que apenas son 65037 bytes en un archivo con un guion escrito en lenguaje PHP para que funcione (la licencia nos obliga a distribuir completo los archivos de ejemplos y manuales, todos escritos en idioma inglés).

El analizador de HTML (y XML) que veremos y aprenderemos a usar tiene el pomposo nombre de “PHP Simple HTML DOM Parsercon todas las implicaciones que derivan de llamar “simple” al D.O.M. (“Document Object Model”).

Document Object Model.

El Modelo de Objeto Documento es una norma propuesta por el Consorcio World Wide Web o W3C que son quienes hacen las recomendaciones y sientan las bases, de facto, del Web creado por el Doctor Tim Berners-Lee. En dicho papel de trabajo, a nuestro modo de ver las cosas, se propone que una página web es un documento y todo lo que está contenido en ella está representada por nodos. Si nos ponemos a ver tiene sentido porque la norma HTML5 establece unas sub divisiones que a su vez contienen títulos, sub títulos, párrafos, listas, etc.

Este concepto es mucho más amplio porque contempla, aparte de propiedades, también métodos que por definición HTML5 no contempla y para respetar la neutralidad hacen de la vista gorda del JavaScript (¿definirán algún día al CSS para suplantarlo? Sí, los sabemos, nuestro pensamiento siempre es profano).

El DOM está estructurado sobre tres pilares básicos:

  • “Core DOM”: modelo normativo para todos los tipos de documentos.
  • “XML DOM”: para documentos XML (febrero, 1998).
  • “HTML DOM”: no menos importante, aunque aparezca en tercer lugar, para documentos HTML.

Autores.

La idea original proviene de José Solorzano quien comenzó un proyecto bautizado como “HTML Parser for PHP 4” (dale con esto de los nombres largos ¿será que estoy leyendo muchos artículos en inglés y me estoy contagiando? Porque el idioma castellano es bastante prolijo…) que como podemos ver funciona con PHP 4 y pues va a ser que ya está descontinuado (incluso tienen un avisito recomendando el proyecto que vemos hoy acá).

Basado en ello S.C. Chen (me578022@gmail.com) programó una versión actualizada y basada en DOM con ayuda de Yousuke Kumakura y publicada en SourceForge, un alojador de contenido de software de código abierto que alberga más de 430.000 proyectos (3,7 millones de usuarios y 42 millones de clientes). Solo sabemos que S.C Chen es famoso a nivel mundial por su ópera prima que trajimos en este momento a colación.

Core DOM.

(pronto desarrollaremos este tema).

XML DOM.

Para poder entender el HTML DOM debemos primero estudiar y aprender el XML DOM y a continuación haremos nuestro racionamiento y sustento.

Concepto de XML.

“eXtensible Markup Language” o Lenguaje de Marcado Extensible (lo siento por el castellano pero lo seguiremos identificando como XML dado su impacto de facto en el mundo entero) es un lenguaje que “describe” como hacer las cosas y que además se puede ampliar en cualquier momento conservando una retrocompatibilidad. Fue diseñado para almacenar y transportar datos y que, además, pudiera ser leído por ordenadores y humanos por igual.

Si queréis leer sobre nuestra disertación acerca de lo que es un lenguaje de marcado, os invitamos a leer nuestro tutorial en línea sobre HTML. XML es guardado en ficheros codificados, generalmente, en UTF-8 para lograr compatibilidad con los diversos idiomas del mundo, nuestro tutorial sobre HTML5 también habla  y describe al respecto en forma detallada.

Normas XML.

Hay unas normas destacadas que mencionaremos y que a futuro, en la medida que tengamos tiempo para ello, le publicaremos sus diferentes entradas en nuestro humilde blog.

  • XML AJAX
  • XML DOM
  • XML XPath
  • XML XSLT
  • XML XQuery
  • XML DTD
  • XML Schema
  • XML Services

¿Qué es y qué NO es XML?

Aparte de lo que ya definimos, hay otros detalles que decir acerca del XML: fue diseñado para ser autodescriptivo, ya que a diferencia del HTML tiene muy pocos “comandos” o etiquetas y el XML como tal no hace absolutamente nada por sí solo. Esa es entonces la principal diferencia con HTML, que se enfoca en presentar los datos mientras que XML se enfoca en transportar datos.

Decimos que se puede extender ya que nosotros mismo “inventamos” nuestros propias etiquetas, así que no tenemos limitación pero una vez hallamos agregado más etiquetas a una información preexistente ésta seguirá siendo completamente leída y manipulada por distintas aplicaciones sin ningún tipo de problema.

Por supuesto, hacemos la advertencia que hablamos de extender, no de contraer: al eliminar algún dato por supuesto que las aplicaciones ya no podrán realizar su trabajo completo, y en muchos casos se negarán a realizarlo de plano.

Elementos de un documento XML.

Un documento XML está constituido por un elemento raíz el cual tiene elemento ramas o nodos que a su vez pueden contener subelementos y así sucesivamente. Cada elemento a su vez puede contener atributos.

De manera obligatoria un documento XML debe tener un elemento raíz, y aunque un prólogo no es obligatorio ni forma parte del documento es muy recomendable agregarlo; siempre va al principio del documento.

La función del prólogo es denotar la versión XML del documento y, de manera adicional, la codificación de caracteres el cual ya dijimos UTF-8 es lo más recomendable. La sintaxis del prólogo comienza con un símbolo “menor que” o mejor dicho, un corchete angular de apertura, ya que no estamos hablando de matemáticas en este caso (pero ayuda muchísimo a entender el concepto de aperura y cierre). Debe cerrar con un símbolo “mayor que” o corchete angular de cierre. Además de los dos símbolos anteriores se necesitan dos signos de interrogación de cierre y los contenidos deben estar entrecomillados para lo cual recomendamos las comillas simples, esto nos ahorra problemas para cuando vayamos a programar. Veamos un ejemplo de prólogo:

<?xml version='1.0' encoding='UTF-8'?>

El prólogo es un caso especial, y ya dijimos que no forma parte del documento, por lo tanto tiene distintas reglas que las aplicadas a los elementos, los cuales pasamos a describir en la siguiente sección.

Sintaxis de los elementos XML.

  • Cada uno de los elementos debe tener su correspondiente cierre pero con una barra invertida, por ejemplo:
    • <elemento> texto </elemento>
  • Los nombres de los elementos distinguen mayúsculas de minúsculas por lo tanto <elemento> no es igual a <Elemento>.
  • Los nombres de los elementos deben comenzar con una letra o en su defecto con un guion bajo ” _ “.
  • Los nombres de los elementos no pueden comenzar con “XML” o sus combinaciones de mayúsculas y/o minúsculas.
  • Los nombres de los elementos no puden contener espacios (de hecho un espacio denota que comienza un atributo, por eso no pueden contener espacios).
  • Los subelementos deben estar correctamente anidados dentro de los elementos, ejemplo:
    • <elemento><subelemento>valor</subelemento><elemento>
  • Los atributos de los elementos deben estar entrecomillados (lo mismo que dijimo para el prólogo se aplica en este caso), ejemplo:
    • <elemento principal=’si’> dato </elemento>
  • Como tal vez hayan captado, hay unos caracteres especiales en los documentos XML que no podremos usar directamente porque se presta a confusión para los ordenadores a la hora de leer el documento XML por lo tanto debemos sustituirlos por otros caracteres si queremos usarlos como datos:
    • Corchete angular de apertura “<” lo sustituimos por “&lt;” (recordad “lt”= “less than”, menos que).
    • Corchete angular de apertura “>” lo sustituimos por “&gt;“(recordad “gt”= “greater than”, mayor que).
    • Ampersand o “et” (proviene del latín, como en “etcétera”): “&” lo sustituimos por “&amp;“.
    • Apostrofo ” ” lo susituimos por “&apos;“.
    • Comillas dobles ” ” las sustituimos por “&quot;” (“quotation mark”).
  • Si queremos o necesitamos dejar un comentario para nosotros los seres humanos y que sea ignorado por el ordenador hacemos lo mismo que en el lenguaje HTML, lo encerramos entre los siguientes signos:
    • <!– comentario –>
    • Nota: dentro de un comentario no podemos escribir dos guiones juntos ya que dos guiones juntos indican inicio y fin de comentario, así que se prestaría a confusión para los ordenadores.
  • En los documentos XML debemos tener en cuenta que todo espacio es considerado como tal, es decir, los espacios se conservan y son un dato en sí mismo y así será leído ya quedará de parte de la aplicación el cortar o comprimir espacios “innecesarios”. Este comentario lo hacemos porque los documentos XML pueden ser leídos -y editados- por nosotros los humanos y un espacio en blanco mal colocado de nuestra parte hará que la aplicación que va  a leer los datos le suceda una excepción pero nosotros no veamos el error al abrir el archivo nosotros mismos.
  • Parecerá una tontería pero el caracter que indica el final de una línea es el caracter LF o “Line Feed” OSEA al caracter ASCII 10 y debemos tener siempre presente que en el sistema operativo Windows se utiliza LF más CR (ASCII 10 y 13 respectivamente) y en los viejos sistemas operativos Mac solo CR.

Características de los elementos de un documento XML.

  • Un elemento comienza desde el primer corchete angular de apertura hasta el último corchete angualr de cierre.
  • Un elemento puede contener:
    • Nada (pues eso, vacío, ni siquiera un espacio -si tuviera un espacio no sería vacio-).
    • Ya que introducimos el concepto de elemento vacio -y esto debería estar en la sintaxis- un elemento tácitamente vacio lo podremos denotar de la siguiente manera y ambos son iguales y válidos:
      • <elemento />
      • <elemento></elemento>
    • Texto -datos, para los ordenadores-.
    • Otros elementos -recordad anidar correctamente-.
    • Cualquier combinación de los tres anteriores, las combinaciones son infinitas y por ende decimos que son extensibles -y retrocompatibles-.

Una breve aclaratoria sobre los atributos.

Hay que tener especial cuidado con los atributos que le coloquemos a los elementos. Para no caer en abstracciones les haremos un caso práctico: consideremos un elemento llamado “persona” y lo que eso significa para nosotros los castellanohablantes.

<?xml version='1.0' encoding='UTF-8'?>
<persona></persona>

Ahora consideremos colocarle un atributo de género femenino o masculino:

<?xml version='1.0' encoding='UTF-8'?>
<persona sexo='masculino'>
    <nombre>Pedro</nombre>
</persona>
<persona sexo='femenino'>
   <nombre>María</nombre>
</persona>

Como vemos podemos “cargar” en memoria de ordenador solamente los hombres -o las mujeres- pero la aplicación que lee dichoa rchivo debe estar programada, de manera previa, a buscar esos dos géneros solamente ¿Qué sucedería si surgiera un tercer tipo de sexo, como por ejemplo hermafrodita?

<?xml version='1.0' encoding='UTF-8'?>
<persona sexo='masculino'>
    <nombre>Pedro</nombre>
</persona>
<persona sexo='hermafrodita'>
 <nombre>Michelle</nombre>
</persona>
<persona sexo='femenino'>
   <nombre>María</nombre>
</persona>

No habría forma ni manera que la aplicación pudiera “ampliarse” para que leyera datos adicionales ampliados, así que es una mejor idea plantearlo de la siguiente manera:

<?xml version='1.0' encoding='UTF-8'?>
<persona>
    <sexo>masculino</sexo>
    <nombre>Pedro</nombre>
</persona>
<persona>
    <sexo>hermafrodita</sexo>
    <nombre>Michelle</nombre>
</persona>
<persona>
    <sexo>femenino</sexo>
    <nombre>María</nombre>
</persona>

Como veís, colocado de esta manera la aplicación puede ir generando una matriz con los distintos nuevos tipos de valores tal como lo hace con los valores en sí mismos. Aparte de esta ventaja debemos recordar también que los atributos NO pueden contener múltiples valores y tampoco pueden tener estructuras tipo árbol, entonces ¿para que diantres sirven los atributos? Antes de responder esta pregunta queremos dejar en claro algo más sobre los atributos: los atributos son elemento fuertemente tipados -como decimos en los lenguajes de programación-, son estructura rígidas que son difíciles de cambiar a futuro pero que debido a esto podremos tomar ventaja; veamos la siguiente sección.

Eliminando ambigüedades en el nombrado de los elementos.

Como ya bien sabemos los documentos XML nos sirven para almacenar datos y debido a que nosotros los seres humanos asignamos un nombre para todo en nuestro universo -y a medida que lo seguimos descubriendo- no siempre escogemos nombres únicos. Tomemos por caso la palabra “banco”: tal vez primero pensemos en una institución financiera pero es que también un “banco” es un objeto sobre el cual podemos sentarnos.

Si por alguna idea peregrina nos damos a la tarea de guardar datos de ambos conceptos en un mismo documento XML debemos hallar una manera de diferenciarlos para que no haya lugar a dudas. Para ello podemos -y debemos- asignar un prefijo para eliminar cualquier duda, pero ¿qué prefijo usaremos? Pongamos por caso que los bancos -instituciones financieras- le colocamos el prefijo “i:” y los bancos -objetos- los prefijamos con “o:” (notemos que no violan la sintaxis de nombres de elementos ya que comienzan con una letra, no comienzan con “xml” ni contiene espacios):

<?xml version='1.0' encoding='UTF-8'?>
<raíz>
    <i:bancos>
        <i:nombre>Banco de Venezuela</i:nombre>
        <i:nombre>Banco Mercantil</i:nombre>
        <i:nombre>Banco Bicentenario</i:nombre>
    </i:bancos>
    <o:bancos>
        <o:nombre>banco de madera</o:nombre>
        <o:nombre>banco de metal</o:nombre>
        <o:nombre>taburete</o:nombre>
    </o:bancos>
</raíz>

Rapidamente notamos, si fueramos un lector ajeno que recibiera este documento XML, ¿qué diablos significa ambos prefijos, aparte de separarlos sintacticamente? Bien podríamos colocar un comentario para hacer alusión a qué nos referimos (“i:”institución financiera, “o:”obejto), pero eso funciona solo para nosotros los humanos, los ordenadores obvian estas observaciones ¿qué otra solución podemos echar mano?

Espacios de nombres en XML: XMLNS.

Los espacios de nombres (“Name Spaces”) en XML (juntos serían XMLNS) es el concepto para definir los prefijos que querramos usar en cualquier documento XML. Este “Name Spaces” son unos atributos y como tales debemos colocarlos en el elemento “padre” con un valor bajo la forma de URI (Uniform Resource Identifier) que bien puede ser a su vez un URL (Uniform Resource Locator) o un URN (Uniform Resource Name).

Para este nuestro caso vamos a usar el modelo de comentario y el modelo de URL todo esto apuntando siempre a que sea un ser humano el que va a leer la información (y luego veremos el caso de si es un ordenador el que “procesará” la información):

<?xml version='1.0' encoding='UTF-8'?>
<!--
  prefijo 'i:' se refiere a instituciones financieras.
  prefijo 'o:' se refiere a muebles, objetos.
-->
<raíz>
    <i:bancos xmlns:i='https://es.wikipedia.org/wiki/Banco'>
        <i:nombre>Banco de Venezuela</i:nombre>
        <i:nombre>Banco Mercantil</i:nombre>
        <i:nombre>Banco Bicentenario</i:nombre>
    </i:bancos>
    <o:bancos xmlns='https://es.wikipedia.org/wiki/Banco_(mueble)'>
        <o:nombre>banco de madera</o:nombre>
        <o:nombre>banco de metal</o:nombre>
        <o:nombre>taburete</o:nombre>
    </o:bancos>
</raíz>

También podemos declarar dichos atributos en el elemento raíz para darle mayor claridad a nuestro código y es igualmente válido:

<raíz
    xmlns:i='https://es.wikipedia.org/wiki/Banco'
    xmlns='https://es.wikipedia.org/wiki/Banco_(mueble)'
>

Recordemos que los documentos XML permiten los espacios en blanco para precisamente indentar para clarificar, por ello este formato de elemento raíz.

HTML DOM

Fuentes consultadas.

En idioma castellano.

En idioma inglés.