Backlog

Next up

In Progress

Done

Main Roadmap

Users need line items to display in the same order as they appear in the original document. Currently, the platform may change the sequence, making it harder to review and verify information quickly. 

 To solve this, we plan to add an index field to each line item. This index will preserve the original document order and ensure line items display in the correct sequence. Users will also have the flexibility to manually reorder line items as needed.

In Review

Preserve Original Document Order for Line Items

An Anonymous User

Users would benefit from quick access to commonly filtered document views. The current filtering process involves navigating a complex filter panel, which can be inefficient. Streamlining this would save time and improve the user experience. To address this, we propose implementing 'quick filters' as clickable chips above the documents table. These filters would provide one-click access to pre-defined filter combinations such as status, date ranges, payment status and document types, leading to a faster and more intuitive filtering experience.

Implement Quick Filter Chips for Document Views

Users have expressed a need for a more streamlined way to access frequently used document views. Currently, filtering documents requires navigating through a detailed filter panel, which can be time-consuming. A simpler, more direct method is desired for common filtering tasks. 

 To address this, we propose implementing "quick filters" as clickable buttons or chips displayed above the document table. These quick filters will offer one-click access to pre-defined filter combinations for status, date ranges, payment status, and document type, enhancing efficiency and ease of use.

Users need a more efficient way to access commonly used document views. Currently, filtering through documents requires navigating complex filter panels, which can be time-consuming. This makes it difficult to quickly find documents based on specific statuses, time periods, or types. 

 A new feature will be implemented to allow users to instantly filter documents with a single click using quick filter chips located above the documents table. These quick filters will provide one-click access to frequently used filter combinations, such as status filters, date shortcuts, payment status, and document type, improving overall efficiency.

Implement Quick Filter Chips for Documents Table

<p><strong>Why</strong></p>
<p>Users need quick access to commonly filtered document views without navigating through complex filter panels. Quick filters reduce time spent searching for documents by providing one-click access to frequently used filter combinations. This improves efficiency when reviewing documents across different statuses, time periods, and types.</p>
<p><strong>What</strong></p>
<p>Implement quick filter chips above the documents table that allow users to instantly filter documents with a single click.</p>
<p>Quick filter options:</p>
<ul>
<li><strong>Status filters:</strong> All, Pending Review, Approved, Rejected</li>
<li><strong>Date shortcuts:</strong> This Week, This Month, Last 30 Days, Last 90 Days</li>
<li><strong>Payment status:</strong> All, Paid, Unpaid</li>
<li><strong>Document type:</strong> All Documents, Invoices, Purchase Orders, Receipts</li>
</ul>
<p>Filters should:</p>
<ul>
<li>Display as clickable chips/buttons above the table</li>
<li>Show active state when selected</li>
<li>Work alongside sorting functionality from <a href="https://linear.app/coreloops/issue/COR-1099">COR-1099</a></li>
<li>Allow multiple filters to be active simultaneously</li>
<li>Include a "Clear All" option to reset filters</li>
</ul>
<p><strong>How</strong></p>
<ol>
<li>Create filter chip component with active/inactive states</li>
<li>Add filter chip container above documents table</li>
<li>Implement filter logic to update table query parameters</li>
<li>Ensure filters persist during pagination and sorting</li>
<li>Add visual feedback for active filters (highlight, count badge)</li>
<li>Implement filter combination logic (filters work as AND conditions)</li>
<li>Store active filters in session state</li>
</ol>
<p><strong>Dependencies</strong></p>
<ul>
<li>Documents table component</li>
<li>Backend API support for multiple filter parameters</li>
<li>Sorting functionality from <a href="https://linear.app/coreloops/issue/COR-1099">COR-1099</a></li>
<li>Figma design specifications: <a href="https://www.figma.com/design/CHGxZf6kRS53EKMv0gbaWY/Documents?node-id=924-141592">https://www.figma.com/design/CHGxZf6kRS53EKMv0gbaWY/Documents?node-id=924-141592</a></li>
</ul>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>[ ] Quick filter chips display above documents table</li>
<li>[ ] Clicking a filter chip activates/deactivates the filter</li>
<li>[ ] Active filters show visual indication (highlighted state)</li>
<li>[ ] Multiple filters can be active simultaneously</li>
<li>[ ] Filters work correctly with sorting from <a href="https://linear.app/coreloops/issue/COR-1099/add-sorting-on-all-sections-of-documents-page">COR-1099</a></li>
<li>[ ] "Clear All" button removes all active filters</li>
<li>[ ] Filter state persists during pagination</li>
<li>[ ] Filter state persists during sorting changes</li>
<li>[ ] Table updates immediately when filters change</li>
<li>[ ] UI matches Figma design specifications</li>
</ul>

