Manual de Usuario — Salesforce + Kulturra Payments

Cómo usar este manual

Este manual explica qué hace cada botón, qué significa cada estado, y por qué el sistema se comporta como se comporta — no solo los clics a dar, sino la lógica de negocio detrás, para que puedas resolver situaciones que no están exactamente descritas aquí.

A lo largo del documento vas a ver tres tipos de recuadro:

💡 Tip — un atajo o una aclaración que te ahorra tiempo.

⚠️ Atención — algo que, si lo pasás por alto, puede causar un cobro incorrecto o un problema para el cliente.

🔧 Estado del sistema — para que sepas si lo que estás leyendo ya está funcionando y confirmado, o si todavía es un desarrollo en curso.

Siempre que una pantalla pueda verse distinto a la captura (Salesforce cambia layouts con el tiempo), el texto y el comportamiento descrito son lo que debés tomar como referencia.

1. La pestaña Services del Customer

Cada Customer (el residente/cliente que paga el servicio — no confundir con el Account, que representa la Propiedad) tiene una pestaña Services con dos tablas: Customer Packages y Customer Discounts.

Vista general: tabla de Customer Packages con sus badges de estado, y Customer Discounts debajo.

Customer Packages lista cada servicio que el Customer tiene o tuvo — recurrente (Internet, Entertainment) o One-Time (Equipment) — con columnas para precio bruto, descuento, neto, impuesto, monto final, el período de servicio, y tres badges de color que resumen todo lo que necesitás saber de un vistazo:

• Status (verde Active, naranja Pending Activation/Pending Cancellation, gris Inactive) — el estado del servicio en sí.
• Bulk (Bulk / Non-Bulk) — si el servicio es parte del paquete de propiedad (sin costo para el residente) o un servicio individual que el Customer paga.
• Sync (Synced / Pending / Error) — si ese servicio ya quedó reflejado del lado de Kulturra (la plataforma de facturación). Pending es normal mientras el sistema procesa el cambio; si se queda en Error por más de unos minutos, ver la Sección 15.

💡 Tip — la columna Tax muestra el desglose completo en una sola celda (por ejemplo "$11.84 FLORIDA · 7.40%"). Si necesitás explicarle a un cliente por qué un monto incluye impuesto, está ahí, no hace falta ir al PDF de la factura (que no desglosa el impuesto por línea).

Desde esta tabla tenés tres botones, y marcás Show Inactive si querés ver también los servicios ya terminados (para preservar el historial, nunca se borran):

• Add Package — agregar un servicio nuevo (recurrente, One-Time, o un cambio de Internet). Ver Sección 3 y siguientes.
• Generate Invoice — facturar los cargos pendientes. Ver Sección 6.
• Inactivate Customer (el botón cambia de nombre a Revert o Activate Customer según el estado del Customer) — da de baja, reactiva, o activa por primera vez al Customer. Ver Sección 2 (Activate Customer) y Sección 13 (Inactivate y Revert).

Customer Discounts, debajo, lista los descuentos aplicados a cualquiera de los paquetes de ese Customer, con su propio botón Add Discount (Sección 5).

2. Crear y activar un Customer

Antes de venderle o cobrarle cualquier servicio, el Customer tiene que existir y estar activo. Esta sección cubre los pasos en orden: crearlo, activarlo, y qué pasa si su Unit ya tenía otro Customer.

Crear un Customer

Un Customer se crea desde su Unit (la unidad donde vive). El dato clave es su Party: el registro de la persona (un Individual) a nombre de quien queda el servicio. Los pasos son:

1. Entrá a la Unit y abrí su lista de Customers. Abrí la Unit (pestaña Units → la unidad). Debajo del encabezado hay una franja de enlaces; hacé clic en Customers. Se abre la lista de Customers de esa Unit — vacía si es la primera vez — y ahí apretás New.

Desde la Unit: el enlace Customers abre la lista de esa unidad y el botón New abre el formulario New Customer.

2. Elegí o creá el Party. En el formulario New Customer, el campo Party es obligatorio. Hacé clic en él y elegí + New Individual (abajo de la lista).

El Party es la persona (Individual). Si ya existe, la podés buscar; si es nueva, + New Individual.

3. Completá el New Individual. Last Name, Phone Number y Email Address son obligatorios (y conviene completar también el First Name). Guardá con Save.

Formulario New Individual. El correo es importante: Kulturra lo exige para poder facturarle.

4. Volvé al New Customer y completá el Name. El Party queda con la persona que acabás de crear. Copiá ese nombre en el campo Name, que también es obligatorio y no se completa solo. No hace falta tocar nada más: Status ya viene en Inactive y la Unit ya viene puesta porque entraste desde ella.

