Skip to content

Added lading support#2

Open
Anidem1995 wants to merge 2 commits intomainfrom
feat/AddLadingComplementSupport
Open

Added lading support#2
Anidem1995 wants to merge 2 commits intomainfrom
feat/AddLadingComplementSupport

Conversation

@Anidem1995
Copy link
Contributor

@Anidem1995 Anidem1995 commented Mar 20, 2026

Summary by CodeRabbit

  • New Features

    • Added comprehensive bill of lading support with multiple transport modes including auto, maritime, air, and rail transport capabilities.
    • Enhanced invoice complement functionality with bill of lading integration.
  • Chores

    • Updated project version from 4.0.360 to 4.0.372.
    • Reorganized package structure for improved code organization.

@Anidem1995 Anidem1995 requested a review from mendozagit March 20, 2026 22:34
@coderabbitai
Copy link

coderabbitai bot commented Mar 20, 2026

📝 Walkthrough

Walkthrough

The PR increments the Maven version from 4.0.360 to 4.0.372 and extends the invoicing domain model by introducing a comprehensive bill of lading (CartaPorte) support. This includes 14 new data model classes covering transportation, merchandise, locations, and customs documentation, plus updates to the Complement class.

Changes

Cohort / File(s) Summary
Project Configuration
pom.xml, src/main/java/com/fiscalapi/examples/Examples.java
Incremented artifact version and changed Examples class package declaration from com.fiscalapi to com.fiscalapi.examples.
Core Bill of Lading Support
src/main/java/com/fiscalapi/models/invoicing/Complement.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/CartaPorte.java
Extended Complement with new cartaPorte field and introduced CartaPorte root domain class with 11 ID fields, 2 BigDecimal weight/distance metrics, and nested transport/merchandise structures.
Transport Models
src/main/java/com/fiscalapi/models/invoicing/billOfLading/Autotransporte.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteMaritimo.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteAereo.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteFerroviario.java
Added four transport mode classes with mode-specific identifiers, permit data, vehicle/vessel details, insurance information, and nested structures for containers and trailers.
Merchandise & Cargo Models
src/main/java/com/fiscalapi/models/invoicing/billOfLading/Mercancia.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/DetalleMercancia.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/CantidadTransporta.java
Introduced merchandise models with product descriptors, weight/quantity tracking, hazmat classification, expiration dates, customs documentation links, and detail breakdowns with BigDecimal serialization.
Location & Participant Models
src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/Domicilio.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/TipoFigura.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/ParteTransporte.java
Added location tracking (with timestamps and distance), address structures, participant/figure roles (shipper, agent, carrier), and transport segments.
Regulatory & Logistics Models
src/main/java/com/fiscalapi/models/invoicing/billOfLading/RegimenAduanero.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/DocumentoAduanero.java, src/main/java/com/fiscalapi/models/invoicing/billOfLading/Remolque.java
Added customs regime, customs documentation (pedimentos, RFC), and trailer specifications for multi-trailer configurations.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • Feat/add payroll support #1 — Both PRs extend the Complement invoice class with new domain-specific fields (cartaPorte bill of lading vs. payroll/payment/taxes).

Suggested reviewers

  • mendozagit

Poem

