Monday, 29 August 2016

Restriction Groups Architecture

Hi All,

Today I want to share with you some technology information about how Acumatica Restriction groups works inside Acumatica.
Acumatica Restriction groups

For each group system assign one byte in the GroupMask Database column:
Group 1 - 0x8000 = 1000 0000 0000 0000
Group 2 - 0x4000 = 0100 0000 0000 0000
Group 3 - 0x2000 = 0010 0000 0000 0000
Group 4 - 0x1000 = 0001 0000 0000 0000
Group 5 - 0x0800 = 0000 1000 0000 0000
Group 6 - 0x0400 = 0000 0100 0000 0000
and so on

Here you can see that Acumatica numbers groups using bytes. Each group - one unique byte.
To maintain correct security rights fore new and removed groups Acumatica cannot reuse bytes that are already used, that's why you cannot delete existing groups.
Actually it can be changed/reused technically, but it require to update each record in database, that may be quite long on big databases.

When you assign some item to some group it actually sets the flags in the group masks for the item: Lets assume vendor belongs to group 3 and group 6, than mask will be
0010 0100 0000 0000 = 0x2400
Note that we have "1" exactly on position of group where this record belongs.

You can see exactly this configuration based on demo data:
User interface configurations:
And database:

Users are also belongs to groups by the same rule. Than system search for interceptions between groups to which user and entity belongs and than calculate calculate assess rights.
Also do not forget that there are different types of groups that can calculate interception and access rights differently.

Have a nice configuration.

Wednesday, 24 August 2016

Configuring Batch Payments for Custom File Format

Hi All,

Today I want to share with you an configuration way for new bank format. Out of the box Acumatica supports: ACH and GIRO file types.

Support for bank files works through configuration of 3 different components

  1. Batch Payments - Process where multiple payments can be combined to one single document. Exactly this document will be exported to payment file.
  2. Export scenarios - To generate real file from document Acumatica uses export scenarios with special data provider. Scenario is uses as instruction and columns mapping between file and acumatica.
  3. Data Provider - Knows how to generate required file. For different payment standard you may need to create a different providers, but luckily it is highly customization.

Lets start with Batch Payments.
You can setup special payment method that will be configured as "batch payment".

Later you can generate Batch payment document that will combine one or several payments into one batch (Screen ID: AP305000)

If you click "Export" button on this screen, system will generate file and attach it to the current document. But the actual export will be done with export scenario, that you configure for Payment Method on previous image. Here you can see an export scenario that you can copy and customize for your own format.
As I already mention, scenarios are mostly mapping between Acumatica Batch Payment document and file format. You selecting Acumatica and File fields and sometimes can just change some fields using formulas and other data manipulations.

Now we are coming to Provider configuration. Each provider consists of 2 main parts: parameters and fields configuration. Parameters is mostly responsible on some small configurations of the result data format. Sometimes when it is complex to change configuration with single property, you can decide to create own provider.
In Acumatica we have 2 out of the box providers:

  1. ACH Provider - mostly responsible for generation fix-width file format. Also it may be used for files with strict requirements for block size.
  2. GIRO Provider - mostly responsible for generation flexible and less structured file with no limitations on block or line sizes.

File format is defined by schema file, which is a simple text file attached to provider.

Schema file contains:

  • Header/footer information. This is #01 number on the begin of line. Number defines the level of sub group. #01 - is header and footer, #02 can be a group of documents, #03 can be details. For the GIRO provider usually it is enough to have only 2 levels
  • Placeholders for dynamic fields from Acumatica - values like this {H2_Corporate_ID:30}. This field will be visible in Acumatica Export scenario and can be mapped with data. Fields can contain some formation options:
    • ":30" - means that field should be not more that 30 characters in length.
    • ":-10" - means that field value should aligned to right
    • "NotKey|FillOnEnd" - define calculation parameters, like in the reports.
      • NotKey - means that field should not define new group when field is changed
      • FillOnEnd - means that data should be calculated in the end
    • "=TotalCount" - some formulas that can do simple calculations
  • Simple text, that will me stored as is. In my example all character like this "|||||||||||||||" means just a simple text, that should be there in the end file. Of course there are some parameters that can be passed there, but in our continuations it can be empty.

