Mudanças entre as edições de "Discussão:Vinculação entre cliente e vendedor"
Ir para navegação
Ir para pesquisar
(7 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
Linha 2: | Linha 2: | ||
# Necessidade | # Necessidade | ||
− | #* "Realizar a vinculação entre cliente e vendedor através da plataforma GeoSales EVO." O que seria precisamente esse vínculo? Seria org_venda_cliente? Seria o vendedor padrão da tabela cliente? | + | #* Anderson: "Realizar a vinculação entre cliente e vendedor através da plataforma GeoSales EVO." O que seria precisamente esse vínculo? Seria org_venda_cliente? Seria o vendedor padrão da tabela cliente? |
+ | #* Ana Júlia: Anderson, não será na org_venda_cliente. Será nas novas vinculações desenhadas pelo Leonardo e Jeff conforme anexo no redmine. <span style="color:red">Somente o TXT anexado no redmine não pode ser considerado como documentação técnica estrutural. Precisamos da documentação completa da funcionalidade onde sejam apresentados as regras de restrição, estruturas a serem criadas, impactos no sistema e exemplos de utilização.</span> | ||
− | #Implementação | + | # Implementação |
− | #* "Na plataforma GeoSales EVO será possível realizar a vinculação e manutenção entre cliente e vendedor." - Como será essa manutenção? Quais tabelas serão alteradas e quais pontos serão tratados nessa manutenção (edição, exclusão, inserção)? | + | #* Anderson: "Na plataforma GeoSales EVO será possível realizar a vinculação e manutenção entre cliente e vendedor." - Como será essa manutenção? Quais tabelas serão alteradas e quais pontos serão tratados nessa manutenção (edição, exclusão, inserção)? |
− | #* Sobre os filtros, eu realmente fiquei confuso com os campos descritos. Esses filtros apresentados estão ok para a tela de cadastro, mas e a tela de listagem das vinculações? Quais filtros serão adicionados? Como será a pesquisa dos dados? E como será feita a diferenciação entre os dados cadastrados no ERP e no geosales? Saliento isso por que se eu entendi certo e estamos falando da tabela de ORG_VENDA_CLIENTE, não existe um chave cega, os campos componentes da chave são os dados de vinculação e não poderemos fazer a questão de chaves negativas. Ai eu pergunto como faremos a diferenciação para evitar a alteração de dados vindos do ERP? | + | #* Ana Júlia: O nome das tabelas não deve ser decidida por mim. Conforme documento no anexo do redmine, será o que foi desenhado junto ao Jeff e Leonardo. <span style="color:red">Aqui novamente enalteço que é preciso que seja implementada essa documentação previamente antes de prosseguir com as implementações. Visto que, dependendo do como for planejado, pode ser necessária alterações nessa parte da funcionalidade. Por isso, peço que seja pedido ao Sousa a priorização dessa documentação para poder evoluir nessa atividade.</span> |
− | #* "Vale salientar que o só poderá ser cadastrado um cenário por cliente com um ou vários vendedores." - Aqui ficou uma dúvida, e os outros filtros? Grupo meio de pagamento, organização de venda, tabela de preço? Não vi o detalhamento do cadastro desses campos, novamente, se entendi correto e você está trabalhando com a OVC, então a regra detalhada acima não se aplica, visto que eu posso ter múltiplos cenários de clientes repetindo o mesmo vendedor para os outros dados diferente. Então detalha como será isso. | + | |
− | #* "Caso o cliente já esteja vinculado ao vendedor, e haja a tentativa de realizar um novo cadastro para o cliente selecionado, a plataforma exibirá o alerta' Já existe uma vinculação para este cliente." Pelo que eu detalhei acima, essa validação não se aplica dessa forma. Por favor detalhar melhor como será a validação de registro já cadastrado e de como será feita a substituição. | + | #* Anderson:Sobre os filtros, eu realmente fiquei confuso com os campos descritos. Esses filtros apresentados estão ok para a tela de cadastro, mas e a tela de listagem das vinculações? Quais filtros serão adicionados? Como será a pesquisa dos dados? E como será feita a diferenciação entre os dados cadastrados no ERP e no geosales? Saliento isso por que se eu entendi certo e estamos falando da tabela de ORG_VENDA_CLIENTE, não existe um chave cega, os campos componentes da chave são os dados de vinculação e não poderemos fazer a questão de chaves negativas. Ai eu pergunto como faremos a diferenciação para evitar a alteração de dados vindos do ERP? |
− | #* "Para que haja a vinculação entre cliente e vendedor na plataforma, as informações mínimas de cliente e vendedor precisam estar integrados a GeoSales. Caso o cliente ou vendedor não estejam cadastrados, não será possível prosseguir com o cadastrado." - Quais são as informações mínimas? Preciso saber disso para poder implementar a validação. | + | #* Ana Júlia: Não se trata da org_venda_cliente, conforme mencioando acima. Nas telas criadas pelo Alexandre já constam os filtros. <span style="color:red">Sua resposta não contempla a totalidade das perguntas. Por exemplo, o print mostra a listagem, mas não existe um detalhamento de como será a navegação. Principalmente porque o documento não diz como será persistido as informações nem a estrutura que deverá ter os dados inseridos. As outras perguntas feitas também não foram respondidas.</span> |
− | #* | + | |
+ | #* Anderson:"Vale salientar que o só poderá ser cadastrado um cenário por cliente com um ou vários vendedores." - Aqui ficou uma dúvida, e os outros filtros? Grupo meio de pagamento, organização de venda, tabela de preço? Não vi o detalhamento do cadastro desses campos, novamente, se entendi correto e você está trabalhando com a OVC, então a regra detalhada acima não se aplica, visto que eu posso ter múltiplos cenários de clientes repetindo o mesmo vendedor para os outros dados diferente. Então detalha como será isso. | ||
+ | #* Ana Júlia: Conforme mencionado a estrutura irá mudar, conforme documento em anexo no redmine. A responsabilidade da documentação das demais tabelas estava com o Jeff até onde lembro. Realizei a documentação da vinculação entre cliente e vendedor, pois o cliente irá pagar. <span style="color:red">O documento anexado não responde esse questionamento.</span> | ||
+ | |||
+ | #* Anderson:"Caso o cliente já esteja vinculado ao vendedor, e haja a tentativa de realizar um novo cadastro para o cliente selecionado, a plataforma exibirá o alerta' Já existe uma vinculação para este cliente." Pelo que eu detalhei acima, essa validação não se aplica dessa forma. Por favor detalhar melhor como será a validação de registro já cadastrado e de como será feita a substituição. | ||
+ | #* Ana Júlia: Me desculpa, mas não entendi o que não se aplica a esse cenário se a regra não será na org_venda_cliente. <span style="color:red">Como não existe a estrutura, não fica claro como será a inserção do dado.</span> | ||
+ | |||
+ | #* Anderson:"Para que haja a vinculação entre cliente e vendedor na plataforma, as informações mínimas de cliente e vendedor precisam estar integrados a GeoSales. Caso o cliente ou vendedor não estejam cadastrados, não será possível prosseguir com o cadastrado." - Quais são as informações mínimas? Preciso saber disso para poder implementar a validação. | ||
+ | #* Ana Júlia: Tabela de cliente e vendedor | ||
+ | |||
+ | #* Anderson:"Clientes que estiverem bloqueados ou inativos não serão exibidos para vinculação com o vendedor.". Pode detalhar o que é um cliente inativo? Não lembro bem dessa regra. | ||
+ | #* Ana Júlia: O Campo DS_SITUACAO da tabela CLIENTE deve estar diferente de NULL, para que o cliente NÃO seja exibido <span style="color:red">Isso não faz muito sentido. No nosso sistema é essa a regra? Tipo mesmo que esteja escrito "ATIVO" no campo ele vai ser interpretado como inativo?</span> | ||
+ | |||
+ | #* Anderson:Assim como em outros documentos está faltando detalhar melhor os fluxos do CRUD. Teremos o mesmo problema dos cadastros de impostos. O cadastros de serão feitos para múltiplos dados e a listagem mostrará um registro da tabela ou agrupará tudo por cliente? Sobre a exclusão, como serão as regras e restrições? Da mesma forma para a edição, quais serão as regras? | ||
+ | #* Ana Júlia: Já foi explica a regra de edição, até incluímos uma mensagem de alerta. O Alexandre criou os cruds e a tabela de listagem com a finalidade de evitar esses erros. <span style="color:red">Júlia, eu acredito que não tá claro mesmo com o print. O print mostra um fluxo de cadastro genérico onde o usuário cadastrará segundo o fluxo a regra geral de todos os clientes para todos os clientes. Ou pode fazer individualmente. Porém o individual, ao meu ver, tá meio estranho. No caso da edição, como ficará a tela? O mandatório será sempre cliente, visto que no cadastro eu posso cadastrar todos para todos, na edição virá somente o dado apontado na listagem? E se ele quiser editar dados de outros clientes que não foram selecionados no clique de edição será possível? E sobre a exclusão, você pode detalhar o fluxo para mostrar como deverá ser implementado com suas validações? Será possível remover múltiplas vinculações de clientes simultaneamente? Se sim, como será a interface?</span> | ||
+ | |||
+ | #* Anderson:Quais ações da funcionalidade terão ações para permitir a execução por perfil? | ||
+ | #* Ana Júlia: Criar o acesso 'Realizar vinculação cliente e vendedor' <span style="color:green">OK</span> | ||
+ | |||
+ | #* Anderson:Sobre os cenários, seria bom adicionar os outros cenários, e para que o mesmo seja fidedigno, seria ideal colocar os valores dos dados inseridos e não somente "os dados foram inseridos" | ||
+ | #* Ana Júlia: Foi adicionado o cenário principal. <span style="color:red">Ao meu ver, o mesmo não está suficiente vista quantidade de ações desse documento. Ainda mais devido a importância dessas ações onde caso o usuário faça uma remoção errada. Então é importante que os cenários demonstrem esses fluxos.</span> | ||
+ | |||
+ | Acredito que nesse momento são os apontamentos para esse documento. Quando tiver mais apontamentos, pode ser que apareçam mais dúvidas. |
Edição atual tal como às 14h44min de 23 de novembro de 2020
Vou listar ponto a ponto os questionamentos sobre o que está descrito no documento.
- Necessidade
- Anderson: "Realizar a vinculação entre cliente e vendedor através da plataforma GeoSales EVO." O que seria precisamente esse vínculo? Seria org_venda_cliente? Seria o vendedor padrão da tabela cliente?
- Ana Júlia: Anderson, não será na org_venda_cliente. Será nas novas vinculações desenhadas pelo Leonardo e Jeff conforme anexo no redmine. Somente o TXT anexado no redmine não pode ser considerado como documentação técnica estrutural. Precisamos da documentação completa da funcionalidade onde sejam apresentados as regras de restrição, estruturas a serem criadas, impactos no sistema e exemplos de utilização.
- Implementação
- Anderson: "Na plataforma GeoSales EVO será possível realizar a vinculação e manutenção entre cliente e vendedor." - Como será essa manutenção? Quais tabelas serão alteradas e quais pontos serão tratados nessa manutenção (edição, exclusão, inserção)?
- Ana Júlia: O nome das tabelas não deve ser decidida por mim. Conforme documento no anexo do redmine, será o que foi desenhado junto ao Jeff e Leonardo. Aqui novamente enalteço que é preciso que seja implementada essa documentação previamente antes de prosseguir com as implementações. Visto que, dependendo do como for planejado, pode ser necessária alterações nessa parte da funcionalidade. Por isso, peço que seja pedido ao Sousa a priorização dessa documentação para poder evoluir nessa atividade.
- Anderson:Sobre os filtros, eu realmente fiquei confuso com os campos descritos. Esses filtros apresentados estão ok para a tela de cadastro, mas e a tela de listagem das vinculações? Quais filtros serão adicionados? Como será a pesquisa dos dados? E como será feita a diferenciação entre os dados cadastrados no ERP e no geosales? Saliento isso por que se eu entendi certo e estamos falando da tabela de ORG_VENDA_CLIENTE, não existe um chave cega, os campos componentes da chave são os dados de vinculação e não poderemos fazer a questão de chaves negativas. Ai eu pergunto como faremos a diferenciação para evitar a alteração de dados vindos do ERP?
- Ana Júlia: Não se trata da org_venda_cliente, conforme mencioando acima. Nas telas criadas pelo Alexandre já constam os filtros. Sua resposta não contempla a totalidade das perguntas. Por exemplo, o print mostra a listagem, mas não existe um detalhamento de como será a navegação. Principalmente porque o documento não diz como será persistido as informações nem a estrutura que deverá ter os dados inseridos. As outras perguntas feitas também não foram respondidas.
- Anderson:"Vale salientar que o só poderá ser cadastrado um cenário por cliente com um ou vários vendedores." - Aqui ficou uma dúvida, e os outros filtros? Grupo meio de pagamento, organização de venda, tabela de preço? Não vi o detalhamento do cadastro desses campos, novamente, se entendi correto e você está trabalhando com a OVC, então a regra detalhada acima não se aplica, visto que eu posso ter múltiplos cenários de clientes repetindo o mesmo vendedor para os outros dados diferente. Então detalha como será isso.
- Ana Júlia: Conforme mencionado a estrutura irá mudar, conforme documento em anexo no redmine. A responsabilidade da documentação das demais tabelas estava com o Jeff até onde lembro. Realizei a documentação da vinculação entre cliente e vendedor, pois o cliente irá pagar. O documento anexado não responde esse questionamento.
- Anderson:"Caso o cliente já esteja vinculado ao vendedor, e haja a tentativa de realizar um novo cadastro para o cliente selecionado, a plataforma exibirá o alerta' Já existe uma vinculação para este cliente." Pelo que eu detalhei acima, essa validação não se aplica dessa forma. Por favor detalhar melhor como será a validação de registro já cadastrado e de como será feita a substituição.
- Ana Júlia: Me desculpa, mas não entendi o que não se aplica a esse cenário se a regra não será na org_venda_cliente. Como não existe a estrutura, não fica claro como será a inserção do dado.
- Anderson:"Para que haja a vinculação entre cliente e vendedor na plataforma, as informações mínimas de cliente e vendedor precisam estar integrados a GeoSales. Caso o cliente ou vendedor não estejam cadastrados, não será possível prosseguir com o cadastrado." - Quais são as informações mínimas? Preciso saber disso para poder implementar a validação.
- Ana Júlia: Tabela de cliente e vendedor
- Anderson:"Clientes que estiverem bloqueados ou inativos não serão exibidos para vinculação com o vendedor.". Pode detalhar o que é um cliente inativo? Não lembro bem dessa regra.
- Ana Júlia: O Campo DS_SITUACAO da tabela CLIENTE deve estar diferente de NULL, para que o cliente NÃO seja exibido Isso não faz muito sentido. No nosso sistema é essa a regra? Tipo mesmo que esteja escrito "ATIVO" no campo ele vai ser interpretado como inativo?
- Anderson:Assim como em outros documentos está faltando detalhar melhor os fluxos do CRUD. Teremos o mesmo problema dos cadastros de impostos. O cadastros de serão feitos para múltiplos dados e a listagem mostrará um registro da tabela ou agrupará tudo por cliente? Sobre a exclusão, como serão as regras e restrições? Da mesma forma para a edição, quais serão as regras?
- Ana Júlia: Já foi explica a regra de edição, até incluímos uma mensagem de alerta. O Alexandre criou os cruds e a tabela de listagem com a finalidade de evitar esses erros. Júlia, eu acredito que não tá claro mesmo com o print. O print mostra um fluxo de cadastro genérico onde o usuário cadastrará segundo o fluxo a regra geral de todos os clientes para todos os clientes. Ou pode fazer individualmente. Porém o individual, ao meu ver, tá meio estranho. No caso da edição, como ficará a tela? O mandatório será sempre cliente, visto que no cadastro eu posso cadastrar todos para todos, na edição virá somente o dado apontado na listagem? E se ele quiser editar dados de outros clientes que não foram selecionados no clique de edição será possível? E sobre a exclusão, você pode detalhar o fluxo para mostrar como deverá ser implementado com suas validações? Será possível remover múltiplas vinculações de clientes simultaneamente? Se sim, como será a interface?
- Anderson:Quais ações da funcionalidade terão ações para permitir a execução por perfil?
- Ana Júlia: Criar o acesso 'Realizar vinculação cliente e vendedor' OK
- Anderson:Sobre os cenários, seria bom adicionar os outros cenários, e para que o mesmo seja fidedigno, seria ideal colocar os valores dos dados inseridos e não somente "os dados foram inseridos"
- Ana Júlia: Foi adicionado o cenário principal. Ao meu ver, o mesmo não está suficiente vista quantidade de ações desse documento. Ainda mais devido a importância dessas ações onde caso o usuário faça uma remoção errada. Então é importante que os cenários demonstrem esses fluxos.
Acredito que nesse momento são os apontamentos para esse documento. Quando tiver mais apontamentos, pode ser que apareçam mais dúvidas.