Articles in this section

Ascent Financial Platform

AscentERP
Follow

Document Purpose:

Detail an object model and functionality model to integrate with other Financial Systems including but not limited to Quickbooks, Quickbooks Online, Intacct, XERO, Accounting Seed, Sage Live, Oracle, SAP, Great Plains,  etc.

 

Preface:

Ascent will continue to focus on the core Inventory Management, Procurement, Manufacturing, Order Management, Rentals, and Inventory Resource Planning.  The Ascent Financial Platform is a package that depends on and complements the main Ascent4SalesForce package.  It is not Ascent’s intent to develop full scale accounting and finance as an offering.  Ascent will continue to rely on external systems for true accounting and finance functions.  Instead this package will serve as an “agnostic” approach to integrating or exporting critical business data to external finance systems.

 

Existing Functionality Highlights:

 

Line of Credit/AR - Related to an account. Based on all Accounts Receivable records.  Open Sales Orders, Sales Invoices, Credit Memos, Cash Entries, Applied Cash Receipts, Applied Credits, Refunds, and Deposits.  (Released)

Cash Entries - that can be recorded stand alone or against Invoices.  (Released)

Deposits - recorded against Sales Orders.  (Released)

Credit Memos - ability to record customer credits against an account - (Released)

Refunds - refund the customer from a credit memo.  (Released)

Vendor Invoices - recorded against Purchase Orders.  (Released)

Vendor Bill Payments - that can be recorded against Vendor Invoices.  (In development)

 

Accounting Financial Platform Object Model:

These are new objects as part of Ascent Financial Platform package

    • Cash Entry and Applied Cash Receipts - Cash Entry of type “Cash Receipt” represents a customer payment in any form.  The act of applying Cash Entries to an outstanding document represents an Applied Cash Receipt record. (Released)

 

  • Credit Memo, Credit Memo Line, Applied Credit - Applying a credit to an outstanding document represents an Applied Credit record. (Released)
  • Refund - Record of Customer Refund (Released)
  • Deposit - Record of Cash for a specific Sales Order to a later automatically apply to invoice balances off of the Sales Order. (Released)
  • Account, Sales Invoice, Sales Order, and Credit Memo Balance Fields - Recording the balance at every type of transaction that could have revenue and line of credit style impacts. (Released)

 

    • Payment Terms - for AR and Discounting based on early pay  (Released)
    • General Ledger Account - Reference Record to represent GL Accounts in Finance System. (Released)

 

  • Journal Entry   (Released)
  • Journal Entry Lines (Released)

 

    • Integration Error Message - Record any accounting error messages in a logical list.  (Could use existing Ascent Transaction Log object) (In Development)

 

  • Transaction Profiles - A data driver record that allows you to create mappings for every type of functionality in Ascent to create Journal Entries from types of transactions.  For instance there could be a Transaction Profile record for sales order pack which will say which GL Accounts get DB and CR depending on data mapping. (Released)

 



Accounting Platform Existing Functionality:

 

The Ascent Financial Platform allows users to maintain Line of Credit, Outstanding Balance, Open A/R, and open Credits against a customer account in Salesforce/Ascent.  The current focus of the Platform is on the Customer Management and Journal Entries. In the future Ascent will support Vendor management and vendor bill payments.  Ascent does not plan on creating a replacement for heavy A/R and A/P operations.  Ascent is a Quote to Fulfilment platform and the purpose of this functionality is to provide a way to log cash in/out at the end of this sales cycle to augment operations that depend on A/R functions to complete fulfilment.  It is also to allow for an stable/standardized object model for integration with external systems where true AR and AP will be accomplished.  

 

Description of AFP (Ascent Financial Platform) Light A/R Accounts Receivable Steps:

 

After installing the Ascent Financial Platform users will get a new object related to the Account, Sales Order, and Sales Invoice and several fields on these objects.  Expose the “Cash Entry” as a related list on at least the SalesForce Account object.  

 

Fields to expose on the Account Object:

Line of Credit : Line of credit for the customer - user entered number

Outstanding Balance : Open Sales Orders or Invoices with balances.

Total Unapplied Credits : Outstanding unapplied credit memos.

Total Unapplied Payments : Outstanding unapplied cash receipts

Customer Balance : (Outstanding Balance - Total Unapplied Credits - Total Unapplied Payments)

Available Credit : Line of Credit - Customer Balance

Resale Certificate Number - for tax purposes

Payment Terms - A record that dictates what the customer’s payment terms

 

Fields:

  • Account Payment Terms
  • Available Credit
  • Customer Balance
  • Line of Credit
  • Outstanding Balance
  • Payables Account
  • Payment Terms
  • Receivables Account
  • Resale Certificate Number
  • Sales Order Balance
  • SLA
  • SLA Expiration Date
  • SLA Serial Number
  • Tax Number
  • Total Unapplied Credits
  • Total Unapplied Payments
  • Use for Refunds

 

Fields/Buttons to Expose on Sales Invoice:

Receive Payment - Allows you to create a cash receipt and apply it at the same time.

Pay - Allows you to apply open cash Entries or credits to this invoice and reverse them.

Void - Allows you to void an open invoice (instead of deleting)

Several balance related fields.  Please use Ascent_FPL namespace to find these.

 

Buttons:

  • Apply Deposit
  • Email Invoice AFP
  • Pay
  • Print Invoice AFP
  • Receive Payment
  • Refresh Invoice
  • Void

Fields:

  • Aging Category
  • Aging Date
  • Balance Due
  • Journal Status
  • Last Payment Date
  • Payment Discount Amount
  • Payment Method
  • Payment Terms
  • Reference 1
  • Reference 2
  • Total Applied Amount
  • Void Date
  • Voided By

 

Fields/Buttons to Expose on Sales Order:

Several balance related fields. Please use Ascent_FPL namespace.

Deposit - Allows you to create deposits against sales orders.

 

Buttons:

  • Deposit
  • Generate Invoice AFP

Fields:

  • Applied Amount
  • Applied Credits
  • Balance Due
  • Do not use for Balance
  • Last Payment Date
  • Payment Discount Amount
  • Payment Terms AFP
  • Shipping Expense Journalized
  • Total Deposited

 

Fields/Buttons to Expose on Credit Memo:

 

Fields:

  • Balance
  • Credit Reference Details
  • Do not use for Balance
  • Journal Status
  • Manual Amount
  • Payment
  • Reference 1
  • Reference 2
  • Refund
  • Total Applied Amount
  • Total Refunded Amount
  • Total Reverse Amount
  • Voided
  • Voided By

Buttons and Links:

  • Applied Credit
  • Create Payment
  • Refund
  • Void

 

Fields/Buttons to Expose on Cash Entry:

Fields:

  • Account
  • Amount
  • Amount Paid
  • Balance
  • Entity
  • Entity Type
  • Expected Receipt Date
  • GL Account
  • Internal Notes
  • Org Exchange Rate
  • Payment Method
  • Payment Purpose
  • Payment Reference ID
  • Receipt Date
  • Reference 1
  • Reference 2
  • Refunded Amount
  • Reporting Profile
  • Status
  • Total Applied Amount

   Buttons or Links:

  • Apply
  • Refund

 

Fields/Buttons to Expose on Journal Entry:

Fields:

  • Lines
  • Account
  • Applied Credit
  • Applied Payment Detail
  • Balanced
  • Count Journal
  • Credit Note
  • Custom Object Id
  • Description
  • Entity
  • External ID
  • Grouping Reference
  • Journal Date
  • Journal Entry
  • Movement Journal
  • Override Class ID
  • Payment
  • Production Work Order
  • Purchase Order
  • Reference 1
  • Reference 2
  • Refund
  • Return
  • RMA
  • Sales Invoice
  • Sales Order
  • Shipment Tracker
  • Status
  • Total Credits
  • Total Debits
  • Type
  • Vendor Invoice
  • Work Order

Buttons or Links

  • Reverse Journal





Fields/Buttons to Expose on Journal Entry Line:

Fields:

  • Custom Field1
  • Custom Field 2
  • Custom Field 3
  • Custom Field 4
  • Custom Field 5
  • Custom Field TP Subtype
  • Custom Field TP Type
  • Debit/Credit
  • Decimal Precision Variance Value
  • Department
  • External ID
  • GL Account
  • Grouping Reference
  • Item
  • Journal Entry
  • Net Effect
  • Org Exchange Rate
  • Originating IDs
  • Packed Sales Order Line
  • Reference1
  • Reference 2
  • Reporting Profile
  • Transaction Date
  • Value
  • Value 2





Typical Accounts Receivable Use Cases:

 

After exposing the appropriate fields you will want to go through a light A/R cycle in AFP.

 

STEPS:

  1. Fill in a value for the line of credit field on the Customer Account.  
  2. Create a sales order with some line items that have values.
  3. Check the Account record.  You should now see Outstanding Balance and Customer balance have been impacted utilizing your line of credit values.  

 

Note:: Balances can go negative.  This is by design.  If you need to prevent the balance fields to go negative then validation rules on sales order or sales order line can be used to reference the Account balance fields to stop operations from creating orders over the customer Line of Credit.

 

  1. Pack the sales order
  2. Generate an invoice.

 

Note: We count open sales orders as well as invoices in the balance fields on the customer account.  As soon as you invoice some or all of a sales order we do not count this value twice.  We only count uninvoiced sales order lines and invoice lines.  This prevents us from double counting a line item on a sales order or invoice.

 

  1. Go back to the Account and go the related list “Cash Entries”.  Click “New” button to create a new cash entry.  Creating a new cash entry you must enter a value, Entry Type = “Cash Receipt” and a type of entry it will be like “Credit Card”, “Check”, “Bank Wire” etc.
  2. Save the Cash Entry.
  3. Now you should see an “Apply” button which allows you to apply the cash receipt you just created against any open invoice.  If you click apply you will see the invoice you just generated in #5
  4. You can now enter a value or quickpay by clicking the “Pay” button on the line items.
  5. Clicking Save will create an Applied Cash Receipt against the Cash Entry, Account, Sales Invoice and Sales Order.  It will also update the balance fields on Sales Order, Sales Invoice, and Account.

 

Note: This is the traditional A/R functionality AFP supports.  There are other types of A/R documented below.

 

“Receive Payment” button on Sales Invoice combines steps 6-10 above into one button on the invoice.

 

“Pay” button on the Sales Invoice combines steps 8-10 above with one exception.  This button is more intelligent than the “Receive Payment” and “Apply” buttons.  It recognizes all open unapplied Cash Entries AND all open unapplied Credit Memos on the customer account.

 

Applying Credits Typical Flow:

 

After completing steps 1-10 above you will also want to create customer credits.  

 

STEPS:

11.) Go to the sales order created above.  The sales order must be packed and optionally an invoice.

12.) Click Create RMA and chose some items from the sales order.

13.) Process the RMA Lines.

14.) Click Credit Memo button on RMA Header.

 

Note: At this point you choose if you want to associate the credit memo and credit memo lines to the Received in RMA Lines at the top you can choose an invoice from the list of invoices on this Sales Order associated to the RMA.  The most common use case is to associate a credit memo to a previously closed out invoice because this will show which revenue transaction it came from, but in some rare cases you may not have an Invoice for an RMA.  In this scenario we have made it possible to optionally tie a Credit Memo explicitly to returned inventory materials.  

15.) Once you have created the credit memo connected to the Invoice, next you will navigate to the Credit Memo page.

16.) On this page you will see the Credit Memo has taken its values, shipping, discounts, etc. directly from the invoice.  This is not possible if you tie to returned lines.

17.) You can now apply the credit to open invoices using the “Apply Credit” button on the credit memo.  You can apply some or all of the credit to any number of open invoices.  

18.) This will result in balance updates on invoices, account, sales orders and this specific credit memo.

Refunds:

 

It may be that the customer wants a bonafide refund.  In this scenario you must first create a credit memo.  Starting from above:

 

19.) On the credit memo page press the Refund button.  This button will bring up a page allowing you to say how much you would like to refund.  

Note: You can apply some of a credit and then do a refund for the remaining amount on the Credit Memo.  Giving a customer a refund closes out the credit memo and therefore updates the balances on the customer account since you are cashing out a Customer Credit it no longer belongs on the customer’s account

 

20.) Choose a type of refund (cash, check, credit card, etc.)

21.) Save - this will create a refund against the customer account.



AFP Journal Entries Functionality:

 

Ascent Financial Platform automatically makes Journal Entries based on a predetermined set of rules for transactions identified as having a financial impact.  Examples are Sales Order Pack. Inventory Adjustment, or Purchase Order Receipt.  To make a Journal Entry we need GL Accounts for the debit(s) and credit(s).  For each transaction, Ascent assumes that an Item Master is used whether it is a Revenue Type (Invoice/Credit Memo), Inventory Type (PO, PWO, SOPack), or other type of transaction.  Based on the transaction type, the rules for selection of which GL Accounts to use for debiting and crediting are always the same.  It starts with the Item and then Item Group and then finally the Transaction Profiles "Credit" and "Debit" accounts.  There are several approaches to how the user can control which GL Accounts the system will choose.

 

Most Granular: Set GL Accounts at the Item Master Level

The Item Master has lookups to these GL Accounts:

COGS GL Account

Inventory GL Account

Expense GL Account

Revenue(Income) GL Account

PWO Material Variance Account

 

Less Granular (Most Common) : Set GL Accounts at the Item Group Level

The item Group has the same 5 lookups:

COGS GL Account

Inventory GL Account

Expense GL Account

Revenue(Income) GL Account

PWO Material Variance Account

 

Least Granular  (All customers must do at least this configuration Step):

Set the GL Accounts at the Transaction Profile Level

Setting the GL Accounts for a specific type of transaction using a Transaction Profile like "sales order pack" gives the ORG something to fall back on when a sales order is packed for an item that does not yet have an item group GL Account or item Master GL Account for COGS and Inventory, for example.  On a sales order pack the system is looking to "credit" an Inventory GL Account.  The system will first look at the item master being packed and asks if the Inventory GL Account has a value in that lookup.  If there is no value in that lookup, then it goes to the Item Group of that item being packed and asks if the Inventory GL Account on the Item Group is filled in.  If no value is filled in there then it goes to the Transaction Profile list and finds the org transaction profile for Sales Order Pack and pulls the credit Account from that record.  If no Transaction Profile is found for "Sales Order Pack" for the org, then no Journal Entry is created.  The Transaction Profile is a fall back.  It is expected that the Item Group GL Accounts or Item Master GL Accounts would be filled in unless the company treats all sales order pack outs the same way for inventory.  The same behavior is on the Debit side of the Journal Entry for Sales Order Pack looking for the COGS GL Account.  First item, then item group, then finally the transaction profile but on the Debit side.   It is perfectly acceptable and a legitimate configuration for a journal entry for sales order pack to pull the COGS GL Account from the Transaction Profile for the debit and then pull the Inventory GL Account from the Item master for the credit side of the Journal Entry.  

 

This illustrates the user's strong level of control with which GL Accounts are chosen for Journals based on how granular they wish to be with Items, Groups, Profiles, and associating them to the Chart (GL) of Accounts.

 

Ascent expects customers will put their items into the most granular Item Groups based on how the Journal Entries should eventually post into the financial system.  Specifically, the items should be organized into Item Groups that share the different GL Accounts for debits or credits.  Later if some item(s) need to be different than what was originally decided with the existing set of item groups, then users make a new group and specify those GL Accounts and put those Item(s) into that group.  If users temporarily want to post a single item a special way then they can simply specify those GL Accounts at the item master level and move on until the organization starts buying/selling more items like that one.  When the organization starts selling more items like said item it is expected a new Item Group would be created so all of these items in the same product line can post the same way.  

 

How to use object model to get GL Accounts when creating Journal Entries

Every Journal Entry will consist of 1 Journal Entry record for the transaction (Sales Invoice, Packed SO, etc.) and at least 2 related Journal Entry Line records (minimum of 1 Debit and 1 Credit).

 

When AFP is configured for a specific client, the Transaction Profile object will be populated with at least 1 record for each Transaction Type that requires a Journal Entry.  The Transaction Profile record has a Type (Sales Invoice, Packed SO, etc.) and a Sub-Type (Items, Sales Tax, etc.).  When processing a specific type of transaction, all of the records with the same Type should be used to determine the Journal Entry Line records that need to be created for that particular Journal Entry.

 

For Exampel count Journal: 

If you adding Inventory, Debit the inventory account from the Item, Item Group or Transaction Profile Type = Count Journal - Add, Sub-Type = Item.

If subtracting inventory, Credit the inventory account from the Item, Item Group or Transaction Profile Type = Count Journal - Subtract, Sub-Type = Item.

 

Certain objects contain lookups to the GL Account object.  When a particular GL Account lookup is populated in one of these objects, that GL Account should be used as an override to the Transaction Profile record.  The objects with specific GL Account lookups are:

  • Account
    • GL – Payables
    • GL – Receivables
  • Tax Code
    • GL – Payables
  • Item
    • GL – COGS
    • GL – Inventory
    • GL – Revenue
  • Item Group
    • GL – COGS
    • GL – Inventory
    • GL – Revenue

 

So, for example, when creating the Journal Entry for a Sales Invoice, if the Customer (Account) on the Invoice has a lookup to GL – Receivables, then that GL Account should be used to create the Debit(s) to Accounts Receivable instead of using the Debit GL Account values found in the Transaction Profile records of Type = Sales Invoice.

 

Similarly, if the Tax Code record referenced by the Sales Invoice has a lookup to GL – Payables, then that GL Account should be used to create the Credit to Sales Tax instead of the one in the Transaction Profile record with Type = Sales Invoice and Sub-Type = Sales Tax.

 

When processing Inventory related line items (Invoiced Line, Packed SO Line, etc.), the Transaction Profile may be overridden at the Item level or Item Group level.  For each Item being processed, first determine if that Item has lookups to GL for COGS, Inventory and/or Revenue.  If so, use those GL Accounts for the Journal Entry.  If not, determine if the Item Group of the Item has lookups to GL for COGS, Inventory and/or Revenue.  If so, then use those GL Accounts.  Otherwise, use the GL Accounts in the Transaction Profile record for the corresponding transaction (ie, Type = Sales Invoice, Sub-Type = Items).  The end result of Journal Entry Lines related to a particular Journal Entry will summarize amounts by GL Account and Debit/Credit. For example, if processing a Packed SO and there are multiple Items that affect GL Account “1000 – A/R” as a “Debit”, then all of those Item amounts will be summarized and only 1 Journal Entry Line record will be created as a “Debit” to GL Account “1000 – A/R” for that particular Journal Entry.

 

Income Accounts:  Customers typically use the Revenue/Income GL Accounts for syncing their item Masters with an accounting system on or off platform because those systems want an Income account so the revenue transactions posting to the GL need those accounts so it knows what to do in revenue/income transaction such as Invoicing. There is functionality in AFP that allows one to create Journal Entries from Sales Invoices, Credit Memos, Cash Entries, and Vendor Invoices however this is not typically leveraged because Ascent Invoices and Cash will not synchronize with that accounting system.  Ascent only sends over Journal Entries.  

 

 

When Journals are created they will be created with a status of “In Progress” and will be marked for external financial system import.  The external system of import will periodically import all of the “In Progress” journals into the financial system and mark all Journals as imported.  This can be done in near real time fashion or as little as once a month for a reporting purposes.  

 

Additionally Ascent has several objects including Sales Invoices, Vendor Invoices, Sales Payments and Bill payments that will all work together to create the concept of AR, AP, and Credit.  These objects will also have statuses that detail if they have been imported into the external financial system of record.  Once imported they will be marked as imported so only new records are imported on the next periodic import.

 

Ideally, the Ascent Financial Platform does relies on the combination of Accounts, Vendors, General Ledger Account Mappings, Journals for Costing, Sales Invoices and Payments for AR, and Vendor Invoices and Bill Payments for AP all importing into an external financial system will create the necessary records in the financials to do the following functions :

 

P&L Reporting

Financial Reporting and Forecasting

Bank Reconciliation

Checks

Close the Books

 

AFP Supported Transactions that will post a Journal Entry:

  • Applied Payment
    • Payment Discount
    • Payment
  • Applied Credit
    • Payment
  • Credit Memo
    • Items
    • Sales Tax
    • Shipping Revenue
  • Customer Payment (from customer, broken down by payment method)
    • Amex
    • Bank Transfer
    • Cash
    • Check
    • Credit Card
    • Discover
    • Electronic Pmt
    • Visa/Master Card
    • Other
  • Customer Refund (to customer, broken down by payment method)
    • Bank Transfer
    • Cash
    • Check
    • Credit Card
    • Other
  • Count Journal
    • Item
  • Count Journal Add
  • Count Journal Sub
  • Inventory Adjustment
    • Item
  • Inventory Adjustment Add
    • Engineering Usage
  • Inventory Adjustment Sub
    • Engineering Usage

 

  • Packed SO
    • Items
    • Shipping Expense
  • Production Work Order

 

    • Items

 

  • Payable Invoice
  • Processed RMA (to customer)
    • Items
  • Processed RMA (to vendor)
    • Items



  • Received PO
    • Items
    • Freight
    • Discounts
    • PPV 1

 

  • Return to Vendor
    • Item
  • Return from Customer
    • Item
  • Sales Invoice
    • Items
    • Sales Tax
    • Shipping Revenue
    • Miscellaneous Charge
  • Shipment Tracker
    • Shipping Revenue
    • Shipping Expense

 

  • Work Order
    • Repair

 

