DESENVOLVIMENTO DE UM MÓDULO DE PLANEJAMENTO DE COMPRAS APLICANDO O CONCEITO DE OPEN TO BUY

Transcrição

1 UNIVERSIDADE REGIONAL DE BLUMENAU CENTRO DE CIÊNCIAS EXATAS E NATURAIS CURSO DE SISTEMAS DE INFORMAÇÃO BACHARELADO DESENVOLVIMENTO DE UM MÓDULO DE PLANEJAMENTO DE COMPRAS APLICANDO O CONCEITO DE OPEN TO BUY FABRÍCIO DE SOUZA BLUMENAU /1-05

2 FABRÍCIO DE SOUZA DESENVOLVIMENTO DE UM MÓDULO DE PLANEJAMENTO DE COMPRAS APLICANDO O CONCEITO DE OPEN TO BUY Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação Bacharelado. Prof. Wilson Pedro Carli, Mestre - Orientador BLUMENAU /1-05

3 DESENVOLVIMENTO DE UM MÓDULO DE PLANEJAMENTO DE COMPRAS APLICANDO O CONCEITO DE OPEN TO BUY Por FABRÍCIO DE SOUZA Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por: Presidente: Membro: Membro: Prof. Wilson Pedro Carli, Mestre Orientador, FURB Prof. Alexander Roberto Valdameri, Mestre FURB Prof. Everaldo Artur Grahl, Mestre FURB Blumenau, 09 de julho de 2009

4 Dedico este trabalho à minha família, pelo apoio irrestrito em todos os momentos de minha vida, e a todos que, de alguma forma, contribuíram para a conclusão de mais esta etapa.

5 AGRADECIMENTOS Agradeço a Deus pela vida, por estar presente em todos os momentos, e por ter me proporcionado saúde e inteligência para conclusão deste trabalho. Ao meu pai Jair, minha mãe Lidia e à minha irmã Elaís, pelo imenso amor e atenção com que sempre me trataram, e pela paciência que tiveram durante o último ano de conclusão deste curso. Agradeço também, e muito, pela determinação de meus pais, que ao longo da vida, com muito esforço, proporcionaram a base da minha educação e personalidade. À minha namorada Cintya Sayuri Abiko, por todo o amor dedicado à minha pessoa, pelo apoio e incentivo, e também pelos incontáveis dias que deixei de estar ao seu lado para que este trabalho pudesse ser concretizado. Aos meus amigos e colegas de turma que me ajudaram durante os anos que passamos juntos. Ao professor e amigo Marcos Rogério Cardoso, por ter sido meu orientador na primeira etapa da elaboração deste trabalho, e por ter acreditado e apoiado esta idéia. Ao meu orientador, professor Wilson Pedro Carli, pela amizade, confiança e continuidade dada a este trabalho. Aos demais professores que estiveram presentes durante esta caminha, pelo grande conhecimento compartilhado. Aos meus companheiros de desenvolvimento do módulo Comercial do Sistema Sapiens, em especial, o supervisor deste trabalho, Sr. Fernando da Silva, por ter acreditado e dado todo o apoio e conhecimento necessário durante a sua realização.

6 Aos meus parceiros do módulo de Compras, Jonas Ivan de Abreu e Maikon Frech, por proporcionarem um grande conhecimento e auxílio, os quais foram muito importantes para a concretização deste trabalho. Ao gerente de sistemas da Senior Sistemas Corporativos Ltda, Sr. Agnaldo Montibeler, por permitir a utilização do Sistema Sapiens e toda a tecnologia da Senior necessária para a realização deste trabalho. Aos meus amigos de trabalho, Thiago Wilvert e Mabel Oackley Molina, pela ajuda e incentivo. A todos os demais colegas da Senior Sistemas Corporativos, que embora não mencionados nominalmente, sabem o quão importante foram os auxílios recebidos. À Senior Sistemas Corporativos como um todo, pelos desafios vividos diariamente e pelo conhecimento por eles proporcionados. À minha amiga Giovana Santos, pela ajuda e suas valiosas dicas. Aos autores dos livros que li durante a realização deste trabalho, certamente seus conhecimentos foram de grande valia. E a todas as outras pessoas que embora não citadas nominalmente, contribuíram para a realização deste trabalho. A todos vocês, o meu sincero muito obrigado!

7 O mal que os homens fazem vive para sempre. The evil that men do Iron Maiden

8 RESUMO O presente trabalho descreve os procedimentos utilizados na elaboração de um sistema de planejamento de compras para a área comercial de uma empresa, aplicando o conceito de Open to Buy no Sistema de Gestão Empresarial Sapiens da empresa Senior Sistemas Corporativos Ltda. A aplicação do estudo acontece em forma de desenvolvimento de um módulo de planejamento de compras, onde os gestores poderão planejar suas compras baseando-se em um orçamento financeiro para os materiais comprados, a ser administrado em um determinado período. Palavras-chave: Compras. Planejamento de compras. Open to buy.

9 ABSTRACT This paper describes the procedures used to develop a purchasing planning system for the commercial area of a company, applying the Open to Buy concept in Sapiens E.R.P. (Enterprise Resource Planning) of Senior Corporate Systems Ltda. The application of this study case is in how to develop a planning purchases module, where the administrators can plan their purchases based on a financial budget for materials purchased, to be administered in a certain period. Key Words: Purchases, Purchases Planning, Open to buy.

10 LISTA DE ILUSTRAÇÕES Quadro 1 Evolução da Administração de Materiais Quadro 2 Comparativo entre as atividades da área de compras no passado e no presente Quadro 3 Meta de Compras do mês Quadro 4 Exemplo simplificado da lógica do orçamento de compras Quadro 5 Cálculo do Open to Buy para o mês corrente Quadro 6 Cálculo do Open to Buy dos próximos meses Quadro 7 Exemplo de controle do Open to Buy Figura 1 Divisão dos módulos existentes no Sistema Sapiens Figura 2 Menu principal do Sistema Sapiens Figura 3 Fluxograma do sub-módulo compras do Sistema Sapiens Figura 4 Exemplo de geração de Nota Fiscal de Entrada via Ordem de Compra no Sistema Sapiens Figura 5 Fluxograma do sub-módulo vendas do Sistema Sapiens Figura 6 Fluxograma do sub-módulo estoques do Sistema Sapiens Figura 7 Planejamento integrado de mercadorias e sortimento na solução SAP Retail MAP Quadro 8 Requisitos funcionais Quadro 9 Requisitos não funcionais Figura 8 Diagrama de casos de uso gerente de compras Figura 9 Diagrama de casos de uso comprador Figura 10 Pacotes do módulo de planejamento de compras Figura 11 Pacote ObjetosPlanejamento Figura 12 Pacote InterfacesPlanejamento Figura 13 Pacote AuxiliaresPlanejamento Figura 14 Diagrama de estados da classe TPlanejamento Figura 15 Diagrama de atividades do planejamento de compras Figura 16 Diagrama entidade relacionamento Figura 17 Interface da ferramenta CBDS Figura 18 Interface do gerador de relatórios do Sistema Sapiens Figura 19 Menu do módulo de planejamento de compras Figura 20 Tela de seleção dos relatórios gerais do módulo Comercial... 71

11 Figura 21 Tela de permissões de acesso do Sistema Sapiens Figura 22 Tela de cadastro de planejamentos de compras Figura 23 Exemplo de hierarquia de produtos existente no Sistema Sapiens Figura 24 Exemplo de hierarquia de produtos utilizando agrupamento de produtos Figura 25 Mensagem de aviso para escolha correta do início de uma quinzena Figura 26 Mensagem de confirmação para aplicação correta da data final da quinzena Figura 27 Mensagem de advertência para a não utilização de período passado Figura 28 Exemplo de dados do cabeçalho já informados em um planejamento Figura 29 Tela de cálculo do OTB para período corrente Figura 30 Tela de cálculo do OTB para período futuro Quadro 10 Campos da grid de Itens do Planejamento Figura 31 Tela de base para geração do planejamento de compras Figura 32 Exemplo de histórico de compras Figura 33 Exemplo de histórico utilizando tipo de período quinzenal Figura 34 Exemplo de histórico utilizando tipo de período mensal Figura 35 Consulta de produto base para planejamento via tela de pesquisa de registro Figura 36 Itens do planejamento após utilização da base para geração Figura 37 Valores e saldos dos itens de planejamento Figura 38 Tela de cadastro de ordens de compra Figura 39 Aba de Produtos do cadastro de ordens de compra Figura 40 Exemplo de aviso de produto não planejado Figura 41 Exemplo de bloqueio de compra de produto não planejado Figura 42 Exemplo de aviso de produto com condição de pagamento não planejada Figura 43 Exemplo de bloqueio de compra de produto com condição de pagamento não planejada Figura 44 Item de produto digitado na ordem de compra Figura 45 Relacionamento de um item de planejamento com item de ordem de compra Figura 46 Demais informações disponibilizadas através do relacionamento Figura 47 Informações atualizadas no planejamento de compras Figura 48 Exemplo de falta de saldo financeiro para o produto planejado Figura 49 Exemplo de falta de saldo físico para o produto planejado Figura 50 Exemplo de falta de saldo financeiro para a origem de produto planejada Figura 51 Consistência efetuada na alteração de quantidade de um item de planejamento já utilizado... 94

12 Figura 52 Consistência efetuada na alteração de valor de um item de planejamento já utilizado Figura 53 Consistência efetuada na tentativa de inativação de um planejamento de compras já utilizado Figura 54 Consistência efetuada na tentativa de exclusão de um planejamento de compras já utilizado Figura 55 Consistência efetuada na tentativa de alteração do código de origem de um item utilizado Figura 56 Consistência efetuada na tentativa de exclusão de um item já utilizado Figura 57 Consistência efetuada na tentativa de ativação de um planejamento de compras já finalizado Figura 58 Tela de consulta de ordens de compra da nota fiscal de entrada Figura 59 Aba de Produtos do cadastro de notas fiscais de entrada Figura 60 Tela de consulta de planejamentos de compras Figura 61 Tela de consulta de quantidades e valores já utilizados (NFEs) Figura 62 Tela de consulta de saldos disponíveis para compras Figura 63 Demais informações da consulta de saldos disponíveis para compras Figura 64 Tela de consulta de desempenho com relação às vendas Figura 65 Demais informações da grid de Itens Detalhados da consulta de desempenho com relação às vendas Figura 66 Relatório resumido de planejamentos de compras Figura 67 Relatório detalhado de planejamentos de compras Quadro 11 Tabela EMPRESA Quadro 12 Tabela FILIAL Quadro 13 Tabela PLANEJCOMPRAS Quadro 14 Tabela ITENSPLANEJAMENTO Quadro 15 Tabela ORDEMCOMPRA Quadro 16 Tabela ITENSPROOC Quadro 17 Tabela NFENTRADA Quadro 18 Tabela ITENSPRONFE Quadro 19 Código fonte dos métodos mais relevantes da classe TPlanejamento Quadro 20 Código fonte dos métodos mais relevantes da classe TItemPlanejamento Quadro 21 Código fonte dos métodos mais relevantes da classe Frm_CadastraPlanejamento

13 Quadro 22 Código fonte do método Mostrar da classe Frm_BasePlanejamento

14 LISTA DE SIGLAS CBDS Central de Banco de Dados Senior CTRC Conhecimento de Transporte Rodoviário de Cargas EA Enterprise Architect ECF Emissor de Cupom Fiscal ERP Enterprise Resource Planning IDV Instituto para Desenvolvimento do Varejo NFE Nota Fiscal de Entrada OC Ordem de Compra OTB Open to Buy PDV Ponto de Venda RF Requisitos Funcionais RH Recursos Humanos RNF Requisitos Não Funcionais SEBRAE Serviço Brasileiro de Apoio às Micro e Pequenas Empresas SGBD Sistema Gerenciador de Banco de Dados SGQ Sistema de Gestão da Qualidade SIG Sistema de Informação Gerencial SQL Structured Query Language SVCL Senior Visual Component Library TEF Transferência Eletrônica de Fundos UML Unified Modeling Language

15 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS DO TRABALHO ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA ADMINISTRAÇÃO DE MATERIAIS COMPRAS NO CONTEXTO EMPRESARIAL Varejo: Compras no segmento comercial PLANEJAMENTO DE COMPRAS Organização financeira de compras x Objetivos da alta administração Orçamento de compras Open to Buy Planejamento unitário das compras Como comprar bem utilizando o planejamento de compras na visão do SEBRAE SISTEMA SAPIENS Módulo Comercial do Sistema Sapiens Compras Ordem de Compra (OC) Nota Fiscal de Entrada (NFE) Vendas Estoques Distribuição Transporte TRABALHOS CORRELATOS DESENVOLVIMENTO DO MÓDULO DE PLANEJAMENTO DE COMPRAS REQUISITOS Requisitos funcionais Requisitos não funcionais ESPECIFICAÇÃO Diagramas de Casos de Uso Diagrama de Casos de Uso do Gerente de Compras Diagrama de Casos de Uso do Comprador... 53

16 3.2.2 Diagramas de Classes Pacote ObjetosPlanejamento Pacote InterfacesPlanejamento Pacote AuxiliaresPlanejamento Diagrama de Estados Diagrama de Atividades Diagrama Entidade Relacionamento IMPLEMENTAÇÃO Técnicas e ferramentas utilizadas Central de Banco de Dados Senior (CBDS) Gerador de Relatórios Sapiens Operacionalidade da implementação Tela de Cadastro de Planejamentos de Compras Processo de abatimento de saldos via tela de Cadastro de Ordens de Compra Processo de relacionamento Ordem de Compra Nota Fiscal de Entrada Tela de Consulta de Planejamentos de Compras Tela de Consulta de Quantidades e Valores já Utilizados (NFEs) Tela de Consulta de Saldos Disponíveis para Compras Tela de Consulta de Desempenho com Relação às Vendas Relatório Planejamento de Compras - Resumido Relatório Planejamento de Compras - Detalhado RESULTADOS E DISCUSSÃO CONCLUSÕES EXTENSÕES REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A Definições das tabelas e campos envolvidos no desenvolvimento do módulo de planejamento de compras APÊNDICE B Métodos de maior relevância de algumas das classes utilizadas no desenvolvimento do módulo de planejamento de compras

17 17 1 INTRODUÇÃO Segundo Parente (2000), as atividades de planejamento são essenciais à sobrevivência de qualquer empresa onde servem, principalmente, para antecipar e organizar as atividades a fim de alcançar um objetivo. O planejamento estratégico é de extrema importância, visto que o mesmo é responsável por envolver a determinação de intenções e objetivos de longo prazo, além do planejamento tático, que envolve as atividades de marketing de curto prazo. Para atingir os objetivos de lucro e crescimento das empresas, existem várias etapas e processos que devem ser seguidos a fim de obter resultados positivos. Neste contexto, um dos processos, talvez o mais importante, é o planejamento de compras, pois, segundo Grazziotin (2003, p. 23), comprar bem já é a metade da venda, ou seja, no ato da compra já se inicia a venda. Para o autor, quando se assina um pedido já se define a metade do lucro, portanto, o lucro está na compra e a venda é uma decorrência de uma boa compra. No Brasil, assim como em grandes empresas internacionais, também existem problemas com relação à área de compras onde, de acordo com Dias e Costa (2006, p. 29), muitos profissionais da área acabam sendo forçados a atuar na fase de execução dos trabalhos, deixando em segundo plano ou, pior, ignorando a importante fase de planejamento. Segundo as definições de missão e objetivos da área de compras especificadas por Coronado (2001), Costa (2002) e Dias e Costa (2006), pode-se definir que esta área tem como principais objetivos: comprar a quantidade de material e mercadoria correta, bem como também adquirir serviços, no momento certo, da fonte certa, com a qualidade desejada, e ao menor custo possível. Diante do exposto, neste trabalho desenvolveu-se um módulo de planejamento de compras na área comercial de uma empresa, através do Sistema de Gestão Empresarial (Enterprise Resource Planning - ERP) 1 Sapiens da empresa Senior Sistemas Corporativos Ltda. O trabalho aplica o conceito de Open to Buy (OTB), ou seja, o tratamento dos saldos de recursos financeiros disponíveis para compras no ERP Sapiens, pois, para Parente (2000, p. 224), uma vez estabelecido o planejamento de compras, o Open to Buy precisa ser desenvolvido para que haja a monitoração do cumprimento das previsões de compra. 1 ERP são sistemas que permitem que as decisões e as bases de dados de todas as partes de uma organização sejam integradas de forma que as consequências das decisões de uma parte da organização sejam refletidas nos sistemas de planejamento e controle do resto da organização (SLACK; CHAMBERS; JOHNSTON; BETTS, 2007, p. 338).

18 OBJETIVOS DO TRABALHO O objetivo deste trabalho foi o desenvolvimento de um módulo de planejamento de compras para a área comercial de empresas varejistas aplicando o conceito de Open to Buy, atribuído ao ERP Sapiens da empresa Senior Sistemas Corporativos. Os objetivos específicos do trabalho foram: a) desenvolver um módulo que automatiza os processos de planejamento de compras no ERP Sapiens; b) possibilitar que o sistema gerencie o andamento das compras conforme definido no planejamento; c) disponibilizar, através do planejamento de compras, informações sobre o controle de gastos inerentes a esta área, bem como o saldo disponível para compras. 1.2 ESTRUTURA DO TRABALHO O presente trabalho está estruturado em quatro capítulos. No primeiro capítulo apresenta-se a introdução, o objetivo geral, bem como os objetivos específicos e a estrutura do trabalho, disponibilizando uma visão geral do mesmo e o contexto em que está inserido. O segundo capítulo apresenta a fundamentação teórica necessária para o desenvolvimento do trabalho onde são apresentados os principais conceitos de Administração de Materiais, Compras no contexto empresarial, Planejamento de Compras e Open to Buy. O capítulo também mostra características do ERP Sapiens e de alguns trabalhos correlatos. No terceiro capítulo é apresentado o desenvolvimento do módulo de planejamento de compras no ERP Sapiens, mostrando a apresentação dos requisitos, diagramas e ferramentas utilizadas no desenvolvimento, bem como é feita também uma demonstração do funcionamento do módulo. O quarto capítulo apresenta as conclusões finais e sugestões para trabalhos futuros.

19 19 2 FUNDAMENTAÇÃO TEÓRICA Neste capítulo são apresentados os aspectos teóricos relacionados aos conceitos envolvidos na Administração de Materiais e Compras, os quais devem ser compreendidos para um melhor entendimento dos conceitos de Planejamento de Compras e Open to Buy. Os conceitos de Administração de Materiais também contribuirão para uma melhor compreensão do conteúdo exposto sobre o ERP Sapiens e os trabalhos correlatos que também são apresentados ao final do capítulo. 2.1 ADMINISTRAÇÃO DE MATERIAIS A Administração de Materiais é uma das atividades de gestão mais importantes para as empresas. A manutenção da competitividade está ligada diretamente à forma com que os materiais são administrados, os quais devem possuir níveis compatíveis com suas demandas, como também as compras necessitam ser cada vez mais ágeis para poder atender às necessidades de aumento da velocidade da renovação dos estoques. Reduzir os níveis de armazenamento sem causar desabastecimento é o grande desafio para a gestão de materiais, visto que a manutenção da lucratividade da empresa é altamente dependente deste processo (COSTA, 2002, p. 17). Outra definição a respeito da Administração de Materiais é apresentada por Severo Filho (2006, p. 15): Administração de Recursos Materiais é utilizar os princípios básicos da Administração, com um padrão de qualidade sistemática, com a finalidade de bem aplicar os recursos financeiros e materiais, destinados às atividades operacionais de uma organização, seja de natureza industrial, comercial ou de serviços. Segundo Francischini e Gurgel (2002, p. 4), a evolução da Administração de Materiais processou-se em várias fases: a) atividade exercida diretamente pelo proprietário da empresa, pois comprar era a essência do negócio;

20 20 Quadro 1. b) atividades de compras como apoio às atividades produtivas e, portanto, integradas à área de produção; c) condenação dos serviços envolvendo materiais, começando com o planejamento das matérias-primas e a entrega de produtos acabados, em uma organização independente da área produtiva; d) agregação à área logística das atividades de suporte à área de marketing; e) modelo atual da área de logística da qual faz parte a Administração de Materiais. Os pontos anteriormente mencionados podem ser resumidos conforme mostrado no Percepção Empresarial O administrador de materiais Perfil do profissional Progresso do profissional Atividades da Administração de Materiais Situação Inicial Pessoa de recados Pessoa bem considerada Sem possibilidades Faz despesas Processo de Evolução Funcionário a serviço da produção Burocrata eficiente Comprador Evita faltas e desmobiliza estoques excedentes Estágio Avançado Executivo conhecedor do mercado de abastecimento Conhecedor de administração comercial e de mercados Planejamento do negócio Planejamento estratégico Fonte: Francischini e Gurgel (2002, p. 4). Quadro 1 Evolução da Administração de Materiais Situação Atual Executivo que administra 60% dos custos e das despesas Executivo com preparo técnico, econômico e legal Diretor Executivo Concentração em uma visão de melhoria dos resultados 2.2 COMPRAS NO CONTEXTO EMPRESARIAL Nos últimos anos, em todo o mundo, a área de compras vem passando por grandes transformações e o grande motivo está no fato de que passou a ter importância equivalente à finanças, marketing ou produção, e hoje integra as decisões estratégicas das empresas, sendo que nenhuma organização financeiramente bem sucedida pode abstrair-se da contribuição de compras/suprimentos em seu planejamento estratégico (DIAS; COSTA, 2006, p. 11). No Quadro 2 é apresentado um comparativo entre as principais atividades da área de compras no passado e no presente.

21 21 NO PASSADO NO PRESENTE era um mal necessário é vantagem competitiva função isolada, normalmente vinculada à produção função integrada, normalmente vinculada à alta direção objetiva redução de custos objetiva otimização de custos gerenciava crises antevê problemas e busca soluções operava manualmente ou usava o computador precariamente opera com sistemas integrados de gestão, muitos deles ligados aos fornecedores trabalhava com muitos fornecedores trabalha com poucos fornecedores utilizava inspeções de utiliza qualidade assegurada qualidade denominava o público interno de usúarios denomina o público interno de clientes internos pedidos de compras isolados contratos de longo prazo profissional: comprador profissional: empreendedor informações dispersas gerenciamento das informações Fonte: Dias e Costa (2006, p. 12). Quadro 2 Comparativo entre as atividades da área de compras no passado e no presente Com esta comparação pode-se perceber que o profissional desta área atualmente possui características típicas de um empreendedor, e não mais apenas de comprador, visto que atualmente o mercado exige destes profissionais conhecimentos técnicos, comerciais e de gerenciamento. Costa (2002), afirma que a função de comprador é mais que uma atividade administrativa, ela é de vital importância para o sucesso das atividades logísticas de uma empresa. Ele ainda afirma que: A Área de Compras é, por muitos, vista de forma equivocada como uma área excessivamente burocrática e geradora de despesas, mas na realidade pode trazer resultados bem diferentes, desde que suas funções sejam bem executadas. Constata-se facilmente que a questão da compra, de modo geral, não tem um tratamento mais sério, mais profissional. Um teste simples comprova isso: basta entrar numa livraria e verificar quantos títulos existem sobre vendas e quantos, sobre compras. A venda é algo que dá mais tesão, é mais agradável, e achamos muito importante vender é o nosso negócio. Continuo, porém, acreditando que comprar é mais importante. (GRAZZIOTIN, 2003, p. 24). Sabe-se que no contexto empresarial a administração de compras já é reconhecida como uma atividade estratégica crucial, e que no mundo acadêmico esta área também já

22 22 possui seu reconhecimento, com disciplinas acadêmicas e grande número de professores universitários dedicados ao estudo desta área. Com relação à grande importância da área de compras, Dias e Costa (2006), afirmam que essa importância é relativa em vários fatores, tais como a natureza da organização ou o seu grau de dependência de terceiros. Porém, independente de qualquer fator, está comprovado que muito pode ser feito de positivo, em uma empresa, a partir do desempenho de uma área de compras bem estruturada. Como já mencionado, sabe-se que a área de compras tem como principais objetivos comprar a quantidade de material e mercadoria correta, bem como também adquirir serviços, no momento certo, da fonte certa, com a qualidade desejada, e ao menor custo possível. Baily et al. (2000, p. 31), ainda propõe a seguinte definição ampla de objetivos da área de compras no contexto empresarial: a) suprir a organização com um fluxo seguro de materiais e serviços para atender a suas necessidades; b) assegurar continuidade de suprimento para manter relacionamentos efetivos com fontes existentes, desenvolvendo outras fontes de suprimentos alternativas, ou para atender a necessidades emergentes ou planejadas; c) comprar eficiente e sabiamente, obtendo por meios éticos o melhor valor por centavo gasto; d) administrar estoques para proporcionar o melhor serviço possível aos usuários e ao menor custo; e) manter relacionamentos cooperativos sólidos com outros departamentos, fornecendo informações e aconselhamentos necessários para assegurar a operação eficaz de toda a organização; f) desenvolver funcionários, políticas, procedimentos e organização para assegurar o alcance dos objetivos previstos. Além disso, Baily et al. (2000) ainda acrescenta alguns objetivos mais específicos como: a) selecionar os melhores fornecedores do mercado; b) ajudar a gerar o desenvolvimento eficaz de novos produtos; c) proteger a estrutura de custos da empresa; d) manter o equilíbrio de qualidade/valor; e) monitorar as tendências do mercado de suprimentos; f) negociar eficazmente para trabalhar com fornecedores que buscarão benefício

23 23 mútuo por meio de desempenho economicamente superior. Embora no contexto empresarial tem-se conhecimento que a maioria das operações de aquisição envolve a parte financeira de uma organização, Severo Filho (2006, p. 23) propõe uma justificativa do por que não tratar-se a função aquisição como compra. Segundo ele, o sentido da palavra aquisição significa várias maneiras ou formas de adquirimos alguma coisa. Pode-se adquirir através de compra, doação, leilão, empréstimo, leasing, ou até mesmo utilizando meios ilegais, porém, todas estas formas seguem um processo, que utiliza-se de meios e estratégias. Severo Filho (2006), afirma que a função Aquisição depende especificamente da Gerência de Estoques, onde o comprador por meios de relatórios gerenciais possui diariamente a posição dos estoques e, conseqüentemente, as quantidades a serem adquiridas, bem como quando essas aquisições devem ser feitas. As informações destes relatórios representam as necessidades de aquisição de determinado material, dando início ao ciclo de aquisição Varejo: Compras no segmento comercial Segundo Dias e Costa (2006, p. 531), embora os princípios fundamentais sejam semelhantes, existem algumas diferenças conceituais nas aquisições para empresas comerciais relativamente às industriais. Na indústria sabe-se que os materiais adquiridos serão manufaturados e, durante este processo será agregado valor ao produto final, resultando em um valor global muito superior ao somatório dos custos individuais dos componentes empregados. O mesmo não acontece no varejo, pois a empresa que comercializa vende os produtos exatamente como foram recebidos, ou seja, a função do varejo é realizar a distribuição, colocando ao alcance do público as mercadorias desejadas. Uma primeira dificuldade diz respeito ao problema da marca. No âmbito industrial, o profissional de compras pode consultar vários fornecedores, detentores de marcas diferentes. Basta que estas estejam aprovadas pelo controle de qualidade. A compra, então, será decidida em função das melhores condições comerciais oferecidas, independentemente da marca, pois todas são aceitáveis. No varejo, a situação é diferente. Muitos consumidores têm preferência por marcas especificas. Mesmo quando determinado fabricante pratica preço muito acima da concorrência,

24 24 seu produto deve ser adquirido para não desfalcar a gôndola. (DIAS; COSTA, 2006, p. 532). Diante do exposto, Dias e Costa (2006, p. 532) elencam alguns aspectos relevantes sobre a atuação do comprador varejista: a) acompanhamento do giro do estoque: como o ressuprimento é atribuição do analista de compras, conhecer o nível dos estoques dos itens, verificando quais estão sendo mais comercializados, é imperativo para garantir a não ocorrência de faltas e, também, que não existam mercadorias encalhadas nas prateleiras; b) atrasos nos pedidos colocados: diferentemente do procedimento padrão para a indústria e o serviço, no comércio a substituição de fornecedores é tarefa muito difícil. Aqui existe o conceito da marca. O consumidor tem preferências, e essas não podem ser ignoradas pelo comprador. A ocorrência de atrasos é dos maiores problemas, pois, apesar do mau atendimento de alguns fornecedores, não podemos simplesmente cancelar o pedido e substituir esses fornecedores. A receita é justamente oposta a essa recomendação padrão. Ao invés de cancelar o pedido, o procedimento mais usado é colocarmos outro, garantindo nosso lugar na fila de atendimento e resguardando-nos de outros atrasos, mais para frente; c) compras especulativas: no varejo, a perspectiva de aumento nos preços de uma mercadoria pode desencadear uma aquisição especulativa. O comprador aumenta os níveis de estoque para beneficiar-se dessa elevação potencial. Com essa providência, poderá optar por acompanhar os preços dos concorrentes, aumentando seus lucros, ou manter os preços e vender volume acima da média normal; d) desenvolvimento de marcas alternativas: como o parâmetro preço é um dos determinantes na decisão de compra do consumidor, o comprador deve ficar atento para novas marcas colocadas no mercado. Geralmente, essas são oferecidas em condições especiais, com a finalidade de conquistar parcela do mercado. Sabendo explorar essas oportunidades, é possível oferecer produtos mais baratos, atraindo consumidores de baixa renda, ou realizar promoções para aumentar a venda de outros produtos os quais poderão ser vendidos aos clientes que procurarem ofertas; e) contatos com clientes nos PDVs 2 : uma atividade de suma importância no trabalho 2 PDV é uma sigla comumente utilizada para designar o estabelecimento comercial, cujo significado é Ponto de Venda (DIAS; COSTA, 2006, p.533).

25 25 do profissional do varejo é o permanente contato com os clientes nos PDVs. Como, muitas vezes, a decisão sobre o que e quanto comprar é deles, torna-se fundamental conhecer as preferências dos consumidores. Identificar modelos, marcas, cores ou tamanhos mais procurados propiciará mais segurança à decisão de compra, evitando os encalhes ou faltas dos itens mais vendidos; f) terceirização com fornecedores: prática ainda pouco difundida no Brasil, a transferência para alguns fornecedores da gestão do estoque do varejista, cuidando para que a reposição aconteça na mesma velocidade das vendas ao consumidor final, começa a ser exercida. Esse conceito sedimenta-se na premissa de que o fornecedor, por conhecer profundamente o seu segmento de mercado, desfruta de melhores condições de responder às flutuações da demanda, assim como, por ter a responsabilidade pela reposição, tenderia a conceder mais prioridade aos clientes que se enquadram nessa categoria. O comprador passa a administrar os contratos, cuidando para que os estoques não sejam maiores do que o desejado, exercendo o controle do processo, especialmente no que se refere aos preços praticados, e assegurando seu sucesso; g) utilização do regime de consignação: outra prática muito usual é a consignação de mercadorias. O fornecedor remete determinado volume de produtos para pagamento posterior, em conformidade com as vendas futuras, assumindo o compromisso de receber de volta as unidades não vendidas. Essa sistemática facilita demais a decisão de compra, pois risco de arcar com o estoque não vendido passa a ser do fornecedor e não do varejista. Cuidado fundamental, contudo, é não utilizar esse instrumento de modo indesejado. Apenas porque o risco é do fornecedor, alguns compradores solicitam volumes excessivos de mercadorias. Muitas vezes, ocorre a obsolescência ou as devoluções de grandes quantidades. É fácil perceber que, caso essa conduta se estenda por muito tempo, o fornecedor desiste do procedimento e passa a ter sérios problemas financeiros, porque o seu estoque vai-se tornar excessivamente elevado, em função das devoluções; h) trabalhar com margens negativas: muitos varejistas usam o rendimento financeiro como substituto da margem operacional. O comprador, ao negociar com os fornecedores, obtém prazos de pagamento elevados. Como muitas mercadorias são vendidas à vista, o recurso financeiro pode ser mantido aplicado até o efetivo pagamento. Assim, fazendo o cálculo tradicional de margem, partindo-se do valor de aquisição versus o preço de venda, essa é muito pequena ou, até negativa, mas,

