Mudanças entre as edições de "Discussão:Vinculação entre cliente e vendedor"
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. | ||
#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. |
− | #* "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. |
− | #* "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. | + | |
− | #* 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? | + | |
− | #* Quais ações da funcionalidade terão ações para permitir a execução por perfil? | + | #* 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. |
− | #* 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: 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. |
+ | |||
+ | #* 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 | ||
+ | |||
+ | #* 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 | ||
+ | |||
+ | #* 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é incluimos uma mensagem de alerta. O Alexandre criou os cruds e a taela de listagem com a finalidade de evitar esses erros. | ||
+ | |||
+ | #* 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' | ||
+ | |||
+ | #* 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. | ||
Acredito que nesse momento são os apontamentos para esse documento. Quando tiver mais apontamentos, pode ser que apareçam mais dúvidas. | 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 das 17h42min de 18 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.
- 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.
- 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.
- 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.
- 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
- 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
- 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é incluimos uma mensagem de alerta. O Alexandre criou os cruds e a taela de listagem com a finalidade de evitar esses erros.
- 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'
- 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.
Acredito que nesse momento são os apontamentos para esse documento. Quando tiver mais apontamentos, pode ser que apareçam mais dúvidas.