quinta-feira, 4 de maio de 2017

BC sets: Conjuntos de configurações de negócio – O que são e como usá-los

Olá pessoal,

Neste blog post vamos explicar brevemente para que usamos BC sets e vamos mostrar um passo-a-passo de como implementamos eles.
BC sets é uma ferramenta que permite que você registre, salve e compartilhe customizações. Quando um BC set é criado, os valores das tabelas de customizing originais são copiados para o BC set.
Muitas vezes, a SAP entrega BC sets como um anexo das SAP Notes para que vocês não precisem criar manualmente master data, tipos de notas ou master groups, por exemplo.
No entanto, a implementação dos BC Sets não cria nenhum tipo de objeto, esses precisam ser criados por meio de passos manuais ou usando o report anexo à SAP Note.
Além disso, não é um objetivo dos BC Sets serem um guia de configuração; eles precisam ser implementados. Portanto, existe uma grande chance de vocês não conseguirem simplesmente abrir o arquivo e fazer manualmente a configuração entregue com o BC Set.
Suponhamos, então, que vocês tenham recebido uma SAP Note com um BC set anexo, estes são os passos para a implementação:
1) Salve o anexo BCS que está na SAP Note no seu computador.
2) Faça login no sistema usando um cliente de customzing.
3) Acesse a transação SCPR3.
4) Selecione Upload de um CCN.
5) Selecione o arquivo que você salvou no seu computador.
Se depois de salvar o arquivo no seu computador, você ainda não conseguir encontrá-lo,              verifique se o encoding do arquivo é compatível com o encoding do seu sistema.
6) Selecione OK na tela pop up.
7) Salve suas alterações.
8) Acesse a transação SCPR20.
9) No campo CCN, insira o nome do BC Set.
10) Ative o BC Set.
11) O sistema exibe uma tela com possíveis mensagens de erro, se não houver nenhum erro, confirme a ativação do BC Set.
Espero que tenha ajudado.
Qualquer dúvida, deixem comentários abaixo.
Até mais,
Karla Reis
Fonte: https://blogs.sap.com/2017/02/08/bc-sets-conjuntos-de-configuracoes-de-negocio-o-que-sao-e-como-usa-los/

quarta-feira, 3 de maio de 2017

Automatic Printing of a Sales Order Document immediately after saving the Application in VA01 transaction using NACE



This scenario shows how to print a document whenever a sales order from VA01 is created immediately after saving the application using NACE.Before that we need to maintain the configuration in the NACE transaction.
Step1: Go to transaction NACE and select the application V1.This is a standard application to confirm the sales order.



Step2:  Click on condition records.

a) It is used to set the values to process the output type based on the Business rule. The following screen will appear. 
 
b) Double click on the BA00. The following screen will appear. Select the any one key combination based on the business rule.
For example, if you want process the appropriate output by giving the Sales Organization, Distribution channel, Division and customer then select the first one. This means it processes the output only when the values found with this combination.

 
c) Set the values and click on Execute/F8 button. Consider the values according your database. 
 d) Provide the customer and partner details and in the Medium click on F4 help. You can see the list of available mediums. Select the medium1i.e. print output.
In date/time filed click on F4 help and select time 4(Send immediately when saving the application). If we don't select this option it won't process the output immediately when saving the application. Maintain the language also. 
e) Now click on Communications button to set the printer properties. Maintain your own printer settings and don't forget to check the filed 'Print Immediately'.  
The configuration to print the document automatically when saving the application is completed.
 Step3:  In order to process the output type we require programs and forms.
The programs and forms to process the output are readily available in SAP system. There are some standard programs and forms are pre configured in the NACE transaction. To see that
 a) Go to NACE, select V1 and click on 'Output Types' 
b) SelectBA00and double click on 'Processing Routines'. 
c) The following screen will appears. Here we can find programs and corresponding forms to process the outputs for different mediums. As per our requirement the corresponding program and forms are preconfigured in the Print output Medium. If we want make our own zprogram and zform, simple just replace it in the corresponding fields in the Print Medium. 
Step4:  Now go to transaction VA01. Give the values we mentioned in the condition records and press enter.
Order type                  :      OR
Sales Organization   :   0001
Distribution Channel:       01
Division                       :       01

