Information Systems:AR Detail Report - Revision history

Norwinu: /* Caveats */

2019-02-07T23:18:22Z

Caveats

Norwinu at 23:14, 7 February 2019

2019-02-07T23:14:01Z

Norwinu at 23:09, 7 February 2019

2019-02-07T23:09:55Z

Norwinu at 22:30, 7 February 2019

2019-02-07T22:30:08Z

Norwinu: Created page with "A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The utility is called IN2_ARCUST.PGM i..."

2019-02-07T22:25:55Z

Created page with "A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The utility is called IN2_ARCUST.PGM i..."

New page

A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The utility is called IN2_ARCUST.PGM in Infonet. The query logic behind this report attempts to simulate the business logic that runs when the system produces an invoice, because this data is not logged to the database (rather, it is calculated ad-hoc during invoice generation). As the report is recalculating data and working around the limitations of not having the actual data to work with, this page details the caveats and flaws of this report.

==Files==
These are the files implicated in the query in order to be able to recalculate the values that would normally show up on an A/R statement (which this report is supposed).

* Invoice lines (for items) are kept in SROISDPL.
* Surcharge invoice lines are kept in SROISDSU.
* Admin fee invoice lines are kept in SROISA.
* The tax amount and discounts for invoice lines are logged to UZIVLIL1. This is a custom table that presumably was too close in proximity to base functionality so it was put in the ASW library (UP1480BFVA) instead of UWDASWPRDD.
* AR transaction lines are stored in SRODTA.

==Query Logic==
Trying to recreate data and simulate application logic using query logic will be prone to error. These are some of the potential issues regarding this report.

* Invoices and credit notes are kept in the same file, but with positive values. Another field - invoice type - determines whether the value should be positive or negative.
* Discounts are calculated during invoice generation according to terms code and invoice. The discount amount for the invoice line is logged to UZIVLIL1, but if a line follow.

[[Category: Reports]]

@@ Line 11: / Line 11: @@
 ==Caveats==
-Trying to recreate data and simulate application logic using query logic will be prone to error. These are some of the potential issues regarding this report.
+Trying to recreate data and simulate application logic using query logic is prone to error. These are some of the potential issues regarding this report:
 * Invoices and credit notes are kept in the same file, both with positive amounts. Another field - invoice type - must therefore be used to determine whether the amount should be reported as positive (sales invoice) or negative (credit note).
-* Discounts are applied to the invoice total, but the invoice total cannot be obtained by adding the amounts as they exist in the invoice table, because the program rounds them first when producing an invoice. Each invoice line is first rounded to 2 decimal places, then summed. The discount is then applied to this amount. These rounded amounts are not logged. The report calculates other values based on the net amounts that are stored to 4 decimal places, hence there will ultimately be discrepancies.
+* Discounts are applied to the invoice total, but the invoice total cannot be obtained by adding the amounts as they exist in the invoice table, because the program rounds the amounts first when producing an invoice i.e. aach invoice line is first rounded to 2 decimal places from 4, then summed. The discount is then applied to this amount. The rounded invoice amounts are not logged. The report calculates other values based on the amounts from the table that are stored to 4 decimal places, hence ultimately yielding discrepancies from the actual invoices.
 * The discount amount per invoice line is also not logged. Instead the total discount amount (for the invoice) is written to each invoice line in UZIVLIL1. Therefore, the discount amount per line/item must be recalculated by the query, since it is not logged anywhere.
 * The previous point is further complicated by surcharge and admin fees, some of which are discounted but at the header level instead of the item (see next point).

← Older revision		Revision as of 23:14, 7 February 2019
Line 1:		Line 1:
−	A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The ~~utility~~ is called IN2_ARCUST.PGM ~~in Infonet~~. The query logic behind this report attempts to simulate the customized business logic that runs when the system produces an invoice, because this data is not logged to the database (~~rather,~~ it is ~~calculated~~ ~~ad-hoc~~ ~~during~~ ~~invoice~~ ~~generation~~). As the report is ~~recalculating~~ ~~data~~ ~~and~~ ~~working~~ around ~~the~~ ~~limitations~~ of ~~not~~ ~~having~~ ~~the~~ ~~actual~~ ~~data~~ to ~~work~~ ~~with,~~ ~~this~~ ~~page~~ ~~details~~ the caveats and flaws of ~~this report~~.	+	A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The resulting SQL was converted to an Infonet utility called IN2_ARCUST.PGM. The query logic behind this report attempts to simulate the customized business logic that runs when the system produces an invoice, because this data is not logged to the database (in a usable manner) after it is generated and output to a printable document (the actual invoice). As the report is doing recalculations to work around data that doesn't physically (physidigitally?) exist, this page was written to point out some of the caveats and flaws about it.

	==Files==		==Files==

@@ Line 10: / Line 10: @@
 * AR transaction lines are stored in SRODTA.
-==Query Logic==
+==Caveats==
 Trying to recreate data and simulate application logic using query logic will be prone to error. These are some of the potential issues regarding this report.
-* Invoices and credit notes are kept in the same file, but with positive values. Another field - invoice type - determines whether the value should be positive or negative.
+* Invoices and credit notes are kept in the same file, both with positive amounts. Another field - invoice type - must therefore be used to determine whether the amount should be reported as positive (sales invoice) or negative (credit note).
 [[Category: Reports]]

@@ Line 1: / Line 1: @@
-A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The utility is called IN2_ARCUST.PGM in Infonet. The query logic behind this report attempts to simulate the business logic that runs when the system produces an invoice, because this data is not logged to the database (rather, it is calculated ad-hoc during invoice generation). As the report is recalculating data and working around the limitations of not having the actual data to work with, this page details the caveats and flaws of this report.
+A special type of A/R report was created (upon shareholder request) to provide a list of A/R transactions broken down to the item level. The utility is called IN2_ARCUST.PGM in Infonet. The query logic behind this report attempts to simulate the customized business logic that runs when the system produces an invoice, because this data is not logged to the database (rather, it is calculated ad-hoc during invoice generation). As the report is recalculating data and working around the limitations of not having the actual data to work with, this page details the caveats and flaws of this report.
 ==Files==
-These are the files implicated in the query in order to be able to recalculate the values that would normally show up on an A/R statement (which this report is supposed).
+These are the files implicated in the query in order to be able to produce the desired results:
-* Invoice lines (for items) are kept in SROISDPL.
+* Invoice lines (for items) from SROISDPL.
-* Surcharge invoice lines are kept in SROISDSU.
+* Surcharge invoice lines from SROISDSU.
-* Admin fee invoice lines are kept in SROISA.
+* Admin fee invoice lines from SROISA.
-* The tax amount and discounts for invoice lines are logged to UZIVLIL1. This is a custom table that presumably was too close in proximity to base functionality so it was put in the ASW library (UP1480BFVA) instead of UWDASWPRDD.
+* The tax amount and discounts for invoice lines are logged to UZIVLIL1. This is a custom table that presumably was too close in proximity to base functionality that it was put in the ASW library (UP1480BFVA) instead of UWDASWPRDD.
 * AR transaction lines are stored in SRODTA.