Changing Default Currency in a Data Entry Screen

Hi Everyone,

One of our customer asked to change the USD currency, system uses by default, when opening an empty data entry screen. Say if our base currency is USD, system will use it as default, but in that particular screen, say Journal Transactions entry, they wanted it to be SGD. Just because 90% of all the entries in that screen are SGD. Seemed simple... but...

We faced a real issue customizing it, Currency control is a specific one... And currency rate needs to get auto updated...

Finally, with Ruslan's help we've found a workaround.

All is needed - to add below code to a constructor of the Journal Entry screen:

  #region Event Handlers
protected override void Batch_CuryID_FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e)
{
  e.NewValue = "SGD";
  e.Cancel = true;
}


protected override void CurrencyInfo_CuryID_FieldDefaulting(PXCache sender, PXFieldDefaultingEventArgs e)
{
                e.NewValue = "SGD";
                e.Cancel = true;  
}

protected override void CurrencyInfo_RowInserting(PXCache sender, PXRowInsertingEventArgs e)
{
    base.CurrencyInfo_RowInserting(sender, e);
    sender.RaiseFieldUpdated<CurrencyInfo.curyID>(e.Row, null);
}

All the best,

Sergey.

Recommendations based on Resource Level Licensing (CPU Cores)

Hi Everyone,

There are many questions from partners on what Resource Level of the Licensing to recommend based on specific customer patterns.
What we have on the plate is: S, M, L, XL sizes, which determine number of CPU cores at IIS server. Let me discuss the Subscription on Premise or Perpetual licensing schemes with on-premise deployment. Other words, your IIS server is sitting right in front of you and you have chance to modify it and you are not sharing it with anyone else.

End user concerns for Acumatica licensing come from certain factors:

• Number of transactions and operations per second – it directly affects CPU utilization
• Modules in use – can affect system performance as SO/FA modules take more CPU time for business logic and initial screen loads
• Usage of Import/Export functionality – Import directly affects CPU usage and should be planned ahead, very critical item for capacity planning
• Number of account/subaccounts – affects most of reports execution time as well as integrity checks and processes
• Number of Fixed Assets, other entities if they become more than 10,000 (Inventory ID, Vendors, Customers, Employees etc.) – affects system performance on processing screens, initial openings and reports

Guidance for Named Users

The main problem is that customer does not always have information about transactional/operational usage.
We should transform it to more user friendly “named users concept” to identify average transactional payload.
We can help here by identifying the users as Heavy, Medium and Light. Let the end customer to tell us how many of each users they have in the organisation. Well the "user" could mean a person, or it can also be a machine entering the data, or device like POS system. I will touch data import specifically later, considering it as Super heavy User :)
Lets categorise the User types by the amount of time they spend with Acumatica ERP:

Heavy Users: 200 Operations per day  1,500 Transactions for data entry per day.
Medium Users:      50 Operations per day 500 Transactions for data entry per day.
Light Users:      10 Operations per day 5 Transactions for data entry per day.

By "operations" I mean accessing the screen or report , also by logins etc.
Next we should determine the time when users are actually working per day. Practically we can say that most of the data entries are done during 2 major time frames: 2 hours at any time before lunch and 1 hours after lunch.

Meaning we can reduce working day for particular Acumatica usage for 3 hours per day only (3*3600=10,800 sec). Meaning that all the transactions that user does per day will have to be made within 3 hours interval, therefore creating more load to the CPU. It is very conservative.
In fact there could be times (end of month, internal audit etc.) when number of transactions significantly increases within just single hour. But I would like to skip those peak loads for now.
We can use standard guidance for total number of transactions plus operations per CPU per hour in this case, assuming there are 3 hours in a day.
Another scenario could be the users sitting in multiple offices, working with the ERP at different time zones, anyway, good enough approximation would be active usage of ERP is 3 hours out of 8 working hours per day (well lets make our system to be stressed a bit).

