Schema Updates
With Invoice object records no longer being created, the Sales Order will now be the golden record to draw your accounting information from. All the necessary fields that were on the Invoice have been recreated on the Sales Order. Any object that relied on the Invoice Object (receipt line, transaction line, credit notes, etc.) now looks up to the Sales Order Object. See the below sections for details.
Page Contents:
Schema
Schema Updates
Many fields have been added to the Sales Order and Sales Order Line now that the Invoice and Invoice Lines are no longer generated. Here are some new and noteworthy object/field relationships:
The Credit Note, Credit Memo, and Credit Memo Line objects now have lookup fields to the Sales Order and/or the Sales Order Line.
The E-Payment Line has a new lookup field to the Sales Order Line for partial payments and enhanced reporting.
The Community Site has new fields to hold field set names for financial docs. New field sets have been created on the Sales Order and Sales Order Line for the new invoice financial document.
Here is a full accounting of schema updates for the merger:
Fields:
Object | Fields |
OrderApi__Sales_Order__c |
|
OrderApi__Sales_Order_Line__c |
|
OrderApi__Receipt_Line__c |
|
OrderApi__Transaction_Line__c |
|
OrderApi__Credit_Note__c |
|
OrderApi__Credit_Memo__c |
|
OrderApi__Credit_Memo_Line__c |
|
OrderApi__Epayment_Line__c |
|
LTE__Site__c (Community Site) |
|
OrderApi__Store__c |
|
Field Sets:
Object | Field Set |
OrderApi__Sales_Order__c |
|
OrderApi__Sales_Order_Line__c |
|
Schema With No Logic On The Sales Order:
The Fonteva codebase has no reference on the following fields as of the Fonteva 20Spring release. Populating and updating these fields will have no impact on the Sales Order.
Object | Fields |
OrderApi__Sales_Order__c |
|
Lifecyle (Statuses)
The Status of the Sales Order (receipt- or invoice-type) is now driven by action buttons. In previous releases, statuses were driven by checking checkboxes and selecting from picklists. Now, staff will click an action button to change the Sales Order to a new status. See the table below for the list of buttons and their results.
Sales Order Actions | Results |
Ready for Payment | Changes the Status field from Draft to Unpaid. If Posting Entity Type is Invoice, the AR transactions are created. |
Apply Payment | Takes the user to the Apply Payment page where they can make a payment on the selected Sales Order. (Status field MUST read Unpaid) |
Send Proforma Invoice | Sends a Proforma Invoice email to the Contact of the selected Sales Order. No Status change for this action. |
Convert to Invoice | Changes the Posting Entity Type field from Sales Order to Invoice. The Status will change to Unpaid. |
Void | Changes the Status field to Voided. Creates all applicable transactions to void the invoice. |
Write-Off | Write-off the remainder of the invoice. All applicable transactions are created. The Status will be changed to Paid. |
Rapid Order Entry | Opens Rapid Order Entry to allow edits to the selected Sales Order. No Status change for this button |
Delete | Deletes the Sales Order Record. Do not delete records that have related records, like receipts or transactions, attached. This will remove your audit trail for transactions. |
The diagram below outlines the expected statuses as a result of clicking the action buttons. The rectangles represent the Sales Order, its Posting Entity (Receipt or Invoice), and its Status. The ovals represent the action that was taken on the Sales Order.
As a result of actions taken on a Sales Order (type Receipt or Invoice), the statuses will change. The table below is what the expected status should be throughout the lifecycle of the order.
Status | Sales Order Type Receipt | Sales Order Type Invoice |
Draft | It is not ready for payment | It is not ready for payment |
First status of a new SO. You cannot make payments against this and it is not visible in the community. | First status of a new SO. You cannot make payments against this and it is not visible in the community. | |
Unpaid | Ready to be Paid | Posted and Ready to be Paid |
Is Closed = true | Is Closed = true and Is Posted = true Today <= Due Date | |
Overdue | Has not been paid or voided and today's date has passed the due date | Has not been paid or voided and today's date has passed the due date |
Today > Due Date AND Balance Due > 0 | Today > Due Date AND Balance Due > 0 | |
Paid | Paid in full | Paid in full |
Balance Due = 0 AND Is Voided = false Is Closed = false AND Is Posted = true | Balance Due = 0 AND Is Voided = false Is Closed = false AND Is Posted = true | |
Voided | When a not fully paid order or invoice has been deemed invalid. | When a not fully paid order or invoice has been deemed invalid. |
Is Voided = true | Is Voided = true |
Previous Vs. Today’s Behavior
Previously, statuses were driven by selecting a new status in the Status dropdown and/or the Posting Status dropdown. See below for how Sales Orders and Invoices used to change statuses based on the Status and Posting Status selection versus how they will in the Fonteva 20Spring release.
Here’s a quick list of changes.
Previously | Today |
We controlled the lifecycle of the Sales Order/Invoice by updating the Status fields and/or checkboxes. | We control the lifecycle of the Sales Order/Invoice using the action buttons provided on the Sales Order record. |
No clear definition of the different status fields. | Statuses mean the same thing to everyone. You cannot change the status as it's now a formula field. |
We needed to Close and Post the Sales Order to create invoices. | We decided to mark Sales Orders/Invoices as Unpaid, meaning they are ready for payment. Closed contradicted common vernacular for invoices and is no longer used. |
We could Cancel invoices, which did not create reversing Transaction entries. | We no longer support Cancelling invoices since it has no accounting impact. To remove an invoice, we should always Void or Write-off the invoice. |
This table describes the Status and Posting Status fields and how they previously worked on the two order types.
Posting Status / Status | Sales Order Type Receipt | Sales Order Type Invoice |
Status = Open | Sales Order is a “Draft” mode | Sales Order is a “Draft” mode |
Status = Closed | Sales Order is “Ready for Payment” | Invoices are generated under the Sales Order with “Draft” status |
Status = Closed | Sales Order is fully “Paid” | Related invoices are updated as “Posted” status. |
This is the status field’s values and their definitions/functionality.
Status | Invoice |
Draft | When Sales Order marked as Unpaid, Invoice gets created |
Posted | Ready for Payment. |
Canceled | Balance Due remains, Transactions are not reverted back (System Checkbox field) |
Voided | Transactions reverted back. Balance due is 0. (System Checkbox field) |
Paid | No Balance Due. Invoice is fully Paid. (Formula field) |
Overdue | Has Balance Due and Due Date past. (Formula field) |