Ticket 2.0

Khái niệm ticket không chỉ còn là của CRM mà đưa sang các phân hệ khác : DMS, DMS.ABE, IWM, IOT và các phân hệ này tham gia dưới vai trò là nơi tạo ticket hoặc nơi xử lý.

Thiết kế class cũ

Trường	Kiểu dữ liệu	Mô tả
Id	long	Id ticket
TicketTypeId	long	Id loại Ticket
TicketGroupingId	long	Id nhóm ticket ( nhóm ticket theo loại )
IssueTypeId	long	Id loại vấn đề ( loại vđ theo nhóm ticket )
IssueId	long?	Id vấn đề là nguồn
Code	string	mã ticket
Name	string	tên ticket
Content	string	nội dung
CustomerTypeId	long	Loại KH
CustomerId	long	KH
TicketPriorityId	long	độ ưu tiên
TicketSourceId	long	Id nguồn
TicketStatusId	long	Id trạng thái
HandlingOrganizationId	long?	?đơn vị xử lý
OrganizationId	long	đơn vị phụ trách ticket
AppUserId	long	Người phụ trách
AppUserInChargeId	long	Người xử lý
CreatorId	long	Người tạo ticket
ReOpenCounter	long	Số lần mở lại ticket
TicketResolveTypeId	long?	Loại giải quyết
ResolveContent	string	Nội dung giải quyết
SLAStatusId	long?	Trạng thái SLA
FirstResponsedAt	datetime?	Thời điểm phản hồi đầu tiên
LastResponsedAt	datetime?	Thời điểm phản hồi cuối
ResponseExpectedAt	datetime?	Thời điểm phản hồi mong muốn
ExpectedAt	datetime	Thời điểm hoàn thành mong muốn
CompletedAt	datetime?	Thời điểm hoàn thành ticket thực tế
Note	string	Ghi chú
TicketActionId	long?	? enum
Used	bool	đã dc sử dụng hay chưa
RowId	uniqueidentifier
IsReminded	bool?	?
TicketFileMappings	List<TicketFileMapping>	danh sách tệp đính kèm
TicketItemMappings	List<TicketItemMapping>	dach sách sp
TicketProductGroupingMappings	List<TicketProductGroupingMapping>	danh sách nhóm sp
TicketHistories	List<RequestHistory<Ticket>>	lịch sử ticket lưu trên mongo
CreatedAt	datetime	ngày tạo
UpdatedAt	datetime	ngày cập nhật cuối
DeletedAt	datetime?	ngày xóa

Với thiết kế mới Ticket sẽ thêm các trường mới:

Trường	kiểu	mô tả	API lấy dữ liệu
BeneficiaryServiceId	long?	Id phân hệ thụ hưởng( từ IssueSource )	rpc/ticket/single-list-beneficiary-service
BeneficiaryAppUserId	long?	Id nhân viên thụ hưởng ( nếu phân hệ là DMS app nhân viên)	rpc/ticket/single-list-app-user
BeneficiaryCustomerId	long?	Id khách hàng thụ hưởng	rpc/ticket/single-list-customer
ServiceInChargeId	long	Id phân hệ xử lý	rpc/ticket/single-list-service-in-charge
CustomerInChargeId	long?	Id khách hàng xử lý	rpc/ticket/single-list-customer

IssueSourceEnum

1	IOT	Ứng dụng RalliSmart
2	DMS	DMS App nhân viên
3	IWM	IWM
4	CRM	CRM
5	OTHER	Khác
6	DMS_ABE	DMS App đại lý

Và thay đổi cách lưu lịch sử như hiện tại:

TicketHistoryDAO

Trường	kiểu	mô tả
Id	long
TicketId	long
AppUserId	long?	id nhân viên thay đổi ( modifierTypeId = 1)
CustomerId	long?	id khách hàng thay đổi ( modifierTypeId = 2)
ModifierTypeId	long	vai trò người thay đổi
TicketStatusId	long	trạng thái ticket
Content	string	ghi chú về sự thay đổi
CreatedAt	datetime	thời gian thay đổi

ModifierTypeEnum

Id	Code	Name
1	AppUser	Nhân viên
2	Customer	Khách hàng

và trả ra cho FE theo DTO sau TicketHistoryDTO:

Trường	Kiểu	mô tả
Id	long
TicketId	long
ModifierId	long?
ModifierTypeId	long
TicketStatusId	long
Content	string
CreatedAt	datetime

Modifier

Trường	kiểu	mô tả
Id	long
Code	string
Name	string

Tức là Be sẽ gộp appUser và customer lại đưa vào Modifier

Luồng ticket mới (lấy từ docs)

API	mô tả	payload mẫu
rpc/crm/ticket/single-list-beneficiary-service	danh sách các phân hệ thụ hưởng	{}
rpc/crm/ticket/single-list-service-in-charge	danh sách các phân hệ phụ trách	{}
rpc/crm/ticket/single-list-app-user	danh sách nhân viên thụ hưởng hoặc phụ trách	{}
rpc/crm/ticket/single-list-customer	danh sách khách hàng thụ hưởng hoặc phụ trách: IWM: khách hàng thầu thợ => CustomerTypeId = 6 Rallismart: khách hàng lẻ => CustomerTypeId = 1 App đại lý: khách hàng đại lý => CustomerTypeId = 3	`{"customerTypeId":{"equal":6}}` `{"customerSubKindId":{"equal":3}}`