New Customer listo para guardar: Name igual al nombre del Party, Status Inactive y la Unit de origen.

5. Guardá. Apretá Save. El Customer queda creado como Inactive, sin servicios. Después se activa desde su pestaña Services (ver abajo, "Activar el Customer").

Qué hace el sistema solo al crearlo:

• Crea el Contact del Customer con el mismo nombre y el correo del Individual, y lo deja ligado al Customer (y a la propiedad). No lo cargues a mano.
• Liga el Individual de vuelta al Customer.
• Status arranca en Inactive: no se le puede vender ni cobrar nada hasta activarlo con el botón Activate Customer.
• Cuando lo activás por primera vez, el sistema crea solo su facturación recurrente de Kulturra (vacía y sin activar); empieza a facturar cuando se paga el primer cargo.

💡 Tip — no hace falta crear la factura recurrente ni vincularla a mano; el sistema lo hace al activar. Y si más adelante el Contact quedara sin correo, Kulturra puede fallar al crear la facturación recurrente: revisá que el correo siga puesto.

Activar el Customer

Con el Customer en Inactive (un Customer nuevo, o uno que volvió después de una baja), el botón de arriba de la tabla de Customer Packages dice Activate Customer. Al activarlo, el sistema agrega automáticamente cualquier servicio Bulk que le corresponda por el Price Book de su propiedad, sin costo, y crea un Case si hizo falta activar algún Bulk nuevo.

💡 Tip — en el modal de Activate verás una advertencia de que se agregará el servicio Bulk automáticamente; es información, no algo que tengas que configurar vos.

• El Case de activación Bulk: si se agregó algún servicio Bulk, se crea un solo Case (con asunto "Bulk services activated - technical activation needed: [nombre del Customer]") en la cola S1 Queue, que lista todos los servicios Bulk agregados, para que el equipo de campo haga la activación técnica/de red. Si no se agregó ningún Bulk (por ejemplo, ya lo tenía), no se crea Case.
• Si la propiedad no tiene Price Book o un Bulk falla: la activación del Customer igual se completa. Si falta un Bulk, agregalo a mano con Add Package.
• Si ya hay otro Customer Active en la misma Unit: el modal te avisa antes de confirmar con el texto "This Unit already has an Active Customer: [nombre]…", y te lista sus servicios activos. Al confirmar, el otro Customer se inactiva ese mismo día: sus servicios terminan hoy, sin reembolso prorrateado; sus facturas futuras sin pagar se anulan (las ya pagadas no se tocan); y se crea un Case de desconexión en S1 Queue. Solo un Customer puede estar Active por Unit (ver más abajo, "Un solo Customer activo por Unit").
• Si el Customer está Suspended: el botón no deja activarlo a mano; verás "This Customer is Suspended for non-payment. This status is managed automatically by the billing system and cannot be changed manually."

Un solo Customer activo por Unit

Cada Customer vive en una Unit (un apartamento o unidad de una propiedad). La Unit apunta siempre a su Customer actual. Solo puede haber un Customer Active por Unit: cuando se activa uno nuevo en una Unit que ya tenía otro activo (por ejemplo, cambió el residente), el sistema inactiva al anterior ese mismo día y pone el nuevo como Customer actual de la Unit. Qué ocurre con el anterior:

• Sus servicios terminan hoy (End Date = hoy), sin reembolso prorrateado, en vez de esperar al fin de mes.
• Su facturación recurrente de Kulturra se desactiva.
• Sus facturas futuras sin pagar se anulan; las ya pagadas no se tocan.
• Se crea un Case de desconexión (tipo Cancellation, cola S1 Queue) que lista los servicios finalizados, para que el equipo de campo desconecte el servicio.

El modal de Activate Customer te avisa de todo esto antes de confirmar.

💡 Tip — con el Customer ya Active, el siguiente paso es agregarle sus servicios: ver la Sección 3.

3. Agregar un servicio recurrente

Un servicio recurrente es cualquier cosa que se cobra mes a mes — Internet, Entertainment, HBO Max, etc. (lo opuesto a un servicio One-Time, que se cobra una sola vez — ver Sección 4).

Desde Add Package, elegís el servicio en Available Packages (la lista sale del Property Price Book de esa propiedad específica — si un servicio no aparece, probablemente no está configurado en el Price Book de esa propiedad; ver Apéndice A), una Start Date, y la Quantity.

Qué pasa según la fecha que elijas:

• Si el Start Date es hoy o una fecha pasada dentro del mismo mes, el sistema cobra una proración inicial: del día de inicio hasta el último día del mes, no el mes completo. El servicio queda en Pending Activation hasta que se pague esa proración.
• Si el Start Date es futuro, el servicio queda en Pending Activation y no se activa solo, aunque se pague, hasta que llegue esa fecha.
• Una vez pagada la proración (o cualquier cargo inicial) y llegada la fecha de inicio, el servicio pasa solo a Active — no hace falta que nadie lo active a mano.

⚠️ Atención — Internet y Service Tier Rank. Si el servicio que estás agregando es de tipo Internet, el campo Service Tier Rank (en Mbps) tiene que estar bien configurado en su Service Catalog — aunque el formulario no lo exija. Si falta o está mal, el sistema no va a poder clasificar correctamente un Upgrade o Downgrade más adelante para ese servicio. Esto se configura al crear el Service Catalog (ver Apéndice A), no al agregar el paquete.

⚠️ Atención — un solo Internet no-Bulk a la vez. Si el Customer ya tiene un servicio de Internet activo o pendiente, el sistema no te va a dejar agregar otro desde cero — para cambiar de plan de Internet usás Upgrade, Downgrade o Replacement (Secciones 9–11), no "Add Package" de nuevo.

El modelo es prepago mensual: los días antes del Start Date nunca se cobran, y si el servicio se cancela después de pagado, no se genera un reembolso prorrateado por los días no usados — el servicio sigue activo hasta el final del período ya pagado (ver Sección 13).

4. Agregar un servicio One-Time

Un servicio One-Time (por ejemplo, un cargo de equipo) se cobra una sola vez, no mes a mes, y sigue un camino de estados distinto al de un recurrente:

Pending Billing  →  Pending Payment  →  Billed

• Pending Billing: el cargo existe pero todavía no se generó ningún Invoice para él.
• Pending Payment: ya se generó (o se agrupó en) un Invoice, esperando el pago.
• Billed: pagado por completo.

Un servicio One-Time nunca se convierte en una línea recurrente de Kulturra — no tiene ciclo mensual ni se le aplica proración. Si es taxable, el impuesto se calcula igual que en un servicio recurrente y se ve en la misma columna Tax de la tabla de Customer Packages.

5. Aplicar y desactivar un descuento

Desde Add Discount, primero elegís el Customer Package sobre el que va el descuento, y después el descuento específico de la lista de Available Discounts (solo aparecen los descuentos que ya están configurados y vigentes para ese servicio en esa propiedad — ver Apéndice A).

Add Discount: primero el paquete, después el descuento disponible para ese paquete.

Cada descuento que ves en la lista muestra su tipo (Amount en dólares, o Percent), si es Stackable (se puede combinar con otro descuento sobre la misma línea) o no, y su rango de fechas efectivo:

Dos descuentos marcados "Stackable" sobre el mismo paquete — se pueden aplicar los dos a la vez.

Si un descuento no es Stackable, el sistema bloquea un segundo descuento sobre la misma línea mientras el primero siga activo. Si son Stackable (como en la imagen), ambos se suman: en un caso real confirmado, $10 + $20 de descuento se sumaron correctamente a $30 sobre la misma línea.

Al aplicar o quitar un descuento, el Net y el Amount de la línea se recalculan solos, y la línea queda marcada para volver a sincronizarse con Kulturra (vas a ver el badge de Sync pasar por Pending un momento).

Desactivar un descuento no lo borra — queda en el historial con su fecha de fin, igual que un servicio cancelado. Si el paquete sobre el que estaba el descuento llega a Inactive, cualquier descuento activo sobre esa línea se desactiva automáticamente como parte de ese mismo proceso.

6. Generar un Invoice (Generate Invoice)

El botón Generate Invoice agrupa en una sola factura de Kulturra todos los cargos pendientes de facturar de ese Customer: cargos de proración inicial, de Upgrade, y cualquier servicio One-Time que todavía esté en Pending Billing.

💡 Tip — si un Customer tiene varios cargos pendientes al mismo tiempo (por ejemplo, un servicio nuevo de Entertainment más un equipo), un solo clic en Generate Invoice los agrupa a todos en la misma factura — no hace falta generar una por cada uno. Esto está confirmado funcionando: un caso real agrupó 2 servicios recurrentes más 1 equipo en una única factura de 3 líneas.

Algunas cosas importantes sobre este botón:

• Si volvés a apretarlo cuando ya hay una factura pendiente para esos mismos cargos, el sistema no crea una segunda factura — te vuelve a mostrar la que ya existe.
• Generar este Invoice no usa el mecanismo de facturación recurrente normal de Kulturra ni adelanta el ciclo mensual del Customer — es estrictamente para estos cargos puntuales.
• Si una factura se anula (Voided) sin que se haya pagado nada, el cargo de esa factura queda en Voided y el servicio que todavía no se había activado pasa a Inactive. Generate Invoice no lo rescata: si la facturación estaba mal, agregá el servicio de nuevo correctamente y generá una factura nueva. Ver Sección 7.

Una vez generada, la factura vive del lado de Kulturra (el Invoice real, con su PDF y su link de pago) — ver Sección 7 para qué pasa después.

7. Pago y activación del servicio

El pago en sí siempre pasa por Kulturra — por el botón interno "Pay Invoice" (para cuando un agente cobra en nombre del cliente) o por el link público de pago que recibe el cliente por correo. Salesforce no procesa el pago; solo reacciona a lo que Kulturra confirma.

Pantalla de pago (botón interno "Pay Invoice"): acá se elige Full Amount o Partial Amount.

Pago completo — una vez que Kulturra confirma el pago total:

• El cargo pasa a Billed.
• Si el servicio es recurrente y su Start Date ya llegó, pasa a Active solo.
• Si es un Upgrade, el servicio anterior se cierra (ver Sección 9).
• El servicio queda marcado para sincronizarse con Kulturra.

⚠️ Pago parcial — el servicio NO se activa. Si se paga solo una parte de la factura (como en la imagen de arriba), el cargo se queda en Pending Payment y el servicio en Pending Activation — a propósito. Es una validación financiera: el sistema no activa un servicio que todavía no está completamente pagado. El Invoice queda con estado Partial hasta que se complete el pago restante.

🔧 Comportamiento confirmado de Kulturra, no de Salesforce: un pago parcial sí deja activa (fw1__Is_Active__c = true) la Recurring Invoice del Customer del lado de Kulturra, aunque el servicio en sí se quede correctamente sin activar. Esto es comportamiento del paquete gestionado de Kulturra, confirmado por descarte completo del código propio — no es un error de Salesforce, y no afecta que el servicio del cliente se active correctamente solo cuando el pago se completa.

Si en algún momento ves que el link público de pago no te deja ingresar un monto parcial — es esperado: solo el botón interno "Pay Invoice" soporta pago parcial; el link que recibe el cliente por correo solo acepta el monto completo.

Invoice anulado (Voided) sin pago: si una factura se anula (por ejemplo, un agente marca Is Voided en el Invoice de Kulturra) y no se había pagado nada, el sistema hace esto solo:

• Cada cargo de esa factura pasa a Voided y conserva su historial (la factura, la fecha y el período quedan como referencia; no se reciclan).
• Cada servicio vinculado que nunca llegó a activarse (estaba en Pending Activation, Pending Billing o Pending Payment) pasa a Inactive, sin End Date, porque nunca empezó.
• Un servicio que ya estaba Active no se toca — por ejemplo, el plan anterior de un Upgrade cuya diferencia se anuló sigue activo.

La razón de este diseño: si la facturación estaba mal, el agente agrega el servicio de nuevo, correctamente, y genera una factura nueva, en vez de reutilizar un cargo equivocado. Solo se afectan los servicios de esa factura; ningún servicio activo no relacionado.

🔧 Estado del sistema: implementado, todavía no validado de punta a punta. La regla está desplegada y cubierta por pruebas automáticas del cierre por suspensión, pero falta repetir la prueba en vivo con un Invoice anulado a mano (caso Voided del UAT).

Auto Bill Pay Date: en las facturas de un Customer que tiene cobro automático (Auto Bill Pay) activado, el sistema pone la Auto Bill Pay Date 2 días antes de la fecha de vencimiento (Due Date) cuando la factura se crea. Si después alguien cambia la Due Date, la Auto Bill Pay Date no se recalcula sola.

⚠️ Atención — perfiles de pago al cobrar con "Pay Invoice". Antes de cobrar, confirmá que el Invoice tiene un Contact asignado. Se comprobó que un Invoice sin Contact puede mostrar perfiles de pago de otros clientes de la misma propiedad. Nunca cobres con un perfil que no sea del cliente que está pagando. Kulturra está evaluando exigir un Contact en todos los Invoices; mientras eso no esté, la verificación es manual.

🔧 Dependencia de Kulturra (prioridad alta): pendiente de respuesta del proveedor.

Payment Portal: Kulturra está construyendo un portal de pagos para el cliente. Hasta que esté disponible, el cliente paga con el link público que recibe por correo.

8. Instalación del servicio y Work Orders

El servicio físico en la Unit se instala o desinstala mediante un Work Order, y ese Work Order mantiene al día una casilla de la Unit.

