• Nenhum resultado encontrado

Anexo 1. Escopo do Projeto de Desenvolvimento do Sistema do ERP

N/A
N/A
Protected

Academic year: 2021

Share "Anexo 1. Escopo do Projeto de Desenvolvimento do Sistema do ERP"

Copied!
10
0
0

Texto

(1)

Anexo 1

Escopo do Projeto de Desenvolvimento do Sistema do

ERP

1

Informações Gerais do Software

1.1

O sistema será desenvolvido totalmente para plataforma WEB, ou seja deve ser possível operar lo em sua totalidade na ultima versão disponível dos navegadores Internet Explorer e Mozilla Firefox.

1.2 O software deve ser desenvolvido para operação de múltiplos usuários simultaneamente.

1.3 A linguagem de programação utilizada deve ser PHP na versão 5.3 ou superior.

1.4 O banco de dados utilizado deve ser o MySQL na versão 5.1 ou superior.

1.5 A tecnologia AJAX ou similar deve ser utilizada em todas as telas do usuário de forma que as informações nas paginas possam ser atualizadas sem que seja necessário fazer o recarregamento completo da pagina.

1.6 O software deve ser capaz de manter histórico de todas os eventos ocorridos. Entende-se por eventos a criação, modificação ou remoção de registros / dados.

1.7 O software deve ser desenvolvido em módulos. Os módulos “pai” que devem existir são: "Cadastro” - “Orçamento” - “Pedido" - “Pedido" - “Financeiro” - “Gerencial” - “Configurações”.

1.8 O acesso ao sistema deve acontecer única e exclusivamente mediante a um usuário e senha previamente definido pelo administrador do sistema, configuração esta feita no módulo de configurações do sistema.

1.9 Deve ser possível restringir ou permitir o acesso a cada parte do sistema ou informação baseando-se no usuário que esta acessando o sistema.

1.10 Todas as formatações de “valor” devem ser no formato da moeda real do Brasil.

1.11 Todas as paginas, consultas, relatórios do sistema devem ser passiveis de impressão de uma forma limpa e organizada.

2 Descrição dos Módulos

2.1

Cadastro

(2)

2.1.1.1

Este submódulo destina-se ao inclusão, consulta ou alteração de clientes no sistema.

2.1.1.2

Selecionado este submódulo o sistema deve exibir todos os campos existentes de cadastro. Com o preenchimento de algum dos campos “Código”, “Nome / Razão Social”, “Nome Fantasia” ou “CNP/ CPF” o sistema já deve procurar em sua base por um semelhante, e encontrando dar opção no estilo “caixa de seleção” para ele poder ser selecionado. Selecionado um registro já existente no sistema as informações deste cliente devem ser carregadas na tela. Caso não seja encontrado nada, o usuário segue inserindo os demais campos como se fosse uma inclusão. Ao final, tanto para o caso de um nova inclusão quanto de uma alteração o sistema deve disponibilizar um botão para “gravar dados”.

2.1.1.3 Cada cadastro de cliente deve ter um código de cliente com seis dígitos, sequencial, ou seja, deve seguir a sequencia do último número inserido no sistema, e este número deve ser único em todo o sistema. 2.1.1.4 Apenas o nome do cliente deve bastar para o sistema incluir um novo

cadastro de cliente no sistema, porem não pode haver duplicidade de CNPJ / CPF caso este seja cadastrado.

2.1.1.5 Os campos de informações cadastrais do cadastro que o sistema deve disponibilizar são: Código, Razão social em caso de empresa ou nome em caso de pessoa física, nome fantasia em caso de empresa, CNPJ ou CPF, endereço e endereço de entrega, a possibilidade de dez números de telefone (podendo especificar o tipo), pessoas de contato, e um campo tipo texto para observações.

2.1.1.6 Alem das informações acima citadas o sistema deve exibir uma caixa de seleção que conterá os diversos “estados” possíveis para um cliente no sistema. Os estados são: Ativo | Inativo | Restrição | Ouro | Prata | Bonze ). Ao criar um novo cadastro de cliente o sistema deve pré-selecionar o estado “Ativo”.

