PROYECTO DE INSTRUCTIVO TÉCNICO DEL SISTEMA DE SEGUIMIENTO …

PROYECTO DE INSTRUCTIVO TÉCNICO DEL SISTEMA DE SEGUIMIENTO, MONITOREO Y FISCALIZACIÓN DE BAJAS Y

MIGRACIONES

RESOLUCIÓN DE GERENCIA GENERAL N° 00153-2021-GG/OSIPTEL

COMENTARIOS RECIBIDOS: Se han recibido comentarios al referido Proyecto, mediante las siguientes comunicaciones:

▪ VIETTEL PERÚ S.A.C. (en adelante, BITEL), a través de la carta N° 0480-2021/DL recibida el 02 de junio de 2021. ▪ ENTEL PERÚ S.A., (en adelante, ENTEL), a través de la carta N° CGR-1509/2021 recibida el 03 de junio de 2021. ▪ TELEFÓNICA DEL PERÚ S.A.A. (en adelante, TELEFÓNICA), a través de la carta N° TDP-1710-AG-GER-21 recibida el 02 de junio de

2021 y la carta N° TDP-1722-AG-GER-21 recibida el 03 de junio de 2021.

▪ AMÉRICA MÓVIL PERÚ S.A.C. (en adelante, CLARO), a través de la carta N° DMR/CE/N°1335/21 recibida el 03 de junio de 2021. ▪ ASOCIACIÓN PARA EL FOMENTO DE LA INFRAESTRUCTURA NACIONAL (en adelante, AFIN), a través de correo electrónico

registrado en el sistema documentario del OSIPTEL el 04 de junio de 2021.

Matriz de Comentarios

Numeral del Proyecto a Comentarios Versión Final del Numeral

1. OBJETIVO Establecer el procedimiento a través del cual, las empresas operadoras deben reportar la información relacionada a los procesos de bajas y migraciones, presentadas por sus abonados o ejecutadas por la empresa operadora, al Sistema de seguimiento, monitoreo y supervisión del OSIPTEL (Sistema de Seguimiento).

1. OBJETIVO Establecer el procedimiento a través del cual, las empresas operadoras deben reportar la información relacionada a los procesos de bajas y migraciones, presentadas por sus abonados o ejecutadas por la empresa operadora, al Sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones del OSIPTEL.

Comentarios recibidos Posición del OSIPTEL

No se recibieron comentarios. No se recibieron comentarios.


2. ALCANCE El presente instructivo es aplicable a las empresas operadoras de los servicios públicos de telecomunicaciones, que cuenten con más de 500 000

2. ALCANCE El presente instructivo es aplicable a las empresas operadoras de los servicios públicos de telecomunicaciones, que cuenten con más de 500 000

abonados; se contempla la realización de actividades referidas a la entrega y recojo de la información de relacionada a los procesos de bajas y migraciones.

abonados; se contempla la realización de actividades referidas a la entrega y recojo de la información de relacionada a los procesos de bajas y migraciones. Se excluye del alcance de la presente norma los servicios contratados en el marco de convocatorias o negociaciones de carácter público o privado en las cuales la oferta ha sido diseñada de manera específica, y aquellos abonados con la condición de persona jurídica que tienen registrados bajo su titularidad diez (10) o más servicios


CLARO

CLARO no considera razonable la creación de seis (6) reportes que deberán ser entregados diariamente por las empresas operadoras al OSIPTEL para que el Regulador pueda verificar si las solicitudes de baja y migración han sido ejecutadas dentro de los plazos regulados. Así, considera que no existe una proporcionalidad entre el objetivo (verificar si las empresas ejecutan oportunamente las solicitudes de baja y migración) y los medios contemplados en el proyecto, esto es, la creación de seis (6) reportes diarios, los cuales se han denominado: i) Solicitudes de baja, ii) Solicitudes de migración; iii) Bajas ejecutadas por solicitud de abonado; iv) Bajas ejecutadas sin solicitud de abonado; v) Migraciones ejecutadas por solicitud de abonado; y vi) Migraciones ejecutadas sin solicitud de abonado.

Sobre el comentario formulado por CLARO, se debe precisar que el objetivo del sistema es efectuar un seguimiento a los procesos de bajas y migraciones. Esto incluye aquellas bajas y migraciones que son producto de las solicitudes presentadas por los abonados, así como aquellas que son ejecutadas, de manera unilateral, por las empresas operadoras. Conforme a lo estipulado en los artículos 76 y 77 del Texto Único Ordenado de las Condiciones de Uso de los Servicios Públicos de Telecomunicaciones, aprobado por Resolución de Consejo Directivo Nº 138-2012-CD-OSIPTEL (en adelante, TUO de las CDU), los plazos se encuentran regulados para ambos escenarios; de allí nace la importancia de su inclusión dentro del Sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones (en adelante, sistema de seguimiento) y la

Sobre la base de lo expuesto, manifiesta que si el objetivo es "prevenir" cualquier perjuicio a los clientes a través de algún eventual incumplimiento de los plazos regulados de ejecución de las solicitudes de migración y baja que sean formuladas, entonces la acción que gatillaría cualquier tipo de reporte debería ser precisamente la solicitud efectuada por el cliente, razón por la cual no debería contemplarse en el instructivo los reportes denominados "bajas ejecutadas sin solicitud de abonado - BASS": y el reporte de las "Migraciones ejecutadas sin solicitud de abonado - MISS".

Asimismo, indica que entre los dos reportes antes señalados el Regulador solicita la entrega de 29 campos de información, de los cuales actualmente 22 campos se encuentran en el Registro de Abonados, esto es, el 76% de los campos requeridos en dichos reportes ya son entregados al regulador, por lo que no considera razonable solicitar nuevamente la entrega de los mismos, lo cual también es concordante con lo señalado en el artículo 48°

de la LPAG. De igual manera, señala que los otros 7 campos de información restantes se encuentran constituidos por NUEVA información que forma parte del ámbito de protección de datos de sus clientes, y que no resultan necesarios para que el Regulador pueda verificar el cumplimiento de la normativa aplicable, lo cual será desarrollado en el punto 5 del proyecto. A mayor abundamiento, los campos de información que consideran información sensible se detallan a continuación:

1) Reporte BASS: Plan Contratado y Deuda del Servicio. 2) Reporte MISS: Plan Origen, Plan Destino, Ciclo de Facturación,

Motivo de Migración.

En esta línea, señala que la información antes descrita se constituye en información sensible y confidencial que se encuentra protegida --inclusive— a nivel constitucional, razón por la cual le causa mucha preocupación que sea solicitada con la finalidad de "verificar la correcta ejecución de las solicitudes de baja y migración", en tanto no resulta relevante para alcanzar dicha finalidad. Por lo expuesto, solicita la eliminación del reporte de las "bajas ejecutadas sin solicitud de abonado - reporte BASS" y el reporte de las "Migraciones ejecutadas sin solicitud de abonado - reporte MISS", debido no sólo a que los campos de información ya son reportados actualmente mediante el

necesidad de contar con seis (6) reportes que permiten gestionar todo tipo de escenarios. Por otro lado, resulta importante contar con los reportes BASS (bajas sin solicitud) y MISS (migraciones sin solicitud) dado que podrían corresponder al escenario de bajas no solicitadas que son materia de reclamo. En efecto, al primer trimestre del año 2021, se tiene que el 17.7% de las consultas presentadas al Sistema de Atención del OSIPTEL corresponden a bajas no solicitadas por el abonado y el 13.3% corresponde a migraciones no solicitadas por el abonado. Por tanto, se desestima la solicitud formulada por CLARO sobre la eliminación de los referidos reportes. Respecto al comentario relacionado con los campos que forman parte del RENTESEG, debemos resaltar que, a través de dicho sistema, sólo se reporta información de los abonados de los servicios móviles, los que constituyen 2 de los 7 servicios contemplados en el sistema de seguimiento:

1. Telefonía fija. 2. Telefonía móvil. 3. Internet fijo. 4. Internet móvil. 5. TV Cable. 6. Empaquetado (dúo, trío, otro), que incluye teléfono fijo. 7. Empaquetado (dúo, trío, otro) que no incluye teléfono fijo.

En ese sentido, considerando que, para los servicios móviles, parte de la información requerida para el sistema de seguimiento es reportada al RENTESEG, atendiendo a la solicitud planteada por CLARO, cuando se trate de solicitudes de baja o migración correspondientes a servicios móviles, no será necesario que se reporte la información que ya se reporta al RENTESEG; sin embargo, si se trata de servicios que no son móviles, dicha información deberá ser reportada de manera obligatoria. Sobre la base de lo expuesto, se han realizado los ajustes correspondientes en el Instructivo Técnico. Con relación a los siete campos de información que, de acuerdo a CLARO, forman parte del ámbito de protección de datos de sus clientes y no resultarían necesarios para que el Regulador pueda verificar el cumplimiento de la normativa aplicable, manifestamos que la empresa

Registro de Abonados, sino también que se trataría de información protegida por la normativa de protección de datos, conforme ha sido señalado. De otro lado, CLARO considera necesario que el proyecto bajo análisis no debe resultar de aplicación al segmento Corporativo / Gobierno, en tanto que se encuentran en un segmento que tiene una naturaleza diferente al masivo, que inspiró la creación del proyecto. Añade que, en efecto, a lo largo del análisis realizado en el Informe N° 00031-DAPU/2021 se señala que el objetivo del proyecto es reducir la cantidad de consultas recibidas por parte de los usuarios respecto a sus solicitudes de baja y migración, no habiéndose efectuado la desagregación entre clientes masivos y corporativos, por lo que considera que las consultas recibidas por el Regulador deben haber sido realizadas casi en su totalidad por clientes del segmento masivo, en tanto que resulta usual que los clientes corporativos y del sector Gobierno cuenten con asesores personalizados (segmento carterizado) con los cuales mantienen una comunicación fluida y, por ende, la solución de problemas es realizado de manera rápida, dinámica y ágil, por lo que no resulta necesario que el segmento antes señalado sea incorporado en el ámbito de aplicación del proyecto.

Finalmente, señala que la atención de los requerimientos formulados por los clientes corporativos del segmento carterizado y sector Gobierno no necesariamente son atendidos por el sistema de atención de clientes masivos (front de atención), sino por pedidos de ejecución realizados de manera directa en los sistemas de las empresas a través de pedidos de ejecución realizados de manera manual, debido a la cantidad de líneas que suelen involucrar en dichos pedidos. Es por ello que en caso se apruebe el proyecto bajo análisis y se contemple también la atención de clientes corporativos, se podrían ocasionar serios inconvenientes en la operación, debido a que los reportes serían alimentados por información obtenida por los sistemas (clientes masivos atendidos por el front de atención) así como por acciones manuales.

precisa seis, respecto de los cuales el campo Deuda del Servicio ha sido retirado de los reportes, acogiendo de esta manera parcialmente el comentario formulado. No obstante, los campos Plan Contratado, Plan Origen y Plan Destino permitirán establecer si existen problemas puntuales respecto a la baja o migración de determinados planes; ello considerando los bajos incentivos que podrían tener las empresas para atender solicitudes relacionadas con planes con rentas mensuales altas. Además, debe tenerse en consideración que, en el caso de la baja de servicio, las empresas pierden al abonado y todos los ingresos que ello supone, mientras que, en el caso de las migraciones, es probable que los usuarios estén solicitando trasladarse a un plan con una menor renta mensual. En cuanto al ciclo de facturación, se debe tener en consideración que, de acuerdo al artículo 63 del TUO de las CDU, la migración se efectúa en el siguiente ciclo de facturación posterior a la presentación de la solicitud, por lo que resulta indispensable contar con dicha información para realizar el seguimiento del trámite. Por lo que se refiere a la preocupación de la empresa por el tratamiento de la información en mención y el riesgo en el que asegura se encontraría, es importante resaltar que la entrega de dicha información no afecta el derecho de confidencialidad de la información personal, en tanto resulta necesaria para el ejercicio de nuestras funciones. Lo expuesto encuentra asidero en el artículo 8 de la Ley de Desarrollo de las Funciones y Facultades del Organismo Supervisor de Inversión Privada en Telecomunicaciones – OSIPTEL, Ley Nº 27336 (en adelante, LDFF).

“Artículo 8.- Secreto e inviolabilidad de las comunicaciones (…) 8.3 No constituye violación del derecho al secreto y la inviolabilidad de las telecomunicaciones, ni afecta el derecho a la confidencialidad de la información personal, el acceso que tenga OSIPTEL a la información necesaria para cumplir sus funciones y, particularmente, el ejercicio que haga de las facultades contempladas en el Artículo 15 de la presente Ley.

En ningún caso OSIPTEL podrá exigir la presentación de información que revele el contenido de las comunicaciones.”

A ello debe agregarse que se adoptarán las medidas necesarias para el resguardo de la información que se reciba, tal como se viene haciendo en todos los procedimientos a cargo del OSIPTEL. Finalmente, en relación con la solicitud de no incluir al segmento corporativo, debemos precisar que este ha sido excluido de la reportería, tal como se evidencia en el artículo 2 de la Norma que establece el sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL:

“Artículo 2.- Alcance (...) Se excluye del alcance de la presente norma los servicios contratados en el marco de convocatorias o negociaciones de carácter público o privado en las cuales la oferta ha sido diseñada de manera específica, y aquellos abonados con la condición de persona jurídica que tienen registrados bajo su titularidad diez (10) o más servicios.”


3. REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN ENTREGAR AL SISTEMA DE SEGUIMIENTO DEL OSIPTEL

3.1. Reportes relacionados a la baja del servicio

En este proceso se ha identificado tres reportes funcionales:

3.1.1. Reporte de solicitudes de baja (SOBA): contiene información detallada de todas las solicitudes presentadas por los abonados, a través de los distintos canales de atención, para dar de baja a su servicio. El reporte debe contener todas las solicitudes presentadas entre las 00:00:00 y las 23:59:59 del día anterior.

3.1.2. Reporte de bajas ejecutadas por solicitud de abonado (BACS): una vez que transcurre el plazo o se alcanza la fecha programada en la solicitud, la baja debe ser ejecutada y la información concerniente debe ser entregada al Sistema de

3. REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN ENTREGAR AL SISTEMA DE SEGUIMIENTO DEL OSIPTEL

De acuerdo a lo señalado en la Primera Disposición Transitoria de la norma que establece el “Sistema de Seguimiento, Monitoreo y Fiscalización de Bajas y Migraciones” (en adelante, Sistema de seguimiento), aprobada mediante Resolución N° 00111-2021-CD/OSIPTEL, se establecen dos (2) fases para la implementación del Sistema. Es así que, en el plazo de seis (6) meses contados a partir de la fecha de la publicación del presente Instructivo Técnico se inicia el seguimiento de las bajas y migraciones solicitadas por decisión del abonado (Primera Fase) y, en el plazo máximo de doce (12) meses contados a partir de la fecha de la publicación del presente Instructivo Técnico se inicia el seguimiento del total de bajas y migraciones solicitadas por los abonados y ejecutadas por la empresa operadora (Segunda Fase).

Seguimiento a través de este reporte. El reporte debe contener las bajas con solicitud ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.

El Sistema de Seguimiento verifica que cada solicitud de baja reportada se ejecute dentro del plazo establecido, para lo cual utiliza información de los dos reportes antes mencionados. En caso se identifique solicitudes de baja que no han sido atendidas, se generan notificaciones hacia el operador.

3.1.3. Reporte de bajas ejecutadas sin solicitud de abonado

(BASS): contiene información detallada de todas las bajas que han sido ejecutadas sin que exista una solicitud de baja explícita por parte del abonado. Es el caso de las bajas por cuestionamiento de titularidad, por portabilidad, por falta de recarga para el servicio prepago, por falta de pago para el servicio postpago, entre otros. El reporte debe contener todas las bajas sin solicitud ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.

Nombre del Archivo Descripción Periodicidad Horario

CONCESIONARIO_SOBA_YYYYMMDD.TXT

Solicitudes de baja

Diario 09:00

CONCESIONARIO_BACS_YYYYMMDD.TXT

Bajas ejecutadas con solicitud

Diario 09:00

CONCESIONARIO_BASS_YYYYMMDD.TXT

Bajas ejecutadas sin solicitud

Diario 09:00

3.2. Reportes relacionados a la migración del servicio


3.2.1. Reporte de solicitudes de migración (SOMI): contiene información detallada de todas las solicitudes presentadas por los abonados, a través de los distintos canales de atención, para cambiar el servicio que tiene contratado. El reporte debe contener las solicitudes presentadas entre las 00:00:00 y las 23:59:59 del día anterior.

A continuación, se detallan los reportes que forman parte del Sistema de seguimiento.

3.1. Reportes relacionados a la baja del servicio En este proceso se ha identificado tres reportes funcionales:

Primera Fase

3.1.1. Reporte de solicitudes de baja (SOBA): contiene

información detallada de todas las solicitudes de los abonados sin expresión de causa, a través de los distintos canales de atención, para dar de baja a su servicio. El reporte debe contener todas las solicitudes presentadas entre las 00:00:00 y las 23:59:59 del día anterior.

3.1.2. Reporte de bajas ejecutadas por solicitud de abonado (BACS): una vez que transcurre el plazo o se alcanza la fecha programada en la solicitud, la baja debe ser ejecutada y la información concerniente debe ser entregada al Sistema de Seguimiento a través de este reporte. El reporte debe contener las bajas ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.

El Sistema de Seguimiento verifica que cada solicitud de baja reportada se ejecute dentro del plazo establecido, para lo cual utiliza información de los dos reportes antes mencionados. En caso se identifique solicitudes de baja que no han sido atendidas, se generan notificaciones hacia el operador.



Solicitudes de baja

Diario 00:00 - 09:00


Bajas ejecutadas con solicitud

Diario 00:00 - 09:00

TABLA 1.- Reportes relacionados a la baja del servicio, primera fase

3.2.2. Reporte de migraciones ejecutadas por solicitud de abonado (MICS): una vez que transcurre el plazo o se alcanza la fecha programada en la solicitud, la migración debe ser ejecutada y la información concerniente debe ser entregada al Sistema de Seguimiento a través de este reporte. El reporte debe contener todas las migraciones ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior El Sistema de Seguimiento verifica que cada solicitud de migración reportada se ejecute dentro del plazo establecido, para lo cual utiliza información de los dos reportes antes mencionados. En caso se identifique solicitudes de migración que no han sido atendidas, se generan notificaciones hacia el operador.

3.2.3. Reporte de migraciones ejecutadas sin solicitud de abonado (MISS): contiene información detallada de todas las migraciones que han sido ejecutadas sin que exista una solicitud de migración explícita por parte del abonado. El reporte debe contener todas las migraciones sin solicitud ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.


CONCESIONARIO_SOMI_YYYYMMDD.TXT

Solicitudes de migración

Diario 09:00

CONCESIONARIO_MICS_YYYYMMDD.TXT

Migraciones ejecutadas con solicitud

Diario 09:00

CONCESIONARIO_MISS_YYYYMMDD.TXT

Migraciones ejecutadas sin solicitud

Diario 09:00

3.3. Reportes de subsanación

En caso se encuentren errores en los reportes entregados por las empresas operadoras, estos son informados por el Sistema de Seguimiento para que sean subsanados en la siguiente ventana de entrega de información.

Segunda Fase

3.1.3. Reporte de bajas ejecutadas sin solicitud de abonado (BASS): contiene información detallada de todas las bajas que han sido ejecutadas sin que exista una solicitud expresa del abonado. Es el caso de las bajas por portabilidad numérica; falta de recarga; falta de pago; fallecimiento del abonado; insolvencia o extinción de la persona jurídica; problemas de calidad de servicio (para contratos a plazo forzoso); por aplicación de tarifas distintas a las contratadas (para contratos a plazo forzoso); por eliminación de la señal de programación del servicio de televisión de paga (para contratos a plazo forzoso); falta de instalación, activación y/o traslado; por no acreditación de mecanismo de contratación; uso indebido; y uso prohibido, entre otros. El reporte debe contener todas las bajas ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.



Bajas ejecutadas sin solicitud

Diario 00:00 - 09:00

TABLA 2.- Reportes relacionados a la baja del servicio, segunda fase

3.2. Reportes relacionados a la migración del servicio


Primera Fase

3.2.1. Reporte de solicitudes de migración (SOMI): contiene información detallada de todas las solicitudes de migración por decisión del abonado a través de los distintos canales de atención, para cambiar el servicio que tiene contratado. El reporte debe contener las solicitudes presentadas entre las 00:00:00 y las 23:59:59 del día anterior.

3.2.2. Reporte de migraciones ejecutadas por solicitud de abonado (MICS): una vez que transcurre el plazo o se alcanza la fecha programada en la solicitud, la migración debe ser


CONCESIONARIO_SOBA_YYYYMMDD_SUB.TXT

Subsanación de solicitudes de baja rechazadas

Diario 09:00

CONCESIONARIO_BACS_YYYYMMDD_SUB.TXT

Subsanación de bajas ejecutadas con solicitud rechazadas

Diario 09:00

CONCESIONARIO_BASS_YYYYMMDD_SUB.TXT

Subsanación de bajas ejecutadas sin solicitud rechazadas

Diario 09:00

CONCESIONARIO_SOMI_YYYYMMDD_SUB.TXT

Subsanación de solicitudes de migración rechazadas

Diario 09:00

CONCESIONARIO_MICS_YYYYMMDD_SUB.TXT

Subsanación de migraciones ejecutadas con solicitud rechazadas

Diario 09:00

CONCESIONARIO_MISS_YYYYMMDD_SUB.TXT

Subsanación de migraciones ejecutadas sin solicitud rechazadas

Diario 09:00

ejecutada y la información concerniente debe ser entregada al Sistema de Seguimiento a través de este reporte. El reporte debe contener todas las migraciones ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior El Sistema de Seguimiento verifica que cada solicitud de migración reportada se ejecute dentro del plazo establecido, para lo cual utiliza información de los dos reportes antes mencionados. En caso se identifique solicitudes de migración que no han sido atendidas, se generan notificaciones hacia el operador.



Solicitudes de migración

Diario 00:00 - 09:00


Migraciones ejecutadas con solicitud

Diario 00:00 - 09:00

TABLA 3.- Reportes relacionados a la baja del servicio, primera fase

Segunda Fase

3.2.3. Reporte de migraciones ejecutadas sin solicitud de

