Supplier Service

​

Overview

​

Core Entities

​

Proveedor

• id (Long) - Primary key
• ruc (String) - Tax identification number (RUC)
• nombre (String) - Supplier company name
• telefono (String) - Phone number
• direccion (String) - Address
• correo (String) - Email address
• estado (Boolean) - Active status (default: true)

• @PrePersist - Sets estado to true on creation

​

Key Components

​

Controllers

​

ProveedorController

• GET /proveedor - List all suppliers
• GET /proveedor/{id} - Get supplier by ID
• POST /proveedor - Create new supplier
• PUT /proveedor/{id} - Update supplier
• DELETE /proveedor/{id} - Delete supplier
• PUT /proveedor/desactivar/{id} - Deactivate supplier
• PUT /proveedor/activar/{id} - Activate supplier
• GET /proveedor/buscar?ruc={ruc} - Search by RUC

• RUC-based supplier lookup
• Activation/deactivation endpoints
• Full CRUD operations
• Standard REST conventions

​

Services

​

ProveedorService

• listarTodos() - List all suppliers
• obtenerPorId() - Find by ID
• crear() - Create new supplier
• actualizar() - Update supplier information
• eliminar() - Delete supplier
• desactivar() - Deactivate supplier (soft delete)
• activar() - Reactivate supplier
• buscarPorRuc() - Find by RUC (tax ID)

​

Repositories

​

ProveedorRepository

• findByRuc() - Lookup supplier by RUC
• findByEstado() - Filter by active status

​

Dependencies

• spring-boot-starter-data-jpa - JPA/Hibernate
• spring-boot-starter-web - REST API
• spring-boot-starter-validation - Bean validation
• spring-cloud-starter-netflix-eureka-client:4.0.3 - Service discovery
• spring-cloud-starter-config:4.0.4 - Centralized configuration
• springdoc-openapi-starter-webmvc-ui:2.0.2 - OpenAPI/Swagger UI
• postgresql - PostgreSQL driver
• lombok - Code generation

​

Configuration

server:
  port: ${PORT:${SERVER_PORT:0}}

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/proveedor-db
    username: postgres
    password: ""
  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true

eureka:
  client:
    serviceUrl:
      defaultZone: http://localhost:8090/eureka

​

Database Schema

• proveedor - Supplier master data
  • Primary key: id
  • Recommended unique constraint: ruc
  • Index on ruc for fast lookups

​

Key Features

• Supplier master data management
• RUC-based supplier identification
• Active/inactive status tracking
• Soft delete via activation/deactivation
• RUC-based supplier search
• PostgreSQL database (same as Customer service)
• OpenAPI/Swagger documentation
• Eureka service discovery integration
• Centralized configuration via Config Server

​

Integration Points

​

Consumed by:

• Purchase Service - Fetches supplier data for purchase transactions via ProveedorFeign

​

APIs Exposed:

• Supplier CRUD operations
• Supplier lookup by ID
• Supplier search by RUC
• Supplier activation/deactivation
• Supplier listing

​

Usage Pattern

// In Compra entity
@Column(name = "proveedor_id")
private Long proveedorId;

@Transient
private Proveedor proveedor; // Retrieved via Feign client

@FeignClient(name = "jea-proveedor-service")
public interface ProveedorFeign {
    @GetMapping("/proveedor/{id}")
    Proveedor obtenerPorId(@PathVariable Long id);
    
    @GetMapping("/proveedor/buscar")
    Proveedor buscarPorRuc(@RequestParam String ruc);
}

​

Validation Rules

​

RUC (Tax ID)

• Unique identifier for suppliers
• Should be unique across all suppliers
• Used for legal and tax identification
• Format varies by country (Peru: 11 digits)

​

Supplier Status

• estado = true - Active supplier, can be used in purchases
• estado = false - Inactive supplier (soft deleted)
• Deactivation is preferred over deletion for audit trail

​

Status Management

​

Activation/Deactivation

PUT /proveedor/desactivar/{id}
PUT /proveedor/activar/{id}

• Clear intent vs generic update
• Audit-friendly operations
• Prevents accidental deletions
• Maintains referential integrity in purchases

• Deactivate: Supplier no longer in business, poor performance, contract ended
• Activate: Re-engaging with previous supplier, resolving issues

​

Comparison: Customer vs Supplier

​

Data Privacy Considerations

​

Business Information

• Tax identification (RUC)
• Company information
• Contact details

• Implement access control at API Gateway level
• Log access for audit trails
• Maintain data accuracy for tax/legal compliance
• Support data export for reporting

​

Database Choice: PostgreSQL

​

Why PostgreSQL?

1. Data Integrity - ACID compliance for supplier master data
2. Consistency - Same database as Customer service for similar data types
3. Reliability - Critical business relationships require stable storage
4. Future Features - Support for complex supplier hierarchies, JSON fields

​

Benefits for Supplier Management

• Strong foreign key constraints
• Better support for complex queries (if needed for reporting)
• Robust transaction handling
• Reliable for critical business data

​

Supplier Lifecycle

​

1. Registration

POST /proveedor

• Create new supplier with basic information
• estado automatically set to true
• RUC should be unique

​

2. Active Operations

• Supplier used in purchase transactions
• Information updated as needed via PUT /proveedor/{id}

​

3. Deactivation

PUT /proveedor/desactivar/{id}

• Set estado = false
• Supplier cannot be used in new purchases
• Historical purchases remain intact

​

4. Reactivation (if needed)

PUT /proveedor/activar/{id}

• Set estado = true
• Supplier available for new purchases again

​

5. Permanent Deletion (rare)

DELETE /proveedor/{id}

• Physical deletion from database
• Only if no purchase history exists
• Generally discouraged in favor of deactivation

​

Best Practices

​

Supplier Validation

1. RUC Validation
   • Validate RUC format before saving
   • Check for duplicates
   • Verify with tax authority API (if available)
2. Contact Information
   • Ensure at least one contact method (phone or email)
   • Validate email format
   • Store multiple contacts if needed (future enhancement)
3. Address Validation
   • Complete address for legal documents
   • Support multiple addresses (future: billing, warehouse)

​

Status Management

1. Use Deactivation Over Deletion
   • Maintains audit trail
   • Preserves purchase history
   • Allows reactivation
2. Status Filtering
   • Default to showing active suppliers only
   • Provide option to view all/inactive
   • Warn users when selecting inactive supplier

​

Future Enhancements

• Supplier categories/classifications
• Supplier ratings and reviews
• Payment terms (net 30, net 60, etc.)
• Credit limits for purchases
• Multiple contacts per supplier
• Supplier documents (contracts, certificates)
• Product catalogs per supplier
• Supplier performance metrics
• Supplier onboarding workflow
• Integration with procurement systems