a) Enter the sold-to-party or customer as 1000 and enter the Item details. 

Once the data is enterd click on save button. Now the document will automatically print the document. Before that if you want to check the configured output type. Follow the steps.
 b) Go to transaction VA02 and enter the created sales order number. 
  
To check the output type, Go to Extras-> Output->Header->Edit. The following screen will appear. 
Here we can see two types of statuses.
 The Yellow color indicates that it is ready to process. It will automatically come into the picture because we configured the values in NACE transaction. Whenever system found these values (0001, 01, 01, 1000) it will automatically process the above output. We need not to give the output parameters every time the document is to be printed.
 The Green color indicates that the document is successfully processed.
 c) Select Back button and click on SAVE. The document will automatically go to the printer. Now you can collect the document from the printer.
 The document Output is shown below: 

 
 Fonte: https://wiki.scn.sap.com/wiki/display/BPX/Automatic+Printing+of+a+Sales+Order+Document+immediately+after+saving+the+Application+in+VA01+transaction+using+NACE

quinta-feira, 27 de abril de 2017

SAP Configuring Email SCOT

How to config and send email from SAP

  The Details that are required before configuration.
1. SMTP Mail Server Domain Name
2. SMTP Port Number (usually 25).
It is required to configure SAPconnect settings for every client that is used for send processes (E-mails, Faxes, SMS).
Step No 1
Go To Tx Code SCOT
1. Enter the Value for Default Domain
Under Settings -> Default Domain, define the domain of the SAP system client. This allows for the following to take place:
1.1* The SMTP plug-in logs on to the mail server using the domain as ID.
1.2* The message ID of the outbound e-mails is assembled with this domain.
1.3* If an SAP user who does not have an Internet mail address sends an e-mail, a sender address consisting of the SAP user name and this domain is generated.
Choose the Menu Option
Views -> Nodes -> in the subsequent screen, expand INT -> double click on SMTP

Step No 2 In the Subsequent Screen… enter the following informations.
  How often the Mail should be sent. (mostly every 5 minutes)
  Check the “checkbox” “Node in use”
  Enter the “SMTP Mail Server Host Name”
  Enter the SMTP Port Number (usually 25).
  Click on the button “Set”.


Step No 3 In the Subsequent Screen… enter the following informations.
Address Areas :- To which all address (domains) the mails can be sent.
“*” means emails can go to any E-Mail Addreses, while *yahoo.com means the mails can go to only to users in the yahoo.com domain

Step No 4
  Go to the menu option
View -> Jobs
In the subsequent Screen, Click on the Create Button

Step 5
In the subsequent screen, enter some job name.
Step 6 In the subsequent screen, Click once on the “SAP&CONNECTALL” and double click on the button “Schedule Job”.

Step 7 In the subsequent screen
  Click on the Button “Schedule Periodically” and select how often the Background job should run (mostly every 5 minutes)
  Click on create button

A new node will appear in the Jobs screen.
In Tx Code SM37, check whether the New Job, is scheduled or not.

sábado, 15 de abril de 2017

General Customizing Settings of the Availability Check

Purpose

The purpose of this page is to explain the customizing and important settings of the availability check.

Overview

    • General settings
    • Checking group - transaction OVZ2
    • Material Master - transaction MM02
    • Scope of check - transaction OVZ9

Customizing of the Availability Check in ERP