26 26 considerando o rendimento financeiro, o resultado final será satisfatório. Isso tudo, porém, somente será possível se o comprador conseguir prazos de pagamento realmente longos; i) conhecimento dos principais impostos incidentes: com o elenco de impostos existentes, o comprador do varejo deve estar permanentemente atento. Existem tributos estaduais e, por essa razão, variáveis em função da localização geográfica do fornecedor. Muitas vezes, uma condição de preço, aparentemente atrativa, é inferior a outra, fato visível com uma simples avaliação tributária. Outra preocupação com os impostos diz respeito à recuperação desses. Determinados tributos podem ser compensados ou recuperados. Recomendamos ao comprador varejista consultar o departamento fiscal da sua organização para obter a orientação sobre como proceder em cada situação particular; j) compras com bonificação: muitos fornecedores não podem conceder descontos sobre os seus preços, por serem estes padronizados. Muitos, contudo, podem oferecer bonificações, isto é, acrescentam determinado volume à quantidade constante do pedido, pelo mesmo valor total original, o que, na prática, representa concessão no preço unitário. Cabe ao profissional de compras, avaliar os benefícios decorrentes desse incremento e implementar no âmbito da empresa varejista. Ainda neste contexto, é importante salientar três conceitos muito importantes para uma melhor condução das tarefas do comprador varejista, principalmente no acompanhamento rigoroso das mercadorias integrantes do estoque da empresa, que deve ser exercido pelo comprador. Tais conceitos também são explicados por Dias e Costa (2006, p. 536) conforme visto a seguir: a) variedade: identifica o número de linhas de mercadorias componentes do estoque da empresa colocado à disposição do público. Está relacionada ao conceito de família, sugerindo afinidade entre elas; b) sortimento: quantidade de produtos integrantes de cada linha. Pode-se dispor de poucos produtos para cada linha, situação característica de reduzido sortimento, ou gama muito variada de mercadorias, sugestiva de grande sortimento; c) uniformidade: identifica o grau de inter-relação das diversas linhas entre si. Diz-se que existe uniformidade quando a correlação entre linhas ou mercadorias é elevada. Esta seria situação típica de loja de cama, mesa e banho, por exemplo, em que todas as mercadorias estão associadas.

27 PLANEJAMENTO DE COMPRAS De acordo com Parente (2000, p. 222), o processo de compras envolve, provavelmente, a atividade mais crítica de uma empresa do ramo de varejo. À medida que as vendas são realizadas, os estoque das lojas necessitam ser reabastecidos para que novas vendas possam ocorrer. O ciclo de abastecimento consiste em uma função vital para a sobrevivência e expansão de qualquer empresa varejista. Com base na importância da área de compras perante os outros setores da empresa, percebe-se que os profissionais desta área precisam estar preparados para que a organização como um todo consiga alcançar os objetivos financeiros planejados pela alta administração, para tanto, a seguir serão abordados os principais aspectos relacionados ao planejamento de compras Organização financeira de compras x Objetivos da alta administração Segundo Levy e Weitz (2000), os planos financeiros começam no topo da organização de varejo e são divididos em categorias, enquanto os compradores e planejadores de mercadorias fazem os seus próprios planos e os negociam com os níveis mais altos da organização. Os gerentes superiores precisam tomar decisões que irão definir a imagem comercial da empresa, por outro lado, os compradores e planejadores de mercadorias estudam o desempenho passado de suas categorias, verificam as tendências de mercado e tentam efetuar uma projeção das necessidades de suas mercadorias para as vendas futuras. De acordo com Parente (2000), diversas práticas são adotadas nos procedimentos de planejamento e gestão de compras, estes procedimentos podem ser estruturados em torno de três abordagens: a) de cima para baixo: começa com a gerência determinando um montante em unidade monetária a ser estabelecido para as compras, para toda a empresa. Os gestores de compras, então, distribuem esse montante entre as várias categorias, por loja; b) de baixo para cima: começa com a estimativa no nível de produto, passando pelo nível de categoria, departamento, e consolidados no nível da empresa; c) interativa: linhas gerais de orçamentos financeiros de compras são estabelecidos

28 28 pela gerência. Os compradores, então, seguem a abordagem de baixo para cima com revisões e modificações feitas pela gerência para assegurar que tanto as metas financeiras como as estratégicas de marketing e de abastecimento do produto sejam cumpridas. Essa abordagem pressupõe que a organização possua um bom sistema de informações e de coordenação. Para as empresas menores, o planejamento financeiro também é semelhante, embora não existam tantos níveis de gerenciamento envolvidos Orçamento de compras Segundo Parente (2000, p. 223), em qualquer ramo varejista, as compras constituem a conta de despesa de maior importância no relatório de lucros e perdas da empresa. Para Santos (2006, p. 19), o orçamento de compras de uma empresa varejista determina o valor a ser comprado mensalmente pela empresa em função do volume de vendas previsto, e define os objetivos de venda, margens e níveis de estoque desejados pela empresa. Quando houver alterações nas previsões de venda, o orçamento de compras poderá ser modificado, tem-se como exemplo, o caso em que as vendas superam o objetivo planejado, neste caso, a área de compras deve ser ágil para acelerar as entregas dos fornecedores quando identificado que irá ocorrer a falta dos produtos comercializados pela empresa. Elaborar um bom orçamento de compras ainda é uma tarefa difícil para a maioria das empresas varejistas, uma vez que as mudanças no cenário econômico, nos gostos dos consumidores e na alteração do padrão de compra, podem afetar o volume de vendas e conseqüentemente, exigir mudanças nas quantidades a serem compradas. (SANTOS, 2006, p. 19). Neste contexto, Parente (2000, p. 223) sugere que a Meta de Compras do mês seja adquirida através da fórmula apresentada no Quadro 3.

29 29 Estoque planejado para o final do mês - Estoque inicial do mês + Previsão de vendas do mês + Demarcações previstas = Meta de Compras do mês Fonte: Parente (2000, p. 223). Quadro 3 Meta de Compras do mês O Quadro 4 apresenta um exemplo simplificado da lógica do orçamento de compras. Período 1 (R$ 1.000) Período 2 (R$ 1.000) Período 3 (R$ 1.000) Estoque inicial do mês (preço de venda) Estoque planejado final do mês (preço de venda) Previsão de vendas do mês (preço de venda) Meta de compras do mês (preço de venda) Vendas do mês (preço de venda) Fonte: Parente (2000, p. 223). Quadro 4 Exemplo simplificado da lógica do orçamento de compras Parente (2000, p. 223) explica que, conforme se pode observar no Quadro 4, no primeiro período a empresa iniciou o mês com valor dos estoques iguais ao estoque planejado para o final do mês (R$ 400 mil). A Meta de Compras é então equivalente à previsão das vendas do mês (R$ 200 mil). Percebe-se que as vendas no primeiro período (RS 170 mil) foram inferiores ao valor previsto, o que resultou em uma elevação no valor de estoque inicial do segundo período. No segundo período o valor do estoque do início do mês (R$ 430 mil) é maior do que o valor do estoque planejado para o final do mês (R$ 400 mil), então, neste caso foi estabelecida uma Meta de Compras (R$ 180 mil) menor que a previsão de vendas (R$ 210 mil), isto para que o volume dos estoques seja corrigido para atingir o objetivo inicial do terceiro período. No terceiro período a empresa encontra-se em situação oposta à do segundo período, possuindo um valor de estoque baixo (R$ 390 mil), desta forma, a Meta de Compras (R$ 215 mil) deverá atender as necessidades das vendas (R$ 215 mil) e repor a defasagem do estoque (R$ 10 mil). Em muitas empresas, ocorre a prática das demarcações de preço, estas por sua vez, assumem uma magnitude expressiva, sendo necessário ajustar a Meta de Compras do mês. As demarcações devem incluir não somente as reduções de preços das mercadorias, mas também as quebras, causadas por estragos ou roubos. Desta forma, as demarcações reduzem o valor dos estoques e, portanto, as compras precisam repô-las. Parente (2000), explica ainda que, se o volume de demarcações planejadas no segundo

30 30 período fosse de R$ 10 mil, a Meta de Compras para este período passaria a ser R$ 190 mil, conforme o cálculo: Meta de Compras do Mês = (R$ R$ ) + (R$ ) + (R$ ) = R$ Open to Buy Segundo Parente (2000, p. 224), uma vez estabelecido o planejamento de compras, é necessário que os gestores de compras desenvolvam instrumentos de controle, denominados Open to Buy ( saldo disponível para compras ), para que as compras de determinado período não ultrapassem o que foi projetado. Este controle deve registrar não somente as compras já entregues, mas também as compras efetuadas que ainda não foram recebidas. Um bom controle de estoque é fundamental para assegurar um nível adequado de estoque para as vendas que serão efetuadas. Estoque excessivo ou mercadorias erradas estocadas durante determinados períodos podem atrapalhar o fluxo de caixa e acarretar uma redução dos lucros com excessivas demarcações. Para resolver este problema, utiliza-se o Open to Buy, onde o varejista pode ter a certeza de estar armazenando a quantidade certa de suas mercadorias (WATERS, 2009, tradução nossa). Tudo começa com o planejamento de compras, mas, à medida que o tempo passa, o Open to Buy torna-se o método pelo qual o comprador acompanha o desempenho efetivo com relação ao que foi planejado e se ajusta conforme as condições do mercado. O Open to Buy nada mais é do que as mercadorias necessárias menos as mercadorias disponíveis, incluindo o que já foi pedido (THEOBALD, 2000, p. 169, tradução nossa). O Open to Buy está diretamente ligado às mercadorias do ramo de varejo. Ele está estruturado especificamente para atender as necessidades dos varejistas. É uma ferramenta desenhada para ajudar os varejistas a gerir e reabastecer os estoques (HURLBUT, 2006, tradução nossa). Open to Buy é um orçamento, começa com o processo de planejamento, orientando os processos futuros, fornecendo informações sobre o quanto comprar, bem como pontos de referência para avaliar os progressos e ajustar os planejamentos futuros (HURLBUT, 2006, tradução nossa). Embora possa ser utilizado, o Open to Buy não é adequado para todas as categorias de mercadorias, para mercadorias com um ciclo de vida longo, as ferramentas de reposição

31 31 automática são mais sugeridas. O Open to Buy é muito adequado para o ramo de moda, onde produtos específicos podem mudar constantemente, no entanto, as suas classificações e subclassificações permanecem relativamente estáveis. É muito adequado também para as mercadorias sazonais, que precisam estar no estoque logo no início da época de vendas e precisam ser gerenciados com um nível pré-determinado, para que não sobrem mercadorias no final da época de vendas (HURLBUT, 2006, tradução nossa). Embora o Open to Buy possa ser aplicado para qualquer período, geralmente este possui aplicação mensal, desta forma, segundo Westerman (2001, p. 261, tradução nossa), o Open to Buy do mês corrente pode ser calculado através da fórmula apresentada no Quadro 5. Estoque planejado para o próximo mês + Vendas planejadas para o mês corrente + Demarcações planejadas para o mês corrente + Retratibilidade planejada para o mês corrente - Estoque atual do mês corrente = Open to Buy para o mês corrente Fonte: Westerman (2001, p. 261, tradução nossa). Quadro 5 Cálculo do Open to Buy para o mês corrente Ainda segundo Westerman (2001, tradução nossa), o Open to Buy dos próximos meses pode ser calculado através da fórmula apresentada no Quadro 6. Compras planejadas para o mês - Pedidos de compras para o mês = Open to Buy para o mês Fonte: Westerman (2001, p. 261, tradução nossa). Quadro 6 Cálculo do Open to Buy dos próximos meses Conforme pode ser observado no Quadro 5, de certa forma, o cálculo do Open to Buy apresentado por Westerman (2001) para o mês corrente, já inclui em sua fórmula a Meta de Compras apresentada por Parente (2000), apenas incrementando a retratibilidade, que são os furtos de mercadorias no estabelecimento e demais formas de perdas de produtos. No cálculo do Open to Buy dos próximos meses apresentado no Quadro 6, as compras planejadas nada mais são do que a Meta de Compras definida através do cálculo apresentado por Parente (2000). O Quadro 7 apresenta um exemplo de controle do Open to Buy.

32 32 Data Valores (R$ mil) Saldo para compras (R$ mil) Estoque planejado final 400 Estoque inicial 430 Previsão de vendas 210 Demarcações previstas 10 1/fev. Meta de compras fevereiro /fev. Mercadorias recebidas em 5/fev /fev. Mercadorias recebidas entre 6 e 20/fev /fev. Pedido colocado em 21/fev /fev. Saldo para compras Open to Buy 15 Fonte: Parente (2000, p. 224). Quadro 7 Exemplo de controle do Open to Buy Um aumento relativamente pequeno nas vendas, muitas vezes, conduz a compras excessivas, e depois, quando as vendas desaceleram, várias demarcações são feitas para eliminar o excesso de mercadorias, que por sua vez, conduz para um menor lucro bruto. Deve-se aprender a utilizar o Open to Buy para comprar de forma mais eficaz, ele requer algum trabalho e muita disciplina, mas vale à pena, pois, contribui para um melhor fluxo de caixa e lucros mais elevados (MATYJEWICZ, 2001, tradução nossa). O Open to Buy mostra quanto de estoque deve-se ter em mãos no início de qualquer mês e como as mercadorias devem ser recebidas durante o mês. Desta forma, pode-se estimar com antecedência o valor financeiro que será necessário para ser investido em estoques de mês para mês, para a próxima época (MATYJEWICZ, 2001, tradução nossa). Por fim, o Open to Buy também ajuda a assegurar o montante adequado de estoque que será necessário para suportar as vendas planejadas, fornecendo o controle dos compromissos para que não se receba as novas mercadorias antes do previsto (MATYJEWICZ, 2001, tradução nossa) Planejamento unitário das compras Para Parente (2000), do ponto de vista da gestão financeira, do fluxo de caixa e da avaliação de indicadores de desempenho, os valores relacionados às vendas, estoques e compras, devem ser expressos em unidades monetárias. Quando se trabalha com agrupamentos de produtos, como departamentos ou categorias, adota-se a unidade monetária, por consistirem um denominador comum

33 33 de unidade de medida. Para produtos individuais, pode-se trabalhar tanto com previsões em unidades monetárias como em unidades físicas (ex.: quilos, litros e quantidades unitárias). (PARENTE, 2000, p. 224). Desta forma, quando se está decidindo sobre o volume de compras de um item específico, a estimativa para o planejamento de compras é desenvolvida com base em unidades físicas. Tem-se ainda que, do ponto de vista da gestão das compras, os produtos podem ser classificados em contínuos e descontínuos, dependendo do tipo de produto, o comprador do varejo deve adotar métodos diferentes de planejamento de compras. Os produtos contínuos são aqueles com um ciclo de vida longo e que tem uma demanda contínua durante muito tempo, como exemplo, pode-se citar os alimentos, produtos de limpeza, perfumaria, eletrodomésticos entre outros. Os produtos descontínuos são aqueles com um ciclo de vida curto, que estão presentes na loja apenas durante certo período de tempo. Como exemplo para estes produtos, pode-se citar os artigos de confecção, que apresentam características de moda e estações do ano e também os produtos que são novidades no mercado, que em muitos casos, atingem bons picos de venda, entretanto, possuem um ciclo de vida muito curto Como comprar bem utilizando o planejamento de compras na visão do SEBRAE O Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) sugere em forma de um instrumento de apoio gerencial, uma séria de regras básicas para comprar bem. Estas regras servem somente como sugestão, sendo que cada empresa pode adaptá-las conforme suas características. Tais informações servem também para evitar os erros mais comuns nas operações de compra, possibilitando desta forma, que a empresa execute o seu planejamento de compras com sucesso. Sendo assim, segundo o SEBRAE (2005), ao se aproximar da época prevista para as compras, as atividades devem seguir uma rotina que pode ser dividida nas seguintes etapas: a) preparar a previsão de vendas; b) ajustar a previsão às possibilidades da empresa; c) decidir o que vai comprar; d) elaborar orçamento para as compras previstas durante um período;

