demanda.py

Contexto

O objetivo desse dessa implementação é criar endpoints para gerenciar serviços que podem ser prestados dentro da plataforma.

Objetivo

Para isso, vamos criar um novo django app tanto na camada de APIs como na camada de backoffice. (São projetos diferentes).

Dentro do Django app, vamos criar o client_services. A tabela deve funcionar como uma grande 
vitrine de serviços disponíveis para compra do usuário paciente. 

Arquétipo de estrutura da tabela

São obrigatórios apenas os param com *
todo client_service precisa ter ou um professional_id ou uma company_id, obrigatoriamente. 
um client_service pode ter professional_id e company_id ao mesmo tempo.
um client_service não pode ter ambos professional_id e company_id nulos 

Regras de negócio

Funcionalidades no projeto Django Admin

CRIAÇÃO

1. upload planilha padrão 
Planilha tem como estrutura todos os campos da tabela, menos id 
Em caso de child_service, o param será preenchido na planilha com um numero 1, 
assim a linha deverá ser cadastrada como child_service da linha anterior 
Criar um formato de upload onde seja possível acompanhar o status do processamento
As linhas que derem erro não impedem a continuidade do processamento
Ao concluir o processamento, deve ser gerado um response ou relatório de erro, 
informando as linhas que deram erro e qual a resposta de cada uma delas.

2. Registro manual
A.Todos os campos disponíveis menos id 
B.Os campos professional_id, company_id, establishment_id e agenda_id, tuss, specialty, precisam ser campos de busca e seleção
busca
professional_id (council_number)

company_id (cnpj)
establishment_id (cnpj, nome, zipcode) 
agenda_id (establishment_id ou company_id)
tuss (number, name)
specialty (name)

C.Type, payment method e client_id são um select 
type (presencial, video, exame, vacina)

D.podem ser selecionados N payment_method dentre os disponíveis (credit_card, pix, boleto, debit_card, cash)

LISTAGEM
lista de client_service paginados ações

A- busca por specialty, establishment_id, establishment_uf, establishment_city, tuss 
B- seleção de itens da lista com ações disponíveis a seguir: desativar marketplace
  (faz atualização campo active_marketplace para false), 
  desativar pilar (faz atualização campo active_pilar para false), 
  ativar marketplace (faz atualização campo active_marketplace para true), 
  ativar pilar (faz atualização campo active_pilar para true)

EDIÇÃO

3.edição client service 

A - todos os campos são editaveis, menos id
B - disponibilizar atalho criar child_service (criar novo servico ja vinculadando o id do novo service no 
parametro "child_service" do serviço original 

------------------------------------
Funcionalidades no projeto API

Disponibilizar 1 único Endpoint: Get client_services 
Permissionamento: O endpoint pode receber requisições por qualquer tipo de usuário autenticado
O endpoint deve permitir os seguintes filtros: name, professional_id, company_id, estabelecimento_saude_id, 
agenda_id, specialty_id, client_id
O response deve ser paginado, seguindo os padrões da API V1, exibindo 10 resultados por página 
O response deve retornar apenas os resultados que tiverem o parâmetro active_marketplace = true

Critérios de aceite
Gerar documentação dos endpoints implementados
Gerar evidência de funcionamento para facilitar testes funcionais
Garantir que o code style segue os projetos existentes