There are some more parameters that can be used when required, but i think it is enough for overview.

You also can create a new provider and inherit it from the base one. For example i'm providing here some simple provide that add new functionality for calculation running total:

public class MyGIROProvider : GIROPaymentProvider
       public override string ProviderName
              get return "MyGIROProvider"; }

       private decimal RunningTotal;
       public decimal AppendToTotal(decimal aAmount)
              this.RunningTotal += aAmount;
              return this.RunningTotal;


This function (AppendToTotal) we actually can use from Export scenarios.

Also you may note some yellow warnings on Source Objects. This means that we are using Data View that exists in Graph object, but does not exists in the UI, so it is some sort of hidden view. It is totally OK for this scenario and sometimes may be useful for you as well.
The good think for you to know Acumatica Platform and Customization tools - it may help you a lot if you want to define new provider.

This is the actual payment file result of new reconfigured provider:
actual payment file result acumatica

Have a nice configuration!

Friday, 19 August 2016

Extending Contract-Based API Default Endpoint

Hi All!

Today, I want to speak with you about Contract-Based Web Services API share with you new cool thing that is available in Acumatica 6 - Extensions of Contracts.

Using this feature you can reuse of all benefits of default endpoint that Acumatica provides you out of the box and just extend it with adding couple of fields.

OK, let me show you one simple example with 2 changes:
  • Adding one more entity to default endpoint. In my case it will be Country screen. Country is a standard table but the same way you can add all custom screens as well. 
  • Adding one more column to Journal Transactions grid. In my case I will add Inventory ID field, which is also standard field but it works perfectly for custom fields as well.

On our first step we need to create an extension on default endpoint. To do this you just need to select default, click "Extend Endpoint" buttons and provide name for new one.

When you do so, new Endpoint will be created and it will be inherited from default one. You can see that all inherited entities will be marked with arrow. Custom entities will be with no mark. 
So now you can add new screens and entities to your endpoint. I have created an entity for country screen.

You also can extend fields on any existing entity. I have selected Journal Entry screen, and have added a new row in the details grid.

If you check the services definition schema (WSDL schema), you will see that Acumatica merges all default and custom definitions into one schema.

That's all you need. Now we can use Visual Studio to define our integration code.

Provided code sample:
class Program
       static void Main(string[] args)
              DefaultSoapClient client = new DefaultSoapClient();
              client.Login("admin", "123", null, null, null);
              foreach (Country cntr in client.GetList(new Country(), false))

              JournalTransaction batch = client.Get(new JournalTransaction()
                      Module = new StringValue() { Value = "IN" },
                      BatchNumber = new StringSearch() { Condition = 
StringCondition.Contains, Value = "00000046" } }
                      ) as JournalTransaction;

              foreach (JournalTransactionDetail tran in batch.Details)


Have a nice integration!

Monday, 15 August 2016

PXViewDetailsButton Attribute for better navigation

Hi All,

Today want to share with you one new way how you can define navigation in Acumatica version 5.3.
navigation in Acumatica 5.3
From T200 Acumatica Framework Fundamentalist you may know that if you want to map action to any cell in the grid and show it as link you need to define LineCommand:

<px:PXGridColumn DataField="ProductID" Width="140px" LinkCommand="ViewProduct" />

But to be able to use it, you should define action, action handler, throw appropriate exception, hide it in data source and so on. Quite log and boring.

In Acumatica 5.3 there is a PXViewDetailsButtonAttribute that can do all these things for you.

    Where<Contact.contactID, Equal<Current<CROpportunity.contactID>>>>))]
