The API was trying to get the next job number when the passed-in job code was "0", but it did not work. Corrected the functionality so it gets the next job number when a job code of blank or "0" is passed in.
The code to convert the record model to view model (and vice versa) did not include all the properties, so the missing ones would end up as blank or zero when creating a new job.
Additional validation:
- CustomerId or CustomerNumber are now validated (ID takes precedence if both are supplied). Previously an empty customerId and number were allowed, causing the job to be created without a customer.
- Customer site ID will be validated to ensure it belongs to the customer and is not inactive.
- InvoiceSiteID / CustomerBillId:
- If a different site is selected in the SO client, the Customer_Bill_Id is set to the primary Customer_Bill_Id of that site's customer. The API will do the same thing unless a specific CustomerBillId is supplied, in which case that CustomerBillId must belong to the InvoiceSiteId's customer and cannot be inactive.
- There do not seem to be any rules for which other sites can be chosen in the SO client, so there is no restriction in the API.
- The default value for both is 1, meaning the primary bill-to of the job's site's customer. If a value < 1 is supplied, it will get set to 1.
- BranchId: Cannot be inactive
- ChangeOrder
- CommissionMultiplier
- CreationDate
- EnteredBy
- EstCustomJC1Total
- EstCustomJC2Total
- EstCustomJC3Total
-
InstallCompanyId: Must be a valid install company that is not inactive
-
JobId: Must be supplied but value is ignored. Typically set to 0. The Job_Id from OE_Job is returned in this field.
-
JobLocked
-
JobTypeId: Must be a valid job type that is not inactive
-
MasterJobId: If value < 1 is supplied, it gets set to 1. If value > 1 is supplied, that must be a valid Job_Id in OE_Job.
-
OutsideInvoicingDone
-
OverrideTaskList
-
PermitRequired: Note that even if this is specified as required, none of the permit fields (Permit1, 2, 3) are required to be supplied to create a job.
-
ProjMgrId: If value < 1 is supplied, it gets set to 1. If value > 1 is supplied, that must be a valid employee that is not inactive.
-
Reversal
-
Salesperson1CommissionPctg: Required, but just supply 0 if it does not apply.
-
Salesperson2CommissionPctg: Required, but just supply 0 if it does not apply.
-
Salesperson2Id: If value < 1 is supplied, it gets set to 1. If value > 1 is supplied, that must be a valid employee that is not inactive. SO client does not restrict to a specific employee type (e.g. sales), so API does not restrict either.
-
SalespersonId: Must be a valid employee that is not inactive. SO client does not restrict to a specific employee type (e.g. sales), so API does not restrict either.
-
SalesSplit
-
SoldDate: Must supply a date >= 1980-01-01
-
TaxingGroupId: Cannot be inactive
-
If JobCode is null, empty, or zero "0", the next job number will automatically get assigned. If any other JobCode value is supplied, that will be used when the job is created. If an existing job already has that job code, the call will fail.
-
Remaining unsupplied values should not cause any nulls in OE_Job. Should get defaulted based on field type to empty string, zero, 1899-12-30, etc. Note that supplied dates prior to 1980-01-01 will get set to 1899-12-30.
-
-
Changed database fields to default "empty" values instead of null if incoming data was null.
-
LaborUnits will be updated on the job when the job is created. This also allows the null values in the database to be replaced by the appropriate default if necessary.
-
EnteredBy If passed in, the value will now be used to populate the job log User_Code which will then populate the job's Entered_By. If an empty value is passed in, the UserSessionData.UserName will be used to populate User_Code/Entered_By ( the name associated with the user Id making the API call). Note: The validation currently requires a value in EnteredBy, so an empty value currently cannot be passed in.
-
Found that the job/queue endpoint threw errors.
-
JobQueueSearch.UserCode was a string being passed to a stored proc integer parameter. Changed so the UserCode is looked up in the SY_User view to retrieve the associated User_Id which is then passed into the stored proc. Had to add the SY_User functionality into SedonaCloud because it was previously not there. Noticed that the view will likely fail if the SedonaMaster database is on a different server from the current database (unsure if that scenario can exist or the view would be created appropriately).
-
