Sage 100

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil

@Jeff Schwenk - Sage doesn't have a native API available. I think the closest they came to that was eBusiness Manager and sData (XML and I believe deprecated), and now possibly whatever it is they're trying to do with Sage Network. What Phil describes is honestly the best way of creating a consistent method that still adheres to the BOI and controls customer cost. Several ISVs have created proprietary web apps like that, but I don't know of an ISV (CIM Cloud, Scanco, etc.) that sells them separately from their core products. 

@Phil McIntosh - I'd love to learn more about this web app. In the world of CRM, the most challenging thing is getting data back into Sage 100 properly while adhering to the Sage 100 BOI. I've been trying to find a reliable method that allows me to perform the following calls (I'm not a Sage 100 expert by any means, so please forgive ignorance in the grouping below):

• GET
  • Customer Inquiry: accessing data such as AR Customer, AR Customer Sales History, AR Customer Contact
  • General Item Inquiries: CI Item, IM Warehouse, and some means of polling Sage 100 for pricing information based on the hierarchy of item pricing
  • Invoices: AR Invoice History Header, AR Invoice History Detail
  • Sales Orders: SO Sales Order Header, SO Sales Order Detail, SO ShipToAddresses, and then the history tables for the sales order module (SO Sales Order History Header, SO Sales Order History Detail)
  • Salesperson history: AR Salesperson and AR Salesperson History
  • Vendor Tables: AP Vendor, AP VendorContact
• POST
  • Customers
  • Contacts
  • Sales Orders
  • Ship-to Addresses
  • Vendors

I realize there are probably 15+ specific tables, but could your web app accomplish GETs and POSTs aligning with the above?

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil

@Basil Malik,  I am traveling today but will get you a detailed answer on Monday.

Phil

@Jeff Schwenk - Sage doesn't have a native API available. I think the closest they came to that was eBusiness Manager and sData (XML and I believe deprecated), and now possibly whatever it is they're trying to do with Sage Network. What Phil describes is honestly the best way of creating a consistent method that still adheres to the BOI and controls customer cost. Several ISVs have created proprietary web apps like that, but I don't know of an ISV (CIM Cloud, Scanco, etc.) that sells them separately from their core products. 

@Phil McIntosh - I'd love to learn more about this web app. In the world of CRM, the most challenging thing is getting data back into Sage 100 properly while adhering to the Sage 100 BOI. I've been trying to find a reliable method that allows me to perform the following calls (I'm not a Sage 100 expert by any means, so please forgive ignorance in the grouping below):

• GET
  • Customer Inquiry: accessing data such as AR Customer, AR Customer Sales History, AR Customer Contact
  • General Item Inquiries: CI Item, IM Warehouse, and some means of polling Sage 100 for pricing information based on the hierarchy of item pricing
  • Invoices: AR Invoice History Header, AR Invoice History Detail
  • Sales Orders: SO Sales Order Header, SO Sales Order Detail, SO ShipToAddresses, and then the history tables for the sales order module (SO Sales Order History Header, SO Sales Order History Detail)
  • Salesperson history: AR Salesperson and AR Salesperson History
  • Vendor Tables: AP Vendor, AP VendorContact
• POST
  • Customers
  • Contacts
  • Sales Orders
  • Ship-to Addresses
  • Vendors

I realize there are probably 15+ specific tables, but could your web app accomplish GETs and POSTs aligning with the above?

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil

@Jeff Schwenk - Sage doesn't have a native API available. I think the closest they came to that was eBusiness Manager and sData (XML and I believe deprecated), and now possibly whatever it is they're trying to do with Sage Network. What Phil describes is honestly the best way of creating a consistent method that still adheres to the BOI and controls customer cost. Several ISVs have created proprietary web apps like that, but I don't know of an ISV (CIM Cloud, Scanco, etc.) that sells them separately from their core products. 

@Phil McIntosh - I'd love to learn more about this web app. In the world of CRM, the most challenging thing is getting data back into Sage 100 properly while adhering to the Sage 100 BOI. I've been trying to find a reliable method that allows me to perform the following calls (I'm not a Sage 100 expert by any means, so please forgive ignorance in the grouping below):

• GET
  • Customer Inquiry: accessing data such as AR Customer, AR Customer Sales History, AR Customer Contact
  • General Item Inquiries: CI Item, IM Warehouse, and some means of polling Sage 100 for pricing information based on the hierarchy of item pricing
  • Invoices: AR Invoice History Header, AR Invoice History Detail
  • Sales Orders: SO Sales Order Header, SO Sales Order Detail, SO ShipToAddresses, and then the history tables for the sales order module (SO Sales Order History Header, SO Sales Order History Detail)
  • Salesperson history: AR Salesperson and AR Salesperson History
  • Vendor Tables: AP Vendor, AP VendorContact
• POST
  • Customers
  • Contacts
  • Sales Orders
  • Ship-to Addresses
  • Vendors

I realize there are probably 15+ specific tables, but could your web app accomplish GETs and POSTs aligning with the above?

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil

@Jeff Schwenk - Sage doesn't have a native API available. I think the closest they came to that was eBusiness Manager and sData (XML and I believe deprecated), and now possibly whatever it is they're trying to do with Sage Network. What Phil describes is honestly the best way of creating a consistent method that still adheres to the BOI and controls customer cost. Several ISVs have created proprietary web apps like that, but I don't know of an ISV (CIM Cloud, Scanco, etc.) that sells them separately from their core products. 

@Phil McIntosh - I'd love to learn more about this web app. In the world of CRM, the most challenging thing is getting data back into Sage 100 properly while adhering to the Sage 100 BOI. I've been trying to find a reliable method that allows me to perform the following calls (I'm not a Sage 100 expert by any means, so please forgive ignorance in the grouping below):

• GET
  • Customer Inquiry: accessing data such as AR Customer, AR Customer Sales History, AR Customer Contact
  • General Item Inquiries: CI Item, IM Warehouse, and some means of polling Sage 100 for pricing information based on the hierarchy of item pricing
  • Invoices: AR Invoice History Header, AR Invoice History Detail
  • Sales Orders: SO Sales Order Header, SO Sales Order Detail, SO ShipToAddresses, and then the history tables for the sales order module (SO Sales Order History Header, SO Sales Order History Detail)
  • Salesperson history: AR Salesperson and AR Salesperson History
  • Vendor Tables: AP Vendor, AP VendorContact
• POST
  • Customers
  • Contacts
  • Sales Orders
  • Ship-to Addresses
  • Vendors

I realize there are probably 15+ specific tables, but could your web app accomplish GETs and POSTs aligning with the above?

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil

Basil,

SDE will allow you to do those that you want to do. See the demo page for it. SDE - Sage 100 API (simpledataexchange.com)

Example post:
{
"user":"Demo",
"password":"Demo123!",
"resource":"SalesOrders",
"method":"post",
"SalesOrderNo":"0000115",
"ShipToName":"MBA Business Software",
"Detail":[
{
"LineKey":"000001",
"LineSeqNo":"00000100000000",
"QuantityOrdered":6
}
]
}

With a response 

{
  "salesorders":
    [
      {
        "salesorderno":"0000115",
        "billtoname":"American Business Futures",
        "billtoaddress1":"2131 E. 14th Street",
        "billtocity":"Milwaukee",
        "billtostate":"WI",
        "billtozipcode":"53151",
        "ordertotal":10682.47,
        "action":"updated"
      }
    ]
}

What is nice is you can go in and edit the resource and manage most, if not all of it, yourself. If you have UDFs or Developer mods using Business Objects, it can be added to the resource. 

@Jeff Schwenk - Sage doesn't have a native API available. I think the closest they came to that was eBusiness Manager and sData (XML and I believe deprecated), and now possibly whatever it is they're trying to do with Sage Network. What Phil describes is honestly the best way of creating a consistent method that still adheres to the BOI and controls customer cost. Several ISVs have created proprietary web apps like that, but I don't know of an ISV (CIM Cloud, Scanco, etc.) that sells them separately from their core products. 

@Phil McIntosh - I'd love to learn more about this web app. In the world of CRM, the most challenging thing is getting data back into Sage 100 properly while adhering to the Sage 100 BOI. I've been trying to find a reliable method that allows me to perform the following calls (I'm not a Sage 100 expert by any means, so please forgive ignorance in the grouping below):

• GET
  • Customer Inquiry: accessing data such as AR Customer, AR Customer Sales History, AR Customer Contact
  • General Item Inquiries: CI Item, IM Warehouse, and some means of polling Sage 100 for pricing information based on the hierarchy of item pricing
  • Invoices: AR Invoice History Header, AR Invoice History Detail
  • Sales Orders: SO Sales Order Header, SO Sales Order Detail, SO ShipToAddresses, and then the history tables for the sales order module (SO Sales Order History Header, SO Sales Order History Detail)
  • Salesperson history: AR Salesperson and AR Salesperson History
  • Vendor Tables: AP Vendor, AP VendorContact
• POST
  • Customers
  • Contacts
  • Sales Orders
  • Ship-to Addresses
  • Vendors

I realize there are probably 15+ specific tables, but could your web app accomplish GETs and POSTs aligning with the above?

@Jeff Schwenk,

If they are wanting to send orders (or anything else) from the other app into Sage 100, then you need a web app on the Sage server set up to listen for POST requests and convert those requests into Sage 100 BOI calls.  The same app can also listen for GET requests to send data from Sage 100 (customers, items, etc).

I have done a number of these - let me know if that is what you want.

Phil