Jiwa

Hi All

Is there a simple example that you could provide in how to call the necessary Jiwa objects (obviously ignore logging in) from outside the application that would produce the price what would be charged to a given debtor account number for a given part number as if that part number was being keyed into a sales order for that customer?

This would need to take into account all pricing rules and scheme inside Jiwa and Qunatity etc as well.

Using the JiwaPriceSchemes assembly, you can perform ad-hoc price queries given a debtor, inventory, warehouse, date and quantity using the GetPrice method of the JiwaPriceSchemes.PriceScheme class.

An example console application project is attached (VS 2015).

The important part of the code:

Code: Select all

decimal price = 0;
bool priceIsIncTax = false;

priceScheme.GetPrice(JiwaFinancials.Jiwa.JiwaPriceSchemes.PriceScheme.PriceSchemePriceChangeOrigin.e_PriceSchemePriceChangeOriginSalesOrder, null, inventory.InventoryID, debtor.DebtorID, DateTime.Now, JiwaFinancials.Jiwa.JiwaApplication.Manager.Instance.CurrentLogicalWarehouse.IN_LogicalID, 5, ref price, ref priceIsIncTax);

Console.Write("Price is {0}", price);


Hi Mike,

I have finally circled back to this one and the code you provided got me with some minor changes to exactly the functionality I needed as part of the project I have been working on in the background.

Two things I was hoping you might be able to clarify for me which are:

1. I notice on the first parameter to GetPrice there is a quote version of the parameter can you expain the difference between that and order version you used, as I would have thought Jiwa would produce the same result in both cases, I only ask in that the project I am using this for deals with both quotes and orders?

2. I noticed you used the Debtor and Inventory objects out of the Jiwa.JiwaApplication.Entities name space, which I didn't know existed until now, am I right in assuming these objects only load the data from the main tables i.e. Debtor to DB_Main and Inventory to IN_Main, and therefore are better to use if you only require lookup data from these tables rather than the versions in the other name spaces?

As always thanks for the help and feedback.

SBarnes wrote:1. I notice on the first parameter to GetPrice there is a quote version of the parameter can you expain the difference between that and order version you used, as I would have thought Jiwa would produce the same result in both cases, I only ask in that the project I am using this for deals with both quotes and orders?

Yes, you'll get the same result. That parameter is only there as legacy support for old version 6 databases. We used to have an option for price scheme elements to be in VB Script, and we'd pass in either a quote line or sales order line object to the pricing engine - that's now defunct.

SBarnes wrote:2. I noticed you used the Debtor and Inventory objects out of the Jiwa.JiwaApplication.Entities name space, which I didn't know existed until now, am I right in assuming these objects only load the data from the main tables i.e. Debtor to DB_Main and Inventory to IN_Main, and therefore are better to use if you only require lookup data from these tables rather than the versions in the other name spaces?

The Jiwa.JiwaApplication.Entities classes are lightweight classes that read a subset of data from the respective areas. We added this - again - for legacy reasons, as our code often just read what was required from the tables directly, so we played it safe and made some entity classes to reproduce this as we thought using the business logic to do a full read might impact performance. They shouldn't be confused with Entity Framework classes, because they're not despite the name - they're just small classes reading from the tables for commonly used scenarios. We generally use them just to get minimal amount of information when needed, without repeating ourselves by writing a queries - such as lookups - as you mentioned.

So, yes for most purposes to get a name/accountno/partno from an id or vice versa, the entity classes are best to use if that's all you need. If you find yourself needing to perform updates, or read more of the fields the entities don't offer, then you should use the business logic instead - or construct your own query to obtain the fields you are interested in.

Mike

Hi Mike,

thanks for the update.