La Unit tiene una casilla Service Installed que indica si el servicio físico está instalado hoy. No se marca a mano: la actualiza el cierre de un Work Order. Solo cuenta cuando el Work Order pasa a Closed Order; un Work Order en Order Canceled nunca la cambia, porque significa que la orden se descartó, no que se instaló ni desinstaló algo.

🔧 Estado del sistema: implementado, todavía sin UAT formal en las cuatro combinaciones (propiedad Bulk o sin Bulk, instalación o desinstalación). Si dos Work Orders de la misma Unit se cierran exactamente en el mismo momento, el último en procesarse decide el resultado; no se espera en operación normal.

9. Upgrade de Internet

Un Upgrade es cambiar a un plan de Internet de mayor velocidad (el sistema lo sabe por el Service Tier Rank del Service Catalog — ver Apéndice A).

Lo iniciás igual que un servicio nuevo — Add Package, elegís el plan nuevo — y el sistema detecta solo que es un Upgrade y te muestra esta confirmación antes de continuar:

Confirmación de Upgrade — notá que el botón dice "Confirm Replacement" aunque el título diga "Upgrade": es el mismo botón de confirmación que usan los tres tipos de cambio de Internet (Upgrade, Downgrade, Replacement), no es un error de la pantalla.

Qué pasa exactamente:

• El Upgrade puede tomar efecto a mitad de mes — no tenés que esperar al mes siguiente.
• Se cobra la diferencia prorrateada entre el plan viejo y el nuevo, por los días que quedan del mes. Ejemplo real validado: de $49 a $60/mes, con 27 de 31 días restantes, la diferencia a cobrar fue $9.58.
• El servicio anterior sigue activo mientras se paga esa diferencia — el cliente no se queda sin Internet en el medio del cambio.
• El plan nuevo queda en Pending Activation hasta que se pague.
• Una vez pagado: el plan viejo pasa a Inactive (con su End Date real) o Pending Cancellation según corresponda, y el plan nuevo pasa a Active si ya llegó su fecha efectiva.

⚠️ Atención — un cambio de Internet a la vez. Si el Customer ya tiene un Upgrade/Downgrade/Replacement pendiente de pago o activación, el sistema bloquea cualquier otro cambio de Internet hasta que ese se resuelva (se pague/active) o se anule. Vas a ver este mensaje exacto:

"The current Internet package is still Pending Activation. Resolve or void its pending charge before creating another Internet change."

💡 Upgrade con fecha futura (Future Period Upgrade). Si programás un Upgrade para un mes que todavía no empezó, el sistema lo clasifica distinto internamente (como un ajuste de período futuro) para que el cobro no se mezcle con la facturación del mes actual. El comportamiento que ves en pantalla es el mismo; la diferencia es solo en cómo se calcula y factura el cargo.

Si al elegir la fecha de inicio ves este error:

— significa que la fecha que pusiste es anterior o igual a la fecha de inicio del plan actual. El Start Date de un Upgrade siempre tiene que ser posterior al del servicio que estás reemplazando.

10. Downgrade de Internet

Un Downgrade es cambiar a un plan de Internet de menor velocidad. A diferencia del Upgrade, acá no hay ningún cobro inmediato:

Confirmación de Downgrade: el servicio actual sigue hasta fin de mes, sin crédito ni reembolso, y el nuevo empieza el día 1 del mes siguiente.

Qué pasa exactamente:

• El servicio actual sigue activo hasta el último día del mes ya pagado — sin importar qué fecha hayas intentado poner en el formulario, el sistema la ajusta solo al día 1 del mes siguiente.
• No se genera ningún crédito ni reembolso por el cambio a un plan más barato.
• El plan nuevo queda en Pending Activation hasta esa fecha.
• No se crea ningún cargo (Customer_Package_Charge__c) para un Downgrade normal — a diferencia del Upgrade, acá no hay nada que pagar.

Si cancelás un Downgrade ya programado antes de que tome efecto, ver Sección 12 — el servicio anterior se restaura automáticamente a Active.

11. Replacement de Internet (mismo nivel)

Un Replacement es cuando el plan nuevo tiene el mismo Service Tier Rank que el actual (por ejemplo, cambiar de un plan de 1Gb a otro plan distinto que también está configurado como 1Gb). Se comporta igual que un Downgrade: sin cobro inmediato, sin crédito ni reembolso, efectivo el primer día del mes siguiente.

Confirmación de Replacement — mismo patrón que el Downgrade: sin cargo inmediato, efectivo el 1 del mes siguiente.

