http://wiki.geosales.com.br:8000/api.php?action=feedcontributions&feedformat=atom&user=Ryvanemaria 2026-05-05T13:05:14Z Contribuições do(a) usuário(a) MediaWiki 1.35.0 http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13506 2020-07-09T19:48:47Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> O supervisor deve visualizar as metas de todos os integrantes de sua alçada, sejam eles supervisores ou vendedores.<br /> <br /> A visão de metas deverá ser implementada na tela de gestão de equipes, atualmente, nessa tela, é possível visualizar algumas informações a respeito de cada vendedor e supervisor. Informações como: Pedidos Mês, Orçamentos (Mês), Pedidos Hoje, Ticket Médio, Rentabilidade, Positivação. Essas informações são exibidas em forma de cards, e cada usuário (supervisor ou vendedor) possui um card individual.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13505 2020-07-08T17:51:22Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> O supervisor deve visualizar as metas de todos os integrantes de sua alçada, sejam eles supervisores ou vendedores.<br /> <br /> <br /> '''- Visão das metas da equipe de vendas:'''<br /> A visão de metas deverá ser implementada na tela de gestão de equipes, atualmente nessa tela é possível visualizar algumas informações a respeito de cada vendedor e supervisor. Informações como: Pedidos Mês, Orçamentos (Mês), Pedidos Hoje, Ticket Médio, Rentabilidade, Positivação. Essas informações são exibidas em forma de cards, e cada usuário (supervisor ou vendedor) possui um card individual. <br /> <br /> Deverá ser criado nessa mesma tela um painel que proporcione ao usuário uma visão geral das metas propostas, e principalmente dos resultados obtidos <br /> Filtros por vendedor, supervisor, organização de venda. <br /> <br /> <br /> <br /> '''- Visão das metas do vendedor:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13504 2020-07-08T14:13:11Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> O supervisor deve visualizar as metas de todos os integrantes de sua alçada, sejam eles supervisores ou vendedores.<br /> <br /> <br /> '''- Visão das metas da equipe de vendas:'''<br /> A visão de metas deverá ser implementada na tela de gestão de equipes, atualmente nessa tela é possível visualizar algumas informações a respeito de cada vendedor e supervisor. Informações como: Pedidos Mês, Orçamentos (Mês), Pedidos Hoje, Ticket Médio, Rentabilidade, Positivação. Essas informações são exibidas em forma de cards, e cada usuário (supervisor ou vendedor) possui um card individual. <br /> <br /> <br /> Filtros por vendedor, supervisor, organização de venda<br /> <br /> <br /> '''- Visão das metas do vendedor:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13502 2020-07-06T18:31:04Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> O supervisor deve visualizar as metas de todos os integrantes de sua alçada, sejam eles supervisores ou vendedores.<br /> <br /> <br /> '''- Visão das metas da equipe de vendas:'''<br /> Filtros por vendedor, supervisor, organização de venda<br /> <br /> <br /> '''- Visão das metas do vendedor:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13501 2020-07-06T14:22:48Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> '''- Visão das metas da equipe de vendas:'''<br /> Filtros por vendedor, supervisor, organização de venda<br /> <br /> <br /> '''- Visão das metas do vendedor:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Meta&diff=13500 2020-07-06T13:07:38Z

<p>Ryvanemaria: Criou página com ''''- Visão de todas as metas do supervisor:''' '''- Visão das metas da equipe de vendas:''' '''- Visão das metas do vendedor:''''</p> <hr /> <div>'''- Visão de todas as metas do supervisor:'''<br /> <br /> '''- Visão das metas da equipe de vendas:'''<br /> <br /> '''- Visão das metas do vendedor:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Documenta%C3%A7%C3%B5es_da_sprint&diff=13498 2020-06-25T16:51:40Z

