Schema Mapping Accounting API & Cloudbeds API

This document provides a schema mapping between the Accounting API and Cloudbeds API. Cloudbeds API serves as the root system, and fields from the Accounting API will feed into and populate the Cloudbeds API. Fields that can be mapped directly are linked, while those that cannot are marked as “Not Migratable.”

Cloudbeds API	Accounting API	Mapping Notes
transactionID	id	Direct mapping.
propertyID	propertyId	Direct mapping.
transactionCode		There is no direct mapping and we can’t use additional info to map it
notes	notes	Direct mapping.
category		There is no direct mapping. Information for custom item is missing
amount	amount	Direct Mapping
currency	currency	Direct Mapping
guestID		Direct mapping with customer_id
parentTransactionID	parentId	Direct Mapping
reservationID		Direct mapping from Booking table
subReservationID	subSourceId	Direct mapping from Booking Room table
transactionCategory		On the public API the available values are adjustment, addon, custom_item, fee, payment, product, rate, room_revenue, refund, tax, void so we can map them based on the internal transaction code
houseAccountID		It maps to sourceId when SOURCE KIND is HOUSE ACCOUNT
houseAccountName		We don’t have this information available to map
roomTypeID		Direct mapping from Booking room table
roomTypeName		We don’t have this information available to map
roomName		We don’t have this information available to map
description	description	Maps directly, but there might be differences that should be reported.
quantity	quantity	Maps Directly
userName		Pull from user service
transactionDateTime	transactionDatetimePropertyTime	Maps to Transaction Datetime, but on Public API might refer to the service date
transactionDateTimeUTC	transactionDatetime	Maps to Transaction Datetime, but on Public API might refer to the service date
transactionModifiedDateTime		No Mapping. Accounting is immutable so this field does not make sense
transactionModifiedDateTimeUTC		No Mapping. Accounting is immutable so this field does not make sense
guestCheckIn		Direct mapping from Booking table
guestCheckOut		Direct mapping from Booking table
cardType		Pulled from payment service
isDeleted		Always false
propertyName		Pulled from org service
transactionType		No direct mapping but we will need to implement logic to understand if the transaction is debit or credit since it is what this transaction represents debit, credit
itemCategoryName		No direct mapping missing information for custom items
	customTransactionCode	New Field, was created for adding the custom transaction code
	generalLedgerCustomCode	New Field, created for adding the general ledger custom code
	internalTransactionCode	Internal Transaction Code defined by-product to categorize the transactions
	customerId	Id of the customer that the transaction is associated with
	sourceId	Id of the source that the transaction belongs, associated to the Source KIND
	sourceKind	RESERVATION, GROUP_PROFILE, HOUSE_ACCOUNTS OR ACCOUNTS_RECEIVABLE
	originId	ID of the origin, for example, the reservation is the room rate ID, the tax is the tax ID,
	account	Used for Deposits, new field
	routedFrom	ID of the transaction that is routed from.
	externalRelationId	This maps to Link ID, is a new field and not exposed on the MFD Public API
	externalRelationKind	Is the KIND of the external relation such as ACCOUNTS RECEIVABLE, TAX, ITEM, PAYMENTS and more
	userId	ID of the User that is creating the transaction
	sourceDatetime	New Field that has the date the event was produced before creating the transaction. For example when Item was added
	createdAt	UTC time when transaction was inserted on DB
	serviceDate	New Field that is useful for reports and can be modified indicating days in the past while transaction datetime will always be the moment the transaction is created. For example if you create a reservation for yesterday, service date will be yesterday but transaction now

Notes:

Validation Required: Some mappings, such as externalRelationId to roomTypeID, require validation for consistency between APIs.

Not Migratable Fields: Fields without a clear equivalent in the Accounting API are marked as “Not Migratable”,

Custom Parsing: Custom codes and descriptions might require additional parsing to ensure accurate migration.

Recommendations:

Data Consistency Checks: Before migration, perform consistency checks to ensure accurate field mappings.

Extend API: If critical fields like rootId or originId are needed, consider extending the Cloudbeds API.