The first prerequisite in order to be able to carry out an ATP check is to set up a checking group and to assign it to your material in the material master.
The checking group you can create in transaction OVZ2:
Let us have a closer look at the different settings of the checking group:
Fields ’TotalsSales’ and ’TotDLvReqs’ is a setting that determines where and how requirements of sales and shipping documents are stored. ’TotalsSales’ is for sales documents and’TotDLvReqs’ is for deliveries. You have to decide whether you would like to store single or summarized requirements. SAP recommends to use single requirements. Single requirements are stored in table VBBE. Single requirements means that for every single schedule line a record will be created in table VBBE. If you are using summarized requirements then they are stored in table VBBS. Here you will get one record for several sales order items that lie e.g. on the same date. Table VBBS has no information about the document number and this table is used in transaction MD04 and Co09 to display the requirements of sales and shipping documents. VBBS has been introduced when memory was limited and expensive. Nowadays there is not much reason to use summarized records. If you do not maintain these settings then no requirements will be created as the system does not know where to store the requirements. So in order to have a transfer of requirements you have to fill in these fields.
There are some cases when the requirements are written into VBBE even if according to this customizing you suppose to find them in VBBS. These are the cases when necessary information would be lost if they were written in VBBS. In case of dynamic assembly process but also other scenarios with special stock (SOBKZ), APO-checked materials, ICON check and MRP areas only individual requirements can be written.
The next setting ’Block QtRq’ is one of the blocking concept that is available in the ERP system. SAP recommends to set this setting here in transaction OVZ2. During the ATP check blocking ensures that the same available quantity cannot be allocated several times when doing the ATP in parallel sessions. There are 2 blocking concepts for availability check: 1. Hard block:  in transaction OVZ1 set the indicator ’Block’ (TMVFP-VFPSP). In transaction OVZ2 the indicator ’Block’ (TMVF-ACENQ) is not set. During the availability check, the material is blocked for other users. The block remains until the transaction has been saved. If you have performed an ATP check in one session but you haven't saved the order yet then in parallel sessions it is not possible to perform an ATP check. I.e. parallel processing of the same material is in general not possible. A parallel ATP check will give the result: ’No availability check can be carried out for material Message no. V1082’   2. Soft block: in transaction OVZ2 the indicator ’Block’ (TMVF-ACENQ) is set. In this case the hard block in transaction OVZ1 TMVFP-VFPSP is not relevant whether it is set or not.) Set this block if you want several users to be able to process the material simultaneously in different transactions without blocking each other. If you have performed an ATP check in one session but you haven't saved the order yet then the ATP data are written in an enqueue record into the enqueue table (table ATPENQ) on the enqueue server. In parallel sessions an ATP check reads these records and take them into account. The lock entries should be deleted when you are leaving the transaction. Thus, parallel processing of the same material is possible and the ATP-check gives meaningful results. SAP recommends to use the soft block.
When setting the flag for ’No check’ then the ATP check is not carried out.
The setting for 'Accumulation' is a very important setting. It can avoid over confirmation situations. SAP recommends to use accumulation ’3’. The accumulation is important for two different things. The first is that dependent on this setting the system can behave differently when creating or changing the document. When setting accumulation to the recommended value ’3’ then the system will take into account required quantities when creating the document. What does this mean exactly? The system checks whether the required quantities of the documents can be covered by the stock and receipt elements. If not then you will not be able to confirm a new sales order when creating. When you change the document then the system checks whether the confirmed quantities can be covered by the stock and receipt elements. If yes and further available quantity remains then you will be able to confirm a further requirement. To make it more clear please check the following example.
Stock   100                required quantity       confirmed date
Sales order 1                          100                        0        
When accumulation is set to ’3’ then you will not be able to confirm a further requirement because the system checks with required quantities. Sales order 1 has a requirement of 100 and is so blocking the 100 on stock. There is no further available quantity for a further requirement during creation. When you create a further sales order e.g. sales order 2 with quantity 60 nothing will be confirmed. When you save the sales order and you reenter it and you carry out a new ATP check then you will receive a confirmation. While changing the ATP check is carried out with confirmed quantities. Sales order 1 has no confirmed quantity so 100 are available when you change sales order2 and you carry out a new ATP check.
If accumulation is set to ’1’ then system checks with confirmed quantities during creation and changing. Please check the F4 help in the ERP system for the field accumulation.
The second thing for which accumulation is important is to avoid over confirmation. Please check the F1 help in the ERP system. It provides you an example that highlights what can be happen when you do not use accumulation.
Please also have a look at the example below which provides you a graphical description how an over confirmation can happen when moving receipt elements on the time axis.
The next setting ‘Response’ controls whether you receive an information message when carrying out the ATP check that you have a shortfall. The message that is raised is: The sum of the requested quantity exceeds the sum of stock items (Message no. VV041)
The last setting ’RelChkPlan’ controls whether for a component the check against planning should be carried out.