<p>Ryvanemaria: </p> <hr /> <div>*[[Pesquisa]]<br /> *[[Meta]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13497 2020-06-23T14:53:43Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> Inicialmente será criado um relatório Excel em forma de planilhão, onde serão exibidas todas as respostas de todas as perguntas para a pesquisa selecionada.<br /> <br /> A planilha será composta de uma coluna fixa, para informação de Cliente. As colunas seguintes serão alimentadas com as perguntas que o usuário cadastrar, sendo uma coluna para cada pergunta criada. <br /> <br /> As perguntas serão dispostas no relatório conforme imagem em anexo. <br /> <br /> [ANEXAR IMAGEM AQUI] <br /> <br /> Algumas regras: <br /> <br /> 1. Perguntas que tem mais de uma resposta objetiva, as respostas serão exibidas numa mesma célula, e separada por vírgulas.<br /> <br /> 2. Perguntas em grade, cada linha da grade será uma nova pergunta no formulário, ou seja, cada linha inserida na grade irá gerar uma nova coluna no relatório.<br /> <br /> 3. Perguntas objetivas com a opção &quot;outros&quot; para que o usuário digite uma outra alternativa, o texto digitado será uma das alternativas selecionadas, incluso na célula separado por vírgulas como se fosse uma seleção comum. <br /> <br /> 4. Respostas não obrigatórias que não foram não respondidas numa pesquisa deverão ser exibidas em branco na planilha.<br /> <br /> 5. <br /> <br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas. Deverá ser possível que o usuário altere a ordem das perguntas na listagem, mas a priori, elas seguem a ordem de cadastro. <br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro da resposta de uma pergunta, deve ser possível que o usuário selecione para qual pergunta o sistema irá redirecionar a pesquisa caso a resposta em questão seja selecionada. <br /> <br /> Algumas regras: Não é possível selecionar perguntas anteriores a que está sendo digitada, então o ideal seria que o usuário fizesse as vinculações após a criação de todas as perguntas.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13496 2020-06-23T14:45:32Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> Inicialmente será criado um relatório Excel em forma de planilhão, onde serão exibidas todas as respostas de todas as perguntas para a pesquisa selecionada.<br /> <br /> A planilha será composta de uma coluna fixa, para informação de Cliente. As colunas seguintes serão alimentadas com as perguntas que o usuário cadastrar, sendo uma coluna para cada pergunta criada. <br /> <br /> As perguntas serão dispostas no relatório conforme imagem em anexo. <br /> <br /> [ANEXAR IMAGEM AQUI] <br /> <br /> Algumas regras: <br /> <br /> 1. Perguntas que tem mais de uma resposta objetiva, as respostas serão exibidas numa mesma célula, e separada por vírgulas.<br /> <br /> 2. Perguntas em grade, cada linha da grade será uma nova pergunta no formulário, ou seja, cada linha inserida na grade irá gerar uma nova coluna no relatório.<br /> <br /> 3. Perguntas objetivas com a opção &quot;outros&quot; para que o usuário digite uma outra alternativa, o texto digitado será uma das alternativas selecionadas, incluso na célula separado por vírgulas como se fosse uma seleção comum. <br /> <br /> 4. Respostas não obrigatórias que não foram não respondidas numa pesquisa deverão ser exibidas em branco na planilha.<br /> <br /> 5. <br /> <br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro da resposta de uma pergunta, deve ser possível que o usuário selecione para qual pergunta o sistema irá redirecionar a pesquisa caso a resposta em questão seja selecionada. <br /> <br /> Algumas regras: Não é possível selecionar perguntas anteriores a que está sendo digitada. (é uma problemática, porque somente após cadastrar todas as perguntas o usuário consegue fazer as vinculações</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13495 2020-06-23T14:43:48Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> Inicialmente será criado um relatório Excel em forma de planilhão, onde serão exibidas todas as respostas de todas as perguntas para a pesquisa selecionada.<br /> A planilha será composta de uma coluna fixa, para informação de Cliente. As colunas seguintes serão alimentadas com as perguntas que o usuário cadastrar, sendo uma coluna para cada pergunta criada. <br /> As perguntas serão dispostas no relatório conforme imagem em anexo. <br /> [ANEXAR IMAGEM AQUI] <br /> Algumas regras: <br /> 1. Perguntas que tem mais de uma resposta objetiva, as respostas serão exibidas numa mesma célula, e separada por vírgulas.<br /> 2. Perguntas em grade, cada linha da grade será uma nova pergunta no formulário, ou seja, cada linha inserida na grade irá gerar uma nova coluna no relatório.<br /> 3. Perguntas objetivas com a opção &quot;outros&quot; para que o usuário digite uma outra alternativa, o texto digitado será uma das alternativas selecionadas, incluso na célula separado por vírgulas como se fosse uma seleção comum. <br /> 4. Respostas não obrigatórias que não foram não respondidas numa pesquisa deverão ser exibidas em branco na planilha. <br /> 5. <br /> <br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro da resposta de uma pergunta, deve ser possível que o usuário selecione para qual pergunta o sistema irá redirecionar a pesquisa caso a resposta em questão seja selecionada. <br /> <br /> Algumas regras: Não é possível selecionar perguntas anteriores a que está sendo digitada. (é uma problemática, porque somente após cadastrar todas as perguntas o usuário consegue fazer as vinculações</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13494 2020-06-23T13:46:24Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> Inicialmente será criado um relatório Excel em forma de planilhão, onde serão exibidas todas as respostas de todas as perguntas para a pesquisa selecionada.<br /> A planilha será composta de uma coluna fixa, para informação de Cliente. As colunas seguintes serão alimentadas com as perguntas que o usuário cadastrar, sendo uma coluna para cada pergunta criada. <br /> As perguntas subjetivas <br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro da resposta de uma pergunta, deve ser possível que o usuário selecione para qual pergunta o sistema irá redirecionar a pesquisa caso a resposta em questão seja selecionada. <br /> <br /> Algumas regras: Não é possível selecionar perguntas anteriores a que está sendo digitada. (é uma problemática, porque somente após cadastrar todas as perguntas o usuário consegue fazer as vinculações</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13493 2020-06-22T20:26:12Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro da resposta de uma pergunta, deve ser possível que o usuário selecione para qual pergunta o sistema irá redirecionar a pesquisa caso a resposta em questão seja selecionada. <br /> <br /> Algumas regras: Não é possível selecionar perguntas anteriores a que está sendo digitada. (é uma problemática, porque somente após cadastrar todas as perguntas o usuário consegue fazer as vinculações</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13492 2020-06-22T20:06:55Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve ter uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> Solução 2: No momento do cadastro de uma pergunta</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13491 2020-06-22T19:41:27Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática 1: Qual é a primeira pergunta a respondida?<br /> <br /> Solução 1: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.<br /> <br /> Problemática 2: Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve tem uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> <br /> Solução 2:</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13490 2020-06-22T19:35:24Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> '''- Ordem de aplicação de perguntas de uma pesquisa:'''<br /> <br /> Problemática: Qual é a primeira pergunta a respondida?<br /> <br /> Solução: A primeira pergunta a ser respondida é a primeira pergunta cadastrada pelo usuário. E as perguntas seguintes irão também ser respondidas na sua ordem de cadastro, caso não hajam interações de alternativas com fluxo de perguntas.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13489 2020-06-22T19:19:12Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.<br /> <br /> '''- Relatório de pesquisa:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13488 2020-06-22T18:06:28Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução: Pode-se parametrizar intervalo de busca máxima de 3 meses. <br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13487 2020-06-22T17:32:38Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> Problemática: Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> <br /> Solução:<br /> <br /> <br /> '''- Data de início e fim do período da pesquisa:'''<br /> <br /> Problemática: No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Solução: Ao buscar pesquisas sem data de nascimento, o sistema deve considerar todas as datas a partir da data de início. Ou seja, pesquisa que não possuem uma data final, entraram nos resultados das buscas a partir da sua data de início. <br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta.<br /> <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13486 2020-06-19T15:27:54Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''<br /> <br /> <br /> <br /> '''- Relatório de pesquisa:'''<br /> <br /> <br /> <br /> '''- Ajustar componente para passar para a próxima pergunta:'''<br /> <br /> Problemática: Durante a aplicação da pesquisa, ao responder as perguntas, o usuário precisa ir até o botão flutuante para passar para a próxima pergunta. Esse fluxo não está tão intuitivo, fora que se torna cansativo ir até o botão sempre que for passar para próxima pergunta. <br /> Solução: Posicionar os botões de 'voltar' e 'próxima pergunta' logo abaixo da pergunta, para que seja mais simples essa ação para o usuário.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13485 2020-06-19T13:59:29Z

<p>Ryvanemaria: </p> <hr /> <div>'''- Definir um período de aplicação para busca listagem de pesquisa:'''</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Discuss%C3%A3o:Pesquisa&diff=13484 2020-06-19T13:58:24Z

<p>Ryvanemaria: Criou página com 'A pesquisa tem alguns comportamentos diferenciados para aplicação. Posso ter uma pesquisa que nunca ficará vencida, ou uma com uma validade determinada. No caso do filtro...'</p> <hr /> <div>A pesquisa tem alguns comportamentos diferenciados para aplicação. Posso ter uma pesquisa que nunca ficará vencida, ou uma com uma validade determinada.<br /> <br /> No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> Favor dar o seu parecer.<br /> <br /> Foi removido essa implementação devido a alguns questionamentos:<br /> <br /> Foi desabilitado pelo motivo que não existe uma regra de determinação como é a hierarquia de perguntas por exemplo: Qual é a primeira pergunta a respondida?<br /> <br /> Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve tem uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> E no desenvolvimento para responder a pesquisa ficará muito complexa e com isso poderá tem problemas de manutenção e pode ocorrer o caso de o que foi implementando não atente a ninguém.<br /> <br /> Por isso eu optei em desativar a funcionalidade de ordem de pergunta.<br /> <br /> É melhor vemos uma nova forma de realizar essa ordem e com calma e evitar dores de cabeças. Precisamos que o negócio analise esses pontos e elabore como os mesmos devem ser tratados.<br /> <br /> Ficamos no aguardo do detalhamento de como essa parte da pesquisa deve ser implementada para que possamos implementar sem mais retrabalhos.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13483 2020-06-19T13:58:16Z

<p>Ryvanemaria: Limpou toda a página</p> <hr /> <div></div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Pesquisa&diff=13482 2020-06-19T13:47:56Z

<p>Ryvanemaria: Criou página com 'A pesquisa tem alguns comportamentos diferenciados para aplicação. Posso ter uma pesquisa que nunca ficará vencida, ou uma com uma validade determinada. No caso do filtro...'</p> <hr /> <div>A pesquisa tem alguns comportamentos diferenciados para aplicação. Posso ter uma pesquisa que nunca ficará vencida, ou uma com uma validade determinada.<br /> <br /> No caso do filtro solicitado, será necessário um filtro com data de início e data de fim correto? Se for colocado o valor de data de fim, como proceder com pesquisas sem data de vencimento?<br /> <br /> Ultimamente, a questão do período máximo para pesquisa em nosso sistema tem sido muito questionado. Então, para filtros de data eu irei sempre perguntar ao negócio qual o máximo de intervalo podemos colocar para essa pesquisa. Minha sugestão são 3 meses.<br /> Favor dar o seu parecer.<br /> <br /> Foi removido essa implementação devido a alguns questionamentos:<br /> <br /> Foi desabilitado pelo motivo que não existe uma regra de determinação como é a hierarquia de perguntas por exemplo: Qual é a primeira pergunta a respondida?<br /> <br /> Para cada tipo de pergunta ao meu ver deve existe uma regra de determinação de qual é a próxima pergunta exemplo:<br /> Uma pergunta Objetiva Simples, que tem duas alternativas, as duas tem fluxos distintos só que deve tem uma regra ao meu ver novamente de não selecionar perguntas que estão acima dela, que voltamos novamente a hierarquia por que se não eu um dessas alternativas eu posso adicionar um fluxo de uma perguntar já respondida, e com isso eu a pesquisa fica falha ao tentar obter.. Se não fizemos isso e deixamos na mão do usuário teremos muita dor de cabeça futuramente.<br /> <br /> E no desenvolvimento para responder a pesquisa ficará muito complexa e com isso poderá tem problemas de manutenção e pode ocorrer o caso de o que foi implementando não atente a ninguém.<br /> <br /> Por isso eu optei em desativar a funcionalidade de ordem de pergunta.<br /> <br /> É melhor vemos uma nova forma de realizar essa ordem e com calma e evitar dores de cabeças. Precisamos que o negócio analise esses pontos e elabore como os mesmos devem ser tratados.<br /> <br /> Ficamos no aguardo do detalhamento de como essa parte da pesquisa deve ser implementada para que possamos implementar sem mais retrabalhos.</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Documenta%C3%A7%C3%B5es_da_sprint&diff=13481 2020-06-19T13:42:09Z

<p>Ryvanemaria: Criou página com '*Pesquisa'</p> <hr /> <div>*[[Pesquisa]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Neg%C3%B3cios&diff=13478 2020-06-10T13:50:18Z

<p>Ryvanemaria: </p> <hr /> <div>*[[Geosales Nuportal]]<br /> *[[Documentos - Integração]]<br /> *[[Documentos - Gerência de configurações]]<br /> *[[Documentos - Arquitetura]]<br /> *[[Documentações da sprint]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13444 2020-05-08T23:07:37Z

<p>Ryvanemaria: </p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 07/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada ‘Venda Fator’, que altera o valor da nota pela metade. Essa modalidade carece de um segundo tipo de condição e meio de pagamento, que deve ser inserido no momento do cadastro do pedido.<br /> <br /> == Solução ==<br /> <br /> No cadastro de pedidos do GeoSales serão incluídos dois campos, um para o usuário cadastrar a segunda condição de pagamento, e outro para o usuário cadastrar o segundo meio de pagamento. <br /> <br /> Será criado no GeoSales um tipo de pedido chamado 'Venda Fator', que irá ativar a exibição dos campos meio e condição de pagamento secundários. <br /> <br /> Caso o pedido seja do tipo 'venda fator', será feita uma tratativa no ERP para que o valor do pedido seja cortado pela metade. Esse cenário ocorrerá exclusivamente no ERP e será responsabilidade da Casas Freitas criar e dar manutenção a essa consulta. Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao GeoSales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Para viabilizar esse procedimento, o GeoSales irá habilitar, para o pedido do tipo 'Venda Fator', os dois novos campos, de meio e condição de pagamento.<br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de meio e de condição de pagamento:'''<br /> <br /> Serão criados dois campos para que o usuário possa preencher um segundo meio e uma segunda condição de pagamento no GeoSales. Esses campos serão habilitados de acordo com o tipo do pedido, neste caso, de 'Venda Fator'. <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de 'Venda Fator'. Ou seja, é de responsabilidade exclusiva da Casa Freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento são obrigatórios para pedidos do tipo 'Venda Fator'. <br /> <br /> '''[RN6] - ''' O GeoSales irá sinalizar na integração o tipo de pedido 'venda fator', que será integrado como qualquer outro pedido. <br /> <br /> '''[RN7] - ''' É importante salientar que os dois campos de condição ou meio de pagamento são independentes, ou seja a escolha de uma condição ou meio no primeiro campo, não interfere na condição ou meio do segundo campo.<br /> <br /> '''[RN8] - ''' As regras de seleção de meio e condição de pagamento do segundo campo seguirão as mesmas regras do primeiro campo padrão.<br /> <br /> '''[RN9] - ''' Só serão consideradas para ativação de regras no GeoSales, o meio e condição de pagamento cadastrado no campo padrão (primeiro campo) do GeoSales. O segundo campo de meio e condição de pagamento tem finalidade exclusiva de sinalização ao ERP.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Líder Técnico - GeoSales || Anderson Gomes || 08/05/2020<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13435 2020-05-08T16:15:00Z

<p>Ryvanemaria: /* Regras de Negócios */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 07/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada ‘Venda Fator’, que altera o valor da nota pela metade. Essa modalidade carece de um segundo tipo de condição e meio de pagamento, que deve ser inserido no momento do cadastro do pedido.<br /> <br /> == Solução ==<br /> <br /> No cadastro de pedidos do GeoSales serão incluídos dois campos, um para o usuário cadastrar a segunda condição de pagamento, e outro para o usuário cadastrar o segundo meio de pagamento. <br /> <br /> O tipo de pedido ‘Venda Fator’ será identificado no GeoSales através do preenchimento desses dois novos campos. Esses campos serão como uma verificação no momento da integração do pedido do GeoSales para o ERP. <br /> <br /> Caso o pedido tenha sido preenchido com esses dois campos e integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá exclusivamente no ERP e será responsabilidade da Casas Freitas criar e dar manutenção a essa consulta. Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao GeoSales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Para viabilizar esse procedimento, o GeoSales irá habilitar, para o pedido de venda, os dois novos campos, de meio e condição de pagamento.<br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de meio e de condição de pagamento:'''<br /> <br /> Serão criados dois campos para que o usuário possa preencher um segundo meio e uma segunda condição de pagamento no GeoSales. Esses campos serão habilitados de acordo com o tipo do pedido, neste caso, de venda. <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa Freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' O GeoSales não irá sinalizar o tipo de pedido 'venda fator', essa modalidade será sinaliza apenas caso o vendedor preencha o segundo meio e condição de pagamento. <br /> <br /> '''[RN7] - ''' É importante salientar que os dois campos de condição ou meio de pagamento são independentes, ou seja a escolha de uma condição ou meio no primeiro campo, não interfere na condição ou meio do segundo campo.<br /> <br /> '''[RN8] - ''' As regras de seleção de meio e condição de pagamento do segundo campo seguirão as mesmas regras do primeiro campo padrão.<br /> <br /> '''[RN9] - ''' Só serão consideradas para ativação de regras no GeoSales, o meio e condição de pagamento cadastrado no campo padrão (primeiro campo) do GeoSales. O segundo campo de meio e condição de pagamento tem finalidade exclusiva de sinalização ao ERP.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || || 00/05/2020<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13434 2020-05-08T16:10:42Z

<p>Ryvanemaria: /* GeoSales */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 07/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada ‘Venda Fator’, que altera o valor da nota pela metade. Essa modalidade carece de um segundo tipo de condição e meio de pagamento, que deve ser inserido no momento do cadastro do pedido.<br /> <br /> == Solução ==<br /> <br /> No cadastro de pedidos do GeoSales serão incluídos dois campos, um para o usuário cadastrar a segunda condição de pagamento, e outro para o usuário cadastrar o segundo meio de pagamento. <br /> <br /> O tipo de pedido ‘Venda Fator’ será identificado no GeoSales através do preenchimento desses dois novos campos. Esses campos serão como uma verificação no momento da integração do pedido do GeoSales para o ERP. <br /> <br /> Caso o pedido tenha sido preenchido com esses dois campos e integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá exclusivamente no ERP e será responsabilidade da Casas Freitas criar e dar manutenção a essa consulta. Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao GeoSales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Para viabilizar esse procedimento, o GeoSales irá habilitar, para o pedido de venda, os dois novos campos, de meio e condição de pagamento.<br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de meio e de condição de pagamento:'''<br /> <br /> Serão criados dois campos para que o usuário possa preencher um segundo meio e uma segunda condição de pagamento no GeoSales. Esses campos serão habilitados de acordo com o tipo do pedido, neste caso, de venda. <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa Freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' O GeoSales não irá sinalizar o tipo de pedido 'venda fator', essa modalidade será sinaliza apenas caso o vendedor preencha o segundo meio e condição de pagamento. <br /> <br /> '''[RN7] - ''' É importante salientar que os dois campos de condição ou meio de pagamento são independentes, ou seja a escolha de uma condição ou meio no primeiro campo, não interfere na condição ou meio do segundo campo.<br /> <br /> '''[RN8] - ''' As regras de seleção de meio e condição de pagamento do segundo campo seguirão as mesmas regras do primeiro campo padrão.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || || 00/05/2020<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13433 2020-05-08T16:09:53Z

<p>Ryvanemaria: /* Regras de Negócios */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 07/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada ‘Venda Fator’, que altera o valor da nota pela metade. Essa modalidade carece de um segundo tipo de condição e meio de pagamento, que deve ser inserido no momento do cadastro do pedido.<br /> <br /> == Solução ==<br /> <br /> No cadastro de pedidos do GeoSales serão incluídos dois campos, um para o usuário cadastrar a segunda condição de pagamento, e outro para o usuário cadastrar o segundo meio de pagamento. <br /> <br /> O tipo de pedido ‘Venda Fator’ será identificado no GeoSales através do preenchimento desses dois novos campos. Esses campos serão como uma verificação no momento da integração do pedido do GeoSales para o ERP. <br /> <br /> Caso o pedido tenha sido preenchido com esses dois campos e integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá exclusivamente no ERP e será responsabilidade da Casas Freitas criar e dar manutenção a essa consulta. Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao GeoSales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Para viabilizar esse procedimento, o GeoSales irá habilitar, para o pedido de venda, os dois novos campos, de meio e condição de pagamento.<br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de meio e de condição de pagamento:'''<br /> <br /> Serão criados dois campos para que o usuário possa preencher um segundo meio e uma segunda condição de pagamento no GeoSales. Esses campos serão habilitados de acordo com o tipo do pedido, neste caso, de venda. <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa Freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' O GeoSales não irá sinalizar o tipo de pedido 'venda fator', essa modalidade será sinaliza apenas caso o vendedor preencha o segundo meio e condição de pagamento. <br /> <br /> '''[RN7] - ''' É importante salientar que os dois campos de condição ou meio de pagamento são independentes, ou seja a escolha de uma condição ou meio no primeiro campo, não interfere na condição ou meio do segundo campo.<br /> <br /> '''[RN8] - ''' As regras de seleção de meio e condição de pagamento do segundo campo seguirão as mesmas regras do primeiro campo padrão.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13432 2020-05-08T15:05:27Z

<p>Ryvanemaria: </p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 07/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada ‘Venda Fator’, que altera o valor da nota pela metade. Essa modalidade carece de um segundo tipo de condição e meio de pagamento, que deve ser inserido no momento do cadastro do pedido.<br /> <br /> == Solução ==<br /> <br /> No cadastro de pedidos do GeoSales serão incluídos dois campos, um para o usuário cadastrar a segunda condição de pagamento, e outro para o usuário cadastrar o segundo meio de pagamento. <br /> <br /> O tipo de pedido ‘Venda Fator’ será identificado no GeoSales através do preenchimento desses dois novos campos. Esses campos serão como uma verificação no momento da integração do pedido do GeoSales para o ERP. <br /> <br /> Caso o pedido tenha sido preenchido com esses dois campos e integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá exclusivamente no ERP e será responsabilidade da Casas Freitas criar e dar manutenção a essa consulta. Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao GeoSales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Para viabilizar esse procedimento, o GeoSales irá habilitar, para o pedido de venda, os dois novos campos, de meio e condição de pagamento.<br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de meio e de condição de pagamento:'''<br /> <br /> Serão criados dois campos para que o usuário possa preencher um segundo meio e uma segunda condição de pagamento no GeoSales. Esses campos serão habilitados de acordo com o tipo do pedido, neste caso, de venda. <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa Freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' O GeoSales não irá sinalizar o tipo de pedido 'venda fator', essa modalidade será sinaliza apenas caso o vendedor preencha o segundo meio e condição de pagamento. <br /> <br /> '''[RN7] - ''' <br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_fator&diff=13431 2020-05-08T13:49:17Z

<p>Ryvanemaria: Criou página com '== Histórico de Alterações == {| class=&quot;wikitable&quot; ! Data ! Quem ! Comentários |- | 06/05/2020 || Ryvane Maria || Criação do documento |} == Necessidade == Existe...'</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 06/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada <br /> <br /> Algumas regiões o tipo de pedido ‘Venda Fator’ altera o valor da nota pela metade. Para atender a necessidade citada, no Geosales será criada o tipo de pedido ‘Venda Fator’, mas a seleção desse tipo de pedido não irá alterar o preço do produto, ou seja, o produto será exibido com o valor cheio.<br /> <br /> == Solução ==<br /> <br /> <br /> O tipo de pedido ‘Venda Fator’ será utilizado como uma verificação no momento da integração do pedido do Geosales para o ERP. Caso o pedido esteja com o tipo de pedido ‘Venda Fator’ e for integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá somente dentro do ERP e será responsabilidade da Casas Freitas criar e dar manutenção nessa consulta.<br /> <br /> Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao Geosales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Caso o tipo de pedido selecionado seja ‘Venda Fator’ o Geosales disponibilizará dois meios de pagamento e duas condições de pagamento. Para a primeira forma de pagamento e condição de pagamento, será utilizada na nota fiscal.<br /> <br /> <br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de condição de pagamento:'''<br /> <br /> <br /> '''- Criar segundo campo de meio de pagamento:'''<br /> <br /> <br /> '''- Sa:'''<br /> <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' É <br /> <br /> '''[RN7] - ''' Cas<br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Projeto/Casa_Freitas&diff=13430 2020-05-08T13:48:41Z

<p>Ryvanemaria: </p> <hr /> <div>[[Venda fator]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Projeto/Casa_Freitas&diff=13429 2020-05-08T13:48:31Z

<p>Ryvanemaria: </p> <hr /> <div>[[Venda fator]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_forma&diff=13428 2020-05-08T13:48:05Z

<p>Ryvanemaria: Limpou toda a página</p> <hr /> <div></div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_forma&diff=13427 2020-05-08T13:47:43Z

<p>Ryvanemaria: /* Necessidade */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 06/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Existe uma modalidade de venda chamada <br /> <br /> Algumas regiões o tipo de pedido ‘Venda Fator’ altera o valor da nota pela metade. Para atender a necessidade citada, no Geosales será criada o tipo de pedido ‘Venda Fator’, mas a seleção desse tipo de pedido não irá alterar o preço do produto, ou seja, o produto será exibido com o valor cheio.<br /> <br /> == Solução ==<br /> <br /> <br /> O tipo de pedido ‘Venda Fator’ será utilizado como uma verificação no momento da integração do pedido do Geosales para o ERP. Caso o pedido esteja com o tipo de pedido ‘Venda Fator’ e for integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá somente dentro do ERP e será responsabilidade da Casas Freitas criar e dar manutenção nessa consulta.<br /> <br /> Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao Geosales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Caso o tipo de pedido selecionado seja ‘Venda Fator’ o Geosales disponibilizará dois meios de pagamento e duas condições de pagamento. Para a primeira forma de pagamento e condição de pagamento, será utilizada na nota fiscal.<br /> <br /> <br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de condição de pagamento:'''<br /> <br /> <br /> '''- Criar segundo campo de meio de pagamento:'''<br /> <br /> <br /> '''- Sa:'''<br /> <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' É <br /> <br /> '''[RN7] - ''' Cas<br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_forma&diff=13426 2020-05-08T13:26:41Z

<p>Ryvanemaria: </p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 06/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Algumas regiões o tipo de pedido ‘Venda Fator’ altera o valor da nota pela metade. Para atender a necessidade citada, no Geosales será criada o tipo de pedido ‘Venda Fator’, mas a seleção desse tipo de pedido não irá alterar o preço do produto, ou seja, o produto será exibido com o valor cheio.<br /> <br /> <br /> == Solução ==<br /> <br /> <br /> O tipo de pedido ‘Venda Fator’ será utilizado como uma verificação no momento da integração do pedido do Geosales para o ERP. Caso o pedido esteja com o tipo de pedido ‘Venda Fator’ e for integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá somente dentro do ERP e será responsabilidade da Casas Freitas criar e dar manutenção nessa consulta.<br /> <br /> Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao Geosales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Caso o tipo de pedido selecionado seja ‘Venda Fator’ o Geosales disponibilizará dois meios de pagamento e duas condições de pagamento. Para a primeira forma de pagamento e condição de pagamento, será utilizada na nota fiscal.<br /> <br /> <br /> <br /> == Implementação GeoSales ==<br /> <br /> '''- Criar segundo campo de condição de pagamento:'''<br /> <br /> <br /> '''- Criar segundo campo de meio de pagamento:'''<br /> <br /> <br /> '''- Sa:'''<br /> <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> <br /> '''[RN2] - ''' O segundo meio de pagamento e a segunda condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não serão exibidas em nenhum relatório de pedidos do GeoSales.<br /> <br /> '''[RN3] - ''' O segundo meio de pagamento e a segunda condição de pagamento serão destinados a venda fator. Caberá ao usuário selecionar as opções desejadas. <br /> <br /> '''[RN4] - ''' O GeoSales não irá realizar o rateio de valor nos pedidos de Venda. Ou seja, é de responsabilidade exclusiva da Casa freitas realizar os ajustes necessários no valor do pedido dessa modalidade de venda.<br /> <br /> '''[RN5] - ''' O preenchimento dos campos de segundo meio e condição de pagamento não são obrigatórios no pedido. <br /> <br /> '''[RN6] - ''' É <br /> <br /> '''[RN7] - ''' Cas<br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Venda_forma&diff=13425 2020-05-08T12:15:34Z

<p>Ryvanemaria: Criou página com '== Histórico de Alterações == {| class=&quot;wikitable&quot; ! Data ! Quem ! Comentários |- | 06/05/2020 || Ryvane Maria || Criação do documento |} == Necessidade == Algumas...'</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 06/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Algumas regiões o tipo de pedido ‘Venda Fator’ altera o valor da nota pela metade. Para atender a necessidade citada, no Geosales será criada o tipo de pedido ‘Venda Fator’, mas a seleção desse tipo de pedido não irá alterar o preço do produto, ou seja, o produto será exibido com o valor cheio.<br /> <br /> O tipo de pedido ‘Venda Fator’ será utilizado como uma verificação no momento da integração do pedido do Geosales para o ERP. Caso o pedido esteja com o tipo de pedido ‘Venda Fator’ e for integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá somente dentro do ERP e será responsabilidade da Casas Freitas criar e dar manutenção nessa consulta.<br /> <br /> Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao Geosales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> Caso o tipo de pedido selecionado seja ‘Venda Fator’ o Geosales disponibilizará dois meios de pagamento e duas condições de pagamento. Para a primeira forma de pagamento e condição de pagamento, será utilizada na nota fiscal.<br /> <br /> A segunda forma de pagamento e condição de pagamento será destinada a venda fator. Caberá ao usuário selecionar as opções desejadas. Saliento que a segunda forma e condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não será exibida em nenhum relatório de pedidos do Geosales.<br /> <br /> == Solução ==<br /> <br /> <br /> == Implementação ==<br /> <br /> '''- Cr:'''<br /> <br /> <br /> <br /> '''- Sa:'''<br /> <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' O <br /> <br /> '''[RN2] - ''' A <br /> <br /> '''[RN3] - ''' A<br /> <br /> '''[RN4] - ''' C<br /> <br /> '''[RN5] - ''' As<br /> <br /> '''[RN6] - ''' É <br /> <br /> '''[RN7] - ''' Cas<br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Projeto/Casa_Freitas&diff=13424 2020-05-08T12:15:24Z

<p>Ryvanemaria: Página substituída por 'Venda forma'</p> <hr /> <div>[[Venda forma]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Projeto/Casa_Freitas&diff=13423 2020-05-07T00:58:33Z

<p>Ryvanemaria: Criou página com '== Histórico de Alterações == {| class=&quot;wikitable&quot; ! Data ! Quem ! Comentários |- | 06/05/2020 || Ryvane Maria || Criação do documento |} == Necessidade == Algumas...'</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 06/05/2020 || Ryvane Maria || Criação do documento<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Algumas regiões o tipo de pedido ‘Venda Fator’ altera o valor da nota pela metade. Para atender a necessidade citada, no Geosales será criada o tipo de pedido ‘Venda Fator’, mas a seleção desse tipo de pedido não irá alterar o preço do produto, ou seja, o produto será exibido com o valor cheio.<br /> <br /> O tipo de pedido ‘Venda Fator’ será utilizado como uma verificação no momento da integração do pedido do Geosales para o ERP. Caso o pedido esteja com o tipo de pedido ‘Venda Fator’ e for integrado ao ERP, o valor do pedido será cortado pela metade. Esse cenário ocorrerá somente dentro do ERP e será responsabilidade da Casas Freitas criar e dar manutenção nessa consulta.<br /> <br /> Além disso, a Casas Freitas deverá garantir que no momento do retorno do pedido do ERP ao Geosales, os pedidos do tipo ‘Venda Fator’, venham com o valor cheio.<br /> <br /> Vale salientar que não haverá integração de nota fiscal ao GeoSales, será tratado somente o status do pedido.<br /> Caso o tipo de pedido selecionado seja ‘Venda Fator’ o Geosales disponibilizará dois meios de pagamento e duas condições de pagamento. Para a primeira forma de pagamento e condição de pagamento, será utilizada na nota fiscal.<br /> <br /> A segunda forma de pagamento e condição de pagamento será destinada a venda fator. Caberá ao usuário selecionar as opções desejadas. Saliento que a segunda forma e condição de pagamento só estarão disponíveis no cadastro do pedido, ou seja, não será exibida em nenhum relatório de pedidos do Geosales.<br /> <br /> == Solução ==<br /> <br /> <br /> == Implementação ==<br /> <br /> '''- Cr:'''<br /> <br /> <br /> <br /> '''- Sa:'''<br /> <br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' O <br /> <br /> '''[RN2] - ''' A <br /> <br /> '''[RN3] - ''' A<br /> <br /> '''[RN4] - ''' C<br /> <br /> '''[RN5] - ''' As<br /> <br /> '''[RN6] - ''' É <br /> <br /> '''[RN7] - ''' Cas<br /> <br /> '''[RN8] - ''' <br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Gerente TI - GeoSales || Leonardo Sousa || 18/12/2018<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Projetos&diff=13422 2020-05-06T23:00:11Z

<p>Ryvanemaria: </p> <hr /> <div>'''Projetos realizados pela Softsite'''<br /> <br /> *[[Projeto/AAF|AAF]]<br /> *[[Projeto/AGROSEMA|AGROSEMA]]<br /> *[[Projeto/ALL ALIMENTOS|ALL ALIMENTOS]]<br /> *[[Projeto/ANHAMBI|ANHAMBI]]<br /> *[[Projeto/AUSTER|AUSTER]]<br /> *[[Projeto/BACKER|BACKER]]<br /> *[[Projeto/BelMetal|BelMetal]]<br /> *[[Projeto/Camil|Camil]]<br /> *[[Projeto/Campneus|Campneus]]<br /> *[[Projeto/CriaSim|CriaSim]]<br /> *[[Projeto/Casakm|CasaKm]]<br /> *[[Projeto/Casa Freitas|Casa Freitas]]<br /> *[[Projeto/Casio|Casio]]<br /> *[[Projeto/Damare|Damare]]<br /> *[[Projeto/Davene|Davene]]<br /> *[[Projeto/Delrio|Delrio]]<br /> *[[Projeto/Dovac|Dovac]]<br /> *[[Projeto/Estrella Galicia|Estrella Galicia]]<br /> *[[Projeto/Expressa|Expressa]]<br /> *[[Projeto/Famiglia Zanlorenzi|Famiglia Zanlorenzi]]<br /> *[[Projeto/Forno de Minas|Forno de Minas]]<br /> *[[Projeto/Futuragro|Futuragro]]<br /> *[[Projeto/Frugal|Frugal]]<br /> *[[Projeto/FerroNorte|FerroNorte]]<br /> *[[Projeto/Guaraves|Guaraves]]<br /> *[[Projeto/Gart|Gart]]<br /> *[[Projeto/GTFoods|GTFoods]]<br /> *[[Projeto/Golden Vision|Golden Vision]]<br /> *[[Projeto/Gran Palatto|Gran Palatto]]<br /> *[[Projeto/Hafele|Hafele]]<br /> *[[Projeto/Hileia|Hileia]]<br /> *[[Projeto/Hugo Cini|Hugo Cini]]<br /> *[[Projeto/Icofort|Icofort]]<br /> *[[Projeto/Isdra|Isdra]]<br /> *[[Projeto/Lebrinha|Lebrinha]]<br /> *[[Projeto/Lifemed|Lifemed]]<br /> *[[Projeto/Lorenfer|Lorenfer]]<br /> *[[Projeto/Mais Próxima|Mais Próxima]]<br /> *[[Projeto/Makita|Makita]]<br /> *[[Projeto/Minorgan|Minorgan]]<br /> *[[Projeto/MIZU|MIZU]]<br /> *[[Projeto/Motasa|Motasa]]<br /> *[[Projeto/Montana Química|Montana Química]]<br /> *[[Projeto/Mypa|Mypa]]<br /> *[[Projeto/Ourolux|Ourolux]]<br /> *[[Projeto/Pão da Hora|Pão da Hora]]<br /> *[[Projeto/Palusa|Palusa]]<br /> *[[Projeto/Plastilit|Plastilit]]<br /> *[[Projeto/Premix|Premix]]<br /> *[[Projeto/Produto|Produto]]<br /> *[[Projeto/RealAlimentos|Real Alimentos]]<br /> *[[Projeto/Rio Mix|Rio Mix]]<br /> *[[Projeto/Reflexa|Reflexa]]<br /> *[[Projeto/Sabe|Sabe]]<br /> *[[Projeto/SAINT BIER|SAINT BIER]]<br /> *[[Projeto/Santa Helena|Santa Helena]]<br /> *[[Projeto/Serveng|Serveng]]<br /> *[[Projeto/Sigvaris|Sigvaris]]<br /> *[[Projeto/Sonora|Sonora]]<br /> *[[Projeto/Vale do Sol|Vale do Sol]]<br /> *[[Projeto/VB ALIMENTOS|VB ALIMENTOS]]<br /> *[[Projeto/Yama|Yama]]<br /> *[[Projeto/Wow|Wow]]<br /> *[[Projeto/NeoGrid|NeoGrid]]</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13385 2020-04-07T12:10:19Z

<p>Ryvanemaria: /* Empresa solicitante */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> '''[RN8] - ''' A parametrização por cliente não é obrigatória no GeoSales.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || || 00/00/0000<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> |- <br /> | Gerente de Projeto - Cliente || || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13384 2020-04-07T12:09:38Z

<p>Ryvanemaria: /* Empresa solicitante */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> '''[RN8] - ''' A parametrização por cliente não é obrigatória no GeoSales.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || || 00/00/0000<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13383 2020-04-07T12:09:15Z

<p>Ryvanemaria: /* GeoSales */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> '''[RN8] - ''' A parametrização por cliente não é obrigatória no GeoSales.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || || 00/00/0000<br /> |- <br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |-<br /> | Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13382 2020-04-03T18:27:33Z

<p>Ryvanemaria: /* Implementação */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> '''[RN8] - ''' A parametrização por cliente não é obrigatória no GeoSales.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |- <br /> | Integração - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> | Configurações - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |-<br /> | Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13381 2020-04-03T18:17:53Z

<p>Ryvanemaria: /* Regras de Negócios */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto,, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> '''[RN8] - ''' A parametrização por cliente não é obrigatória no GeoSales.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |- <br /> | Integração - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> | Configurações - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |-<br /> | Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Discuss%C3%A3o:Cotas_de_venda&diff=13380 2020-04-03T18:13:29Z

<p>Ryvanemaria: </p> <hr /> <div>Observações:<br /> <br /> &lt;del&gt;Não ficou claro o funcionamento da funcionalidade de cota. Seria bom definir o que é a cota e como ela funciona e a partir disso evidenciar as modificações que devem ser feitas na funcionalidade.&lt;/del&gt;<br /> <br /> Outra coisa importante é colocar um contraponto entre a funcionalidade de cota atual da tabela de cota_produto e as modificações que deverão ser feitas na tabela de forma um pouco mais específico.<br /> RESPOSTA: NA TABELA SERÁ NECESSÁRIO INCLUIR O CAMPO DE FAMILIA DE PRODUTOS (CD_FAMILIA), E O CAMPO DE COMPORTAMENTO (ID_...)<br /> <br /> &lt;del&gt;Não conheço a funcionalidade de cota e para mim não foi muito claro o funcionamento nem o que deve ser feito com exceção da pendência que está bem claro. Seria interessante evidenciar o cenário de uma venda em que as 3 situações de pendência/bloqueio e nada acontecessem.&lt;/&lt;del&gt;<br /> <br /> Sobre os filtros, período de vigência da regra, produto, família de produtos, cliente e vendedor, é preciso saber quais são obrigatórios e também sobre a prioridade de aplicação entre eles. Existirão vários cenários conflitantes, como o sistema deve se comportar? Qual a quantidade deve ser pegue, a mais específica, a maior, a menor? Isso deve estar definido no documento.<br /> <br /> É importante definir os dados originais para que a construção dos dados na tabela sejam corretos:<br /> Esses dados serão buscados na tabela e campos XXX do ERP. (a definir). Tivemos vários casos em que por não saber como o campo era no erp os dados foram construídos de forma errada e queremos evitar isso.<br /> <br /> Também é importante mostrar o cenário de validação com múltiplos períodos de análise com por exemplo 2 regras de cotas. Colocar aquele cenário que eu te falei no suporte.<br /> <br /> <br /> '''cenário 2, cota2 permitindo venda para cliente D<br /> Dados:<br /> O vendedor A tem uma cota (cota2) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2019-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades de produto 1.<br /> Resultado esperado:<br /> cota2 não é estourada (total de 2 produtos no intervalo da cota) e proíbe a venda<br /> <br /> '''cenário 3, cota3 permitindo venda para cliente D'''<br /> Dados:<br /> O vendedor A tem uma cota (cota3) de produto 1, para o cliente A. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente A duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> nenhuma cota é ativada para o cliente D, logo nenhuma cota estoura<br /> <br /> '''cenário 4, cota4 permitindo venda para o cliente D'''<br /> Dados:<br /> O vendedor A tem uma cota (cota4) do produto 1, para o cliente C. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor B tenta vender para o cliente D duas unidades do produto 1<br /> Resultado esperado:<br /> nenhuma cota é ativada para O vendedor B, logo nenhuma cota estoura<br /> <br /> '''cenário 5, cota6 proibindo venda para Carol'''<br /> Dados:<br /> O vendedor A tem uma cota (cota5) do produto 1, para o cliente C. A cota é de 4, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A tem uma cota (cota6) do produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor A tenta vender para o cliente C duas unidades do produto 1<br /> Resultado esperado:<br /> cota6 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13379 2020-04-03T18:13:17Z

<p>Ryvanemaria: /* Implementação */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto,, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |- <br /> | Integração - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> | Configurações - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |-<br /> | Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Cotas_de_venda&diff=13370 2020-03-26T14:08:55Z

<p>Ryvanemaria: /* Implementação */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 02/01/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Aplicação de cotas de vendas de produtos por vendedor objetivando-se realizar um controle sobre o volume de vendas de um vendedor, através de um sistema de cotas de vendas definido previamente.<br /> <br /> == Solução == <br /> <br /> A cota de venda determina um limite a ser respeitado no momento da venda, tento como critérios diversos parâmetros previamente definidos.<br /> <br /> Será criada no GeoSales uma estrutura com finalidade de persistir os dados de cotas de venda, que serão trazidos do ERP via integração de dados. Dessa estrutura serão extraídas as informações necessárias para realizar a validação de contas de vendas no GeoSales, ao passo do cadastro de pedidos.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar estrutura para receber os dados de cotas de vendas:'''<br /> <br /> Inicialmente, será criada no ambiente do GeoSales uma estrutura de dados capaz de salvar as informações de cotas de vendas. Nessa estrutura, serão persistidas as informações de: Volume de vendas (quantidade de itens), período de vigência da regra, produto,, cliente e vendedor.<br /> <br /> Além disso, deverá ser criado um campo com finalidade de definir o comportamento da regra a ser aplicada, este campo poderá receber os valores: 'B' para regra que bloqueie a venda, 'P' para regra que torne o pedido pendente, e 'A', para regras onde o usuário será apenas alertado da situação. <br /> <br /> '''- Integrar os dados de cadastro de cotas de vendas:'''<br /> <br /> Com finalidade de alimentar a estrutura anteriormente criada, será realizada uma tratativa na integração atual, para que sejam buscados os dados de cotas de vendas do Protheus.<br /> <br /> Esses dados serão buscados na tabela e campos do ERP a serem definidos antes da assinatura deste documento.<br /> <br /> '''- Validar a cota de vendas no cadastro de pedidos:'''<br /> <br /> O GeoSales irá validar, no momento do cadastro do pedido, o limite da cota de vendas a ser aplicado no pedido, de acordo com o cadastro realizado no ERP. Caso hajam cotas cadastradas para o cenário definido no momento da inserção do pedido, o GeoSales irá limitar a venda a quantidade de itens cadastrada na cota.<br /> <br /> A definição de qual resultado será oriundo da validação de cotas será feita no ERP. Existem três cenários possíveis para validação, onde será definido através de um campo na estrutura de cotas do GeoSales. Caso este campo esteja setado com o valor'B' a venda deverá ser bloqueada, e o pedido não poderá ser salvo, caso esteja setado com o valor 'P' o pedido ficará pendente, e aguardará aprovação, e caso esteja setado com o valor 'A', o usuário será apenas alertado da situação, sem que haja pendências ou bloqueios.<br /> <br /> É importante salientar que, ao editar um pedido, o limite de cotas será validado novamente, de acordo com os parâmetros definidos no dia da edição do pedido, bem como nas alterações realizadas.<br /> <br /> <br /> '''- Cenários para validação:'''<br /> <br /> Considerando para os cenários abaixo os vendedores A e B; os clientes C e D; e os produtos 1 e 2.<br /> <br /> '''cenário 1, cota1 proibindo venda para o vendedor A'''<br /> Dados:<br /> O vendedor A tem uma cota (cota1) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades de produto 1, no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> cota1 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> '''cenário 2, cota2 permitindo venda para cliente D<br /> Dados:<br /> O vendedor A tem uma cota (cota2) de produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2019-01-03.<br /> Ação:<br /> Em 2020-01-09, o vendedor A tenta vender para o cliente D duas unidades de produto 1.<br /> Resultado esperado:<br /> cota2 não é estourada (total de 2 produtos no intervalo da cota) e proíbe a venda<br /> <br /> '''cenário 3, cota3 permitindo venda para cliente D'''<br /> Dados:<br /> O vendedor A tem uma cota (cota3) de produto 1, para o cliente A. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente A duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor A tenta vender para o cliente D duas unidades do produto 1.<br /> Resultado esperado:<br /> nenhuma cota é ativada para o cliente D, logo nenhuma cota estoura<br /> <br /> '''cenário 4, cota4 permitindo venda para o cliente D'''<br /> Dados:<br /> O vendedor A tem uma cota (cota4) do produto 1, para o cliente C. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor B tenta vender para o cliente D duas unidades do produto 1<br /> Resultado esperado:<br /> nenhuma cota é ativada para O vendedor B, logo nenhuma cota estoura<br /> <br /> '''cenário 5, cota6 proibindo venda para Carol'''<br /> Dados:<br /> O vendedor A tem uma cota (cota5) do produto 1, para o cliente C. A cota é de 4, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A tem uma cota (cota6) do produto 1, independente de cliente. A cota é de 3, válida de 2020-01-01 até 2020-02-01<br /> O vendedor A vendeu para o cliente C duas unidades do produto 1 no dia 2020-01-03.<br /> Ação:<br /> Em 2020-01-09, O vendedor A tenta vender para o cliente C duas unidades do produto 1<br /> Resultado esperado:<br /> cota6 é estourada (total de 4 produtos no intervalo da cota) e proíbe a venda<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A implementação da funcionalidade de cotas de venda será realizado exclusivamente no Portal GEOSALES EVO.<br /> <br /> '''[RN2] - ''' Não será possível que o usuário consulte no GeoSales as regras previamente cadastradas no ERP, tendo em vista que não haverá cadastro dessas informações no GeoSales.<br /> <br /> '''[RN3] - ''' A validação de controle de cotas de venda será feita também no aplicativo GeoSales Mobile.<br /> <br /> '''[RN4] - ''' Caso o usuário ultrapasse a sua cota de vendas para algum item inserido no pedido, não será possível salvar o pedido.<br /> <br /> '''[RN5] - ''' É importante salientar que é de responsabilidade do usuário o cadastro correto das informações de cota no ERP, bem como o comportamento que ela irá aplicar no pedido.<br /> <br /> '''[RN6] - ''' É importante salientar, também, que caso existam mais de um cenário de cotas cadastrado para o mesmo período vigente, o GeoSales irá considerar todas as regras vigentes, ou seja, todas as regras cadastradas serão validadas.<br /> <br /> '''[RN7] - ''' O Geosales irá considerar o saldo restante da regra de cotas, ou seja, caso o usuário tenha pedidos cadastrados anteriormente durante o período vigente da cota, esses pedidos também irão ser considerados para que seja validada a cota.<br /> <br /> == Regras de Integração ==<br /> <br /> '''[RI1] - ''' O cadastro de cotas de venda deverá ser feito exclusivamente no Protheus. Portanto, será de responsabilidade da Damare o cadastro correto dessas informações.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação no Sistema GeoSales, em nome da Organização a qual estou vinculado.<br /> <br /> === GeoSales ===<br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> <br /> |- <br /> | Desenvolvimento - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |- <br /> | Integração - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> | Configurações - GeoSales || Pessoa que aprovou || 00/00/0000<br /> |-<br /> |}<br /> <br /> === Empresa solicitante === <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! Aprovado Por<br /> ! Data<br /> ! Assinatura<br /> |-<br /> | Gerente TI - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente de Projeto - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> | Gerente Comercial - Cliente || Pessoa que aprovou || 00/00/0000 ||<br /> |- <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Inclus%C3%A3o_de_campo_no_relat%C3%B3rio_de_resumo_do_pedido&diff=13331 2020-03-17T18:27:41Z

<p>Ryvanemaria: /* Necessidade */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 10/03/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> | 17/03/2020 || Ryvane Maria || Alteração do relatório de faturamento para o relatório de resumo do pedido<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Criação de um novo campo no relatório de resumo de pedido do GeoSales EVO, com finalidade de informar se o cliente é simples nacional ou não.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar campos no relatório de resumo de pedido:'''<br /> <br /> Será incluído no relatório de resumo de pedido do portal GeoSales EVO um campo com finalidade de informar se o cliente é simples nacional ou não. Esse campo poderá ser visualizado no relatório em formato PDF. Esse campo será preenchido com 'Sim' ou 'Não', de acordo com as informações integradas do ERP.<br /> <br /> '''- Criar campo na tabela de clientes:'''<br /> <br /> Com finalidade de salvar as informações integradas, será criado um campo na tabela CLIENTE, especificando se o cliente é simples nacional ou não. Desse campo que serão extraídas a informação a ser exibida no relatório de resumo de pedido.<br /> <br /> '''- Integração de dados:'''<br /> <br /> A informação que define se o cliente é simples nacional ou não deverá ser buscada na tabela SA1, através do campo A1_SIMPNAC. Esse campo no ERP é preenchido com o valor 1, 2 ou vazio. Onde o valor '1' representa que SIM, o cliente é simples nacional, o valor '2' representa que NÃO, e caso o campo esteja vazio representa que não há informação cadastrada.<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A customização descrita neste documento será implementada exclusivamente no portal GeoSales EVO. <br /> <br /> '''[RN2] - ''' Para que essa informação seja exibida no relatório de resumo de pedido, ela deve ser corretamente e previamente cadastrada no campo A1_SIMPNAC da tabela SA1.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || Anderson Gomes || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria http://wiki.geosales.com.br:8000/index.php?title=Inclus%C3%A3o_de_campo_no_relat%C3%B3rio_de_resumo_do_pedido&diff=13330 2020-03-17T18:27:10Z

<p>Ryvanemaria: /* Necessidade */</p> <hr /> <div>== Histórico de Alterações ==<br /> {| class=&quot;wikitable&quot;<br /> ! Data<br /> ! Quem <br /> ! Comentários <br /> |-<br /> | 10/03/2020 || Ryvane Maria || Criação do documento<br /> |-<br /> | 17/03/2020 || Ryvane Maria || Alteração do relatório de faturamento para o relatório de resumo do pedido<br /> |-<br /> |}<br /> <br /> == Necessidade ==<br /> <br /> Criação de uma novo campo no relatório de resumo de pedido do GeoSales EVO, com finalidade de informar se o cliente é simples nacional ou não.<br /> <br /> == Implementação ==<br /> <br /> '''- Criar campos no relatório de resumo de pedido:'''<br /> <br /> Será incluído no relatório de resumo de pedido do portal GeoSales EVO um campo com finalidade de informar se o cliente é simples nacional ou não. Esse campo poderá ser visualizado no relatório em formato PDF. Esse campo será preenchido com 'Sim' ou 'Não', de acordo com as informações integradas do ERP.<br /> <br /> '''- Criar campo na tabela de clientes:'''<br /> <br /> Com finalidade de salvar as informações integradas, será criado um campo na tabela CLIENTE, especificando se o cliente é simples nacional ou não. Desse campo que serão extraídas a informação a ser exibida no relatório de resumo de pedido.<br /> <br /> '''- Integração de dados:'''<br /> <br /> A informação que define se o cliente é simples nacional ou não deverá ser buscada na tabela SA1, através do campo A1_SIMPNAC. Esse campo no ERP é preenchido com o valor 1, 2 ou vazio. Onde o valor '1' representa que SIM, o cliente é simples nacional, o valor '2' representa que NÃO, e caso o campo esteja vazio representa que não há informação cadastrada.<br /> <br /> == Regras de Negócios ==<br /> <br /> '''[RN1] - ''' A customização descrita neste documento será implementada exclusivamente no portal GeoSales EVO. <br /> <br /> '''[RN2] - ''' Para que essa informação seja exibida no relatório de resumo de pedido, ela deve ser corretamente e previamente cadastrada no campo A1_SIMPNAC da tabela SA1.<br /> <br /> == Aprovação ==<br /> <br /> Considero aprovada a documentação da funcionalidade especificada acima, e autorizo a implementação da mesma no Sistema GeoSales, em nome da Organização a qual estou vinculado. <br /> <br /> {| class=&quot;wikitable&quot;<br /> ! Setor <br /> ! style=&quot;width:200px&quot; |Aprovado Por<br /> ! style=&quot;width:200px&quot; |Data<br /> <br /> |- <br /> | TI || Anderson Gomes || <br /> |- <br /> | Gestor do Projeto || || <br /> |- <br /> | Diretoria || || <br /> |}</div>

Ryvanemaria