Desarrollo Laravel en Valencia para exportadores y mayoristas

Un mayorista de Valencia le pide al backend algo que el comercio electrónico de consumo nunca pide: dile a este cliente concreto cuánto cuesta este producto concreto, bajo unas condiciones que alguien negoció hace dos años, y sé capaz de justificar la cifra después.

Quien compra son exportadores, productores agroalimentarios y distribuidores industriales. Su complejidad no es el tráfico ni el tamaño del catálogo, es que casi nada en una línea de pedido es un valor guardado. El precio se deriva, la disponibilidad se deriva, el tratamiento fiscal depende de a dónde va la mercancía, y todo ello tiene que seguir teniendo sentido impreso en un documento con peso legal.

El precio en Valencia es una cadena de reglas, no una columna

La primera decisión de diseño en estos sistemas es el orden de prelación, y es una decisión comercial disfrazada de técnica.

Un cliente está en una tarifa. La tarifa tiene saltos por volumen. Una promoción puede ganar al salto. Un contrato marco puede ganar a la promoción. La moneda y los incoterms se aplican sobre el resultado. Invierte dos de esos pasos y sale una cifra que nadie puede defender.

Así que la cadena se escribe, se prueba contra los ejemplos sobre los que el equipo comercial ya discute y - esta es la parte que se salta - el precio resuelto se guarda en la línea del pedido junto con la identidad de la regla que lo produjo. Un sistema que recalcula precios históricos con las reglas de hoy no puede explicar una factura antigua, y en B2B esa conversación ocurre.

Dinero y fechas son las decisiones que no se deshacen es la lectura de fondo, y la parte de los céntimos enteros importa aquí más que en casi cualquier otro sitio, porque una diferencia de redondeo en un salto por volumen se multiplica por palé.

Doscientas líneas, dos mil consultas de Laravel

El problema de rendimiento de un sistema mayorista casi nunca es el catálogo. Es el pedido.

Un presupuesto de doscientas líneas, donde cada línea busca por su cuenta el cliente, su tarifa, el salto aplicable y la posición de stock, produce miles de consultas para una sola página. Es invisible con diez líneas y doloroso con doscientas, y por eso llega a producción. Es el clásico patrón N+1 con disfraz comercial, y resolver el pedido entero en unas pocas consultas en vez de línea a línea suele ser la mayor mejora disponible.

El stock disponible en Valencia es una resta, y la resta compite

Tres almacenes y un palé es donde estos sistemas pierden dinero.

Disponible es lo que hay menos lo reservado, por ubicación, y el fallo vive en la reserva. Si la aplicación comprueba la disponibilidad y luego la descuenta en una sentencia aparte, dos pedidos simultáneos pasan los dos la comprobación y los dos se confirman. El síntoma que ve el cliente es un pedido confirmado que no se puede servir, y eso cuesta más que cualquier problema de velocidad.

La forma fiable es una sentencia atómica que descuenta de forma condicional y deja que la base de datos rechace el segundo intento, con la aplicación reaccionando al rechazo en vez de intentando evitarlo. El optimismo en el código no sobrevive a la concurrencia; una restricción sí.

Un pedido de exportación de Valencia necesita sus documentos, no solo sus líneas

Un pedido nacional se expide contra una hoja de picking. Un pedido de exportación se expide contra un juego de documentos, y ese juego forma parte del pedido en lugar de ser algo que alguien produce después con una plantilla.

La factura comercial, la lista de contenido, el certificado de origen cuando se exige, un certificado fitosanitario o sanitario para mercancía agrícola, y lo que el destino haya añadido a la lista este año. Cada uno se genera desde el pedido y cada uno tiene campos que el pedido no contiene de forma natural - códigos arancelarios por línea, pesos neto y bruto, número de bultos, el país de origen de la mercancía y no del vendedor.

Lo que significa que esos campos pertenecen al producto y a la línea de pedido desde el principio. Añadir un código arancelario a un catálogo de cuatro mil productos después del primer rechazo en aduana es una semana de la vida de alguien, y el propio rechazo tiene un contenedor parado en algún sitio.

Los incoterms deciden quién responde de qué y por tanto qué tiene que decir la factura y qué cargos aparecen en ella. El término pertenece al pedido, no a la ficha del cliente como un valor por omisión que puede no aplicarse a este envío, y los cargos que se derivan de él se calculan en lugar de teclearse. Un término que implica que el vendedor paga flete y seguro, con esos cargos ausentes de la factura, es una discrepancia que un banco encontrará si el envío va contra un crédito documentario.

Laravel y los códigos de producto del propio cliente de Valencia

Un cliente mayorista pide con sus códigos, no con los tuyos. Su pedido llega con sus referencias, sus descripciones, sus unidades, y emparejarlos con el catálogo es trabajo que debería hacer el sistema y no una persona.

Así que existe una tabla de equivalencias por cliente - su código, su descripción, su unidad de medida, asociados al producto y a la conversión. Una vez que es una tabla, un pedido entrante se puede emparejar automáticamente, y las líneas sin coincidencia se presentan para que alguien decida en lugar de rechazar el pedido entero. Esas líneas son la salida útil - suelen ser un producto nuevo, uno descatalogado o una errata, y las tres quieren a una persona por un momento.

Los códigos de barras del cliente van en el mismo sitio. Un GTIN a nivel de unidad de consumo, otro distinto a nivel de caja, y un cliente que etiqueta palés con su propio esquema. El escaneo tiene que resolver cualquiera de ellos al mismo producto, y el número de dígitos no es un discriminador fiable, así que cada identificador se guarda con su tipo en lugar de deducirse.

Sus códigos también tienen que salir. Un aviso de expedición, una factura, una etiqueta en una caja - si va al cliente debería llevar su referencia junto a la tuya, porque su almacén recibe contra sus propios números y una entrega que no pueden dar de alta es una entrega que espera. Eso es la misma tabla de equivalencias leída en el otro sentido, que es el argumento para construirla como datos y no como lógica de importación.

En lo comercial

El alcance se fija por escrito antes de empezar y se presupuesta por proyecto. El marco de España - software de facturación certificado, reglas fiscales territoriales, requisitos del sector público - está en la página de mercado de España.

Factura la Codefacture Yazılım A.Ş. en Türkiye, en euros, por transferencia, sin IVA turco bajo la exención de servicios exportados.