CR0380 - WilloWare

advertisement
Property of WilloWare Incorporated
CHANGE REQUEST
Change Request #
CR0380 PRO FORMA MODULE Enhancements
Description of Change
Description of Need:
ACME needs the following changes to the Pro Forma module:
1. Item Extended Price from Pro Forma added to the CUSTOMER load plan.
2. Pro Forma number added to the 3PL load plan and summarize by PFINV, Item Number, Lot Number
3. Change the source of the Country of Origin from the wSOPPOPLinks table to Lot Attribute 1
(IV00300)
4. Enter one PF payment and have it post through Cash Receipts as one payment. The entire payment
shouldn’t have to be applied when it is posted.
5. Ability to modify a Pro Forma after a payment has been applied.
6. Auto-apply the sales invoice based on the applied credits to the Pro Forma invoice.
7. Default all reports to “Print to Screen”
8. Give an option to only select from the lot that is labeled as a direct ship lot.
Description of Solution:
1. Item Extended Price from the Pro Forma will be added as the last column on the CUSTOMER load
plan. The column header will be “Extended Price”
2. Pro Forma Number from the Pro Forma will be added to the 3PL load plan. The column will be
called “Pro Forma Inv”. The 3PL load plan will now be summarized by PF Inv, Item Number, Lot
Number (labeled “S/O Number” in Excel).
3. The function that returns the Country of Origin was looking to the table wSOPPOPLinks for the
Vendor ID, and then getting the country from the vendor master table. This function will change to
get the COO from the Lot Attribute 1 field in the Lot Attributes table. The Country of Origin function
is used in the following areas of the Pro Forma customization:
 Pro Forma Invoice
 Pro Forma Packing Slip
 Customer and 3PL load plan
In the case of the PF Invoice, Packing Slip and Customer Load Plan, the country of origins will be
summarized for all lot numbers and displayed in sequence. For example: Australia, Canada, China.
The COO’s will be below the item description on the PF Invoice and Packing Slip.
4. The proposed solution will change the module to allow a PF Payment to be posted without being
completely applied and create only one Cash Receipt during posting. This will create a 1 to 1
relationship between PF Payment and Cash Receipt.
For each Pro Forma that is applied, An additional journal entry will be created that debits General
AR and credits Unearned Sales/Deposits Received FOR ONLY THE AMOUNT APPLIED.
The two account of the journal entry will be taken from Posting Account Setup (Setup >> Posting >>
Posting Accounts. Display = SALES. The two accounts will be:
 Accounts Receivable
 Deposits Received
Page 1
Property of WilloWare Incorporated
For example, if two Pro Forma were applied, two separate journal entries would be posted to
account for the unearned revenue.
5. The PF module will be modified so that after the payment is posted, PF invoices can be applied or
unapplied as required. If a Pro Forma is unapplied, the journal entry to record unearned revenue is
reversed. If a Pro Forma is applied, a journal entry to record unearned revenue is recorded.
If Pro Forma needs to be changed after it is applied to a payment, it must be unapplied first. If the
PF Payment is posted, a journal entry will record the reversing of unerarned revenue, then, after the
Pro Forma is changed and re-applied, another unearned revenue journal entry is created for the
new amount.
The Pro Forma Apply window will be modified to include the PF Payment number and Cash Receipt
number in the header. There will be a lookup next to the PF Payment Number, so if the window is
opened from the new navigation (Transactions >> Sales >> Pro Forma Apply)
Any payment in the system, posted or unposted, can be selected. The user just needs to choose if
they want to view historical or open payments. If the window is opened from PF Payment Entry, the
field will be filled automatically and disabled. A voided payment cannot be viewed in this window.
When the window is opened for a posted payment, the system will check the unapplied amount for
the GP cash receipt. The Cash Receipt could be applied to a document outside of the Pro Forma
module, so this will prevent over-applying.
Changes are required to the Sales Apply Documents window, which are described in #6.
If the PF Payment is unposted, the unearned revenue is recorded for applied Pro Formas is
recorded when the Payment is posted (same as current functionality). If a Pro Forma is applied after
the payment is already posted, the journal entries will be created and posted when the user closes
the window.
To find and unapply a PF Payment from a Pro Forma, The Payment Doc label on the Applied
Payment Inquiry window will be a zoom to the new Apply window so the user can unapply the Pro
Forma. The Applied Payment Inquiry window is accessed from the expansion button next to the
Page 2
Property of WilloWare Incorporated
Applied Amount field on Pro Forma Entry.
In order to make this change, WLP10103 and WLP30103 will be changed to add the Cash Receipts
Number and Batch.
The WLP10104 and WLP30104 tables will be changed to add the Journal Entry field. This will let us
locate the original JE to back-out.
This estimate includes a migration script to transfer all the data from the old versions to the new
versions.
6. The proposed solution will take the pre-applied credits from the ProForma to transfer them to the
invoice. Since GP does not support the ability to apply credits to an unposted document, the
application on the credits to the invoice will occur when the invoice is posted. Since there will be a
time delay from the application at the PF level to the invoice level, restrictions will be placed on the
Apply sales documents window that will make the credit unavailable to other users.
Changes to SOP Posting Process
When an invoice is posted in SOP, the system will look if it was generated from a ProForma, and if
payments have been applied. If so, the payments will automatically be applied to the invoice.
Changes to Apply Sales Documents
To prevent an AR User from applying a document that has been pre-applied to the ProForma, some
additional controls will be added to the Apply Sales Documents window.
 When the Customer ID is entered, the system will check if there are ANY unposted Pro Formas
that are applied to any Cash Receipt Payments for that customer. If so, the Mass Apply button
will be disabled.
 If the credit document a user attempts to choose is linked to any unposted Pro Formas, the user
will receive a warning and be prevented from applying the document. The unapplied amount will
be decreased by the pre-apply amount since it will be applied once the invoices are posted.
Page 3
Property of WilloWare Incorporated
7. The GL Posting Journals generated by the posting of a PF Payment will directly go to the screen.
The report destination window will not open. The unearned revenue posting from the Apply window
after the Payment is posted will also print directly to screen. This behavior will be hardcoded into the
project and cannot be user configurable.
8. A new checkbox will be added to Pro Forma Entry labeled “Direct Only”. This checkbox will also be
added to the WLP10100 and WLP30100 tables. These tables will need migration scripts, which are
included in this estimate.
When the Direct Only checkbox is marked, the auto-assignment of lots will only assign from the lot
number that is assigned as the “DIRECT” lot setup (described below). When the Sales Lot Entry
window is opened for the Pro Forma line, the only lots displayed in the “Available” window will be the
Direct Lot.
A new Field will be added to the Pro Forma Setup window called Direct Lot. The User will enter the
Lot Number that the PF module will use for Direct Only Pro Formas. This This field is an upper-case
alphanumeric field that is 20 characters in length. This field is not validated against any GP tables to
check if this lot entered here already exists in the system.
Page 4
Property of WilloWare Incorporated
This addition requires a new field added to the WLPF4000 table. A migration script is included in this
estimate.
Page 5
Download