[$250] Expense-"Create 2 expenses" is shown on confirmation page after editing distance expense in DM

[lanitochka17]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.60-14
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13177029/test-cases/68907543
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: MacBook Air 15.7.4 Chrome, iPhone 15 iOS 26.3.1
App Component: Money Requests

Action Performed:

1. Sign in to ND as User A
   2.Create chat with User B
2. Click + > Split expense > Distance
3. Enter waypoints and split the expense
4. Open the distance expense, created for User B, edit the amount and save
5. Navigate back to 1:1 chat, click "+" button > Create expense > Manual
6. Enter the amount and click Next button
7. Observe the "Confirm details" page

Expected Result:

Only one expense appears on the confirmation page, green button shows "Create $XX expense".

Actual Result:

Two expenses appear on the confirmation page, green button shows "Create 2 expense". When navigating through the expenses using < > buttons, second $0 expenses can be seen.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Bug7132442_1776448507359.2_expenses.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @ChavdaSachin

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022045229306057177065
• Upwork Job ID: 2045229306057177065
• Last Price Increase: 2026-04-17

[MelvinBot]

Proposal

What is the root cause of that problem?

The confirmation page counts expenses by reading all entries from the TRANSACTION_DRAFT Onyx collection (useTransactionDraftValues), then useOptimisticDraftTransactions shows all of them when the count exceeds 1. A stale TRANSACTION_DRAFT entry with a real transaction ID persists after the split + edit flow, so when the user starts a new expense the collection has 2 non-null entries.

The most likely source of the stale draft is setMoneyRequestAmount, which unconditionally writes to TRANSACTION_DRAFT — unlike peer functions like setMoneyRequestCreated (line 1065) which gate on an isDraft flag. Any caller that passes a real (non-optimistic) transactionID creates an orphaned draft that cleanup cannot remove, because:

1. The cleanup (clearMoneyRequest) relies on validTransactionDraftIDsSelector which reads draft.transactionID (the value). Partial drafts from Onyx.merge (e.g., {amount, currency} only) lack a transactionID field, so draft.transactionID is undefined and cleanup targets the wrong key.
2. The draft cleanup in getUpdateMoneyRequestParams only runs when hasPendingWaypoints || hasModifiedDistanceRate, which is false for amount-only edits.

What changes do you think we should make in order to solve the problem?

Fix setMoneyRequestAmount to respect the isDraft pattern — add an isDraft parameter (defaulting to true) and gate the Onyx key accordingly, consistent with setMoneyRequestCreated:

function setMoneyRequestAmount(transactionID, amount, currency, shouldShowOriginalAmount = false, shouldStopSmartscan = false, isDraft = true) {
    const key = isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION;
    Onyx.merge(`${key}${transactionID}`, {amount, currency, shouldShowOriginalAmount});
    setMoneyRequestReceiptState(transactionID, isDraft, shouldStopSmartscan);
}

All existing callers pass draft transactionIDs, so the default isDraft = true is backwards-compatible.

Additionally, as a defense-in-depth improvement, validTransactionDraftIDsSelector should use the Onyx collection keys (which are always reliable) rather than draft.transactionID (which may be missing from partial merges) to build the cleanup ID list.

What alternative solutions did you explore? (Optional)

• Filter useTransactionDraftValues by reportID or creation context — would fix the symptom but is a broader refactor; the real bug is that stale drafts shouldn't exist at all.
• Add blanket cleanup of all TRANSACTION_DRAFT entries in clearMoneyRequest — too aggressive; it would break multi-scan flows that intentionally maintain multiple drafts.
• Clean up TRANSACTION_DRAFT in getUpdateMoneyRequestParams for amount-only edits — addresses the symptom for this specific flow but doesn't prevent future callers of setMoneyRequestAmount from creating the same problem.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ChavdaSachin (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022045229306057177065

[aswin-s]

Proposal

What is the root cause of that problem?

When a user edits a split distance expense in a 1:1 DM, setSplitShares in src/libs/actions/IOU/Split.ts:2354 writes split-share data to TRANSACTION_DRAFT_<realTransactionID> — keyed by the actual expense's UUID, not the optimistic '1' used for new expenses. When the edit completes, updateSplitTransactions at line 2222 only calls removeDraftSplitTransaction(originalTransactionID), cleaning up SPLIT_TRANSACTION_DRAFT_<id>, but never calls removeDraftTransaction(originalTransactionID), leaving TRANSACTION_DRAFT_<realUUID> stale in Onyx.

Later, when the user starts a fresh manual expense, TRANSACTION_DRAFT_1 is created for the new flow. useTransactionDraftValues (src/hooks/useTransactionDraftValues.ts:6) subscribes to the entire TRANSACTION_DRAFT collection and returns all values — now two entries: the new transactionsDraft_1 and the stale transactionsDraft_<realUUID>. useOptimisticDraftTransactions (src/hooks/useOptimisticDraftTransactions.ts:16) falls into the "multiple transactions" branch (optimisticTransactions.length > 1), so the confirmation page renders both, showing "Create 2 expenses" with a ghost $0 entry.

App/src/libs/actions/IOU/Split.ts

Lines 2219 to 2222 in 5838c42

	}
	}
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.runAfterInteractions(() => removeDraftSplitTransaction(originalTransactionID));

What changes do you think we should make in order to solve the problem?

src/libs/actions/IOU/Split.ts — at line 2222, alongside the existing removeDraftSplitTransaction(originalTransactionID) call, add removeDraftTransaction(originalTransactionID) to null out the stale TRANSACTION_DRAFT_<realUUID> entry that setSplitShares wrote during the edit flow. removeDraftTransaction is already imported on line 75.

All split-expense edits (amount, waypoints, distance rate) funnel through updateSplitTransactions in Split.ts, never through getUpdateMoneyRequestParams in UpdateMoneyRequest.ts. The branching happens at the UI layer in IOURequestStepDistanceMap.tsx (~line 454): isEditingSplit routes to setDraftSplitTransaction (Split.ts flow), while non-split edits route to updateMoneyRequestDistance (UpdateMoneyRequest.ts flow). So cleanup in Split.ts:2222 is the complete fix for this bug.

What alternative solutions did you explore? (Optional)

An alternative is to filter useTransactionDraftValues to only return drafts keyed by CONST.IOU.OPTIMISTIC_TRANSACTION_ID (i.e., '1'), ignoring real-UUID keys. This would prevent any stale draft from leaking into the confirmation page. However, this is a band-aid — it doesn't clean up Onyx, wastes memory, and could mask other flows that legitimately use real-UUID draft keys. Cleaning at the write source in Split.ts is the correct fix.

[JustDreameritis]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After splitting a distance expense in a DM, editing the amount, then creating a new manual expense, the confirmation page shows "Create 2 expenses" instead of one — because a stale TRANSACTION_DRAFT entry from the edit flow was never cleaned up.

What is the root cause of that problem?

setMoneyRequestAmount at src/libs/actions/IOU/index.ts#L1060-L1062 always writes to ONYXKEYS.COLLECTION.TRANSACTION_DRAFT, regardless of whether the transactionID belongs to an existing (non-draft) transaction. Peer functions like setMoneyRequestCreated (line 1065), setMoneyRequestDescription (line 1079), and setMoneyRequestMerchant (line 1084) all accept an isDraft parameter to gate which Onyx collection they write to — and setMoneyRequestCategory has the same bug, also always writing to TRANSACTION_DRAFT without an isDraft gate. When the user edits the amount of an existing split expense, a real transactionID is passed to setMoneyRequestAmount, creating an orphaned draft entry. Later, clearMoneyRequest only cleans up the optimistic draft ID, so this stale entry persists — and useOptimisticDraftTransactions (line 16) counts all non-null drafts, surfacing the phantom second expense.