Quick Filters for documents

Linear

Customers need more flexibility in reporting to analyze data based on specific criteria and timeframes. They require the ability to create custom reports tailored to their unique business needs and export this data for further analysis. 

This ticket proposes enhancing the reporting functionality to allow users to define custom parameters, select specific data fields, and schedule automated report generation. It also includes adding flexible export options such as CSV or Excel.

Enhanced Reporting for Custom Data Analysis and Export

Users require more control over which projects and suppliers are synced with their accounting software. Certain projects may be internal or contain test data, and some suppliers might need unique accounting outside the automated system. This flexibility ensures that only relevant and finalized data is transferred. 

We propose adding features to exclude specific projects and suppliers from the automatic sync. This will enable users to customize their sync settings, ensuring accurate and relevant data is processed by their accounting software.

Granular Control for Excluding Projects and Suppliers

Need: Customers require better insight into why documents occasionally fail to process. Currently, these documents disappear from view, creating a blind spot that can lead to missed invoices or costs. This lack of visibility poses a risk to financial tracking and operational efficiency.

Solution: We plan to improve document handling by displaying failed documents with a clear status and explanation of the failure. We will also implement both email and in-platform notifications to promptly inform users of any processing issues, ensuring no document goes unnoticed.

Enhance Document Processing Visibility and Notifications

Customers need a way to improve the accuracy of document parsing, cost code assignment, and supplier identification, as current AI prompts struggle with the variety of invoice formats and naming conventions. A solution is needed to allow users to provide specific instructions for each supplier. We propose adding a custom AI prompt field to the supplier create and edit forms. This will allow users to enter specific instructions for the AI, improving its ability to accurately parse documents and assign cost codes for that supplier.

Custom AI Prompts for Improved Supplier Document Parsing

Our customers need a way to improve the accuracy of document parsing, cost code assignment, and supplier identification for suppliers with unique invoice formats and relationships. Currently, the AI model uses a generic prompt that doesn't always account for these supplier-specific nuances. This results in inefficiencies and potential errors in processing supplier documents. 

We propose adding a "Custom AI Prompt" field to the supplier create and edit forms within the platform. This field will allow users to input specific instructions for the AI, tailored to individual suppliers, enabling more accurate and efficient document processing. This feature will expose the existing backend `custom_ai_prompt` capability to users through the UI, providing greater control over AI parsing.

Custom AI prompts for improved supplier document parsing

Many suppliers have specific invoice formats and naming styles, which can make it difficult to accurately process documents. This also affects how costs are assigned and how suppliers are identified. Because of these differences, customers need a way to provide specific instructions for each supplier. 

We can add a new field in the supplier settings where users can input custom instructions for our AI. This will help the AI better understand and process documents from that specific supplier, improving accuracy and efficiency.

Planned

Documents

Custom AI Instructions to Improve Supplier Parsing Accuracy

Gabriel Makinwa

Users need more control over how documents are synchronized with their accounting systems. Currently, the system automatically syncs documents, but users require the ability to manage the timing and status of these syncs to better align with their workflows and compliance needs. 

This ticket proposes adding configurable options that allow users to map Coreloops statuses to accounting system statuses. It also introduces a manual sync workflow and a sync status filter in the documents table. These features will provide greater flexibility and visibility into the document synchronization process.

Integration

Configurable document sync to accounting system

chloe

<p>Allow the user to choose which section a variation is published to. In the Modal allow the user to create a new section.</p>
<p>Default the name to variations.</p>

Choose which section a variation is published to

