Pedidos abiertos

• Planta venta (campo SALFCY)

La planta de venta se inicializa con la planta de venta asociada al perfil función del usuario. La planta de venta se puede modificar (si aún no se ha introducido ninguna línea en el documento) por otra procedente de la lista de plantas de venta autorizadas para el usuario.

• Tipo (campo SOHTYP)

El tipo de pedido permite determinar:

• la categoría del pedido: solo se puede seleccionar el tipo Pedido abierto.
• el contador utilizado: si el contador es manual, solo se puede introducir el número de pedido.

Solo se puede indicar un tipo de pedido cuya legislación y grupo de sociedades sean coherentes con los de la sociedad de la planta de venta.

• N.º pedido (campo SOHNUM)

Este número permite identificar la factura de forma única. Este número se asigna automáticamente o se introduce en cada creación de pedido, según la parametrización del contador asociado al tipo de pedido elegido.

Si el contador de pedido está definido con asignación automática, el número de pedido no está disponible y el contador se asigna en la creación del pedido. Por el contrario, si el contador de pedido está definido con asignación manual, se puede introducir manualmente. Si no se introduce en la creación, el sistema asigna automáticamente un número de pedido en función del contador.

• campo REVNUM

Es el último número de revisión establecido para este pedido abierto. Se incrementa automáticamente con cada modificación del contrato si el parámetro >SALREV (gestión de revisiones) está posicionado en "Sí y si el usuario confirma que su modificación es objeto de una revisión.

• Referencia (campo CUSORDREF)

Esta información permite indicar la referencia del pedido en el cliente. En un pedido de venta intersociedad o interplanta generado a partir de un pedido de compra del mismo tipo, el número del pedido de compra se introduce en este campo y se puede acceder por túnel al pedido de compra de la planta del cliente.

• Fecha (campo ORDDAT)

La fecha de solicitud de compra se inicializa con la fecha del día y se puede modificar (solo en creación). La modificación de esta fecha en curso de creación desencadena un mensaje que propone volver a actualizar los precios y los posibles descuentos calculados en las líneas de pedido que ya se han introducido. Esta modificación también conlleva la actualización de la fecha de recepción prevista en las líneas de pedido que no han consumido ninguna necesidad.

• Cliente pdo (campo BPCORD)

Este campo indica el código de identificación del cliente. 

• Cliente facturado (campo BPCINV)

Es el código del cliente al que se va a facturar, inicializado por defecto con el propio código del cliente.
Este cliente se puede modificar por cualquier otro de la tabla de clientes.

Puedes buscar uno o varios clientes con un mismo criterio seleccionando "Búsqueda cliente rápida". Al tabular en el siguiente campo, se genera una lista de correspondencias.
Para una búsqueda más específica, se pueden completar todos los campos del bloque. La lista de correspondencias se reduce con cada tabulación.

• Cliente pagador (campo BPCPYR)

Este campo permite indicar el código del cliente pagador, inicializado por defecto con el código del cliente introducido en la cabecera. La programación de facturas estará asignada a este tercero.
Este cliente se puede cambiar por otro de latabla de clientes.

• Cliente grupo (campo BPCGRU)

Cliente grupo se inicia por defecto con el código de cliente grupo asociado al cliente pedido en la ficha de este último. Esta información es especialmente útil para establecer estadísticas. Interrviene también en el reagrupamiento de las facturas en el momento de la generación automática de las mismas. Existe la posibilidad de modificar el cliente grupo si es necesario. Desde este campo se puede seleccionar un cliente o acceder por túnel a la gestión de clientes si las habilitaciones del usuario se lo permiten.

• Interplanta (campo BETFCY)

Esta información no se puede modificar y especifica si el pedido abierto es de tipo interplanta o intersociedad.
Cuando el pedido abierto se refiere a un cliente interplanta (planta de la misma sociedad), este no se puede facturar.
Cuando el pedido abierto se refiere a un cliente intersociedad (planta de una sociedad distinta), se podrá generar una factura a partir de entregas procedentes de este pedido.