What changes do you think we should make in order to solve the problem?

Add an isDraft parameter to setMoneyRequestAmount (and setMoneyRequestCategory) defaulting to true for backward compatibility, gating the Onyx collection key to match the established pattern used by the other setMoneyRequest* functions:

function setMoneyRequestAmount(transactionID: string, amount: number, currency: string, shouldShowOriginalAmount = false, shouldStopSmartscan = false, isDraft = true) {
    Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {amount, currency, shouldShowOriginalAmount});
    setMoneyRequestReceiptState(transactionID, isDraft, shouldStopSmartscan);
}

Callers that edit existing (non-draft) transactions should pass isDraft = false. This is a single-file fix in src/libs/actions/IOU/index.ts plus updating the relevant caller(s) to pass the correct flag.

What alternative solutions did you explore? (Optional)

Filtering stale drafts in useOptimisticDraftTransactions by checking if the draft's transactionID matches a known optimistic ID would fix the symptom, but leaves the underlying data leak — orphaned drafts accumulating in Onyx. Fixing the source is cleaner and consistent with how the codebase already handles this for every other money request field setter.

[abbasifaizan70]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After a user completes a Split expense (Distance) and then edits the amount of one of the resulting distance expenses, starting a fresh Manual expense from the same 1:1 chat shows two expenses on the Confirm details page (the new manual expense plus a leftover $0 expense), and the submit button reads "Create 2 expense" instead of "Create $XX expense".

What is the root cause of that problem?

The Confirm details page derives the list of expenses to show from every entry currently present in the TRANSACTION_DRAFT Onyx collection via the useOptimisticDraftTransactions hook. Whenever that collection has more than one entry, the page switches into multi-expense mode and displays all of them, regardless of whether they belong to the flow that was just started.

The hook treats any TRANSACTION_DRAFT entry as belonging to the current flow as soon as the collection has more than one item, so an unrelated draft left over from an earlier flow is surfaced on the confirmation screen:

App/src/hooks/useOptimisticDraftTransactions.ts

Lines 13 to 22 in c05060c

	const useOptimisticDraftTransactions = (transaction: OnyxEntry<Transaction>) => {
	const optimisticTransactions = useTransactionDraftValues();
	const allTransactions = optimisticTransactions && optimisticTransactions.length > 1 ? optimisticTransactions : [transaction];
	const transactions = allTransactions.filter((value): value is Transaction => !!value);
	const optimisticDraftTransactions = [transactions, optimisticTransactions];
	return optimisticDraftTransactions as [Transaction[], Array<OnyxEntry<Transaction>> | undefined];
	};

IOURequestStepConfirmation uses that output directly to decide both which expenses to render and whether it is a multi-transaction flow, so any extra draft leads to an extra card and to the "Create N expense" label:

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 94 to 95 in c05060c

	const [transactions] = useOptimisticDraftTransactions(initialTransaction);
	const hasMultipleTransactions = transactions.length > 1;

The leftover draft in this bug is produced during the Split Distance edit step. SplitExpenseEditPage initializes an edit draft at CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID in TRANSACTION_DRAFT when the user taps into the distance row, and this entry is never removed after the edit is saved:

App/src/pages/iou/SplitExpenseEditPage.tsx

Lines 186 to 196 in c05060c

	initDraftSplitExpenseDataForEdit(originalTransactionDraft, splitExpenseTransactionID, reportID, CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID);
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DISTANCE.getRoute(
	CONST.IOU.ACTION.EDIT,
	CONST.IOU.TYPE.SPLIT_EXPENSE,
	CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID,
	reportID,
	Navigation.getActiveRoute(),
	),
	);
	}}

