Similar post to this:
Curious about properly defining the DAC.
I have a T-SQL CREATE VIEW script that I've added to the 'Database Scripts' are of the Customization project as shown. But I suspect that I haven't added the DAC properly. When I attempt to add this DAC within the context of a Generic Inquiry 'Add Related table' screen I do not get any results when searching for the name of the DAC I tried to create.
When I initially attempted to define the DAC in the 'Code' area, the system complained that the object didn't exist in the database. This makes sense as it's a SaaS instance and I've just created the T-SQL view from a local copy of the database.
So I just added the CREATE VIEW statement within the 'Database Scripts' area and published the customization successfully.(This implies to me that the object exists in the database now).
But I now believe I need to retroactively 'Generate Members from Database' in order to identify the key fields so Acumatica can see how it aligns with other DACs. Is this a correct assumption?
In the CODE area I see this (where vGFCINItemClassSeg is the name of the SQL view )
using System;
using PX.Data;
namespace vGFCINItemClassSeg
{
[Serializable]
[PXCacheName("vGFCINItemClassSeg")]
public class vGFCINItemClassSeg : IBqlTable
{
}
}
Any suggestions on how to properly provide Acumatica with what it needs to associate this to the INItemClass table in the database and make it available as a DAC?
Got this resolved.
Problem was that I had attempted to add the DAC prior to adding the Database script.
Solution: unpublish the customization package. drop the custom SQL view from the database. Start a new customization package. Add the Database Script first. THEN publish. Then after that is successful, re-open the customization project and add the DAC as a second step.
Related
I have a custom table in SQL Server called AnimalBreed and maintenance page.
I wish to add User Defined Field support via the KvExt approach instead of
traditional practices involving either CSAnswers or a CacheExtension of the
DAC and underlying "Usr" fields.
Is this possible?
Can it be done for line-level (child) DACs, such as
existing INLocation and INLocationKvExt?
Thanks!
UPDATE:
It appears the feature needs at least:
ensure your table has the NoteID column as uniqueidentifier datatype and the DAC has the corresponding field: Guid? NoteID and [PXNote()] attribute.
In the ASPX, if not ListView, add the following to the PXDataSource tag:
EnableAttributes="true"
By making these changes, I can Manage User Defined Fields, choose Attributes to include, and I can store values to the KvExt table.
I am using Version = 19.205.0023
Sales Order page observation: if I add two UDFs on SO Order Entry page, one is combobox and one is checkbox, setting their values saves just fine, but then updating the combobox and save leads to loss of the checkbox (from true to false), unless you uncheck and recheck prior to the save. Is this a bug?
Maybe technically possible but definitely not recommended to use undocumented feature like KvExt.
If you need to deploy User Defined Fields on a page which already contains them. Configure them manually and then add them in a customization package in the user defined fields section for deployment as described here:
https://help-2019r2.acumatica.com/Help?ScreenId=ShowWiki&pageid=e01f29d3-b6b1-40f4-a2d1-45c9d01bdde3
Example:
I need to perform soft deletion using jhipster.
Ex:
If user click on delete button I need to mark is_active flag to false.
Writing custom code will be the only solution or is there any way to do it?
Things I have done so far :
I have followed Jhipster web site and created Monolithic application.
Then I have created new entity called 'Student' using the entity sub-generator . (filed names : id, name age, address and is_active. )
The Sub generator generated files contain all the basic CRUD operations and provided a CRUD front-end for student entity.
The front end contains buttons for create student, view, edit and delete.
When I Click on a delete button the studuent record will be permanatly delete from the database.
But my Requirement is to keep the record in the database and mark only the is_active filed in to false.
Basically I need to keep history data of the student without permanatly deleting them.
you will have to edit it yourself. First of all, I recommend you to extend all classes generated by JHipster (except for Resources, you will have to create another class and use a custom mapping thus changing the service in the frontend)
Extend your StudentRepository and create a method that updates the is_active value (it would be better if it receives the id and the value: true or false)
Extend yout StudentService and create a new method (e.g. call it public void disableAddress(Long id))
In that method the your newly created method in the repository layer
Edit StudentResource and change the code inside the deleteStudent method and call your newly created method in the service layer
If you created a new resource, change the service calling your api.
I have a DAC extension that has a default attribute set for it(see definition below). I have noticed that for any records that existed prior to the DAC extensions existence will still hold a null value. Is there a conventional way that we can get all the records initialized?
If not I will likely perform a check within an event handler before its used.
Thanks in advance!
public abstract class usrCustOptInOut : IBqlField
{
}
protected string _UsrCustOptInOut;
[PXDBString(1, IsUnicode = true)]
[PXDefault(OptInOut.Default, PersistingCheck = PXPersistingCheck.Nothing)]
[PXUIField(DisplayName = "Click To Pay Opt In/Out")]
[PXStringList(
new[]
{
OptInOut.OptOut,
OptInOut.OptIn,
OptInOut.Default
},
new[]
{
"Customer Opt Out",
"Customer Opt In",
"Default"
})]
public virtual string UsrCustOptInOut
{
get
{
return _UsrCustOptInOut;
}
set
{
_UsrCustOptInOut = value;
}
}
You will need to run an update manually. Existing records will not be updated automatically when adding new fields and records exist.
I see two options:
Add a a customization plugin to your project (preferred)
Add a custom SQL script to your project
Option 1
You can use a customization plugin to make sure all null values have a default. The customization plugin will run at the end of each publish within the site.
You can create a code file in your customization project to this:
The UpdateDatabase() method in a CustomizationPlugin runs after the customization was published and the website was restarted (the Usr field will be applied).
Then you can use PXDatabase.Update to run the update without needing a graph or any validation/events to run. You just need a bulk SQL update and PXDatabase.Update will do the job. The example below will only set a default if there is a null value. The same concept can be applied to any table/field added not just user fields. For example if you have a custom table and you need to add a new field and have existing records contain a default.
A down side (when compared to Option 2) is PXDatabase.Update will run for the current tenant (company) as it appends the current CompanyID to the SQL statement (which is a good thing). If you have multiple tenants (companies) you will need to run the publish for multiple tenants. Alternativly you can write your code so that it will loop each company and run your statement using PXLoginScope (see references).
The end result using a Customization Plugin would look something like this:
public class UsrFieldDefaults : CustomizationPlugin
{
//This method executed after customization was published and website was restarted.
public override void UpdateDatabase()
{
PXDatabase.Update<MyDac>(
new PXDataFieldAssign<MyDacExt.usrCustOptInOut>(PXDbType.NChar, 1, OptInOut.Default),
new PXDataFieldRestrict<MyDacExt.usrCustOptInOut>(PXDbType.NChar, 1, null, PXComp.ISNULL)
);
}
}
Option 2
You can write a custom SQL script to do the same and put it in your customization project. Keep in mind which DBMS you are publishing to (MSSQL/MYSQL). There is also a way to use a shared SQL syntax so it should work for any DBMS. Also be aware that you would most likely run the script for all tenants (companies) which would include snapshots.
Additional References:
Custom Processes During Publication of a Customization
To Add a Customization Plug-In to a Project
Save data to different company
To Publish a Customization for a Multitenant Site
Creating a Custom SQL Script
Writing Custom SQL Scripts for Interpretation
Newbie to Acumatica here. I've performed a small amount of customization to our system, and am now diving into adding custom data fields.
My goal is to synchronize hardware shipment information from Acumatica into our legacy (outdated and proprietary) hardware management system, as we will need to continue using this system for the time being for warranty calculations. I plan to eventually build this into Acumatica.
My current issue is that I need a method of associating Customer Locations to the customer locations in our legacy system. Adding the field DCL_ID was easy enough to accomplish following the To Add a Custom Data Field documentation. I made the column be required by setting
[PXDefault]
[PXUIField(DisplayName="DCL Account ID", Required = true)]
to the attributes section of the Data Access class as outlined here. I then added the field to my form using the Layout Editor.
At this point all seemed well. The field shows an asterisk in the UI and also validates that a value is provided. Then I realized that Customer Locations is not the only place that uses CR.Location -- it is also used by Account Locations. Doing some digging I've found that Account Locations can include many more account types than Customer Locations. I only need this attribute to be required for Customer Locations. Thus, I have opted to use the To Make a Field Mandatory on the Graph Level.
Here is my CustomerLocationMaint code:
using System;
using PX.Data;
using PX.Objects.CR;
using System.Collections.Generic;
using PX.Objects;
using PX.Objects.AR;
namespace PX.Objects.AR
{
public class CustomerLocationMaint_Extension : PXGraphExtension<CustomerLocationMaint>
{
#region Event Handlers
[PXDefault]
[PXCustomizeBaseAttribute(typeof(PXUIFieldAttribute), "Required", true)]
protected virtual void SelectedCustomerLocation_UsrDCL_ID_CacheAttached(PXCache cache)
{
}
#endregion
}
}
After I save and publish the customization, the field does not function as a required field, as it did when I defined the requirements at the DAC level.
So, what have I done wrong? I've read and re-read the documentation multiple times, but cannot find my mistake.
Setup:
My thought is the underscore in the field name causing the cache attached to not properly register the graph level attribute change. Using a field name without the underscore is the preferred naming convention for tables and columns.
The Acumatica documentation mentions this should be avoided as listed here:
Database Design Guidelines
Found under Table and Column Naming Conventions:
Do not use the underscore symbol (_) in table or column names, because
it is a reserved symbol in Acumatica Framework. For example,
CompanyType is a valid column name, while Company_Type is invalid.
Hopefully it is not a stupid question - can I use BQL to query a new field that I just added through customization in database?
I just added a new field to "contract" table through "System->Customization" - I created a project there and added a new field called "ProductCode" (it automatically became "UsrProductCode" in database), and the field does show in "contract" table as well as the "contract template" screen (CT202000) after successful compilation and publish, exactly as I expected, however, I got error:
The type name 'UsrProductCode' does not exist in the type 'PX.Objects.CT.Contract' in file: Code#SOOrderEntry(80)
when I then tried to use this field in a BQL as below:
// Lookup contract template ID
Contract template = PXSelect<Contract,
Where<Contract.isTemplate, Equal<boolTrue>, And<Contract.UsrProductCode, Equal<Required<Contract.UsrProductCode>>>>>
.Select(Base, inventoryCD);
I thought adding new field through customization would automatically make it available for BQL query but it seems I was wrong - what would I need to do in order to make it be able to be used in BQL?
Thanks for your help.
Edited:
Following suggestion from #Jeff Williams, I tried to find out the class definition file related to my customization - the only file I found is "PX_Objects_CT_Contract_extensions.cs", which is under "C:\Program Files (x86)\Acumatica ERP\AcumaticaERP\App_Code\Caches" and the code is very simple as below:
public class PX_Objects_CT_Contract_Extension_AddColumn: PXCacheExtension<PX.Objects.CT.Contract>{
#region UsrProductCode
[PXDBString(30)]
[PXUIField(DisplayName="Product Code")]
public virtual string UsrProductCode{get;set;}
public abstract class usrProductCode : IBqlField{}
#endregion
I also tried to use "PX_Objects_CT_Contract_Extension_AddColumn.UsrProductCode" in BQL and got error during compilation:
'PX_Objects_CT_Contract_Extension_AddColumn.UsrProductCode' is a 'property' but is used like a 'type' in file:
Can somebody tell me what else I need to do to make this new field available for BQL?
It does add it however you cannot reference it as "Contract.Usr..." it would be under something like "ContractExtension.Usr...".
Look at the data class where the DAC extension is and see what that name is. If your BQL is in a different name space you will need to add a reference to the codeclass namespace as well.