Wednesday, October 8, 2014

ERP Software Seletion and Implementation Tips

Companies often know that this day would come.  The last workaround you implemented was also the last straw.  It is time to replace your antiquated accounting/software ERP system with something that will relieve some of the stress building around your company, and hopefully give it an economic boost that will take it to the next level. Those are lofty goals and not easily achievable with just any ERP software solution. 
The next thing you know long meetings and discussions on what's the best way to select a new ERP software? Countless companies face this question every year.

Too often, people select an ERP system based on factors such as price, current technology buzz or the system that is the flashiest. But without a good fit, companies are left with expensive customization and bolted together solutions

ERP Selection and implementation without a due diligence can really bite you.
 
 
 
Whatever your reasons for looking for a new ERP system, the following questions will help you during the selection process.
  • What do reference users have to say about the system?
  • What's the total cost of ownership for 5, 10 and 15 years?
  • How much will later expansions cost?
  • Does the provider have a proven implementation method?
  • How easily can add-ons be integrated?
  • Is the system user-friendly?
  • Does the provider guarantee upgrade compatibility at reasonable costs despite customizations?
  • Is the system available internationally?
  • Does the ERP provider have a sound foundation for the future?
  • Does the System Integrator has the right skills and valid references?
  • Does it available in cloud based install or on premise only?
Keep these key questions in mind as you begin and work thru the ERP selection process. Find an ERP system that is industry-specific, with tools and features designed to solve your business requirements. The ROI and long-term benefits of a good fitting system are extensive. Your choice for which ERP partner to work with is almost as important as the choice of which ERP package will best fit your business.

While there are many ERP solutions that will give you portions of what your company needs, there is one clear winner that can deliver them all. Microsoft Dynamics AX can provide your business with robust flexibility and software integration with other business mission-critical applications like Microsoft Dynamics CRM and Microsoft Office 365.  The right choice is clear.

Until next time Cheers !

Saturday, July 19, 2014

Royalty Management in Microsoft Dynamics AX 2012 R3

Microsoft Dynamics AX 2012 R3, provides functionality to manage royalty agreements and claim amounts, book their accruals and manage payments.

What is a Royalty?

Royalties can be defined as paying certain amount to the owner of a property or a brand for the usage of property or brand. Normally, the original owner of a product sells their product against a certain share of future revenues.
The common practice is the usage of Brand names by third party, in this case, a company use a brand owned by another company and pay a specific percentage of sales to the brand owner.
Microsoft Dynamics AX2012 R3 provides complete solution of Royalty Management, whereby, organization can manage royalty agreements, claims and their payments. In the following lines, the solution is illustrated to help consultants and users:-

Royalties Management with Microsoft Dynamics AX 2012 R3

1

Parameters – Accounts Payable

In the accounts payable parameters, select the “Broker and Royalty” tab as shown in the following screen shot.
2
  1. Starting day of week would be required in case of royalty calculated on weekly basis.
  2. The accrual account is the liability account in which the royalty liabilities would be credited
  3. The expense account is the charge account where the royalties would be charged.
  4. Procurement category is used for vendor invoice creation to pay the royalty liabilities.

 Royalty Agreements

After setting up parameters, the next step is to define the Royalty Agreement, for this purpose, in accounts payable module click common click royalties and then click royalty agreements, as shown in below screen shot.
3
The following is the royalty agreement form which has two important parts i.e. Header and Line.
4

Royalty Agreement – Header

In the header section of Royalty Agreement, provide the information of vendor to which the Royalty is payable and then provide the basics of calculations.
FieldDescription
Royalty contractEnter the identifier for the royalty agreement; the identifier is used to determine the royalty type and default ledger accounts for this agreement.
Vendor accountSelect the vendor for the royalty contract.
DescriptionEnter a description of the agreement.
UnitEnter the unit of measure for the royalty quantity.
Unit typeSelect or view the royalty agreement unit type. The values are Inventory unit and Catch weight unit.
Unit of measure royalty optionSelect the unit of measure royalty option for the royalty agreement. This option identifies the unit of measure for the royalty line. If you use the Exact match option, the unit of measure for the royalty line must exactly match the unit of measure specified in the sales order. If not, the royalty does not qualify. If you use the Convert option, the unit of measure for the royalty line is the same as the unit of measure for the royalty agreement. The royalty unit of measure is converted to the sales order unit of measure, or the catch weight unit of measure, based on the option selected in the Unit type field.
Calculation date typeSelect the date type, which is used for royalty calculation. The values are:
  • Created: The date when the sales order was created
  • Requested receipt date: The requested receipt date of the sales order
  • Requested ship date: The requested ship date of the sales order
