Movistar me toma el pelo: “Pagos Movistar”

Los errores de facturación y las odiseas con las teleco no son ninguna novedad. Sin embargo, uno no sabe a lo que se enfrenta hasta que los sufre en sus propias carnes (o en las de alguien cercano, como es el caso).

A continuación expondré el problemilla que estamos teniendo en casa con una línea de móvil Movistar, en la que, desde hace tres meses, nos están facturando por servicios en los que no nos hemos dado de alta, que nunca hemos recibido y que ni nosotros, NI ELLOS, saben lo que son.

Breve exposición de hechos:

En la factura de julio, nos encontramos con que Movistar ha cobrado un importe de 17,20 € (+IVA) en concepto de “Pagos Movistar”. Según la factura, este importe corresponde a 5 accesos a “Movilisto”, por valor de 3,44 € cada uno.

Inmediatamente llamo al 1004 para indicar que desconocemos qué es esto, que desde esa línea no se ha realizado ningún tipo pago, que no se ha recibido ningún SMS con contenido “premium” y solicitamos la devolución del importe. Tras hablar con la operadora y un rato de espera, me indican que se ha facturado por error y que van a proceder a la devolución del importe en la siguiente factura. “Bien, parece que se han dado cuenta del error”, pensamos como ilusos.

Llega la factura de agosto, y no sólo no se nos ha devuelto el importe, si no que nos vuelven a aparecer 13,76 € (+IVA) en concepto de “Pagos Movistar”. Y aquí empieza la odisea.

Casi una decena de llamadas al 1004 y cada operador me dice una cosa diferente: “Esos pagos son de compras hechas por Internet, son de un servicio de alertas en el que estamos suscritos, que no pueden procesar la devolución sin el número procedencia de los mensajes…” (insisto e insisto en que no hemos recibido ningún SMS y que en la factura tampoco aparece ningún número de procedencia o destino de los cargos). La última persona con la que hablo parece que tiene algo de idea (o eso creía yo), nos pide disculpas por el error en la apertura de la incidencia del mes anterior y nos indica que abre dos nuevas incidencias: una correspondiente a la baja restricción del supuesto servicio premium y otra para la devolución de la suma de los dos importes.

Llega la factura de septiembre y, como no podía ser de otra manera, nuevo cargo de 10,32 € (+IVA) en concepto de “Pagos Movistar” y ni rastro de ninguna devolución. Ahora sí, vuelvo a llamar Movistar echando fuego por la boca.

La operadora que me atiende es española y me indica que las incidencias abiertas hasta ahora no sirven para nada -son todas incorrectas-, y que lo que se está facturando son descargas de música a través de e-moción (imagino a mi padre descargándose la última canción de Shakira en su viejo Nokia a las 04:02 de la madrugada y me entra una risa de loco desesperado al borde del suicidio…).

Nuevamente me dicen que se ha procedido a dar de baja el servicio, que se ha solicitado la devolución de la suma de los tres importes (blablabla…), me dan un nuevo número de incidencia y me dicen que en 24/48h se pondrán en contacto conmigo para informarme sobre su resolución. Ya han pasado esas 48 horas y sin novedades.

En definitiva, ya acumulamos 41,28 € (+IVA) facturados por error que no sabemos si algún día nos devolverán. No obstante, lo más preocupante y lo que ha llevado a esta incidencia a su punto de máxima desesperación es la INCOMPETENCIA de los operadores de Movistar: ha quedado demostrado que no saben porque se está facturando esto y, aún más grave, no tienen ni idea de cómo darlo de baja.

Y ahora, ante todo esto: ¿Qué solución tenemos?

Si portamos la línea a otro operador, nadie nos asegura que no sigamos recibiendo estos cargos (¿y si los está facturando Movilisto independientemente del operador?). Así que, si Movistar no soluciona el problema, no va a quedar más remedio que pedir la baja definitiva de la línea perdiendo el número de móvil.

¡Gracias Movistar!

ACTUALIZACIÓN 01/09/10

Acaban de llamar del 1004 diciendo que, después de investigar la incidencia, resuelven que ellos no pueden restringir ni dar de baja este servicio y que, por tanto, van a seguir facturando por unos supuestos contenidos que nunca hemos recibido. Ahora parece que ya no es un servicio de descarga de música a través de e-moción, si no un servicio de Antena 3 (¿?).

