Material List Structural Member Reporting Method and Its Affect on Pricing

[ccarpenter18]

In X12 I've noticed that when using Structural Member Reporting in a material list, the price column in the list does not appear to be sensitive to whether a "per unit" or "per length" calculation is being performed by the material list.  In both cases, the material list appears to use the same Price variable in the Component Panel of each object.  Does anyone know of some Ruby scripting that could be used to correct this?  Off hand, I'm thinking of a macro inserted into the Price variable on the Component Panel of each structural member that would use the Material List row context to report a price that depends on how the row wants to use the Price.

[Alaskan_Son]

I don't understand the problem.  Can you show a quick example?

[Kbird1]

40 minutes ago, ccarpenter18 said:

Structural Member Reporting

 

which Type ?  by Default it uses Total Lineal Length , so if you haven't set up a SMR Method for your needs , eg Cut list , Buy list etc..... it will only show total Lft. 

 

 

 

[ccarpenter18]

I've attached 3 photos of a material list.  The framing members appearing here all have a price of $0.58 as recorded in the Price variable of each framing member's Component Panel.  It is intended to be a "per foot" price.

 

The first attached photo (linear.png) shows the material list.  Note the "Linear Length" structural reporting method selection in the upper left.  This method shows an accurate subtotal price ($349.57) for framing.  Buy.png shows the same list with "Buy List" selected.  Note that the subtotal is substantially smaller ($46.98).  This is because Chief is still using the "per foot" price from each member rather than a "per member" price*, which is what it should be doing if the pricing is to be accurate for this type of reporting.  Finally, Mixed.png shows the same framing for "Mixed Reporting".  Half the list is "per foot" and the other half is "each" (ie "per member").  The subtotal price is $160.19, which is also inaccurate.

 

Since all prices are coming from the Component Panels, I'm wondering if there is a Ruby script, or at least Ruby NVPs I can use to adjust the reported price in the panels depending on how the price data is being used in the material list.

 

Hope this makes it a little clearer.  I'm not sure I have a solution.  For now I just ignore pricing in the material list for anything other than "linear".
 

*  or "per unit" price as I was using earlier -sorry if this caused any confusion

[ccarpenter18]

Kbird1, I'm using just the default Structural Member Reporting list.  I'm toggling the reporting method on the material list itself (button on the upper left) as I described above.

[Kbird1]

If you are using the Component list to bring in the Lft Price then you'd need a (simple ?) macro in the total Cost column and you'd have to insert it if changing the SMR List Type....  you could make several macro and insert them from the M> Icon when needed too.

 

eg for Buy list assuming 9 ft Studs       =((count*9)+extra)*price

 

** I think you be better off just changing the price to $5.22 for a 9ft stud , the total is then automatic , it will be a lot trickier if you need to switch list types continually in the ML?

 

I have a feeling I am not understanding exactly what you are doing though...

 

Mick.

[ccarpenter18]

I'm trying to avoid a lot of manual insertion in the material list each time I toggle the SMR List Type.  Also, I regenerate the material list often.  In theory, at least, a macro in the Components Price column of each member could be designed to use the Ruby context of the material list line.  Once the member is used in a material list, it could use the material list context to sense the SMR List Type being used and whether the line represents a "per foot" or "per member" type of calculation to come up with the right pricing.

 

Of course, the BEST way to lick this problem is to do a Chief redesign so that the components panel always assumes a price-per-length value AND the material list uses the price plus the member's length (when appropriate) to calculate a price-per-member.  Short of that happening, I thought someone might have figured out a way to use Ruby to get around the problem.

[Kbird1]

13 minutes ago, ccarpenter18 said:

I'm trying to avoid a lot of manual insertion in the material list each time I toggle the SMR List Type.  Also, I regenerate the material list often.  In theory, at least, a macro in the Components Price column of each member could be designed to use the Ruby context of the material list line.  Once the member is used in a material list, it could use the material list context to sense the SMR List Type being used and whether the line represents a "per foot" or "per member" type of calculation to come up with the right pricing.

 

If that is possible , Michael  ( Alaskan_Son above), would be one of the individuals on the Forum, to talk to directly about a Custom Macro.

 

Most people are not switching the Reporting style frequently , so my guess is your needs have not come onto Chief's Radar..... perhaps make a Suggestion in that forum.

 

M.

[ccarpenter18]

I've used Chief since X6 but am new to these forums.  Perhaps I selected the wrong one?  My SSA support person recommended I ask around in the forums to see if anyone had worked on the general topic of using Ruby with material lists.  I see Alaskan_Son inquired about this issue earlier so I suspect he will raise it elsewhere if he feels its important enough to pursue.  Thanks.

[Alaskan_Son]

This is totally doable using Ruby.  Are you competent with Ruby and custom text macros?

[Ridge_Runner]

14 minutes ago, ccarpenter18 said:

I've used Chief since X6 but am new to these forums.  Perhaps I selected the wrong one?