34 34 e) elaborar orçamento de mercadorias por seção; f) efetivar as compras; g) acompanhar os pedidos. A previsão de vendas, geralmente, é realizada para um determinado período, conforme as necessidades de cada empresa. Em muitas empresas, a etapa da previsão está diretamente ligada à área de compras, entretanto, esta não parece ser a melhor solução. Se a etapa da previsão fica por conta do setor de compras, o setor de vendas, maior interessado, entra na elaboração da previsão apenas como um simples informante, não assumindo a responsabilidade por ela. Desta forma, o mais correto é fazer com que a previsão de vendas seja um trabalho conjunto dos setores de compras e de vendas. É aconselhável que se faça uma previsão para cada seção da empresa, estas devem ser consideradas individualmente e, somente mais tarde, reunidas em uma só, para fins de planejamento. De posse da previsão de vendas, a área de compras poderá então estabelecer a relação estoque/venda para atender às vendas previstas. Após preparadas as previsões de vendas, estas devem ser discutidas em reuniões, onde além do empresário, devem participar os gestores dos setores de compras, vendas e financeiro da empresa, sendo que a participação do gestor do departamento financeiro é de vital importância, pois é ele que conhece a real situação financeira da empresa, suas limitações e possibilidades. Mesmo o gestor de vendas apresentando bons argumentos para a compra de uma grande quantidade de determinado produto, somente o gestor do setor financeiro é quem poderá dizer se a empresa terá condições de assumir estes compromissos financeiros. Baseado na previsão de vendas, a área de compras toma a decisão do que realmente irá comprar, considerando o plano de desembolso mensal. A área financeira, por sua vez, irá planejar os desembolsos mensais necessários para as compras, bem como, indicar como e onde buscar se necessários, os recursos para complementar o capital de giro da empresa, este processo deve levar em consideração a relação estoque/venda fornecida pelo setor de compras. O controle financeiro determina um orçamento para a área de compras, para que este possa colocar em prática as aquisições programadas para determinado período. Este orçamento prevê o cronograma dos desembolsos, mês a mês. Após elaborado o orçamento que atende às aquisições de mercadorias previstas para determinado período, é preciso detalhar o orçamento para cada uma das seções da empresa. O orçamento de mercadorias por seção somente poderá ser realizado quando a empresa estiver de posse da previsão de vendas aprovada, do orçamento que vai dispor para o período considerado, do conhecimento das mercadorias necessárias à complementação do estoque e

35 35 quando a mesma souber com precisão, o que será necessário adquirir no que se refere às novidades no mercado. Com estes dados, o gestor da área de compras tem condições de organizar um orçamento de mercadorias para cada uma das seções da empresa, estabelecendo as cotas de compras mensais. Se as etapas anteriores estiverem bem organizadas, a efetivação das compras torna-se uma etapa fácil de ser cumprida, bastando apenas o setor de compras fazer seus pedidos de forma a atender às limitações ditadas pelo cronograma de desembolso mensal. Conforme a área de compras vai efetuando as aquisições, as áreas de vendas e financeiras devem ser informadas sobre as mercadorias e as datas previstas para sua chegada. Além disso, a área financeira deve ser constantemente informada sobre o recebimento e a aceitação das mercadorias compradas e mercadorias que, por algum motivo, foram rejeitadas, bem como os cancelamentos de pedidos que possam ocorrer. O acompanhamento dos pedidos é uma etapa muito importante e é essencial que o gestor de compras acompanhe os pedidos que ainda não foram entregues. O gestor de compras deve constantemente acompanhar os pedidos, a fim de fazer com que não ocorram atrasos nas entregas, pois, caso isto venha a ocorrer o planejamento ficará prejudicado, principalmente o planejamento dos produtos descontínuos (SEBRAE, 2005). 2.4 SISTEMA SAPIENS O Sistema Corporativo Sapiens é um sistema de gestão empresarial desenvolvido pela empresa Senior Sistemas Corporativos, sediada na cidade de Blumenau, no estado de Santa Catarina. A Senior Sistemas também desenvolve soluções para outros segmentos de mercado, os quais se destacam o Vetorh, sistema voltado para o gerenciamento estratégico de recursos humanos (RH) e o Ronda, sistema para controle de acesso e segurança. O ERP Sapiens atende diversos segmentos de negócios nas áreas administrativa, financeira, comercial, industrial, logística e recursos humanos, além de atender a vários outros segmentos específicos. A integração e independência dos módulos do sistema distribuem as informações por toda a estrutura organizacional, permitindo ainda, a integração total com outros sistemas corporativos, como os direcionadores para a área de recursos humanos (SENIOR SISTEMAS, 2009a). Com relação à tecnologia, a parte de aplicação do sistema é totalmente desenvolvida

36 36 para a plataforma Windows, com arquitetura cliente/servidor. Além da arquitetura cliente/servidor, o Sistema Sapiens também pode ser executado em outras formas de aplicação, como uma versão web (funcionalidade parcial do sistema), WindowsAccess (execução em ambiente remoto para desktop Windows), e BrowserAccess (acesso completo ao sistema 100% web) (SENIOR SISTEMAS, 2009b). O Sapiens é composto por um conjunto de módulos integrados que incluem todos os processos empresariais com versatilidade, envolvendo todas as etapas de decisões e produtividade de uma empresa, conforme ilustrado na Figura 1. Fonte: Senior Sistemas (2009c). Figura 1 Divisão dos módulos existentes no Sistema Sapiens O Sistema Sapiens é uma ferramenta ERP moderna, eficiente e flexível, idealizada dentro do conceito toque único, em que um só lançamento no sistema alimenta com informações toda a empresa (SENIOR SISTEMAS, 2009d). A Figura 2 apresenta o menu principal do Sistema Sapiens.

37 37 Figura 2 Menu principal do Sistema Sapiens Conforme pode ser visto na Figura 2, o sistema possui uma divisão de áreas nos menus que podem ser definidos da seguinte forma: a) núcleo de informações gerais: são itens apresentados nos menus Tabelas e Cadastros. As informações cadastradas nestes menus são na maior parte informações de uso comum entre todos os módulos, sendo que no menu Tabelas existe uma divisão de concentração das informações separadas por módulos, e no menu Cadastros todas as demais informações necessárias para o funcionamento das rotinas executadas diariamente em uma empresa. Pode-se desta forma fazer uma analogia, e dizer que estes menus formam o coração do sistema; b) módulos do sistema: são os itens de menus que representam na sua concepção, as grandes áreas de uma organização, são eles: Comercial, Financeiro, Contábil, Produção, Custos, e Sistema de Gestão da Qualidade (SGQ). Estes módulos concentram todas as informações inerentes a estas áreas em uma organização, sendo que existe uma integração total entre as mesmas; c) recursos do sistema: neste item de menu são concentradas uma série de recursos disponibilizados no sistema que facilitam o dia a dia de uma organização. Alguns exemplos destes recursos são: gerador de relatórios (cada empresa pode desenvolver os seus próprios relatórios), gerador de cubos (trabalha com dados no

38 38 formato de matriz, permitindo análises multidimensionais das informações pertinentes a empresa), gerador de telas (cada empresa pode criar seus próprios formulários para cadastramento de informações), além de importação e exportação de dados, regras definidas pelos próprios usuários que permitem que o sistema fique ainda mais aderente aos processos de cada cliente, entre outros; d) diversos: neste item de menu o sistema disponibiliza alguns facilitadores e configurações diversas, tais como: personalização de menus, personalização de barras, configurações de acesso, entre outros Módulo Comercial do Sistema Sapiens O módulo Comercial é um dos principais módulos do sistema. Tem integração com todos os outros módulos, fornecendo e recebendo informações destes. No que se refere ao ramo varejista, segundo o Instituto para Desenvolvimento do Varejo (IDV), a importância deste setor no cenário econômico brasileiro vem sendo cada vez mais reconhecida e destacada. Além de gerador do maior número de empregos formais no país, o setor exibe, especialmente nos últimos quatro anos, números expressivos de crescimento e consistentes indicadores de modernização (IDV, 2009). Na utilização do Sapiens no segmento varejista, a alimentação dos dados do PDV no módulo Comercial é feita através de um sistema de automação comercial integrado com o Sistema Sapiens, este sistema de PDV é desenvolvido pela empresa Megasul Informática, também sediada em Blumenau, Santa Catarina. Esta integração tem o objetivo de atender a área comercial do ramo varejista com o sistema da Megasul trabalhando em pontos de venda utilizando o equipamento Emissor de Cupom Fiscal (ECF), deixando o Sapiens realizar todas as suas atividades de gestão empresarial como um sistema de retaguarda. Desta forma, o Sistema Sapiens é constantemente alimentado com as informações comerciais realizadas nos pontos de venda, sendo assim, o mesmo, juntamente com o sistema da Megasul é comercializado como solução para o ramo de varejo. O Sistema Sapiens como solução para o varejo, traz funcionalidades que auxiliam no gerenciamento de todos os processos comerciais, de crédito, contábeis, de estoque, entre outros. (SENIOR SISTEMAS CORPORATIVOS, 2009). O Sapiens como solução para o varejo permite agilidade no atendimento ao cliente,

39 39 reduzindo filas, gerando segurança no processo de vendas, além de bloqueio de descontos e limites, análise imediata de crédito, transações de Transferência Eletrônica de Fundos (TEF), atendimento à Legislação Fiscal e Tributária e emissão de carnês automaticamente. (SENIOR SISTEMAS CORPORATIVOS, 2009). O módulo Comercial é dividido em três principais sub-módulos, sendo eles: Compras, Vendas e Estoques. Como complemento para o módulo Comercial, este possui ainda os submódulos de Distribuição e Transporte Compras O sub-módulo de Compras está diretamente ligado ao módulo de Estoques no que se refere às requisições de materiais e solicitações de compras, além de ser integrado, também, com o módulo de Contas a Pagar. Este módulo contempla também as etapas de cotação com fornecedores até a entrada da nota fiscal, passando pela atualização dos estoques que é transparente dentro do processo de compras. A Figura 3 apresenta um fluxograma das atividades envolvidas neste módulo. Conforme Senior Sistemas (2009e), as principais funcionalidades deste módulo são: a) administra solicitações de compras, com proposição automática dos preços dos fornecedores nas cotações; b) gera solicitações de compra automaticamente a partir da análise de estoques, via requisição e necessidade de produção; c) possibilita análise entre as condições das ordens de compra e respectivas notas fiscais; d) gera ordens de compra via cotações, automaticamente; e) controla ordens de compra e compradores responsáveis; f) considera opcionalmente as ordens de compra no fluxo de caixa; g) permite envio de automático ao fornecedor com cópia da ordem de compra; h) permite condições flexíveis de pagamento; i) controla o cadastro de fornecedores, incluindo tabelas de preços; j) controla contratos; k) permite gerar cotações de compra via web; l) possibilita controle orçamentário das compras por centro de custo; m) aceita qualquer unidade de medida de produto no recebimento de mercadoria,

40 40 através de conversão automática; n) sugere a melhor cotação, trazendo o valor presente; o) permite a entrada de notas fiscais via códigos de barra; p) controla o processo de entrada e saída de mercadorias através da interface com balanças. Fonte: Senior Sistemas Corporativos (2009). Figura 3 Fluxograma do sub-módulo compras do Sistema Sapiens Ordem de Compra (OC) Segundo Francischini e Gurgel (2002, p. 24), a ordem de compra é, sem dúvida, um importante documento que, por suas diversas vias, permitirá uma amarração geral dos serviços de compra. Para o Sapiens, a Ordem e Compra faz a oficialização junto ao

41 41 fornecedor, nela são calculados os valores totais e líquidos dos produtos/serviços, impostos, frete e seguro. Desta forma, tem-se a visualização prévia dos dados da Nota Fiscal que possivelmente será emitida pelo fornecedor. O Sapiens permite que no momento da negociação com o fornecedor sejam definidos todos os detalhes da compra. Assim, na entrada da Nota Fiscal de Compra, basta indicar as OCs a que a nota se refere e fazer uma conferência com os dados já previamente calculados, desta forma, não é necessária a digitação da mesma, adquirindo agilidade e segurança (SENIOR SISTEMAS, 2009i) Nota Fiscal de Entrada (NFE) A Nota Fiscal de Entrada é o documento que comprova a existência de um ato comercial. O Sapiens permite efetuar a geração de uma Nota Fiscal manualmente ou via confronto e confirmação com as Ordens de Compra previamente negociadas. Uma vez que os dados necessários à composição da Nota Fiscal foram previamente calculados com base na Ordem de Compra, o Sapiens organiza a Nota e as respectivas parcelas de pagamento. Após a finalização da Nota Fiscal de Entrada, que se concretiza com o fechamento da mesma, são atualizados os saldos e movimentação do estoque, títulos a pagar, saldos e dados históricos do fornecedor, situação da própria Ordem de Compra, documentos de requisição, bem como o rateio de valores por contas e centros de custos (SENIOR SISTEMAS, 2009j). A Figura 4 apresenta um exemplo do processo de geração de Nota Fiscal de Entrada via Ordem de Compra no Sistema Sapiens. Pode-se perceber através da figura que em uma Nota Fiscal de Entrada podem estar vinculadas uma ou mais ordens de compra, e que a quantidade do item de produto/serviço não necessariamente precisa ser a mesma da OC, ou seja, pode ser total ou parcial.

42 42 Figura 4 Exemplo de geração de Nota Fiscal de Entrada via Ordem de Compra no Sistema Sapiens Vendas O módulo de Vendas é responsável por administrar os pedidos de venda, bem como efetuar a geração de notas fiscais de saída. Possibilita também faturamentos por pedido, cálculo de comissões via faturamento, além de colocar à disposição dos usuários, informações gerenciais baseadas em estatísticas de vendas. A Figura 5 apresenta um fluxograma das atividades envolvidas neste módulo.

43 43 Fonte: Senior Sistemas Corporativos (2009). Figura 5 Fluxograma do sub-módulo vendas do Sistema Sapiens Conforme Senior Sistemas (2009f), as principais funcionalidades deste módulo são: a) permite entrada de pedidos com produtos configuráveis; b) permite o agendamento de visitas a clientes; c) efetua análise de embarque gerando preparação para faturamento e montando as embalagens para expedição de forma automática; d) possibilita faturamento por pedido, por lote e/ou especiais (produtos e serviços); e) controla pedidos de vendas, orçamentos e previsões de produção; f) considera opcionalmente os pedidos de venda no fluxo de caixa; g) analisa disponibilidades de estoques para vendas; h) reajusta, gera e emite tabelas de preços de venda; i) emite notas fiscais com layout adaptável; j) calcula comissões via faturamento; k) controla crédito, cadastros e históricos de clientes; l) controla representantes, cotas e comissões;

44 44 m) permite condições flexíveis de pagamento; n) mantêm históricos de tabelas de preços de venda de produtos e de serviços; o) rastreia pedidos na produção; p) controla contratos; q) permite entrada de pedidos via web; r) coloca à disposição informações gerenciais baseadas em estatísticas de vendas por região, por representantes e por clientes (SIG Sistema de Informação Gerencial); s) permite a entrada de pedidos e notas fiscais via códigos de barra; t) controla o processo de entrada e saída de mercadorias através da interface com balanças; u) aceita qualquer unidade de medida para venda, por meio de conversão automática Estoques O sub-módulo de Estoques é responsável por atender às requisições de materiais, emitir solicitações de compra para materiais sem saldo em estoque, bem como emitir solicitações de compra de materiais para a produção. Em resumo, seu objetivo é controlar os estoques de uma empresa com toda a movimentação (entrada e saída) de mercadorias que ocorre nos sub-módulos de compras e vendas. A Figura 6 apresenta um fluxograma das atividades envolvidas neste módulo. Conforme Senior Sistemas (2009g), as principais funcionalidades deste módulo são: a) controla estoques de produtos multidepósitos, por lotes, por prazos de validade e por séries; b) possui rotinas de requisição de materiais/serviços, aprovação, atendimento e solicitação de compras; c) calcula preço médio, de custo, de reposição e última entrada; d) possui rotina de inventário com recontagem e acertos automáticos, permitindo também o inventário por lote/série; e) operacionaliza estoques com códigos de barras; f) controla consignações (clientes e fornecedores); g) analisa reposições de estoques; h) gerencia curva ABC; i) gera acúmulos mensais de Consumos, Entradas e Devoluções;

45 45 j) possibilita a formação de embalagens de estocagem; k) possibilita aprovações e requisições via web; l) permite a geração e o controle de numeração de produtos (séries); m) gera solicitações de compra automaticamente a partir da análise de estoques, via requisição e necessidades de produção; n) permite controle de aprovação multinível por valor e centros de custos para ordens de compra e solicitações de compras; o) permite controle de localização através da máscara do código de depósito. Fonte: Senior Sistemas Corporativos (2009). Figura 6 Fluxograma do sub-módulo estoques do Sistema Sapiens Distribuição O sub-módulo de Distribuição tem como objetivos disponibilizar complementos de

46 46 funcionalidades de pedidos do módulo de vendas, bem como processos de carga, acertos e faturamentos. Conforme Senior Sistemas (2009f), as principais funcionalidades deste módulo são: a) forma cargas obedecendo rotas de entrega; b) efetua faturamento conforme cargas geradas; c) permite o acerto de contas no retorno das cargas; d) permite entrada de pedidos via telemarketing ativo ou passivo; e) permite gerar e receber informações de venda via palmtop; f) possibilita o fracionamento dos produtos em estoque; g) efetua ordens de compra com programação de entrega; h) permite inclusão de pendências financeiras na formação da carga Transporte O sub-módulo de Transporte tem como objetivo atender as necessidades de empresas de logística de transporte de mercadorias, realizando processos de coleta de mercadorias, contratação de motoristas, geração de Conhecimento de Transporte Rodoviário de Cargas (CTRC), Manifesto, entre outros. Conforme Senior Sistemas (2009f), as principais funcionalidades deste módulo são: a) controla o cadastro de veículos e motoristas; b) possibilita o cadastramento de tabelas de preço de frete; c) permite o cadastramento de solicitações para coletas de mercadorias, controlando remetente, destinatário e consignatário; d) efetua a cotação de preços para transporte das mercadorias, controlando a disponibilidade do motorista e a rota de entrega que ele atende; e) controla a contratação dos motoristas/veículos que farão o transporte; f) gera o conhecimento de transporte através das coletas cadastradas; g) permite a geração do Manifesto, gerando títulos no Contas a Pagar para o motorista contratado.

47 TRABALHOS CORRELATOS No que diz respeito ao planejamento de compras e aplicação do Open to Buy, existem alguns sistemas de gestão no mercado que desempenham papel semelhante ao proposto por este trabalho, no entanto, poucos trabalhos acadêmicos foram desenvolvidos acerca destes conceitos. A Solução SAP Retail Merchandise and Assortment Planning, mais conhecida como SAP Retail MAP, é uma ferramenta voltada para o varejo, baseada no planejamento de mercadorias e sortimentos. O software é produto da empresa alemã SAP, desenvolvedora de soluções para gestão empresarial. Além das quatro áreas principais, planejamento estratégico, de local, de produtos e de seleção de mercadorias, o SAP Retail MAP também faz interação com o planejamento de redução de preços, otimização da exposição de produtos, gerenciamento de estilo, compras e recursos de alocação, além de fazer integração, entre o planejamento OTB e o sistema de compras. Conforme pode ser visto na Figura 7, o SAP Retail MAP foi concebido para atender aos desafios do complexo setor de varejo, desta forma, diminuindo a distância entre a análise, a simulação, o planejamento e a execução (SAP AG, 2005). Fonte: SAP AG (2005). Figura 7 Planejamento integrado de mercadorias e sortimento na solução SAP Retail MAP

48 48 A Millennium NetWork, empresa brasileira também desenvolvedora de softwares para gestão empresarial, comercializa o Millennium Business Manager (Millennium BM), uma ferramenta ERP voltada para o mercado de vestuário e decoração. O Millennium BM é um sistema modular, flexível, integrável, e que cobre os processos produtivos, administrativos e comerciais de empresas ligadas ao ramo da moda e vestuário (MILLENNIUM NETWORK, 2006a). A metodologia do planejamento de compras da Millennium envolve, também, o planejamento de abastecimento de lojas, diminuição das quebras de estoque e remarcação contínua, incluindo também um modelo parametrizável de Open to Buy (MILLENNIUM NETWORK, 2006b). No meio acadêmico, Santos (2006) apresentou uma dissertação de Mestrado no Programa de Pós-Graduação e Pesquisa em Administração e Economia da Faculdade de Economia e Finanças IBMEC, cujo título é Propostas para Aumento do Desempenho da Área de Compras em Empresa Varejista. Nesta dissertação, a autora realizou um estudo de caso em uma empresa varejista de material de construção, onde foi necessário identificar as principais mudanças ocorridas na área de compras da referida empresa após a entrada da concorrência, em relação aos quatro tópicos estratégicos: planejamento de compras, estrutura organizacional, relacionamento com fornecedores e sistemas de informação, bem como diagnosticar o estágio de evolução da área de compras nesta empresa. No que se refere ao planejamento de compras, a autora faz algumas propostas para aumento do desempenho da área de compras da empresa analisada, fazendo um comparativo entre o planejamento utilizado pela empresa e as propostas apresentadas, elencando os possíveis benefícios da aplicação de suas propostas.

49 49 3 DESENVOLVIMENTO DO MÓDULO DE PLANEJAMENTO DE COMPRAS Neste capítulo são demonstradas as etapas de desenvolvimento do módulo de forma detalhada, tais como, elaboração dos requisitos funcionais e não funcionais, diagramas de casos de uso, diagrama de atividades, diagrama de estados, diagramas de classes, diagrama entidade relacionamento, ferramentas utilizadas, bem como a operacionalidade da implementação e os resultados obtidos acerca do presente trabalho. O módulo de planejamento de compras desenvolvido possui a tarefa de automatizar os processos de planejamento do setor de compras das empresas varejistas, bem como disponibilizar informações sobre o controle de gastos utilizados nos pedidos de compra emitidos pelos compradores através dos saldos disponíveis para compras. As compras podem ser planejadas de acordo com os dados históricos de compras e vendas, permitindo aplicar percentuais de crescimento para geração dos dados do planejamento. O comprador pode considerar em todas as etapas do gerenciamento do seu planejamento, variáveis como: estoque inicial planejado, estoque final planejado, previsões de venda e metas de compra. Com o cálculo do Open to Buy é possível fazer estimativas de compras com grande antecedência e conseqüentemente saber o valor financeiro necessário para ser investido em determinado período. Quando o planejamento elaborado entrar em vigência, o valor das compras será abatido do saldo disponível a cada fechamento de ordem de compra registrada no sistema. Neste contexto, a utilização deste módulo possibilita aos compradores uma melhor utilização do desenvolvimento de estratégias que permitam facilitar a gestão da função compras, evidenciando uma grande melhoria neste processo, permitindo ao gerente de compras cadastrar planejamentos de acordo com a realidade orçamentária da empresa. Durante toda a etapa de vigência do planejamento, é possível acompanhar o andamento do mesmo, visualizando as quantidades já compradas e o saldo disponível para compras. Com a utilização do planejamento de compras no Sistema Sapiens, os compradores podem desenvolver suas funções de forma programada e profissional, visto que outros processos são altamente dependentes desta função em uma empresa. Como instrumento de modelagem do sistema para descrever o módulo, optou-se por trabalhar com a Unified Modeling Language (UML), que segundo Booch, Rumbaugh e Jacobson (2000), é uma linguagem-padrão para elaboração da estrutura de projetos de software.

50 REQUISITOS Os requisitos descrevem as funcionalidades e características que o sistema deve apresentar. Para tanto, a seguir estão listados os requisitos do módulo desenvolvido, divididos em requisitos funcionais (RF) e requisitos não funcionais (RNF) Requisitos funcionais O Quadro 8 apresenta os requisitos funcionais atendidos pelo módulo de planejamento de compras e sua rastreabilidade, ou seja, vinculação com os casos de uso associados que são posteriormente apresentados. Requisitos Funcionais (RF) Caso de Uso RF01: O sistema deverá permitir ao gerente de compras projetar o saldo UC01 disponível para compras (OTB) para determinado período. RF02: O sistema deverá permitir ao gerente de compras gerenciar o cadastro UC02 de planejamentos de compras. RF03: O sistema deverá permitir a geração dos planejamentos com base no UC03 histórico de compras ou vendas. RF04: O sistema deverá permitir ao comprador efetuar a atualização dos UC04 saldos disponíveis para compras através do fechamento de ordens de compra lançadas no sistema. RF05: O sistema deverá permitir a visualização do andamento dos UC05 planejamentos de compras. RF06: O sistema deverá permitir ao comprador consultar as quantidades já UC06 compradas. RF07: O sistema deverá permitir ao comprador consultar os saldos disponíveis UC07 para compras. RF08: O sistema deverá permitir ao comprador a visualização do desempenho UC08 do planejamento com relação às vendas. RF09: O sistema deverá permitir ao comprador emitir relatório resumido dos UC09

51 51 planejamentos de compras. RF10: O sistema deverá permitir ao comprador emitir relatório detalhado dos planejamentos de compras. Quadro 8 Requisitos funcionais UC Requisitos não funcionais O Quadro 9 apresenta os requisitos não funcionais atendidos pelo sistema. Requisitos Não Funcionais (RNF) RNF01: O sistema deverá ser implementado utilizando o ambiente de desenvolvimento Delphi e a Biblioteca de Componentes Visuais da Senior Sistemas. RNF02: O sistema deverá utilizar um dos SGBDs homologados pela Senior Sistemas Corporativos (Oracle, Sybase Server, Sybase SQL Anywhere, MS SQL Server ou DB2). RNF03: O sistema deverá rodar em arquitetura cliente/servidor, ambiente remoto, e acesso web, através das formas de acesso disponibilizadas pela Senior Sistemas. Quadro 9 Requisitos não funcionais 3.2 ESPECIFICAÇÃO Neste item são apresentadas as especificações dos diagramas de casos de uso, diagramas de classes, diagrama de estados e diagrama de atividades, bem como a especificação do diagrama entidade relacionamento. Para a elaboração dos diagramas de casos de uso, de classes, de estados e de atividades, utilizou-se a ferramenta Enterprise Architect (EA), já para a elaboração do diagrama entidade relacionamento foi utilizada a ferramenta MySql Workbench.

52 Diagramas de Casos de Uso Os casos de uso têm como função representar as principais funcionalidades que se pode observar em um sistema e dos elementos externos que interagem com o mesmo (BEZERRA, 2002). A seguir são apresentados os diagramas de casos de uso modelados na fase de especificação do módulo de planejamento de compras Diagrama de Casos de Uso do Gerente de Compras O gerente de compras é a pessoa responsável pelo cadastramento dos planejamentos que envolvem as projeções de saldo a serem utilizados, bem como a possibilidade de utilização do histórico para geração destes planejamentos. Na Figura 8, é ilustrado o diagrama de casos de uso do módulo desenvolvido no sistema disponível ao gerente de compras. Figura 8 Diagrama de casos de uso gerente de compras A seguir é fornecida uma breve descrição para os casos de uso do gerente de compras: a) projetar saldo disponível para compras para determinado período: permite que o

53 53 gerente de compras calcule o Open to Buy para o período de vigência de um planejamento de compras; b) cadastrar planejamento de compras: permite que o gerente de compras cadastre o planejamento a ser utilizado em determinado período de vigência, informando os dados gerais do planejamento, permitindo definir a maneira como o planejamento irá se comportar durante o seu período de vigência, bem como informar os itens que farão parte do planejamento; c) efetuar planejamento com base no histórico de compras ou vendas: permite que o gerente de compras utilize dados históricos de compras ou vendas para sugestão automática de quebras de valores por período na geração do planejamento. Permite que seja utilizado o histórico de ordens de compra, notas fiscais de entrada, notas fiscais de saída e pedidos, bem como utilizar filtros para a busca dos dados históricos Diagrama de Casos de Uso do Comprador Os compradores são subordinados ao gerente de compras, eles são responsáveis por efetuar as compras com os fornecedores, ficando limitados aos saldos disponíveis para compras estipulados pelo gerente. Na Figura 9, é ilustrado o diagrama de casos de uso do módulo desenvolvido no sistema disponível aos compradores.

54 54 Figura 9 Diagrama de casos de uso comprador Como se pode observar na Figura 9, além das permissões apresentadas no diagrama de casos de uso gerente de compras, o gerente também podem realizar todas as atividades comuns entre os compradores a ele subordinado. A seguir é fornecida uma breve descrição para os casos de uso do comprador: a) efetuar fechamento de ordens de compra: permite que o comprador efetive o pedido de compra com o fornecedor através da ordem de compra, onde neste momento serão atualizados os saldos disponíveis para compras; b) visualizar andamento do planejamento de compras: permite que o comprador a qualquer momento faça consultas para obter detalhes sobre o respectivo planejamento. Permite que sejam visualizadas informações inerentes aos dados gerais do planejamento, bem como informações dos itens que fazem parte do planejamento; c) consultar quantidades já compradas: permite ao comprador consultar as notas fiscais já fechadas para saber quais compras já foram realmente efetivadas; d) consultar saldos disponíveis para compras: permite ao comprador obter informações detalhadas acerca dos saldos que ainda possui disponíveis para

55 55 comprar; e) visualizar desempenho do planejamento com relação às vendas: permite que o comprador visualize os dados do planejamento confrontando-os com os dados das vendas efetuadas. Estes dados referem-se às quantidades e valores envolvidos no planejamento, nas compras (notas fiscais) e nas vendas (notas fiscais) do item planejado; f) emitir relatório resumido do planejamento de compras: permite que o comprador efetue a emissão de um relatório resumido dos planejamentos gravados no sistema, a fim de obter apenas algumas das informações mais importantes dos mesmos, como informações inerentes aos dados gerais e totalizadores de valores e saldos; g) emitir relatório detalhado do planejamento de compras: permite que o comprador efetue a emissão de um relatório detalhado dos planejamentos gravados no sistema, a fim de obter todas as informações importantes dos mesmos, como informações inerentes aos dados gerais, informações dos itens, bem como totalizadores de valores e saldos Diagramas de Classes Os diagramas de classes expressam a estrutura estática de um sistema e a possibilidade de interações entre as classes (TONSIG, 2003). Segundo Guedes (2004), seu principal enfoque é permitir a visualização das classes que irão compor o sistema com os respectivos métodos e atributos. Cada classe do diagrama costuma possuir atributos, que guardam dados dos objetos da classe e os métodos, que são funções que uma instância da classe pode executar. Como são muitas as classes necessárias para o desenvolvimento do módulo de planejamento de compras, elas estão reunidas, de acordo com as ligações lógicas entre si, em pacotes, conforme apresentado na Figura 10.

56 56 Figura 10 Pacotes do módulo de planejamento de compras Pacote ObjetosPlanejamento O primeiro pacote é denominado ObjetosPlanejamento e contém classes relativas à implementação das regras de negócio e demais tratamentos envolvidos na criação de um planejamento de compras. Conforme pode ser visto na Figura 11, fazem parte deste pacote as seguintes classes: a) TPlanejamento: classe que implementa todos os métodos e atributos necessários para a criação e manipulação dos dados gerais do planejamento de compras, bem como as regras de negócio a ele associadas; b) TItemPlanejamento: classe que implementa todos os métodos e atributos necessários para a criação de um item de planejamento de compras, bem como as regras de negócio associadas ao mesmo. Segundo Braude (2005, p. 88), mostrar mais detalhes do que o necessário pode tornar um diagrama confuso e mais difícil de entender, neste contexto, o pacote ObjetosPlanejamento apresenta apenas os atributos e métodos mais importantes de cada classe, com o objetivo de não poluir o diagrama.