public PXSelectReadonly<CROpportunit> Opportunities;

This attribute will do following:

  • Will add dynamic action with name <DataView_Name>_<DAC_Name>_ViewDetails. So in our example it will be Opportunities_BAccount_ViewDetails and Opportunities_Contact_ViewDetails.
  • Will add an action handler where it will search for required entity based on provided BQL and do redirect.
  • Will hide dynamic action in data sources.

So as the result you just can go to aspx file and use it!

<px:PXGridLevel DataMember="Opportunities">
              <px:PXGridColumn DataField="OpportunityID" />
<px:PXGridColumn DataField="BAccount__AcctCD"
LinkCommand="Opportunities_BAccount_ViewDetails" />
              <px:PXGridColumn DataField="Contact__DisplayName"
LinkCommand="Opportunities_Contact_ViewDetails" />


In the result you code is cleaner and the result is nicer.

Also note that you may have multiple PXViewDetailsButton attributes that will generate multiple buttons.
As an addition you can configure action behavior with attribute properties:

  • Custom action name by explicitly specifying it
  • Window open mode: popup or window
  • What to do when popup is closed - refresh data for example.

Have a nice Development!

Thursday, 11 August 2016

Sync files from Acumatica to FTP server

Hi Everyone,

In Acumatica for every file you have in the database you may enable exporting or importing it to several supported protocols:
  • Shared Folder
  • FTP
  • HTTP
* Unfortunately HTTP protocol is supported only for downloading.

Today I want to share with you configuration and usage flow of file synchronizations based on File Transfer Protocol (FTP). Please be sure you have one if you want to complete this exercise.
ftp acumatica
All acumatica files should be attached to one or multiple entities. So you can find files attached to one particular document/line or you also can use search in files screen:
ftp acumatica

If you select single file will be able to see some configuration as well as other important information such as versions, security and synchronization.
Lets speak about synchronization in details.
synchronization ftp acumatica


Monday, 8 August 2016

Cool ways to use PXFormula

Hi All,

Acumatica platform continuously evolving and includes more and more new cool features to optimize your code and save time on development and testing.

Today i want to share with you some really cool features of PXFormula attribute and how to use it to significantly simplify your cod
PXFormula attribute acumatica
Here I want to cover following parameters:
  • Validate - Validate<field>
  • Current - Current<TRecord.field>
  • Parent - Parent<TParent.field>
  • IsTableEmpty - IsTableEmpty<TRecord>
  • Selector - Selector<KeyField, ForeignOperand> 
Welcome in details if you need examples.

Thursday, 4 August 2016

Using of PXRestrictorAttribute

Hi All,

Today I want to speak with you about PXRestrictorAttribute usage and examples.

Lets start with PXSelector, as they are lies together. The PXSelectorAttribute attribute is required for selecting some dependent data. Also selector maintain consistency and checks that referred data exists and meets required conditions.
However from development stand point it has two major drawbacks:
  • It gives the uninformative message <object_name> cannot be found in the system if a record with a given key does not meet the selector condition.
  • When you change other fields of the object, the selector incorrectly gives the same message if the object referenced by the selector has changed and no longer meets the condition of the selector.
The PXRestrictorAttribute can be used to solve these problems.

Monday, 1 August 2016

Passing parameters from UI to PXSelectorAttribute

Hi All,

Today I want to speak with you about passing UI parameters to the server code and PXSelector attribute.
Lets assume that you have some document (like AR Invoice), where you have 2 keys: document type and document number. If you want to add reference to the this document for other screen (like payment), you need to have 2 selectors, that are depend on each other.
PXSelector attribute

In this example we have a selector that depend on MultiPaymentInvoice.invoiceType. But how to correctly define this dependency. Here I want to describe 3 ways to archive it:
  • Current Parameter with Sync Position
  • Current Parameter with SyncGrid Paramenter
  • Optional Parameter with Control Parameter 
Lets discuss all of them.