• Home
  • About
  • Contact
  • German

Dynamics 365FO/AX Finance & Controlling

Dynamics 365FO/AX Finance & Controlling

Tag Archives: Vendor payments

Default descriptions – Accounts Payable

23 Sunday Jun 2019

Posted by Ludwig Reinhard in Accounts Payable, Bank Management

≈ 28 Comments

Tags

Analyze payments, Cash Flow, Default descriptions, Vendor payments

In this webcast I will demonstrate how one can inherit and track invoice information from the initial recording of the invoice until the settlement and payment of the invoice on the bank account. Realizing this inheritence and tracking does not require sophisticated Artificial Intelligence (AI) or Business Intelligence (BI) tools but rather the setup of default descriptions only. Have a look at the following video to see how this secret ‘super weapon’ works.

 

 

Some notes on vendor payment advices in MSDyn365FO

05 Saturday Jan 2019

Posted by Ludwig Reinhard in Accounts Payable

≈ 30 Comments

Tags

Email, PDF, Vendor payment advice, Vendor payments

In this webcast, I will demonstrate how one can modify the standard payment advice document and include company specific logos and modifications. In addition, the creation and Email transmission of payment advices as PDF documents will be illustrated.

 

 

 

Storage and transfer of electronic documents by Email

14 Wednesday Mar 2018

Posted by Ludwig Reinhard in Accounts Payable

≈ 2 Comments

Tags

Covering letter, Email, Vendor payments

This post illustrates how electronic documents such as payment covering letters can automatically be send to external parties by email.

The standard D365FO functionalities do not only allow this transfer but also provide tools that automatically store those documents.

You can thus resend those documents if your vendor requests – something that was not possible prior Dynamics AX versions. Just take a look yourself

Summarize vendor payments to one line for bank reconciliation

04 Sunday Sep 2016

Posted by Ludwig Reinhard in Accounts Payable

≈ 2 Comments

Tags

summarize bank transactions, Vendor payments, voucher

Recently, I came across a requirement where payments were made from a specific bank account. As only one single bank account was used for making the payments, the expectation was that Dynamics AX creates only one single posting on the bank account. Dynamics AX did, however, create numerous bank postings – one for each journal line – as the invoices paid were recorded with different financial dimension combinations. This fact made the bank reconciliation process more difficult because the bank deduced all vendor payments made in one single amount, which had to be matched with the numerous transactions recorded on the Dynamics AX bank account.

 

Example
The next screenshots exemplify how the payment proposal was created and the vouchers and bank transactions resulting from posting the payment journal.

Example – creation payment proposal
EN_133_5

Example – voucher created for the first journal line
EN_133_10

Example – bank transactions posted
EN_133_15

 

A) Change journal setup
In order to get the transactions posted on the bank account summarized, a new vendor payment journal was setup with the following (modified) settings:
EN_133_20
Note: Previously the parameter ‘new voucher’ was set to ‘in connection with balance’ and the ‘detail’ level was previously set to ‘details’.

The result of this first change in the setup was that Dynamics AX created one single voucher for all lines included in the vendor payment journal. However, there were still a number of postings created on the company’s bank account, as the next screen-print illustrates. EN_133_25

 

B) Change bank account setup
The underlying reason why Dynamics AX did not summarize the transactions made on the bank account were the different financial dimensions used at the invoice level that got inherited to the bank account. This can be identified from the previous screen-print, which shows that the bank account transactions were posted with the financial dimension ‘cost center’ no. 022, 023 and 024.

In order to avoid this problem, default financial dimension values were setup at the bank account level. For details, please see the following screen-print.
EN_133_30
With this setup in place, the expectation was that only one single posting on the bank account is created when posting the vendor payment journal. However, the setup changes made had no influence on the outcome, as the next screenshot proves.
EN_133_35
Once again the financial dimension inheritance from the vendor invoice level that was overwriting the default financial dimension setup at the bank account level was the underlying reason that prevented a summary of the bank postings.

 

C) Change main account setup
To get the posting summary issue resolved, the main account associated to the bank account was finally setup with fixed financial dimension values, as illustrated next.
EN_133_40
After creating another vendor payment journal, the following summarized voucher resulted, which shows only one single transaction on the bank account used.
EN_133_45

 

