Comments
You can also use the "Perform an unbound action" by adding the trigger name in an expression as a custom value in the "Action name" field to force the "Action parameters" field to show up. Then you just have to make some small changes to the JSON payload.Action Name expression: trim('')Modified JSON payload:{"msdynmkt_order": {"salesorderid": ""},"msdynmkt_surveyinvite": {"activityid": ""},"msdynmkt_bindingid": "msfp_surveyinvites/","msdynmkt_signalingestiontimestamp": "@{utcnow()}","msdynmkt_signaltimestamp": "@{utcnow()}","msdynmkt_signaluserauthid": "","msdynmkt_profileid": ""}
This sounds like an Abstract Class (abstract table?) concept more than an interface, but I am still here for it!Sales Header, Sales Header Archive, Purchase Header, and Purchase Header Archive for example, might inherit from the "Abstract Table" Commerce Transaction Header or something similar, which would define the shared fields as well as any shared functions.It would probably mean a new datatype of Abstract Record rather than an extension of the Interface datatype, to keep with the conventions that an interface cannot implement properties (look up "Interface Keyword C#"), but instead comparing a record to a C# class which can implement properties (fields in AL), the appropriate addition in AL would be supporting the Abstract Keyword (look up "Abstract Keyword C#" as a TableType value and having inheritance between record definitions, or having support for the implements keyword towards a new abstract type.Note: I did have direct links to the Microsoft documentation for the interface and abstract keywords but ideas doesn't like links (very sad).
I support @Moustapha's proposal for introducing AndAlso/OrElse operators. Coming from a .NET background, I've found myself frequently needing short-circuit evaluation patterns in my code. This became particularly evident when working with token validation, where you'd want to check whether a token value is null, before checking if its contents are empty to avoid conversion errors. Adding these operators would significantly improve code scenarios like this.
Hello, We might have to go a deep dive into this There was a similar requirement of such sort from a client of our and when we ask what all fields are we looking to change then the result was - Dimension on Header Level / Line LevelUnit of MeasureAddition of a Sample Line - An Item given Free of Cost etc. Payment Terms Etc.We told them that this could change the reporting part and adding to it, it might also be possible that this might be a gateway to fraud - if not properly used. I'm open to hearing your suggestions on this as well as if there's any practical use cases. RegardsKaran
Hello Team, I have a question here - When you accept the additional quantity based on the Over-receipt code - Won't this impact the 3 way matching of PO, GRN and PI ???Also, If vendor is going to charge us for the additional quantity - it'll create an imbalance between the PO and PI, Correct ?How we solve this till now - We always ask the PO Creator to Amend the PO along with a Note, So that we know that this has been ameneded - Also, We keep a trail for Audit purpose as to why this was opened and sent for approval again ?This ensures the 3 way matchingPlease let me know if i'm going in wrong direction with this ?