segunda-feira, 17 de setembro de 2018

Execução de Jobs em segundo plano no SAP

As tarefas em segundo plano no sistema SAP são executadas em segundo plano sem afetar as operações normais no sistema. Esses trabalhos são usados ​​para reduzir o esforço manual e automatizar o processo. Eles podem ser executados em segundo plano sem qualquer entrada do usuário e podem ser programadas para serem executadas quando o carregamento do sistema estiver baixo.
Jobs em segundo plano podem ser divididos em três categorias -

Classe A (alta prioridade)

Isso é usado para tarefas urgentes ou críticas e deve ser agendado como Jobs prioritário de classe A. O Job de Classe A reserva um ou mais processos de trabalho em segundo plano.

Classe B (Prioridade Média)

Esses Jobs são executados após a conclusão de trabalhos de alta prioridade da Classe A.

Classe C (baixa prioridade)

Os Jobs nessa categoria são executados depois que as tarefas de classe A e de classe B são concluídas.

Determinação de Preço



Ir para o final dos metadados
1.       O sistema determina o esquema de cálculo de acordo com as informações definidas no tipo de documento de vendas e no registro mestre de cliente;
2.       O esquema de cálculo de preços define os tipos de condição válidos e a seqüência em que aparecem na ordem do cliente. No exemplo, a partir do primeiro tipo de condição (PR00) no esquema de cálculo, o sistema começa a pesquisa por um registro de condição válido
3.       Cada tipo de condição do esquema de cálculo pode ter uma seqüência de acesso atribuída a ele. Nesse caso, o sistema utiliza a seqüência de acesso PR00. O sistema verifica os acessos até encontrar um registro de condição válido. (Embora isso não possa ser visto no diagrama, cada acesso define uma tabela de condições específica. A tabela fornece a chave com que o sistema pesquisa os registros).
4.       No exemplo, o primeiro acesso (a pesquisa de um preço de material específico de cliente) não é bem-sucedido. O sistema passa para o acesso seguinte e encontra um registro válido.
5.       O sistema determina o preço de acordo com as informações gravadas no registro de condição. Se existir uma escala de preços, o sistema calcula o preço adequado. No exemplo, o item de ordem do cliente pede 120 unidades do material. Ao utilizar o preço de escala que se aplica a quantidades de 100 unidades ou mais, o sistema determina um preço de US$ 99 por unidade.

 TIPOS DE CONDIÇÕES

 São representações de determinados cálculos ou determinações de acordo com necessidades do usuário.
É possível definir um tipo de condição específico para cada tipo de preço, dedução ou sobretaxa ocorrido nas transações comerciais.
Pode-se, também, definir que determinadas condições sejam determinadas automaticamente e que outras sejam fornecidas manualmente ou, ainda, definir que as mesmas serão calculadas a partir de fórmulas próprias.
Exemplo :
O usuário deseja que o sistema calcule um percentual de dedução com base nas quantidades solicitadas pelo cliente  (por exemplo, uma dedução de 1% a partir de 100 unidades de venda).
Também é possível determinar que o sistema calcule a dedução com base no peso total (bruto) da mercadoria sendo adquirida (por exemplo: uma dedução de US$ 0,20 por kg, a partir de cada 100 quilos adquiridos).
Para se utilizar as duas possibilidades, é preciso definir dois tipos diferentes de condição

TABELAS DE CONDIÇÕES

 Definem a combinação de campos (as chaves) que identificam um registro de condição individual.
Um registro de condição consiste na maneira como o sistema grava os dados de condição específicos entrados no sistema como registros de condição.
Uma tabela é criada a partir de uma lista de campos (catálogo) que é parametrizável, ou seja, pode-se inserir nas estruturas do catálogo de campos quaisquer campos que sejam necessários para a determinação de preços.
Note que nem todos os campos que podem ser selecionados conterão valores no momento da determinação de preço. Veremos como "driblar" este problema em tópicos posteriores.
Exemplo :
Cada área de vendas da empresa deseja ter uma lista de preços contendo os preços de todos os seus produtos, agrupados de maneira diferenciada.

 SEQUENCIAS DE ACESSOS

 É uma estratégia de pesquisa que o sistema utiliza para encontrar dados válidos para um determinado tipo de condição. Ela determina a seqüência em que o sistema pesquisa os dados.
A seqüência de acesso é composta de um ou mais acessos. A seqüência dos acessos estabelece quais registros de condição têm prioridade sobre os outros.
Os acessos indicam ao sistema onde procurar em primeiro lugar, em segundo e assim por diante, até encontrar um registro de condição válido. Pode-se orientar o sistema para que, quando se achar um registro de condição em uma tabela, que se interrompa a procura nas demais tabelas (exclusiva) ou exigir do mesmo que a pesquisa seja feita em todas.
O usuário deve indicar uma seqüência de acesso para cada tipo de condição para o qual deseja criar registros de condição.
Exemplo :
Um departamento de vendas pode oferecer aos clientes diversos tipos de preços. O departamento pode criar, por exemplo, os seguintes registros de condição :
-           Um preço básico para um material
-           Um preço especial específico de cliente para o mesmo material
-           Uma lista de preços para clientes importantes
Durante o processamento da ordem o departamento deseja que seja pesquisado cada um dos possíveis preços para o cliente, mas prevalecendo o preço acordado com o mesmo.

EXCLUSÃO DE CONDIÇÃO

 Na determinação de preço para documentos de venda e faturamento, é possível aplicar mais de um registro de condição a determinado item. É possível utilizar o processo de exclusão de condições para comparar as condições possíveis e determinar, por exemplo, o melhor preço para um cliente ou, ainda, na eventualidade de se existirem duas condições pré-determinadas ao mesmo tempo, que se mantenha apenas uma delas.
 CRIANDO OS TIPOS DE CONDIÇÕES
 A parametrização das características do Tipo de condição está dividida em grupos de campos que são os seguintes :
Dados de controle 1 - Determina que tipo de condição está sendo criada e algumas regras de processamento
Condição de grupo - Indica se o sistema deve tratar a condição individualmente ou como parte de um grupo.
Possibilidades de modificação - Indica como a condição poderá ser alterada.
Dados mestre - Configura-se como os dados serão propostos, gerados e controlados.
Escalas - Determina os controles de escala da condição.
Dados de controle 2 - Determinar outras regras complementares de processamento da condição.
Determinação de texto - Indica atribuições de determinação de texto para a condição.

 DELIMITANDO VALORES PARA OS TIPOS DE CONDIÇÕES:

 O intuito da delimitação de valores para tipos de condição é impedir que valores acima ou abaixo do esperado para uma condição sejam calculados ou lançados manualmente. Isto é particularmente útil para prevenir erros de cálculo em condições que são calculadas ou entradas manualmente.
Para se criar valores de delimitação, basta acessar a rotina em questão e se cadastrar os valores para o tipo de condição que se deseja delimitar

 OTIMIZANDO SEQUENCIA DE ACESSOS:

 Pode-se otimizar o acesso às tabelas da sequência determinando-se que o R/3 utilize como primeiro acesso os campos disponíveis no cabeçalho do documento.
Isto melhora significativamente a performance de procura, pois o R/3 irá efetuar a busca de dados das sequências primeiramente com os dados de cabeçalho e, para aquelas tabelas onde ele encontrar dados, não será efetuada a pesquisa por item.
Logicamente, as tabelas deverão ter campos que estejam no cabeçalho do documento, caso contrário a operação é inviável.
É justificável efetuar esta parametrização quando se utiliza muitos itens no documento de vendas, pois a operação de busca da sequência de acesso é efetuada para cada um deles.
Para tanto basta acessar a rotina em questão e indicar para qual sequência e qual tabela da sequência deve-se procurar os dados com otimização

 FÓRMULA DE CÁLCULO NA PRICING

 Determina uma rotina interna do R/3 (ou uma rotina desenvolvida pelo cliente) que efetua o cálculo do valor da condição. Pode-se utilizar aqui as variáveis que se definiu anteriormente na coluna de sub-totais, bem como acessar outras bases de dados, ou ainda, acessar os dados de outras condições do esquema sendo processado.

Dicas :

           Na memória, os dados de pricing estão armazenados nas tabelas internas XKOMV, KOMP e KOMK;
           As fórmulas de cálculo não devem utilizar o comando LOOP a menos que se guarde a posição atual da linha do pricing, caso contrário, todas as condições abaixo da linha em questão serão desconsideradas e substituídas pela linha atual;

           Internamente o SAP guarda os valores multiplcados por 1000, 10000 e 100000. Depende da variável;

           Após se efetivar o cálculo, deve-se atribuir o resultado à variável XKWERT, que é a variável de valor da condição. Esta variável é automaticamente transferida para a linha de valor do esquema.

 SUBTOTAL - CONDIÇÃO:

 Controla se os valores de condição ou os subtotais devem ser gravados temporariamente e em que campos (na memória ou na base de dados) os mesmos serão gravados. Se o mesmo campo for indicado para gravar diferentes valores de condição, o R/3 somará todos os valores. Estes valores de condição ou subtotais servem, por exemplo, como referência para outros cálculos.
Dica: Para que exista análise de crédito, deve-se atribuir uma condição ao sub-total "A"

  FÓRMULA DE BASE:

 Determina uma rotina interna do R/3 (ou uma rotina desenvolvida pelo cliente) que determina o valor base da condição ou linha sendo processada. Pode-se utilizar aqui as variáveis que se definiu anteriormente na coluna de sub-totais, bem como acessar outras bases de dados, ou ainda, acessar os dados de outras condições do esquema sendo processado. Quando se define níveis inicial e final, os valores somados das linhas referenciadas são armazenados aqui. Este valor será utilizado para o cálculo da linha.

Dica : Após se efetivar a determinação da base, deve-se atribuir o resultado à variável XKBETR, que é a variável de valor de base da condição. Esta variável é automaticamente transferida para a linha de base do esquema.

O que significa SAP SD?

O que significa SAP SD?

O módulo de SD (Sales e Distribution, Vendas e distribuição) realiza operações para as áreas, comercial e logística, através destas operações a empresa organiza e gerencia sua estrutura comercial possibilitando gerar pedidos de venda através dos cadastros de cliente, materiais, preços, impostos e demais condições comerciais. A partir da geração dos dados comerciais as funções da área logística poderão ser executadas permitindo assim reservar estoques, realizar separação dos produtos, embalar e finalizar a expedição através da baixa dos estoques, preparando assim o fluxo do processo para a fase final de faturamento. No processo final de faturamento ocorrerá a integração contábil junto ao módulo de (FI- Finanças), nesta etapa, por exemplo o processo de vendas irá gerar a receita (contas a receber) perante ao cliente, ocorrerá a contabilização dos impostos devidos na operação e todos os dados comerciais e de logística serão integrados para que o cliente possa receber a mercadoria solicitada bem como os documentos fiscais e de cobrança que possibilitarão a formalização e entrega dos produtos vendidos ao cliente. Vários outros cenários do processo comercial e logísticos da empresa poderão ser configurados, de modo atender as necessidades de cada cliente em suas operações diárias.

Processos e integrações

Processos e integrações

O módulo SAP SD está integrado com diversos módulos do sistema SAP ERP, como podemos ver logo abaixo:

Integração com SAP FI

Para que uma venda seja feita, o sistema precisa de um cliente. O cadastro inicial de todos os clientes é feito no módulo SAP FI, assim como a avaliação de crédito, os lançamentos feitos em contas a receber, bancos, entre outros processos.

Integração com SAP MM

Assim como ter clientes é essencial, o sistema também precisa de produtos, mercadorias e serviços cadastrados. Estes cadastros são feitos inicialmente no módulo SAP MM. A movimentação deles é  feita com a integração com o módulo MM, pois além de outros processos, ele controla o estoque desses produtos e mercadorias.

Integração com SAP PP

Existem processos integrados entre SAP SD e SAP PP para a produção de produtos exclusivos para determinadas vendas. Além destas produções exclusivas, também podemos destacar a integração existente para o planejamento de produção, de acordo com o planejamento de vendas.

Integração com SAP CO

O SAP SD pode fazer diversos lançamentos no módulo SAP CO para garantir a apuração eficiente dos custos envolvidos nas vendas e nas movimentações de mercadorias e produtos. Além disso, é possível controlar as vendas x coletores de custos, como CDCs e ordens internas.
Como você pode observar, a integração existente entre SAP SD e os demais módulos é muito grande e também muito importante para o bom funcionamento do sistema.

Visão geral sobre SAP SD - Ordens de cliente - Remessas, entregas e fornecimentos


Visão geral sobre SAP SD

Ordens de cliente

Em SAP SD, as ordens de clientes geralmente são os documentos iniciais de qualquer processo empresarial que envolvam clientes, produtos e mercadorias. Nas ordens de clientes, podemos controlar os processos de acordo com os dados organizacionais de uma empresa, representados por uma área de vendas.
Nas ordens de clientes também controlamos os aspectos de recebedores das mercadorias, pagadores da fatura, prazos combinados para as entregas, precificação, descontos, impostos e vários outros processos.
Alguns exemplos de ordens de clientes: as ordens de clientes usadas no processo de vendas são chamados de ordens de vendas, assim como as ordens de clientes usadas no processo de devolução de produtos ou mercadorias são chamadas de ordens de devolução.

Remessas, entregas e fornecimentos

O principal documento de controle de expedição do módulo SAP SD são as remessas, mas o sistema SAP ERP também denomina estes documentos como entregas ou fornecimentos.
As remessas são documentos que controlam os aspectos de expedição, como o local da expedição, o centro onde as mercadorias e produtos estão armazenados, os depósitos, os lotes dos produtos, entre outros processos.
A partir da remessa, o sistema SAP ERP faz a separação das mercadorias e produtos. Se estiver configurado, também faz o empacotamento dos mesmos. Além disso, existe uma integração da expedição do módulo SAP SD com o módulo SAP WM, onde é determinada de qual posição do armazém as mercadorias e produtos sairão.
Após os processos requeridos serem cumpridos, são realizadas a movimentação das mercadorias e produtos, efetivando a saída ou entrada no estoque.

Faturas

Faturas

O processo de faturamento pode acontecer logo após a criação de uma ordem de cliente ou logo após a movimentação das mercadorias e produtos de uma remessa.
É através do processo de faturamento que acontece a integração do módulo SAP SD com o módulo SAP FI. Após o faturamento de uma ordem ou de uma remessa, o sistema SAP ERP cria vários lançamentos em FI para contemplar os processos configurados, como por exemplo atualizar as contas a receber do cliente faturado, com um débito ou com um crédito.
As fichas de crédito dos clientes também são atualizadas, gerando novos compromissos para o cliente faturado. Posteriormente, estes compromissos são liquidados com os pagamentos e novamente a atualização da ficha de crédito acontece.

SAP SD

Entenda como, na área de logística e utilizado o  SAP SD ou Comercial tem os seguintes componentes:
  • Funções Básicas (SD-BF) - Compreende na determinação de preços e condições de pagamento, verificação da disponibilidade, gestão de créditos e riscos, determinação de materiais, determinação de mensagens, determinação de impostos e de contas.
  • Vendas (SD-SLS) - Diferentes operações comerciais estão baseadas em documentos de vendas definidos no sistema: consultas e ofertas de clientes, pedidos de clientes, contratos e reclamações. Alguns fazem de forma automática a criação de documentos de entrega e de faturamento posterior.
  • Faturamento (SD-BIL) - Representa a etapa final de uma operação comercial. A informação sobre o faturamento está disponível em cada uma das etapas de gerenciamento de pedidos e entregas.
  • Comércio Exterior / Alfândegas (SD-FT) - Permite gerenciar processos de exportação e importação, identificar automaticamente os requisitos para autorização, simplificar o gerenciamento de informes com procedimentos automáticos para completar declarações, determinar que produtos estarão sujeitos a uma política de preferência.

sexta-feira, 2 de março de 2018

SAP PI v / s SAP BODS

O que é SAP PI: -
            O SAP PI fornece infra-estrutura técnica para troca de mensagens baseada em XML para permitir a integração de processos de negócios.
    É uma tecnologia e plataforma de integração
  • Para integrar sistemas SAP com sistemas não-SAP.
  • Para integrar aplicações A2A e B2B.
  • Para troca de mensagens síncrona e assíncrona.
  • Para gerenciamento de processos de negócios de componentes cruzados.
O que é SAP BODS: -
                O Data Service é a principal ferramenta para extrair, transformar e carregar dados de um ou mais sistemas de origem em um ou mais sistemas de destino.
Os Serviços de Dados podem acessar dados de uma grande variedade de aplicativos e fontes de arquivos e podem consumir quase todos os tipos de dados estruturados, semi-estruturados e não estruturados - dessas fontes.
Tipos de Integração: -
Existem diferentes maneiras de integrar aplicativos de negócios.
  • Integração de serviços
  • Integração de mensagens
  • Integração de Processo Empresarial
  • Integração de dados
Diferentes abordagens para lidar com os tipos de integração.
  • Integração de serviços.
  • ® Estabelecimento de uma arquitetura orientada a serviços.
  • Integração de mensagens e integração de processos de negócios.
  • ® Enterprise Application Integration ou integração B2B.
  • Integração de dados.
  • Utilitários de Extração, Transformação e Carga.
Arquitetura Orientada a Serviços
  • Todas as funcionalidades são publicadas como serviços independentes da plataforma.
  • Os serviços podem ser consumidos por outros aplicativos.
Integração de aplicativos corporativos.
  • Processo de ligação de diferentes aplicativos dentro de uma única organização em conjunto, a fim de simplificar e automatizar os processos de negócios, na medida do possível.
Extrair Transformar e Carregar
  • Extraindo dados de diferentes fontes.
  • Transformando-o para atender às necessidades operacionais e analíticas.
  • Carregando nos objetivos finais.
Nessas SOA e EAI podem ser gerenciadas pela SAP PI & ETL pode ser gerenciado pela BODS.
Existe uma sobreposição entre SAP PI & BODS sobre as funcionalidades que eles oferecem.
Determinar os fatores sobre a escolha entre o PI e os BODS são
  • Capacidades técnicas e funcionais de ambos
  • Ambiente organizacional
  • O tipo de integração a ser feita.
  • Ambiente técnico (tamanho do hardware)
  • Outros fatores.
  
 
Process Integration v / s Data Services
Vamos discutir as capacidades em detalhes

Volume de dados: -
  • Se grande número de mensagens for por segundo, com menos ou médio amt de dados precisam ser entregues, então o SAP PI é a escolha muito boa.
  • Se o volume de dados for muito grande e a frequência de dados a transferir é menor que o SAP BODS é a escolha.
     Exemplo:-
                Suponha que o requisito é que os dados sejam enviados para um parceiro comercial duas vezes por mês e o tamanho do arquivo é de 4 GB. Então, nesse caso, o envio dos dados para BODS é uma boa opção.
   
Modo de processamento: -
  • Programado / baseado em lote: -
                O processamento de serviços de dados normalmente está agendado. Você pode agendar os trabalhos em Batch em BODS ou executá-lo especificamente. Os trabalhos de Pi também podem ser agendados, mas geralmente eles não estão agendados.
  • Evento / Disparador Baseado: -
A BODS tem capacidade para receber eventos através de serviços web ou outros meios e processar esses eventos.
PI geralmente é acionado por dados recebidos.
  • Tempo real (síncrono / assíncrono): -
A latência de dados para DS é maior (minutos em vez de segundos).
O PI oferece mecanismos para transações síncronas em tempo real.
Exemplo:- 
  • Os dados devem ser movidos do banco de dados para o sistema BW uma vez em uma semana ou uma vez em um dia, então a opção BODS é a mercadoria.
  • O arquivo deve ser escolhido a partir do sistema remetente após cada 10 minutos, então o SAP PI é a boa opção.
Nível de processamento de dados: -
  • PI é usado para trocar mensagens entre sistemas enquanto o serviço de dados é usado para trocar o conjunto de dados.
Transformação de dados: -
  • Ambos os serviços de dados e PI fazem bem na aplicação de transformações básicas. As funções básicas necessárias para as transformações estão disponíveis em ambas as plataformas. por exemplo. Funções de cordas, funções matemáticas etc. são encontradas em ambos.
  • O serviço de dados tem muitas funcionalidades anteriores relacionadas à atividade de limpeza de dados. por exemplo. Validar, Tabela Comparação, Map_operations etc.
Business Process Management: -
  • Pi fornece capacidades de fluxo de trabalho completo. Os fluxos de trabalho centrais e centrados no ser humano são possíveis no PI.
  • O foco do serviço de dados apenas em fluxos de trabalho centrados no sistema. Nos fluxos de trabalho do DS são acordos simples com o processo de seqüenciamento de processos e erros.
Mensagens confiáveis: -
  • O serviço de dados não oferece suporte à entrega garantida.
  • O PI suporta entrega garantida com 2 opções, Exatamente um (EO) e Exatamente uma vez na ordem (EOIO).
  • As mensagens assíncronas (EO e EOIO) baseiam-se no padrão WS.
Conectividade: -
  • Tanto PI como BODS são capazes de gerenciar conectividade entre sistemas SAP e não SAP.
  1. Manipulação de arquivos, Aplicações SAP (RFC, IDOCs, Proxy), Legacy protocols (JMS), Bases de dados.
  • A manipulação de banco de dados é a funcionalidade básica de BODS. É capaz de extrair tabelas da maneira complexa.
  • Para a conectividade EDI de acordo com os padrões da indústria PI é mais adequado, pois os adaptadores EDI estão disponíveis no SAP PI.
SOA: -
  • O PI está posicionado como um middleware SOA. É a base da SOA. Você pode criar um serviço web a partir das interfaces usadas no PI.
  • No PI, você pode publicar seus serviços da Web no registro de serviços, que é baseado no UDDI 3.0, onde você pode pesquisar, gerenciar e consumir os serviços da Web.
  • A BODS atua como provedor de serviços ou consumidor, mas não oferece mais funcionalidades SOA.
TCO: -
  • O custo do uso do SAP PI como uma ferramenta de integração é baseado no volume de mensagens processado global expresso em GB / mês. O SAP PI é livre de usar para a integração entre os sistemas SAP para SAP.
  • Em BODS com um aplicativo, podemos cobrir vários processos de gerenciamento de dados, portanto, reduz o TCO.
Exemplo:-
  • Assim, para integração SAP para SAP, a SAP PI é mais adequada.
  • E para a migração de dados, limpeza e validação de dados de origem para sistema alvo BODS é mais adequado.
  
 
Tipo de Integração: -
  • Para o serviço, integração de aplicativos corporativos e integração Business-Business (B2B), a SAP PI é a melhor escolha.
  • Para integração de dados, SAP BODS é a melhor escolha.
Exemplo:-
  • Se o usuário precisar conhecer os detalhes sobre o número de materiais criados em uma unidade de trabalho, a criação do serviço da Web para esse fim e consumi-lo em qualquer lugar é a escolha certa e para este SAP Pi é a melhor opção.
  • O serviço de dados é a melhor opção para integração de dados com SAP Netweaver BW, SAP HANA e toda a Plataforma de BI do Business Objects. Serviços de dados é a ferramenta preferida para carregar dados que não são SAP no SAP HANA. De fato, os recursos de integração de dados dos Serviços de Dados estão incluídos no SAP HANA. Além disso, a SAP está fazendo grandes melhorias para uma interface de usuário perfeita entre os Serviços de Dados e SAP HANA.
Conteúdo de Integração: -
  • A SAP oferece conteúdo de integração pré-embalado, que é criado com base na metodologia de design SAP SOA. Esse conteúdo comercial inclui tipos de dados globais, interfaces de serviço e definições de mapeamento. Os profissionais de TI podem usar este conteúdo predelivered da SAP para iniciar suas implementações SOA no SAP PI.
  • Os adaptadores de terceiros também estão disponíveis no SAP PI para atender a padrões específicos da indústria. Adaptadores EDI da Seeburger
Interface de desenvolvimento: -
  • Em BODS, todos os processos de geração e qualidade de dados são desenvolvidos e gerenciados em uma única interface, ou seja, " Data Service Designer" .
  • Na criação de PI de design e configuração, os objetos são separados em " Repositório de Integração " e "Diretório de Integração ", respectivamente.
Resumo:-
                Como vimos a sobreposição entre a SAP PI & BODS, percebemos que ambas são ferramentas importantes e, dependendo do requisito de negócios, custo, recursos disponíveis, opções de conectividade e volume de dados, escolheremos SAP PI ou SAP BODS por seu requisito de integração.