Understanding the "Posting Accounts from Customer or Item" option in SOP

I have been a Microsoft Dynamics GP consultant for more than a decade now and have always found that a big point of contention (and confusion) during the implementation of Sales Order Processing in any environment has always been selecting whether posting accounts will default from the customer or from the item for the effects of creating an accounting distribution for transactions entered and processed.

From a business perspective...

Typically, organizations use one of these two criteria -- there may be many more -- for reporting profitability: by customer or by product, these two terms used in the broader sense.


Posting Accounts From can be found the Sales Order Processing Setup
window by going to MSDGP > Tools > Setup > Sales > Sales Order Processing


Accounting wise, Customer may refer to a segment in the chart of accounts that represent geographical market location (for example, sales territories, regions; or domestic customers vs international customers), or specific customer activity (for example, retail customers, wholesale customers, not-for-profits, etc). The end goal with this type of revenue and COGS segregation is to report profitability in the different markets where the organization does business. This will in turn allow the organization's executives to implement certain market strategies that are geared towards improving its bottom line in these markets, or in extreme cases, determine whether having a presence in a specific market makes business sense. It's also true that organizations that choose this revenue and COGS breakdown typically carry a small amount of product lines, with product costs and prices that do not vary that often.

Accounting wise, Item, may refer to a segment in the chart of account that represent different product lines (for example, analog, digital, embedded processing; or frozen, perishables, dry goods, meats, etc.), or a specific type of fabrication (for example, pinbrazing, vacuum brazing, induction brazing, etc). The end goal with this type of revenue and COGS segregation is to report profitability by the different products carried by the company. This will in turn allow the organization's executives to implement certain business strategies geared towards minimizing production costs, or find better suppliers of raw material or finished goods, or in extreme cases, determine whether having a certain product line makes business sense. It's also true that organizations that choose this revenue and COGS breakdown typically carry a wide array of products, where, contrary to the customer scenario, costs and prices may vary often due to market conditions.

Making the decision as to what option is best for the organization should always take into account the financial reporting structure for revenue and cost of sales.

From a technical perspective...

From a technical standpoint, Microsoft Dynamics GP's chart of account is static, meaning, the chart of account is configured and stored ("hardcoded") as a pre-requisite to any transaction activity in the system. This in turn imposes certain limitations in the way the system selects accounts at transaction time, but the most notorious limitation is the inability to match chart of account segments based on rules as opposed to selecting defaults. These limitations have given way to third party solutions that implement a rules based system to determine the account that must be used, for example eOne Integrated Business Solutions' Flexicoder. Flexicoder allows organizations with complex revenue and COGS reporting requirements to build rules for GL accounts used in Sales Order Processing transactions.

I hope you've found this article useful and that you understand how each posting account configuration option is related to an organization's financial reporting requirements.

Until next post!

MG.-
Mariano Gomez, MVP
Maximum Global Business, LLC
http://www.maximumglobalbusiness.com/

Comments

Popular posts from this blog

Power Apps - Application Monitoring with Azure Application Insights

DBMS: 12 Microsoft Dynamics GP: 0 error when updating to Microsoft Dynamics GP 2013 R2

eConnect Integration Service for Microsoft Dynamics GP 2010