2.1.1.7 O armazenamento do CNPJ e CPF deve seguir o formato existente no Brasil e o digito verificador do número deve ser validado.

2.1.1.8 Ao lado do campo endereço deve conter um caixinha que se selecionada copiará os dados do campo endereço para o campo endereço de entrega.

2.1.1.9 Deve existir uma forma de inserir até dez pessoas de contato para o cliente. As informações deste contato são: Nome, o departamento e a opção de dez números de telefone.

2.1.2 Produtos

2.1.2.1 Este submódulo destina-se ao inclusão, consulta ou alteração de produtos no sistema.

2.1.2.2 Cada produto no sistema deve receber um “código de produto” com seis dígitos, sequencial, ou seja, deve seguir a sequencia do último número inserido no sistema, e este número deve ser único em todo o

(3)

sistema.

2.1.2.3 Os campos de informações do produto que o sistema deve disponibilizar são: Código, nome, descrição, valor e um campo tipo “texto” chamado “observações” onde os usuários do sistema poderão escrever o que desejar.

2.1.2.4 O nome do produto deve aparecer de forma dividida, conforme o exemplo que se segue: Produto → Exemplo: Cadeira | Modelo → Exemplo: Diamante | Verniz → Exemplo: Mogno | Estofamento → Exemplo: Verde liso, e as operações de inclusão, consulta e alteração deve utilizar-se deste esquema.

2.1.2.5 É o “produto” concatenado com o “modelo” que recebe um código de produto no sistema e o valor, e o verniz e o estofamento são apenas variantes que não alteram o valor.

2.1.2.6 Deve ser possível incluir uma novo produto, ou seja, novas entradas nos campos “produtos” e / ou “modelo”, e este deve então receber um “código de produto”. Também deve ser possível cadastrar um novo tipo de “verniz” ou “estofamento” porem sem que se crie um “código de produto”.

2.1.2.7 Este submódulo ao ser selecionado deve exibir as caixas divididas como no esquema citado no item 2.3.1.4 onde o usuário do sistema poderá incluir, consultar ou alterar algum produto.

2.1.2.8 Para as categorias “produto”, “modelo” e verniz exibir uma caixa de seleção e para a categoria “estofamento” fornecer um campo para digitação onde o sistema procurará pelas opções disponíveis a partir da digitação do usuário.

2.2 Orçamento

2.2.1 Este submódulo deve ser capaz de incluir, pesquisar e alterar um orçamento no sistema.

2.2.2 Este módulo deverá conter as seguintes abas: Cadastro | Produtos.

2.2.3 Selecionado este módulo o sistema deve exibir no topo os seguintes campos: Código / Nome / Razão Social | Nome Fantasia |CNP/ CPF. Caso algum deles seja preenchido o sistema já deve procurar em sua base por um semelhante, e encontrando dar opção de selecionar-lo. Caso não seja encontrado nada, o usuário segue inserindo os demais campos como se fosse uma inclusão.

2.2.4 Encontrado um cliente existente o sistema deve exibir todas suas informações cadastrais e permitir sua edição igualmente como é possível no módulo de “cadastro / cliente”. Um botão salvar alterações deve ser disponibilizado também para eventuais alterações. O sistema também deve exibir as abas “orçamento” e “pedidos” assim como é feito no módulo “cadastro / cliente”.

2.2.5 Encontrado e selecionado um orçamento existente este deve ser exibido ao usuário do sistema.

(4)

2.2.6 O sistema deve permitir transformar um orçamento em pedido, onde então todas as informações constantes deste orçamento devem ser aproveitadas para o pedido. O orçamento permanece porem no sistema 2.2.7 A área produtos ao ser clicada deve esconder os detalhes da área cliente

e exibir os detalhes da área de produtos que são os mesmo como no submódulo “cadastro / produto”

2.2.8 O usuário do sistema então poderá selecionar os produtos para o orçamento de forma sub dividida.