Start dateEnter the date on which royalty management begins to create accruals based on the agreement. If the agreement is effective immediately, leave the field blank.
End dateEnter the date on which royalty will no longer be created based on this agreement. If the agreement does not end, leave the field blank.
Cumulate sales bySelect the period during which invoiced lines will be added and compared against the agreement. The options to select from include Invoice, Week, Month, Year or Customized period.
Period typeWhen Cumulate sales by is Customized period, you have to select the period type to cumulate the sales.
Taken fromSelect whether the royalty value is based on the gross or net of the sales order line.
Accrual accountEnter the ledger account to be used for interim liability postings.
Expense accountEnter the ledger account to be used for interim expense postings.
CurrencyThe currency type determines the currency in which royalty is remitted. You can specify a generic currency, which is converted on the order, or you can specify a specific currency for the royalty.
Approval requiredSelect if royalties created from this royalty agreement require approval before they are processed to the ledger accounts.
Calculate bySelect if the royalty break is based on quantity or amount.
ValidatedShows whether the royalty program is validated.
Validated byShows whether the royalty program is validated.
Item numberSelect the items which qualify for this royalty agreement.
Product nameShows the product name of the item.
UnitShows the sales unit of the item.
SiteShows the default sales site of the item.
WarehouseShows the default sales warehouse of the item.
LocationShows the default issue location at the default sales warehouse.
NoteYou can enter specific notes for the royalty agreement.

Royalty Agreement – Lines

At the line level of Royalty Agreement, provide the information on the basis of which the royalty amounts would be calculated, in also contains the specific items on which royalty has to be calculated. However the item on which the royalties are calculated can be defined at the header level but in case, the royalty is payable to one vendors on all sales and to one another vendor on sales of a specific item, the specific item will be described at the line level.
FieldDescription
Royalty codeEnter the identifier for the royalty agreement; the identifier is used to determine the royalty type and default ledger accounts for this agreement.
DescriptionEnter a description of the agreement.
Vendor accountSelect the vendor for the royalty contract.
Calculation date typeSelect the date type, which is used for royalty calculation. The values are:
  • Created: The date when the sales order was created
  • Requested receipt date: The requested receipt date of the sales order
  • Requested ship date: The requested ship date of the sales order
CurrencyThe currency type determines the currency in which royalty is remitted. You can specify a generic currency, which is converted on the order, or you can specify a specific currency for the royalty.
UnitEnter the unit of measure for the royalty quantity.
Amount typeSelect the amount type of the agreement:
  • Amount per unit: A certain amount per sold unit.
  • Fixed amount: A fixed amount for a range of quantities sold.
  • Percentage: A certain percentage of the net amount sold.
Start dateEnter the date on which royalty management begins to create accruals based on the agreement. If the agreement is effective immediately, leave the field blank.
End dateEnter the date on which royalty will no longer be created based on this agreement. If the agreement does not end, leave the field blank.

Royalty Agreement – Lines – General Tab


FieldDescription
Royalty codeEnter the identifier for the royalty agreement; the identifier is used to determine the royalty type and default ledger accounts for this agreement.
NoteEnter a comment or note for the agreement.
DescriptionEnter a description of the agreement.
Vendor accountSelect the vendor for the royalty contract.
CurrencyThe currency type determines the currency in which royalty is remitted. You can specify a generic currency, which is converted on the order, or you can specify a specific currency for the royalty.
UnitEnter the unit of measure for the royalty quantity.
Calculation date typeSelect the date type, which is used for royalty calculation. The values are:
  • Created: the date when the sales order was created
  • Requested receipt date: the requested receipt date of the sales order
  • Requested ship date: the requested ship date of the sales order
Start dateEnter the date on which royalty management begins to create accruals based on the agreement. If the agreement is effective immediately, leave the field blank.
End dateEnter the date on which royalty will no longer be created based on this agreement. If the agreement does not end, leave the field blank.

Royalty Agreement Lines – Selection Tab

FieldDescription
Item numberSelect the items, which qualify for this royalty agreement.
Product nameShows the product name of the item.
UnitShows the sales unit of the item.
SiteShows the default sales site of the item.
WarehouseShows the default sales warehouse of the default warehouse.
LocationShows the default issue location of the item.

Royalty Agreement Lines  – Royalty Amount Tab

