Recently, while trying to implement Bootstrap’s typeahead.js to an ASP.NET MVC project, we ran into a couple problems. To start, we were using the following articles as a guide:

http://deanhume.com/home/blogpost/twitter-bootstrap-typeahead-and-asp-net-mvc—key-value-pairs/88

http://yassershaikh.com/using-twitter-typeahead-js-with-asp-net-mvc-web-api/

The code within these articles worked just fine for the purpose of dealing with in-memory data. For instance, creating a handmade List<Company> would execute without flaws. However, these articles didn’t work for our particular situation because we were dealing with an Entity Framework generated class containing data from a database. This being the case, we figured we could make an equivalent list using an Entity Framework query like so:

var companies = db.Companies.Where(m => m.Name.StartsWith(query)).Select(c => new { c.Name, c.CompanyID });

This turned out to be only half of the battle. We were still having issues so we began logging some JavaScript objects in the console. With the handmade list, the console showed a conventional JSON object. On the other hand, when we passed the Entity Framework JSON serialized object we got numerous errors, including:

A circular reference was detected while serializing an object of type ‘System.Data.Entity.DynamicProxies.Company_983FFFBF6539DF8F813E1EAB1A1565F8743CF808D3B09F748B8A4906B756C4EF’.

We tried manually serializing, but it gave a similar error:

Using JsonConvert.SerializeObject
In Visual Studio before getting to client:
Self referencing loop detected for property ‘Company’ with type ‘System.Data.Entity.DynamicProxies.Company_983FFFBF6539DF8F813E1EAB1A1565F8743CF808D3B09F748B8A4906B756C4EF’. Path ‘[0].SalesCalls[0]’.

So, the big problem was trying to serialize an Entity Framework object. This can be done by changing a particular setting to false. In your code, you can simply call the following:

context.Configuration.ProxyCreationEnabled = false;

After adding that, we had no more issues. Our final action method looked like this:

public ActionResult GetCompanies(string query) {

    // Enable json serialization of the object.
    db.Configuration.ProxyCreationEnabled = false;

    var companies = db.Companies.Where(m => m.Name.StartsWith(query)).Select(c => new { c.Name, c.CompanyID });

    return Json(companies, JsonRequestBehavior.AllowGet);
}

I do not have any experience in accounting background, and some of the concepts so obvious to others are a mystery to me. One of those concepts was “Quantity in Base”. Although there may be a great description of this concept directed at the ignorant, I did not find it, and most of the discussion I found did not help me.

Quantity in base is used in several contexts, and one of them is described here by an example.

Suppose you have a new product, ITEMNMBR ‘1234’, and you enter it into Dynamics GP. Table IV00101 will have a new row, and you must have supplied values that include SELNGUOM (Selling Unit of Measure), PRCHSUOM (Purchasing Unit of Measure) and UOMSCHDL (Unit of Measure Schedule).  These units are expressed as strings so that they can be somewhat descriptive.

This means that you must supply a value for SELNGUOM such as EACH, 5P (5 Pieces), 10P, lb (pound), oz (ounce), or CASE, etc.  When someone sells the item and it is entered into as a line item into SOP10200, each line item will have a QUANTITY and a UOFM (Unit of Measure). Normally we would expect the Unit of Measure to the same as the SELNGUOM in IV00101, but what if it isn’t?

The order can have a different UOM for an item than that which is anticipated so long as there is a table entry to translate the UOFM in the sale order to the “Base Unit of Measure” that is anticipated in the record setup for the item’s definition in IV00101. The line item for an actual sale of an item is in SOP10200 (and is moved to SOP30300 after posting). For each line of SOP10200 there is a UOFM (the units used in the order and invoice for sale) and the QUANTITY sold.

The table that translates from one UOFM to another is IV40202. The table has a number of rows that will translate the units. To find the one we want, we must know the UOMSCHDL for the item in IV00101. This, combined with the actual selling unit of measure (which is the UOFM column in iv40202) two pieces of information needed to look up the QTYBSUOM (Quantity in Base Unit of Measure), which is a _ratio_ between  the Actual Unit of Measure (UOM)  and the usually expected unit of measure. To get the units in the SELNGUOM, you will multiply the actual number of units in the actual line item (QUANTITY in SOP10200) by the QTYBSUOM.

SELECT QTYBSUOM

FROM IV00202

WHERE UOMSCHDL = <<the SELNGUOM of the item from IV00101>> AND UOM = <<the actual unit of measure used in the sales line item of SOP10200>>

But apparently you don’t have to look this up, because the record in SOP10200 has a QTYBSUOM which is inserted into the record for convenience.