> For the complete documentation index, see [llms.txt](https://docs.theconfigteam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.theconfigteam.com/prebilt-for-im-wm-strm/applications/general-postings-migo-and-vlmove/functions-and-features.md). # Functions and Features {% hint style="info" %} **Note** This Functions and Features page contains differing sections of useful, additional information and topics related to each app which may be of a functional or technical nature. {% endhint %} ## Bypass posting screen You can by-pass the posting screen in the General Postings app for both posting via the basket or posting immediately if you don't need to enter any material document header fields. This is achieved by removing ALL the fields in the AMD from the INPUT\_\*\*\*\*\_POST screen. The system then default the system date for both the posting and document date for the material document. {% hint style="info" %} **Note** If you want or need to enter header fields then, as of release 5.8.0, you can now add the header fields (i.e. those usually entered in the posting screen (INPUT\_\*\*\*\*\_POST)) into the item input screen (INPUT\_\*\*\*\*\_ITEM) and use the "post immediately" action. You are not able to use the basket functionality with these header fields. {% endhint %} ## Posting period closed for current date This feature can be used generally in test SAP systems if it is required to add items to the basket in the General Postings app BEFORE being able to specify a posting date in the past. This is generally required when the open posting period has not been rolled over and so is not valid for today's date. The posting date field PSTNG\_DATE can be added to the INPUT\_\*\*\*\*\_ITEM screens so that a date in the past can be entered on the screen and the item added to the basket. This does not store the date entered in the basket - it is only a way to allow items to be added to the basket. When the basket is posted then the user will have the usual header details determined on the posting screen (if the AMD for INPUT\_\*\*\*\*\_POST is setup) where they can edit the posting date if allowed or if the posting screen is being by-passed then the system will attempt to use today's date as default. ## Displaying of stock on hand For displaying the stock quantity in General Postings the following setup is required: 1\. For standalone General Postings or jumps to General Postings, the fields ORIG\_QNT and ORIG\_UOM can be used in the AMD together with the field class /TCTM/WM\_APP\_513\_FIELDS. This will display either the IM stock level or if the LQUA storage bin is provided, the IMB stock level (for that bin) or if the LQUA storage bin AND storage type is provided, the WM stock level (for that bin). 2\. To support this feature, in the standalone version of General Postings, it is now possible to define the storage bin field LQUA-LGPLA (to be used for WM and IMB) and the storage type LQUA-LGTYP (for WM use only) in the INPUT\_\*\*\*\*\_MATERIAL screen - then when on the INPUT\_\*\*\*\*\_ITEM screen the app will display the WM or IMB stock rather than the MB52 stock. {% hint style="info" %} **Note** This does NOT work for the "reservation" transactions and for this a different setup is required in AMD: the fields MB52-MENGE and MB52-MEINS together with field class /TCTM/WM\_APP\_513\_FIELDS needs to be defined. It is not possible to show any WM or IMB specific stock levels as the WM and IMB bins would be unknown since they can't be entered before getting to the screen INPUT\_\*\*\*\*\_ITEM. {% endhint %} ## Stock records (technical) Developers should note the following for use in any custom field class or enhancements: For items being processed in Inventory Management (IM) storage locations, the MB52 structure and table MB52\_T will be added to GT\_DTA and the LQUA records will NOT. For items being processed in Warehouse Management (WM) or IM Multi-bin (IMB) storage locations, the LQUA structure and LQUA\_T table will be used to hold the stock data. This allows you to determine whether to use MB52 data or LQUA data depending on whether we are in IM or WM/IMB. ## Image and signature capture {% hint style="info" %} **Note** As of release 5.9.0 it is now possible to capture some images and a signature as you are processing in the general posting app transactions BEFORE the material document is created and then those images and signature will be attached the material document AFTER it is created. A new app catalogue number 609 has been created to support this with two app transactions which will be delivered for you to reference, namely, *PB2\_CAP\_IMAGES* and *PB2\_CAP\_SIGN*. {% endhint %} There are several options available for the setup in the AMD which you can make after the initial installation: * The images and/or signature can be made "optional" and accessed from either the item input screens or once at the final input posting screen. * The images and/or signature capture can be made "mandatory" and will then be requested whenever the user attempts to post either an item with "post immediately" or posting from the basket. ### For "optional" image or signature capture Add either or both of the following actions (as shown) into either INPUT\_\*\*\*\*\_ITEM\_ACTIONS and/or INPUT\_\*\*\*\*\_POST\_ACTIONS depending on when you want the users to be able to access the capture options: * SIGNATURE - for accessing on-screen signatures. * IMAGE\_CAPTURE - for uploading image files or taking a picture.
### For "mandatory" image or signature capture This is controlled by adding appropriate entries (as shown) into the CALL\_TRANSACTION\_\*\*\*\* element: * Activity = IMAGES which maps to the appropriate image capture transaction, for example *PB2\_CAP\_IMAGES.* * Activity = SIGNATURE which maps to the appropriate signature capture transaction, for example *PB2\_CAP\_SIGNATURE.*
If a signature or image has not already been captured via the optional avenues then the user will be forced to do so before the material document gets posted. ## Integrating with WM There are a couple of different ways that General Postings transactions can be used in WM and some constraints: * The individual movement types being posted can be set in AMD to either create the transfer orders after the posting which may or may not need confirming, or find the automatically created transfer orders that need confirming. * If transfer orders need confirming then General Postings will jump to a suitable Stock Movements transaction (set in the AMD of General Postings). * If the transfer orders (whether created by the app or automatically in SAP) do not require confirming then the app does not jump to Stock Movements. * Currently, if General Postings is creating the transfer order then it will only be confirmed automatically if the "Propose TO confirmation" is set in the WM configuration for the movement type. Development in an enhancement point would allow you to change that logic. * For the transfer orders being created by General Postings it is possible to specify the storage type and bin from which the stock will be removed or placed into, or these fields can be left blank in which case SAP placement / removal strategies will determine the exact storage type and bin. * If the storage type and bin are being entered during the General Postings processing or were carried over from a jump from Stock Enquiry app then you need to make sure that the automatic transfer order creation is NOT active for the movement type being processed, otherwise they will be ignored. * If you are not jumping from Stock Enquiry app then you can enter the storage type and bin directly in the standalone versions of General Posting. This is achieved by capturing the storage type and bin in either of the input screens (INPUT\_\*\*\*\*\_MATERIAL or INPUT\_\*\*\*\*\_ITEM) during processing. On the material input screen the fields to be used are LQUA-LGTYP and LQUA-LGPLA. Technically, this data is then copied as initial values to the fields LAGP-LGTYP and LAGP-LGPLA on the item input screen and subsequently copied into the BAPI structure for posting. {% hint style="info" %} **Note** As of release 5.9.0 the storage type can be automatically determined from the bin or bin verification code entered if the bin exists in only one storage type. This is controlled by setting the usual 513 field class to the bin field. If more than one storage type is found that has the same bin number then you will be forced to manually select / enter the storage type in the storage type field. {% endhint %} * Whether or not a transfer order is created automatically in the background after a posting made by the PreBilt General Postings transaction depends on the settings in the WM-IM movement type interface configuration: IMG > Logistics Execution > Warehouse Management > Interfaces > Inventory Management > Define Movement Types > LE-WM Interface to Inventory Management
* If the General Postings app is to create the transfer order then the "Immediate TO Creation" indicator must NOT be set to "A" (which is the setting for automatic TO creation). This allows PreBilt to then control the transfer order creation. {% hint style="info" %} **Hint** If it is required to support both automatic TO creation if users are processing the posting directly in the SAP GUI but not when posting via PreBilt, then a suitable "Special Movement Indicator" can be configured to allow the mapping in the above table to support both ways. The "Special Movement Indicator" could be mapped to "no" automatic TO creation and it be set up in the AMD of the appropriate General Postings screen to be defaulted with the required value. {% endhint %} * General Postings integration with transfer order creation or jumping to Stock Movements app is controlled by assigning the appropriate "\*\_TO" class in the AMD to the movement type being processed. For example, if the usual class for the movement being processed is "/TCTM/WM\_APP\_513\_GRPROD\_IM", then the transfer order integration is with class "/TCTM/WM\_APP\_513\_GRPROD\_IM\_TO".