<h2 id="why">Why</h2>
<p>Variations (change orders) significantly impact project budgets and timelines. Users need to chat with CorePilot about variation status, approvals, financial impacts, and relationships to payment applications. Questions like "What's the total value of approved variations?" or "Show unapproved variations affecting margin" require variation context.</p>
<h2 id="what">What</h2>
<p>Index all variation-related data and enable conversational queries about:</p>
<ul>
<li>Variation orders (VO numbers, descriptions, values)</li>
<li>Approval status and workflows (internal, client approvals)</li>
<li>Financial impact (added/removed amounts, margin effects)</li>
<li>Relationships to payment applications and certifications</li>
<li>Line item details (BoQ items affected, quantities, rates)</li>
</ul>
<h2 id="how">How</h2>
<h3 id="dataindexingcoreloopsai">Data indexing (coreloops-ai)</h3>
<p><strong>Vector DB seeding:</strong></p>
<ul>
<li>Extract variation data from main DB</li>
<li>Structure context documents:</li>
<li>Variation header: VO number, description, supplier, total value</li>
<li>Approval status: internal/client approval states, dates, approvers</li>
<li>Line items: BoQ references, quantities, rates, subtotals</li>
<li>Payment links: which payment applications include this VO</li>
<li>Financial impact: effect on budget, margin, forecast</li>
<li>Generate embeddings for semantic search</li>
<li>Update on variation creation/modification</li>
</ul>
<p><strong>Query capabilities:</strong></p>
<ul>
<li>Filter by: status (approved/pending/rejected), value ranges, dates</li>
<li>Aggregate: total variation value, approved vs pending</li>
<li>Join: variations → payment applications, variations → suppliers</li>
<li>Calculate: impact on budget utilisation, margin erosion</li>
</ul>
<h3 id="chatprompts">Chat prompts</h3>
<p><strong>Sample queries to support:</strong></p>
<ul>
<li>"Show all pending variations awaiting client approval"</li>
<li>"What's the total value of variations this month?"</li>
<li>"List variations for [supplier name]"</li>
<li>"Which variations are in payment application #5?"</li>
<li>"Show proceed-at-risk variations"</li>
<li>"What's the impact of approved variations on our margin?"</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>COR-1267: Parent chat interface</li>
<li>COR-1398: Tenant data guardrails</li>
<li>Variation data model and approval workflows</li>
<li>Payment application linkage</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] All variation orders indexed with full details</li>
<li>[ ] Approval status and workflow state available in chat</li>
<li>[ ] Users can query variations by status, supplier, value, date</li>
<li>[ ] Chat calculates total variation impact on budget and margin</li>
<li>[ ] Variation-to-payment-application relationships surfaced</li>
<li>[ ] Line item details accessible through chat</li>
<li>[ ] Proceed-at-risk variations flagged in responses</li>
<li>[ ] Queries scoped to user's tenant and project permissions</li>
<li>[ ] Context updates when variations created/approved/modified</li>
</ul>

Variations

<h2 id="why">Why</h2>
<p>Payment applications (valuations) are critical monthly snapshots of project financial status. Users need to chat about certification gaps, retention, historical trends, and supplier claims. Questions like "What's the gap between applied and certified this period?" or "Show payment application history for cost code 02" require detailed valuation context.</p>
<h2 id="what">What</h2>
<p>Index payment application data to enable queries about:</p>
<ul>
<li>Valuation summaries (numbers, dates, total values)</li>
<li>Line item details (BoQ items, claimed vs certified amounts)</li>
<li>Retention calculations and release status</li>
<li>Variations included in each application</li>
<li>Period-over-period trends</li>
<li>Supplier-specific applications</li>
</ul>
<h2 id="how">How</h2>
<h3 id="dataindexingcoreloopsai">Data indexing (coreloops-ai)</h3>
<p><strong>Vector DB seeding:</strong></p>
<ul>
<li>Extract payment application data from DB</li>
<li>Structure context documents:</li>
<li>Application header: valuation number, date, supplier, total applied/certified</li>
<li>Line items: BoQ references, quantities, rates, applied %, certified %</li>
<li>Retention: amount held, cumulative retention, release dates</li>
<li>Variations: VOs included, amounts</li>
<li>Summary metrics: total applied, certified, gap, retention</li>
<li>Historical comparison: vs previous application, cumulative totals</li>
<li>Generate embeddings for search</li>
<li>Update on application submission/certification</li>
</ul>
<p><strong>Query capabilities:</strong></p>
<ul>
<li>Filter by: application number, supplier, date, status</li>
<li>Aggregate: total applied, certified, gaps, retention held</li>
<li>Trend: period-over-period changes, cumulative progression</li>
<li>Drill-down: specific cost codes, BoQ items within applications</li>
</ul>
<h3 id="chatprompts">Chat prompts</h3>
<p><strong>Sample queries to support:</strong></p>
<ul>
<li>"Show the latest payment application status"</li>
<li>"What's the certification gap in valuation #8?"</li>
<li>"List all payment applications from [supplier]"</li>
<li>"Show retention held across all applications"</li>
<li>"Compare this month's application to last month"</li>
<li>"Which line items were reduced in certification?"</li>
<li>"What's the total uncertified work in progress?"</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>COR-1267: Parent chat interface</li>
<li>COR-1398: Tenant data guardrails</li>
<li>Payment application data model</li>
<li>Variation linkage</li>
<li>Retention calculation logic</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] All payment applications indexed with line item detail</li>
<li>[ ] Users can query applications by number, supplier, date</li>
<li>[ ] Chat calculates certification gaps (applied vs certified)</li>
<li>[ ] Retention amounts surfaced in responses</li>
<li>[ ] Variations included in applications shown</li>
<li>[ ] Period-over-period comparisons available</li>
<li>[ ] Drill-down to specific cost codes and BoQ items</li>
<li>[ ] Uncertified WIP calculated correctly</li>
<li>[ ] Historical application data accessible</li>
<li>[ ] Queries scoped to tenant and project permissions</li>
<li>[ ] Context updates on new applications and certifications</li>
</ul>

