Dynamics GP Connection Details

Introduction

Connector Version

This documentation is based on version 23.0.8663 of the connector.

Get Started

Microsoft Dynamics GP Version Support

The connector leverages the Dynamics GP Web services APIs to access Microsoft Dynamics GP 2010, 2013, and 2015. Web services must be enabled for your instance.

Establish a Connection

Connect to Microsoft Dynamics GP

To connect set URL to the Web services endpoint; for example, http://{servername}:{port}/Dynamics/GPService. Additionally, set CompanyId to the unique identifier of the company you are connecting to. You can obtain this value by querying the Company table and leaving the property empty.

Authenticate to Microsoft Dynamics GP

The Microsoft Dynamics GP data source supports the following authentication methods:

• Anonymous Authentication
• WS-Security (WSS) Authentication
• Basic Authentication
• NTLM User Authentication
• Digest
• Negotiate (Kerberos)

Anonymous Authentication

In some situations, you can connect to Microsoft Dynamics GP without setting any authentication connection properties. To do so, set the AuthScheme to None, and you are ready to connect.

WS-Security (WSS)

Set the User and Password to connect and set AuthScheme to WSS.

Basic

Set the User and Password to connect and set AuthScheme to Basic.

Windows (NTLM)

Set the Windows User and Password to connect and set AuthScheme to NTLM.

Digest

Set the User and Password to connect and set AuthScheme to Digest.

Kerberos

See Using Kerberos for details on how to authenticate with Kerberos.

Fine Tuning Data Access

The connector returns data summaries by default to save performance. Set LookupIds to true to return details such as line items; however, note that entities must be retrieved one at a time.

Use Kerberos

This section shows how to use the connector to authenticate using Kerberos.

Kerberos

To authenticate to Microsoft Dynamics GP using Kerberos, set the following properties:

• AuthScheme: Set this to NEGOTIATE.
• KerberosKDC: Set this to the host name or IP Address of your Kerberos KDC machine.
• KerberosRealm: Set this to the realm of the Microsoft Dynamics GP Kerberos principal. This will be the value after the '@' symbol (for instance, EXAMPLE.COM) of the principal value (for instance, ServiceName/MyHost@EXAMPLE.COM).
• KerberosSPN: Set this to the service and host of the Microsoft Dynamics GP Kerberos Principal. This is the value prior to the '@' symbol (for instance, ServiceName/MyHost) of the principal value (for instance, ServiceName/MyHost@EXAMPLE.COM).

Retrieve the Kerberos Ticket

You can use one of the following options to retrieve the required Kerberos ticket.

MIT Kerberos Credential Cache File

This option enables you to use the MIT Kerberos Ticket Manager or kinit command to get tickets. Note that you do not need to set the User or Password connection properties with this option.

1. Ensure that you have an environment variable created called KRB5CCNAME.
2. Set the KRB5CCNAME environment variable to a path pointing to your credential cache file (for instance, C:\krb_cache\krb5cc_0 or /tmp/krb5cc_0). This file is created when generating your ticket with MIT Kerberos Ticket Manager.
3. To obtain a ticket, open the MIT Kerberos Ticket Manager application, click Get Ticket, enter your principal name and password, then click OK. If successful, ticket information appears in Kerberos Ticket Manager and is stored in the credential cache file.
4. Now that you have created the credential cache file, the connector uses the cache file to obtain the Kerberos ticket to connect to Microsoft Dynamics GP.

As an alternative to setting the KRB5CCNAME environment variable, you can directly set the file path using the KerberosTicketCache property. When set, the connector uses the specified cache file to obtain the Kerberos ticket to connect to Microsoft Dynamics GP.

Keytab File

If the KRB5CCNAME environment variable has not been set, you can retrieve a Kerberos ticket using a Keytab File. To do so, set the User property to the desired username and set the KerberosKeytabFile property to a file path pointing to the keytab file associated with the user.

User and Password

If both the KRB5CCNAME environment variable and the KerberosKeytabFile property have not been set, you can retrieve a ticket using a user and password combination. To do this, set the User and Password properties to the user/password combination that you use to authenticate with Microsoft Dynamics GP.

Cross-Realm

More complex Kerberos environments may require cross-realm authentication where multiple realms and KDC servers are used (e.g., where one realm/KDC is used for user authentication and another realm/KDC is used for obtaining the service ticket).

In such an environment, set the KerberosRealm and KerberosKDC properties to the values required for user authentication. Also set the KerberosServiceRealm and KerberosServiceKDC properties to the values required to obtain the service ticket.

Important Notes

Configuration Files and Their Paths

• All references to adding configuration files and their paths refer to files and locations on the Jitterbit agent where the connector is installed. These paths are to be adjusted as appropriate depending on the agent and the operating system. If multiple agents are used in an agent group, identical files will be required on each agent.

Advanced Features

This section details a selection of advanced features of the Microsoft Dynamics GP connector.

User Defined Views

The connector allows you to define virtual tables, called user defined views, whose contents are decided by a pre-configured query. These views are useful when you cannot directly control queries being issued to the drivers. See User Defined Views for an overview of creating and configuring custom views.

SSL Configuration

Use SSL Configuration to adjust how connector handles TLS/SSL certificate negotiations. You can choose from various certificate formats; see the SSLServerCert property under "Connection String Options" for more information.

Proxy

To configure the connector using private agent proxy settings, select the Use Proxy Settings checkbox on the connection configuration screen.

Query Processing

The connector offloads as much of the SELECT statement processing as possible to Microsoft Dynamics GP and then processes the rest of the query in memory (client-side).

See Query Processing for more information.

User Defined Views

The Jitterbit Connector for Microsoft Dynamics GP allows you to define a virtual table whose contents are decided by a pre-configured query. These are called User Defined Views, which are useful in situations where you cannot directly control the query being issued to the driver, e.g. when using the driver from Jitterbit. The User Defined Views can be used to define predicates that are always applied. If you specify additional predicates in the query to the view, they are combined with the query already defined as part of the view.

There are two ways to create user defined views:

• Create a JSON-formatted configuration file defining the views you want.
• DDL statements.

Define Views Using a Configuration File

User Defined Views are defined in a JSON-formatted configuration file called UserDefinedViews.json. The connector automatically detects the views specified in this file.

You can also have multiple view definitions and control them using the UserDefinedViews connection property. When you use this property, only the specified views are seen by the connector.

This User Defined View configuration file is formatted as follows:

• Each root element defines the name of a view.
• Each root element contains a child element, called query, which contains the custom SQL query for the view.

For example:

{
    "MyView": {
        "query": "SELECT * FROM Customer WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Use the UserDefinedViews connection property to specify the location of your JSON configuration file. For example:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Define Views Using DDL Statements

The connector is also capable of creating and altering the schema via DDL Statements such as CREATE LOCAL VIEW, ALTER LOCAL VIEW, and DROP LOCAL VIEW.

Create a View

To create a new view using DDL statements, provide the view name and query as follows:

CREATE LOCAL VIEW [MyViewName] AS SELECT * FROM Customers LIMIT 20;

If no JSON file exists, the above code creates one. The view is then created in the JSON configuration file and is now discoverable. The JSON file location is specified by the UserDefinedViews connection property.

Alter a View

To alter an existing view, provide the name of an existing view alongside the new query you would like to use instead:

ALTER LOCAL VIEW [MyViewName] AS SELECT * FROM Customers WHERE TimeModified > '3/1/2020';

The view is then updated in the JSON configuration file.

Drop a View

To drop an existing view, provide the name of an existing schema alongside the new query you would like to use instead.

DROP LOCAL VIEW [MyViewName]

This removes the view from the JSON configuration file. It can no longer be queried.

Schema for User Defined Views

User Defined Views are exposed in the UserViews schema by default. This is done to avoid the view's name clashing with an actual entity in the data model. You can change the name of the schema used for UserViews by setting the UserViewsSchemaName property.

Work with User Defined Views

For example, a SQL statement with a User Defined View called UserViews.RCustomers only lists customers in Raleigh:

SELECT * FROM Customers WHERE City = 'Raleigh';

An example of a query to the driver:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Resulting in the effective query to the source:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

That is a very simple example of a query to a User Defined View that is effectively a combination of the view query and the view definition. It is possible to compose these queries in much more complex patterns. All SQL operations are allowed in both queries and are combined when appropriate.

SSL Configuration

Customize the SSL Configuration

By default, the connector attempts to negotiate SSL/TLS by checking the server's certificate against the system's trusted certificate store.

To specify another certificate, see the SSLServerCert property for the available formats to do so.

Data Model

The Jitterbit Connector for Microsoft Dynamics GP models Microsoft Dynamics GP entities in relational views, or read-only tables. The tables are determined automatically based on the metadata the connector retrieves when you connect. Any changes that you make to your Microsoft Dynamics GP account, such as creating a custom field or changing its data type, are reflected on reconnection.

Views shows some sample view definitions included in the Microsoft Dynamics GP development environment. The actual views available will depend on your account.

Executing Inserts

Some of the entities which are exposed as tables support insert operations. For example to insert a new Customer into the Customer table we execute the following query:

INSERT INTO Customer (Id, Name, Comment1, Comment2) VALUES ('TEST_CST', 'Name', 'Comment1', 'Comment2')

Executing Inserts using Temporary Tables

While inserting you may encounter columns which end with "Aggregate" keyword. These columns will accept only temporary table values. If using temporary tables, they must be defined and inserted within the same connection. Closing the connection will clear out any temporary tables in memory. For example while inserting a new SalesInvoice the sales lines need to be inserted as well. The sales lines are exposed in SalesInvoice table as the column LinesAggregate. First we have to find the child view that corresponds to the LinesAggregate column. In this case the view is SalesInvoiceLines. Using the view name for our temporary table and its columns as a reference to the sales lines attributes, we will first insert the sales lines to the temporary table. Follow the sql queries below:

INSERT INTO SalesInvoiceLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('100XLG', 'WAREHOUSE', '1', '30', 'USD')
INSERT INTO SalesInvoiceLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('M1700', 'WAREHOUSE', '1', '30', 'USD')
INSERT INTO SalesInvoice (BatchId, CustomerId, DocumentTypeKeyType, DocumentTypeId, LinesAggregate) VALUES ('CONTRACTS', 'PLAZAONE0001', 'Invoice', 'STDINV' , 'SalesInvoiceLines#TEMP')

First we add 2 sales lines into the temporary table with name "SalesInvoiceLines#TEMP". Then we are able to create a new SalesInvoice using the temporary table name as a value for the column LinesAggregate. Note: The columns LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency in the example above have to correspond to real columns in the child table otherwise it will not work.

Below you can find other query examples with or without using temp tables.

INSERT INTO Customer (Id, Name) VALUES ('TEST_CST', 'Name')

INSERT INTO CustomerAddress (SalespersonId, SalesTerritoryId, Id, KeyCustomerId, Line1, Line2, City, State, CountryRegion, Fax, Phone1, Phone2, PostalCode) VALUES ('PAUL W.', 'TERRITORY 1', 'WAREHOUSE', 'TEST_CST', '11403 45 St. South', 'Billing Dept.', 'Chicago', 'IL', 'USA', '31255501010000', '42555501010000', '00000000000000', '98052-6399')

INSERT INTO Vendor (Id, Name, Comment1, Comment2) VALUES ('test11', 'Name', 'Comment1', 'Comment2')

INSERT INTO VendorAddress (SalespersonId, SalesTerritoryId, Id, KeyVendorId, Line1, Line2, City, State, CountryRegion, Fax, Phone1, Phone2, PostalCode) VALUES ('PAUL W.', 'TERRITORY 1', 'PRIMARY', 'test11', '11403 45 St. South', 'Billing Dept.', 'Chicago', 'IL', 'USA', '31255501010000', '42555501010000', '00000000000000', '98052-6399')

INSERT INTO PayablesCreditMemo (BatchId, Id, VendorId, PurchaseAmount, PurchaseAmountCurrency, VendorDocumentNumber) VALUES ('JAN-98', 'DM6502', 'CENTRALC0001',  '100', 'USD', 'DOCUMENT 42')

INSERT INTO ApplicantApplications#TEMP (ApplicationsDateApplied, ApplicationsLastModifiedDate) VALUES ('2021-01-07T00:00:00+01:00','2021-01-07T00:00:00+01:00')
INSERT INTO Applicant (FirstName, LastName, ApplicationsAggregate) VALUES ('Test', 'Applicant', 'ApplicantApplications#TEMP')

INSERT INTO PurchaseOrderLines#TEMP (LinesQuantityOrdered, LinesVendorItemNumber, LinesWarehouseId) VALUES ('1', '100XLG', 'WAREHOUSE')
INSERT INTO PurchaseOrder (LinesAggregate, Id, VendorId) VALUES ('PurchaseOrderLines#TEMP', 'PO4056', 'ACETRAVE0001')

INSERT INTO SalesReturnLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('100XLG', 'WAREHOUSE', '1', '30', 'USD');
INSERT INTO SalesReturnLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('M1700', 'WAREHOUSE', '1', '30', 'USD');
INSERT INTO SalesReturn (BatchId, CustomerId, DocumentTypeKeyType, DocumentTypeId, LinesAggregate) VALUES ('SALES RETURNS', 'PLAZAONE0001', 'Return', 'RTN' , 'SalesReturnLines#TEMP');

Executing Delete

Some of the entities which are exposed as tables support delete operations. For example to delete a Customer from the Customer table we execute the following query:

DELETE FROM Customer WHERE Id='TEST_CST'

Executing Delete using multiple keys

Some delete operations require multiple keys in order for the query to be successful. For example to delete a CustomerAddress from the CustomerAddresses table requires both key columns the ID and the KeyCustomerId values to be set for ex:

DELETE FROM CustomerAddress WHERE Id='WAREHOUSE' AND KeyCustomerId='TEST2'

Below you can find other query examples with or without multiple keys.

DELETE FROM Applicant WHERE ApplicantId='2'

DELETE FROM SalesInvoice WHERE Id='STDINV2262'

DELETE FROM ApplicantApplication WHERE ApplicantApplicationKeyApplicantId='3' AND ApplicantApplicationKeySequenceId='1'

Executing Update

Some of the entities which are exposed as tables support update operations. For example to update a Customer from the Customer table we execute the following query:

UPDATE Customer SET Name='new test name',Comment1='new comment 1', Comment2='new comment 2' WHERE Id='TEST1'

Executing Update using multiple keys

Some update operations require multiple keys in order for the query to be successful. For example to update a CustomerAddress from the CustomerAddresses table requires both key columns the ID and the KeyCustomerId values to be set for ex:

UPDATE CustomerAddress SET Line1='new line 1', Line2='new line 2', City='new city', State='new state', Fax='111111111', Phone1='222222222', Phone2='3333333', PostalCode='235-325' WHERE KeyCustomerId='TEST1234' AND Id='WAREHOUSE'
UPDATE SalesInvoice SET CustomerId='AARONFIT0001', Date='2021-01-07T00:00:00+01:00' WHERE Id='STDINV2300' AND BatchId='CONTRACTS'

Note: When updating the tables SalesInvoice, SalesOrder, SalesQuote, SalesReturn, SalesBackorder, SalesFulfillmentOrder the Date column should be set for a successful query.

Executing Update using temporary tables

As explained in Executing Inserts using Temporary Tables the temporary tables can also be used in update operations. Take a look at the query below which updates the quantity of the existing items in our invoice:

INSERT INTO SalesInvoiceLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('100XLG', 'WAREHOUSE', '2', '30', 'USD')
INSERT INTO SalesInvoiceLines#TEMP (LinesItemId, LinesWarehouseId, LinesQuantity, LinesUnitPrice, LinesUnitPriceCurrency) VALUES ('M1700', 'WAREHOUSE', '2', '30', 'USD')

UPDATE SalesInvoice SET Date='2021-01-07T00:00:00+01:00', LinesAggregate='SalesInvoiceLines#TEMP' WHERE Id='STDINV2300' AND BatchId='CONTRACTS'

Below you can find other query examples.

UPDATE SalesOrder SET CustomerId='AARONFIT0001', Date='2021-01-07T00:00:00+01:00' WHERE Id='ORDST2225' AND BatchId='SOP ORDERS'

INSERT INTO ApplicantApplications#TEMP (ApplicationsDateApplied, ApplicationsLastModifiedDate) VALUES ('2021-01-05T00:00:00+01:00','2021-01-07T00:00:00+01:00')
UPDATE Applicant SET FirstName='New Test Name', LastName='New Applicant Name', ApplicationsAggregate='ApplicantApplications#TEMP' WHERE ApplicantId='3'

UPDATE SalesQuote SET CustomerId='BAKERSEM0001', Date='2021-01-07T00:00:00+01:00' WHERE Id='QTEST1022' AND BatchId='SALES QUOTES'

UPDATE Vendor SET Name='new test name',Comment1='new comment 1', Comment2='new comment 2' WHERE Id='ACETRAVE0001'

UPDATE VendorAddress SET Line1='new line 1', Line2='new line 2', City='new city', State='new state', Fax='111111111', Phone1='222222222', Phone2='3333333', PostalCode='235-325' WHERE KeyVendorId='ACETRAVE0001' AND Id='PRIMARY'

Tables

The connector models the data in Microsoft Dynamics GP into a list of tables that can be queried using standard SQL statements.

Generally, querying Microsoft Dynamics GP tables is the same as querying a table in a relational database. Sometimes there are special cases, for example, including a certain column in the WHERE clause might be required to get data for certain columns in the table. This is typically needed for situations where a separate request must be made for each row to get certain columns. These types of situations are clearly documented at the top of the table page linked below.

Jitterbit Connector for Microsoft Dynamics GP Tables

Applicant

Return a list of: Applicant

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantEducation

Return a list of: ApplicantEducation

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantInterview

Return a list of: ApplicantInterview

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantReference

Return a list of: ApplicantReference

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantSkill

Return a list of: ApplicantSkill

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantTest

Return a list of: ApplicantTest

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ApplicantWorkHistory

Return a list of: ApplicantWorkHistory

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

BackOfficeRoleAssignment

Return a list of: BackOfficeRoleAssignment

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

BusinessObjectUserAssignment

Return a list of: BusinessObjectUserAssignment

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

CashReceipt

Return a list of: CashReceipt

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

Customer

Return a list of: Customer

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

CustomerAddress

Return a list of: CustomerAddress

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

Employee

Return a list of: Employee

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

EmployeeAddress

Return a list of: EmployeeAddress

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

EmployeePayCode

Return a list of: EmployeePayCode

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

Fee

Return a list of: Fee

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

GLFixedAllocationAccount

Return a list of: GLFixedAllocationAccount

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

GLPostingAccount

Return a list of: GLPostingAccount

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

GLTransaction

Return a list of: GLTransaction

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

GLUnitAccount

Return a list of: GLUnitAccount

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

GLVariableAllocationAccount

Return a list of: GLVariableAllocationAccount

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

HRRequisition

Return a list of: HRRequisition

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

InventoryAdjustment

Return a list of: InventoryAdjustment

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

InventoryTransfer

Return a list of: InventoryTransfer

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

InventoryVariance

Return a list of: InventoryVariance

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ItemCurrency

Return a list of: ItemCurrency

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ItemVendor

Return a list of: ItemVendor

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

ItemWarehouse

Return a list of: ItemWarehouse

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

PayablesCreditMemo

Return a list of: PayablesCreditMemo

Columns

Pseudo-Columns

Pseudo-Column fields are used in the WHERE clause of SELECT statements and offer a more granular control over the tuples that are returned from the data source.

PayablesFinanceCharge

Return a list of: PayablesFinanceCharge

Columns