Daily Sales Data Collection

This workflow collects and stores daily business performance data including sales, costs, and micro-actions. It's designed to be called by other workflows and automatically calculates profit while storing all business metrics in a PostgreSQL database.

Purpose

No business context provided yet — add a context.md to enrich this documentation.

How It Works

1. Receives Input Data: The workflow is triggered by another workflow that passes in daily business metrics including date, phone number, sales figures, various costs, and micro-actions
2. Stores Raw Data: All input data is inserted into the dailyProfitTracking table in PostgreSQL
3. Calculates Profit: After storing the data, the workflow calculates profit by subtracting all costs (stocking, transport, and other costs) from sales revenue

Workflow Diagram

graph TD
    A[When Executed by Another Workflow] --> B[Insert rows in a table]
    B --> C[Edit Fields]

Trigger

Execute Workflow Trigger: This workflow is designed to be called by other workflows within the same n8n instance. It accepts the following input parameters:

• date (string): Date of business activity
• phoneNumber (string): Phone number identifier
• sales (number): Total sales amount
• stockingCost (number): Cost of inventory/stock
• transportCost (number): Transportation expenses
• otherCost (number): Miscellaneous business costs
• Micro actions (string): Description of micro-actions taken
• isPractice? (boolean): Flag indicating if this is practice data

Nodes Used

Node Type	Node Name	Purpose
Execute Workflow Trigger	When Executed by Another Workflow	Receives input data from calling workflows
PostgreSQL	Insert rows in a table	Stores business data in the dailyProfitTracking table
Set	Edit Fields	Calculates profit from sales and cost data

External Services & Credentials Required

• PostgreSQL Database: Requires a PostgreSQL credential named "kdpTables"
  • Database must contain a table called dailyProfitTracking with appropriate schema
  • Required columns: phoneNumber, dateOfBusiness, sales, stockingCost, transportCost, otherCost, microActions, isPractice

Environment Variables

No environment variables are used in this workflow.

Data Flow

Input Data: - Date of business activity - Phone number (identifier) - Sales amount - Stocking cost - Transport cost - Other costs - Micro actions description - Practice flag (boolean)

Processing: - Raw data is stored in PostgreSQL - Profit calculation: sales - stockingCost - transportCost - otherCost

Output Data: - All input data plus calculated profit field - Data persisted in database for future analysis

Error Handling

This workflow does not implement explicit error handling. Database insertion failures or calculation errors would cause the workflow to fail and would need to be handled by the calling workflow.

Known Limitations

• No data validation on input parameters
• No duplicate detection (same date/phone number combinations)
• No error handling for database connection issues
• Profit calculation assumes all cost fields are provided and numeric

Related Workflows

This workflow is designed to be called by other workflows but no specific related workflows are identified in the current configuration.

Setup Instructions

1. Import the Workflow: Import the JSON into your n8n instance

2. Configure PostgreSQL Credential:

   • Create a PostgreSQL credential named "kdpTables"
   • Ensure it has read/write access to the target database

3. Database Setup:

   • Create the dailyProfitTracking table with the following columns:
     • phoneNumber (string)
     • dateOfBusiness (datetime)
     • sales (number)
     • stockingCost (number)
     • transportCost (number)
     • otherCost (number)
     • microActions (string)
     • isPractice (boolean)

4. Test the Workflow:

   • Create a test workflow that calls this one with sample data
   • Verify data is correctly stored in the database
   • Check that profit calculation works as expected

5. Integration:

   • Update calling workflows to use the correct workflow ID
   • Ensure input parameter names match exactly
   • Set appropriate caller policy if needed