Thursday, 20 October 2016

Encrypted batch payment file (ACH, GIRO)

Hi All,

In Acumatica you can easily generate electronic payment files (such as ACH, GIRO and others). By using this process you will have a file that will have payment amounts and other required information.
But what about data protection? Bu default payment file will have clear text amounts.
Today i want to share with you how you can easily encrypt this file.

Payment file will be generated by Acumatica Integration Services Export Scenario. The main class that is responsible for generation file is Integration Services Data Provider. In Acumatica out of the box we have only 2 providers : ACH and GIRO.

In my Example i will show you standard .NET encryption using Triple DES encryption.

  1. Using customization module create a new provider and inherit it from from base provider (ACHProvider or GIROPaymentProvider).
  2. Override SetFile method.
  3. Put your encryption logic there.
  4. Publish customization.
  5. Use new provider type in the export provider. Do not forget to update provider object and fields when you changing type. Also will be good to save previous object name, as Export Scenario is linked to provider object by name.

That is all you need to do. Now you can generate a file and it will be encrypted.

Full code snippet:

Have a nice decryption!

Monday, 17 October 2016

Acumatica Test Framework

Hi All,

Acumatica has a strong focus on the Platform and Development tools, that can help all our clients and partners to provide better product faster and with lower cost.

One of the nice and free tool that Acumatica provides as part of platform is Acumatica Test Framework. Acumatica test Framework is a set of tools and libraries that can be used for unattended black-box testing of any product or customization that is based on Acumatica Platform right in your favorite browser. For interacting with UI controls and components Acumatica Test Framework uses Selenium Web Driver. You can read more about Selenium here.

The diagram of Test Framework components is described here.

The usage flow is like this:
  1. You have Acumatica ERP instance with required module or customization that you want to test.
  2. Using Page Wrapper Generation Tool you create a set of classes that will represents Acumatica page structure including controls, buttons, grids, columns, panels and so on. This tool is related on Acumatica platform and can dynamically analyse all standard and custom pages including customization. You need to create wrappers for each page that you want to test.
  3. Test Framework contains all required classes and methods that you can use to work with browser pages and controls. For example you can open selectors, search values, type or past values, click buttons, wait for long run operations and so on.
  4. Based on Wrappers and Framework classes you write your own Tests (that is classes) that will contains test logic.
  5. Using Test Runner you can lunch required tests. Test runner will load all test libraries and using interaction with Selenium Web Driver will open browser and execute all required steps.
  6. Selenium Web Driver is intermediate layer between test and browser. This tool knows browser API and can simulate user clicks with mouse and keyboards on each control separately. Also it can get values back to validate result. 
  7. Browser is embedded in test SDK, as it requires specific version of browser to run smoothly. When you run test you will see browser window and can check how your test is running.

Wednesday, 12 October 2016

Replacing Cache with custom class

Hi All,

Today i want to share with you a good trick how you can override original PXCache object.
Why you may need it?

  • To replace base cache logic, that should not be executed in some cases.
  • Forbid cache to read data for database in case of virtual DAC
  • Inject required logic to the standard workflow
  • Do not clear cache data on graph clearing
  • Access protected method
And many other things.

As you may know, that when you (or system) create a new instance of a graph, it will automatically instantiate all caches for each data views that are declared. Unfortunately, because this is unattended process it is almost impossible to adjust it for our own purposes.

But luckily Acumatica is very flexible system and there are several easy ways to do it lately after base initialization. So the reccomended solution will be:

  1. Create an graph extension for required Graph. Or also you may use constructor of the graph, if you develop new functionality.
  2. Override Initialize method to add your logic
  3. Create a new class for cache that should be inherited form PXCache<DAC> type.
  4. Instantiate a new cache object a new cache of the same DAC type.
  5. Replace original cache in the PXGraph.Caches collection with a new one.
On now it is done. You may use your new cache type and put logic there.

Code example:
public class InventoryItemFilterCache : PXCache<InventoryItemFilter>
       public InventoryItemFilterCache(PXGraph graph)
              : base(graph)

       public override void Clear()

       public override int Persist(PXDBOperation operation)
              return 0;

public class NonStockItemMaintExt : PXGraphExtension<NonStockItemMaint>
       public override void Initialize()
Base.Caches[typeof(InventoryItemFilter)] = new InventoryItemFilterCache(Base);


Have a nice Development!

Thursday, 6 October 2016

Provide Default Value for Report Parameter from Branch

Hi All,

Really often you may want to have some default values for report parameters, that may depend on environment. For example different default warehouse depend on branch where are you working now. Or different warehouse depend on current employee.
But unfortunately it is not out of the box functionality in Acumatica.

Luckily, using powerful Acumatica Customization engine it is quite easy to to. Let me share with you a way to archive it.

Scenario: lets assume that we want to have different default warehouse on Inventory Valuation report based on different branch that is selected as current.

We will do this task in 3 steps:
  1. Adding custom field to link branch and warehouse
  2. Create a class that can evaluate required warehouse by currently selected branch
  3. Provide default parameter in report 

Monday, 3 October 2016

Generate Grid Columns Dynamically

Hi All,

Today I want to show you an example how you can generate grid columns dynamically.
Sometime it is really important for dynamic inquiry report, where you want to show data that may be changed due to some other configurations.