The checking group has to be assigned in the mateial master. You have two options to maintain this int he material master. On the view ’Sales: General/Plant’ and the ’MRP 3’ view.
 



The second prerequisit for the ATP check is the checking rule. The checking group together with the checking rule establish the scope of check which can be maintained in transaction OVZ9. Further information regarding the checking rules you will find on the pages with the application specific settings like e.g. SD/LE specific settings. Now we will have a closer look to the scope of check.
In the scope of check you can control which stocks, receipts and issues should be considered during the ATP check. Please check the F1-help of the different fields. In this documentation only some of the settings will be explained that sometimes are misunderstood. ‘StockIn Transfer’ is often mixed up with the stock in transit. The stock in transit cannot be considered in the ATP check. When doing a two step (goods issue and goods receipt in two different steps) transfer posting via e.g. transaction MIGO then we are talking about stock in transfer. So in this case you post the goods issue into the stock in transfer and later on you post the goods receipt out of the stock in transfer. When you work with stock transport orders then you can create a delivery for the stock transport order. When you post goods issue for the delivery then depending on the movement type you can post it into the stock in transit. Later on when you post the goods receipt for the stock transport order you can post it out of the stock in transit into your stock. So in case of stock in transfer you only do a transfer posting. In case of stock in transit you have MM and LE documents for which you post goods issue and goods receipt.
‘W/o subcontracting’ controls not only the subcontracting stock but also the subcontracting requirements. There is no possibility to separate this. When you include the subcontracting stock then automatically the subcontracting requirements are included.
Regarding ‘Check without RLT’ there is Knowledge Base Article  2135782 - Calculation of the Replenishment Lead Time which explains exactly how the calculation happens. When you are checking ATP with RLT then everything that lies after the replenishment lead time will get a confirmation independent of whether you have available stock or not.
‘No stor.loc.inspectn’ deactivates ATP check on storage location level. If batches are involved then also the batch/storage location level will not be checked. The ATP check is carried out only on plant level and in case of batches also on batch level.
In the material master you can set whether a storage location should be planned separately.
If you plan a storage location separately then the setting ‘No stor.loc.inspectn’ has no effect. In this case the ATP check is only carried out on storage location level and in case of batches also on batch/storage location level. The setting in the material master overrules the setting in the scope of check.
‘Incl.Purchase Orders’ controls whether you would like to include purchase orders. It also controls the stock transport order on the receiving side. When you maintain value ‘X’ then purchase orders are considered and stock transport orders are considered with the whole requested quantity. This means e.g. you have a stock transport order with a requested quantity of 100 and a confirmation of 60 then on the receiving side 100 will be considered as receipt. Setting the value to ‘A’ the system will consider only the confirmed quantity on the receiving side. Considering our example the system will consider 60 as receipt. This setting has no effect on transaction MD04. In MD04 you will see the whole requested quantity on the receiving side. In the MM customizing you have a setting that controls also transaction MD04 in this regard. Further information you will find in Knowledge Base Article  2195518 - Everything about stock transport orders and the ATP check
‘Incl. dependent reqs’ controls whether you want to include the requirements of the planned order components. In planned orders there is no automatic ATP check. You have to trigger the ATP check manually by pressing the availability check button.


‘Include Reservation’ includes the material reservation that can be created via transaction MB21. This setting is not relevant for reservations for components of a production order. Also in material reservations you can carry out an ATP check.


‘Incl.ship.notificat.’
 controls whether you would like to consider shipping notifications. Please consider that shipping notifications are automatically considered when you include purchase orders ‘Incl.Purchase Orders’. So this setting is only relevant when you do not want to consider purchase orders but you want to consider shipping notifications. Please consider Knowledge Base Article 1890026 - Shipping notification in the availability check
