swift_mt_message/fields/field30.rs
1use chrono::NaiveDate;
2use serde::{Deserialize, Serialize};
3use swift_mt_message_macros::SwiftField;
4
5/// **Field 30: Date Specifications**
6///
7/// ## Purpose
8/// Specifies various types of dates critical to financial transaction processing, including
9/// execution dates, value dates, settlement dates, and other time-sensitive information.
10/// This field family provides precise temporal specifications required for proper transaction
11/// timing, settlement coordination, and regulatory compliance.
12///
13/// ## Format
14/// - **Swift Format**: `6!n` (Basic), `8!n` (Extended variants)
15/// - **Description**: Date in YYMMDD or YYYYMMDD format
16/// - **Date Validation**: Must represent valid calendar dates
17/// - **Business Date**: Must align with business day conventions
18///
19/// ## Presence
20/// - **Status**: Conditional/Mandatory depending on message type and business requirements
21/// - **Swift Error Codes**: T40 (invalid date), T50 (format violation)
22/// - **Usage Context**: Transaction timing and settlement coordination
23///
24/// ## Usage Rules
25/// - **Valid Dates**: Must represent actual calendar dates
26/// - **Business Logic**: Must comply with business day and settlement conventions
27/// - **Time Zones**: Interpreted in appropriate business time zone context
28/// - **Forward Dating**: Future dates must be within reasonable business limits
29///
30/// ## Network Validation Rules
31/// - **Date Format**: Must follow exact YYMMDD or YYYYMMDD format
32/// - **Calendar Validation**: Must be valid calendar date
33/// - **Business Rules**: Must comply with market-specific business day rules
34/// - **Range Validation**: Must be within acceptable date ranges for business context
35///
36/// ## Date Types and Applications
37///
38/// ### Execution Date (Basic Field 30)
39/// - **Format**: `6!n` (YYMMDD)
40/// - **Purpose**: Date when transaction should be executed
41/// - **Usage**: Customer payment instructions, trade settlements
42/// - **Business Context**: Determines when payment processing begins
43///
44/// ### Value Date Applications
45/// - **Settlement**: Date funds become available
46/// - **Interest**: Date for interest calculations
47/// - **Trade**: Date for trade settlement
48/// - **Currency Exchange**: Date for FX rate application
49///
50/// ### Premium Payment Date (Field 30V)
51/// - **Format**: `8!n` (YYYYMMDD)
52/// - **Purpose**: Date premium is paid for option contracts
53/// - **Usage**: FX options, derivative contracts
54/// - **Business Context**: Critical for option contract timing
55///
56/// ## Business Context
57/// - **Payment Processing**: Determines transaction execution timing
58/// - **Settlement Coordination**: Aligns settlement across counterparties
59/// - **Interest Calculations**: Provides basis for accrual calculations
60/// - **Regulatory Compliance**: Meets timing requirements for various regulations
61///
62/// ## Examples
63/// ```logic
64/// :30:250719 // July 19, 2025 (execution date)
65/// :30V:20250719 // July 19, 2025 (premium payment date)
66/// :30T:250720 // July 20, 2025 (trade date)
67/// :30P:250721 // July 21, 2025 (processing date)
68/// ```
69///
70/// ## Date Calculation Logic
71/// - **Business Days**: Excludes weekends and holidays
72/// - **Settlement Cycles**: Standard T+0, T+1, T+2, T+3 settlements
73/// - **Cut-off Times**: Coordination with daily processing cut-offs
74/// - **Time Zones**: Market-specific time zone considerations
75///
76/// ## Regional Considerations
77/// - **European Markets**: TARGET2 business day calendar
78/// - **US Markets**: Federal Reserve business day calendar
79/// - **Asian Markets**: Local holiday and business day calendars
80/// - **Cross-Border**: Coordination across multiple market calendars
81///
82/// ## Error Prevention
83/// - **Date Validation**: Verify date is valid calendar date
84/// - **Business Day Check**: Ensure date complies with business day conventions
85/// - **Range Verification**: Confirm date is within reasonable business range
86/// - **Market Calendar**: Check against relevant market holiday calendars
87///
88/// ## Related Fields
89/// - **Field 32A**: Value Date, Currency, Amount (settlement information)
90/// - **Field 61**: Statement Line (transaction dates)
91/// - **Field 13C/13D**: Time Indication (precise timing information)
92/// - **Block Headers**: Message timestamps
93///
94/// ## Settlement Coordination
95/// - **Same Day Settlement**: T+0 processing requirements
96/// - **Next Day Settlement**: T+1 standard processing
97/// - **Standard Settlement**: T+2 typical market practice
98/// - **Extended Settlement**: T+3 or longer for specific instruments
99///
100/// ## Processing Impact
101/// - **Batch Processing**: Date-based transaction grouping
102/// - **Real-Time Processing**: Immediate execution date processing
103/// - **Schedule Processing**: Future-dated transaction scheduling
104/// - **Exception Handling**: Holiday and weekend date adjustments
105///
106/// ## Compliance Framework
107/// - **Regulatory Timing**: Meeting regulatory execution requirements
108/// - **Market Rules**: Compliance with market settlement rules
109/// - **Audit Trail**: Maintaining accurate date records
110/// - **Documentation**: Proper date documentation for compliance
111///
112/// ## STP Compliance
113/// - **Date Standardization**: Consistent date format for automation
114/// - **Validation Enhancement**: Automated date validation and correction
115/// - **Processing Rules**: Date-based automated processing logic
116/// - **Exception Management**: Automated handling of date-related exceptions
117///
118/// ## See Also
119/// - Swift FIN User Handbook: Date Field Specifications
120/// - Settlement Guidelines: Business Day Conventions
121/// - Market Calendars: Holiday and Business Day References
122/// - Processing Standards: Date-Based Transaction Handling
123///
124/// **Field 30: Execution Date**
125///
126/// Basic execution date specification for transaction processing timing.
127#[derive(Debug, Clone, Serialize, Deserialize, PartialEq, SwiftField)]
128pub struct Field30 {
129 /// Execution date
130 ///
131 /// Format: 6!n (YYMMDD) - Date when transaction should be executed
132 /// Must be valid calendar date and comply with business day conventions
133 #[component("6!n")]
134 pub execution_date: NaiveDate,
135}