Lars, Do you have a specific example you could share? Off the top of my head I would say treat the different price points as a service provided and then associate the assets and customers related to that service. All you would have to do is change the service price. It sounds like you may have a little different situation. As an example the organization may provide desktop services. There may be a bronze, silver, and gold package with different price points and configurations. You would setup the bronze package for $x.xx and associate all the customers and desktops to that package. I'm not sure if this is how you are currently setup or if you have widget A that you charge customer X $10 and customer Y $20. I would tend to think the services are different price points and the physical assets are the same price. Another scenario might be if you sell widget A for $10, but if they buy 100 widgets it is $8/widget. I would think these price points would also be listed separately in the system. I'm not sure it is a far stretch to utilize the basic OOB functionality with the addition of a couple workflow items to handle price changes and merges. I would also probably look at instead of modifying the existing price point just setting up new ones. This way you have a historical record of both. Hopefully this gives you a few ideas.
Brian On Wed, Feb 29, 2012 at 9:55 AM, <lars.j.petters...@vattenfall.com> wrote: > ** ** > We have different prices for different customers, today we have an ars > form with price-information/asset, and when an asset is created and marked > yes for invoicing, we check who the customer is, and get the right price > set, this also have to work when using the import tool, we also need to > connect an asset to different attributes, like a special user, or just > connect to an organisation. During the invoicing routine we have some forms > locked for editing, so that the files to R3 will match the specifications. > We need to be able to change a price, and that should update all assets > related. Before invoicing starts we need to be able to find errors, like > mismatch between projectnumber/asset and related customer e t c and correct > that. There need to be functions to merge two customers into one, change > customer numbers and so on. And much more. All this is working today in our > home built system. I look forward to find out how itsm can handle this. > > // L ars > > ------------------------------ > *Från:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *För *Brian Pancia > *Skickat:* den 29 februari 2012 15:33 > *Till:* arslist@ARSLIST.ORG > *Ämne:* Re: Asset Invoicing > > ** > > For the purchasing piece you probably only need the COTAR as an approver. > Adding/modifying a project should fall under the Change Management process, > with the purchasing portion being a task(s) under the CR. The CR would > then have the multiple approvals if needed. **** > > ** ** > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *Roger Justice > *Sent:* Wednesday, February 29, 2012 8:25 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Asset Invoicing**** > > ** ** > > ** This is included with ITBM. > > **** > > -----Original Message----- > From: Tommy Morris <tommy.mor...@pinebreeze.com> > To: arslist <arslist@ARSLIST.ORG> > Sent: Wed, Feb 29, 2012 8:22 am > Subject: Re: Asset Invoicing**** > > ** **** > > The OOB Purchasing module is not very robust. There is only one approval > allowed so chain approvals are out of the question. If you have a current > homegrown process then you need to really go through the OOB purchase > process to see where all the gaps are. I’ll bet that you are going to have > to customize like crazy to get it to work the way your business partners > need it.**** > > **** > > *From:* Action Request System discussion list(ARSList) [* > mailto:arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG?>] *On Behalf Of *Brian > Pancia > *Sent:* Wednesday, February 29, 2012 6:53 AM > *To:* *arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG> > *Subject:* Re: Asset Invoicing**** > > **** > > ** **** > > Lars,**** > > **** > > The Asset Management piece has a purchasing and receiving piece that might > solve the bulk of your requirements. You may also be able to setup the > projects as CIs and relate all the items purchased to the project CI. Add > your additional attributes that you need to the project CI. If there are a > lot of things outside the OOB functionality that you need you can always > setup a backend staging form to setup your invoicing, but I think with > little effort you can probably use the straight OOB functionality to handle > most of what you're looking for. You can setup the paying units as cost > centers and you have the ability to relate multiple cost centers. The only > part that may require some customization is your pricing model for initial > cost versus monthly costs, but it doesn't sound like this would be major.* > *** > > **** > > Brian**** > > **** > > **** > > *From:* Action Request System discussion list(ARSList) [* > mailto:arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG?>] *On Behalf Of ** > lars.j.petters...@vattenfall.com* <lars.j.petters...@vattenfall.com> > *Sent:* Wednesday, February 29, 2012 5:16 AM > *To:* *arslist@ARSLIST.ORG* <arslist@ARSLIST.ORG> > *Subject:* Asset Invoicing**** > > **** > > ** **** > > Hi, has anyone been able to create an invoicing module of assets in the > ITSM-system (7.6) with very few changes within the itsm-code. Something > besides itsm handling the invoicing of assets. Assets are supposed to be > connected to a paying unit, have a price which can easily modified, logic > for initial cost and after that a monthly cost, file has to be created for > R3, and excelfiles has to be created as specifications to the different > customers. Each asset has to be connected to a project number, and a lot of > other economy attributes, like order number.**** > > **** > > We have run this for many years in our home built system, but now it has > to be done in itsm.**** > > **** > > Any feedback will be appreciated.**** > > **** > > L ars**** > > **** > > **** > > **** > > _attend WWRUG12 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ **** > > _attend WWRUG12 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_**** > > _attend WWRUG12 *www.wwrug.com* <http://www.wwrug.com/> ARSlist: "Where > the Answers Are"_ **** > > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_**** > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
