Erro apos copia PI/GRC

Boa tarde pessoal,
Fiz uma copia de um ambiente PI/GRC, e estou com problemas na parte Java, fiz o pos instalation do help.sap, e mesmo assim não funciona, não aparecem erros no dev_server0 e nem std_server.out, mas quando tento logar no sld não acontece nada.
Alguem sabe o que pode ser?

Rodei novamente com o seguinte resultado:
0: gowsap21_GD2_03                           : Execução programa: SLDMSGSRV
0: gowsap21_GD2_03                           : Execução programa: SLDLIVECACHE
0: gowsap21_GD2_03                           : Execução programa: SLDIPSERV
0: gowsap21_GD2_03                           : Execução programa: SLDINSTSP
0: gowsap21_GD2_03                           : Execução programa: SLDINSTSC
0: gowsap21_GD2_03                           : Execução programa: SLDINSTPRD
0: gowsap21_GD2_03                           : Execução programa: SLDGWSRV
0: gowsap21_GD2_03                           : Execução programa: SLDDBSYS
0: gowsap21_GD2_03                           : Execução programa: SLDCOMPSYS
0: gowsap21_GD2_03                           : Execução programa: SLDCLIENT
0: gowsap21_GD2_03                           : Execução programa: SLDBCSYS
0: gowsap21_GD2_03                           : Execução programa: SLDAPPL_SERV
0: gowsap21_GD2_03                           : Fim da coleta de dados SLD.
0: gowsap21_GD2_03                           : Coleta de dados efetuada com êxito.
0: gowsap21_GD2_03                           : Dados RFC foram editados.
0: gowsap21_GD2_03                           : Destino RFC utilizado: SLD_UC
0: gowsap21_GD2_03                           : Chamada RFC sem êxito: Error when opening an RFC connection
0: gowsap21_GD2_03                           : Jobs periódicos existentes eliminados. Nº: 1
0: gowsap21_GD2_03                           : Programa escalonado: 20100811 043500.
1: gowsap21_GD2_03                           : Job controlado por eventos já existe. Escalonamento não necessário.

Similar Messages

Error during client copy in GRC 10.0 -Application exit

Hello Experts,
After installing GRC 10.0,as post installation activity ,
we are doing client copy (accordence with the sap note 1505255).
but we are getting 'Application Exit Error' when executing method FDT_BEFORE_EXPORT_C:
any help would be appreciated.
regards,
vinay singh

HI
Can you attach client copy log for analysis.
Regards
Rajan Arora

APO Copy/Version Management

Hi,
We need to copy a quarterly key figure from one planning area to a monthly key figure in another planning area. We have a Z table that holds the Characteristic Value Combinations (CVCs) and percentages to allocate to each month per quarter. Program /SAPAPO/RTSCOPY does the copy, but allocates the qrtly kf evenly to the monthly kf.
I've looked for a userexit in /SAPAPO/TSCOPY but did not find one.
Does anyone know how we can utilize the Z table to allocate the qrtly kf data to the monthly kf data based upon the CVCs and percentages in the Z table?
Regards,
Jim

It was a back up POS so we could make changes to our main POS without losing any of our livecache data.
We did manage to resolve this problem. In the copy set up we have ticked ignore zero values to speed up the transfer. But believe there was some data that wasn't being over written.
So, we deleted the time series of the target POS to make sure there was no data in there to start with.
And I wouldn't recommend transfer any KF with planning area calculation setting as "A". It didn't really seem to balance and as we had little data in this KF we could manage this manually.
Hopefully this little insight will help other users.

Erro tablespace no GRC, notas paradas após correção

Olá pessoal,
Hoje de madrugada houve um problema de tablespace no GRC e todas as notas emitidas durante o período, ficaram paradas com Status 01 (Received from feeder system).
Após a correção, as novas notas emitidas foram processadas normalmente porém as anteriores ficaram paradas.
Verifiquei que nesse momento em que ocorreu o problema, as notas que chegaram não foram enviadas para assinatura, occorreu um dump, porém também não temos registro desse erro no monitor do GRC.
Algumas notas criadas inclusive não geraram histórico nas tabelas XNFE, ficando com Status 00 no monitor.
Tentamos re-enviar as notas para verificar se o GRC reprocessava as mesmas, porém também sem sucesso.
Tentamos também forçar um histórico de erro de assinatura na tabela XNFE/BAT_HIST para re-enviar a assinatura, porém no monitor ficou com status "NF-e Data Re-Requested" e não enviou a assinatura.
Alguem já passou por este problema. Existe alguma forma de re-enviar estas mensagens? Ou de eliminar o histórico das mesmas?
Obrigada!
Vanessa

Bom dia Vanessa,
Avalie caso a caso o que aconteceu e faça a intervenção sempre inserindo algum histórico novo ao invés de modificar (rastreabilidade) e coloque no campo de usuário algo como CREEEEU rsss (brincadeira, coloque um usuário ou uma identificação tipo o numero do chamado).
Vamos lá:
- Primeiro verifique no PI se tem alguma fila (SMQ2) que possa ser restartada ou se a mensagem chegou e está scheduled (SXI_MONITOR) com opção de restart. Isso pode diminuir as intervenções manuais necessárias.
- Para as que ficaram paradas como 01 ou 02 ou 00, insira um status novo na nfe_hist 02 / 24 (erro de assinatura) permitirá você fazer o restart no monitor. Ao restart o GRC irá chamar no ERP a função J_1B_NFE_MS_REQUESTS_DATA (veja se SAP Note 1234054)
Atenciosamente, Fernando Da Rö

Erro "B2B: erro de sistema PI"

Olá a todos. Aplicamos a versão 2.0 do GRC, Support Package 15 e após isso, quando uma Nota Fiscal é cancelada, o cliente não recebe o XML desse cancelamento, apresentando um erro no GRC como: B2B: erro de sistema PI. Nessa nova versão esse envio é obrigatório. Alguém já passou por esse erro? Tem alguma idéia do que pode ser?
Obrigado a todos que puderem ajudar
Marcos Cristiano Ickert
Basis

Marcos,
Alem de configurar o Cenário para o novo namespace 006, no Design para o Produto/SWCV usado o B2B você precisa alterar o Interface Mapping(7.0)/Operation Mapping(7.1) de Envio(NTB2B_procNFe_TO_procNFe)/Cancelamento(CTB2B_procCancNFe_TO_procCancNFe) para o namespace 006, assim como já deve estar para a versão 005a.
(isso apenas para os objetos do seu produto/swcv)
OBS.: caso vocês utilizem a solução igual ou parecida com o que Henrique postou no forum.
E caso você precise reiniciar esse erro de B2B no GRC, como você está SPK 15 será necessário aplicar a nota 1512936 para tirar o dump que gera.
Espero que ajude.
Abraço,
Bruno Lima

Erro Lançamento CT-e com CST 60 - Erro M8 534 - Monitor CT-e

Prezados, Boa Noite!
Estamos tentando realizar um lançamento no sistema de um conhecimento de transporte eletrônico CT-e com CST 60 pelo módulo GRC, ao simular esse lançamento encontramos um erro que acreditamos ser um erro de produto.
Abaixo segue TAG do XML.
Fizemos todas às analises e chegamos à conclusão de que no momento em quem o GRC está realizando a simulação do lançamento no ECC o mesmo está passando para a função MRM_INVOICE_CREATE no parâmetro I_RBKPV-RMWWR o valor líquido do conhecimento de transporte, entendemos que nesse campo deveria ser passado o valor total do CT-e e não o valor líquido do mesmo.
A fim de validar se o fato relatado acima é realmente o erro que esta ocorrendo, pegamos os parâmetros que o GRC estava passando para essa função e mudamos apenas o conteúdo no parâmetro I_RBKPV-RMWWR, para que o mesmo assumisse o valor liquido + impostos, ao realizar a mudança desse valor o erro parou de acontecer.
Para validar se o erro estava somente no GRC pegamos o mesmo pedimos e lançamos de forma manual um MIRO no ECC, o lançamento no ECC ocorreu sem nenhum problema o que nos faz acreditar mais ainda que possa ser um erro no produto. Abaixo segue print detalhado do erro que estamos encontrando.
Monitor GRC – CT-e
Observem que na imagem acima do monitor todas as informações relativas à taxa de imposto, Montante do Imposto e Montante Básico estão com os valores idênticos no momento da simulação, no momento que o usuário vai registrar os dados da simulação o sistema dá uma mensagem de erro informando que os valores de débito e crédito não batem, observem no monitor que os valores são os mesmos.
Ao tentar realizar o mesmo lançamento através da transação MIRO no ECC não encontramos nenhum problema os valores são calculados corretamente sem nenhum problema.
Abaixo segue print dos valores que estão chegando da função MRM_INVOICE_CREATE.
Abaixo segue detalhes da configuração do IVA
Já configuramos o IVA com CST1 e CST2 mas nao conseguimos obter sucesso no lançamento pelo GRC

Sim Eduardo,
Finalizado.
Deu trabalho mas ficou muito bom.

Erro Retorno ERP Nota status 10

Bom dia Srs,
Estou com um problema para voltar o status de uma nota para o ERP, a nota tem status 10 erro de validação.
Já tentei algumas coisas:
Verifiquei os jobs esta rodando normalmente, smq2, e monitor enfim tudo em ordem.
Rodei o programa /XNFE/UPDATE_ERP_STATUS_DIAL sem sucesso, pois também não esta na tabela /xnfe/backstatus.
Alterei o status da nota na tabela /XNFE/NFeHist para 24, para rodar novamente na aba de erro de assinatura, mas mesmo assim sem sucesso o status não volta para o ERP, porem essa nota antes estava com status 25 erro de assinatura também.
Meu GRC esta no SP16 SP do PI 23 e SAP_BASIS 24, e vamos subir para o 17, mas creio que isso não vai resolver o problema.
Será que alguém tem mais alguma idéia?
Obrigado
Abs

Fernando, eu já tinha 3 notas neste situação nos testes, agora eu fiz uma simulação desse erro que esta ocorrendo, vou explicar o procedimento:
Eu alterei a senha do J2ee_admin no CC SIG_SOAP_RCV, enviamos uma nota essa nota vai dar erro assinatura , então a mesma fica parada no monitor do GRC com erro de assinatura status u201C25u201D, corrigi o problema da senha do j2ee_admin no CC, após isso reenvie a nota pela aba erro de assinatura , o que acontece a nota cai na mesma situação relatada aqui:
Monitor GRC status u201C10u201D
Monitor SAP ERP
Status da Açao: engrenagem
Log NF-e : Bandeira Vermelha ( com o mesmo log de erro do monitor do GRC)
Status Sist.msgs: status u201CAu201D
Seu tiver 1 mil notas que cair nessa situação de dar erro na assinatura e fazer o reenvio, todas elas vão ficar com esse status nos monitores.
Alguma coisa não esta funcionando como deveria não?
GRC SP17
Será que esta faltando aplicar alguma nota no ECC, acho que não, mas se vê tiver alguma idéia.
Agradeço
Abs

GRC 300 for 10.1

Dear Experts,
Can anyone provide me copy of GRC 300 for 10.1 ?
Thanks
KH

1) Currently there is no version of the GRC300 course that is taught on a 10.1 system.
2) To get access to the material, please book yourself to attend the course at the nearest SAP Education center

Nf-e monitor

Olá,
Na NF-e acompanhar ao enviar NF-e a partir de R / 3 para GRC estamos obtendo validação erro 10. e no log exibir estamos recebendo erros como "Validation Error: Campo nome do país. Este campo não corresponder ao formato esperado. (Campo IS_NFE_HEADER-C1_XPAIS, Campo ID C015)." Há muitos mais semelhantes tipo de erros.
Alguém tem idéia do que estes são do campo id. Qualquer ajuda será arreciated.
obrigado

Bom dia Honey,
Estes três campos devem ser preenchidos pela BADI CL_NFE_PRINT->FILL_HEADER visto que são campos customer sem origem certa no standard.
C1_CNAE - Como incluir o campo CNAE
MODFRETE - Erro de Validação GRC
TPIMP - Erro de Validação GRC
Missing values - SAP Note 1180402
Leia o conteúdo das duas threads acima que serão esclarecedoras para a fase que você está.
Atenciosamente,
Fernando Da Ró

Duplicidade de NF-e

Boa tarde pessoal,
hoje emitimos 2 NFe's no ambiente de DEV no do cliente. As NFe's são:
33100407005330000119550023000004150577201076
33100407005330000119550023000004160209120157
No SAP PI verifiquei que as duas notas foram colocadas no mesmo lote 501.
As duas NFe's foram encaminhadas para a Sefaz e a mesma rejeitou. Segue o XML:
Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e </xMotivo></infProt></protNFe></protNFeStr>
</protNFeString>
</nfeRetRecepcaoResponse>
Posteriormente, executei o botão "Consulta do status" no GRC e recebi o retorno:
<ns2:cStat>562</ns2:cStat>
<ns2:xMotivo>Rejeicao: Codigo Numerico informado na Chave de Acesso difere do Codigo Numerico da NF-e</ns2:xMotivo>
Na transação SNUM, o intervalo de numeração se encontra com valor de 510 e o lote foi gerado com o número 501.
Alguém já viu isso?
A duplicidade de NFe pode estar ligada ao fato de no mesmo lote ter 2 NFe's?
Como faço para ter

