1. Home
  2. ERP
  3. Acumatica
  4. Transactions and Licensing

Transactions and Licensing

Acumatica Licensed Seats

Acumatica limits the number of Web Services API Users based on your license tier.
The following rules apply to how Acumatica licensed seats are occupied when using
StarShip:

  • Every open Web Client with a logged-in user takes up one Acumatica seat for the entirety of each session.
  • An additional seat may be temporarily used when the Customize Interface or Value
    Translations screen is open in StarShip.
  • An additional seat may be temporarily used when the Acumatica Setup window is open (Setup > Source Interface > Acumatica) in StarShip and the user is editing the company. For example, if a user is updating Acumatica’s Current System Version in StarShip, this will temporarily occupy a licensed seat.
  • Keep in mind that having the Acumatica application open also occupies a licensed seat.
  • If the maximum number of allowed parallel connections is reached, each new connection will cause Acumatica to log a user out of one of the existing connections.

Transactions (Acumatica 2018 R1 and later)

Acumatica implements throttling based on license tier. Throttling limits the number of requests that can be submitted to the Acumatica Web Services API in order to prevent the web service from being inundated with requests. Depending upon your tier and the number of requests you are allotted, this can affect the speed of using and processing shipments with StarShip. You can check your licensing limits in Acumatica from Configuration > Common Settings > Licensing Monitoring Console. Acumatica also provides a License Tiers Chart for an overview of what each tier includes.

StarShip, as well as any other application that is using the Acumatica API, will
affect these system limits:

Maximum Number of Web Services API Users

This system limitation represents he maximum number of simultaneously signed-in users
whose accounts are used by external applications that may connect to Acumatica ERP
by using the web services API. When an extra user tries to sign in to the system,
an error message is displayed (Error HTTP 429) and the sign-in process is interrupted.

Each connected StarShip Client will use one seat, as well as the temporary and other
cases listed in the Acumatica Licensed Seats section above.

Maximum Number of Concurrent Web Services API Requests

This represents the number of Web Services API seats that can send Web Services requests at any given time.

The maximum number of Web services API requests that can be run concurrently by external applications that connect to Acumatica ERP. When the number of simultaneously run processes reaches the limit, the system starts queuing requests. When the queue contains 20 requests, each extra request is declined. If a request is waiting in the queue
for more than one minute, it is declined.

To minimize and manage the impact of Acumatica throttling, you can use the setting found in Setup > Source Interface > Acumatica > Additional Options. This option lets you set the Number of Concurrent Web Services API Requests that StarShip can send to the Acumatica Web Services API. This applies to Acumatica 2018 R1 and later; users of earlier versions can leave this value set to the default of “0” to indicate no limit. See Additional Options for more information.

It may appear that shipment processing is slower because StarShip has to wait to send requests to the Acumatica Web Services API. StarShip will effectively “hold on” to transactions until the Web Services API is ready to accept them.

Maximum Number of Web Services API Requests Per Minute

This system limitation represents the maximum number of requests per minute that
external applications can send to the Acumatica Web Services API. If the number of
requests per minute exceeds the limit, the system declines extra requests (throttling).

As a guide, we have provided an average number of transactions that StarShip sends
for typical actions performed during shipping in the table below. StarShip will send
multiple requests per action that depend upon the type of order. Any one workstation
will use the number of transactions shown in each row. Keep in mind that the number
of transactions is also affected by the number of workstations performing the same
actions, or any custom fields that are mapped. For example, when you first load StarShip,
this uses 20 transactions but this number can very. You may want to look at your
other third party apps to see how many transactions they use as well.

We’ve provided some common actions in StarShip and the average number
of transactions they require per workstation below:

Actions: Connect, Get Lists, Reference Data (20 transactions)

Notes: When you remain connected to a company, these transactions do not repeat. Switching companies will use 20 more transactions.

Actions: Search Sales Orders (2 transactions), Load Sales Order (4 transactions), Write-Back to Sales Order (4 transactions).

Notes: These actions add up to a total of 10 transactions. 1 or 2 additional transactions may occur if custom fields are in use.

Actions: Search Shipments (1 transaction), Load Shipments (8 transactions), Write Back to Shipment (4 transactions).

Notes: These actions add up to a total of 13 transactions. 3 or more additional transactions may occur if custom fields are in use.