Central de Ajuda Quaza Provedores

o Projeto de las API's em cSharp segue a arquitetura mais mordena de criacción de API's, donde

Para o inicio del desenvolvimento de las nossas API's com cSharp, temos que ter alguns conhecimentos previos, o dominio de la linguagem cSharp en el es essencial, pois poderá entender en el decorrer del desenvolvimento, mas um certo entimento del docker, donde ficará o banco para el desenvolvimento, pelo menos subir um postgres 15 com bind de portas e guardar o storage, para cuando o dokcer reiniciar nao perder o banco salvo.

o Projeto de las API's em cSharp segue a arquitetura mais mordena de criacción de API's, donde separaremos o maximo possivel de la regra de negocio e suas responsabilidades.

Atualmente estamos organizando em 3 grandes SOLUTIONS FOLDERS, son pastas que en el son criadas fisicamente, somente em exibição, serve para elrganizar dentro de la IDE.

As SOLUTIONS FOLDERS son as Core, CrossCutting e Projects

Core

Dentro de la core, irão ficar basicamente as BASES, exemplo Entity, que cada um de las nossas entitdades irão extender. O RequestResponse, Command, Query, cada um desses son bases para els seus respectivos, o Core es referente as bases que todos os outros projetos vão usar, nele inclusive, ficam os pacostes NuGet's, resposavel pelos controllers e domain

Architecture

Ficara os respectivos bases de la aplicacción ou os bases e pacotes NuGet's referente as Aplicações, o responsavel pelas regras de la aplicacción, o sistema backend em si

Infrastructure

Ficara os bases e pacotes NuGet's referente a camada de infrastructure, que antigamente era chamada de DAO, a camada doi banco de dados

CrossCutting

O cross cutting, tambem chamado de "responsabilidades transversais" son serviçoes comuns fornecidos por uma camada ou serviço específico usado por todas as camadas de uma aplicacción. Seria como uma camada/serviço que cruza toda a hierarquia. Ali dentro teremos separado entre os BASES, as policies, o controle de mensageria, e as coisas que tanto o Serviços externos e serviços internos vão usar

Os serviços externos serão as API's que usaremos de terceiros, exemplo, PlugNotas, Sicredi, Sicoob, DryTelecom....

Os Serviços internos serão os que usaremos internamente, RabbitMQ, Redis...

Projects serão so nossos Projetos propriamente ditos, Hoje temos 2, APEX e ATLAS

Apex es o projeto que gerenciara o que hoje chamamos de backuper, ele contera nossos clientes, quem tem permiso, versões de las aplicações deles, e tudo mais, inclusive logins, inclusive tera login tanto de usuarios, que serão usuarios del tipo ADMIN, que vão poder inativar clientes e tudo mais e usuario del tipo CONSUMERS que es nossos clientes, eles vao ter acesso a consumir as API's que estamos criando

Atlas es a API que cuidará de tudo referente a GEOGRAFIA, Paises, Estados, Cidades, Provincias, Codigo de Telefone e tudo mais.

dentro de cada projeto teremos as separações, de API que es basicamente o controller que cuidará de las rotas.

Aplication será o resposavel que tera os Commands, Queries e Handlers, as traduções e seus services de regra de nogocios

Domain será o resposavel aos Models del projeto/sistema, es como sera salvo en el banco de dados e seus vinculos

Infrastructure fica os context, os mappings repositories, seeds, tudo relacionado a guardar ou buscar del banco de dados.

Com isso voce terá um entendimento mais amplo del que estamos tentando trabalhar

Então como estamos construindo ou como isso tudo ta funcionando, atualmente, a API.[projeto] servira basicamente um controller de rota, tem uma rota aberta, que ira receber em POST, GET, PATCH ou DELETE e ira receber um determinado DTO (Data Transfer Object), e via MediatoR ele ira enviar pro cara certo, tudo que irá modificar en el banco sera um COMMAND (inserção), PATCH (alteracción) ou DELETE (remoção), ou um QUERY, uma busca en el banco de dados.

a função en el controller é, receber um DTO em json e converter em objeto, e lançar para la aplication via MediatoR, verificar e retornar de acordo com o que foi processado

No Handler, tanto de QUERY quanto del COMMAND, terá tanto o DTO de recepción quanto de la resposta, o Handler recebera es seguira o que necesita fazer, basicamente irá chamar um grupo de services que ira manipular os dados para processamento, se necesitar buscar dados del banco usará os repositories, para en el precisarmos escrever a mesma consulta mais de uma vez, os services son para en el escrever os mesmos processos mais de uma vez.

O Handler serve basicamente para criar um passo a passo de processamento que ele ira hacer cuando receber uma chamada de uma determinada rota.

Desenvolvimento

os Commands criados, sempre serão selados (class sealed), nada puede extender eles

as Queries criadas, sempre serão registros (class record), en el sofrerão mudanças del que veio via requisição

Toda a vez que criar um Service, Handler, Query, Command... devido a injeção de dependencia, teremos que  registrar e añadir en el escopo

Criei ja pipeline que compila em produção a imagem de la versão e publica en el nosso registry, en el estamos usando um serviço como o DOCKER HUB.

Glosario

Trampas frecuentes

FAQ

Quem puede acceder essa funcionalidade?

Depende de la permiso del usuário. Confira com o administrador del Quaza se usted en el vê a opção.

O que hacer se aparecer um erro?

Anote a mensaje completa, screenshot, e abra um chamado en el soporte del Quaza com esses dados.

Esta funcionalidade tem versão para cliente final?

Algumas funcionalidades têm Portal del Cliente. Verifique en el módulo Portal .

Posso integrar via API?

Sim — a maioria de las funcionalidades del Quaza expõe endpoints REST. Consulte a documentacción técnica.

Quaza tem treinamento oficial?

Sim — equipe de soporte oferece sessões de onboarding sob agendamento.

Ciclo completo de la operacción

Boas práticas operacionais

Para tirar o máximo desta funcionalidade, observe os pontos abaixo. São práticas que proveedores experientes adotam para evitar erros recorrentes e maximizar valor extraído del Quaza.

Antes de operar

• Confirme permiso de acesso: nem todo operador tem permiso para todas as funcionalidades. Verifique com o administrador del Quaza se algo en el aparece como esperado. Permissões son vinculadas a papéis (operador, supervisor, admin).
• Cadastros pré-requisitos completos: muitas funcionalidades dependem de outros cadastros estarem completos antes. Por exemplo, antes de criar um contrato usted necesita ter o cliente cadastrado, plano de ventas configurado, e regras de cobranza definidas.
• Treine pelo menos 2 operadores: redundância previne paralisacción por ausência. Funcionário puede sair, ficar doente, ter dia ruim. Mantenha conhecimento distribuído entre múltiplas pessoas.
• Documente procedimentos internos: crie checklist próprio para elperações recorrentes. Quem opera amanhã agradece — especialmente se for funcionário novo.

Durante a operacción

• Documente decisões en el óbvias: se usted ajustou algo de forma diferente del default, anote o porquê. Próximo operador agradece e evita refazer análise.
• Operaciones em massa pedem cuidado: antes de aplicar a 100+ registros, teste com 5 e revise resultado completo. Se possível, exporte CSV antes para ter como rollback.
• Backup antes de mudanças grandes: cancelar/desfazer puede en el ser possível em todas as ações. Em dúvida, faça export ou imprima pantalla antes.
• Comunique alterações: mudanças que impactam outras equipes (atención, financeiro) devem ser anunciadas com antecedência. Surpresa gera retrabalho.

Acompanhamento e revisão

• Revisão semanal de 30 minutos: dedique tempo regular para revisar o que rodou, falhou, ficou pendente neste módulo. Anomalia detectada cedo custa 10x menos que descoberta tarde.
• Defina KPIs próprios: 2-3 indicadores que medem saúde de la operacción. Acompanhe tendências, en el só valores absolutos. Variacción maior que 20% merece investigacción.
• Auditoría mensal: revise sample de operações del mês passado. Use logs para confirmar que tudo aconteceu como esperado, sem desvios silenciosos.
• Compare com período anterior: "Vendi R$ 100k" — es bom? Compare com mês anterior, mesmo mês ano passado. Contexto importa mais que número absoluto.

Resolução de problemas

• Anote a mensaje de erro completa: copie o texto exato. Captura de pantalla ajuda. Anote quais passos levaram ao problema — facilita diagnóstico.
• Tente reproduzir em ambiente de teste: se possível, simule o erro com dado dummy antes de pedir soporte. Isso acelera resolução.
• Procure en el histórico: provavelmente alguém já viu erro similar. Veja log de auditoria para entender o que mudou recentemente.
• Abra chamado bem documentado: equipe de soporte del Quaza resolve mais rápido com contexto: o que esperava, o que aconteceu, frequência, screenshots.

Indicadores típicos a acompanhar

Cada proveedor define seus próprios indicadores, mas alguns son quase universais para qualquer operacción en el Quaza:

• Volume mensal processado (registros/transações/eventos)
• Taxa de erro (% de operações que falharam)
• Tempo médio de processamento
• Cobertura (% de la carteira atendida pela funcionalidade)
• Satisfacción operacional (feedback de la equipe que usa)

Compare valores atuais com média de los últimos 3 meses. Variacción maior que 20% em qualquer direção merece investigacción — puede ser melhoria sustentável ou degradacción silenciosa.

Recursos relacionados en el Quaza

Este recurso se conecta com outros módulos del sistema. Conhecer essas conexões ajuda en el troubleshooting e em decisões operacionais:

• Cadastro de cliente — base de tudo en el Quaza. Cliente bem cadastrado evita problemas downstream.
• Plano de Cuentas — donde o impacto financeiro es classificado cuentabilmente.
• Logs de auditoria — histórico de quem fez o quê e cuando, essencial para diagnóstico.
• Permissões e papéis — definem quem puede operar o quê.
• Tareas crontab — automações que tocam neste recurso periodicamente.

Referência rápida

Atalhos e shortcuts para elperacción eficiente:

• Busca avançada: use filtros de data, status, responsável para reduzir lista. Filtro padrão puede escdonder registros antigos.
• Exportacción: a maioria de las listas exporta para CSV/Excel. Útil para lanálise externa ou backup pré-mudança.
• Histórico: cada registro tem timeline de modificações. Acceda via botón "Histórico" ou aba lateral.
• Atalhos de teclado: Ctrl+F (busca), Ctrl+S (guardar), Esc (cancelar) en la maioria de las pantallas.
• Permiso restrita: se botón estiver cinza, es falta de permiso — en el bug.