diff --git a/AS400/QCBLLESRC/prd_spec.md b/AS400/QCBLLESRC/prd_spec.md
new file mode 100644
index 0000000..9ab5116
--- /dev/null
+++ b/AS400/QCBLLESRC/prd_spec.md
@@ -0,0 +1,426 @@
+# Product Requirements Document (PRD)
+
+## Title
+COBOL to Java 18 Migration: AS/400 Inventory Management System
+
+## Introduction
+This document outlines the requirements for migrating the existing AS/400 COBOL inventory management system to a modern Java 18 application. The current system consists of multiple COBOL programs that manage material inventory, process transactions (obraty - turnovers), and update material quantities across different plants (zavod) and warehouses (sklad). This migration aims to modernize the codebase, improve maintainability, enhance performance, and leverage contemporary development practices while preserving the core business logic and data integrity.
+
+## Problem Statement
+The current AS/400 COBOL system faces several challenges:
+
+1. **Legacy Technology Stack**: The system relies on IBM i (AS/400) specific COBOL, CL (Control Language), and DDS (Data Description Specifications) which limits the talent pool and increases maintenance costs.
+
+2. **Platform Dependency**: The tight coupling with AS/400 infrastructure makes it difficult to migrate to modern cloud platforms or containerized environments.
+
+3. **Limited Integration Capabilities**: The legacy system has limited ability to integrate with modern REST APIs, microservices, and contemporary enterprise systems.
+
+4. **Development Velocity**: The development cycle for new features is slow due to the specialized nature of the platform and limited tooling support.
+
+5. **Scalability Concerns**: The current architecture may not scale efficiently to handle growing business demands and data volumes.
+
+6. **Technical Debt**: Years of maintenance have resulted in accumulated technical debt, making modifications increasingly complex and risky.
+
+## Objectives
+
+### Primary Objectives
+1. **Migrate Core Business Logic**: Translate all COBOL programs (STAOBR, STAOBR2, STAOBR_2, STAPOR, TABULKY1, TABULKY2, COND1, DUMP_FULL) to Java 18 with equivalent functionality.
+
+2. **Modernize Data Access**: Replace file-based data access (indexed and sequential files) with a modern relational database system (e.g., PostgreSQL, MySQL, or Oracle) using JPA/Hibernate.
+
+3. **Maintain Data Integrity**: Ensure all data migration and processing maintains the same level of integrity and consistency as the current system.
+
+4. **Improve Performance**: Achieve equal or better performance compared to the legacy system, particularly for batch processing operations.
+
+5. **Enable Cloud Deployment**: Design the Java application to be cloud-ready and deployable in containerized environments (Docker/Kubernetes).
+
+### Secondary Objectives
+1. **Enhance Maintainability**: Implement clean code principles, SOLID design patterns, and comprehensive documentation.
+
+2. **Improve Testability**: Establish a comprehensive test suite including unit tests (80%+ coverage), integration tests, and end-to-end tests.
+
+3. **Enable Modern Integration**: Expose functionality through RESTful APIs for integration with other systems.
+
+4. **Implement Monitoring**: Add application performance monitoring (APM), logging, and metrics collection.
+
+5. **Support Future Growth**: Design with extensibility in mind to accommodate future business requirements.
+
+## Requirements
+
+### Functional Requirements
+
+#### FR1: Material Inventory Update (STAOBR Program)
+- **FR1.1**: Read turnover records (OBRATY) sequentially from the database
+- **FR1.2**: Update corresponding inventory records (STAVY) by adding turnover quantities
+- **FR1.3**: Handle multi-key lookups using plant (ZAVOD), warehouse (SKLAD), and material (MATER) identifiers
+- **FR1.4**: Support both indexed (random access) and sequential file processing patterns
+- **FR1.5**: Implement error handling for missing inventory records (INVALID KEY scenarios)
+
+#### FR2: Alternative Processing Methods (STAOBR2, STAOBR_2)
+- **FR2.1**: Support MOVE CORRESPONDING functionality for field-level data transfer
+- **FR2.2**: Implement random access patterns for inventory lookups
+- **FR2.3**: Provide flexible data manipulation capabilities between source and target records
+
+#### FR3: Ordering Process (STAPOR)
+- **FR3.1**: Implement ordering logic for materials
+- **FR3.2**: Maintain transactional integrity for order processing
+- **FR3.3**: Support similar file access patterns as inventory update programs
+
+#### FR4: Array and Table Processing (TABULKY1, TABULKY2)
+- **FR4.1**: Implement array iteration and manipulation using modern Java collections
+- **FR4.2**: Support character array operations and string manipulation
+- **FR4.3**: Provide indexed access to data structures
+
+#### FR5: Conditional Logic (COND1)
+- **FR5.1**: Implement conditional value ranges (88-level condition names)
+- **FR5.2**: Support numeric range validations and condition testing
+- **FR5.3**: Maintain business rule logic integrity
+
+#### FR6: Data Dump Utility (DUMP_FULL)
+- **FR6.1**: Provide debugging and data export capabilities
+- **FR6.2**: Generate formatted output for troubleshooting
+
+### Non-Functional Requirements
+
+#### NFR1: Performance
+- **NFR1.1**: Batch processing must complete within the same or better time as the legacy system
+- **NFR1.2**: Database operations must be optimized with appropriate indexes and query plans
+- **NFR1.3**: Support concurrent processing where applicable (thread-safe operations)
+- **NFR1.4**: Target response time of <100ms for single record operations
+
+#### NFR2: Scalability
+- **NFR2.1**: Design for horizontal scalability in cloud environments
+- **NFR2.2**: Support connection pooling for database access
+- **NFR2.3**: Implement efficient memory management for large batch operations
+
+#### NFR3: Reliability
+- **NFR3.1**: Achieve 99.9% uptime for production systems
+- **NFR3.2**: Implement transaction rollback for failed operations
+- **NFR3.3**: Provide comprehensive error handling and logging
+- **NFR3.4**: Support data validation at all input points
+
+#### NFR4: Maintainability
+- **NFR4.1**: Follow Java coding standards and best practices
+- **NFR4.2**: Maintain comprehensive JavaDoc documentation
+- **NFR4.3**: Achieve minimum 80% code coverage with unit tests
+- **NFR4.4**: Use dependency injection (Spring Framework)
+- **NFR4.5**: Implement separation of concerns (layered architecture)
+
+#### NFR5: Security
+- **NFR5.1**: Implement database access control and authentication
+- **NFR5.2**: Encrypt sensitive data in transit and at rest
+- **NFR5.3**: Follow OWASP security guidelines
+- **NFR5.4**: Implement audit logging for all data modifications
+- **NFR5.5**: Support role-based access control (RBAC)
+
+#### NFR6: Portability
+- **NFR6.1**: Use Java 18 LTS features for long-term support
+- **NFR6.2**: Avoid platform-specific dependencies
+- **NFR6.3**: Package as container images (Docker)
+- **NFR6.4**: Support multiple database backends through JPA
+
+#### NFR7: Observability
+- **NFR7.1**: Integrate with logging frameworks (SLF4J/Logback)
+- **NFR7.2**: Expose metrics via Micrometer/Prometheus
+- **NFR7.3**: Support distributed tracing (OpenTelemetry)
+- **NFR7.4**: Implement health checks and readiness probes
+
+## User Stories
+
+### US1: Batch Processing Operator
+**As a** batch processing operator  
+**I want to** run inventory update jobs efficiently  
+**So that** material quantities are updated accurately and in a timely manner
+
+**Acceptance Criteria:**
+- Job can be triggered via command line or scheduled task
+- Progress is visible through logs and monitoring dashboards
+- Errors are clearly reported with actionable messages
+- Job completion status is recorded for audit purposes
+
+### US2: System Administrator
+**As a** system administrator  
+**I want to** deploy and configure the application in cloud environments  
+**So that** we can leverage modern infrastructure and reduce operational costs
+
+**Acceptance Criteria:**
+- Application can be deployed via Docker containers
+- Configuration is externalized using environment variables or config files
+- Application supports health checks for load balancer integration
+- Resource usage is monitored and optimized
+
+### US3: Database Administrator
+**As a** database administrator  
+**I want to** ensure data integrity during migration and operation  
+**So that** business operations continue without data loss or corruption
+
+**Acceptance Criteria:**
+- Migration scripts preserve all data from legacy system
+- Referential integrity is enforced through database constraints
+- Transactions ensure atomicity of operations
+- Backup and recovery procedures are documented and tested
+
+### US4: Application Developer
+**As an** application developer  
+**I want to** easily understand and modify the codebase  
+**So that** I can implement new features and fix bugs efficiently
+
+**Acceptance Criteria:**
+- Code follows consistent style guidelines
+- Documentation explains business logic and technical decisions
+- Unit tests provide examples of usage
+- Development environment setup is automated and documented
+
+### US5: Integration Developer
+**As an** integration developer  
+**I want to** access inventory functions via REST API  
+**So that** I can integrate with other enterprise systems
+
+**Acceptance Criteria:**
+- RESTful endpoints are documented using OpenAPI/Swagger
+- API supports standard HTTP methods (GET, POST, PUT, DELETE)
+- Authentication and authorization are properly implemented
+- API versioning is supported
+
+### US6: Quality Assurance Engineer
+**As a** QA engineer  
+**I want to** validate that the new system behaves identically to the legacy system  
+**So that** we can confidently migrate to production
+
+**Acceptance Criteria:**
+- Automated tests compare outputs between old and new systems
+- Performance benchmarks show equal or better results
+- All edge cases and error conditions are tested
+- Test data covers representative production scenarios
+
+## Acceptance Criteria
+
+### AC1: Functional Equivalence
+- [ ] All COBOL programs have equivalent Java implementations
+- [ ] Output data matches legacy system for identical inputs (verified through parallel runs)
+- [ ] All business rules and calculations produce identical results
+- [ ] Error handling behavior is consistent with legacy system
+
+### AC2: Data Migration
+- [ ] All data from AS/400 database files is migrated to target database
+- [ ] Data integrity is verified through checksums and row counts
+- [ ] Referential relationships are preserved
+- [ ] No data loss during migration process
+
+### AC3: Performance
+- [ ] Batch processing completes within 90% of legacy system time
+- [ ] Single transaction response time is under 100ms (p95)
+- [ ] System handles peak load (defined as 2x average load) without degradation
+- [ ] Memory usage is optimized and within defined limits
+
+### AC4: Code Quality
+- [ ] All code passes static analysis (SonarQube) with A grade
+- [ ] Unit test coverage exceeds 80%
+- [ ] Integration tests cover all major workflows
+- [ ] Code review approval from at least 2 senior developers
+
+### AC5: Documentation
+- [ ] Architecture documentation explains system design and key decisions
+- [ ] API documentation is complete and accurate (OpenAPI/Swagger)
+- [ ] Deployment guide covers all environments
+- [ ] Runbooks exist for common operational tasks
+- [ ] Database schema is documented with ER diagrams
+
+### AC6: Security
+- [ ] Security scan shows no high or critical vulnerabilities
+- [ ] Authentication and authorization are implemented
+- [ ] Sensitive data is encrypted
+- [ ] Audit logging captures all data modifications
+- [ ] Security review approved by security team
+
+### AC7: Operational Readiness
+- [ ] Application successfully deploys in all environments (dev, test, staging, production)
+- [ ] Monitoring and alerting are configured
+- [ ] Backup and recovery procedures are tested
+- [ ] Disaster recovery plan is documented and validated
+- [ ] Production support team is trained
+
+## Timeline
+
+### Phase 1: Planning and Architecture (Weeks 1-3)
+- **Week 1**: Requirements gathering and stakeholder alignment
+- **Week 2**: Architecture design and technology stack selection
+- **Week 3**: Development environment setup and team training
+
+### Phase 2: Data Migration Planning (Weeks 4-5)
+- **Week 4**: Data mapping and transformation logic design
+- **Week 5**: Migration scripts development and testing
+
+### Phase 3: Core Application Development (Weeks 6-12)
+- **Week 6-7**: Database layer implementation (JPA entities, repositories)
+- **Week 8-9**: Business logic layer (service classes)
+- **Week 9-10**: Batch processing implementation (STAOBR family programs)
+- **Week 11**: Utility programs implementation (TABULKY, COND1, DUMP_FULL)
+- **Week 12**: Integration layer (REST APIs)
+
+### Phase 4: Testing and Quality Assurance (Weeks 13-16)
+- **Week 13-14**: Unit and integration testing
+- **Week 15**: Performance testing and optimization
+- **Week 16**: Security testing and vulnerability remediation
+
+### Phase 5: Data Migration Execution (Weeks 17-18)
+- **Week 17**: Data migration dry runs in test environment
+- **Week 18**: Final data migration and validation
+
+### Phase 6: Deployment and Go-Live (Weeks 19-20)
+- **Week 19**: Production deployment and parallel run
+- **Week 20**: Go-live and post-deployment validation
+
+### Phase 7: Hypercare and Stabilization (Weeks 21-24)
+- **Weeks 21-24**: Production support, issue resolution, and optimization
+
+**Total Duration**: 24 weeks (approximately 6 months)
+
+## Dependencies
+
+### Technical Dependencies
+1. **Java Development Kit (JDK) 18**: Core runtime environment
+2. **Spring Framework 6.x**: Dependency injection, transaction management
+3. **Spring Boot 3.x**: Application configuration and runtime
+4. **Hibernate/JPA**: Object-relational mapping
+5. **Database**: PostgreSQL 14+ or equivalent relational database
+6. **Build Tool**: Maven 3.8+ or Gradle 8+
+7. **Container Runtime**: Docker 20+, Kubernetes 1.25+
+8. **Monitoring**: Prometheus, Grafana, ELK Stack
+9. **CI/CD**: Jenkins, GitLab CI, or GitHub Actions
+
+### External Dependencies
+1. **AS/400 Access**: Read access to legacy system for data extraction and parallel testing
+2. **Database Infrastructure**: Provisioned database instances for dev, test, and production
+3. **Cloud Infrastructure**: Cloud platform account and resources (if cloud deployment)
+4. **Network Connectivity**: Secure network access between legacy and new systems
+5. **Load Testing Tools**: JMeter, Gatling, or equivalent for performance testing
+
+### Team Dependencies
+1. **COBOL SMEs**: Subject matter experts to clarify business logic and validate translations
+2. **Database Administrators**: For database design, migration, and optimization
+3. **DevOps Engineers**: For CI/CD pipeline setup and infrastructure provisioning
+4. **Security Team**: For security reviews and compliance validation
+5. **Business Stakeholders**: For requirements clarification and acceptance testing
+
+### Process Dependencies
+1. **Change Management**: Approval process for production deployment
+2. **Data Governance**: Policies for data handling and migration
+3. **Testing Environments**: Availability of isolated environments for testing
+4. **Documentation Standards**: Templates and guidelines for technical documentation
+
+## Risks
+
+### R1: Incomplete Business Logic Understanding
+**Description**: COBOL code may contain undocumented business rules or edge cases  
+**Impact**: High - Could result in incorrect behavior in production  
+**Probability**: Medium  
+**Mitigation Strategy**:
+- Conduct thorough code walkthrough sessions with COBOL SMEs
+- Implement comprehensive test cases based on production data samples
+- Perform parallel runs comparing legacy and new system outputs
+- Use feature flags to gradually migrate functionality
+
+### R2: Performance Degradation
+**Description**: Java application may not match COBOL performance for batch operations  
+**Impact**: High - Could impact business operations and SLAs  
+**Probability**: Medium  
+**Mitigation Strategy**:
+- Conduct early performance baseline testing
+- Optimize database queries and indexes
+- Implement batch processing optimizations (batch inserts, parallel processing)
+- Use profiling tools to identify and address bottlenecks
+- Consider horizontal scaling if needed
+
+### R3: Data Migration Failures
+**Description**: Data corruption or loss during migration from AS/400 to new database  
+**Impact**: Critical - Could result in business disruption and data loss  
+**Probability**: Low  
+**Mitigation Strategy**:
+- Develop comprehensive data validation scripts
+- Perform multiple dry-run migrations in test environments
+- Implement checksums and data integrity verification
+- Maintain backup of legacy system during initial go-live period
+- Plan for rollback procedures
+
+### R4: Schedule Delays
+**Description**: Development may take longer than estimated due to unforeseen complexity  
+**Impact**: Medium - Could delay business benefits and increase costs  
+**Probability**: Medium  
+**Mitigation Strategy**:
+- Build buffer time into schedule (20% contingency)
+- Use agile methodology with regular sprint reviews
+- Prioritize core functionality (MVP approach)
+- Identify critical path items early and allocate additional resources
+- Regular status reviews with stakeholders
+
+### R5: Knowledge Transfer Gap
+**Description**: Team may lack sufficient COBOL or AS/400 expertise  
+**Impact**: Medium - Could result in misinterpretation of business logic  
+**Probability**: Medium  
+**Mitigation Strategy**:
+- Engage COBOL SMEs throughout the project
+- Document all business logic discoveries
+- Create knowledge base with code explanations
+- Pair programming between COBOL and Java developers
+- Maintain access to legacy system for reference
+
+### R6: Integration Challenges
+**Description**: Difficulty integrating with existing enterprise systems  
+**Impact**: Medium - Could limit functionality of new system  
+**Probability**: Low  
+**Mitigation Strategy**:
+- Early identification of integration points
+- API-first design approach
+- Use of standard protocols and formats
+- Early integration testing with dependent systems
+- Maintain adapter pattern for flexibility
+
+### R7: Security Vulnerabilities
+**Description**: New system may introduce security vulnerabilities  
+**Impact**: High - Could result in data breaches or compliance violations  
+**Probability**: Low  
+**Mitigation Strategy**:
+- Regular security scanning during development
+- Follow OWASP secure coding guidelines
+- Implement security reviews at each phase
+- Use established security frameworks (Spring Security)
+- Conduct penetration testing before go-live
+
+### R8: Resistance to Change
+**Description**: Users and operators may resist moving away from familiar legacy system  
+**Impact**: Medium - Could impact adoption and operational efficiency  
+**Probability**: Medium  
+**Mitigation Strategy**:
+- Early stakeholder engagement and communication
+- Comprehensive training programs
+- User documentation and quick reference guides
+- Phased rollout approach
+- Dedicated support during transition period
+
+## Conclusion
+
+The migration of the AS/400 COBOL inventory management system to Java 18 represents a significant modernization initiative that will position the organization for future growth and agility. This PRD outlines a comprehensive approach to translating the existing business logic while adopting modern development practices, cloud-ready architecture, and enhanced operational capabilities.
+
+**Key Success Factors:**
+1. **Functional Equivalence**: Ensuring the new system replicates all business logic exactly
+2. **Data Integrity**: Maintaining perfect data fidelity through migration and ongoing operations
+3. **Performance**: Matching or exceeding legacy system performance
+4. **Team Collaboration**: Close cooperation between COBOL experts and Java developers
+5. **Thorough Testing**: Comprehensive validation through parallel runs and automated testing
+
+**Expected Benefits:**
+1. **Reduced Maintenance Costs**: Modern technology stack with broader talent pool
+2. **Improved Agility**: Faster feature development and deployment cycles
+3. **Cloud Enablement**: Ability to leverage cloud economics and scalability
+4. **Better Integration**: Seamless connectivity with modern enterprise systems
+5. **Enhanced Observability**: Superior monitoring, logging, and troubleshooting capabilities
+
+**Next Steps:**
+1. **Stakeholder Review**: Distribute PRD to all stakeholders for review and approval
+2. **Team Formation**: Assemble development team with required skill sets
+3. **Environment Setup**: Provision development, test, and staging environments
+4. **Architecture Workshop**: Finalize technical architecture and design patterns
+5. **Sprint 0**: Initialize project infrastructure, CI/CD pipelines, and development standards
+
+This migration project is estimated at 24 weeks with a cross-functional team. Success will require commitment from both technical teams and business stakeholders, with clear communication and rigorous quality control throughout the process. The resulting system will provide a solid foundation for the organization's inventory management needs for years to come.