to select ↑↓ to navigate
vfd provider

vfd provider

Overview

This document provides comprehensive information about property setters in the VFD Providers application. Property setters are used to modify the behavior and appearance of standard DocType fields without altering the core system files.

Property Setters Status

Current Implementation

The VFD Providers application does not currently implement any property setters. All customizations are handled through:

  1. Custom Fields: Added via patch files to extend existing DocTypes
  2. DocType Modifications: Direct modifications to custom DocTypes within the app
  3. Client-side Scripts: JavaScript customizations for form behavior

Property Setters vs Custom Fields

Aspect Property Setters Custom Fields
Purpose Modify existing field properties Add new fields to DocTypes
Use Case Change labels, options, visibility Extend functionality with new data
Implementation Frappe Property Setter DocType Frappe Custom Field DocType
VFD Providers Usage Not used Extensively used

Potential Property Setter Use Cases

If property setters were to be implemented in VFD Providers, they could be used for:

1. Field Label Modifications

  • Changing standard field labels to be more VFD-specific
  • Localizing field names for different regions

2. Field Visibility Control

  • Hiding irrelevant fields in VFD-enabled companies
  • Showing/hiding fields based on VFD provider selection

3. Field Options Enhancement

  • Adding VFD-specific options to existing select fields
  • Modifying dropdown values for better VFD integration

4. Field Validation Rules

  • Adding VFD-specific validation patterns
  • Enforcing TRA compliance requirements

Implementation Pattern (If Used)

Standard Property Setter Structure

def execute():
    properties = [
        {
            "doctype": "Sales Invoice",
            "fieldname": "customer",
            "property": "label",
            "value": "VFD Customer",
            "property_type": "Data",
        },
        {
            "doctype": "Customer",
            "fieldname": "tax_id",
            "property": "reqd",
            "value": 1,
            "property_type": "Check",
        }
    ]

    for property in properties:
        make_property_setter(
            property.get("doctype"),
            property.get("fieldname"),
            property.get("property"),
            property.get("value"),
            property.get("property_type"),
            for_doctype=False,
            validate_fields_for_doctype=False,
        )

Common Property Types

  • label: Change field display name
  • reqd: Make field mandatory/optional
  • hidden: Hide/show field
  • read_only: Make field read-only
  • options: Modify select field options
  • default: Set default values
  • depends_on: Control field visibility
  • fetch_from: Auto-fetch from linked documents

Alternative Approaches Used

1. Custom Fields with Fetch Properties

Instead of property setters, VFD Providers uses custom fields with fetch properties:

{
    "fieldname": "vfd_cust_id",
    "fieldtype": "Data",
    "fetch_from": "customer.vfd_cust_id",
    "fetch_if_empty": 1,
}

2. Client-side JavaScript Customizations

Form behavior modifications are handled through JavaScript files:

  • apps/vfd_providers/vfd_providers/utils/sales_invoice.js
  • apps/vfd_providers/vfd_providers/utils/customer.js

3. Server-side Hooks

Field validations and modifications are handled through document events:

doc_events = {
    "Sales Invoice": {
        "before_submit": "vfd_providers.utils.sales_invoice.vfd_validation",
    },
    "Customer": {
        "validate": "vfd_providers.utils.utils.clean_and_update_tax_id_info",
    },
}

Advantages of Current Approach

1. Simplicity

  • Easier to maintain and debug
  • Clear separation of custom functionality
  • No complex property setter dependencies

2. Transparency

  • All customizations are visible in custom fields
  • Easy to identify VFD-specific modifications
  • Better documentation and understanding

3. Flexibility

  • Custom fields provide more control
  • JavaScript allows complex form interactions
  • Server-side hooks enable business logic

Future Considerations

When to Consider Property Setters

Property setters might be beneficial if:

  1. Extensive Field Modifications: Need to modify many existing fields
  2. Conditional Behavior: Complex field visibility rules based on company settings
  3. Localization: Different field labels for different regions
  4. Compliance Requirements: Mandatory fields based on VFD provider

Implementation Guidelines

If property setters are added in the future:

  1. Create Property Setter Patch: Add to patches.txt for proper execution
  2. Document Changes: Clearly document what properties are being modified
  3. Test Thoroughly: Ensure no conflicts with existing customizations
  4. Version Control: Track property setter changes for maintenance
Last updated 4 days ago
Was this helpful?
Thanks!