Createdon (CreatedDateTime) for a new customer is always 5/15/2024

Hi ​@keithschm 

In standard Acumatica, there is no setting to hard-code or default the `Created On` (`CreatedDateTime`) field to a specific date for new records. The framework handles this transparently via the `[PXDBCreatedDateTime]` attribute, which securely captures the system's UTC time (`DateTime.UtcNow`) at the exact moment the record is inserted into the database. 

If your date is consistently locking to `5/15/2024` through both the UI and the API, it is an environmental anomaly or a hidden code override. Here are the specific areas you should check to resolve this, ordered from most root causes to least:

1. Expired Sandbox / Trial License (Date Locking)
If you are running in a Sandbox, Test, or Demo environment on a Trial License, Acumatica routinely evaluates the license validity. When a trial expires, the system often restricts the application's internal date mechanisms to the exact date of expiration. If your trial expired on May 15, 2024, the framework is capping your new audit dates.

• How to check: Navigate to **System Management > Licensing > Manage Licenses** (`SM201510`) and verify your license status and exact expiration date.

2. Hidden Customization Project Override
Even if you haven't customized the UI or process yourself, another developer or a third-party ISV package might have deployed a Customization Project containing a faulty `FieldDefaulting` or `RowInserting` event on the `BAccount` DAC. For example, if a custom package was coded to pull the current "Business Date" for some fields, and the Business Date in your environment is set to 5/15/2024 for demo purposes, it will incorrectly lock the audit date.

• How to check: Go to **Customization Projects** (`SM204505`), unpublish all projects temporarily (preferably in a Sandbox or off-hours), and create a new Customer. If the `Created On` date is now correct, re-publish packages one-by-one to isolate the culprit. 

3. Underlying IIS / Server OS Clock Incorrect
If your environment is hosted On-Premises or on a Private Cloud, the physical hardware clock on the Windows Server could be stuck in the past. Acumatica relies on the physical machine's time for audit fields. (If you are on Acumatica SaaS, this does not apply). 

• How to check: Have your IT team check the Windows Server time that is hosting IIS and your SQL Database to ensure the Windows Time Service is syncing.

If none of the above apply, the final culprit would be if a rogue developer placed a hardcoded SQL Default Constraint `('2024-05-15')` directly onto the SQL Server `BAccount` table, which would require running a SQL query in SSMS to identify and drop. 

Hope this helps! Let me know what you find.

Hi ​@keithschm,

Could you please confirm the date and time displayed on the top section of the screen in Acumatica, next to the Branch field?

I believe the Created Date should match what is shown in the Acumatica instance.

​@keithschm I think it will fix the database date. can you try to hardcode the created date from API and verify?

Thank you all. I confirmed the date/time is correct in the upper left. We do not have a sandbox only a Test Company so I can’t unpublish all. I will have to look through the custimazatiosn again.  We have a cloud Tennant so no Access to the OS. This happens if I create in the UI or API. I should not have to pass a createdon date.

These are all new customers. New names Address ETC…  Not any that have been deleted.

This was correct. I though for sure it was not, but as it turns out our Partner must imported all of our customers with the incorrect Customer number at Go Live, then deleted them and them imported them with their old numbers. We moved to a new sequence with Acumatica.

Questions,

1. Can we view these records anywhere
2. Can I remove them so we can see the actual Created on Date?

Thank you