Cada plano recorrente no Zenamu mantém um registo interno completo de todos os eventos importantes: desde o momento em que é criado, passando por cada renovação, pausa e cancelamento, até a quaisquer reembolsos. Este registo é o seu histórico completo e a sua rede de segurança para resolver disputas e tratar da contabilidade. Este artigo explica onde encontrar a atividade de um plano e como ler cada tipo de evento.

Onde encontrar a atividade de um plano

Abra o detalhe do plano de um cliente na administração e vai ver:

O estado atual do plano (ativo, pausado, a aguardar pagamento, cancelado e por aí fora), a data da próxima renovação e — se algo falhou — detalhes sobre o período de carência e o pagamento falhado.
A secção Pedidos: uma lista dos documentos emitidos para este plano (data de criação, data de pagamento, estado do pagamento, valor, descrição e uma ligação para o detalhe do documento). Esta é a sua principal fonte de informação sobre os pagamentos bem-sucedidos individuais, e serve também de base para a sua contabilidade.

No seu perfil (em Os meus planos → detalhe), o cliente vê o mesmo estado e a mesma lista de pedidos.

Importante: O Zenamu ainda não tem um ecrã dedicado de «Histórico de renovações» que detalhe eventos individuais como pausas, alterações de variante ou correções. Esses eventos ficam guardados num registo interno na base de dados e refletidos no seu Stripe Dashboard (em Subscriptions, Invoices e Events). Na aplicação, tem três locais com que trabalhar diretamente: o estado atual do plano, a lista de documentos (Pedidos) e a atividade do cliente, onde os principais eventos são descritos em linguagem clara (renovado, pagamento falhado, pausado ou pausado automaticamente, retomado, cancelado pelo cliente, cancelado do lado do Stripe ou no fim do período). Para a sequência detalhada de cada evento individual, procure no Stripe. Abaixo descrevemos os tipos de eventos que o sistema regista, para que façam sentido quando os for procurar.

Os tipos de eventos que o sistema regista

Cada evento interno tem um tipo, uma data e, muitas vezes, alguns detalhes adicionais (um valor, uma razão, o ID do registo relacionado no Stripe).

Plano criado (primeira compra)

A primeira compra bem-sucedida de um plano aparece como a criação do plano (estado ativo, ou brevemente a aguardar pagamento) e como o primeiro documento na secção Pedidos. A partir dele, pode ver a data, a variante que o cliente escolheu e o primeiro valor cobrado.

Renovação bem-sucedida

O sistema regista cada cobrança recorrente bem-sucedida. Uma renovação inclui:

A data e a hora da renovação.
O valor cobrado.
O período de faturação que o pagamento cobre (pode segui-lo na fatura no Stripe).
O documento emitido (um recibo ou uma fatura), que vai encontrar na secção Pedidos.

Se o cliente usar um saldo de crédito (que pode vir, por exemplo, de um reembolso anterior emitido como crédito em vez de para o cartão) e este cobrir o pagamento todo do período, a renovação é efetuada na mesma — o Zenamu regista-a internamente e o plano continua — mas não é criado nenhum documento contabilístico para ela. Nada foi cobrado ao cartão, por isso não há nada a documentar. Não vai encontrar um documento para esse período na secção Pedidos nem na exportação para o seu contabilista. O crédito do cliente é reduzido pelo preço do período.

Renovação falhada

O sistema regista cada tentativa do Stripe de cobrar um pagamento que não foi bem-sucedida (as tentativas automáticas do Stripe, uma tentativa manual e por aí fora).

A data e a hora da tentativa.
A razão da falha (o código do banco — fundos insuficientes, recusado, cartão expirado, verificação necessária e por aí fora).

Uma única renovação falhada pode gerar vários registos (o Stripe faz várias tentativas durante o período de carência). O melhor sítio para seguir estas tentativas e os seus códigos é na fatura no seu Stripe Dashboard.

O início do período de carência é um evento interno separado; além disso, a data em que o período de carência termina (normalmente 7 dias após a falha) aparece diretamente na administração, como parte do aviso de pagamento falhado no plano.

Plano pausado

Isto é registado sempre que um plano é pausado. Pode ver que um plano está pausado diretamente pelo seu estado na administração. Há dois casos:

Pausa automática (porque o plano do estúdio foi despromovido). Uma nota explicativa a descrever esta razão é guardada com o registo.
Pausa manual (a partir da administração). Esta é guardada sem nota — não é introduzida nenhuma razão.

A atividade do cliente também distingue se o plano foi pausado (manualmente) ou foi pausado automaticamente. Esta diferença é importante, porque determina se o plano renova automaticamente quando voltar mais tarde ao plano Ultimate (só os planos pausados automaticamente o fazem).

Plano retomado

Isto é registado quando um plano pausado é reiniciado. A razão distingue se foi:

«Retomado automaticamente: o estúdio voltou ao Ultimate» — automaticamente, depois de o estúdio regressar ao plano Ultimate.
Um retomar manual a partir da administração ou do perfil do cliente.

Alteração de variante

Criado quando um cliente é mudado de uma variante para outra. Na atividade do cliente, a aplicação designa este evento como Variante alterada.

A data.
Variante antiga → nova variante.
O tipo de alteração — um aumento de preço, uma redução de preço agendada, uma alteração de intervalo de faturação ou o mesmo preço (a variante foi renomeada, e por aí fora).
Consoante o cenário: para um aumento de preço, aparece uma fatura imediata pela diferença proporcional dos dias restantes (a data da próxima renovação mantém-se); para uma redução de preço agendada, não é criado nenhum documento no dia em que muda — a administração mostra um banner «Alteração agendada a partir de {{data}}» no plano, e a alteração aplica-se apenas na próxima renovação; para uma alteração de intervalo de faturação, o ciclo recomeça e é criada uma única fatura líquida (o novo preço menos um crédito proporcional pela parte não usada do período anterior).

Pode ver quem fez a alteração a partir da atividade do cliente na administração. Distingue se o cliente alterou a variante a partir do perfil ou se o estúdio o fez a partir da administração (nas ações do estúdio, o nome do membro da equipa também é guardado).

Alteração de variante agendada cancelada

Quando um cliente (ou o estúdio em seu nome) cancela uma alteração de variante agendada anteriormente (sempre Cenário B — uma redução de preço), o banner de alteração agendada desaparece da administração e o sistema faz uma nota interna do cancelamento. Não há consequências financeiras; o plano simplesmente reverte para a variante original sem deixar rasto.

Situações raras em torno de uma alteração de variante agendada

Ocasionalmente, um cliente agenda uma redução de preço, mas algo invulgar acontece entre o agendamento e o dia da renovação — por exemplo, o estúdio arquiva a variante de destino entretanto, ou elimina o grupo. O Zenamu trata destas situações automaticamente e faz uma nota interna delas.

O que pode acontecer e o que o Zenamu faz:

O que aconteceu	O que o Zenamu faz
O estúdio arquivou a variante de destino antes da renovação	A alteração não é aplicada. O preço reverte para a variante original, e o cliente continua como se nunca tivesse agendado a redução.
O estúdio eliminou por completo a variante de destino	O mesmo comportamento que arquivar.
O estúdio arquivou ou eliminou todo o grupo	O mesmo comportamento; o cliente fica na variante original.
A reversão do preço não é bem-sucedida do ponto de vista técnico (por exemplo, uma breve falha do Stripe)	O Zenamu faz uma nota da situação. Vai ver um estado de aviso no plano na administração. Neste caso raro, pode verificar o preço atual da subscrição do cliente no seu Stripe Dashboard e ajustá-lo manualmente, se necessário.

Estas situações são muito raras (normalmente menos de 1% das alterações agendadas). Na grande maioria dos casos, a alteração é efetuada exatamente como o cliente pretendeu no dia em que a agendou.

Preço atualizado

O sistema regista quando o estúdio aplicou uma alteração de preço em massa a este cliente. O registo inclui:

A data.
O preço antigo e o novo.
Uma nota de que o novo preço se aplica apenas na próxima renovação regular.

Plano cancelado

Isto é registado em qualquer cancelamento — manual (o cliente a partir do perfil, o estúdio a partir da administração, ou através do portal do cliente Stripe) e automático (pelo Zenamu, depois de o período de carência de 7 dias expirar). Pode ver que um plano está cancelado diretamente pelo seu estado na administração (ou um banner «Cancelamento no final do período» com uma data). Além disso, o registo interno inclui:

A data do cancelamento.
O método de cancelamento: no fim do período atual, ou de imediato.
A razão do cancelamento (por exemplo, um cancelamento manual no fim do período, um cancelamento imediato, ou um cancelamento automático depois de o período de carência expirar). Esta descrição é apenas indicativa: está guardada internamente em inglês e não é o texto exato que veria na aplicação.

Pode ver quem fez o cancelamento. Tanto a partir do registo interno como da atividade do cliente na administração, consegue perceber se foi o cliente, o estúdio ou o sistema a cancelar o plano depois de o período de carência expirar. Para as ações feitas pelo estúdio, o nome do membro da equipa também é guardado. O que o registo não inclui é uma ligação para qualquer reembolso. Vai encontrá-lo no seu Stripe Dashboard, em Refunds.

Confirmação de pagamento necessária e reembolsos — estes aparecem de forma diferente

Confirmação de pagamento necessária (3D Secure) numa renovação é registada como um evento interno, mas o estado do plano mantém-se Ativo. Quando é necessária verificação adicional numa renovação, o Zenamu não o muda para A aguardar pagamento (esse estado está reservado para uma primeira compra por concluir; consulte o artigo «Estados do plano»). O resultado aparece então ou como uma renovação falhada (se o cliente não concluir a verificação e o Stripe parar de tentar) ou como uma renovação bem-sucedida (se a concluir a tempo).

Os reembolsos não são registados como uma atividade separada do plano. Um reembolso total leva a que o plano seja cancelado automaticamente; um reembolso parcial não altera o estado do plano. Vai encontrar o estado do próprio reembolso no documento (a secção Pedidos) ou no seu Stripe Dashboard.

Correção de uma verificação interna (eventos raros)

Este tipo de registo regista uma situação em que uma verificação interna no Zenamu encontrou uma discrepância entre o seu próprio estado e o estado no Stripe e a corrigiu ou anotou para tratar mais tarde. Os tipos específicos são:

Pedido de compra pendente — o cliente comprou, o Stripe confirmou, mas o Zenamu não conseguiu criar o pedido interno. O sistema sinaliza o registo para o recuperar mais tarde.
Pedido de renovação pendente — o mesmo, para uma renovação.
Reembolso pendente após uma sobreposição — o Zenamu cancelou um plano no exato momento em que o Stripe cobrou um pagamento em paralelo. O reembolso automático não aconteceu de imediato, mas fica anotado para ser tratado mais tarde.
Mudança de variante pendente — uma mudança de variante não terminou de forma limpa nalguma fase.
Mensagem para um plano que já não existe — o Stripe enviou uma mensagem sobre um plano que já não existe no Zenamu (o cliente foi eliminado).

Estes são, grosso modo, os cinco mais comuns; o Zenamu usa vários outros marcadores específicos para sobreposições raras (quando duas coisas acontecem no mesmo momento). Estas correções correm em segundo plano; uma correção individual costuma estar bem por si só — o problema é o mesmo marcador a repetir-se no mesmo plano. Se estiver a lidar com uma situação destas, contacte o apoio ao cliente.

Estas correções são informativas e aparecem no sentido em que o estado do plano no Zenamu acaba por corresponder ao Stripe:

Uma correção pontual está bem. Pequenas discrepâncias entre o Stripe e o Zenamu acontecem de vez em quando.
Uma discrepância repetida para o mesmo cliente ou estúdio pode apontar para um problema mais profundo. No seu Stripe Dashboard, verifique se a sua conta está restrita (em Account requirements) e se todas as subscrições recentes deste cliente correspondem ao que vê no Zenamu. Se a discrepância persistir, pode ressincronizar manualmente no Stripe (cancelar e criar uma nova subscrição).

Atualizações de estado em tempo real

Na administração, o estado do plano e a lista de pedidos atualizam-se automaticamente, em tempo real. Isso significa:

Quando o Stripe envia uma mensagem ao Zenamu (um pagamento bem-sucedido, uma falha, um cancelamento), o Zenamu muda o estado do plano em poucos segundos e adiciona qualquer novo documento.
O estúdio vê a alteração sem ter de atualizar a página.

