The development (in Python) of a centralized system for electronic invoice stamping in Panama is required, with direct integration from Odoo. The project involves creating two main connectors for feeding invoicing data with a common core: A) Common Core (for both connectors): Central endpoint/service for: Validating requests and determining which company they belong to. Basic validations (required fields, totals, taxes, etc.). Submission to stamping service. Status management: received → in_process → stamped → rejected/error. Idempotence: if the same invoice arrives twice, do not stamp it twice. Controlled retries and queuing (to avoid losing invoices). 1. Email Connector: This module must be able to receive XML files in Factur-X CII format sent via email from Odoo. The functionality will include extracting the relevant data contained in the XML for subsequent processing and submission to the stamping service. 2. API Connector: A connector will be developed to extract invoice data directly from an Odoo Online Custom instance via its API. This connector must handle communication via JSON to obtain the necessary information and prepare it for the electronic invoicing process. The objective is to establish an efficient and automated workflow for issuing electronic invoices compliant with Panamanian regulations, ensuring the correct extraction, processing, and electronic invoicing of the information. 1. Email Connector: Automation of electronic invoicing in Panama from Odoo via email (factur-x/cii) → PAC (SOAP) in Google Cloud (multi-company/multi-branch) Functional Scope 1. Server configuration in Google Cloud to receive emails containing the PDF and XML files, possibly using a bucket. 2. Email Ingestion (IMAP) a. Receive emails containing the PDF and XML files from Odoo. b. Detect and download attached XML Factur-X (CII) and discard the PDF. 3. Extraction and mapping (Odoo XML → PAC) a. Parse Factur-X (CII) and extract header, client, lines, taxes, totals, currency, etc. b. Construct the XML in the PAC's format (SOAP "send" and internal provider nodes). 4. Sending to the PAC + handling the response a. Send the XML to the PAC endpoint (SOAP). b. Register the response (accepted/rejected, CUFE or equivalent, error messages). c. Respond to Odoo by email, returning the result (e.g., response/acknowledgment XML). a. Handle errors due to: incomplete XML, PAC validations, network outages, timeouts. b. Controlled retries and corrective suggestions when data is missing (e.g., required line description). a. Adding new companies/databases to the system should be easy. Non-functional Requirements / Architecture 4. Simple configuration per company: ideally via config file (YAML/JSON) or a mini web UI for managing companies/branches (optional). I need basic security to prevent other companies from issuing electronic invoices by impersonating the company via email. The company can be identified by name/tax ID/domain, but additional controls are necessary. The proposal should include: 1. Incoming email validation with SPF/DKIM/DMARC (where possible). 2. Company-specific token (secret) to authorize electronic invoice issuance. 3. Whitelist of allowed senders (optional). 2. API Connector Title: Odoo ↔ (PAC Panama) Integration – Multi-Company Intermediary Platform (Python) Brief Description: Building a cloud-based platform in Python that reads invoices/notes from Odoo via API (without modifying Odoo) and sends them to hka thefactory (PAC Panama) for stamping/authorization. It must be multi-tenant, scalable for mass operation, with status management, retries, and XML/PDF download. Objectives: • Extract data from Odoo with minimal intrusion (read-only, no Studio, no new fields). • Map standard Odoo accounting documents to the PAC services. • Stamp/check status/return XML/PDF/void. • Operate with multiple companies (each with its own Odoo credentials + PAC tokens). Scope: 3. Extracting information via the Odoo API using JSON-2. 5. Receiving the PAC's response to Odoo in the tracking chat and entering the electronic invoice number in the "ref" field. 6. Handling submission errors, with recommendations for invoice stamping and resubmissions. 7. Delivery with a presentation explaining the solution within 1 hour. 8. Post-delivery support for two weeks (4 hours total). 9. Guidance on obtaining the key from the invoice issuer. 10. Creating new fields in Odoo or installing custom modules is not permitted. Deliverables: 1. Repository with complete code. 2. Dockerfile + Docker Compose for local/staging deployment. 3. Database schema + migrations. 4. Postman/Insomnia collection. 5. Odoo mapping document → HKA (key fields). 6. Deployment and operation guide (create tenant, run sync, view states, retries). 7. Minimum tests (mapping + states + an end-to-end "happy path" test in staging).