Bom dia pessoal,
Este código de status novo é para uma situação antiga que normalmente tinha como resultado um 204 e mesmo o Status Query não resolvia a questão.
Onde é comum: DEV/QAS
Motivo: É comum após refresh ou por não existir na empresa uma separação de numeração entre os ambientes chegar até a Sefaz uma mesma numeração porém com chave diferente (normalmente o aleatório). Neste caso, de fato são notas diferentes, geradas em ambientes diferentes, porém com mesma numeração.
Motivo adicional: Mesmo que você tenha vários ambientes DEV/QAS a Sefaz tem apenas 1 ambiente de homologação, e não faz distinção sobre o seu ambiente.
Solução: Customize sua numeração de forma a não conflitar os ambientes, ex.: DEV client xxx de 1 a 100000, DEV client yyy de 100001 a 200000, QAS clilent bbb de 200001 a 300000... E por aí vai.
Observação: Em caso de refresh de ambiente, fazer um backup antes da numeração atual e reinserí-la antes de liberar o ambiente.
Pode também acontecer em produção, porém é raro e normalmente denota uma falha no momento em que estava sendo criada a nota. Se acontecer a criação/transmissão ao GRC, porém por falha de update o ERP "esqueceu" da numeração aleatória então criará novamente e para o GRC/Sefaz será uma nova nota.
Solução para este caso: Investigação no ERP sobre quais chaves, possíveis erros, investigação no GRC para saber as chaves envolvidas e na Sefaz para saber qual é a que foi autorizada. Por fim, acertar o ambiente na mão conforme o encontrado na Sefaz.
@Bernardo, sim o decouple reduz quase a zero a possibilidade disto acontecer em produção por falhas de sistema.
Atenciosamente, Fernando Da Rós
@Sergio, se sua questão foi respondida ou quando for poderia fechá-la (marcar como respondida). Verifiquei que você tem várias questões abertas e isto confunde o fórum. Total Questions: 82 (47 unresolved)
Edited by: Fernando Ros on Apr 26, 2010 8:20 PM

Problemas de comunicação entre PI e Sefaz SP

Olá,
Nos últimos dias estamos percebendo de 5 a 15 timeouts para os lotes que esperam aprovação NF para a região de São Paulo. O erro que vemos no SXMB_MONI é "com.sap.engine.interfaces.messaging.api.exception.MessagingException: java.net.SocketException: Connection reset" depois de cerca de 2 minutos abertos em uma transação. (Interface de BATCH_nfeAutorizacaoLote_SYNC)
Depois de reiniciar os lotes com erro a partir de GRC, eles são enviados normalmente e temos a aprovação. Esta situação é aceitavel se fosse um problema temporário, mas achamos estranho isto estar acontecendo varias vezes e de forma aleatoria. Isso já aconteceu cinco vezes já hoje. Normalmente não temos estes problemas os quais começaram acontecer recentemente.
Não temos conhecimento de mudanças do nosso lado, isso tem funcionado bastante estável por um longo tempo. Estamos em contato com SEFAZ e eles disseram que o serviço web está funcionando normal.
Todas as idéias ou conselhos são muito bem vindos!
Muito obrigado a todos

Aaron,
isto está acontecendo com diversos contribuintes. Aqui na minha empresa está acontecendo quase todo dia, também de maneira aleatória.
Ao meu ver, a SEFAZ está com um gargalo no processamento das requisições e em determinados momentos, conexões são desconectadas por falta de recursos. Isso se justifica principalmente pelo fato que muitas empresas estão iniciando as emissões da NF-e 3.10 nesses últimos dias, por conta da proximidade com a data de corte da NF-e 2.00.
Sugiro abrir chamado na SEFAZ, apenas como forma de documentar o problema.
[]'s
JN

Lote com status 02 - Enviado ao PI