‘Incl.depen.reservat.’ controls the requirements for components of production orders. If you want to consider them then you have the option whether you would like to consider all reservation or only reservations that come from already released production orders. The last one is controlled by the value ‘A’ -Only include withdrawable reservations.
‘Incl.rel.order reqs’ controls the requirements of stock transport purchase requisitions and orders (supplying side)





Related Content

Related Documents
Related SAP Notes/KBAs


Fonte: https://wiki.scn.sap.com/wiki/display/SD/General+Customizing+Settings+of+the+Availability+Check

ATP Customising

Purpose

The purpose of this page is to explain how ERP ATP check is customized.

Overview

Essential steps and methods for customising ERP ATP Check.

Requirement types and requirement class determination

The system allows the standard search strategy and two alternate search strategies. This is helpful for the customers that wish to base their requirements type/class on the sales process (triggered by the item category) rather than being limited by using only the planning characteristics of the material (= production process).

Standard search strategy

The system uses a series of checks to determine the requirements type. The sequence of checks are called a search strategy.
 First, the system will look for a Strategy Group. This is maintained in the material master (MRP view). The requirements type is defaulted from the strategy group in OPPT. The details of thestrategy group can be viewed within transaction OPPS.
 If there is no strategy group maintained, then the system looks at the MRP group, from the material master. The plant and the MRP group are used to determine the strategy group, which will determine the requirement type (using the method described above).  This configuration is found within transaction OPPU.
 If there is no strategy group and  no MRP group exists in the material master,  the system will then look at the material type as maintained within transaction OPPR. MRP group = Material type.  The system will use the MRP group information to derive the strategy group, etc, as described above.
 If there is no strategy group and no MRP group in the material master, and no MRP group equals the material type, then the system will look at the Item Category and MRP Type to find theRequirement Type. This is configured within transaction OVZI. It is also possible to have configuration with the Item category + BLANK = requirements type within the table.
 Finally, if the system has been unable to determine a requirements type by using the steps above, the system will leave the field blank in the sales document.

Alternate search strategies


Item category and MRP type (1)
 The standard search is performed and the entry from OVZI (Item category + MRP type) is used as the Requirements type even if this is not a valid requirements type from the standard search. It is still possible to enter different requirement types manually, since more than one valid requirement type is possible because there can be several Strategies within a Strategy Group.
Item Category and MRP Type with validity check (2)
The standard search is performed and then the Requirements Type from OVZI (Item Category + MRP type) is used ONLY if it is valid from the standard search method. If the entry from OVZI is not valid then the requirements type derived from the standard search method is used.
If the Item Category + MRP type combination cannot be found on transaction OVZI, you can add a new entry on the customizing transaction VOV5. 
Note: If you want to find the requirements class without checking the configuration, go to the schedule line screen and hit ‘/H’ and check contents of XVBEP. The fields are BDART and PLART. The fields must be combined to get the actual requirement class.
 Example
BDART = 04
PLART = 1
Requirement class = 041

Illustration of ERP ATP Customizing.

1.Material Master: relevant fields: 
  • MRP1 View:  MRP type, MRP group.
  • MRP3 View :   Strategy Group.
  • Sales org. 2:  Item Category Group
2.DEBUGGING: relevant fields:
  • xvbap-pstyv = Item Category
  • xvbap-bedae = Requirements Type
  • xvbep-bdart + xvbep-plart = together in this order show Requirements Class

Detailed Customising for Required for Sales order

Related Content

Related Documents

Related SAP Notes/KBA

Fonte: https://wiki.scn.sap.com/wiki/display/SCM/ATP+Customising

sexta-feira, 14 de abril de 2017

Transfer of Requirements

Purpose

The purpose of this page is to explain how the transfer of requirements works in SD / LE side and what needs to be checked in case of problems realted to the transfer of requirements.

Overview

Requirements are generated in SD side if you create e.g. a sales order, delivery... etc.
Requirement is a set of data which includes the information which quantity of which material at which date is required.
The transfer of requirements controls which sales and/or delivery requirements should be written to table VBBE or VBBS.

Typical issues and their solution