Payment Application

<h2 id="why">Why</h2>
<p>Construction projects involve numerous documents (invoices, contracts, certificates, correspondence) that provide critical context. Users need to chat about document status, contents, and relationships. Questions like "Show all invoices over £5k this month" or "What documents are pending approval?" require document metadata and content in CorePilot context.</p>
<h2 id="what">What</h2>
<p>Index document metadata and enable queries about:</p>
<ul>
<li>Invoice documents (supplier, amounts, dates, cost codes)</li>
<li>Contract documents (values, terms, parties)</li>
<li>Certificates (types, dates, values)</li>
<li>Supporting documents (correspondence, change notices)</li>
<li>Document status and approval workflows</li>
<li>Relationships to suppliers, variations, payment applications</li>
</ul>
<h2 id="how">How</h2>
<h3 id="dataindexingcoreloopsai">Data indexing (coreloops-ai)</h3>
<p><strong>Vector DB seeding:</strong></p>
<ul>
<li>Extract document metadata from DB</li>
<li>Structure context documents:</li>
<li>Document profile: type, name, reference, upload date</li>
<li>Financial details: amount, currency, cost code allocation</li>
<li>Relationships: supplier, project, variation, payment application links</li>
<li>Status: approval state, workflow position, pending actions</li>
<li>Content summary: key fields extracted from document</li>
<li>Generate embeddings for semantic search</li>
<li>Update on document upload/modification</li>
</ul>
<p><strong>Query capabilities:</strong></p>
<ul>
<li>Filter by: document type, supplier, amount ranges, dates, status</li>
<li>Search: document content (if OCR/text extraction available)</li>
<li>Aggregate: total invoice amounts, document counts by type</li>
<li>Join: documents → suppliers → payment applications</li>
</ul>
<h3 id="chatprompts">Chat prompts</h3>
<p><strong>Sample queries to support:</strong></p>
<ul>
<li>"Show all invoices uploaded this week"</li>
<li>"What documents are pending approval?"</li>
<li>"List invoices from [supplier] over £10k"</li>
<li>"Which documents are linked to variation VO-123?"</li>
<li>"Show all certificates for this project"</li>
<li>"What's the total value of invoices awaiting payment?"</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>COR-1267: Parent chat interface</li>
<li>COR-1398: Tenant data guardrails</li>
<li>Document data model and storage</li>
<li>Document approval workflows</li>
<li>Supplier and payment application linkage</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] All document metadata indexed in vector DB</li>
<li>[ ] Users can query documents by type, supplier, amount, date</li>
<li>[ ] Document approval status available in chat responses</li>
<li>[ ] Relationships to suppliers, variations, applications surfaced</li>
<li>[ ] Financial totals calculated (invoice values, pending amounts)</li>
<li>[ ] Document content searchable (if text extraction available)</li>
<li>[ ] Queries filtered to user's tenant and permissions</li>
<li>[ ] Context updates on document upload/status changes</li>
<li>[ ] Links to view full documents provided in responses</li>
</ul>