abonado (MISS): contiene información detallada de todas las migraciones que han sido ejecutadas sin que exista una solicitud expresa del abonado. Es el caso de la migración por desistimiento de la migración previa y la migración por habilitación del tope de consumo, entre otros. El reporte debe contener todas las migraciones ejecutadas entre las 00:00:00 y las 23:59:59 del día anterior.



Migraciones ejecutadas sin solicitud

Diario 00:00 - 09:00

TABLA 4.- Reportes relacionados a la migración del servicio, segunda fase

3.3. Reportes de subsanación

En caso se encuentren errores en los reportes entregados por las empresas operadoras, estos son informados por el Sistema de Seguimiento para que sean subsanados en la siguiente ventana de entrega de información.


CONCESIONARIO_SOBA_YYYYMMDD_SUB.TXT

Subsanación de solicitudes de baja rechazadas

Diario 00:00 - 09:00

CONCESIONARIO_BACS_YYYYMMDD_SUB.TXT

Subsanación de bajas ejecutadas con solicitud rechazadas

Diario 00:00 - 09:00

CONCESIONARIO_SOMI_YYYYMMDD_SUB.TXT

Subsanación de solicitudes de migración rechazadas

Diario 00:00 - 09:00

CONCESIONARIO_MICS_YYYYMMDD_SUB.TXT

Subsanación de migraciones ejecutadas con solicitud rechazadas

Diario 00:00 - 09:00

TABLA 5.- Reportes de subsanación, primera fase


CONCESIONARIO_BASS_YYYYMMDD_SUB.TXT

Subsanación de bajas ejecutadas sin solicitud rechazadas

Diario 00:00 - 09:00

CONCESIONARIO_MISS_YYYYMMDD_SUB.TXT

Subsanación de migraciones ejecutadas sin solicitud rechazadas

Diario 00:00 - 09:00

TABLA 6.- Reportes de subsanación, segunda fase


BITEL

Sobre los reportes de solicitudes de baja, BITEL requiere se especifique o ejemplifique las siguientes columnas:

− NUMERO_SOLICITUD: aclarar qué tipo de información debe ir en esta columna. Ejemplo: el código de solicitud o el código ID en su sistema. Además, si este código debe ser el mismo para todos los reportes de solicitudes de baja.

− DURACION_CONTRATO: especificar los criterios a tomar en cuenta para la obtención de esta columna.

− FECHA_BAJA_PROGRAMADA: indicar qué valor debe colocarse en esta columna si el cliente no desea programar una fecha.

− FECHA_RELACIONADA_BAJA: brindar más detalle acerca del valor que debe ir en esta columna. Si es posible, brindar ejemplos.

FECHA_BAJA_EFECTIVA: indicar la diferencia entre esta columna y FECHA_RELACIONADA_BAJA y qué valor debe considerarse por cada una. Sobre los reportes de solicitudes de migración, BITEL requiere se especifique o ejemplifique las siguientes columnas:

− NUMERO_SOLICITUD: aclarar qué tipo de información debe ir en esta columna. Ejemplo: el código de solicitud o el código ID en su sistema. Además, si este código debe ser el mismo para todos los reportes de solicitudes de migración o baja.

− FECHA_MIGRACION_PROGRAMADA: indicar el artículo que avala esta columna y qué tipo de información debe registrarse aquí, en caso el cliente no desee programar una fecha.

− MOTIVO_MIGRACION: especificar las 2 opciones brindadas en el instructivo y el artículo en relación al mismo.

Acerca de los comentarios formulados por BITEL en este extremo, se acogen los mismos en lo que se refiere a:

Reportes de Baja

(i) NUMERO_SOLICITUD: se especifica que corresponde al código definido en el literal (ii) del artículo 118 del TUO de las CDU. Asimismo, se cambia el nombre a Código de Pedido.

(ii) DURACION_CONTRATO: se especifica que corresponde a las definiciones establecidas en los artículos 76 y 77 del TUO de las CDU.

(iii) FECHA_BAJA_PROGRAMADA: se realiza la especificación. (iv) FECHA_RELACIONADA_BAJA: se realiza la especificación,

según lo detallado en los artículos 76 y 77 del TUO de las CDU. (v) FECHA_BAJA_EFECTIVA, se especifica su relación con la

FECHA_RELACIONADA_BAJA.

Reportes de Migración

(i) NUMERO_SOLICITUD: se especifica que corresponde al código definido en el literal (ii) del artículo 118 del TUO de las CDU. Asimismo, se cambia el nombre a Código de Pedido.

(ii) FECHA_MIGRACION_PROGRAMADA: se especifica que aplica a Telefónica del Perú S.A.A.

ENTEL

Con relación a las obligaciones de entrega, recojo de la información de las solicitudes y ejecución de bajas y migraciones, ENTEL considera que las mismas suponen una excesiva carga para las empresas operadoras, puesto que la obligación de remitir los 7 días de la semana la información de bajas y migraciones al OSIPTEL y el recojo de la información de las observaciones ejecutadas por el OSIPTEL supone la inversión de recursos que (i) no atienden adecuadamente el problema identificado y (ii) resulta desproporcionado a los fines que se buscan tutelar, lo cual ha desarrollado en sus comentarios remitidos mediante carta CGR-1159 de fecha 30 de abril y carta CGR-1220 de fecha 07 de mayo de 2021. Agrega que el horario establecido para la entrega de los referidos reportes, la cual debe realizarse a las 09:00 horas durante los siete (07) días de la semana, implica el uso de recursos de las empresas operadoras durante los fines de semana e incluso en feriados, estimando esta medida costosa y desproporcional con el fin que se busca tutelar, por lo que solicita se evalué la posibilidad de que las empresas operadoras entreguen la información y ejecución de bajas y migraciones en días hábiles y no los siete (07) días a la semana, a fin de que en caso de que exista inconveniente alguno, se pueda contar con el soporte necesario para cumplir con la obligación.

Sobre lo manifestado por ENTEL, respecto de los días de entrega de la información, nos remitimos a lo manifestado por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados por la citada empresa al artículo 4 del referido Proyecto de Norma. Sin perjuicio de ello, se estima conveniente precisar, en relación con la entrega de la información en días hábiles, que se espera que la generación y entrega de los reportes se realice de manera automática, por lo que, una vez efectuado el desarrollo correspondiente, el uso de recursos no debería ser excesivo. Asimismo, se debe tener en cuenta que la atención de solicitudes de bajas y migraciones se realizan durante los fines de semana e incluso feriados; en ese sentido, los horarios establecidos guardan relación con el flujo de procesos que se utiliza en el sector. Asimismo, contrariamente a la opinión de ENTEL, se estima que la regulación propuesta permitirá atender adecuadamente el problema, puesto que en los casos en los que se presenten inconvenientes con la atención de las solicitudes de bajas y migraciones, permitirá que los mismos sean detectados de manera inmediata y, en consecuencia, se podrán adoptar las medidas que correspondan para dar solución a los mismos de manera oportuna, lo cual repercutirá en la satisfacción del usuario, quienes podrán finalmente ver atendidas sus solicitudes, y, por parte de las empresas operadoras y el OSIPTEL, permitirá mejorar el seguimiento a la atención de este tipo de solicitudes, identificar oportunidades de mejora y actuar tempranamente frente a los inconvenientes presentados. Por lo expuesto, no es posible acoger la propuesta formulada por ENTEL.

TELEFÓNICA

TELEFÓNICA considera que el envío de reportería de manera diaria implicaría una afectación grave en la operación de la empresa operadora., toda vez que este envío requiere interacción de las diferentes áreas, sistemas, plataformas y procesos vinculados al requerimiento realizado. Asimismo, indica que genera costos en el diseño, implementación y ejecución de un proceso que permita dar atención a lo solicitado.

Al respecto, cabe precisar que la implementación del sistema de seguimiento ha sido sustentada respetando los Lineamientos de Calidad Regulatoria dispuestos por Resolución N° 069-2018-CD/OSIPTEL. Debe tenerse en consideración que la implementación del proyecto normativo propuesto forma parte del desarrollo y modernización de los sistemas de información que viene promoviendo el OSIPTEL y asume que las empresas operadoras realizan sus operaciones con un nivel mínimo de

A más detalle, asegura que resulta ser sumamente compleja la creación del sistema de bajas y migraciones, por distintas realidades que no se han considerado, las mismas que, según señala, incluyen las siguientes:

1. Cuenta con más de una fuente (sistemas comerciales, plataformas y herramientas) de los cuales se deben realizar las extracciones requeridas. Estos sistemas son distintos, por lo que resulta extremadamente compleja la implementación del sistema propuesto. Asimismo, implicaría incurrir en costos excesivos.

2. Las extracciones diarias comprometerían la funcionalidad del sistema comercial. Esto se debe a que, al realizar trabajos de extracción diarios, se afecta el desarrollo de las actividades necesarias para el negocio durante el procesamiento de la información requerida, e incluso puede afectar solicitudes que son atendidas por estos sistemas.

3. Para el caso de extracciones, resulta necesario la gestión de presupuestos asociados a los trabajos respectivos. Sobre el particular, cabe precisar que el ejercicio de la facultad fiscalizadora de la Administración Pública debe ejecutarse en cumplimiento del principio de costo-beneficio, el mismo que rige la actuación supervisora del OSIPTEL, de acuerdo con lo establecido en la Ley N° 27336, la cual señala que “las acciones de supervisión procurarán desarrollarse evitando generar costos excesivos a las empresas supervisadas”, más aún, considerando que el presente sistema no busca solucionar un problema estadísticamente relevante ni ha evaluado de manera adecuada los sobrecostos en los que incurrirían los administrados. Es así, que el OSIPTEL tiene el deber de acreditar que efectivamente su intervención es menos onerosa que otras alternativas, lo cual no ocurre en este caso.

La referida empresa manifiesta que, en el marco del presente proceso consultivo, se debe evaluar que la creación de este sistema responde a una necesidad estadísticamente relevante y que no existen alternativas (menos intrusivas) que impliquen menos costos a los administrados. Asimismo, indica que es preciso considerar que, de manera voluntaria, ha venido presentando la información de bajas y migraciones al OSIPTEL con periodicidad semanal, periodicidad que ya implica una complejidad elevada lo cual ha sido informado al Regulador, por lo que considera sería más

eficiencia, usando adecuados sistemas de información; en ese sentido, el sistema debería permitir que se pueda cumplir con la entrega de la información durante los siete (7) días de la semana. De esta manera, en el marco del desarrollo y modernización de los sistemas de información, si alguna empresa encuentra que estos proyectos les resulta muy onerosos, es debido a que el estado actual de sus sistemas se encuentra alejado del óptimo esperado, y requieren ser mejorados. Además, se debe tener presente que el sistema de seguimiento comprende una lógica de intercambio de información de amplio dominio de las empresas operadoras, por cuanto se viene empleando desde hace varios años para el envío de los reportes de los indicadores de calidad del servicio, reportes de sustracción o pérdida de equipos terminales, así como el RENTESEG. En efecto, el sistema utilizará un servidor SFTP que es implementado por el OSIPTEL, encontrándose a cargo de la empresa la conexión a dicho servidor para remitir sus reportes sobre bajas y migraciones, lo cual, si bien implica un costo, en el corto plazo permitirá reducir los costos de intercambio de información manual en los que ya incurre la empresa operadora. Así también, de presentarse errores en este tipo de trámites, las empresas operadoras podrán tomar medidas de corrección en forma rápida, lo cual les generará beneficios por cuanto se evitarán problemas en las facturaciones, tendrán una menor demanda de sus canales de atención por parte de los usuarios, entre otros. Con relación a lo manifestado por TELEFÓNICA, en el sentido que las fotos diarias no permiten ver el ratio de ejecución en los plazos, debemos precisar que por ello se están requiriendo distintos tipos de reporte y no uno unificado. Esto es, a través de un reporte se captura la solicitud del abonado y a través de un reporte distinto se captura la ejecución de la solicitud. El sistema de seguimiento ha sido diseñado para hacer conversar ambas informaciones y, de este modo, tener un control diario de la ejecución dentro de los plazos establecidos, por lo que lo manifestado por TELEFÓNICA no resulta correcto.

razonable remitir la información de manera mensual para viabilizar el proceso de entrega de información. Sin perjuicio de ello, TELEFÓNICA estima que las fotos diarias no permiten ver el ratio de ejecución en los plazos, considerando que para las solicitudes de baja pueden haber plazos muy breves, hasta de 1 día hábil para ejecutar (tal como sucede en el servicio de internet para Telefónica) y en las solicitudes de migración, hasta 1 día para aprobarlo y 1 día hábil o 5 días hábiles para ejecutarlo (en el caso de los servicios de internet de Telefónica), por lo que resulta necesario que la información no corresponda al día anterior, sino que represente el cierre de un periodo (mensual). Esto permitiría, según ella, que las empresas puedan brindar información que permita realizar la supervisión de mejor manera, así como reduciría de manera importante los costos y riesgos en la extracción de la información.

En cuanto a la alternativa de remitir la información de manera mensual, la misma contraviene los objetivos de la norma, debido a que el OSIPTEL no contará con la información que le permita verificar la adecuada atención de las bajas y migraciones, y, en los casos que corresponda, disponer las medidas necesarias y oportunas para corregir cualquier falla que se presente, generando mayor afectación a los usuarios, quienes tampoco podrán verificar, de manera actualizada, el estado de sus solicitudes.

CLARO

CLARO reitera la necesidad de que los reportes denominados BASS y MISS sean eliminados del instructivo que finalmente sea aprobado, en tanto considera que no resultan proporcionales a la finalidad que inspiró la creación del proyecto. También reitera que la totalidad de la información contemplada en dichos reportes puede ser calificada en información que: i) ya se encuentra en poder del Regulador (en el Registro de Abonados) o ii) se constituye en información sensible y personal de los clientes tutelados en la normativa de protección de datos. Es por dicha razón, que reitera su solicitud de eliminación de los reportes BASS y MISS. De otro lado, considera necesario que el proyecto contemple un mecanismo de intercambio alternativo aplicable cuando los elementos de red involucrados en la generación del reporte o en su entrega sean objeto de un proceso de mantenimiento correctivo o preventivo; o, inclusive, algún error en los servidores del OSIPTEL que impidan efectuar la entrega de los reportes. CLARO alega que las redes de las empresas operadoras constantemente se encuentran siendo objeto de diversos procesos de mantenimiento y mejoras tecnológicas, a efectos de que puedan trabajar de una manera óptima y se encuentren preparados para la prestación de los nuevos servicios que requieren los clientes. En dicho contexto, estima que resulta indispensable que la normativa vigente contemple algún mecanismo que

Respecto al pedido de CLARO de eliminar los reportes BASS y MISS, la información con la que ya contaría el Regulador y en lo referido al carácter sensible de la información que alega, nos remitimos a la respuesta brindada sobre el particular en los comentarios formulador por ella al numeral 2 del Proyecto de Instructivo. Con relación al mecanismo de intercambio alternativo, debemos manifestar que el numeral 11 del Proyecto de Instructivo establece la existencia del mismo, cuyo detalle técnico será brindado de manera previa al periodo de pruebas técnicas, de conformidad con lo señalado en la segunda disposición transitoria de la “Norma que establece el sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL. En cuanto al cronograma y manual de operatividad para las pruebas técnicas del referido sistema, estos serán comunicados por escrito por el OSIPTEL. Por otro lado, la norma a la que se hace referencia en el párrafo que antecede, en su artículo 6, contempla el escenario de indisponibilidad de los sistemas de la empresa operadora, ya sea por causas ajenas al control de la empresa operadora, así como por una situación de mantenimiento preventivo o mejoras tecnológicas, estableciéndose, para ambos casos, reglas aplicables.

permita realizar trabajos de mantenimiento y mejora tecnológica en los elementos de red involucrados en el proceso de generación y/o entrega de los reportes contemplados en el proyecto, de modo tal que se permita a las empresas operadoras realizar --cuando la necesidad técnica lo amerite—mantenimientos en sus plataformas o diferentes elementos de red que pudieran impactar en los procesos del proyecto. Por lo expuesto, CLARO propone la incorporación de reglas que permitan a las empresas operadoras realizar —en una ventana determinada— los mantenimientos y/o adecuaciones que sean necesarios en sus sistemas, sin que ello genere ninguna afectación al proceso de contemplado en el instructivo. Finalmente, la empresa manifiesta que no se ha especificado cuál es el rango horario en el cual serán entregados los reportes, en tanto que en el instructivo se señala las 9:00 de la mañana, pero especifica que la entrega podrá ser realizada entre las 00:00 horas y las 9:00 horas; o, en su defecto, la entrega de los reportes podrán ser realizados a partir de dicha hora, por lo que solicita se precise ello.

Finalmente, se tiene a bien precisar en el Instructivo Técnico que el rango horario va desde las 00:00 hasta las 09:00 horas.


4. REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN RECOGER DEL SISTEMA DE SEGUIMIENTO DEL OSIPTEL

4.1. Verificación de la consistencia de la información presentada

por las empresas operadoras - archivo de errores El Sistema de Seguimiento del OSIPTEL evalúa la información contenida en los reportes entregados por las empresas operadoras y, de ser el caso, genera archivos que contienen el detalle de los errores. La corrección de estos errores se da mediante los archivos de subsanación

4.2. Reportes de solicitudes de baja y migraciones no ejecutadas

El Sistema de Seguimiento del OSIPTEL verifica que cada solicitud de baja o migración se ejecute dentro del plazo establecido. En caso se identifique solicitudes que no han sido atendidas se genera archivos con el detalle de dichas solicitudes.

4.3. Reportes de bajas y migraciones sin sustento

4. REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN RECOGER DEL SISTEMA DE SEGUIMIENTO DEL OSIPTEL

4.1. Verificación de la consistencia de la información presentada

por las empresas operadoras - archivo de errores El Sistema de Seguimiento del OSIPTEL evalúa la información contenida en los reportes entregados por las empresas operadoras y, de ser el caso, genera archivos que contienen el detalle de los errores. La corrección de estos errores se da mediante los archivos de subsanación

4.2. Reportes de solicitudes de baja y migraciones no ejecutadas

El Sistema de Seguimiento del OSIPTEL verifica que cada solicitud de baja o migración se ejecute dentro del plazo establecido. En caso se identifique solicitudes que no han sido atendidas se genera archivos con el detalle de dichas solicitudes.

4.3. Reportes de bajas y migraciones sin sustento

El Sistema de Seguimiento del OSIPTEL evalúa la información contenida en los reportes entregados por las empresas operadoras y, de ser el caso, genera archivos que contienen el detalle de las bajas y migraciones que fueron ejecutadas sin sustento.


ERRORES _NOMBREDEARCHIVOEVALUADO.TXT

Archivo del detalle de los errores encontrados en el archivo reportado por el operador

Diario 11:00

CONCESIONARIO_BAJA_NO_EJECUTADA_YYYYMMDD.TXT

Solicitudes de baja no ejecutadas

Diario 11:00

CONCESIONARIO_MIGR_NO_EJECUTADA_YYYYMMDD.TXT

Solicitudes de migración no ejecutadas

Diario 11:00

CONCESIONARIO_BAJA_SIN_SUSTENTO_YYYYMMDD.TXT

Bajas ejecutadas sin sustento

Diario 11:00

CONCESIONARIO_MIGRACION_SIN_SUSTENTO_YYYYMMDD.TXT

Migraciones ejecutadas sin sustento

Diario 11:00

El Sistema de Seguimiento del OSIPTEL evalúa la información contenida en los reportes entregados por las empresas operadoras y, de ser el caso, genera archivos que contienen el detalle de las bajas y migraciones que fueron ejecutadas sin sustento.


ERRORES _NOMBREDEARCHIVOEVALUADO.TXT

Archivo del detalle de los errores encontrados en el archivo reportado por el operador

Diario A partir de las 11:00

CONCESIONARIO_BAJA_NO_EJECUTADA_YYYYMMDD.TXT

Solicitudes de baja no ejecutadas


CONCESIONARIO_MIGR_NO_EJECUTADA_YYYYMMDD.TXT

Solicitudes de migración no ejecutadas


TABLA 7.- Reportes por recoger, primera fase


CONCESIONARIO_BAJA_SIN_SUSTENTO_YYYYMMDD.TXT

Bajas ejecutadas sin sustento


CONCESIONARIO_MIGRACION_SIN_SUSTENTO_YYYYMMDD.TXT

Migraciones ejecutadas sin sustento


TABLA 8.- Reportes por recoger, segunda fase


ENTEL Sobre el numeral 4 del Proyecto de Instructivo, ENTEL solicita se tengan en consideración los comentarios efectuados al numeral 3 del mismo.

Con relación a los comentarios formulados por ENTEL al numeral 4 del Proyecto de Instructivo, en tanto deriva a los comentarios formulados al

numeral 3, nos remitimos a lo expuesto por el OSIPTEL en atención a estos últimos.

CLARO

Al respecto, la empresa operadora indica que el Instructivo no es claro respecto a los horarios para efectuar el recojo de la información, en tanto se señala las 11:00 horas, pero no se especifica si los archivos en mención, por ejemplo, desde las 9:00 horas hasta las 11:00 horas; o, en su defecto, se podrán recoger a partir de las 11:00 horas, por lo que solicita se precise ello.

En lo referido a este punto, se acoge el comentario de CLARO, por lo que se precisa que la hora de recojo de información es a partir de las 11:00 horas


5. ESTRUCTURA DE LOS REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN ENTREGAR AL SISTEMA DE SEGUIMIENTO DEL OSIPTEL En esta sección se detallan los aspectos relevantes que las empresas operadoras deberán tener en cuenta para elaborar los reportes de información que serán entregados al OSIPTEL: 5.1. ESTRUCTURA DEL REPORTE DE SOLICITUDES DE BAJA: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOBA: Identificador correspondiente a la solicitud de baja. - YYYY: Son los cuatro dígitos que identifican el año de entrega

de la información. - MM: Son los dos dígitos que identifican el mes de entrega de la

información. - DD: Son los dos dígitos que identifican el día de entrega de la

información. - TXT: Extensión del archivo que corresponde a formato de texto.