Desde el 1004 nos instan a “hablar con Movilisto” pero, digo yo, ¿porqué tengo que tratar con una empresa que no conozco, en la que nunca me he dado de alta y de la que no recibo ningún contenido suyo?

Asimismo, desde Movistar insisten en que sí que nos hemos dado de alta en ese servicio, pero es que, aunque así fuera, hasta el día de hoy, NUNCA se ha recibido en la línea afectada ningún tipo de contenido (SMS o similar) que justifique los cargos que se realizan en la factura, así como tampoco se ha realizado ninguna descarga de música o pago de ningún servicio. Además, se puede demostrar mediante factura que no se ha enviado ningún SMS a ningún número “premium”.

En definitiva, parece ser que la única manera de acabar con el problema, sin más dolores de cabeza, es dar de baja la línea, perdiendo el número de teléfono. Así que, mañana mismo, enviaremos la solicitud de baja total y definitiva de la línea, por correo. No obstante, y mientras la baja no se haga efectiva, hemos solicitado el cambio de contrato a prepago, para evitar nuevas sorpresas en la factura.

  • Twitter
  • Facebook
  • Meneame
  • del.icio.us
5 Comentarios

Configurar Zend Studio para proyectos PHP en UTF-8

Hace relativamente poco que he empezado a usar Zend Studio como IDE para PHP y uno de los primeros pequeños problemas con los que me he encontrado ha sido con la codificación de caracteres de los proyectos.

Aunque cambiar el charset por defecto de Zend Studio (CP1252) no presenta mayor dificultad que tocar una opción de menú, la cosa se complica si quieres poder trabajar con proyectos que utilizan diferente codificación y, además, que la documentación se genere correctamente para todos ellos.

Después de hacer algunas pruebas creo que he encontrado la configuración idónea para poder trabajar correctamente con todos los proyectos, estableciendo UTF-8 como codificación por defecto.

1. Configurar codificación de los proyectos

Lo primero que debemos hacer es cambiar la codificación de los proyectos a UTF-8, y para ello tenemos dos opciones:

a) Configuración a nivel de entorno de trabajo (recomendado)

A través de esta opción, indicamos a Zend Studio que la codificación por defecto de nuestro entorno de trabajo es UTF-8, por lo que todos los nuevos proyectos que se creen tendrán este charset. El cambio no afectará a los proyectos que ya tengamos creados, que mantendrán su codificación original. Es la opción recomendada.

Para realizar el cambio accedemos a Window > Preferences > General > Workspace y en el apartado Text File Encoding seleccionamos UTF-8 en el desplegable Other.

b) Configuración a nivel de proyecto

Si, por contra, queremos mantener la codificación por defecto de Zend Studio (CP1252), tenemos la opción de cambiar la codificación a nivel proyecto, de forma individual.

Para ello accedemos a las propiedades del proyecto (Botón derecho sobre el proyecto > Properties) y veremos que en el apartado Text file encoding tenemos dos opciones: mantener la configuración por defecto del entorno de trabajo, o especificar una nueva para ese proyecto (en la que seleccionaríamos UTF-8 del desplegable Other).

Sea como sea, una cuestión MUY IMPORTANTE es NO TOCAR la codificación a través de la opción Content Types de las preferencias de la aplicación. Al tocar esta opción, estamos indicando que todos los archivos con determinada extensión cambien su codificación, con lo provocaremos que los archivos creados con una codificación diferente a la que hemos establecido se visualicen de manera errónea.

2. Configurar  documentos HTML y CSS

Aunque hayamos cambiado la codificación a UTF-8 a nivel de entorno de trabajo o de proyecto, los nuevos archivos HTML creados desde Zend Studio estarán en ISO-8859-1.

Para establecer que los nuevos documentos HTML y CSS estén codificados en UTF-8, deberemos acceder a Window > Preferences > Web > HTML Files o CSS Files y, seleccionaremos ISO 10646/Unicode (UTF-8) en el selector Encoding del apartado Creating files.

Ahora, al crear un nuevo documento HTML o CSS , veremos que aparece lo siguiente en sus respectivas cabeceras:

HTML:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

CSS:

@CHARSET "UTF-8";

3. Configurar PHPDocumentor

Aún habiendo realizado correctamente los pasos anteriores, veremos que si generamos la documentación de un proyecto UTF-8 usando PHPDoc, ésta se visualizará de forma errónea (acentos, tildes…).

Esto es debido a que las plantillas de PHPDocumentor están configuradas para codificación iso-8859-1, tal y como se puede ver en los archivos .tpl de, por ejemplo, la plantilla HTML:frames:default

