When creating an AP Invoice, there are 3 types (Bill, Credit Adjustment, Debit Adjustment and Prepayment). Is this extensible to add another different type? I checked the DAC and the DocType property has the following attribute [APInvoiceType.List()]. Perhaps it is somehow possible to change/enhance this attribute?
Related
Can Assemblies inherit or display the attributes of member items? The source of truth for the Assembly is not the fields on the Assembly record, but rather lives at the member item level below, so I want to avoid duplicating data.
We're manufacturing assemblies of electronics, the BOM has many entries of member items and one of the member items is an LED array. LED array comes in 5 different types, each with a different wattage W, 8W or 12W etc.
If the member items have an attribute for 8W or 12W etc, can the Assembly/BOM record inherit or otherwise display the attribute from the member item?
Again I want to avoid duplicating data that already exists elsewhere.
First, created a custom field in the PM.PMTask DAC called usrNumberofPanel
Second, created a custom field in the PM.PMProject DAC usrTotalPanels.
Want each of the lines from task to update the total number of panels on the project, so modified the attribute for PM.PMTask.userNumberofPanel and added a PXFormula as shown below to add the SumCalc.
[PXDBDecimal]
[PXUIField(DisplayName="Number of Panels")]
[PXFormula(null, typeof(SumCalc<PX.Objects.CT.ContractExt.usrTotalPanels>))]
Made sure the attributes for the Total Panel and set as follows to make sure no one types into the field.
[PXDBDecimal]
[PXUIField(DisplayName="Total Panels", Enabled = false)]
Any thoughts would be appreciated.
It's a known issue that SumCalc doesn't work properly across DACs that are linked with PXParent relationships.
I can only recommend to use a RowSelected or FieldSelecting graph event handlers to compute the sum instead of a solution involving DAC attributes. You can add a comment explaining the limitation of DAC attributes in the event handler if you are seeking Acumatica ISV Certification for your solution.
I want to make the SOLine Qty field to 1.0 by default, so I have changed at DAC level, by doing this it will be applied to the entire application?
Next, I can do same by writing Graph CacheAttached method also, I think this will apply only to that particular graph and if the same field is used in another graph or a custom new screen this will not affect in that graph.
Please suggest.
You are correct, adding an attribute to SOLine DAC extension will apply this attribute system wide. To limit its scope to a graph, use a CacheAttached.
Here are good reads on this subject :
DAC : https://help.acumatica.com/(W(12))/Wiki/ShowWiki.aspx?pageid=b3d24079-bda4-4f82-9fbd-c444a8bcb733
Append and replace of dacs attributes : http://asiablog.acumatica.com/2017/01/append-and-replace-of-dacs-attributes.html
These concepts are well explained in the T200 certification, which I suggest you do if you haven't already.
I have added two custom fields in the Screens: Payment and Application(AR302000), Cash Transactions(CA304000), Funds Transfers(301000) and Back Deposits(305000), and I pretend to add those fields also in the Table CATran
I have a Generic Inquiry that mimic the Report Cash Account Detail (CA633500) where I can see that the Field ExtReference and Description are copied from the Original Ducument (AR302000,CA304000,etc) to the CATran records.
If I would like to pass the value of my custom field to the CATran Table, to get the same behavior that the External Reference and Description does.
Does anybody know what is the action'name to override the Insertion of CATran Detail?
Form AR302000 uses following class: PX.Objects.AP.APPaymentEntry. It means that you should create extension for this class in way similar to this:
public class APPaymentEntryExt : PXGraphExtension<APPaymentEntryExt>
{
}
Then you can use extending with help of CATran_RowInserting for initial values configuration and CATran_RowInserted for modification of inserted values
I'am designing a new invoicing application. There are a number of features that I don't know how to implement in Core Data. I ask you for help with the following.
To keep things simple assume that there are 2 entities, Invoice entity and Detail entity with to-many relationship 'invoiceDetails' and to-one relationship 'detailInvoice'. Here are my questions.
Detail entity should have attribute 'sequenceNumber' which should be auto-generated when the user adds new detail. For each invoice the sequenceNumber should start at 1 and be incremented as the user adds new details. The sequenceNumber should be used to sort details within their invoice.
Detail entity has also attributes 'numberOfItems' and 'price'. It also should have attribute 'amount' which should be auto-generated as product of numberOfItems and price.
Invoice entity should have attribute 'netAmount' which should be generated as the sum of all detail amounts.
Invoice entity should have attribute 'vat' which should be auto-generated as an expression from netAmount.
Invoice entity should also have attribute 'totalAmount' auto-generated as a sum of netAmount and vat.
Invoice entity should have attribute 'dueTo' auto-generated from current date plus some number of days.
How do I accomplish this in Core Data application? Thanks.
/Mikael
Detail entity should have attribute 'sequenceNumber' which should be auto-generated when the user adds new detail.
You'll have to assign this value yourself. What I'd do is store the highest sequence number as metadata on the persistent store file (see NSPersistentStoreCoordinator's metadata-related methods). Any time you create a new instance, read the highest number from the store metadata, increment it, use that value on the new instance, and then save the new value back to store metadat.
2-6. Calculated attributes
These are generally handled by subclassing NSManagedObject and then overriding the setter methods on attributes whose value affects other attributes. For example, based on #2, the setter for your price attribute would look something like:
- (void)setPrice:(NSDecimalNumber *)price
{
[self willChangeValueForKey:#"price"];
[self setPrimitiveValue:price forKey:price];
[self didChangeValueForKey:#"price"];
// Now calculate the new value for "amount" and set it on self.
}
Follow the same pattern for each case. You can also use key-value observing to watch for changes on these attributes, but I find custom accessors to be clearer and less error-prone.