<h2 id="why">Why</h2>
<p>To enable meaningful chat about suppliers, CorePilot needs comprehensive context about subcontractor relationships, payment histories, invoice details, and financial status. Users frequently ask "Which suppliers are we behind on payments?" or "Show me all invoices from X supplier" - these require rich supplier data in the AI context.</p>
<h2 id="what">What</h2>
<p>Index all supplier-related data into CorePilot's vector database and enable natural language queries:</p>
<ul>
<li>Supplier master data (names, contacts, payment terms, categories)</li>
<li>Invoice history (amounts, dates, statuses, cost codes)</li>
<li>Payment history (paid amounts, dates, outstanding balances)</li>
<li>Contract details (values, retention rates, payment schedules)</li>
<li>Performance metrics (payment application claims, certifications)</li>
</ul>
<h2 id="how">How</h2>
<h3 id="dataindexingcoreloopsai">Data indexing (coreloops-ai)</h3>
<p><strong>Vector DB seeding:</strong></p>
<ul>
<li>Extract supplier data from main DB (suppliers table)</li>
<li>Structure context documents:</li>
<li>Supplier profile: name, contact, category, payment terms</li>
<li>Invoice summary: total invoiced, paid, outstanding by supplier</li>
<li>Payment history: chronological payment records</li>
<li>Contract summary: PO values, retention, terms</li>
<li>Generate embeddings and store in corepilot_contexts table</li>
<li>Implement incremental updates on supplier/invoice changes</li>
</ul>
<p><strong>Query capabilities:</strong></p>
<ul>
<li>Enable SQL generation for supplier-specific queries</li>
<li>Add filters: supplier name, outstanding amounts, date ranges</li>
<li>Calculate aggregations: total outstanding, average payment time</li>
<li>Support joins: supplier → invoices → payments</li>
</ul>
<h3 id="chatprompts">Chat prompts</h3>
<p><strong>Sample queries to support:</strong></p>
<ul>
<li>"Show all suppliers with outstanding balances over £10k"</li>
<li>"What's the payment history for [supplier name]?"</li>
<li>"Which suppliers have we paid this month?"</li>
<li>"List all invoices from [supplier] for cost code 01"</li>
<li>"What's our total outstanding to subcontractors?"</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>COR-1267: Parent chat interface</li>
<li>COR-1398: Tenant data guardrails</li>
<li>Supplier data model and invoice schema</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] All supplier master data indexed in vector DB</li>
<li>[ ] Invoice and payment history available for chat queries</li>
<li>[ ] Users can query suppliers by name, category, or financial status</li>
<li>[ ] Chat returns supplier payment history with amounts and dates</li>
<li>[ ] Outstanding balances calculated correctly per supplier</li>
<li>[ ] Queries filtered to user's tenant only</li>
<li>[ ] Supplier context updates when new invoices/payments added</li>
<li>[ ] Chat can surface suppliers requiring attention (overdue, over budget)</li>
</ul>

Suppliers

<h2 id="why">Why</h2>
<p>Operatives are best positioned to provide accurate information about their work hours, breaks, and job activities. Currently, they cannot input this data directly, leading to inaccuracies, delays, and dependence on supervisors or office staff to manually enter timesheet information.</p>
<h2 id="what">What</h2>
<p>A self-service interface for operatives to view, update and submit their own timesheets. The system respects configurable review workflows, routing submissions to either supervisors or office staff based on organisational settings.</p>
<h2 id="how">How</h2>
<ul>
<li>Create operative-specific timesheet view showing their scheduled and actual hours</li>
<li>Build interface for operatives to update their timesheet entries (hours worked, breaks, job details)</li>
<li>Implement timesheet submission workflow</li>
<li>Add validation to prevent submission of incomplete timesheets</li>
<li>Display timesheet status and review workflow</li>
<li>Route submissions based on settings (supervisor review vs office review)</li>
<li>Implement mobile-first design for field access</li>
<li>Add read-only view for approved timesheets</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>Operative user authentication</li>
<li>Timesheet settings configuration (review workflow)</li>
<li>Timesheet data model</li>
<li>Notification system for submission confirmations</li>
<li>COR-1478 (parent feature)</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] Operatives can view their own timesheets (scheduled and actual)</li>
<li>[ ] Operatives can update hours worked, breaks, and job details</li>
<li>[ ] Operatives can submit timesheets when complete</li>
<li>[ ] Clear validation prevents submission of incomplete data</li>
<li>[ ] Timesheet status visible to operative (draft, submitted, approved, rejected)</li>
<li>[ ] Submissions route correctly based on review settings (supervisor or office)</li>
<li>[ ] Operatives receive confirmation when timesheet is submitted</li>
<li>[ ] Approved timesheets are read-only</li>
<li>[ ] Rejected timesheets can be edited and resubmitted</li>
<li>[ ] Interface is mobile-responsive for use on phones in the field</li>
<li>[ ] Operatives can only access their own timesheets</li>
</ul>

Operative view