⚠️ Atención. Si el plan actual o el nuevo no tienen un Service Tier Rank válido configurado, el sistema bloquea el cambio como un problema de configuración (no sabe si es Upgrade, Downgrade o Replacement). Esto refuerza la importancia de configurar bien ese campo al crear el Service Catalog (Apéndice A).

12. Cancelar un servicio en Pending Activation

Esto aplica a un servicio recurrente que todavía no se activó (sigue en Pending Activation) — por ejemplo, te arrepentiste de un Upgrade antes de que se pagara, o el cliente canceló un servicio nuevo antes de que empezara.

Desde el ícono de edición de esa línea, Cancel Pending Activation:

La ventana se ve exactamente igual tenga o no un Invoice de Kulturra generado detrás — el sistema detecta y resuelve la diferencia automáticamente.

El aviso naranja te dice exactamente lo que va a pasar: "This service has not been activated. Pending charges without an Invoice will be voided. If this is a scheduled Downgrade, the previous Internet service will be restored."

Según el caso, el sistema hace lo siguiente solo:

• Sin ningún Invoice generado todavía: el cargo abierto se anula (Voided), el paquete pasa a Inactive sin End Date (porque nunca llegó a estar activo — no se inventa una fecha de fin para un servicio que nunca empezó), y queda registrado quién lo canceló, cuándo y por qué.
• Con un Invoice generado pero sin ningún pago: el sistema anula automáticamente ese Invoice de Kulturra, confirma que quedó anulado, y recién ahí anula el cargo y pasa el paquete a Inactive. No hace falta que entres manualmente al Invoice de Kulturra para anularlo vos mismo — el botón ya lo hace.
• Si el Invoice era agrupado (tenía otros cargos de otros servicios mezclados): esos otros cargos se protegen — vuelven a Pending Billing para poder facturarlos de nuevo, en vez de perderse junto con el cargo cancelado.
• Si ya hay algún pago (total o parcial) sobre ese Invoice: la cancelación se bloquea. En ese caso hace falta una decisión de reembolso/reversión financiera — ver Apéndice C.
• Si era un Downgrade o Replacement programado: cancelarlo restaura automáticamente el servicio anterior a Active, sin End Date (como si el cambio nunca se hubiera pedido).

Después de cancelar un Downgrade/Replacement programado, el servicio original vuelve solo a Active.

13. Dar de baja a un Customer

El botón de arriba de la tabla de Customer Packages cambia de nombre según el estado del Customer. Para dar de baja usás Inactivate Customer, y para deshacerla Revert (el botón Activate Customer se explica en la Sección 2).

Inactivate Customer (Customer Active → Pending Inactivation):

El date-picker solo ofrece fines de mes disponibles — no podés poner cualquier fecha.

• Elegís una fecha de fin de mes (el sistema solo te deja elegir entre los fines de mes disponibles — nunca una fecha a mitad de mes) y, opcionalmente, una razón.
• Ningún servicio se corta de inmediato. Todos los servicios recurrentes activos pasan a Pending Cancellation con su fecha de fin en ese fin de mes — siguen facturando y funcionando normalmente hasta esa fecha, sin reembolso por el período ya pagado (mismo principio prepago de siempre).

Resultado inmediato: el Customer pasa a Pending Inactivation, y cada línea recurrente (incluido el Bulk) queda en Pending Cancellation con su fecha de fin.

• El Customer llega a Inactive (final) solo cuando todos esos servicios efectivamente terminan — ahí el sistema crea automáticamente un Case de tipo Cancellation (cola S1 Queue) para que el equipo de campo desconecte el servicio físico.
• Cancelar un solo servicio individual, con el Customer sin pasar por este botón: si un servicio puntual simplemente vence (por ejemplo, se dejó de renovar) pero el Customer nunca pasó por "Inactivate Customer", igual se genera automáticamente un Case de cancelación por cada servicio que termina así — sin importar si al Customer le quedan otros servicios. Si ya no le queda ningún servicio no-Bulk facturando, el sistema además cierra la factura recurrente de Kulturra de ese Customer (y, al quedar sin factura activa, el propio sistema le arma una nueva factura inactiva automáticamente, lista para cuando se le agregue un servicio nuevo — no tenés que crearla vos).

Revert (Pending Inactivation → Active): deshace la baja, siempre que ningún servicio haya llegado ya a su fin real (si alguno ya terminó de verdad, con su End Date puesto, el sistema bloquea el Revert para no reescribir historial — eso es intencional, no un error).

Programar la baja de un solo servicio activo (Schedule Service Cancellation)

