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¶