To calculate how many CPU cores for IIS server is required, just calculate the result of the
(H.U.*1700 + M.U.*550 + L.U.*15)/10,800=Ops Per Second
H.U – heavy users, M.U. – medium users and L.U. – light users.

Based on result you can roughly estimate the number of CPU cores required.

Ops Per Second Recommended Number Of CPU Cores
Less than 5 2
5 to 10 4
10 to 20     8
20+          16

Guidance is based on average, not peak consumption, we should also reserve CPUs for data import processes if any, see below the guidance for Data Import.
It is always recommended to add 1-2 extra CPU cores to the calculated number for the sake of stability during peak loads.

Guidance for modules used

Fixed Assets module require single CPU sometimes when new screen starts, same for Sales order screen and some processing inside SO module.
Therefore it is recommended to add 1 CPU core to the total number of licensed calculated CPU cores in case of FA or SO module is in use.

Guidance for determining CPU brand and model

Looking at current CPU technology, let’s compare most advanced latest CPU with 3 years old same frequency CPU:

As you may see, Single thread execution for the core have increased from 1,238 to 1,758 or just 40% for the last 3 years.

Let me explain what Single Thread Rating actually is - it is the speed measurement of the single core of the CPU. Other words - it determines HOW FAST your Acumatica will chew the data entered. And the thing is - Clock Speed of CPU it something that DIRECTLY affects that Single Thread Rating. It is something like REVs at your car tachometer, so more you press - faster you go uphill. Well, take note, car Gear 1 is equivalent to CPU Turbo Mode, car Gear 5 is similar to "Super Power Saving (or whatever Intel marketing dept says)"  mode :).  Other ratings are not that important.

The only real advantage we are getting here is 4 cores versus 10 cores per CPU chip.
But, technically, I could have placed more of older CPU chips into a single hardware box to get similar results with new CPU chip, so 10 cores vs. 4 cores is rather “questionable” advance.

For me it signifies that CPU manufacturing technology actually reached the peak in terms of single CPU core speed and we can use “standard CPU” term when recommending hardware requirements.

The choice of CPU for particular hardware configuration does not affect system speed for more than 20-40 %, so paying extra multiple times $$$ for 30% increase in CPU speed…up to you.

Finally. It makes much easier for the end customer to choose the CPU model for their server.
The only critical is CPU Clock speed, in our case it is 2.8/3.6 GHz for normal/turbo modes respectively and desired number of cores, that is only limited by our licensing terms.

Guidance For Data Import Process

For the data imports I suggest to use standard approach, based on import to Sales Orders screen. It takes most significant time to process lines of average 0.1 sec per line per dedicated CPU core.
It means that every line (not the order) we import in the system will occupy the single CPU core for 0.1 second. If we use more than single Import process it will occupy another CPU core, and if number of processes is bigger than number of licensed CPU cores, IIS server will start parallel execution for imports, that will effectively mean that time for single line will get doubled/tripled etc.
Let say we do import of 100,000 order lines into our system and we split these imports according to the table below, see column 2. Say for line 2 we split 50/50, for line 3 we split 33/33/33, line 4 we split by25/25/25/25 the total number of lines into multiple import processes.

What is significant here is the single import always takes single CPU core, does not matter how many licensed CPUs you have purchased. And single CPU core always gives 0.1sec per line performance.
But multiple CPU cores provide advantage if we split the import process into multiple.
Please also note, when you assume other users will use the system at the same time when you do the import, please do not run more Imports that total number of all CPUs less one, to allocate at least one CPU for the end users for data entry.

Please note however, that 0.1 second per order line per CPU core is the best time achieved so far. Under some production environment conditions, with complicated discount calculations the worst time seen yet was 0.5 sec per line per CPU core. You will need to adjust the figures from the table accordingly.

Large number of Entities

In case of the large number of Accounts/Subaccounts, Fixed assets or any other master items is recommended to increase the amount of RAM for the IIS (6-8GB). It is also recommended to increase the performance of the SQL server by placing more RAM and improving I/O speed.

