Archive for category: Integration

fmEcommerce Link (WooCommerce Edition) Update

/0 Comments/in , , , , , /by

We’ve just released our first update to fmEcommerce Link (WooCommerce Edition) for 2017 – this release provides an alternative method for handling authentication for some servers that may not parse the Authorization header correctly, as well as making the process of working with Product Variations much easier.

The WooCommerce REST API docs mention that some servers may not parse the Authorization header correctly – we’ve never encountered this during the testing and development of fmEcommerce Link but recently a customer contacted us after having trouble getting started with fmEcommerce Link (WooCommerce Edition). Upon further investigation we noticed that were receiving the same error each time they attempted to download data from WooCommerce:

{
 "code": "woocommerce_rest_cannot_view", 
 "data": {
 "status": 401
 }, 
 "message": "Sorry, you cannot list resources."
}

After many hours of frustration we stumbled across the suggestion to switch from using HTTP Basic Auth and implemented a change to test this and had immediate success. We’ve decided to add a toggle that users can switch on/off in case anyone else in the future encounters this issue:

We’ve also made it easier to download, update, create and view Product Variations in the fmEcommerce Link (WooCommerce Edition) file:

and also show which variations were selected when viewing an Order:

This is a free update to all our existing customers – we have a number of items on the list to add, including Refunds (create a Refund in FileMaker and upload to WooCommerce) and download Reviews. If there’s any examples that we don’t currently have that you would like to see please get in touch and let us know.

fmAccounting Link (MYOB AccountRight Edition) Updates – my.MYOB Login and General Journals

/0 Comments/in , , , , , /by

We’ve been busy working on some updates to fmAccounting Link (MYOB AccountRight Edition) over the past few weeks. fmAccounting Link (MYOB AccountRight Edition) was a popular item during our recent End Of Year sale and we’ve had some great feedback from customers about features they would like to see in future releases.

We’ve just released an updated version of fmAccounting Link  – v1.0.8. As well as the usual bug fixes we’ve added examples for working with the General Journals API endpoint – you can now download, create and update General Journals from FileMaker using fmAccounting Link. We’ve also added support for users that have linked their MYOB Company File User ID to their my.MYOB login – typically this is set using either of the following dialogs in AccountRight:

We couldn’t find anything about working with linked my.MYOB logins in the API documentation and after raising a ticket with MYOB developer support we were informed about the changes you need to make when working with linked my.MYOB accounts. We’ve added a new checkbox to the MYOB Company screen that allows you to flag that you’ll be using a linked my.MYOB login:

which handles the required changes automatically. For existing customers using older versions of fmAccounting Link you can simply disable a single script step to handle working with linked my.MYOB logins – see our FAQ page for details.

We’ve started working on adding examples for working with the JOBS API endpoint and hope to have this completed in the next few weeks. If there are features you would like to se in the core fmAccounting Link (MYOB AccountRight Edition) file please get in touch and let us know. You can view the full release notes on our version history page.

fmEcommerce Link (WooCommerce Edition) and Webhooks

/1 Comment/in , , , , /by

When we released fmEcommerce Link (WooCommerce Edition) last week there was one feature that we wanted to include that wasn’t quite ready: Order Webhooks. The initial release of fmEcommerce Link lets you download orders from WooCommerce, either all at once or within a specified date range. For many users that will be sufficient as they might only need to download all orders from the previous day.

Some customers would prefer to be notified immediately the order was placed and have it automatically download into FileMaker – you could setup a server side schedule that ran every x minutes that checked for new orders since a specified timestamp, but it’s much more efficient to leverage Webhooks if they are available. A Webhook is simply a way of having WooCommerce send a notification to another service at a nominated URL when a particular event is triggered.

Webhooks were introduced in WooCommerce 2.2 and can trigger events each time you add, edit or delete orders, products, coupons or customers. New orders seemed the logical place to start – wouldn’t it be great if upon receiving a new order in WooCommerce it could be pushed to the fmAccounting Link FileMaker file automatically without you having to do anything?

We’ll be releasing a free update to fmEcommerce Link (WooCommerce Edition) in the next couple of days which will include support for Webhooks when a new Order is created. You will need to setup a Webhook and install the supplied PHP file on your FileMaker Server (you will need to enable Custom Web Publishing/PHP in your FileMaker Server Admin Console), and once this in place anytime a new Order is received in WooCommerce it will automatically be pushed to the fmEcommerce Link file, typically within a few seconds.

