Purchase Requistion#
General#
The purchase requisition (BANF) is a module that is used to manage materials that are not relevant to the article master. Examples are marketing materials, work clothes, etc..
The purchase requisition represents a separate process with release regulations (workflows), which do not run via the article disposition (order worksheets).
In a purchase requisition, items can be entered as pseudo-articles for G/L accounts. Buyers can process the purchase requisitions analogous to the known purchase order worksheets in purchasing and trigger a corresponding purchase order via the event message.
Note
The purchase requisition (BANF) is an activation module, which can only be used with an additional license and activation in the module setup.
Institution#
Purchase requisition facility#
The purchase requisition for the institution can be called up via the user search. The following contents are stored in the purchase requisition setup:
Information Register General#
Field | Comment |
---|---|
Standard purchase order type | The order type for presetting the purchase orders is selected in this field. |
Department Code | Global Dimensionscode 1 (in Microsoft Dynamics Business Central™ these are usually the departments) |
Cost unit code | Global Dimensionscode 2 (in Microsoft Dynamics Business Central™ these are usually the Cost Unit Code) |
Information Register Number Series#
Field | Comment |
---|---|
Number series | The number series for the creation of the purchase requisition is managed in this field. |
Information Register E-mail Notification#
Field | Comment |
---|---|
E-mail notification | If the switch is active, the e-mail notification for the BANF is activated. |
Rejection email to | Here you can select whether the message should go to the previous approver or to all persons involved in the process. If the field remains empty, no one is notified. |
Release text module | Contains the default text to be included in the notification email in the approval workflow. |
Text module Rejected | Contains the default text to be included in the notification email in the approval workflow in the event of a rejection. |
Text module order | Contains the default text to be included in the notification email in the approval workflow in case of order. |
Reminder interval | The reminder frequency is entered in the field, in which the person who has to process, release or reject the BANF is to be reminded. |
Email account#
In the purchase requisition process, there are approval processes where people set up in the system are notified by email. For this purpose, either a standard e-mail account can be created in Microsoft Dynamics Business Central™ or a specific one for the purchase requisitions, from which the notifications are sent. For the specific account, you can select the BANF scenario via the "Assign scenario" call.
Permit User Facility#
A permit administrator and a permit flow code are stored in the permit user facility:
The approval administrator has all rights to execute the various functions of the BANF Application. Only one user can be the approval administrator; the checkbox must be activated for this user.
Users who use the BANF Application should already be assigned an approval process code here. Since the code defines the approval process as well as the approvers, it is mandatory for the approval process. It is automatically carried over from the approval user facility into the document when the BANF is created. Already here there is the possibility to store and assign an approval process according to the section "Approval Processes" by diving into the field "Approval Process Code". The approval process code must be selectable in the document at the latest, otherwise the requisition cannot be sent due to missing approval processes. If necessary, however, the user can change the code in the purchase requisition process, for example, if he/she requests as an employee in the company, e.g. for different cost centres, or if a different approval process is required.
An email address must be entered so that notifications can be sent to the appropriate persons, if necessary also as a collective email address if several persons are involved in the approval process.
In addition, there is the possibility to store a deputy from the user institution. This person must also have a valid email address for the process to work.
Field | Comment |
---|---|
User ID | Indicates the ID of the user. |
Sales/Purchaser Code | Here you can select the code of the seller/buyer for your own user ID. |
Approver ID | The user ID of the approver who must approve BANF created by the user from the User ID field is entered here. |
Limit amount for sale | Specifies the maximum amount (sale) that the user may authorise. |
Unlimited sales permit | Check here if the approver is not bound by any maximum amount for approvals. If the check mark is active, no value can be stored in the field "Limit amount for sale". |
Limit amount for purchase | Specifies the maximum amount (purchase) that the user may authorise. |
Unguaranteed purchase permit | Check here if the approver is not bound by any maximum amount for approvals.If the check mark is active, no value can be stored in the field "Limit amount for purchase". |
Limit amount for enquiry request | Specifies the maximum amount (requests) that the user may authorise. |
Unlimited request authorisation | Check here if the approver is not bound by any maximum amount for approvals.If the check mark is active, no value can be stored in the field "Limit amount for purchase". |
Deputy | Indicates the possible deputy of the approver. |
An e-mail address must be stored here for each person involved in the approval process. Collective addresses can also be used instead. | |
Telephone no. | Indicates the telephone number of the user. |
Approval administrator | The approval administrator has all rights to execute the functions in the BANF module. For this purpose, the checkbox must be ticked. |
Permit expiry code | The code for the respective approval procedure is stored here. |
Approval processes#
To set up the approval procedures, first call them up via the user search.
Approval processes define the number and authorisations of the approving persons or departments in the process.
A new approval procedure can be added to the overview via "New" in the menu ribbon. Alternatively, existing approval processes can be edited here:
Field | Comment |
---|---|
Code | A code for the corresponding approval procedure is assigned here. |
Description | A description that is as self-explanatory as possible serves to identify the respective approval process. |
Number of approvers | The number of approvers results from the approvers deposited for the expiry. |
All approvers for the approval procedure are stored via the function key "Approver" in the menu ribbon. The approvers of an approval procedure can be determined from the user set-up or existing approvers can be edited.
Field | Comment |
---|---|
Approver ID | Specifies the user from the user facility who is to participate in the approval process. |
Name | The name is preset from the user setup of the selected user. |
Level | Sets the numerical order in which approvers are notified or approve. Several persons can be included in the same level. They are then notified at the same time. |
Approval limit | The respective approver is only notified if the amount of the purchase requisition in the process exceeds the value deposited here. |
May edit | Determines whether the respective approver may process the BANF document. |
May refuse | Determines whether the respective approver may reject the purchase requisition. |
Notify at WG/plant | If this field is activated, the approver will be notified in any case for purchase requisitions that use the type "WG/plant" in the lines. |
Note
If you have KUMAVISION project365 in use, an approval process is stored in the "Setup Projects". More information about this topic can be found here.
Master data#
Pseudo article#
In addition, text modules can be stored for each pseudo article, which are transferred to the purchase order. For this purpose, the function call "Text modules" is available in the menu ribbon. Subsequently, a new text module can be created via "New" in the menu ribbon or an existing text module can be edited via "Edit".
The following fields are available in the pseudo item card:
Field | Comment |
---|---|
No. | Is a mandatory field and must be filled in. |
Description | Name of the pseudo article. |
Description 2 | Another line to designate the pseudo-article. |
G/L account | Only those G/L accounts can be selected here that can be posted on the purchasing side ("Directly in purchasing" = Yes). |
Description G/L account | Displays the description stored for the G/L account. |
Creditor no. | An already existing creditor can be selected here. |
Credit item no. | The respective article number of the creditor is stored here. |
EK price | A purchase price per unit can be entered here. |
Unit code | Defines the purchasing unit. |
Department Code | Specifies the global dimensons code 1 if required. (in Microsoft Dynamics Business Central™ these are usually the departments) |
Cost unit code | Global Dimensionscode 2 (in Microsoft Dynamics Business Central™ these are usually the Cost Unit Code) |
Number of text modules | Shows how many text modules are stored in the pseudo-article. Clicking on the number displays the text module overview. |
In the purchase requisition process, the purchase requisition lines are pre-filled with the information of the pseudo item card.
Note
If you have KUMAVISION project365 in use, pseudo articles are currently not supported in the project budget. More information about this topic can be found here.
Pseudo article text modules#
In addition, text modules can be stored for each pseudo-article, which are transferred to the purchase order. The function call "Text modules" in the menu ribbon is available for this purpose. Subsequently, a new text module can be created via "New" in the menu ribbon or an existing text module can be edited via "Edit".
A text module can be used for a limited period of time by entering a start and end date. If it is to be automatically inserted into the vouchers, the option "Automatic" must be selected in the field "Use in voucher text". The field "Position in voucher text" determines whether the text module is to be printed before or after the line.
The selection fields of the text module lines are used to decide on which document the text module is to be printed.
Pseudo Article Purchase Prices#
With the function call "Purchase prices" in the menu ribbon of the pseudo-article there is the possibility of an extended price maintenance. Here, time-controlled prices with start and end dates can be stored depending on minimum quantities, but also prices and price scales of alternative suppliers:
If price records of several or alternative suppliers are stored here, it is also possible to store the different vendor article numbers on the price record. The preassignment from the pseudo article card in the lines of a purchase requisition can then be overwritten with these values in the "Vendor no." field.
Functionality#
Create BANF#
To create a new requisition, call up the requisitions via the user search and click on "New" in the menu ribbon to create a new requisition.
An empty purchase requisition card will open.
Information Register General#
By pressing the ENTER key in the "General" tab, the system automatically assigns a new voucher number.
With the function call "Remarks" in the menu ribbon, relevant notes can be added to the process:
The fields in the "General" tab have the following meaning:
Field | Comment |
---|---|
No. | The system automatically draws the next higher document number after the ENTER key is pressed. |
Order date | Automatically defaults to the current date. |
Due date | In the ordering process, the due date represents the desired, the planned and the expected goods receipt date. It should therefore be supplemented. |
Approval code | If available, is preset from the authorisation user facility. If this is not the case, a code must be stored here. |
Causes code | To be able to execute the "Reject" function, a cause code must first be selected. |
Department Code | Specifies the global dimensons code 1 if required. (in Microsoft Dynamics Business Central™ these are usually the departments) |
Cost unit code | Global Dimensionscode 2 (in Microsoft Dynamics Business Central™ these are usually the Cost Unit Code) |
Status | Indicates the document status in the approval process and is automatically continued in the process. The following statuses are possible: • Open • Waiting for release • Rejected • Create order |
Created by | Pre-populated by the user creating the purchase requisition. |
Created on | Indicates the date and time the voucher was created. |
Corrected on | Indicates when the document was last corrected. |
Corrected from | Indicates by whom the document was last corrected. |
Level | The number next to the field indicates how far the operation has progressed in the approval process. Clicking on the blue coloured number shows the order of the approvers. |
Remarks available | Click on the blue link to see which remarks have been added to the purchase requisition. |
Total Amount Net | Is the sum of the individual item values recorded in the rows. |
Note
If the "approval code" has not already been preset from the approval user facility, it is mandatory to select it here, otherwise the BANF cannot be sent due to missing approval processes.
The permit code is created as described in the section Permit User Setup and Permit Procedures section.
Information register BANF lines#
The desired items of the purchase requisition can now be entered in the BANF lines. All lines of the type "G/L account", "Article", "Resource" and "WG/Facility" are permitted, whereby articles should be ordered via their MRP data and the order proposal.
It is now possible to select pseudo articles instead of G/L account, article or WG/plant. If a pseudo article number is entered in the line without first determining the type, the system automatically changes the "Type" field to G/L account and specifies the G/L account number stored for the pseudo article in the "No." field.
Finally, the quantity is entered. The system then determines the valid cost price for the vendor from the pseudo article number card or a price scale stored for it from the pseudo article purchase prices (if stored). The same applies to prices for lines with the type, G/L account, article and WG/plant.
If prices or price scales of alternative suppliers have also been stored in the pseudo item purchase prices, the "Vendor no." field can be dipped into in the purchase requisition line in order to select the alternative supplier with its respective price and the associated vendor item number. In most cases, however, a separate pseudo article number is created for this due to a lack of grouping criteria.
The field "BANF URL" serves as support for the purchaser. If the requisitioner enters a link to a web address, the purchaser can view the information and conditions for the item on the Internet. All he has to do is click on the function "Open URL" in the respective line:
Once all the information has been entered, the purchase requisition is sent to the first approver by clicking the "Send" button in the menu ribbon:
Confirm the following system message with "Yes" to start the approval workflow or click "No" to make any changes or corrections to the purchase requisition.
Note
To send the emails in the approval workflow, the SMTP server must be set up. This setup depends on the technical conditions of the environment and should have been done beforehand by the IT department of the company.
In case of correction, restart the approval workflow with the function call "Submit" in the menu ribbon and then confirm the message with "Yes".
If the value falls below a possibly set approval limit value at the approver, the purchase requisition is sent directly to the approver stored in the next level.
The approver then receives the following email notification with the request to release the purchase requisition. The approver finds the purchase requisition to be released in the system via the BANF number contained in the email; if necessary, the link to the purchase requisition contained in the email can also be used for this purpose.
Release BANF#
By calling up purchase requisitions via the user search, the approver gets to the purchase requisition to be released. In the overview, he can see the status of the requisition sent to him for approval.
With the function button "Edit" or by double-clicking on the corresponding line in the purchase requisition overview, the document is navigated to for editing. The approver can now continue the approval workflow via the function button "Release" in the menu ribbon so that the purchase requisition is sent to the approver in the next stage.
This continues until the requisition has passed through all approval stages and has reached the status "Create BANF" in the last stage.
However, if an approver is authorised to do so according to his approval user facility, he can also process and/or reject the UANF. For more information on rejecting a UANF, see the section "Rejecting a UANF".
Reject BANF#
After receiving the requisition email notification in the approval workflow, an authorised approver may as well reject the requisition, for example because a requisitioner is not authorised to request an asset.
To do this, the notified person goes to the requisition to be released via the requisition.
In order to be able to execute the "Reject" function in the menu ribbon, a cause code must first be selected in the "Cause Code" field of the "General" info tab. The system will otherwise return the following error:
The "Reject" function button in the menu ribbon rejects the purchase requisition.
The purchase requisition is then given the status "Open" in the document, and the creator receives an e-mail informing him that the purchase requisition has been rejected.
The creator can either edit the BANF again and then restart the approval workflow, or cancel it.
Resend BANF#
If the requisitioner has made all the appropriate changes to the purchase requisition for a successful approval, he can restart the approval workflow by sending it again. To do this, the requester simply clicks on the "Submit" function button in the menu ribbon again.
The process is continued analogous to the description in section "Release BANF".
Cancel BANF#
If the requisition has been justifiably rejected and cannot be changed by the requester in such a way that there is a chance of release, it can be terminated and archived via the "Cancel" function button in the menu ribbon:
If the subsequent message from the system is confirmed with "Yes", the purchase requisition with the status "Cancelled" is moved to Archived purchase requisitions.
With "No" there is the possibility to process the purchase requisition again.
Create order#
If the purchase requisition has been released by all approvers and the status "Create purchase order" has been reached in the last stage, the buyer goes from the purchase requisition overview to the document and executes the function "Create purchase order" in the menu ribbon.
Depending on the number of different creditors contained in the BANF, one or more purchase orders are now generated.
The creator of the BANF receives a corresponding e-mail notification.
The purchase orders contain, among other things, the following information from the purchase requisition process:
In the head:
Field | Comment |
---|---|
Assigned User ID | This is the BANF creator. |
Purchase order type | STANDARD - or depending on the preassignment in the purchase requisition Setup. |
Buyer code | Sales/buyer code - either by default from the approval user facility or code of the ordering buyer. |
In the lines:
Field | Comment |
---|---|
Planned date of receipt of goods | Due date of the BANF. |
Expected date of receipt of goods | Due date of the BANF. |
Requested Goods Receipt Date | Calculated from the Expected Goods Receipt Date |
BANF no. | Document number of the purchase requisition. |
Pseudo Article no. | Number of the pseudo article as "G/L account filter". |
Requester | Corresponds to the BANF creator. |
In the line functions - document texts:
Pre- and/or post-texts from the pseudo-article can be placed here, if necessary.
When the function "Create purchase order..." is executed, the document of the purchase requisition is completed and archived. From here on, the purchase order generated from the BANF represents the usual worklist of a purchaser.
Archived purchase requisitions#
Archived requisitions and the requisition log can be found as follows:
As soon as a purchase requisition document has attained the status "Ordered" by triggering the function "Create purchase order...", the document is archived and the purchase requisition overview is updated accordingly. In addition to the archived requisition, open purchase orders are also generated.
If a purchase requisition receives the status "cancelled" by triggering the "cancel" function, the purchase requisition document is also archived, but without triggering a purchase order. The overview of the purchase requisitions is simultaneously cleared of the cancelled PReq.
Regardless of whether an approved or cancelled BANF is archived, the archived documents can be found in the "Archived requisitions".
Purchase requisition log#
All actions are recorded in the purchase requisition log.
The purchase requisition log can also be called up from the place described in the section Archived purchase requisitions. However, it is also possible to view all process steps that have taken place so far at several points in the purchase requisition process via the function call "Log Entries" in the "Related" tab of the ribbon:
All changes resulting from the process are documented in the purchase requisition log.