ERPNext Supplier ETA Portal

1. Project Overview
This project aims to develop a comprehensive delivery management module within ERPNext, designed to provide granular control and visibility over purchase order line items. The primary goal is to replace the current single-date-per-line model with a flexible, schedule-based system that allows for batch splitting, status tracking, and seamless data exchange via Excel, all without impacting core inventory or accounting modules . The solution will focus on improving usability for procurement teams by providing a powerful, spreadsheet-like interface within the ERP system.

2. Core Functional Requirements
2.1. Unified Delivery Schedule View

Centralized Workspace: Create a new "Delivery Schedule Workbench" that displays one row for every scheduled delivery batch, not one row per order line. This is a fundamental shift from the current ERPNext model where a Purchase Order line typically holds a single quantity and delivery date .

Data Aggregation: For a purchase order with 60 orders and 508 lines, the workbench will flatten the data, showing each individual delivery batch. Each row must include: Part Number (A COMPANY-PN), Revision, Description, Quantity, Order Number, "Required Date", "Promised Date", and a unique "A COMPANY-PN" column .

Dynamic Rows: A standard order line (e.g., 100 units) with a single delivery date will appear as a single row. The system will add a second row only if a user splits the delivery, making the new schedule visible directly on the main screen .

2.2. Line-Level Splitting and Management

Batch Splitting: Users must be able to split a delivery line by specifying a quantity (e.g., 5 of 100). The system will automatically create two distinct rows: one for the split quantity and one for the remainder, each with its own, independently editable date and status.

Quantity Integrity: The system must enforce strict quantity control. The sum of quantities for all delivery rows linked to an order line must always equal the total ordered quantity. The system will reject uploads or edits that violate this rule (e.g., a total of 95 for an order of 100).

2.3. Independent Status Tracking

Non-Inventory Statuses: Introduce a status field for each delivery row with the following options: In Production, Delivered, Scrapped, or Suspended . These statuses are purely informational and serve as communication from the vendor. Crucially, they must not trigger any Goods Receipt, update stock levels, or affect the "ordered against invoiced" values .

Scrap and Replacement Workflow: To scrap a batch, a user changes its status to Scrapped and creates a new row with a replacement quantity and a new delivery date. This allows for full traceability of the issue and the new expected delivery.

2.4. Robust Data Import/Export

Bidirectional Excel Sync: The workbench must support one-click export to Excel and a corresponding import function. The exported file will be a 1:1 representation of the screen data, including all columns (A COMPANY-PN, dates, quantities, statuses) .

Offline Editing: Users can edit the file in Excel (splitting quantities by copying rows, modifying dates, changing statuses) and upload it back. The system will validate the upload, enforce quantity integrity, and update the workbench in ERPNext .

Handling Child Table Data: The import/export logic must correctly handle the "child table" nature of the delivery schedule, where multiple rows (the schedule) belong to a single parent (the order line). This is a common area of complexity in ERPNext data import .

2.5. Filtering, Sorting, and Archiving

Comprehensive Filtering: The workbench must be sortable and filterable on any column, enabling users to find specific part numbers, dates, or A COMPANY-PNs easily .

Hide Fully Delivered Items: The screen must hide order lines where all scheduled delivery rows are marked as Delivered. A single "Show All" toggle should bring these back into view. This declutters the main interface for active work.

Archive for Completed POs: Once all lines on a Purchase Order are fully delivered, the order should automatically drop out of the main "live work" view, potentially moving to a separate "Finished Purchase Orders" page or being easily filtered out.

3. Technical Implementation Strategy
3.1. Custom Doctypes and Fields

Parent Doctype (Delivery Schedule): A new custom DocType to act as the main workbench. It will hold metadata about the schedule and link to the Purchase Order.

Child Doctype (Delivery Schedule Item): A child table DocType to store the individual delivery rows. It will contain fields for:

part_no (Link to Item)

revision (Data)

description (Data)

quantity (Float)

order_number (Link to Purchase Order)

a_company_pn (Data, synced with import/export)

required_date (Date)

promised_date (Date)

status (Select: In Production, Delivered, Scrapped, Suspended)

comments (Small Text, free text)

last_updated (Datetime, auto-updated)

Table Field in Purchase Order: A custom table field (linked to the Delivery Schedule Item child DocType) will be added to the Purchase Order to display and manage the schedule .

3.2. Data Import/Export API

Export API: A server-side script will generate a CSV/Excel file by fetching all active Delivery Schedule Item records for a given set of orders.

Import API: A server-side script will parse the uploaded file. It will perform row-by-row validation, checking that the sum of quantities per order line matches the ordered quantity. If a discrepancy is found, the import process will halt and notify the user of the specific line with the error .

Update Logic: Valid rows will trigger updates to the existing Delivery Schedule Item records, with new rows being created for newly split items.

3.3. Client-Side Development (UI/UX)

Framework: Leverage Frappe's modern UI framework to build a fast, responsive, and spreadsheet-like experience.

JavaScript Logic: Implement front-end logic for splitting rows, updating totals, and validating quantities in real-time.

Frappe Reporting: If needed, custom reports can be built using Frappe's reporting tools to provide dashboards on delivery performance.

4. Key Workflows and Use Cases
Use Case 1: Splitting a Delivery

User views a Purchase Order line for 100 of P/N1 with a single delivery date.
User clicks a "Split" button and enters "5" in the quantity field.
The system automatically creates two rows: 5 (with the original date) and 95 (with a new, editable date).
Each row now has its own editable status .
Use Case 2: Working Offline

User exports the current workbench view to an Excel file.
User edits the file, changing a promised date and marking a row as Delivered.
User uploads the file.
The ERPNext system validates the changes and updates the workbench accordingly .
Use Case 3: Handling Scrap

Vendor informs that a batch of 5 will not be delivered.
User changes the status of the related row to Scrapped.
User adds a new row for a replacement batch of 5 with a new delivery date.
The ordered quantity of 100 remains consistent (5 scrapped + 95 delivered + 5 pending = 105 total, but the original line quantity remains 100, so validation ensures accuracy). The system maintains a historical record of the event.
5. Out of Scope (What This Module Will NOT Do)
Automated Inventory Management: This module is a planning and communication tool. It will not automatically create Purchase Receipts, update stock, or impact accounting .

Financial Adjustments: It will not affect pricing, invoicing, or payment flows. The "ordered against invoiced" calculation remains unaffected .

Direct Integration with External Vendor Systems: The primary interface for vendor communication is the manual update of statuses by the user.