/* Clases compartidas por los circuitos EXTERNO (módulo Compras) e INTERNO (módulo Abastecimiento).
   Son tres reglas de presentación de líneas y totales; se mantienen acá en vez de duplicarse en un
   abastecimiento.css. Registrado en WebApp/Pages/_Host.cshtml. */

/* Compras: los vc-CRUD del módulo (Proveedores, Percepciones) reutilizan
   íntegramente verticalcrudlayout.css. */

/* Orden de Compra: grilla de líneas (MudSimpleTable) — alineación derecha de columnas
   numéricas (Cantidad, Precio unitario, Subtotal) sin recurrir a inline styles.

   `.oc-lineas-num` la pone el `Class` de un CustomMudNumericField, o sea que aterriza en el wrapper
   `.mud-input-control` y no en el `<input>`. El descendiente `input` es la ÚNICA regla del documento que
   toca el `text-align` de ese slot —verificado sobre el CSS de MudBlazor 9.10.0 preguntándole al navegador
   qué reglas matchean—, así que gana sin pelear con nadie. */
.oc-lineas-num input {
    text-align: right;
}

/* `.oc-right-align` va sobre el <th> o el <td> mismo, y ahí sí hay con quién pelear. El paquete declara:

       .mud-simple-table table * tr>td { text-align: start }   → (0,1,3)
       .mud-simple-table table * tr th { text-align: start }   → (0,1,3)

   contra los (0,1,0) de una clase pelada. El paquete gana, y gana sin importar el orden de las hojas: la
   especificidad se resuelve antes que la cascada. O sea que desde que nació (019b250a, 2026-07-15) y hasta
   el 2026-09-17 esta clase fue INERTE en sus 144 sitios — 51 cabeceras y 93 celdas, en 10 componentes de
   Compras y Abastecimiento.

   No se notó en las grillas EDITABLES porque ahí la cifra vive dentro de un input y la salva la regla de
   arriba; quedó a la vista justo donde no hay input, y así se reportó: el histórico de «Recepciones
   anteriores» del diálogo de remito, con el número «descolgado en el medio del renglón». No estaba
   desalineado — estaba alineado a la izquierda de una columna de 282px, con 250px de aire a la derecha.
   Mismo defecto, y sin reportar, en los `<th>` de todas esas tablas: la cabecera a la izquierda mientras su
   propio input iba a la derecha.

   El remedio califica el selector con el contexto del paquete en vez de ponerle `!important`: (0,2,3) le
   gana a (0,1,3) y deja abierta la puerta a que un sitio puntual lo sobreescriba, que es lo que un
   `!important` cierra. Es el mismo idioma —y la misma cuenta de especificidad— que datagrid.css ya hacía
   para MudDataGrid con `grid-cell-right`/`grid-header-right`. Que ese archivo la hiciera y este no es el
   patrón que las auditorías de este repo encuentran una y otra vez: la regla resuelta de un lado y no
   cruzada al gemelo.

   Los DOS selectores hacen falta: el del paquete usa `>td` para las celdas y ` th` (descendiente, sin `>`)
   para las cabeceras, y un selector que no espeje esa forma no matchea.

   Y esto es lo que hace que las tablas hermanas de un mismo diálogo se alineen ENTRE SÍ sin recurrir a
   `vc-section-grid`: toda tabla de MudBlazor es `width: 100%`, así que su última columna termina contra el
   mismo borde derecho. Medido con el fix puesto: el `<th>` de «Recibido ahora» de la tabla de líneas, la
   cabecera del histórico y las cifras de dos entregas distintas —una con descripción de 60 caracteres y
   número de 9 dígitos— caen las cuatro en la misma vertical, y `scrollWidth - clientWidth` da 0 en las tres
   tablas. Por eso acá NO se declaran anchos: un ancho fijo traería `table-layout: fixed` y con él la barra
   de scroll horizontal que la «regla de oro» de verticalcrudlayout.css advierte. */
.mud-simple-table table * tr > td.oc-right-align,
.mud-simple-table table * tr th.oc-right-align {
    text-align: right;
}

/* Tope de ancho para los tooltips de "motivo" de las listas de los DOS circuitos: el motivo por el que una
   orden interna no se puede cancelar (OrdenAbastecimientoLista) y el motivo de anulación de un comprobante
   (ComprobanteCompraLista). Los dos son textos largos —143/146 caracteres los que devuelve
   CancelacionOrdenAbastecimientoHelper, hasta 500 el que tipea el usuario al anular— y `.mud-tooltip` del
   paquete NO trae `max-width`, así que sin este tope el popover se arma como UNA sola línea de media pantalla.

   Pero el tope no está acá por estética. El ancho de un popover `position:absolute` es shrink-to-fit, o sea
   que sin `max-width` lo decide el `left` que MudBlazor le acabe de poner — y eso realimenta la posición con
   el tamaño. Con el `max-width` puesto y el placement correcto (`Placement.Left`, en los dos .razor), el ancho
   pasa a ser independiente de la posición y el bucle no arranca. Las DOS cosas hacen falta: el tope solo, con
   el placement por default, EMPEORA el cuadro. El detalle medido está en MovimientoTesoreria.razor, que es
   donde se diagnosticó; su gemelo de esa hoja es .tes-tooltip-motivo, en tesoreria.css.

   Se aplica por `TooltipContent` (un div propio) y no por el `Class` de MudTooltip: ver el comentario allá. */
