Method Community

I'm creating some custom logic to calculate invoice line item commission amounts. This logic will be needed from a couple different screens.

Rather than write the SAME logic in two different screens I'm creating a new screen and calling it as a pop up where it will load, get some variables, perform it's logic, then return with a couple different Shared Results. It's a total hack but I think it will work fine.

Any Method users out there accomplishing this same goal (e.g. avoiding duplicated action steps) in a more elegant way? Also, I'll be calling this screen/function in a loop so the pop up will be loading and unloading quickly and may induce seizures which really hurts overall productivity. Joking...

Thanks

Hi Blake,

What information are you using to calculate the commission amounts? Is it possible for you to simply add a custom linked field into your InvoiceLineItems table to obtain the information you need? I believe I understand what you are trying to do and to my understanding it should work, but it may be slow this way.

-Audisho

Thanks...

Unfortunately it's not that simple. This is all custom fields and data I'm adding to the system. Commissions based on our service items are going to vary slightly based on a Customer's location/zone so a handful of lookups will be needed to arrive at the correct commission percent value for a particular invoice line item.

Not only that, there are a few other variables that factor into a line item's overall correct commission amount...so what I basically have here is a small rules engine being applied.

The goal here is to replace our current process of manually figuring commissions per line item on each and every invoice we generate and send to a customer. By putting data in the right places, commissions will be automatically figured going forward. This will obviously reduce the overall effort and time associated with invoicing (commissions are figured at time of invoicing here).

I was just hoping someone else had come up with a better/different way to avoid duplicating action steps needed from multiple screens.

I did something similar with printing/reports in Method. It's much easier to report from flattened out, simplified master detail table structures. I have several reports that takes the more normalized data a screen is based on and shove that data on the fly over to different tables used for reporting. I often need to print/run the same report from two diff screens so for these situations I create a screen that takes selected record IDs to be printed, copies the data to the report tables, then runs the report. It avoids the duplication of any cusotm report logic I've created.

HOLY COW. I've been using Method for several years and I'm JUST NOW SEEING THIS!?!?!?!

Apparentlly Button Actions allow you to not only copy Action steps from elsewhere on the current screen, you can also copy action steps from ANYWHERE else within your app/account.

For me, the initial benefit here is I can write actions in one place and if I ever need the same logic elsewhere, I can copy it rather than duplicating it manually. While that's a nice benefit, that also can lead to unwanted code/action duplication; so if you change the script logic in one place, you have to make the same change in any other place(s) you copied the script. That's not good.

So...knowing I have this ability to copy entire actions from anywhere in the app, once I do need an action to be available in more than one place, I could first move the SOURCE action onto it's own screen where I would maintain and make any changes going forward to the action on that screen. Then, when it's working and it's ready to publish, I could copy the action to the screens that use it.

I really wish (feature request) Method allowed me to EXECUTE these actions from anywhere in the app (like a global function) so as to avoid the rigamarole of copying action scripts around the app. But if this is how I can avoid duplication of complex actions in Method, then so be it.

This is a big time hack using Method in this manner and basically a poor man's refactoring capability (for those that have written custom software before, you know how important easy refactorings are). One other side benefit: on the screen where the source action will be housed, you can write small test harnesses on the screen - using text boxes, messages, etc - as you develop/maintain the action logic to help ensure it's working as desired. Once you have it working the way you want, then copy the script ("publish") to the screens where it's needed (again, if you've developed quality software before, you know how important developer testing is).

Anyway, I hope all this makes sense and hopefully others will somehow find this information useful.

Hello Blake,

    You are right.  From an action, you can call other actions within the screen or copy actions.  Also, we don't have a "global call function" where you can store actions in a central place and call it at any place.  Most likely this is due to the complicated nature of developing global functions.  An action would have to be based on a screen, which really means it is based on a single database table.  It gives a point on which a function can operate.  If you had a global function, it would have to be very generic or would need to be restricted to use on certain tables.  As well, customizers have only one or two screens to manage a single table and don't need global functions.  We'll

   I'm not sure if you are a Method Partner.  If you are, try the Method Partner forum and see if anyone has done it there.

Greg

Thanks..

I have many screens that are definitely not simply modifying data on a single table...things that our business has been doing for YEARS on pieces of paper but that had quite a bit of manual effort and logic involved with a heavy dose of math and intuition added for good measure. I've written countless actions that are not based on a single screen but are mere functions called to move data around, check certain data condtions, count things, generate multi-table reports, send emails AND faxes with a single click and so much more.

Using Method I've been able to create entirely new, productive business processes, duplicate our existing ones, improve them, and all but eliminate the tedious manual effort involved.

As a Method customizer, I look WAY beyond the app's basic capability of using 'only one or two screens to manage a single table'. Since day one I've been customizing Method based on business process and the desire to ease and simplify how we operate...not simply showing table data on a screen and saving it.

When I create a custom action on a screen, I always consider the different variables involved in a piece of logic and refactor it into it's own custom action (e.g. subroutine) for easier maintenance going forward. Creating actions like this...I think that's the "generic" thing you referred to and it's a very good idea to break up logic like that when customizing screens in Method. It's not unlike creating cohesive classes in object oriented programming.

Allowing actions to be callable from anywhere within Method would be a VERY BENEFICIAL feature for customizers and one that Method product management should definitely consider moving up on the feature roadmap/priority list. It would be awesome if we could write an action to do some work and call it from anywhere within Method with the ability to perhaps even "pass in" variables as well. I'm speculating here but it's possible there may not be a very good way to make that happen using the current version of ASP.Net Method runs on???

Thanks again...

"Apparentlly Button Actions allow you to not only copy Action steps from elsewhere on the current screen, you can also copy action steps from ANYWHERE else within your app/account."

Nice.  I won't be recreating action steps manually any longer.  Thank you Blake.

-James