D) Modification 1 – different payment dates
To test  the stability and reliability of the setup made, another vendor payment journal was created. This time, different payment dates were used for the lines included in the journal.

The outcome of this modified payment run was that Dynamics AX created several summarized bank postings – one for each day. The next screen-print shows the journal lines and the resulting vouchers.
EN_133_50
Note: The major problem with the vouchers generated in the example is that Dynamics AX uses the same voucher number for postings made on different dates. This outcome is likely to result in problems with the company’s auditors, as all accounting standards the author is familiar with, do not allow such kind of postings.

 

E) Modification 2 – different methods of payments
The next modification made to test the stability of the setup was posting a payment journal with different methods of payments. The result of this second test run was that Dynamics AX still summarized all payments made in one single bank posting. For details, please see the next screen-print.
EN_133_55

 

Summary
Within this post the possible summary of payments made into one single bank posting was illustrated. Please note that what has been shown above does also apply to bridge-payment scenarios where all vendor payments are initially made against a bridging ledger account that is in a second step posted against a bank / cash account.

An important prerequisite of the posting summary illustrated is that the payment account used in the vendor payment journal is setup with fixed financial dimension combinations. Otherwise, the financial dimensions used at the invoice level get inherited to the bank / cash account and result in a large number of bank postings.

In addition, it has been shown that the summary does only work as intended, if one single payment date is used in the payment journal. If this cannot be ensured, Dynamics AX will create vouchers that might be questioned by tax and corporate auditors.

Duplicate vendor invoices

08 Wednesday Jun 2016

Posted by Ludwig Reinhard in Accounts Payable

≈ 2 Comments

Tags

Avoid double payments, Vendor invoice recording, Vendor payments

A general problem when recording and paying vendor invoices is the question how to ensure that invoices are not entered and paid more than once. What sounds like common sense can involve a lot of practical problems especially when it comes to recording and paying expense related vendor invoices that are not linked and tracked through purchase orders.

Imagine the following scenario where an employee orders some advertising material (brochures) for the next trade fair. As the total order value is quite small and given that the costs for the brochures are going to be expensed directly, the advertising material is ordered straightaway via Email without making use of the purchase requisition / purchase order process.

If the vendor sends a copy of the invoice together with the shipped advertising material and the original invoice via Email, an invoice – and copies thereof – arrives several times in a company.

For the sake of this demonstration let’s further assume that the invoice copy is forwarded from the warehouse agent to the employee who ordered the goods. After checking and approving the invoice it is then forwarded to the Accounts Payable department where it is recorded by an AP clerk for the first time in the ERP system with invoice no. “INV1234”.

Let’s continue the scenario by assuming that the original invoice is sent to the Accounts Payable department where another AP clerk forwards the invoice to the marketing manager for approval. If the marketing manager does not coordinate with his employee who placed the order, the invoice might get approved and recorded a second time in the system e.g. with invoice no. “INV 1234”. Please note that this time the invoice is recorded with a blank before the number and as a result, the invoice is not identified as a duplicate invoice by the ERP system, as the invoice numbers “INV1234” and “INV 1234” differ from a technical perspective.

At this point three questions arise:

  1. How to identify that an invoice has been recorded more than once in the system?
  2. How to avoid paying the vendor twice? and
  3. How to avoid double entries of invoices altogether?

Within the following subsections I will try answering those questions by referring to Dynamics AX standard features.

 

Q1: How to identify that an invoice has been recorded more than once in the system?
In order to answer the first question, I will slightly modify the scenario portrayed in the beginning of this post. To understand and follow up the example, it has to be noted that the AP parameter “reject duplicate” invoices is activated. Please see the next screen-print.
EN_125_0001
Next, two invoices are recorded in a vendor invoice journal. The first invoice is entered with invoice number “INV1234” and the second one with invoice number “INV 1234”. That is, the second invoice is recorded with a blank between the term “INV” and the invoice number. Because of that blank, Dynamics AX treats both invoices as distinct records.
EN_125_0025
Referring back to our scenario introduced above – and different from the illustration in the previous screen-print – the first and the second invoice would have been entered by different AP clerks in different vendor invoice journals. Because of a (“human”) typing error, Dynamics AX cannot identify that the same invoice has been entered twice.

