[BR] Accounting Optimization (UX)
1. Creating an Invoice
After accountant uploads POD, the system should display a modal with the following options:
Update load status
Dropdown with load statuses (pre-populated to “To be Billed”
Button to “Update”
This allows the user to update the load status
Export to Quickbooks Button
This allows the user to export the invoice to quickbooks
If the customer does not exist, the user should be prompted to create the customer and map to quickbooks (functionality already exists)
This should all happen within the modal
Email Invoice Button
This button would open a new tab with the new “Email Invoice” interface that combines all steps into one (see specs in Confluence and Invision).

Once the user has performed an action, the button should become disabled, and there should be text underneath providing feedback that the action has been performed.
Exceptions:
Email: The email button does not become disabled in case the user wants to email the invoice again.
Load Status: Once the user updates the load status, the “Update” button should become disabled. HOWEVER, if the user changes the load status again, then the “Update” button should become enabled again.

2. Collecting Payments
The payment collection flow can be significantly optimized by:
Allowing the user to log payments for multiple customers at the same time;
Automating status changes; and
Exporting payments to quickbooks
Current Process for collecting payments:

Optimized Process for collecting payments:

Updates to Mark Payment as received screen
In order to optimize the flow, we will need to modify the Mark Payment as Received screen to add additional data points, and to support accepting payments from multiple customers.

The top portion of the page includes only the “Payment date” as an input.
The “Total Income” at the top represents the sum of all payments amount entered by the user in the data table below.
The data table includes the following columns:
Customer
Invoice #
Invoice Date
Payment Method (Dropdown)
ACH - default option
Check
Credit Card
Reference # (input)
Notes
A link that pops up a modal where the user can add a note (see below for UI)
Invoice Total
Balance
Payment Amount (Input, currency)
Paid in Full (checkbox)
When selected, the “Payment Amount” input automatically fills the entire “balance” amount, and becomes disabled so the user cannot modify the amount unless the “Paid in Full” checkbox is unchecked
If the user manually enters the full amount of the balance into the “Payment amount” text box, then clicks out of the text box, the “Paid in Full” checkbox should automatically get checked, and the text box should be disabled.
Export to Quickbooks (checkbox)
When checked, the data for that payment should automatically export to quickbooks when the user clicks on the “Apply Payment” button at the top.
This should be checked by default for all payments
UI for Payment Notes link

Automation after Payments are applied
After the payments are applied, the load status for each load should be updated as follows:
For payments where the entire balance was paid:
Load status changes to “Paid in Full”;
IF the Carrier has already been paid on the load
Load status and Truck status updated to “Archived”
Else
Load status changes to “Partial Payment”
For all payments where the “Export to Quickbooks” checkbox was selected, the payment info should be exported to quickbooks.
3. Upload Remittance for Collecting Payments (Home Depot)
Overview
Some customers, like Home Depot, are very large and do a lot of business. When they pay Zuum, they issue a single payment for a large number of loads. When they issue these payments, they send Zuum a PDF document that itemizes each load and the payments that were made for those loads.
Currently, the process for collecting these payments is very time consuming and inefficient.
Prototype of Entire Flow on InVision.

Optimized Process
To optimize this flow, we will add a feature that allows the user to upload the “Remittance.” The system then collects the data from the PDF, which is always the same format, and automates many of the steps that previously required human intervention.

The Remittance File
The “Remittance” file is a file that includes information from the customer about payments that were issued FROM the customer TO Zuum for a series of loads.
These customers often issue one payment for a high volume of loads at a time. The Remittance breaks down the batch payment into an itemized list in a PDF. We will need to pull data from the PDF and map it to our system.
Home Depot
Currently, this feature will focus on Home Depot Remittances. In the future, other large customers may send similar remittances, and we will need to create functionality that will know to read the other remittances.
Here is a home depot remittance. The data is digital, and is usually pulled into a spreadsheet by Zuum’s accountant.
The remittance includes a data table with the information that we will use in Zuum to log the payment. The following properties should be mapped to Zuum as follows:
In Remittance | In Zuum |
---|---|
Invoice Number | Invoice/Load Number |
Inv Date | Invoice Date |
PO Number / Text | N/A |
GrossAmount | Invoice Total |
Adjmt Amount | N/A |
Net Amount | Payment Amount |
Document # | Reference # |
Uploading The Remittance to Zuum
The user flow begins in the “Invoices” section of the application. There should be a new button on the toolbar at the top-right, that says “Upload Remittance”:

When the user clicks this button, a modal appears

The modal allows the user to:
Upload the remittance file
Modify the Ref # (this field should be optional so that the user can delete this number altogether if desired )
The reference # is the “Document Number” in the remittance file. Please see example highlighted below:
The modal includes a dropdown for the user to select the customer. This is because each major customer will have their own Remittance file format, and will likely require a separate function to pull the required data.
For now, Home Depot is the only customer that is large enough to warrant including this function. Accordingly, Home Depot should be the only option, and should be selected by default.
Once the data is pulled from the invoice, it should be applied to the “Mark Payments as Received” screen, with the data mapped to the appropriate columns. See example below:

By Default:
The customer should be set to home depot for each line item
Payment method should be pre-set to ACH
Reference # should be filled based on what the user input in the “Upload Remittance Modal”
Balance = Invoice Total - any previous payments applied for that invoice # (if any)
Payment Amount
If Payment Amount = Balance
The checkbox for “Paid In Full” should be selected
Payment Amount != Balance
The checkbox for “Paid in Full” should be unselected
Export to Quickbooks should be selected by default
Please Note: When “Paid in Full” is selected, the payment amount input is “read-only”
When payments have been applied, there should be a modal that lets the user know that the payments were recorded:

Automated Processes
Once all payments have been applied, the following processes should happen:
Status
If a balance is paid in full, the status should change to “Paid in Full”
If a balance is partially paid, the status should change to “Partial Payment”
Quickbooks
If the “Export to Quickbooks” box was selected, the payment should be exported to quickbooks as a received payment
Contingencies
In some cases, the “Invoice Number” on the remittance file does not match a load number in Zuum.
When this happens, the user will need to apply these payments to a load in Zuum.
User Flow
This flow begins when after the user uploads the file. If the system identifies Invoice Numbers in the remittance that do not match loads in Zuum, then the user should be taken to the following flow BEFORE going to the “Mark Payments as Received” screen.
Step 1. No Matching Invoices Found

The user is informed that there are no matching invoices found for certain payments in the remittance.
These payments are often made for fees that are billed after a payment has already made. For example, if the driver needed to stay extra time because Home Depot took longer than expected, Home Depot will need to reimburse the driver for that time.
Sometimes, a single payment like this, might apply to more than one invoices. Therefore, the user needs to be able to match multiple invoices to one of these payments.
There is a data table with the following columns:
Remittance Inv. #
This is the “Invoice Number” as defined in the remittance”
Invoice Date
PO# (from remittance)
Gross Amount
Adjustments
Net Amount
Total to be Applied
This field will change based on what the user inputs below
Below the data table there is a section that says “Apply payment to invoice(s)
This section allows the user to enter an invoice number, and a corresponding payment amount that should be applied to that invoice.
There is a link to “add another invoice”
This allows the user to add another invoice number and payment amount, if the remittance was made for multiple invoices.
When the user inputs an invoice number:
The system looks for the invoice #/Load # and lets the user know if there was a match or not
The amount that was entered by the user, is then applied to the “Total to be Applied” column of the data table.
If the user clicks on “Add another invoice”, then another line appears with the same two fields, and the link is pushed down. This way the user can add as many invoice numbers as desired.
The total “payment amount to be applied” cannot exceed the “Net amount” for a single “Remittance Inv. #”
Once the user has completed the process of matching invoices to a “Remittance Inv #”, the user can click on the “Apply Payment(s)” button, and the entire section for that “Remittance Inv #” gets pushed off the screen, as the invoices are matched in the system.
If there are other Remittance Inv. # that need to be matched to a Zuum invoice, they will be pushed up to the top.
Here is an example where there were 3 Inv. Remittance #s that needed to be matched to invoices in Zuum:

If the user does not wish to match these remittance numbers to invoices in Zuum, then the user can click on the “Skip These Payments” button on the top right.
When the user does this, a modal appears, and tells the user that these payments will not be applied in Zuum:

The user can proceed or go back.
Once the user has completed the invoice matching step, whether by entering matching invoice numbers, or by skipping, the user is taken to the “Mark Payments as Received” screen.
If the user matched the Invoice Remittance #s to invoices in Zuum,
The Invoice Numbers and Payment amount for each invoice, should display as rows in the “Mark Payments as Received” screen.
4. Creating a Bill
Overview
Prototype of the entire workflow.
When Zuum hires a carrier to haul a load, the carrier needs to get paid after the work is complete. Zuum needs to keep track of the money it owes to carriers, and whether the carriers have been paid.
In order to do this, Zuum allows the user to generate a “Bill”, which is a record of money owed to a carrier. “Bills” must also be tracked in Quickbooks, as this is Zuum’s external accounting software.
The current process for creating a “Bill” in Zuum, and exporting the “Bill” to Quickbooks, requires the user to navigate to several sections of the Zuum application, and to do repetitive work in Quickbooks.
To optimize this process, we will introduce a feature that allows the user to perform these steps from one page, while automating steps that do not require user intervention.
Current Process Flowchart

Optimized Process Flowchart

Business Process
In order to get paid, the carrier must submit two things:
A signed Proof of Delivery (POD); and
An invoice
Generally, the POD is submitted shortly after the driver delivers the load, and the Invoice is sent by the Carrier’s company afterward. Sometimes, the POD and Invoice are submitted at the same time.
Generally, Zuum is responsible for paying the Carrier 30 days after Zuum receives the invoice. For this reason, it is important to keep track of the date the invoice was received and uploaded into Zuum.
The Current Process allows the user to “Create a Bill” after a signed POD is uploaded to the platform.
The problem with this, is that the payment due date is set to 30 days from the day the POD was uploaded.
If the carrier submits the invoice 5 days later, the user needs to go into the bill and manually adjust the date to when the invoice was received. Otherwise, Zuum would need to pay the carrier 5 days early.
The ability to create an Bill after the user uploads a POD should be disabled.
NOTE: There is a ticket to disable creating a bill when the POD is uploaded. By the time this goes into development, that ticket may have already been completed.
Optimized Workflow
In order to optimize the accounting process, we will introduce a new screen where the user can “Create a Bill”. This screen will be a single location from where the user can:
Create a bill
upload an invoice
upload/View a POD
set the bill date and due date
set the amount due
Link a factoring company to the carrier
View details of the load
View and modify the financials of the load; and
Export the bill to quickbooks
Prototype of the entire workflow.
Requirements
The workflow begins in the “Bills” section of the Broker Admin application.
There is a new button in the top-right of the tool bar at the top of the page, called “+ New Bill”.

When the user clicks on this button, the user is taken to the new “Create Bill” page.

The “Create Bill” page has the following elements:
“Discard” button in the toolbar
This discards the “New Bill” without saving any of the information the user inputs, if any.
If clicked, there should be a modal that confirms whether the user really wants to discard and lose all changes.
Enter Load # - Input with search button
Here, the user enters the load number.
Once it is entered, the system should search for a matching load.
If a match is found,
the system should display a green checkmark letting the user know that a match was found
If there were more than one carriers assigned to the matching load,
The user should be presented with a list of the carriers that were assigned to that load
The user can select the desired carrier to associate with the bill that is being created
When the user selects a carrier, the screen should animate into the next state
The unselected carriers disappear
The selected carrier animates up into the “Carrier Info” spot (see below)
The fields populate below
The data populates into the sections on the right
The system should automatically display and populate the following:
Carrier Info
Below the load # input field, the carrier’s basic information should be displayed:
Carrier Name
Address
Phone
Invoice Date - with the current date
Payment Due - according to the “Expense Total”, which is located in the financials section for that Load #;
This should be in US currency format/type
The Load details on the right side of the screen (explained in more detail below);
The Load Financials
This is like an iFrame that loads the financials page of the load. The user should have full functionality of the financial page
The only button that I left out of this design is the “view invoice” button under “Expense Items.” This is because the user will be uploading the invoice while creating a bill.
If the carrier is linked to a Factoring Company, the Factoring Company “Link” UI should auto-populate with the Factoring Company Name.
Else, the “Link a factoring company” combo-box should appear, with the “Link a factoring company” flow. (see prototype).
If a match is not found, the system should display a red X next to the Load Input field, and let the user know that a match was not found
A matching load must be found in order to create the bill
Upload Invoice Button
This button should trigger an upload modal, with the file type pre-selected as “Carrier Invoice”
This is the same modal that appears in the Docs & Images section of loads
The user cannot change the document type in this setting
There should be no “document sharing options” at the bottom
Once uploaded, the Carrier Invoice document should be stored in that load’s Docs & Images section, along with the regular document data (type, description, upload source, etc.)
After the file is uploaded, the upload button should change to reflect that a file has been uploaded.
The uploaded state includes a link to “View” the invoice, and button (“X”) that discards the uploaded file, and brings back the upload button.
When the user clicks “View”, there should be a lightbox where the user can view the invoice, along with the invoice options. This functionality currently exists in Zuum Fleet Manager (Carrier TMS) when a user views a document.
Note: The document title, date, and source should reflect the actual data (in this example, instead of “Blind Bill of Lading” it should say “Carrier Invoice”
Below the “Upload Invoice” button there should be a text input called
“Carrier Invoice #”
The user enters the number of the carrier invoice
this becomes a property of the Bill that is being created
Link a Factoring Company
As detailed above,
If the carrier is linked to a factoring company:
The Factoring Company Name should auto-populate with the Factoring Company Name from the carrier’s details.
If the user wants to link a carrier to a factoring company, the user can do this through the “linking a factoring company” flow. (Prototype).
Export to Quickbooks Checkbox
If the tenant account does not have Quickbooks integration enabled, the checkbox should be disabled, with a tooltip that says “To enable this feature, please connect Quickbooks in your account settings”
This should be checked by default
When checked
When the user finishes creating the bill, the bill should export to quickbooks.
This is the same functionality as when the user clicks on the 3 dots in the bills section, and clicks “Export to Quickbooks,” except the user is not taken to a separate page to confirm the export.
If the Carrier (Vendor) is not mapped to quickbooks, then quickbooks should automatically create a new record for that carrier and map it to that carrier in Zuum.
Here is the completed state for this page:

Load Details & Financials
On the right side of the screen, there is an area that displays the load details and the load financials.
In the initial state, this area does not display any information.

When the user enters a load number and initiates the search, this area displays the following details from the load:
Pickup 1
City, ST
Date/Time
Dropoff 1
City, ST
Date/Time
Commodity Info
Truck Type
Load Type
Commodity
Weight
Distance
Rate Per Mile (US Currency)
This allows the user to quickly check if the correct Load was found.
Load Details Section Heading
The load details section has a heading that says “Load Details.”
When the user enters a load number and initiates the search, the top right of the section heading should display a link with the Load ID# that allows the user to open that load in a new tab.
This will take the user into the shipment details page of the load #.
The Load Details header also displays the POD status.
This should mirror the POD status from the load’s Docs & Images section
If a POD has not yet been uploaded, there should be a link next to the status that allows the user to upload the POD
When the user does this, the Upload POD modal should pop up, just as in Docs & Images, and the user goes through the same flow.


IF a POD has already been uploaded to the Docs & Images of the load that the user is creating a bill for,
The link should say “View”
When clicked, this should open, in a new tab, the “View POD” page in docs & images of that load

Create Bill Button
At the bottom of the page there is a “Create Bill” button. This button is initially disabled.
The button only becomes enabled after the user has:
Looked up a matching load number
Completed all input fields
Uploaded a file for the invoice
Once this process is complete, and the user clicks “Create Bill,” the bill is created and the user is taken back to the Bills page.
There should be a snackbar on the bottom left, giving the user feedback that the bill was successfully created:

Automations
When the bill is created, the following things should happen automatically:
The uploaded invoice is saved to the Docs & Images section of that load
Truck status for that load is updated to “Carrier Invoice Received”
Confirmation email is sent to the Carrier who submitted the invoice (this template should already exist, if not, please letMatan Dareyknow)The Bill is exported to quickbooks (if the checkbox was selected)
Bill Numbering
A user can create more than one bill for a single load.
Bill Numbering
Bill # should be the load number with the following additional elements:
There should be a lowercase “p” immediately at the end of the load #. The “p” stands for Payable, as this is a bill
An uppercase letter should be added after the “p”
This letter should be the letter “A”
If the user creates a second bill for the same load, this letter should be “B”
For every additional Bill, the replace “B” with the next letter in the alphabet
If the end of the alphabet is reached, add a second letter and continue with the same sequence (ex. Z, AA, AB, AC, etc.)
Example: A shipment has the Load ID: 1234
When the user creates a bill, the bill # should be 1234pA
If the user creates a second bill for the same load, the second bill’s # should be 1234pB
5. Bills Module
The Bills Module is where the user accountant manages Accounts Payable (money that is owed to carriers). This entire module has been updated to streamline the process of:
logging payments in Zuum,
processing these payments through Zuum’s bank, and
exporting these records into Accounting Software (in this case, Quickbooks).
Payment Processing Requirements
This process of issuing payments requires an integration to a payment processor. In this case, Zuum needs to integrate with its bank through an API. The below flow reflects the Payment Processing Requirements:

Overview
The Bills module has 3 sections:
Bills
Payments Schedule
Remittances
All three sections have the following common elements at the top of the page:
Bills Subheader
This is the subheader that says the name of the module “Bills”, and has a button on the right to create a new bill.

2. Tab Subheader
This allows the user to navigate between the 3 sections:
Bills
Payments Schedule
Remittances
Payees
An important update to the bills module is the introduction of the “Payee” property.
A Payee is the person who receives payment for a bill.
Every bill must have a Payee.
In general, the Payee is the company (the carrier) who was hired for the load.
IF the carrier is linked to a Factoring Company, then the linked Factoring Company is the Payee for any Bill where that carrier was hired for the load.
In the current version of the Bills section, there is a column called “Paid To”. But as you can see below, this column is blank when there is no Factoring Company associated with the Carrier.

In this update, instead of the “Paid To” section, all Bills must have a Payee.
Payees are very important in this section, as bills are grouped into Payees and payments are issued to Payees.
Section 1. Bills
The Bills section is where the user can view all of the company’s Bills that are owed to Carriers who have been hired by the company.
This section consists of the following Elements:
“Export XLS” button in the subheader at the top
When the user clicks on this button, it should export to an excel spreadsheet (Not CSV per Ali’s request), a list of all of the bills that meet the criteria of the active filters on the page.

The spreadsheet should have the following columns:
Company Name
Payee
Bill #
Balance Due
Due Date
Status
Remittance
Load #
Invoice Date
Balance on QB
Carrier Invoice #
Filters Menu
The Filters Menu enables the user to display a list of bills meeting a specific criteria. The following filters are available:
Status (dropdown)
All
Not Paid
Scheduled
Paid
On Hold
Canceled

Status Colors: Spec

Payment Due Date (Date Selector)
Should allow the user to select a date range
Should display only bills where the “Due Date” falls within the specified date range
Search Load ID
Enables the user to run a numeric search that only searches for the Load ID property
Search
A free text search similar to the search functionality in the Shipments module

On the left there are Quick Filters that, when selected, automatically set the “Status” and “Payment Due Date” filters. To the right of the Quick Filters are the number of Bills that fall within those filter parameters.
Quick Filter Configuration:
Quick Filter | Status | Payment Due Date |
---|---|---|
Due Tomorrow | Not Paid | Tomorrow’s Date |
Due This Week | Not Paid | Today - 7 days from today |
View All Bills | All | [No Filter] |
Bills On Hold | On Hold | [No Filter] |
Past Due | Not Paid | Before Today’s Date |
At the top right of this menu there is a toggle that enables the user to group the Bills list by Payee, or to turn this off in order to view the bills individually.
Bills List (Grouped by Payee)
The Bills list is a list of all Bills. When “Grouped by Payee”, the list will consist of two levels:
Level One - Payee
On Level One, each row represents a Payee. The Columns include
Payee Name
Total Due
This represents the sum of the payments due to that Payee for the specified date range

Level One rows are collapsed by default, but can be expanded when the user clicks on the dropdown button on the left of the row.

When expanded, the row displays a data table that contains a list of each bill that is due to that payee. The sub-data table includes the following columns:
Company Name (the carrier that was hired for the load)
Bill #
Balance Due
Due Date
Status
Remittance # - The remittance # is issued after a bill is paid. Unpaid bills will never had a remittance #
Load #
Invoice Date
Balance on QB - This represents the current amount due on this Bill in Quickbooks
If this number is different from the “Balance Due” according to Zuum, the number should display in red.
Carrier Invoice - This should pop up the carrier’s
invoice in a lightbox.
Bills List (Not Grouped by Payee)
When the Bills List is not grouped by Payee, each bill is listed individually. The columns on this list are the same, except there is not a “Payee” column right after the “Company Name” column.

Bill Options
Each Bill row has an action button with the following options:
Place Hold - Changes the bill status to “On Hold”
This disables the checkbox that is all the way on the left of the row of that bill.
When a bill is “On Hold”, and the user clicks on the “Bill Options”, then this option will say “Remove Hold”, and the bill will return to its original status.
Edit Bill (opens in new tab)
View in Scheduler (goes to that bill in the Scheduler)
Sync Quickbooks - Overwrites the data in quickbooks associated with this bill, with the current data in Zuum
Void Bill - Changes the status of the bill to “Canceled,” and makes it so that the dollar amount on the bill is no longer due to the Payee.

Selecting Bills
To the left of each Bill row, there is a checkbox.
When grouped by Payee, each sub-data-table has a checkbox in the header, to allow the user to select all bills within that group.

When not grouped by Payee, the data table has a checkbox in the header that allows the user to select all bills within that group.

A user selects one or more bills in order to issue payments for those bills. When a user selects one or more bills, the selections are reflected in the “Issue Payments Menu”
Issue Payments Menu
The Issue Payments menu allow the user to schedule payments for bills that are due. This menu has the following elements:

Bank Link Signifier
On the top right there is a blue rectangle with a link icon inside of it, and the name of the user’s bank, along with the last four digits of the linked bank account number.
This represents that there is an active link between the application and the user’s bank account
Bills Selected
This shows the number of bills that have been selected by the user in the Bills list
Total Payments
This represents the total number of Payees that are included within all of the bills that are selected
Example the user selects the following bills:
Payee
Mike’s Trucking
Bill #1 = $100 (for Mike’s Trucking)
Happy Factoring Company
Bill #1 = $100 (For Dave’s Trucking)
Bill #2 = $100 (For Steve’s Trucking)
Bills Selected = 3
Total Payments = 2 (because there is one Payee for these two bills, they will be combined into one payment)
Total Expense
This is the sum of the “Amount Due” from all of the selected bills
Payment Date (date selector)
This is a dropdown that allows the user to select a date for when the selected bills should be paid
Schedule Payments (button)
This is a button that schedules the payments for the selected bills
When clicked, the status of all selected bills will change to “Scheduled”
The payment data should be exported to quickbooks for all selected bills
All of the selected bills will be unselected
The Bills list should be updated to only show the correct bills (depending on the filter)
There should be a snackbar on the bottom left that tells the user ““Payments Successfully Scheduled”

Effect:
The bills are grouped into payees, and the amount of the bills are added up for each Payee. In other words, each Payee will be issued a payment that is equal to the sum of all of the bills that were scheduled for that date.
Scheduling these payments, means that the system sets the date as a trigger for a function that automates a payment through the user’s bank, to the payee, on the desired date.
Quickbooks Integration
When Bills are scheduled to be paid, the payment data should sync to Quickbooks, including the date of payment.
Mapping
If a bill cannot be exported because the vendor/carrier is not “mapped” to quickbooks, then the system should automatically map the vendor to quickbooks without requiring user action.
Errors
If a bill payment could not be synced to quickbooks, then an error should appear at the top of the page. (Prototype)

When the user clicks on the “details button”, a dropdown appears with a data table showing the bills that could not be synced.
If there is an action that the user can take in order to fix the problem, that action should be included within the Bill’s row in the data table.
Edit Bill
If a user needs to make changes to the details of a bill, the user can click on the Bills Options menu and select “Edit Bill”

This will open the “Edit Bill” page in a new tab.
The “Edit Bill” page is almost identical to the “Create Bill” page from Step 4 with a few minor differences:

The page is called “Edit Bill”
The data from the bill is already pre-filled
At the top left, the Bill # is displayed
the user cannot enter or change the load number
At the top right there is a button to “Void Bill”
This changes the bill’s status to “Canceled”
The button at the bottom is called “Updated Bill”
it is disabled until changes are made
Note: Changes made to the load financials should trigger the update bill button to activate
The changes should export to quickbooks if the checkbox is selected
Since this is open in a new tab, when the user “Updates” or “Voids” the bill, the user should be taken back to the main “Bills” page
Section 2. Payments Schedule
The Payments Schedule allows the user to view and manage payments that are scheduled by navigating to a specific date.

This module has the following sections:
Date Picker (top left)
The date picker allows the user to select a date.
The current date has blue text
The selected date has a blue circle around it, and has white text
All dates prior to the current date are disabled (gray text)
All dates that are after the current date AND that are not selected have black text
When the user selects a date
That date displays on the Payments List
All payments scheduled for that date appear on the Payments List
Payments List (right)
The Payments list is a data table that displays all of the payments that are scheduled on a specific date. The Payments list has two components:
Header
Data Table
Payments List Header
The Header consists of the following elements:
Selected Date
Number of payments scheduled
Payments List Data Table
The Payments List Data Table is a data table with expandable rows.
The Parent rows have the following columns:

Checkbox
Selects the payment
Payee
Displays the name of the Payee, the company that will receive money
Method
Displays the payment method
ACH
Check
There are two payment methods. The payment methods that are available to each Payee will depend on the data that has been input into the system.
If ACH data is available for a payee, then the ACH method will be selected by default; else
Check method should be selected by default
If Check information is not specified, then the following data should be used
Company Name
Company Address, City, St, Zip
More information about payment methods will be in the Payment Processing Integration section below.
Amount
This is the total amount due to the payee for the scheduled payment
This is the sum of all bills that were scheduled for payment for that payee
The Child Rows (when rows are expanded) show each bill that is included in the payment. These rows have the following columns:

Company Name
Bill #
Balance Due
Due Date
Load #
Delete Button
This button removes the bill from this scheduled payment
If removed, the Status of the bill reverts to “unpaid”
Note: If a bill is scheduled, but then its status is changed to “On Hold,” then it is removed from the payment schedule.
Payment Options (bottom left)
The Payment Options menu allows the user to manage one or more selected payments.
The initial state of this menu reflects that no payments are selected.

When one or more payments are selected, the following options are displayed:

Payment Date
This Shows the date that the payment has been scheduled;
When clicked, it opens a date picker that allows the user to select a new date
Payment Method
This Allows the user to select the desired payment method for the selected payment(s)
If one or more payments are selected, and only one payment method is available, then the other payment method should be disabled for the selection.
Options
ACH
Check
Payment Note
This allows the user to add a note to the payment. This note will appear on the remittance (see below)
Cancel Payment
This button will cancel the payment and change the status to all of the bills within the payment to “Not Paid”
Apply Changes
Initially disabled
Becomes active when a change is made to the options
When clicked, this will apply the changes to the selected payments
If a payment is rescheduled or canacled, there should be a snackbar on the bottom left of the screen that gives the user feedback about the action that was taken.
Rescheduled text = “Payment(s) successfully rescheduled. {Option to Undo}”
Canceled text = “Payment(s) successfully canceled. {Option to Undo}”

3. Remittances
What is a Remittance?
A Remittance is like a receipt for a payment that was issued to a payee. The remittance includes:
Information of the Payer (the one making the payment)
Information of the Payee (the one receiving the payment)
Information about the Payment
Remittance #
Reference #
If the payment method was ACH, then display the ACH # that is returned from the payment processor
If the payment method was Check, then display the Check # that is returned from the payment processor
Document Date (the date the remittance was generated)
Payment Date (the date the payment was processed)
An itemized list of each Bill that was included in the payment. For each listed bill, the following info is provided:
Invoice #
Carrier/Company Name
Invoice Date
Amount
The total amount of the payment

How are Remittances Originated?
When a payment is scheduled, and the date of the payment arrives, the payment is processed.
After the payment is processed, the payment processor returns a confirmation number.
That number is used as a reference number
At this time Zuum generates a Remittance, which includes the bank’s confirmation number, and the information detailed above.
The Remittance is then stored in the Remittance List, which is accessed through the Remittance tab of the Bills module.
When a Remittance is generated, it should automatically be emailed to the Payee.
Email List has been updated (row 18)
The Remittances List
The Remittances list is a data table that lists all of the remittances that have been generated. It includes the following components:

Export XLS Button
This exports an excel spreadsheet of all remittances displayed on the list (subject to filters)
Filters
Payee (combo-box)
Text Search
Date Range
Filters by “Date Issued”
Data Table with the following columns
Checkbox (allows the user to select one or more remittances) for batch actions
Method
displays the payment method used to issue the payment for that remittance
ACH/Check
ACH/Check #
This is the ACH/Check number returned from the payment processor.
Remittance # (auto-generated by Zuum for each remittance)
Date Issued (the date the remittance was issued)
Total Payment
Email Contact
The Payee’s email address where the remittance was sent
Buttons
Email - allows the user to generate a new email with the remittance document attached
Download - downloads the remittance document
View - opens a preview of the remittance in a lightbox
Batch Actions
When the user selects one or more remittances with the checkbox, the “Batch Actions” component should appear at the bottom, and allow the user to perform one of the following actions to all selected Remittances:
Download;
Email; or
Export

If the user clicks on the “X” button of the Batch Actions component, then all of the Remittances should be unselected.
The Batch Action component is already functional on Carrier TMS. This code may be shareable. Please check with Alexander Narbut.