Why neither Bosnia and Herzegovina, Montenegro, Croatia, nor Serbia has Quality OCA "Odoo" Localization

Bosnian version of this article / Bosanska verzija članka

The Problem: Duplication Instead of Collaboration

Every Odoo implementer in Bosnia and Herzegovina, Croatia, and Serbia faces the same challenges:

  • Duplicating basic fiscal localizations
  • Maintaining regulatory compliance individually
  • Spending time on commodity features instead of client innovation
  • Competing on infrastructure instead of expertise

We estimate each company wastes 200-400 hours annually on redundant development.

Why Do Spain and Romania Have It, and We Don’t?

Success Stories: Spain and Romania

Critical Mass of Companies: Both countries have numerous companies using Odoo, creating a natural incentive for shared development. Spain particularly has a strong SME sector that adopted Odoo early.

Strong Technical Education: Both countries have robust technical universities producing developers familiar with Python and open-source principles. Romania especially has become a European tech hub.

Early Adopters with Vision: Key companies or individuals championed open-source localization early, setting a collaborative tone. In Spain, companies like Tecnativa and ACSONE became major OCA contributors.

Economic Incentives: Sharing localization costs across multiple implementers makes economic sense. These countries had enough implementers to make collaboration worthwhile.

Language Advantage: Spanish being a major world language creates spillover benefits - Spanish localizations can be adapted for Latin America, increasing ROI on development efforts.

Challenges in Our Region

Market Fragmentation: Smaller markets with fewer Odoo implementations mean less incentive for community development. Individual companies may find it easier to develop proprietary solutions.

Competitive Mindset: In smaller markets, implementers may view localization as competitive advantage rather than shared infrastructure. This “zero-sum” thinking inhibits collaboration.

Lack of Anchor Contributors: Without a major company or organization leading by example and contributing consistently, community efforts fail to gain momentum.

Resource Constraints: Smaller implementation companies may lack resources to contribute to open-source development while managing client projects.

Regulatory Complexity: Complex or frequently changing regulations may discourage open-source development, as companies fear liability or prefer keeping solutions proprietary.

Technical Reality: What We Share, What We Don’t

We Share (common infrastructure):

  • Basic fiscal localizations (tax codes, fiscal positions)
  • Banking integrations (statement import, SEPA adaptations)
  • Regulatory reports (VAT, statistical reports)
  • Payment gateway integrations

We Don’t Share (competitive advantage):

  • Client-specific customizations
  • Industry vertical solutions
  • Implementation methodologies
  • Client relationships

Economics of Shared Development

Current State: Each company spending 400 hours/year × 50 EUR/hour = 20,000 EUR on basic localization

Possible State: 10 companies × 2,000 EUR annual contribution = 20,000 EUR shared pool

Result:

  • Same feature coverage
  • 90% less individual costs
  • Higher quality through peer review
  • Faster implementation of new regulations

First Practical Step: l10n_adriatic_banking

Instead of talk, let’s focus on concrete technique. Here’s a module structure everyone needs and is politically neutral:

Module Structure

l10n_adriatic_banking/
├── __manifest__.py
├── README.rst
├── data/
│   ├── res.bank.csv          # Regional banks data
│   └── account.journal.xml
├── models/
│   ├── res_bank.py
│   └── account_bank_statement_import.py
├── wizard/
│   └── mt940_parser_adriatic.py  # Regional MT940 variants
├── tests/
│   ├── test_mt940_import.py
│   └── fixtures/
│       ├── sample_raiffeisen.mt940
│       ├── sample_unicredit.mt940
│       └── sample_intesa.mt940

Key Technical Details

Encoding challenge: Regional banks use different encodings (Windows-1250, UTF-8, Latin-2). Parser must handle all variants:

def _decode_regional(self, data):
    """Try multiple encodings common in the region"""
    encodings = ['utf-8', 'windows-1250', 'iso-8859-2']
    for encoding in encodings:
        try:
            return data.decode(encoding)
        except UnicodeDecodeError:
            continue
    raise ValueError('Unable to decode file')

Bank-specific MT940 variants: Each bank has its specifics in MT940 format. Module needs to support all major variants.

Bank data: Centralized database for all regional banks (SWIFT, BIC, national codes).

Practical Action Plan

Phase 1: Mapping the Landscape (1-3 months)

  1. List all Odoo implementers in BiH, Serbia, Croatia
  2. Identify who’s already doing localizations (even proprietary)
  3. Document what everyone is duplicating
  4. Find common needs

Phase 2: First Collaborative Module (3-6 months)

  1. Pick the right first project (e.g., banking integration)
  2. Structure collaboration with clear cost-sharing model
  3. Create infrastructure (GitHub organization, communication channels)
  4. Monthly video calls and transparent documentation

Phase 3: Building Momentum (6-12 months)

  1. Academic approach: Partnership with universities
  2. Enterprise approach: Including community development in proposals
  3. Regional integration: Organizing “Adriatic Odoo Day” event

Technical Module Priorities

Immediate wins (everyone needs now):

  • l10n_ba_hr_rs_base - Shared regional base module
  • account_banking_sepa_adriatic - Regional SEPA adaptations
  • l10n_ba_fiscal_printer - Fiscal device integrations

Medium-term (collaborative potential):

  • hr_payroll_balkans - Base payroll rules (customized per country)
  • stock_delivery_posta - Regional postal services integration
  • account_invoice_ubl_rs_hr_ba - e-Invoice implementations

Overcoming Regional Challenges

Trust Problem

  • Solution: Start with code, not promises
  • Contribute something useful unilaterally first
  • Document everything transparently
  • Use OCA infrastructure for neutrality

Competition Concern

  • “We compete on implementation quality, not basic compliance”
  • “Clients don’t choose us for VAT calculations, they choose us for business understanding”
  • “Every hour not spent on basic localization is an hour for value-added services”

Resource Problem

  • Apply for EU funding (Horizon Europe, IPA funds)
  • Position as “digital infrastructure for regional SMEs”
  • Partnership with diaspora tech companies

Current Strategy of bring.out for Development on Open-Source “Odoo” Platform:

You can read more about our current development strategy in a separate blog post: Current Strategy of bring.out: “Odoo” Open-Source “Behind Closed Doors”

Call to Action

We invite all Odoo implementers from the region:

  1. Review our code - https://github.com/bringout/odoo-bringout-l10n_ba
  2. Contact us - Let’s talk about concrete collaboration
  3. Share your needs - What are you missing? What are you duplicating?
  4. Join the discussion - This blog post is the beginning, not the end

References

Content created with Claude AI 🤖 assistance per Ernad’s instructions

Ernad Husremović bring.out doo Sarajevo hernad@bring.out.ba