Calcular el saldo con mi historial de transacciones de PayPal descargado

Question

PayPal le permite descargar todas las transacciones de su cuenta, desde que se abrió la cuenta, a un archivo CSV para que lo procese como desee.

Deseo determinar el actual saldo de la cuenta.

He importado todo mi PayPal a una única tabla de base de datos SQL para poder ejecutar consultas en ella para realizar cálculos y explorar los datos. De todos modos, hay demasiados datos para Excel.

El esquema de mi tabla de base de datos contiene todos los campos del archivo CSV, pero estos campos en particular destacan:

DateTime,
Type,
Status,
Gross,
Fee,
Net,
TransactionId,
ReferenceTransactionId

Lamentablemente, PayPal no proporciona ningún documento de especificación que explique el significado de ciertos valores (los CSV de transacciones son diferentes a las IPN de PayPal).

Mi primera observación con los datos es que PayPal reescribe la historia . Uno supondría que PayPal funcionaría como un banco en el sentido de que las transacciones son inmutables una vez escritas en el registro: por ejemplo, si se añaden 50 dólares a su cuenta bancaria pero unos días después la transacción se anula/reembolsa, uno esperaría ver:

Date         Amount     Description
2016-01-04    50.00     $50 deposit
2016-01-07   -50.00     $50 deposit refunded

Si haces un SUM(Amount) obtendrá 0.00 - porque estas dos transacciones resultaron en un cero neto.

Sin embargo, con PayPal la experiencia es esta:

1. Paso 1: Descargar el CSV de las transacciones de enero

2. Paso 2: El archivo CSV contendrá lo siguiente (parafraseado):

   Date         Amount     Description    Status
   2016-01-04   50.00      $50 deposit    Completed

3. Paso 3: Volver a descargar el CSV de las transacciones de enero unos días después

4. Paso 4: Observe que el archivo CSV seguirá conteniendo sólo una fila, pero con el siguiente aspecto:

   Date         Amount     Description    Status
   2016-01-04   50.00      $50 deposit    Canceled

...lo que significa que siempre hay que volver a descargar el historial que se remonta al menos a un año atrás para captar cualquier transacción reescrita y volver a importarla a la tabla de la base de datos.

Se puede argumentar que no es un problema - solo hay que realizar un SUM donde Status <> 'Canceled' - y probablemente sea la solución correcta, excepto...

• He identificado más de 47 combinaciones diferentes de Type y Status valores, lo que hace más difícil determinar cuáles de ellos deben incluirse en el SUM o no:

  +-----------------------------------------+-----------+
  | Type                                    | Status    |
  +-----------------------------------------+-----------+
  | Add Funds from a Bank Account           | Completed |
  | Authorization                           | Completed |
  | Cancelled Fee                           | Completed |
  | Chargeback Reimbursement                | Completed |
  | Chargeback Settlement                   | Completed |
  | Donation Received                       | Canceled  |
  | Donation Received                       | Cleared   |
  | Donation Received                       | Completed |
  | Donation Received                       | Refunded  |
  | Donation Received                       | Reversed  |
  | Donation Received                       | Uncleared |
  | Donation Sent                           | Completed |
  | eCheck Sent                             | Cleared   |
  | Express Checkout Payment Sent           | Completed |
  | Mobile Payment Received                 | Completed |
  | Payment Received                        | Completed |
  | Payment Review                          | Cleared   |
  | Payment Review                          | Placed    |
  | Payment Sent                            | Completed |
  | Payment Sent                            | Refunded  |
  | PayPal card confirmation refund         | Completed |
  | Recurring Payment Received              | Completed |
  | Recurring Payment Received              | Refunded  |
  | Refund                                  | Completed |
  | Request Received                        | Canceled  |
  | Request Received                        | Pending   |
  | Reversal                                | Completed |
  | Shopping Cart Payment Sent              | Completed |
  | Temporary Hold                          | Placed    |
  | Temporary Hold                          | Removed   |
  | Update to Add Funds from a Bank Account | Completed |
  | Update to eCheck Received               | Canceled  |
  | Update to eCheck Received               | Cleared   |
  | Update to eCheck Received               | Updated   |
  | Update to eCheck Sent                   | Cleared   |
  | Update to Reversal                      | Canceled  |
  | Web Accept Payment Received             | Canceled  |
  | Web Accept Payment Received             | Cleared   |
  | Web Accept Payment Received             | Completed |
  | Web Accept Payment Received             | Held      |
  | Web Accept Payment Received             | Refunded  |
  | Web Accept Payment Received             | Reversed  |
  | Web Accept Payment Received             | Uncleared |
  | Web Accept Payment Sent                 | Completed |
  | Withdraw Funds to a Bank Account        | Completed |
  | Withdraw Funds to a Bank Account        | Pending   |
  | Withdraw Funds to Bank Account          | Completed |
  +-----------------------------------------+-----------+

• PayPal reescribirá algunos transacciones, pero otras veces añadirán una transacción relacionada a su historial (apuntando a la transacción original en el ReferenceTxnId ), y a veces hacen ambas cosas.

• Y el ReferenceTxnId se utiliza para representar una jerarquía de transacciones de varios niveles, es decir, la transacción de compra 1 podría tener una transacción de reembolso relacionada 2 y la transacción 2 podría tener una operación de contrareembolso 3 esa referencia 2 y no 1 ).

  • Tuve que escribir una consulta CTE recursiva para recuperar el "árbol de transacciones" de una determinada transacción root.

Otras curiosidades que he observado son:

• PayPal utilizando el Name columna (destinada al nombre del cliente) a a veces almacenan la información del tipo de transacción, y el From Email (la dirección de correo electrónico del cliente) para contener las propias direcciones de correo electrónico de PayPal, como riskmanagement@x.com .
• Uso inexplicable y aparentemente incoherente de:
  • " Canceled ", frente a " Refunded ", frente a " Reversed ", frente a " Removed "
  • " Completed ", frente a " Cleared ", frente a " Placed "
• Y cuál es la diferencia entre:
  • Type: Web Accept Payment Received, Status: Refunded
  • ...y...
  • Type: Refund, Status: Completed

...¿por qué PayPal es tan obtuso?

Este es un ejemplo real de una serie de transacciones que importé. Mi pregunta para usted, el lector, es que asumiendo que estos son los sólo transacciones en una cuenta, ¿cuál es el saldo final de la cuenta PayPal?

DateTimeUtc           Name                         Type                            Status       Gross     Fee      Net      FromEmail              TxnId     ReferenceTxnId
------------------    -------------------------    ----------------------------    ----------   -----    -----    -----     --------------------   ----      --------------
2014-06-15 17:47:30   (Customer name)              Web Accept Payment Received     Completed    20.00     -1.05    18.95    customer@hotmail.com   1111          
2014-07-02 03:41:22   (Customer name)              Temporary Hold                  Removed     -20.00      1.05   -18.95    customer@hotmail.com   2222      1111
2014-07-16 21:00:58   Reversal                     Update to Reversal              Canceled     18.95      0.00    18.95    customer@hotmail.com   3333      2222
2014-07-16 21:00:59   Chargeback Settlement        Chargeback Settlement           Completed   -20.00    -20.00   -40.00    riskmanagement@x.com   4444      1111
2014-10-01 13:32:55   Chargeback Reimbursement     Chargeback Reimbursement        Completed    20.00      0.00    20.00    riskmanagement@x.com   5555      1111

Dependiendo de cómo lo interpretes, podría ser:

• - 1.05
• 17.90
• -20.00

...¡y yo mismo no tengo ni idea de cuál es la respuesta correcta!

Answer 1

Yo también me he encontrado con esto, y casi todos los meses las transacciones descargadas no coinciden con los saldos de los extractos. Según mi experiencia, no es necesariamente porque las transacciones cambien posteriormente; he visto discrepancias por las siguientes razones:

1. Cuando se procesa un reembolso, la parte de la tarifa fija no es reembolsable, y esto no se incluye en la transacción descargada. En su ejemplo de $20 refund, $ 0,05 de los 1,05 dólares es la parte de la comisión fija y no se te devuelve, por lo que tu saldo real estará desfasado en 5 céntimos. (No tengo ni idea de por qué la cantidad real no se refleja en la transacción descargada. Sin embargo, es correcto en el extracto detallado).
2. Cuando un cliente presenta una disputa con su proveedor de tarjeta de crédito, PayPal se pondrá en contacto con usted y le informará de ello, y habrá una opción para aprobar el reembolso. Si lo aprueba, PayPal le devolverá el dinero y también le cobrará $20, and that fee will not show up on your downloaded transactions. (At least it didn't for me the one time it happened.) BTW, instead of approving the refund for the CC dispute, if it was paid to you in the last 60 days you should be able to just refund the transaction the normal way and avoid the $ 20 de tasa. (No sé por qué la gente disputa un cargo con su compañía de tarjetas de crédito en lugar de enviar un correo electrónico al servicio de atención al cliente y pedir un reembolso primero).

¿Y qué hacer al respecto? Hasta ahora he estado conciliando manualmente con el extracto detallado cada mes. En mi caso, los reembolsos son escasos, por lo que las diferencias son fáciles de detectar.

Nota al margen : Veo que está utilizando el sistema de micropagos. Ya que no tienes el predeterminado estoy seguro de que sabes que PayPal ofrece 2 horarios diferentes:

1. 0,30 $ + 2,9% (normal)
2. 0,05 + 5% (micropagos)

Un poco de álgebra rápida nos dice que si su artículo medio vendido es más de $11.90, then you are better off with option 1. You are apparently using option 2 even though all of the charges in your example are $ 20 o más. Si sus cifras de ejemplo son indicativas de su venta media, podría probablemente ahorre algo de dinero cambiando a la opción 1. Tenga en cuenta que la razón por la que digo probablemente en lugar de definitivamente es porque cuando hay reembolsos no se recupera la cuota fija. Así que ahora mismo sólo pierdes 5 céntimos por devolución, mientras que perderías 30 céntimos por devolución si te cambias. Tendrá que hacer números con su precio medio de venta y considerar su tasa de reembolso para saber qué es lo mejor para usted.

Answer 2

Gran esfuerzo en la pregunta.

Todo lo que puedo aconsejar es: Si paypal no proporciona la tabla de asignación (Tipo, Estado, Crédito/Débito) tendrás que construirla tú mismo sobre la marcha.

Yo lo abordaría de esta manera: Tu tabla de mapeo SQL tiene entradas de Crédito/Débito para todas las combinaciones conocidas y la entrada de Crédito/Débito sería -1 para todas. Luego, al obtener una lista de transacciones, tendrá que mostrar todos los resultados posibles al usuario, que marcará el correcto (comparándolo con el saldo). La entrada de crédito/débito se almacenaría si es única. De este modo, aprenderá cuáles son las posibles combinaciones a lo largo del tiempo.

Es un problema a la enésima potencia, así que tal vez se pueda empezar con un pequeño número de transacciones primero. Supongo que se puede aumentar muy rápidamente.

Será un experimento interesante...

Answer 3

Recientemente necesitaba calcular un mejor balance que nos permitiera elegir qué incluir en la suma calculada sin perder información, así que volví a tratar este tema y me complace decir que he encontrado una solución que funciona (al menos para nuestros datos - puede que tengas transacciones que este código no reconozca, pero siempre puedes modificarlo para que coincida).

Mi solución fue escrita de forma nativa para MS SQL Server 2008 o posterior, utiliza un UDF escalar, un VIEW y un agregado con ventana ( SUM OVER (ORDER BY ...) lo que significa que debería ser casi compatible con la sintaxis de PostgreSQL. MySQL no soporta OVER pero se puede realizar una suma corrida usando una variable con adición aritmética directamente en el SELECT cláusula.

1. Cree una tabla de base de datos con este esquema (siéntase libre de excluir las columnas que no le interesen, como Option1Name ):

   CREATE TABLE dbo.PayPalHistory (
       \[RowId\]                     bigint         NOT NULL IDENTITY(1,1) PRIMARY KEY,
       \[DateTimeUtc\]               datetime       NOT NULL,
       \[Name\]                      nvarchar(100)  NOT NULL,
       \[Type\]                      nvarchar( 50)  NOT NULL,
       \[Status\]                    nvarchar( 50)  NOT NULL,
       \[Gross\]                     money              NULL,
       \[Fee\]                       money              NULL,
       \[Net\]                       money              NULL,
       \[FromEmail\]                 nvarchar(255)  NOT NULL,
       \[ToEmail\]                   nvarchar(255)  NOT NULL,
       \[TxnId\]                     varchar(50)    NOT NULL,
       \[CounterPartyStatus\]        varchar(50)    NOT NULL,
       \[AddressStatus\]             varchar(50)    NOT NULL,
       \[ItemTitle\]                 nvarchar(255)  NOT NULL,
       \[ItemId\]                    nvarchar(50)   NOT NULL,
       \[ShippingAndHandlingAmount\] money              NULL,
       \[InsuranceAmount\]           money              NULL,
       \[SalesTax\]                  money              NULL,
       \[Option1Name\]               nvarchar(50)   NOT NULL,
       \[Option1Value\]              nvarchar(50)   NOT NULL,
       \[Option2Name\]               nvarchar(50)   NOT NULL,
       \[Option2Value\]              nvarchar(50)   NOT NULL,
       \[AuctionSite\]               nvarchar(50)   NOT NULL,
       \[BuyerId\]                   nvarchar(50)   NOT NULL,
       \[ItemUrl\]                   nvarchar(50)   NOT NULL,
       \[ClosingDate\]               nvarchar(50)   NOT NULL,
       \[EscrowId\]                  nvarchar(50)   NOT NULL,
       \[InvoiceId\]                 nvarchar(50)   NOT NULL,
       \[ReferenceTxnId\]            nvarchar(50)   NOT NULL,
       \[InvoiceNumber\]             nvarchar(50)   NOT NULL,
       \[CustomNumber\]              nvarchar(50)   NOT NULL,
       \[ReceiptId\]                 nvarchar(50)   NOT NULL,
       \[Balance\]                   money              NULL,
       \[AddressLine1\]              nvarchar(255)  NOT NULL,
       \[AddressLine2\]              nvarchar(50)   NOT NULL,
       \[AddressTownCity\]           nvarchar(50)   NOT NULL,
       \[AddressState\]              nvarchar(50)   NOT NULL,
       \[AddressZip\]                nvarchar(50)   NOT NULL,
       \[AddressCountry\]            nvarchar(50)   NOT NULL,
       \[ContactPhoneNumber\]        nvarchar(50)   NOT NULL
   )

   • Crear un UNIQUE índice sobre TxnId - se podría usar como llave primaria, supongo.

   • Podría estar tentado de crear una relación de clave extranjera entre ReferenceTxnId y TxnId Sin embargo, esto fallará si se impone: tenemos muchas transacciones en las que ReferenceTxnId apunta a una Transacción que no existe. Esto suele ocurrir en el caso de [Type] = 'Web Accept Payment Received' AND [Status] = 'Canceled' .

   • También tenemos algunos valores de TransactionId de más de 17 caracteres: algunos TransactionIds comienzan con " U- " - todas las solicitudes de dinero pendientes, sospecho que esto indica que la transacción está "inacabada".

2. Vuelva a descargar todos los archivos CSV del historial de PayPal para tener las últimas actualizaciones retroactivas.

   • Algunas cuentas de PayPal obtienen el historial "completo" con las 41 columnas, pero algunas cuentas sólo obtienen algunas columnas en los archivos CSV descargables. Mi cuenta comercial recibe todas las columnas, pero mi cuenta personal no. Compruebe primero antes de continuar.

3. Importe estos archivos CSV a este PayPalHistory mesa.

   • Tendrá que manipular un poco los datos para importarlos, como por ejemplo convertir los valores separados de Fecha y Hora en un único valor UTC DateTime (compruebe el Time Zone en el archivo CSV).

4. Haga una simple prueba para ver lo malos que son los datos por defecto de PayPal:

   1. Haga SELECT TOP 1 [Balance] FROM PayPalHistory ORDER BY DateTimeUtc para obtener el saldo oficial tal y como lo informa PayPal en su archivo CSV importado. Debe coincidir con el saldo reportado en su tablero de PayPal.com.
   2. Haga SELECT SUM( [Net] ) FROM PayPalHistory para ver la suma ingenua de todas las transacciones que ha importado - supongo que verá un número muy diferente al que vio en el paso anterior.

   3. Para saber de dónde provienen las diferencias, ejecute esta consulta:

      SELECT
          \*,
          SUM( \[Net\] ) OVER ( ORDER BY DateTimeUtc, RowId ) AS RunningSum,
          NULLIF( SUM( \[Net\] ) OVER ( ORDER BY DateTimeUtc, RowId ) - \[Balance\], 0 ) AS RunningSumError
      FROM
          PayPalHistory
      ORDER BY
          DateTimeUtc,
          RowId

      (El ORDER BY (...), RowId es para garantizar un ordenamiento coherente cuando varias transacciones comparten la misma marca de tiempo)

      Al desplazarse por los resultados, verá cómo los ingenuos SUM se desprende del cálculo oficial de PayPal Balance columna.

5. Así que, como puede ver, el Net El valor de la columna no siempre es fiable; lo que necesitamos es generar nuestro propio " EffectiveNet "que es preciso, es decir, el valor es 0.00 para las filas que no afectan al equilibrio, en lugar de ser lo que son ahora.

6. El problema es que, dada una única fila de datos (como cualquier fila de la tabla de ejemplo de mi pregunta original) no tenemos forma de saber intrínsecamente cuál es su " EffectiveNet " es.

7. He ideado dos funciones para ayudar a resolver este problema, la primera función sólo mira el ReferenceTxnId , Type y Status y genera valores precisos para la gran mayoría de las filas; de hecho, en nuestro conjunto de datos sólo había una fila para la que este enfoque no funcionaba. Te recomiendo que pruebes este método primero y compares el valor de la suma acumulada para asegurarte de que funciona con tus datos:

   CREATE FUNCTION \[dbo\].\[GetEffectiveNet\] 
   (
       @net money,
       @type nvarchar(50),
       @status nvarchar(50),
   
       @refTxnId varchar(50)
   )
   RETURNS money
   AS
   BEGIN
       RETURN CASE @type
           WHEN 'Add Funds from a Bank Account' THEN
   
               -- When funds are added because of a send-money transaction (because funds are needed to meet the minimum balance required to send the money)
               -- then the balance-change takes-effect immediately.
               -- but when funds are added by-request, without a parent outgoing transaction, it waits until the 'Update to Add Funds from a Bank Account' txn for the balance-change.
               CASE @refTxnId
                   WHEN '' THEN NULL
                   ELSE         @net
               END
   
           WHEN 'Update to eCheck Received' THEN 
   
               CASE @status
                   WHEN 'Canceled' THEN NULL
                   ELSE                 @net
               END
   
           WHEN 'Web Accept Payment Received' THEN
   
               CASE @status
                   WHEN 'Canceled' THEN NULL
                   WHEN 'Cleared'  THEN NULL
                   ELSE                 @net
               END
   
           WHEN 'Cancelled Fee' THEN
   
               CASE @status
                   WHEN 'Completed' THEN NULL
                   ELSE                  @net
               END
   
           WHEN 'Update to eCheck Sent' THEN
               NULL
   
           WHEN 'Donation Received' THEN
   
               CASE @status
                   WHEN 'Cleared'  THEN NULL -- Weirdly, "Donation Received"/"Cleared" only take effects after the follow-up "Update to eCheck Received", but "Web Accept Payment Received"/"Cleared" takes effect immediately. I don't know why PayPal seems to place a kind-of hold on Donations but not WebAccept, weird.
                   WHEN 'Canceled' THEN NULL
                   ELSE            @net
               END
   
           WHEN 'Authorization' THEN
   
               CASE @status
                   WHEN 'Completed' THEN NULL
                   ELSE             @net
               END
   
           WHEN 'Request Received' THEN
   
               CASE @status
                   WHEN 'Pending'  THEN NULL
                   WHEN 'Canceled' THEN NULL
                   ELSE            @net
               END
   
           ELSE
               @net
       END
   
   END

Puede utilizar esta función en la consulta como se indica a continuación, con la esperanza de que le proporcione una cifra exacta de la suma y el saldo al final:

<pre>
SELECT
    *,
    SUM( dbo.GetEffectiveNet( [Net], [Type], [Status], [ReferenceTxnId] ) ) OVER ( ORDER BY DateTimeUtc, RowId ) AS RunningSum,
    NULLIF( SUM( dbo.GetEffectiveNet( [Net], [Type], [Status], [ReferenceTxnId] ) ) OVER ( ORDER BY DateTimeUtc, RowId ) - [Balance], 0 ) AS RunningSumError
FROM
    PayPalHistory
ORDER BY
    DateTimeUtc,
    RowId
</pre>

8.

• En nuestros datos, tuvimos algunos casos en los que el Type , Status y la falta de ReferenceTxnId la información no era suficiente para determinar el " EffectiveNet ", concretamente la transacción fue una " Recurring Payment Received " - que debería haber tenido un EffectiveNet de 0.00 sin embargo, no había nada que la distinguiera de otras Recurring Payment Received los pagos.
• Escribí una consulta CTE (Common Table Expression) recursiva para recuperar todas las filas descendientes de un determinado TxnId (siguió recursivamente a todos los ReferenceTxnId valores) y vi que esta fila en particular tenía un solo hijo con [Type] = 'Update to eCheck Received' AND [Status] = 'Updated' Y fue en esta fila de seguimiento donde se cambió el balance.
• Escribí una función más robusta que calcula el EffectiveNet de manera que también se tengan en cuenta las filas de niños. Afortunadamente este era el único caso que necesitaba manejar que requiere específicamente la inspección de las transacciones child - todas las demás transacciones pueden ser manejadas de manera muy similar a la anterior.

• Así que aquí está la función reescrita (se ejecuta más lentamente en comparación con la función anterior) que es más precisa

  CREATE FUNCTION \[dbo\].\[GetEffectiveNet\_Improved\] 
  (
      @net money,
      @type nvarchar(50),
      @status nvarchar(50),
  
      @txnId varchar(50),
      @refTxnId varchar(50),
  
      @relatedCount int
  
  )
  RETURNS money
  AS
  BEGIN
  
  RETURN CASE @refTxnId
      WHEN '' THEN -- no referenced parent, this is a root transaction
  
          CASE @relatedCount
  
              WHEN 0 THEN
                  CASE @status
                      WHEN 'Pending'  THEN NULL
                      WHEN 'Canceled' THEN NULL
                      ELSE                 @net
                  END
  
              ELSE
                  -- @relatedCount > 0, Money Sent
  
                  CASE WHEN @net = 0, Money Received
  
                      CASE @type
                          WHEN 'Add Funds from a Bank Account' THEN
  
                              CASE @status
                                  WHEN 'Completed' THEN NULL
                                  ELSE                 @net
                              END
  
                          ELSE
  
                              CASE @status
                                  WHEN 'Cleared'  THEN NULL
                                  WHEN 'Canceled' THEN NULL
                                  ELSE 
  
                                  -- Need to manually check the tree at this point.
                                  -- Our example is (type: "Recurring Payment Received", status: "Completed", net: +18.95)
                                  -- There is nothing in the row to suggest the payment should not be considered immediately (i.e. it doesn't say it's an eCheck), however there WAS/IS a follow-up transaction that's (type: "Update to eCheck Received", status: "Updated") and this is the TXN that adjusts the balance.
                                  -- So to handle this case, we need to inspect the related transactions and return NULL if the follow-up is 'Updated'
  
                                  -- I need more data to verify this assumption works, until then I have to special-case it:
  
                                      CASE
                                          WHEN @relatedCount = 1 AND ( SELECT \[Status\] FROM PayPalHistory WHERE ReferenceTxnId = @txnId ) = 'Updated'
                                              THEN NULL
                                          ELSE
                                              @net
                                      END -- CASE WHEN @relatedCount = 1 AND ...
                              END -- CASE @status
                      END -- CASE @type
                  END -- CASE WHEN @net  '', a child row
  
          CASE WHEN NOT EXISTS( SELECT 1 FROM PayPalHistory WHERE TxnId = @refTxnId ) THEN
  
              CASE @type
                  WHEN 'Cancelled Fee' THEN
  
                      CASE @status
                          WHEN 'Completed' THEN NULL
                          ELSE                  @net
                      END
  
                  ELSE @net
              END
  
          ELSE
  
              CASE @type
                  WHEN 'Update to eCheck Received' THEN
  
                      CASE @status
                          WHEN 'Cleared'  THEN @net
                          WHEN 'Canceled' THEN NULL
                          WHEN 'Updated'  THEN @net
                          ELSE                 @net
                      END
  
                  WHEN 'Update to eCheck Sent' THEN
  
                      CASE @status
                          WHEN 'Cleared'  THEN NULL -- When sending money, net is deducted from balance immediately after sending, before it clears; whereas when receceiving it's added only when it clears, not when it first arrives.
                          ELSE                 @net
                      END
  
                  WHEN 'Add Funds from a Bank Account' THEN
  
                      CASE @status
                          WHEN 'Completed'  THEN @net
                          ELSE                   @net
                      END
  
                  ELSE @net
              END
  
          END
  
  END
  
  END

9. Y aquí está la vista que lo une todo:

   CREATE VIEW PayPalHistoryWithAccurateBalance AS
   
   SELECT
       \*
   FROM
   (
       SELECT
           \*,
           SUM( EffectiveNet ) OVER ( ORDER BY DateTimeUtc, RowId ) AS RunningSum,
       FROM
       (
           SELECT
               \*,
               dbo.GetEffectiveNet\_Improved(
                   \[Net\],
                   \[Type\],
                   \[Status\],
                   \[TxnId\],
                   \[ReferenceTxnId\],
                   ( SELECT COUNT(\*) FROM PayPalHistory AS \[related\] WHERE \[related\].ReferenceTxnId = PayPalHistory.TxnId )
               ) AS EffectiveNet
           FROM
               PayPalHistory
       ) AS \[inner\]
   ) AS \[outer\]

10. Se usa así:

    SELECT
        \*
    FROM
        dbo.PayPalHistoryWithAccurateBalance
    ORDER BY
        DateTimeUtc,
        RowId

Espero que esto ayude a cualquiera que quiera llevar una contabilidad precisa con los archivos del historial de transacciones de PayPal.