Saltar al contenido principal

Using RPAfelApi for ALL Document Types (Including Invoices)

🎯 Question​

Should we use RPAfelApi for regular invoices (FACT) as well, not just for credit notes, debit notes, and cancellations?

✅ YES - Absolutely! This is the Right Decision​

Why Use RPAfelApi for Invoices Too​

  1. ✅ Consistency

    • Same certification path for all document types
    • Unified error handling
    • Single code path to maintain

  2. ✅ Immediate Benefits

    • Certificate caching for invoices (especially Infile)
    • Automatic "already signed" error handling
    • Production-tested reliability

  3. ✅ Simpler Architecture

    • One provider for everything
    • Less code to maintain
    • Easier to debug

  4. ✅ Future-Proof

    • All new features in RPAfelApi benefit all documents
    • Centralized improvements
    • Better scalability

📊 Current vs Proposed Architecture​

Current Architecture (Mixed)​

Invoice (FACT)
  ↓
XmlConversionService → XML
  ↓
Direct Certifier (Digifact/Infile)
  ↓
Response

Credit Note (NCRE) - Future
  ↓
XmlToDteJsonService → DTE JSON
  ↓
RPAfelApi
  ↓
Response

Problems:

  • ❌ Two different paths
  • ❌ Invoices don't get caching
  • ❌ Invoices don't get "already signed" handling
  • ❌ More code to maintain
  • ❌ Inconsistent behavior

Proposed Architecture (Unified)​

All Documents (FACT, NCRE, NDEB, ANULACION)
  ↓
XmlToDteJsonService → DTE JSON
  ↓
RPAfelApi
  ↓
Response

Benefits:

  • ✅ Single path for all documents
  • ✅ All documents get caching
  • ✅ All documents get error handling
  • ✅ Less code to maintain
  • ✅ Consistent behavior

🔄 Migration Strategy​

Phase 1: Add RPAfelApi Support (Keep Direct Certifiers)​

Timeline: Week 1

  1. Create RPAfelApi Provider

    • ProviderRpaFelApiService
    • HTTP client for RPAfelApi

  2. Create DTE JSON Converter

    • XmlToDteJsonService
    • Convert Invoice to DTE JSON

  3. Update FelService

    • Add routing logic
    • Feature flag: USE_RPA_FEL_API
    • Keep direct certifiers as fallback

  4. Test with Invoices

    • Test FACT documents via RPAfelApi
    • Compare with direct certifiers
    • Verify caching works

Phase 2: Enable for Invoices (Gradual Rollout)​

Timeline: Week 2

  1. Enable for Test Businesses

    • Set USE_RPA_FEL_API=true for test businesses
    • Monitor performance
    • Check cache hit rates

  2. Monitor & Optimize

    • Track errors
    • Measure response times
    • Verify caching benefits

  3. Enable for All Businesses

    • Roll out to production
    • Keep direct certifiers as fallback
    • Monitor closely

Phase 3: Deprecate Direct Certifiers (Optional)​

Timeline: Week 3+ (After confidence)

  1. Remove Direct Certifier Code (Optional)
    • Only if RPAfelApi is 100% reliable
    • Or keep as fallback forever

💡 Implementation Changes​

1. Update FelService.processSaleEvent​

Current:

felProviderData: {
  providerName: "digifact", // Hardcoded
},

Updated:

felProviderData: {
  providerName: process.env.USE_RPA_FEL_API === 'true' 
    ? "rpafelapi" 
    : business.felCertifier || "digifact",
},

2. Update certifyDocument Routing​

Current:

// Always uses direct certifiers
const provider = this.providerService.getProvider(
  felProviderData.providerName
);

Updated:

// Route to RPAfelApi if enabled
const useRpaFelApi = 
  process.env.USE_RPA_FEL_API === 'true' || 
  felProviderData.providerName === 'rpafelapi';

if (useRpaFelApi) {
  return await this.certifyViaRpaFelApi(document, business, taxId);
}

// Fallback to direct certifiers
const provider = this.providerService.getProvider(
  felProviderData.providerName
);

3. Remove XML Generation for Invoices (Eventually)​

Current:

  • XmlConversionService.convertToXml() for FACT
  • Direct certifier expects XML

Future:

  • XmlToDteJsonService.convertInvoiceToDteJson() for FACT
  • RPAfelApi expects DTE JSON
  • Can keep XML conversion for direct certifier fallback

📊 Benefits Comparison​

FeatureDirect CertifiersRPAfelApi (All Docs)
Certificate Caching❌ No✅ Yes (Infile)
Already Signed Handling❌ Manual✅ Automatic
Consistency❌ Mixed paths✅ Single path
Code Maintenance⚠️ More code✅ Less code
Error Handling⚠️ Manual✅ Built-in
Future Features❌ Need to build✅ Get automatically
Performance⚠️ No caching✅ Cached responses
Reliability⚠️ Network issues✅ Production-tested

🎯 Recommended Approach​

Option 1: Full Migration to RPAfelApi (Recommended) ⭐⭐⭐​

Strategy:

  • Use RPAfelApi for ALL documents (FACT, NCRE, NDEB, ANULACION)
  • Keep direct certifiers as fallback
  • Feature flag for gradual rollout

Benefits:

  • ✅ Maximum consistency
  • ✅ All benefits for all documents
  • ✅ Simplest architecture
  • ✅ Easiest to maintain

Timeline: 2-3 weeks

Strategy:

  • Use RPAfelApi for NCRE/NDEB/ANULACION
  • Keep direct certifiers for FACT

Problems:

  • ❌ Invoices don't get caching
  • ❌ Two code paths
  • ❌ More complexity
  • ❌ Inconsistent behavior

🚀 Implementation Plan​

Step 1: Add RPAfelApi Support (Week 1)​

  1. Create ProviderRpaFelApiService
  2. Create XmlToDteJsonService
  3. Update FelService with routing
  4. Add feature flag

Step 2: Test with Invoices (Week 1)​

  1. Test FACT documents via RPAfelApi
  2. Compare results with direct certifiers
  3. Verify caching works
  4. Test error scenarios

Step 3: Enable for Invoices (Week 2)​

  1. Enable for test businesses
  2. Monitor performance
  3. Roll out to all businesses
  4. Keep direct certifiers as fallback

Step 4: Add NCRE/NDEB/ANULACION (Week 3+)​

  1. Implement credit note service
  2. Implement debit note service
  3. Implement cancellation service
  4. All use RPAfelApi (consistent!)

💡 Key Insight​

If RPAfelApi is good enough for credit notes, debit notes, and cancellations, it's definitely good enough for invoices!

Why:

  • Same certification process
  • Same error handling needs
  • Same caching benefits
  • Same reliability requirements

Plus:

  • Invoices are the most common document type
  • Caching benefits are most valuable for invoices
  • Consistency across all document types

✅ Final Recommendation​

Use RPAfelApi for ALL document types, including invoices (FACT).

Why:

  1. ✅ Consistency across all documents
  2. ✅ Caching benefits for invoices
  3. ✅ Simpler architecture
  4. ✅ Less code to maintain
  5. ✅ Better long-term

Implementation:

  • Add RPAfelApi support
  • Enable for invoices first (most common)
  • Then add NCRE/NDEB/ANULACION
  • Keep direct certifiers as fallback

Timeline:

  • Week 1: Add RPAfelApi, test with invoices
  • Week 2: Enable for all invoices
  • Week 3+: Add credit notes, debit notes, cancellations

Last Updated: 2025-12-18
Status: Recommendation - Use RPAfelApi for All Documents