Discussão:Meios de pagamento
Neste Crud, acredito que não seja ideal excluir, mas desativar quando não não for atualizado, então para isso necessita criar um campo que controle o ativar e desativar. Quando esse campo estiver null, deve ser tratado como ativo, dessa forma, não necessitamos modificar integração.
Outra coisa que precisa ser tratado, é que meios de pagamento que tenham sido integrados, não podem ser alterados.
Como são dados que tem integração, quando for cadastrado no Geosales, ideal será salva-los como negativos.
Falar sobre a tela de pesquisa, pois na implementação não vi nada relacionado.
- Novos pontos de atenção
-- Os cenários novamente estão sem os dados, apenas um passo a passo. -- Com a adição da funcionalidade de ativação/desativação de um meio de pagamento, faz-se necessário que o sistema tenha um entendimento desse novo campo antes de termos o CRUD pronto, visto que o sistema ficará inconsistente uma vez que eu deixar um meio de pagamento inativo e o mesmo continue aparecendo no portal e nas versões do mobile. -- Sobre a coexistência dos dados gerados no ERP e no Geosales, para os outros CRUDs realizados para a mantiqueira, foi determinado que ou se cadastraria pelo geosales ou pelo ERP. Sendo assim, não poderíamos ter coexistência ou arcaremos os riscos da coexistência como impossibilidade de truncar dados adição de -funcionalidades para impedir que o cliente possa editar os dados do ERP entre outras? -- Não vi as tratativas de validação que o sistema deve ter. -- RN1 está confusa, não consegui entender como será a validação de duplicidade, visto que a única chave primária é o CD_MEIO_PGTO. Segundo sua descrição de regra, eu posso ter 15 meios de pagamento iguais chamados cheque. Isso é válido? Somente devo validar o código de referencia como identificador, visto que a chave é algo que não vai se repetir se o cadastro for feito somente em uma plataforma ou se tiverem leis de formações de códigos sem possibilidade de choque. -- RN2 eu concordo, só deixaria mais direta a explicação. Diria como o sistema se comportará e não que não há uma possibilidade. Tipo, ao tentar cadastrar um meio de pagamento com os campo a e b com valores iguais aos de um registro já inserido na base, o sistema deve impedir o cadastro e mostrar a seguinte mensagem "AXAFDAF". Saliento que isso não é uma regra de negócio, mas sim uma validação, e ao meu ver não deveria estar nesse tópico. -- RN3 também não é uma regra de negócio, mas sim uma restrição. -- RN4 aqui temos que decidir se essa é a melhor alternativa. -- RN5 em momento algum do documento é falado sobre integração de dados geosales ---> ERP. Isso necessitaria de explicações maiores e detalhamento de como isso seria feito. Tratativas de aceite (ACK), ajustes de integração, pontos de entrada etc... Se isso for necessário, não seria preciso um indicativo da importação ou não do dado? E se houver falha nas importações o que acontecerá? Existirá diferença de tratativa entre dados importados e dados não importados? -- Na RN6, qual os impactos da inativação? Onde isso impactará? -- Outra coisa, você diz em seus cenário o seguinte: "Na tela de edição posso mudar os campos de descrição do meio de pagamento e código do meio de pagamento referencia;" Eu trocaria "código do meio de pagamento referencia" por "Referência do meio de pagamento". Saliento também que esse campo é a chave do ERP necessário para vinculação de integração. Então não sei como seria a necessidade desse campo no cadastro do GeoSalaes. Esse ponto não é impeditivo, mas é importante ser salientado.
Outro ponto muito importante é a questão das vinculações, de nada vai adiantar esse crud se não houver a possibilidade de vinculação. Ao meu ver, esse crud deveria ser feito depois do crud de vinculação para que seja possível agregar valor logo no início da implementação e não no final.