관리 응용 프로그램에서 유효 날짜 다루기

보험 기반 정보를 다룰 때, 대부분의 데이터에 유효 날짜를 사용하도록 구현해야하는 경우가 종종 있습니다. 디자인의 일부를 변경할 수 없다고 말할 필요가없는 여러 가지 이유가 있습니다.

내가 자주 겪는 문제는 비즈니스 사용자를 위해이 데이터에 대한 관리 인터페이스를 만들어야 할 때입니다. 일반적으로 화면의 맨 위에있는 사용자는 유효 날짜를 선택합니다. 이 유효 날짜는 편집 목적으로 제공되는 데이터를 결정합니다. (즉, 해당 기간 동안 데이터가 효과적 임)

이제 사용자가 변경을 할 때마다이 변경의 유효 날짜를 요청합니다. 그런 다음 사용자의 행동에 따라 데이터베이스를 변경합니다.

• 레코드를 삭제 한 경우 실제로는 레코드의 종료 날짜를 다음과 같이 표시합니다.
  변경 날짜.

• 레코드를 업데이트하면 이전 레코드 날짜가 끝나고 새 레코드가 만들어집니다.
  새로운 유효 날짜를 기록하십시오.

• 그들이 레코드를 추가하면 ... 음 우리는 레코드를 추가합니다.

좋은 UI/사용자 경험으로 겪고있는 문제는 다음과 같습니다.

1. 사용자는 변경 날짜를 지속적으로 알려야합니다. 이것은 사용자에게 번거롭고 성가신 일입니다.

2. 변경 사항을 즉시 적용하지 않으면 사용자가 화면에서 변경 내용을 볼 수 없습니다. 이것은 화면 상단에서 유효 날짜를 선택했기 때문입니다. 또한 거의 즉시 변경 사항을 적용하지 않습니다.

3. 마지막으로, 실제로 변경하는 것은 아니기 때문에 데이터를 표 형식으로 표시 할 수는 없습니다. 데이터는 그다지 의미가 없기 때문입니다. 그들은 한 조각의 데이터가 한 번 있다고 생각하지만 25 가지 변경으로 인해 25 번 볼 수 있습니다.

이와 같은 문제를 해결하기 위해 UI에 어떤 종류의 변경 사항을 적용했는지에 대한 피드백을 얻을 수 있기를 바랍니다. 사람들이 자주 다루어야하는 문제인지 잘 모르겠지만 보험 업계에서는 자주 다루어야합니다. 기술은 중요하지 않습니다. Thick Client, Web App 등.

편집하다

조금 더 명확하게.

1. 내가 언급하는 응용 프로그램은 백엔드 데이터의 수정을 처리하는 관리 응용 프로그램입니다. 실제 애플리케이션 자체는 이미 백엔드 데이터를 사용하여 실행 중입니다.
2. 유효 날짜를 언급 할 때. 실제 응용 프로그램이 데이터를 요청하면 해당 날짜에 "유효한"레코드를 찾기 위해 유효 날짜를 전달합니다. 해당 "종료 날짜"가 null이거나 채워져 있습니다. 20 개의 테이블이있는 데이터베이스에서 10 개 이상은 레코드에 유효한 날짜를 갖습니다.
3. 내가 말할 때 우리는 그들이 기대하는 것을하지 않는다. 내 말은, "이 레코드를 삭제합니다"라고 말하고 실제로 종료합니다. "이 레코드 업데이트"라고 말하고 실제로 날짜를 끝내고 새 레코드를 만듭니다.
4. 모든 항목에는 유효 날짜가 필요합니다. 새로운 기록 인 경우, 애플리케이션은 여전히 ​​효력이 발생하는 시점을 알아야하며, 추론은 단순히 비즈니스가 원하는시기 또는 특정 법률이 시행되기 때문일 수 있습니다. 추측 할 방법이 없습니다.

작업이 완료되면 간단히 확인/상태 메시지를 사용자에게 게시 할 수 있지만, 내가하려고하는 것은이 프로세스를 조금 더 매끄럽고보다 유익하며 직관적으로 만드는 사용자 인터페이스를 구현하는 것입니다. 최종 사용자. 따라서 실제로 백엔드에서 일어나는 일에 대한 모든 작은 세부 사항을 알지 못할 수도 있지만 필요한 일을하고 있다고 확신 할 것입니다.