Uno de los principales problemas que se plantean al implementar facturas o informes es como imprimir verticalmente por regla general es imposible en impresoras matriciales ya es una odisea. Si nuestro cliente es muy pero q muy “rata” o “cicatero y no quiere entrar en la era de las nuevas tecnologías con una impresora láser o estamos atados por una ISO que nos obligue a dar formatos extraños a la factura, podemos utilizar las dll’s del sistema para acceder a los documentos e incluso voltear o girar las fuentes de impresión para imprimir el famoso registro empresarial de las facturas.

axl_gdi_2.xpo

Buenas a todas y a todos. Por regla general las secuencias de facturación suelen configurarse y no dar problemas, pero en el caso que nos ocupa tenemos una multinacional que utiliza unos terminales de venta para generar facturas y albaranes etc, con numeraciones propias y esto hay que trasladarlo al AX con el minimo de problemas y de accesos a base de datos.

Nada de soluciones Salomónicas de update a “cholones” contra la custinvoicejour y cosas así que se os ve la pinta de “programatas” de medio pelo salidos de la vieja escuela del “clipper 5″, ahora el famoso “Delfi 6″. (jejejejej)

Bueno lo dicho aquí va el código para contabilizar facturas o albaranes con la numeración que queramos sin que el estándar de deje de chutar.

protected void insertJournal()
{;
ttsbegin;

numberSeq = this.allocateNumAndVoucher();
//axl numero de factura..
if (salesParmUpdate.invoiceid != ”)
{
number = salesParmUpdate.invoiceid;
numberSeq.parmNumberSequenceCode(”);
ttsbegin;
voucher = numberSeq.voucher();
ttscommit;
}
else
{
[number, voucher] = this.getNumAndVoucher();
}

if (this.updateNow())
{
this.postUpdate();

TransactionLog::create(this.transactionLogType(),this.transactionLogTxt());
ttscommit;
}
else
throw error(strFmt(“@SYS21533″));
}

Tan solo hay que sobre escribir el método insertjournal de la salesformletter