.compras-tooltip-motivo {
    max-width: 360px;
}

/* Orden de Compra: la fila de líneas que el guardado rechazó. Antes el único aviso era una alerta arriba de
   la grilla que describía la regla sin señalar la fila, y con varias líneas cargadas eso obliga a revisarlas
   a ojo una por una — se reportó exactamente así.

   El tinte sale de la paleta con opacidad y no de un hex, igual que .rem-datos de más abajo: la app alterna
   tema claro y oscuro en vivo, y un rojo fijo se vuelve ilegible en uno de los dos.

   Va sobre el `td` y no sobre el `tr`: la grilla declara Hover, y MudBlazor pinta ese fondo en las celdas, de
   modo que un fondo puesto en la fila queda tapado justo cuando el usuario pasa el mouse por la fila que
   tiene que corregir. Con `!important` por lo mismo — la regla de hover de MudBlazor gana por especificidad.

   El tinte NO es el único aviso: la columna de acciones lleva un ícono con el detalle de lo que falta. Un
   color solo deja afuera a quien no lo distingue. */
.oc-linea-error td {
    background-color: rgba(var(--mud-palette-error-rgb), 0.10) !important;
}

/* Columna «Origen» de la grilla de líneas: las pastillas del origen APILADAS, nunca en fila.
   Una línea de artículo lleva dos —«OC #11» y «Remito #56»— y `.vc-col-tag` mide 9rem fijos
   (verticalcrudlayout.css): lado a lado no entran, y lo que no entra le pone scroll horizontal a las TRES
   listas del documento, no sólo a esta celda. Dejarlo al wrap natural tampoco sirve: con números de una cifra
   las dos pastillas entrarían en un renglón y con números de cuatro no, o sea que la misma columna cambiaría
   de forma según el documento que se esté mirando.

   El margen del chip se anula desde acá porque MudBlazor lo declara en `.mud-chip` (0,1,0) y este selector es
   (0,2,0): una clase pelada sobre el propio chip perdería. El `gap` reemplaza ese margen con uno simétrico. */
.oc-origen {
    display: flex;
    flex-direction: column;
    align-items: flex-start;
    gap: 2px;
}

.oc-origen .mud-chip {
    margin: 0;
}

/* `.oc-total-nota` vivía acá y se borró el 2026-09-05, junto con sus dos únicos usos. Atenuaba la fila
   "Conceptos" del panel de Totales para que no se leyera como un sumando. Se sacó a pedido: la fila tiene que
   verse con el mismo color sólido que las demás, y lo que la distingue es su etiqueta —"Conceptos (ya
   incluidos)"—, que es la aclaración que antes vivía en el color y en un tooltip. Si alguna vez vuelve a
   hacer falta atenuar una fila informativa de un cuadro de totales, la nota está en el comentario de esa
   fila en ComprobanteCompraCRUD, que registra las idas y vueltas completas. */

/* Chip de estado financiero que además es un atajo (ver OrdenCompraEstadoChipHelper.OfreceFacturar). El
   cursor va en el <span> envolvente y no en el MudChip: ese span es el que existe para frenar la
   propagación del click hacia el RowClick de la grilla, así que es también el que tiene que verse
   clickeable — poner el cursor en el chip dejaría un borde muerto alrededor. */
.oc-chip-accion {
    cursor: pointer;
    display: inline-flex;
}

/* ── Diálogo de Remito: la zona de datos de cada línea ─────────

   El diálogo pide UN dato por artículo —cuánto llegó— y todo lo demás es contexto. Antes no se leía así:
   el "Recibido ahora" era un input de variante Text (sólo una línea inferior, sin caja) y las tres cifras
   compartían peso con la descripción del artículo, así que el ojo tenía que buscar dónde escribir en vez de
   caer ahí solo.

   `rem-datos` tinta las dos celdas numéricas de la fila. Es la alternativa a meter un panel dentro del <td>:
   un contenedor anidado pelea con la grilla de la tabla —bordes dobles, alturas que no acompañan— mientras
   que la banda de color aísla la zona igual y no agrega una caja más. El tinte sale de la paleta con
   opacidad, no de un hex, así acompaña el tema claro y el oscuro (que en esta app se alternan en vivo).

   `rem-num` es el peso de las cifras que el operador compara entre sí (pendiente, recibido, histórico). No
   lleva color propio a propósito: el contraste ya lo da el `rem-desc` de al lado, que ATENÚA la descripción.
   Subir las dos puntas dejaría la fila entera gritando y ninguna jerarquía. */

.rem-datos {
    background-color: rgba(var(--mud-palette-primary-rgb), 0.06);
}

.rem-num {
    font-weight: 600;
    font-variant-numeric: tabular-nums;
}

.rem-desc {
    color: var(--mud-palette-text-secondary);
}