This was a feature that we wanted for ourselves to completely streamline the order entry process for our business – there’s nothing better than waking up in the morning and seeing new overnight orders already in the fmEcommerce Link file. Here’s a short video demonstrating this in action (you can also watch this on YouTube here):

 

 

fmEcommerce Link (WooCommerce Edition) Preview Video

/2 Comments/in , , , , /by

Last week we announced the upcoming release of our latest FileMaker integration solution – fmEcommerce Link (WooCommerce Edition) – and included some screenshots. We’re in the final stages of testing and working on the website product pages etc but I can confirm that v1.0 will have the following features:

  • download Customers, Products, Orders, Tax Rates, Tax Classes, Categories, Attributes, Shipping Classes and Tags from WooCommerce
  • download all Product Details, including Images
  • update existing Customer, Product and Order records from WooCommerce to FileMaker
  • download Orders between 2 dates
  • create/update a Customer record from FileMaker to WooCommerce

Like our other products it will also have these features:

  • will work with FileMaker Pro v12, 13, 14 and 15
  • can be hosted by FileMaker Pro or FileMaker Server
  • works with Macintosh and Windows
  • 100% unlocked for you to integrate into your own FileMaker solution

I’ve put together a short preview video showing fmEcommerce Link (WooCommerce Edition) in action downloading Products, Orders and Customer data from WooCommerce to FileMaker. You can watch this below or via this link on YouTube:

Coming Soon – fmEcommerce Link (WooCommerce Edition)

/2 Comments/in , , , , , , , /by

Earlier this year we published a series of articles about FileMaker and eCommerce Integration, highlighting our use of External SQL Data Sources (ESS) to make our online store orders visible in our internal FileMaker CRM. We’ve been using this method of integration successfully for many years and it has saved us countless hours by not having to manually re-enter online orders in our main FileMaker business app and our accounting software (Xero).

That was until recently when we started getting this error message every time we navigated to the online orders layouts:odbc-error

Suddenly we could no longer see our online order records! Everything was still working on the website and orders were still being submitted successfully (we receive an email for each order) so we started troubleshooting this to try and get to the bottom of it. After many frustrating hours we still could not establish the ODBC connection to our server, so we made contact with our web host and opened a ticket explaining our issue and describing how this had previously worked fine for many years. We were then informed that they had disabled remote MySQL access for security reasons and there were no exceptions – talk about a great way to annoy your customers by switching off access and not informing your customers about this!

It was still possible to connect but you had to create an SSH tunnel first – we then wasted another couple of days setting up the SSH tunnel which would work but then drop out, and we had issues with automating this so it could run when the server wasn’t logged in. After many days of frustration and lost productivity I decided to abandon the SSH tunnel efforts as it was proving too unreliable and too look at other options. Databuzz specialises in FileMaker integration and having recently written an article on working with eCommerce APIs and Webhooks I revisited my article and knew what needed to be done.

Our website stores are built with WooCommerce, a popular plugin for WordPress that powers over 39% of all online stores. WooCommerce offer both a push and pull API so you can have new orders automatically pushed to a server, and also download new orders on demand (e.g. get all new Orders today). The push option is the more complicated of the two options as it requires FileMaker Server, Customer Web Publishing, PHP pages and Webhooks to be setup, so we decided to focus initially on the WooCommerce REST API as that allows us to query WooCommerce for any new Orders and download the data directly into FileMaker. This can be run regardless of whether the file is hosted with FileMaker Server or just using FileMaker Pro, and we can also setup server side schedules to run each night and download new data. The REST API also allows us to push data from FileMaker to WooCommerce, such as Product updates, which is something customers have requested in the past.

Fast forward a few months and we are in the final stages of development and testing of our latest product – fmEcommerce Link (WooCommerce Edition):

preview-home

fmEcommerce Link is our solution to connecting FileMaker to WooCommerce when you can’t make a direct ESS/ODBC connection – you use the fmEcommerce Link file to query your WooCommerce store for new orders, product inventory changes, new customers and also to push data back to WooCommerce such as new Products. You can link the fmEcommerce Link file to your existing FileMaker solution to push orders from WooCommerce into your main FileMaker business app, or recreate the same functionality inside your FileMaker business app as the fmEcommerce Link will be 100% unlocked for you to explore.

Here’s some screenshots showing data that we have downloaded from our test WooCommerce site:

preview-order-details

preview-orders-list

preview-products-list

I’ll be posting some videos demonstrating the core functionality of fmEcommerce Link over the coming days and would love to hear any feedback from existing FileMaker/WooCommerce users about any features you would like to see in the product – just leave a comment below.

Credit Card Tokens and Payment Processing Video

/1 Comment/in , , , , , , /by

Recently we wrote an article about the benefits of automating the processing of credit card payments using your FileMaker solution and why you shouldn’t be storing unencrypted credit card numbers in your FileMaker database. We wanted to demonstrate how easy it is to tokenise a credit card number and then charge that token when processing a transaction so we put together a short video demonstrating this. We’re using the eWay Payment Gateway in this example.

You can watch the video below or directly on YouTube via this link.

FileMaker and Xero Integration Webinar Recording

/3 Comments/in , , , , , , , /by
Read more

FileMaker and Xero Integration Webinar

/1 Comment/in , , , , , /by

Are you using FileMaker to run your business and also Xero for your accounting software? Would you like to see how they can be integrated together so you can streamline your workflow and protect your sensitive Xero data at the same time?

Join Andrew Duncan from Databuzz and David Borgnis, Business Development Manager, APAC at FileMaker Inc. for an informative and explorative 60 minute presentation. The webinar details are:

Date: Thursday, 3 November, 2016
Time: 12 noon (AEST)
Duration: 60 minutes
Register now

Integrating FileMaker and Xero allows you to remove double data entry and human errors saving your company significant time, money and hassle by automating the exchange of data between FileMaker and Xero. Xero was recently named the most-loved accounting software for a second year in a row, beating MYOB and Intuit Quickbooks, scoring five stars across seven criteria. It was named the preferred accounting software of Australian accountants – as you can see from the chart below it was by a significant margin:

afr-chart-1-1_800x480_acf_cropped

In the webinar will demonstrate:

  • how to setup the authentication between FileMaker and Xero without giving your staff direct access to Xero
  • how to download data from Xero into FileMaker (Chart of Accounts, Tax Rates, Inventory Items etc)
  • how to push a Sales Invoice from FileMaker to Xero (and create a Contact in Xero at the same time)
  • how to push a Payment for a Sales Invoice from FileMaker to Xero

We hope you can join us for the webinar – if you have anything you would like addressed in the webinar please leave a comment below. For further details on fmAccounting Link (Xero Edition), our FileMaker solution for integrating with Xero please visit the fmAccounting Link (Xero Edition) product page.

Update: thanks to everyone who was able to attend the webinar. If you weren’t able to make the live webinar the recording is now available here.

fmSMS and Emoji Support 😀

/2 Comments/in , , , , , , , /by

At the recent FileMaker Developer Conference I was doing one of my fmSMS demonstrations to an attendee which involved me sending a message from fmSMS to their mobile phone (showing how you can use FileMaker to send SMS messages) and then having them send a reply back to demonstrate how you can use fmSMS to receive incoming messages directly into FileMaker. Normally the reply is a simple text reply of a few words, but this one was a bit different as you can see here:

screen-shot-2016-10-21-at-10-42-30-pm

I was pleasantly surprised to see that the Emoji reply had made it all the way back from their phone to fmSMS via the SMS Gateway and the PHP page that is used to convert the incoming reply into a FileMaker record without me having to do anything to handle the Unicode characters – it just worked! I decided to do a bit more research into this to see how different SMS Gateways handled Emoji characters as a way of testing their Unicode support (there are now hundreds of Emoji characters encoded in the Unicode standards).

It’s important here to understand the history of SMS – back when the GSM standard was being adopted the mobile phone industry decided on a standard set of characters called GSM 03.38. Support for this character set became mandatory for all GSM handsets and network elements (carriers etc). The GSM character set includes the English alphabet ( A-Z ), numbers (0 – 9) and some special characters, and the size of a single SMS was limited to 160 characters. The 160 character maximum actually comes from the fact that you can encode 160 7-bit characters into 140 bytes – 140 bytes being the limit for the size of a message.

Unicode characters use several GSM characters to describe each Unicode character which means that you won’t be able to send as many characters in your SMS when include Unicode characters. Depending on which special characters you’re sending, you may only be able to send between 35 and 70 characters. To send a message that is longer than the 160 characters/140 bytes limit the message needs to use Concatenation, which involves breaking up the message over multiple SMS messages.

