May work in some cases but not in ours, we already have account codes through our LD provider and the toll fraud employees just use them to commit the fraud.
I wish it was as simple as "fire that theif" but unfortunately that's not the case. Josh Patten Assistant Network Administrator Brazos County IT Dept. (979) 361-4676 On 2/22/2010 8:25 AM, Paul Herron wrote: > Here's a somewhat related idea that may be a better solution... and I > believe that a feature request is already in the tracker... what about > implementing accounting codes for all "toll " calls? > > I've worked in shops where some or all calls required a billing code > before being allowed to proceed. Codes corresponded to client jobs, > departments, and individual employees. By implementing billing codes, > this problem once again becomes a managerial problem as calls are > charged to a particular client, department, or user who has > responsibility for seeing that those charges are paid (and identifying > fraudulent charges). Individuals can also be given an allowance and, be > charged if they exceed that allowance. > > If an employee purposely enters another user's code, it is still a > managerial problem since the behavior now clearly falls into the > category of misconduct. > > -Paul > > -----Original Message----- > From: Tony Graziano [mailto:[email protected]] > Sent: Sunday, February 21, 2010 1:49 PM > To: [email protected] > Cc: [email protected] > Subject: Re: [sipx-users] "forward calls external" permission > > Then if your job requires internatuonal calling privileges your best > toll is > a reporting one. > ============================ > Tony Graziano, Manager > Telephone: 434.984.8430 > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > ----- Original Message ----- > From: [email protected]<[email protected]> > To: Tony Graziano<[email protected]> > Cc: sipx-users<[email protected]> > Sent: Sun Feb 21 13:24:30 2010 > Subject: Re: [sipx-users] "forward calls external" permission > > I don't have customers. I have users. This was an employee purposely > stealing from the company so he didn't have to pay to call his mother in > africa. Yes, in my situation, it was a thief. > Sent via BlackBerry from T-Mobile > > -----Original Message----- > From: Tony Graziano<[email protected]> > Date: Sun, 21 Feb 2010 13:04:56 > To: [email protected]<[email protected]> > Cc: sipx-users<[email protected]> > Subject: Re: [sipx-users] "forward calls external" permission > > On Sun, Feb 21, 2010 at 10:23 AM, [email protected]< > [email protected]> wrote: > > >> On 2/21/2010 7:49 AM, Raymond Dans wrote: >> >>> I wonder if maybe introducing a User, time based set of permissions >>> might help in this situation. So for example user A has long >>> > distance > >>> permissions between the hours of 7 a.m. to 6 p.m. but not after that >>> time. Not sure of the complexity involved in implementing this, >>> > just > >>> throwing out the idea off the top of my head. >>> >>> >> Wouldn't it need to be blocked in the personal auto attendant as well? >> That would seem like a better place for the thief to set this up. They >> could have multiple numbers that they could transfer out to, and it >> would be harder for them to get caught. We had someone doing this >> (different company, different phone system) and the volume wasn't high >> enough to raise any flags. The only way they got caught was because >> their boss called their desk after hours to leave a VM, and was >> surprised when they reached the employees mother at her home instead. >> > I > >> have no idea if blocking LD privileges at a certain time would affect >> how the personal attendant worked as well. >> _______________________________________________ >> sipx-users mailing list [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users >> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users >> sipXecs IP PBX -- http://www.sipfoundry.org/ >> >> > > Thief? Ok, whatever you say. What we find is the "opposite". We have > customers who intentionally setup International calling for certain > regions > of the world with the intent that their employees are able to use it to > contact family (as a perk, or benefit). > > With the exception of International Dialling, all of our customers have > unlimited domestic long-distance, so as long as there is no abuse during > working hours that keeps people from doing their job, they don't really > care. With the work force becoming so mobile, controlling it becomes an > impedance to getting work done, and so on. So it seems I would look at > your > request as legitimate, but not on the same priority as you need. > Realize > this could have been addressed "first", and it sounds like you jumped in > without addressing this and other issues as an 11th hour need. > > It would be proper to set an expectation based on what the system does, > instead of what it can do "if someone changed the code". In that spirit, > realize there are changes that would have to be made in order to add > this to > sipxconfig in order to satisfy the management goal of the project, > whether > it is schedule based or a plain permission. The changes have to involve > sipxconfig too, and I suggest you open an enhancement request to see if > it > can be scheduled for an upcoming version, so you can set the proper > expectations for your "boss". > > Regards, > > Tony > > > > _______________________________________________ > sipx-users mailing list [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users > Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users > sipXecs IP PBX -- http://www.sipfoundry.org/ > _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