2.2.9 Selecionando um produto o sistema deve adicionar lo ao orçamento, exibindo-o logo abaixo da linha de seleção, com a quantidade de uma unidade pré-selecionada Alem da quantidade o sistema deve exibir o preço unitário e o preço total que seria a quantidade multiplicado pelo preço unitário. Ao mudar a quantidade do produto selecionado o sistema deve recalcular automaticamente o total ao lado sem que a tela seja recarregada. (AJAX)

2.2.10

Selecionado todos os itens do orçamento o sistema deve exibir no final a totalização da quantidade e o valor total de todos os produtos selecionados.

2.2.11 Ao final de tudo o sistema deve apresentar um botão “gerar orçamento” onde então o sistema irá gerar um código para o orçamento gravando suas informações e indexando ao cliente selecionado.

2.2.12 Para cada orçamento o sistema deve gerar um código de orçamento com oito dígitos, sequencial, ou seja, deve seguir a sequencia do último número inserido no sistema, e este número deve ser único em todo o sistema.

2.2.13 Se o cliente tiver o estado de “restrição” uma tela deve ser exibida ao usuário dizendo para ele entrar em contato com o departamento financeiro. O usuário ao clicar neste tele deve poder seguir normalmente com a inclusão do orçamento.

2.3 Pedido

2.3.1 O sistema deve disponibilizar uma caixa de seleção para que o “estado” de cada pedido no sistema seja selecionado. Os possíveis estados estão discriminados abaixo.

2.3.1.1 Financeiro → Pedidos criados e que estão aguardando aprovação do financeiro.

2.3.1.2 Produção → Pedidos que foram aprovador pelo financeiro e estão para serem fabricados.

2.3.1.3 Finalizado → O a fabricação do pedido foi finalizada 2.3.1.4 Entregue → O pedido foi entregue ao cliente

(5)

2.3.1.6 Cancelado → O pedido foi cancelado em algum momento

2.3.2 Este módulo deverá conter as seguintes três abas: Cadastro | Produtos | Forma de Pagamento.

2.3.3 Selecionado este módulo o sistema deve exibir no topo os seguintes campos: Código | Nome / Razão Social | Nome Fantasia | CNP/ CPF. Com o preenchimento de um destes campos o sistema já deve procurar em sua base por um semelhante, e encontrando dar opção de selecionar lo. Caso não seja encontrado nada, ou o usuário não tenha selecionado nenhum, o usuário deve poder seguir inserindo os demais campos como se fosse uma inclusão.

2.3.4 Encontrado e selecionado um cliente existente o sistema deve exibir todas suas informações cadastrais e permitir sua edição igualmente como é possível no módulo de “cadastro / cliente”. Um botão salvar alterações deve ser disponibilizado também para eventuais alterações. O sistema também deve exibir as abas “orçamento” e “pedidos” assim como é feito no módulo “cadastro / cliente”.

2.3.5 Se o cliente tiver o estado de “restrição” uma tela deve ser exibida ao usuário dizendo para ele entrar em contato com o departamento financeiro. O usuário ao clicar neste tele deve poder seguir normalmente com a inclusão do pedido.

2.3.6 Encontrado e selecionado um pedido existente este deve ser exibido ao usuário do sistema.

2.3.7 Selecionado a aba produtos esconder os detalhes das demais abas e exibir os detalhes da área de produtos que são os mesmo como no submódulo “cadastro / produto”

2.3.8 O usuário do sistema então poderá selecionar os produtos para o pedido de forma sub dividida.

2.3.9 Selecionando um produto o sistema deve adicionar lo ao pedido, exibindo-o lexibindo-ogexibindo-o abaixexibindo-o da linha de seleçãexibindo-o, cexibindo-om a quantidade de “1” pré-selecionada. Alem da quantidade o sistema deve exibir o preço unitário e o preço total que seria a quantidade multiplicado pelo preço unitário. Ao mudar a quantidade do produto selecionado o sistema deve recalcular automaticamente o total ao lado sem que a tela seja recarregada. (AJAX) 2.3.10 O valor do produto na inclusão de pedido não pode ser alterado.