FieldDescription
From valueFrom quantity/amount in which a royalty has to be calculated.
To valueTo quantity/amount in which a royalty has to be calculated.
ValueEnter the value of the royalty.

Following is the basic process flow for royalty claims, when items which are associated with royalty agreements are invoiced through sales order, the royalty claims are created. The royalty amount can be viewed in sales order line>Price Details>:
5

Royalty Claims

Click Accounts Payable>”Royalties”>”Royalty Claims”, to cumulate and process royalty claims.
6
In case approval is required on royalties, the royalties can only be cumulated after approval.
The status column on royalty claim provide following information about the claim:-
  • To calculate: The final royalty amount is pending completion of the cumulate royalties run. This status applies to royalty claims that are generated from weekly, monthly or yearly agreements.
  • Calculated: The claim was cumulated and is pending approval.
  • Approved: The claim had been approved if approval is required.
  • Mark: The claim is available for processing.
  • Processed: The claim was processed and a vendor invoice was posted.

Cumulate Royalty Claims

After invoicing the sales order, user has to cumulate royalty claims. This will sum up royalty claims amounts. The royalty amounts can be cumulate on each invoice, week, month, year or a customized period.
7
Once the royalties are cumulated and processed, the status of royalty claim will be set as “completed” and the vendor invoice will be posted, which can be paid.
8 

Until next time Cheers !

Monday, June 30, 2014

Automatic Bank Reconciliation in AX 2012 R3


One of the most interesting new features of Dynamics AX 2012 r2, and one which was crucially missing in previous versions, is the ability to import then automatically reconcile bank statements.
Bank Reconciliation, when done manually, can be an extremely long and tedious process. Some studies show that automating this process can reduce time spent on it by 70%.So, when you do the math, the return on investment can be very quick !
You must first of all set up the file format you want to import. For this you need to set up a Service /  AIF Inbound port, and link it to a bank format resource. AX 2012 comes with 3 standard formats : MT940, BA12 and ISO20022 (SEPA). All banks / countries using a specific format has been one of the key issues in the past, but the introduction of the common SEPA format inside the Euro-zone in 2014 should make this easier, for Europe at least. Of course, more formats can easily be developed and added to this list of resources.
Once your format is set up, you simply import the file received from your bank as a Bank Statement :
Dynamics AX 2012 r2

Microsoft Dynamics AX 2012
The detail of your bank statement is then read from your file and imported as a bank statement in AX :
Ax 2012, erp solutions
Now create a Bank reconciliation journal for this bank account, you will see that AX displays a screen with 3 sections :
1 - shows the transactions from your bank statement
2 – shows the unreconciled transactions on your bank account
3 – shows the transactions matched :

Automatic Bank Reconciliation in AX 2012
No transactions are matched so far, but you can now run matching rules, either one by one or in a pre-defined order (Matching rule set). These rules can be defined like this :

So, for example, the first rule can try to match transactions where amounts are identical AND Document Number in the statement = Payment Reference in AX, then the second rule can try to match only when amounts are equal. Tolerance can also be set on amounts, dates etc…
Once you run these rules, AX matches the transactions together. Here 2 transactions have been matched, and reconciled :
Microsoft Dynamics AX 2012
Your reconciliation was automatically performed. It can be amended manually if some transactions could not be reconciled automatically, then your reconciliation can be posted.
So AX 2012 now offers a highly efficient and flexible way to automate your bank reconciliation.
Until next time Cheers !

Tuesday, April 1, 2014

Bank Reconciliation in AX2012

In this post I would like to explain, how to do the Bank Reconciliation and few notable points during the reconciliation.

I’m taking an example of Bank Account whose currency is “USD” and also, my company currency is “USD”. Below is the list of Transactions in my Bank Account.

Now, How to start reconciling..? Assuming that we got a statement from Bank on 30th June-2012 which is listing the transaction of USD 10,000, USD -500 and USD -1500 and also some charges levied of USD -50.
The closing balance that may appear in the bank statement shall be USD 7950.
Click the button Account reconciliation to start the reconciliation. In the “Bank statement form” that is opened, enter the Bank Statement date, Bank statement identification and the Ending balance(In this case 7950).

Click the Transactions button which will list all the un-reconciled transactions of the corresponding Bank. In the below screen, there are three highlighted fields which need to be understood to solve the Reconciliation problems.

