I think it will be worth creating an enum with statuses including this PLACED instead of using magic strings

Wouldn't it be better to place this code from if (isSomeItemsDontMatchExpirationDate) { ... } directly in if (data.inventoryItem && data.inventoryItem.expirationDate !== it.expirationDate)?
Basically, you are trying to find at least one item that doesn't match the expiration date, so I think there is no need to use an additional let declaration, and then check if we change the value of this particular variable because within this loop we already know if we found something that doesn't match expiration date.
So I think it should be something similar to (not tested):

  for (const it of itemsWithLotAndExpirationDate) {
      const { data } = await ProductApi.getInventoryItem(it.product?.id, it.lotNumber);
      if (data.inventoryItem && data.inventoryItem.expirationDate !== it.expirationDate) {
       const isConfirmed = await this.confirmExpirationDateSave();
        if (!isConfirmed) {
          return Promise.reject();
        }
      }
  }

I agree with Alan's comment here

maybe it would be better to check if (!hasErrors) { ... return } to avoid nesting ifs, and because of that you can avoid using else 😆

maybe return without else will be more readable?
+ with that change if (correctErrors) won't be nested in the else.

I regret that this component is not a functional one 😢
When it is functional we will be able to move all of those confirmation alerts to a hook, and make this component a little bit shorter (those alerts have close to 100 lines). Maybe other developers may have any idea how we can make this part of the code a little bit cleaner.

Maybe other developers may have any idea how we can make this part of the code a little bit cleaner.

I can see that the only difference between those are either button labels or title/message.
We wouldn't achieve much by creating a generic function that would accept the title, message, buttons, because the amount of the props we'd have to provide would probably be the same, but I would have to see it after the refactor.

A second approach might be to have one alert method, and we could potentially have a map that would store the labels and we could access it depending on an alert key, e.g.:

const Alerts = {
  VALIDATION_ON_EXIT: 'VALIDATION_ON_EXIT',
  ...
};

const alertsMap = {
  [Alerts.VALIDATION_ON_EXIT]: {
    title: '...'
    message: '...',
    resolveButtonLabel: '...',
    rejectButtonLabel: '...',
  }
}

runConfirmAlert(key) {
  const labels = alertsMap[key];
  return new Promise((resolve) => {
     confirmAlert({
        title: labels?.title,
        message: labels?.message,
        willUnmount: () => resolve(false),
        buttons: [
              {
                label: labels?.resolveButtonLabel
                onClick: () => resolve(true),
              },
              {
                label: labels?.rejectButtonLabel
                onClick: () => resolve(false),
              },
        ],
    });
  });
}

I decided not to proceed with it, I feel like generalizing it will make the code a bit less maintainable.
I know these methods are very similar but I think we will benefit more if we leave it separated as we have it now.

@drodzewicz OK. I've just wanted to show @alannadolny that there is a possibility to make it generic if we would want to. I'm fine with leaving it, as this component anyway needs to be rewritten anytime soon hopefully, but on the other hand I would not agree that my version makes it difficult to maintain.

Maybe other developers may have any idea how we can make this part of the code a little bit cleaner.

I can see that the only difference between those are either button labels or title/message.
We wouldn't achieve much by creating a generic function that would accept the title, message, buttons, because the amount of the props we'd have to provide would probably be the same, but I would have to see it after the refactor.

A second approach might be to have one alert method, and we could potentially have a map that would store the labels and we could access it depending on an alert key, e.g.:

const Alerts = {
  VALIDATION_ON_EXIT: 'VALIDATION_ON_EXIT',
  ...
};

const alertsMap = {
  [Alerts.VALIDATION_ON_EXIT]: {
    title: '...'
    message: '...',
    resolveButtonLabel: '...',
    rejectButtonLabel: '...',
  }
}

runConfirmAlert(key) {
  const labels = alertsMap[key];
  return new Promise((resolve) => {
     confirmAlert({
        title: labels?.title,
        message: labels?.message,
        willUnmount: () => resolve(false),
        buttons: [
              {
                label: labels?.resolveButtonLabel
                onClick: () => resolve(true),
              },
              {
                label: labels?.rejectButtonLabel
                onClick: () => resolve(false),
              },
        ],
    });
  });
}

I agree with Alan's comment here

let's use our notification factory.

if it's made async how about using await instead of .then(() => ...?

why do we actually want to do nothing when an error happens? Shouldn't we let the error handler handle the error and display it to a user?

the error will be displayed to the user, because when using our custom apiClient we have a response interceptor that displays an alert when we get a server error.

I am returning here to prevent the function going further, because the last step is redirecting to stock movement show page and if we have an error we don;t want to do that.

@drodzewicz ok. I thought it would work like in Java (if we use the catch, we'd override the error handler and not let it handle the error).

The difference between our grails error handler and frontend axios error handler is the order when they are called.
In case of grails, the global error handler is called as the last method, so when we catch a method manually it does not propagate to the global error handler.
For our custom apiClient on frontend we set the error handler as a response interceptor which is always called first. It handles the error and then returns a rejected promise.

I apologize not for catching it earlier, but I think we used to name such urls as ..._BY_ID, not to repeat the urls for update, delete, get, read, so I think it should be:

export const STOCK_TRANSFER_BY_ID = id => `${STOCK_TRANSFER_API}/${id}`;

Someone only did it for stock movements, I think it could be just STOCK_TRANSFER, and then you just have:
delete(STOCK_TRANSFER), update(STOCK_TRANSFER) etc.

It was done only for stock movements, because it was the moment in which we decided to avoid using DELETE, GET, POST, and PUT. I remember we created a ticket for the refactor of the rest of the namings (but I could be wrong).

yeah, I think you've followed what was there, but I think this should also be _BY_ID. (Like for STOCK_MOVEMENT)

or perhaps just STOCK_TRANSFER without _BY_ID :)

basically, it would be better to name it as it was done for stock movements

export const STOCK_TRANSFER_API = `${API}/stockTransfers`;
export const STOCK_TRANSFER_BY_ID = id => `${STOCK_TRANSFER_API}/${id}`;

it couldn't be just STOCK_TRANSFER, because we have to separate the URLs for sending requests and redirects.

Oh, that's why it was done like that, forgot about redirects :/

but wait, should not be used for this applicationUrls?