Now let’s extend the scenario by recording another two invoices with invoice numbers “INV.1234” and “INV1234.” in the vendor invoice workbench. That is the invoices are entered with a dot in between respectively behind the invoice number. Please see the next screen-print.
EN_125_0030
Due to the blank and dot characters used, the invoice was finally recorded four times in Dynamics AX. This can be identified from the vendor invoice journal form illustrated next. EN_125_0035

After entering those four invoices we will now try identifying the duplicate invoices by making use of the audit policy feature available in the audit workbench module. (In AX2012 the same functionality can be found in the compliance and internal controls module).

The first thing that needs to be setup in this module is a policy rule type that makes use of a predefined query (“vendor invoice”) that is incorporated into standard Dynamics AX. The query type used is “duplicate” as we want to search for invoices that have been entered more than once. (Additional information on the available query types can be found on the following TechNet site).
EN_125_0005
Next, an audit policy needs to be setup and linked to an organization. Please see the next screen-print for an example.
EN_125_0010
The last and most important setup required is the specification of an audit policy rule that identifies the duplicate invoices. Example:
EN_125_0015
The criteria that the audit policy rule uses to identify (potentially) duplicate invoices are entered in the “group by” filter tab. In my example, I specified that invoices with the same amount and date for the same invoice account are potentially duplicate invoices.
EN_125_0020
Please note that the invoice number cannot be used as a criteria, as all the invoice numbers that we entered differ.

Once the audit policy rule is established, a batch job needs to be setup which analyzes all vendor invoices for potentially duplicate records based on the criteria that we specified before.
EN_125_0050
If the invoice batch search process finds duplicate records, it creates a case where it lists the potentially duplicate invoices as illustrated in the next screen-print.

Note: A prerequisite not explicitly mentioned/illustrated here is the setup of an audit type case category in the organization administration module. Details for this setup can be found on the following TechNet site.
EN_125_0055
If you take a close look at the duplicate vendor invoices identified above, you will notice that Dynamics AX only listed the invoice numbers with the dot characters in the audit case window. On the other hand, the invoices that were entered in the vendor invoice journal are not picked up and identified as duplicates.

The underlying reason for this standard behavior is the Dynamics AX policy framework. That is, only those invoices that do – among others – have a source document header and source document line associated are picked up by the audit policy check. As the invoices recorded through vendor invoice journals do not have this association they are not taken into consideration by the audit policy rule.
EN_125_0060

This standard behavior of the audit policy rules does have three major implications:

  • If you want to make use of the audit policy rule functionality, vendor invoices cannot be recorded through vendor invoice journals.
  • Alternatively, a comprehensive system modification needs to be implemented, and
  • Given that users are still allowed entering invoices through vendor invoice journals, manual checks for duplicate vendor invoices are required to avoid double payments.

From the authors perspective the first implication that requires entering all vendor invoices through the vendor invoice workbench seems to be superior as it provides one single point of entry for vendor invoices irrespective of whether those invoices are linked to a purchase order or not.

What is more, recording expense related invoices by referring to descriptive categories rather than a multi-digit ledger accounts reduces the risk of typing/posting error especially if temporary employees or trainees are recording vendor invoices in the system. Example:
EN_125_0070
Please note that users still have the chance to overwrite the ledger account that is linked to the category if necessary, as illustrated in the previous screen-print.

Even if users are familiar and used to entering vendor invoices through the Dynamics AX vendor invoice journals, a process change towards entering all invoices through the vendor invoice workbench might be beneficial. That is not only because of the audit policy functionality mentioned before but also because of the standard Excel-import and workflow processes that can be associated with the invoice workbench resulting in an overall streamlined and simplified invoice recording process.

 

Q2: How to avoid paying the vendor invoice twice?
Based on what has been said before, you can setup and process an audit policy rule for duplicate vendor invoices before you start making vendor payments to minimize the risk of making double payments. As mentioned previously, this requires that all invoices are entered through the vendor invoice workbench. Otherwise your only option is executing manual checks for potentially duplicate invoices that might require a lot of time and resources.

 