Usá esta opción cuando el cliente quiere dejar un servicio puntual que ya está Active (por ejemplo, un Internet o un Entertainment que paga) pero seguir con el resto. Es distinta de las otras dos bajas: Inactivate Customer da de baja todos los servicios del Customer, y Cancel Pending Activation (Sección 12) es para un servicio que nunca llegó a activarse.

Pasos:

1. En la pestaña Services del Customer, buscá en Customer Packages la fila del servicio Active que querés dar de baja y hacé click en el lápiz que está a la derecha de esa fila (al pasar el mouse dice Cancel Service).

El lápiz está en la última columna de la fila del servicio.

2. Se abre la ventana Schedule Service Cancellation. En Cancellation Effective Date (obligatorio) elegí el último día en que el servicio va a seguir activo. El desplegable solo ofrece fines de mes, empezando por el fin del mes en curso; no hay fechas a mitad de mes ni fechas pasadas.

Solo aparecen fines de mes. El servicio sigue funcionando y facturando normalmente hasta la fecha que elijas.

3. En Cancellation Reason escribí el motivo (opcional, texto libre). Queda guardado junto con quién pidió la baja y cuándo.

4. Click en Schedule Cancellation. Aparece el mensaje verde "Service cancellation scheduled successfully." y la tabla se actualiza.

Qué pasa después:

• El servicio pasa a Pending Cancellation y su columna Period muestra la fecha de fin que elegiste. Sigue activo y facturando hasta ese día, y no hay reembolso por el período ya pagado (mismo principio prepago de siempre). La columna Sync queda en Pending hasta que el cambio se refleja en Kulturra.
• Al llegar la fecha de fin, el sistema lo pasa solo a Inactive, cierra cualquier descuento que tuviera y genera el Case de cancelación en la cola S1 Queue para el equipo de campo (ver el último punto de la lista de Inactivate Customer, más arriba).
• No se puede editar ni deshacer desde la pantalla: una vez programada la baja, el lápiz de esa fila queda deshabilitado. Si te equivocaste de fecha o el cliente se arrepintió, avisale a Sistemas antes de que llegue la fecha de fin.

💡 Tip — este procedimiento solo aplica a servicios recurrentes en Active que todavía no tienen fecha de fin. Para un servicio Pending Activation usá la Sección 12; para un servicio One-Time sin pagar, el ícono de la fila es una X en lugar de un lápiz.

14. Suspensión por no pago

Un Customer llega a Suspended cuando una factura vence sin pagarse. Este estado lo escribe únicamente la integración con Kulturra, nunca un agente: el botón de Customer Status ni siquiera lo ofrece.

Qué hace el sistema, paso a paso:

1. Al suspenderse el Customer (lo hacen los procesos de Kulturra): su facturación recurrente de Kulturra se desactiva. Cada servicio no-Bulk pasa a Suspended con su End Date, y se crea un Case de Suspension para que el equipo técnico haga la parte de red. Los servicios Bulk no se suspenden: los paga la propiedad.
2. Si paga el monto vencido: Kulturra reactiva su facturación y devuelve al Customer a Active. Entonces cada servicio Suspended vuelve a Active (el mismo registro, con la End Date borrada, porque el servicio nunca terminó de verdad) y se crea un Case de Suspension para que el equipo técnico restablezca el servicio.
3. Si pasa más de un mes sin pagar: el sistema hace un cierre completo de la cuenta: todos los servicios no-Bulk quedan Inactive (con End Date = el día del cierre), y se anulan todas las facturas abiertas sin ningún pago. Un servicio que nunca llegó a activarse y estaba atado a una de esas facturas también pasa a Inactive. Qué pasa con el Customer depende de la propiedad: - Propiedad sin servicio Bulk: el Customer queda Inactive y pierde su factura recurrente; si vuelve, se le crean registros nuevos. - Propiedad con servicio Bulk: el Customer vuelve a Active (sigue teniendo el Bulk que paga la propiedad), sin servicios individuales.

⚠️ Atención. Cualquier pago, aunque sea parcial, hoy puede reactivar la facturación recurrente del lado de Kulturra. Kulturra confirmó que agregará un filtro para que solo el pago completo reactive; hasta entonces, tené cuidado con los pagos parciales a un Customer suspendido.

🔧 Estado del sistema. Cierre completo tras un mes sin pagar: implementado y probado. Suspensión de servicios individuales y reactivación al pagar: implementados, todavía sin validar de punta a punta (la prueba de Suspensión del UAT los cubre). Cómo reacciona Kulturra al pago: depende de Kulturra y se confirma en esa misma prueba.

15. Troubleshooting — mensajes y situaciones comunes