🐰 Hop, hop, the CartaPorte arrives!
New shipment models come alive,
BigDecimals dance with LocalDateTime's tune,
Transport and cargo sync in June!
✨📦🚚

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (2 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The PR title 'Added lading support' is directly related to the main changes—adding comprehensive bill of lading (CartaPorte) support with multiple new model classes. However, it is quite vague and uses an abbreviation ('lading') that may not be immediately clear to all developers reviewing the history.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/AddLadingComplementSupport

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Tip

You can disable poems in the walkthrough.

Disable the reviews.poem setting to disable the poems in the walkthrough.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 17

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Autotransporte.java`:
- Line 9: The Autotransporte DTO currently doesn't inherit the project DTO
hierarchy; update its declaration so it extends the project's DTO base (e.g.,
change class Autotransporte to extend BaseDto from the
SerializableDto→AuditableDto→BaseDto chain) and add the necessary import(s) for
BaseDto (and any serialVersionUID if required by SerializableDto); ensure the
class therefore inherits id (from BaseDto) and createdAt/updatedAt (from
AuditableDto) as required by the project's DTO convention.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/CantidadTransporta.java`:
- Line 8: The CantidadTransporta DTO is declared as a plain POJO; update its
declaration to extend the project DTO hierarchy by making CantidadTransporta
extend BaseDto (which inherits AuditableDto and SerializableDto in the project),
add the necessary import for BaseDto, and add any required serialVersionUID or
constructors if other DTOs in the hierarchy require them; ensure the class
signature uses "public class CantidadTransporta extends BaseDto" (and remove any
duplicate id/createdAt/updatedAt fields if present).

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/CartaPorte.java`:
- Line 9: CartaPorte is missing the required DTO inheritance chain; update the
class declaration for CartaPorte so it extends the DTO base chain
(SerializableDto → AuditableDto → BaseDto) by making it extend SerializableDto
(which in turn inherits AuditableDto and BaseDto), ensure the appropriate
imports for SerializableDto/AuditableDto/BaseDto are added, and remove any
duplicate id/createdAt/updatedAt fields if present so the class relies on the
inherited fields and behavior.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/DetalleMercancia.java`:
- Line 8: The DetalleMercancia class currently stands alone; update its
declaration so it extends the shared DTO hierarchy (BaseDto via
AuditableDto/SerializableDto) — e.g., change the class to extend AuditableDto or
BaseDto following the project's chain (SerializableDto → AuditableDto →
BaseDto), add the necessary import(s) for the chosen base class, and ensure any
required fields/methods (id, createdAt, updatedAt) or constructors align with
the inherited contract in DetalleMercancia.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/DocumentoAduanero.java`:
- Line 3: DocumentoAduanero is declared as a plain class but must participate in
the DTO inheritance chain; change its declaration to extend the BaseDto from the
DTO hierarchy (which itself extends AuditableDto and SerializableDto) so it
inherits id, createdAt and updatedAt fields. Update the class signature to
"public class DocumentoAduanero extends BaseDto" and add the necessary import
for BaseDto (and remove any conflicting fields/annotations that duplicate
id/createdAt/updatedAt) so the model follows the SerializableDto → AuditableDto
→ BaseDto hierarchy.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Domicilio.java`:
- Line 3: Domicilio currently does not inherit the project's DTO base chain;
update the class declaration for Domicilio to extend BaseDto (which already
inherits AuditableDto and SerializableDto) so it participates in the
SerializableDto → AuditableDto → BaseDto hierarchy, and add any required import
for BaseDto and a serialVersionUID if your DTOs declare one; locate the class
named Domicilio and change its declaration to extend BaseDto and ensure
imports/serialization fields are present.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Mercancia.java`:
- Line 14: Mercancia currently is a standalone model; update it to inherit the
DTO hierarchy by extending BaseDto (which already brings AuditableDto and
SerializableDto) so it complies with the DTO contract; locate the class
declaration for Mercancia and change it to extend BaseDto, remove any duplicate
id/createdAt/updatedAt fields if present, and ensure imports reference
BaseDto/AuditableDto/SerializableDto as needed.
- Around line 27-30: The fechaCaducidad field in Mercancia is annotated with a
JsonFormat pattern that includes milliseconds; update the JsonFormat pattern on
the fechaCaducidad field (the annotations on LocalDateTime fechaCaducidad in
class Mercancia) to use "yyyy-MM-dd'T'HH:mm:ss" to match
InvoiceConstants.SAT_DATE_FORMAT_OUT (remove the .SSS milliseconds portion) so
serialized values conform to the SDK SAT datetime output standard; keep the
existing JsonSerialize/JsonDeserialize annotations intact.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/ParteTransporte.java`:
- Line 3: ParteTransporte is declared as a standalone DTO but must inherit the
shared DTO chain; change its declaration to extend the top-level DTO in the
hierarchy (e.g. make ParteTransporte extend SerializableDto so it inherits
AuditableDto and BaseDto), add the proper import for SerializableDto, and ensure
any required serialVersionUID/constructors call super() if needed to satisfy the
parent classes (update class declaration "public class ParteTransporte" to
"public class ParteTransporte extends SerializableDto").

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/RegimenAduanero.java`:
- Line 3: Change the class declaration so RegimenAduanero inherits the DTO
hierarchy (e.g., "public class RegimenAduanero extends SerializableDto") so it
gets AuditableDto/BaseDto fields; add the appropriate import for SerializableDto
and update any constructors to call super() if required so the class compiles
and obtains id, createdAt and updatedAt from the DTO base hierarchy.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Remolque.java`:
- Line 3: Remolque is currently a plain POJO but must participate in the DTO
inheritance chain; change its declaration so it extends the project DTO base
(make Remolque extend BaseDto, which already chains SerializableDto →
AuditableDto → BaseDto), add the necessary import for BaseDto, and remove/adjust
any duplicate id/createdAt/updatedAt fields in Remolque so those come from the
inherited BaseDto/AuditableDto instead.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TipoFigura.java`:
- Line 5: TipoFigura is currently a plain class; change its declaration to
extend the project's DTO hierarchy by making it extend BaseDto (which itself
inherits AuditableDto and SerializableDto), add the necessary import for
BaseDto, and ensure any required serialVersionUID or no-arg constructor
expectations from SerializableDto/AuditableDto are satisfied so the DTO conforms
to the SerializableDto → AuditableDto → BaseDto contract.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteAereo.java`:
- Line 3: The TransporteAereo model must extend the project's DTO hierarchy;
update the class declaration for TransporteAereo to extend the existing BaseDto
(which sits on top of AuditableDto and SerializableDto in the chain), add the
necessary import for BaseDto, and remove any duplicate id/createdAt/updatedAt
fields from TransporteAereo so it relies on the inherited fields and behavior.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteFerroviario.java`:
- Line 9: The railway DTO classes (e.g., TransporteFerroviario and the other
DTOs noted in this file) currently do not inherit the required DTO hierarchy;
update each DTO class declaration to extend the project's base DTO chain by
making them extend BaseDto (which in turn inherits AuditableDto and
SerializableDto) — e.g., change "public class TransporteFerroviario" to "public
class TransporteFerroviario extends BaseDto" and apply the same change to the
other DTO classes at the other locations so they inherit id and audit fields.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteMaritimo.java`:
- Line 9: The new DTO classes (e.g., TransporteMaritimo) are not inheriting the
required project DTO chain; update their class declarations to extend BaseDto
(which itself extends AuditableDto and SerializableDto) so id, createdAt and
updatedAt are available, add the necessary import for BaseDto, and apply the
same change to the other two DTO-like classes referenced at the other locations
(the classes introduced at the other two spots) so they all inherit the DTO
hierarchy.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java`:
- Line 13: Ubicacion is declared as a plain POJO but must participate in the DTO
inheritance chain; update the class declaration for Ubicacion to extend the
project's DTO base (e.g., change to "public class Ubicacion extends BaseDto")
and add the necessary import for BaseDto so it inherits id, createdAt/updatedAt
and Serializable behavior via BaseDto → AuditableDto → SerializableDto; ensure
no other DTO fields are duplicated (remove local id/createdAt/updatedAt if
present).
- Around line 25-29: The JsonFormat pattern on the Ubicacion class field
fechaHoraSalidaLlegada currently includes milliseconds; change the annotation on
fechaHoraSalidaLlegada (the `@JsonFormat` on the field) to use the
SAT_DATE_FORMAT_OUT pattern "yyyy-MM-dd'T'HH:mm:ss" (remove ".SSS"), ensuring
`@JsonSerialize/`@JsonDeserialize remain intact so Jackson serializes/deserializes
exactly to the SDK's SAT format.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 2f2198e4-4c61-4e1b-ace5-a4e37014ce32

📥 Commits

Reviewing files that changed from the base of the PR and between a405b2f and 6273f18.

📒 Files selected for processing (20)
  • pom.xml
  • src/main/java/com/fiscalapi/examples/EjemplosCartaPorteReferencias.java
  • src/main/java/com/fiscalapi/examples/EjemplosCartaPorteValores.java
  • src/main/java/com/fiscalapi/examples/Examples.java
  • src/main/java/com/fiscalapi/models/invoicing/Complement.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/Autotransporte.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/CantidadTransporta.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/CartaPorte.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/DetalleMercancia.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/DocumentoAduanero.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/Domicilio.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/Mercancia.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/ParteTransporte.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/RegimenAduanero.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/Remolque.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/TipoFigura.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteAereo.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteFerroviario.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteMaritimo.java
  • src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java

import java.math.BigDecimal;
import java.util.List;

public class Autotransporte {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Autotransporte must extend the project DTO base hierarchy.

Line 9 defines a model DTO without inheriting from the required DTO chain.

As per coding guidelines **/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Autotransporte.java`
at line 9, The Autotransporte DTO currently doesn't inherit the project DTO
hierarchy; update its declaration so it extends the project's DTO base (e.g.,
change class Autotransporte to extend BaseDto from the
SerializableDto→AuditableDto→BaseDto chain) and add the necessary import(s) for
BaseDto (and any serialVersionUID if required by SerializableDto); ensure the
class therefore inherits id (from BaseDto) and createdAt/updatedAt (from
AuditableDto) as required by the project's DTO convention.