Q3: How to avoid double entries of invoices altogether?
The audit policy process introduced in this post helps you identifying whether an invoice has been entered more than once. That is, the feature is able to identify with hindsight that something went wrong that needs to be cured.

As prevention is usually better than cure, the question arises how one can prevent similar scenarios as the one described in the introduction of this post?

From the author’s perspective the best and safest way for avoiding duplicate vendor invoice records is a complete and consistent use of the Dynamics AX purchase order process for each and every purchase that is made in your company. This requires that also expense related and often small value purchases are processed through purchase orders. Especially for small- and medium-sized companies this might sound like taking a sledgehammer to crack a nut. However, I made the experience that especially small- and medium-sized companies are the ones that do not have the most stringent organizational business processes in place and as a result are the most likely ones running into the risk of entering and paying invoices double.

 

I hope you enjoyed reading this post and would be happy if you could share your experience with the AX community on how to prevent duplicate vendor invoices & payments in Standard Dynamics AX. Thank’s and till next time.

Invoice groups & Invoice payment groups

01 Sunday Nov 2015

Posted by Ludwig Reinhard in Accounts Payable

≈ Comments Off on Invoice groups & Invoice payment groups

Tags

Dynamics AX 2012 R3, Vendor invoice recording, Vendor payments

Within this blog post I will describe the newly released Accounts Payable invoice group and invoice payment group functionalities.

Invoice Groups
Let’s start by having a look at the invoice group feature. The new invoice group feature can be made available by activating the following Accounts Payable parameter:
EN_17-RG-1After this parameter is activated, users can decide whether the default invoice group code is based on (a) user name, (b) date or (c) “custom”.

A result of this setup is that a new “invoice group” field can be identified in the vendor invoice form. This newly available field is initialized with the default invoice group code that has been setup; in my case with my user ID “$1D58”.EN_17-RG-3
After posting the vendor invoice, the invoice group entered can be identified in the invoice journal form.
EN_17-RG-4Based on this additional information various analyzes can be performed such as e.g. the number of invoices entered per day or the number of invoices entered per employee, etc. The outcome of those investigations can thus be used for the setup of an activity based cost management.

Irrespective of those advantages, a couple of disadvantages remain.

  • The first disadvantage is that the invoice group field is currently not available in the various Accounts Payable invoice journals such as e.g. the invoice journal, the invoice approval journal, etc.
  • A second disadvantage is that the default invoice group values can be changed to any other combination consisting of numbers and characters. As an example, the user ID “XYZ” that is shown in the previous screenshot does not represent a valid user ID in my demo company.
  • A final disadvantage is that invoice groups cannot be used for summary updates of receipt lists, packing slips and vendor invoices.

 

Invoice payment groups
The second newly created “invoice payment group” feature is a Dynamics AX public sector functionality that becomes available with the activation of the corresponding license code in the system administration module. It can be made available by activating the following Account Payable parameter (please see the next screenshot). 
EN_17-RZG-1As for invoice groups, the activation of the invoice payment group parameter makes a new field available in the vendor invoice form.
EN_17-RZG-2
When a vendor payment proposal is created later on, the invoice payment group code can be used for filtering on invoices with the same payment group code. As an example, a filter for urgently to pay invoices can be setup.
EN_17-RZG-4
If – for example due to a payment date filter setting – one or more invoices that belong to the same invoice payment group are excluded from the payment proposal, a warning message with the following text pops up:
EN_17-RZG-5
From the warning message illustrated in the previous screenshot you can identify that the invoice payment group feature helps users verifying whether all invoices that belong to the same invoice payment group – e.g. those that need to be paid urgently – get paid.

Despite this advantage, the currently available invoice payment group functionality has also some disadvantages: First, invoice payment groups are limited to a single vendor, which prevents an immediate use of this feature in practice. Second, as mentioned before, the vendor payment group functionality is a Public sector feature that requires some code adjustment to get rid of some unnecessary info/error Messages in private company system environments.

In summary, the use of invoice groups and invoice payment groups offer some new and interesting possibilities for finance & controlling users. Yet, because of the several issues mentioned before, both features cannot be applied directly in a live environment without making some system modifications.

