Automate Unit Account Values Based on Sales Quantities

It is a typical KPI request to be able to report on unit account values.  Let's go ahead and say that we're looking at a profit and loss report, by product and the business wants to see units sold that are included in that margin.

In a perfect world (and using some tools that are not named Management Reporter), if you're capturing the Product A quantity in the Sales Order Processing (SOP) module in GP, you'd be able to reference the sum of the sales instead of using a unit account.  However... We don't live in a perfect world whilst using Management Reporter thus Unit Accounts are required.

So what we'd see is in GP, we'd setup a unit account for something like "Units Sold - Product A"

In Management Reporter, we'd then have a row definition that looked something like...

Sales Product A

- Expenses Product A

= Margin

/ Units Sold - Product A

= Margin/Unit

In a typical fashion, in order for this report to be up to date, the accounting team would need to make a routine journal entry to the unit account within GP.  This process leaves way for manual errors, timing issues & the potential for management to lose confidence in their reports.

Using the method below, we complete streamline this process by automating the unit account journal entry within GP.

Part 1: Associate a unit account with an inventory item in GP.

Note: For example deliverable, one item may be used at multiple locations (segment 1 of COA).  Therefore, we just assign the Natural account to the item & then let the integration define the remaining COA segments)

Approach: We accomplish this using

eOne Solution's Extender product

Part 2: Setup integration that captures posted activity in GP & creates journal entry in GP.

Note: For example deliverable, we're pulling the prior day's activity & creating a journal entry first thing in the morning.

Note: Integration script defines COA segments based on the SITE of the sale on SOP invoice & then the natural account that we associated to the item.

Approach:  We accomplish this using

eOne Solution's SmartConnect product

Map/Integration Setup

ODBC Connection to Company Database - Selecting Prior Day Sales

Part 3: Enable map/integration schedule.  This is an out of the box functionality of SmartConnect.

Part 4: Create reconciling reports using SmartList/SmartView.  These reports can be used at month-end to reconcile financials.

Note: This report is best suited to be built using a Sales Line Item report, filter on the posting date & ensures that returns are shown as negatives

Part 5: Notify accounting team that all they need to do moving forward is post their batches & reconcile once @ month-end!

Integrated transactions in GP would look similar to...

Note: All prior day activity are rolled into 1 line.  Option to separate for each sales transaction would be available if desired.

A few other notes to consider in this process...

- Returns must be accounted for

- When deploying, it is recommended to have the accounting team reconcile more frequent.  As they gather an understanding of process and ensure that numbers are tying out, reconcile less frequent.

- Failed integrations should auto-notify an integration PowerUser.  PowerUser could re-run integration if/when needed

This solution is built in a manner that's easy to implement & maintain and quickly accomplishes the goals of time savings, accurate data & providing a more robust GP system.

Thinking about implementing for your business and looking for additional details?  Already implemented and have feedback?  Let us know in the comments below!

Automatically Running the Receivables Aging Routine via SQL - Dynamics GP

The manual aging routine can be a controversial topic when dealing with Dynamics GP.  For some businesses, seeing aged values at a certain period in time (say end of week, end of month, end of year), is all that's needed for receivables management.  For other businesses, there may be a demand to have more up to date receivable balances thus requiring the aging routine to be run on a more frequent basis. 

With a system like Microsoft Dynamics GP where the customer base is so diverse, having this sort of flexibility is key and makes sense from a development perspective.  However... it does create a rather tedious process of having to run the aging process each time the receivables team deems they'd like to see up to date summary balances by period.

Until Microsoft releases the ability to auto-age on a pre-determined schedule (fingers crossed for GP 2016!), the following script can be used to run the aging process directly through SQL.  The beauty of having a script is that this routine can be scheduled to run on a nightly basis thus never having to manually run again!

Please note that this stored procedure is designed to run in

GP2015R2

.  Table/Stored procedures can change between versions thus requiring the script to be updated.  If you're looking for another version of the script, please contact us or let us know in the comments below.

/*
Automatic Running of Aging Routine
--Includes Aging of Finance Charges
--Deployed Date yyMMdd
--Runs every x hours, days, months, etc
*/

DECLARE @O_iErrorState int, @I_dAgingDate datetime

select @I_dAgingDate = convert (varchar(10),GetDate(),102)

EXEC dbo.rmAgeCustomer 0,'','þþþþþþþþþþþþþþþ',@I_dAgingDate,127,1,0,'',@O_iErrorState OUT

/*
Automatic Running of Aging Routine
--Excludes Aging of Finance Charges
--Deployed Date yyMMdd
--Runs every x hours, days, months, etc
*/

DECLARE @O_iErrorState int,@I_dAgingDate datetime

select @I_dAgingDate = convert(varchar(10),GetDate(),102)

EXEC dbo.rmAgeCustomer 0,'','þþþþþþþþþþþþþþþ',@I_dAgingDate,127,0,0,'', @O_iErrorState

OUT

After running the script, you can open the aging window in GP to view your last run and also view the customer summary window to see the "Aged as of date".

Quick, efficient, and manageable solutions that make everyone's live easier are our favorite.  Running the auto-aging routine via SQL when wanting to see up to date balances is a no-brainer.  Just be sure that this routine is documented so that it doesn't get forgotten in future upgrades or server changes.

Check back soon for information on more simple solutions that we'll be discussing!