When you have to do custom work in Apex to automate things on FinancialForce Accounting (FFA), you are likely to get error messages telling you that you don’t have any current companies. Even when you’re not working directly with FFA module, you may need to eventually setup an FFA company in Apex. For example, when working with FinancialForce Supply Chain Management (SCM) in an integration with FFA, you have to set the company on the sales orders and purchase orders in SCM in order to push SCM invoice into FFA sales invoice, and SCM AP Vouchers into FFA Payable Invoices.
FFA companies are represented both by records of the custom object ‘Company’ and by User Queues. It’s usually recommended that companies be created in the Accounting Quickstart process. This is a user-friendly process that speeds up the configuration of FFA by creating companies and much more, but for the purpose of this article, we will focus on companies. We will also assume that you already have at least one valid company properly set up by the Accounting Quickstart process to follow the explanations.
We will first look at the company record(s) in the custom object: go to the + sign on your SalesForce menu to see all tabs, and click on the Company tab. Open any existing valid company. Notice the owner of this company record – regardless of who has run the Accounting Quickstart process, this user won’t be the owner of the company record. Instead, you are likely to see something like ‘FF_YourCompanyName’. This is the User Queue associated to this company.
Now go to Setup/Manage Users/Queue. Look for ‘FF_YourCompanyName’. Notice it has a lot of supported objects such as year, sales invoice or journal. Open this queue, and notice there might be a list of users that are members of this queue. These users currently have this company selected as their current company. They might be member of more than one company queue (multi-company mode), depending of their access to the different companies in the organization. Their access to select different companies as their current company is defined in the custom object ‘User Company’. If there are some users who cannot select different companies due to a lack of an FFA license but still need to be related to an FFA company (for example, sales reps doing customer quotations in CPQ and then turning them into sales orders: they typically do not have an FFA license, but there is still a need for specifying the company on the sales orders records they create), they can be directly added to the appropriate queue here. If the users would need to be able to select different companies without access to FFA, more customization would be needed.
When working on a sandbox, it is possible to have existing queues from the production organization, except there is no Company and User Company records to go with it. This is because the Company and User Company are records of non-setup objects, which are usually not replicated in sandbox (unless you create a ‘full’ sandbox). The queues, however, are setup objects – so they are replicated just like users or security profiles. The fact that FFA companies are a queue makes it a little more complex to handle in Apex, but it is feasible, which makes it feasible also to avoid running test with the nasty @isTest(seeAllData=true) annotation. However, you will need to change context between DML operations on setup objects and non-setup objects using System.runAs(someUser), or to use the @future annotation to perform the DML operations in different transactions.
With this blog post you will find a trigger that sets the current user’s current company on a purchase order (you can easily replicate this for the sales order), its test class, and the test data factory that creates the company for the test class. Please do not blindly copy-paste: it currently works as is on most of our implementations, however depending on the customizations that might have been done in your organization, you might need to adapt it. For example, on one of our implementations, we had to remove the error message of the trigger.
Now let’s have a look at the trigger:
Here, we look for a company record whose owner id is a queue in which the current user is a member. This means we are looking for this user’s current company, if any. Multi-companies mode is possible in FFA when it comes to viewing records or reports, but you must have only one current company selected when you create records. This is why we check if we get one and only one result from this query. If there is no result, the current user has no current company, if there is more than one result, the current user is in multi-companies mode. We then write this company on the purchase order if the user has not already specified one when filling the object form.
Let’s have a look at the test data factory now, which creates a FFA company:
Here the taxRegistrationNumber is not mandatory, we just happened to need it for printing it out in some VisualForce templates. Up until very recently we didn’t bother specifying a record type, but with the latest release of FFA v13 there is now a new company record type called ‘Combined’ to support Canadian taxes, so for some customers we do need to specify this too.
We can then reference this test data factory in the test class for the purchase order trigger, where we test 5 scenarios. The first 3 scenarios return an error: the current user has no current company, the current user is member of a queue which is not a company queue, or the current user is in multi-companies mode. The fourth scenario tests if the user already specified a company on the new purchase order before saving it – in this case, we do not want to overwrite it. Finally, the last scenario verifies that if the current user has one company selected as his current company, it gets written on the purchase order.