2.3.11 Deve existir um produto chamado “outros” onde então o cliente colocará o valor manualmente.

2.3.12 Selecionado todos os itens do pedido o sistema deve exibir no final a totalização da quantidade e o valor total de todos os produtos selecionados.

2.3.13 Selecionado a aba “formas de pagamento” esconder os detalhes das demais abas e exibir os detalhes da aba em questão.

2.3.14 Na aba “forma de pagamento” deve conter um campo com o valor referente a somatória dos produtos selecionados.

(6)

2.3.15 Na aba “forma de pagamento” deve conter um campo para o vendedor colocar o valor de desconto, valor este que será em porcentagem.

2.3.16 Na aba “forma de pagamento” deve conter um campo “valor de frete” para que o vendedor coloque um valor em reais referente ao frete.

2.3.17 Na aba “forma de pagamento” deve conter um campo chamado “parcelas” para que o vendedor coloque o numero de parcelas que o pedido esta sendo feito.

2.3.18 Inserido a porcentagem de desconto, o valor de frete e o numero de parcelas o sistema deve abrir automaticamente uma linha para cada parcelas já com o valor liquido calculado e dividido pelo numero de parcelas, bem como com a data, que deve ser sugerida como sendo a primeira a vista (data atual) e as demais a cada 30 dias.

2.3.19 Se o vendedor quiser passar uma pedido com desconto ou quantidade de parcelas superior a sua alçada, outra pessoa com permissões para isso deverá digitar seu usuário e senha, e o sistema deve validar lo e permitir a ação. Esta situação também deve ser registrada como evento.

2.3.20 Cada linha de parcela deve exibir no começo um caixa de seleção com as opções de pagamento existentes, opções estas que devem estar gravadas em uma tabela no banco de dados.

2.3.21 Mostrar ou esconder os detalhes de acordo com as formas de pagamento selecionado para aquela parcela. Exemplo: Se for dinheiro não exibir detalhes do cheque.

2.3.22 Selecionado alguma forma de pagamento com cartão, apresentar um novo campo chamado CV e calcular as datas como sendo múltiplo de 31 dias. 2.3.23 Uma caixinha ao lado da primeira linha de parcela deve ser criado para

copiar seu conteúdo para as demais linhas. Ex. Eu preencho os dados de um cheque, clico nesta caixinha e o sistema copia todos estes dados para as demais parcelas. O mesmo serve para o campo CV, porem este sera igual para todos. Este campo é editável pelo operador, ele é apenas uma facilitador .

2.3.24 O usuários poderá a qualquer momento alterar a forma de pagamento das parcelas.

2.3.25 O usuário poderá alterar o valor e a data de cada parcela, porem o sistema deve conferir se a somatória das parcelas inseridas pelo usuário corresponde com a somatória dos produtos inseridos no pedido, já considerando a porcentagem de desconto se existir, e o valor de frete. 2.3.26 Ao lado de cada parcela deve haver ainda um campo para marcar se que a

parcela foi recebida na loja ou não, devendo vir pre selecionada que “sim”.

2.3.27 Para parcelas com a forma de pagamento “boleto” exibir uma caixinha se este foi emitido ou não na loja, devendo vir pre selecionada que “sim”. 2.3.28 Para cada pedido inserido o sistema deve gerar um código de pedido

(7)

caracteres seguido de um código com três caracteres, sequencial, ou seja, deve seguir a sequencia do último número inserido no sistema, e este número deve ser único em todo o sistema.

2.3.29 Inserido o pedido exibir um botão para impressão onde então um “recibo” será formatado para imprimir ao cliente. O recibo do cliente não deve trazer o nome “pedido”, mas sim “orçamento” em seu cabeçalho Neste recibo deve aparecer todas as informações do pedido com exceção dos detalhes das parcelas, ou seja, o sistema deve mostrar apenas a data e o valor.

