Magento being an ecommerce platform running at a pace of a dragster, its highly difficult for its competitors to keep up with its features, updates, community base and no. of organizations using it.

Now the organizations using it also uses/need other subsystems for the tasks which Magento is not programmed/supposed to do. For example, to maintain accounting records organizations using Accounting Systems such as Quickbooks, using POS Systems such as Microsoft RMS, iVend, Lightspeed Retail for physical stores, using ERP such as SAP Business One, MS Dynamics NAV, Open ERP for order processing, accounting and for a full business management cycle, using Shipping Systems and Tax Management Systems such as Avalara or Exactor etc. For a smooth data flow and proper information management organizations are also using some Plugins/Connectors which connects these back office systems with the Magento eCommerce.

But have we ever thought that how these back office systems should be connected with Magento so that proper information can flow between two systems and not some junk data which again need manual rekeying to correct it. What factors to remember before starting the integration of Magento with back office systems? Well here are some key tips to consider when connecting Magento with third party systems:

Entity Codes:

Customer and Products, these 2 entities has presence in almost all back end systems, POS, Accounting and in ERP. But Magento uses auto generated Customer Codes and Product IDs and the back end systems also has its own ID Format to maintain records, so how can you map up  these parameters ? Magento provides one option for products which is the Unique SKU Code which is user entered. So you can use Back Office Item Ids to be mapped as SKUs of Magento and let Magento generate and maintain its own auto generated Product ID. For Customers, generally it needs to be entered into Back Office Systems based on Magento Info, so you can use Magento’s auto generated Customer ID as the Back Office System Customer ID.

Document Number:

It’s one of the main concerns for connecting the Magento with back office systems. Both Magento and Back Office Systems maintain its own document numbering for legal documents such as Sales Order, Shipment, Invoice and Credit Memo. You need to follow any one option, for example:

1. If you follow Magento’s Document Number, then this will be shown to the consumers and this need to maintain in Back Office System as well along with the Back Office Own Document Numbers which are usually auto generated. So that you and your employees can relate the Magento’s document number with the corresponding Back Office Documents.
2. If you want to use and show Back Office Document numbers to Magento Consumers, then you need hide the Magento’s own document numbers, need to maintain Back Office Document numbers in Magento in some Custom Fields which will be shown to the consumer.

Document Type:

Again this is related to many factors and a major concern. Magento follows Sales Order, Shipment, Credit Memo and Invoice, mainly these 4 documents. But your back office systems might have many variations, such as Draft/Sales Order, Delivery, A/R Reserve Invoice, A/R Down Payment Invoice, A/R Invoice, Incoming Payment, etc. So what and how you will follow, below are some best practices:

• For Offline Payments you can follow the below document types
• Magento Sales Order-> Back Office System Draft Sales Order converted to Sales Order Upon Validity Check
• Back Office Delivery-> Magento Shipment
• Back Office A/R Invoice -> Magento Invoice

• For Online Payments
• Magento Sales Order-> Back Office System Sales Order
• Magento Invoice-> Back Office System A/R Reserve Invoice
• Back Office Delivery-> Magento Shipment

• For Partial Payment Online
• Magento Sales Order-> Back Office System Sales Order
• Magento Invoice-> Back Office System A/R Down payment Invoice
• Back Office Delivery-> Magento Shipment

Tax:

Magento maintains Product and Customer Tax Class, Tax Rate Identifier and based on these a Tax Rule is defined in Magento. But different back office systems uses different norms in Tax Calculation. Overriding Tax Values is not a good idea. Rather it is a good practice to follow proper tax rates in Magento as well as Back Office Systems and map the Magento and Back Office System Tax Rule rather than pushing the tax amount forcefully into the other system’s Document.

Shipment Type and Price:

Magento uses a single entity for Shipping Type and Shipping Cost, while most back office systems uses 2 entities, Shipping Method and Freight Charges. So while entering Sales Order of Magento into the other system you need to remember and carefully map this, Magento Shipping Method and Back Office Shipping Method need to be mapped, so that if in Magento ‘UPS’ is selected as Shipping Method, then in back office too the same has to be selected. But the story merely ends here, shipping cost which is automatically calculated in Magento, needs to be entered as freight charges in back office POS/ERP/Accounting system.

Online Payment:

It is the most important factor to consider and provides multiple choices. Below we have mentioned some of the best practices, but it might vary from business to business.

1. Use Payment Gateway in Magento to perform Pre Authorization of Credit Cards and pass on Online Payment Transaction ID, this you can use as Payment Information in Back Office System
2. Capture Credit Card Information in Magento (Need PCI Compliance for this) and transfer that information to Back Office system and then perform Post Authorization
   1.  Charge the Credit Card Manually, or
   2. Charge the Credit Card using some payment processing add-on at the Back Office system

But need to remember that maintaining PCI Compliance in a ecommerce store is not an easy job.

Also Read:

Official Source of PCI DSS Compliance Guidelines

PCI Compliance Requirements and Secure Payment Systems in Magento