You are in the right forum. The Seeking Services forum would be the one to go to if you already knew you needed custom macros; or contact members directly who respond, such as Michael.

[ccarpenter18]

I was a software developer for many years but am brand new to Ruby.  Know just enough to be dangerous!

 

Are there any docs that go rigorously into how to access all the Ruby contexts and NVPs available in Chief?  The one chapter on Ruby in the Tech Doc doesn't say much on this.

 

[ccarpenter18]

Ridge_Runner, I'm not in the market to purchase a custom macro, if that is what you were suggesting.  I had assumed these forums are exchanges of free ideas and code that have been developed within the Chief user community for love of the product and the subject.  I understand we all have to make a living, so I'm not opposed to the concept of fee for service as a general proposition.  It's just that I can't afford such an undertaking at this point.

 

[Ridge_Runner]

1 minute ago, ccarpenter18 said:

Ridge_Runner, I'm not in the market to purchase a custom macro, if that is what you were suggesting.

My bad. I wasn't offering my services; I don't do custom macros but many of these guys do. Several on this forum do help with macro advice from time to time and from their own time. But they also offer custom macro work for those who need it for a reasonable fee.

[ccarpenter18]

No problem. I wasn't assuming you were offering macro services.  Was just trying to get a sense of the rules of the road, at least as to what one could expect on these forums.  Thanks.

[Alaskan_Son]

37 minutes ago, ccarpenter18 said:

No problem. I wasn't assuming you were offering macro services.  Was just trying to get a sense of the rules of the road, at least as to what one could expect on these forums.  Thanks.

The problem here is that situations like this almost invariably require code that only works for one specific use case scenario and so its not some simple pre-existing idea or code that you really need.  In this case, you need a very specifically (and creatively) designed, written, and configured code that meets your specific use case.  In other words, it requires someone to do the work. 

 

If you already know how, I could give you some quick tips, but otherwise I would just need to do the work for you.  Sometimes I feel like people think we're being stingy with our knowledge and ideas, but I could literally spend all day everyday answering followup questions to that free information I provide. 

 

Its akin to designing homes...it takes someone who knows what they're doing to get it done and its not something you can learn in a few posts.  This is why there are VERY few people here who know how to effectively write and use some of the more complex custom macros.  The investment is simply too great, and I would argue that its typically not even worth it either.  You could spend literally hundreds of hours getting it all figured out from a technical standpoint, but maybe you're not the creative type, so you still end up hitting roadblocks.  Plus, even if you are super good at devising creative solutions and you master Chief and you master Ruby, is it really worth all the hundreds of hours invested if you could simply pay somebody for a few hours of their time to do it for you?

 

Anyway, I don't have much extra time to play with right now, but here's some quick custom macros and general ideas on-the-house as a one time courtesy.  Just open the attached plans and see how I set the 2 joists up.  They both contain a slightly different solution depending on what your end goal is, but they both essentially do what you're trying to accomplish...

 

Material List price mod.zip

 

 

Again, that was as a one-time courtesy.  Use it freely as you wish, but if you need further modifications, in depth explanations, or coaching, that would be a different story. 

 

 

[TheKitchenAbode]

16 hours ago, ccarpenter18 said:

No problem. I wasn't assuming you were offering macro services.  Was just trying to get a sense of the rules of the road, at least as to what one could expect on these forums.  Thanks.

 

When posting a question one does not "expect", what you do is "Hope" a forum member will take interest in your dilemma and offer some advice/guidance that will assist you in resolving it. Don't expect to always receive a definitive answer, this will depend upon the complexity of your issue. What you should be hoping for is some guidance as to where you should focus your own efforts to resolve the problem. There are no rules other than to be polite and appreciative to those trying to assist you. Keep-in-mind that some users have developed over time extensive skills, knowledge and techniques that they may rightfully consider to be somewhat proprietary, it's not really fair to expect them to just divulge this in an open public forum. If you need access to this depth of knowledge then it is not unreasonable for them to desire a bit of compensation. I believe you will find that those members offering paid for support services likely provide exceptional value for what they charge. I'm just guessing here but if a macro costs you $100 or $200 and saves you half an hour of work each day then your return on investment is well worth it.

[ccarpenter18]

Thanks Michael!  (My delay in responding was due to trying to click the download in the email sent to me by Chief rather than inside the Chief Forum environment and getting an error).  Your code is similar to something I had been playing with, except that I was going after the word "each" in the Price field rather than the hyphen in the Size field.  Discovered that "each" is not really part of the variable and is added by Chief dynamically.  Besides, I knew generally that using information from the same field you plan to modify is not likely to work.  So that was a show-stopper for me.

 

At any rate, I'll incorporate what you sent me and if I need further (paid) assistance I'll contact you.  BTW, you are very kind to provide this code snippet!  I wasn't expecting anyone to actually code anything on the spot.  Was just asking around to see if someone else had run across the same problem and had already coded a solution.

 

Thanks again,

Chuck