2.3.30 Consultado um pedido o usuário deve ter um botão para poder cancelar o pedido, se estiver tiver a permissão para tal ação.

2.3.31 Pedidos já criado em nome de um cliente podem ser transferidos para outro cliente.

2.3.32 O sistema deve guardar a informação do usuário que fez o pedido.

2.4 Financeiro

2.4.1 Fechamento do Caixa

2.4.1.1 Módulo destinado a controlar o fechamento de caixa da loja e dos vendedores.

2.4.1.2 Este submódulo deve exibir as seguintes opções de consulta de filtro: Data inicial | Data Final | Nome do Usuário do Sistema. Selecionado as data e o usuário o sistema deverá buscar pelos pedidos inseridos por aquele usuário naquela data. Deve ser possível inserir mais de um usuário, e até mesmo todos ao mesmo tempo.

2.4.1.3 Deve ser possível restringir que certos usuários filtrem apenas pedidos que foram inseridos por ele, e que outros filtrem pedidos inseridos por todos.

2.4.1.4 O fechamento do caixa deve compor os valores, ou seja, somar e agrupar por tipo de pagamento e por data, sempre trazendo subtotais e totais gerais. Ele também deve subdividir todos os valores que foram marcados como “NÃO Recebido na Loja”

2.4.2 Contas a Receber

2.4.2.1 Módulo destinado a controlar o recebimento e valores das parcelas dos pedidos gerados no sistema.

2.4.2.2 Este modulo deve oferecer o filtro por data inicial, data final e tipo de pagamento, recebida ou não recebida.

2.4.2.3 Ao exibir o resultado do filtro, agrupar por tipo de pagamento, data, trazendo os subtotais e os totais gerais. Também deve ser possível expandir o agrupamento para ver quais parcelas de quais pedidos estão compondo aquele valor.

(8)

2.4.2.4 Ainda neste módulo deve ser possível marcar ou desmarcar uma parcela como recebidas

2.4.3 Comissão Vendedores

2.4.3.1 Relatório destinado a exibir as informações das comissão dos vendedores sobre os pedidos.

2.4.3.2 Permitir o filtro por data inicial, data final e vendedor.

2.4.3.3 Selecionado o filtro, calcular o valor de comissão do vendedor aplicando a porcentagem cadastrada para ele no módulo de usuários ao valor do pedido.

2.4.3.4 Exibir o resultado do filtro agrupado por data, com subtotal por data, e com o total geral ao final. Ao clicar na data expandir para exibir todos os pedidos que compõem aquela seleção, exibindo o numero do pedido, o nome / razão social, o nome fantasia, o CPF / CNPJ e o valor.

2.4.4 Consulta Cheque

2.4.4.1 Submódulo destinado a pesquisa de cheques utilizados no pagamento de parcelas dos pedidos.

2.4.4.2 O sistema deve permitir a busca por qualquer um dos campos do cheque.

2.4.4.3 Encontrado o cheque no sistema, exibir o pedido o qual eles foi utilizado.

2.4.5 Consulta Cartão

2.4.5.1 Submódulo destinado a pesquisa de números de “CV” do cartão utilizados no pagamento de parcelas dos pedidos.

2.4.5.2 O sistema deve permitir a busca pelo numero do “CV”

2.4.5.3 Encontrado o CV no sistema, exibir o pedido o qual eles foi utilizado

2.4.6 Consulta Boleto

2.4.6.1 Submódulo destinado a pesquisa de boletos que foram marcados no pedido para serem impressos no financeiro

2.4.6.2 O sistema deve permitir o filtro por data inicial, data final.

2.5 Gerencial

(9)

2.5.1.1 Submódulo destinado a gerar relatórios sobre os orçamentos

2.5.1.2 Este modulo deve oferecer o filtro por data inicial, data final, estado do pedido e usuário do sistema

2.5.1.3 Selecionado as opções de filtro o sistema deve exibir um orçamento por linha, criando um subtotal por data, por estado, e ao final um total geral.