import java.math.BigDecimal;

public class CantidadTransporta {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

CantidadTransporta should inherit from the required DTO hierarchy.

Line 8 declares this DTO as a standalone POJO instead of extending the project DTO base chain.

As per coding guidelines **/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/CantidadTransporta.java`
at line 8, The CantidadTransporta DTO is declared as a plain POJO; update its
declaration to extend the project DTO hierarchy by making CantidadTransporta
extend BaseDto (which inherits AuditableDto and SerializableDto in the project),
add the necessary import for BaseDto, and add any required serialVersionUID or
constructors if other DTOs in the hierarchy require them; ensure the class
signature uses "public class CantidadTransporta extends BaseDto" (and remove any
duplicate id/createdAt/updatedAt fields if present).

import java.math.BigDecimal;
import java.util.List;

public class CartaPorte {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

CartaPorte also needs to inherit from the DTO base chain.

Line 9 defines the class without the required SerializableDto → AuditableDto → BaseDto inheritance structure.

As per coding guidelines: "**/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field)".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/CartaPorte.java` at
line 9, CartaPorte is missing the required DTO inheritance chain; update the
class declaration for CartaPorte so it extends the DTO base chain
(SerializableDto → AuditableDto → BaseDto) by making it extend SerializableDto
(which in turn inherits AuditableDto and BaseDto), ensure the appropriate
imports for SerializableDto/AuditableDto/BaseDto are added, and remove any
duplicate id/createdAt/updatedAt fields if present so the class relies on the
inherited fields and behavior.


import java.math.BigDecimal;

public class DetalleMercancia {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

DetalleMercancia must extend the shared DTO hierarchy.

Line 8 declares a standalone class instead of inheriting from the required model base chain.

As per coding guidelines: "**/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field)".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/DetalleMercancia.java`
at line 8, The DetalleMercancia class currently stands alone; update its
declaration so it extends the shared DTO hierarchy (BaseDto via
AuditableDto/SerializableDto) — e.g., change the class to extend AuditableDto or
BaseDto following the project's chain (SerializableDto → AuditableDto →
BaseDto), add the necessary import(s) for the chosen base class, and ensure any
required fields/methods (id, createdAt, updatedAt) or constructors align with
the inherited contract in DetalleMercancia.

@@ -0,0 +1,31 @@
package com.fiscalapi.models.invoicing.billOfLading;

public class DocumentoAduanero {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

DocumentoAduanero should inherit from the DTO base hierarchy.

Line 3 introduces a DTO in models without extending the required base DTO chain.

As per coding guidelines **/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field).

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/DocumentoAduanero.java`
at line 3, DocumentoAduanero is declared as a plain class but must participate
in the DTO inheritance chain; change its declaration to extend the BaseDto from
the DTO hierarchy (which itself extends AuditableDto and SerializableDto) so it
inherits id, createdAt and updatedAt fields. Update the class signature to
"public class DocumentoAduanero extends BaseDto" and add the necessary import
for BaseDto (and remove any conflicting fields/annotations that duplicate
id/createdAt/updatedAt) so the model follows the SerializableDto → AuditableDto
→ BaseDto hierarchy.

@@ -0,0 +1,103 @@
package com.fiscalapi.models.invoicing.billOfLading;

public class TransporteAereo {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

TransporteAereo should extend the mandated DTO hierarchy.

Line 3 currently defines a standalone model class in a path where DTO inheritance is required.

As per coding guidelines: "**/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field)".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteAereo.java`
at line 3, The TransporteAereo model must extend the project's DTO hierarchy;
update the class declaration for TransporteAereo to extend the existing BaseDto
(which sits on top of AuditableDto and SerializableDto in the chain), add the
necessary import for BaseDto, and remove any duplicate id/createdAt/updatedAt
fields from TransporteAereo so it relies on the inherited fields and behavior.

import java.math.BigDecimal;
import java.util.List;

public class TransporteFerroviario {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

New railway transport DTO classes bypass the mandated base DTO inheritance chain.

Line 9, Line 65, Line 88, and Line 139 define model DTOs without extending the required hierarchy. Please align these classes to the standard DTO base chain for consistent id and audit metadata behavior.

As per coding guidelines: **/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field).

Also applies to: 65-65, 88-88, 139-139

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteFerroviario.java`
at line 9, The railway DTO classes (e.g., TransporteFerroviario and the other
DTOs noted in this file) currently do not inherit the required DTO hierarchy;
update each DTO class declaration to extend the project's base DTO chain by
making them extend BaseDto (which in turn inherits AuditableDto and
SerializableDto) — e.g., change "public class TransporteFerroviario" to "public
class TransporteFerroviario extends BaseDto" and apply the same change to the
other DTO classes at the other locations so they inherit id and audit fields.

import java.math.BigDecimal;
import java.util.List;

public class TransporteMaritimo {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

DTO hierarchy requirement is not applied to the new bill-of-lading models.

Line 9, Line 266, and Line 355 introduce DTO-like classes that do not extend the required DTO chain. Please inherit from the project DTO hierarchy so id, createdAt, and updatedAt are consistently available.

As per coding guidelines: **/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field).

Also applies to: 266-266, 355-355

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteMaritimo.java`
at line 9, The new DTO classes (e.g., TransporteMaritimo) are not inheriting the
required project DTO chain; update their class declarations to extend BaseDto
(which itself extends AuditableDto and SerializableDto) so id, createdAt and
updatedAt are available, add the necessary import for BaseDto, and apply the
same change to the other two DTO-like classes referenced at the other locations
(the classes introduced at the other two spots) so they all inherit the DTO
hierarchy.

import java.math.BigDecimal;
import java.time.LocalDateTime;

public class Ubicacion {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

This model should inherit the required DTO chain.

Line 13 introduces Ubicacion as a plain POJO, which breaks the DTO inheritance requirement for models.

As per coding guidelines: "**/models/**/*.java: All DTOs must extend the DTO hierarchy: SerializableDtoAuditableDto (with createdAt, updatedAt fields) → BaseDto (with id field)".

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java` at
line 13, Ubicacion is declared as a plain POJO but must participate in the DTO
inheritance chain; update the class declaration for Ubicacion to extend the
project's DTO base (e.g., change to "public class Ubicacion extends BaseDto")
and add the necessary import for BaseDto so it inherits id, createdAt/updatedAt
and Serializable behavior via BaseDto → AuditableDto → SerializableDto; ensure
no other DTO fields are duplicated (remove local id/createdAt/updatedAt if
present).

Comment on lines +25 to +29
@JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss.SSS")
@JsonSerialize(using = LocalDateTimeSerializer.class)
@JsonDeserialize(using = LocalDateTimeDeserializer.class)
private LocalDateTime fechaHoraSalidaLlegada;

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🏁 Script executed:

cat -n src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java

Repository: FiscalAPI/fiscalapi-java

Length of output: 5032


🏁 Script executed:

# Search for SAT output formatter patterns in the codebase
rg "yyyy-MM-dd.*HH:mm:ss" --type java -n

Repository: FiscalAPI/fiscalapi-java

Length of output: 2612


🏁 Script executed:

# Search for LocalDateTime serialization patterns
rg "LocalDateTime" --type java -B 3 -A 3 -n | head -100

Repository: FiscalAPI/fiscalapi-java

Length of output: 9738


Align fechaHoraSalidaLlegada format with SAT output pattern.

Line 25 currently serializes with milliseconds (...ss.SSS), but the SDK's SAT_DATE_FORMAT_OUT is yyyy-MM-dd'T'HH:mm:ss (without milliseconds). Code comments and the formatter constant explicitly require the pattern without fractions. Update to match the standard SAT pattern to prevent serialization inconsistencies.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java`
around lines 25 - 29, The JsonFormat pattern on the Ubicacion class field
fechaHoraSalidaLlegada currently includes milliseconds; change the annotation on
fechaHoraSalidaLlegada (the `@JsonFormat` on the field) to use the
SAT_DATE_FORMAT_OUT pattern "yyyy-MM-dd'T'HH:mm:ss" (remove ".SSS"), ensuring
`@JsonSerialize/`@JsonDeserialize remain intact so Jackson serializes/deserializes
exactly to the SDK's SAT format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant