Presupuestos y albaranes
Integración con a3ERP
La app no se conecta nunca con a3ERP ni con a3FACTURA. Lo que hace es crear los presupuestos, los albaranes y sus líneas en FileMaker y, después, llamar a un guion de la solución, que es quien numera el documento y lo envía al ERP. Por eso, cuando un albarán hecho desde el móvil no llega a a3ERP, el problema casi nunca está en el dispositivo: está en el guion, en la conexión de FileMaker con el ERP o en los datos del documento.
La integración se activa por empresa, en EMPRESAS:
| Campo | Efecto en la app |
|---|---|
SYNC_A3ERP_CONECTA |
La empresa trabaja con a3ERP |
CONECTA_A3FACTURA |
La empresa trabaja con a3FACTURA |
Si los dos están a 0, la app no muestra «Servir a albarán» en los partes y no envía nada a ningún ERP. Los albaranes de presupuestos y certificaciones se siguen creando en FileMaker.
Servir un parte a albarán#
«Servir a albarán» aparece en la sección de facturación del parte cuando se cumplen todas estas condiciones:
- el parte no está en el estado final de la empresa (
ID_ESTADO_PARTE_FINAL_DEFAULT); - no hay ningún servicio en marcha;
- el parte tiene conceptos facturables;
- el perfil tiene
MODIFICAR_APPyMOSTRAR_BOTON_SERVIR_ALBARANa1; - la empresa tiene activado a3ERP o a3FACTURA.
Antes de servir, la app pide confirmar el documento de pago, la descripción del trabajo y las anotaciones. Propone el documento de pago del cliente o, si el cliente no tiene, el primero de la empresa. Si el perfil exige firma al salir (REQUIERE_FIRMA_OUT en la sección Marcaje) y el parte no está firmado, avisa «Es necesaria la firma» y no deja continuar.
Al servir, la app:
- Guarda la descripción del trabajo y las observaciones internas del parte.
- Crea la cabecera en
PRESUPUESTOS_ALBARANES, conTIPO_DOCUMENTO=ALBARANyESTADOyESTADO_ALBARAN=Pendiente. La serie y la actividad son las del parte, la referencia es la de la tarea, y las notas resumen la tarea y el parte. La forma de pago es la del cliente. - Crea una línea en
DETALLES_PRESUPUESTOpor cada concepto marcado para servir y que todavía no está servido, y marca el concepto como servido con el id del albarán. - Numera el albarán con el guion
API_GuardarPresupuesto. - Lo envía al ERP con el guion
API_guardarDocumentoPresupuestoAlbaran. Ver El envío al ERP. - Si con esto quedan servidos todos los conceptos, marca el parte como servido, le pone el estado final de la empresa y da por finalizada la planificación del día del parte.
Si no hay ningún concepto marcado para servir, la app avisa con «No hay artículos marcados para servir.» y no crea nada. Si alguna línea no se puede crear, su concepto no se marca como servido, el parte no se da por servido y la app avisa con «Se ha generado el albarán, pero algunas líneas no se han podido crear.». En ese caso el albarán ya existe, numerado y enviado, con las líneas que sí se crearon: los conceptos que faltan se pueden servir en otro albarán.
Sin conexión, la app deja en cola el albarán completo, con sus líneas, y avisa con «Sin conexión: el albarán se enviará al servidor cuando se establezca.». Al sincronizar se crea, se numera y se envía.
Servir un presupuesto a albarán#
Desde la ficha de un presupuesto, «Servir» exige que el presupuesto esté en estado Aceptado y firmado (FIRMADO = 1). Si no lo está, la app avisa «Para generar el albarán, el presupuesto debe estar aceptado y firmado». El diálogo previo deja revisar el cliente y el documento de pago.
La app sirve lo que queda pendiente de cada línea, es decir, sus unidades menos las ya servidas, y se salta las líneas que no tienen nada pendiente. Así, un presupuesto que ya se ha certificado en parte solo sirve el resto. Si no queda nada pendiente, avisa «No quedan unidades pendientes de servir en este presupuesto.» y no crea el albarán.
El albarán copia del presupuesto el cliente con sus datos, el documento de pago, la referencia, que es el código del presupuesto, y el enlace al presupuesto de origen (ID_PRESUPUESTO_ORIGEN). La serie y la actividad son las de presupuestos de la empresa. No copia la forma de pago, la tarifa ni el cliente de facturación, aunque en el diálogo previo se pueda cambiar este último.
El presupuesto se marca como servido antes de crear las líneas
La app pone el presupuesto como servido nada más crear la cabecera del albarán. Si después falla alguna línea, la app lo dice («Se ha generado el albarán, pero no se han podido crear estas líneas:», con sus descripciones) y esas líneas del presupuesto quedan pendientes, pero el presupuesto ya figura como servido y la app no vuelve a ofrecer «Servir». Las líneas que faltan hay que completarlas a mano en el albarán.
Certificaciones#
Certificar un presupuesto genera un albarán con una parte de cada línea, en unidades o, si la empresa tiene CERTIFICACIONES_SERVIR_ALBARAN_UNIDADES_PORCENTAJE a 1, en porcentaje. La app no exige que el presupuesto esté aceptado ni firmado. Si se certifica más de lo pendiente, avisa pero deja continuar.
Cada línea del albarán lleva las unidades certificadas, las de certificaciones anteriores del mismo presupuesto (UNIDADES_ANTERIOR) y el acumulado (UNIDADES_ACUMULADO). En la línea del presupuesto suma lo certificado a UNIDADES_SERVIDAS_A_ALBARAN, y el presupuesto queda servido cuando ya no queda nada pendiente.
Al terminar llama, por este orden, a API_GuardarPresupuesto, a API_guardarDocumentoPresupuestoAlbaran, solo si la empresa tiene la integración activada, y a numeroAlbaranesPorLineaDesdePresupuestos, que enlaza cada línea con su albarán. Sin conexión, la certificación se queda en cola y se envía al sincronizar.
El envío al ERP#
El guion API_guardarDocumentoPresupuestoAlbaran recibe el id del documento, la empresa, si se envía a a3ERP (conectaA3FERP) o a a3FACTURA (conectaA3FACTURA), el tipo de documento y crearFactura. La app solo lo llama si la empresa tiene la integración activada: al servir un parte o un presupuesto, al certificar y al pulsar «Guardar» en la ficha de un presupuesto o un albarán que no esté servido ni facturado. «Guardar» lo vuelve a enviar aunque ya conste como enviado.
La app no comprueba si el envío ha ido bien
El guion devuelve el resultado del envío, o KO si no encuentra el documento, pero la app no lo mira: para el usuario, el albarán siempre se ha generado bien. Si un albarán no aparece en a3ERP, lo que hay que mirar es su estado en FileMaker o en la propia ficha del albarán en la app.
El estado lo escribe FileMaker y la app lo muestra en el apartado «Estado albarán» de la ficha:
ESTADO_ALBARAN |
Significado en la app |
|---|---|
Pendiente |
Creado en FileMaker y todavía sin enviar al ERP |
Enviado |
Enviado al ERP |
Facturado |
Facturado en el ERP. La app lo muestra en solo lectura |
Si FileMaker ha guardado un error en el campo ERROR del documento, la app muestra ese error en lugar del estado, con un icono de aviso.
El envío puede tardar varios segundos. Si tarda más de 8, la app repite la llamada y el guion se ejecuta dos veces. Ver Tiempos de espera y reintentos.
La app no genera facturas#
La app siempre sirve a albarán. El ajuste «Servir Partes a Albarán o Factura» del perfil (CREAR_FACTURA_ALBARAN_APP) se lee y se ignora: la app envía siempre crearFactura = 0. Aunque se enviara un 1, en el guion actual el paso que lo comprobaría va después de la salida del guion y no se llega a ejecutar, así que tampoco se facturaría.
Traspaso de stock#
Cuando un parte consume material, la app pide a FileMaker que mueva ese stock del almacén de origen al de obra en curso, con el guion API_AlbaranTraspasoMaterial de la presentación API_PARTES. Lo hace si la empresa tiene activado el control de stock (SYNC_CONTROL_STOCK) o la conexión con a3ERP, y solo para artículos con CONTROL_STOCK = 1.
Se lanza al añadir un material al parte con conexión, al cambiar sus unidades o sus almacenes, y al borrarlo, en este caso para deshacer el traspaso.
| Almacén | De dónde sale |
|---|---|
| Origen | El que ya tenga el material. Si no tiene, depende de SYNC_TIPO_CONTROL_STOCK, como se detalla debajo |
| Destino | El ID_ALMACEN_ENCURSO del proyecto o, si no lo tiene, el ID_ALMACEN_EN_CURSO de la empresa |
El almacén de origen sigue la misma regla que el traspaso de s360 escritorio. La persona y el activo son los del primer servicio del parte por orden de alta, que la app pide al servidor entre todos los servicios del parte, también los de otras personas y aunque el perfil tenga «ver solo los suyos»:
SYNC_TIPO_CONTROL_STOCK |
Almacén de origen, si el material no tiene |
|---|---|
| Almacén por Proyecto | El ID_ALMACEN_ORIGEN del proyecto o, si no lo tiene, el ID_ALMACEN_ORIGEN de la empresa |
| Almacén por Operario y Proyecto | El almacén de la persona. Si no tiene, el del proyecto o el de la empresa |
| Almacén por Activo y Proyecto | El almacén del activo. Si no tiene, el del proyecto o el de la empresa |
| Cualquier otro valor | Ninguno: sin almacén en el material, no hay traspaso |
Si un traspaso sale de un almacén inesperado, lo primero es mirar el ID_ALMACEN_ORIGEN que quedó en el material, porque el que ya tiene el material siempre manda.
Hay tres límites más que conviene conocer:
- Sin conexión no hay traspaso. El material se guarda con el almacén de origen por defecto y no se traspasa ni al sincronizar.
- La app no comprueba la respuesta del guion. Si el traspaso falla, el usuario no se entera.
- Si no se puede determinar uno de los almacenes, la app no llama al guion y no avisa.
Precios desde a3ERP#
Al añadir artículos a un presupuesto o a la facturación de un parte o una tarea, la app pide el precio y el descuento al guion API_getPriceFromA3ERP, que es quien decide si los consulta en a3ERP.