5. ESTRUCTURA DE LOS REPORTES QUE LAS EMPRESAS OPERADORAS DEBEN ENTREGAR AL SISTEMA DE SEGUIMIENTO DEL OSIPTEL En esta sección se detallan los aspectos relevantes que las empresas operadoras deberán tener en cuenta para elaborar los reportes de información que serán entregados al OSIPTEL. Cabe señalar que, la especificación de valor nulo – utilizada dentro de la descripción de algunos campos - es sinónimo de vacío o inexistente; ello de acuerdo a lo establecido en los modelos de base de datos relacionales. Por tanto, no se trata de una especificación de un valor con error. 5.1. ESTRUCTURA DEL REPORTE DE SOLICITUDES DE BAJA: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOBA: Identificador correspondiente a la solicitud de baja. - YYYY: Son los cuatro dígitos que identifican el año de entrega

de la información.

El archivo a remitir está en formato de texto plano, contiene diecinueve (19) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: NUMERO_SOLICITUD|FECHA_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|MODALIDAD_CONTRATO|DURACION_CONTRATO|PLAN_CONTRATADO|ESTADO_SERVICIO|FECHA_BAJA_PROGRAMADA|TIPO_CANAL|DIRECCION_CANAL|UBIGEO_CANAL|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUMER

O_DOCUMENTO

A continuación, se detallan cada uno de los campos:

1. Número de Solicitud: número asignado al trámite de baja en el sistema comercial del concesionario.

Características:

- Longitud máxima: 20 caracteres. - Tipo: alfanumérico. - No debe haber espacios en blanco ni al inicio ni al final. - Este campo es obligatorio, no puede ser nulo.

2. Fecha de Solicitud: fecha en que el abonado presentó la solicitud

de baja. Características:

- Longitud fija: 8 caracteres. - Tipo: caracter.

Estructura: YYYY: Representa el año. MM: Representa dos dígitos del mes. DD: Representa al día.

- No debe haber espacios en blanco ni al inicio ni al final. - Utilizar el formato de fecha (YYYYMMDD). - Este campo es obligatorio, no puede ser nulo. - La fecha y hora consignada no puede ser mayor a la

fecha del archivo.

- MM: Son los dos dígitos que identifican el mes de entrega de la información.

- DD: Son los dos dígitos que identifican el día de entrega de la información.

- TXT: Extensión del archivo que corresponde a formato de texto.

El archivo a remitir está en formato de texto plano, contiene diecinueve (19) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: CODIGO_PEDIDO|FECHA_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|MODALIDAD_CONTRATO|DURACION_CONT

RATO|PLAN_CONTRATADO |FECHA_BAJA_PROGRAMADA|TIPO_CANAL|

TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUMERO_DOCU

MENTO


1. Código de Pedido: código o número correlativo de identificación del pedido de baja realizado, conforme a lo definido en el literal (ii) del artículo 118 del TUO de las CDU.

Características:





Estructura: YYYY: Representa el año.

3. Tipo de Servicio: tipo del servicio que se dará de baja.

Características: - Longitud fija: 1 caracter. - Tipo: numérico. - Valores:

1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable

6 Empaquetado (duo, trio, otro) que incluye teléfono fijo

7 Empaquetado (duo, trio, otro) que no incluye teléfono fijo

- No debe haber espacios en blanco ni al inicio ni al final. - Este campo es obligatorio, no puede ser nulo.

4. Identificador de Servicio: número que identifica al servicio que

se dará de baja.

Características:

- De acuerdo al tipo de servicio

MM: Representa dos dígitos del mes. DD: Representa al día.


fecha del archivo.


Características:

- Longitud fija: 1 caracter. - Tipo: numérico. - Valores:

1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable

6 Empaquetado (dúo, trio, otro) que incluye teléfono fijo

7 Empaquetado (dúo, trio, otro) que no incluye teléfono fijo



se dará de baja.

Características:


Tipo de Servicio Identificador

1. Telefonía fija

Número telefónico - Tipo numérico - Longitud fija 8 caracteres - Código Provincia + Número Telefónico

2. Telefonía móvil

Número telefónico - Tipo numérico - Longitud fija 9 caracteres - Comienza en 9

3. Internet fijo Identificador - Tipo alfanumérico - Longitud máxima 20 caracteres

4. Internet móvil Identificador - Tipo alfanumérico - Longitud máxima 20 caracteres

5. TV Cable Identificador - Tipo alfanumérico - Longitud máxima 20 caracteres

6. Empaquetado (duo, trio, otro) que incluye teléfono fijo


7. Empaquetado (duo, trio, otro) que no incluye teléfono fijo

Identificador - Tipo alfanumérico - Longitud máxima 20 caracteres


5. Modalidad de Contrato: modalidad de pago del servicio que se

dará de baja.

Características:


1 Prepago

2 Postpago

3 Control


1. Telefonía fija













dará de baja.

Características:


1 Prepago

2 Postpago

3 Control


6. Duración de Contrato: duración del contrato del servicio que se

dará de baja.

Características:


1 Plazo indeterminado

2 Plazo forzoso


7. Plan Contratado: plan contratado del servicio que se dará de baja.

Características:

- Longitud máxima: 200 caracteres. - Tipo: alfanumérico. - Este campo es obligatorio, no puede ser nulo.

8. Estado del Servicio: Estado del servicio al momento de

presentada la solicitud de baja. Características:


1 Activo

2 Suspendido

3 Con corte



6. Duración de Contrato: duración del contrato del servicio que se

dará de baja; corresponde a la definición establecida en los artículos 76 y 77 del TUO de las CDU.

Características:


1 Plazo indeterminado

2 Plazo forzoso

- No debe haber espacios en blanco ni al inicio ni al final. - Este campo es aplicable para servicios control y

postpago. En el caso de servicios prepago, este campo será nulo.

7. Plan Contratado: plan contratado del servicio que se dará de baja.

Características:


8. Fecha de Baja Programada: Fecha de baja establecida por el

abonado. Solo se debe llenar cuando el abonado indique una fecha distinta al plazo establecido por defecto.

Características:

- Longitud fija: 8 caracteres. - Tipo: caracter. - Estructura: YYYYMMDD

YYYY: Representa el año.

9. Fecha de Baja Programada: Fecha de baja establecida por el abonado. Solo se debe llenar cuando el abonado indique una fecha distinta a los cinco (5) días hábiles por defecto.

Características:


YYYY: Representa el año. MM: Representa dos dígitos del mes. DD: Representa al día.

- No debe haber espacios en blanco ni al inicio ni al final. 10. Tipo de Canal: tipo de canal a través del cual se realizó la solicitud



1 Presencial (documento escrito)

2 Telefónico (grabación audio)

3 Redes Sociales (WhatsApp, otros)

4 Medios informáticos que incluyan el uso de contraseñas


11. Dirección del Canal: dirección del canal en el que se presentó la

solicitud de baja.

Características:

- Longitud máxima: 150 caracteres. - Tipo: alfanumérico. - Este campo solo debe llenarse si “Tipo de Canal” es

igual a “1”.


- No debe haber espacios en blanco ni al inicio ni al final. - En caso el abonado no indique una fecha este campo

puede ser nulo entendiéndose que la baja se ejecutará en el plazo establecido en la normativa vigente

9. Tipo de Canal: tipo de canal a través del cual se realizó la solicitud





3 Aplicativo web

4 Aplicativo móvil

5 WhatsApp

6 Otros, aprobados por el OSIPTEL


10. Tipo de Abonado: tipo de abonado que tiene a su nombre el

servicio que se dará de baja.

Características:


1 Persona Natural

2 Persona Jurídica

- No debe haber espacios en blanco ni al inicio ni al final.

12. UBIGEO del Canal: UBIGEO del canal en el que se presentó la solicitud de baja.

Características:

- Longitud fija: 6 caracteres. - Tipo: numérico. - Este campo solo debe llenarse si “Tipo de Canal” es

igual a “1”. 13. Tipo de Abonado: tipo de abonado que tiene a su nombre el

servicio que se dará de baja.

Características:


1 Persona Natural

2 Persona Jurídica

- No debe haber espacios en blanco ni al inicio ni al final. - Este campo es obligatorio, no puede ser nulo. - Todos los abonados que se identifiquen con RUC,

deben ser considerados personas jurídicas.

14. Nombres del Abonado: nombres del abonado del servicio que se dará de baja.

Características:

- Longitud máxima: 60 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - Este campo solo debe llenarse si “Tipo de Abonado” es

igual a “1”.

15. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se dará de baja.

- Todos los abonados que se identifiquen con RUC, deben ser considerados personas jurídicas.

- En caso se trate de un abonado de servicio móvil, este campo podrá ser nulo, la información correspondiente se extraerá del RENTESEG.

11. Nombres del Abonado: nombres del abonado del servicio que se

dará de baja.

Características:


igual a “1”. - En caso se trate de un abonado de servicio móvil, este

campo podrá ser nulo, la información correspondiente se extraerá del RENTESEG.

12. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se dará de baja.

Características:

- Longitud máxima: 40 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - En caso el abonado no tenga apellido paterno, de

acuerdo a RENIEC, se deberá consignar un punto (.). - Solo se puede consignar un punto (.) en uno de los

apellidos del abonado. - Este campo solo debe llenarse si “Tipo de Abonado” es



13. Apellido Materno del Abonado: apellido materno del abonado del servicio que se dará de baja.

Características:




igual a “1”.

16. Apellido Materno del Abonado: apellido materno del abonado del servicio que se dará de baja. Características:

- Longitud máxima: 40 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - En caso el abonado no tenga apellido materno, de



igual a “1”.

17. Razón Social: razón social del abonado del servicio que se dará de baja. Características:


igual a “2”.

18. Tipo de Documento Legal: tipo de documento legal de identificación del abonado del servicio que se dará de baja.

Características:






14. Razón Social: razón social del abonado del servicio que se dará





15. Tipo de Documento Legal: tipo de documento legal de

identificación del abonado del servicio que se dará de baja.

Si el “Tipo de abonado” es igual a “1” (Persona Natural), el Tipo de Documento Legal tendrá que ser diferente de “2” (No podrá ser RUC).

Si el “Tipo de abonado” es igual a “2” (Persona Jurídica), el Tipo de Documento Legal tendrá que ser igual a “2”.



Características:


1 DNI

2 RUC

3 Carné de Extranjería

4 Pasaporte

5 Documento Legal de Identidad válido requerido por la SNM.


19. Número de Documento Legal: número del documento legal de


Características:

- Longitud máxima: 20 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - Si el tipo de documento legal es “1” (DNI), la longitud

debe ser igual a 8 (valores numéricos). - Si el tipo de documento legal es “2” (RUC), la longitud

debe ser igual a 11 (valores numéricos). - Si el tipo de documento legal es diferente de “1” (DNI)

y “2” (RUC), la longitud debe ser menor o igual a 20.

5.2. ESTRUCTURA DEL REPORTE DE BAJA CON SOLICITUD: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:


1 DNI

2 RUC


4 Pasaporte


- No debe haber espacios en blanco ni al inicio ni al final. - En caso se trate de un abonado de servicio móvil, este




Características:




y “2” (RUC), la longitud debe ser menor o igual a 20. - En caso se trate de un abonado de servicio móvil, este


5.2. ESTRUCTURA DEL REPORTE DE BAJA CON SOLICITUD: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - BACS: Identificador correspondiente a la baja efectuada como

consecuencia de la solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene cinco (5) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación:

NUMERO_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICI

O|FECHA_BAJA_EFECTIVA|DEUDA 1. Número de Solicitud: número de solicitud que corresponde a la

baja ejecutada.

Características:



Características:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - BACS: Identificador correspondiente a la baja efectuada como

consecuencia de la solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene cinco (5) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación:

CODIGO_PEDIDO|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|F

ECHA_BAJA_EFECTIVA_DESISTIMIENTO|DESISTIMIENTO 1. Código de Pedido: código de pedido que corresponde a la baja

ejecutada.

Características:



Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se dio de baja. Características:



1. Telefonía fija











1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se dio de baja.

Características:



1. Telefonía fija







6. Empaquetado (dúo, trio, otro) que incluye teléfono fijo


7. Empaquetado (dúo, trio, otro) que no incluye teléfono fijo



4. Fecha de baja efectiva: fecha en que se ejecutó la baja.

Características:




fecha del archivo. 5. Deuda: deuda del abonado, en nuevos soles, al momento de la

baja. Se reporta un valor positivo si el abonado debe al concesionario y un valor negativo si el concesionario debe al abonado (renta adelantada para postpago o saldo prepago existente)

Características:

- Longitud máxima: 20 caracteres. - Tipo: numérico. - Se acepta una coma o un punto decimal. - Se acepta signo negativo (-) al inicio del número

5.3. ESTRUCTURA DEL REPORTE DE BAJA SIN SOLICITUD: El archivo a remitir al OSIPTEL tiene el siguiente nombre:



4. Fecha de baja efectiva/desistimiento: fecha en que se ejecutó la

baja o el abonado desistió de la misma. Características:




fecha del archivo. 5. Desistimiento: flag que indica si la solicitud de baja fue desistida.

Características:

- Longitud fija: 1 caracter. - Tipo: numérico. - Valor: ‘D’ - No debe haber espacios en blanco ni al inicio ni al final. - Este campo solo se llena para los casos de

desistimiento de la solicitud de baja, en caso contrario debe ser nulo.

5.3. ESTRUCTURA DEL REPORTE DE BAJA SIN SOLICITUD: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - BASS: Identificador correspondiente a la baja efectuada sin que

exista una solicitud explícita del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene quince (15) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|MODALIDAD_CONTRATO|PLAN_CONTRATADO|MOTIVO_BAJA|FECHA_RELACIONADA_BAJA|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUM

ERO_DOCUMENTO|FECHA_BAJA_EFECTIVA|DEUDA

1. Tipo de Servicio: tipo del servicio que se dio de baja.

Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable




Características:

- CONCESIONARIO: Es el código asignado al concesionario. - BASS: Identificador correspondiente a la baja efectuada sin que

exista una solicitud explícita del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene quince (15) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|MODALIDAD_CONTRATO|PLAN_CONTRATADO|MOTIVO_BAJA|FECHA_RELACIONADA_BAJA|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUM

ERO_DOCUMENTO|FECHA_BAJA_EFECTIVA

1. Tipo de Servicio: tipo del servicio que se dio de baja.

Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable




2. Identificador de Servicio: número que identifica al servicio que se dio de baja.

Características:



1. Telefonía fija













dio de baja.

Características:

- Longitud fija: 1 caracter.

- Este campo es obligatorio, no puede ser nulo.

2. Identificador de Servicio: número que identifica al servicio que se dio de baja.

Características:



1. Telefonía fija













dio de baja.

- Tipo: numérico. - Valores:

1 Prepago

2 Postpago

3 Control


4. Plan Contratado: plan contratado del servicio que se dio de baja.

Características:


5. Motivo de Baja: Motivo por el que se dio de baja al servicio.

Características:

- Longitud fija: 2 caracteres. - Tipo: numérico. - Valores:

1 Cuestionamiento de titularidad

2 Portabilidad

3 Sin recarga dentro del plazo máximo (prepago)

4 Falta de pago

5 Fallecimiento abonado, insolvencia o extinción persona jurídica

6 Falta de instalación y/o activación del servicio

7 Traslado pendiente más de 3 meses

8 Uso indebido

9 Uso prohibido

10 Normativa RENTESEG

11 Problemas de calidad de servicio

12 Aplicación de tarifas distintas a las contratadas, no favorables

13 Eliminación de señal de cable

14 Inexistencia del mecanismo contratación

15 Sin sustento

Características:


1 Prepago

2 Postpago

3 Control


4. Plan Contratado: plan contratado del servicio que se dio de baja.

Características:


5. Motivo de Baja: Motivo por el que se dio de baja al servicio.

Características:

- Longitud fija: 2 caracteres. - Tipo: numérico. - Valores:


6. Fecha Relacionada a la Baja: Fecha de evento y/o documento

relacionado a la baja, de acuerdo al motivo reportado:

Motivo Fecha a reportar

1. Cuestionamiento de titularidad Fecha de solicitud de cuestionamiento

2. Portabilidad Fecha de solicitud de portabilidad

3.Sin recarga dentro del plazo máximo (prepago)

Fecha de última recarga

4. Falta de pago Fecha de vencimiento de la deuda

6. Falta de instalación y/o activación del servicio

Fecha de comunicación del abonado informando la situación

7.Traslado pendiente más de 3 meses Fecha de comunicación del abonado informando la situación

10. Normativa RENTESEG Fecha de suspensión RENTESEG

11. Problemas de calidad de servicio Fecha de comunicación del abonado informando la situación

12. Aplicación de tarifas distintas a las contratadas, no favorables

Fecha de comunicación del abonado informando la situación

13. Eliminación de señal de cable Fecha de comunicación del abonado informando la situación

14.Inexistencia del mecanismo contratación Fecha en que se advirtió la inexistencia

15. Otros No aplica

Características:




1 Portabilidad

2 Sin recarga dentro del plazo máximo (prepago), conforme a lo establecido en el artículo 14 del TUO de las CDU

3 Falta de pago, conforme a lo establecido en el numeral (ii) del artículo 76 y el numeral (i) - resolución unilateral de la empresa - del artículo 77 del TUO de las CDU

4 Fallecimiento abonado, insolvencia o extinción persona jurídica

5 Falta de instalación y/o activación del servicio, conforme a lo establecido en el numeral (v) del artículo 76 y el numeral (iii) – resolución unilateral del abonado - del artículo 77 del TUO de las CDU

6 Traslado pendiente más de 3 meses, conforme a lo establecido en el numeral (vi) del artículo 76 y el numeral (iv) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

7 Uso indebido

8 Uso prohibido

9 Problemas de calidad de servicio, conforme a lo establecido en el numeral (i) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

10 Aplicación de tarifas distintas a las contratadas, no favorables, conforme a lo establecido en el numeral (ii) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

11 Eliminación de señal de cable, conforme a lo establecido en el numeral (v) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

12 Inexistencia del mecanismo contratación, conforme a lo establecido en el artículo 121-A del TUO de las CDU

13 Otros


6. Fecha Relacionada a la Baja: Fecha de evento y/o documento

relacionado a la baja, de acuerdo al motivo reportado. Solo debe ser llenado para los motivos especificados en la siguiente tabla según el detalle mostrado

7. Tipo de Abonado: tipo de abonado que tiene a su nombre el servicio que se dio de baja.

Características:


1 Persona Natural

2 Persona Jurídica



8. Nombres del Abonado: nombres del abonado del servicio que se dio de baja.

Características:


igual a “1”.

9. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se dio de baja.

Características:



apellidos del abonado.

Motivo Fecha a reportar

1. Portabilidad Fecha de solicitud de portabilidad

2.Sin recarga dentro del plazo máximo (prepago)

Fecha de última recarga, conforme a lo establecido en el artículo 14 del TUO de las CDU

3. Falta de pago Fecha de vencimiento de la deuda, conforme a lo establecido en el numeral (ii) del artículo 76 y el numeral (i) - resolución unilateral de la empresa - del artículo 77 del TUO de las CDU

5. Falta de instalación y/o activación del servicio

Fecha de comunicación del abonado informando la situación, conforme a lo establecido en el numeral (v) del artículo 76 y el numeral (iii) – resolución unilateral del abonado - del artículo 77 del TUO de las CDU

6.Traslado pendiente más de 3 meses Fecha de comunicación del abonado informando la situación, conforme a lo establecido en el numeral (vi) del artículo 76 y el numeral (iv) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

- Este campo solo debe llenarse si “Tipo de Abonado” es igual a “1”.

10. Apellido Materno del Abonado: apellido materno del abonado del servicio que se dio de baja. Características:




igual a “1”.

11. Razón Social: razón social del abonado del servicio que se dio de baja. Características:


igual a “2”.

12. Tipo de Documento Legal: tipo de documento legal de identificación del abonado del servicio que se dio de baja.



9. Problemas de calidad de servicio Fecha de comunicación del abonado informando la situación, conforme a lo establecido en el numeral (i) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

10. Aplicación de tarifas distintas a las contratadas, no favorables

Fecha de comunicación del abonado informando la situación, conforme a lo establecido en el numeral (ii) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

11. Eliminación de señal de cable Fecha de comunicación del abonado informando la situación, conforme a lo establecido en el numeral (v) - resolución unilateral del abonado - del artículo 77 del TUO de las CDU

12.Inexistencia del mecanismo contratación Fecha en que se advirtió la inexistencia, conforme a lo establecido en el artículo 121-A del TUO de las CDU

Características:



- No debe haber espacios en blanco ni al inicio ni al final. Esta fecha sirve para verificar si la baja fue ejecutada dentro del plazo establecido en la normativa vigente. Por ejemplo, en caso se

Características:


1 DNI

2 RUC


4 Pasaporte




identificación del abonado del servicio que se dio de baja.

Características:




y “2” (RUC), la longitud debe ser menor o igual a 20. 14. Fecha de baja efectiva: fecha en que se ejecutó la baja.

Características:




reportarse una baja por Portabilidad (motivo 1), debería existir una diferencia de 1 días entre la Fecha Relacionada a la Baja (campo 6) y la Fecha de Baja Efectiva (campo 14), conforme a lo establecido en el artículo 12-A del TUO de las CDU. 7. Tipo de Abonado: tipo de abonado que tiene a su nombre el

servicio que se dio de baja.

Características:


1 Persona Natural

2 Persona Jurídica

- No debe haber espacios en blanco ni al inicio ni al final. - Todos los abonados que se identifiquen con RUC,

deben ser considerados personas jurídicas. - En caso se trate de un abonado de servicio móvil, este



dio de baja.

Características:




9. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se dio de baja.

- Utilizar el formato de fecha (YYYYMMDD). - Este campo es obligatorio, no puede ser nulo. - La fecha y hora consignada no puede ser mayor a la

fecha del archivo. 15. Deuda: deuda del abonado, en nuevos soles, al momento de la

baja. Se reporta un valor positivo si el abonado debe al concesionario y un valor negativo si el concesionario debe al abonado (renta adelantada para postpago o saldo prepago existente)

Características:

- Longitud máxima: 20 caracteres. - Tipo: numérico. - Se acepta una coma o un punto decimal. - Se acepta signo negativo (-) al inicio del número

5.4. ESTRUCTURA DEL REPORTE DE SOLICITUDES DE

MIGRACIÓN: El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOMI: Identificador correspondiente a la solicitud de migración. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene veinte (20) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación:

Características:






10. Apellido Materno del Abonado: apellido materno del abonado del servicio que se dio de baja. Características:






11. Razón Social: razón social del abonado del servicio que se dio de

baja. Características:

- Longitud máxima: 100 caracteres.

NUMERO_SOLICITUD|FECHA_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|PLAN_ORIGEN|PLAN_DESTINO|CICLO_FACTURACIÓN|FECHA_MIGRACION_PROGRAMADA|MOTIVO_MIGRACIÓN|FECHA_ACEPTACIÓN_MIGRACIÓN|CANAL|DIRECCION_CANAL|UBIGEO_CANAL|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DO

CUMENTO|NUMERO_DOCUMENTO


1. Número de Solicitud: número asignado al trámite de migración en el sistema comercial del concesionario.

Características:



de migración. Características:




fecha del archivo.

3. Tipo de Servicio: tipo del servicio que se migrará.

- Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - Este campo solo debe llenarse si “Tipo de Abonado” es







Características:


1 DNI

2 RUC


4 Pasaporte






Características:

- Longitud máxima: 20 caracteres.

Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se migrará.

Características:



1. Telefonía fija







- Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final. - Si el tipo de documento legal es “1” (DNI), la longitud





14. Fecha de Baja Efectiva: fecha en que se ejecutó la baja.

Características:




fecha del archivo.

5.4. ESTRUCTURA DEL REPORTE DE SOLICITUDES DE MIGRACIÓN:

El archivo a remitir al OSIPTEL tiene el siguiente nombre:


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOMI: Identificador correspondiente a la solicitud de migración.






5. Plan Origen: plan del abonado antes de la migración.

Características:


6. Plan Destino: plan al que migrará el abonado.

Características:


7. Ciclo de Facturación: El valor corresponde al día del mes en que

se efectúa la facturación. Características:

- Longitud máxima: 2 caracteres. - Tipo: numérico, menor o igual a treinta y uno - No debe haber espacios en blanco ni al inicio ni al final. - Este campo es obligatorio, no puede ser nulo.

8. Fecha de Migración Programada: Fecha de migración

programada. Solo se debe llenar cuando la migración no se efectúe en el siguiente ciclo de facturación.

- YYYY: Son los cuatro dígitos que identifican el año de entrega de la información.

- MM: Son los dos dígitos que identifican el mes de entrega de la información.



El archivo a remitir está en formato de texto plano, contiene veinte (20) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: CODIGO_PEDIDO|FECHA_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|PLAN_ORIGEN|PLAN_DESTINO|CICLO_FACTURACIÓN|FECHA_MIGRACION_PROGRAMADA|FECHA_ACEPTACIÓN_MIGRACIÓN|CANAL|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DO

CUMENTO|NUMERO_DOCUMENTO


1. Código de Pedido: código o número correlativo de identificación del pedido de migración realizado, conforme a lo definido en el literal (ii) del artículo 118 del TUO de las CDU..

Características:





Estructura:

Características:




9. Motivo de Migración: Motivo de migración del servicio. Características:


1 Solicitud abonado cambio de plan

2 Habilitación tope de consumo

3 Desistimiento de migración previa


10. Fecha de Aceptación de Migración: Fecha de aceptación de la

solicitud de migración. Por defecto es el mismo día, sin embargo, la empresa puede tomar hasta tres (3) días hábiles para aceptar la solicitud de migración.

Características:






fecha del archivo.

3. Tipo de Servicio: tipo del servicio que se migrará.

Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se migrará.

Características:



1. Telefonía fija


11. Tipo de Canal: tipo de canal a través del cual se realizó la solicitud de migración.

Características:




3 Redes Sociales (WhatsApp, otros)

4 Medios informáticos que incluyan el uso de contraseñas


12. Dirección del Canal: dirección del canal en el que se presentó la

solicitud de migración.

Características:

- Longitud máxima: 150 caracteres. - Tipo: alfanumérico. - Este campo solo debe llenarse si “Tipo de Canal” es

igual a “1”. 13. UBIGEO del Canal: UBIGEO del canal en el que se presentó la

solicitud de migración.

Características:

- Longitud fija: 6 caracteres. - Tipo: numérico. - Este campo solo debe llenarse si “Tipo de Canal” es

igual a “1”. 14. Tipo de Abonado: tipo de abonado que tiene a su nombre el

servicio que se migrará.

Características:












Características:


6. Plan Destino: plan al que migrará el abonado.

Características:



se efectúa la facturación.


1 Persona Natural

2 Persona Jurídica



15. Nombres del Abonado: nombres del abonado del servicio que se migrará.

Características:


igual a “1”.

16. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se migrará.

Características:




igual a “1”.

17. Apellido Materno del Abonado: apellido materno del abonado del servicio que se migrará.

Características:


8. Fecha de Migración Programada: Fecha de migración

programada. Solo se debe llenar cuando la migración no se efectúe en el siguiente ciclo de facturación.

Características:




Conforme a la normativa vigente, este campo solo debería ser llenado por la empresa Telefónica del Perú S.A.A., para su servicio de internet fijo, de acuerdo a lo dispuesto en el artículo 7 de las “Normas Especiales para la prestación del servicio de internet fijo aplicables a Telefónica del Perú S.A.A.", que establece un plazo diferenciado para ejecutar la migración.

9. Fecha de Aceptación de Migración: Fecha de aceptación de la solicitud de migración. Por defecto es el mismo día, sin embargo, la empresa puede tomar hasta tres (3) días hábiles para aceptar la solicitud de migración.

Características:


YYYY: Representa el año.

Características:




igual a “1”.

18. Razón Social: razón social del abonado del servicio que se migrará. Características:


igual a “2”.

19. Tipo de Documento Legal: tipo de documento legal de identificación del abonado del servicio que se migrará.



Características:



- No debe haber espacios en blanco ni al inicio ni al final. 10. Tipo de Canal: tipo de canal a través del cual se realizó la solicitud





3 Aplicativo web

4 Aplicativo móvil

5 WhatsApp

6 Otros, aprobados por el OSIPTEL



servicio que se migrará.

Características:


1 Persona Natural

2 Persona Jurídica



1 DNI

2 RUC


4 Pasaporte




identificación del abonado del servicio que se migrará.

Características:





5.5. ESTRUCTURA DEL REPORTE DE MIGRACIONES EJECUTADAS CON SOLICITUD:



Características:

- CONCESIONARIO: Es el código asignado al concesionario. - MICS: Identificador correspondiente a la migración efectuada

como consecuencia de la solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega


información.



migrará.

Características:




13. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se migrará.

Características:






14. Apellido Materno del Abonado: apellido materno del abonado del servicio que se migrará.



El archivo a remitir está en formato de texto plano, contiene cuatro (4) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: NUMERO_SOLICITUD|TIPO_SERVICIO|IDENTIFICADOR_SERVICI

O|FECHA_MIGRACION_EFECTIVA 1. Número de Solicitud: número de solicitud que corresponde a la

migración ejecutada.

Características:


2. Tipo de Servicio: tipo del servicio que se migró.

Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable




Características:






15. Razón Social: razón social del abonado del servicio que se

migrará. Características:








3. Identificador de Servicio: número que identifica al servicio que se migró.

Características:



1. Telefonía fija












4. Fecha de Migración Efectiva: fecha en que se ejecutó la

migración. Características:

- Longitud fija: 8 caracteres.

Características:


1 DNI

2 RUC


4 Pasaporte






Características:






5.5. ESTRUCTURA DEL REPORTE DE MIGRACIONES

EJECUTADAS CON SOLICITUD: El archivo a remitir al OSIPTEL tiene el siguiente nombre:

- Tipo: caracter. Estructura: YYYY: Representa el año. MM: Representa dos dígitos del mes. DD: Representa al día.


fecha del archivo.

5.6. ESTRUCTURA DEL REPORTE DE MIGRACIONES EJECUTADAS SIN SOLICITUD:



Características:

- CONCESIONARIO: Es el código asignado al concesionario. - MISS: Identificador correspondiente a la migración efectuada

sin que exista una solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene catorce (14) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|PLAN_ORIGEN|PLAN_DESTINO|CICLO_FACTURACIÓN|MOTIVO_MIGRACIÓN|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUMERO_DOCUMENT

O|FECHA_MIGRACION_EFECTIVA


Características:

- CONCESIONARIO: Es el código asignado al concesionario. - MICS: Identificador correspondiente a la migración efectuada

como consecuencia de la solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene cuatro (4) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: CODIGO_PEDIDO|TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|FECHA_MIGRACION_EFECTIVA_DESISTIMIENTO|DESISTIMIENT

O 1. Código de Pedido: código de pedido que corresponde a la

migración ejecutada.

Características:



Características:




Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se migró.

Características:



1. Telefonía fija





4. Internet móvil Identificador - Tipo alfanumérico

1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable





se migró.

Características:



1. Telefonía fija











- Longitud máxima 20 caracteres








Características:


4. Plan Destino: plan al que migró el abonado.

Características:






4. Fecha de Migración Efectiva/Desistimiento: fecha en que se

ejecutó la migración o el abonado desistió de la misma. Características:




fecha del archivo.

5. Desistimiento: flag que indica si la solicitud de baja fue desistida.

Características:

- Longitud fija: 1 caracter. - Tipo: numérico. - Valor: ‘D’ - No debe haber espacios en blanco ni al inicio ni al final. - Este campo solo se llena para los casos de

desistimiento de la solicitud de migración, en caso contrario debe ser nulo.

5.6. ESTRUCTURA DEL REPORTE DE MIGRACIONES EJECUTADAS SIN SOLICITUD:





1 Por finalización de promoción

2 Sin sustento



servicio que se migró.

Características:


1 Persona Natural

2 Persona Jurídica



8. Nombres del Abonado: nombres del abonado del servicio que se migró.

Características:

- Longitud máxima: 60 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final.

Características:

- CONCESIONARIO: Es el código asignado al concesionario. - MISS: Identificador correspondiente a la migración efectuada

sin que exista una solicitud del abonado. - YYYY: Son los cuatro dígitos que identifican el año de entrega




El archivo a remitir está en formato de texto plano, contiene catorce (14) campos que deberán estar separados por el carácter PIPE (|) como se muestra a continuación: TIPO_SERVICIO|IDENTIFICADOR_SERVICIO|PLAN_ORIGEN|PLAN_DESTINO|CICLO_FACTURACIÓN|TIPO_ABONADO|NOMBRES|APELLIDO_PATERNO|APELLIDO_MATERNO|RAZON_SOCIAL|TIPO_DOCUMENTO|NUMERO_DOCUMENTO|FECHA_MIGRACION

_EFECTIVA|MOTIVO_MIGRACION



Características:


1 Telefonía fija

2 Telefonía móvil

3 Internet fijo

4 Internet móvil

5 TV Cable




9. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se migró.

Características:




igual a “1”.

10. Apellido Materno del Abonado: apellido materno del abonado del servicio que se migró. Características:




igual a “1”.

11. Razón Social: razón social del abonado del servicio que se migró. Características:

- Longitud máxima: 100 caracteres. - Tipo: caracter. - No debe haber espacios en blanco ni al inicio ni al final.



se migró.

Características:



1. Telefonía fija















identificación del abonado del servicio que se migró.



Características:


1 DNI

2 RUC


4 Pasaporte





Características:





Características:


4. Plan Destino: plan al que migró el abonado.

Características:





6. Tipo de Abonado: tipo de abonado que tiene a su nombre el servicio que se migró.

Características:


1 Persona Natural

2 Persona Jurídica



14. Fecha de Migración Efectiva: fecha en que se ejecutó la migración.

Características:




fecha del archivo.



migró.

Características:




8. Apellido Paterno del Abonado: apellido paterno del abonado del servicio que se migró.

Características:






9. Apellido Materno del Abonado: apellido materno del abonado del servicio que se migró.

Características:






10. Razón Social: razón social del abonado del servicio que se migró.

Características:








Características:

- Longitud fija: 1 caracter.

- Tipo: numérico. - Valores:

1 DNI

2 RUC


4 Pasaporte






Características:






13. Fecha de Migración Efectiva: fecha en que se ejecutó la migración.

Características:


Estructura:



fecha del archivo. -



1 Habilitación tope de consumo, conforme a lo establecido en el artículo 51-

A del TUO de las CDU

2 Desistimiento de migración previa, conforme a lo establecido en el artículo 64-A del TUO de las CDU

3 Otros



ENTEL Sobre el numeral 5.1., ENTEL formula las siguientes consultas:

- En el campo “Fecha de baja programada”, se establece que solo

se debe llenar cuando el abonado indique una fecha distinta a los cinco (05) días hábiles establecidos en la normativa. ¿Es decir, cuando el abonado no señale la fecha de baja o cuando el plazo sea de cinco (05) días hábiles, debe ir el campo en blanco? Al respecto, solicita se precisa ello en el instructivo, dado que se indica que no debe haber espacios en blanco ni al inicio ni al final.

En cuanto a lo señalado por ENTEL respecto del numeral 5.1. del Proyecto de Instructivo, se tiene a bien acoger los comentarios planteados en el sentido que:

(i) Se precisa que la fecha de baja programada puede ir vacía. (ii) Se adiciona la opción “Otros” en el campo tipo de canal. (iii) Se retira los campos “dirección de canal” y “ubigeo de canal”.

- En cuanto al campo “Tipo de Canal”, solicita considerar el campo “otros”, indicando que se vienen aprobando distintos mecanismos digitales que permiten al cliente la posibilidad de realizar bajas por canales distintos al presencial o telefónico, incluso a través de aplicativos informáticos, por lo que estima que no debería hacerse referencia solo a los canales tradicionales.

- Sobre el campo “dirección del canal”, solicita se pueda eliminar del formato, por cuanto, según indica, el OSIPTEL tiene acceso a dicha información en virtud de las obligaciones establecidas en el TUO de Condiciones de Uso y través de la página web de las empresas operadoras, por lo que en atención al artículo 48 del Decreto Supremo Nº 004-2019-JUS, Decreto Supremo que aprueba el Texto Único Ordenado de la Ley Nº 27444 - Ley del Procedimiento Administrativo General, el Regulador ya contaría con la información requerida en este campo, por lo que no debería duplicarse el requerimiento de información.

Acerca del numeral 5.3, ENTEL formula las siguientes consultas:

- En el campo “Motivo de baja” se establece en el numeral 14 el motivo “Sin sustento”. Respecto a ello, solicita precisar qué tipo de casuística debe ser incluida en dicho motivo o, en todo caso, precisar si en dicho campo se deben considerar “otros motivos” que identifique la empresa operadora.

- Respecto al motivo “normativa RENTESEG”, solicita considerar que la fecha que se indique sea en la que se da de baja la línea, no desde la fecha de suspensión del servicio (tal como señala el Proyecto de Instructivo Técnico). Cita, a manera de ejemplo, que en las disposiciones de la Séptima Disposición Complementaria Transitoria de las Normas Complementarias para la Implementación de RENTESEG se establece la obligación de suspender la línea del abonado vinculado a uno o más equipos terminales móviles con IMEI inválido por más de una vez y; luego de transcurrido treinta (30) días calendario, en caso el abonado no haya solicitado la reconexión del servicio, se debe dar de baja dicha línea. En ese caso, la empresa operadora considera que la fecha que debe consignarse en este reporte debe ser la del día en que se realice la baja del servicio, no la fecha de suspensión.

Por lo que se refiere a los comentarios formulados por ENTEL al numeral 5.3 del Proyecto de Instructivo, se ha considerando pertinente acoger los mismos en los siguientes extremos:

(i) Sobre el campo “Motivo de baja”, se modifica la opción “Sin sustento” por “Otros”.

(ii) Se retira el motivo “normativa RENTESEG”. Estas bajas deberán ser reportadas bajo la opción “Otros” y su evaluación se realizará a partir de la información contenida en el RENTESEG.

Con relación al numeral 5.4, ENTEL formula las siguientes consultas:

- En cuanto al campo “Tipo de Canal”, solicita considerar el campo “otros”, indicando que se vienen aprobando distintos mecanismos digitales que permiten al cliente la posibilidad de realizar cambios de plan por canales distintos al presencial o telefónico, incluso a través de aplicativos informáticos, por lo que considera no debería hacerse referencia solo a los canales tradicionales.

- Sobre el campo “dirección del canal”, solicita sea eliminado del formato, por cuanto, según indica, el OSIPTEL tiene acceso a dicha información en virtud de las obligaciones establecidas en el TUO de Condiciones de Uso y través de la página web de las empresas operadoras, por lo que en atención al artículo 48 del Decreto Supremo Nº 004-2019-JUS, Decreto Supremo que aprueba el Texto Único Ordenado de la Ley Nº 27444 - Ley del Procedimiento Administrativo General, el Regulador ya contaría con la información requerida en este campo, por lo que no debería duplicarse el requerimiento de información.

Finalmente, sobre el numeral 5.6 bajo comentarios, ENTEL formula las siguientes consultas:

- En el campo “Motivo de Migración” se establece el motivo “Sin sustento”. Respecto a ello, solicita precisar qué tipo de casuística debe ser incluida en dicho motivo o, en todo caso, precisar si en dicho campo se deben considerar “otros motivos” que identifique la empresa operadora.

- Asimismo, en el campo “motivo de migración” se establece el campo “por finalización de promoción”. Al respecto, solicita precisar qué tipo de casuística debe ser considerada en dicho campo.

En lo que se refiere a los comentarios expuestos por ENTEL al numeral 5.4 del Proyecto de Instructivo, se ha considerado pertinente acoger los mismos, según el siguiente detalle:

(i) Se adiciona la opción “Otros” en el campo tipo de canal. (ii) Se retira los campos “dirección de canal” y “ubigeo de canal”.

AFIN

AFIN indica que en el proyecto de instructivo se propone el envío de seis (6) reportes con periodicidad diaria, lo cual implica sobrecostos en la actividad de las empresas, al tener que realizar casi una actualización en línea de la información. De igual manera, AFIN señala que en el proyecto de instructivo se solicita que la información de los reportes cuente con campos específicos; sin

En lo relativo a los sobrecostos a los que hace referencia AFIN, es importante precisar que, pese a contar con las facultades, este Organismo no ha dispuesto de un sistema en línea que acceda directamente a los sistemas comerciales de las empresas operadoras, sino un mecanismo para intercambiar información sobre las bajas y migraciones vía electrónica, que permita sistematizar procesos que actualmente se realizan para el seguimiento de estos trámites, a fin de facilitar la implementación.

embargo, hace hincapié en que las empresas pueden almacenar la información de distintas maneras y en distintas fuentes, por lo que considera que solicitar una estandarización de conceptos y de estructuras, implicaría sobrecostos en la implementación propuesta. Asimismo, manifiesta que la información solicitada resulta ser muy detallada y extensa, considerando necesario que se acote la misma a los campos mínimos necesarios, toda vez que, según indica, mientras mayor sea la información solicitada en cada reporte, mayor será la complejidad en la extracción. Continuando con sus comentarios, AFIN indica que siete (7) campos de información constituyen nueva información que formaría parte del ámbito de protección de datos de clientes, y que no resultan necesarios para que el Regulador pueda verificar el cumplimiento de la normativa aplicable. En este sentido, a su entender, la entrega --sin que medie la autorización expresa de los abonados titulares del servicio-- de los campos de información Plan Contratado, Deuda del Servicio, Plan Origen, Plan Destino, Ciclo de Facturación y Motivo de Migración (que forma parte de los Reportes BASS y MISS), constituye una situación que pone en altísimo riesgo información extremadamente personal y sensible del abonado titular del servicio, todo ello dentro del marco del compromiso de confidencialidad que los operadores han asumido frente a sus clientes y que la Ley de Protección de Datos Personales1, así como el Reglamento General de la Ley de Telecomunicaciones2 les exigen. AFIN agrega que la información antes descrita se constituye en información sensible y confidencial que se encuentra protegida, razón por la cual les causa mucha preocupación que sea solicitada con la finalidad de “verificar la correcta ejecución de las solicitudes de baja y migración”, en tanto que no resultaría relevante para alcanzar dicha finalidad.

De igual manera, conviene subrayar que la implementación del sistema de seguimiento ha sido sustentada respetando los Lineamientos de Calidad Regulatoria dispuestos por la Resolución N° 069-2018-CD/OSIPTEL. Así, se tiene que el sistema utilizará un servidor SFTP que es implementado por el OSIPTEL, encontrándose a cargo de las empresas la conexión a dicho servidor para remitir sus reportes sobre bajas y migraciones, lo cual, si bien implica un costo, en el corto plazo permitirá reducir los costos de intercambio de información manual en los que ya incurre la empresa operadora. Adicionalmente a ello, es de considerar que, de presentarse errores en este tipo de trámites, las empresas operadoras podrán tomar medidas de corrección en forma rápida, lo cual les generará beneficios, por cuanto se evitarán problemas en las facturaciones3, tendrán una menor demanda de sus canales de atención por parte de los usuarios, entre otros. De otro lado, con relación a la extensión en la cantidad de campos, se ha procedido a eliminar algunos de ellos, a fin de reducir la complejidad de la extracción de información por parte de las empresas operadoras, de acuerdo al siguiente detalle: REPORTE DE SOLICITUDES DE BAJA (SOBA)

(i) Estado del Servicio (ii) Dirección de Canal (iii) Ubigeo de Canal

REPORTE DE BAJA CON SOLICITUD (BACS)

(i) Deuda

1 La Ley de Protección de Datos Personales, los artículos 31 y 32 del Reglamento de la Ley de Protección de Datos Personales protegen la confidencialidad, seguridad y adecuado uso de los datos personales de los usuarios del servicio público de telecomunicaciones, en tanto que estos datos personales sólo pueden ser tratados para las finalidades específicas que en su oportunidad fueron informadas a dichos usuarios, salvo que exista una orden judicial o mandato legal expreso que fundamente específicamente su divulgación. 2 En atención al artículo 13° de Texto Único Ordenado del Reglamento General de la Ley de Telecomunicaciones aprobado por Decreto Supremo N° 020-2007-MTC , y los numerales 6 y 8 de la Norma que Establece Medidas Destinadas a Salvaguardar la Inviolabilidad y el Secreto de las Telecomunicaciones y la Protección de Datos Personales, y regula las acciones de supervisión y control a cargo del Ministerio de Transportes y Comunicaciones aprobado mediante Resolución Ministerial N° 111-2009- MTC-03, América Móvil Perú S.A.C, como concesionaria de servicios públicos de telecomunicaciones, está obligada a mantener en confidencialidad los datos personales de sus usuarios y la información que se obtenga en el desarrollo de sus operaciones. 3 Por facturaciones indebidas posteriores a la fecha que correspondía ejecutar la baja o migración