Para poder crear un archivo tipo bat o cmd con definirlo de esta manera “file = new asciiio(‘c:\\filex.bat’,'w’);” ya tenemos un fichero llamado filex.bat en c:\ . Ahora bien en nuestro c: o en el del sevidor???? Pues eso solo lo sabremos si el metdodo q hemos ejecutado se lanza del lado del cliente o del lado del servidor, y para salir de dudas mejor definir una metodo static y ponerle server para que de fijo se lance en el servidor donde se este ejecutando nuestro AOS (AX32serv.exe).

static server void Start()
{
asciiio file;
str txt;
;
winapi::deleteFile(‘C:\\file2.txt’);

file = new asciiio(‘c:\\filex.bat’,'w’);

if (file)
{
txt = (strfmt(‘net start “Axapta batch 1″ ‘));
file.write(txt);

file = null;

winapi::shellExecute(‘c:\\filex.bat’);
winapi::deleteFile(‘C:\\filex.txt’);
}

}

ftx_tpv_shutdownrestartservices.xpo

Lo cierto es que desde que microsoft cogió por banda nuestro ERP favorito ha hecho buenas mejoras a parte de subirle los costes de instalación y licencia que va muy bien para eso de la facturación mensual. Una de las grandes mejoras es el rendimiento del AOS, originariamente esto del aos era la hiper-mega-solution para grandes redes pero en la practicar era mas rapido una tortuga en java que el dichoso AOS aparte de los miles de errores de sincronización de objetos, formularios y hasta de datos, por que el manejo de la cache de estos era pesimo por no decir pobre. En algunos desarrollos era mejor optar por un diseño plano sobre cliente para evitar sorpresas de ultima hora con las impresoras y dios sabe que mas.

También durante la primera epoca de 3.0 algun iluminati de dangard y luego de navision le dio por dar los cursos de instalación como si esto fuera un IE 7, vamos siguiente — siguiente — etc. Y resulto que muchas por no decir el 60 % de instalación se hicieron sobre dos directorios diferentes de objetos, lo que provoca desde errores en los formularios a errores de sincronía con la base de datos que pueden hacer desaparecer nuestros datos.

Al menos los siguientes sp han corregido muchos errores y han mejorado la velocidad y estabilidad de ususarios.

vaya el siguiente texto de ejemplo de lo que se vendia de un AOS :

 

 

The AOS and the quest for Bandwidth.

When the discussion is about the ‘speed’ of the Axapta system running client and the AOS, some important factors have to be considered. This article will try to explain some of these issues.

Bandwidth, which we all want lots of, is the amount of data that can pass from the source to the destination per unit of time, averaged over many transactions. Measurement in mega bits per second (Mbps)/kilo bits per second (kbps).

Keep in mind that bandwidth is not a measure of speed, but rather of quantity.

If you look at your connection to the AOS as a freeway, bandwidth is a measure of the number of lanes available for traffic. The more lanes you have the greater the number of cars your freeway can handle.

Please keep in mind that bandwidth is not everything. Latency, “the speed”, also matters.

Latency, is the time it takes for a single data transaction to occur — the time between sending the data on the source end and its reception on the far end. Measurement is in millisecond, ‘ms’.

The speed on your freeway would be measured in the speed the cars traveled, and would be independent of the number of lanes available, (bandwidth). Speed on the network/Internet is determined by a measurement called “latency.”

Simply put, latency measures the minimum amount of time possible for a packet to be transferred over your connection. The higher the latency gets the longer transfers take and the lower your connection “Speed Limit” will be.

This means that there will always be a minimum time that you can never beat. This is the latency. Even if you send a very small packet, the fastest it can get to the server will be depending on the latency and not the bandwidth. (This of course, if you have enough bandwidth for the packet)

So the perception of speed, is (therefore) actually a combination of these two performance numbers.

The ping command can inform you about the latency on the network from your client to the AOS in ms.
A more accurate way is to use the build in performance measurement tool in Axapta 2.5. e.g. (Administrator;Inquiries;Performance Tests;Performance Tests;Client/Server connection.) If the network has a high load of traffic, there is a possibility that the lower prioritized icmp packet will indicate higher latency then there really is on the network.
This is due to the fact that the icmp packet used in combination with the ping command has a lower status on the network than the TCP packet.

What about the ASU?

Navision a/s has defined the following:

1 ASU is the load generated by Axapta 2.5 when creating and invoicing the amount of 10 salesorder with each 5 orderlines processed over the period of 1 hour.
That’s a total of 10 Salesorder with a total of 50 salesline in one hour.

Please read at Technet.damgaard.com ‘ResourcesHardware Sizing Guide’ about the definition of ASU. Please also read about the number of ASU the different Axapta modules produce.

How does all the above relate to the AOS?

With the above definition of ASU and demand for bandwidth and latency, and not at all having discussed the need for hardware, Navision a/s on the standard Axapta 2.5 gives the following rule of thumb that:

1 ISDN 64kbps is able to handle the throughput of 10 ASU, meaning that you e.g. can produce 100 salesorder with a total of 500 saleslines over a period on 1 hour.

The demand for latency has to be <100ms and preferably <50ms on the communication line.
When the latency is high, it has a huge impact on the speed of the system.

Development gives the following formula to compute the bandwidth requirements.

The formula

ASU x 6,4 kbps = y
If y < 64 kbps then bandwidth = 64 kbps
else bandwidth = y kbps

E.g. The requirement for bandwidth by the load of 20 ASU
20 x 6,4 kbps = 128 kbps
Required bandwidth = 128 kbps

Keep in mind that the above has been tested on a standard Axapta 2.5 installation. If you have been adding to the standard application you have to consider the impact of this.

Recommendations

These can be rule of thumb only so please apply your common sense when sizing for a customer.

When talking bandwidth and latency requirements, you will need to agree to a performance level for Axapta with your customer.

Make sure that the bandwidth and latency are measured using Axapta’s built-in tool rather than relying on what the network provider promises and measure it periodically over a period of time and particularly at peak hours to ensure that you know what the user will experience. Also make sure that the measurements are done on the production environment with as realistic a load as possible. It is of little value to measure one client loading a line that has to provide for 100.

Preferably Axapta should have a dedicated line to avoid mail, print etc. generating inexplicable sporadic bad performance. If this is not possible, make sure that the connection amply sized.

Bear in mind that due to the client/server architecture of Axapta, Axapta is hit very hard from high latency.

What about the future?

In the future Navision a/s have plans to produce some more detailed information in regard to the AOS communication and different types of communications lines.

The concept of Axapta System Tables

Axapta system tables contain data that the Axapta kernel uses to control the behaviour of the kernel.  Axapta system tables are created automatically by the kernel, when Axapta is started for the first time against an empty database or after a service pack upgrade.

Axapta system tables are in many ways treated as ordinary Axapta tables from the kernel’s point of view. They are synchronized in same way and inserts / updates of the tables are done in a similar way.

System tables are not company specific and do not have a “DataAreaId” column.  Therefore, system tables are implicitly treated as if they belong to the “DAT” company.

All system tables (except “SqlSystemVariables”) have a “RecId” column, which is updated as an ordinary table belonging to the “DAT” company.

Some system tables has the following standard columns:

·         MODIFIEDDATE

·         MODIFIEDTIME  

·         MODIFIEDBY    

·         CREATEDDATE   

·         CREATEDTIME   

·         CREATEDBY

 

All system tables (except “SqlSystemVariables”) have a TableId.  The TableId’s for system tables starts at 65508 and each field in a system table also has a Id that follows the normal rules for Id generation of FieldId’s.  Please refer to the form “SysSqlDictionary” to see the mapping of system tables and TableId / FieldId.

Axapta system tables can’t be accessed or viewed directly from the AOT (Axapta Object Tree).  Furthermore, you should not access the system tables Axapta application layer.

This document contains a description of the most important Axapta system tables, except the table “SqlSystemVariables” which is described in another document. The information in this document is not valid for the table “SqlSystemVariables”.

 

Description of Axapta System Tables

ACCESSRIGHTSLIST (TableId = 65526)

This table contains info about explicit granted access rights for the defined user groups.

Note: Until you have explicitly defined permissions for a table, access to tables is defined using Feature keys. Once you set restrictions on a particular table for a particular user group, all other groups automatically have No Access to that table. As this will seriously impact the way the system works, you are presented with a warning dialogue before any change takes effect. In the dialogue you must decide whether other user groups should have no access as the result of the change you are making, or if other groups should keep their present permissions.

 

Column	Description
GroupId	Id of group for which the access right is valid. Entry must be found in system table “UserGroupInfo”. Type: Varchar2(5) Value: Admin:        Administrator group Xxxxx:        Other groups
RecordType	Type of access rights Type: Number(10) Value: 0:            Table permissions 3:            Feature key and menu permissions
ParentId	????? Type: Number(10) Value:
Id	Internal Id of element on which access rights is defined. Type: Number(10)
UtilElement	Name of element on which access rights are defined. Type: Varchar2(40)

 

AccessType

Granted access right Type: Number(10) Value: 0:            No Access. Prevent access to the functional group. 1:            Read. Allow the group to view data but not edit, add, or delete data. 2:            Change. Allow the group to view and edit data but not add, or delete. 3:            Add. Allow the group to view, edit, add, but not delete data. 4:            Full control. Allow the group to view, edit, add, and delete data.

AccessTypeFkeyUse

Access right granted through feature keys. Type: Number(10) Value: See AccessType

 

COMMON

 

COMPANYDOMAINLIST (TableId =  65509)

This table contains relation between companies and domains.

 

DATAAREA (TableId = 65533)

This table contains data about created companies.

 

Column	Description
Id	Id of company. Type: Varchar2(3)
Name	Name of company. Type: Varchar2(40)
IsVirtual	Indicates whether or not company is virtual or not Type: Number(10) 0:            Real company 1:            Virtual company.
AlwaysNative	Indicates whether or not data from company is stored in native files. Type: Number(10) 0:            Stored in database. Always the case when running against an Oracle database. 1:            Stored in native files.

 

DATABASELOG (TableId = 65508)

This table contains data about which tables and events to log. The events are logged in the Axapta table SysDatabaseLog.

 

DOMAININFO (TableId =  65510)

This table contains data about domains.

 

PRINTJOBHEADER (TableId = 65525)

This table is used in connection with printing from Axapta.

 

PRINTJOBPAGES (TableId = 65524)

This table is used in connection with printing from Axapta.

 

SQLDESCRIBE (TableId = 65527)

This table is used temporarily during check / synchronisation process and should normally be empty.

 

SQLDICTIONARY (TableId = 65518)

This table contains data dictionary data about Axapta application and system tables (except SqlSystemVariables) as stored in Axapta data dictionary. Content of this table can be viewed by the form “SysSqlDictionary”

 

Column

Description

TableId

TableId of table. Type: Number(10) Value: 1 – n 1 – 7999           Standard SYS layer. 8001 – 15999  GLS layer 16001 – 17999 DIS layer 18001 – 19999 LOS layer 20001 – 29999 BUS layer 30001 – 39999 VAR layer 40001 – 49999 CUS layer 50001 – 59999 USR layer 65513 – n:    System tables   When an object is initially created, Axapta automatically manages ids and assigns a new id according to the above table. Note, though, that when you modify an existing object, the object keeps its original id and is not assigned a new id in your layer.

 

FieldId	FieldId of field. Type: Number(10) Value: 1 – n 1 – 7999           Standard SYS layer. 8001 – 15999  GLS layer 16001 – 17999 DIS layer 18001 – 19999 LOS layer 20001 – 29999 BUS layer 30001 – 39999 VAR layer 40001 – 49999 CUS layer 50001 – 59999 USR layer 61440:             ModifiedDate 61441:             ModifiedTime 61442:             ModifiedBy 61443:             ModifiedTransactionId 61444:             CreatedDate 61445:             CreatedTime 61446:             CreatedBy 61446:             CreatedTransacrionId 61448:             DataAreaId 65534:             RecId 65513 – n:    System fields
Array	Number of array elements in field Type: Number(10) Value: 0 – n 0:                 Table description entry 1:                 Field is a normal field > 1:          Field is a array field
Name	Axapta name of object (table / field) Type: Varchar2(40)
SqlName	SQL name of object (table / field) Type: Varchar2(40)

 

FieldType	Type of field. Type: Number(10) Value: 0:            String, Table entry 1:            Integer, Time 2:            Real 3:            Date 4:            Enum 7:            Container 8:            MemoString
StrSize	Size of string. Only relevant for STR fields. Type: Number(10) Value: 0 – 1000 0:            Non Str field n:            Str field
Shadow	Not in use. Type: Number(10) Value: 0
RightJustify	Is field right justified? Only relevant for STR fields. Type: Number(10) Value: 0:            Field is left justified or field type not STR 1:            Field is right justified.
Nullable	Is NULL allowed for field at the Oracle database. Type: Number(10) Value: 0:            NULL value not allowed. 1:            NULL value allowed. Only container and Memo string.
Flags	Flag field. Currently only used for STR fields. Type: Number(10) Value: 1,2 1 (Bit 0 = 1):     Field is DataAreaId 2 (Bit 1 = 1):     Field is ordinary STR field

 

 

SQLPARAMETERS (TableId = 65517)

This table is for future use.

 

SQLSTATISTICS (TableId = 65513)

This table is for future use. It is planned to store Axapta specific statistic data, which can help the kernel to optimize the parse, bind, execute and fetch operations.

 

 

SQLSTORAGE (TableId = 65515)

This table contains Oracle storage parameters as specified in Axapta “Storage Setup” utility. The value are added to the CREATE statement, whenever a database object is created from Axapta.

 

Column	Description
Id	Id of storage paramter entry. Type: Number(10) Value: 0,1 0:            Entry for a specific storage parameter. Used for display purposes. 1:            Entry contains all storage parameter for the object. Used for generating CREATE statements.
ObjectType	Type of Object. Type: Number(10) Value: 0,1 0:            Table 1:            Index
TableId	TableId of table to which the object is related. Type: Number(10) Value: 0 – 65512 0:            Default for object of ObjectType n:            TableId
IndexId	Index number for table with TableId. Type: Number(10) Value: 0 – n 0:            If ObjectType = 0 or TableId = 0 n:            If ObjectType = 1 and TableId <> 0 65535 : Index RecId
OverRide	Not used. Type: Number(10)

 

Parm

Name of storage parameter. Type: Varchar2(25) Value: Null:              Id = 1 Tablespace:   Id = 0 and Tablespace specified Initial:           Id = 0 and Initial specified Next:              Id = 0 and Next specified Minextents:   Id = 0 and Minextents specified Pctincrease:  Id = 0 and Pctincrease specified Initrans:          Id = 0 and Initrans specified Maxtrans:          Id = 0 and Maxtrans specified Pctfree:           Id = 0 and Pctfree specified Pctused:           Id = 0 and Pctused specified

Value

Value of entry for the specified object. Type: Varchar2(255)

 

 

SQLSYSTEMVARIABLES

The SQLSystemVariables table is not viewable from with Axapta; however, you can look at the contents by looking at the Database Information form.
SYSCONFIG (TableId = 65514)

This table contains license information, version, feature key setup and other basic system configuration data.

 

Column	Description
ConfigType	Type of configuration information. Type: Number(10) Value: 0 – 4 0:            License Name 1:            License Serial number 2:            Module license code 3:            Feature key info 4:            Service Pack Info 5:            ???
Id	Specific configuration information of give type. Type: Number(10) Value: Dependent of ConfigType 0:            License Name               Always 0 1:            License Serial number               Always 0 2:            Module license code               License code entry number 3:            Feature key info               Feature key entry number, which is not activated. 4:            Service Pack Info               1 = Current Service Pack               > 1 = Used to control the upgrade process
Value	Value of given configuration information. Type: Varchar2(40)

 

SYSLASTVALUE (TableId = 65528)

This table is used to store set values for specific program elements for individual users, which should survive from session to session.  This table is used by both the kernel and the application.

 

Column	Description
UserId	Name of Axapta user for which this set up is stored. Type: Varchar2(5)
RecordType	Type of record Type: Number(10) Value: ?????
ElementName	Name of program element. Type: Varchar2(40)
DesignName	Design name of program element. Type: Varchar2(40)
IsKernel	Is set up kernel or application specific. Type: Number(10) Value: 0,1 0:            No 1:            Yes
Value	Value of the stored setup. Type: BLOB

 

SYSTEMRECORDLEVELSECURITY (New for version 3.0)

This table contains info about record level security based on table, user and company. The stored information is the extra where condition for the table.

SYSSEMAPHORE

This is a virtual system table that is created and maintained by the kernel. The table can’t be found on the database; however, it contains data about all kernel semaphores

SYSTEMSEQUENCES (TableId = 65516)

This table contains sequence numbers for RecId and TransactionId. A row for each used company and sequence.

 

Column	Description
Id	Type of sequence. Type: Number(10) Value: -1, -2 -1:           RecId sequence -2:           TransactionId sequence
NextVal	Next sequence number (value) to be drawn from the sequence. Type: Number(10) Value:                                 Before version 2.5              : 1..2147483647                                 From version 2.5                 : 1..2147483647, -2147483647..-1 From version 2.5 the next value for the sequence is wrapped around at value 2147483647 to –2147483647 For RecId sequences this value is updated by 25 for each drawing of a new number by the Axapta kernel. For TransactionId sequences this value is updated by 20 for each drawing of a new number by the Axapta kernel.
MinVal	Minimum value of sequence Type: Number(10) Value: 1
MaxVal	Maximum value of sequence Type: Number(10) Value:               Before version 2.5 : 2147483647               From version 2.5         : -1

 

Cycle	Can the sequence loop around (cycle) Type: Number(10) Value: 0, 1 0:            No 1:            Yes
Name	Name of sequence Type: Varchar2(20) Value: RECID:             RecId sequence TRANSID:      TransactionId sequence
DataAreaId	Company for which the sequence is defined Type: Varchar2(3) Value: DAT:          Used for DAT company and system tables xxx:          All other companies including virtual companies.

 

 

TABLECOLLECTIONLIST (TableId = 65532)

This table contains data about relation between virtual companies and table collections

 

Column	Description
VirtualCollectionArea	Id of virtual company. Type: Varchar2(3)
TableCollection	Name of table collection attached to the virtual company. Type: Varchar2(40)

 

USERGROUPINFO (TableId = 65530)

Table contains name for the defined user groups

 

Column	Description
Id	Id  of user group. Type: Varchar2(5)
Name	Name of user group. Type: Varchar2(45)

 

USERGROUPLIST (TableId = 65529)

Table describes relation between users and user groups.

 

Column	Description
UserId	Id  of Axapta user Type: Varchar2(5)
GroupId	Id of group. Type: Varchar2(5)

 

 

USERINFO ((TableId = 65531)

Table is used to store general set up values for individual users. Use the “Tool/Options..” menu-item  to change values in this table. If “UserInfo” is empty or entry for current user doesn’t exists, then no menu item or toolbar is available from Axapta. 

 

UTIL*  (UTILAPPLHELP, UTILCODEDOC,  UTILELEMENTS,  UTILELEMENTSOLD,  UTILIDELEMENTS, UTILIDELEMENTSOLD, UTILLOCKS)

These are all virtual tables containing info about programming elements.

 

VIRTUALDATAAREALIST (TableId = 65534)

This table contains data about relation between real companies and virtual companies.

 

Column	Description
Id	Id of company. Type: Varchar2(3)
VirtualDataArea	Id of virtual company. Type: Varchar2(3)

Buenas, pues todo el mundo sabe lo que es un cluster de maquinas no??,  el que no se pede pasar por la wiki y luego seguimos.

Total  Ax (axapta 3.0) permite instalar un balanceador de conexiones entre dos o mas AOS, para que sirve esto, pues más bien para no mucho, el concepto es que el dependiendo del número de usuario que se han conectado a un u otro AOS este cluster distribuye la conexión entrante para mantener un numero homogéneo de conexiones. 

Nada de  transacciones o de carga de procesos, simple y “molt macu” para vender un poco de tecno-logia al puro estilo de las modas de internet. Seguro que en un par de meses se les ocurre algo para dual core.. jajjajaa..

Para terminar un copy paste de como se instala y se configura.. Perdon por los derechos de autor.. jejjeje

Axapta Object Server cluster

The Axapta Object Server cluster environment is build to provide load balancing and fall back. An Axapta Object Server can be specified to belong to a specific cluster. If the same cluster name is given for a number of object servers they all belong to the same cluster. A user can be specified to connect to a given cluster.

Suppose a number of servers are set up in the same cluster – named AOSC. They should all use the same application and database, and in other aspects have the same settings. All clients connecting to the AOSC should be specified to search for servers belonging to this cluster, otherwise the load balancing mechanism will not work properly. A client starting up against an Axapta Object Server Cluster will start out by broadcasting an UDP package requesting Axapta Object Servers fulfilling names and IP server masks given in the client settings to respond. It is therefore vital that firewalls allows such packages to pass through. The client will receive answers from all Object Servers with information on object server name and the name of the instance plus the number of clients connected to that instance. The client disregard information from servers not belonging to the requested cluster. The client then chooses one of the instances with the lowest number of clients.

Since a client automatically can choose from all servers in a cluster one or more Object Servers can be down with out changing the connection procedures. However performance might suffer severely due to higher load on the fewer servers.

Setting up the server

On the server manager select the server of interest and click settings. In the advanced field write -cluster=<my cluster name>. The cluster name can be up to 10 characters long.

Setting up the client

In the configuration tool choose the configuration of interest. In the advanced field write -cluster=<my cluster name>. The client setting for connecting to an object server depends on two situations. The first situation being both client and Axapta Object Servers being in the same subnet. The second being client and Axapta Object Servers belong to different subnets.

Recall the settings in the configuration utility for connecting to an object server:

- Axapta Object Server Mask
- Axapta Object Server host names
- Axapta Object Server IP Address masks

When the client and Object Servers belong to the same subnet the above three masks can be left blank.

When the client and Object Servers belong to different subnets the IP Address masks should contain the mask for the subnet the Object Servers belong to. An example could be 192.88.253.255, where the last 255 specifies that the search is done among servers in the subnet 192.88.253.*.

Note – if client at any time receives only service response from Object Servers within the same cluster it will automatically choose the least loaded of these servers without having to specify the cluster name in the client configuration. This means that if your installation is one single Axapta cluster, there is no need to change the existing configuration with respect to cluster name. Ensure that all relevant Object Servers are located by client configurations network set up.

Args  es utiliza para pasar argumentos al constructor de una clase. Args pueden transmitir información como el nombre, y los parámetros que llaman a una nueva clase.

Los formularios, informes y consultas utilizan  la clase Args como primer argumento en el constructor.

Pasandole el nombre del objeto a crear a una clase args y despues llamar a classfactory con estos argumentos podemos inicializar fomularios, informes etc.

    Args a = new Args(“CustTable”);
    formRun fr = ClassFactory.FormRunClass(a);
    fr.init();
    fr.run();
 

para recuperar el objeto args en la clase de destino, por regla general existe un metodo que nos devuelve este dato.

elment.args() en el caso de formulario.

El objetivo de esto es poder pasar a traves de args objetos completos a otros contextos de ejecución de forma que podriamos abrir un formulario inicial F1 ejecutar otro formulario secundario F2 y poder ejecutar metodos del formulario 1 desde el formulario 2.

un ejemplo.

Hemos creado un from con un metodo para recuperar el texto de un strignedit y este texto lo vamos a pintar desde un report, utilizando para ello una clase intermedia o el metodo del form que lo ha llamado.

fir_dem.xpo 

public void init()
{
    object ob;
    FIR_ReportClas FIR_ReportClas;

    super();

    //axl si no es la clase entonces es el formmm…
    if (classIdGet(element.args().caller()) == classNum(FIR_ReportClas))
    {
            FIR_ReportClas = element.args().caller();
            print FIR_ReportClas.texto();
    }
    else
    {
        ob = element.args().caller();
        print ob.texto();
    }

Desde este blog apostamos más por la utilidad y el buen hacer que por las facturas que van a cobrar las consultoras en ventas de productos Microsoft. Hemos de reconocer que AX es un buen producto como “erp” que ya se ha asentado en nuestro país y que día a día es una solución tanto para la pequeña como media empresa. A la hora de implantar un Ax normalmente los que deciden que base de datos o plataforma se va a utilizar, suelen ser los comerciales que le venden la moto al pobre cliente que no sabe realmente que necesita ya  que no tiene experiencia sobre en el tema. Aprovechando esta carencia algún que otro desalmado le coloca un sql Server solo para sacarse unas perrillas de más y de paso subir un par de puntos en el ranking de “Partners“, o tal vez por puro desconocimiento o falta de profesionalidad. Para nosotros y con la experiencia adquirida desde la versión 2.1,  desde antes del año 2000 recomendamos “oracle” para las instalaciones que requieran un volumen de movimientos  grande. Bases de datos que vayan a superar los 30 o 50 GB no en su instalación base, sino en el crecimiento que sufrirá tras su puesta en producción. A lo que vamos. La instalación de AX 4.0 es muy sencilla y solamente necesitamos una maquina 2003 server r2 actualizada y una base de datos en este caso oracle Express que aun con una limitación de 4 GB  nos servirá de ejemplo. http://www.oracle.com/technology/software/products/database/xe/index.htmlTras instalar oracle Express que no es muy difícil continuaremos con la de AX 4.0, uno de los pasos en la instalación es la elección de la base de datos, en este instante nos solicitara una serie de datos, el listener, el puerto tcp o el usuario y la contraseña de la base de datos. Ax necesita que la autentificación de base de datos la realice el sistema operativo. Para conseguir esto solo necesitamos cambiar el parámetro de XE

os_authent_prefix  

Con un prefijo tipo ‘ops$’ nos sevira,  de manera que oracle sepa identificar si el usuario del SO que solicita la conexión esta creado en oracle autorizando el acceso.  Crearemos un usuario  en oracle como este:

-- Windows

CREATE USER "OPS$DOMINIO.COM\DBO" IDENTIFIED EXTERNALLY;

GRANT CONNECT TO "OPS$DOMINIO.COM\DBO";

Crearemos un usuario en nuestro dominio en este caso DBO .Oracle –> OPS$dominio\DBOWin –> DBOY podremos finalizar la instalación.Ni que decir tiene que debemos crear un tablespace de datos otro de indices etc. (Vamos lo típico en estos casos).http://www.oracle-base.com/articles/misc/OsAuthentication.php Para finalizar recomendaros que ORACLE + SUSE Linux  + AX es la mejor combinación para un optimo rendimiento de la instalación y evitar los sustos que nos dará Microsoft con el día a día que ya sabemos todos.  Un saludo.

A mi me cuesta mucho entender el modelo de seguridad de AX, pero menos mal que tenia por hay un documento de M$ que vamos a pegar integro por si a alguien le sirve pa algo…

Configuration and security in Navision Axapta

This technical information paper will go through the concept of the configuration and security system introduced in version 3.0 of Navision Axapta.

Introduction

With version 3.0 of Navision Axapta the Configuration and Security system is introduced. This system is an extension of the feature key system that has existed since the first version of Axapta.

This paper is an introduction to the concept and ideas behind the new system. The paper will not deal with the technical aspects of how to create configuration and security keys and connect these to application objects. These issues are covered in the Navision Axapta Developer’s Guide, which is available from the Help menu in the toolbar.

For help on specific forms in Navision Axapta, please consult the online help.

Configuration and security key concept

The new security system was created to make the system more intuitive and flexible, and easier for the administrator to set up. The feature keys are replaced by two types of keys: configuration and security keys. This means, that the double-function the feature keys previously had, is now replaced by two types of keys each having one function.

The standard version 2.5 of Navision Axapta had more than 1,000 feature keys. The new system will only have few, but well-defined keys. To maintain the flexibility, security can now be set up on each menu item.

License codes

The license code concept has not changed on the interface with version 3.0. The setup form still looks the same, and license information can be entered manually or loaded from the license file. But license codes are now defined in the AOT. The specific codes, however, are still requested at, and generated by Navision.

Configuration keys

Configuration keys are used to disable or enable functionality and, according to the name, used for configuration of your system. Configuration keys are present everywhere in the AOT like the feature keys were present.

When buying license codes and entering these in the system, you perform the first steps of the configuration. A more detailed configuration is done from the Administration menu; click Setup, then System and double-click Configuration. In most cases license codes control the configuration keys, therefore it is not possible, and would not make sense, to disable a configuration key. A configuration key, however, can control a number of child configuration keys, and they can be either disabled or enabled as required. An example could be a company buying the Trade module license code; the company wants most of the functionality in this module, but does not do business with other countries, and chooses therefore to disable the Foreign trade configuration key. This can all be controlled from the Configuration form.

A minimized system

Having loaded the license code file, the system will start up minimized. This means that all child configuration keys are disabled. Any required extra features can safely be enabled later. A specific setup can still be exported and imported, or, if necessary reset to standard, which is the minimized system. The minimized system will not be used during an upgrade.

Security keys

Having set up the configuration keys, security must be considered. Security keys are used to control access to functionality for users. The security keys are used almost everywhere the feature keys were, except for indexes, fields and types:

• Indexes – the performance of indexes must be available for all users, just as in version 2.5.

• Fields – security on fields must be set up from the User group permissions form, under the table they belong to.

• Types – security can only be applied to fields, making the concept of indirect access obsolete.

Security keys control access to menu items and tables, and setup is done from the Administration menu, click Setup, then Security, and User group permissions. Access for menu items and tables can be set to:

• No access,

• View,

• Edit,

• Create, and

• Full control.

   

The figures (2 and 3) below illustrate the hierarchy of the configuration and security keys.

Key hierarchy

Fig 3.: (C) = Configuration key, (S) = Security key, (MI) = Menu item, and (T) = Table.

 

Figure 3 illustrates how security keys control menu item and table access, and how the Ledger configuration key controls the Cust security key.

For each module, a set of 9 security keys exists, they all have the same naming, and the prefixes denote the module. For the Accounts Receivable module the security keys are:

• Cust

• CustDaily,

• CustJournals,

• CustInquiries,

• CustReports,

• CustPeriodic,

• CustSetup,

• CustMisc, and

• CustTables.

  The security key structure resembles the Main menu structure. To make setup easier, drill-down of menu items is possible. A drill-down will display the tables, form controls and other menu items that are accessible from the menu item.

Record level security

Another new feature for version 3.0 is the Record level security system. It can be used in addition to the other permissions setup in Navision Axapta. For each combination of company, user group, and table a query can be set up, limiting data access for the specific combination. Specify, for example, that a certain user group within a company only has access to see customer numbers from 1000 to 4999. Row level security is set up from the Administration menu, under Setup, then Security, and Record level security.

Read more about Record level security in the online help.

Forms’ setup

In previous versions, an extension of the security access was to set up access to fields etc. on specific forms. The setup was done from each specific form for the user group. With version 3.0, the same functionality is available, but it is handled differently. Granting access to form controls is done from the User group permissions form. In the tree, each control for a specific form, this being a field, a button or a display field can be set to the appropriate access level.

Comparison

For the user coming from an Axapta version 2.5, the changes may not seem very overwhelming on the interface. The main difference between the old and the revised system is the split-up into two different types of keys. This means that it is more obvious to the user what keys are used for what purpose.

Another difference is, that indirect access no longer exists. Indirect access was introduced to allow related fields to be shown in the related table in order to, for example, show the Item number on a Sales Order. Since it is no longer possible to set security on types, the Item number field will not be removed, and the indirect access is not necessary. To remove the Item number field from the Sales Order, use table access on the sales order table and item number field.

The following table illustrates the Feature key system versus the Configuration system:

 

Functionality	2.5	3.0
License codes	Used for registering license information. Codes are requested at Navision.  License codes are defined in the kernel.	Used for registering license information. Codes are requested at Navision.  License codes are defined in the AOT.
Configuration keys	 Did not exist as a separate type of key. The function lied in Feature keys.	 Are used for enabling/disabling functionality.
Security keys	 Did not exist as a separate type of key. The function lied in Feature keys.	 Are used for assigning access to user groups.
Users	Users are created, and permissions are assigned to User groups. A user must be member of at least one User group.	Users are created, and permissions are assigned to User groups. A user must be member of at least one User group.
User groups	Permissions are assigned to User groups. A User group can belong to one or more Domain(s), and can have different permissions assigned through the Domain.	Permissions are assigned to User groups. A User group can belong to one or more Domain(s), and can have different permissions assigned through the Domain.
Companies	A company can be connected to one or more Domain(s).	A company can be connected to one or more Domain(s).
Domains	A domain is a collection of one or more company accounts. The purpose of domains is to enable user groups to have some permissions within a number of company accounts, and other permissions within other company accounts.	A domain is a collection of one or more company accounts. The purpose of domains is to enable user groups to have some permissions within a number of company accounts, and other permissions within other company accounts.
User group permissions	User group permissions are assigned for a user group within a certain domain. The same user group can have different permissions assigned within each domain.  Feature keys controlled the access rights for user groups to features, menus and tables.	User group permissions are assigned for a user group within a certain domain. The same user group can have different permissions assigned within each domain.  Security keys control the access for user groups. Each module is divided into 8 categories, resembling the Main menu structure: Daily, Journals, Inquiries, Reports, Periodic, Setup, Miscellaneous, and Tables.  The indirect access concept has disappeared. Access is set up on security keys, menu items, tables, fields, and form controls.
Record Level Security	 Did not exist.	 Record level security allows setup of data limitations for a certain combination of Company/User group/Table. It extends the User group permissions setup.
Forms’ setup	 Setup for the specific controls on a form, saved per User group and Domain.	 No longer exists as a separate form. Setting form control access is done from the User group permissions form per User group and Domain.
Table access	 A separate system to limit access to confidential tables and fields by overruling the feature keys.	 No longer exists as a separate system. Security is set up from the security tree, see Example on page 7.

Syslastvalue es una tabla de sistema que contiene información desde las configuraciones de formularios hasta las consultas utilizadas en informes o clases.

Un ejemplo sencillo seria este.

La clase PurchFormLetter_Invoice contiene en su definicion de clase una macro con los siguientes valores:

    #define.CurrentVersion(8)
    #LOCALMACRO.ParmList
        parmId,
        purchParmUpdate,
        QueryCriteria,
        Editing,
        Printout,
        PrintFormletter,
        PrinterSettingsFormLetter,
        printEuVatInvoice,
        printerSettingsEuVatInvoice,
        printPromissoryNote,
        printerSettingsPromissoryNote
    #ENDMACRO

Cuando se ejecute este clase, se intentaran recuperar los valores desde el metodo unpack . Utilizando el siguiente formato [version, #ParmList]        = packedClass;

Version nos da la posibilidad de discriminar y evitar errores al descomprimir los datos almacenados y a su vez evita que al devolver los datos comprimidos no se solapen datos numericos con datos alfabeticos etc. y se produzca el famoso AXAPTA CRASH LOG …(quien no recuerda el error de datos decimales jejejje mch1202 jajaj)

Para evitar esto sin cambiar de version se suelen borrar todos los datos referentes al codigo de la clase o report de las syslastvalue, esta tarea se puede realizar desde la propia tabla o desde la opcion “herramientas – > opciones -> datos de uso” (SysUserSetup -> SysLastValue)