FacturX > Cii#5511
Open
mariohd wants to merge 5 commits into
Open
Conversation
The serializers and services under `factur_x/` produce Cross Industry Invoice (CII) XML — the UN/CEFACT XML standard — not Factur-X itself. Factur-X is the hybrid output format: a PDF/A-3 wrapping CII XML as an embedded attachment. The directory names were therefore semantically wrong; this commit renames them to match what their contents actually produce. Move 14 directories from `factur_x` to `cii` under `app/serializers/e_invoices/`, `app/services/e_invoices/`, and the corresponding spec mirrors. File contents are unchanged in this commit, so the `FacturX` module names inside still mismatch the new directory structure; the codebase will not load until the follow-up commit renames the modules to `Cii`. The PDF-embedding step in `Invoices::GeneratePdfService#attach_facturx` and its credit-note and payment-receipt equivalents are intentionally left under their current names — that operation genuinely is Factur-X (CII XML embedded in a PDF/A-3 wrapper).
The previous commit moved the `factur_x` directories to `cii` but left the `FacturX` module name unchanged inside the files, so the constants no longer matched the file paths and Rails autoloading was broken. This commit completes the inside-the-namespace rename. Rewrite every `FacturX` reference within the moved directories to `Cii`, and every `factur_x` reference to `cii` — module declarations, nested constants, and spec `describe` headers. Files outside the renamed directories are untouched in this commit. The three PDF-service callers (`Invoices::GeneratePdfService`, `CreditNotes::GeneratePdfService`, `PaymentReceipts::GeneratePdfService`) still reference `EInvoices::*::FacturX::CreateService`, so the build remains broken until the follow-up commit updates them.
The previous two commits renamed the `factur_x` directories and modules to `cii`, but the three PDF-generation services still referenced the old `EInvoices::*::FacturX::CreateService` constants and could not load them. This commit updates those references and brings the build back to green. Update the `attach_facturx` method in `Invoices::GeneratePdfService`, `CreditNotes::GeneratePdfService`, and `PaymentReceipts::GeneratePdfService` to call `EInvoices::*::Cii::CreateService` instead of the old `FacturX` constant. The method names (`attach_facturx`) stay — the operation they perform genuinely is Factur-X (embedding a CII XML attachment into a PDF/A-3 wrapper), so the name remains accurate at the call site even though the inner serializer namespace is now `Cii`.
Two follow-on places still referenced the old `FacturX` name after the source-side rename: the namespace lookup in `spec/support/xml_helper.rb` keyed on `:factur_x`, and the three PDF-service specs (`Invoices::GeneratePdfService`, `CreditNotes::GeneratePdfService`, `PaymentReceipts::GeneratePdfService`) that stub `EInvoices::*::FacturX::CreateService`. With these updated, no `FacturX` or `factur_x` references remain anywhere in `app/`, `spec/`, or `lib/`. Rename the `:factur_x` key in `XMLHelper::NAMESPACES` to `:cii` and point its value at `EInvoices::Cii::BaseSerializer::ROOT_NAMESPACES`; the spec files that consume the helper already call `xml_document(:cii)` after the earlier sweep. Update the three PDF-service specs to stub `EInvoices::*::Cii::CreateService` instead of the old `FacturX` constant. All e-invoice and PDF-service specs pass; the `grep` sanity check across `app/`, `spec/`, and `lib/` returns no results.
## Context The earlier commits renamed the FacturX namespace to Cii but left the `attach_facturx` and `should_generate_facturx_einvoice_xml?` methods (and their spec descriptions) under the old name. With the serializer namespace now uniformly `Cii`, the helper-method names were the only remaining `facturx` references in the codebase. ## Description Rename `attach_facturx` to `attach_cii` and `should_generate_facturx_einvoice_xml?` to `should_generate_cii_einvoice_xml?` in `Invoices::GeneratePdfService`, `CreditNotes::GeneratePdfService`, and `PaymentReceipts::GeneratePdfService`. Update the matching spec descriptions. No behavior change; a `grep` for `facturx`, `FacturX`, or `factur_x` across `app/`, `spec/`, and `lib/` now returns nothing.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The serializers and services under
app/serializers/e_invoices/factur_x/andapp/services/e_invoices/*/factur_x/were named after Factur-X, but they actually produce Cross Industry Invoice (CII) XML. Factur-X is the hybrid output format — a PDF/A-3 file with a CII XML stream embedded as an attachment — and is assembled one level up inInvoices::GeneratePdfService#attach_facturx(and its credit-note and payment-receipt equivalents), where the PDF is generated and the XML is embedded. The XML-producing namespace itself produces pure CII, so the directory and module names should reflect that.This PR is a cosmetic rename. The classes, generated XML, env vars, schema, and operator-facing API are all unchanged — only file paths and Ruby constants move.
What moved
app/serializers/e_invoices/factur_x/*app/serializers/e_invoices/cii/*app/serializers/e_invoices/{invoices,credit_notes,payments}/factur_x/builder.rb…/cii/builder.rbapp/services/e_invoices/{invoices,credit_notes,payments}/factur_x/create_service.rb…/cii/create_service.rbspec/{serializers,services}/e_invoices/.../factur_x/*…/cii/*EInvoices::FacturX::*EInvoices::Cii::*XMLHelper::NAMESPACES[:factur_x]XMLHelper::NAMESPACES[:cii]EInvoices::*::FacturX::CreateServiceEInvoices::*::Cii::CreateServiceWhat did not move
The
attach_facturxmethod inInvoices::GeneratePdfService,CreditNotes::GeneratePdfService, andPaymentReceipts::GeneratePdfServicekeeps its name. That method's job — embedding CII XML inside a PDF/A-3 — is genuinely Factur-X, so the name is still accurate at the call site even though the inner serializer namespace is nowCii.Test plan
bundle exec rspec spec/serializers/e_invoices/(every CII and UBL serializer spec — both load the sharedspec/support/xml_helper.rb)bundle exec rspec spec/services/e_invoices/(the renamedcii/create_service.rbfiles)bundle exec rspec spec/services/{invoices,credit_notes,payment_receipts}/generate_pdf_service_spec.rb(PDF callers stubbing the renamed constants)grep -rn 'FacturX\|factur_x' app/ spec/ lib/returns no resultsbundle exec rubocopclean on the 44 changed filesMigration
None. Pure internal rename with no behavior change, no schema change, no env-var change, and no public-API change. Operators see nothing.