# Início Esta documentação detalha os fluxos de processos internos que são geridos pelo KAPIM. ### Conceito KAPIM é um ERP (aplicação de gestão de processos empresariais) voltado para pequenas empresas e tem por objetivo facilitar o dia-a-dia de seus usuários nas diversas tarefas relativas à gestão da empresa.\ O ciclo de vida de uma empresa é composto por diversos processos, de vendas à financeiro, controle de estoque, gestão de pessoas e faturamento. KAPIM é um sistema modularizado para ter seus processos distribuídos para o cliente de acordo com sua necessidade mediante o conceito de [DEPARTAMENTO](/acesso/departamento) e [GRUPOS](/acesso/grupos) de usuário. ### Navegação As opções de navegação estão dispostas em um menu lateral em formato de árvore à esquerda (ao clicar sobre um determinado item, ele será *expandido* revelando opções dentro do contexto) e também com opções de atalho na área superior da interface. # Grupos Um grupo é uma perspectiva de restrição de acesso aplicada à todo momento durante o uso do sistema. O grupo define qual o nível de acesso que o usuário terá à um determinado [departamento](/acesso/departamento) , e com isso restringir ou liberar determinadas ações como edição , exclusão ou mesmo o acesso em modo leitura à um determinado conteúdo. Os grupos de acesso são padronizados no sistema e definidos pelo usuário ADMINISTRADOR da empresa através da opção de gerenciamento de usuários. | Grupo | Nível de acesso | Inserir | Editar | Excluir | | ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-----: | :----: | :-----: | | Administrador | Possui acesso total à todos os departamentos que a empresa contratou na empresa e ainda possui acesso á funções de configuração da empresa e gestão de usuários | OK | OK | OK | | Gerente | Possui acesso total aos departamentos liberados | OK | OK | OK | | Usuário | Possui acesso total ao conteúdo gerado pelo próprio usuário | OK | OK | - | | Leitura | Possui acesso restrito acessando o conteúdo somente para visualização | - | - | - | | | | | | | # Departamento Um departamento dentro do modelo de dados do KAPIM representa uma unidade de negócio não hierárquica que tem total liberdade para realizar seus processos sem ter ligação direta (em termos de acesso) com outros departamentos. Por exemplo, um usuário do departamento de estoque pode realizar seus processos sem acessar nenhum processo do departamento de vendas ou departamento financeiro. {% hint style="info" %} **Nota**: estamos aqui documento uma funcionalidade de acesso, obviamente que as ações tomadas podem impactar outros processos e outros departamentos, porém o acesso ocorre de forma totalmente independente entre os departamentos. {% endhint %} # Cadastros O sistema é projetado para ter uma cadeia específica de cadastros, que passam por Clientes, Vendedores, Fornecedores e outros tipos que forem necessários. Cada um destes cadastros desempenha suas funções específicas e são utilizados nos momentos específicos do ciclo de vida da gestão da empresa. Por exemplo um vendedor é utilizado em uma proposta comercial, enquanto que uma transportadora é informada na nota fiscal para remessa de produtos. Se o tipo de cadastro permitir relações, elas serão disponibilizadas na forma de 1 para muitos, ou seja 1 cadastro pode ter N relações à ele. Por exemplo um cliente pode possuir cinco endereços vinculados e três pessoas de contato Os cadastros são disponibilizados mediante solicitação para a desenvolvedora, pois por padrão os cadastros liberados para a empresa já contemplam todos os possíveis padrões de mercado, se há necessidades específicas é preciso contatar a Kmeleon para identificação das necessidades e criação de um novo tipo de cadastro # Usuários Um usuário deve ser incluído no sistema para que seja possível realizar o acesso. O usuário criado será vinculado aos [departamentos](/acesso/departamento) definidos pelo cadatrante, de acordo com o papel do [grupo](/acesso/grupos) definido. Por exemplo, cadastrando um novo usuário será definido que no **departamento financeiro** ele terá o **grupo gerente**. O e-mail do usuário é chave única no sistema, ou seja, não pode haver dois usuários cadastrados com o mesmo e-mail. O login é realizado pelo CPF do usuário, importante que seja informado um CPF válido e também deve ser um valor único no sistema (ou seja, não são permitidos CPF duplicados). # Clientes O cliente é a principal conta de cadastro dentro do sistema. ### Tipos de cliente Através de um cliente várias ligações de processos são realizadas, um cliente representa um relacionamento comercial com ou sem histórico comercial (um cliente pode somente estar cadastrado e não ter comprado nada em sua empresa por exemplo). Desta forma há segregações para determinar clientes efetivos (que compram com frequência) e clientes potenciais (aqueles com potencial para prospecção e negócios). ### Conexões de um cliente Um cliente pode gerar diversos artefatos vinculados à ele dentro do sistema, como contatos (funcionários que trabalham na empresa e que respondem por áreas diversas dentro do organograma da empresa, como vendas, engenharia, estoque, financeiro, etc...) Além das conexões geradas pela própria empresa (como seus funcionários), existem as conexões internas de sua empresa com seu cliente (por exemplo qual o vendedor que atende a empresa). # Proposta O começo de todo o fluxo comercial é a proposta. A partir de uma proposta, que contém diversas informações, um vendedor realizará o cadastro de uma intenção de compra por parte de um [cliente](/vendas/clientes) e se aprovada a proposta enviada, ela se tornará um pedido dentro do sistema. Por sua vez, um pedido ao ser aprovado, emitirá um documento fiscal (ou seja, irá gerar uma nota-fiscal) com base no pedido. Lembrando que no caso de cancelamento do fluxo em etapas posteriores à proposta, **não implicam** em alterações da proposta criada. # Pedido O segundo passo em um fluxo comercia de venda, após uma proposta ter sido submetida para aprovação do cliente **e ter sido aprovada**, um pedido será gerado. Neste momento o estoque será movimentado e o pedido realizará a reserva de produtos disponíveis no estoque de acordo com o local de armazenamento definido. Um pedido é criado sempre com status pendente, para que a equipe de estoque realize a próxima etapa (conferência do estoque passando o pedido para **conferido**). Após a conferência, o pedido gera uma nota-fiscal e será migrado para faturado (e aqui encerra-se seu ciclo de vida), pois a próxima etapa é a emissão de uma nota-fiscal para o cliente final. # Remessa Um processo de remessa consiste em enviar um produto para um cliente / fornecedor sem que necessariamente haja uma transação financeira envolvida. Por exemplo, o envio de um produto para teste é uma transação de remessa onde não haverá movimentação financeira, o cliente / fornecedor que recebe o produto está avaliando o produto para fins de compatibilidade/desempenho ou outros fatores. O ciclo de vida de um processo de remessa segue obrigatoriamente os mesmos passos de um pedido de venda, ou seja : Pendente -> Aprovado -> Conferido -> Faturado Com isso, o objeto final do processo de remessa é uma nota-fiscal de simples remessa para o cliente (ou de devolução quando é o caso). # Nota-Fiscal O sistema é voltado para a emissão de notas fiscais de **comercialização de produtos** e não realiza a emissão de notas fiscais de prestação de serviços. Todo o conjunto de parâmetros relativos à nota fiscal estão devidamente distribuidos no sistema (alíquotas, regras fiscais e enquadramentos). Porém é importante ressaltar que a parametrização deve ser feita acompanhada por um contador experiente que faça a devida parametrização das situações de cada produto ou contexto de nota. Uma nota fiscal pode ser emitida de três formas: 1\) Com base em um pedido de vendas 2\) Com base em um processo de remessa (testes/garantia/devolução) 3\) Totalmente manual por conta de processos de devolução e caberá ao usuário realizar o enquadramento de CFOP e todo o restante. # Nota por pedido As notas ficais originadas a partir de pedidos realizados no sistema são consideradas notas automáticas. Elas tem como base , todos os dados do cliente e do pedido de vendas, sendo uma junção entre estes dois eventos. Uma nota fiscal por pedido é emitida quando o pedido é passado para o status faturado e será enquadrada de acordo com um conjunto complexo de regras fiscais. É importante observar que uma nota-fiscal é sempre validada pela SEFAZ (Secretária da Fazenda) em âmbito nacional e posteriormente por estado (com regras específicas). O não processamento de uma nota-fiscal está diretamente atrelado ao seu conteúdo, e cabe ao usuário revisar os dados, e garantir a qualidade da informação. **Por exemplo:** CEP inválido Código IBGE inválido Caracteres inválidos em campos de texto Cadastro correto dos produtos Aplicação correta das alíquotas # Nota manual As notas manuais são usadas para diversas finalidades (que não se originam necessariamente de um processo de venda / pedido). Uma nota manual tem seu conteúdo 100% informado pelo usuário, uma vez que não há insumos para a geração de conteúdo, cabe ao usuário garantir o correto preenchimento de todos os dados. # Links Úteis O processo de emissão da nota fiscal é extremamente complexo por depender em sua grande parte de parâmetros e conteúdos externos, não relacionados ao processo de venda em sí. Por isso é importante obter conteúdo confiável com base em parâmetros simples (como o CNPJ ou CPF do destinatário de uma nota fiscal). Para obter a **inscrição estadual** registrada na SEFAZ para um CNPJ: