## Context

As fee now can be related to a fixed_charge, items will be charge fee's
addon, so a lot of item-related methods should be updated

## Description

- added new fee_type
- updated item methods on fee
- updated tests

---------

Co-authored-by: Ancor Cruz <hello@ancorcruz.com>

## Context

As Charge Model will be used by both: Charges and FixedCharges, on this
step we want to extract ChargeModel services into their own namespace in
services directory

## Description

- moved ChargeModel out of Charges repository
- updated all usages of Charges::ChargeModel

(note: the services only change is removing Charges namespace, we
updated 11 files, removing `module Charges; end` - 2 lines in each file,
so 22 lines difference comes from here)

---------

Co-authored-by: Ancor Cruz <hello@ancorcruz.com>

### Problem
```            
"message": "undefined method 'code' for an instance of BaseService::ThirdPartyFailure",
 "backtrace": [
       "/app/app/graphql/concerns/execution_error_responder.rb:85:in 'ExecutionErrorResponder#result_error'",
       "/app/app/graphql/mutations/invoices/generate_payment_url.rb:23:in 'Mutations::Invoices::GeneratePaymentUrl#resolve'",
```

`::Invoices::Payments::GeneratePaymentUrlService.call(invoice:)` can
result in a `result.third_party_failure!`.


https://github.com/getlago/lago-api/blob/main/app/services/invoices/payments/stripe_service.rb#L68

### Stacktrace

https://github.com/getlago/lago-api/blob/main/app/graphql/mutations/invoices/generate_payment_url.rb

https://github.com/getlago/lago-api/blob/main/app/services/invoices/payments/generate_payment_url_service.rb#L35

https://github.com/getlago/lago-api/blob/main/app/services/payment_intents/fetch_service.rb#L19-L21

https://github.com/getlago/lago-api/blob/main/app/services/invoices/payments/stripe_service.rb#L55-L69

### Fix
Respond `BaseService::ThirdPartyFailure` correctly at
`ExecutionErrorResponder`

https://github.com/getlago/lago-api/blob/0b0500f7fa85ab6e1fe6a204274e13d3c3a2ff4f/app/graphql/concerns/execution_error_responder.rb#L79-L80

---------

Co-authored-by: Ivan Novosad <ivannovosad@users.noreply.github.com>

## Context

extract `Charges::BuildDefaultPropertiesService` into it's own
namespace, becuase now it will also be used by fixed_charge, and it is
related to selected charge_Model, rather than to charge itself

## Description

- Move `Charges::BuildDefaultPropertiesService` to
`ChargeModels::BuildDefaultPropertiesService`

---------

Co-authored-by: Ancor Cruz <hello@ancorcruz.com>

## Context

Add fixed_charges_taxes

## Description

Describe your changes in detail.

- added a migration to created fixed_charges_taxes table
- Added `FixedCharge::AppliedTax` model
- updated relationships to the new model

---------

Co-authored-by: Ancor Cruz <hello@ancorcruz.com>

Need it to bind some FE logic

---------

Co-authored-by: Miguel Pinto <darkymiguel@gmail.com>

## Context

Add FixedCharge::ApplyTaxes service

## Description

- Added FixedCharge::ApplyTaxes service that is analogical to
Charges::ApplyTaxes service

---------

Co-authored-by: Ancor Cruz <hello@ancorcruz.com>

… not paid (#4092)

## Context

Request from users:

> We need webhook message when a dunning campaign ends and isn't paid so
we can auto-block users who don't pay at the end of their dunning
campaign.
> 
> If possible - it would be great to include the customer's overdue
balance in the message

## Description

This PR adds `dunning_campaign.finished` webhook to match described
use-case

#4102)

## Context

There is an issue when we're calling `ActivityLog` with a huge payload
e.g. an invoice with a lot of fees.
In that case we're hitting the Kafka payload limit (1MB by default) and
getting `WaterDrop::Errors::MessageInvalidError`

## Description

In order to fix this issue we skip fees to be serialized for invoices
that have more than 25 fees.
So that `ActivityLog` would still log the invoice except the fees in
this case.

## Description

Ignore Adyen's [OFFER_CLOSED
webhook](https://docs.adyen.com/api-explorer/Webhooks/1/post/OFFER_CLOSED)

## Description
When an organization have a payment from a discarded customer, the page
for listing payments and the payment page gets broken.

## Fix
Allow payment to load discarded customers.

## Context

Currently, when voiding an invoice, it’s not possible to regenerate it
with updated fee attributes. This limitation creates friction for users
who want to correct or adjust values such as units, unit_amount_cents,
or invoice_display_name after an invoice has already been issued and
voided.

## Description

This PR introduces two new services that enable the regeneration of a
voided invoice with adjusted fee values:

AdjustedFees::EstimateService

This service is used to preview how a fee would be adjusted before
persisting any data. It handles all necessary backend calculations—such
as tax application, amount breakdown, and unit price derivation—based on
the provided input. It is designed to be used by the frontend to fetch
real-time estimates while the user is making adjustments to fees.

Invoices::RegenerateFromVoidedService

This service is responsible for actually rebuilding the invoice from a
voided one. It:
	•	Duplicates relevant fee records,
• Applies adjustments coming from the frontend (e.g., new units, updated
unit_amount_cents, or invoice_display_name),
	•	Recalculates all fee amounts, taxes, and totals,
	•	Applies coupons, credit notes, and prepaid credits if applicable,
• Transitions the invoice to the appropriate payment status (pending or
succeeded).

## Roadmap Task

👉  https://getlago.canny.io/feature-requests/p/{{FEATURE_SLUG}}

## Context

Include relevant motivation and context.

## Description

Describe your changes in detail.

List any dependencies that are required.