New Custom Objects:

  • GL Account
    • Active (checkbox)
    • Bank (checkbox)
    • External ID Detail (Text40, ext. id, unique)
    • Normal Balance (formula field, returns “Debit” or “Credit”)
    • Reporting Code (Text32, unique?)
    • Type (picklist)
    • Sub-Type (dependent picklist controlled by Type)
  • Transaction Profile
    • Credit GL Account (lookup to GL Account)
    • Debit GL Account (lookup to GL Account)
    • Type (picklist)
    • Sub-Type (dependent picklist controlled by Type)
  • Journal Entry
    • Applied Payment Detail (lookup to Applied Payment Detail)
    • Balanced (formula checkbox)
    • Credit Note (lookup to Credit Note)
    • Date
    • Movement Journal (lookup to Movement Journal)
    • Payment (lookup to Payment)
    • Production Work Order (lookup to PWO)
    • Purchase Order (lookup to PO)
    • Refund (lookup to Refund)
    • RMA (lookup to Case)
    • Sales Invoice (lookup to Sales Invoice)
    • Status (picklist)
    • Total Credits (rollup summary)
    • Total Debits (rollup summary)
    • Type (picklist)
  • Journal Entry Line
    • Amount (number 16,2)
    • Debit/Credit (picklist)
    • GL Account ((lookup to GL Account)
    • Journal Entry (Master-Detail to Journal Entry)
    • Net Effect (formula returns Amount or (Amount * -1))
    • Originating IDs (Long Text Area 32768): This field will store the id’s of all the transaction line items that are summarized.  For example, when summarizing Invoiced Lines by unique GL Account to create a single Journal Entry Line, all of the id’s for those Invoiced Line records will be written to this field.
  • AscentAFP Setting (custom setting):
    • Journal Entry for Applied Payment Detail (checkbox)
    • Journal Entry for Credit Note (checkbox)
    • Journal Entry for Payment from Customer (checkbox)
    • Journal Entry for Refund to Customer (checkbox)
    • Journal Entry for Inventory Adjustment (checkbox)
    • Journal Entry for Packed SO (checkbox)
    • Journal Entry for Production Work Order
    • Journal Entry for Received PO (checkbox)
    • Journal Entry for RMA from Customer (checkbox)
    • Journal Entry for RMA to Vendor (checkbox)
    • Journal Entry for Sales Invoice (checkbox)
    • Journal Entry for Shipment Tracker (checkbox)
    • Journal Entry for Count Journal (checkbox)

 

Custom Fields added to existing objects:

  • add GL – Payables as a lookup from Account to GL Account
  • add GL – Receivables as a lookup from Account to GL Account
  • add GL – Payables as a lookup from Tax Code to GL Account
  • add GL – COGS as a lookup from Item to GL Account
  • add GL – Inventory as a lookup from Item to GL Account
  • add GL – Revenue as a lookup from Item to GL Account
  • add GL – COGS as a lookup from Item Group to GL Account
  • add GL – Inventory as a lookup from Item Group to GL Account
  • add GL – Revenue as a lookup from Item Group to GL Account
  • add Journal Status (picklist) to Credit Note
    • Approved
    • Posted
  • add Journal Status (picklist) to Sales Invoice
    • Approved
    • Posted

 

Business Logic for Journals

 

 

  • Applied Payment Detail:

 

      • If Applied Payment Detail.Payment Discount > 0, get the GL accounts from the Transaction Profile record for Type = Applied Payment and Sub-Type = Payment Discount to create the Journal Entry and Journal Entry Line.

 

  • Credit Note:

 

      • Debits:
        • Summarize Credit Note Line.SubTotal by unique GL Account.
        • If Credit Note.Tax Amount > 0, then use Tax Code.GL – Payables, else get the Debit GL Account from the Transaction Profile record for Type = Credit Note and Sub-Type = Sales Tax.
        • If Credit Note.Shipping Cost > 0, get the Debit GL Account from the Transaction Profile record for Type = Credit Note and Sub-Type = Shipping Revenue
      • Credit (only 1 credit Journal Entry Line needs to be created per Credit Note Transaction):
        • If Credit Note.Customer.GL – Receivables is not null, then use that GL Account, else get the Credit GL Account from the Transaction Profile record for Type = Credit Note and Sub-Type = Items. Use Credit Note.Total Amount for the amount of the Journal entry Line.

 

  • Payment (from a Customer):

 

      • Use the Payment Method on the Payment record to get the Transaction Profile record for Type = Customer Payment and Sub-Type = Payment.Payment Method.

 

  • Refund (to customer):

 

      • Use the Refund Method on the Refund record to get the Transaction Profile record for Type = Customer Refund and Sub-Type = Payment.Refund Method.

 

  • Inventory Adjustment

 

      • Use the GL – Inventory lookup in the Item or Item Group to either Debit (if adding to inventory) or Credit (if subtracting from inventory). Otherwise, get the GL Accounts from Transaction Profile Type = Inventory Adjustment, Sub-Type = Item.

 

  • Packed SO
  • Use the GL – Inventory lookup in the Item or Item Group to Credit inventory.  Otherwise, get Transaction Profile Type = Packed Sales Order, Sub-Type = Item.
  • Production Work Order

 

      • Use the GL – Inventory lookup in the Item or Item Group to either Debit (if adding to inventory) or Credit (if subtracting from inventory). Otherwise, get Transaction Profile Type = Production Work Order, Sub-Type = Item.

 

  • Received PO
  • Use the GL – Inventory lookup in the Item or Item Group to Debit inventory.  Otherwise, get Transaction Profile Type = Received PO, Sub-Type = Item
  • RMA (from Customer)
  • Use the GL – Inventory lookup in the Item or Item Group to Debit inventory.  Otherwise, get Transaction Profile Type = RMA – Customer Return, Sub-Type = Item
  • Use the Customer (account) to get the GL – Receivables to Credit.  Otherwise, get the Credit GL from Transaction Profile Type = RMA – Customer Return, Sub-Type = Item
  • RMA (to Vendor)
  • Use the GL – Inventory lookup in the Item or Item Group to Credit inventory.  Otherwise, get Transaction Profile Type = RMA – Vendor Return, Sub-Type = Item
  • Use the Vendor (account) to get the GL – Payables to Debit.  Otherwise, get the Debit GL from Transaction Profile Type = RMA – Vendor Return, Sub-Type = Item
  • Sales Invoice

 

      • Credits:
        • Summarize Invoiced Line.SubTotal by unique GL Account.
        • If Sales Invoice.TotalTax > 0, then use Tax Code.GL – Payables, else get the Credit GL Account from the Transaction Profile record for Type = Sales Invoice and Sub-Type = Sales Tax.
        • For Shipping Charges, see Shipment Tracker below
      • Debit (only 1 debit Journal Entry Line needs to be created per Sales Invoice Transaction):
        • If Sales Invoice.Customer.GL – Receivables is not null, then use that GL Account, else get the Debit GL Account from the Transaction Profile record for Type = Sales Invoice and Sub-Type = Items. Use Sales Invoice.InvoiceTotal for the amount of the Journal entry Line.

 

  • Shipment Tracker

 

      • If Shipment Tracker .ShippingCharged > 0, get the Credit GL Account from the Transaction Profile record for Type = Shipment Tracker and Sub-Type = Shipping Revenue.

 

  • Count Journal

 

    • If adding Inventory, Debit the inventory account from the Item, Item Group or Transaction Profile Type = Count Journal - Add, Sub-Type = Item.
    • If subtracting inventory, Credit the inventory account from the Item, Item Group or Transaction Profile Type = Count Journal - Subtract, Sub-Type = Item.

 

Business Logic processing notes:

  • When a reverse transaction is done (ie, Reverse Pack SO) use the same logic as the originating transaction to determine how to create the Journal Entries but process the opposite of Debits and Credits.
  • A custom setting for each Transaction Type will indicate whether or not to create a Journal Entry for that particular transaction type.
  • If the Transaction Profile record is not found for a particular transaction type, the trigger should send an exception message and abort processing that transaction.  No Journal Entry is to be created for the transaction when this condition occurs.
  • The triggers will always populate [Journal Entry.Status] = “Approved”





Light Accounting Education:

 

Accounting Package Technical References:

QB - http://www.rssbus.com/kb/help/RQY3-A/pg_table-receivepayments.rst

QB Online - https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services

XERO - http://developer.xero.com/documentation/api/api-overview/

FF - http://developer.financialforce.com/technical-reference/

Intacct - https://developer.intacct.com/



What we DO NOT do:

  • We do not have a General Ledger in Ascent.  You do not create GL Accounts for your Finance System in Ascent.  These are imported into Ascent.  Hence, there are no Transactions against the GL, and nothing “hits the GL” in SalesForce.  That happens in Financial System.
  • You do not “close your books” in Ascent.  Hence, there is no concept of Years, Periods etc.
  • No financial reporting.  This is done in your financial package.
  • No P&L.
  • No cutting checks.
  • No Time Tracking, Payroll, Expenses, Fixed Assets, Depreciation
  • No Projects, Budgets, Budget Forecasts
  • No Bank Accounts, Bank Statements

Related articles

Comments

0 comments

Please sign in to leave a comment.