Feature Requirement: BOM Validity Period (Start and End Dates)
Ver | Date | User | Changes |
---|---|---|---|
1.0 | 20240527 | hunglq | Initial creation of BOM validity period feature requirement |
User Story
As a production planner or engineer using ERPNext, I want to set start and end dates for the validity of a BOM so that the system automatically recognizes when a BOM is active or expired. This helps ensure that outdated materials or processes are no longer used in production planning and manufacturing.
Overview
Description:
This feature enables users to define a validity period for each Bill of Materials (BOM) by specifying start and end dates. During BOM creation and update, users will input these dates. The system will enforce validity constraints, such as preventing the use of expired BOMs in production plans and blocking changes to BOM validity if the BOM is already referenced in active production plans.
Purpose:
To improve the accuracy and control of production processes by ensuring only valid BOMs are used, preventing outdated materials or configurations from being applied.
Target Users:
Production planners, manufacturing engineers, procurement staff, and ERPNext administrators involved in BOM management and production planning.
Assumptions
- The ERPNext system supports date fields and relevant validations.
- Production plans and other dependent documents reference BOMs by unique identifiers.
- Users have sufficient permissions to create and update BOMs.
- Existing BOMs may or may not have validity dates — for backward compatibility, such BOMs are considered valid indefinitely unless dates are set.
- BOM usage in production plans can be queried efficiently.
Acceptance Criteria
Criterion 1: Users can specify a start date and an end date for the validity period when creating or updating a BOM.
Test: Create a new BOM and set start = 2024-06-01 and end = 2024-12-31; verify dates are saved correctly.Criterion 2: The system prevents setting an end date earlier than the start date.
Test: Attempt to save a BOM with end date before start date and confirm the validation error is shown.Criterion 3: If a BOM is already used in any active or completed production plan, the system disallows changing the BOM’s start or end dates.
Test: Associate a BOM with a production plan; attempt to edit the validity dates and verify the update is rejected with an appropriate message.Criterion 4: BOMs with no set validity dates are treated as valid indefinitely.
Test: Create a BOM with empty start/end dates and verify it can be selected for production plans at any date.Criterion 5: When creating or updating a production plan, the system warns or blocks selection of BOMs that are expired (current date is after their end date).
Test: Attempt to select a BOM with an end date in the past for a new production plan and verify the system shows an error or prevents selection.Criterion 6: The BOM listing and detail views display the validity period clearly.
Test: Open a BOM record and confirm start and end dates are visible and formatted consistently.Criterion 7: Expired BOMs are still viewable but cannot be used in new production plans.
Test: Search for expired BOMs; verify that they appear in lists but cannot be selected where usage is intended.Criterion 8: Users with sufficient rights can delete or archive expired BOMs but should be warned if referenced in production plans.
Test: Try to delete a BOM referenced in a production plan and verify the system prevents this with a warning.
Constraints
- Validity dates must be in date format (YYYY-MM-DD).
- Updates to validity dates are blocked if the BOM is referenced in production plans.
- The system must maintain backward compatibility with existing BOMs that do not have validity dates.
- User interface forms must clearly indicate required fields and provide tooltips about validity period usage.
- The validity period applies only to production planning and does not affect BOM costing or historical data reporting.
- Timezone consistency - all date fields should be treated as server/local timezone dates without time components.
Technical Requirements
- Database: Add two new date fields
valid_from
andvalid_to
to the BOM master data schema. - Validation: Enforce
valid_to >= valid_from
at data entry level. - Business Logic:
- Prevent selection of expired BOMs in production plans.
- Prevent modifying validity dates if BOM is referenced in any existing production plan.
- UI:
- Date pickers for start and end dates in BOM creation and update forms.
- Visual indicators (e.g., color-coded labels) showing active/expired status on BOM list and detail views.
- API: Support validity dates in BOM APIs for integrations and automated validations.
- Notification: Provide explicit error or warning messages when an action is disallowed due to validity constraints.
- Backward Compatibility: Existing BOMs without dates are treated as always valid.
- Performance: Ensure validation queries for production plans referencing a BOM are optimized to avoid latency on BOM updates.
Notes
- Consider allowing optional override permissions for administrators to update validity dates on BOMs used in production plans, with audit trail.
- Expired BOMs can still be used for historical reporting or quality audits.
- Align terminology with existing ERPNext standards to maintain UI consistency.
- Potential future enhancement: system automatically suggests archiving expired BOMs.
- Ensure proper unit and integration tests to cover all acceptance criteria, especially around production plan locking logic.
Inputs used
Feature Requirement
Prompt body
Similar prompts
Great that you want to validate your mental wellness app idea before investing heavily! Validating early with real potential users can save time, money, and ensure product-market fit. Here’s a practical step-by-step guide tailored for a mobile app-based self-care business using low-cost methods:
Step 1: Define Your Hypotheses and Target Audience
- Identify Core Problem: Clearly state the problem your app solves.
- Define User Persona: Who exactly is your app for? (age, gender, lifestyle, mental wellness goals)
- Value Proposition: What unique benefit does your app offer compared to existing solutions?
Example: “Young professionals aged 25-35 struggling to manage daily stress with limited time, who want quick and effective self-care exercises.”
Step 2: Conduct Desk Research
- Competitor Analysis: Study existing mental wellness/self-care apps (e.g., Headspace, Calm, Sanity & Self).
- Market Validation: Look for market reports, trends, and surveys highlighting user needs in mental wellness.
- Identify Gaps: What are competitors missing that your solution will provide?
Step 3: Build a Simple Landing Page (Pre-Launch or MVP Site)
- Use tools like Carrd or Unbounce to create a single-page website.
- Clearly describe the app’s benefits and features.
- Add a call-to-action (CTA) to collect email addresses of interested users ("Get Early Access," "Join Waitlist").
Purpose: Test interest and gather contact info for early adopters without building the app.
Step 4: Run Targeted Ads and Social Media Tests
- Use Facebook/Instagram or TikTok ads targeted at your user personas with a compelling ad copy and link to your landing page.
- Alternatively, post in relevant mental health and self-care communities on Reddit, Facebook Groups, or LinkedIn.
- Measure click-through rates, sign-ups, and engagement to gauge demand.
Cost tip: Start with a small daily budget ($5-$10) to test waters.
Step 5: Conduct Qualitative Customer Interviews
- Reach out to your email subscribers or community members who signed up.
- Use Zoom or phone calls to interview 5-10 potential users. Focus on:
- Their current coping strategies for mental wellness
- Challenges they face with current solutions/apps
- Feedback on your app concept and willingness to pay
Step 6: Create a Concierge MVP or Wizard of Oz Prototype
- Concierge MVP: Manually deliver core self-care activities you intend to automate, interacting personally with a few users.
- Wizard of Oz: Build a very simple app interface or prototype that looks functional but is manually operated behind the scenes.
Purpose: Validate user engagement and see if your idea really helps users before automating with full development.
Step 7: Run a Minimal Viable Product (MVP) or Prototype Test
- Use no-code tools like Bubble, Adalo, or Glide to build a clickable app prototype or a barebones MVP with core features.
- Deploy to a small user group (from your email list or community).
- Collect quantitative and qualitative feedback on usability, features, and perceived value.
Step 8: Validate Willingness to Pay
- Test pricing and monetization models through surveys or by offering premium early access plans/memberships.
- See if users are willing to pay upfront, subscribe monthly, or prefer freemium options.
Step 9: Analyze and Iterate
- Review all collected data: signup conversion rates, interview insights, prototype usage stats, and payment interest.
- Identify if the demand and user feedback support moving forward.
- Refine the value proposition and features before full build.
Bonus Tips:
- Be Transparent and Ethical: Because it’s mental wellness, ensure you’re clear about the app’s role (not a replacement for professional help) and handle user data sensitively.
- Focus on Core Value: Don’t build everything at once; concentrate on one or two key features that solve a painful and specific problem.
- Build a Community Early: Leverage social media groups or forums for organic growth and validation.
If you want, I can help you draft landing page copy, ad ideas, interview questions, or prototype plans next!