<h2 id="why">Why</h2>
<p>Supervisors have direct oversight of operative work and schedules but currently cannot input or manage timesheet data. This creates dependency on office staff and delays in timesheet processing, whilst reducing accuracy as supervisors cannot verify work performed.</p>
<h2 id="what">What</h2>
<p>A supervisor-specific interface for managing operative timesheets, including the ability to schedule shifts, update hours worked, and submit timesheets for payroll processing.</p>
<h2 id="how">How</h2>
<ul>
<li>Create supervisor dashboard showing all operatives under their supervision</li>
<li>Build timesheet creation interface for scheduling operative shifts</li>
<li>Implement timesheet editing capabilities (hours, breaks, job details)</li>
<li>Add bulk submission functionality for multiple operative timesheets</li>
<li>Display timesheet status (draft, submitted, approved)</li>
<li>Show validation errors and warnings before submission</li>
<li>Implement mobile-responsive design for field use</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>User role management (supervisor identification)</li>
<li>Supervisor-operative relationship data</li>
<li>Timesheet data model</li>
<li>Authentication system</li>
<li>COR-1478 (parent feature)</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>[ ] Supervisors can view list of all their operatives</li>
<li>[ ] Supervisors can create new timesheet entries for operatives</li>
<li>[ ] Supervisors can schedule shifts with start/end times, breaks, and job codes</li>
<li>[ ] Supervisors can edit draft and submitted (but not approved) timesheets</li>
<li>[ ] Supervisors can submit individual or multiple timesheets at once</li>
<li>[ ] Clear validation messages shown for incomplete or invalid timesheet data</li>
<li>[ ] Timesheet status clearly displayed (draft, submitted, approved, rejected)</li>
<li>[ ] Interface is mobile-responsive for use on tablets/phones in the field</li>
<li>[ ] Supervisors can only access timesheets for their assigned operatives</li>
</ul>

Supervisor view

<p><strong>Why</strong></p>
<p>Implement integration between Coreloops and Sage 200 for seamless accounting synchronisation via Membrane and Zynk. Export approved documents from Coreloops into Sage 200.</p>
<p><strong>What</strong></p>
<p>Implement one-way data export from Coreloops to Sage 200 for invoices, bills, and related financial documents.</p>
<p><strong>How</strong></p>
<p>See child issues for detailed implementation tasks.</p>
<p>Integration approach:</p>
<ul>
<li>Use Membrane as the integration platform</li>
<li>Leverage Zynk connectors for Sage 200 connectivity</li>
<li>Export approved documents from Coreloops to Sage 200</li>
</ul>
<p>Key features:</p>
<ol>
<li>CIS mapping to Sage 200</li>
<li>Export invoices and bills to Sage 200</li>
<li>Tracking categories/cost centres mapping</li>
<li>Automatic sync via webhooks</li>
<li>Attachment handling</li>
</ol>
<p><strong>Dependencies</strong></p>
<ul>
<li>Membrane configuration with Zynk for Sage 200</li>
<li>Sage 200 API access and credentials</li>
<li>Zynk documentation: <a href="https://docs.zynk.com/workflow/documentation/sage-200/index.html">https://docs.zynk.com/workflow/documentation/sage-200/index.html</a></li>
</ul>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>All child issues completed</li>
<li>Documents export successfully from Coreloops to Sage 200</li>
<li>CIS settings sync correctly</li>
<li>Error handling and logging implemented</li>
<li>Users can view sync status from Coreloops</li>
</ul>

Integrate Coreloops with Sage 200

<p><strong>Why</strong></p>
<p>Line items are not displaying in the same order as they appear in the original document. The platform needs to maintain the sequence from the AI response.</p>
<p><strong>What</strong></p>
<p>Add <code>index</code> field to line items to preserve display order from original document.</p>
<p><strong>How</strong></p>
<p><strong>Coreloops AI (Victor):</strong></p>
<ul>
<li>Add sequence number to each line item in JSON response</li>
<li>Index should match document order (first item = 0 or 1)</li>
</ul>
<p><strong>Platform (Ibrahim/Nonso):</strong></p>
<ul>
<li>Add <code>index</code> column to document<em>line</em>items table</li>
<li>Sort line items by index in UI displays</li>
<li>Support manual reordering with index updates</li>
</ul>
<p><strong>Dependencies</strong></p>
<ul>
<li>None</li>
</ul>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>AI response includes index for each line item</li>
<li>Line items display in document order</li>
<li>Index stored in database</li>
<li>Line items can be manually reordered</li>
<li>Export maintains correct order</li>
</ul>

Add index field to document line items to maintain order

Users have reported that when importing payment applications, the system sometimes incorrectly flags line items as not matching previously certified figures. This creates confusion and adds extra time to verify the accuracy of the payment applications. 

To improve this, we plan to refine the validation process for payment applications to reduce instances of false flagging. This will ensure that only true discrepancies are flagged, leading to a more efficient and accurate workflow for our users.

Completed

Improve Payment Application Import Validation Logic

james

Our users need more control over what data syncs to their accounting software. Currently, all project and supplier data is automatically synced, which isn't ideal for all use cases. Some data, such as internal projects or test data, may need to be excluded from the automatic sync. 
 
We propose adding functionality to exclude specific projects and suppliers from syncing. This would allow users to have greater control over their data and ensure that only relevant information is synced to their accounting software. This exclusion functionality would apply to both automatic and manual sync workflows.

Granular Control for Data Sync to Accounting Software

