Actions working differently in different environments

Options

I have an Process which contains 4 actions. This Process is in DEV, Test and production environment. The process works well in Prod but not in DEV and Test for the end user.

 

No change was made with respect to the actions in DEV. Also tried setting model same as end user's role. But still its throwing error in Test and dev.

 

Can some one help me understand what might have gone wrong? Is it can be some settings issue? If yes what can it be?

 

Thanks!

Tagged:

Answers

  • Hi @VDurgaPriya,
    Can you provide more information? I assume actions are import (correct me if I am wrong), but are they imports from file or model-to-model? Do they connect to other models, and if so, are Source Models different depending on environment? Are you sure that the same account, with the same access (not workspace admin, same selective access and DCA), is used for tests in all environments? Have you checked all settings of import and it's data source to be correct?
  • Hi @VDurgaPriya ,

     

    Can you please share the screenshot or error message?

     

    Thanks

    Akhtar

  • Hi @M.Kierepka ,

     

    Yes it is an import process. Importing from excel(csv) file to module.

     

    The error shows as time format mapping is wrong. In my excel, the time column format is like " Jan-21" but in model, it is just "Jan 21". 

    The action is showing error as "Ensure the column headers in the import file map to the correct dimensions in your module, then run the import again." 

    When I download the error file, the error message is "Expected 2 or 4-digit year in date/period: Jan-21".

    When I change time format in mapping, it works. But without this change, it is working in Production. Wondering why it is not working in dev and test.

     

    Yes, have given same selective access as end user in test env, but same issue. Checked access for modules, lists, versions, etc..

     

    Thanks!

  • Hi @Akhtar.shahbaz ,

     

    Error is - "Ensure the column headers in the import file map to the correct dimensions in your module, then run the import again"

     

    Provided more details in above reply.

     

    Thanks!

  • Hi,
    OK, so it's all the fault of time format. I suggest changing import definition for this field to "MMM?YY" (so both Jan 22 and Jan-22 will be accepted and recognized). This error is quite common and can be a result of Excel changing date format when you open CSV etc.
  • Hi @M.Kierepka ,

     

    Ys I have changed it in DEV and it works, But my question is how come its already working in PROD without this change and not in DEV.

    I also observed the difference for MAC and Windows is that, MAC has their default app for opening excel and there the format is "Jan 22". But in windows it is "Jan-22". Might its the difference? If so, what if an user works from windows? Is there any permanent fix for this?

     

    Thanks!

  • Hi @VDurgaPriya,

    As I wrote, the permanent fix for all environments will be "changing import definition for this field to "MMM?YY" (so both Jan 22 and Jan-22 will be accepted and recognized)". "?" means any character, so even if it will be "Feb_22" or "Apr|22", Anaplan should properly map it.

    And yes, it can be because one user uses different operating system, has different language/location set in regional settings etc., so when they open CSV in Excel, it interprets data and assumes some date formatting. After you save such Excel-modified file, even as CSV, it may no longer have format of the source CSV. That's why you should always work and upload raw/unprocessed CSVs.

    Hint: You can open CSV using Notepad (or Notepad++, or some other text editor) to see raw, unformatted content, and compare what has been changed between raw and Excel-processed CSV.

    Hint2: If you are testing, to make sure that inconsistency is Anaplan's fault, always have the same settings for testers: not only file, but also user's access, browser, language, operating system, location etc. should be the same.