RAM/HDD Considerations for IIS Server

As Acumatica system is optimised not to use more than 4 GB or RAM per single Application Pool, we can recommend to use 4-6 GB RAM for IIS server.
Hard drive on IIS server is not engaged most of the times, therefore you can place any type of it and any reasonable size as well.

CPU/RAM/HDD Considerations for SQL Server

Even though we are not restricting you the license for SQL server, I would like to mention recommendations for it.
As SQL server is very memory hungry application, that tends to place all the data into RAM for faster indexing and calculations, it is recommended to put there as much RAM as possible.
Secondary consideration is hard drives. It is recommended to use SSD drives, SSD Arrays or SAN Arrays to keep your data Input Output operations as fast as possible.
As per CPU, SQL parallelism optimization inside SQL server itself is good enough for dual core server, you can still put more CPU cores on it, based on hardware servers availability, it will not however significantly affect the server performance. There are more optimizations that can be done on SQL server but this is out of scope for the current topic.

All the best,
Sergey.

Customizing Numbering in Acumatica

Hi Guys,

Acumatica has flexible numbering sequences that allow us to create prefixes, separate numbering sets and basically serves well when there is a uniformity for the numbering for a given screen.

For example, when we issue specific number for specific month or year we can always create separate numbering sets with starting date from effective date for that month or year and problem will be solved.
Here is the example of numbering set for AR payment screen, where each month system will generate numbers for Payment Reference ID starting from predefined prefix and month code:

When we look at AR Setup screen, this numbering sequence ID is specified at Payment Numbering Sequence:

But this example is too simple. What if we need to use special numbering under specific condition. For example, when you do synchronization with external system, Oracle for example, it may be that you are getting Payment ID numbers from there, and need to override the Auto numbering sequence that is in force at your setup. Another words, from Oracle you can get number starting from IV instead of RV and the number itself should be from Oracle, not generated by Acumatica.

To solve it, we can add Numbering Sequence as a custom field to our setup screen. Just add a field to AR Setup, and make it same as other payment numbering sequence fields:

 Here is the customization code behind it:
<DAC type="PX.Objects.AR.ARSetup">
<Field FieldName="UsrARImportID" TypeName="string" MapDbTable="ARSetup" TextAttributes="#CDATA">
<CDATA name="TextAttributes"><![CDATA[[PXDBString(10, IsKey=false, BqlTable=typeof(PX.Objects.AR.ARSetup), IsFixed=false, IsUnicode=true)]
[PXDefault("ARIMPORT")]
[PXSelector(typeof(Numbering.numberingID))]
[PXUIField(DisplayName="Import Numbering Sequence")]]]></CDATA>
</Field>
</DAC>

And then we should create a new Numbering Sequence called ARIMPORT. Here is the hint, if we need number to come automatically from Acumatica, then we should feel it with something, but if number is provided from outside, say MANUALLY, then we can just create the ID ARIMPORT, leaving content blank:

Now next step, somehow we need to identify that the Data Import is going on. We have a special function to do it. So now I will go to the AR screen, then add data event Row Persisting, to the Document Level. Basically the number for the AR Invoice or payment is issued on save :)

Please take note of this.IsImport it changes to True when we do data import from Oracle.
Next we should tell the screen if this is Data Import process, not to use standard numbering sequence but to look at newly defined ARImport one:

So here we only do at Inserting the row, then we create numbering variable and pass whatever we keep in AR Setup, in our case it will be ARIMPORT value. Then we select from table Numbering the content for the ARIMPORT row. If we do have it there, we set autonumber variable to False.

So now we can decide what do we do, we manually populate the number from our Import file or call autonumbering process from ARIMPORT predefined sequence.

I do here manual population from the field UsrOrigRefNbr from the Import file.
But you can use commented code to call AutoNumberAttribute process to generate the number based on ARIMPORT Numbering Sequence content.

All the best,

Sergey.