DC1 v12 Highlights

This is made possible via the new Work with sales orders, Header, all lines discount details panel (for the new Discount type = A (All lines discount)) which is accessed by clicking the new All lines discount function key on the Work with sales orders, Header, discount details panel when in Add mode.

On the new Work with sales orders, Header, all lines discount details panel you define the Discount ID, Discount percentage you want to apply, and the panel value for Add/replace which denotes how to handle any existing discounts for the existing sales order lines.

The following panel value codes are available:

• 0 – Add the new All lines discount
• 1 – Replace all existing line discounts
• 2 – Replace all existing manual line discounts

Any defined A-discounts can be changed or deleted. The change/deletion will automatically be updated on all lines.

The number series to use is defined under Default and replacements for group AUTOGEN, level NUMBER, and keys BP_TYPE_1, BP_TYPE_2, BP_TYPE_3, BP_TYPE_9.

• Send details of pick list such as weight, volume and address to carrier software.
• Receive and process freight amount to sales order header or create sales order line based on a fictitious item code.
• Receive back tracking numbers from carrier.
• Log details of what was sent and received in the interface.

The system has been prepared to handle a connection to a third-party software for freight fee calculation. This includes the following:

• Application External Interface (AXI): Used to activate/deactivate the shipping software interface to Iptor.com. This encompasses the following:

  – Installed CARRIER SHIPPING Additional product for the DIS application in Work with additional products that must be activated on the Work with companies, Additional products panel for the applicable company.

  – New SHIPPING AXI Group in Work with AXI’s that contains the following activated AXI’s: CREATESHIPMENT, GETFREIGHT, and MANUALFREIGHT.

When the CARRIER SHIPPING Additional product has been activated, the set-up is minimal.

Impact at sales order entry

The system initiates the following new fields on the Work with sales orders, Order header, Add info 3 panel:

Fre inv hld
This field indicates if the creation of the invoice should be held until freight information has been received from a third-party software through the Carrier shipping interface. The field is initiated with Yes and is automatically changed to No when freight information has been received. This field can also be manually changed.

Downl to shp
This field indicates if the sales order shall be included in the Carrier shipping interface, meaning the order can be sent to a third-party software that handles the shipping and freight fee. The value is initiated from the sales order type but can be changed for the order.

Impact at Pick list confirmation

When the Carrier shipping interface function is active:

1. The program will call the CREATESHIPMENT AXI to send shipment information (i.e., customer delivery address, terms of delivery, etc) to a third-party shipping software IF the sales order is defined for Download to shipping.
2. Via the new CARSHIP_xx Direct Job, (where xx = the company code), the GETFREIGHT AXI waits for a reply.
3. When received, the program reads through the shipping response file and processes the responses. Processed responses will be updated to the sales order and package information files. Depending on the set-up for the carrier shipping information for the Terms of delivery, the Freight fee will either be updated to the sales order header or a new order line with a fictitious item representing the freight will be added to the order.
4. The order is released for invoicing.

Manual entry of freight info

Via the new Carrier shipping interface, manual freight fee menu item, (called via the MANUALFREIGHT AXI), carrier shipping information can be manually entered for an order. This function can be used for locations without shipping software as well as for testing the interface.
The information entered will be added to the inbound interface file and will be processed in the Carrier shipping direct job, and subsequently update the sales order.

To handle situations for MDC transit orders, where the intermediate delivery point is located abroad, a new type of warehouse is now supported. This is achieved via the new Auto pick mdc trnsit field in Work with warehouses. By setting this field to Y, the applicable warehouse will be flagged as a Fictive MDC transit warehouse, and the MDC order lines will never end up on any outbound shipment. When receiving an MDC transit order into such a warehouse in the demanding company, the pick list will be automatically created and confirmed.

When this function control is activated the following applies:

• The system will not populate the invoice reference and invoice document type on a credit sales order.
• These fields will be protected (i.e., no entry of values in these fields will be allowed).
• No warning message related to blank invoice reference for credit order will be displayed.
• The auto settlement field (OHAUST) will be set to NO.

A new MDSKIPFP (MDC direct, skip fee panel) function control has been added to provide the choice of displaying or not displaying the fee panel in the demanding company. If this function control is activated, the fee panel will not be displayed in the demanding company when leaving the sales order if all lines are MDC direct deliveries.

