Many of us still have customers, vendors, employees, etc. who require printed invoices, checks, letters, or other documents to be mailed to them. This is a hassle to do. Extracting and formatting the data, mail-merging, printing, folding, stuffing envelopes, postage, and mailing takes time and costs money.
Catalina Technologies’ Cloud based printing and mailing solution automates this process and merges data from your ERP, CRM, helpdesk, or other system and prints and mails these documents for you.
How does this work? We merge your data into a customizable template, print it, and mail it. All on the Cloud! It is just that simple!
(NOTE: You can jump to the end of this post to see a demo of this in action!)
Data Integration
To make life easier, you want your ERP, helpdesk, CRM, or other system to automatically feed the cloud printing and postage so that you don’t have to do manual steps to get your data out of your back office, merged, printed, and mailed. Catalina Technology has a full set of integration tools that allows you to integrate from most ERP’s, CRM systems, Helpdesk, or SQL Query, Excel spreadsheet, CSV, etc. Catalina also has a front-end to Quick Query that allows you to define Quick Query filter definitions that can have custom mapping rules. These Quick Query filter definitions can then be saved and scheduled as automated jobs.
- Dynamics SL, GP, and CRM
- Salesforce.com
- Any SQL Query
- Excel spreadsheets
- .CSV files
- You can call our API from your system
- Custom integration
Templating
Templating is an important part of a printing solution. This allows you to be able to customize how data is merged into the output document to any format you want.
These can then be printed as:
- Invoices
- Letters
- Postcards
- Holiday cards
- Checks
- Anything you would normally send to a customer, vendor, employee, business associate, etc!
Demo
Here is a quick demo we did on one of our recent webinars showing how we can receive data from Dynamics SL, merge it into invoices, and then send it out to be printed and mailed to your customers.
[youtube https://www.youtube.com/watch?v=kJGuq5id7pM]
For more information contact Catalina Technology: [email protected]
There are many times where you want to be able to import sales orders into Dynamics SL and have SL automatically price the order items for you (instead of you manually setting it). This is easy to do in REST, because you can omit fields like CurySlsPrice and then the RESTful API will see that as a null and then ask SL to price for you. But SOAP isn’t as simple since passing nulls isn’t as easy.
We have a simple way of handling this by a secret number. Yes, I said that right. We use a secret number (-999876 to be exact). This is a very unlikely number to ever have a price set as in SL. So, if you set the sales price of a line item to -999876, the Catalina API will then ask SL to automatically price it for you. If you pass any other number, the Catalina API will use that number for pricing override.
Here is an example: (NOTE: see the setting of the orderItems array, both the CurySlsPrice and CuryCost is getting set to -999876. This tells the Catalina API that it is to use the SL sales price for the customer and follow all pricing rules setup against the customer, price class, quantity ordered, etc.
// Test placing an order with the bare minimum
ctDynamicsSL.orders.order oOrder = new ctDynamicsSL.orders.order
{
SOTypeID = "SO", // set your order type (must be a valid soTypeID)
CustID = "C300", // which customer are you creating an order for (must be a valid CustID)
ShipViaID = "BEST", // how are you shipping it (ust be a valid shipViaID)
ShiptoID = "DEFAULT", // Which ShipToID for the customer are you shipping to (must be a valid shipto address for the customer)
AdminHold = true, // for kicks, we are going to put it on admin hold
};
// create an array of orderItems with the bare minimum (this allows SL to price)
List<ctDynamicsSL.orders.orderItem> orderItems = new List<ctDynamicsSL.orders.orderItem>();
orderItems.Add(new ctDynamicsSL.orders.orderItem
{
InvtID = "0RCRANK", // which invtID are you sending this to? (must be a valid InvtID)
CurySlsPrice = -999876, // -999876 is a secret number that will tell the web services to allow SL to price the item
CuryCost = -999876, // if you want to price this yourself, just put in the amount you want to price
Taxable = 1
});
oOrder.orderItems = orderItems.ToArray();
// lets place the order using placeOrder()
var placedOrder = OrderService.placeOrder(oOrder);
// if there is a value in the errorString property of the returned object, then there was an error
if (placedOrder.errorString.Trim() != "")
{
Console.WriteLine("An Error Occurred: " + placedOrder.errorString.Trim());
}
else
{
Console.WriteLine("Order Created: " + placedOrder.OrdNbr);
}
You can see the full example on GitHub here: https://github.com/CatalinaTechnology/ctAPIClientExamples/tree/master/TestSLConsole
Catalina Technology has an API that allows you to integrate with Dynamics SL’s Quick Query through both SOAP and REST interfaces. This example shows you how to make a call to Quick Query using RESTful API.
If you want to learn about the SOAP methods, you can see an earlier blog post here:
Example of building a Form Client to use the Catalina Quick Query SOAP Web Service
First, thing you can do is look at your swagger documentation by directing your browser to the swagger docs on your ctDynamicsSL web application.
Continue Reading →
Many times, we want to be able to create Purchase Orders, using the Catalina API for Dynamics SL, and don’t want to worry about having to create the PO Number ourselves so that we don’t reuse a PO number, etc. This is a function of Dynamics SL and is configured in the POSetup table. If you look at the POSetup table, at the AutoRef column, it can be either a 0 or a 1:
If it is a 1, it means that SL will auto-number for you and if you leave the PoNbr blank when you call the ctDynamicsSL.purchaseOrders.saveNewPurchaseOrder function it will auto generate it for you, just like sales orders.
If PO Auto numbering is not enabled, POSetup.AutoRef=0 then you have to specify the PONbr yourself. But dont worry, we have a work-around for this that will generate a custom incremented number for you by calling this Catalina API call:
[code lang=”csharp”]
ctDynamicsSL.common.getNextCounterAsString(counterName);
[/code]
This function uses the xct_tblDSLCounter table to determine the next number value. This table is a Catalina table that is used for anything you want to have a counter for and is keyed off of the column: counterName. If you create a new record with the counterName = “PONBR”, you can then do an API call like this to get the next number:
[code lang=”csharp”]
string nextPONbr = ctDynamicsSL.common.getNextCounterAsString("PONBR");
[/code]
Looking further in the xct_tblDSLCounter table, you can see the following fields:
- counterName: This is the key to determine which counter you want to increment
- counterPrefix: If you want to have some type of custom prefix on your counter, you can enter something here
- counterAmt: this is the last counter used
- minWidth: this will make sure that you have a certain width of number come out (not including the prefix)
Lets create a record in the table for PONBR. I just choose PONBR because it makes sense to me. But you could use any counterName. Or for that matter, you could have several records for PO Numbers so that you can have separate prefixed counters for different applications that might be feeding your PO’s.
[code lang=”sql”]insert into xct_tblDSLCounter
values(‘PONBR’, ‘PO’, 0, 5)
[/code]
So, if I make this call:
[code lang=”csharp”]
string nextPONbr = ctDynamicsSL.common.getNextCounterAsString("PONBR");
[/code]
The first time I call it, it will give me a value for nextPONbr
PO00001
The second time I call it, it will give me a value for nextPONbr
PO00002
The one hundredth time I call it, it will give me a value for nextPONbr
PO00100
bwharton
February 24, 2017
The Catalina Integrator is a simple ETL tool that allows you to call API’s, transform the data, and send that data to other API’s.
In this demo, we are going to show how you can make a call to one of Catalina’s API’s and totally customize the API output so that you can then send it to another API or have it work for your specific client needs (mobile, web, etc).
This article is summarized in a video demo. You can view the demo or read the details below. (NOTE: the video is from a webinar and the capture is pretty poor. That’s why I did a write-up to follow since most of the screens are barely visible in the video) Continue Reading →
This is an example of how to use Quick Query as a data delivery tool for external systems using Catalina’s API for Dynamics SL. This example is for those who want to use a SOAP based interface.
For an example on how to retrieve Quick Query data through a REST interface, check out this article: Dynamics SL Quick Query through Catalina’s RESTful API
1. In Visual Studio, we select the Visual C# Template for a Windows Form Application. Our client will be named: client.ctDynamicsSL.quickQuery.
Note: you can call the Catalina web services from any type of client that is able to make http/https calls, but for this example, we will use a Form Application.
2. Add a reference to our Quick Query Web Service
a. Right click on “References” and select “Add Service Reference”
b. On the “Add Service Reference” screen, click the “Advanced” button in the bottom left. (Image: qqcclient3.png)
c. On the “Service Reference Settings” screen, click the “Add Web Reference” button. (Image: qqcclient4.png)
d. On the “Add Web Reference” screen, enter in the URL to the web service.
E.g.: http://localhost/ctDynamicsSL/quickQuery.asmx
Click the arrow button to discover the web service schema.
After the service definition loads, enter in a name to refer to this service in your client.
E.g.: ctDynamicsSL.quickQuery
e. Click the “Add Reference” button.
f. The new web reference will show up in your project.
3. Create code to instantiate an object referencing our web service.
a. I like to store values that are required in the Soap Header in the app.config file using System.Configuration, so we will first add a reference to the System.Configuration assembly. References -> Add Reference -> System.Configuration
b. Create a private variable to store the actual object and a property to auto create the instance if the variable is null. This get{} property will pull the required header values from the app.config
Now whenever we want to call a function in the web service, we just reference it like so: myQQObj.functionName().
4. Add the necessary elements for our main Form.
a. TextBox for typing in a QueryViewName (tbQueryViewName)
b. Button for a QueryViewName search (btnSearch)
c. Button for executing our search (btnGetQuery)
d. DataGridView for holding our search parameters (dgvFilters)
e. 
DataGridView for holding our search results (dgvQueryResults)
5. Add a popup form for QueryViewName searches.
a. The QueryViewName is the root of the Quick Query Service; they are names of SQL Views built in to SL. This is a required element, so let’s build an easy way to lookup them up.
b. Add another Form object to the project: queryViewsPopup.cs
c. Add a DataGridView to the new Form object.
d. Click on the little arrow at the top right of the Grid and add ctDynamicsSL.quickQuery.vs_qvcatalog as the Data Source.
e. For ease of use, edit the DataGridView Columns.
- Move the QueryViewName column to the first position.
- Change Name to “QueryViewName” we will use this to reference the cell later.
f. On our main Form, tie an EventHandler to open this form.
g. Add a CellDoubleClick Event Handler, to take the selected row and return the QueryViewName back to the tbQueryViewName on the main Form.
6. Setup Filters DataGridView
a. The Quick Query Service getScreen call requires 2 parameters: queryViewName, filters[]. The filters parameter is of type: ctDynamicsSL.quickQuery.queryFilter.
b. The Filters is an array of triplets holding 3 required fields:
- name – This must match the name of a column in the query view)
- value – This is the value we are to filter/compare against)
- comparisonType – This is any valid SQL comparison operator. E.g.: =, <, >, LIKE, IN, NOT IN
c. Select the Data Source as ctDynamicsSL.quickQuery.queryFilter
7. The Quick Query Service, is a V2 service by Catalina Technology and by design uses a screen() object for most calls that replicate the SL screen. Create a private variable to hold an instance of the screen object for all of our subsequent calls to the service.
8. Write the code to call the web service, pass the parameters and tie the results to the Result DataGridView (dgvQueryResults)
9. Test our Web Service Client:
a. Find a Query View with our popup.
b. Enter in some filters then Search and View the Results
Note: You can download the sample client Visual Studio Project at the following link: https://github.com/CatalinaTechnology/ctAPIClientExamples/tree/master/client.quickQuery
Catalina has a simple queuing engine that allows you to track changes on any table in SQL server. There is then an API that allows you to retrieve items that have been queued so that you can take action on them. This is mostly done when you need to send Dynamics SL data, that has changed, to an outside system.
Example: A customer in Dynamics SL is modified in the SL Customer Maintenance Screen. You want to make sure that the customer terms, class, and other information makes it out to Salesforce.com (or other CRM system). Continue Reading →
How many times have you wanted to just make a SQL call from an app, website, or other system, but you don’t have direct access to a SQL connection or other easy method to call SQL?
Well the Catalina API for Dynamics SL has a secure way for you to make SQL calls over to your SL database using the Catalina common.asmx web service call.
Below is a quick tutorial on how to do this using .NET and the Catalina API for Dynamics SL (SOAP calls) Continue Reading →
Often, you don’t want to code out a client to run quick tests for an API. Example, you might just want to retrieve a record or maybe you want to see what the return looks like when you post data to the API. Writing a client can be a lot of work when all you need to do is just test things out.
You can do quick API calls by using Swagger and Postman. This article is to show you how you can use Swagger to generate code so that you can then use the power of Postman to further test and work with the API. Continue Reading →
bwharton
January 27, 2017
Catalina Technologies API for Dynamics SL allows you to create your own custom defaults and validations when sending data into SL through the API.
How to set Custom Defaults and Validations for web services in CTAPI. As of RELEASE builds post 2017/1/1, you are now able to overwrite defaults and validations in two single files. This is now the preferred place to make customizations, as it will avoid overwriting changes with new release builds of CTAPI.
The file for Defaults customizations is named: custom.default.ctDynamicsSL.xml and is located in your DEFAULTCONFIGDIRECTORY. (Path defined in your DSLCONFIGFILE, default: c:\inetpub\xctFiles\config\)
The file for Validations customizations is named: custom.validate.ctDynamicsSL.xml and is located in your VALIDATIONCONFIGDIRECTORY. (Path defined in your DSLCONFIGFILE, default: c:\inetpub\xctFiles\config\)
All customizations for defaults and validations for all CTAPI web services are contained in these two files.
Definition of the custom.default.ctDynamicsSL.xml file:
ID: (The field to set)
1. inItem – Always used to represent the Table/Object being defaulted. (not the field)
DEFAULTTYPE: (TEXT, PROC, CODE)
1. TEXT – sets the field value to the value listed in this xml element.
2 PROC – sets the field value to the value returned by the stored procedure listed in the xml element value. (optional: PARMS attribute listing stored procedure parameters)
3. CODE – sets the field value to the value returned by performing an eval on the code listed in the xml element value.
PARMS: (An optional, comma-delimitated list of parameters used for PROC Type defaults)
1. Variables from the inItem object that match stored procedure variable names.
e.g.: PARMS=’inItem.Status’
2. Rename an inItem object variable to a different stored procedure variable name.
e.g.: PARMS=’VendStatus=inItem.Status’
3. Hardcoded Stored procedure variable values.
e.g.: PARMS=’Active=1’
Definition of the custom.validate.ctDynamicsSL.xml file:
ID: (The field to set)
1. inItem – Always used to represent the Table/Object being defaulted. (not the field)
VALIDATETYPE: (LIST, PROC, NUMBERRANGE, DATERANGE, CODE)
1. LIST – a comma delimitated list of text values that are valid.
2. PROC – validates based on returnValue returned by the stored procedure listed in the xml element value. (optional: PARMS attribute listing stored procedure parameters)
3. NUMBERRANGE – a comma delimitated range of doubles.
e.g.: 1,5
4. DATERANGE – a comma delimitated range of dates.
e.g.: 1/1/2016,1/1/2019
5. CODE – validates the Boolean returned by performing an eval on the code listed in the xml element value.
PARMS: (An optional, comma-delimitated list of parameters used for PROC Type validations)
6. Variables from the inItem object that match stored procedure variable names.
e.g.: PARMS=’inItem.Status’
7. Rename an inItem object variable to a different stored procedure variable name.
e.g.: PARMS=’VendStatus=inItem.Status’
8. Hardcoded Stored procedure variable values.
e.g.: PARMS=’Active=1’
