I thought it was time to look at the Cloper report again. We reviewed some common errors in Sage X3: Clearing common Cloper anomalies . Let’s take a look at a few less frequent ones.

First here’s a Cloper refresher:

The Cloper is the Pre-closing verification report. This report generates a log file that identifies any controls that could block closing one or several periods. You can run the report for one or several non-closed accounting periods defined at folder level. If you run the report for a closed accounting period, it will not generate. It can be run under Reports, Reports, Reports (AIMP). It is also generated when you attempt to close periods that have issues.

Don’t forget about Memo and Recall.  Using Memos, you can save the report parameters so that you don’t have to rekey each time you run it. Just click Recall and call up the specific parameters (Sage Ent. Mgmt. Overlooked features: Memos and Criteria). 

Now let’s look at a couple of examples of errors found in the Cloper report.

$VERF_GIC Intercompany entry not validated : NA102312INT00000007

My Cloper for December shows that Intercompany entry NA102312INT00000007 has not been posted. To validate our intercompany journal entry, off we go to Financials, Journals, Intercompany journal entry. Select the entry referenced in our error message, click Post.

When I tried to validate, I received an error message: INTCO Journal not open (12/31/23) (Company DE10).

How do I fix this?

1. Go to Common data, General accounting tables, General, Journal codes (GESJOU).
2. Select the Journal code referenced in the error message (e.g. INTCO).
3. Click the Opening
4. Enter a valid Opening start date and select OK.
5. Re-attempt the transaction posting.

Now back to validating the intercompany journal entry.

Here is the log for the validation. This lists the journal entries that were created for each company.

You can also find the journal entry numbers by clicking on Accounting entries in the right box under Zooms.

These journal entries have to be moved from Temporary Status to Final Status so that the period can be closed. We can do this by going into each journal and manually changing the status or by executing Final Validation (CPTVAL) found under Financials, Current processes.

"SITE: xxxx some stock movements need to be posted."

This indicates that we have unposted shipments with suspended stock transactions.

On the Product (GESITM) record, if a product is set for "Stock < 0 authorized" (field NEGSTO) the system allows us to create and validate the shipments for such products. The product will also appear in the color green on the shipment line. The Stock accounting interface (FUMSTKACC) does not process the STOJOU table record for this stock movement until we adjust the shortage with the stock, once available.

1. Go to the function Stock Shortage adjustment (FUNSHTSEL).
2. Populate your site and product range and process OK.
3. Depending on the priority set, system will populate the list of suspended transactions, including the shipment.
4. Make sure to include your suspended shipment or any other stock transactions that needs processing.
5. Click Adjustment on right hand menu.

In the log file you will see the stock transactions processed in this action. Now, if we go back to our shipment, we will also notice that the product color on the lines has changed to black. If we run the Stock accounting interface (FUNSTKACC), the system will process this transaction. The generated journal entry will have to be moved from temporary Status to Final so that the period can be closed.

"[Site]: There is still some subcontract in process that needs to be posted"

There are a number of reasons why this may appear:

• The Batch server has been deactivated preventing the subcontract from posting.
• There are unfinished subcontract orders awaiting processing.
• There are unbalanced subcontract related journals which should be included on the WIP posting (FUNWIPACC)
• There are unfinished work orders awaiting processing or unbalanced work order related journals which should be included on the WIP posting (FUNWIPACC)
• This error can occur even if subcontract PO's and subcontract BOM's are not being used. It can indicate a Work Order process that is not yet posted.

We first want to verify the Batch server (BATCHSERVERS) is running.

Here is a Query Tool (GESALH) to help locate the problem transactions:

1. Go to Setup, Usage, Reports, Query tool (GESALH).
2. Click the New

1. Enter a Code beginning with a Z. This is to indicate this requester as a non-standard/customer created requester. For example: ZSUBCON.
2. Enter a Title and a Short title.
3. Select Active.
4. Set Represenation to Character.
5. On the Field tab make the following four entries:
   • Line 1: Table: WIPCOST - WIP valuation, Field: VCRTYP Entry Type.  Tab through the remaining fields.
   • Line 2: Table: WIPCOST - WIP valuation, Field: VCRNUM Order no. Tab through the remaining fields.
   • Line 3: Table: WIPCOST - WIP valuation, Field: TXNTYP Transaction type. Tab through the remaining fields.
   • Line 4: Table: WIPCOST - WIP valuation, Field: WIPSEQ Sequence. Tab through the remaining fields.
6. On the Advanced tab enter the following two lines in Selection criteria:
   • [F:MWI]ENTCOD<>"" and [F:MWI]GLPSTA<>2 and [F:MWI]TXNDAT<gdat$(dd,mm,yyyy)
     Note: Replace the dd,mm,yyyy with the end date being closed. Example: For period ending December 31, 2024, enter 31,12,2024 in place of dd,mm,yyyy
   • [F:MWI]VCRTYP=36
7. Click Create, then Validate.
8. To run the requester, click Run then Search. Prior to running the requester, verify and adjust the date in the formula on the requester's Advanced tab.

Using the Query tool:

• The purpose of this query tool is to retrieve records from the WIPCOST WIP valuation table. Where:
  • The automatic journal code has been assigned but the record has not posted.
  • The transaction date is less than the date entered, gdat$(dd,mm,yyyy), on the formula.
  • The Subcontract as the entry type.
• The date must be formatted as: gdat$(Day,Mon,Year).
• Verify and adjust the date on the formula before running.
• Each time you make a change to the requester, you must Save then Validate.
• Each time you run the Query tool, you must select Run then Search.
  • If you only click Run, you will see the data saved from the last search.
• Use the results to isolate the unvalidated transactions.

If you forget to complete the gdat$(DD,MM,YYYY) formula with a date such as gdat$(31,01,2024), clicking Search will leave you an Information message:  ------------------- Error -------------------

@SEED.TRT/WMMZSUBCON$adx (20)

Variable Non-existent

DD

To get past the error, return to the Advanced tab, fill in the period. Click Save, Validate and Run to update the query.

If you enter the date and miss a comma, you will receive an error: “Type incompatibility gdat.” Again, return to the Advanced tab, fill in the comma. Click Save, Validate and Run to update the query.

I hope this helps your close go smoothly.

 Take care my X3 friends. Stay safe!