<meta http-equiv='Content-Type' content='text/html; charset=iso-8859-1'/>
<?xml version="1.0"  encoding="iso-8859-1"?>

Para solucionar el problema, deberíamos crear una nueva plantilla -partiendo de una existente- substituyendo la cadena iso-8859-1 por UTF-8. El problema es que esta nueva plantilla generada no será mostrada por el asistente en el momento de generar la documentación, a causa de un error documentado de Zend Studio.

Aún así, podemos hacer lo siguiente:

1. Accedemos a la ruta donde se encuentran las plantillas HTML:frames de PHPDocumentor:

C:\Program Files\Zend\Zend Studio - 7.0.1\plugins\com.zend.php.phpdocumentor_7.0.0.v20090826-1200\Resources\phpdocumentor\phpDocumentor\Converters\HTML\frames\templates

2. Hacemos una copia del directorio default y le llamamos default-iso8859 (por ejemplo).

3. Con la ayuda de un editor de texto (por ejemplo: Notepad++), substituimos la cadena iso-8859-1 por UTF-8 en todos los archivos .tpl del directorio default.

Ahora, por defecto, la documentación de nuestros proyectos UTF-8 se generará correctamente y siempre dispondremos de la plantilla original en caso de necesitar documentar un proyecto antiguo.

  • Twitter
  • Facebook
  • Meneame
  • del.icio.us
4 Comentarios

Cómo redirigir el puerto LPT1 a una impresora de red o USB en Windows XP

En ocasiones -sobre todo si nos movemos en un entorno empresarial-, podemos encontrarnos con programas antiguos (ya sean basados en DOS o en Windows) que sólo permitan imprimir a través del puerto LPT1 del equipo en el que están instalados.

Para solucionar el problema, y poder imprimir desde estas aplicaciones en cualquier otra impresora instalada en el equipo (ya sea una impresora de red o conectada por USB), debemos mapear (o redirigir) el puerto LPT1.

Para ello, deberemos realizar los siguientes pasos:

1) Compartir la impresora a la que queremos que se redirijan las peticiones

Podemos utilizar cualquier impresora instalada en el equipo. Para compartirla accedemos a Inicio > Impresoras y faxes > Seleccionamos “Compartir” del menú contextual de la impresora y le asignamos un nombre de recurso compartido.


2) Redirigir el puerto LPT1 a la impresora

Si estamos en un equipo con permisos de administrador, bastará con abrir una consola de comandos (Inicio > Ejecutar > cmd.exe) y ejecutar lo siguiente:

NET USE LPT1: \\%COMPUTERNAME%\NOMBRE_IMPRESORA /persistent:yes

De esta manera estamos redirigiendo las peticiones del puerto LPT1 a la impresora que hemos compartido en el punto anterior. Además, con el parámetro /persistent:yes, estamos indicando que queremos que el mapeo siga disponible una vez reiniciemos el equipo.

Si intentamos ejecutar el comando anterior con un usuario no administrador (por ejemplo, un usuario de dominio), veremos que nos devuelve un error.

Esto es debido a que el puerto LPT1 se asigna por defecto al puerto paralelo local, y sólo los administradores pueden modificar esta asignación.

Para solucionar este problema, deberemos deshabilitar la asignación del puerto LPT1 al puerto paralelo durante el inicio del equipo, tal y como se explica en el artículo E313644 de Microsoft Support. Deberemos realizar lo siguiente:

1. Descargar la utilidad DevCon de Microsoft y copiar el ejecutable en un directorio del PATH del sistema (por ejemplo, en C:\Windows).

2. Ejecutar el siguiente comando en el equipo:

devcon disable *PNP0401

Podemos ejecutar el comando de dos formas: Accediendo al equipo con una cuenta de Administrador o, si es un equipo de dominio, configurando una directiva de grupo para ejecutarlo como secuencia de comandos de inicio de equipo (En el administrador de directivas de grupo:  Configuración de equipo > Configuración de Windows > Archivos de comandos (Inicio/Apagado) > Inicio).

Después de realizar estos pasos, un usuario no administrador podrá redirigir el puerto LPT1 desde consola de comandos usando NET USE, así como también funcionará si la instrucción se ejecuta como comando de inicio de sesión en una directiva de grupo a nivel de usuario.

  • Twitter
  • Facebook
  • Meneame
  • del.icio.us
1 Comentario
Página 1 de 912345...Última »