Special Upgrade / Install Instructions
If your company uses the SedonaCloud API, IT will update the SedonaCloud version at the same time as your SedonaOffice upgrade. This is to ensure compatibility with the all modules utilizing SedonaCloud.
Supported Environments
This version of SedonaCloud requires SedonaOffice version 6.2.0.4 or above.
Minimum System Requirements
Server is on Microsoft .Net 4.6.1
Enhancements/Features
SedonaCloud API -- POST API /api/part/PartTransferWarehouse not available (26320) [00040172]
Issue: Users updating to the new API cannot create Part Transfer transactions.
Solution: The PartTransferWarehouse and PartTransfers endpoints have been added: The POST PartTransferWarehouse creates the warehouse transfer for the specified part; The POST PartTransfers retrieves part transfers according the specified search parameters.
PartTransferWarehouse will create a header entry in IN_Transfer and detail entries in IN_Journal where IN_Journal.Transfer_Id = IN_Transfer.Transfer_Id. GL_Register entries are created when COGS > 0 and the warehouse GL accounts or branches are different. These can be found by GL_Register.Primary_Register_Number = PrimaryRegisterId returned in the response.
See technical documentation for further information.
Sedona-X Mobile Permissions for Payment Method (27570)
There is a new Sedona-X Mobile permission to SedonaCloud users (web users with mobile app enabled) that restricts adding a payment method from a service ticket. It is a new checkbox called Add Payment Method.
If the checkbox is selected, a user can add a payment method from a service ticket. If the checkbox is cleared, a user cannot add a payment method from a service ticket. In addition, if the checkbox is cleared, a user cannot add a bank account or a customer credit card and cannot execute the paymentmerchant/iframe endpoint.
This checkbox is selected by default for existing users who already have the mobile app enabled. This checkbox will need to be cleared for any user who should not have this permission.
Ensure Sedona-X Mobile role groups are tagged properly (28579) [Internal]
Several Sedona APIs have been modified to allow the Sedona-X Mobile app to adjust functionality based on defined role groups:
- PUT /api/job/{jobId}/parts - Senior Technician, Project Manager, Manager
- DELETE /api/job/{jobId}/parts - Senior Technician, Project Manager, Manager
- GET /api/CustomerNotes - Doc says that all roles should be able to view customer notes, but API did not have subcontractors included. Added that role.
- DELETE /api/ServiceTicketParts - all roles
- GET /api/dispatch - removed Junior Technician, Subcontractor, Senior Technician so only Project Manager and Manager remain.
- GET /api/Job/{jobId}/dispatch - removed Junior Technician, Subcontractor, Senior Technician so only Project Manager and Manager remain.
- POST /api/Job/{jobId}/dispatch - Senior Technician, Project Manager, Manager
- GET /api/ServiceTicketDispatch - Project Manager, Manager
- GET /api/ServiceTicketDispatch/{id} - all roles
Corrected Bugs (Application Corrections)
Note: Development Item Number in Parenthesis ( ), Customer Case Number in brackets [ ]
API Allows NULLs for Bank_Account_Nam so User cannot edit payment method on customer (22804, 24186) [00027110, 00030013]
Issue: API Post is allowing required fields to not be sent causing Null values where they are not allowed.
Solution: This was resolved by a rework of the validation for bank and credit card information add/update. This involved changes to the api/paymentmerchant/addbankaccount endpoints.
See technical documentation for further information.
POST APBill allows duplicate invoice numbers (26605) [41499]
Issue: Using POST to /api/APBill endpoint is not validating invoice number for duplicate invoices.
Solution: Added a validation to make sure that the invoice number isn't in use more than once per vendor. If an invoice is posted that uses an invoice number that is already in the system for that vendor, then an error will need to be returned.
POST Credit API - BillCycle Required Error posting credit. (26606) [40987]
Issue: Posting Credit is requiring the BillCycle field when item is not recurring item.
Solution: Credit endpoint was updated with newer validations and error messages.Code fields that are present in the view model can be used to look up values (where possible). Fields tied to the Credit endpoint will get set to defaults (where possible).
Sedona API Error posting ACH transaction on Customer 0000 (26607) [00040538]
Issue: Using POST to /api/ACH endpoint is looking for a customer ID of 0 and customer number 000000.
Solution: The validation routine has been changed to ignore the company preference for "ach transaction customer number" and to require a valid customer to be supplied (via either CustomerId or CustomerNumber).
Sedona API Error on Tax posting Credit. (26882) [40014]
Issue: POST - Error if TaxAmount = 0, Missing output parameter declaration for tax_exempt.
Solution: Added tax_exempt parameter to POST Credit API.
PUT api/job/{job}/parts/{id} is updating the wrong table row (26978) [Internal]
Issue: It is updating the table row based on the PartId passed in rather than the JobPartId.
Solution: Corrected the PUT so it updates the correct database row; it updates based on the JobPartId passed in as it should.
api/paymentmerchant/addcreditcard (and addbankaccout) merge LastName, FirstName in Customer Bill to. (26997) [Internal]
Issue: If the referenced CustomerBillTo for the CustomerBillId in the POST payload has a Business Name in the format of LastName, Firstname, the endpoint contains logic that will reformat that name and save it back to the database as 'FirstNameLastname'. It should be 'FirstName LastName'.
Solution: Fixed POST api/paymentmerchant/addcreditcard and api/paymentmerchant/addBankAccount that changes a CustomerBillTo Business Name saved in LastName, Firstname is reformatted and saved 'FirstName LastName' not 'FirstNameLastName'
POST Credit API - Credit detail does not work if type isn't I. (27023) [40014]
Issue: POST Credit API only supports the TypeIM of "I" (Invoice)
Solution: The POST Credit API has been changed to support both the TypeIM of "I" (Invoice), which requires a valid invoice id or number (or both) be sent and the TypeIM of "M" (Miscellaneous) that requires a valid general ledger account number or general ledger account id (or both) be sent in the Credit Detail section for the miscellaneous general ledger account to be used.
POST Credit API - Sum of credit items does not match credit amount. (27024) [40014]
Issue: TaxAmount is coming in NULL, which is throwing off the calculation to determine whether the error needs returned.
Solution: Added TaxAmount field and added logic to set TaxAmount to 0 if it is Null.
POST UnappliedCashDetail - api crash (27025) [Internal]
Issue: One of the functions used needed invoice id, which doesn't need to be supplied if the typeAIM field is set to M.
Solution: This has been resolved by updating the validations for the Unapplied Cash Detail api endpoint.
ARPayment - POST - API Crash (27026) [Internal]
Issue: Validation Error: The DepositCheckId 0 is required or must be set to a valid DepositCheckId.
Solution: Added validations to three endpoints (CreditAuto, DepositCheck & DepositCheckDetails), and marked the DepositCheckId field as required to correct the error message.
GET ACH blank response even when ACHID is provided. (27033) [Internal]
Issue: GET ACH blank response even when ACHID is provided.
Solution: Changed the ACH and AR_ACH models to no longer require the DepositCheckId and PreviousAchId. Also, changed the model mapping to make the navigation property relationships for these IDs to be optional.
POST Credit API - Sum of credit items does not match credit amount. (27024) [40014]
Issue: TaxAmount is coming in NULL, which is throwing off the calculation to determine whether the error needs returned.
Solution: Added TaxAmount field and added logic to set TaxAmount to 0 if it is Null.
Amex payment pushing as Card_type AMEX s/b AMER (27159) [00043233, 46513]
Issue: When customer enters American Express credit card information on Sedonaweb, it registers in SedonaOffice with the card type "Amex" instead of "Amer". Sedona does not allow card type "Amex" so when you try to pull up the Amex payment method in Sedona, you see an error.
Solution: On the Sedona Payment Portal, the credit card type for American Express credit card payments now record properly as "Amer".
Add GET api/paymentmerchant/bankaccounts (27220) [Internal]
Issue: There is an endpoint to retrieve customer credit cards but not one to retrieve customer bank accounts.
Solution: This was resolved by a rework of the validation for bank and credit card information add/update. This involved changes to the api/paymentmerchant/addbankaccount endpoints.
See technical documentation for further information.
POST Credit API - Error when using Account Id = 1 (27559) [Internal]
Issue: If you pass Account ID = 1 in the JSON for the AcountId field, then a validation error is triggered when it should not.
Solution: The Account ID field allowed a default value, which in this case was 1; however, the validation was not handling this scenario. The validation logic for AccountId was modified to handle this.
AR Credit and CreditDetail need Type codes tested (27827) [Internal]
Issue: The issue was that Type codes (for example: TypeIM, TypeJSCO) should return a validation error if the type is blank, empty, null, or not included in the JSON. These were not returning a validation error.
Solution: This issue has been corrected so that type fields that are blank, empty, null, or not supplied will generate an error.
API - Credit Details. InvoiceId needs to check TypeIM. (27929) [Internal]
Issue: Credit Detail is validating the invoice ID regardless of the type present in the TypeIM field.
Solution: There is now an additional validation so that when applying credit to an invoice, the invoice number must be supplied and when applying credit to a miscellaneous account, a general ledger account must be supplied.
POST AR Credit Create Auto Issue (27947) [Internal]
Issue: The validation for LastInvoice was not set to only run if a record with the invoice number was not found.
Solution: The condition for the LastInvoice validation was updated to trigger only when an invoice is not found for the invoice number. The error message has been updated to match the correct field.
We were not able to capture funds without an invoice. We need the ability to capture funds without invoice (28684) [00049752]
Issue: The /api/paymentmerchant/captureauthorizedtransaction endpoint was originally programmed to only support capturing authorized transactions and applying to specific SedonaOffice invoices.
Solution: The /api/paymentmerchant/captureauthorizedtransaction endpoint has been changed to allow all four types of transactions supported by SedonaOffice: Invoice, Advanced Deposit, Unapplied Cash, and Miscellaneous.
POST api/CustomerInvoice not allowing Invoice Items with negative amount (28775) [00050279]
Issue: The SedonaCloud api/CustomerInvoice stopped allowing invoice items to have a negative amount.
Solution: The api/CustomerInvoice has been changed to allow invoice items to have a negative amount.
