sabre-client 0.6.0 → 0.7.0

package/README.es.md

@@ -12,21 +12,31 @@ SDK de TypeScript para las APIs de Sabre.
 
 ## Estado
 
-La `0.6.0` está publicada con el dist-tag `next` mientras se prueba; `latest` sigue en la `0.5.1`.
+La `0.7.0` está publicada con el dist-tag `next` mientras se prueba; `latest` sigue en la `0.6.0`.
 Cubre el Tier 1 y el Tier 2 del flujo de Air Booking por REST, el Tier 3 (sesiones SOAP y colas) y
 el Tier 4: actividad de colas, historial del PNR, la cola de mensajes `S`, `selection` en `list` y
-`onRawRequest`. La `0.6.0` suma filtros de cola: `count` con una cola, un rango o `selection`,
-`activity` con una cola o un rango, y `selection` en el fake de colas. No trae cambios
-incompatibles; la línea `0.5` trae tres (ver [Actualizar desde la 0.4](#actualizar-desde-la-04)).
+`onRawRequest`, además de los filtros de cola de la `0.6.0`. La `0.7.0` suma la emisión y el void
+de boletos ([Emitir y anular boletos](#emitir-y-anular-boletos)), las ventas del día
+([Ventas del día](#ventas-del-día)) y un fake REST de reservas y emisión en
+`sabre-client/testing`. Trae un cambio incompatible, en el void (ver
+[Actualizar desde la 0.6](#actualizar-desde-la-06)).
 
 ```sh
-npm install sabre-client@next   # 0.6.0
-npm install sabre-client        # 0.5.1
+npm install sabre-client@next   # 0.7.0
+npm install sabre-client        # 0.6.0
 ```
 
 El paquete sigue en `0.x`: una versión minor puede traer cambios incompatibles, y el
 [CHANGELOG](./CHANGELOG.md) los marca.
 
+### Actualizar desde la 0.6
+
+- **Un void que pudo no haberse hecho lanza.** Con `flightTicketOperation: 'VOID'`,
+  `booking.cancel` ya no devuelve `END_TRANSACTION_PROBLEM` como aviso: lanza
+  `SabreUncertainOutcomeError`, igual que con un fallo de red, un `5xx`, un cuerpo ilegible o un
+  abort con el request ya mandado. Atrápalo y verifica con `sabre.tickets.verify` antes de
+  reintentar (ver [Anular](#anular)). Un cancel sin `VOID` no cambia.
+
 ### Actualizar desde la 0.4
 
 - **`pcc` ya no está en la config.** Pasarlo a `new Sabre` o a `new SabreLegacy` da un error de
@@ -49,6 +59,14 @@ El Tier 1 cubre el flujo básico de Air Booking por REST:
 | Reserva | Create Booking (Booking Management API v1, ATPCO por `flightDetails`) | `sabre.booking.create` |
 | Gestión de la reserva | Get Booking y Cancel Booking (Booking Management API v1) | `sabre.booking.get`, `sabre.booking.cancel` |
 
+Emisión (flujo W4, `0.7.0`):
+
+| Paso | Servicio | Método |
+| - | - | - |
+| Emisión | Fulfill Flight Tickets (Booking Management API v1) | `sabre.tickets.fulfill` |
+| Verificación | Get Booking | `sabre.tickets.verify` |
+| Void | Cancel Booking con `flightTicketOperation: 'VOID'` | `sabre.booking.cancel` |
+
 El Tier 2 agrega la elección de asiento:
 
 | Paso | Servicio | Método |
@@ -65,6 +83,7 @@ El Tier 3 agrega el cliente SOAP `SabreLegacy`, con una sesión stateful y Queue
 | Párrafo de cola | — (función pura) | `parseQueueParagraph`, `parseQueuePlaceRemark`, `resolveHostDate` |
 | Historial del PNR | `TravelItineraryHistoryLLSRQ` 2.4.0 | `session.reservation.history` |
 | Comandos de host | `SabreCommandLLSRQ` 2.0.0 | `session.command` |
+| Ventas del día | `TKT_TravelAgencyReportsRQ` / `DailySalesSummaryRQ` 1.2.2 (el «Summary» del DQB) | `session.reporting.dailySalesSummary` |
 
 Planeado después de `0.5.0`: Get Ancillaries (solo NDC).
 
@@ -233,9 +252,9 @@ Como `create`, **nunca se reintenta automáticamente**. Las combinaciones que Sa
 rechaza (`cancelAll` junto con listas, ni `cancelAll` ni listas, `offerItemId` junto con
 `flightTicketOperation`) lanzan un `TypeError` antes de enviar nada. Si Sabre responde
 `NO_ITEMS_CANCELLED`, la llamada lanza `SabreBusinessError` aunque Sabre lo mande como aviso,
-porque no se canceló nada; los errores que explican el motivo están en `error.errors`. El aviso
-`END_TRANSACTION_PROBLEM` significa que la confirmación sigue pendiente: verifica el resultado
-con `sabre.booking.get`.
+porque no se canceló nada; los errores que explican el motivo están en `error.errors`. Sin
+`VOID`, el aviso `END_TRANSACTION_PROBLEM` significa que la confirmación sigue pendiente: verifica
+el resultado con `sabre.booking.get`. Con `VOID`, lanza: ver [Anular](#anular).
 
 Toda request acepta un `AbortSignal`. Las búsquedas aceptan además una política de reintentos
 propia:
@@ -244,6 +263,109 @@ propia:
 await sabre.air.bargainFinderMax(search, { signal, retry: { maxRetries: 1 } });
 ```
 
+## Emitir y anular boletos
+
+`sabre.tickets.fulfill` emite los boletos (y EMD) de una reserva con su PQ guardado (Fulfill
+Flight Tickets). **Mueve dinero y nunca se reintenta**, ni siquiera tras un fallo de red; pasar
+`retry.maxRetries` distinto de 0 lanza `TypeError` sin llamar a Sabre.
+
+```ts
+import { SabreUncertainOutcomeError } from 'sabre-client';
+
+const before = await sabre.booking.get({ confirmationId });
+const knownTickets = (before.flightTickets ?? []).map((ticket) => ticket.number);
+
+try {
+  const issued = await sabre.tickets.fulfill({
+    confirmationId,
+    fulfillments: [{ payment: { primaryFormOfPayment: 1 }, ticketingQualifiers: { commissionPercentage: '0.00' } }],
+    formsOfPayment: [{ type: 'CASH' }],
+    designatePrinters: [{ profileNumber: 1 }],
+  });
+  if (issued.status === 'partial') {
+    // Hay boletos emitidos y faltan otros: guarda estos y verifica antes de completar.
+  }
+} catch (error) {
+  if (!(error instanceof SabreUncertainOutcomeError)) throw error; // no se emitió
+  const check = await sabre.tickets.verify({
+    confirmationId,
+    knownTickets,
+    expectedTickets: error.tickets.map((ticket) => ticket.number),
+  });
+  // check.status: 'issued' | 'notCommitted' | 'notFound'
+}
+```
+
+El SDK manda `acceptPriceChanges: false` y `priceQuoteExpirationMethod: 'Quit'` salvo que pases
+otros valores: una emisión automática nunca paga un precio que nadie vio. Con un precio nuevo,
+Sabre responde `PRICE_MISMATCH`.
+
+Hay cuatro desenlaces:
+
+| Desenlace | Qué recibes | Qué hacer |
+| - | - | - |
+| Emitido | `status: 'issued'`, todos los boletos con `isCommitted: true` | Guardar `tickets` |
+| Parcial | `status: 'partial'`: algunos boletos, y `PARTIAL_FULFILLMENT` o un error | Guardar los emitidos y verificar antes de completar |
+| No emitido | `SabreBusinessError` (`PRICE_MISMATCH`, `BOOKING_FULFILLED`…) o `SabreGatewayError` (400, 401, 403, 429) | Corregir la causa; no se emitió nada |
+| Incierto | `SabreUncertainOutcomeError`, con `reason`, `confirmationId`, `tickets` y `cause` | Verificar con `tickets.verify` antes de pensar en reintentar |
+
+> [!WARNING]
+> **`partial` no es una emisión completa**: hay pasajeros sin boleto. No vuelvas a emitir a
+> ciegas: los boletos emitidos son reales, y un segundo fulfill puede dar `BOOKING_FULFILLED` o
+> emitir dos veces. Verifica primero.
+
+- **Incierto** cubre `UNABLE_TO_RETRIEVE_TICKETS`, `FULFILLMENT_NOT_CONFIRMED`,
+  `INTERNAL_SERVER_TIMEOUT` (salvo que Sabre diga que no emitió boletos nuevos),
+  `DOWNLINE_SERVICE_ERROR`, `PAYMENT_CARD_ISSUE`, un fallo de red, un `5xx`, un cuerpo ilegible y
+  un abort con el request ya mandado (`ABORTED`, con el `AbortError` en `cause`). Un abort antes
+  de mandarlo se propaga tal cual.
+- Con `reason: 'NOT_COMMITTED'`, `tickets` trae los boletos que Sabre devolvió con
+  `isCommitted: false`. **Esos boletos existen**, aunque el PNR todavía no los muestre: no vuelvas
+  a emitir.
+- Los errores de configuración del PCC (comisión, impresora, Secure Flight) llegan como
+  `DOWNLINE_SERVICE_ERROR` y se tratan como incierto (CERT).
+- `BOOKING_FULFILLED` quiere decir que la reserva ya tiene boletos, **no** que sean de esta
+  emisión: verifica.
+
+`sabre.tickets.verify` lee la reserva con Get Booking y nunca emite. Mira el `ticketStatusCode`
+de cada boleto (`TE`, `ME` o `TO` están vigentes, `TV` está anulado), no `isTicketed`, que sigue
+en `true` después de un void:
+
+- `issued`: hay boletos vigentes nuevos (fuera de `knownTickets`), y están todos los
+  `expectedTickets`.
+- `notCommitted`: faltan `expectedTickets` en el PNR (un *ghost ticket*). Están emitidos: no
+  vuelvas a emitir.
+- `notFound`: ningún boleto vigente nuevo. **No prueba que no se haya emitido**: el guardado en el
+  PNR puede tardar. Espera y verifica otra vez, y en producción revisa también las ventas del día
+  ([Ventas del día](#ventas-del-día), por `pnrLocator`) antes de reintentar.
+
+Si emitiste con `targetPcc` en `fulfill`, pasa el mismo `targetPcc` a `verify`.
+
+### Anular
+
+El void va por `sabre.booking.cancel` con `flightTicketOperation: 'VOID'`. Con `cancelAll` y
+`HALT_ON_ERROR`, una sola llamada anula los boletos y cancela la reserva, y `voidedTickets` trae
+los números anulados (CERT):
+
+```ts
+const result = await sabre.booking.cancel({
+  confirmationId,
+  cancelAll: true,
+  flightTicketOperation: 'VOID',
+  errorHandlingPolicy: 'HALT_ON_ERROR',
+});
+result.voidedTickets; // ['0060000000001']
+```
+
+- **Un void no se puede deshacer.** Un fallo de red, un `5xx`, un cuerpo ilegible, un abort con
+  el request ya mandado o `END_TRANSACTION_PROBLEM` lanzan `SabreUncertainOutcomeError`
+  (`operation: 'booking.cancel'`): no se sabe si se anularon los boletos. Verifica con
+  `sabre.tickets.verify` (un boleto anulado queda en `TV`) o con `booking.get` antes de reintentar.
+- `VOID` sobre una reserva sin boletos lanza `NO_ITEMS_CANCELLED` con `UNABLE_TO_VOID_TICKET` y
+  **no cancela nada**. Para una reserva que nunca se emitió, cancela sin `VOID`.
+- Una venta anulada sigue en las ventas del día como `SALE` con `documentStatusCode: 'V'`, y no
+  cuenta en `totals` (CERT).
+
 ## Elegir un asiento
 
 `sabre.air.getSeats` devuelve el mapa de asientos con disponibilidad y precio. Es una sola
@@ -431,6 +553,44 @@ const { transactions } = await legacy.withSession((session) => session.reservati
   lanza un `TypeError` sin llamar a la red. Un PNR que no existe lanza un `SabreBusinessError`
   (`service: 'itineraryHistory'`).
 
+### Ventas del día
+
+`session.reporting.dailySalesSummary(request?, options?)` lee las ventas del día (el «Summary» del
+DQB, `TKT_TravelAgencyReportsRQ` / `DailySalesSummaryRQ` 1.2.2): una transacción por movimiento del
+PCC en ese día (ventas, reembolsos, voids, EMD y MCO), sin tope, y los totales del día.
+
+```ts
+const report = await legacy.withSession((session) =>
+  session.reporting.dailySalesSummary({ date: '2026-11-12' }),
+);
+// report.status → 'complete' | 'incomplete' | 'deferred'
+// report.transactions[0] → { documentType: 'TKT', transactionCode: 'SALE', documentNumber,
+//                            documentStatusCode, pnrLocator, passengerName, payments,
+//                            transactionDateTime: '2026-11-12T11:02:00.000', … }
+// report.totals → por tipo de transacción, settlement y moneda
+```
+
+- **Un día por llamada**, sin rango. Sin `date`, es el día en curso, hasta minutos antes de la
+  llamada (producción). Los filtros son `pcc`, `documentType`, `settlementType`, `airline` y
+  `documentNumber`.
+- **Las fechas y horas llegan tal como las manda Sabre, sin zona**: `transactionDateTime` es
+  `'YYYY-MM-DDTHH:MM:SS.sss'`, en hora local del PCC en producción. El SDK no las convierte,
+  porque no conoce la zona.
+- **Solo `status: 'complete'` es el día entero.** `incomplete` quiere decir que Sabre no pudo leer
+  algunos documentos (`failedDocuments`), así que faltan transacciones. `deferred` quiere decir
+  que Sabre dejó el reporte en caché (`deferred.reportId`) o sigue corriendo: vuelve a pedirlo más
+  tarde. El SDK no manda `CachedReportRQ`.
+- Un void no agrega una transacción: la venta original sigue como `SALE` con
+  `documentStatusCode: 'V'`, y no cuenta en `totals` (CERT).
+- Los importes van como string, tal como los manda Sabre. **Trae nombres de pasajeros**
+  (`passengerName`); el SDK nunca los registra en el log.
+- Otro PCC necesita Branch Access. Sin él, Sabre responde `45100` y el SDK lanza
+  `SabreBusinessError` (`service: 'dailySalesSummary'`). Un filtro con forma equivocada lanza
+  `TypeError` sin llamar a la red.
+- **En CERT el reporte puede no tener datos**: un PCC que no emite recibe un reporte `complete`
+  sin transacciones. Un reporte vacío en CERT no prueba nada.
+- Es una lectura: se reintenta ante fallos de transporte, no ante errores de negocio.
+
 ### Colas
 
 Las operaciones de cola están en `session.queue`. `pcc` es opcional en cada llamada, y por defecto
@@ -658,6 +818,12 @@ fake.openSessions; // 0: la sesión se cerró
   `count` con `queue` cuenta los que cumplen y devuelve `totals.unfiltered`; con `range` o sin
   cola, da los errores de Sabre. Otro código recibe un error de host marcado como no simulado,
   nunca la cola entera.
+- `reporting.dailySalesSummary`: `dailySales` siembra las transacciones por PCC y fecha
+  (`{ ABCD: { '2026-11-12': [transacciones] } }`, con la forma de `DailySalesTransaction`), o un
+  día con `status: 'incomplete'` o `'deferred'`, o un `errorCode` como `'45100'`. Sin `pcc` usa el
+  PCC de la sesión; sin `date`, el día de `now()` en `dailySalesTimeZone` (una zona IANA, `'UTC'`
+  por defecto). Un PCC o un día sin sembrar da un reporte `complete` vacío. El filtro
+  `documentType` se simula, los demás no, y los `totals` salen vacíos.
 - **No simula** los PCC (las colas son las mismas para cualquier `pcc`) ni las reglas de
   combinación de `selection` del host.
 - `queueFixtures` trae las respuestas anonimizadas que se grabaron en producción (`walk`,
@@ -683,6 +849,50 @@ fake.openSessions; // 0: la sesión se cerró
   }));
   ```
 
+#### Reservas y emisión (REST)
+
+El mismo `fake.fetch` responde también al cliente REST (`Sabre`): el token, Create, Get y Cancel
+Booking, y Fulfill Flight Tickets. Pásalo en la config de `Sabre` para correr la emisión y el void
+sin red:
+
+```ts
+import { Sabre } from 'sabre-client';
+import { createQueueFake } from 'sabre-client/testing';
+
+const fake = createQueueFake({
+  bookings: { ABCDEF: {} }, // o deja que booking.create cree FAKEAA, FAKEAB…
+  ticketing: { fulfill: [{ downline: 'COMMISSION_REQUIRED' }, 'issued'] },
+});
+const sabre = new Sabre({ ...config, fetch: fake.fetch });
+
+await sabre.tickets.fulfill(request); // SabreUncertainOutcomeError, reason DOWNLINE_SERVICE_ERROR
+await sabre.tickets.fulfill(request); // issued: un boleto TE, que aparece en booking.get
+await sabre.booking.cancel({ confirmationId: 'ABCDEF', cancelAll: true, flightTicketOperation: 'VOID' });
+await sabre.tickets.verify({ confirmationId: 'ABCDEF' }); // notFound: el boleto ya está en TV
+```
+
+- `tickets.fulfill` emite un boleto `TE` por reserva, que después aparece en `booking.get` y en
+  `tickets.verify`. Una segunda emisión sobre una reserva con un boleto vigente da
+  `BOOKING_FULFILLED`.
+- `booking.cancel` con `VOID` deja los boletos vigentes en `TV`, devuelve sus números en
+  `voidedTickets` y, con `cancelAll`, cancela la reserva en la misma llamada. `isTicketed` sigue en
+  `true`, como en CERT. `VOID` sobre una reserva sin boletos da `NO_ITEMS_CANCELLED` con
+  `UNABLE_TO_VOID_TICKET` y no cancela nada.
+- `ticketing.fulfill` y `ticketing.void` fuerzan los desenlaces siguientes, en orden:
+  - `'issued'` o `'partial'` (`PARTIAL_FULFILLMENT`);
+  - `{ uncertain: reason, issued? }`, para cada reason de `SabreUncertainOutcomeError`. `issued`
+    dice si la reserva quedó emitida de verdad, para probar tu verificación. Con `NOT_COMMITTED`
+    el boleto existe pero Get Booking no lo muestra (un *ghost ticket*);
+  - `{ downline }`, para los cuatro `DOWNLINE_SERVICE_ERROR` vistos en CERT, con su texto real:
+    `INVALID_TICKET_STOCK`, `COMMISSION_REQUIRED`, `HARDCOPY_PRINTER` y `SECURE_FLIGHT`;
+  - `{ error, description? }`, para cualquier otro error de Fulfill, como `PRICE_MISMATCH`;
+  - para el void, `'voided'` o `{ uncertain, voided? }`.
+- `fake.calls` registra `token`, `createBooking`, `getBooking`, `cancelBooking` y `fulfill`, con el
+  localizador.
+- **No se simula**: el itinerario, las tarifas ni los pasajeros (Get Booking devuelve una reserva
+  mínima), más de un boleto por reserva, Void Flight Tickets ni `targetPcc` (cualquier PCC ve las
+  mismas reservas).
+
 `examples/queue-review.mjs` es un ejemplo completo, y su test lo corre contra el fake.
 
 #### Anonimizar respuestas grabadas
@@ -729,6 +939,7 @@ Todos los errores que lanza el SDK extienden `SabreError`:
 | `SabreOrchestrationError` | Error de un servicio orquestado dentro de un `200` (`SP.*`) | `code` |
 | `SabreBusinessError` | Error del catálogo propio de un servicio (p. ej. `No Availability`, una reserva que no se creó) | `service`, `code`, `warnings`, `errors` |
 | `SabreSessionError` | Falla de la sesión SOAP de `SabreLegacy`, subclase de `SabreGatewayError` | `kind`: `'limit'` (más de 50 sesiones), `'invalid'`, `'expired'`, `'blocked'` |
+| `SabreUncertainOutcomeError` | La emisión o el void pudieron haberse hecho, o no (`tickets.fulfill`, `booking.cancel` con `VOID`): verifica antes de reintentar | `operation`, `confirmationId`, `reason`, `tickets`, `warnings` |
 | `SabreWarning` | Aviso no fatal (p. ej. `category: WARNING` en Create Booking) | `service`, `code` |
 
 Todos tienen `retryable`, que indica si la política de reintentos puede volver a intentar.
@@ -757,7 +968,8 @@ try {
 ## Respuesta cruda
 
 Toda operación REST (`air.bargainFinderMax`, `air.revalidateItinerary`, `air.getSeats`,
-`booking.create`, `booking.get` y `booking.cancel`), y toda operación de `SabreLegacy`, acepta un
+`booking.create`, `booking.get`, `booking.cancel`, `tickets.fulfill` y `tickets.verify`), y toda
+operación de `SabreLegacy`, acepta un
 callback `onRawResponse` en sus
 opciones, junto a `signal`. Recibe la respuesta de Sabre tal cual llegó, por ejemplo para
 guardarla junto al resultado tipado. En `air.getSeats`, `operation` indica el endpoint que se
@@ -782,7 +994,8 @@ const booking = await sabre.booking.get({ confirmationId }, { onRawResponse: (r)
   conserva el valor y escríbelo cuando la llamada vuelva.
 
 En `SabreLegacy`, `protocol` es `'soap'`, `body` es el sobre SOAP completo, y `operation` es
-`'openSession'`, `'close'`, `'ping'`, `'command'` o `'queue.<método>'`. El token de la sesión
+`'openSession'`, `'close'`, `'ping'`, `'command'`, `'queue.<método>'`, `'reservation.history'` o
+`'reporting.dailySalesSummary'`. `tickets.verify` reporta `'booking.get'`, el Get Booking que corre. El token de la sesión
 (`BinarySecurityToken`) se reemplaza por `[REDACTED]` donde aparezca. No se cambia nada más.
 
 > [!WARNING]
@@ -825,7 +1038,8 @@ await sabre.booking.get({ confirmationId }, { onRawRequest: (r) => (sent = r) })
 ## Reintentos
 
 Solo se reintentan las operaciones idempotentes: Bargain Finder Max y Revalidate Itinerary
-(ambas son `POST` de solo lectura). Create Booking nunca se reintenta. Los reintentos usan
+(ambas son `POST` de solo lectura), además de Get Booking y `tickets.verify`. Create Booking,
+Cancel Booking y `tickets.fulfill` nunca se reintentan. Los reintentos usan
 backoff exponencial con full jitter y un piso de 500 ms, ante `429`, `500`, `503`, `504`,
 `SP.PROVIDER_ERROR` y los errores temporales del catálogo de Bargain Finder Max.
 

package/README.md

@@ -12,21 +12,31 @@ TypeScript SDK for the Sabre APIs.
 
 ## Status
 
-`0.6.0` is published under the `next` dist-tag while it is tested; `latest` stays on `0.5.1`.
+`0.7.0` is published under the `next` dist-tag while it is tested; `latest` stays on `0.6.0`.
 It covers Tier 1 and Tier 2 of the Air Booking flow over REST, Tier 3 (SOAP sessions and queues)
 and Tier 4: queue activity, PNR history, the `S` message queue, `selection` in `list` and
-`onRawRequest`. `0.6.0` adds queue filters: `count` with one queue, a range or `selection`,
-`activity` with one queue or a range, and `selection` in the queue fake. It has no breaking
-changes; the `0.5` line has three (see [Upgrading from 0.4](#upgrading-from-04)).
+`onRawRequest`, plus the queue filters of `0.6.0`. `0.7.0` adds ticket issuance and void
+([Issuing and voiding tickets](#issuing-and-voiding-tickets)), the day's sales report
+([Daily sales](#daily-sales)) and a REST fake of bookings and ticketing in
+`sabre-client/testing`. It has one breaking change, in the void (see
+[Upgrading from 0.6](#upgrading-from-06)).
 
 ```sh
-npm install sabre-client@next   # 0.6.0
-npm install sabre-client        # 0.5.1
+npm install sabre-client@next   # 0.7.0
+npm install sabre-client        # 0.6.0
 ```
 
 The package is still `0.x`: a minor version may include breaking changes, and the
 [CHANGELOG](./CHANGELOG.md) marks them.
 
+### Upgrading from 0.6
+
+- **A void that may not have happened throws.** With `flightTicketOperation: 'VOID'`,
+  `booking.cancel` no longer returns `END_TRANSACTION_PROBLEM` as a warning: it throws
+  `SabreUncertainOutcomeError`, and so do a network failure, a `5xx`, an unreadable body and an
+  abort after the request was sent. Catch it and check with `sabre.tickets.verify` before
+  retrying (see [Voiding](#voiding)). A cancel without `VOID` is unchanged.
+
 ### Upgrading from 0.4
 
 - **`pcc` is no longer in the config.** Passing it to `new Sabre` or `new SabreLegacy` is a type
@@ -49,6 +59,14 @@ Tier 1 covers the core Air Booking flow over REST:
 | Booking | Create Booking (Booking Management API v1, ATPCO by `flightDetails`) | `sabre.booking.create` |
 | Booking management | Get Booking and Cancel Booking (Booking Management API v1) | `sabre.booking.get`, `sabre.booking.cancel` |
 
+Ticketing (flow W4, `0.7.0`):
+
+| Step | Service | Method |
+| - | - | - |
+| Issuance | Fulfill Flight Tickets (Booking Management API v1) | `sabre.tickets.fulfill` |
+| Verification | Get Booking | `sabre.tickets.verify` |
+| Void | Cancel Booking with `flightTicketOperation: 'VOID'` | `sabre.booking.cancel` |
+
 Tier 2 adds seat selection:
 
 | Step | Service | Method |
@@ -65,6 +83,7 @@ Tier 3 adds the `SabreLegacy` SOAP client, with a stateful session and Queue Man
 | Queue paragraph | — (pure function) | `parseQueueParagraph`, `parseQueuePlaceRemark`, `resolveHostDate` |
 | PNR history | `TravelItineraryHistoryLLSRQ` 2.4.0 | `session.reservation.history` |
 | Host commands | `SabreCommandLLSRQ` 2.0.0 | `session.command` |
+| Daily sales | `TKT_TravelAgencyReportsRQ` / `DailySalesSummaryRQ` 1.2.2 (the DQB «Summary») | `session.reporting.dailySalesSummary` |
 
 Planned after `0.5.0`: Get Ancillaries (NDC only).
 
@@ -233,9 +252,10 @@ Like `create`, it is **never retried automatically**. Combinations that Sabre al
 (`cancelAll` together with item lists, no `cancelAll` and no list, `offerItemId` together with
 `flightTicketOperation`) throw a `TypeError` before any request is sent. If Sabre answers
 `NO_ITEMS_CANCELLED`, the call throws `SabreBusinessError` even though Sabre sends it as a
-warning, because nothing was cancelled; the errors that explain why are in `error.errors`. An
-`END_TRANSACTION_PROBLEM` warning means the confirmation is still pending: check the result
-with `sabre.booking.get`.
+warning, because nothing was cancelled; the errors that explain why are in `error.errors`.
+Without `VOID`, an `END_TRANSACTION_PROBLEM` warning means the confirmation is still pending:
+check the result with `sabre.booking.get`. With `VOID` it throws instead: see
+[Voiding](#voiding).
 
 Every request accepts an `AbortSignal`. Shopping calls also accept a per-request retry policy:
 
@@ -243,6 +263,109 @@ Every request accepts an `AbortSignal`. Shopping calls also accept a per-request
 await sabre.air.bargainFinderMax(search, { signal, retry: { maxRetries: 1 } });
 ```
 
+## Issuing and voiding tickets
+
+`sabre.tickets.fulfill` issues the tickets (and EMDs) of a booking with its stored price quote
+(Fulfill Flight Tickets). **It moves money and is never retried**, not even after a network
+failure; passing `retry.maxRetries` other than 0 throws a `TypeError` without calling Sabre.
+
+```ts
+import { SabreUncertainOutcomeError } from 'sabre-client';
+
+const before = await sabre.booking.get({ confirmationId });
+const knownTickets = (before.flightTickets ?? []).map((ticket) => ticket.number);
+
+try {
+  const issued = await sabre.tickets.fulfill({
+    confirmationId,
+    fulfillments: [{ payment: { primaryFormOfPayment: 1 }, ticketingQualifiers: { commissionPercentage: '0.00' } }],
+    formsOfPayment: [{ type: 'CASH' }],
+    designatePrinters: [{ profileNumber: 1 }],
+  });
+  if (issued.status === 'partial') {
+    // Some tickets were issued and some are missing: store these and verify before completing.
+  }
+} catch (error) {
+  if (!(error instanceof SabreUncertainOutcomeError)) throw error; // not issued
+  const check = await sabre.tickets.verify({
+    confirmationId,
+    knownTickets,
+    expectedTickets: error.tickets.map((ticket) => ticket.number),
+  });
+  // check.status: 'issued' | 'notCommitted' | 'notFound'
+}
+```
+
+The SDK sends `acceptPriceChanges: false` and `priceQuoteExpirationMethod: 'Quit'` unless you
+pass other values: an automatic issuance never pays a price nobody saw. With a new price, Sabre
+answers `PRICE_MISMATCH`.
+
+There are four outcomes:
+
+| Outcome | What you get | What to do |
+| - | - | - |
+| Issued | `status: 'issued'`, every ticket with `isCommitted: true` | Store `tickets` |
+| Partial | `status: 'partial'`: some tickets, and `PARTIAL_FULFILLMENT` or an error | Store the issued ones and verify before completing |
+| Not issued | `SabreBusinessError` (`PRICE_MISMATCH`, `BOOKING_FULFILLED`…) or `SabreGatewayError` (400, 401, 403, 429) | Fix the cause; nothing was issued |
+| Uncertain | `SabreUncertainOutcomeError`, with `reason`, `confirmationId`, `tickets` and `cause` | Verify with `tickets.verify` before thinking of retrying |
+
+> [!WARNING]
+> **`partial` is not a complete issuance**: some passengers have no ticket. Do not issue again
+> blindly: the tickets that were issued are real, and a second fulfill can give
+> `BOOKING_FULFILLED` or issue twice. Verify first.
+
+- **Uncertain** covers `UNABLE_TO_RETRIEVE_TICKETS`, `FULFILLMENT_NOT_CONFIRMED`,
+  `INTERNAL_SERVER_TIMEOUT` (unless Sabre says no new tickets were issued),
+  `DOWNLINE_SERVICE_ERROR`, `PAYMENT_CARD_ISSUE`, a network failure, a `5xx`, an unreadable body
+  and an abort after the request was sent (`ABORTED`, with the `AbortError` in `cause`). An abort
+  before sending propagates as is.
+- With `reason: 'NOT_COMMITTED'`, `tickets` holds the tickets Sabre returned with
+  `isCommitted: false`. **Those tickets exist**, even if the PNR does not show them yet: do not
+  issue again.
+- PCC configuration errors (commission, printer, Secure Flight) come as `DOWNLINE_SERVICE_ERROR`
+  and are treated as uncertain (CERT).
+- `BOOKING_FULFILLED` means the booking already has tickets, **not** that they are from this
+  issuance: verify.
+
+`sabre.tickets.verify` reads the booking with Get Booking and never issues. It looks at each
+ticket's `ticketStatusCode` (`TE`, `ME` or `TO` are live, `TV` is voided), not at `isTicketed`,
+which stays `true` after a void:
+
+- `issued`: there are new live tickets (outside `knownTickets`), and every `expectedTickets` is
+  there.
+- `notCommitted`: some `expectedTickets` are missing from the PNR (a ghost ticket). They are
+  issued: do not issue again.
+- `notFound`: no new live ticket. **It does not prove nothing was issued**: saving to the PNR can
+  take a while. Wait and verify again, and in production check the day's sales too
+  ([Daily sales](#daily-sales), by `pnrLocator`) before retrying.
+
+With `targetPcc` in `fulfill`, pass the same `targetPcc` to `verify`.
+
+### Voiding
+
+A void goes through `sabre.booking.cancel` with `flightTicketOperation: 'VOID'`. With `cancelAll`
+and `HALT_ON_ERROR`, one call voids the tickets and cancels the booking, and `voidedTickets`
+holds the voided numbers (CERT):
+
+```ts
+const result = await sabre.booking.cancel({
+  confirmationId,
+  cancelAll: true,
+  flightTicketOperation: 'VOID',
+  errorHandlingPolicy: 'HALT_ON_ERROR',
+});
+result.voidedTickets; // ['0060000000001']
+```
+
+- **A void cannot be undone.** A network failure, a `5xx`, an unreadable body, an abort after the
+  request was sent or `END_TRANSACTION_PROBLEM` throw `SabreUncertainOutcomeError`
+  (`operation: 'booking.cancel'`): it is not known whether the tickets were voided. Check with
+  `sabre.tickets.verify` (a voided ticket is `TV`) or `booking.get` before retrying.
+- `VOID` on a booking without tickets throws `NO_ITEMS_CANCELLED` with `UNABLE_TO_VOID_TICKET`
+  and **cancels nothing**. For a booking that was never issued, cancel without `VOID`.
+- A voided sale stays in the day's sales as a `SALE` with `documentStatusCode: 'V'`, and does not
+  count in `totals` (CERT).
+
 ## Choosing a seat
 
 `sabre.air.getSeats` returns the seat map with availability and prices. It is one function
@@ -427,6 +550,44 @@ const { transactions } = await legacy.withSession((session) => session.reservati
   `TypeError` without calling the network. A PNR that does not exist throws a `SabreBusinessError`
   (`service: 'itineraryHistory'`).
 
+### Daily sales
+
+`session.reporting.dailySalesSummary(request?, options?)` reads the day's sales (the DQB
+«Summary», `TKT_TravelAgencyReportsRQ` / `DailySalesSummaryRQ` 1.2.2): one transaction per movement
+of the PCC on that day (sales, refunds, voids, EMDs and MCOs), with no cap, and the day's totals.
+
+```ts
+const report = await legacy.withSession((session) =>
+  session.reporting.dailySalesSummary({ date: '2026-11-12' }),
+);
+// report.status → 'complete' | 'incomplete' | 'deferred'
+// report.transactions[0] → { documentType: 'TKT', transactionCode: 'SALE', documentNumber,
+//                            documentStatusCode, pnrLocator, passengerName, payments,
+//                            transactionDateTime: '2026-11-12T11:02:00.000', … }
+// report.totals → per transaction type, settlement and currency
+```
+
+- **One day per call**, no range. Without `date`, it is the current day, up to a few minutes
+  before the call (production). The filters are `pcc`, `documentType`, `settlementType`,
+  `airline` and `documentNumber`.
+- **Dates and times come as Sabre sends them, without a time zone**: `transactionDateTime` is
+  `'YYYY-MM-DDTHH:MM:SS.sss'`, in the PCC's local time in production. The SDK does not convert
+  them, because it does not know the zone.
+- **Only `status: 'complete'` is the whole day.** `incomplete` means Sabre could not read some
+  documents (`failedDocuments`), so transactions are missing. `deferred` means Sabre cached the
+  report (`deferred.reportId`) or is still running it: ask again later. The SDK does not send
+  `CachedReportRQ`.
+- A void does not add a transaction: the original sale stays as a `SALE` with
+  `documentStatusCode: 'V'`, and does not count in `totals` (CERT).
+- Amounts are strings, as Sabre sends them. **It carries passenger names** (`passengerName`); the
+  SDK never logs them.
+- Another PCC needs Branch Access. Without it Sabre answers `45100`, and the SDK throws
+  `SabreBusinessError` (`service: 'dailySalesSummary'`). A filter with the wrong shape throws a
+  `TypeError` without calling the network.
+- **In CERT the report may have no data**: a PCC that does not issue gets a `complete` report
+  with no transactions. Do not read an empty CERT report as proof of anything.
+- It is a read: it is retried on transport failures, not on business errors.
+
 ### Queues
 
 The queue operations live in `session.queue`. `pcc` is optional in every call and defaults to the
@@ -652,6 +813,13 @@ fake.openSessions; // 0: the session was closed
   `count` with `queue` counts the matches and returns `totals.unfiltered`; with `range` or without
   a queue it gives Sabre's errors. Any other code gets a host error marked as not simulated,
   never the whole queue.
+- `reporting.dailySalesSummary`: `dailySales` seeds the transactions per PCC and date
+  (`{ ABCD: { '2026-11-12': [transactions] } }`, in the shape of `DailySalesTransaction`), or a
+  day with `status: 'incomplete'` or `'deferred'`, or an `errorCode` like `'45100'`. Without
+  `pcc` it uses the session's PCC; without `date`, the day of `now()` in `dailySalesTimeZone`
+  (an IANA zone, `'UTC'` by default). A PCC or day that is not seeded gives an empty `complete`
+  report. The `documentType` filter is simulated, the other filters are not, and `totals` come
+  back empty.
 - **Not simulated**: PCCs (the queues are the same for any `pcc`) and the host's combination rules
   for `selection`.
 - `queueFixtures` holds the anonymized responses recorded in production (`walk`, `emptyQueue`,
@@ -676,6 +844,49 @@ fake.openSessions; // 0: the session was closed
   }));
   ```
 
+#### Bookings and ticketing (REST)
+
+The same `fake.fetch` also answers the REST client (`Sabre`): the token, Create, Get and Cancel
+Booking, and Fulfill Flight Tickets. Pass it in the `Sabre` config to run the issue-and-void flow
+without the network:
+
+```ts
+import { Sabre } from 'sabre-client';
+import { createQueueFake } from 'sabre-client/testing';
+
+const fake = createQueueFake({
+  bookings: { ABCDEF: {} }, // or let booking.create make FAKEAA, FAKEAB…
+  ticketing: { fulfill: [{ downline: 'COMMISSION_REQUIRED' }, 'issued'] },
+});
+const sabre = new Sabre({ ...config, fetch: fake.fetch });
+
+await sabre.tickets.fulfill(request); // SabreUncertainOutcomeError, reason DOWNLINE_SERVICE_ERROR
+await sabre.tickets.fulfill(request); // issued: one TE ticket, shown by booking.get
+await sabre.booking.cancel({ confirmationId: 'ABCDEF', cancelAll: true, flightTicketOperation: 'VOID' });
+await sabre.tickets.verify({ confirmationId: 'ABCDEF' }); // notFound: the ticket is now TV
+```
+
+- `tickets.fulfill` issues one `TE` ticket per booking, which then shows in `booking.get` and
+  `tickets.verify`. A second fulfill on a booking with a live ticket gives `BOOKING_FULFILLED`.
+- `booking.cancel` with `VOID` turns the live tickets into `TV`, returns their numbers in
+  `voidedTickets` and, with `cancelAll`, cancels the booking in the same call. `isTicketed` stays
+  `true`, as in CERT. `VOID` on a booking without tickets gives `NO_ITEMS_CANCELLED` with
+  `UNABLE_TO_VOID_TICKET` and cancels nothing.
+- `ticketing.fulfill` and `ticketing.void` force the next outcomes, in order:
+  - `'issued'` or `'partial'` (`PARTIAL_FULFILLMENT`);
+  - `{ uncertain: reason, issued? }` for every reason of `SabreUncertainOutcomeError`. `issued` says
+    whether the booking really got the ticket, so you can test your verification. With
+    `NOT_COMMITTED` the ticket exists but Get Booking does not show it (a ghost ticket);
+  - `{ downline }` for the four `DOWNLINE_SERVICE_ERROR`s seen in CERT, with their real text:
+    `INVALID_TICKET_STOCK`, `COMMISSION_REQUIRED`, `HARDCOPY_PRINTER` and `SECURE_FLIGHT`;
+  - `{ error, description? }` for any other Fulfill error, such as `PRICE_MISMATCH`;
+  - for the void, `'voided'` or `{ uncertain, voided? }`.
+- `fake.calls` records `token`, `createBooking`, `getBooking`, `cancelBooking` and `fulfill`, with
+  the locator.
+- **Not simulated**: the itinerary, fares and passengers (Get Booking returns a minimal booking),
+  more than one ticket per booking, Void Flight Tickets, and `targetPcc` (any PCC sees the same
+  bookings).
+
 `examples/queue-review.mjs` is a full example, and its test runs it against the fake.
 
 #### Anonymizing recorded responses
@@ -722,6 +933,7 @@ Every error thrown by the SDK extends `SabreError`:
 | `SabreOrchestrationError` | Orchestrated service error inside a `200` (`SP.*`) | `code` |
 | `SabreBusinessError` | Error from a service's own catalog (e.g. `No Availability`, a booking that was not created) | `service`, `code`, `warnings`, `errors` |
 | `SabreSessionError` | SOAP session failure in `SabreLegacy`, a subclass of `SabreGatewayError` | `kind`: `'limit'` (more than 50 sessions), `'invalid'`, `'expired'`, `'blocked'` |
+| `SabreUncertainOutcomeError` | Issuance or void may or may not have happened (`tickets.fulfill`, `booking.cancel` with `VOID`): verify before retrying | `operation`, `confirmationId`, `reason`, `tickets`, `warnings` |
 | `SabreWarning` | Non-fatal warning (e.g. `category: WARNING` in Create Booking) | `service`, `code` |
 
 All of them have `retryable`, which says whether the retry policy may try again.
@@ -750,7 +962,8 @@ try {
 ## Raw response
 
 Every REST operation (`air.bargainFinderMax`, `air.revalidateItinerary`, `air.getSeats`,
-`booking.create`, `booking.get` and `booking.cancel`), and every `SabreLegacy` operation, accepts
+`booking.create`, `booking.get`, `booking.cancel`, `tickets.fulfill` and `tickets.verify`), and
+every `SabreLegacy` operation, accepts
 an `onRawResponse` callback in its
 options, next to `signal`. It receives Sabre's response as it arrived, for example to store it
 next to the typed result. For `air.getSeats`, `operation` names the endpoint that was called
@@ -775,7 +988,8 @@ const booking = await sabre.booking.get({ confirmationId }, { onRawResponse: (r)
   asynchronously, keep the value and write it after the call returns.
 
 In `SabreLegacy`, `protocol` is `'soap'`, `body` is the whole SOAP envelope, and `operation` is
-`'openSession'`, `'close'`, `'ping'`, `'command'` or `'queue.<method>'`. The session token
+`'openSession'`, `'close'`, `'ping'`, `'command'`, `'queue.<method>'`, `'reservation.history'` or
+`'reporting.dailySalesSummary'`. `tickets.verify` reports `'booking.get'`, the Get Booking it runs. The session token
 (`BinarySecurityToken`) is replaced by `[REDACTED]` wherever it appears. Nothing else is changed.
 
 > [!WARNING]
@@ -818,7 +1032,8 @@ await sabre.booking.get({ confirmationId }, { onRawRequest: (r) => (sent = r) })
 ## Retries
 
 Only idempotent operations are retried: Bargain Finder Max and Revalidate Itinerary (both
-are read-only `POST`s). Create Booking is never retried. Retries use exponential backoff with
+are read-only `POST`s), plus Get Booking and `tickets.verify`. Create Booking, Cancel Booking and
+`tickets.fulfill` are never retried. Retries use exponential backoff with
 full jitter and a 500 ms floor, on `429`, `500`, `503`, `504`, `SP.PROVIDER_ERROR` and the
 temporary errors in the Bargain Finder Max catalog.