> Mejora continua de procesos > Procesamiento de pagos de cuentas por pagar > NetSuite > Template de datos

Su Template de datos para el procesamiento de pagos de cuentas por pagar

NetSuite

Atributos del procesamiento de pagos de cuentas por pagar (21) Actividades del procesamiento de pagos de cuentas por pagar (14) Guías de extracción (3)

Su Template de datos para el procesamiento de pagos de cuentas por pagar

Este Template ofrece un marco completo para mapear sus Workflows de cuentas por pagar en NetSuite. Incluye una lista detallada de los atributos de datos esenciales, las actividades principales del proceso y las instrucciones especializadas de extracción para garantizar que su análisis sea preciso y práctico.

Atributos recomendados para un análisis detallado
Hitos esenciales del proceso que debe seguir
Guía específica de extracción para NetSuite

¿Es nuevo en los registros de eventos? Aprenda a crear un registro de eventos de Process Mining.

Descargar Template

Atributos del procesamiento de pagos de cuentas por pagar

Estos son los campos de datos recomendados que debe incluir en su registro de eventos para realizar un análisis exhaustivo del procesamiento de pagos de cuentas por pagar en su entorno de NetSuite.

5 Obligatorio 10 Recomendado 6 Opcional

	Nombre	Descripción
	Actividad Activity	El nombre del paso del proceso o evento ejecutado.
Descripción Este atributo registra la acción específica o el cambio de estado que tuvo lugar en un momento determinado. Algunos ejemplos son «Invoice Created», «Approval Status Changed» o «Payment Processed». Estos datos son esenciales para reconstruir el mapa del flujo del proceso. Al ordenar cronológicamente estas actividades para cada número de factura, la herramienta de Process Mining visualiza el Workflow real e identifica bucles, retrabajos y desviaciones de la ruta esperada. Por qué es importante Define los pasos del mapa del proceso y es obligatorio para cualquier análisis de Process Mining. Dónde obtenerlo Registros de System Notes o del historial del Workflow Ejemplos Factura creadaFactura aprobadaPago programadoPago compensado
	Hora del evento EventTime	La marca de tiempo en la que tuvo lugar la actividad.
Descripción La fecha y hora exactas en las que tuvo lugar una actividad. Se utiliza para ordenar secuencialmente los eventos y calcular la duración entre los pasos. Las marcas de tiempo precisas son fundamentales para identificar cuellos de botella. Permiten calcular los tiempos de ciclo, como el tiempo necesario para una aprobación o el tiempo que una factura permanece bloqueada. Por qué es importante Obligatorio para ordenar los eventos y calcular todos los KPI basados en el tiempo. Dónde obtenerlo Campo «date» de System Notes Ejemplos 2023-10-01T14:30:00Z2023-10-02T09:15:00Z
	Número de factura InvoiceNumber	El identificador único de la factura del proveedor.
Descripción Este atributo representa el número de referencia único asignado a una factura de proveedor en NetSuite. Actúa como identificador definitivo del caso para el proceso de Cuentas por pagar y agrupa todas las actividades relacionadas con una obligación de pago específica. En el análisis, este campo funciona como clave principal de las instancias del proceso. Permite rastrear el ciclo de vida completo de una obligación, desde la recepción y el registro de la factura hasta la liquidación del pago final. Las variantes se agregan según este identificador para determinar las rutas habituales del proceso. Por qué es importante Es el Case ID obligatorio que vincula todos los eventos para formar un caso de proceso. Dónde obtenerlo Tabla de transacciones, campo «tranid» cuando el tipo es «Vendor Bill» Ejemplos INV-2023-001VB-99822ACME-10299982311
	Sistema de origen SourceSystem	El nombre del sistema del que proceden los datos.
Descripción Identifica la aplicación de software de la que se extrajeron los datos de eventos. En este contexto, el valor suele ser estático, como «NetSuite». Este atributo resulta útil en entornos con varios sistemas para rastrear el linaje de los datos. Aunque esta vista se centra en NetSuite, mantener este campo garantiza la compatibilidad con los modelos de datos de toda la empresa. Por qué es importante Obligatorio para el linaje de los datos y para distinguir los datos en entornos con varios sistemas. Dónde obtenerlo Codificado durante la extracción Ejemplos NetSuiteNetSuite OneWorld
	Última actualización de los datos LastDataUpdate	La marca de tiempo en la que se extrajeron o actualizaron los datos.
Descripción Indica cuándo se extrajeron por última vez los datos del sistema de origen a la plataforma de Process Mining. Esto ayuda a comprender la actualidad del análisis. Se utiliza para determinar si los datos que se muestran en los Dashboards representan el estado en tiempo real o una instantánea de un periodo anterior. Esto es fundamental para confiar en los cálculos de «Días de retraso». Por qué es importante Obligatorio para comprender la actualidad de los datos y el estado de sincronización. Dónde obtenerlo Marca de tiempo de ETL Ejemplos 2023-11-01T00:00:00Z
	Departamento Department	El departamento interno asociado a la factura.
Descripción Clasifica la factura según el centro de costes o el departamento interno, como TI o Marketing, que generó el gasto. Este atributo permite desglosar los tiempos de ciclo por departamento. Ayuda a identificar si determinados departamentos tardan más en codificar o aprobar las facturas y permite aplicar mejoras específicas al proceso. Por qué es importante Permite analizar la eficiencia del proceso dentro de la organización. Dónde obtenerlo Campo «department» de la transacción Ejemplos TIMarketingManufactura
	Es sin PO IsNonPO	Indicador que señala si la factura no está vinculada a una orden de compra.
Descripción Un atributo booleano derivado de la ausencia de una orden de compra vinculada. Segmenta el proceso entre facturas respaldadas por una PO y facturas FI directas. Se utiliza en el panel «Non PO Invoice Processing Speed» para destacar la ineficiencia del procesamiento manual de facturas frente al proceso de conciliación a tres bandas. Por qué es importante Segmento de alto nivel para analizar las variantes del proceso. Dónde obtenerlo Derivado de que «PurchaseOrderNumber» es nulo Ejemplos truefalse
	Estado de aprobación ApprovalStatus	El estado actual de aprobación de la factura en el Workflow.
Descripción Indica si la factura está pendiente de aprobación, aprobada o rechazada. Este estado determina la lógica de transición del Workflow. Este campo es fundamental para la «Approval Workflow Compliance Audit». Los cambios en este estado generan eventos de actividad y el estado final determina si la factura está lista para el pago. Por qué es importante Realiza el seguimiento del avance de la factura a través de la etapa de aprobación. Dónde obtenerlo Campo «approvalstatus» de la transacción Ejemplos Pendiente de aprobaciónAprobadaRechazada
	Fecha de pago PaymentDate	La fecha en la que se ejecutó el pago.
Descripción La fecha registrada en la transacción Vendor Payment vinculada a la factura. Representa la finalización del ciclo de Cuentas por pagar. Se utiliza para calcular «End to End Payment Cycle Times». Comparar esta fecha con «InvoiceDate» proporciona la duración total del proceso. Por qué es importante Marca de tiempo final del ciclo principal del proceso. Dónde obtenerlo Fecha de la transacción Vendor Payment vinculada Ejemplos 2023-11-202023-12-05
	Fecha de vencimiento DueDate	La fecha límite en la que debe efectuarse el pago al proveedor.
Descripción Este atributo indica el plazo contractual de pago según las condiciones de la factura. Sirve como referencia para calcular los pagos realizados a tiempo. Este campo es el componente principal del KPI «On Time Payment Rate». Al comparar la fecha «Payment Executed» con este campo, el sistema identifica los pagos atrasados y ayuda a estimar posibles penalizaciones. Por qué es importante Fundamental para calcular las tasas de pago puntual e identificar obligaciones vencidas. Dónde obtenerlo Campo «duedate» de la transacción Ejemplos 2023-11-152023-12-01
	Filial Subsidiary	La filial o entidad jurídica de la empresa que recibe la factura.
Descripción En entornos NetSuite OneWorld, identifica la entidad jurídica específica (Subsidiary) a la que pertenece la factura. Permite realizar comparaciones entre organizaciones. Este atributo impulsa el panel «End to End Payment Cycle Times» y permite comparar la eficiencia entre distintas unidades de negocio. Ayuda a determinar si determinadas regiones o entidades presentan un rendimiento inferior. Por qué es importante Fundamental para que las organizaciones con varias entidades comparen el rendimiento entre sus unidades de negocio. Dónde obtenerlo Campo «subsidiary» de la transacción Ejemplos Este de EE. UU.Sede central de EMEAVentas de APAC
	Importe de la factura InvoiceAmount	El valor monetario total de la factura.
Descripción El importe total de la factura del proveedor, normalmente en la moneda base o en la moneda de la transacción. Esta métrica permite analizar el impacto financiero. Se utiliza en el panel «Late Payment and Penalty Tracking» para cuantificar el riesgo para el flujo de caja derivado de los pagos atrasados. También permite priorizar las facturas de mayor importe para su intervención manual. Por qué es importante Necesario para cuantificar el impacto financiero de las ineficiencias del proceso. Dónde obtenerlo Campo «usertotal» o «foreignamount» de la transacción Ejemplos 1500.00250.5010000.00
	Nombre del proveedor VendorName	El nombre del proveedor que emitió la factura.
Descripción Este atributo contiene el nombre de la entidad asociada a la factura del proveedor. Es fundamental para analizar el rendimiento en toda la cadena de suministro. En el análisis, este campo permite utilizar el panel «Vendor Payment Cycle Variance». Los analistas pueden agrupar los casos por proveedor para identificar a aquellos que provocan sistemáticamente discrepancias en la conciliación o aplican condiciones de pago no estándar. Por qué es importante Esencial para agrupar el análisis por proveedor y encontrar cuellos de botella específicos de cada proveedor. Dónde obtenerlo Campo «entity» de la transacción unido al registro del proveedor Ejemplos Office DepotOracleFedEx
	Número de orden de compra PurchaseOrderNumber	El número de referencia de la orden de compra relacionada.
Descripción Vincula la factura del proveedor con una orden de compra (PO) de origen. Si este campo está vacío, la factura se considera una factura sin PO. Este atributo es esencial para el panel «Non PO Invoice Processing Speed». Permite separar las variantes del flujo entre facturas respaldadas por una PO y facturas sin PO (FI), y comparar su eficiencia y cumplimiento. Por qué es importante Necesario para distinguir entre el procesamiento de facturas basado en PO y el procesamiento de facturas sin PO. Dónde obtenerlo Campo «createdfrom» de la transacción Ejemplos PO-8821PO-1002null
	Usuario User	La persona empleada que ejecutó la actividad.
Descripción Identifica a la persona responsable de un evento específico, como aprobar una factura o liberar un bloqueo de pago. Se utiliza en «Approval Workflow Bottleneck Monitor» para identificar retrasos relacionados con determinados recursos. Ayuda a la dirección a equilibrar la carga de trabajo y detectar necesidades de formación de miembros específicos del equipo. Por qué es importante Necesario para analizar los recursos e identificar cuellos de botella a nivel de usuario. Dónde obtenerlo System Notes «nombre» o Transacción «empleado» Ejemplos John DoeAdministrador de FinanzasSistema
	Bloqueo de pago PaymentHold	Indica si la factura está bloqueada actualmente para el pago.
Descripción Una marca o estado que indica que se ha aplicado un bloqueo de pago a la factura, lo que impide incluirla en las ejecuciones de pagos. Este atributo respalda el panel «Payment Block Impact Analysis». Analizar el tiempo durante el que este campo permanece en «true» permite identificar retrasos de procesamiento causados por disputas o información faltante. Por qué es importante Fundamental para analizar por qué las facturas están bloqueadas o se retrasan. Dónde obtenerlo Campo «paymenthold» de la transacción Ejemplos truefalse
	Condiciones de pago PaymentTerms	Las condiciones acordadas que determinan el plazo de pago y los descuentos.
Descripción Especifica las condiciones de pago, como «Net 30» o «2% 10 Net 30». Este contexto ayuda a explicar la «Due Date» y la posibilidad de obtener descuentos por pronto pago. Este atributo se utiliza en el panel «Early Payment Discount Capture Rate». Identifica las facturas que podían beneficiarse de descuentos y ayuda a relacionar los descuentos no obtenidos con determinadas condiciones restrictivas. Por qué es importante Aporta contexto sobre la fecha de vencimiento e identifica oportunidades de descuento. Dónde obtenerlo Campo «terms» de la transacción Ejemplos Neto a 30 días2% a 10 días, neto a 30 díasVencimiento contra entrega
	Descuento disponible DiscountAvailable	El importe potencial del descuento disponible por pronto pago.
Descripción El valor monetario del descuento por pronto pago calculado según el importe de la factura y las condiciones de pago. Representa el ahorro potencial. Este atributo es fundamental para el panel «Early Payment Discount Capture Rate». Al sumar este valor en los pagos atrasados, los analistas pueden calcular el total de ahorros no obtenidos. Por qué es importante Cuantifica la oportunidad financiera de acelerar el proceso. Dónde obtenerlo Calculado a partir de Terms e InvoiceAmount Ejemplos 30.000.0015.50
	Días de retraso DaysOverdue	El número de días transcurridos entre la fecha de vencimiento y la fecha en que se efectuó el pago.
Descripción Una métrica calculada que mide el retraso del pago con respecto a la fecha de vencimiento. Los valores negativos indican un pago anticipado. Este atributo alimenta el panel «Late Payment and Penalty Tracking». Es esencial para cuantificar la gravedad de los pagos atrasados e identificar patrones de retraso recurrentes. Por qué es importante Métrica clave para analizar el cumplimiento de los pagos y el riesgo de penalizaciones. Dónde obtenerlo Calculado: PaymentDate - DueDate Ejemplos 50-2
	Fecha de la factura InvoiceDate	La fecha impresa en la factura del proveedor.
Descripción La fecha del documento proporcionada por el proveedor. A menudo es el punto de partida para calcular la antigüedad. Se utiliza para calcular el «End to End Processing Cycle Time». La diferencia entre esta fecha y la fecha de creación en NetSuite puede indicar retrasos en el escaneado o en el departamento de recepción de correspondencia. Por qué es importante Marca el inicio oficial del periodo del proveedor. Dónde obtenerlo Campo «trandate» de la transacción Ejemplos 2023-10-012023-10-05
	Moneda Currency	La moneda en la que se emitió la factura.
Descripción El código ISO que representa la moneda de la transacción. Es importante para las organizaciones multinacionales. Se utiliza para normalizar los valores financieros en el análisis de «Invoice Amount». También ayuda a identificar si los procesos de cambio de divisas están añadiendo tiempo a la actividad «Payment Cleared». Por qué es importante Necesario para realizar una agregación financiera correcta y analizar el cambio de divisas. Dónde obtenerlo Campo «currency» de la transacción Ejemplos USDEURGBP

Obligatorio Recomendado Opcional

Actividades del procesamiento de pagos de cuentas por pagar

Estos son los pasos clave del proceso y los hitos que debe capturar en su registro de eventos para descubrir con precisión el ciclo de vida del procesamiento de sus pagos.

5 Recomendado 9 Opcional

	Actividad	Descripción
	Factura aprobada	El estado de Vendor Bill cambia a Open, lo que indica que está autorizado para el pago y que ha afectado al General Ledger. Este es un hito clave antes del pago.
Por qué es importante Finaliza el ciclo de aprobación y hace que la factura esté disponible para la programación del pago. Es esencial para medir la eficiencia de las aprobaciones. Dónde obtenerlo System Notes. Busque un cambio en el campo 'approvalstatus' a '2' (Approved) o en el estado a 'Open'. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Factura conciliada con la orden de compra	Indica que Vendor Bill se creó a partir de una Purchase Order existente o está vinculada a ella. Esto distingue las facturas respaldadas por una orden de compra de las facturas sin orden de compra.
Por qué es importante Es fundamental para analizar el cumplimiento de las políticas de compras y comparar los tiempos de ciclo entre facturas con y sin orden de compra. Dónde obtenerlo Tabla de transacciones. Compruebe el campo 'createdfrom' en el registro Vendor Bill. Si contiene un ID de Purchase Order, esta actividad tuvo lugar. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Factura creada	Creación inicial del registro Vendor Bill en NetSuite. Este evento marca el inicio del proceso e indica que la factura se ha introducido en el ERP.
Por qué es importante Establece la marca de tiempo de referencia para todo el ciclo de Cuentas por pagar y para los cálculos de antigüedad. Dónde obtenerlo Tabla de transacciones. Filtre cuando el tipo de registro sea Vendor Bill. Capture el campo datecreated o trandate. Recopilar Se registra cuando se ejecuta la transacción Vendor Bill Tipo de evento explicit
	Pago compensado	Bill Payment se marca como compensado durante el proceso de conciliación bancaria. Esto confirma que los fondos han salido de la cuenta bancaria.
Por qué es importante Proporciona la fecha financiera real de finalización para el análisis del flujo de caja, distinta de la fecha contable del pago. Dónde obtenerlo Transaction Line. El indicador 'cleared' se establece en True en la línea de transacción Bill Payment. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit
	Pago procesado	Un registro Bill Payment se contabiliza correctamente y marca la factura como Paid in Full o Partially Paid. La obligación se libera en el GL.
Por qué es importante Es el principal hito de finalización del proceso de pago. Se utiliza para calcular 'End to End Processing Cycle Time'. Dónde obtenerlo Tabla de transacciones. Identifique la creación del registro 'Bill Payment' o el cambio de estado a 'Deposited' (para cheques) o 'Paid'. Recopilar Se registra cuando se ejecuta la transacción Bill Payment Tipo de evento explicit
	Aprobación de factura solicitada	El estado de Vendor Bill cambia a Pending Approval. Esto indica que la factura ha entrado en la ruta del Workflow para su autorización.
Por qué es importante Marca el inicio del tiempo de ciclo de aprobación y permite identificar cuellos de botella en la cadena de autorización. Dónde obtenerlo System Notes. Busque un cambio en el campo 'approvalstatus' a '1' (Pending Approval). Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Crédito del proveedor aplicado	Se aplica un Bill Credit (Vendor Credit) a Vendor Bill, lo que reduce el importe pendiente. Es una alternativa al pago en efectivo.
Por qué es importante Explica por qué el importe de un pago puede diferir del importe de la factura y permite cerrar correctamente la obligación. Dónde obtenerlo Transaction Links. Identifique cuándo una transacción de tipo 'Vendor Credit' está vinculada a Vendor Bill. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Cuenta de la factura modificada	Se modifica la cuenta de gastos del General Ledger en las líneas de la factura. Esto indica la corrección de un error de codificación o una reclasificación.
Por qué es importante Mide directamente el KPI 'Invoice Coding Rework Rate' y destaca las pérdidas de eficiencia en el paso de codificación contable. Dónde obtenerlo System Notes. Busque cambios en el campo 'account' de la sublista Transaction Line. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit
	Factura rechazada	Vendor Bill se devuelve a quien la envió para su corrección o rechazo. Esto representa un ciclo de retorno o la terminación del Workflow de aprobación.
Por qué es importante Una tasa elevada de rechazos indica fricción en el proceso, problemas de capacitación o problemas de calidad de los datos en etapas anteriores. Dónde obtenerlo System Notes. Busque un cambio en el campo 'approvalstatus' a '3' (Rejected). Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Importe de la factura modificado	El importe total de Vendor Bill cambia después de su creación inicial. Esto puede indicar retrabajo, errores de introducción de datos o resolución de discrepancias.
Por qué es importante Indica intervención manual y retrabajo, lo que afecta negativamente a las tasas de Straight Through Processing. Dónde obtenerlo System Notes. Busque cambios en los campos 'total' o 'usertotal' del registro Vendor Bill. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit
	Pago anulado	Se anula un Bill Payment procesado anteriormente y se vuelve a abrir Vendor Bill. Esto representa una excepción importante y un fallo del proceso.
Por qué es importante Es fundamental para el cumplimiento en auditorías y para identificar las causas de los pagos fallidos, como errores de impresión de cheques o rechazos bancarios. Dónde obtenerlo System Notes en Bill Payment. Cambio de estado a 'Voided'. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit
	Pago programado	Se crea un registro Bill Payment en estado 'Pending Approval'. Esto suele ocurrir durante la creación de un lote de Electronic Bank Payment (EFT).
Por qué es importante Distingue entre la intención de pagar y la ejecución real de los fondos, y destaca los retrasos en la autorización del pago. Dónde obtenerlo Tabla de transacciones. Creación de un registro 'Bill Payment' vinculado a Bill, con estado 'Pending Approval'. Recopilar Compare el campo de estado antes y después Tipo de evento inferred
	Retención de pago aplicada	La casilla Payment Hold de Vendor Bill se establece en True. Esto impide que la factura se seleccione para las ejecuciones de pagos.
Por qué es importante Identifica cuellos de botella en los que las facturas se detienen debido a disputas o decisiones de gestión del flujo de caja. Dónde obtenerlo System Notes. Busque el cambio del campo 'paymenthold' de 'F' a 'T'. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit
	Retención de pago liberada	La casilla Payment Hold se establece en False, lo que libera la factura para su procesamiento de pago. Esto marca el final de un periodo de bloqueo.
Por qué es importante Se utiliza para calcular el KPI 'Payment Block Duration' y comprender los tiempos de resolución de las facturas disputadas. Dónde obtenerlo System Notes. Busque el cambio del campo 'paymenthold' de 'T' a 'F'. Recopilar Se registra cuando se ejecuta la transacción X Tipo de evento explicit

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de NetSuite

Pasos

Inicie sesión en NetSuite como administrador o con un usuario que tenga permiso para crear y exportar búsquedas guardadas.
Vaya a Lists > Search > Saved Searches > New.
Seleccione Transaction en la lista de tipos de registro para iniciar una nueva búsqueda guardada de transacciones.
En la pestaña Criteria, compruebe que la casilla Use Expressions esté desmarcada inicialmente y, después, añada el filtro Type. Seleccione cualquiera de estas opciones: Vendor Bill, Bill Payment o Bill Credit.
En la misma pestaña Criteria, añada el filtro Main Line y establézcalo en True. Así se centrará en el nivel de encabezado para los eventos de creación y estado.
Para capturar el historial, vaya a la relación System Notes en la lista de filtros, situada al final del menú desplegable, y añada System Notes : Date. Establezca el intervalo de fechas que desee, por ejemplo, los últimos 90 días.
Cambie a la pestaña Results. Elimine todas las columnas predeterminadas.
Añada la columna de identificador de caso: seleccione Transaction Name o Document Number. Asigne la etiqueta personalizada InvoiceNumber.
Añada la columna de hora del evento: seleccione System Notes fields... > Date. Asigne la etiqueta personalizada EventTime.
Añada la columna de actividad: seleccione Formula (Text). En la ventana de fórmula, pegue la instrucción CASE proporcionada en la sección Query siguiente. Esta lógica asigna los cambios de campos de NetSuite a sus nombres de actividad estándar. Asigne la etiqueta personalizada Activity.
Añada los demás atributos requeridos, como Source System y Last Data Update, mediante Formula (Text) con valores estáticos, por ejemplo, 'NetSuite', y la etiqueta integrada {today}.
Haga clic en Save & Run. Cuando se carguen los resultados, haga clic en el icono Export - CSV situado en la esquina superior izquierda de la barra de herramientas de resultados para descargar el registro de eventos para ProcessMind.

Configuración

Tipos de transacción: filtre estrictamente por Vendor Bill, Bill Payment y Bill Credit para evitar datos innecesarios de Journal Entries o Purchase Orders.
Unión con System Notes: esta configuración depende en gran medida de la unión con System Notes para generar un historial, en lugar de una instantánea del estado actual. Asegúrese de que su rol de usuario tenga permiso para consultar System Notes.
Intervalo de fechas: aplique el filtro de fecha al campo System Notes : Date, no al campo de fecha de la transacción. Así capturará actividades recientes de facturas antiguas, como un pago realizado hoy para una factura creada el año pasado.
Main Line: se recomienda establecer Main Line = True para reducir el volumen de filas, pero si necesita seguir el evento 'Invoice Account Modified', quizá deba establecer Main Line = False o crear una búsqueda independiente para los cambios a nivel de línea.
Límites de las fórmulas: las fórmulas de NetSuite están limitadas a 4.000 caracteres. Si la lógica de Activity se vuelve demasiado compleja, divídala en dos búsquedas o procese el mapeo fuera de NetSuite.

a Consulta de ejemplo config

Type: Transaction

CRITERIA TAB:
- Type: is any of Vendor Bill, Bill Payment, Bill Credit
- Main Line: is True
- System Notes : Date: is within [Your Date Range]

RESULTS TAB:

Column 1: Document Number
- Label: InvoiceNumber

Column 2: System Notes : Date
- Label: EventTime

Column 3: Formula (Text)
- Label: Activity
- Formula:
CASE 
   WHEN {systemnotes.type} = 'Create' AND {type} = 'Bill' THEN 'Invoice Created'
   WHEN {systemnotes.type} = 'Create' AND {type} = 'Bill' AND {createdfrom} IS NOT NULL THEN 'Invoice Matched to PO'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Pending Approval' THEN 'Invoice Approval Requested'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Open' THEN 'Invoice Approved'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Approval Status' AND {systemnotes.newvalue} = 'Rejected' THEN 'Invoice Rejected'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Amount' THEN 'Invoice Amount Modified'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Account' THEN 'Invoice Account Modified'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Payment Hold' AND {systemnotes.newvalue} = 'T' THEN 'Payment Hold Applied'
   WHEN {type} = 'Bill' AND {systemnotes.field} = 'Payment Hold' AND {systemnotes.newvalue} = 'F' THEN 'Payment Hold Released'
   WHEN {type} = 'Bill Credit' AND {systemnotes.type} = 'Create' THEN 'Vendor Credit Applied'
   WHEN {type} = 'Bill Payment' AND {systemnotes.type} = 'Create' AND {status} = 'Pending Approval' THEN 'Payment Scheduled'
   WHEN {type} = 'Bill Payment' AND {systemnotes.type} = 'Create' AND {status} = 'Paid In Full' THEN 'Payment Processed'
   WHEN {type} = 'Bill Payment' AND {systemnotes.field} = 'Void' THEN 'Payment Voided'
   WHEN {type} = 'Bill Payment' AND {systemnotes.field} = 'Cleared' AND {systemnotes.newvalue} = 'T' THEN 'Payment Cleared'
   ELSE 'General Update'
END

Column 4: Formula (Text)
- Label: SourceSystem
- Formula: 'NetSuite'

Column 5: Formula (Text)
- Label: LastDataUpdate
- Formula: TO_CHAR({today}, 'YYYY-MM-DD HH24:MI:SS')

Column 6: Vendor : Name
- Label: VendorName

Column 7: Subsidiary
- Label: Subsidiary

Column 8: Amount
- Label: InvoiceAmount

Column 9: Due Date
- Label: DueDate

Column 10: Created From
- Label: PurchaseOrderNumber

Column 11: System Notes : Set by
- Label: User

Column 12: Department
- Label: Department

Column 13: Status
- Label: ApprovalStatus

Column 14: Formula (Text)
- Label: IsNonPO
- Formula: CASE WHEN {createdfrom} IS NULL THEN 'True' ELSE 'False' END

Pasos

Configure el controlador ODBC: asegúrese de que el controlador ODBC de SuiteAnalytics Connect esté instalado y configurado en el equipo de extracción. Necesitará su ID de cuenta de NetSuite, el ID del rol y credenciales válidas.
Verifique los permisos: el rol de usuario asociado a la conexión ODBC debe tener el permiso 'SuiteAnalytics Connect' y acceso de 'View' a Transactions, System Notes y Entities.
Prepare el entorno: abra su cliente SQL, por ejemplo, DBeaver, DataGrip o una herramienta ETL propia, y establezca una conexión con la fuente de datos de NetSuite.
Defina el alcance: identifique los ID de Subsidiary y el intervalo de fechas de la extracción. Actualice la cláusula WHERE de la Common Table Expression (CTE) denominada 'VendorBills' en la consulta proporcionada.
Ejecute la consulta: ejecute el script SQL proporcionado. Este script agrega datos de las tablas 'Transaction', 'TransactionLine', 'SystemNote' y 'TransactionLink' para reconstruir el historial del proceso.
Supervise la ejecución: las conexiones ODBC de NetSuite pueden agotarse con grandes volúmenes de datos. Si la consulta falla, considere dividir la extracción por mes o trimestre mediante el filtro 'trandate'.
Valide los datos: compruebe que exista una distribución razonable de eventos 'Invoice Created' frente a eventos 'Payment Processed'. Asegúrese de que 'InvoiceNumber' esté informado en todas las filas.
Exporte los datos: guarde los resultados de la consulta como archivo CSV o incorpórelos directamente a su dataframe. Asegúrese de utilizar la codificación UTF-8 para gestionar los caracteres especiales de los nombres de proveedores.
Formatee las fechas: asegúrese de que la columna 'EventTime' se analice como un objeto datetime (YYYY-MM-DD HH:MM:SS) durante la importación a ProcessMind.
Gestione los valores nulos: en la columna 'User', los valores nulos suelen indicar eventos generados por el sistema, como scripts programados. Si lo desea, puede sustituirlos por 'System' durante el procesamiento posterior.
Realice la revisión final: confirme que la columna 'Activity' contenga los nombres de evento específicos necesarios, por ejemplo, 'Invoice Created' y 'Payment Processed', y que no se hayan producido errores de mapeo.

Configuración

Intervalo de fechas: filtre mediante 'Transaction.trandate'. Para el análisis inicial de Process Mining, se recomienda un intervalo de 3 a 12 meses.
Filtrado por subsidiaria: si su entorno de NetSuite es OneWorld, filtre siempre por 'Transaction.subsidiary' para asegurarse de analizar la entidad jurídica correcta.
System Notes: la extracción depende en gran medida de la tabla 'SystemNote' para los registros de aprobación y cambios. Asegúrese de que 'Log System Notes on Update Only' NO impida capturar pasos críticos del Workflow.
Estado de la transacción: los estados de las transacciones de NetSuite son distintos, por ejemplo, 'A' y 'B'. La consulta los convierte en textos legibles. Verifique que su entorno utilice los códigos de estado estándar.
Versión del controlador ODBC: utilice la versión más reciente disponible del controlador de SuiteAnalytics Connect para evitar problemas de compatibilidad con las actualizaciones recientes de NetSuite.

a Consulta de ejemplo sql

WITH VendorBills AS (
    SELECT
        t.ID AS TransactionID,
        t.tranid AS InvoiceNumber,
        t.trandate AS InvoiceDate,
        t.createDate AS CreatedDate,
        t.lastModifiedDate AS LastModified,
        e.altName AS VendorName,
        s.name AS Subsidiary,
        t.foreignTotal AS InvoiceAmount,
        t.dueDate AS DueDate,
        t.createdFrom AS CreatedFromID,
        CASE WHEN t.createdFrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
        dep.name AS Department,
        'NetSuite' AS SourceSystem
    FROM
        Transaction t
        LEFT JOIN Entity e ON t.entity = e.id
        LEFT JOIN Subsidiary s ON t.subsidiary = s.id
        LEFT JOIN Department dep ON t.department = dep.id
    WHERE
        t.type = 'VendBill'
        AND t.trandate >= TO_DATE('2023-01-01', 'YYYY-MM-DD') -- REPLACE WITH YOUR START DATE
        AND t.trandate <= TO_DATE('2023-12-31', 'YYYY-MM-DD') -- REPLACE WITH YOUR END DATE
),
PO_Data AS (
    SELECT
        t.ID AS PO_ID,
        t.tranid AS PONumber
    FROM
        Transaction t
    WHERE
        t.type = 'PurchOrd'
)

-- 1. Invoice Created
SELECT
    vb.InvoiceNumber,
    'Invoice Created' AS Activity,
    vb.CreatedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Created' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID

UNION ALL

-- 2. Invoice Matched to PO
SELECT
    vb.InvoiceNumber,
    'Invoice Matched to PO' AS Activity,
    vb.CreatedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Created' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID

UNION ALL

-- 3. Invoice Approval Requested (Derived from System Notes)
SELECT
    vb.InvoiceNumber,
    'Invoice Approval Requested' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Pending Approval' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND sn.newValue = 'Pending Approval'

UNION ALL

-- 4. Invoice Approved
SELECT
    vb.InvoiceNumber,
    'Invoice Approved' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Open' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND (sn.newValue = 'Approved' OR sn.newValue = 'Open')

UNION ALL

-- 5. Invoice Rejected
SELECT
    vb.InvoiceNumber,
    'Invoice Rejected' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Rejected' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'approvalstatus'
    AND sn.newValue = 'Rejected'

UNION ALL

-- 6. Invoice Amount Modified
SELECT
    vb.InvoiceNumber,
    'Invoice Amount Modified' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Modified' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    (sn.standardfield = 'foreigntotal' OR sn.standardfield = 'total')

UNION ALL

-- 7. Invoice Account Modified
SELECT
    vb.InvoiceNumber,
    'Invoice Account Modified' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Modified' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'account'

UNION ALL

-- 8. Payment Hold Applied
SELECT
    vb.InvoiceNumber,
    'Payment Hold Applied' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Hold' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'paymenthold'
    AND sn.newValue = 'T'

UNION ALL

-- 9. Payment Hold Released
SELECT
    vb.InvoiceNumber,
    'Payment Hold Released' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Released' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN SystemNote sn ON vb.TransactionID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    sn.standardfield = 'paymenthold'
    AND sn.newValue = 'F'

UNION ALL

-- 10. Vendor Credit Applied
SELECT
    vb.InvoiceNumber,
    'Vendor Credit Applied' AS Activity,
    vc.createDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Credit Applied' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vc ON tl.nextDoc = vc.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vc.type = 'VendCred'

UNION ALL

-- 11. Payment Scheduled (Bill Payment created but pending)
SELECT
    vb.InvoiceNumber,
    'Payment Scheduled' AS Activity,
    vp.createDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Scheduled' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND vp.status = 'Pending Approval'

UNION ALL

-- 12. Payment Processed (Payment posted)
SELECT
    vb.InvoiceNumber,
    'Payment Processed' AS Activity,
    vp.trandate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Paid' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND (vp.status = 'PaidInFull' OR vp.status = 'Deposited' OR vp.status = 'NotDeposited')

UNION ALL

-- 13. Payment Voided
SELECT
    vb.InvoiceNumber,
    'Payment Voided' AS Activity,
    sn.date AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    emp.entityid AS User,
    vb.Department,
    'Voided' AS ApprovalStatus,
    vb.IsNonPO,
    NULL AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    INNER JOIN SystemNote sn ON vp.ID = sn.recordID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
    LEFT JOIN Entity emp ON sn.name = emp.id
WHERE
    vp.type = 'VendPymt'
    AND sn.standardfield = 'status'
    AND sn.newValue LIKE '%Void%'

UNION ALL

-- 14. Payment Cleared
SELECT
    vb.InvoiceNumber,
    'Payment Cleared' AS Activity,
    vp.clearedDate AS EventTime,
    vb.SourceSystem,
    vb.LastModified AS LastDataUpdate,
    vb.VendorName,
    vb.Subsidiary,
    vb.InvoiceAmount,
    vb.DueDate,
    po.PONumber AS PurchaseOrderNumber,
    NULL AS User,
    vb.Department,
    'Cleared' AS ApprovalStatus,
    vb.IsNonPO,
    vp.trandate AS PaymentDate
FROM
    VendorBills vb
    INNER JOIN TransactionLink tl ON vb.TransactionID = tl.previousDoc
    INNER JOIN Transaction vp ON tl.nextDoc = vp.ID
    LEFT JOIN PO_Data po ON vb.CreatedFromID = po.PO_ID
WHERE
    vp.type = 'VendPymt'
    AND vp.clearedDate IS NOT NULL

Pasos

Requisitos previos: Asegúrese de tener una cuenta de NetSuite con acceso de administrador o desarrollador. Debe tener habilitadas las funciones 'SuiteTalk REST Web Services' y 'SuiteAnalytics Connect' en Setup > Company > Enable Features.
Configure la integración: Vaya a Setup > Integration > Manage Integrations > New. Cree una integración llamada 'ProcessMining_ETL'. Marque 'Rest Web Services' y 'Token-Based Authentication'. Anote el Consumer Key y el Consumer Secret generados.
Genere el token: Vaya a la página Manage Access Tokens. Cree un token nuevo para el rol que tenga permisos para consultar Transacciones, System Notes y Lists. Anote el Token ID y el Token Secret.
Prepare el entorno de Python: Instale Python 3.x. Instale las bibliotecas necesarias mediante pip: pip install requests requests-oauthlib pandas.
Configure el script: Copie el script de Python proporcionado en la sección Query que aparece a continuación. Actualice las variables ACCOUNT_ID, CONSUMER_KEY, CONSUMER_SECRET, TOKEN_ID y TOKEN_SECRET con sus credenciales. Establezca la variable START_DATE en el periodo de extracción que desee, por ejemplo, '2023-01-01'.
Lógica de SuiteQL: El script utiliza un enfoque basado en UNION ALL. Consulta la tabla Transacción para obtener los eventos de creación y pago, y la tabla SystemNote para obtener los eventos del registro de auditoría, como aprobaciones, cambios y retenciones.
Ejecución: Ejecute el script desde la línea de comandos: python netsuite_extract.py. El script gestiona automáticamente la paginación; SuiteQL crea páginas de 1.000 registros.
Procesamiento de datos: El script convierte automáticamente la respuesta JSON en un formato tabular plano adecuado para Process Mining. Gestiona la asignación de columnas y el formato de las fechas.
Validación: El script muestra el número total de filas extraídas. Si es necesario, compárelo con una búsqueda guardada de NetSuite.
Exportación: El DataFrame final se guarda como netsuite_ap_event_log.csv. Este archivo está listo para cargarse en ProcessMind.
Carga: Importe el CSV en ProcessMind. Asigne InvoiceNumber como ID del caso, Actividad como Actividad y EventTime como Marca de tiempo.

Configuración

Autenticación: Utiliza OAuth 1.0a (autenticación basada en tokens). Este es el modelo de seguridad estándar de la API REST de NetSuite.
Tamaño del lote: El script solicita 1.000 filas por página, que es el máximo predeterminado de NetSuite para SuiteQL.
Filtrado por fecha: Está configurado para filtrar por trandate (para las transacciones) y por date (para las notas del sistema) >= START_DATE, con el fin de optimizar el rendimiento.
Ámbito: Filtra la tabla Transacción por los tipos 'VendBill' (factura de proveedor), 'BillPymt' (pago de factura) y 'VendCred' (abono de proveedor).
Notas del sistema: Esta tabla es fundamental para capturar los ciclos de aprobación y los cambios. Puede ser grande; asegúrese de que el usuario de integración tenga permiso para consultar SystemNote.
Zona horaria: La API de NetSuite devuelve las fechas en la zona horaria de la cuenta. El script presupone formatos ISO estándar.

a Consulta de ejemplo python

import requests
from requests_oauthlib import OAuth1
import pandas as pd
import time

class=class="hl-string">"hl-comment"># === CONFIGURATION ===
ACCOUNT_ID = class="hl-string">'1234567_SB1'  class=class="hl-string">"hl-comment"># Your NetSuite Account ID (Realm). Use hyphens for sandbox (e.g., 1234567-sb1)
CONSUMER_KEY = class="hl-string">'your_consumer_key'
CONSUMER_SECRET = class="hl-string">'your_consumer_secret'
TOKEN_ID = class="hl-string">'your_token_id'
TOKEN_SECRET = class="hl-string">'your_token_secret'
START_DATE = class="hl-string">'2024-01-01'  class=class="hl-string">"hl-comment"># Filter for data extraction

class=class="hl-string">"hl-comment"># Normalize Account ID for URL (NetSuite requires lowercase and hyphens)
url_account_id = ACCOUNT_ID.lower().replace(class="hl-string">'_', class="hl-string">'-')
BASE_URL = fclass="hl-string">'https://{url_account_id}.suitetalk.api.netsuite.com/services/rest/query/v1/suiteql'

class=class="hl-string">"hl-comment"># === SUITEQL QUERY ===
class=class="hl-string">"hl-comment"># This query extracts 14 activities using UNION ALL to combine Transaction data and System Notes.
suiteql_query = fclass="hl-string">"""
/* 1. Invoice Created */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Created' AS Activity,
    TO_CHAR(t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM Transaction t
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee e ON t.createdBy = e.id
LEFT JOIN Department d ON t.department = d.id
WHERE t.type = 'VendBill'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 2. Invoice Matched to PO */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Matched to PO' AS Activity,
    TO_CHAR(t.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    'False' AS IsNonPO,
    NULL AS PaymentDate
FROM Transaction t
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee e ON t.createdBy = e.id
LEFT JOIN Department d ON t.department = d.id
WHERE t.type = 'VendBill'
AND t.createdfrom IS NOT NULL
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 3. Invoice Approval Requested (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Approval Requested' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30 /* Internal ID for Vendor Bill */
AND sn.field = 'status'
AND sn.value = 'Pending Approval'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 4. Invoice Approved (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Approved' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'status'
AND sn.value = 'Open'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 5. Invoice Rejected (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Rejected' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'status'
AND sn.value = 'Rejected'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 6. Invoice Amount Modified (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Amount Modified' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'total'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 7. Invoice Account Modified (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Invoice Account Modified' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'account'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 8. Payment Hold Applied (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Payment Hold Applied' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'paymenthold'
AND sn.value = 'T'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 9. Payment Hold Released (System Note) */
SELECT
    t.tranid AS InvoiceNumber,
    'Payment Hold Released' AS Activity,
    TO_CHAR(sn.date, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t.foreignTotal AS InvoiceAmount,
    t.duedate AS DueDate,
    t.otherrefnum AS PurchaseOrderNumber,
    rau.entityid AS User,
    d.name AS Department,
    t.status AS ApprovalStatus,
    CASE WHEN t.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    NULL AS PaymentDate
FROM SystemNote sn
JOIN Transaction t ON sn.recordid = t.id
LEFT JOIN Entity bu ON t.entity = bu.id
LEFT JOIN Subsidiary s ON t.subsidiary = s.id
LEFT JOIN Employee rau ON sn.name = rau.id
LEFT JOIN Department d ON t.department = d.id
WHERE sn.recordtypeid = -30
AND sn.field = 'paymenthold'
AND sn.value = 'F'
AND t.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 10. Vendor Credit Applied */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Vendor Credit Applied' AS Activity,
    TO_CHAR(t_cred.trandate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_cred.trandate AS PaymentDate
FROM Transaction t_cred
JOIN TransactionLine tl ON t_cred.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_cred.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_cred.type = 'VendCred'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 11. Payment Scheduled */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Scheduled' AS Activity,
    TO_CHAR(t_pay.createddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Pending Approval'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 12. Payment Processed */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Processed' AS Activity,
    TO_CHAR(t_pay.trandate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status <> 'Voided'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 13. Payment Voided */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Voided' AS Activity,
    TO_CHAR(t_pay.lastmodifieddate, 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Voided'
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')

UNION ALL

/* 14. Payment Cleared (Logic depends on bank rec features, using Check Cleared date or modification) */
SELECT
    t_bill.tranid AS InvoiceNumber,
    'Payment Cleared' AS Activity,
    /* Fallback to trandate if clearedDate is unavailable in your config */
    TO_CHAR(COALESCE(t_pay.createddate, t_pay.trandate), 'YYYY-MM-DD HH24:MI:SS') AS EventTime,
    'NetSuite' AS SourceSystem,
    TO_CHAR(SYSDATE, 'YYYY-MM-DD HH24:MI:SS') AS LastDataUpdate,
    bu.name AS VendorName,
    s.name AS Subsidiary,
    t_bill.foreignTotal AS InvoiceAmount,
    t_bill.duedate AS DueDate,
    t_bill.otherrefnum AS PurchaseOrderNumber,
    e.entityid AS User,
    d.name AS Department,
    t_bill.status AS ApprovalStatus,
    CASE WHEN t_bill.createdfrom IS NULL THEN 'True' ELSE 'False' END AS IsNonPO,
    t_pay.trandate AS PaymentDate
FROM Transaction t_pay
JOIN TransactionLine tl ON t_pay.id = tl.transaction
JOIN Transaction t_bill ON tl.appliedtotransaction = t_bill.id
LEFT JOIN Entity bu ON t_bill.entity = bu.id
LEFT JOIN Subsidiary s ON t_bill.subsidiary = s.id
LEFT JOIN Employee e ON t_pay.createdBy = e.id
LEFT JOIN Department d ON t_bill.department = d.id
WHERE t_pay.type = 'BillPymt'
AND t_pay.status = 'Paid In Full' /* Indicates cleared/posted in some contexts */
AND t_bill.trandate >= TO_DATE('{START_DATE}', 'YYYY-MM-DD')
"""

class=class="hl-string">"hl-comment"># === AUTH AND EXECUTION ===

def get_suiteql_results(query):
    oauth = OAuth1(
        client_key=CONSUMER_KEY,
        client_secret=CONSUMER_SECRET,
        resource_owner_key=TOKEN_ID,
        resource_owner_secret=TOKEN_SECRET,
        realm=ACCOUNT_ID,
        signature_method=class="hl-string">'HMAC-SHA256'
    )
    
    all_rows = []
    offset = 0
    has_more = True
    
    print(class="hl-string">"Starting extraction...")
    
    while has_more:
        class=class="hl-string">"hl-comment"># SuiteQL REST API payload
        headers = {
            class="hl-string">'Prefer': class="hl-string">'transient',
            class="hl-string">'Content-Type': class="hl-string">'application/json'
        }
        
        class=class="hl-string">"hl-comment"># Add LIMIT/OFFSET to query if not using built-in cursors (SuiteQL doesn't support OFFSET well natively in string, 
        class=class="hl-string">"hl-comment"># but REST API handles pagination via links. However, for raw query, we usually rely on class="hl-string">'items' return)
        class=class="hl-string">"hl-comment"># Note: Pure SuiteQL via REST returns a set number of records. We must iterate via the class="hl-string">'links' provided in response
        class=class="hl-string">"hl-comment"># or typically, SuiteQL REST creates a job for large queries. 
        class=class="hl-string">"hl-comment"># For simplicity in this script, we assume a direct synchronous call pattern.
        
        class=class="hl-string">"hl-comment"># Actually, for large datasets, we must use the class="hl-string">'q' parameter. 
        class=class="hl-string">"hl-comment"># But SuiteQL POST body is standard. We will implement simple looping if class="hl-string">'hasMore' is present.
        
        payload = {
            class="hl-string">"q": query
        }
        
        response = requests.post(BASE_URL, headers=headers, auth=oauth, json=payload)
        
        if response.status_code != 200:
            print(fclass="hl-string">"Error: {response.text}")
            break
            
        data = response.json()
        items = data.get(class="hl-string">'items', [])
        all_rows.extend(items)
        
        class=class="hl-string">"hl-comment"># Check if there are more results (SuiteQL REST paging)
        class=class="hl-string">"hl-comment"># Standard REST response has class="hl-string">'hasMore' and class="hl-string">'links'. 
        class=class="hl-string">"hl-comment"># However, Query API V1 often requires traversing the class="hl-string">'next' link.
        has_more = data.get(class="hl-string">'hasMore', False)
        
        if has_more:
            class=class="hl-string">"hl-comment"># For subsequent pages, we follow the class="hl-string">'next' link logic or offset logic.
            class=class="hl-string">"hl-comment"># Note: The Query API creates a paged result set. We strictly need to follow the class="hl-string">'links' > class="hl-string">'next'.
            links = data.get(class="hl-string">'links', [])
            next_link = next((l[class="hl-string">'href'] for l in links if l[class="hl-string">'rel'] == class="hl-string">'next'), None)
            if next_link:
                BASE_URL = next_link class=class="hl-string">"hl-comment"># Update URL for next loop
                class=class="hl-string">"hl-comment"># Payload is not needed for next link GET usually, but Query API might differ.
                class=class="hl-string">"hl-comment"># If using links, we switch to GET for the next page.
                class=class="hl-string">"hl-comment"># (Simplified logic: In production, robustly handle the href)
            else:
                has_more = False
        
        print(fclass="hl-string">"Fetched {len(items)} rows. Total: {len(all_rows)}")
        time.sleep(1) class=class="hl-string">"hl-comment"># Rate limit protection

    return pd.DataFrame(all_rows)

class=class="hl-string">"hl-comment"># === RUN ===
if __name__ == class="hl-string">'__main__':
    df = get_suiteql_results(suiteql_query)
    
    class=class="hl-string">"hl-comment"># Post-processing
    if not df.empty:
        class=class="hl-string">"hl-comment"># Ensure numeric formats
        df[class="hl-string">'invoiceamount'] = pd.to_numeric(df[class="hl-string">'invoiceamount'], errors=class="hl-string">'coerce').fillna(0)
        
        class=class="hl-string">"hl-comment"># Save
        filename = class="hl-string">'netsuite_ap_event_log.csv'
        df.to_csv(filename, index=False)
        print(fclass="hl-string">"Success! Saved {len(df)} rows to {filename}")
    else:
        print(class="hl-string">"No data found.")

¿Listo para comenzar?

Comience hoy su recorrido de Process Mining aplicando este Template a su entorno de NetSuite. Descubra oportunidades de eficiencia y optimice de inmediato sus Workflows de pago.

Volver a la guía de mejora Descargar Template

Optimice hoy el procesamiento de pagos de sus cuentas por pagar

Identifique cuellos de botella y reduzca el tiempo de ciclo un 30 %.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. La configuración solo tarda unos minutos.

Su Template de datos para el procesamiento de pagos de cuentas por pagar

Su Template de datos para el procesamiento de pagos de cuentas por pagar

Atributos del procesamiento de pagos de cuentas por pagar

Actividades del procesamiento de pagos de cuentas por pagar

Guías de extracción

Exportación de Saved Search de NetSuite para transacciones de cuentas por pagar

Pasos

Configuración

a Consulta de ejemplo config

Extracción de SuiteQL mediante ODBC de SuiteAnalytics Connect

Pasos

Configuración

a Consulta de ejemplo sql

ETL de Python mediante la API REST de SuiteTalk con SuiteQL

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy el procesamiento de pagos de sus cuentas por pagar

Su Template de datos para el procesamiento de pagos de cuentas por pagar

Su Template de datos para el procesamiento de pagos de cuentas por pagar

Atributos del procesamiento de pagos de cuentas por pagar

Actividades del procesamiento de pagos de cuentas por pagar

Guías de extracción

Exportación de Saved Search de NetSuite para transacciones de cuentas por pagar

Pasos

Configuración

a Consulta de ejemplo config

Extracción de SuiteQL mediante ODBC de SuiteAnalytics Connect

Pasos

Configuración

a Consulta de ejemplo sql

ETL de Python mediante la API REST de SuiteTalk con SuiteQL

Pasos

Configuración

a Consulta de ejemplo python

¿Listo para comenzar?

Optimice hoy el procesamiento de pagos de sus cuentas por pagar

Valoramos su privacidad