Variaveis de Sistemas

Uma das melhores tecnicas disponibilizadas pela SAP é a tabela SYS ou mais conhecidas por SY. Esta tabela pode ser lida para cada instancia de programa ABAP em execução. Os principais campos da tabela SY são:

• SY-SUBRC – Retorna 0 se foi bem sucedido ou diferente de 0 se falhou, usada após uma pesquisa, condição.

• SY-UNAME – Retorna o nome do usuário

• SY-DATUM – Retorna a data do sistema

• SY-UZEIT – Retorna a hora, minuto, segundo do sistema

• SY-TCODE – Retorna código da transação atual

• SY-TABIX – Retorna o numero da linha da tabela atual (Normalmente usando dentro de loop.)

• SY-LANGU – Retorna o idioma de logon do usuário

• SY-DYNNR – Retorna o numero da tela atual

• SY-UCOMM – Retorna o nome de um botão pressionado (OKCODE)

• SY-REPID – Retorna o nome do programa

• SY-CPROG – Nome do programa principal

• SY-FDPOS – Utilizado na comparação de Strings, ver comparação strings acima.

• SY-BATCH – Indica a execução de um programa em background

• SY-LINNO – Retorna a linha corrente de um relatório

• SY-LISEL – Retorna a linha selecionada em relatórios interativos

• SY-MANDT – Retorna o mandante do sistema

• SY-PAGNO – Retorna a pagina atual de um relatório

• SY-TVAR0 .. SY-TVAR9 – Retorna elementos de textos ou títulos de relatórios

• SY-VLINE – Efetua a fechamento de bordas em um relatório

• SY-ULINE(n) – Imprime uma linha com n posições

• SY-TCODE – Código da transação

• SY-DBCNT – Dentro de SELECT, contém o contador de interação

ABAP NetWeaver

Nestas últimas safra de inovação, a SAP esta cada vez mais aperfeiçoado-se. E como todos sabem a uma grande tendencia de se utilizar modelos de desenvolimentos mais populares assim como o proprio COBOL esta fazendo. Uma pergunta? qual a ferramenta usada em 100% das universidades de ensino que tenha cursos de TI?

Linguagem? Java

IDE? Eclipse.

Pensando nisso SAP e IBM começaram a migrar os seus EDITORES, podendo assim cobrir o mercado tão carente de bons profissionais.

Para expandir o conhecimento segue três videos importantes:

 

 

 

 

RFC_READ_TABLE – Lendo qualquer Tabela do SAP

Muitos desenvolvedores de outras plataformas tais como Java (JCO) Dot.NET (proxy), necessitam de informações do SAP, com isso realizam integração com contruções de RFC na plataforma ABAP. Está dependencia de ABAP acaba quando conhecemos a RFC RFC_READ_TABLE. Através desta RFC é possivél acessar e ler dados de qualquer tabela SAP.

Relizando a leitura:

Demostrarei os argumentos através da Se37 (SAP), porém basta realizar a mesma chamada do sistema de origem:

RFC – RFC_READ_TABLE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Introdução ao XML Schema (XSD)

 

Uma breve contextualização

“O XML está se tornando rapidamente um padrão universal para os sistemas de informação”. Você certamente já se deparou com essa frase ou alguma similar. A aplicabilidade do XML de alguns anos pra cá está cada vez mais surpreendente. Sua utilização não é limitada a algumas APIs presentes no Java, no .NET ou em outra linguagem de programação. Sua presença é tão forte que o XML se aplica até em áreas que muitos nem ao menos imaginam. O PlayStation 3 com sua interface de programação aberta possui um padrão de importação e exportação de arquivos para modelos 3D em XML (COLLADA). Existem produtos baseados em XML que promovem uma maior acessibilidade para portadores de necessidades especiais através de voz. O software embarcado também utiliza diversos padrões XML.

Seguindo o padrão XML, outras tecnologias também começam a despontar. Padrões relacionados ao XML como a XPath, o Xml Schema (XSD), a XQuery, etc também merecem atenção. É fato que o XML é importante e caracteriza uma verdadeira revolução na comunicação entre aplicações, empresas, etc além de ser um padrão cada vez mais presente na WEB. É igualmente fato que sem os padrões relacionados, o XML perde muito do seu poder. A ausência dessas tecnologias tornaria o XML apenas um formato texto um pouco mais moderno e flexível. Nesse artigo falarei sobre uma dessas tecnologias, o XML Schema (XSD).

A troca de informações

A maior parte da usabilidade do XML é a transferência de dados. Anteriormente as empresas com requisitos de transferência de dados utilizavam o Exchange Data Interchage – EDI, onde um número elevado de transações é comunicado em arquivos em lote. Estes arquivos tinham que atender padrões previamente negociados e pouco flexíveis e a necessidade de agrupamento das transações atrasava o andamento dos negócios . Com o advento da internet a troca de dados entre aplicações se tornou um requisito cada vez mais necessário e freqüente, incorrendo em formas mais flexíveis de troca e representação de dados, com o uso da hipermídia e outros formatos de apresentação.

A necessidade de validação

A possibilidade de criação de tags próprias permite uma grande liberdade na confecção de documentos XML. Essa liberdade, no entanto, pode trazer grandes problemas senão for controlada. Suponha que uma empresa, por exemplo, desejasse obter ofertas de seus fornecedores e estes enviassem os dados em XML. Com a liberdade oferecida pelo XML, os fornecedores poderiam enviar os dados com as tags que achassem mais apropriadas (possivelmente as que seus sistemas gerarem mais facilmente). Seriam possíveis diversas construções. Ex:

<fornecedor razaosocial=”ABC Ltda”>
<produto nome=”Modem ADSL Broadxent BritePort 8120 4 Portas” preco=”649″/>
<produto nome=”Modem ADSL Router NM200 Stracta” preco=”169″/>
<fornecedor>

<fornecedor razaosocial=”ABC Ltda”>
<produto>
<nome>Modem ADSL Broadxent BritePort 8120 4 Portas</nome>
<preco>649</preco>
</produto>
<produto>
<nome>Modem ADSL Router NM200 Stracta</nome>
<preco>169</preco>
</produto>
</fornecedor>

<fornecedor razaosocial=”ABC Ltda”>
<produtos>
<produto nome=”Modem ADSL Broadxent BritePort 8120 4 Portas” preco=”649″/>
<produto nome=”Modem ADSL Router NM200 Stracta” preco=”169″/>
</produtos>
</fornecedor>

Com apenas alguns poucos itens de dados (nome do fornecedor, nome doproduto e preço do produto) foi possível produzir 4 variações de documentos XML contendo a mesma informação. A quantidade de possibilidades só é limitada pela quantidade de itens de dados e pela imaginação e criatividade do responsável pela construção do documento XML. A empresa nesse caso teria que interpretar todos os padrões existentes para obter os dados de cada oferta de seu fornecedor. Como não existe limite para os padrões possíveis e nem a possibilidade de prever quais são os padrões a serem utilizados é inviável permitir toda a flexibilidade do XML na transmissão de dados. Essa é uma das principais razões pelas qual a validação precisa ser feita. Apenas com um acordo prévio sobre o padrão a ser utilizado é que é possível que o intercâmbio de dados possa ser feito.

Documentos XML bem formados

Quando se fala em documentos XML existem dois conceitos importantes a serem tratados. São eles formação e validação. Podem parecer sinônimos mas não o são. Existem algumas regras para que um documento XML seja considerado bem formado (well-formed). São expostas abaixo as principais regras para a boa formação de documentos XML:

• Regra 1: Todas as tags abertas são devidamente fechadas
• Regra 2: Não há sobreposição de tags
• Regra 3: Existe um e somente um elemento raiz

 

 

A seguir são apresentados alguns documentos bem-formados e mal-formados de acordo com as regras acima:

Regra 1

Documento bem formado	Documento mal formado
<?xml version=”1.0″?> <empresa CNPJ=”51468791000115″> <razaosocial>Papelaria ZYX</razaosocial> </empresa>	<?xml version=”1.0″?> <empresa CNPJ=”51468791000115″> <razaosocial>Papelaria ZYX</Razaosocial> </empresa>

Regra 2

Documento bem formado	Documento mal formado
<?xml version=”1.0″?> <empresa CNPJ=”51468791000115″> <dados> <razaosocial>Papelaria ZYX</razaosocial> </dados> </empresa>	<?xml version=”1.0″?> <empresa CNPJ=”51468791000115″> <dados> <razaosocial>Papelaria ZYX</dados> </razaosocial> </empresa>

Regra 3

Documento bem formado	Documento mal formado
<?xml version=”1.0″?> <empresas> <empresa CNPJ=”51468791000115″> <razaosocial>Papelaria ZYX</Razaosocial> </empresa> <empresa CNPJ=”43269791000120″> <razaosocial>Xerox do Armando</Razaosocial> </empresa> </empresas>	<?xml version=”1.0″?> <empresaCNPJ=”51468791000115″> <razaosocial>Papelaria ZYX</Razaosocial> </empresa> <empresaCNPJ=”43269791000120″> <razaosocial>Xerox do Armando</Razaosocial> </empresa>

Mensageria CT-e

Bom, muitos estão preocupados com está modalidade para o sistema SAP. Porém acredito que pela grande experiência obtida com NF-e, conseguir bolar um projeto de CT-e dentro do SAP, de uma forma que acredito que nem a SAP tem, rs. Bom Pessoal vou apresentar o processo conforme apresentei na empresa. Qualquer duvidas podem entrar em detalhe através do email uderson@gmail.

Baixar apresentação 1:

Saneamento de cadastro de clientes e fornecedores passa a ser cada vez mais exigido

Diante das obrigações impostos pelo SPED e NFe, o saneamento de cadastro de clientes e fornecedores, passa a ser cada vez mais exigido. O artigo procura orientar um pouco mais sobre a melhor forma de fazer este saneamento cadastral.

O saneamento cadastral; consiste na atividade de atualizar e complementar as informações cadastrais das empresas, visando atender a aspectos do negócio, neste caso que aqui queremos relatar as necessidades do projeto SPED.

Fazer o saneamento de cadastros de clientes e fornecedores, não é uma tarefa tão simples quanto pode parecer num primeiro momento e requer atenção e dedicação. A experiência mostra que as empresas acabam subestimando a importância do assunto e na maioria das vezes, não tem a visão clara da abrangência do trabalho a ser efetuado.

Por muitas vezes entendem que uma vez feita à busca das informações junto aos sites oficiais da Receita Federal e Sintegra, o problema está 100% resolvido, o que é um erro. Provavelmente esta empresa terá em seu cadastro (CNPJ Baixados ou Suspensos) de clientes importantes os quais devem ser imediatamente tratados e não simplesmente bloqueados.

Deve ser levado em consideração que uma empresa pode ter CNPJ Matriz e diversos CNPJ filiais, o que é muito comum, principalmente nas organizações de médio e grande porte. Faz necessário verificar além do status do CNPJ e Sintegra, se estes de fato estão atrelados um ao outro. Ou seja, o CNPJ cadastrado deve estar atrelado a uma IE pertencente a aquele CNPJ. É de ocorrência comum encontramos IE que esteja atrelada a outro CNPJ, quer seja ele da mesma razão e até de razão social diferente!

Por outras vezes depara-se com a ocorrência de endereço errado, como por exemplo; o endereço contido no cadastro é do estado do MT, todavia o cadastro apresenta CNPJ e IE do estado de São Paulo por exemplo. Por outras vezes o endereço contido no cadastro de faturamento é também confundido com o endereço de entrega. E outras tantas ocorrências bastante comuns de serem encontradas que não vou aqui detalhar para não ser exaustivo.

Fases do saneamento de cadastro

Portanto o saneamento de cadastros, não termina simplesmente com a busca das informações oficiais, requer um trabalho cuidadoso de análise, para então depois devolver seus dados ao ERP da forma mais confiável possível.

Mas ainda não acabou, temos agora que levar em consideração que os cadastros alteram mais rápido do que imaginamos. A prática mostra que um cadastro contendo 3.000 CNPJ pelo menos, sofre alterações de Receita Federal e Sintegra pelo menos uma vez a cada mês de uma forma geral. Assim as empresas necessitam revisão de seus processos para os novos entrantes no cadastro e também uma revisão de processos, que possam garantir a manutenção dos seus cadastros em seu banco de dados sempre ativos, habilitados com os dados de endereço corretos, razão social etc…

Por Ivan Ricardo Martini

Validando IE (Inscrição Estadual)

Em muitos caso, não temos sistemas de automação de cadastro (vide artigo Sanemaneto de Cadastro), que permitem através do CNPJ coletar todas as informações necessarias em bases de dados legais, tais como Sintegra e Receita Federal, com esta ausencia de sistemas temos que realizar o cadastro de cliente e fornecedor de forma manual, através de suas respectivas transações (FD01,XD01 – FK01,XK01). Devido o sistema SAP R/3 ser um sistema multi-paises não é possivél que os campos ja venham com os mesmo nomes que gostariamos, exemplos deste é o campo CNPJ e IE. Para estás opção de nomes temos que alterar a LABEL para os respectivos nomes. Internamente os campos CNPJ e IE contém um nome próprio os quais são:

STCD1 = CNPJ

STCD3 = IE

Para que possamos validar as informações do campo STCD3 (IE) é necessario a implementação da field EXIT. Todas as FIELD EXIT seguem a seguinte regra: função (se37) FIELD_EXIT_<CAMPO>. Com isso temos a seguinte FIELD EXIT para este campo STCD3 FIELD_EXIT_STCD3. Para validar as IE, é necessario implementar uma rotina capaz de validar os tamanhos, formatos e digito verificador da IE de cada estado brasileiro, para isso a SAP disponibilizou a seguinte função “TAX_NUMBER_CHECK_GENERIC” que tem capacidade de realizar esta validação. Para Implementar a EXIT segue código fonte de validação:

*”*”Interface local:

*” IMPORTING

*” REFERENCE(INPUT)

*” EXPORTING

*” REFERENCE(OUTPUT)

*”———————————————————————-

DATA: v_regio TYPE sadr-regio.

v_regio = lfa1-txjcd(2).

CALL FUNCTION ‘TAX_NUMBER_CHECK_GENERIC’

EXPORTING

i_intca = ‘BR’

natural_person_flag = space

region = v_regio

stkzu = space

tax_code_1 = space

tax_code_2 = space

type_of_tax_code_1 = space

tax_code_3 = input

tax_code_4 = space.

ENDFUNCTION.

Veja os principais campos de importancia da FUNÇÃO:

• I_INTCA – Sigla país
• REGION – Estado
• TAX_CODE_3 – IE

Observe que é possivél implementar com esta função a validação dos campos STCD1,2,3 e 4.

Reprecificação SD

Em algum momento no processo de vendas através do modulo SD, temos a necessidade de atualizar o preço através da atualização de preços, seja ela por alteção de organização de venda, centro, cliente, etc… Visualmente temos esta opção na VA01 e VA02, porém em nivél de código temos uma opção que fica bem escondida, através de EXITS no processo de SD. Para que será atualizado os preço, impostos de forma automatica quando houver uma mudança de informação basta realizar a implementação da EXIT:

Através do include “MV45AFZB”

 

SE38:

 

No form:  FORM USEREXIT_NEW_PRICING_VBKD CHANGING NEW_PRICING.

Veja:

 

 *&———————————————————————*
*&      Form  USEREXIT_NEW_PRICING_VBKD
*&———————————————————————*
*       This userexit can be used to perform new pricing, dependant   *
*       on the change of datafields                                   *
*                                                                     *
*       Available data-fields:                                        *
*         vbak – header data                                          *
*         vbkd – business data (changed)                              *
*         *vbkd – business data (old, before the change)              *
*                                                                     *
*       Field vbkd-posnr is the item-number of the business data.     *
*       If the field is initial, then vbkd contains the business      *
*       header data.                                                  *
*                                                                     *
*       Parameter new_pricing controls the new pricing in the calling *
*       form. It can be filled according the the allowed values       *
*       of domain KNPRS (Pricing type), for example:                  *
*       ‘ ‘ = no new pricing                                          *
*       B   = Carry out new pricing                                   *
*       C   = Copy manual pricing elements and redetermine the others
*———————————————————————*
FORM USEREXIT_NEW_PRICING_VBKD CHANGING NEW_PRICING.

* Example: new pricing, when Price list type is changed
* if vbkd-pltyp ne *vbkd-pltyp.
*   new_pricing = ‘B’.
* endif.
ENDFORM.

Internamente o sistema armazena VBAK e VBKD com os novos valores e *VBAK e *VBKD com os antigos valores, basta implementar a verificação de campos de necessidade e enviar o código de atualização.

 

Exemplo:

 IF vbak-vkbur NE *vbak-vkbur.
   new_pricing = ‘C’.
 ENDIF.

Saneamento de cadastro de clientes e fornecedores passa a ser cada vez mais exigido

Diante das obrigações impostos pelo SPED e NFe, o saneamento de cadastro de clientes e fornecedores, passa a ser cada vez mais exigido. O artigo procura orientar um pouco mais sobre a melhor forma de fazer este saneamento cadastral.

O saneamento cadastral; consiste na atividade de atualizar e complementar as informações cadastrais das empresas, visando atender a aspectos do negócio, neste caso que aqui queremos relatar as necessidades do projeto SPED.

Fazer o saneamento de cadastros de clientes e fornecedores, não é uma tarefa tão simples quanto pode parecer num primeiro momento e requer atenção e dedicação. A experiência mostra que as empresas acabam subestimando a importância do assunto e na maioria das vezes, não tem a visão clara da abrangência do trabalho a ser efetuado.

Por muitas vezes entendem que uma vez feita à busca das informações junto aos sites oficiais da Receita Federal e Sintegra, o problema está 100% resolvido, o que é um erro. Provavelmente esta empresa terá em seu cadastro (CNPJ Baixados ou Suspensos) de clientes importantes os quais devem ser imediatamente tratados e não simplesmente bloqueados.

Deve ser levado em consideração que uma empresa pode ter CNPJ Matriz e diversos CNPJ filiais, o que é muito comum, principalmente nas organizações de médio e grande porte. Faz necessário verificar além do status do CNPJ e Sintegra, se estes de fato estão atrelados um ao outro. Ou seja, o CNPJ cadastrado deve estar atrelado a uma IE pertencente a aquele CNPJ. É de ocorrência comum encontramos IE que esteja atrelada a outro CNPJ, quer seja ele da mesma razão e até de razão social diferente!

Por outras vezes depara-se com a ocorrência de endereço errado, como por exemplo; o endereço contido no cadastro é do estado do MT, todavia o cadastro apresenta CNPJ e IE do estado de São Paulo por exemplo. Por outras vezes o endereço contido no cadastro de faturamento é também confundido com o endereço de entrega. E outras tantas ocorrências bastante comuns de serem encontradas que não vou aqui detalhar para não ser exaustivo.

Fases do saneamento de cadastro

Portanto o saneamento de cadastros, não termina simplesmente com a busca das informações oficiais, requer um trabalho cuidadoso de análise, para então depois devolver seus dados ao ERP da forma mais confiável possível.

Mas ainda não acabou, temos agora que levar em consideração que os cadastros alteram mais rápido do que imaginamos. A prática mostra que um cadastro contendo 3.000 CNPJ pelo menos, sofre alterações de Receita Federal e Sintegra pelo menos uma vez a cada mês de uma forma geral. Assim as empresas necessitam revisão de seus processos para os novos entrantes no cadastro e também uma revisão de processos, que possam garantir a manutenção dos seus cadastros em seu banco de dados sempre ativos, habilitados com os dados de endereço corretos, razão social etc…

Por Ivan Ricardo Martini

Abrir a transação J1BTAX em ambientes fechados

Problema: Manutenção em tabelas da transação J1BTAX não é permitida em ambientes fechados pela transação SCC4.

Solução: Abertura das tabelas via Atualização de Cluster – Transação SOBJ.

Procedimentos:
01. Acesse a transação SOBJ no mandante que se
deseja abrir.
02. Clique em Maintain.
03. Clique no botão Position.
04. Informe o objeto: J_1BTXIP1.
05. Pressione Enter.
06. Pressione o botão Details (Ctrl+Shift+F2).
07. Informe a chave de acesso.
08. Marque a opção Current Settings.
09. Pressione o botão Save.
10. Informe a request para transporte.
11. Repita os passos de 04 a 10 para os objetos J_1BTXIP2, J_1BTXIP3, J_1BTXIC1, J_1BTXIC2, J_1BTXIC3.