Thankfully most SMS Gateways and mobile phone handsets support concatenation where multiple messages are joined together to form a single message on the handset, even though that single message is greater than 160 characters (or 140 bytes). As each message needs to broken up into individual 140 byte messages the SMS Gateways will charge you for each individual message, even though they appear as a single message to the recipient.

Here’s an example of such a message using the GSM character set which is 312 characters but appears as a single received message on the phone:

long-message

SMS Gateways that handle the encoding of Unicode characters make life easy for us developers – we don’t have to do anything when sending or receiving messages from FileMaker. One such SMS Gateway is Twilio which I used in my tests and was able to handle the Emoji characters with ease – they have a number of articles on their website that go into the details of their support for Unicode. I created an outgoing message in fmSMS with some Emoji characters (FileMaker Pro 7 and later being a fully Unicode aware application):

screen-shot-2016-10-21-at-10-26-51-pm

and sent the message using a number of different SMS Gateways. Where the SMS Gateway supported Unicode the message appeared exactly as it was sent:

emoji-received

 

 

I tried with some SMS Gateways that don’t have native support for Unicode characters and on the handset here’s what the same message looked like:

no-emoji

I then sent some replies containing Emoji characters back to fmSMS which has a “chat view” that shows all the sent/received messages to an individual contact – here’s our Emoji conversation:

screen-shot-2016-10-21-at-10-33-36-pm

As you can see the incoming message containing Emoji characters was received successfully using the Twilio SMS Gateway once again.

Unicode support isn’t only important for Emojis – if you need to send accented characters or messages in Greek, Cyrillic, Hebrew, Arabic, Thai, Chinese, Japanese, Korean etc then you will be thankful for Unicode support as well. Just remember that when sending messages containing Unicode characters the standard 160 character test doesn’t apply – I’m yet to find a way to have a Unicode character check that converts back to the GSM character set in FileMaker so I can accurately count the number of credits required for each message, regardless of whether it contains GMS or Unicode characters). If anyone knows of a way please let me know in the comments below. 😃

Are you still processing credit card payments manually?

/3 Comments/in , , , , , , , /by

american-express-89024_640

Do you process credit card transactions manually and wonder if there is a better way? The good news is that there is a better more automated way that can integrate with your custom FileMaker solution and save your staff time and your business money.

Chances are if you’re a small business that sells goods or services your customers are going to want to pay by credit card, and having options and making it easy for customers to pay your invoices is a good thing for your business. Once you start accepting credit card payments however you need to comply with the PCI DSS (Payment Card Industry Data Security Standard) to help protect card data and prevent payment data theft. Small businesses are increasingly at risk for payment data theft – nearly half of cyberattacks worldwide in 2015 were against businesses with less than 250 workers according to cybersecurity firm Symantec.

The easiest way to protect against data breaches is to not store card data at all, however that isn’t always practical, especially if you’re selling an ongoing service that requires ongoing payments (e.g. a monthly subscription service). Whilst you definitely should not be storing unencrypted credit card data in your FileMaker solution that any employee can access, you can take advantage of encryption and tokenisation technologies that allow you to store an “alias” or token in your FileMaker solution and use that to processes future charges. Here’s how it works:

  1. customer provides credit card details to pay an Invoice
  2. you send an encrypted HTTPS request to a PCI DSS compliant credit card gateway who store the credit card details (as they are PCI DSS compliant) and send you back a token and a masked version of the credit card number (e.g. 512345…346)
  3. you store this token in your FileMaker transaction record. As this is a token and not a real credit card number it’s completely useless if stolen. You can also store the masked version of the card number in case you need to confirm with the customer which card number you are charging
  4. when you need to process a payment in the future you make another HTTPS request to the credit card gateway requesting a payment and referencing the token
  5. the credit card gateway returns a response indicating whether the transaction was processed successfully or if there was an error (e.g. declined, insufficient funds etc)

This can all be automated in a FileMaker solution allowing staff to process a payment or tokenise a card at the click of a button. We’ve worked with many PCI DSS compliant credit card gateways such as Stripe, eWay, BPOINT and Authorize.Net to help customers automate the process of processing credit card payments securely in their FileMaker solutions. If you’re currently storing credit card numbers in your FileMaker solution and would like to tokenise these we can also help you batch process these.

If you would like to discuss implementing a secure credit card processing system for your FileMaker solution plesae get in touch for a free initial consultation. For more information on how you can protect card data the Payment Card Industry has a number of guides for small businesses, including:

Update: we’ve published a short video demonstrating how you can use FileMaker to tokenise a credit card and then process a transaction by referencing that token.