In your case, you have to KILL the underlying globals manually.
As seen in Storage definition

eg. <Global>^SVK</Global>  and all others too that you didn't publish

What I've seen so far DDL enabling might not fit your expectations because of that ancient mapping.
(looks like late 80ties or before) 

Well the code you posted shows a rather ancient type of table mapping away from standards.

And the errors you got underlines this as standard methods like %BuildIndices and %PurgeiIndices are not implemented.

I see 3 possible options:
- you find in the code (not necessarily in the class definition) some method to (re) generate the indices. 
Without experience with Caché and Object Script a rather impossible task.

- you create a copy of the class definition and move all data there by INSERT INTO new.table SELECT * from old.table
but it is unclear from what you showed to us if INSERT into your table is supported at all 

- least risky. you out-comment all broken indices except [IDKEY] and just use a flat table scan.
this is a fast workaround at the price of a poor performance on bigger tables.

honestly. - not a funny situation
 

You gave the answer already!

By compilation, you DEFINE indexes at their rules.

But you need to generate their content separately by ClassMethod 

 in each class.

Or from management portal. 

Then they are ready to use.

There is another way directly with SQL 

First, you CREATE a temporary table according to your needs (or have it ready)

CREATE GLOBAL TEMPORARY TABLE MyTemp.Table temp1, temp2, . . . . .

Next, you fill it by INSERT directly from SELECT

The select is the same as before.

give your anchor tag an ID and modify it using some JS script.

or use %ZEN.Auxiliary.locatorLink or any other element that allows a  HREF.

or trigger it with JS from any onclick event or similar. 

It's not much ZEN but pure JS

Francisco,

instead of FOR EACH which obviously uses a nonexisting   Next method
you could create a loop using <WHILE> and do a "manual" loop.

For the condition   source.retorno.datos.polizas.poliza.%Size() gives you the  index limit

and source.retorno.datos.polizas.poliza.%Get(idx).sucursal   .... and similar provides the content. 

You have to increment idx manually and it runs from 0 (zero!) to %Size()-1

It's not as elegant as <foreach> but you have control over your JSON input.

You can get the pid without iteration.

|nsp| is only required for access to a lock in a different namespace.

as you describe if you refer to a file outside Caché and Caché has no control over it
it's a clear case of data inconsistency

you have 4 options:
1a) create a fake file at that reference an delete it then

1b) add an "on before delete" trigger to check and fix in advance either in the record or  in file system 

2a) manipulate the file reference using the object behind your entry

2b) do the delete at object level, trap the error and ignore it. since the file is gone anyway 

when you generate Classes from XSD you require a reference. That' s where xsd is stored.  It may make sense to ich copy it first to your default repository and generate your classes after.

In fact, I see not 1 but 2 tables that share the same global.

so it might be easier to have 2 separated definitions one with and the other without the  4th subscript (some $h)

for access with SQL you than can use a UNION to assemble them. like:

or  you decide to add the missing subscript in your global to have a common structure

If this is Caché standard ID it is projected to SQL as xDBC Type INTEGER
Caché SQL Reference - Data Types says:

so 5983658923646 is definitely out of range

xDBC Type :

   represents a 64 bit integer value.

I'm not aware of any parameter to change the data type of the generated ID.
But this hack may do the trick. Just add this calculated Property to your class without affecting the storage.

Property myID As %BigInt [ Calculated, SqlComputeCode = { set {*}=%ID}, SqlComputed ];
 

At first sight in Documatic, it  looks like 

 was just renamed to  

%Storage.Persistent

As a workaround, I would simply try in Caché to make a copy of  %Library.CacheStorage to a new %Storage.Persistent
(a pure rename)  Then compile a class with one and the other and compare the generated .int code.

It's a dirty hack. 
But I have no hope ISC will ever provide some backward port from IRIS to Caché.

Sorry I have no IRIS at hands and can't try it myself.