Now transport times can be defined in the demanding company, via the new Work with customer BtB dir transp times table, to facilitate being able to define end customer unique transport times for MDC direct deliveries, as well as transport times from an external supplier (non-MDC) to an end customer. The set-up is: From supplier (which also can be an external supplier (Non-MDC BtB direct), to end customer.

When a direct BtB (MDC or against external supplier) sales order is entered in demanding company, transport time is retrieved from the new table to the order.
Transport time is transferred to the corresponding purchase order. If MDC, transport time is also transferred to the corresponding sales order in the supplying company. Note: The transport time can be changed on the order in both companies, and changes will update the corresponding order in the supplying/demanding company.

To accommodate this new regulation, Pharma serial number functionality is developed. This allows the possibility to keep serial numbers for batch items, on each unit activated for an item. This means that if a user scans the serial number for, e.g., a whole pallet, the system will know the serial numbers for all inner boxes down to the serial number for each specific piece of unit.

Pharma serial number handling is available in all processes that affect stock. Each action for a Pharma serial number is saved in the Pharma serial number history. This makes it possible to follow the history for a specific serial number allowing tracking to see from where it was purchased and to which customer it was sold.

• Invoiced purchase price is now displayed in the sub-file.
• Possibility on a purchase order line to directly call P/O matching enquiry – Matched invoices.

This enhancement includes:

• Purchase price lists – Functionality to create price lists and allowing item purchase prices for the same supplier but for different price lists.
• Purchase pricing methods – Functionality that allows flexible set-up of purchase prices and discounts using DIS control keys; similar to the existing Sales pricing methods functionality. Note that Purchase pricing methods does not include all functionality that exists for sales pricing methods. For example, it will only be possible to create methods for types N (Normal) and C (Chain discounts).
• Limit dependent pricing – Purchase price 1 – 5 are removed and replaced with the same type of limit dependent pricing that is exists for sales pricing. This allows the system to handle an unlimited number of quantity or amount limits, each holding a specific price or discount.
• Purchase line discounts – Discount percentage fields 1 – 9 are removed. Instead, the functionality for adding discounts to, e.g., a purchase order line is changed to work in the same way as it works for sales order lines. This will allow the system to handle an unlimited number of discounts for, e.g., the PO line, and it will be possible to mix discount percentages with discount amounts.

Note: This enhancement is also applicable for the substitute item functionality.

This is made possible by the enhanced functionality in Item cross reference maintenance, whereby the user can now enter the Unit and Conversion factor for types RE and SU. If these values are entered, they will be used to convert the ordered quantity into stock unit and then calculate the new quantity for the replaced/substituted item.

Example for replacement item (Type = RE)

Item 1 and Item 2 are the same items, but differ in how they are sold (i.e., Item 1 is sold in packages of 100 (stock unit = P100), and Item 2 is sold in packages of 500 (stock unit = P500)). Item 2 is the most popular and often out of stock.

In the Item file maintenance, Item cross references, add panel for Item 2, you would enter the following:

Type = Re
Cross ref item = Item 1
Unit = P100
Conv factor = 0.2 (To convert one package of 500 into one package of 100, the conversion factor needs to be 0.2)

With the above set up, the system will suggest to replace Item 2 with Item 1 if Item 2 is out of stock.

Sales order line entry:
The customer wants to order two packages of Item 2. When creating a sales order line for Item 2 with Quantity = 2, and no stock is available, the system will automatically suggest to replace item 2 with 10 packages of Item 1.

• Select item functionality has been implemented for the Item selection field. This means that all types of cross reference values will be allowed to be entered to find matching item.
• When a selection value is entered that results in only one PO line, this line will automatically be selected for reception.
• If the reception program ends with F12, the sub-file is now re-displayed. In previous releases, the program continued with the next selected sub-file record.

• Only backlogged lines – When set to YES, the system will only re-plan SO lines that are flagged as backordered (OLROCO = Y)
• Only in stock – When set to YES, re-planning shall take place only based on quantity in stock, i.e. the re-planning will not consider any quantities from not received purchase orders.

The following changes/enhancements have been implemented:

• Time axis rebuild function can now be run any time of the day without having to close the system for other users.
• Selections have also been introduced allowing the rebuild to be performed for a single warehouse and/or item.
• Additional accumulators like, e.g., Quantity delivered not invoiced, and Quantity in quality control have been added, allowing the update of these additional accumulators in the item/warehouse file.

• A new Sort by item and Sort by order function key has been added giving you the possibility to toggle between order and item sequence.
• A new Sort by item View control field has been added allowing you to determine which type of sequence should be the starting sequence.

Severity code ‘5’ (Dispatch date moved forward) has been introduced. A sales restriction with this severity code will require a maximum quantity limit to be defined. Exceptions are not allowed to be defined for a sales restriction with this severity code.

When a sales order line is entered and a sales restriction with this severity code is found (and the order line quantity is above the restriction limit), a warning message will be displayed and the dispatch date for the order line will automatically be set to the first date outside of the planning time (i.e. the dispatch date will be delayed). This will happen regardless of the quantity that exists in stock.

The new SRST5DAT (Sales restr sev 5 date adjust) function control can be used together with this new functionality. This function control will, if active, set the Date adjustment flag on the Order header to YES for the order if a sales restriction with severity code 5 is found for an order line. This means that all order lines will be updated with the same dispatch date as the order with the latest dispatch date.

For the Date adjustment flag to be set to YES, the following stipulations must be met for the order lines on the order:

• The order lines are not BtB lines with a direct delivery.
• The order lines are not attached to a pick consolidation.
• All order lines must have the same warehouse.
• All order lines that are defined for Shipment preparation, must be attached to the same outbound shipment.
• All order lines defined for Shipment preparation must have handling/hazard codes that can be shipped together.

The Sales re-planning routine has also been updated for this functionality. Any order lines that have the dispatch date set to be outside the planning time are prohibited from being re-planned back to their requested date.

1. The Close and update option, making it possible to restrict authority for the running of a stock count update. This is done via the addition of the following:
   • New “STKLCLO” authority routine.
   • The new authority routine has been attached to the existing “WWOPTION” authority group.
     Note: By default, all users will have authority.
     To revoke authority for any user, add new entry in Objects/Routines/Users under the WWOPTION authority group. Object used should be “DMR670” and Routine should be “STKLCLO”.
2. The Create list option, as well as for the multiple add function. This is done via the addition of the following:
   • New “STKLCRT” authority routine.
   • The new authority routine has been attached to the existing “WWOPTION” authority group.

     Note: By default, all the users will have authority.
     To revoke authority for any user, add new entry in Objects/Routines/Users under the WWOPTION authority group. Object used should be “DMR670” and Routine should be “STKLCRT”.

1. First, if the same purchase order and same purchase order line exists for the reception note, then the first 3 text lines from this PO line will be searched and displayed. If text does not exist on the PO line then the PO header text will be searched, and the first 3 text lines will be displayed on the panel.
2. If there are multiple and different PO lines for the reception note which are displayed on the screen, then the first 3 text lines are searched only from the purchase order header (not PO lines). If text is found for the purchase order header then the first 3 text lines will be displayed on the panel.
3. If there are multiple purchase orders for the reception note then text will not be displayed on the panel.

In addition to the modification above, the item and description columns are now displayed in separate columns on the detail panel.

1. Suppliers
2. Items
3. Orders
4. Receptions
5. Shipments

Account Receivable

• Retrieve A/P DI INVOIC
• Retrieve financial transactions, A/P invoices

• New selection code = 6 has been added for the Supplier invoice number selection field. If this code is used, the system finds the documents with the Supplier invoice number containing the indicated text string. The selection code 6 for the field has also been added for the A/P transactions enquiry template to re-define the selection pattern for the field. If it is indicated for a template applied for A/P transactions enquiry, only one selection field for the Supplier invoice number is shown and no selection code is available. A string search is performed for the value entered in the selection field.
• New columns have been added on Settlement-related panels to display, e.g., Supplier invoice number and Bank reference number.
• On the A/P transactions overview and A/P transaction detail panels, the eWorkflow id that is set for the transaction is displayed if the EWF application is active.
• On the A/P transactions overview panel, a new column has been added to display the Description of the transaction’s Terms of payments.

Business partner number for the G/L transactions, which are not related to A/* transactions, can be either manually entered or loaded into the new field in the system transfer file for G/L postings.

Business partner number for the G/L transactions, which are related to an A/* transaction, is automatically updated by the system with the Business partner of the corresponding A/* transaction and cannot be changed.

A new Work with additional G/L summary keys table has been created to define whether summarized transactions should include the Business Partner file in the set of summary fields or not. If the control record, preloaded at system installation, is activated the summation is performed over identical Business Partner numbers.

Note: A new Update additional G/L summary keys utility program has been enabled to update the Business partner file for already existing General Ledger transactions related to A/* transactions (posted prior to this release). For summarized transactions, the field in the G/L transactions log file is updated. For non-summarized transactions, the field is also updated in the G/L transactions file.

Processing details

Business partner number can be indicated in the following routines:

• Enter financial transactions, G/L transactions entry
• Work with standing orders: The Business partner can be entered in the new Business partner field on the Standing order detail maintenance panel.
• Import of G/L transactions from Integrator – new field in the supported Excel and XML file format.
• When loading transfer data into the G/L postings transfer file.
• Work with journal in errors, G/L transactions: The Business partner number is displayed on the panel and can be edited for G/L transactions that are not related to an A/R or A/P transaction.

Business partner number, inherited from the base transactions, is populated by the following routines to be updated in the G/L transaction files at Journal update:

• Enter financial transactions, A/* invoice and A/* payment entry.
• Journals maintenance, G/L postings for A/R and A/P transactions.
• Copy/Eliminate G/L journals: The business partner entered for a G/L transaction is also updated for the corresponding transaction of the Copied/Eliminated journal.
• Automatic created pricing, calculation/redistribution transactions.
• Retrieve financial transactions, import of accountings for A/R and A/P transactions: The Business partner number field is added to the G/L postings transfer file. It can be indicated for G/L postings which are not related to an A/R or A/P transaction.

Business partner number, if indicated, is updated into:

• G/L transactions log file (SROLOGGL)
• G/L transactions file (SROPST), for non-summarized transactions
• G/L transaction file (SROPST), for summarized transactions if the control record in the Work with additional G/L summary keys is activated.

Enquiries

It is now possible to select and sequence on Business partner number and to indicate whether G/L, A/R or A/P ledger postings should be selected when one enquires on G/L transactions. The Business partner number and its internal name are displayed on the transaction overview panels. The applicable enquiries include:

• G/L transactions enquiry
• G/L transaction voucher enquiry
• G/L transaction detail enquiry

Printouts

It is now possible to select and sequence on Business partner number and to indicate whether G/L, A/R or A/P ledger postings should be selected when printing G/L transactions. The Business partner number and its internal name is printed, if requested for the printout. New specification fields are added. The applicable printouts include:

• G/L transactions enquiry list
• G/L transaction list
• G/L transaction log list

Sundry invoicing

The XML syntax is the one defined for the UBL invoice/UBL credit note and described in the PEPPOL BIS Billing 3.0 document published on https://docs.peppol.eu/poacc/billing/3.0/.

PEPPOL BIS is based on EN 16931, and the specification is a compliant Core Invoice Usage Specification (CIUS) of EN 16931.

The system processes an XML invoice document creation at SIP and at DIS invoice printing in the same way

The XML document creation embraces the following processes, served by Iptor.com, Integrator and APERIO web services:

1. Sending a notification (Iptor.com) after a new invoice is created in DIS or SIP modules.
   Data base triggers are used to enable the notification.
2. Receiving the notification about new invoice is awaiting XML creation (Integrator)A dedicated APERIO method is created to get this info.
3. Getting the requested invoice data from Iptor.com (Integrator)
   Dedicated APERIO methods are created to communicate with Iptor.com and to get the invoice data.
4. Creating an XML document (Integrator)
   The XML format is the one defined by PEPPOL BIS Billing 3.0

To provide the core elements of an electronic invoice the following new tables/fields/group have been created/added:

• Work with VAT categories (New table)
  This new table holds the set of available VAT category codes that are preloaded for the GEN application. For each VAT handling code (if it is to be applied at electronic invoice creation) the VAT category must be indicated.
• Work with VAT handling codes (New field)
  The VAT category field has been added to support e-invoicing for SIP and DIS invoice. If a VAT handling code is to be applied for an e- invoice a VAT category must be indicated.
• Work with sundry invoice line categories (New table)
  This new table stores valid codes to be set for sundry invoice lines. It is primarily to distinguish the charge/allowance from item lines, as they are defined as different core elements with different validation rules.
• Work with sundry invoice codes (New field)
  The Invoice line category field has been added allowing you to set a default value. Valid codes are defined in the Work with sundry invoice line categories.
• Default and replacement (New group)
  To enable translation of certain internal codes used in the system to the codes which are to be used for an electronic invoice, a new E-INVOICE Electronic invoice group has been added to this table. The following two Levels are defined for this group:
  • UNIT_CODE Invoiced quantity unit code:
    Unit codes used in the system can be translated here to the codes valid for electronic invoice, i.e., to the codes from UN/ECE Recommendation 21 or UN/ECE Recommendation 21
  • VAT_EXEMPT VAT exemption reason code
    For an electronic invoice it is mandatory to indicate exemption reason code or exemption reason text. Note: VAT exemption reason code will be written to the XML document, if required.

    Internal Iptor.com code is the one entered in the VAT text code field in the VAT handling codes table.

    All the required internal VAT text codes should be translated here to the valid VAT exemption reason code, i.e., to the codes from the CEF VATEX list.

    The valid codes can be found here:

    https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/Code+lists

• Purchase order number
• Purchase order line

G/L entry (AR/AP) template

• The attribute code “D” (= Default text from the A/R (A/P) document) is new and is valid for the Text field. If indicated, then the text of the corresponding A/R (A/P) document is defaulted for postings manually registered on the G/L postings entry for A/R (A/P) documents panel.

A/P invoice entry template

• • Attribute code X (already present for Document type field) is now valid for the following attribute fields:
    • Customer/Supplier
    • Terms of payments
    • Currency
    • Attestor

It indicates that the dependent fields should be completed with default values, replacing already entered/defaulted.

Customer number – dependent fields

• Cost centre
• Currency
• Terms of payments
• Due date
• Bank reference number (if FROM or TO BP is defined with RF Creditor Ref = Y)
• Trader country
• Debtor VAT country
• VAT registration number
• Import/Export code
• EU VAT rep act code

If Customer is changed the dependent fields are overwritten, highlighted and an information message is sent notifying the user about the override.

Supplier number dependent fields are same as for CUSTOMER plus Attestor.

Terms of payments dependent fields

• Due date

Attestor – dependent fields

• Cost centre

Currency – dependent fields

• System amount (Amount is system currency)

Example 1
If Customer is marked with attribute X and changed upon entry, then all the dependent fields are overwritten with new default values.

Example 2
If Customer is not changed but the Currency is changed then:

• If Currency is marked with attribute X the system amount is re-calculated/overwritten if entered.
• If Currency is not marked with attribute X – the current handling applies.

Work with A/P payment proposals create payment order file
If the Payment status report field is Y for selected payment mode, a record is created in the new IFS log file after the XML file pain.001 has been stored on IFS.

Work with A/P payment status reports
When the first Payment status report file, pain.002, for a specific payment proposal is processed, the system deletes the IFS XML file pain.001 and the related record in the IFS log file. Note: The IFS file pain.001 is not deleted from the Back-up folder, if it exists.

See also Reorganise IFS log file.

Work with A/R payment proposals create collection file
If the Payment status report field is Y for selected payment mode, a record is created in the new IFS log file after the XML file pain.008 has been stored on IFS.

Work with A/R payment status reports
When the first Payment status report file, pain.002, for a specific payment proposal is processed, the system deletes the IFS XML file pain.008 and the related record in the IFS log file. Note: The IFS file pain.008 is not deleted from the Back-up folder, if it exists.

See also Reorganise IFS log file.

Set-up
The Iptor.com set-up that is required to execute data transfer from an Excel file (new process) is the same as the one required for transfer from an XML file (existing process).

Iptor.com transactions, to be included in the VAT declaration/EU VAT sales report, are selected based on the transactions’ Voucher date, i.e. the Voucher date is considered as the transaction’s TAX point (or to be exact: as the point in time VAT can/should be posted according to the VAT regulations).

Functionality has been implemented when writing and selecting records for INTRASTAT declaration. An Intrastat reference date field has been added in the Countries table, allowing the following values:

• V = Adapted to VAT (Voucher/Goods reception date)
  This value means that the Voucher date should be used as the INTRASTAT reference date when selecting transactions to be reported on the EU INTRASTAT declaration for this country. If there is no invoice, then the Goods reception date is used, as in the previous release. The voucher date to be used as the INTRASTAT reference date is either the voucher date of the concerned invoice or the voucher date of the matching transactions.
• S = Standard (Invoice/Goods reception date)
  This means that current handling (prior to this release) applies when selecting transactions to be printed on EU INTRASTAT declaration for this country. (i.e., the invoice document date or reception date is to be used).

Accounts Receivable

Upon import of DIS sales invoices to Financials, the instalment numbers already allocated at DIS Invoice printing are used when creating and posting Instalment documents in Accounts Receivable.

Accounts Receivable

Account Payable
If you do not receive any A/P Status Report, you have a possibility to clean-up in the IFS log file.
See also IFS log file and automatic deletion of the XML 20022 CreditTransfer Initiation file pain.001.001.0x stored on IFS.

Accounts Receivable
If you do not receive any A/R Status Report, you have a possibility to clean-up in the IFS log file.

See also IFS log file and automatic deletion of the XML 20022 CustomerDirectDebitInitiation file pain.008.001.02 stored on IFS.

(New functionality) If the Structured Remittance Information information is disabled for the selected Credit Transfer scheme, and the supplier is set for Structured Remittance Information, the XML file pain.001.001.0x reports the references as Unstructured Remittance Information

As in previous releases, the bank reference number is reported in the sub-element Creditor Reference Information, if active.

(New functionality) The supplier invoice number is reported in the sub-element Referred Document information, if active. Otherwise, in the sub-element Creditor Reference Information.

(New functionality) A/P text for on-account payments is reported in the sub-element Additional Remittance Information, if active. Otherwise in the sub-element Referred Document information, if active. Otherwise in the sub-element Creditor Reference Information.

(New functionality) The same also applies when printing the A/P remittance advice.

• Code 0 = N in previous releases.
• Code 1 = Y in previous releases.
• Code 2 = create a unique payment for invoices/credit notes with additional payment information.
  Code 2 is only enabled for Credit Transfer/SEPA payment modes.

Note: Creation of payments to sundry supplier has not been changed.

New Y/N field to change Structured Remittance Information to Unstructured Remittance Information when there is no space in the XML file to report all reference as Structured Remittance has been added.

New fields for reporting Structured Referred document Information.

For more information, see Work with business partner A/P payment modes, Credit Transfer, and Work with credit transfer schemes.

• Add: New template handling is enabled to create a proposal. The template includes parameters for Print Control list.
• Print Control list: New template handling is enabled to Print the control list for selected proposal (replaces the old one). New selection parameters have also been added.
• Change: New field to clarify if Detail payment info exists or not.
• Payment order: The new Multiple currencies Y/N parameter, added in Work with banks, validates the currency between the payment and the bank account (our) at payment order creation. Note: The field replaces local modifications for application BE, DE and SE. See also Country Functionality, as well as Work with banks.

• New Authority (Secure) handling. Controls if the user is allowed to use selected option. For the Change option, the Authority (Secure) handling is extended. The “Message exception handling” controls if the user is allowed to maintain a document when it exists in an A/P payment proposal.
• New Bank reference number selection field.
• The local Payment code option for the FI application has been removed.
• The local JPKITM option for the PL application has been added.
• Credit transfer: When adding new additional payment information, all new fields are initiated from the Business partner A/P payment mode Credit Transfer table.

Values for Structured Remittance Information are reported in the XML if they are enabled for selected Credit Transfer scheme.

For more information, see Work with credit transfer schemes.

Now the reporting has been extended for CT in pain.001.001.03 to support the following sub-elements.

• Creditor Reference Information.
• Referred Document Information.
• Referred Document Amount.
• Additional Remittance Information.

The Creditor Ref Info field must be active to activate the other fields.

The limitation remains for SEPA pain.001.001.0x and for CT pain.001.001.02.

If the FI application is active, the system reports the references according to AOS2.

The fields replace local modifications for Scheme short name *S09, SE09 and NO09.

• Voucher type
• Document type
• Document number
• Business partner number
• Business partner internal name
• User ID

This process has now been simplified with the new Supplier prices panel to review different supplier prices, and also to transfer suggestion line to a specific supplier (with lower price). This new panel can be accessed from the Purchase suggestion line subfile as well as the Purchase suggestion line detail panels.

1. Possibility for periodic purchasing by intervals, and
2. Simulation of purchase suggestion.

When this field is set to YES, the system will calculate ROP and SST based on year forecast. When this field is set to NO the system will calculate ROP
and SST based on period forecast.

In addition, when user selects Year forecast then it is mandatory to select the method as ‘Demand Based’ or ‘Zero safety stock’, otherwise the system will send an error message.

These include the following:

mfgStructureHeader.update – Structure header
mfgStructureMaterial.update – Structure material (BOM)
mfgStructureOperation.update – Structure operation (BOR)
mfgStructureAltProduct.update – Structure alternative product(s)
mfgStructureTools.update – Structure oper tools (if more than 2)
mfgStructureMassUpd.update – Structure mass update
mfgStructureHeaderTxt.update – Header text
mfgStructureMaterialTxt.update – Material text
mfgStructureOperationTxt.update – Operation text
mfgStructureAltProductTxt.update – Alt product text

• Work with configurator attributes
  displays where used in parameters
• Work with configurator parameters
  displays where used in configuration items
• Work with configurator bill of material
  displays where used in configuration items
• Work with configurator bill of routing
  displays where used in configuration items

• 1 – One day between the orders
• 2 – Planned on same day

An additional operation-related field has also now been added on the Work with structures, Bill of material and Work with master BOM, materials panels. The new field is called Pick in operation and is used for reserving and during the actual picking of the material.

An example of a scenario for these two fields is as follows: You want to pick all material at the start of the whole manufacturing order to streamline the picking process, but at the same time you want to tell the production personnel in what operation the material will be used.

An entry in the new Pick in operation field is optional. If left blank, the material will be reserved/picked according to what is defined in used in operation as in previous releases.

The following has been added:

• Detail planning: indication if manufacturing order is part of an order network.
• When a manufacturing order that is part of a network order is rescheduled, a pop-up window will ask the planner if other Manufacturing orders that are included in the network should also be rescheduled.

This is controlled by a CMI (Contract Managed Inventory) order for a Customer Buffer Stock (CBS) inventory contract, which means that the CMI application must be active, and a Customer Buffer Stock (CBS) inventory contract must be set up and initialized in your system to utilize this functionality.

At purchase order reception, and if the project is defined with ‘Delivery via picking’, a CMI order is created for the receipt quantity defined as CBS (Customer buffer stock) to allocate the stock to the project which later is selected to be delivered from the project module. At that time a sales order is created with an order type defined with ‘stock update’. The sales order will also be attached to the CMI order which will be used during sales order pick process for the stock and CMI update.

• All items (as in previously releases, this is the mode that is first displayed when you access Work with configurator items).
• Configuration items: Only those items connected to bill of material will be displayed.
• Selectable items: Only those items without a connection to bill of material will be displayed.

To better differentiate the re-planning of late and early orders, there are now two Re-sch ind days fields. One is for late orders, and the other is for early orders.

The following stipulations apply for this new functionality:

• the sales order lines must be defined as BtB order for a manufacturing order
• the sales order line text must be defined with document *SHOPFLOOR

See also Work with banks.

The old local FI bundle handling has been removed and replaced by the standard bundle handling.

See also Work with banks.

Functionality has been implemented to support the new VAT handling legislation that came into effect on January 1, 2021. These ‘Brexit exception rules’ apply for Northern Ireland businesses that conduct inter-country trade, as well as for businesses that trade with Northern Ireland. As part of this legislation, businesses that conduct the previously mentioned trade must differentiate the VAT handling for goods and services separately.

The exception rules can result in a change of the from/to country and thereby the retrieval of new VAT handling codes. The new program is called when:

• Adding a new line to a sales order.
• Changing delivery-to country for a sales order.
• Adding a new line to a purchase order.

The set-up requirements are as follows:

Impact at Sales order entry

When adding a new line to a sales order, and/or changing the delivery-to country for a sales order, the system will check if it is a delivery from or to Northern Ireland. If such is the case, exceptions will automatically be applied to the order according to the following:

Impact at Purchase order entry

When adding a new line to a purchase order, the system will check if it is a delivery from or to Northern Ireland. If such is the case, exceptions will automatically be applied to the order according to the same rules as described above for sales orders.

See also Work with banks.

The following UI Views have been created:

– itemAdditionalInfoPharma.json
– businessPartnerCertificateInfo.json

When selling or buying controlled substances a special DEA Form 222 needs to be filled in. This form has a unique number that needs to be stored on the order header.

In previous releases, the standard order reference has been used for this purpose, and there is an existing check that the Order reference is mandatory if the order has lines with items that are controlled substances. Since the standard order reference is needed for other purposes, the following enhancements have been implemented:

• A new DEA Form 222 reference field has been added to the sales order header and purchase order header, and the check to verify if the order has controlled substances has been taken off the Order reference field and applied, instead, on this new field.
• The DEA Form 222 reference is now available in DI for sales and purchase orders (i.e., the reference can now be sent on DI purchase orders and received on DI sales orders).
• The DEA Form 222 reference can now be passed between MDC orders.
• The DEA Form 222 reference is now printed on external order related documents.
• The DEA Form 222 reference has been added to the invoice header file and to DI invoices.

A U.S. federal law requires a transaction document (TD). The TD is a document, initially in paper or electronic form, constructed by the entity selling the products and provided to the new owner. It contains transactional information and history and several statements to certify compliance with the law. The Drug Supply Chain Security Act (DSCSA) requires trading partners in the Supply Chain to pass Transaction Information (TI), a Transaction History (TH) and the Transaction Statement (TS) when finished. Referred as the “T3” human prescription drugs change ownership in a transaction (as defined in the law).

In compliance with this, and if the UPH application is activated, functionality has been implemented giving you the possibility to produce the new texts referred to as DSCSA transaction details in the system consisting of the following three parts:

• TS – Transaction statement
  Text can be entered for the new pre-loaded Document text type *NODSCSATS. Provided that at least one item on the order is defined for DSCSA transaction details, this text will automatically be retrieved once per sales order when a sales order is created and attached to the order as normal order header text.
• TH – Transaction history
  Text can be entered for the new pre-loaded Document text type *NODSCSATH. Provided that the item is defined for DSCSA transaction details, this text will automatically be retrieved for each item when a sales order line is created and attached to the line as normal line text.
• TI – Transaction information
  This is based on the Pharma information defined for the item. Provided that the item is flagged for DSCSA transaction details, this information will be created, in a new file, for each batch that is attached to the order line.

The set-up requirements are as follows:

The T3 statement can be seen as an extension to the DSCSA functionality and requires storing detailed history information for the product, like manufacturer and distributers. This to be able to show all steps in the supply chain for a product.

The T3 statement can be printed stand alone or be included on the transport note and on the invoice.

In the UPH Pharma US application, it is possible to record a state license (permission) on business partner address.

Previously, the system checked the license validity, (i.e., State permit expiry date not yet met), at sales order entry if a state license was required (State permit reqrd = Y for the business partner address). This check was done when the sales order header was created independent of what items were to be sold on the order.

To minimize any restrictive timing of this check, functionality has been implemented allowing the system to only perform a check if/when items requiring a state license check are added to the order.

The following has been implemented:

• A State license required Y/N field has been added on the Item file maintenance, Pharma information panel denoting if the item needs state license verification.
• The check for a valid state license has been moved from the creation of the order header to the creation of the order line. In addition, the check will now also include checking if the item requires a state license. The check for the license validity will only be performed if the item requires a state license. If the license is not valid, the order line will not be created. An error message will be displayed which will include the expiration date.
• For other orders (DI, E-commerce), the license is validated when the order is coming into Iptor.com, and the order is put on hold if the license has expired.

See State license information displayed within SO handling, below, for additional enhancements.

The following enhancements have been implemented:

• Sales order entry has been enhanced with the prompting of the Business partner maintenance, License information panel, displaying the State license information that has been registered on the business partner address. This panel, which is only displayed when the UPH application is active, allows the CSR to review the address and certificate information before entering lines on the order.
• Additionally, a new List GPO function key is available on this panel to access the Business partner file enquiry, Customer buying groups panel, allowing the user to see the list of Active GPO’s.
• Access to the Customer Buying Groups and License information panels is also available via the new License info and GPO/Buying group function keys from any panel within Sales order entry.
• The equivalent panels can also now be accessed in the Sales order enquiry via the newly added function keys when the UPH application is active.

US regulation (21 C.F.R. § 1301.74(b)) requires manufacturers and distributors of pharmaceutical products to design and operate a system to identify suspicious orders of controlled substances and to report suspicious orders to the local DEA Field Division upon discovery.

The regulation defines suspicious orders as:

• Orders of unusual size
• Orders deviating substantially from a normal pattern
• Orders of unusual frequency

Iptor has partnered with FiveRiversRX that provides Suspicious Order Monitoring as a service. The FiveRiversRX service is called NavigateSOM. Integration with NavigateSOM has been done by calling the API’s provided by FiveRiversRX from Iptor.com.

Note: Iptor.com handles the sending part in this integration since it is assumed that the receiving part will be handled outside of Iptor.com and orders will be released, or put on SOM hold directly.

To be able to send data to the NavigateSOM interface, the following conditions must be met:

• Order must be held due to Suspicious order monitoring
• Order must be a normal invoice order
• Order must not be a service order
• Order must not be of type quotation
• Order must not be a MDC order
• Order must not be a BtB order
• Order must not be an internal order

The following has been preloaded for the UPH application:

• Two new order held reason codes, i.e., US (Under SOM) and SH (SOM hold)
• One new sales restriction key (115 = Suspicious order monitoring)

To be able to manage suspicious orders in Iptor.com, the following system and item related set-up information must be met:

• US Pharma (UPH) is active for the company.
• The new Suspicious order monitoring flag is activated in the Pharma control file.
• The new SOM API URL field in the Pharma control file is completed denoting the SOM API that will communicate with the Iptor.com system (i.e., to post the data on the External API using the URL).
• The new Suspicious order monitoring flag is set to YES for the applicable item(s) on the Item file maintenance, Pharma information panel, denoting that the item needs to be monitored for suspicious activity.
• The new panel value controlled Type of trader field is completed on the Business partner maintenance, Address file panel. The value from this field will be used when sending order details to NavigateSOM.

The standard system functionality to hold sales orders, utilizing the Sales restriction functionality, is used for SOM.

The process is as follows:

1. 1. Sales orders are recorded in the system as normal (Manual entry, DI, E-commerce, etc).
   2. Orders applicable for SOM will be held using the US hold reason code which will signify that the order is “Under SOM”, and the order will be interfaced to NavigateSOM.
      • a. Changing a sales order (adding/removing items and/or quantities) requires a new check,
      • b. Only orders that contain items that are flagged for Suspicious order monitoring will be checked,
      • c. Only orders for deliveries are monitored. Orders, e.g., for credits, price adjustments, etc are not monitored.
   3. The reply from NavigateSOM controls the next step:
      • a. If non-suspicious, the order is released.
      • b. If suspicious, the order is held with reason code SH (SOM hold), and the US (Under SOM) reason code is removed.

Existing system authority control functionality (i.e., Authority group ORDHLDRECO and routine RELSO) can be utilized on the held reason code to grant the applicable authority for release.

1. Managing the orders that are on “SOM hold” is a manual process (i.e., reporting to authorities, delete orders, etc).