• Intersociedad (campo BETCPY)

Este indicador permite señalar si se trata de un tercero interplanta:

• Los clientes/proveedores interplanta se utilizan para los intercambios multiplanta.
• Un cliente es una planta de compra o una planta financiera.
• Un proveedor es una planta de venta o una planta financiera.

• Proyecto (campo PJT)

La gestión del código de proyecto depende del valor del parámetro CTLOPPCOD - Control proyecto obligatorio (capítulo TC, grupo MIS).

• Cuando el valor es No, puede ser un código elegido libremente.
• Cuando el valor es Sí, se realiza sistemáticamente un control de existencia del código de proyecto introducido.

Cuando se controla la entrada, y en función del contexto, el usuario puede elegir un proyecto o una de las entidades imputables del proyecto (un lote presupuestario o una tarea) mediante su código de imputación:

Solo puedes seleccionar un código de imputación activo, dependiendo del estado de la entidad correspondiente. Si se vuelve inactivo después de crear el documento, el control se aplica y evita la modificación de dicho documento.

En creación, el código de proyecto se traslada sistemáticamente a las líneas del documento, donde solo se puede modificar si se permite la gestión multiproyecto (el parámetro PJTSNGDOC - Un proyecto por documento tiene asignado el valor No).

Al transformar un documento, el código de proyecto de la cabecera se inicializa con el primer documento seleccionado (si el código de proyecto de la cabecera del documento de origen ha quedado inactivo, el del documento de destino no se alimenta).

• Sí. El código de proyecto se traslada a todas las líneas, salvo a las vinculadas a un plan de facturación y a un hito no compatible.
• No: el código de proyecto no se traslada a las líneas.
• Mismo valor. El código de proyecto solo se traslada a las líneas que tenían el antiguo código.

Documentos venta: presupuestos, pedidos, entregas y facturas

• Para un presupuesto: el presupuesto no está pedido.
• Para un pedido: el pedido no está entregado (pedidos normales) o facturado (pedidos en facturación directa) y no se ha saldado ninguna línea.
• Para una entrega: la entrega no está validada y es una entrega directa.
• Para una factura o un abono: la factura o el abono no está validado y es una factura o un abono directo.

Solo se permite la agrupación de dos o más documentos con códigos de proyecto diferentes en la cabecera si el parámetro PJTSNGDOC - Un proyecto por documento tiene asignado el valor No. En este caso, por ejemplo, 2 pedidos que cuentan con un código de proyecto distinto se pueden agrupar en un mismo documento de entrega.

• Si la gestión multiproyecto de los documentos está permitida (el parámetro PJTSNGDOC - Un proyecto por documento tiene asignado el valor "No"), la entrega puede contener líneas de entrega directa y líneas de artículo asociadas a tareas. El código de proyecto de la cabecera solo se utiliza como valor por defecto en las líneas de entrega directa. Las líneas de artículo asociadas a tareas mantienen su código de proyecto, que no se puede modificar. Si el código de proyecto se modifica en la cabecera, se propone su traslado a las líneas, como se describe anteriormente. Esto solo es aplicable a las líneas de entrega directa.
• Si la gestión multiproyecto de los documentos no está permitida (el parámetro PJTSNGDOC - Un proyecto por documento tiene asignado el valor Sí), la entrega no puede contener simultáneamente líneas de entrega directa y líneas de artículo asociadas a tareas.
• Cuando la entrega contiene líneas de entrega directa, no puedes introducir un código de proyecto asociado a tareas en la cabecera.
• Cuando la entrega contiene líneas de artículo asociadas a tareas, solo puedes seleccionar líneas de artículo asociadas a la misma tarea. De esta forma, el código de proyecto permite filtrar las tareas en el panel de selección.