Deploy tag sync to production

<h2 id="why">Why</h2>
<p>When documents fail to process (due to API errors, PDF version issues, etc.), they are currently hidden from the user interface. This creates severe financial risk:</p>
<ul>
<li>Customers are unaware documents failed</li>
<li>No email notification of failures</li>
<li>Can result in hundreds of missing invoices over months</li>
<li>Leads to unclaimed VAT and untracked costs</li>
<li>Previous customer left due to this issue (6 months of failed invoices)</li>
</ul>
<h2 id="what">What</h2>
<p>Update document handling to:</p>
<ol>
<li>Show failed documents with clear status indicator</li>
<li>Display reason for failure</li>
<li>Send email notification when documents fail</li>
<li>Notify users in-platform for failed documents</li>
</ol>
<h2 id="how">How</h2>
<ul>
<li>Update document display logic to show failed documents with "Processing failed" or similar status (avoid negative language if possible)</li>
<li>Add failure reason field and display in document view</li>
<li>Implement email notification system for failed documents</li>
<li>Add in-platform notification for failures</li>
<li>Exception: Images without plan items may still be hidden (separate handling needed)</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>Email notification system</li>
<li>Document status model updates</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>Failed documents appear in document list with clear status</li>
<li>Failure reason displayed to user</li>
<li>Email sent when document fails processing</li>
<li>User notified in platform when document fails</li>
<li>Email notification includes document name and failure reason</li>
<li>Works for all document types (excluding images edge case)</li>
</ul>

Show failed documents instead of hiding them

<h2 id="why">Why</h2>
<p>Suppliers have unique invoice formats, naming conventions, and relationships (e.g. Screwfix handling hardware from Electric Fix) that a generic AI prompt cannot account for. Tenants — including BuildX — need the ability to define custom supplier-level context to improve document parsing accuracy, cost code assignment, and supplier disambiguation. This field exposes the backend <code>custom_ai_prompt</code> capability (COR-1545) to users via the UI.</p>
<h2 id="what">What</h2>
<p>Add a UI field on the supplier create and edit forms that allows users to enter a custom AI prompt for that supplier:</p>
<ul>
<li>Optional free-text field labelled (e.g. "Custom AI Prompt" or "AI Parsing Instructions")</li>
<li>Displayed under an "Advanced" tab or dedicated "AI Settings" section on the supplier form</li>
<li>Field is nullable — no prompt is required</li>
<li>Field maps to the <code>custom_ai_prompt</code> column on the suppliers table (added in COR-1545)</li>
</ul>
<h2 id="how">How</h2>
<ul>
<li>Design the field placement and label within the supplier create/edit UI (Advanced or AI Settings section)</li>
<li>Wire the field to the <code>custom_ai_prompt</code> attribute on the supplier model</li>
<li>Ensure field is included in both create and edit flows</li>
<li>Validate that the input is saved and retrievable correctly</li>
<li>Confirm field is visible and editable by tenant admins without engineering involvement</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>COR-1545 — backend <code>custom_ai_prompt</code> field on the suppliers table must be shipped first</li>
<li>Supplier create/edit UI components</li>
<li>Design sign-off required (Design Reqd label)</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>Custom AI prompt field appears on supplier create and edit forms</li>
<li>Field is optional and accepts free text</li>
<li>Saving the form persists the value to <code>custom_ai_prompt</code> on the supplier record</li>
<li>Field is accessible to tenant admins without engineering intervention</li>
<li>Empty/null field does not break existing supplier or parsing behaviour</li>
<li>UI matches approved design</li>
</ul>

Add field for custom AI prompt at supplier level

<p><strong>Why</strong>
Users need to quickly locate specific line items within the entry interface, especially as project data scales.</p>
<p><strong>What</strong>
Add a search/filter input to the line item entry screen, enabling users to find line items by keyword in real time.</p>
<p><strong>How</strong>
Implement a search input above the line item list that filters results as the user types, matching against item name, code, or description.</p>
<p><strong>Dependencies</strong>
None.</p>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>Users can type in a search box to filter the visible line items</li>
<li>Filtering is real-time (no page reload required)</li>
<li>Empty state is shown if no results match the query</li>
</ul>

Add search to line item entry