To add columns dynamically you should follow this plan:
  1. Create a separate method that will generate columns.
  2. Call method create above from the graph constructor. Please not that if you put method into any event you need to make sure that you generation columns only once. Also you logic assume that columns may be changes if user select some other values on the same screen you need to make sure that you delete previously generated columns.
  3. On the columns go throught all new columns and do following:
    1. Add new Field to the PXCached
    2. Subscribe 2 events for FieldSeleting and FieldUpdating. These are most important events that are interacting with user interface. On the FieldSeleting you need to provide value and the configuration how this value should be displayed. On FieldUpdating you need to check, how system updated the value back to cache.
Here you can see a code snippet for columns generation:
protected void GenerateColumns(PXCache sender, List<String> columns)
       foreach (String column in columns)
              String key = column;
              String name = column;

              if (!sender.Fields.Contains(key))
                      this.FieldSelecting.AddHandler("Partners", key,
(PXCache cache, PXFieldSelectingEventArgs args) =>
                      this.FieldUpdating.AddHandler("Partners", key,
                             (PXCache cache, PXFieldUpdatingEventArgs args) =>


Friday, 23 September 2016

Custom Selector Attribute

Hi All,

Today I want to discuss with you a ways to define selectors and data for them.
Usually you define selectors like this:

In this case system will automatically select value from database Carrier table and show list of Carrier IDs to user.
In this case you have 2 potential problems:

  • you should have a database table, otherwise you will see an error.
  • There is no way to dynamically change or adjust data that is returned to user
  • You can limited configurations to control selector behavior. 

To solve these problem Acumatica has a Custom Selector attributes:
public class CustomerPriceClassAttribute : PXCustomSelectorAttribute
    public CustomerPriceClassAttribute()
        : base(typeof(ARPriceClass.priceClassID))
            this.DescriptionField = typeof(ARPriceClass.description);
    protected virtual IEnumerable GetRecords()
        foreach (ARPriceClass pc in PXSelect<ARPriceClass>.Select(this._Graph))
            yield return pc;


In this case you see that you have simple attribute, that is really similar to the attribute for first example. Using GetRecords method you can create a custom BQL querry, select any data you want, apply any filter and return it as a IEnumberble collection.
In the user interface you will see exactly data provided by your custom query.

Monday, 19 September 2016

Make compilation of extension library faster

Hi All,

When you develop customization using Microsoft Visual Studio you may notice that compilation process (if you click F6 or Ctrl+Shift+B) is really long - you may wait for 5-10 minutes.

Usually this happens because system compiles full solution that contains DLL and also Web Site. Site has multiple pages that have aspx markup and must be transformed before compilation. But actually this process is required only for validation purpose and does not require for Acumatica functionality, as ASP.NET will compile page any way one more time when you open it in browser.
You may read more about it here.

So as it is optional compilation you may guess that it can be disabled. Just go to web site property pages and deactivate 2 configurations:

  • Build Web site as part of the solution
  • Before run startup page - no build.

After this your compilation process will take just few seconds instead of minutes. And it is absolutely save for your customization development.

But we still highly recommend you to do one full compilation and validation before releasing of final production version of customization to ensure that there is not errors on final pages.

Have a nice development!

Wednesday, 14 September 2016

Acumatica REST API

HI All,

With Acumatica 6 release you can find (and actually use) new type of API - Rest API.

Acumatica Rest API is based on Contract based API, so here you have some important points:

  • You need to use existing or custom endpoint be able to send API calls
  • Field and container is available for REST API only if it is defined in contract. But you may extend existing contracts.
  • With REST API you have the same set of commands that you have with Contract Based API.
  • Acumatica uses Json format for transfer data between client and server
  • You still have to maintain session and authentication cookies.


Ok, lest try to do some examples. Here I will show you how to call Acumatica REST commands from Browser. By using this approach you can easily test functionality and just feel, how does it work.

Thursday, 8 September 2016

Mass Processing using GI

Hi All,

Lets assume that you have multiple records where you need to mass execute some action or update multiple fields to the new value.
From the I100 Acumatica Integration Services Training course you may know that you can do it with Export or Import scenarios. Integration Scenarios are some sort of the small program inside your ERP where you can update multiple fields, calculate depended values, execute actions and so on.

But what if you want to have more control on records need to be updated. Some sort of semi-manual mass updating tool? In this case Generic Inquiry Mass Update feature can be more interesting and useful.

Lets try to use it.

Monday, 5 September 2016

Disable Discounts Calculation for API Calls

Hi All,

When you creating a multiple AR/SO documents with multiple lines through the API, you may have a nice trick to little-bit optimize system performance.

By default Acumatica business logic is optimized for entering data from UI, so all variables as taxes and discounts must be recalculated on each document line.
But during bulk load you actually can do it just once - before document save.

Here you have extension that will disable automatic discounts calculation if you loading data from API or Integration services.

public class SOOrderEntryExtension : PXGraphExtension<SOOrderEntry>
       public virtual void RecalculateDiscounts(PXCache sender,
SOLine line, Action<PXCache, SOLine> del)
              if (!Base.IsImport) del(sender, line);


To calculate discounts before saving the record you can manually call RecalculateDiscounts Action from your code. Here is example for Screen-Based API.

List<Command> list = new List<Command>();
list.Add(new Value() { Value = "False", LinkedCommand =
schema.RecalculatePricesAndDiscounts.RecalcUnitPrices });
list.Add(new Value() { Value = "True", LinkedCommand =
schema.RecalculatePricesAndDiscounts.RecalcDiscounts });

Content[] result = screen.Submit(list.ToArray());

You can use the similar code for AR invoices as well.

Have a nice integration!