Customers, Jobs and Payment Obligations

You can think of the QuickBooks Customer as being the same as the Rosemark Customer: the person that pays for a Client's Service. In a very loose way, you can think of the QuickBooks Job as being the same as the Client whose Service is being paid for. The Job actually corresponds to Rosemark's Payment Obligation, which connects a Customer to a Service (and, therefore, a Client), for a given period of time.

More detail about setting understanding and setting up Customers and Payment Obligations in Rosemark can be found in the Customers and Payment Obligations section. Here we will mainly be concerned with understanding the correspondence between these QuickBooks and Rosemark elements.

The correspondence of Customers between QuickBooks and Rosemark depends on there being a First Name and Last Name in QuickBooks. The Customer Name field will be filled in based on what is in these fields. It is possible, through a quirk in QuickBooks' user interface, to have these fields be blank, while the Customer Name is filled in. If this happens, Rosemark's QuickBooks Connection will flag an error, which you must first correct back in QuickBooks.

In the course of syncing, the name of a Customer and Job in QuickBooks will be "normalized" to the following format:

Customer for another person	Last Name, First Name \| Client Name
Customer for multiple other persons	Last Name, First Name Service Type1 \| Client Name1 Service Type2 \| Client Name2
Client is the Customer	Last Name, First Name \|
Client is the Customer, multiple Service Payment Obligations	Last Name, First Name Service Type1 Service Type2

In QuickBooks, the Customer (or, more accurately Customer:Job) is a hierarchically organized list. At the top level is the Customer, which corresponds to a Customer in Rosemark. The second level can be thought of as Jobs (which correspond to Rosemark's Payment Obligations). Rosemark does not support deeper nesting in the Customer:Job hierarchy. Though the Jobs repeat much of the Customer information, they are actually separate, and their information can be different than their "parent" Customer (though many fields of a new Job will be populated with values from the parent). A customer with no sub-jobs still has one (implicit) Job contained within it. When the first explicit Job is added, if any information has been entered on the original Customer's Job tab, that job information gets split off into another explicit sub-job at that time.