### Escrever backlog da alteração de status da tabela de preço
> Toda AR, Projeto e Unidade, deve ter sempre uma tabela ativa.
> Após uma tabela de preço ser cadastrada para cada um desses escopos, não deve ser possível mais ter uma tabela inativa.

Regras:
- Ao cadastrar a primeira tabela de preço de alguém, ela deve estar ativa como padrão
- Ao cadastrar outras tabelas de preço, elas devem estar inativas.
- Ao alterar o status de uma tabela de preço deve ser validado se:
	- Existe outra tabela de preço ativa.
		- Se sim, inativar esta.
		- Se não, ignorar.
	- Alterar status da tabela de preço de interesse para ativa.

endpoint: PATCH /prices/{id-da-tabela-de-preco}/activate
payload: (sem payload)
resposta: status 200 em caso de sucesso
validações:
	- se for uma tabela de preço de AR (arId preenchido, projectId null e unityId null):
		- perfil do usuário logado precisa ser de AR (ou seja, o perfil deve ter a chave arId preenchida)
	- se for uma tabela de preço de Projeto ou de Unidade (arId preenchido, projectId preenchido)
		- perfil do usuário logado precisa ser de Projeto (projectId preenchido)

### Escrever backlog de quais usuários do CCA podem ver quais unidades

endpoints:
1. GET /cca/{ccaId}/unities?page=1&pageSize=10&status="ATIVO"
	- retornar lista de unidades que o cca pode ver
	- exemplo de resposta:
		- {totalElements: 100, data: [{id: 0, name: "Nome da unidade", projeto: {id: 1, name: "Construtora MRV"}, address: { state: "MG", city: "Uberlândia"}}]}
2. POST /user/{userId}/unities
	- cadastrar quais unidades o usuário pode ver (será usado no futuro para limitar quais unidades o funcionário do caa pode ver na hora de criar o pedido)
	- exemplo de body:
		- { ccaId: 1, unitiesIds: [1, 2, 3, 4]}


### Escrever backlog de integração de certificados

- Criar um endpoint para integrar os pedidos da serpro com um período de início e fim
	- POST /serpro/integrate
		- body: {dateStart: "dd/mm/yyyy", dateEnd: "dd/mm/yyyy"} (validar se o período não é maior que 31 dias)

Como funciona a integração com o serpro:
1. Primeiro deve-se usar o período para buscar os pedidos APROVADOS: POST {{ _.baseUrl }}/v1/pedidos-de-certificado/aprovados/ar (endpoint do serpro)
2. Depois deve-se usar o endpoint de pedidos EMITIDOS: POST {{ _.baseUrl }}/certificados/emitidos/ar

O fluxo é baseado em sincronizar as informações da serpro com as informações de nossa base.
A integração será feita sempre através do protocolo, e para sincronizar as pessoas físicas e jurídicas será identificado através do tipo do certificado e do documento (CPF ou CNPJ)
Caso o protocolo recuperado no endpoint da serpro não existir em nossa base de dados, o pedido e a emissão devem ser criadas com a origem ("Integração")
Caso o protocolo exista em nossa base, deve ser realizada uma atualização das informações da base, com objetivo de deixar as bases sincronizadas.
É necessário verificar como os campos da serpro se relacionam com a nossa base de dados
	- Se algum campo estiver como obrigatório na nossa base e não ser retornado pela serpro, deve ser avaliado se pode ser preenchido com um valor padrão como "Indefinido" ou deixar a coluna da base como not null.