Asimismo, AFIN considera necesario que el proyecto contemple un mecanismo de intercambio alternativo aplicable cuando los elementos de red involucrados en la generación del reporte o en su entrega sean objeto de un proceso de mantenimiento correctivo o preventivo; o inclusive algún error en los servidores del OSIPTEL que impidan efectuar la entrega de los reportes. Añade que, de los 77 campos de información contenida en los reportes del proyecto (reportes SOBA, BACS, BASS, SOMI, MICS y MISS), ha podido apreciar que 48 campos ya son reportados diariamente al Regulador a través del Registro de Abonados, lo cual significa que el 62% de la información requerida actualmente en el proyecto no es nueva y ya se entrega al Regulador diariamente en cumplimiento de la normativa del RENTESEG, razón por la cual no resulta razonable solicitar a las empresas operadoras que realicen nuevos desarrollos (con la inversión que implica) para entregar nuevamente la misma información. Por lo expuesto, solicita que los campos de información que actualmente se están reportando al OSIPTEL (detallados anteriormente) de conformidad con la normativa vigente (por ejemplo, RENTESEG) no sean incluidos en la versión final del proyecto de instructivo, de conformidad a lo dispuesto en el artículo 48° del Texto Único Ordenado de la Ley del Procedimiento Administrativo General - Ley 27444, aprobado mediante Decreto Supremo Nº 004-2019-JUS.

REPORTE DE BAJA SIN SOLICITUD (BASS)

(i) Deuda REPORTE DE SOLICITUDES DE MIGRACIÓN (SOMI)

(i) Dirección de Canal (ii) Ubigeo de Canal

En este mismo sentido, específicamente respecto de los reportes BASS y MISS, AFIN considera que la entrega de la información sobre el plan contratado, deuda del servicio, plan origen, plan destino, ciclo de facturación y motivo de migración (seis campos) no resulta necesaria para que el Regulador pueda verificar el cumplimiento de la normativa aplicable. Respecto al campo deuda del servicio, este ha sido retirado de los reportes, acogiendo parcialmente el comentario formulado. No obstante, los campos Plan Contratado, Motivo Migración, Plan Origen y Plan Destino permitirán establecer si existen problemas puntuales respecto a la baja o migración de determinados planes; ello considerando los bajos incentivos que podrían tener las empresas para atender solicitudes relacionadas con planes con rentas mensuales altas. Además, debe tenerse en consideración que, en el caso de la baja de servicio, las empresas pierden al abonado y todos los ingresos que ello supone, mientras que, en el caso de las migraciones, es probable que los usuarios estén solicitando trasladarse a un plan con una menor renta mensual. En cuanto al ciclo de facturación, se debe tener en consideración que, de acuerdo al artículo 63 del TUO de las CDU, la migración se efectúa en el siguiente ciclo de facturación posterior a la presentación de la solicitud, por lo que resulta indispensable contar con dicha información para realizar el seguimiento del trámite. Por lo expuesto, los campos indicados permanecerán en los reportes. Con relación al mecanismo de intercambio alternativo, debemos manifestar que el numeral 11 del Proyecto de Instructivo establece la existencia del mismo, cuyo detalle técnico será brindado de manera previa al periodo de pruebas técnicas, de conformidad con lo señalado en la segunda disposición transitoria de la “Norma que establece el sistema de

seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL. En cuanto al cronograma y manual de operatividad para las pruebas técnicas del referido sistema, estos serán comunicados por escrito por el OSIPTEL. Por otro lado, la norma a la que se hace referencia en el párrafo que antecede, en su artículo 6, contempla el escenario de indisponibilidad de los sistemas de la empresa operadora, ya sea por causas ajenas al control de la empresa operadora, así como por una situación de mantenimiento preventivo o mejoras tecnológicas, estableciéndose, para ambos casos, reglas aplicables. Finalmente, sobre la preocupación de la asociación por el tratamiento de la información en mención y el riesgo en el que asegura se encontraría, es preciso señalar que la entrega de dicha información no afecta el derecho de confidencialidad de la información personal, en tanto resulta necesaria para el ejercicio de nuestras funciones, tal como lo establece el artículo 8 de la LDFF.

“Artículo 8.- Secreto e inviolabilidad de las comunicaciones (…) 8.3 No constituye violación del derecho al secreto y la inviolabilidad de las telecomunicaciones, ni afecta el derecho a la confidencialidad de la información personal, el acceso que tenga OSIPTEL a la información necesaria para cumplir sus funciones y, particularmente, el ejercicio que haga de las facultades contempladas en el Artículo 15 de la presente Ley. En ningún caso OSIPTEL podrá exigir la presentación de información que revele el contenido de las comunicaciones.”

A ello debe agregarse que se adoptarán las medidas necesarias para el resguardo de la información que se reciba, tal como se viene haciendo en los procedimientos a cargo del OSIPTEL.

TELEFÓNICA

Por su parte, TELEFÓNICA advierte que se propone que se brinde información de 6 reportes diarios, los cuales contemplan, como mínimo, 15 campos. Al respecto, considera que la información debe acotarse a los campos mínimos necesarios, señalando que, mientras mayor sea la cantidad y complejidad de los campos a extraer, existe riesgo que no se cuente con la totalidad de la información solicitada, o que resulte necesario realizar procesos más complejos de extracción.

TELEFÓNICA, en este extremo, presenta similares comentarios a los de AFIN, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular.

CLARO Respecto a este punto, la empresa operadora señala que ha podido apreciar que una importante cantidad de campos de información requerida en los diferentes reportes contemplados en el proyecto ya se encuentran siendo entregados diariamente al Regulador en cumplimiento de la normativa del RENTESEG (Registro de Abonados), tales como lo serían, por ejemplo: 1. Reporte SOBA: Tipo de Abonado, Identificador de Servicio, Modalidad

de Contrato, Estado de Servicio, Tipo de Abonado, Nombres, Apellido Materno, Apellido Paterno, Razón Social, Tipo de Documento, y Numero de Documento.

2. Reporte BACS: Tipo de Servicio, Identificador de Servicio, y Fecha efectiva de baja.

3. Reporte BASS: Tipo de Servicio, Identificador de Servicio, Modalidad de Contrato, Motivo de Baja, Fecha de documento relacionado a la baja, Tipo de Abonado, Nombres, Apellido Materno, Apellido Paterno, Razón Social, Tipo de Documento, Número de Documento y Fecha Efectiva de Baja.

4. Reporte SOMI: Tipo de Servicio, Identificador de Servicio, Tipo de Abonado, Nombres, Apellido Materno, Apellido Paterno, Razón Social, Tipo de Documento, y Número de Documento.

5. REPORTE MICS: Tipo de Servicio, Identificador de Servicio, y Fecha Efectiva de Migración.

6. REPORTE MISS: Tipo de Servicio, Identificador de Servicio, Nombres, Apellido Materno, Apellido Paterno, Razón Social, Tipo de Documento, Número de Documento, Fecha Efectiva de Migración.

CLARO, en este extremo, presenta similares comentarios a los de AFIN, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular. Respecto de los campos “motivo de migración” y “motivo de baja”, es importante precisar que los mismos se refieren a las causales establecidas en el TUO de las CDU para cada uno de estos supuestos y no a las razones que motivaron al abonado a solicitar la baja o migración, según sea el caso (motivos económicos, insatisfacción con el servicio, etc.). Finalmente, en lo que se refiere a la utilización del código HASH, tanto para el envío como el recojo, debemos manifestar que el detalle técnico será brindado de manera previa al periodo de pruebas técnicas, de conformidad con lo señalado en la segunda disposición transitoria de la “Norma que establece el sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL.

En ese sentido, señala que, luego de haber efectuado un análisis minucioso de los campos de información de los seis (6) reportes que se detallan en el instructivo (SOBA, BACS, BASS, SOMI, MICS y MISS), ha podido comprobar que se contempla la entrega de 77 campos de información en TOTAL, pudiendo apreciar que 48 campos ya son reportados diariamente al Regulador a través del Registro de Abonados, lo cual significa que el 62% de la información requerida actualmente en el proyecto no es nueva y ya se entrega al Regulador diariamente en cumplimiento de la normativa del RENTESEG, razón por la cual no resulta razonable solicitar a las empresas operadoras que realicen nuevos desarrollos (con la inversión que implica) para entregar nuevamente la misma información. Por tal motivo, solicita que los campos de información que actualmente se están reportando al OSIPTEL (detallados anteriormente) de conformidad a la normativa vigente (por ejemplo, RENTESEG) no sean incluidos en la versión final del presente proyecto, acorde a lo dispuesto en el artículo 48 del Texto Único Ordenado de la Ley del Procedimiento Administrativo General - Ley 27444, aprobado mediante Decreto Supremo N° 004-2019-JUS. De otro lado, considera que existen diversos campos de información cuya incorporación en el formato no resulta proporcional para la finalidad que inspiró los reportes contenidos en el proyecto y que además revelarían información sensible de sus clientes, como lo sería por ejemplo:

3. Reporte SOBA: Duración del contrato, y Plan Contratado. 4. Reporte BACS: Deuda del Servicio. 5. Reporte BASS: Plan Contratado, y Deuda del Servicio. 6. Reporte SOMI: Plan Origen, Plan Destino, Ciclo de Facturación, y

Motivo de Migración. 7. Reporte MISS: Plan Origen, Plan Destino, Ciclo de Facturación,

Motivo de Migración, y Tipo de Abonado. Al respecto, considera de suma importancia tomar en cuenta que el hecho de poner en conocimiento de terceros la referida información personal sin que medie la autorización expresa de los abonados titulares del servicio constituye una situación que pone en altísimo riesgo información extremadamente personal y sensible del abonado titular del servicio, todo ello dentro del marco del compromiso de confidencialidad que ha asumido

frente a sus clientes y que la Ley de Protección de Datos Personales4 así como el Reglamento General de la Ley de Telecomunicaciones5 exigen. CLARO considera importante mencionar que el conocimiento de la información antes descrita implica que cualquier funcionario del Regulador podrá visualizar información sensible de sus clientes y protegida a nivel constitucional inclusive, situación que a todas luces conlleva un grave riesgo a la seguridad y privacidad de sus clientes. Asimismo, la empresa estima que dicha supervisión puede ser realizada por el regulador utilizando mecanismos y alternativas menos intrusivas (menos gravosos) a los derechos de los usuarios que no incluyan que la empresa operadora tenga que revelar información sumamente sensible y confidencial, por lo que solicita se evalúen alternativas menos gravosas para que el Regulador pueda supervisar el cumplimiento de las obligaciones referidas a la ejecución de las solicitudes de baja y migración, en aras de la razonabilidad que debe guiar la actuación del Regulador6, teniendo en cuenta además que una regla importante en relación con las actuaciones de las entidades administrativas frente a los administrados (empresas o usuarios) es aquella según la cual sus actuaciones deben ser realizadas de la forma menos gravosa posible7. Reitera que la información descrita anteriormente podría colisionar con lo dispuesto por la Ley de Protección de Datos Personales, aprobada por Ley N° 29733, en la medida que, indirectamente y al exponer los motivos de la baja, podría revelarse información sensible de sus abonados.

4 La Ley de Protección de Datos Personales, los artículos 31 y 32 del Reglamento de la Ley de Protección de Datos Personales protegen la confidencialidad, seguridad y adecuado uso de los datos personales de los usuarios del servicio público de telecomunicaciones, en tanto que estos datos personales sólo pueden ser tratados para las finalidades específicas que en su oportunidad fueron informadas a dichos usuarios, salvo que exista una orden judicial o mandato legal expreso que fundamente específicamente su divulgación. 5 En atención al artículo 13° de Texto Único Ordenado del Reglamento General de la Ley de Telecomunicaciones aprobado por Decreto Supremo N° 020-2007-MTC , y los numerales 6 y 8 de la Norma que Establece Medidas Destinadas a Salvaguardar la Inviolabilidad y el Secreto de las Telecomunicaciones y la Protección de Datos Personales, y regula las acciones de supervisión y control a cargo del Ministerio de Transportes y Comunicaciones aprobado mediante Resolución Ministerial N° 111-2009- MTC-03, América Móvil Perú SAC, como concesionaria de servicios públicos de telecomunicaciones, está obligada a mantener en confidencialidad los datos personales de sus usuarios y la información que se obtenga en el desarrollo de sus operaciones. 6 Principio de razonabilidad, recogido en el numeral 1.4 del artículo IV del Título Preliminar de la Ley del Procedimiento Administrativo General. En el caso de un requerimiento de información, ello obliga a que éste deba ser razonable y ajustarse al fin público perseguido por el procedimiento administrativo que se tramita. 7 Esta regla se encuentra explícita en el T.U.O. de la Ley del Procedimiento Administrativo General, es su artículo 66: "Artículo 66.- Derechos de los administrados Son derechos de los administrados con respecto al procedimiento administrativo, los siguientes: (. ..) 10. A que las actuaciones de las entidades que les afecten sean llevadas a cabo en la forma menos gravosa posible."

En esa misma línea, hace notar que el Proyecto pretende exigir que se brinde información sensible que el Regulador no necesita ni ha sido materia del Análisis de Calidad Regulatoria, citado brevemente en el Informe N° 00031-DAPU/2021 (en adelante, el "Informe") que sustenta la Resolución N° 057-2021-CD/OSIPTEL asociada al Proyecto. En virtud de lo anterior, la propuesta de reportar lo antes indicado no coadyuva a lograr el objetivo del Proyecto, y, por lo mismo, resulta una medida desproporcionada y es contraria al Principio de Razonabilidad que rige la actuación de las entidades de la Administración Pública. Con relación al referido principio, el Tribunal Constitucional ha señalado lo siguiente en la sentencia recaída en el Expediente N° 00535-2009-PA/TC: "La razonabilidad es un criterio íntimamente vinculado a la justicia y está en la esencia misma del Estado constitucional de derecho. Se expresa como un mecanismo de control o interdicción de la arbitrariedad en el uso de las facultades discrecionales, exigiendo que las decisiones que se tomen en ese contexto respondan a criterios de racionalidad y que no sean arbitrarias. Como lo ha sostenido este Colegiado, esto "implica encontrar justificación lógica en los hechos, conductas y circunstancias que motivan todo acto discrecional de los poderes públicos”8 En este sentido, la empresa operadora solicita que, en caso se decida mantener dichos campos de información en el Instructivo, antes de su aprobación definitiva, se eleve en consulta los alcances de dichos extremos del proyecto al Ministerio de Transportes y Comunicaciones (MTC) así como a la Dirección General de Protección de Datos Personales a cargo del Ministerio de Justicia, en la medida que dichas entidades son las legalmente competentes y responsables en materia de protección del derecho al secreto de las telecomunicaciones y de datos personales. Por otro lado, la empresa operadora considera que algunos campos de información no resultan de utilidad para alcanzar la finalidad que inspiró al Regulador a la emisión del proyecto, como lo sería:

1. Reporte SOBA: Canal en el cual se presenta la solicitud, dirección del canal, y ubigeo del canal.

8 Fundamento 16 de la Sentencia recaída en el Expediente W 00535-2009-PA/TC.

2. Reporte SOMI: Canal en el cual se presenta la solicitud, dirección del canal, y ubigeo del canal.

Al respecto, manifiesta su rechazo a la incorporación en el proyecto de la información antes señalada ya que la misma no resulta de utilidad para el Regulador a fin de determinar si las solicitudes de baja y migración han sido ejecutadas oportunamente, siendo inclusive que la incorporación de la información antes señalada ocasionaría serios inconvenientes en la operación comercial, toda vez que, en la actualidad, no cuenta con la información antes señalada de manera automatizada, y su implementación implicaría la ejecución de diversos desarrollos en sus sistemas, situación que no ha sido debidamente analizada en el proyecto. Asimismo, indica que, en la actualidad, la mayor cantidad de solicitudes no son recibidas por el canal presencial, sino por canales no presenciales (v.g. canal telefónico), por lo que no sería razonable que las empresas efectúen modificaciones en los sistemas para determinar el ubigeo y dirección de dicho canal. En línea con lo anterior, señala que, actualmente, en sus sistemas no cuentan con información del ubigeo e incluso no forma parte de sus sistemas comerciales la información de la dirección de sus canales, por lo que cruzar ambos campos de información podría ocasionar desalineaciones, al tratarse de fuentes de diferente naturaleza. Es por ello que solicita que dichos campos de información sean eliminados del proyecto que finalmente sea aprobado. De otro lado, en relación con los formatos denominados BASS y MISS, ha podido apreciar la existencia de un campo de información denominado "motivo de migración" v "motivo de baja", los cuales son campos de información que no suelen ser brindado por los clientes, en tanto que no existe ninguna obligación legal a cargo del cliente para brindar dicha información o, en su defecto, en caso el cliente brinde alguna razón, esta no necesariamente es concordante con los supuestos contemplados en el proyecto. Es por tal motivo que solicita que se agregue un campo adicional "no desea indicar" u "otros" para los escenarios antes descritos. Por último, solicita precisar en el instructivo si los archivos deberán contemplar la utilización del código HASH, tanto para el envío como el

recojo, en tanto que dicho aspecto no se señala en el instructivo publicado para comentarios.


6. VERIFICACIÓN DE LA CONSISTENCIA DE LA INFORMACIÓN ENTREGADA POR LAS EMPRESAS OPERADORAS – ARCHIVO DE ERRORES

La información remitida por las empresas operadoras (CONCESIONARIO_SOBA_YYYYMMDD.TXT, CONCESIONARIO_BACS_YYYYMMDD.TXT, CONCESIONARIO_BASS_YYYYMMDD.TXT, CONCESIONARIO_SOMI_YYYYMMDD.TXT, CONCESIONARIO_MICS_YYYYMMDD.TXT, CONCESIONARIO_MISS_YYYYMMDD.TXT, CONCESIONARIO_SOBA_YYYYMMDD_SUB.TXT, CONCESIONARIO_BACS_YYYYMMDD_SUB.TXT, CONCESIONARIO_BASS_YYYYMMDD_SUB.TXT, CONCESIONARIO_SOMI_YYYYMMDD_SUB.TXT, CONCESIONARIO_MICS_YYYYMMDD_SUB.TXT y CONCESIONARIO_MISS_YYYYMMDD_SUB.TXT) será verificada y validada por el OSIPTEL, a fin de advertir si ésta se ajusta a las características y condiciones establecidas en el presente documento (Estructura de los reportes). La validación de la información se realiza con la finalidad de advertir errores; a modo de referencia, procedemos a enumerar algunos casos:

Campos nulos,

Campos que no se ajusten a la longitud establecida,

Campos que no se ajusten al tipo de carácter establecido,

Error en los delimitadores (utilizar siempre el separador pipe (|)),

Formato incorrecto en el orden de los campos a reportar.

Entre otros, contemplados en el presente documento.

Asimismo, se validará la estructura de los nombres de los archivos remitidos por las empresas operadoras.

6. VERIFICACIÓN DE LA CONSISTENCIA DE LA INFORMACIÓN ENTREGADA POR LAS EMPRESAS OPERADORAS – ARCHIVO DE ERRORES

La información remitida por las empresas operadoras (CONCESIONARIO_SOBA_YYYYMMDD.TXT, CONCESIONARIO_BACS_YYYYMMDD.TXT, CONCESIONARIO_BASS_YYYYMMDD.TXT, CONCESIONARIO_SOMI_YYYYMMDD.TXT, CONCESIONARIO_MICS_YYYYMMDD.TXT, CONCESIONARIO_MISS_YYYYMMDD.TXT, CONCESIONARIO_SOBA_YYYYMMDD_SUB.TXT, CONCESIONARIO_BACS_YYYYMMDD_SUB.TXT, CONCESIONARIO_BASS_YYYYMMDD_SUB.TXT, CONCESIONARIO_SOMI_YYYYMMDD_SUB.TXT, CONCESIONARIO_MICS_YYYYMMDD_SUB.TXT y CONCESIONARIO_MISS_YYYYMMDD_SUB.TXT) será verificada y validada por el OSIPTEL, a fin de advertir si ésta se ajusta a las características y condiciones establecidas en el presente documento (Estructura de los reportes). La validación de la información se realiza con la finalidad de advertir errores; a modo de referencia, procedemos a enumerar algunos casos:

Campos nulos,

Campos que no se ajusten a la longitud establecida,

Campos que no se ajusten al tipo de carácter establecido,

Error en los delimitadores (utilizar siempre el separador pipe (|)),

Formato incorrecto en el orden de los campos a reportar.

Entre otros, contemplados en el presente documento.

Asimismo, se validará la estructura de los nombres de los archivos remitidos por las empresas operadoras.

En caso se detecten inconsistencias en algunos de los campos de la información remitida por las empresas operadoras, el OSIPTEL depositará en la carpeta del SFTP correspondiente a la empresa operadora, un archivo con la información de los errores detectados por cada registro del respectivo reporte, indicando los errores observados - adjuntando un código de error - por registro (fila), para que sean subsanados en la siguiente ventana de entrega de información

6.1. Archivo de errores:

El archivo que recibirá la empresa operadora contará con el siguiente nombre:

ERRORES_ NOMBREDEARCHIVOEVALUADO.TXT

Características:

- ERRORES_: Identificador del archivo que contiene los errores

encontrados en el archivo reportado por el concesionario. - NOMBREDEARCHIVOEVALUADO: Nombre del archivo fuente

reportado por el concesionario al que corresponden los errores encontrados.

- TXT: Extensión del archivo que corresponde al formato de texto.

El archivo que recibirá la empresa operadora está en formato de texto plano, contiene tres (3) campos separados por el carácter PIPE (|) como se muestra a continuación: NUMERODEFILA|CÓDIGODEERROR|CODIGODESUBSANACION

A continuación se detallan cada uno de los campos:

1. Número de Fila: Número de fila, dentro del archivo evaluado, en el

que se encuentra el registro que contiene el error.

Características:

- Longitud fija: 8 caracteres. - Tipo: numérico.

En caso se detecten inconsistencias en algunos de los campos de la información remitida por las empresas operadoras, el OSIPTEL depositará en la carpeta del SFTP correspondiente a la empresa operadora, un archivo con la información de los errores detectados por cada registro del respectivo reporte, indicando los errores observados - adjuntando un código de error - por registro (fila), para que sean subsanados en la siguiente ventana de entrega de información.