Opening Balance – It always shows you the previous statement’s ending balance. As this is the first Reconciliation entered in the system, the opening balance shows “0”.
Ending Balance – The ending balance that is entered by the user in the current statement .
Un reconciled – The Amount of Transaction that can be included. In the other way, the sum of the transactions that are being included in the current statement should match this value.
Note: If the “Un reconciled” field shows the value “0” then only the button “Reconcile Account” will be enabled and allows you to complete the reconciliation.
In our Bank trans and the Statement that is sent by the bank, we have 3 common transactions i.e., 10000,-1500,-500. The charges that are levied by bank -50 is not appearing in bank Trans currently as we will get to know the charges only after we get the statement. So, we need to include a transaction of -50 which is not appearing in Bank Trans.
Few Transactions like Interest, Check Fees, other Fees Transactions can be directly entered during the reconciliation. Clicking the new button allows you to do that.

In the above image, highlighted in yellow is the Transaction that is newly entered by seeing the Bank statement and the offset account also can be specified which can be seen the yellow highlighted box. Highlighted in red is the total transactions that are included in the current statement which sums up to USD  7950.
Now, you can observe the Un reconciled field shows “0” and the “Reconcile Account” button enabled.
Clicking the “Reconcile Account” will reconcile the transactions that are included in the statement.
From Bank Accounts form>Click the Transactions button to see the transaction those are reconciled. The transactions that are reconciled in the statement have the checkbox “Reconciled” marked. Also, the tab “Bank Reconciliation” shows the corresponding “Bank statement” and “Statement date” . Now the Bank Reconciliation is done.
Comparing the closing balance of the Bank and the balance of the control account:
Bank Closing balance on the statement date:
To see the closing balance, click Print> bank reconciliation button from “bank Statement” form.
The closing balance that shows in the report is the sum of the Reconciled and Un reconciled  transactions till the Statement date.
Ledger Balance till the particular statement date:
From Main Accounts form, Click parameters button, remove the fiscal year and specify the “To date” as the Bank statement date that you are comparing.
Both the “Ledger Balance and Bank closing balance” should read the same value.

Until next time Cheers!

Sunday, January 12, 2014

Fixing an ERP Implementation




It's not news that not all ERP implementations don't go smoothly. Sometimes you can catch the problems while it is still in the implementation phase. Sometimes the problems don't become obvious until after the system goes live.

If that's the case you've got a serious problem. Given all the time and money invested in the system, you need to do something to salvage it, if possible. Fortunately there are a number of fixes you can apply which can help make a failed ERP system functional.

Understand, you can't always fix everything. If the implementation went off the rails early enough the mess may be unfixable. However if it went that far wrong in the beginning it's more likely you realized something was wrong early in the process.

More likely, things just aren't working right in the failed implementation. Generally this is, if not fixable, at least patchable to get the system to more-or-less work.

The first step is to go through and identify what isn't working on a department by department and function by function basis. Make a complete list of what is working poorly or not working at all. Identify your pain points in the system as it is now.

You'll probably want input from all the affected departments on this to make the list as complete as you possibly can. Also make it specific and determine what is an acceptable level of performance for the fix. For example if one department is having trouble getting screens to display in a timely fashion, it's not enough to note “speed up screens.” You need to quantify that. How fast do you need the screens to be? (Or to put it another way, what's the slowest you can put up with?

The next step is triage. It is seldom a problem will have only one fix. Examine the possible fixes.

Now, estimate the time and the cost for the classes of fixes. Some of your proposed solutions will take too long or cost too much, no matter how elegant they are. These are the ones that you will apply the quick-and-dirty fixes to. There will be others where you have the time and effort to do the job right. Finally there will be a class of problems you can patch with the quick-and-dirty fixes, but you will have to go back quickly and implement the costlier solution.

Now look at the major pain points. Not all these problems are going to be causing the same amount of difficulty. Prioritize according to which ones are hurting the business the most.

Next, go looking for low-hanging fruit. These are problems which are causing the most disruption but which are easiest to fix. Prioritize your list so these obvious and easy to fix problems are at the top.

Don't be afraid to change the business processes to get immediate fixes. Likewise, consider the possibility of new training for users to help solve the problem. The result of all this probably won't be pretty, and you may have to re-do a lot of it once you get the project stabilized.

The reason for doing this is to produce some results fast. Note that the low hanging fruit won't necessarily be the worst problems, merely the ones that will show fast results. This is mainly psychological since the organization is going to need some quick, obvious fixes to build confidence in what you're doing.

After you get some quick wins in place you can start working on the harder, more time-consuming parts of the problem.

What comes out of this won't be as efficient or as streamlined as the original design, but it should be functional. It should be good enough to keep you going until you can go back and spend the time and resources to do everything right.