Skip to content

Plataforma de Recepción Inteligente

What is Plataforma de Recepción Inteligente

Section titled “What is Plataforma de Recepción Inteligente”

Plataforma de Recepción Inteligente is the Futuh module that collects incoming documents and requests, identifies them with the help of an AI agent, and converts them into organized work within the system. Each incoming document is recognized by its type (a national ID, an activity certificate, a financial report, a responsible declaration), associated with the collection cycle that was expecting it, and made available to the team member responsible for validating it.

The problem it solves is common in organizations that process grant calls, manage consortia, or request documentation from their counterparts. Documents arrive through different channels and in heterogeneous formats. Someone has to open each PDF, read the first pages to understand what it is, note it on a spreadsheet, file it in the correct folder, and notify the validation lead. Multiplied by thirty counterparts and seven document types per counterpart, that work consumes hours every week and leaves gaps whenever someone gets distracted.

The platform is organized in four pieces that act in sequence:

  1. Collection cycles. An administrator defines a cycle for a recurring situation: “initial counterpart documentation 2026” or “NEXT-MED consortium intermediate justification”. Each cycle groups the expected document types and the people or organizations from whom they will be requested.
  2. Individual document requests. When the cycle opens, the system creates a document request for each recipient, with a unique upload link sent by email. The recipient uploads their documents without needing a Futuh account.
  3. AI classification. When a document arrives, an AI agent reads its name, its MIME type, and, if it is a PDF, its content. It compares against the expected types and emits a classification with a confidence score between 0 and 1. If it exceeds the configured confidence threshold (default 0.7), the document is automatically validated; if not, it is placed on hold for review.
  4. Validation and tracking. The operator sees the inbox of received documents with their status, proposed classification, and confidence score. They confirm or correct each case. When a recipient is late, a daily cron job sends escalated reminders (friendly, assertive, urgent) according to the configured policy.

The platform is designed for organizations that systematically receive documentation from third parties. The three canonical use cases are:

  • Consortia and networked projects. When your organization leads or participates in a consortium and needs to collect documents from several partner entities for a justification. Each partner has their own upload link and the coordinator sees the consortium’s progress in a single view.
  • Internal grant justification. When within your organization several teams contribute documents (invoices, receipts, certificates, activity reports) to the same file. Each team uploads their part from their link, the system classifies it, and the file coordinator closes it when it is complete.
  • Documentation collection from members or counterparts. When you need to keep the documentation of your member organizations or regular counterparts up to date (national ID, bylaws, tax-compliance certificates, annual plans) and want to turn that annual collection into a predictable process.

The typical case is the project officer who opens Futuh in the morning, looks at the inbox, confirms four classifications resolved with high confidence, corrects one pending case, and rejects one that arrived by mistake.

The platform is tightly integrated with Futuh projects:

  • Each cycle can be associated with a project in the ERP. The system then knows which receiving partners, which funding entities, and which team members are involved, and directs requests to the right people without the operator having to enumerate recipients.
  • Classification, confidence-based validation, and reminder generation use configurable AI agents. The administrator decides which AI model backs them.
  • An additional module adds the public upload link that recipients use from outside your instance.
  • The catalog of canonical document types is served from Federación Futuh when your instance is federated: the basic sector types arrive already defined.

The current version has a defined scope. It is useful to know what is out of bounds:

  • It does not archive validated documents in your file system. When a document is validated, it lives as an attachment on the Futuh record. Integration with SharePoint, OneDrive, or a proprietary server is planned for a later phase.
  • It does not process incoming emails as a trigger. Today, requests are created from a cycle defined by the administrator. Automatic detection from a shared mailbox is in the backlog. [VERIFY: ticket pendiente Algalia §3.1.]
  • It does not electronically sign documents. If you need to sign an associated agreement, that is handled with Odoo’s native Sign module and referenced from the corresponding task.

Plataforma de Recepción Inteligente is the documentary entry point of your organization. It collects what arrives from outside and, depending on what it contains, triggers work in other modules. When a request classifies as a project request, it escalates to Gestión de ayudas at the Planning stage. Silvio can act on received requests, validate automatic classifications, or send reminders when a recipient is late. The canonical document type catalog is not something you invent: it comes from Federación Futuh. And when a request refers to an open public call, it can be cross-referenced with the catalog that Radar monitors.

ModuleWhat this module gives / receivesFlow
Gestión de ayudasWhen a request classifies as a project request, it escalates to Planning stageProcess a document request
SilvioSilvio can validate requests, open tasks, and send reminders via ToolsConverse with Silvio
Federación FutuhReceives canonical document templates from the Hub CentralSynchronize with the Federation
Radar(bidirectional emerging relationship when the request refers to an open call)(emerging flow)