6.1. Archivo de errores:

El archivo que recibirá la empresa operadora contará con el siguiente nombre:

ERRORES_ NOMBREDEARCHIVOEVALUADO.TXT

Características:

- ERRORES_: Identificador del archivo que contiene los errores

encontrados en el archivo reportado por el concesionario. - NOMBREDEARCHIVOEVALUADO: Nombre del archivo fuente

reportado por el concesionario al que corresponden los errores encontrados.

- TXT: Extensión del archivo que corresponde al formato de texto.

El archivo que recibirá la empresa operadora está en formato de texto plano, contiene tres (3) campos separados por el carácter PIPE (|) como se muestra a continuación: NUMERODEFILA|CÓDIGODEERROR|CODIGODESUBSANACION

A continuación se detallan cada uno de los campos:

1. Número de Fila: Número de fila, dentro del archivo evaluado, en el

que se encuentra el registro que contiene el error.

Características:


2. Código de Error: Campo que contiene el(los) error(es) encontrados. Características:

- Tipo: alfanumérico. - Si el registro tiene más de un error se listarán todos los

errores separados por comas.

3. Código de Subsanación: Asignado por el OSIPTEL para identificar la subsanación del registro con error.

Características:


2. Código de Error: Campo que contiene el(los) error(es) encontrados. Características:

- Tipo: alfanumérico. - Si el registro tiene más de un error se listarán todos los

errores separados por comas.

3. Código de Subsanación: Asignado por el OSIPTEL para identificar la subsanación del registro con error.

Características:


Para fines ilustrativos, se muestra el contenido de un reporte de baja con solicitud (SOBA) ficticio y su correspondiente archivo de error. Ambos se encuentran formateados para mejor visibilidad, se ha agregado una cabecera que describe los campos. Archivo SOBA, reportado por la empresa operadora

Archivo de error

De acuerdo al archivo de error mostrado, se ha encontrado errores en las filas 2 y 4 del archivo SOBA. En el caso de la fila 2 (código de pedido 1234567891), se tiene el error SOBA0060 que indica que el campo DURACION_CONTRATO se

encuentra vacío y el error SOBA0070 que indica que el campo PLAN_CONTRATADO se encuentra vacío; el sistema ha asignado a este registro el código de subsanación 000000000000017, el cual deberá ser utilizado para su subsanación. En el caso de la fila 4 (código de pedido 1234567893), se tiene el error SOBA0023 que indica que el campo FECHA_SOLICITUD presenta un formato incorrecto; el sistema ha asignado a este registro el código de subsanación 000000000000018.

Comentarios recibidos

Posición del OSIPTEL

BITEL Al respecto, BITEL solicita mayor detalle para esta información, así como esclarecer cada columna dentro de la misma con algún ejemplo por migración o baja. Asimismo, de no encontrarse ningún error, solicita se les confirme si el OSIPTEL brindará algún tipo de confirmación del estado de los reportes en revisión. Por último, solicita se les confirme si solo se necesitarán las columnas descritas o si será necesario algún tipo de evidencia adicional.

Sobre lo indicado por BITEL, se tiene a bien incluir un ejemplo ilustrativo en el Instructivo Técnico. Además, en el flujo descrito en el numeral 12 se indica las salidas que tendrá el sistema. Para terminar, cabe precisar que la información requerida es aquella que se incluye en el Instructivo Técnico.

CLARO

En relación con el punto 6, CLARO considera necesario que el plazo de subsanación sea de por lo menos tres (3) días hábiles para efectuar dicha labor, en tanto que un plazo inferior resultaría insuficiente en caso la subsanación implique efectuar modificaciones en las tablas fuentes. Al respecto, dado que la situación de caso fortuito, fuerza mayor o circunstancia fuera de control podría contener hechos extraordinarios o incidencias de complejo análisis, la empresa considera que el plazo es insuficiente, máxime si debe elaborarse un informe técnico para acreditar tales hechos. En ese sentido, solicita que los mencionados plazos sean modificados por tres (3) días hábiles y seis (6) días hábiles, respectivamente, ambos computados desde el día siguiente a la fecha de producida la indisponibilidad y no desde el mismo día. Sustenta su solicitud en el Principio de Proporcionalidad o de Razonabilidad, previsto en el numeral 1.4 del artículo IV del Título Preliminar de la LPAG.

Acerca de lo solicitado por CLARO, se debe precisar que los plazos de ejecución de las bajas y migraciones, por su naturaleza, son cortos, por lo que no resulta viable otorgar plazos extensos para la subsanación de la información, más aún si tenemos en consideración que, en principio, estos casos deberían ser excepcionales. En ese sentido, el artículo 4 de la norma que establece el sistema de seguimiento dispone que la subsanación deberá ser realizada en la siguiente entrega de información, en caso contrario, no se cumpliría con el objetivo principal de la norma, que es realizar un seguimiento diario a fin de evitar potenciales problemas derivados de la no atención oportuna de las solicitudes de migración y baja (reclamos, apelaciones, facturaciones no deseas, etc.). Respecto a los plazos, nos remitimos a los numerales (ii) y (iii) del artículo 6 de la norma antes descrita, los cuales establecen que:

(ii) En caso de indisponibilidad de los sistemas de la empresa operadora o de su conectividad de red, la empresa operadora debe comunicar dicha indisponibilidad en el plazo de un (1) día hábil y precisar la causa y acreditarla dentro de cuatro (4) días hábiles, ambos computados desde la fecha de producida la indisponibilidad. La acreditación se realiza mediante un informe técnico que detalle la causa de la indisponibilidad y adjunte los medios probatorios respectivos.

(iii) En caso de indisponibilidad de los sistemas de la empresa operadora o de su conectividad de red, por una situación de mantenimiento preventivo o mejoras tecnológicas, ésta debe ser acreditada con una anticipación mínima de tres (3) días calendarios al OSIPTEL.


7. REPORTES SUBSANADOS POR LA EMPRESA OPERADORA

El archivo a remitir al OSIPTEL tiene el siguiente nombre. CONCESIONARIO_[SOBA|BACS|BASS|SOMI|MICS|MISS]_YYYY

MMDD_SUB.TXT Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOBA|BACS|BASS|SOMI|MICS|MISS: Identificador del tipo de

archivo subsanado. - YYYY: Son los cuatro dígitos que identifican el año de entrega



información. - TXT: Extensión del archivo que corresponde a formato de texto. - SUB: Identificador de los archivos que corresponden a la

subsanación de errores.

Se deben reportar todos los campos del registro observado, subsanando el/los campos rechazados por contener algún tipo de error. La empresa operadora, deberá agregar un “campo” al final del registro a subsanar, el mismo que será llenado con el “Código de

7. REPORTES SUBSANADOS POR LA EMPRESA OPERADORA

El archivo a remitir al OSIPTEL tiene el siguiente nombre. CONCESIONARIO_[SOBA|BACS|BASS|SOMI|MICS|MISS]_YYYY

MMDD_SUB.TXT Características:

- CONCESIONARIO: Es el código asignado al concesionario. - SOBA|BACS|BASS|SOMI|MICS|MISS: Identificador del tipo de

archivo subsanado. - YYYY: Son los cuatro dígitos que identifican el año de entrega



información. - TXT: Extensión del archivo que corresponde a formato de texto. - SUB: Identificador de los archivos que corresponden a la

subsanación de errores.

Se deben reportar todos los campos del registro observado, subsanando el/los campos rechazados por contener algún tipo de error. La empresa operadora, deberá agregar un “campo” al final del registro a subsanar, el mismo que será llenado con el “Código de

Subsanación” (código de 10 dígitos numéricos) consignado en el archivo de errores. Cabe mencionar que la información subsanada también será validada, a fin de verificar si ha sido remitida conforme las características y formato establecido.

Subsanación” (código de 10 dígitos numéricos) consignado en el archivo de errores. Cabe mencionar que la información subsanada también será validada, a fin de verificar si ha sido remitida conforme las características y formato establecido.


BITEL Al respecto, BITEL requiere se indique el tiempo que tienen las empresas operadoras para subsanar los errores encontrados por el OSIPTEL y se detalle si este criterio está sujeto a algún tipo de penalidad para las empresas operadoras.

Respecto de lo requerido por BITEL, se indica que, de conformidad con lo establecido en el artículo 4 de la “Norma que establece el Sistema de Seguimiento, Monitoreo y Fiscalización de Bajas y Migraciones”, aprobada mediante Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL, la información subsanada debe ser remitida en la siguiente entrega de información. Asimismo, en cuanto al incumplimiento de la obligación antes mencionada, es preciso señalar que el artículo 5 de la citada norma establece como responsabilidad de la empresa operadora el subsanar los reportes en el plazo establecido:

Artículo 5.- Responsabilidades La empresa operadora del servicio público de telecomunicaciones es responsable de:

a) Verificar la consistencia, coherencia y validez de la información reportada, de tal forma que los campos enviados no se encuentren vacíos, correspondan a la información requerida, no comprendan datos inexactos y se encuentren en el formato solicitado.

b) Subsanar los reportes en el plazo establecido (…) Acorde a ello, el numeral 2 del Régimen de Infracciones y Sanciones establece que la empresa operadora del servicio público de telecomunicaciones que a través del sistema de seguimiento no subsane los reportes en el plazo establecido incurre en infracción leve:


8. BAJAS Y MIGRACIONES NO EJECUTADAS

Con periodicidad diaria, se evalúa que las solicitudes de baja y migración se atiendan dentro de los plazos establecidos en la normativa vigente. En caso la empresa operadora no ejecute la baja o migración dentro del plazo antes indicado, se genera un archivo que contiene el detalle de las solicitudes que no habrían sido atendidas, a fin de que la empresa operadora cumpla hacer efectiva la baja o migración. El archivo que recibirá la empresa operadora estará en formato TXT (texto plano) y tendrá la siguiente nomenclatura: CONCESIONARIO_[BAJA|MIGRACION]_NO_EJECUTADA_YYYY

MMDD.TXT Características:

- CONCESIONARIO: Es el código asignado al concesionario. - BAJA|MIGRACION: Identificador del tipo de archivo. - YYYY: Son los cuatro dígitos que identifican el año de entrega



información.

El archivo que recibirá la empresa operadora está en formato de texto plano, contiene tres (3) campos separados por el carácter PIPE (|) como se muestra a continuación:

8. BAJAS Y MIGRACIONES NO EJECUTADAS

Con periodicidad diaria, se evalúa que las solicitudes de baja y migración se atiendan dentro de los plazos establecidos en la normativa vigente. En caso la empresa operadora no ejecute la baja o migración dentro del plazo antes indicado, se genera un archivo que contiene el detalle de las solicitudes que no habrían sido atendidas, a fin de que la empresa operadora cumpla con hacer efectiva la baja o migración. El archivo que recibirá la empresa operadora estará en formato TXT (texto plano) y tendrá la siguiente nomenclatura: CONCESIONARIO_[BAJA|MIGRACION]_NO_EJECUTADA_YYYY

MMDD.TXT Características:




información.

El archivo que recibirá la empresa operadora está en formato de texto plano, contiene tres (3) campos separados por el carácter PIPE (|) como se muestra a continuación:

NUMERO_SOLICITUD|FECHA_PROGRAMADA |IDENTIFICADOR_SERVICIO


1. Número de Solicitud: número de solicitud de baja o migración

que no ha sido reportado en plazo.

Características:

- Longitud máxima: 20 caracteres. - Tipo: alfanumérico.

2. Fecha Programada: fecha en que debió ejecutarse la baja o la





se dará de baja.

Características:

- Longitud máxima: 20 caracteres - Tipo: alfanumérico

CODIGO_PEDIDO|FECHA_PROGRAMADA |IDENTIFICADOR_SERVICIO


1. Código de Pedido: código de pedido de la baja o migración que

no ha sido reportado en plazo.

Características:

- Longitud máxima: 20 caracteres. - Tipo: alfanumérico.

2. Fecha Programada: fecha en que debió ejecutarse la baja o la





se dará de baja o que migrará.

Características:



BITEL

Al respecto, BITEL solicita se confirme si solo se necesitarán las columnas descritas o si será necesario algún tipo de evidencia adicional. De igual manera, requiere se brinde un ejemplo sobre estos casos y se indique el

En cuanto al archivo de las bajas y migraciones no ejecutadas que, de ser el caso, reciba la empresa operadora, es importante precisar que la existencia de este parte de la premisa que la empresa operadora no ha

tiempo que tienen las empresas operadoras para subsanar los errores encontrados por el OSIPTEL.

ejecutado la baja o migración solicitada dentro de los plazos establecidos en la normativa vigente. Bajo este presupuesto, se espera que al tomar conocimiento la empresa de la falta de atención oportuna de la solicitud presentada, actúe diligentemente evaluando la información recibida y haciendo efectiva la baja o migración de manera inmediata, sobre todo teniendo en cuenta que el abonado se está viendo obligado a mantener un servicio con el que ya no desea contar, con la repercusión económica que ello representa, o un plan tarifario que no se ajusta a sus necesidades.

CLARO

Respecto al punto 8 del Proyecto de Instructivo, la empresa operadora considera necesario que se efectúen las siguientes precisiones: - Se debe tomar en consideración la posibilidad de que los clientes

desistan de su solicitud de baja o miqración de plan tarifario, siendo más frecuente la primera debido a las campañas de retención existentes, razón por la cual les preocupa que el proyecto bajo análisis no contemple la realidad antes descrita.

- Considera necesario efectuar una precisión respecto a la periodicidad

de envío de dichos reportes (diario / semanal) y que se establezcan las reglas aplicables en dichos casos.

- Señala que se debe otorgar un plazo razonable para la ejecución de la

reversión de la migración o solicitud de baja, el mismo que estima no debería ser inferior a los dos (2) días hábiles.

- Considera importante que se precise la manera en que se confirmará al

OSIPTEL la ejecución de la reversión realizada o, en su defecto, se precise que será suficiente la actualización de dicho cambio en el Registro de Abonados.

Sobre el desistimiento de la solicitud, se acogen los comentarios realizados por CLARO, en el sentido que, en el reporte de bajas ejecutadas, detallado en el punto 5.2 del numeral 5, y en el reporte de migraciones ejecutadas, detallado en el punto 5.5 del numeral 5, se ha adicionado el campo DESISTIMIENTO, en el cual se debe consignar el valor “D” en caso el abonado haya desistido de su solicitud. Asimismo, los campos Fecha de Baja Efectiva y Fecha de Migración efectiva han sido renombrados a Fecha de Baja Efectiva/Desistimiento v Fecha de Migración Efectiva/Desistimiento, respectivamente, por lo que cuando en el campo DESISTIMIENTO se consigne el valor “D”, la fecha registrada se entenderá que corresponde a la fecha de desistimiento. De este modo, la solicitud en cuestión no será evaluada como parte de las solicitudes no atendidas. En cuanto al archivo de las bajas y migraciones no ejecutadas que, de ser el caso, reciba la empresa operadora, es importante precisar que la existencia de este parte de la premisa que la empresa operadora no ha ejecutado la baja o migración solicitada dentro de los plazos establecidos en la normativa vigente. Bajo este presupuesto, se espera que al tomar conocimiento la empresa de la falta de atención oportuna de la solicitud presentada, actúe diligentemente evaluando la información recibida y haciendo efectiva la baja o migración de manera inmediata, sobre todo teniendo en cuenta que el

abonado se está viendo obligado a mantener un servicio con el que ya no desea contar, con la repercusión económica que ello representa, o un plan tarifario que no se ajusta a sus necesidades. En cuanto al penúltimo comentario formulado por CLARO, conviene precisar que se evidencia que el mismo corresponde al numeral 9 del Proyecto de Instructivo; no obstante, a fin de dar atención al comentario formulado, nos remitimos a lo anteriormente expuesto en lo que respecta a los archivos de bajas y migraciones no ejecutadas, por guardar relación. Finalmente, en lo que se refiere al último comentario, cumplimos con señalar que, en tanto el presente sistema tiene como finalidad principal la atención oportuna de las solicitudes de baja y migración, en el caso de que las mismas se realicen sin sustento, este Organismo se encuentra en la potestad de desplegar las acciones que correspondan en el ejercicio de su facultad supervisora.


9. BAJAS Y MIGRACIONES SIN SUSTENTO

Con periodicidad diaria, se verificará y se generará un archivo que contiene el detalle de las bajas y migraciones que fueron ejecutadas sin sustento, a fin de que la empresa operadora revierta dicha ejecución. El archivo que recibirá la empresa operadora estará en formato TXT (texto plano) y tendrá la siguiente nomenclatura: CONCESIONARIO_[BAJA|MIGRACION]_SIN_SUSTENTO_YYYYM

MDD.TXT Características:



información.

9. BAJAS Y MIGRACIONES SIN SUSTENTO

Con periodicidad diaria, se verificará y se generará un archivo que contiene el detalle de las bajas y migraciones que fueron ejecutadas sin sustento, a fin de que la empresa operadora revierta dicha ejecución. El archivo que recibirá la empresa operadora estará en formato TXT (texto plano) y tendrá la siguiente nomenclatura: CONCESIONARIO_[BAJA|MIGRACION]_SIN_SUSTENTO_YYYYM

MDD.TXT Características:



información.


El archivo que recibirá la empresa operadora está en formato de texto plano, contiene el identificador del servicio que se migró o dio de baja, sin sustento:

IDENTIFICADOR_SERVICIO

1. Identificador de Servicio: número que identifica al servicio.

Características:



El archivo que recibirá la empresa operadora está en formato de texto plano, contiene el identificador del servicio que se migró o dio de baja, sin sustento:

IDENTIFICADOR_SERVICIO

1. Identificador de Servicio: número que identifica al servicio.

Características:




BITEL

Al respecto, BITEL solicita se confirme si solo se necesitará la columna descrita o si será necesario algún tipo de evidencia adicional. De igual manera, requiere se brinde un ejemplo sobre estos casos y se indique el tiempo que tienen las empresas operadoras para subsanar los errores encontrados por el OSIPTEL.

En cuanto al archivo de las bajas y migraciones sin sustento que, de ser el caso, reciba la empresa operadora, es importante precisar que la existencia de este parte de la premisa que la empresa operadora ha ejecutado la baja del servicio o la migración del plan tarifario sin que se haya configurado alguna de las causales establecidas en la normativa legal vigente. Bajo este presupuesto, se espera que al tomar conocimiento la empresa de los hechos descritos, actúe diligentemente evaluando la información recibida y revierta dicha ejecución, sobre todo teniendo en cuenta que el abonado se está viendo privado de contar con el servicio, en el caso de la baja, o si bien cuenta con el servicio, el mismo se brinda bajo características distintas a las deseadas por él.


10. MECANISMO A UTILIZAR PARA LA ENTREGA Y RECOJO DE INFORMACIÓN DEL SISTEMA DE SEGUIMIENTO DEL OSIPTEL El intercambio de información se realizará exclusivamente por medios electrónicos, a través del protocolo SFTP9, cuya arquitectura se muestra a continuación

La transmisión de la información se realizará a través de Internet. Cada empresa operadora del servicio público será responsable de:

La seguridad física y lógica de sus sistemas empleados para el envío de información. La seguridad de las comunicaciones se implementará a través de los protocolos de comunicaciones definidos y en los componentes de las aplicaciones utilizadas.

La confidencialidad y uso adecuado de las contraseñas y nombre de usuario que el OSIPTEL le haya otorgado para el acceso al Sistema de Seguimiento.

La confidencialidad de la información enviada y el acceso restringido de su personal a ésta.

10. MECANISMO A UTILIZAR PARA LA ENTREGA Y RECOJO DE INFORMACIÓN DEL SISTEMA DE SEGUIMIENTO DEL OSIPTEL El intercambio de información se realizará exclusivamente por medios electrónicos, a través del protocolo SFTP10, cuya arquitectura se muestra a continuación

La transmisión de la información se realizará a través de Internet. Cada empresa operadora del servicio público será responsable de:

La seguridad física y lógica de sus sistemas empleados para el envío de información. La seguridad de las comunicaciones se implementará a través de los protocolos de comunicaciones definidos y en los componentes de las aplicaciones utilizadas.

La confidencialidad y uso adecuado de las contraseñas y nombre de usuario que el OSIPTEL le haya otorgado para el acceso al Sistema de Seguimiento.

La confidencialidad de la información enviada y el acceso restringido de su personal a ésta.

9 SSH File Transfer Protocol. 10 SSH File Transfer Protocol.

La instalación, configuración y administración de sus respectivos equipos de cómputo, los clientes / servidores requeridos y de la cuenta de acceso al sistema de intercambio centralizado asignada.

Realizar las validaciones previas correspondientes de la coherencia y validez de los datos enviados.

La disponibilidad de sus sistemas usados para el envío a través del sistema de intercambio centralizado ACCESO AL SISTEMA DE SEGUIMIENTO Y PROTOCOLOS DE COMUNICACIONES El OSIPTEL proveerá una cuenta de acceso (usuario y contraseña), con permisos de escritura y lectura para cada empresa operadora, para que realice la carga y recojo de la información diaria. Se emplearán protocolos de comunicaciones seguros SFTP implementado conjuntamente con el protocolo SSH (Secure Shell). Las comunicaciones se realizarán a través de conexión segura mediante certificado SSL generado por el mismo servidor SSH. El software base a utilizar es:

Sistema operativo totalmente compatible con OpenSSH.

Software OpenSSH v5.5 estable o superior.

La instalación, configuración y administración de sus respectivos equipos de cómputo, los clientes / servidores requeridos y de la cuenta de acceso al sistema de intercambio centralizado asignada.

Realizar las validaciones previas correspondientes de la coherencia y validez de los datos enviados.

La disponibilidad de sus sistemas usados para el envío a través del sistema de intercambio centralizado ACCESO AL SISTEMA DE SEGUIMIENTO Y PROTOCOLOS DE COMUNICACIONES El OSIPTEL proveerá una cuenta de acceso (usuario y contraseña), con permisos de escritura y lectura para cada empresa operadora, para que realice la carga y recojo de la información diaria. Se emplearán protocolos de comunicaciones seguros SFTP implementado conjuntamente con el protocolo SSH (Secure Shell). Las comunicaciones se realizarán a través de conexión segura mediante certificado SSL generado por el mismo servidor SSH. El software base a utilizar es:

Sistema operativo totalmente compatible con OpenSSH.

Software OpenSSH v5.5 estable o superior.


BITEL

Al respecto, BITEL requiere se detalle o adjunte el plan que tiene el OSIPTEL para la configuración del SFTP con las empresas operadoras (fases, tiempos, entre otros).

Acerca de lo expresado por BITEL en este punto, es conveniente resaltar que, conforme a lo señalado en la segunda disposición transitoria de la “Norma que establece el sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL, el cronograma y manual de operatividad para las pruebas técnicas del referido sistema son comunicados por escrito por el OSIPTEL.


11. MECANISMO DE INTERCAMBIO ALTERNATIVO

En caso de indisponibilidad del sistema por problemas técnicos, de conectividad u otros, el OSIPTEL comunicará a la dirección de correo

11. MECANISMO DE INTERCAMBIO ALTERNATIVO

En caso de indisponibilidad del sistema por problemas técnicos, de conectividad u otros, el OSIPTEL comunicará a la dirección de correo

electrónico de la empresa operadora el cese de dicha indisponibilidad para que ésta cumpla con regularizar el registro de la información. De ser necesario se establecerá un mecanismo de intercambio utilizando servicios de nube, lo que será comunicado de manera oportuna.

electrónico de la empresa operadora el cese de dicha indisponibilidad para que ésta cumpla con regularizar el registro de la información. De ser necesario se establecerá un mecanismo de intercambio utilizando servicios de nube, lo que será comunicado de manera oportuna.


BITEL

Al respecto, BITEL cree conveniente recibir un correo de confirmación de recepción de la información por parte del OSIPTEL a las empresas operadoras, con el fin de asegurar que la entrega fue correcta. Asimismo, recalca que aún está pendiente estipular los correos a los cuales se deberá la información como escenario alternativo. Por último, indica que, con el fin de una mejor comprensión de los pasos a seguir para el intercambio de información de los diferentes reportes solicitados por el OSIPTEL, solicita los flujos de trabajo que deben seguir las empresas operadoras, de acuerdo al instructivo técnico, estipulando la durabilidad por cada paso (entrega de reportes, corrección, subsanación, entre otros).

Respecto de lo indicado por la empresa operadora, se precisa que dentro del desarrollo del sistema se ha previsto remitir un correo, a cada empresa operadora, con el resultado de la evaluación realizada a cada uno de los archivos presentados en el día. Esta especificación ha sido incluida en el Instructivo Técnico. Con relación a los mecanismos de intercambio alternativo (v.g. correos electrónicos), cumplimos con indicar que el detalle técnico será brindado de manera previa al periodo de pruebas técnicas, de conformidad con lo señalado en la segunda disposición transitoria de la “Norma que establece el sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL. Para concluir, en lo referido a la solicitud de los flujos de trabajo que deben seguir las empresas operadoras, el mismo ha sido incluido en el numeral 12 del Instructivo Técnico.

OTROS COMENTARIOS

LEGALIDAD DEL PROYECTO DE INSTRUCTIVO TÉCNICO



ENTEL Al respecto, ENTEL considera que, en tanto la redacción del proyecto normativo permite que gran parte de las obligaciones asociadas al sistema

Sobre el particular, este Organismo discrepa de lo afirmado por ENTEL, por cuanto el Proyecto de Instructivo no configura una vulneración al principio

de monitoreo sean aprobadas por el Instructivo Técnico, el mismo solo podría ser aprobado por el Consejo Directivo del OSIPTEL, único órgano que cuenta con potestad normativa, según el artículo 8 de la Ley de Desarrollo de Funciones y Facultades del OSIPTEL. ENTEL asevera que, de aprobarse el Proyecto de Instructivo Técnico a través de una resolución de Gerencia General, se estaría excediendo en sus competencias al pretender aprobar un Instructivo Técnico que posee naturaleza normativa. Sobre este punto, ENTEL precisa que la competencia puede condicionar la validez del acto o del Reglamento, tornándolo en inválido o ilegal cuando este sea aprobado por un órgano que no esté facultado para ello, lo cual, a su vez, supondría una infracción al principio de legalidad recogido en el TUO de la LPAG. Asimismo, ENTEL manifiesta que la aprobación del Proyecto de Instructivo Técnico acarrearía también una infracción al principio de jerarquía normativa, recogido en el artículo 51 de la Constitución, conforme al cual la ley prevalece sobre normas de inferior jerarquía. Finalmente, ENTEL solicita que se desestime la propuesta bajo comentarios, por representar una infracción al principio de legalidad contemplado en el TUO de la LPAG y en la Constitución.

de legalidad, toda vez que no constituye un cuerpo normativo, en la medida que no incorpora nuevas obligaciones, sino que, a través de este, se detallan aspectos de índole técnico que, razonablemente, no resulta idóneo que sean detallados en Norma; sin embargo, no por ello dista de su finalidad o crea nuevas obligaciones, sino que incorpora las pautas necesarias para la implementación de la Norma, en aras de generar certidumbre para los sujetos obligados al cumplimiento. De otro lado, resulta importante precisar que el Consejo Directivo del OSIPTEL, en pleno ejercicio de su función normativa, reconocida en el literal c) del artículo 311 de la Ley N° 27332, Ley Marco de los Organismos Reguladores de la Inversión Privada en los Servicios Públicos, encomendó a la Gerencia General la emisión del Instructivo Técnico. Ello guarda concordancia con el artículo 12 de la Sección Primera del Reglamento de Organización y Funciones de OSIPTEL12, el cual señala lo siguiente:

“Artículo 12.- Funciones de la Gerencia General Son funciones de la Gerencia General las siguientes: (…) p) Otras que le encomiende el Consejo Directivo, el Presidente Ejecutivo o que sean propias de su función.”

(Subrayado y énfasis agregado)

11 Ley Marco de los Organismos Reguladores de la Inversión Privada en los Servicios Públicos, Ley Nº 27332 Artículo 3.- Funciones 3.1 Dentro de sus respectivos ámbitos de competencia, los Organismos Reguladores ejercen las siguientes funciones: (…) c) Función Normativa: comprende la facultad de dictar en el ámbito y en materia de sus respectivas competencias, los reglamentos, normas que regulen los procedimientos a su cargo, otras de carácter general y mandatos u otras normas de carácter particular referidas a intereses, obligaciones o derechos de las entidades o actividades supervisadas o de sus usuarios; Comprende, a su vez, la facultad de tipificar las infracciones por incumplimiento de obligaciones establecidas por normas legales, normas técnicas y aquellas derivadas de los contratos de concesión, bajo su ámbito, así como por el incumplimiento de las disposiciones reguladoras y normativas dictadas por ellos mismos. Asimismo, aprobarán su propia Escala de Sanciones dentro de los límites máximos establecidos mediante decreto supremo refrendado por el Presidente del Consejo de Ministros y el Ministro del Sector a que pertenece el Organismo Regulador (…)” 12 Aprobado mediante Decreto Supremo N° 160-2020-PCM

Por lo expuesto, es claro que la actuación del Consejo Directivo se encuentra conforme a las disposiciones normativas que rigen el ordenamiento jurídico, en tanto se advierte el pleno ejercicio de su función normativa, así como de sus atribuciones asignadas, a efectos de que la Gerencia General pueda emitir los documentos técnicos que correspondan para la implementación de la Norma. En definitiva, la obligación de entrega de información se encuentra recogida en la Resolución de Consejo Directivo y el Instructivo Técnico, cuya aprobación fue encargada por el Consejo Directivo a la Gerencia General en ejercicio legítimo de sus funciones, sólo determina aspectos de cumplimiento de dicha obligación, pero no genera o crea obligaciones adicionales. En cuanto a la presunta vulneración al principio de jerarquía normativa que alega ENTEL, se debe tener en consideración que el Texto Único Ordenado de la Ley Nº 27444 - Ley del Procedimiento Administrativo General, aprobado por Decreto Supremo Nº 004-2019-JUS (en adelante, TUO de la LPAG) establece que la Administración Pública en el ejercicio de la actividad de fiscalización no sólo cuentan con las facultades establecidas en dicha norma, sino también con las previstas en leyes especiales:

“Artículo 240.- Facultades de las entidades que realizan actividad de fiscalización 240.1 Los actos y diligencias de fiscalización se inician siempre de oficio, bien por propia iniciativa o como consecuencia de orden superior, petición motivada o por denuncia. 240.2 La Administración Pública en el ejercicio de la actividad de fiscalización está facultada para realizar lo siguiente: (…) 8. Las demás que establezcan las leyes especiales (…)”

En línea con lo expuesto, el artículo 13 de la LDFF brinda al OSIPTEL la facultad para establecer los plazos, condiciones y formas para la entrega de información por parte de la empresa operadora, inclusive, se menciona que se puede requerir el uso de formatos, además de establecer de forma expresa la facultad del OSIPTEL para que la entrega de la información solicitada se realice mediante mecanismos informáticos, de transmisión de datos en línea o similares.

“Artículo 13.- Plazos y condiciones para la entrega de información 13.1 OSIPTEL establecerá los plazos, condiciones y formas para la entrega de información, los cuales deberán ser obligatoriamente observados por la empresa supervisada para la entrega de la información requerida, atendiendo a su tipo, disponibilidad y volumen. Ello incluye la posibilidad de OSIPTEL para presentar formularios o formatos a ser llenados por la empresa supervisada. 13.2 OSIPTEL, de estimarlo conveniente, podrá disponer en ciertos casos la entrega de información mediante el empleo de mecanismos informáticos o de transmisión de datos en línea o similares (…)”

Es más, la citada Ley autoriza al OSIPTEL a establecer procedimientos especiales de fiscalización cuando lo considere conveniente para facilitar el desarrollo de sus funciones.

“Artículo 9.- Procedimientos especiales OSIPTEL podrá establecer procedimientos especiales de supervisión cuando lo considere conveniente para facilitar el desarrollo de sus acciones supervisoras. Tales procedimientos deben estar enmarcados en las disposiciones contenidas en la presente Ley y deben ser aprobados por Resolución del Consejo Directivo de OSIPTEL, sin perjuicio del procedimiento general que deberá aprobar el Consejo Directivo de dicho organismo y que será de aplicación supletoria.”

De ahí que el ejercicio de las facultades específicas con las que cuenta el OSIPTEL, dadas por las Leyes N° 27332 y N° 27336, en su calidad de Organismo Regulador del sector de telecomunicaciones, no pueden

considerarse como una afectación a la Ley N° 27444, Ley del Procedimiento Administrativo General. En definitiva, el Proyecto de Instructivo se sustenta en las normas antes indicadas, sin contravenir el principio de legalidad ni el principio de jerarquía normativa, contrariamente a lo arguye ENTEL, por lo que desestima su solicitud.

AFIN Al respecto, AFIN refiere que si bien el regulador cuenta con facultad normativa, conforme lo reconoce el marco legal vigente, esta función debe ser exclusivamente ejercida por el Consejo Directivo, como se precisa en el Reglamento de los Organismos Reguladores. Continúa, manifestando que, en el presente caso, se ha realizado una delegación de esta facultad normativa a la Gerencia General, lo cual, según ella, vulnera el marco normativo vigente, más aún cuando se reconoce en el artículo 26 del Reglamento General de OSIPTEL que la función normativa del Consejo Directivo es indelegable. Asimismo, hace énfasis en la necesidad de que la normativa que publique el regulador se haga en cumplimiento estricto de los principios de legalidad y de tipicidad, reconocidos en la Ley Nº 27444 – Ley del Procedimiento Administrativo General, lo cual implica que las nuevas obligaciones e infracciones que se impongan se hagan mediante las herramientas normativas dispuestas en el marco legal vigente, en especial el Reglamento de OORR y por las autoridades facultadas para ello. En este mismo sentido, recalca que las infracciones que se creen deben ser perfectamente definidas en el tipo normativo que se publique, sin establecer que sean otras normas de menor jerarquía y emitidas por autoridades que no cuentan con las facultades requeridas para ello las que las complementen, conforme ha sido reconocido por el propio Tribunal Constitucional. La asociación concluye manifestando que regular el sistema de monitoreo a través de un instructivo de Gerencia General no resulta acorde al principio de legalidad.

Con relación a los comentarios de AFIN respecto de la presunta afectación al principio de legalidad, nos remitimos a lo manifestado anteriormente en atención a los comentarios formulados por ENTEL. No obstante, es importante aclarar que no nos encontramos ante el supuesto de delegación aludido por AFIN, toda vez que no se ha delegado la potestad reguladora y normativa exclusivas del Consejo Directivo; y, además, el Instructivo Técnico no constituirá un cuerpo normativo, en la medida que no crea obligaciones adicionales para las empresas operadoras. Para terminar, debemos señalar que la tipificación de las infracciones y su calificación ha sido realizada de acuerdo con los principios y normas que rigen a la Administración Pública y conforme a lo dispuesto en la LDFF.

TELEFÓNICA

Al respecto, TELEFÓNICA colige que el Instructivo Técnico es una manifestación de la función normativa que poseen los Organismos Reguladores, la cual es de competencia exclusiva por parte del Consejo Directivo. Sin embargo, considera en el presente caso, a través de la Resolución de Consejo Directivo que establece la creación del sistema de migraciones y bajas se estaría delegando la función normativa a la Gerencia General, lo cual no se encuentra acorde y vulnera el marco legal vigente, como se ratifica con lo establecido en el Reglamento del OSIPTEL. Recalca que la función normativa es indelegable y sólo la ejerce el Consejo Directivo del OSIPTEL, por lo que no resulta acorde al principio de legalidad que la Gerencia General regule las especificaciones del Instructivo indicado, más aún cuando el mismo regula procesos y establece obligaciones específicas. En este mismo sentido, la empresa señala que únicamente se reconoce un supuesto en el cual se podría generar la delegación de la función normativa del Consejo Directivo, la cual se encuentra establecida en el literal “j” del artículo 86 del Reglamento del OSIPTEL, único supuesto en el que el presidente del OSIPTEL - y no la Gerencia General- puede adoptar medidas en situaciones de emergencia; sin embargo, dicho supuesto no se configura en el presente caso.

TELEFÓNICA presenta similares comentarios a los de ENTEL y AFIN, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular.

CLARO CLARO afirma que el Proyecto de Instructivo no será aprobado por el órgano competente ni siguiendo los procedimientos exigidos por el marco legal aplicable. Agrega que esta situación, que considera irregular, se ha venido cometiendo desde hace algún tiempo, toda vez que, en los últimos meses, la Gerencia General del OSIPTEL ha emitido diversas resoluciones aprobando instructivos específicos con nuevas obligaciones y exigencias para las empresas operadoras, no previstas en normas reglamentarias ni de mayor jerarquía.

CLARO, en cuanto a este punto, presenta similares comentarios a los de ENTEL y AFIN, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular.

PLAZO DE IMPLEMENTACIÓN


ENTEL Al respecto, la empresa operadora solicita que un plazo adecuado para la entrada en vigencia del sistema automático es de diez (10) meses, contados desde la fecha en que se publique el Instructivo Técnico, dada la complejidad y la información que se pretende mostrar. A más detalle, señala que el Regulador debe considerar que sus recursos son limitados y actualmente sus áreas internas (técnicas y de sistemas) se encuentran desarrollando los distintos proyectos publicados por el Regulador y sobre los cuales se han designado distintos recursos y un tiempo estimado de implementación.

Sobre el plazo para la entrada en vigencia del sistema, tal como se indicó en la “Norma que establece el Sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL, la norma entra en vigencia a los seis (6) meses, contados a partir de la fecha de la publicación del Instructivo Técnico respecto de la información correspondiente a las bajas y migraciones solicitadas por decisión del abonado; y en el plazo máximo de doce (12) meses contados a partir de la fecha de la publicación del Instructivo Técnico, respecto del total de bajas y migraciones solicitadas por los abonados y ejecutadas por la empresa operadora. Cabe indicar que dicha ampliación del plazo de implementación se realizó considerando los otros proyectos normativos que se encuentran en curso, así como los comentarios realizados por las empresas operadoras al Proyecto de Norma.

CLARO

CLARO señala que se han efectuado unas estimaciones preliminares de desarrollo (considerando los formatos preliminares informados en las reuniones de coordinación previamente sostenidas) y se ha estimado un plazo de implementación no menor a los siete (7) meses, debido a que requiere realizar el mapeo de las fuentes que serán utilizadas en cada uno de los formatos (data maping), las adecuaciones pertinentes en las plataformas y sistemas que serán utilizados como fuentes, la generación de los nuevos procesos de generación de los reportes solicitados por el regulador y la elaboración los procesos de contingencia respectivos. Una vez culminadas dichas etapas antes señaladas, indica que es necesario que dichos procesos cumplan un proceso de certificación y calidad interno que permitan asegurar no sólo que su implementación no generará ningún tipo de desalineación en los sistemas, sino principalmente que los reportes cumplen con todos los requerimientos del regulador. Finalmente, la empresa indica que una vez culminadas dichas etapas, resulta necesario efectuar la creación de los procesos de control de calidad

CLARO presenta similares comentarios a los de ENTEL, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular. Finalmente, con relación a los costos de implementación, conforme se desarrolló en el informe que sustenta la Norma, la estimación del costo aproximado de implementación se realizó bajo el supuesto de que las empresas operadoras actualmente son eficientes en sus procesos, en el marco de permitir una correcta trazabilidad del cabal cumplimiento de la normativa vigente. En ese sentido, el costo de implementación calculado tiene como conceptos únicamente a las adecuaciones marginales que se realizarían a la situación actual. Es decir, no se realizan requerimientos a discreción, sino que se solicita aquello que permitan cumplir con el objetivo de la Norma, todo ello con la finalidad de brindar al usuario una atención de calidad en el uso de los servicios públicos de telecomunicaciones.

de la información y conciliación que pudieran resultar necesarios, labores cuyo costo ha sido estimado --preliminarmente-- en no menos de S/300.000 Soles y no S/90 000 Soles como se señala en el proyecto, suma que considera podría ser invertida en la mejora de la red, fortalecimiento de sus sistemas, ampliación de la cobertura, entre otros que traerían beneficios más tangibles a sus clientes.

Por lo tanto, el monto estimado se puede deber a la particular situación de la referida empresa respecto del manejo de sus sistemas de información y a la existencia de ineficiencias que no podrían ser incorporadas en el análisis costo-beneficio.

PLAZO PARA REGULARIZAR LA INFORMACIÓN


TELEFÓNICA

En cuanto al plazo para regularizar el registro de la información, TELEFÓNICA señala que un día hábil no resulta un plazo razonable para regularizar, toda vez que los inconvenientes pueden ser causados por elementos ajenos a su actuar, ya sea por caso fortuito o fuerza mayor, por lo que solicita se brinde un plazo de cinco días hábiles para regularizar la reportería que no pudo ser remitida en la oportunidad correspondiente por las causales anteriormente señaladas o en su defecto. Finalmente, en relación con la solicitud de reuniones de trabajo con el equipo técnico responsable del proyecto para la revisión detallada de sus comentarios que fue formulada por TELEFÓNICA, debemos mencionar que una vez revisados los comentarios presentados por la empresa, no se consideró necesario la programación de la misma, por cuanto la información presentada permitía mostrar la postura de la empresa operadora.

Con relación al comentario formulado por TELEFÓNICA, en tanto se refiere al artículo 6 de la “Norma que establece el Sistema de seguimiento, monitoreo y fiscalización de bajas y migraciones”, aprobada por Resolución de Consejo Directivo N° 00111-2021-CD/OSIPTEL, nos remitimos a lo expuesto por el OSIPTEL en atención a los comentarios expuestos por la referida empresa operadora al artículo en mención.

EVALUAR LA NECESIDAD DE REGULAR LOS PROCESOS DE MIGRACIÓN Y BAJA DEL SERVICIO


CLARO CLARO inicia sus comentarios considerando preocupante la emisión del Proyecto de Instructivo sin haber tomado en consideración lo señalado por ella en su comunicación N° DMR/CE/1102/21, respecto a la peligrosa tendencia de regular mediante la emisión de "instructivos", a la cual se remite para mayor abundamiento. La empresa operadora considera importante resaltar que, en los últimos meses, las empresas operadoras han venido implementado diversos

Para empezar, con relación a lo manifestado por CLARO sobre la falta de consideración de lo expresado en su carta N° DMR/CE/1102/21, es importante precisar que los comentarios formulados por esta a través de la referida comunicación fueron analizados y debidamente atendidos en la Matriz de Comentarios del Proyecto de Norma. Luego, en cuanto a los comentarios formulados por CLARO en este punto, nos remitimos a lo manifestado por el OSIPTEL en la Matriz de Comentarios

proyectos normativos aprobados por el Gobierno que implican no sólo una importante inversión económica, sino también un impacto en los sistemas, por lo que considera de suma importancia analizar si existe una justificación de mercado o de falta de acceso a la información para sustentar la aprobación del Proyecto de Instructivo, esto debido a que tanto la exposición de motivos como el informe correspondiente, a su entender, no efectúa un análisis minucioso al respecto, citando únicamente algunas cifras de atenciones efectuadas por el Regulador en los últimos años. CLARO ahonda en que la justificación es importante en la medida que cualquier propuesta de esta naturaleza supone una fuerte intervención sobre la libertad de empresa de las operadoras que incrementaría sustancialmente los costos para la oferta y prestación del servicio, en la medida que se propone la implementación de un monitoreo diario de transacciones de migración y baja del servicio. En este sentido, la presunta ausencia de justificación específica para este caso es contraria a la obligación del regulador de sustentar sus decisiones y medidas, sobre todo en circunstancias en que genera obligaciones a los administrados. En específico, señala que no se cumpliría con los principios de actuación basada en costo - beneficio, de transparencia y de análisis de decisiones funcionales, previstos en el Reglamento General de OSIPTEL. Añade que no debe perderse de vista que no existen precedentes en la región de una medida similar (con dicho grado de intromisión) que tenga por finalidad verificar el cumplimiento de los plazos de ejecución de las solicitudes de migración v baja del servicio, por lo cual no se ha proporcionado evidencia de éxito de una medida de similar naturaleza. CLARO finaliza expresando que considera que el Regulador debería publicar otro proyecto en el cual se justifique no sólo la necesidad de implementar un mecanismo para controlar la ejecución de solicitud de baja y migraciones, sino principalmente que la medida idónea para dicha finalidad es la publicada en el proyecto y no otra medida menos intrusiva para las empresas operadoras.

del Proyecto de Norma en atención a los comentarios formulados por CLARO respecto de la “necesidad de regular los procesos de migración y baja del servicio”. Por otra parte, con relación a la experiencia internacional en la implementación de sistemas de información para el monitoreo y la fiscalización, se ha identificado que Anatel (Brasil) ha desarrollado un centro de monitoreo remoto, el cual es mucho más exigente, en términos de acceso de información automática y en tiempo real, que la propuesta formulada. En efecto, en el Informe N° 0206-GPRC/2018, que sustenta el fortalecimiento de la capacidad supervisora del OSIPTEL, se señala que desde el 2014 la Anatel de Brasil ha decidido sustituir al Sistema de Auditoría y Fiscalización (SAF), desarrollado por las mismas empresas, por el sistema SAFNext. Este nuevo sistema tiene como objetivo optimizar los flujos de trabajo, permitir al usuario personalizar los reportes e indicadores, y ofrecer una mejor visualización de los datos de interés, características que no se disponían en el SAF. Cabe precisar que el acceso online que realiza la Anatel, en el marco de las acciones de fiscalización, se llevan a cabo observando las prácticas de gestión de seguridad de la información, a fin de preservar y garantizar la continuidad de los servicios, la integridad de los datos, entre otros. En ese sentido, a través de las supervisiones remotas, la Anatel puede visualizar y reproducir los datos y la información de los sistemas de las empresas operadoras, sin interferir en sus actividades. Como se puede apreciar, la experiencia internacional nos indica que la regulación actualmente está buscando realizar sus actividades con el apoyo de sistemas de información modernos y que permitan corregir de una manera más ágil los problemas presentados. Por lo tanto, no se estima necesaria la publicación de un nuevo Proyecto, contrariamente a lo que considera CLARO.

EL SUSTENTO ALEGADO ES INSUFICIENTE Y NO PERTINENTE


CLARO CLARO afirma que el OSIPTEL no ha mostrado ninguna estadística o información concreta que sustente que la migración de planes o solicitudes de baja representa un problema sustantivo para los usuarios en el mercado peruano, que requiera una solución regulatoria de alta intensidad como la propuesta en el proyecto. A manera de ejemplo, hace referencia a que las encuestas que el Regulador realiza anualmente podrían haber sido utilizadas para evaluar este supuesto problema; sin embargo, no se han incluido preguntas relacionadas con este tema. Asimismo, la referida empresa considera que tampoco se ha demostrado que se esté generando un perjuicio a los consumidores, sea a través de consultas puntuales sobre este aspecto y/o apelaciones de usuarios. Por lo tanto, a su entender, no hay evidencia empírica ni sustento práctico que indique que la migración de planes y solicitudes de baja esté ocasionando un perjuicio al consumidor.

Con relación a lo manifestado por CLARO en este punto, nos remitimos a lo expuesto por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados por la citada empresa respecto del “sustento alegado es insuficiente y no pertinente”.

ANÁLISIS DE LA PROPUESTA REALIZADA POR EL REGULADOR


AFIN AFIN sostiene que la obligación de implementar el sistema propuesto debe ser analizado a la luz del principio costo - beneficio y del principio de proporcionalidad, para lo cual el Regulador debe sustentar que lo que busca solucionar a través de su propuesta es resolver un problema que sea relevante estadísticamente, siendo necesaria una intervención regulatoria de esta magnitud. De igual manera, señala que se debe acreditar que la medida propuesta resulta la menos onerosa y la más razonable, en comparación con otras medidas, tales como sería, por ejemplo, solicitar el envío de reportería con periodicidad mensual, lo cual, a su entender, no se encuentra acreditado en el informe que sustenta la creación del sistema de monitoreo. Por otro lado, AFIN manifiesta que no existen precedentes en la región de una medida similar (con dicho grado de injerencia en las actividades de los

En lo referido a la experiencia comparada y la información estadística a la que hace referencia AFIN, nos remitimos a lo manifestado por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados por la referida asociación sobre el “correcto análisis de calidad regulatoria”. En cuanto a la alternativa de remitir la información de manera mensual, la misma contraviene los objetivos de la norma, debido a que el OSIPTEL no contará con la información que le permita verificar la adecuada atención de las bajas y migraciones, y, en los casos que corresponda, disponer las medidas necesarias y oportunas para corregir cualquier falla que se presente, generando mayor afectación a los usuarios, quienes tampoco podrán verificar, de manera actualizada, el estado de sus solicitudes.

operadores) que tenga por finalidad verificar el cumplimiento de los plazos de ejecución de las solicitudes de migración y baja del servicio, por lo cual no se ha proporcionado evidencia de éxito de una medida de similar naturaleza. En tal sentido, estima que la ausencia de justificación específica para este caso es contraria a la obligación del Regulador de sustentar sus decisiones y medidas, sobre todo en circunstancias en que genera obligaciones a los administrados. En específico, no se cumpliría con los principios de actuación basada en costo - beneficio, de transparencia y de análisis de decisiones funcionales. En el caso en cuestión, AFIN considera que el OSIPTEL no ha mostrado ninguna estadística o información concreta que sustente que la migración de planes o solicitudes de baja representa un problema sustantivo para los usuarios en el mercado peruano que requiera una solución regulatoria de alta intensidad como la propuesta en el proyecto. Por lo tanto, colige que no habría evidencia empírica ni sustento práctico que indique que la migración de planes y solicitudes de baja esté ocasionando un perjuicio al consumidor, por lo que el beneficio de una eventual reducción de consultas por parte de los usuarios sería limitado, en tanto, según ella, no se ha acreditado que en la actualidad exista una problemática respecto de las consultas de dichas transacciones (baja y migración). Finalmente, estima que estandarizar la inversión que implicaría la elaboración del sistema por parte de las empresas operadora no responde a la realidad del mercado, toda vez que cada empresa cuenta con sistemas distintos y los desarrollos también serían diferentes.

Finalmente, con relación a los costos de implementación, conforme se desarrolló en el informe que sustenta la norma, la estimación del costo aproximado de implementación se realizó bajo el supuesto de que las empresas operadoras actualmente son eficientes en sus procesos, en el marco de permitir una correcta trazabilidad del cabal cumplimiento de la normativa vigente. En ese sentido, el costo de implementación calculado tiene como conceptos únicamente a las adecuaciones marginales que se realizarían a la situación actual. Es decir, no se realizan requerimientos a discreción, sino que se solicita aquello que permitan cumplir con el objetivo de la norma, todo ello con la finalidad de brindar al usuario una atención de calidad en el uso de los servicios públicos de telecomunicaciones.

NO SE HA ACREDITADO QUE LOS BENEFICIOS SUPEREN LOS COSTOS


CLARO CLARO considera que, en el caso de la medida propuesta por el OSIPTEL, no se puede apreciar la aplicación de los principios de actuación basados en el análisis costo-beneficio, de análisis de decisiones funcionales, de eficiencia y efectividad y de subsidiariedad, lo que implica, según su

Con relación a lo manifestado por CLARO en este punto, nos remitimos a lo indicado por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados por la citada empresa respecto de “no se ha acreditado que los beneficios superen los costos”.

entender, que no se haya realizado una correcta identificación del problema ni de las mejores alternativas para solucionarlo. Si bien en el Informe y la exposición de motivos se analizan los motivos de la propuesta regulatoria, considera que su contenido no es suficiente para demostrar la existencia de una problemática que se busque combatir a través de la propuesta formulada y que los beneficios de la propuesta superan los costos de la misma. La empresa agrega, sobre los beneficios de la propuesta, que, según el proyecto, se encontrarían relacionados a una eventual reducción de consultas por parte de los usuarios; sin embargo, estima estos beneficios limitados, en tanto no se habría acreditado que, en la actualidad, exista una problemática respecto de las consultas de dichas transacciones (baja y migración). CLARO continúa, señalando que se ha identificado el principal beneficio de la propuesta, pero no se han ponderado los costos, es decir, según ella, se habría aplicado la lógica inversa que recomienda la teoría y la práctica del análisis de impacto regulatorio (AIR), que señala que debido a que en determinadas ocasiones la valoración monetaria de los beneficios es compleja, la valoración de los costos debe ser lo que permita decidir cuál es la alternativa más eficiente13. La empresa finaliza afirmando que todos los efectos adversos de la aplicación de estas medidas no se han identificado ni ponderado, tales como: los efectos negativos en el bienestar de los consumidores, la competencia en el mercado de servicios móviles, el desempeño de las operadoras, etc., que, según ella, se presentarían.

EJECUCIÓN DE PROCESOS DE MIGRACIÓN Y BAJA DEL SERVICIO


CLARO En este punto, CLARO señala que, en los últimos años, ha podido apreciar una mayor cantidad de solicitudes de cancelación y baja del servicio atendidas oportunamente, mostrando los siguientes cuadros:

Con relación a lo expuesto por CLARO en este punto, nos remitimos a lo manifestado por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados por la citada empresa respecto de “la ejecución de procesos de migración y baja del servicio”.

13 Organisation for Economic Cooperation and Development - OECD - SIGMA. Improving policy instruments through impact assessment. Sigma Paper 312001 (2001), p. 29.

De lo expuesto, CLARO deduce que existe una tendencia constante en las solicitudes de bajas a pedido del cliente (servicios móviles y fijos), así como en las migraciones de postpago a prepago del servicio móvil, en el sentido que han sido adecuadamente atendidas, la misma que fue impactada (al igual que todos los sectores económicos) durante los meses de marzo, abril y mayo del 2020 como consecuencia del COVID-19, durante los cuales los canales de atención al cliente presenciales y no presenciales no pudieron funcionar con normalidad y cuando se reinició la atención en la "nueva normalidad", los nuevos protocolos aprobados no permitían atender a la

misma cantidad de clientes que se atendían antes del inicio de la cuarentena del mes de marzo del 2020. Seguidamente, explica que, luego de la brecha presentada en los meses de abril, mayo y junio del 2020, la cantidad de transacciones de baja y migración ejecutadas no sólo se recuperaron sino que se incrementaron considerablemente a pesar de las restricciones en la atención a los clientes, lo cual representa, a su entender, la mejor prueba de que dichos procedimientos se encuentran funcionando adecuadamente y no es necesaria la intervención regulatoria (y, menos aún, la utilización de un mecanismo regulatorio de gran intensidad como el propuesto). Afirma que es respetuosa de los plazos aprobados por el OSIPTEL para el cumplimiento de las solicitudes de baja y migración del servicio, lo cual considera que se encuentra respaldado por las cifras de reclamos por "baja o desactivación del servicio y migración" y "cambio de plan tarifario" que muestra:

En cuanto a las cifras de reclamos antes señaladas, afirma que no hacen distinción del servicio reclamado, lo cual, según ella, demuestra que no existe una problemática real en las ejecuciones de las solicitudes de baja y cambio de plan. A mayor abundamiento, toma la casuística del mes de enero del presente año, en el cual se ejecutaron 20,471 solicitudes de baja (a pedido del servicio) correspondiente al servicio móvil y fijos, señalando que en dicho mes se presentaron 295 reclamos por dicha materia, de los cuales sólo 8 fueron declarados fundados. Es decir, de la totalidad de solicitudes de baja ejecutadas (100%) en el referido mes, el 1.44% tuvo algún inconveniente en su tramitación que ameritó que el cliente tuviera que presentar un

reclamo, y sólo el 0.04% fue declarado fundado, lo cual estima que demuestra que no existe una problemática real que amerite la intervención del Regulador. CLARO realiza un ejercicio similar con las solicitudes de migración presentadas por los clientes en el mes de enero del presente año, en el cual se ejecutaron 14,993 migraciones de postpago a prepago y se presentaron 410 reclamos por la materia de "migración / cambio de plan tarifario", de los cuales sólo 7 fueron declarados fundados. Es decir, de la totalidad de migraciones ejecutadas (100%), el 2.73% presentó algún inconveniente que ameritó la presentación de un reclamo y sólo el 0.05% (del total de migraciones de ese mes) fue declarado fundado, lo cual considera refuerza lo señalado respecto de la falta de existencia de una problemática que amerite una intervención regulatoria tan intensa como la propuesta en el proyecto. Por todo lo expuesto, la empresa arguye que no se justificaría la aprobación de medidas sumamente intrusivas y gravosas como las que considera se encuentran contenidas en el proyecto.

RESPECTO AL IMPACTO EN EL DERECHO DE DEFENSA (EX ANTE)


CLARO

CLARO manifiesta que los términos del proyecto no son compatibles con el régimen de fiscalización o inspección previsto en la LPAG, el cual presupone -como una manifestación del derecho de defensa- que el administrado fiscalizado participe (o pueda participar) en la acción de fiscalización o supervisión ejerciendo determinados derechos. La empresa cita, a manera de ejemplo, que el numeral 4 del artículo 240 de la LPAG permite a la entidad fiscalizadora realizar grabaciones sólo si previamente se ha puesto ello en conocimiento del administrado:

"Artículo 240.- Facultades de las entidades que realizan actividad de fiscalización 240.2 La Administración Pública en el ejercicio de la actividad de fiscalización está facultada para realizar lo siguiente: (…)

Con relación a lo manifestado por CLARO en este punto, nos remitimos a lo expuesto por el OSIPTEL en la Matriz de Comentarios del Proyecto de Norma en atención a los comentarios formulados referidos al “impacto en el derecho de defensa”

4. Tomar copia de los archivos físicos, ópticos, electrónicos u otros, así como tomar fotografías, realizar impresiones, grabaciones de audio o en video con conocimiento previo del administrado y, en general, utilizar los medios necesarios para generar un registro completo y fidedigno de su acción de fiscalización"

Asimismo, cita que el artículo 241 de la misma norma establece como obligaciones de la Administración identificarse presentando su credencial y entregar copia del acta de fiscalización al administrado, lo cual -obviamente- presupone que el mismo participa en la inspección.

"Artículo 241.- Deberes de las entidades que realizan actividad de fiscalización 241.2 Las autoridades competentes tienen, entre otras, los siguientes deberes en el ejercicio de la actividad de fiscalización: (…) 2. Identificarse a requerimiento de los administrados, presentando la credencial otorgada por su entidad, así como su documento nacional de identidad"

De igual manera, hace referencia al artículo 242 de la LPAG, el que señala como derechos de los administrados fiscalizados -entre otros-: requerir las credenciales de los fiscalizadores, realizar grabaciones, incluir sus observaciones en el acta y llevar asesoría profesional a la diligencia:

"Artículo 242.- Derechos de los administrados fiscalizados Son derechos de los administrados fiscalizados: 1. Ser informados del objeto y del sustento legal de la acción de supervisión y, de ser previsible, del plazo estimado de su duración, así como de sus derechos y obligaciones en el curso de tal actuación. 2. Requerir las credenciales y el documento nacional de identidad de los funcionarios, servidores o terceros a cargo de la fiscalización. 3. Poder realizar grabaciones en audio o video de las diligencias en las que participen.

4. Se incluyan sus observaciones en las actas correspondientes (…)

La empresa concluye este punto precisando que cada uno de estos derechos y obligaciones solo puede materializarse si la entidad fiscalizadora ha permitido al administrado estar presente en la acción de fiscalización que se realiza de manera concreta en un momento determinado. En otras palabras, el cumplimiento de las garantías otorgadas depende necesariamente de que el administrado se encuentre físicamente para tutelar el respeto de la norma por parte de la Administración. CLARO resalta que esta condición es esencial dentro de nuestro sistema de fiscalización y permite que todo levantamiento de información pueda darse en pleno conocimiento de la información concreta y precisa que se está solicitando (lo cual se da incluso en las solicitudes de entrega de información, en cuyo caso el administrado es consciente de la información que está presentado). En cuanto al sistema de verificación de cumplimiento de las solicitudes de bajas y migraciones, CLARO considera que es incompatible con las disposiciones de la LPAG o, lo que es lo mismo, el proyecto deja sin contenido el capítulo referido a la actividad de fiscalización contenido en la LPAG. Añade que si se pretende imponer una regulación que no permite su tutela durante las actuaciones de fiscalización, entonces no puede aprobarse porque sería inconsistente con el marco normativo general aplicable. Así, trae a colación que, en términos generales, las recientes modificaciones a la LPAG han tenido por objeto generar un escenario de respeto a los derechos de los administrados, que además persiga un control normativo compatible con un sistema garantista y que no genere abusos de poder ni exigencias ilegales. Continúa, explicando que, en línea con las nuevas tendencias de la fiscalización propuestas por la OCDE (por ejemplo, la Responsive Regulation), que buscan escenarios de mayor colaboración y acercamiento entre los administrados y la Administración14, es necesario que todas las

14 Al respecto ver: OECD. "Regulatory Policy in Peru: Assembling the Framework for Regulatory Quality". OECD Reviews of Regulatory Reform. 2016. Disponible en: http://www.keepeek.com/Digital-AssetManagementloecd/governance/regulatorv-policv-in-peru 9789264260054-en#page3.

regulaciones permitan escenarios de fiscalización transparentes y garantistas, donde se permitan las manifestaciones, observaciones y opiniones de los fiscalizados. La empresa considera que nada de ello se cumple en la regulación contenida en el proyecto bajo análisis. Por otro lado, alega que el OSIPTEL, en relación con las Acciones de Supervisión15, establece que "El OSIPTEL verifica el cumplimiento de las obligaciones legales, contractuales o técnicas por parte de las empresas operadoras y demás empresas o personas que realizan actividades sujetas a su competencia", por lo que se deja claramente definido que el regulador tiene una función supervisora que se basa en la verificación del cumplimiento de obligaciones legales. En este sentido, en cuanto al término “verificar”, menciona que, según la Asociación de Academias de la Lengua Española, este se define como "comprobar o examinar la verdad de algo"16. Es por ello que, a su entender, claramente se puede definir que la acción de supervisión se enmarca únicamente en comprobar que el administrado cumple con la obligación legal; mas no, en vigilar el comportamiento del administrado, dado que ello se basaría en una interpretación de que el administrado actúa siempre de mala fe, lo cual se contrapone con lo establecido en el numeral 1.8 del artículo IV de la LPAG que establece lo siguiente:

1.8. Principio de buena fe procedimental.- La autoridad administrativa, los administrados, sus representantes o abogados y, en general, todos los partícipes del procedimiento, realizan sus respectivos actos procedimentales guiados por el respeto mutuo, la colaboración y la buena fe. (…) Ninguna regulación del procedimiento administrativo puede interpretarse de modo tal que ampare alguna conducta contra la buena fe procedimental.

Por lo expuesto, la empresa expresa su preocupación con que se intente establecer una acción de supervisión (ex ante) que se base en la vigilancia, dado que ello establecería una interpretación de que el administrado siempre actuaría de mala fe, contraviniendo lo textualmente establecido por

15 0 rganismo Supervisor de Inversión Privada en Telecomunicaciones (OSIPTEL), Pagina Web de OSIPTEL, Acciones de Supervisión. https:l/www.osiptel.qob.pe/porta/-de-operadoras/supervisiones-v-sanciones/acciones-de-supervision/ 16 Asociación de Academias de la Lengua Española, Diccionario de la Lengua Española, Siginicado de Verificar, https://dle.rae.es/verificar

la LPAG, con lo cual se desnaturalizaría la función supervisora de los entes competentes.

EJERCICIO DE LA FUNCIÓN SUPERVISORA


AFIN Sobre este punto, AFIN señala que, a través del sistema de monitoreo, las empresas operadoras se encontrarían siendo supervisadas de manera permanente, y no habría fecha de fin de la actividad supervisora, lo cual considera que vulnera los principios de debido procedimiento y de predictibilidad.

Con relación a la presunta contravención a los principios del debido procedimiento y predictibilidad que alega AFIN, se debe tener en cuenta que este sistema de seguimiento no será utilizado de manera exclusiva para la fiscalización, sino que también debe servir para definir acciones de prevención. En ese sentido, la estrategia de cumplimiento (enforcement) que motiva este proyecto normativo supone el desarrollo de alertas de riesgos y la definición de umbrales para iniciar acciones de supervisión, por lo que se descarta que el OSIPTEL esté planificando algo semejante como una fiscalización permanente. Asimismo, se debe precisar que la implementación del sistema de seguimiento no implica que este Organismo no siga los procedimientos establecidos para el ejercicio de su función supervisora y los principios que rigen dicha actuación. En este sentido, el referido sistema servirá como fuente de información que el OSIPTEL considerará para sus acciones de monitoreo o supervisión, las cuales se ajustarán a las disposiciones establecidas en el Reglamento General de Supervisión y el TUO de la LPAG, respecto de las cuales este Organismo siempre se ha mantenido respetuoso. Aunado a ello, las empresas operadoras cuentan con libre acceso a los expedientes de supervisión y, por tanto, podrán ejercer su derecho de defensa cuando lo consideren pertinente, y, por su parte, el Proyecto de Instructivo define las directrices para la carga y descarga de información, lo que genera predictibilidad respecto del uso de la herramienta propuesta.

TEMPORALIDAD DE LA ENTREGA DE LA INFORMACIÓN


TELEFÓNICA

En este punto, TELEFÓNICA manifiesta que no se señala un periodo para la entrega de la información, por lo que la misma debería ser entregada de manera indefinida; sin embargo, considera que la entrega de información y su periodicidad debe estar en función a un alcance temporal. De lo contrario, se encontraría ante una acción de supervisión permanente, lo cual supera ampliamente la facultad supervisora que tiene la Administración Pública para el ejercicio de sus funciones. La empresa ahonda en que la doctrina también ha señalado en distintas oportunidades la necesidad de contar con una delimitación temporal de las acciones de supervisión, lo que permitirá a las empresas poder organizar sus recursos y cumplir de manera adecuada con la atención de estas. Agrega que este plazo se encuentra reconocido no sólo en los principios de debido procedimiento y predictibilidad, sino en el principio convencional y constitucional de razonabilidad en el plazo. Por tanto, señala que, en caso se dé este envío, el mismo debe realizarse dentro de un periodo de tiempo, no pudiendo ser indefinido al vulnerar derechos y principios del ordenamiento jurídico previamente citados.

TELEFÓNICA, sobre este punto, presenta similares comentarios a los de AFIN, por lo que nos remitimos a lo desarrollado anteriormente sobre el particular.

Documents

PROYECTO DE INSTRUCTIVO TÉCNICO DEL SISTEMA DE SEGUIMIENTO …