Today I want to give information about automatic PO generation in MIGO transaction. Automatic PO generation with ME59N transaction code already is known .In there it is used by Purchase requsition. However this section will be shown a little bit different version .
Firstly we should do some customizing. These are in below.
SPRO>>Materials Management>>Inventory Management and Physical Inventory>>Good receipt>>Create Purchase Order automatically
Here we should assign checkbox according to movement type. In addition we can also check below path in order to assign purchasing group to plant where want to create purchase order.
SPRO>>Enterprize Structure>>Assignment>>Assign Standart Purchasing Organization to plant
After this it can pass MIGO transaction code, but must be needed to sure information about material is full. Any missing data causes some error during the good receipt. One of the need to create thing for automation PO is Info record with ME11. So material gets net price from info record. Another thing is we should write down purchasing group in material master record in Purchasing view.
Last thing must be full in master record is Automatic PO checkbox selection. As below you can see
Now If requirements are completed, we do not face any difficulties,errors during good receipt.So enter the MIGO
Enteries must be as above.After that it can be add material manually with help of marked icon below.
After full filling vendor name, material quantity, document might be post .
Choose display mode in order to look at purchase order number.
Go to the purchase order data tab in item level and double click on the PO number.
As a result If we can summarize writings, the statements in below must be require for generation automatically Purchase Order.
1.Assign the movement type in SPRO .
2.Info record must be exactly create.
3.Write down Purchasing group in Material Master Data(Purchasing View).
4.Full in Automatic PO checkbox in Material Master Data(Purchasing View).
Depois de vários projetos de DRC (e muitas discussões com colegas que estão começando na área) resolvi criar um conteúdo com um compilado de explicações sobre a criação do eDocument e com umas dicas pra ajudar a analisar o que está ocorrendo no sistema bem naquela hora que o “sapato aperta” e não tem opção pra onde correr. Se curtirem o conteúdo deixem um comentário aí ou sugiram algum próximo assunto para fazer um blog post. Se não curtirem, de boas, o mundo é livre ;D
Como nasce um eDocument numa fatura de SD?
Começando do começo vamos ver como o eDocument é criado no SAP. Tudo começou em 1972 quando 5 ex-funcionários da IBM decidiram criar uma empresa de sistemas inte…ops… não precisa ser tão do começo assim. O exemplo a ser analisado é de um cenário de SD criado por uma fatura na VF01. A criação do eDocument é disparada no momento que a fatura é salva.
O eDocument é criado na função RV_INVOICE_DOCUMENT_ADD de SD. Na imagem aqui de baixo você pode ver o ENHANCEMENT (standard da SAP) que chama os primeiros checks de eDocument no módulo de SD.
eDocument Checks in SD invoice
O método INITIAL_CHECKS1 verifica se a empresa está configurada para gerar eDocuments no caso de um documento fonte SD_INVOICE (o comportamento é diferente se a fatura de SD tem contalização, se não tem contabilização ou se é um documento relacionado a FICA).
Main Logic of Initial Checks
Classes genéricas de eDocument
Depois desse ponto é chamado o método CREATE_EDOCUMENT da classe CL_EDOC_SOURCE_SD que é usada para o documento fonte SD_INVOICE. Até esse ponto é basicamente código genérico válido para qualquer cenário de SD e isso é usado para praticamente qualquer país que usa eDocuments a partir da fatura:
Class to create eDocument in SD code
O método CREATE_EDOCUMENT da classe CL_EDOC_SOURCE_SD inicia a criação dos dados do eDocument, esse ponto verifica se eDocument está ativo na empresa e dispara as classes/métodos que transfere os dados das estruturas de SD (vbrk, vbrp, pricing_elements, etc…) para as estruturas internas do framework de eDocument (document_header, document_item, partner_data, etc…). Posteriormente o método CREATE_DOCUMENT vai ser chamado na classe CL_EDOCUMENT.
Se nenhum erro ocorrer logo adiante o método PREPARE_EDOCUMENTS vai ser chamado e vai identificar o país dessa fatura e a partir dessa informação serão buscadas as classes específicas do país that contain the details for the specific edocument type to be created.
Após encontrar qual a respectiva classe do país a arquiteura do o eDocument irá disparar o uso dos métodos dessa classe com a lógica específica do cenário daquele país.
Abaixo tenho uma screenshot da classe CL_EDOCUMENT_MX chamando o método IS_RELEVANT a partir do cenário de SD, existe um código na linha 17 que marca o processo como relevante por padrão e algumas verificações posteriores que podem desabilitar a relevância. Esse é um exemplo interessante, pois essa classe é a mesma chamada para o caso de eDocument no MX vindo tanto de SD como de FI , então ela possui verificações tanto no source_type (FI_INVOICE ou SD_INVOICE) como no edoc type (MX_PAYMENT) porque tem regras diferentes para FI_INVOICE que deve ser eInvoice e FI_INVOICE que deve ser ePayment. Além disso, no cenário do MX não é gerado eDocument para cenários de cancelamento (billing criado pela VF11) e nem para faturas já canceladas.
IS_RELEVANT implementation for MX scenarios
Após a logica de relevância standard da SAP para o México tem a chamada da da BAdI EDOC_ADAPTOR que também tem um método IS_RELEVANT (e aqui gambiarras podem ser feitas).
Essa BadI do eDocument Framework é genérica para todos os países e trabalha com múltiplas implementações usando o país como filtro, por exemplo se você cria uma implementação para MX nessa BAdI só no cenário em que o país do eDocument for MX isso vai ser chamado. Para outros países que você usar eDocument de SD você pode ter outras implementações com outras regras, essa funcionalidade é bem interessante e faz sentido.
O método IS_RELEVANT é usado quando você deseja impedir a criação de um documento eletrônico para um determinado cenário específico. Na maioria dos casos, o tipo de documento FI é o principal motivador da criação do eDocument, mas em um determinado cenário pode haver restrições adicionais. Por exemplo, todos os Tipos de Faturamento usados por uma empresa são atribuídos ao tipo de documento FI RV, mas dependendo do Tipo de Faturamento (por exemplo ZF2B) você pode não precisar que um eDocument seja criado para um determinado cenário.
Código Específico do País ( Classes CL_EDOCUMENT_**)
Um pouco depois da verificação de relevância o sistema começa a executar chamadas para as classes que buscam os dados do process manager instantiation and it calls the PROCESS_CREATE method from the respective country specific class CL_EDOCUMENT_MX .
Start of eDocument Processing in MX
A estrutura de classes métodos do “Process Framework” controla as ações executadas e cada passo a ser rodado com base na configuração do cenário nas tabelas da view cluster “Process Manager”. Isso pode ser consultado na SM34 com view cluster EDOC_PROCMGR utilizando eDocument process ID, que é MXINVOICE nesse caso.
Process Manager actions
A classe específica do país (MX) também irá chamar a persistências dos dados nas tabelas. O método genérico (da classe do framework global) SAVE_TO_DB persiste dados na tabela EDOCUMENT e o método específico de país (da classe do país) persiste na tabela EDOMXINVOICE.
Persistency to Database
O próximo passo na luta de implementar eDocuments é a parte mais importante na minha humilde opinião, o MAPEAMENTO dos dados! Esse é um blog post que vai levar um tempinho para preparar porque é o coração do paranauê todo, dominado o conceito do mapeamento é possível implementar qualquer cenário em qualquer país (com uma boa dose de ABAP).
Valeu Gurizada!
Renan Correa
Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube
Mais infos sobre a localização Brasil no ERP, direto da sap, vocês podem conferir no SAP community na tag de S/4HANA logistics for Brazil
Outros posts sobre Localização você pode conferir filtrando pela categoria NFE/CTE ou Localização BR Geral.
Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/ACR.
When users deal with delivery orders with lots of items lines like greater than 25, it creates processing challenges resulting in long delays as the work must be performed by a single person and can’t be divided out. Then the requirement is split delivery at VL10B for STO when the numbers of delivery line items are greater than a specific number.
This question has been asked many times in the community like this one. Jelena’s answer is absolutely working, in this article just make it more clear how to achieve this by using VOFM.
Q: How can the split be affected via the copy control?
A: Via the copy control, the data is copied from the preceding document to the
header of the delivery and therefore acts as a splitting criterion. Two routines are relevant for the data transfer for outbound deliveries with order reference in the standard:
FORM routine DATEN_KOPIEREN_001 (include FV50C001) for the transfer of the data from the header (CVBAK) and item (CVBAP) of the sales order.
FORM routine DATEN_KOPIEREN_002 (include FV50C002) for the transfer of the data from the business data of the sales order.
With all other outbound delivery types as well as with inbound deliveries,
the data transfer is carried out via FORM routine DATEN_KOPIEREN_301
(include FV50C301) or DATEN_KOPIEREN_201 (include FV50C201).
In the table with delivery header data LIKP, there is field ZUKRL which can be filled with any values via the copying control. The contents of this field act as splitting criteria for the delivery creation so
that you can use it in order to force a delivery split according to your own specifications. Apart from that, the field does not have any business or technical importance and can be delivered via both of the routines mentioned above.
You can find more detailed information in note 166397.
The criterion is not about splitting one order into several deliveries, but about combining or not several orders into one delivery (Zusammenführungskriterium = Combination criterion).
If you want to disallow combining different orders with different distribution channels and different divisions, you can fill ZUKRL as follows:
orders that have the same entries in ZUKRL will be combined, the others will get separate deliveries.
ZUKRL replacement method
As the internal table xkomdlgn keeps all the item details for all STO together and will set the LIKP-ZUKRL inside that routine. The idea of replacing ZUKRL is to collect the numbers of processed xkomdlgn item and save as global data, replace old ZUKRL with new ZUKRL if numbers of items greater than the specific number for a combination of STO number and old ZUKRL.
Copy routine 301 to a new routine like 901, insert below replacement logic after ZUKRL has been assigned.
DATA: ls_split TYPE ZSD_VL10B_DLY_SPLIT,
lv_zukrl type DZUKRL.clear: ls_split, lv_zukrl.
ls_split-VGBEL = xkomdlgn-VGBEL.
ls_split-zukrl = likp-zukrl.
ls_split-count =1." Get new ZUKRL based on accumulated item no.CALLFUNCTION'ZSD_VL10B_SPLIT_ITEM_GT25'EXPORTING
input_split = ls_split
IMPORTING
ZUKRL = lv_zukrl "replaced ZUKRL.
likp-zukrl = lv_zukrl.
Define a structure to save the accumulated items per VGBEL and ZUKRL.
Create below FM to get new ZUKRL when the number of items reaches the specific number here is 25. Define global data GT_SUM at top of the function group for this function module.
DATA: GT_SUM type ZSD_VL10B_DLY_SPLIT_T.
FUNCTION zsd_vl10b_split_item_gt25.*"----------------------------------------------------------------------*"*"Local Interface:*" IMPORTING*" VALUE(INPUT_SPLIT) TYPE ZSD_VL10B_DLY_SPLIT*" EXPORTING*" REFERENCE(ZUKRL) TYPE DZUKRL*"----------------------------------------------------------------------DATA: ls_sum TYPE zsd_vl10b_dly_split,"accumulated ZUKRL
ls_split_no TYPEi,
lv_string type string." --------Example of Split---------" item 0-25, ZUKRL = ZUKRL" item 26-50, ZUKRL = ZUKRL+"SPLIT-1"" item 51-75, ZUKRL = ZUKRL+"SPLIT-2"" ..."----------------------------------" 01. get all incoming entry to Global table GT_SUMCOLLECT input_split INTO gt_sum.* APPEND INPUT_SPLIT TO GT_SUM.CLEAR ls_sum.READTABLE gt_sum INTO ls_sum
WITHKEY vgbel = input_split-vgbel
zukrl = input_split-zukrl." 02. check total items for current ZUKRLIF ls_sum-count BETWEEN1and25."keep original ZUKRL for 1-25 items
zukrl = input_split-zukrl.ELSE.
ls_split_no = ls_sum-count DIV25.
lv_string = ls_split_no."using new ZUKRL with SPLIT no. Per 25 itemsCONCATENATE input_split-zukrl 'SPLIT-'
lv_string INTO zukrl.ENDIF.ENDFUNCTION.
Publicado por:
