M6 Posted September 26, 2006 at 12:55 PM Report #52938 Posted September 26, 2006 at 12:55 PM KISQueanos, 🙂 estamos com alguns problemas técnicos e não temos wiki para editar os requisitos. Ora sendo o meu papel o de "mau da fita", tenho de vos melgar a dizer que "lá por não termos condições para trabalhar isso não quer dizer que não façamos o nosso trabalho"! 🙂 E como tal, enquanto não há wiki, vou dar aqui o kick off dos requisitos de negócio para o KISC. O que se segue abaixo tem apenas a ver com a minha ideia do projecto e serve apenas como ponto de partida para a discussão. Vão acontecer várias "teimas", algumas fortes e feias, e tal deve ser encarado como um processo criativo normal onde várias visões e ideias são batidas, rebatidas e debatidas. Não levem estas discussões a peito, ou seja, não as encarem como nada de pessoal, são normais, extremamente úteis e vão ver que o resultado final será muito melhor do que qualquer das ideias que originaram a discussão. 😛 Nomenclatura: vamos acordar que o identificador único dos requisitos é constituído por um número (sequencial e único) e uma letra identificadora do tipo de requisito. Se um requisito morrer, o seu número perde-se e não mais será usado. O requisito tem de ter um nome e uma descrição, opcionalmente pode ter uma nota de relação com outros requisitos. Ver N8 e N9. Requisitos de Negócio N1 - Línguas - Sistema disponível nas seguintes línguas: português, inglês, francês, espanhol. N2 - Plataforma - Sistema disponível para as seguintes plataformas: Windows, Linux, Mac OS X. N3 - Relatórios - O sistema disponibiliza os seguintes relatórios: lista de produtos com preço máximo, médio, mínimo e mediano. Os cálculos dos relatórios podem levar em conta, ou não, os produtos promocionais. Levando em conta os produtos promocionais a custo zero, os mesmos influenciam os valores estatísiticos, caso contrário, apenas o stock aumenta e as estatísticas são construídas excluindo estes produtos. N4 - Lista de Compras - O sistema constrói uma lista de compras com os produtos considerados em falta ou abaixo de um valor limite indentificado pelo utilizador e mais tarde ajustado pelo proprio sistema (a partir do momento que comece a haver dados suficientes para tal) N5 - Entrada em Stock - O sistema permite a entrada de produtos constantes numa lista de compras em menos de um segundo. Colocando por defeito dados retirados da lista de compras (N4), bastanto assim, confirmar/corrigir as entradas. N6 - Medidas - O sistema suporta produtos nas seguintes medidas: Kg e Unidades. N7 - Formatos de Relatórios - Todos os relatórios devem estar disponibilizados em: papel, pdf e folha de cálculo. Ver N3. N8 - Entrada de produtos - Todos os produtos podem ser registados como uma compra normal ou promocial. O tipo de entrada de produto influencia os relatórios. Ver N3 e N9. N9 Produtos promocionais - Produtos promocionais são aqueles que foram adquiridos de forma promocional: - custo zero; - desconto;. Ver N3. N10 - Selecção de produtos a gerir - A selecção dos produtos que cada utilizador vai gerir é feita por intremédio de uma lista comum, pré criada, com todo o tipo de produtos/acondicionamentos/unidades de medida (N6) possiveis. Cada utilizador vai dessa BD comum selecionar as que lhe intereçam usar. N11 - Geração de receitas - O sistema sugere uma ou mais receitas possiveis com o stock que há na altura. Opção de sugestão também aplicada a meia-receita, onde se sugerem receitas para as quais as quantidades dos produtos existem em valores iguais ou superiores a 50% dos valores da receita completa. N12 - Gestão de listas de compras - O sistema pode guardar listas de compras efectuadas (N4) sendo possível a sua reutilização. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 26, 2006 at 01:01 PM Report #52940 Posted September 26, 2006 at 01:01 PM Em N4 adicionava um outro ponto em que não é falta de produto, nem propriamente stock em baixo. vou dar um exemplo: Leito xpto, gasta-se normalmente á volta de 10 litros por mes, e o preco mais baixo comprado é 0,42€ (Há 12 Litros em stock) No caso de o preço ser inferior ou igual a 0,42 'mandar' comprar mais 20 Litros. (porque a validade do produto o permite e para aproveitar o preço porque REALMENTE é bom) cool stuffs to check. http://blog.zxcoders.com//
Ridelight Posted September 26, 2006 at 01:10 PM Report #52943 Posted September 26, 2006 at 01:10 PM Em N1 convem que as linguas sejam obtidas atraves de um ficheiro externo facilmente editável com um editor de texto, para ser facilmente actualizável e adicionadas novas linguas. Regras do FÓRUM
M6 Posted September 26, 2006 at 01:13 PM Author Report #52945 Posted September 26, 2006 at 01:13 PM Em N4 adicionava um outro ponto em que não é falta de produto, nem propriamente stock em baixo. vou dar um exemplo: Leito xpto, gasta-se normalmente á volta de 10 litros por mes, e o preco mais baixo comprado é 0,42€ (Há 12 Litros em stock) No caso de o preço ser inferior ou igual a 0,42 'mandar' comprar mais 20 Litros. (porque a validade do produto o permite e para aproveitar o preço porque REALMENTE é bom) Mas onde vais buscar o preço para saber se o mesmo é bom? 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
M6 Posted September 26, 2006 at 01:19 PM Author Report #52946 Posted September 26, 2006 at 01:19 PM Em N1 convem que as linguas sejam obtidas atraves de um ficheiro externo facilmente editável com um editor de texto, para ser facilmente actualizável e adicionadas novas linguas. Calma jovem, estás a falar de requisitos de implementação e isso ainda não é agora. 😛 Mas podes fazer essa anotação na wiki, que já está a funfar: http://kisc.info 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 26, 2006 at 01:48 PM Report #52949 Posted September 26, 2006 at 01:48 PM Em 26/09/2006 às 15:13, M6 disse: Mas onde vais buscar o preço para saber se o mesmo é bom? Pelos ultimos preços de compra. Neste caso em concreto pelo preço mais baixo (por exmeplo) dos ultimos 3 meses cool stuffs to check. http://blog.zxcoders.com//
M6 Posted September 26, 2006 at 02:06 PM Author Report #52953 Posted September 26, 2006 at 02:06 PM Mas os preços flutuam bastante, mesmo durante um mês. 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 26, 2006 at 04:26 PM Report #52994 Posted September 26, 2006 at 04:26 PM Os preços podem e variam muito, mas nunca fogem muito. (não estamos a falar de couves nem alfaces, que isso sim,.. varia muito) A variação dos preços nas lojas normalmente é por uma questão ocmercial (a tal hitória do 'roubar aqui e "dar" dali' A ideia é apanhar sempre e só os bons preços. cool stuffs to check. http://blog.zxcoders.com//
M6 Posted September 26, 2006 at 04:40 PM Author Report #52998 Posted September 26, 2006 at 04:40 PM Sim, mas por exemplo, entre o dia 15 e 20 de cada mês, os hipers têm imensas promoções, tipo pague 2 leve 3, nesses casos como se faz? É mesmo um à borla? Ou contabiliza-se o preço a dividir pelos 3? 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 26, 2006 at 05:53 PM Report #53003 Posted September 26, 2006 at 05:53 PM Em relação a esse tipo de promoções ainda nem tinha pensado nisso. Vou pensar agora. edit: Já pensei 😛 Penso que em relação a isso não vá causar problema algum, uma ves que a introdução é feita pelo nº de embalagem e preço total, ou seja vai registar o preço medio. cool stuffs to check. http://blog.zxcoders.com//
M6 Posted September 26, 2006 at 06:05 PM Author Report #53006 Posted September 26, 2006 at 06:05 PM Será? Acho que este é um daqueles casos em que qualquer das opções tem pontos bons e maus... É que depois isso vai influenciar o valor do preço médio e até a mediana, e a verdade é que esses valores, em especial os da mediana, não vão ser correctos. Acho que isto requer mais meditação. Se calhar temos de pensar num esquema mais "evoluido" para contemplar este tipo de situações... 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 26, 2006 at 06:15 PM Report #53010 Posted September 26, 2006 at 06:15 PM Acho que isto requer mais meditação. Se calhar temos de pensar num esquema mais "evoluido" EXACTAMENTE! O que eu estou aqui a dizer não é nenhuma escritura!!! isto até foi o que me lembrei assim de repente em 5 minutos. A segredo MESMO do fundo da questão é mesmo isso! elaborar/estudar/inventar o melhor metodo de rentabilizar ao maximo! Fiz-me entender? cool stuffs to check. http://blog.zxcoders.com//
Ridelight Posted September 26, 2006 at 11:03 PM Report #53103 Posted September 26, 2006 at 11:03 PM No caso dos leve 3 pague 2 vai inflacionar o preço médio, pois o cliente vai registar apenas 2 itens comprados apesar de trazer 3, etodos sabemos que funciona assim: Preço unitário : 1,00€ (antes da promoção) Leve 3 pague 2 : 2,50€ logo o preço unitário vai-se cifrar em 1,25€ - Regras do FÓRUM
pebat Posted September 27, 2006 at 12:12 AM Report #53120 Posted September 27, 2006 at 12:12 AM Em relaçao as promoçoes pode-se e fazer uma cena so para promoçoes k vai afectar a msm o stock mas esse stock vai com outra referencia digamos assim, aquele leite xpto que e do lote X foi comprado em promoçao, logo nao ia mexer mto com o preço medio...
M6 Posted September 27, 2006 at 08:21 AM Author Report #53139 Posted September 27, 2006 at 08:21 AM Também estive a "meditar" sobre o assunto e parece que começamos a ter algum alinhamento de ideias. Acho que se devia marcar a compra como sendo uma promoção mas que, no caso de oferta de produtos (como é o caso de pague 3 leve 2) o produto oferecido não deve entrar para a contabilidade, ou seja, não deve afectar o preço médio nem a mediana. Esta abordagem permite duas coisas: - manter os valores dos produtos registados "correctamente", ou seja, o preço introduzido foi mesmo o preço de compra e não "poluido/destorcido", assim o produto extra é um bónus, o qual não pagámos, não sabemos se vamos voltar a ter hipótese de adquirir de forma gratuíta e como tal não deve ser registado como uma compra real; - gerar relatórios que permitam inferir qual a melhor altura para ir às compras se estamos numa de sacar mais promoções; 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 27, 2006 at 09:15 AM Report #53150 Posted September 27, 2006 at 09:15 AM Ena bem,... voçes vão-me matar! lool Discordo disso tudo, axo precisamente o contrario. - manter os valores dos produtos registados "correctamente", ou seja, o preço introduzido foi mesmo o preço de compra e não "poluido/destorcido", O ideal seria ter o registo do preço REAL (destrocido) porque é nas tais destroções é que vai o engano normal das pessoas que vai na volta pensam que é barato mas é caro. Por exemplo, normalmente dá para comprar o tal produto a 1€ mas que consegue-se apanhar muita vez a leve 3 pague 2 por 1,25 cada (2,5 os 3) O preço registado nao deveria de ser 1,25, por assim quando voltar a ir comprar vamos pensar que 1,10€ é um preço muito bom, quando na realidade o preço razoavel é 1€. ´(já comento mais,.. tou no escritorio a fazer compras nao tenho muito tempo....) cool stuffs to check. http://blog.zxcoders.com//
M6 Posted September 27, 2006 at 09:42 AM Author Report #53154 Posted September 27, 2006 at 09:42 AM Em 27/09/2006 às 11:15, d_pintassilgo disse: Ena bem,... voçes vão-me matar! lool Discordo disso tudo, axo precisamente o contrario. Ora cá está a primeira teimazinha! 😉 Citação O ideal seria ter o registo do preço REAL (destrocido) porque é nas tais destroções é que vai o engano normal das pessoas que vai na volta pensam que é barato mas é caro. Por exemplo, normalmente dá para comprar o tal produto a 1€ mas que consegue-se apanhar muita vez a leve 3 pague 2 por 1,25 cada (2,5 os 3) O preço registado nao deveria de ser 1,25, por assim quando voltar a ir comprar vamos pensar que 1,10€ é um preço muito bom, quando na realidade o preço razoavel é 1€. Mas a "verdade" é que se te oferecem um, os outros dois sairam a 1,25€ cada um, até porque se levasses as embalagens individuais, apenas uma ou até duas soltas sem aproveitares a promoção, o preço é mesmo 1,25€. E 1,25€ é 25% mais caro do que o normal. Talvez uma forma de não influenciar a mediana (estou mais interessado nesta medida do que na média) seja inserir o produto extra como sendo uma oferta, a custo zero. Citação ´(já comento mais,.. tou no escritorio a fazer compras nao tenho muito tempo....) Se estás a fazer compras então está atento a mais requisitos. 😄 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 27, 2006 at 10:05 AM Report #53159 Posted September 27, 2006 at 10:05 AM O que disses-teestá tudo muito certo, mas há ai 2 pequenas lacunas! 😉😄 Mas a "verdade" é que se te oferecem um Nop,.. ninguem oferece nada a ninguem, e é mesmo a ideia de contemplar essa ideia, que parecendo que não há muita gente que ainda vai na canção do bandido. Alem disso: inserir o produto extra como sendo uma oferta, a custo zero. Ou seja,.. vai entrar: 2 unidades a 1,25 = 2,5 + 1 unidade a 0 = 0 Ou seja: 3 unidades a 2,5 Vai dar ao mesmo, fica é mais especificado, talvez,... mas na minha opinião só vai dar mais trabalho na introdução dos dados por arte do utilizador. (sai mais 1 camiao de batata pro CD do sul!! LOL) cool stuffs to check. http://blog.zxcoders.com//
M6 Posted September 27, 2006 at 10:43 AM Author Report #53169 Posted September 27, 2006 at 10:43 AM Em 27/09/2006 às 12:05, d_pintassilgo disse: O que disses-teestá tudo muito certo, mas há ai 2 pequenas lacunas! 😉😄 Força. 😄 Citação Nop,.. ninguem oferece nada a ninguem, e é mesmo a ideia de contemplar essa ideia, que parecendo que não há muita gente que ainda vai na canção do bandido. É pá, não venhas com "ther's no such thing as a free lunch", sei isso muito bem... 😄 Mas a verdade é que efectivamente o terceiro produto é gratuito, pois eu posso muito bem levar as enbalagens em separado, pagando o preço individual de cada uma, sem levar o grátis. Citação Alem disso: Ou seja,.. vai entrar: 2 unidades a 1,25 = 2,5 + 1 unidade a 0 = 0 Ou seja: 3 unidades a 2,5 Não obrigatoriamente. Seria mais: 2 unidades a 1,25 = 2,5 + 1 unidade a 1,25 = 0 (marcada como oferta) As contas podem ser feitas excluindo as promoções. Ou seja, o utilizador poderá ter ao seu dispor: - um relatório que lhe mostre o custo dos produtos que trouxe para casa, e se aqui a média é 0,8(3)€, a mediana vai ser 1,25€ - um relatório que lhe mostre o custo dos produtos que comprou, ou seja, que não foram oferecido, e aqui a média é igual à mediana, ou seja, 1,25€. - um relatório de que mostre os qual o "ganho" no valor das promoções, e no caso acima, sendo 1 produto a 1,25€ seria 1,25€ de ganho. Espero ter-me feito compreender. Citação Vai dar ao mesmo, fica é mais especificado, talvez,... mas na minha opinião só vai dar mais trabalho na introdução dos dados por arte do utilizador. (sai mais 1 camiao de batata pro CD do sul!! LOL) Não é a mesma coisa, há uma granularidade diferente no detalhe do produto, que permite o KISC trabalhar de forma mais "real". 10 REM Generation 48K! 20 INPUT "URL:", A$ 30 IF A$(1 TO 4) = "HTTP" THEN PRINT "400 Bad Request": GOTO 50 40 PRINT "404 Not Found" 50 PRINT "./M6 @ Portugal a Programar."
David Pintassilgo Posted September 27, 2006 at 11:24 AM Report #53183 Posted September 27, 2006 at 11:24 AM Sim.. é certo que isso vai levar a uma maior realismo, mas na minha ideia, como eu estou a imaginar 'a coisa' axo que a "complicação" que isso vai gerar, não compença no que diz respeito á eficiencia Vs facilidade de uso. Mas é assim,.. estes promenores é que são os tais que temos de evoluir com o tmepo,... feito de uma forma ou de outra ao testar 'no campo' é que se vai ver ao certo se é melhor de uma ou de outra forma. Conclusão, por mim aprovo esse sistema desde que não traga 'trabalheira' maior significativa no introduzir os dados por parte do utilizador. cool stuffs to check. http://blog.zxcoders.com//
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now