Conversation
📝 WalkthroughWalkthroughThe 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
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment Tip You can disable poems in the walkthrough.Disable the |
There was a problem hiding this comment.
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
📒 Files selected for processing (20)
pom.xmlsrc/main/java/com/fiscalapi/examples/EjemplosCartaPorteReferencias.javasrc/main/java/com/fiscalapi/examples/EjemplosCartaPorteValores.javasrc/main/java/com/fiscalapi/examples/Examples.javasrc/main/java/com/fiscalapi/models/invoicing/Complement.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/Autotransporte.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/CantidadTransporta.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/CartaPorte.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/DetalleMercancia.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/DocumentoAduanero.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/Domicilio.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/Mercancia.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/ParteTransporte.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/RegimenAduanero.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/Remolque.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/TipoFigura.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteAereo.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteFerroviario.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/TransporteMaritimo.javasrc/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.java
| import java.math.BigDecimal; | ||
| import java.util.List; | ||
|
|
||
| public class Autotransporte { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { | |||
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { | |||
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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 { |
There was a problem hiding this comment.
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: SerializableDto → AuditableDto (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).
| @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; | ||
|
|
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n src/main/java/com/fiscalapi/models/invoicing/billOfLading/Ubicacion.javaRepository: 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 -nRepository: FiscalAPI/fiscalapi-java
Length of output: 2612
🏁 Script executed:
# Search for LocalDateTime serialization patterns
rg "LocalDateTime" --type java -B 3 -A 3 -n | head -100Repository: 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.
Summary by CodeRabbit
New Features
Chores