Redes sociales en el SAT

---

En esta entrada quisiera abordar un problema que, en medio de la explosión de las redes sociales para empresas, está sucediendo y cada día es más común.

Con tal de ahorrar dinero asignando personal no capacitado para atender las redes sociales, las empresas se están equivocando al atender a su cliente potencial o a su cliente actual, esto es a través de la atención equivocada de los mensajes recibidos a través de las redes sociales.

¿Qué es lo que sucede?, el cliente realiza algún comentario, reclamo, pregunta, aviso o lo que sea a la empresa a través de sus redes sociales, dado que el personal que atiende estas redes no conoce la operación o no le interesa conocerla, las respuestas pueden ir desde un error de ubicación hasta una frase escrita con el estómago en mano.

En esta ocasión haré alusión a la forma en que se manejan las redes sociales en el SAT, sí, nuestro Servicio de Administración Tributaria.

Desde el día 16 de julio por la mañana, reporté vía Twitter que el portal del contribuyente no estaba mostrando factura alguna del año 2014, mencionando el software que actualmente tengo en el equipo con el cual se realizó la conexión (IE 11, Chrome 30, Java 7 update 60) y también mencionando que se utilizaron dos ISP diferentes, Infinitum y Megared.

Aquí la imagen de cómo comenzó la comunicación:

Uno intenta dar toda la información posible del entorno para que el departamento de soporte pueda recibir información que sirva y no un normal "no funciona el sistema", al final somos colegas y sabemos que hay información que les puede resultar de utilidad.

A lo cual respondieron con un "intente de nuevo", cosa que se hizo casi de inmediato y el resultado fue el mismo, que no encuentra comprobantes emitidos.

Me preguntaron por el medio por el cual había hecho la factura... aquí es donde pensé "ups, creo que la persona equivocada es la que está atendiendo esta pequeña plática", esto es porque no importa desde qué PAC realices sus timbrados, éstos siempre deberán aparecer en el portal de contribuyentes; antes aparecían y mágicamente ya no.

Cuando le dije que la factura se había hecho desde un PAC, la respuesta fue la que temía reafirmaría y comprobaría mi temor de estar siendo atendido por una persona sin capacitación: "consúltalo directamente con tu proveedor de factura electrónica".

Después de mensajes, impresiones de pantalla e información extra, es más que claro que el problema está en el portal de contribuyentes o bien algo está fallando en la plataforma.    Es entendible que las personas que atienden las redes sociales no son personal de sistemas, sino de comunicación con cierta preparación fiscal, pero el problema radica en que lo que leen no lo entienden, supongo que la empresa que administra las redes sociales del SAT tiene la política de batear lo más que pueda.

Haciendo a un lado la problemática que sigue latente después de más de 21 horas (y no sé cuántas más, si es que se dignan estos personajes a querer entender), es importante notar la importancia que debe tener el contar con gente con criterio atendiendo las redes sociales, es cuestión de pensar un poco para notar que el problema va más allá de un "reinicie y sea feliz", con la información técnica a la mano el personal de redes sociales debe identificar un problema que está fuera de su alcance el resolver.

Desde hace tiempo he tenido mucha comunicación con un amigo que es consultor en redes sociales, y el tema recurrente es que el ahorro en la atención de redes sociales se traduce en una exposición negativa y posible pérdida de clientes de las empresas.    En este caso es el SAT y no hay de otra más que lidiar con ellos, pero esto no es exclusivo del ambiente gubernamental, muchas (y quiero enfatizar en "muchas") empresas no le dan la importancia debida, y cuando el resultado comienza a ser preocupantemente negativo no saben ni por dónde entrarle.

Mi especialidad es SQL Server y el desarrollo de software en .NET, pero esta problemática no necesita de un especialista para notarla, y en definitiva creo que las empresas deberían poner un poco de más atención a estos canales de comunicación y no colocarlos en manos de charlatanes o de personal que no cuente con madurez profesional ni conocimiento del medio y del negocio.

Dirección física de carpetas compartidas

---

Quiero compartir una entrada muy pequeña pero que les puede resultar de mucha utilidad cuando el desorden en el almacenamiento de archivos y creación de carpetas compartidas, se ha convertido en un reto muy importante para una empresa.


Hoy me encontraba en una empresa revisando el sistema de gestión de archivos compartidos que se implementaría y me encontré con el detalle de que existía una cantidad muy grande de carpetas compartidas en el equipo que utilizan como repositorio de archivos.


En el equipo, no quedaba nada claro cuál era la dirección local de las carpetas compartidas, en realidad toda la información está muy dispersa y desordenada, no existe documentación de la localización de las carpetas ni su razón de existir.


El comando que utilicé para encontrar la localización física de las carpetas compartidas fue "net share", ejecutándolo en una consola de línea de comandos fue extremadamente sencillo encontrar la información que necesitaba.


Quise compartirlo con ustedes, porque probablemente algún día se encuentren con este problema y será muy simple resolverlo con dicho comando.


¡Saludos!

Read uncommitted

---

En esta entrada exploraremos cómo funciona el nivel de aislamiento READ UNCOMMITTED.

Antes de comenzar el ejercicio quisiera hacer notar que el nivel de aislamiento por defecto de SQL Server es READ COMMITTED, esto implica que no podemos leer la información sino hasta que ésta ha sido actualizada de forma definitiva (committed) en la base de datos o bien los cambios han sido deshechos a través de un rollback.

Por ejemplo, supongamos que la transacción 1 ejecuta la siguiente instrucción:
USE AdventureWorks GO BEGIN TRAN UPDATE Production.Product SET ListPrice += 1 WHERE ProductID = 1

Notamos que la transacción queda "abierta", es decir que no ha sido confirmada hacia la base de datos (committed) o deshecha (rollback), por lo tanto SQL Server mantendrá el bloqueo de tipo exclusivo sobre el producto cuyo id sea 1.

En otra ventana ejecutaremos la siguiente sentencia:
USE AdventureWorks GO BEGIN TRAN UPDATE Production.Product SET ListPrice += 1 WHERE ProductID = 1

Veremos que este query queda en espera debido a que el nivel de bloqueo que él requiere (READ COMMITTED) no le permite obtener la información que necesita debido a que la transacción 1 no ha finalizado. La transacción 1 tiene un bloqueo exclusivo que no es compatible con READ COMMITTED de otra transacción.

Esta información la podemos confirmar con la siguiente sentencia:
USE AdventureWorks GO SELECT DB_NAME(T.resource_database_id) AS database_name, OBJECT_NAME(P.[object_id]) FROM sys.dm_tran_locks T INNER JOIN sys.partitions P ON T.resource_associated_entity_id = P.hobt_id WHERE T.request_mode = 'X'

Veremos que se tiene un bloqueo exclusivo sobre algún elemento del objeto Production.Product. También se podría obtener la fila que está siendo bloqueada, pero perderíamos el enfoque de esta entrada.

Volvamos a la ventana de la transacción 1 y ejecutemos COMMIT, veremos que de forma casi inmediata la transacción 2 será desbloqueada y podrá obtener los datos que requiere.

¿Qué pasa cuando la información que queremos obtener es "inmutable"?, no quisiera utilizar la palabra inmutable en su totalidad debido a que en teoría los únicos datos inmutables de una base de datos son las llaves primarias, pero podemos suponer que el nombre de un producto es inmutable, sería muy extraño tener que actualizar el nombre de un producto. En este caso no requerimos que alguna otra transacción genere algún bloqueo sobre la lectura del Id y del Nombre del producto, por lo tanto, necesitamos leer los datos independientemente de los cambios que se estén realizando sobre ellos.

Antes de hacer cambios en el código, vamos a la ventana de la transacción 2 y ejecutamos COMMIT para no dejar transacciones abiertas (colgadas) en el manejador de bases de datos.

Volvamos a ejecutar el código de la transacción 1 para generar un bloqueo sobre el producto cuyo Id es 1, y vamos a cambiar un poco el código de la transacción 2:
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED BEGIN TRAN SELECT ProductID, Name, ListPrice FROM Production.Product WHERE ProductID = 1

Podemos notar que ahora estamos estableciendo el nivel de aislamiento en READ UNCOMMITTED para poder leer datos que no han sido hechos "oficiales" en la base de datos. Si ejecutamos la transacción veremos que la información del nombre, producto y precio son inmediatamente devueltos.

Hasta ahora todo parecería que salió tal como lo deseamos, pero... ¿qué pasaría si necesitáramos realizar alguna acción tomando el precio del producto?, he ahí que vendría un fenómeno conocido como "dirty reads", eso quiere decir que podríamos leer un valor que no ha sido hecho oficial sobre la base de datos y que posiblemente su cambio pudiera ser deshecho, es decir que operaríamos con un valor que jamás debió ser tomado.

¿Qué debemos hacer?, dependerá de la operación y de los valores que queremos utilizar, deberemos establecer categorías de los datos que requieren un bloqueo exclusivo y también identificar los datos que pueden ser leídos durante una transacción de actualización.

Espero te haya resultado de utilidad esta entrada, nos vemos la siguiente.