- Cobranças fantastams devem ter #código ?
- caso tenham um código elas vão gastar um incremento da sequencia. A medida que as cobranças repetidas forem sendo criadas, cada uma terá seu próprio código.
- ou seja, teremos "fantasmas" com códigos identicos e ainda gastaremos uma sequencia da cobrança. Este fluxo fica bom ou ruim?
- Uma cobrança que deixou de ser um fantasma e foi persistida deve ter opção de repetir em seu formulário?
- Caso sim, quando usuário modificar esta repetição o sistema deve refletir a repetição somente nos seus irmãos?
- ou deve-se criar uma segunda sequencia de repetição a partir desta cobrança?
- ou alguma outra idéia
- Ao cancelar uma cobrança fantasma sistema vai perguntar:
- Cobranças fantastams devem ter #código ?
- caso tenham um código elas vão gastar um incremento da sequencia. A medida que as cobranças repetidas forem sendo criadas, cada uma terá seu próprio código.
- ou seja, teremos "fantasmas" com códigos identicos e ainda gastaremos uma sequencia da cobrança. Este fluxo fica bom ou ruim?
- Imagine uma cobrança que era um fantasma, e foi persistida para ser cobrada. Ela deve ter opção de repetir em seu formulário?
- Caso sim, qual das opções seria correta
- quando usuário modificar a repetição o sistema deve refletir a repetição somente nos seus irmãos?
- ou o sistema deve criar uma segunda sequencia de repetição a partir desta cobrança?
- Caso sim, qual das opções seria correta
- ou alguma outra idéia
O código nas cobranças fantasmas, só é viavel caso não cause muito trabalho para implementar, pois tem função de busca. Ficou definido que vai ter código!
Agir como o Google Agenda: Que quando usuário modifica a repetição o sistema deve refletir a repetição somente nos seus irmãos, dali pra frente.
https://github.com/denoww/seucondominio/commit/41b1f94cfad3a29e1d0ca4af91dff75cd683de6a
79 additions and 115 deletions.
Ficou um pouco mais organizado e com 36 linhas de código a menos
Observação: Mesmo que tenha ficado bugs eles serão corrigidos em cima de um padrão sustentável
Cobranca.do_cliente(1).simular_repeticoes
O chamado acima irá buscar todas cobranças do cliente 1 e quando chamar simular repetições , o postgres irá simular cobranças de TODOS OS CLIENTES. Portanto Teremos um problema muito sério de performance em um futuro muito próximo
http://redmine.seucondominio.com.br/issues/4695
Inicialmente Grooming somente do registro de boletos (boleto ficar verde)
Analisar Protótipo e Github Diego F.
[ | |
{ | |
titulo: 'Receitas', codigo: '1', tipo: 3, | |
lista: [ | |
{ titulo: 'Cotas condominiais', codigo: '1.1', tipo: 3, lista: [ | |
{ titulo: 'Taxas de Condomínio', codigo: '1.1.1', plano_conta_automatico: { cobrancas: :debitos }, tipo: 3, lista: [] }, | |
{ titulo: 'Taxas de utilização de Área comum', codigo: '1.1.2', tipo: 3, lista: [] }, | |
] }, | |
{ titulo: 'Juros e Multas', codigo: '1.2', tipo: 3, lista: [ |
- Morador será notificado, mas caso a visita seja no condomínio invés de residência vai notificar as pessoas que tem a Role "visitantes_autorizados_notificar"
- Existe um tooltip no formulário explicando isso
- Usuário Cria nova importação
- Utilizando a busca ele encontra várias leituras (no meio delas pode ter importadas e não importadas)
- As 'importadas' terão um cadeado no checkbox
- Usuário vai marcando o checkbox das não importadas (ou ele pode também clicar em 'marcar todas')
- O sistema vai guardando os ids sempre que usuário marca um checkbox (mesmo quando usuário vai trocando de página)
- Se usuário volta pra página anterior o checkbox vem marcado
- Assim que tiver tudo marcado o usuário clica em importar
- O sistema pergunta