Caso específico de los artículos gratuitos generados por una búsqueda de tarifa tras la modificación del código de proyecto en la cabecera: el artículo gratuito solo muestra el código de proyecto del artículo de origen si dicho código de proyecto no se utiliza en una tarea.

• Fecha validez (campo VLYDATCON)

Fecha de fin de validez del contrato.

• Condición pago (campo PTE)

Código asociado por defecto al tercero actual, que permite definir las condiciones de pago.
Este código determina el modo de pago, el tipo de vencimiento y el escalonamiento de los pagos (uno o varios vencimientos al contado, 30 días, fin de mes, etc.).
En la gestión de esta tabla, se pueden simular las reglas de cálculo que se aplicarán en la entrada.

Código asociado por defecto al tercero actual, que permite definir las condiciones de pago.

Este código determina el modo de pago, el tipo de vencimiento y el escalonamiento de los pagos (uno o varios vencimientos al contado, 30 días, fin de mes, etc.).
En la gestión de esta tabla, se pueden simular las reglas de cálculo que se aplicarán en la entrada.

Solo se puede indicar una condición de pago coherente con la legislación y el grupo de la sociedad de la planta del documento.
Los principios generales sobre la parametrización multilegislación se detallan aquí.

• Descuento (campo DEP)

Esta información se introduce en el presupuesto y se inicializa con el código de descuento del cliente facturado. Permite determinar una serie de tasas de descuentos o recargos a aplicar en función del adelanto o retraso de un pago con respecto a la fecha de vencimiento.
Solo se puede introducir un código de descuento coherente con la legislación y el grupo de la sociedad de la planta del documento.
Los principios generales sobre la parametrización multilegislación se detallan aquí.

Si el presupuesto se refiere a un potencial, esta información no se inicializa.

• Tipo entrega (campo SDHTYP)

Este campo muestra el Tipo de entregaasociado al Tipo de pedido elegido y no se puede modificar.

Si no se ha introducido:

• Al entregar el pedido mediante el botón "Entrega":
  Se tiene en cuenta el tipo de entrega indicado en el parámetro SDHTYPNOR - Tipo de entrega normal o SDHTYPLND - Tipo de entrega préstamo (capítulo VEN, grupo SSD).
• Al procesar la Entrega automática de pedidos y la Entrega de documentos de preparación:
  Se tiene en cuenta el tipo de entrega indicado en la función de lanzamiento del procesamiento.

• Divisa (campo CUR)

Es la divisa del pedido, de la entrega o de la factura.
Se inicializa por defecto con la divisa del cliente facturado, pero se puede modificar. En este caso, solo se puede modificar en creación o duplicación y se controla en la tabla de divisas.

Se puede elegir la divisa de la transacción de entrega y definir (en función del valor del parámetro "Precio AI y II" - Capítulo TC/ Grupo INV/NOTATI) si los precios se expresan con o sin impuestos incluidos. Cuando la entrega procede de un pedido, esta información se recupera automáticamente y no se puede modificar. Cuando se trata de una entrega directa, si se ha introducido al menos una línea de entrega, esta información ya no se puede modificar. En este caso, la información se recupera del cliente facturado.

• Tipo de cambio (campo CHGTYP)

Tipo de cambio

Este campo se inicializa con el tipo de curso del cliente factura.

Se controla por un menú local que puede modificarse y puede tomar los siguientes valores:

*     cambio de día

- Cambio del mes

*     cambio medio…

• Rég. impuesto (campo VACBPR)

Este campo permite indicar el régimen de impuesto.

El régimen representa la territorialidad de impuestos, es decir, las reglas de cálculo que se deben aplicar para determinar el importe del impuesto.

Los regímenes se clasifican por tipo de régimen (en la función Régimen de impuesto del tercero, GESTVB) para identificar los diferentes modos de funcionamiento.

Se parametriza a nivel del tercero. El régimen parametrizado en la ficha cliente o en la ficha proveedor se propone por defecto en todas las transacciones en las que interviene este tercero.

En la mayoría de los casos, el cruce de un régimen y un nivel de impuesto permite determinar el código de impuesto a aplicar en la línea del documento y, por consecuencia, en la línea de asiento.

En la pestaña Tercero/Sociedad de este tercero, se puede definir un régimen de impuesto diferente por defecto en función de la sociedad. Cuando existe un valor para una sociedad, este se propone con prioridad.

Solo se puede indicar un régimen de impuesto cuya legislación y grupo sean coherentes con los del documento.
 Consulte la documentación de los principios generales sobre la parametrización multilegislación.

El parámetro CTLTAX – Control de códigos impuestos (capítulo VEN, grupo VAT) permite controlar que el régimen de impuesto del tercero:

• se ha señalado,
• está activo,
• su legislación y grupo son coherentes con los del documento.
  

• Firmado (campo APPFLG)

Esta información permite conocer la situación del documento desde el punto de vista de la gestión de firmas. Los valores posibles son los siguientes: "No", "Parcialmente", "Totalmente", "Sin gestión", "Sí automático".

- Si la gestión de firmas no está activada para la sociedad (parámetro APPSQH para los presupuestos, APPSOH para los pedidos o APPSOC para los pedidos abiertos), el valor será sistemáticamente "Sin gestión". El documento se podrá editar y transformar (transformar el presupuesto en pedido, entregar el pedido o la solicitud de entrega).

- Si la gestión de firmas está activada para la sociedad, el valor dependerá de las reglas de firmas y de las firmas realizadas:

• Si el valor es "No", no se ha firmado ningún documento o un firmante ha cancelado las firmas existentes.
• Si el valor es "Parcialmente", el documento solo está firmado por una parte de los firmantes designados por el circuito.
• Si el valor es "Totalmente", el documento está firmado por todos los firmantes designados por el circuito. Se podrá editar y pedir (para los presupuestos) o entregar (para los pedidos y solicitudes de entrega).
  En estos dos últimos casos, la modificación de ciertos campos del documento (ver lista en la documentación sobre las reglas de firmas (SQHSIGpara los presupuestos, SOHSIG para los pedidos y SOCSIG para los pedidos abiertos) puede reinicializar el circuito de firmas y afectar a la situación del documento con respecto a las firmas.
  En el caso específico de un pedido abierto, el circuito de firmas no se modifica si tiene asociada al menos una solicitud de entrega.
• Si el valor es "Sí automático", la gestión de firmas es opcional (parámetro APPSQH, APPSOH o APPSOC) y no se ha determinado ningún circuito de firmas para este documento. Por lo tanto, se considerará como firmado y se podrá editar y pedir (para los presupuestos) o entregar (para los pedidos y solicitudes de entrega).

• Estado crédito (campo CDTSTA)

Entre las opciones propuestas:

• "Bloqueado": el estado de crédito del cliente está "Bloqueado" cuando en la ficha cliente se ha indicado que el encurso está bloqueado,
• "Rebasamiento encurso": el estado de crédito del cliente está en "Rebasamiento encurso" cuando el total encurso del cliente es superior a su encurso autorizado.

En cuanto a la asignación de las solicitudes de entrega asociadas al pedido abierto, si decide asignar una y el encurso calculado del cliente es superior al autorizado, obtendrá un mensaje solicitando confirmación (si el parámetro usuario SCDTUNL lo autoriza).
En tal caso, no podrá asignar la solicitud de entrega y aparecerá un mensaje de bloqueo.
Si el encurso del cliente está bloqueado, no se podrá ni asignar las solicitudes de entrega asociadas al pedido abierto ni crear nuevos pedidos abiertos para este cliente.

• Precio AI/II (campo PRITYP)

El valor de este campo (AI o II) viene definido por el parámetro general SALPRITYP - Tipo de precio/Importe (capítulo TC, grupo INV).

Si el parámetro general NOTATI - Precio/Importe AI y II (capítulo TC, grupo INV) tiene asignado el valor No, no puedes modificar esta información.

• Tipo asignación (campo ALLTYP)

El tipo de asignación (global/detallada) se inicializa con el valor del parámetro general ALLTYP- Tipo asignación (capítulo VEN, grupo SAL). Se puede modificar según la transacción de entrada utilizada. El tipo de asignación que se indica en esta pestaña se utiliza como valor por defecto para las líneas de pedidos que se introducen posteriormente.

Una vez que haya asignaciones en el pedido, esta información no se puede modificar.

La asignación global reserva la mercancía sin ninguna distinción, recurriendo a un acumulado global, mientras que la asignación detallada reserva objetos de stock (lote, serie, etc.). Un pedido se puede asignar desde el mismo pedido: puedes introducir la cantidad por asignar haciendo clic en el botón Asignación o en el icono Acciones de la línea para elegir las líneas de stock en una asignación detallada, o utilizar las funciones Asignación automática o Asignación por artículo.

• Eje (campo DIE)

Esta tabla permite indicar o visualizar los ejes analíticos, en función de la parametrización de la transacción de entrada de los pedidos abiertos.

• Descripción (campo NAMEDIE)

Este campo recupera la descripción del eje analítico.

• Sección (campo CCE)

Las secciones analíticas se inicializan en función de la parametrización de las Secciones por defecto que hay asociada a la gestión de los pedidos abiertos. Se pueden modificar en función de la parametrización.

Cuando se utiliza un eje analítico en el seguimiento de la gestión del proyecto, cualquier modificación del código de proyecto de la cabecera del documento conlleva la reinicialización del código de sección, en función de la parametrización de las Secciones por defecto.

Particularidades de la intersociedad: en un pedido abierto intersociedad o interplanta, la parametrización del código de secciones por defecto SOR permitirá, si es necesario, transferir las secciones analíticas de ciertos ejes introducidas en la cabecera del pedido abierto de compra.

• Descripción (campo SHO)

Introduzca la descripción corta.

Por defecto, la descripción corta, la descripción larga o la cabecera de columna de un dato (en creación/modificación) se registra en el idioma de conexión del usuario.
Puede traducirlas en otro idioma mediante la función Traducción:

• Haga clic en Traducción desde el icono Acciones del campo correspondiente.
• Añada un nuevo código de idioma y la traducción en la ventana Traducción.

Si se ha realizado la traducción, los usuarios que se conecten en este idioma dispondrán de la descripción corta, la descripción larga o la cabecera de columna en su idioma de conexión. De lo contrario, estarán disponibles en el idioma del dossier.

El idioma de conexión debe estar definido como idioma por defecto deldossier.

• % o importe (campo INVDTAAMT)

Los valores corresponden al pie de facturación. Estos datos pueden proceder directamente de la parametrización de los elementos del pie de facturación o de la ficha del cliente correspondiente.
 Para mayor información, consulte la documentación sobre los elementos de facturación.
Los valores de los elementos del pie se pueden modificar. Los importes con y sin impuestos del documento se ven afectados directamente por estos valores.
Particularidades de la intersociedad
Si el pedido se ha generado a partir de un pedido de compra intersociedad o interplanta y la parametrización intersociedad estipula que los elementos de facturación proceden de Compras, estos se inicializarán con los valores indicados en el pedido de compra original.

• campo INVDTATYP

El sistema indica si el elemento de facturación es un porcentaje o un importe con o sin impuestos.

• Código SST (campo SFISSTCOD)

Introduce el código que se va a utilizar para sustituir el código de impuesto SST por defecto del artículo o del elemento de facturación. Sage Sales Tax reconoce este código de impuesto, que identifica los tipos de línea con fines fiscales. Este campo solo está disponible si el código de actividad "LTA - Impuesto local" está activado y el parámetro USATAX - Uso sistema de impuestos tiene asignado el valor Sí.

Si hay elementos de facturación definidos como descuento en un documento SST para una sociedad, no puedes suprimir el valor del código de impuesto SST del documento.