Regarding requirements transfer, the following issues can happen:
  • sales documents & deliveries are not displayed in transaction MD04, CO06 & CO09
  • entries in table VBBE / VBBS are not created
  • system confirms more than available
  • ATP Check does not consider confirmed sales orders & deliveries.
     
There are various reasons that can cause the above described problems, namely:
  • wrong customizing
  • inconsistencies
  • fixed date & quantity in combination with 0 confirmation
  • transfer of requirements for sales documents and deliveries is not relevant anymore.
To tackle a requirements transfer related issue, the following actions should be carried out:
STEP 1 – checking the settings in the schedule line category:
In transaction VOV6, if the field "Req./Assembly" is switched off, the transfer of requirements will not be carried out.

STEP 2 – checking the settings in the requirements class:

In transaction OVZG, if the field "Req. transfer" is switched off, transfer of requirements will not be carried out.
STEP 3 – checking the settings related to requirements class determination:

If the system cannot find a requirements class, the transfer of requirements will not be carried out. A requirements class needs to be assigned to a requirements type (transaction OVZH). In case of sales documents, table VBAP / field BEDAE contains the requirements type. In case of delivery documents, table LIPS / field BEDAR LF contains the requirements class. If one of the previously mentioned fields is empty (does not get filled), you need to check your customizing and/or user exits. For more information on how the requirements class is getting determined, please consider SAP Note 207942 - MRP: Problems with requirements from sales order/delivery.
STEP 4 – checking the settings related to availability check control:

In transaction OVZ2, there is an option to determine which type of records should be used for the requirements transfer by maintaining column "TotalSales" and "TotDlvReqs".
The user can choose from 4 different options:
A = Single records
B = Total records per day
C = Total records per week, reqs date on Monday of current week
D = Total records per week, reqs date on Monday of fol. week
In case of single records (A), requirement entries will be added to table VBBE. In case of summarized records (B,C,D), requirement entries will be added to table VBBS. SAP strongly recommends to use single records instead of summarized ones. This option shows document/item/schedule line numbers in transaction MD04, CO06 & CO09, while the setting summarized records does not have this option (for more information on this behavior, please consider SAP Note 1649669 - Sales order number or delivery number is not displayed in transaction MD04). Please note that if "TotalSales" and "TotDlvReqs" fields are not maintained, the system will not be able to determine which table (VBBE or VBBS) should be used, therefore the transfer of requirements will not be carried out.
STEP 5 – checking order probability related settings:

Order probability is calculated by two variables. The first variable is the "Order probab." field in the Customer Master (transaction XD02).
The second variable is the "Probability" field assigned to the sales document type (transaction VOV8).
The probability on item level is calculated by multiplying these two variables. In case of quotations and inquiries, if the calculated order probability equals to 0, no requirements transfer will be carried out. This setting only applies for quotations and inquiries, and has no effect on sales orders. You can check the order probability for a sales document in table VBAP, field AWAHR.
STEP 6 – checking the document settings:

• If the Fixed date & quantity indicator is set and the concerned schedule line has no confirmed quantity, no transfer of requirements will be carried out.
• If the Fixed date & quantity AND the credit check is activated, and the customer exceeds its credit limit, the system will change the confirmed quantity to "0" during saving the document, therefore no transfer of requirements will be carried out.
• If the Fixed date & quantity, the Delivery block and the Confirmation block is set, the system will change the confirmed quantity to "0" during saving the document. Please, read the related SAP Note 1642465 - Transfer of requirement of sales documents even though delivery or credit block is set.
• If the reason for rejection is set, no transfer of requirements will be carried out.
• Deleted sales order and delivery items are erased from table VBBE & VBBS, therefore these documents are not displayed in transaction MD04, CO06, and CO09 anymore. Delivery documents disappear from table VBBE & VBBS after posting Goods Issue.
STEP 7 – looking for inconsistencies:

For information on how to search for & eliminate inconsistent / obsolete lock entries that can have a negative impact on availability check, please check the WIKI page titled Inconsistencies.

Related SAP Notes/KBAs

 Fonte: https://wiki.scn.sap.com/wiki/display/SD/Transfer+of+Requirements