GL foreign currency revaluation types

26 Sunday Apr 2015

Posted by Ludwig Reinhard in General Ledger

≈ Comments Off on GL foreign currency revaluation types

Tags

Dynamics AX 2012, Foreign currency revaluation, Vendor payments

If you record foreign currency transactions you might experience a situation in which Dynamics AX records foreign currency gains/losses on the wrong ledger account. This blog post illustrates the circumstances under which you might run into this situation and provides you a possibility how to fix this issue.

Scenario
For this example, the following (fictional) currency exchange rates between the EUR and USD are used. (Please note that the local company currency is EUR). EN_0The first transaction recorded in Dynamics AX on 1 January 2015 is a vendor invoice for 1000 USD. At the time the vendor invoice is recorded the EUR/USD exchange rate stands at 80 EUR/100 USD, resulting in an amount equivalent to 800 EUR. EN_1As the invoice is not settled until the end of January 2015, a foreign currency revaluation is run in the Accounts Payable module. This foreign currency revaluation process results in an unrealized exchange rate gain of 50 EUR (1000 USD * [80/100 EUR/USD – 75/100 EUR/USD]), which is recorded on the ledger account for unrealized exchange rate profits. The next screenshot shows the corresponding voucher. EN_4
On 5 February 2015 the vendor invoice is paid by using a wire transfer. This transfer is – as usual – recorded in a vendor payment journal in the Accounts Payable module. Because the USD appreciated to 87 EUR/100 USD at the time the payment is made, an exchange rate loss of 70 EUR is realized. This loss is recorded on the ledger account for realized exchange rate losses. At the same time, Dynamics AX cancels the previously recorded unrealized exchange rate gain of 50 EUR. The next screens show the payment made and the corresponding vouchers created. EN_6 EN_7Please note that the payment is made via a transfer account – in my example account “109053 Transfer Bank Charlie”. This transfer account is cleared on 8 February when the bank transaction is posted (see the next screenshot). EN_8As the EUR/USD exchange rate changed from 87 EUR/USD (at the time the payment was made) to 83 EUR/USD (at the time the bank transaction was posted), a balance of 40 EUR remains on the payment transfer account. This balance can be identified in the following screenshot.
EN_9To clear this balance on the transfer account the foreign currency revaluation process is run in the General Ledger module for the respective account. The outcome of this revaluation process is a balance of 0 EUR on the transfer account.EN_10EN_11If one takes a close look at the foreign currency posting that is made to clear the balance on the transfer account, one can identify that the balance was posted on the ledger account that is used for recording unrealized exchange rate losses (see the next screenshot). EN_12Posting the remaining balance of 40 EUR against the unrealized exchange rate loss account is wrong because the transaction represents a realized loss. The next figure summarizes all transactions that have been recorded for this example and highlights the remaining realized and unrealized exchange rate gains and losses recorded in Dynamics AX.EN_12aEven though the total exchange loss of 30 EUR is correct from an overall perspective, the elements that make up this total amount are wrong. That is, if your company reports realized and unrealized currency exchange gains/losses separately, your profit and loss statement shows incorrect figures.

Possible solution
In this section I will show a possible solution to the problem illustrated. This solution requires some minor system modifications that are described next.

Step 1
The first modification required is extending the Base Enum values “FinancialGain” and “FinancialLoss” of the “CurrencyGainLossAccountType” Base Enum. In my example I simply added the country codes for Germany (DE) and the USA (US). Please see the next screenshot for details.
EN_13

Step 2
The next (optional) step is to change the following two labels: @GLS109008 and @GLS109005. EN_14

