BREAKING CHANGE(core): Rebrand XInvoice to EInvoice: update package name, class names, imports, and documentation
This commit is contained in:
@ -8,19 +8,19 @@ Transform @fin.cx/einvoice into the definitive, production-ready solution for ha
|
||||
## Phase 0: Project Rebranding
|
||||
|
||||
### 0.1 Rename from XInvoice to EInvoice
|
||||
- [ ] Update package name from @fin.cx/xinvoice to @fin.cx/einvoice
|
||||
- [ ] Rename main class from XInvoice to EInvoice
|
||||
- [ ] Update all error classes (XInvoice* to EInvoice*)
|
||||
- [ ] Update all imports and references
|
||||
- [ ] Update documentation and examples
|
||||
- [ ] Create migration guide for existing users
|
||||
- [x] Update package name from @fin.cx/xinvoice to @fin.cx/einvoice
|
||||
- [x] Rename main class from XInvoice to EInvoice
|
||||
- [x] Update all error classes (XInvoice* to EInvoice*)
|
||||
- [x] Update all imports and references
|
||||
- [x] Update documentation and examples
|
||||
- [x] Create migration guide for existing users
|
||||
- [ ] Set up package alias for backward compatibility
|
||||
- [ ] Update repository name and URLs
|
||||
- [x] Update repository name and URLs
|
||||
|
||||
**Rationale**: "EInvoice" (electronic invoice) is more inclusive and universally understood than "XInvoice", better representing our goal to support all electronic invoice formats globally.
|
||||
|
||||
### 0.2 Architectural Improvements During Rebranding
|
||||
- [ ] Rename classes.xinvoice.ts to einvoice.ts
|
||||
- [x] Rename classes.xinvoice.ts to einvoice.ts
|
||||
- [ ] Split EInvoice class into smaller, focused components
|
||||
- [ ] Create clean separation between data model and operations
|
||||
- [ ] Implement proper domain-driven design structure
|
||||
@ -28,12 +28,12 @@ Transform @fin.cx/einvoice into the definitive, production-ready solution for ha
|
||||
## Phase 1: Core Infrastructure Improvements (Foundation)
|
||||
|
||||
### 1.1 Enhanced Error Handling System
|
||||
- [ ] Create specialized error classes for each operation type
|
||||
- [x] Create specialized error classes for each operation type
|
||||
- `EInvoiceParsingError` for XML parsing failures
|
||||
- `EInvoiceValidationError` for validation failures
|
||||
- `EInvoicePDFError` for PDF operations
|
||||
- `EInvoiceFormatError` for format-specific issues
|
||||
- [ ] Implement error recovery mechanisms
|
||||
- [x] Implement error recovery mechanisms
|
||||
- Partial data extraction on parser failures
|
||||
- Fallback strategies for corrupted data
|
||||
- Detailed error context with actionable solutions
|
||||
@ -63,11 +63,11 @@ Transform @fin.cx/einvoice into the definitive, production-ready solution for ha
|
||||
**Rationale**: A robust test suite is fundamental to ensuring reliability and maintainability. By leveraging the extensive corpus of 646+ test files across multiple formats, we can build confidence in our implementation and catch regressions early. This phase is positioned early in the roadmap because comprehensive testing underpins all subsequent development.
|
||||
|
||||
### 2.1 Test Infrastructure Overhaul
|
||||
- [ ] Reorganize test structure for better maintainability
|
||||
- [x] Reorganize test structure for better maintainability
|
||||
- Group tests by feature (format detection, validation, conversion, PDF operations)
|
||||
- Create test utilities for common operations
|
||||
- Implement test data factories for generating test invoices
|
||||
- [ ] Set up automated test categorization
|
||||
- [x] Set up automated test categorization
|
||||
- Unit tests for individual components
|
||||
- Integration tests for format workflows
|
||||
- End-to-end tests for complete invoice processing
|
||||
@ -75,7 +75,7 @@ Transform @fin.cx/einvoice into the definitive, production-ready solution for ha
|
||||
- Compliance tests against official standards
|
||||
|
||||
### 2.2 Format Detection Test Suite
|
||||
- [ ] Create exhaustive format detection tests using corpus assets
|
||||
- [x] Create exhaustive format detection tests using corpus assets
|
||||
- Test all 28 CII samples from XML-Rechnung
|
||||
- Test all 28 UBL samples from XML-Rechnung
|
||||
- Test 24 ZUGFeRD v1 PDFs (both valid and invalid)
|
||||
@ -83,64 +83,64 @@ Transform @fin.cx/einvoice into the definitive, production-ready solution for ha
|
||||
- Test PEPPOL large invoice samples
|
||||
- Test 15 FatturaPA samples
|
||||
- Test edge cases: malformed files, empty files, wrong extensions
|
||||
- [ ] Add format confidence scoring tests
|
||||
- [ ] Test format detection performance with large files
|
||||
- [x] Add format confidence scoring tests
|
||||
- [x] Test format detection performance with large files
|
||||
- [ ] Test streaming detection for huge documents
|
||||
|
||||
### 2.3 Validation Test Suite
|
||||
- [ ] Implement EN16931 compliance testing
|
||||
- [x] Implement EN16931 compliance testing
|
||||
- Run all 207 UBL Invoice validation tests
|
||||
- Run all 71 UBL CreditNote validation tests
|
||||
- Test all Business Rules (BR-*) from test/assets/eInvoicing-EN16931
|
||||
- Test all Codelist validations (BR-CL-*)
|
||||
- Test calculation rules (BR-CO-*)
|
||||
- [ ] Create format-specific validation suites
|
||||
- [x] Create format-specific validation suites
|
||||
- XRechnung validation using validator-configuration scenarios
|
||||
- ZUGFeRD profile validation (BASIC, COMFORT, EXTENDED)
|
||||
- FatturaPA schema validation
|
||||
- PEPPOL BIS validation
|
||||
- [ ] Test validation error reporting
|
||||
- [x] Test validation error reporting
|
||||
- Ensure clear, actionable error messages
|
||||
- Test error location tracking (line numbers, XPath)
|
||||
- Verify suggested fixes for common errors
|
||||
|
||||
### 2.4 PDF Operations Test Suite
|
||||
- [ ] PDF extraction testing
|
||||
- [x] PDF extraction testing
|
||||
- Test XML extraction from all ZUGFeRD v1 samples (24 files)
|
||||
- Test extraction from ZUGFeRD v2/Factur-X samples (97 files)
|
||||
- Test handling of PDFs without embedded XML
|
||||
- Test corrupted PDF handling
|
||||
- Test large PDF performance (using PEPPOL large samples)
|
||||
- [ ] PDF embedding testing
|
||||
- [x] PDF embedding testing
|
||||
- Test embedding into existing PDFs
|
||||
- Test creating new PDF/A-3 compliant files
|
||||
- Test multiple attachment handling
|
||||
- Test metadata preservation
|
||||
- [ ] PDF signature testing
|
||||
- [x] PDF signature testing
|
||||
- Test signature validation on signed PDFs
|
||||
- Test signature preservation during embedding
|
||||
|
||||
### 2.5 Cross-Format Conversion Testing
|
||||
- [ ] Create conversion matrix tests
|
||||
- [x] Create conversion matrix tests
|
||||
- CII to UBL conversion using XML-Rechnung pairs
|
||||
- UBL to CII conversion validation
|
||||
- ZUGFeRD to XRechnung conversion
|
||||
- Test data loss detection during conversion
|
||||
- Verify mandatory field mapping
|
||||
- [ ] Test conversion edge cases
|
||||
- [x] Test conversion edge cases
|
||||
- Missing optional fields
|
||||
- Format-specific extensions
|
||||
- Character encoding issues
|
||||
- Number format variations
|
||||
- [ ] Performance testing for batch conversions
|
||||
- [x] Performance testing for batch conversions
|
||||
|
||||
### 2.6 Error Handling and Recovery Testing
|
||||
- [ ] Parser error recovery testing
|
||||
- [x] Parser error recovery testing
|
||||
- Test with corpus/other/eicar.*.xml virus test files
|
||||
- Test with truncated XML files
|
||||
- Test with invalid character encodings
|
||||
- Test with mixed format files
|
||||
- [ ] Implement chaos testing
|
||||
- [x] Implement chaos testing
|
||||
- Random byte corruption
|
||||
- Memory pressure scenarios
|
||||
- Concurrent access testing
|
||||
|
Reference in New Issue
Block a user