<p><strong>What</strong></p>
<p>Add a <strong>Reference</strong> field to document line items. The field should accept manual input from the user and also support automatic import when line items are synced from accounting software integrations (e.g. Xero, QuickBooks).</p>
<p><strong>Why</strong></p>
<p>Users need a way to track and cross-reference line items with identifiers from their accounting systems or internal tracking references. This improves traceability, reconciliation, and audit accuracy.</p>
<p><strong>Acceptance Criteria</strong></p>
<ul>
<li>Each line item in a document includes a “Reference” field.</li>
<li>Users can manually enter or edit the reference value.</li>
<li>When documents are imported from Xero, QuickBooks, or similar, the reference value should be automatically populated if available in the source data.</li>
<li>The field should be visible in the document line item table and exported data.</li>
<li>Reference values should sync correctly when documents are updated or re-imported.</li>
</ul>

Add reference number field to document line items (manual input & accounting sync)

<p></p>
<p><strong>Why</strong> </p>
<p>Move VO Number to ref and add description to sub-section description</p>
<p>**What **
**
When users publish variations to the BOQ it should show the reference number in the refernce field for each variation sub-section and the references for each line item in the BOQ should also be published. </p>

Show variation order reference number and description in BOQ

<h2 id="why">Why</h2>
<p>Users need control over how documents sync into their accounting system to match their workflow and compliance requirements.</p>
<p>BuildX needs pending invoices visible in Xero for cash flow planning without automatic approval. Different customers may have different requirements for when documents should sync and in what status.</p>
<h2 id="what">What</h2>
<p>Allow users to configure:</p>
<ol>
<li><strong>Status mapping options</strong> - Choose how Coreloops statuses map to accounting system statuses:</li>
</ol>
<ul>
<li>Draft → Don't Sync / Sync as Draft</li>
<li>Pending → Don't Sync / Sync as Submitted (Awaiting Approval)</li>
<li>Approved → Don't Sync / Sync as Authorised (Awaiting Payment)</li>
<li>Paid → Don't Sync / Sync as Paid</li>
</ul>
<ol>
<li><strong>Manual sync workflow</strong> - When user selects "Don't Sync" for any status:</li>
</ol>
<ul>
<li>Manual "Sync to Xero" button appears in document view</li>
<li>Document syncs to accounting system in the mapped status for that document's current state</li>
<li>Text flag "Not synced" appears in document view and table when changes exist that haven't been synced</li>
<li>Flag clears after manual sync completes</li>
</ul>
<ol>
<li><strong>Sync status filter</strong> - Add filter in documents table:</li>
</ol>
<ul>
<li>Synced</li>
<li>Not synced</li>
<li>Never synced</li>
<li>Sync pending</li>
</ul>
<h2 id="how">How</h2>
<ul>
<li>Add document settings UI for status mapping configuration</li>
<li>Implement manual sync button in document view when manual sync enabled</li>
<li>Add sync status tracking to documents</li>
<li>Display "Not synced" flag in document view and table</li>
<li>Add sync status filter to documents table</li>
<li>Track last sync timestamp and detect changes since sync</li>
<li>Support both automatic and manual sync workflows per configuration</li>
</ul>
<h2 id="dependencies">Dependencies</h2>
<ul>
<li>Xero integration</li>
<li>Document status system</li>
</ul>
<h2 id="acceptancecriteria">Acceptance Criteria</h2>
<ul>
<li>Users can configure status mapping in document settings</li>
<li>Manual sync button appears when "Don't Sync" configured for any status</li>
<li>"Not synced" flag displays when document has unsynced changes</li>
<li>Documents table shows sync status filter</li>
<li>Manual sync sends document to Xero in correct mapped status</li>
<li>Sync status updates in real-time after sync completes</li>
<li>Works for both cost and sales documents</li>
</ul>

Configure document sync mapping and manual sync workflow for Xero

<p>Why
As an estimator, I want to define labour/material/plant rates with markups so I can reuse consistent pricing across BOQs.
What</p>
<ul>
<li>Create rate entity with components: labour (hrs × cost), materials (qty × cost), plant (hrs × cost), overhead %, profit %.</li>
<li>Rate libraries per org; tag by trade; units and currency defined.</li>
<li>Versioning and effective dates.
How</li>
<li><strong><em>DB</em></strong>: <code>rates</code> (id, org<em>id, name, unit, base</em>cost, overhead<em>pct, profit</em>pct, currency, trade, version, effective<em>from, effective</em>to), <code>rate_components</code> (rate<em>id, type ENUM['labour','material','plant'], ref</em>id, qty, cost<em>per</em>unit).</li>
<li><strong><em>GraphQL</em></strong>: <code>createRate(input)</code>, <code>rate(id)</code>, <code>rateLibrary(query)</code>.</li>
<li><strong><em>UI</em></strong>: Rate builder form, component add/remove, live calculation.
Acceptance Criteria</li>
<li>Creating a rate stores components and computed totals; version increments on edit.</li>
<li>Edge: currency conversion handled via org currency; units validated.</li>
</ul>