Compare commits

...
3 Commits
Author SHA1 Message Date
dot.gcalleandClaude Opus 5.5 e343a18da1 CLAUDE.md: nuevo remoto en Gitea y tags SemVer por release
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-20 16:30:49 -03:00
dot.gcalleandClaude Opus 5.5 29dcc8ccef README: cómo generar un release
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-20 16:29:40 -03:00
dot.gcalleandClaude Opus 5.5 7efdcce113 Agregar README.md
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-20 16:29:12 -03:00
2 changed files with 105 additions and 5 deletions

No files matched your search

+5 -5
View File
@@ -92,6 +92,11 @@ Pasos de la UI (decididos):
`npm run publicar`, que deja `app/version.json` (número, fecha y commit). La API lo lee al arrancar
(`src/version.ts`), lo informa en `/auth/info` y `/auth/me`, y la web lo muestra en el login y en la barra
superior (en desarrollo dice "desarrollo").
- **Repositorio**: Gitea, remoto `origin` = `https://unasgeorge.vaquita-hadar.ts.net/george/devolucion_proveedores.git`
(rama `main`; reemplaza al anterior `http://100.68.242.27:30000/...`). Cada release lleva un **tag SemVer
anotado `vX.Y.Z`** igual al `version` del `package.json` (`git tag -a vX.Y.Z` + `git push origin main --tags`),
hecho **antes** de `npm run publicar` para que `version.json` lleve el commit correcto. El primero es
`v2.0.1`. El procedimiento para el usuario está en `README.md` ("Generar un release").
- **Logs**: la aplicación **no escribe logs a archivo**; usa el `Logger` de Nest por consola. En
producción NSSM captura la salida y la rota a los 10 MB (no limita cuántos archivos conserva: hay que
limpiar los viejos). Con `NO_COLOR=1` el log sale sin códigos de
@@ -301,11 +306,6 @@ Reglas:
la cookie de sesión en un navegador real sobre HTTPS.
- **`OpenInvQty`** (2026-10-13): la consulta `DP_EntradasAbiertas` v3 todavía no se ha ejecutado contra el
Service Layer de HANA. Se prueba con *Rehacer FIFO* de la planificación 7 de `SBOTSTLIBROS`.
- **Versión del release** (2026-10-15): release **1.1.0** generado en el servidor Windows de pruebas (Excel,
valores por defecto de la cabecera, versión visible). Lleva "(sin git)": **git no está instalado en ese
servidor**, aunque la carpeta es un repositorio con commits y remoto `origin`
(`http://100.68.242.27:30000/george/devolucion_proveedores.git`). Los cambios del 2026-10-15 **no están en
ningún commit**: hacerlo (y `push`) cuando haya git, antes de seguir trabajando desde el Mac.
- **Estilos:** son CSS porque, en el Mac con macOS 12, el compilador nativo de Sass exige
macOS 14 o superior. En Sequoia se puede volver a SCSS si se prefiere.
+100
View File
@@ -0,0 +1,100 @@
# Devolución a Proveedores
Aplicación web (Angular + NestJS) para SAP Business One que genera **Devoluciones de mercancías**
(ORPD) enlazadas a sus **Entradas de mercancías por compra** (OPDN), a partir de un listado de
artículos y cantidades pegado desde Excel. Reemplaza al addon .NET anterior.
## Cómo funciona
1. **Pegar**: ItemCode + cantidad desde Excel. Se valida contra la **Consignación** del almacén elegido.
2. **Procesar**: asignación FIFO contra las líneas abiertas de Entradas de mercancías del almacén,
ordenadas por fecha. El usuario marca qué líneas devolver.
3. **Crear devoluciones**: agrupa las líneas marcadas por proveedor y crea una Devolución por lote
(11 líneas por defecto).
4. **Descargar PDF**: pide al web service de BES el PDF de la Guía de despacho (DTE 52) de cada
Devolución, con opción de unirlos en uno.
Cada ejecución (planificación) se guarda en el UDO `LIB_ODEV`. Solo puede haber una planificación
abierta a la vez; se cierra a mano.
## Requisitos
- Node.js 22 LTS o superior.
- SAP Business One con **Service Layer** (`/b1s/v1`), base **HANA** (producción) o **MSSQL** (pruebas).
- El usuario de SAP inicia sesión en la web; sus credenciales no se guardan en la configuración.
## Estructura
```
libs/shared/ @dp/shared tipos y lógica de dominio (parseo de Excel, FIFO)
apps/api/ NestJS API REST (/api) sobre el Service Layer; en producción sirve también la web
apps/web/ Angular interfaz
scripts/ publicar.mjs arma la carpeta de despliegue en release/
deploy/windows/ instalación como servicio de Windows (NSSM)
```
## Puesta en marcha (desarrollo)
```sh
npm install
cp apps/api/.env.example apps/api/.env # completar SL_URL, SL_COMPANY_DB y DB_TYPE
npm run dev:api # API NestJS (puerto PORT del .env)
npm run dev:web # Angular en http://localhost:4215 (proxy /api → API)
```
Variables principales del `.env`: `PORT`, `SL_URL`, `SL_COMPANY_DB`, `SL_REJECT_UNAUTHORIZED`,
`DB_TYPE` (`HANA`/`MSSQL`) y `COOKIE_SECURE`. Para producción con HTTPS: `HTTPS_PFX_PATH` y
`HTTPS_PFX_PASSPHRASE` (o `HTTPS_KEY_PATH`/`HTTPS_CERT_PATH`) y `HTTP_REDIRECT_PORT`.
Ver `apps/api/.env.example`.
En el primer ingreso, **Configuración → Metadatos → Reconstruir** crea las tablas, los campos y
el UDO necesarios en SAP.
## Pruebas y compilación
```sh
npm test # shared + api + web
npm run test:e2e -w api
npm run lint -w api
npm run build
```
## Generar un release
La versión es el `version` del `package.json` raíz y sigue SemVer (`MAYOR.MENOR.PARCHE`). Cada
release sube la versión y lleva un tag `vX.Y.Z` en git.
1. **Subir la versión** (elegir uno; no crea commit ni tag):
```sh
npm run version:parche # 2.0.1 → 2.0.2 correcciones
npm run version:menor # 2.0.1 → 2.1.0 funciones nuevas compatibles
npm run version:mayor # 2.0.1 → 3.0.0 cambios incompatibles
```
2. **Commit y tag**:
```sh
git add -A
git commit -m "Versión X.Y.Z"
git tag -a vX.Y.Z -m "Versión X.Y.Z"
git push origin main --tags
```
3. **Armar la carpeta de despliegue** (después del commit, para que el release lleve el commit
correcto):
```sh
npm run publicar # compila shared + api + web y arma la carpeta
npm run publicar -- --sin-build # reutiliza los builds ya hechos (más rápido)
```
El resultado queda en `release/devolucion-proveedores/` (ignorada por git): la API compilada,
la web compilada, solo las dependencias de producción y los scripts de instalación. Incluye
`app/version.json` con el número, la fecha y el commit (si hay cambios sin commit, el commit
aparece con `-modificado`). La versión se muestra en el login y en la barra superior.
4. **Instalar o actualizar en el servidor**: copiar esa carpeta al servidor Windows. Se instala
como un único servicio (NSSM) con HTTPS directo en Node. Instalación nueva: secciones 1 a 8 de
[`deploy/windows/DEPLOY.md`](deploy/windows/DEPLOY.md); actualizar una instalación existente
sin tocar el `.env`: sección 11.