Apéndice A. Configurar el pricing de una propiedad nueva

Antes de poder ofrecerle un servicio a un Customer de una propiedad nueva, alguien de Celerity tiene que configurar la cadena completa, en este orden:

1. Service Catalog — el servicio en sí (si no existe todavía). Define el nombre, si es recurrente o One-Time, el tipo de servicio, si es taxable, y — crítico para Internet — el Service Tier Rank.

2. Property Price Book Line — el precio de ese servicio para esa propiedad específica (el mismo servicio puede costar distinto en cada propiedad).

Cada propiedad tiene su propio Price Book, con sus líneas de precio y sus descuentos habilitados.

3. Service Discount (si no existe el descuento que necesitás) — el descuento en sí, su tipo y monto.
4. Service Discount Scope — activa ese descuento específicamente para esa propiedad, con su duración en meses.

⚠️ Atención. El campo Service Tier Rank del Service Catalog no aparece como obligatorio en el formulario, pero en la práctica lo es para cualquier servicio de Internet: si se deja vacío o mal puesto, el sistema no va a poder clasificar bien un Upgrade/Downgrade/Replacement de ese servicio más adelante, y el problema no se nota hasta que alguien intenta hacer ese cambio.

Apéndice B. Glosario de estados

Customer (Status__c)

Customer Package Line (Status__c)

Sync (Sync_Status__c)

Apéndice C. Qué requiere a Finance o a Kulturra

Hay situaciones que un agente no puede resolver solo desde esta pantalla porque involucran dinero ya cobrado o la plataforma de pagos de Kulturra:

• Cancelar un servicio que ya tiene algún pago (total o parcial) — el sistema bloquea la cancelación automática; hace falta una decisión de reembolso/reversión de Finance.
• El pago en sí (procesar una tarjeta, un link de pago, un reintento de cobro) — siempre pasa por Kulturra, nunca por un campo editable en Salesforce.
• Corregir el saldo o los totales de una Recurring Invoice de Kulturra — esos campos financieros son manejados internamente por el paquete de Kulturra; no se deben editar a mano desde Salesforce.
• Perfiles de pago de otro cliente en un Invoice sin Contact — si ves perfiles de pago que no son del cliente, no cobres; escalalo a Kulturra (ver Sección 7).
• Disputas o reembolsos de un pago ya procesado — decisión de Finance, ejecución en Kulturra.

Apéndice D. Limitaciones y pendientes conocidos

Para que sepas qué esperar hoy, sin sorpresas — esto se actualiza a medida que el proyecto avanza:

• Suspensión por no pago — pendiente de validar de punta a punta. El cierre completo tras un mes sin pagar está implementado y probado. La suspensión de los servicios individuales y su reactivación al pagar están implementadas pero todavía no se validaron de punta a punta; la forma en que Kulturra reactiva al Customer cuando paga se confirma en esa misma validación. Si ves un caso real de Suspensión antes de eso, avisá al equipo técnico.
• Un Invoice anulado sin pago ya no vuelve a Pending Billing. La regla cambió el 1 de octubre de 2026: el cargo queda Voided y el servicio que no se había activado queda Inactive (ver Sección 7). Está implementada, pero falta repetir la prueba en vivo.
• Un Customer que solo tiene servicios Bulk de $0 y ninguna suscripción individual pagada no se puede dar de baja con el botón Inactivate Customer. El botón necesita una facturación recurrente activa. Es un caso límite conocido y sin resolver.
• Un Customer Suspended que además pide su baja (Pending Inactivation) es un caso que todavía no tiene una regla diseñada. Escalalo.
• Un Invoice generado manualmente (no por el ciclo normal) que vence sin pagarse todavía no tiene un aviso/corte automático propio — a diferencia de la Suspensión por no pago del ciclo recurrente normal. Si ves un caso así, escalalo.
• Un pago parcial deja activa la Recurring Invoice de Kulturra, aunque el servicio del cliente se quede correctamente sin activar — comportamiento confirmado del lado de Kulturra, no de Salesforce (ver Sección 7). Kulturra confirmó que agregará un filtro para que solo el pago completo reactive; falta su aviso de despliegue.
• Perfiles de pago de otros clientes en un Invoice sin Contact: dependencia de Kulturra, prioridad alta, sin fecha de entrega (ver Sección 7).
• Payment Portal: en construcción por Kulturra. Hasta que esté listo, el cliente paga con el link público del correo.

Este manual refleja el estado del sistema confirmado al 5 de octubre de 2026. Si algo que ves en pantalla no coincide con lo descrito acá, avisá para actualizarlo — preferimos corregir el manual a que quede desactualizado.