When the user subsequently starts a new Manual expense, startMoneyRequest calls clearMoneyRequest, which only removes the IDs that validTransactionDraftIDsSelector reported to the caller at render time. Any draft that was written under an id that the caller never observed (for example a draft that was created during an edit step that did not use the standard FAB entry point, like the split-distance edit draft) is not included in draftTransactionIDs and therefore survives the cleanup:

App/src/libs/actions/IOU/index.ts

Lines 975 to 981 in c05060c

	function clearMoneyRequest(transactionID: string, draftTransactionIDs: string[] | undefined, skipConfirmation = false) {
	const onyxData: Record<string, null | boolean> = {
	...getRemoveDraftTransactionsByIDsData(draftTransactionIDs),
	[`${ONYXKEYS.COLLECTION.SKIP_CONFIRMATION}${transactionID}`]: skipConfirmation,
	};
	Onyx.multiSet(onyxData as Parameters<typeof Onyx.multiSet>[0]);
	}

So by the time the user reaches the Confirm details page for the fresh Manual expense, TRANSACTION_DRAFT contains:

• the new manual draft at OPTIMISTIC_TRANSACTION_ID (with the amount just entered), and
• the leftover split-distance-edit draft at OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID (with amount = 0 and iouRequestType = DISTANCE).

Because optimisticTransactions.length > 1, useOptimisticDraftTransactions returns both, so IOURequestStepConfirmation renders both cards and labels the submit button as "Create 2 expense".

What changes do you think we should make in order to solve the problem?

Make useOptimisticDraftTransactions only return drafts that actually belong to the current money-request flow, instead of returning every entry that happens to exist in TRANSACTION_DRAFT. Concretely, we only keep optimistic drafts whose iouRequestType matches the iouRequestType of the transaction the caller is operating on (and, as a safety net, drop the known edit-only transient ids used by the split-expense edit flow).

This keeps genuine multi-expense flows working (multi-scan, multi-distance, etc. all create drafts that share the same iouRequestType) while ignoring stale drafts left behind by a previous, unrelated flow.

App/src/hooks/useOptimisticDraftTransactions.ts

Lines 1 to 24 in c05060c

	import type {OnyxEntry} from 'react-native-onyx';
	import type {Transaction} from '@src/types/onyx';
	import useTransactionDraftValues from './useTransactionDraftValues';
	/**
	* A hook that retrieves all optimistic draft transactions,
	* ensuring there is always a draft transaction available to display.
	*
	* If the draft transaction in Onyx data does not exist
	* or contains only a single transaction, it will fallback to the provided transaction.
	* Otherwise, it will use the draft transactions from Onyx data.
	*/
	const useOptimisticDraftTransactions = (transaction: OnyxEntry<Transaction>) => {
	const optimisticTransactions = useTransactionDraftValues();
	const allTransactions = optimisticTransactions && optimisticTransactions.length > 1 ? optimisticTransactions : [transaction];
	const transactions = allTransactions.filter((value): value is Transaction => !!value);
	const optimisticDraftTransactions = [transactions, optimisticTransactions];
	return optimisticDraftTransactions as [Transaction[], Array<OnyxEntry<Transaction>> | undefined];
	};
	export default useOptimisticDraftTransactions;

Change it to scope the draft list to the current flow:

import type {OnyxEntry} from 'react-native-onyx';
import CONST from '@src/CONST';
import type {Transaction} from '@src/types/onyx';
import useTransactionDraftValues from './useTransactionDraftValues';

// Transient draft ids that belong to edit-only flows (e.g. the split-expense
// distance edit page). They must never be treated as part of a new money-request flow.
const EDIT_ONLY_DRAFT_TRANSACTION_IDS: string[] = [CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID];

const useOptimisticDraftTransactions = (transaction: OnyxEntry<Transaction>) => {
    const optimisticTransactions = useTransactionDraftValues();

    const currentFlowRequestType = transaction?.iouRequestType;

    const scopedOptimisticTransactions = (optimisticTransactions ?? []).filter((draft): draft is Transaction => {
        if (!draft) {
            return false;
        }
        if (EDIT_ONLY_DRAFT_TRANSACTION_IDS.includes(draft.transactionID)) {
            return false;
        }
        // Only keep drafts that belong to the same flow as the transaction the caller is rendering.
        // When the caller's transaction has no iouRequestType yet (e.g. first render), fall back to the draft's own value.
        return !currentFlowRequestType || !draft.iouRequestType || draft.iouRequestType === currentFlowRequestType;
    });

    const allTransactions = scopedOptimisticTransactions.length > 1 ? scopedOptimisticTransactions : [transaction];
    const transactions = allTransactions.filter((value): value is Transaction => !!value);

    return [transactions, optimisticTransactions] as [Transaction[], Array<OnyxEntry<Transaction>> | undefined];
};

export default useOptimisticDraftTransactions;

With this change, in the reproduction:

• The new Manual draft has iouRequestType === CONST.IOU.REQUEST_TYPE.MANUAL.
• The leftover split-distance-edit draft has iouRequestType === CONST.IOU.REQUEST_TYPE.DISTANCE and is also excluded by id.

So scopedOptimisticTransactions.length is 1, the hook returns only the manual draft, and the Confirm details page correctly shows a single expense and a Create $XX expense button.

As a complementary cleanup (to avoid accumulating stale entries in TRANSACTION_DRAFT over time), SplitExpenseEditPage should also remove the OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID draft when the edit flow exits:

App/src/pages/iou/SplitExpenseEditPage.tsx

Lines 186 to 196 in c05060c

	initDraftSplitExpenseDataForEdit(originalTransactionDraft, splitExpenseTransactionID, reportID, CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID);
	Navigation.navigate(
	ROUTES.MONEY_REQUEST_STEP_DISTANCE.getRoute(
	CONST.IOU.ACTION.EDIT,
	CONST.IOU.TYPE.SPLIT_EXPENSE,
	CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID,
	reportID,
	Navigation.getActiveRoute(),
	),
	);
	}}

Extend the existing onBackButtonPress / completion paths on SplitExpenseEditPage to clear the edit draft:

import {removeDraftTransaction} from '@userActions/TransactionEdit';

// ...inside SplitExpenseEditPage, when the user leaves the edit flow (save or back):
removeDraftTransaction(CONST.IOU.OPTIMISTIC_DISTANCE_SPLIT_TRANSACTION_ID);

This keeps TRANSACTION_DRAFT free of stale edit-only entries, but the primary fix in useOptimisticDraftTransactions is what actually protects the Confirm details page from surfacing them.

What alternative solutions did you explore? (Optional)

• Filter Confirm details by initialTransactionID: Rewriting IOURequestStepConfirmation to show only the transaction whose transactionID matches the route's initialTransactionID would fix the symptom, but it would also break genuine multi-expense flows (multi-scan, multi-distance), where we intentionally want to render every draft. Scoping by iouRequestType preserves those flows.

• Aggressively clear TRANSACTION_DRAFT inside startMoneyRequest: Replacing clearMoneyRequest with an unconditional Onyx.clear(ONYXKEYS.COLLECTION.TRANSACTION_DRAFT) would remove stale entries, but it would also wipe legitimate pending drafts (for example, a concurrent multi-scan in progress, or drafts deliberately seeded by buildOptimisticTransactionAndCreateDraft). The hook-level filter is safer because it is purely a read-side guard.

• Clear drafts on IOURequestStepParticipants.navigateBack (the fix used for the self-DM "Submit it to someone" variant): that path is not traversed here because the 1:1 chat auto-assigns participants and skips the Participants step, so it would not cover this scenario.

[Eskalifer1]

🚨 Edited by proposal-police: This proposal was edited at 2026-04-17 20:48:44 UTC.

Proposal

What is the root cause of that problem?

This issue only affects Split; currently, when the amount changes, we reset spliShares right here:

App/src/pages/iou/request/step/IOURequestStepAmount.tsx

Lines 397 to 400 in c05060c

	// Edits to the amount from the splits page should reset the split shares.
	if (transaction?.splitShares) {
	resetSplitShares(transaction, newAmount, selectedCurrency);
	}

But the problem is that resetSplitShares and setSplitShares always work only with ONYXKEYS.COLLECTION.TRANSACTION_DRAFT, but once the Split has been sent, it must refer to a different collection (ONYXKEYS.COLLECTION. TRANSACTION), which means that when editing the amount, we add a splitShares entry to the draft collection for this transaction’s ID, resulting in one additional draft transaction appearing on the Confirmation page

What changes do you think we should make in order to solve the problem?

We need to pass the isDraft parameter with a default value of true to the setSplitShares and resetSplitShares functions, and pass these values to the components depending on isEditing.

App/src/libs/actions/IOU/Split.ts

Line 2315 in c05060c

function setSplitShares(transaction: OnyxEntry<OnyxTypes.Transaction>, amount: number, currency: string, newAccountIDs: number[]) {

function setSplitShares(transaction: OnyxEntry<OnyxTypes.Transaction>, amount: number, currency: string, newAccountIDs: number[], isDraft = true)

// use
isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION

App/src/libs/actions/IOU/Split.ts

Line 2357 in c05060c

function resetSplitShares(transaction: OnyxEntry<OnyxTypes.Transaction>, newAmount?: number, currency?: string) {

function resetSplitShares(transaction: OnyxEntry<OnyxTypes.Transaction>, newAmount?: number, currency?: string, isDraft = true)

 setSplitShares(transaction, newAmount ?? transaction.amount, currency ?? transaction.currency, accountIDs, isDraft);

PS: This is a fix for this specific case; if we find any other similar bugs related to these functions elsewhere, we can also fix them there

P.S2: This is standard logic used throughout the project in many different functions; here are some examples. So it’s nothing new—it’s just that in this particular case, we forgot about it:

App/src/libs/actions/IOU/index.ts

Lines 1079 to 1107 in c05060c

	function setMoneyRequestDescription(transactionID: string, comment: string, isDraft: boolean, shouldStopSmartscan = false) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {comment: {comment: comment.trim()}});
	setMoneyRequestReceiptState(transactionID, isDraft, shouldStopSmartscan);
	}
	function setMoneyRequestMerchant(transactionID: string, merchant: string, isDraft: boolean, shouldStopSmartscan = false) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {merchant});
	setMoneyRequestReceiptState(transactionID, isDraft, shouldStopSmartscan);
	}
	function setMoneyRequestAttendees(transactionID: string, attendees: Attendee[], isDraft: boolean) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {comment: {attendees}});
	}
	function setMoneyRequestAccountant(transactionID: string, accountant: Accountant, isDraft: boolean) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {accountant});
	}
	function setMoneyRequestPendingFields(transactionID: string, pendingFields: OnyxTypes.Transaction['pendingFields']) {
	Onyx.merge(`${ONYXKEYS.COLLECTION.TRANSACTION_DRAFT}${transactionID}`, {pendingFields});
	}
	function setMoneyRequestTimeRate(transactionID: string, rate: number, isDraft: boolean) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {comment: {units: {rate}}});
	}
	function setMoneyRequestTimeCount(transactionID: string, count: number, isDraft: boolean) {
	Onyx.merge(`${isDraft ? ONYXKEYS.COLLECTION.TRANSACTION_DRAFT : ONYXKEYS.COLLECTION.TRANSACTION}${transactionID}`, {comment: {units: {count}}});
	}

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[github-actions]

⚠️ @Eskalifer1 Thanks for your proposal. Please update it to follow the proposal template, as proposals are only reviewed if they follow that format (note the mandatory sections).