You are not logged in.

Best practises with data input in palo

Dear visitor, welcome to Palo Community Forum. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

rubi

Intermediate

  • "rubi" started this thread

Posts: 13

Date of registration: Mar 20th 2009

Location: Paris

  • Send private message

1

Saturday, July 11th 2009, 6:17pm

Best practises with data input in palo

Hi to all,

We have implemented Palo (2.5) with Excel Add-in for several customers with complex planning and budgeting rules and off course allocations (using "splash").
With more user’s REX , we have two different needs to increase user's acceptance during collecting data process:
- First, data input on Excel with palo.data formula are not secured. Non advanced users can "break" cells formula containing palo.data (particulary when using accidentally “Del” notepad)
- Secondly splashing data is very usefull for real allocation, but we also use it to input data at agregated level, (for example when 1 measure is non defined on 1 dimension, so we put figures at total; in this case we do not manage non defined element for example, and prefer as far as possible, not creating to many cubes… Therfore in mostly cases, we use “#” input data.
With all that contrainst, we try now to import data from real Excel files (which not contain Palo formulas)
Can you share your experiences with me dealing data input?

Thx to all
Regards,

B.SAAL

sean_s_oreilly

Professional

  • "sean_s_oreilly" is male

Posts: 24

Date of registration: Nov 26th 2008

Location: Melbourne, Australia

Occupation: Senior Analyst Programmer

Hobbies: VBA, Drupal

  • Send private message

2

Monday, July 13th 2009, 1:35am

As you have explained, the Excel front end is not secured. Palo formulas can be overwritten.

However, a user can secure cells in the Excel front end. You need to put code in the Excel function in the worksheet, for example:

Source code

 
1
2
3

Private Sub Worksheet_Change(ByVal Target As Range)
(enter your validation VBA code here)
End Sub
Sean O'Reilly
Melbourne Computing

Pommie

Sage

  • "Pommie" is male

Posts: 412

Date of registration: Feb 21st 2007

Location: Lytham UK

Occupation: OLAP consultant specialising in retail

  • Send private message

3

Monday, July 13th 2009, 9:43am

As regards your protection issue you might find this useful

http://www.jedox.com/community/palo-foru…rotect+and+copy

As regards writing imported values to consolidated elements it sounds like using Palo.Setdata with the splash parameter set to "true" will do what you need

PALO.SETDATA(Value,Splash,(Server/Database,Cube, Coordinate1, Coordinate2,…
Coordinate16,)
Best wishes

John Hobson
The Planning Factory, Lytham, UK
www.planfact.co.uk

rubi

Intermediate

  • "rubi" started this thread

Posts: 13

Date of registration: Mar 20th 2009

Location: Paris

  • Send private message

4

Monday, July 13th 2009, 1:56pm

Thx to your answers.
The vba code customing restrictions rule when inputing is a good solution.
I already thought about palo.Setdata, but It is not reporting and input at the same time, that means that if 2 users is writing at same time ...Bing!
That's why I prefer in that case using real import data...
Ok and what about more alternativ to avoid puting # (for example creating a non defined element to input)?
Regards,

B.SAAL

Pommie

Sage

  • "Pommie" is male

Posts: 412

Date of registration: Feb 21st 2007

Location: Lytham UK

Occupation: OLAP consultant specialising in retail

  • Send private message

5

Monday, July 13th 2009, 4:51pm

You can use PALO.SETDATA for importing data.(see DATA IMPORT in the palo Excel menu).
Best wishes

John Hobson
The Planning Factory, Lytham, UK
www.planfact.co.uk
Rate this thread