Step 3
Step three requires extending the LedgerExchAdj class by the same country codes that have been used in step 1. Please note that those codes are entered slightly different (#isoDE, #isoUS).
EN_15

Step 4
A similar adjustment is required in the ledger form as illustrated in the following screenshot.
EN_16

The result of those modifications is that two new exchange rate transaction types are available in the ledger form (see the next screenshot).
EN_17

With this setup I repeat the previously recorded transactions on another (“fresh”) bank account and its corresponding transfer account. All steps and vouchers are identical except the voucher that is generated when running the foreign currency revaluation in GL for the transfer account.

As you can identify from the next screenshot, after having done the previously described system modifications, Dynamics AX does now record the exchange rate adjustment of 40 EUR on the newly setup account that represents a realized exchange rate adjustment. This change allows you reporting currency exchange rate differences correctly in your profit and loss statement.
EN_21Please note that the foreign currency revaluation process in the Bank module is also affected by the changes described here. For details, please see my previous post.

AP Payment Distribution Functionality

14 Saturday Mar 2015

Posted by Ludwig Reinhard in Accounts Payable

≈ Comments Off on AP Payment Distribution Functionality

Tags

Dynamics AX 2012, Payment distribution, Vendor payments

The following screenshots will provide you with a brief overview of the Accounts Payable (AP) payment distribution functionality that is available in vendor payment journals. For the purpose of this illustration the following three bank accounts are setup.EN_3-1After setting up the three bank accounts a General Ledger (GL) journal is used to post the following initial balances:
EN_3-2

Thereafter, three different AP methods of payments are setup – one for each bank account. EN_3-3Based on the assumption that payments will primarily be made from the Deutsche Bank bank account, all vendor records are setup with the default “SEPA (DB)” method of payment.EN_3-4After finalizing all the setup, a number of invoices is posted for the vendors DE-002, DE-003 and DE-004.EN_3-5After posting the different invoices a payment proposal is created in a vendor payment journal.EN_3-6The result of this payment proposal can be identified in the vendor payment proposal form. As one might expect, Dynamics AX suggests paying all invoices from the Deutsche Bank bank account because previously the SEPA (DB) method of payment was setup as the default method of payment for each vendor. This can be identified from the lower part of the following screenshot. EN_3-7If you open the balance control window you can identify that all invoices cannot be paid from the Deutsche Bank bank account because paying all invoices from this bank account would result in a negative balance of 117000 EUR on this account.EN_3-8To avoid this negative balance, the following payment priority is specified in the last column of the payment distribution window. EN_3-9The priority specified defines that vendor payments should primarily be made from the Citibank bank account. If funds on the Citibank account are insufficient, money from the Deutsche Bank bank account shall be used and so on. Leaving the payment distribution window with “OK” results in the following changed vendor payment proposal.EN_3-10As one can identify from this window, 15000 EUR will be paid from the Citibank account to pay an invoice of vendor DE-003. From Deutsche Bank another 17000 EUR (12000 EUR + 5000 EUR) will be paid and the remainder will be paid from the ING DIBA bank account. The following illustrations summarize how Dynamics AX distributes the payment amounts to the different bank accounts.
EN_3-11b
If you confirm the payment proposal by clicking the transfer button, the payment lines will be transferred to the vendor payment journal where you can create your payments and post the journal as usual.EN_3-12

Project Accounting Book – Part 2

Project accounting book

Categories

  • Accounts Payable
  • Accounts Receivable
  • Bank Management
  • Book reviews
  • Budgeting
  • Cost accounting
  • Fixed Assets
  • General Ledger
  • Inventory
  • Management Reporter
  • Miscellaneous
  • Project
  • Uncategorized

Tags

Accruals Advanced bank reconciliation Allocations Approval Bank reconciliation Controlling Cost accounting module Cost center accounting Cost of Sales Method customer Dynamics AX Dynamics AX 2012 Earned Value Analysis Electronic reporting Email Fixed asset statement General Ledger journal indirect costs intercompany Inventory Inventory reconciliation Inventory valuation Inventory value report invoice invoice recording Management Accounting Management Reporter MS Flow MT940 Nature of Expense Method parallel Posting setup PowerPlatform Prepayments Profit & Loss Statement Project Project controlling Project module Purchase Order search settlement SharePoint standard costs Tax upload valuation Vendor invoice recording Vendor payments WBS workflow

Important Websites

  • Dynamics AX/365FO Links

Legal

  • Disclaimer

Subcribe

  • RSS - Posts
  • RSS - Comments

Enter your email address to follow this blog and receive notifications of new posts by email.

Archives

  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • August 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

Blog at WordPress.com.

Cancel

 
Loading Comments...
Comment
    ×