57 57 cd ObjetosPlanejamento + fcodemp: int + fcodfil: int + fnumpla: long + fcodusu: long + fdespla: string + ftipprg: EnumTipPrg + fblocpr: char + ftipper: ENumTipPrd + fblocpg: EnumCriBlo + fsitpla: ENumSitReg + finivig: date + ffimvig: date + fdatcad: date + fdatalt: date + fvlrbru: double + fvlrliq: double + fqtditp: double + fvlrlit: long + ftipctl: char + SldTot: double + UtiTot: double + OtbTot: double + estado: TEstado + gravado: boolean TPlanej amento + Create() + Destroy() - SetFCodEmp(int) - SetFCodFil(int) - SetFNumPla(long) - SetFCodUsu(long) - SetFDesPla(string) - SetFTipPrg(char) - SetFTipPer(char) - SetFBloCpr(char) - SetFBloCpg(char) - SetFSitPla(char) - SetFIniVig(date) - SetFFimVig(date) - SetFDatCad(date) - SetFDatAlt(date) - SetFTipCtl(char) + Carrega() : boolean + Init() + IniciaLeituraItens() + CriaItemPlanejamento(long) : long + DestroiItemPlanejamento() + RetornaPrimeiroItemPlanejamento() : TItemPlanejamento + RetornaProximoItemPlanejamento() : TItemPlanejamento + PosicionaItemPlanejamento(long) + RetornaPonteiroItem() : Pointer + CalculaValoresItemPlanejamento(TRecalc, DadosItemPlanej, boolean) + AcumulaValores() + Diminuivalores() + Altera() + Grava() + AlteraItem() + GravaItem() + AlteraNumeroPlanejamentoItens() + AtualizaLiquido() + ExcluiPlanejamento(boolean) + ExcluiItensPlanejamento() + BuscaPlanejamentoAtivo() : long + CalculaVlrLit() : double + CalculaSldTot() : double + CalculaUtiTot() : double + CalculaOtbTot() : double 1 1..* + fcodemp: int + fcodfil: int + fnumpla: long + fseqpla: long + fcodori: string + fcodfam: string + fcodpro: string + fcodagp: string + fqtdpla: double + fcodcpg: string + fdatini: date + fdatfim: date + fpercre: double + fvlrbru: double + fvlrcre: double + fvlrliq: double + fsldite: double + fotbite: double + fvlruti: double + fqtddpr: double + fqtduti: double + fqtddis: double + estado: TEstado TItemPlanej amento + Create(TObject, int, int, long, long) + CreateCarrega(TObject, int, int, long, long) + Destroy() + Grava() + Altera() + CriaCustom() + CalculaValores(boolean) + CalculaItemPlanejamento(DadosItemPlanej) Figura 11 Pacote ObjetosPlanejamento

58 Pacote InterfacesPlanejamento O segundo pacote é denominado InterfacesPlanejamento e contém classes relativas à implementação das interfaces disponibilizadas ao usuário para manipulação do planejamento de compras e seus itens. Conforme pode ser visto na Figura 12, como recursos relativos à implementação das interfaces do usuário, têm-se as seguintes classes: a) Frm_CadastraPlanejamento: classe que implementa a tela de cadastro de planejamento de compras. Ela permite a criação de uma instância de planejamento, bem como instâncias de itens do planejamento, além de disponibilizar vários outros métodos que auxiliam na manipulação do planejamento de compras; b) Frm_CalculaOTB: classe que implementa a tela de cálculo do Open to Buy para que o gerente de compras possa incluir os itens que irão compor o planejamento de forma consciente, sabendo o valor disponibilizado através da fórmula existente no conceito de Open to Buy; c) Frm_BasePlanejamento: classe que implementa a tela de base para geração do planejamento. Esta classe disponibiliza os métodos necessários para a manipulação dos dados históricos de compras e vendas que poderão ser utilizados ou não pelo gerente para geração do planejamento; d) Frm_ConsultaPlanejamento: classe que implementa a tela de consulta de planejamentos de compras; e) Frm_ConsultaSaldosDisponiveis: classe que implementa a tela de consulta de saldos disponíveis nos planejamentos de compras, onde é possível visualizar os saldos dos itens de forma agrupada e detalhada; f) Frm_ConsultaQtdsVlrsUtilizados: classe que implementa a tela de consulta de quantidades e valores efetivamente já utilizados, através da consulta de notas fiscais inerentes ao planejamento de compras; g) Frm_ConsultaDesempRelacaoVendas: classe que implementa a tela de consulta de desempenho com relação às vendas. Esta classe disponibiliza os métodos necessários para que a interface possa dispor ao usuário os dados dos planejamentos e das vendas efetuadas de forma agrupada e detalhada.

59 59 cd InterfacesPlanejamento Frm_CadastraPlanej amento + planejamento: TPlanejamento + itemplanejamento: TItemPlanejamento + regitem: TRegItem - codigoitemanterior: string - Create() - Destroy() - LimpaCampos() - DesabilitaCamposCabecalho() - PosicionaPrimeiroCampoGrid() - Processar() - Excluir() - Cancelar() - ConsisteCamposCabecalho() - ConsisteGeraisLinhaGrid() - SetaCorLabelSituacao() - AtualizaLBPlanejamentoAtivo() - HabilitaDesabilitaBtAtivarPlanejamento() - HabilitaDesabilitaBtInativarPlanejamento() - CalculaSaldoDisponivelCompras() - EscondeMostraCampos() - AplicaMascarasDatasVigencia() - EhDiaPrimeiroOuDia16(date) : boolean - EhDia15OuUltimoDiaDoMes(date) : boolean - DataMenorQueUltimoDiaDaQuinzena(date, date) : boolean - RetornaDataFinalQuinzena(date) : date - RetornaDataDecimoSextoDiaMes(date) : date - RetornaDataPrimeiroDiaMes(date) : date - RetornaDataUltimoDiaMes(date) : date - ExisteVinculoItemPlanejamentoComOrdensDeCompra(long, long) : boolean - BuscaValorJaUtilizadoParaCompras(int, int, long, long) : double - BuscaQuantidadeJaUtilizadaParaCompras(int, int, long, long) : double Frm_ConsultaPlanej amento - regpla: TRegPla - regite: TRegIte - Create() - Destroy() - Mostrar() - Cancelar() - LimpaCampos() - HabilitaDesabilitaBotoesConsulta() - ConsultaOrigem() - ConsultaFamilia() - ConsultaProduto() - ConsultaAgrupamentoProduto() - ConsultaProdutoDerivacao() - EscondeMostraCampos() - ConsultaNFEsPlanejamento() 1 1 Frm_CalculaOTB - Create() - Calcular() - Cancelar() - LimpaCampos() - HabilitaDesabilitaCampos(char) Frm_ConsultaQtdsVlrsUtilizados - regnfc: TRegNfc - regipc: TRegIpc - Create() - Destroy() - Mostrar() - Cancelar() - LimpaCampos() - HabilitaBotoesConsulta() - MostrarTotais() - ConsultaOrdem() - ConsultaItensOC() - ConsultaInfFornecedor() 1 - regagr: TRegAgr - regdet: TRegDet Frm_BasePlanej amento - Create() - Destroy() - Marcar() - Desmarcar() - Cancelar() - Mostrar() - Processar() - LimpaCampos() - HabilitaDesabilitaCabecalho(boolean) - EscondeMostraCampos() - HabilitaDesabilitaClienteFornecedor() - HabilitaDesabilitaBotoesConsulta() - AplicaMascarasDatasVigencia() - RetornaProximoDomingoDaSemana(date) : date - RetornaProximoSabadoDaSemana(date) : date - DataEhSabado(date) : date - RetornaInicioProximaQuinzena(date) : date - RetornaFimProximaQuinzena(date) : date 1 Frm_ConsultaDesempRelacaoVendas - regagr: TRegAgr - regdet: TRegDet - Create() - Destroy() - Mostrar() - Cancelar() - LimpaCampos() - HabilitaBotoesConsulta() - ConsultaOrigem() - ConsultaFamilia() - ConsultaProduto() - ConsultaProdutoDerivacao() - ConsultaAgrupamentoProduto() Frm_ConsultaSaldosDisponiv eis - regagr: TRegAgr - regdet: TRegDet - Create() - Destroy() - Mostrar() - Cancelar() - LimpaCampos() - HabilitaBotoesConsulta() - ConsultaOrigem() - ConsultaFamilia() - ConsultaProduto() - ConsultaProdutoDerivacao() - ConsultaAgrupamentoProduto() - MostrarTotais() Figura 12 Pacote InterfacesPlanejamento

60 Pacote AuxiliaresPlanejamento O terceiro pacote é denominado AuxiliaresPlanejamento e contém classes já existentes no sistema, que tiveram novos métodos implementados ou que sofreram alterações em alguns métodos para contemplar as regras de negócio do planejamento de compras, bem como contém também algumas enumerações utilizadas no planejamento. Conforme pode ser visto na Figura 13, fazem parte deste pacote as seguintes classes e enumerações: a) Frm_CadastraOrdemCompra: classe que implementa a tela de cadastro de ordens de compra. Nesta classe foram adicionados novos métodos para tratamento do vínculo de itens de planejamento de compras com itens de ordens de compra. Foram implementados também métodos para atualização dos saldos disponíveis para compras em diversas situações; b) Frm_CadastraNFEntrada: classe que implementa a tela de cadastro de notas fiscais de entrada. Esta classe sofreu alterações em alguns métodos para que seja possível fazer o vínculo de um item de ordem de compra com um item de nota fiscal de entrada, atribuindo a chave do planejamento à nota, para fins de amarração entre todos os documentos envolvidos no processo de planejamento; c) Frm_ConsultaOCGeracaoNFE: classe que implementa a tela de consulta de ordens de compra a serem processadas para geração da nota fiscal de entrada. Esta classe também sofreu alterações para contemplar o vínculo com o planejamento de compras; d) ENumSitReg: enumeração que define a situação do planejamento de compras, possuindo os possíveis valores: ativo ou inativo; e) ENumTipPrd: enumeração que define o tipo de período a ser considerado no planejamento de compras, possuindo os possíveis valores: semanal, quinzenal ou mensal; f) ENumTipPrg: enumeração que define o tipo da programação de compras efetuada no planejamento, possuindo os possíveis valores: programação por origem, família, produto ou agrupamento de produtos; g) ENumTipCtl: enumeração que define o tipo de controle de saldo do planejamento, possuindo os possíveis valores: quantidade (controle físico), valor (controle financeiro) ou ambos (controle físico e financeiro); h) ENumCriBlo: enumeração que define qual o tipo de bloqueio de compras de

61 61 cd AuxiliaresPlanejamento produtos não planejados e também o tipo de bloqueio de compras com condição de pagamento não planejada no item de produto, possuindo os possíveis valores: libera, avisa ou bloqueia. «enumeration» ENumSitReg «enumeration» EnumTipPrg «enumeration» ENumTipPrd «enumeration» ENumTipCtl «enumeration» EnumCriBlo + ativo: + inativo: + produto: + familia: + origem: + agrupamentoproduto: + semanal: + quinzenal: + mensal: + quantidade: + valor: + ambos: + avisa: + libera: + bloqueia: Frm_CadastraOrdemCompra - regregordemcompra: TRegOrdemCompra - regitemprodutooc: TRegItemProdutoOC - TrataVinculoPlanejamentoComprasItemProduto() - ConsisteCondicaoPgtoPlanejamento(DadosItemPlanej) - BuscaOrigemProduto(int, string) : string - BuscaAgrupamentoComercialProduto(int, string) : string - BuscaDescricaoPlanejamentoCompras(int, int, long) : string - AtualizaOpenToBuyItemPlanejamento_FechamentoItem_AlteracaoValorItemJaFechado(DadosItemOC, DadosItemOCOLD, boolean) - AtualizaOpenToBuyItemPlanejamento_CancelamentoOC(ListaProdutos) - AtualizaOpenToBuyItemPlanejamento_CancelamentoItemJaFechado_ReabilitacaoOC(DadosItemOC) Frm_ConsultaOCGeracaoNFE Classe já existente no sistema, nesta são apresentados apenas os atributos mais importantes e os métodos que foram implementados no desenvolvimento do planejamento de compras. 1 - RegOrdemCompra: TRegOrdemCompra - RegItemProdutoOC: TRegItemProdutoOC - Mostrar() - Processar() Frm_CadastraNFEntrada - RegNotaEntrada: TRegNotaEntrada - RegItemProdutoNFE: TRegItemProdutoNFE - TrataSaidaSequenciaItemProdutoGrid() - ProcessaItens() - CarregaDadosProduto() 1 Classes já existentes no sistema, nestas são apresentados apenas os atributos mais importantes e os métodos que sofreram alterações para contemplar o planejamento de compras. Figura 13 Pacote AuxiliaresPlanejamento

62 Diagrama de Estados Segundo Braude (2005, p. 100), um diagrama de transição de estado mostra os estados dos objetos de uma classe, os eventos aos quais os objetos são sensíveis e as transições resultantes entre eles. A Figura 14 apresenta o diagrama de estados da classe TPlanejamento. Figura 14 Diagrama de estados da classe TPlanejamento No diagrama apresentado na Figura 14, observa-se que o planejamento de compras quando cadastrado, inicia seu estado como inativo, ficando a critério do gerente de compras efetuar sua ativação quando achar necessário. Nota-se ainda, que a ativação do planejamento não indica o uso do mesmo pelos compradores, a sua utilização como ferramenta para controle de saldos somente é feita quando o estado muda para ativo em andamento, o que indica que as datas que estão sendo efetuadas as ordens de compra estão dentro do período de vigência estabelecido pelo gerente de compras.

63 Diagrama de Atividades Um diagrama de atividade descreve o comportamento de um processo ou função através da especificação da sequência de operações e decisões que permitem determinar quando e como elas são realizadas. De maneira geral, consiste numa série de atividades ligadas por transições (SILVA; VIDEIRA, 2005). A Figura 15 apresenta o diagrama de atividades do módulo de planejamento de compras, onde é ilustrado o fluxo de trabalho deste módulo. Observa-se que o diagrama apresentado na Figura 15 faz a simulação de um planejamento que possui a característica de bloquear compras de produtos sem saldo (físico ou financeiro) disponível para tal finalidade, portanto, para poder efetuar o fechamento de uma ordem de compra, ou seja, a concretização de um pedido com determinado fornecedor, é necessário que o item de produto possua saldo disponível para compras. No caso do item não possuir saldo, ou a quantidade ou valor financeiro do mesmo ultrapassar o disponível no planejamento, o comprador deverá entrar em contato com o gerente, a fim de conseguir um aumento do saldo disponibilizado inicialmente.

64 Figura 15 Diagrama de atividades do planejamento de compras 64

65 Diagrama Entidade Relacionamento Para Rezende (2005, p. 174), a notação fundamental para a modelagem de dados é o diagrama entidade relacionamento. Segundo o autor, o principal propósito deste diagrama é representar os objetos de dados e suas relações, sendo que cada entidade termina representada por pelo menos uma tabela de dados. O diagrama entidade relacionamento do módulo desenvolvido no presente trabalho é apresentado na Figura 16, o mesmo foi elaborado utilizando-se a notação Crows Foot. Um ponto a ser observado no diagrama entidade relacionamento da Figura 16, é que, não foi preciso criar todas as tabelas apresentadas no diagrama. Foram criadas apenas as tabelas PLANEJCOMPRAS (armazenamento dos dados gerais do planejamento de compras) e ITENSPLANEJAMENTO (armazenamento dos itens do planejamento), isto porque o planejamento de compras usufrui também de outras tabelas já existentes no Sistema Sapiens. As tabelas ITENSPROOC (itens de produto de ordem de compra) e ITENSPRONFE (itens de produto de nota fiscal de entrada) sofreram alterações para armazenar a chave do item de planejamento que estará vinculado ao item de produto destas tabelas. Outro ponto a ser observado é que um item de produto de ordem de compra pode ser utilizado em mais de um item de nota fiscal de entrada, porém somente em notas fiscais diferentes. Esta observação se faz necessária, pois, se fizéssemos um relacionamento um para um nestas tabelas, entenderíamos que um item de ordem de compra só poderia estar presente em um único item de nota fiscal de entrada, seja ela qual for, o que não é verdade. No diagrama da Figura 16, foram apresentadas somente as tabelas que possuem algum vínculo direto com o planejamento, a fim de não poluir o diagrama. O modelo de dados de todo o sistema pode ser considerado de alta complexidade, isto se justifica pelo grande volume de tabelas existentes, atualmente, são mais de 1200 tabelas. O grande número de tabelas existentes ocorre devido à necessidade de o sistema precisar se adaptar a vários tipos de mercado, bem como uma série de outros controles necessários para a realização de diversos processos. No Apêndice A, encontram-se as definições das tabelas e campos envolvidos no desenvolvimento do módulo de planejamento de compras.

66 66 Figura 16 Diagrama entidade relacionamento 3.3 IMPLEMENTAÇÃO Neste item referente à implementação são descritas as técnicas e ferramentas utilizadas no desenvolvimento do módulo de planejamento de compras, bem como é apresentada também a operacionalidade da implementação.

67 Técnicas e ferramentas utilizadas Nesta seção são apresentadas as técnicas e ferramentas utilizadas para a implementação do módulo desenvolvido no sistema, tais como: Borland Delphi, Sybase SQL Anywhere (SGBD), Central de Banco de Dados Senior (CBDS) e Gerador de Relatórios Sapiens. O módulo de planejamento de compras foi implementado na linguagem Object Pascal, utilizando o ambiente de desenvolvimento Delphi 5 e a Senior Visual Component Library (SVCL), que é uma Biblioteca de Componentes Visuais desenvolvida por uma equipe de tecnologia da Senior Sistemas utilizada no desenvolvimento de seus produtos. O Delphi 5 está dividido em três versões, que foram projetadas de modo a se adaptar a uma série de diferentes necessidades: Delphi 5 Standard, Delphi 5 Professional e Delphi 5 Enterprise. Cada uma dessas versões é indicada para um tipo diferente de programador. O Delphi 5 Enterprise foi a versão utilizada no desenvolvimento do módulo de planejamento de compras, ela se destina a programadores que trabalham em ambiente cliente/servidor de grandes corporações, incluindo tudo o que está disponível nas duas outras edições do Delphi 5, além de uma série de outros recursos (TEIXEIRA; PACHECO, 2000, p. 4). O Sybase SQL Anywhere é um pacote abrangente que fornece tecnologias de gerenciamento e de troca de dados, que possibilitam rápido desenvolvimento e implementação de aplicativos ativados por banco de dados. Este pacote oferece bancos de dados de nível corporativo, que se adaptam tanto a servidores de 64 bits com milhares de usuários quanto a pequenos dispositivos portáteis. As tecnologias de troca de dados do SQL Anywhere estendem as informações dos aplicativos e sistemas corporativos a bancos de dados executados em ambientes de linha de frente de missão crítica. As ferramentas de design e de gerenciamento do SQL Anywhere permitem que os desenvolvedores implementem e usem aplicativos de linha de frente e habilitem os administradores a gerenciar e oferecer suporte aos desenvolvedores com grande facilidade (SYBASE, 2009). Apesar de o Sistema Sapiens estar homologado para ser utilizado em diversos Sistemas Gerenciadores de Banco de Dados (SGBDs), o Sybase SQL Anywhere na sua versão foi o SGBD utilizado durante todo o período de desenvolvimento do módulo de planejamento de compras, sendo que ainda como etapa de validação final, o módulo foi testado em todos os outros SGBDs já mencionados, homologados pela Senior Sistemas Corporativos.

68 Central de Banco de Dados Senior (CBDS) Conforme Senior Sistemas (2009h), a Central de Banco de Dados Senior (CBDS) é uma ferramenta desenvolvida pela Senior utilizada na linha de frente para a customização dos sistemas no atendimento aos requisitos dos clientes. Entre os diversos recursos disponíveis nesta ferramenta, destacam-se os seguintes itens: a) manutenção e criação de novas tabelas, campos, índices, stored procedures e usuários; b) backup e restore de base de dados de diferentes SGBDs; c) engenharia reversa; d) configurações de armazenamento; e) permissão e monitoramento de tabelas e campos; f) editor de SQL; g) consistência de bases de dados; h) diversos relatórios referentes à base de dados; A Figura 17 apresenta a interface do CBDS. Figura 17 Interface da ferramenta CBDS

69 Gerador de Relatórios Sapiens O gerador de relatórios é uma ferramenta adicional dos sistemas da Senior que possibilita a adaptação e criação de relatórios gráficos por parte dos usuários para atender as suas necessidades (SENIOR SISTEMAS, 2004). Cada relatório criado no sistema é denominado modelo, sendo que cada um destes modelos possuem uma categoria que indica qual o módulo ou processo do sistema o mesmo está relacionado. Ao criar um modelo, é gerado um arquivo criptografado que somente pode ser interpretado pelos sistemas da Senior. A Figura 18 apresenta a interface do gerador de relatórios no Sistema Sapiens. Figura 18 Interface do gerador de relatórios do Sistema Sapiens Operacionalidade da implementação O módulo de Planejamento de Compras desenvolvido no ERP Sapiens tem por

70 70 objetivo automatizar e gerenciar todo o processo de programação de compras efetuadas pelo gerente desta respectiva área, em um determinado período. Para tanto, o gerente poderá cadastrar um planejamento informando suas características de funcionamento e quais mercadorias irão fazer parte deste planejamento, bem como seus limites de compra, tanto físico quanto financeiro. Conforme pode ser visto na Figura 19, no módulo Comercial do sistema é disponibilizado um menu contendo a tela de cadastro de planejamentos e as telas de consultas inerentes aos mesmos. Para as consultas são apresentadas as seguintes telas: consulta de planejamentos, consulta de quantidades e valores já utilizados para compras (notas fiscais de entrada), consulta de saldos disponíveis para compras e consulta de desempenho do planejamento com relação às vendas. Figura 19 Menu do módulo de planejamento de compras Além da tela de cadastro e telas de consultas, são disponibilizados também através do caminho Comercial > Relatórios Gerais, dois relatórios de planejamentos de compras, sendo um relatório resumido e outro detalhado, conforme pode ser visto na Figura 20.

71 71 Figura 20 Tela de seleção dos relatórios gerais do módulo Comercial Antes de iniciar o processo de planejamento de compras, o administrador do sistema deve informar às pessoas que terão acesso a tela de cadastro de planejamentos. Esta tela pode ser considerada o coração do módulo de planejamento de compras, pois, é através dela que são feitas as manutenções dos saldos de compras quando necessário, ou seja, o aumento do saldo disponível quando este não for mais suficiente para que as compras possam ser realizadas com os fornecedores. A permissão ou não permissão de acesso para determinada tela do sistema é feita através de um recurso já existente no Sistema Sapiens, conforme pode ser visto na Figura 21. Figura 21 Tela de permissões de acesso do Sistema Sapiens

72 72 Conforme apresentado na Figura 21, no caso do planejamento de compras, o único usuário com acesso a tela de cadastro de planejamentos deve ser o gerente de compras, para tanto, o administrador do sistema deve liberar acesso para o gerente de compras e negar acesso para todos os demais usuários. Desta forma, a tela de cadastro somente ficará visível no menu do sistema para o usuário com tal permissão de acesso, ou seja, o gerente de compras. Este critério é adotado apenas para a tela de cadastro, sendo que não existe nenhuma restrição para as telas de consulta, porém, este critério pode variar de empresa para empresa, ou, de filial para filial. Após a configuração de permissão de acesso, o sistema estará apto a trabalhar com planejamentos de compras. A seguir, são apresentadas as telas implementadas no sistema com o objetivo de ilustrar a operacionalidade do módulo desenvolvido, sendo que, no Apêndice B encontram-se os métodos de maior relevância de algumas das classes implementadas no desenvolvimento deste módulo Tela de Cadastro de Planejamentos de Compras Através da tela de cadastros de planejamentos, o gerente de compras pode cadastrar os mesmos, bem como efetuar manutenções quando for necessário. Através da mesma também é possível fazer um acompanhamento, visualizando o andamento do planejamento durante todo o seu período de vigência. A Figura 22 apresenta a tela de cadastro de planejamentos de compras quando iniciada.

73 73 Figura 22 Tela de cadastro de planejamentos de compras O primeiro passo para a criação de um planejamento é definir a descrição do mesmo, sendo que, para o número do planejamento o sistema atribui um número seqüencial. A descrição do planejamento deve ser elaborada de forma que sua leitura seja de fácil compreensão, pois ela aparecerá nas demais etapas do planejamento de compras. O próximo campo a ser informado é o Tipo de Período a ser considerado para o planejamento, além de servir como controle no momento da informação do período de vigência, este campo é responsável também por definir as quebras de datas de previsão de entregas das mercadorias quando utilizado a tela de base para geração do planejamento. Os valores disponíveis para o campo Tipo de Período são: Semanal, Quinzenal e Mensal. O planejamento inicia seu estado como inativo e após o efetivo cadastro através do botão Processar, caso não exista nenhum planejamento ativo no momento, o sistema questiona ao gerente se o mesmo deseja ativá-lo. Caso a decisão seja não ativar o planejamento, o mesmo poderá ser ativado posteriormente quando for conveniente, ou quando chegar ao período de vigência do planejamento. O sistema não permite trabalhar com mais de um planejamento ativo ao mesmo tempo, então, para ativar um planejamento de compras, o

74 74 planejamento anterior, caso exista, deverá ser inativado. O próximo campo a ser informado é o indicativo se o planejamento deve bloquear compras de produtos não planejados. Os seguintes valores estão disponíveis para este campo: a) libera: na geração de ordens de compra, quando o comprador informar um produto que não consta no planejamento, o sistema não fará nenhuma consistência com relação ao bloqueio da compra deste produto; b) avisa: esta opção indica que na geração de ordens de compra, quando o comprador informar um produto que não consta no planejamento, o sistema não bloqueará a compra deste produto, porém, irá alertar o comprador de tal situação; c) bloqueia: esta opção indica que na geração de ordens de compra, quando o comprador informar um produto que não consta no planejamento, o sistema não permitirá a sua utilização, informando que o item não está disponível para compras no planejamento de compras. Semelhante ao campo anteriormente mencionado, também está disponível no planejamento o indicativo se o planejamento deve bloquear compras de produtos com condição de pagamento não planejada. Este campo segue o mesmo critério do campo anterior, porém a consistência na ordem de compra é feita com uma informação dos dados gerais da ordem, e não dos itens, neste caso, a condição de pagamento. O período de vigência é uma das informações mais importantes do planejamento, além de definir o período que o mesmo será executado, ele define também as consistências dos períodos de previsão de entrega dos itens, de forma que estas previsões somente possam ser planejadas dentro do período informado no cabeçalho do planejamento. O próximo campo a ser informado é o indicativo se o planejamento efetua o controle de saldos de forma física ou financeira. Os seguintes valores estão disponíveis para este campo: a) quantidade (controle físico): indica que o sistema irá efetuar o abatimento apenas nos saldos de quantidades dos itens planejados; b) valor (controle financeiro): indica que o sistema irá efetuar o abatimento somente nos saldos de valores dos itens planejados, ou seja, irá controlar o Open to Buy; c) ambos (controle físico e financeiro): esta opção indica que o sistema efetuará tanto o controle de saldo físico quanto financeiro. Após informado o tipo de controle de saldo, deve-se informar o tipo de programação de compras que será efetuado no planejamento. Estão disponíveis as opções: origem, família, produto e agrupamento de produtos comerciais. Estas opções seguem a hierarquia do cadastro

75 75 de produtos existente no Sistema Sapiens, sendo que a única opção não disponível no planejamento é a derivação de um produto. A derivação de um produto no Sistema Sapiens não foi implementada no planejamento por ser uma categoria de um baixo nível muito expressivo para o ramo de varejo, o que na maioria dos casos inviabiliza o planejamento das compras, sendo que, o mais adequado seria trabalhar com a programação de produtos ao invés de derivações. A Figura 23 ilustra um exemplo de hierarquia de produtos existente no Sistema Sapiens. produtos. Figura 23 Exemplo de hierarquia de produtos existente no Sistema Sapiens A Figura 24 ilustra um exemplo de hierarquia de produtos utilizando agrupamento de Figura 24 Exemplo de hierarquia de produtos utilizando agrupamento de produtos Além dos campos já mencionados, o planejamento de compras armazena também o código do usuário responsável pelo cadastro, ou seja, o gerente de compras, bem como a data de cadastro e a data de alteração, que será alimentada sempre que for efetuada alguma manutenção no planejamento. Um ponto a ser observado, é que, dependendo do tipo de período informado, o planejamento se comporta de forma diferente com relação às datas do período de vigência, como exemplo, têm-se a alteração das máscaras destes campos quando utilizado o tipo de período mensal, para se trabalhar apenas com mês e ano nas datas de vigência. Diversas

76 76 consistências são feitas com relação às datas do período de vigência, como exemplo, pode-se citar o período quinzenal. Entende-se que em um mês existem apenas duas quinzenas, e que para o comércio, a primeira quinzena inicia no 1 dia do mês, indo até a metade do respectivo mês, ou seja, o 15 dia. A segunda quinzena inicia-se logo após o término da primeira, ou seja, no 16 dia, indo até o último dia do mês. Neste sentido, são necessárias algumas consistências no planejamento. Um exemplo pode ser visto na mensagem emitida ao usuário conforme demonstrado na Figura 25. Figura 25 Mensagem de aviso para escolha correta do início de uma quinzena No exemplo da Figura 25, o gerente de compras está no mês de junho de 2009, planejando as suas compras para os próximos três meses, ao informar uma data qualquer do mês de julho que não seja dia 1 ou 16, o sistema sugere as possíveis datas para o início do período de vigência do planejamento. Ainda utilizando a quinzena como exemplo, caso o gerente optar por fazer o planejamento para apenas uma quinzena, informando uma data final para o período onde esta seja menor que o último dia da referida quinzena, o sistema questiona ao usuário se o mesmo deseja aplicar a única data possível, conforme apresentado na Figura 26. Figura 26 Mensagem de confirmação para aplicação correta da data final da quinzena Outra consistência feita com relação às datas do período de vigência, é que, a data inicial do período não pode ser menor que a data atual, ou seja, não fez sentido o gerente fazer um planejamento para um período que já passou. Uma exceção ocorre no tipo de período mensal, onde o gerente pode efetuar o planejamento do mês corrente mesmo que o mês já tenha sido iniciado. Um exemplo de consistência para data de início de vigência informada menor que a data atual é apresentada na Figura 27, onde o tipo de período a ser trabalhado é o

77 77 semanal. Figura 27 Mensagem de advertência para a não utilização de período passado Outro ponto a ser observado, é que, embora o planejamento disponibilize os tipos de períodos para se trabalhar, nada impede que o gerente efetue o seu planejamento para um período maior que um mês, ou seja, o mesmo pode fazer programações de compra para qualquer período. Por exemplo, o gerente pode trabalhar com programações de compras semanais, quinzenais, mensais, trimestrais, ou até mesmo anuais, onde neste último caso, estando em dezembro de 2009, o mesmo pode fazer as programações para todo o ano de 2010, ficando a sua escolha qual a melhor forma de se trabalhar com a vigência de um planejamento. Conforme pode ser observado na Figura 22 demonstrada anteriormente, alguns campos já iniciam com um valor padrão que é sugerido pelo sistema. Cada gerente de compras precisa analisar qual a melhor forma de aplicação destas opções e quais os impactos as mesmas terão no departamento de compras. A Figura 28 ilustra um exemplo dos dados gerais informados no cabeçalho de um planejamento de compras. Figura 28 Exemplo de dados do cabeçalho já informados em um planejamento A próxima etapa é efetuar o cálculo do Open to Buy para o período de vigência do planejamento, isto caso o mesmo utilize o controle financeiro, pois para planejamentos com apenas controle físico dos produtos não existe necessidade de considerar o Open to Buy. Este cálculo é feito pelo gerente de compras em uma tela desenvolvida especificamente para tal funcionalidade. Esta tela é denominada Cálculo do Open to Buy e pode ser acessada através do botão Cálculo OTB $, disponível no rodapé da tela de cadastro.

78 78 Embora os autores apliquem a fórmula para obter o Open to Buy do mês corrente ou dos próximos meses, característica do mercado varejista, o módulo de planejamento de compras desenvolvido no presente trabalho não se limita a trabalhar apenas com planejamentos mensais, conforme mencionado anteriormente. Para tanto, os tipos de períodos disponibilizados no cálculo do OTB foram denominados período corrente e período futuro, ao invés de mês corrente e mês futuro (próximos meses). A Figura 29 apresenta a tela de Cálculo do Open to Buy para o período corrente. Figura 29 Tela de cálculo do OTB para período corrente No exemplo da Figura 29, pode-se observar que a fórmula para o cálculo do Open to Buy para período o corrente é muito simples, porém, a sua simplicidade ajuda os compradores a evitarem problemas futuros relacionados à área financeira da empresa. Após lançados os valores no cálculo, descobre-se que o valor ideal para gastar com compras no período é de R$ ,00. Para o cálculo do Open to Buy de um período futuro, a fórmula também é muito simples e semelhante ao cálculo do período corrente. As mudanças mais significativas para esta fórmula com relação ao período corrente são: a) deve ser considerado o estoque planejado para o final do período, ao invés do estoque planejado para próximo período; b) deve ser considerado o estoque planejado para o início do período, ao invés do estoque atual do período corrente; c) após calculado o valor das compras planejadas, deve ser considerado o valor total

79 79 de possíveis ordens de compra programadas com os fornecedores para o período. A Figura 30 apresenta a tela de Cálculo do Open to Buy para um período futuro. Figura 30 Tela de cálculo do OTB para período futuro No exemplo da Figura 30, pode-se observar que após lançados os valores no cálculo, descobre-se que o valor ideal para gastar com compras no período, quando o mesmo chegar, é de R$ ,00. Com o Open to Buy calculado, a próxima etapa do cadastro é informar os itens que farão parte do planejamento na grid denominada Itens do Planejamento. A inserção de itens nesta grid pode ocorrer de duas formas: inserção manual, ou fazendo uso da tela de Base para Planejamento. O Quadro 10 apresenta o significado de cada campo utilizado na grid de Itens do Planejamento, bem como suas funcionalidades/características. Seq. Sequência do Item: identifica a sequência do item do planejamento de compras. Sua numeração é incrementada automaticamente pelo sistema a cada novo item inserido na grid. Origem Código da Origem de Produto: este campo fica visível na grid somente quando o tipo de programação for Origem. Família Código da família de produto: este campo fica visível na grid somente quando o tipo de programação for Família. Produto Código do produto: este campo fica visível na grid somente quando o tipo de programação for Produto.

80 80 Agrupamento de Produtos Código do agrupamento de produtos: este campo fica visível na grid somente quando o tipo de programação for Agrupamento Produto Comercial. Início Prev. Entrega Data inicial da previsão de entrega: indica o início do período programado para a entrega do item. Este período será utilizado na identificação do item de planejamento nas ordens de compra para amarração entre os documentos e abatimentos de saldos. É permitido informar apenas previsões de entrega que estejam dentro do período de vigência do planejamento. Fim Prev. Entrega Data final da previsão de entrega: semelhante ao campo Início Prev. Entrega, porém, indica o fim do período programado para a entrega do item. Quantidade Quantidade planejada para compra: indica a quantidade prevista para o item a ser adquirido pelos compradores. Valor Item Valor do item do planejamento: indica o valor total previsto para o item a ser adquirido pelos compradores. Cond. Pgto. Código da condição de pagamento do item: indica qual é a condição de pagamento prevista para as compras do item. Desc. Cond. Pgto. Descrição da condição de pagamento. % Crescimento Percentual de crescimento aplicado no item: este percentual é aplicado sobre o valor disponível para compras no período, a fim de simular um possível crescimento das vendas de determinando item e conseqüentemente a necessidade de um aumento nas compras. Vlr. Crescimento Valor de crescimento aplicado no item. Valor Disponível p/ Compras no Período Valor disponível para compras no período de entrega previsto: este campo recebe o valor do campo Valor Item e somente é alterado quando informado um percentual de crescimento. Valor Utilizado p/ Compras Valor já utilizado para compras: este campo indica o valor do item já utilizado pelos compradores no fechamento de ordens de compra. Este valor somente é atualizado caso o planejamento utilize o controle financeiro para abatimento de saldos. Saldo Disponível p/ Compras (OTB) Saldo disponível para compras do item do planejamento, ou Open to Buy do item: este saldo também é atualizado no fechamento de ordens de compra, da mesma forma que o valor utilizado para compras, seguindo o mesmo critério de controle financeiro para abatimento de saldos.

81 81 Qtd. Disponível p/ Compras Quantidade disponível para compras no período de entrega previsto. no Período Qtd. Utilizada p/ Compras Quantidade já utilizada para compras: este campo indica a quantidade do item já utilizada pelos compradores no fechamento de ordens de compra. Esta quantidade somente é atualizada caso o planejamento utilize o controle físico para abatimento de saldos. Saldo de Qtd. Disponível p/ Saldo de quantidade disponível para compras do item do planejamento: Compras este saldo também é atualizado no fechamento de ordens de compra, da mesma forma que a quantidade utilizada para compras, seguindo o mesmo critério de controle físico para abatimento de saldos. Quadro 10 Campos da grid de Itens do Planejamento Todos os campos editáveis anteriormente mencionados são informações obrigatórias, com exceção do percentual de crescimento. A tela de Base para Planejamento funciona como um grande facilitador para a geração do planejamento. Através dela é possível fazer uma análise mais detalhada, onde o gerente de compras pode definir quais itens e quantidades irão fazer parte do planejamento baseando-se no histórico de compras ou vendas. Esta tela é acessada através do botão Base Planej., disponível no rodapé da tela de cadastro. A Figura 31 apresenta a tela de base para planejamento de compras no momento de sua inicialização. Figura 31 Tela de base para geração do planejamento de compras Conforme se pode observar na Figura 31, a tela de base para planejamento possui

82 82 várias opções de filtro disponíveis. Inicialmente, é preciso selecionar qual o histórico (compras ou vendas) se deseja visualizar, são disponibilizadas as opções: Ordem Compra, Notas Entrada, Pedidos e Notas Saída. O período do histórico sugerido pelo sistema é sempre o mesmo período da vigência, porém do ano anterior. Esta é apenas a sugestão do sistema, sendo que o gerente de compras pode utilizar qualquer data para carregar o histórico. Como exemplo, pode-se querer utilizar o histórico de notas fiscais de saída dos meses de junho e julho de 2008 para a geração do planejamento de julho de 2009, pressupondo que às vendas aumentarão de tal forma, que serão vendidas em apenas um mês, as mercadorias que foram vendidas em dois meses do ano anterior. A Figura 32 demonstra um exemplo de histórico já carregado na tela de base para planejamento. Figura 32 Exemplo de histórico de compras Como pode ser visto na Figura 32, o exemplo demonstra a utilização de um histórico de compras baseado nas ordens de compra efetivadas no mês de dezembro de A tela apresenta duas grids, sendo uma para visualização dos dados de forma agrupada e outra para visualização de forma detalhada. No exemplo, percebe-se que o tipo de período a ser trabalhado é o semanal e o tipo de programação é por produtos.

83 83 O carregamento do histórico possui uma regra diferente para cada tipo de período, por exemplo, para trabalhar com tipo de período semanal, entende-se que uma semana começa no domingo e termina no sábado, então, no carregamento detalhado dos itens é feito uma quebra para que seja obedecido tal critério. Percebe-se então, que, a primeira semana do mês de dezembro de 2008 começa no primeiro dia do mês, independente se este é ou não domingo, indo até o último dia da semana (06/12/2008). As semanas seguintes obedecem ao critério de início e fim da semana, sendo que o último dia da última semana equivale ao último dia do mês, ou seja, a última semana do mês de dezembro de 2008 equivale ao período de 28/12/2008 à 31/12/2008, porém, como se pode perceber na Figura 32, nesta semana não houve compras para o produto utilizado no filtro da carga dos dados históricos. Na Figura 32, percebe-se também que no mês de dezembro de 2008 foram compradas 814 unidades (pares) do produto TENISADIDAS, a um preço médio de R$ 99,04. Nota-se que valor total aproximado desta compra foi de R$ ,00, e que depois de informado o valor de 10% de crescimento, o valor do saldo sugerido para ser utilizado no Open to Buy do item, que inicialmente era o mesmo valor que o total da compra, passou a ser R$ ,00. O mesmo critério adotado na carga dos valores do histórico agrupado é utilizado para a carga do histórico detalhado, segundo as regras de quebras semanais. As quebras dos dados da grid de histórico detalhado nos tipos de período quinzenal e mensal acontecem da mesma forma que o tipo de período semanal, porém, ao invés de as quebras acontecerem por semana, no tipo de período quinzenal estas são feitas conforme as duas quinzenas existentes no mês, já no tipo mensal, é feito a soma de todas as compras do mês. A Figura 33 apresenta um exemplo de histórico de famílias de produto de notas fiscais de entrada utilizando o tipo de período quinzenal.

84 84 Figura 33 Exemplo de histórico utilizando tipo de período quinzenal Na Figura 34 é apresentado um exemplo de histórico de agrupamento de produtos de notas ficais de saída utilizando o tipo de período mensal. Figura 34 Exemplo de histórico utilizando tipo de período mensal

85 85 É necessário também, que antes do processamento, o gerente de compras informe uma condição de pagamento a ser utilizada nos itens, sendo que caso seja necessário efetuar a alteração de condição de pagamento de algum item, isto pode ser feito na tela de cadastro após a geração dos itens através do botão Processar da tela de base para planejamento. Na grid de histórico agrupado existe o campo Sel. o qual permite que sejam selecionados apenas os itens que realmente se deseja incluir no planejamento de compras. No rodapé da tela de base para planejamento existem botões de consulta, estas consultas referem-se à visualização de todos os dados do item posicionado na grid de histórico agrupado. O botão relacionado à consulta do item fica habilitado conforme o tipo de programação escolhida, ou seja, ao se trabalhar com programação de agrupamentos de produtos, somente o botão Agrup. Prod. ficará habilitado. Este mesmo critério também é utilizado para os outros tipos de programação, sendo que para programação por produtos são dois botões que ficam habilitados, um para consulta padrão via tela de pesquisa de registro existente no Sistema Sapiens e outro para consulta detalhada do produto e suas derivações. A Figura 35 apresenta um exemplo de consulta dos dados de um produto via tela de pesquisa de registro do Sistema Sapiens. Figura 35 Consulta de produto base para planejamento via tela de pesquisa de registro Após processado os itens selecionados na tela de base para planejamento, os mesmos são incluídos automaticamente na grid de Itens do Planejamento da tela de cadastro, sendo que esta inserção obedece algumas regras durante o processamento. Ao processar os itens na tela de base para planejamento, o sistema efetua novamente as quebras de valores e também dos períodos de previsão de entrega, para que estes se ajustem conforme o período de vigência do planejamento, seguindo os mesmos critérios de quebras de períodos utilizados no carregamento da base do planejamento. A Figura 36 apresenta um exemplo dos itens de

86 86 produto de um planejamento inseridos no cadastro após o processamento da base do planejamento. Figura 36 Itens do planejamento após utilização da base para geração A Figura 37 apresenta os demais campos da grid de Itens do Planejamento não visualizados na Figura 36. Figura 37 Valores e saldos dos itens de planejamento

87 87 No exemplo apresentado nas Figuras 36 e 37, foi utilizado o mês de dezembro de 2008 para geração dos itens de planejamento do mês de julho de Com relação ao período de previsão de entrega previsto para os itens, nota-se que foi utilizado o tipo de período semanal, portanto, os períodos foram inseridos nos itens seguindo o conceito de início e fim das semanas, conforme explicado anteriormente. Percebe-se também, que a distribuição dos valores e quantidades da grid de Itens do Planejamento ocorreu de forma proporcional aos valores e quantidades visualizados anteriormente na grid de Histórico Agrupado da tela de base para planejamento. A tela de cadastro apresenta ainda alguns totalizadores, dentre eles, destacam-se o valor total utilizado para compras e o saldo total disponível para compras (OTB), pois, através destes totalizadores o gerente de compras saberá de maneira geral como está o andamento de suas compras planejadas. Através dos assuntos apresentados relacionados ao cadastro do planejamento de compras, pode-se perceber a sua importância perante a utilização do mesmo quando se inicia o período de vigência. Tal importância se justifica pelo fato de que é através do cadastro que é definido o comportamento do sistema quando da ocorrência de uma oficialização de compra junto a um fornecedor através de uma ordem de compra Processo de abatimento de saldos via tela de Cadastro de Ordens de Compra Conforme já mencionado, a partir de uma ordem de compra é possível ter a visualização prévia dos dados de uma nota fiscal de entrada. A partir de uma ordem de compra são definidos todos os detalhes da compra com determinado fornecedor, a qual será oficializada no momento da geração da nota fiscal. O processo de abatimento dos saldos (físico ou financeiro) dos itens de um planejamento acontece por intermédio do fechamento de uma ordem de compra. A tela de cadastro de ordens de compra a ser utilizado é uma tela já existente no Sistema Sapiens, a qual foi necessário implementar todos os tratamentos envolvidos no processo de abatimento de saldos. A tela de cadastro de ordens de compra utilizada no planejamento é acessada através do caminho Comercial > Compras > Ordens Compra > Agrupada. A Figura 38 apresenta a tela de cadastro de ordens de compra quando iniciada.

88 88 Figura 38 Tela de cadastro de ordens de compra A Figura 39 apresenta a aba de produtos de uma ordem de compra, onde são feitos os vínculos de um item de planejamento com um item de ordem de compra. Figura 39 Aba de Produtos do cadastro de ordens de compra Ao digitar um produto na ordem de compra, o sistema verifica se o produto, origem, família ou agrupamento de produtos ao qual o mesmo está relacionado se encontra cadastrado no planejamento ativo (conforme o tipo de programação). Caso o item não esteja cadastrado o

89 89 sistema se comporta conforme o que foi definido no indicativo do planejamento se o sistema bloqueia compras de produtos não planejados. A Figura 40 apresenta um exemplo de consistência de digitação de um produto não cadastrado onde o planejamento está configurado para apenas avisar o usuário de tal situação. Figura 40 Exemplo de aviso de produto não planejado Já a Figura 41 apresenta um exemplo onde o planejamento está configurado para efetuar o bloqueio de produtos não planejados. Figura 41 Exemplo de bloqueio de compra de produto não planejado Caso o planejamento esteja configurado para liberar compras de produtos não planejados, ao digitar um produto qualquer que não esteja presente no planejamento, o sistema não apresenta as mensagens de consistência, permitindo a compra deste produto. O mesmo tratamento anteriormente mencionado é aplicado também para a condição de pagamento da ordem de compra, conforme configurado no indicativo se o sistema bloqueia compras de produtos com condição de pagamento não planejada. Um exemplo de aviso sobre esta situação pode ser visto na Figura 42. Figura 42 Exemplo de aviso de produto com condição de pagamento não planejada Outro exemplo de consistência da condição de pagamento pode ser visto na Figura 43.

90 90 Figura 43 Exemplo de bloqueio de compra de produto com condição de pagamento não planejada Conforme pode se visto na Figura 44, depois de digitado o item de produto e constatado que o mesmo se encontra disponível no planejamento, através da identificação do produto ou sua definição hierárquica e a previsão de entrega do mesmo, o sistema faz o relacionamento do item de produto da ordem de compra com o item de planejamento, sendo possível a visualização de alguns dados importantes do item do planejamento, conforme pode ser visto nas Figuras 45 e 46. Figura 44 Item de produto digitado na ordem de compra

91 91 Figura 45 Relacionamento de um item de planejamento com item de ordem de compra Figura 46 Demais informações disponibilizadas através do relacionamento Ao efetuar o fechamento da ordem de compra (efetivação do pedido com o fornecedor), caso o item de planejamento possua saldo disponível (conforme tipo de controle,

92 92 físico ou financeiro), o sistema realiza a atualização dos saldos e estas informações já podem ser visualizadas pelo gerente de compras através da tela de cadastro, bem como por outros compradores através das telas de consulta. A Figura 47 apresenta um exemplo de quantidades, valores e saldos de um item de planejamento atualizados após o fechamento de uma ordem de compra. Figura 47 Informações atualizadas no planejamento de compras Se no momento do fechamento de uma ordem de compra, o item a ser utilizado não possuir saldo disponível, o sistema bloqueia o fechamento desta ordem de compra. Desta forma, o comprador deve solicitar ao gerente de compras um aumento do saldo disponível (físico ou financeiro) e somente depois de concedido o aumento de saldo a ordem de compra poderá ser fechada. A Figura 48 apresenta um exemplo de bloqueio de fechamento de ordem de compra quando ultrapassado o saldo financeiro de um produto planejado, ou seja, o Open to Buy do item de planejamento.

93 93 Figura 48 Exemplo de falta de saldo financeiro para o produto planejado Na Figura 49, é apresentado um exemplo de bloqueio de fechamento de ordem de compra quando ultrapassado o saldo físico de um produto planejado. Figura 49 Exemplo de falta de saldo físico para o produto planejado Na Figura 50, é apresentado um exemplo de bloqueio de fechamento de ordem de compra quando ultrapassado o saldo financeiro de uma origem de produto planejada. Figura 50 Exemplo de falta de saldo financeiro para a origem de produto planejada