2.5.1.4 Na linha de cada pedido deve aparece o numero do pedido, o nome do cliente, o CNPJ / CPF

2.5.1.5 Cada linha de orçamento ao ser clicada deve levar o usuário a visão completa do mesmo.

2.5.2 Pedidos

2.5.2.1 Submódulo destinado a gerar relatórios sobre os pedidos

2.5.2.2 Este modulo deve oferecer o filtro por data inicial, data final, estado do pedido e usuário do sistema

2.5.2.3 Selecionado as opções de filtro o sistema deve exibir um pedido por linha, criando um subtotal por data, por estado, e ao final um total geral.

2.5.2.4 Na linha de cada pedido deve aparece o numero do pedido, o nome do cliente, o CNPJ / CPF e a opção de se mudar o estado do mesmo.

2.5.2.5 Cada linha de pedido ao ser clicada deve levar o usuário a visão completa do mesmo.

2.5.3 Fabricação

2.5.3.1 Submódulo destinado a gerar relatórios sobre os produtos que foram pedidos.

2.5.3.2 Este modulo deve oferecer a opção de filtro por data inicial, data final e estado do pedido.

2.5.3.3 A exibição do resultado do filtro deve ser agrupada por data, produto e modelo.

2.6 Configurações

2.6.1 Módulo destinado as diversas configurações do sistema.

2.6.1.1

Usuários / Grupos / Perfil

2.6.1.1.1

Submódulo para criação, consulta e alteração dos usuários, grupos e perfis do sistema

(10)

2.6.1.1.2 Deve ser possível conceder ou restringir acesso a cada campo de todos os

módulos do sistema. As permissões possíveis são: “Nenhuma” - “Leitura” -

Leitura e Escrita”

2.6.1.1.3

O campo de permissão do número de parcelas do pedido deve poder receber qualquer número. Por exemplo, perfil 1. Neste campo é cadastrado o numero 6 e portanto o usuário que utiliza deste perfil poderá fazer pedidos em no máximo 6 parcelas. Exemplo perfil 2. Os usuários associados ao perfil 2 que tem cadastrado o numero “10” neste campo poderão realizar pedidos em ate dez parcelas. A mesma lógica deve ser aplicada ao campo desconto, para cada perfil criado um valor de desconto (em porcentagem) será inserido e este deve ser tomado como desconto máximo no pedido para o usuário associado a ele.

2.6.1.1.4

Cancelamento de Pedidos. O perfil deverá ter duas ações de cancelamento de pedidos, uma para os pedidos do dia e outra independente da data. Deve ser possível configurar que certos usuários possam fazer uma das ações e outra não.

Referências

Documentos relacionados

No final, os EUA viram a maioria das questões que tinham de ser resolvidas no sentido da criação de um tribunal que lhe fosse aceitável serem estabelecidas em sentido oposto, pelo

The DCF model using the Free Cash Flow to the Firm (FCFF) method, estimates in the first place the Enterprise Value of the company, that represents the value of all future cash

Este era um estágio para o qual tinha grandes expetativas, não só pelo interesse que desenvolvi ao longo do curso pelas especialidades cirúrgicas por onde

Super identificou e definiu construtos e a respectiva interacção no desenvolvimento da carreira e no processo de tomada de decisão, usando uma série de hipóteses: o trabalho não

Quando nos referimos à construção de personagens dentro dos eventos, identifiquei algumas denominações para algumas categorias dentro do meio, como o próprio

Foram utilizados objetos simuladores cilíndricos, feitos de material equivalente ao tecido, contendo o Fricke gel para derivar a porcentagem de dose em profundidade e os perfis

Deve-se acessar no CAPG, Coordenadorias > Processo de Inscrição > “Selecionar Área/Linha para Inscrição” e indicar as áreas de concentração e linhas de pesquisa nas

Assinale a alternativa correta com relação ao conceito de direitos humanos. a) Direitos humanos é uma forma sintética de se referir a direitos fundamentais da pessoa