Um cliente, no seu perfil, vê o estado atual apenas depois de atualizar a página. A interface do cliente, regra geral, não usa atualizações em tempo real. Se um cliente contactar o estúdio a perguntar porque não vê um novo pagamento, sugira-lhe que atualize a página. Nalgumas situações (logo a seguir a um pagamento), o navegador do cliente verifica brevemente o estado em segundo plano, mas, como regra: atualizar a página = estado atual.

Na maioria dos casos, ambos os lados veem as alterações em poucos segundos a um minuto do evento real do lado do Stripe.

Como usar a atividade de um plano na prática

A combinação do estado do plano + a lista de pedidos no Zenamu e o seu Stripe Dashboard é útil em várias situações:

Explicar um pagamento específico a um cliente

Quando um cliente escreve «Porque é que fui cobrado 60 € a 14 de abril?», abra a secção Pedidos no plano dele e vai ver:

A data e o estado do pagamento.
O valor.
Uma ligação para o detalhe do documento (o recibo). Pode seguir o período de faturação que o pagamento cobre na fatura no Stripe.

Pode então responder ao cliente com os detalhes exatos.

Perceber porque é que um plano foi cancelado

Consegue perceber que um plano terminou automaticamente após pagamentos falhados a partir do seu estado atual (cancelado / não pago) e da ausência do pagamento bem-sucedido em Pedidos. Para a cronologia das tentativas individuais e a data em que o período de carência terminou (normalmente 7 dias), consulte a subscrição e as faturas respetivas no seu Stripe Dashboard. O cliente fica então a saber que teve um período de carência de 7 dias que não usou.

Reembolsar um cliente por um período não usado

Na lista de pedidos, consegue ver a data do último pagamento bem-sucedido; consegue ver até quando o plano é válido a partir do estado do plano (a data da próxima renovação). Calcule o valor proporcional pelos dias não usados e emita o reembolso no seu Stripe Dashboard.

Rastrear cobranças duplicadas

Se um cliente afirmar que o Stripe o cobrou duas vezes, abra a secção Pedidos (e, por segurança, também as faturas no Stripe). Vai ver apenas um pagamento (e o cliente está enganado) ou dois, caso em que pode reembolsar um deles.

Documentação para a contabilidade

A lista de pedidos corresponde ao seu Stripe Dashboard, um para um. Se o seu contabilista precisar de comprovativo de um pagamento específico, abra o detalhe do documento (e no Stripe vai encontrar a faturação completa, a data de vencimento e os detalhes fiscais).

Perguntas frequentes

Um cliente diz-me que não vê o último pagamento no perfil. Algumas possibilidades:

Um crédito cobriu o pagamento todo (sem movimento de dinheiro = sem documento, ver acima).
O perfil do cliente não atualiza em tempo real — peça-lhe que experimente atualizar a página.
A mensagem do Stripe foi adiada; aguarde um minuto e atualize a página.

Posso exportar a atividade de um plano? Para a contabilidade, use a exportação de documentos padrão na administração (ISDOC ou Pohoda XML). Contém todas as faturas e cancelamentos de que o seu contabilista precisa. Não vai encontrar uma sequência detalhada de eventos individuais (renovações bem-sucedidas e falhadas, pausas, mudanças de variante) como um relatório separado na aplicação; esses dados vivem na base de dados e no seu Stripe Dashboard. Na maioria dos casos, o seu contabilista não precisa deles — trabalha com os documentos.

Posso eliminar um registo de evento? Não. Os registos contabilísticos e históricos não são eliminados nem reescritos a posteriori; apenas são adicionados novos ao lado deles. A razão: o histórico tem de se manter completo, tanto para fins contabilísticos como para a resolução de disputas.

E se eu vir algo que não esperava no Stripe ou no estado do plano (por exemplo, o resultado de uma correção de uma verificação interna)? Pode ser uma situação em que uma verificação interna no Zenamu encontrou uma discrepância entre o seu próprio estado e o estado no Stripe e a corrigiu. Se for pontual, está bem (de vez em quando uma mensagem do Stripe perde-se, e a rede de segurança interna corrige-a). Se a discrepância persistir para o mesmo cliente, verifique o estado da subscrição dele no seu Stripe Dashboard e compare-o com o que vê no Zenamu. Se mesmo não corresponder, contacte o apoio ao cliente, ou ressincronize manualmente no Stripe (cancele e crie uma nova subscrição).

Histórico de renovações e atividade do plano