Boa Tarde,
Estamos com 3 lotes que apresentaram o seguinte Status - 02 Enviado ao PI, e não consigo liberá-los para envio para a SEFAZ.
O erro apresentado no SXI_MONITOR é o seguinte:
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
- 
- <SAP:Error xmlns:SAP="http://sap.com/xi/XI/Message/30" xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/" SOAP:mustUnderstand="">
<SAP:Category>XIProxy</SAP:Category>
<SAP:Code area="ABAP">PARSE_APPLICATION_DATA</SAP:Code>
<SAP:P1>Request Message</SAP:P1>
<SAP:P2>CX_ST_DESERIALIZATION_ERROR</SAP:P2>
<SAP:P3>/1SAI/TXS93D66C51A914A80B8BD3</SAP:P3>
<SAP:P4>XML Bytepos.: 705 XML Path: ns1:nfeRecepcaoLoteResponse(1)ns1:nfeRecepcaoLoteResult(1)ns2:retEnviNFe(1)ns2:xMotivo(4) Error Text: Ocorreu um perda de dados durante a conversão de Rejeição: Erro não catalogado - Could not allocate space for object 'dbo.NFe_Fila'.'PK_NFe_Fila_1' in database 'NFe_In' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additi. Kernel ErrorId: CONVT_DATA_LOSS</SAP:P4>
<SAP:AdditionalText />
<SAP:ApplicationFaultMessage namespace="" />
<SAP:Stack>Fehler bei der Konvertierung XML => ABAP (Request Message; FehlerId: CX_ST_DESERIALIZATION_ERROR; (/1SAI/TXS93D66C51A914A80B8BD3 XML Bytepos.: 705 XML Path: ns1:nfeRecepcaoLoteResponse(1)ns1:nfeRecepcaoLoteResult(1)ns2:retEnviNFe(1)ns2:xMotivo(4) Error Text: Ocorreu um perda de dados durante a conversão de Rejeição: Erro não catalogado - Could not allocate space for object 'dbo.NF ) ) Ocorreu um erro na deserialização em o programa ST /1SAI/TXS93D66C51A914A80B8BD3. Ocorreu um perda de dados durante a conversão de Rejeição: Erro não catalogado - Could not allocate space for object 'dbo.NFe_Fila'.'PK_NFe_Fila_1' in database 'NFe_In' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additi.</SAP:Stack>
<SAP:Retry>M</SAP:Retry>
</SAP:Error>
Mas não consigo reestartar a mensagem.
Alguém saberia como solucionar este problema?
Obrigado
Migdon Silva

Bom dia Migdon,
O erro de banco de dados aconteceu na Sefaz SP no dia de hoje, este erro CX_ST_DESERIALIZATION_ERROR aconteceu no proxy do PI para o ABAP devido à descrição do erro no campo xMotivo excedeu o tamanho máximo definido no esquema XML (255 caracteres).
Como é comum das Secretarias estrapolarem este limite nos erros tipo 999, o GRC foi modificado para truncar este valor e eliminar o problema de proxy através da SAP Note 1319911 (SP09).
Para resolver o incidente, você deverá acrescentar linhas falsas na tabela de histórico de lote (/xnfe/bat_hist), conforme xemplo:
   BATCHID      = <seu lote>
   ERTIME       = <current time stamp with format YYYYMMDDHHMISE,99999>
                      Ex.:20090522160000,9999999 --> um bom valor de ERTIME é
pegar o maior atual para o lote e acrescentar 1 segundo.
   BATSTAT      = 02
   ERROR_STATUS = 01    "General error
Após acrescentar esta linha você pode ir no GRC Web Monitor e fazer o restart do lote, que será enviado normalmente.
Atenciosamente, Fernando Da Rós
Edited by: Fernando Da Ros on May 22, 2009 9:05 PM

B2B - Cliente e Transportadora

Fizemos uma alteração na solução standard do B2B.
Na função que chama o Proxy, eu criei um enhancement-point para manipular o campo CNPJ para identificar qual o tipo de mensagem será enviada, no meu caso EMAIL Ou WebService, até ai OK.
O problema é que assim que manda o XML para o cliente eu estou também mandando para a Transportadora o XML, usando o mesmo Proxy e interface PI, repliquei a lógica standard para o envio para a transportadora. Quando ocorre algum erro no envio por email para o Cliente ou para a Transportadora, ex: email não cadastrado, e para o outro envio vai com sucesso o status no monitor do GRC fica com sucesso e eu não consigo reprocessar a mensagem que deu erro. Se os dois cadastros estão OK, ele manda com sucesso para os dois sem problemas.
Existe a possibilidade de caso der erro em algum, deixar com mensagem de erro no monitor do GRC para ser reprocessado posteriormente? Mesmo que uma das duas mensagens tenha ido com sucesso, melhor mandar duas vezes do que não mandar.
Como o cadastro do cliente é mais dinâmico do que o da transportadora, clientes temos mais de 2.000 e transportadoras 3, pensei em assim que executasse a Proxy da interface para o Cliente, tentar identificar se deu erro no Ack, se deu erro eu nem continuo o processo para a transportadora, porém não consegui identificar no código quando deu erro ou não.
Alguém tem alguma idéia?
Desde já, muito obrigado.

Olá Maicon,
sim, esse report é executado via job (schedulando o /xnfe/process_reports, que chama ele via submit).
Nao vai adiantar vc fazer o =>get_acknowledgement() logo depois de manda pois demora um pouco pra mensagem ser executada pelo Integration Engine, Mapping Runtime, Adapter Engine etc.; até dar o erro, vai ter um deltaT considerável. E fazer um while ack() vazio, wait 5seconds, é sacanagem, eheehehehe.
Por isso sugeri, se quiser modificar, que pense em modificar o proprio form get_acknow, pois ele é executado via job, e uma hora vc pega o ack.
Mas note que não necessariamente vc quer que o usuário restarte o B2B manualmente. Como vc mesmo observou, por ser uma interface ***íncrona, o próprio Adapter Engine faz retries automáticos de envio depois de 5 minutos do ultimo erro. Somente em caso de erro permanente é q faz sentido fazer o restart; esse "erro permante" vc pode observar vendo o status da mensagem no Mesage Monitoring do RWB (componente Adapter Engine). Infelizmente nao sei dizer se esse nível de detalhamento do erro volta no ack que vai pro Integration Engine, se voltasse seria o mundo perfeito, e daí vc poderia fazer um IF status = vai tentar de novo, nao joga erro no monitor (talvez faça sentido um status novo, algo do tipo "erro mas vai retentar enviar sozinho"), else status = erro permanente, daí vc joga erro no monitor pro usuário poder restartar.
Se nao vier no ack, daí vc ainda pode tentar pensar numa maneira de ler isso das tabelas do Adapter Engine, que eu pessoalmente nao manjo mas que deve ter alguma coisa no forum de PI.
Abs,
Henrique.
PS: pensei que seu 1o nome fosse Rosa, rs... Desculpe.

Password self service in AC10

What is the procedure to roll out Password self service in a 1000+ company. Does it means all the backend system users has to be copied to GRC Production system to use this feature.
If the user wants to reset his password, is it necessarily to login with GRC Password first into GRC and than reset the backend password. If this is the case, than there are less chances that users will remember his GRC password to login into it to reset the password.

A user shouldn't need access to the GRC box itself to use PSS.
Look at the PSS configuration under SPRO->GRC->AC->User Provisioning->Maintain PSS
You can set the authentication source for a user attempting to leverage the PSS feature. You can use the Challenge Questions themselves or another HR system. Also, under that same IMG tree, you will also need to ensure your End User Logon URL is activated and setup properly. This would be the URL individuals would use to access the basic AC features (creating requests, PSS, etc) whom do not have AC accounts themselves.
The key design decisions will be where you will be storing a user's challenge questions and how you will ensure they have their answers registered (ideally part of their onboarding) so that they can use the PSS tool.

Erro copia de ambiente PI/GRC

Boa tarde,
Fizemos uma copia de um ambiente GR1 para GR2, e fiz o pos-installation da SAP para Netweaver ABAP+JAVA SR3, ocorre que quando finalizei as configuracoes do GR2, as configuracoes de endereco e porta que eu alterei no GR2 foram alteradas tambem no GR1, resultado, tive que refazer uma serie de configuracoes no ambiente GR1, e de novo alterou tudo no GR2 novamente. O que pode estar causando isso?
Obrigado,
Josue Neto

Oi Luiz
Isso é perfeitamente possível. Você pode ter inumeras empresas e filiais fazendo uso do mesmo ambiente do SAP NF-e e do PI.
Lembre-se que no caso de empresas diferentes você terá dois certificados digitais. Um para cada raiz de CNPJ.
Abraço
Eduardo Chagas

Erro apos copia PI/GRC

Similar Messages

Maybe you are looking for