Bee O`clock
  • 📄Terms of use
  • 🔏Privacy policy
  • 📑Documentation
    • Notification
      • Email
  • For programmers
    • Entity
      • State and State History
  • Customer and Order
Powered by GitBook
On this page

Was this helpful?

Customer and Order

Customer and Order Data Structure Documentation

Overview

When a customer orders services their information is captured and stored consistently across multiple related documents (payment, order, and ordered service details). This duplication ensures data integrity and historical accuracy for each stage of the ordering process.

Data Duplication Structure

Customer Snapshot Duplication

The customer’s data is duplicated and stored as a snapshot in three key areas:

  1. Payment Document (payment)

    • Customer information is stored in the field payer.

    export interface IPaymentDto extends IBaseEntity<'PaymentDto'> {
        providerPaymentRef: string | null;
        orderId: Types.StringObjectId;
        
        payer: ICustomer; // <-- HERE
        
        amount: number & tags.Minimum<0>;
        currency: CurrencyCodeEnum & tags.Default<CurrencyCodeEnum.USD>;
        method: PaymentMethodEnum & tags.Default<PaymentMethodEnum.CASH>;
        providerType?: PaymentProviderTypeEnum & tags.Default<PaymentProviderTypeEnum.onSite>;
        status: PaymentStatusEnum & tags.Default<PaymentStatusEnum.pending>;
        paymentDate?: string;
    }
  2. Order Document (order)

    • Customer information is stored directly in the field customer.

    export interface OrderDto extends IBaseEntity<'OrderDto'> {
        products: OrderProductDto[];
        services: OrderServiceDto[];
        status: OrderStatusEnum;
        customer: ICustomer; // <-- HERE
    }
    
    export interface ICustomer {
        object: "CustomerDto",
        _id: "67b8ac9d4b39c2fd27431017",
        createdAt: "2025-02-21T16:40:41.031Z",
        updatedAt: "2025-02-22T12:13:24.745Z",
        state: "active",
        stateHistory: [
            {
                state: "active",
                setAt: "2025-02-24T10:50:40.393Z"
            }
        ],
        email: "[email protected]",
        firstName: "new",
        lastName: "customer",
        customerType: "regular",
        phone: null,
        note: null,
        _version: "1"
    }
  3. Ordered Service Details (CreateOrderServiceDto)

    • Each ordered service stores the customer snapshot within an attendant object. This attendant is then added to the list of attendees within the orderAppointmentDetails.

    export interface OrderServiceDto {
        object: 'OrderServiceDto';
        _id: Types.StringObjectId;
        serviceSnapshot: ServiceDto;
        orderAppointmentDetails: OrderAppointmentDetailsDto;
        customerNote: string;
        status: OrderServiceStatusEnum;
    }
    
    export interface OrderAppointmentDetailsDto {
        object: 'OrderAppointmentDetailsDto';
        start: Types.StringISO;
        end: Types.StringISO;
        languageCodes: LanguageCodeEnum[];
        attachments: {
            object: 'AttachmentDto';
            title: string;
            mimeType: string;
            fileUri: string;
            active: ActiveEnum;
        }[];
        attendees: IAttendant[];
        specialists: ISpecialist[];
        locations: LocationDto[];
        timeZone: string;
        createdAt: Types.StringISO;
        updatedAt: Types.StringISO;
    }
    
    export interface IAttendant {
        object: "AttendantDto";
        customer: ICustomer;  // <-- HERE
        firstTime: boolean;
    }
    
    export interface ICustomer {
        object: "CustomerDto",
        _id: "67b8ac9d4b39c2fd27431017",
        createdAt: "2025-02-21T16:40:41.031Z",
        updatedAt: "2025-02-22T12:13:24.745Z",
        state: "active",
        stateHistory: [
            {
                state: "active",
                setAt: "2025-02-24T10:50:40.393Z"
            }
        ],
        email: "[email protected]",
        firstName: "new",
        lastName: "customer",
        customerType: "regular",
        phone: null,
        note: null,
        _version: "1"
    }

Use Cases

  • Case 1: Single Customer When the customer who pays for the service is the same person who orders and receives the service, their data snapshot is consistent across payer, customer, and each attendant.

  • Case 2: Different Attendee When the paying customer differs from the person who receives the service, the data snapshot for payer and customer in the payment and order documents reflect the paying customer, while the attendant in ordered services reflects the actual service recipient.

This structure ensures clarity and historical accuracy across the order lifecycle, providing flexibility for scenarios involving gifts, third-party bookings, or personal use.

PreviousState and State History

Last updated 2 months ago

Was this helpful?