uniWIKI - User contributions [en]

Information Systems:Bank EDI

2017-01-24T22:12:56Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

Because this application was originally written for TD, Chase transactions must be translated to use the same transaction types and card types. If Chase sends a record with a new, unmapped type, it will have to be added to tables UX BEDICPCRDT or UX BEDICPTRNT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R batch payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

When more than one card type is in a batch, this process is submitted to QBATCH for each type. As each may take a moment to run, the next must wait to be submitted. The user will see this screen -

*PL/480B* A/R batch payment update 11/30/16 11:53:49 FKR05101
-------------------------------------------------------------------------------
Accounting period... 17 10
Voucher type........ 75

Document type....... MC
Voucher date........ 113016
Identity............ MC

Remarks.............

Printer queue....... PRT01
Number of copies.... 1
Hold on spool file.. N

You cannot use this function now

They must wait a moment, then press enter to try again to submit the process.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

===Duplicate File Name===

If you try to import a file with the same name as one that has already been imported, you will get a message. You should cancel the process, and investigate it. Using the 'RD' (raw data) option, look at the file that has already been uploaded. A file with no transactions will have two records; a batch header and batch trailer (record types 10 and 99).

Columns . . . : 1 121 Browse UWDASWPRDD/BECPRDP
SEU==> C170118018
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9
*************** Beginning of data *********************************************************
0001.00 1001191711440310946585 TRN
0002.00 990000000020000000000000000000000000000000000000000000000000000TRN
0003.00
****************** End of data ************************************************************

If the new file to import has the same records as the original file, it can go straight to the archive (to keep a record of the fact it was received twice). Change the name by, for example, adding 'dup' to end to make it clear it was a duplicate file.

If the two files are different, I would question the bank - there is only supposed to be one file per day, and the date is part of the file name. If the second file should also be uploaded, the file name should be changed; but using a different method than above. The files are imported with the name 'C', six digit date (from the file name), then the file suffix; which is the Julian day. To import a second file for the same date, change the file suffix to make the name unique.

Even though the import process will allow you to import a file with a duplicate name, it is best not to do it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2017-01-24T22:07:46Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

Because this application was originally written for TD, Chase transactions must be translated to use the same transaction types and card types. If Chase sends a record with a new, unmapped type, it will have to be added to tables UX BEDICPCRDT or UX BEDICPTRNT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R batch payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

When more than one card type is in a batch, this process is submitted to QBATCH for each type. As each may take a moment to run, the next must wait to be submitted. The user will see this screen -

*PL/480B* A/R batch payment update 11/30/16 11:53:49 FKR05101
-------------------------------------------------------------------------------
Accounting period... 17 10
Voucher type........ 75

Document type....... MC
Voucher date........ 113016
Identity............ MC

Remarks.............

Printer queue....... PRT01
Number of copies.... 1
Hold on spool file.. N

You cannot use this function now

They must wait a moment, then press enter to try again to submit the process.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

===Duplicate File Name===

If you try to import file with the same name as one that has already been imported, you will get a message. You should cancel the process, and investigate it. Using the 'RD' (raw data) option, look at the file that has already been uploaded. A file with no transactions will have two records; a batch header and batch trailer (record types 10 and 99).

Columns . . . : 1 121 Browse UWDASWPRDD/BECPRDP
SEU==> C170118018
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9
*************** Beginning of data *********************************************************
0001.00 1001191711440310946585 TRN
0002.00 990000000020000000000000000000000000000000000000000000000000000TRN
0003.00
****************** End of data ************************************************************

If the new file to import also looks like this, it can go straight to the archive (to keep a record of the fact it was received twice). Change the name by, for example, adding a letter to end to make it clear it was a duplicate file.

If the two files are different, I would question the bank - there is only supposed to be one file per day, and the date is part of the file name. If the second file should also be uploaded, the file name should be changed; but using a different method than above. The files are imported with the name 'C', six digit date, then the file suffix; which is the Julian day. To import a second file for the same date, change the file suffix to make the name unique.

Even though the import process will allow you to import a file with a duplicate name, it is best not to do it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2017-01-24T21:55:27Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

Because this application was originally written for TD, Chase transactions must be translated to use the same transaction types and card types. If Chase sends a record with a new, unmapped type, it will have to be added to tables UX BEDICPCRDT or UX BEDICPTRNT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R batch payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

When more than one card type is in a batch, this process is submitted to QBATCH for each type. As each may take a moment to run, the next must wait to be submitted. The user will see this screen -

*PL/480B* A/R batch payment update 11/30/16 11:53:49 FKR05101
-------------------------------------------------------------------------------
Accounting period... 17 10
Voucher type........ 75

Document type....... MC
Voucher date........ 113016
Identity............ MC

Remarks.............

Printer queue....... PRT01
Number of copies.... 1
Hold on spool file.. N

You cannot use this function now

They must wait a moment, then press enter to try again to submit the process.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

===Duplicate File Name===

If you try to import file with the same name as one that has already been imported, you will get a message. You should cancel the process, and investigate it. Using the 'RD' (raw data) option, look at the file that has already been uploaded. A file with no transactions will have two records; a batch header and batch trailer (record types 10 and 99).

Columns . . . : 1 121 Browse UWDASWPRDD/BECPRDP
SEU==> C170118018
FMT ** ...+... 1 ...+... 2 ...+... 3 ...+... 4 ...+... 5 ...+... 6 ...+... 7 ...+... 8 ...+... 9
*************** Beginning of data *********************************************************
0001.00 1001191711440310946585 TRN
0002.00 990000000020000000000000000000000000000000000000000000000000000TRN
0003.00 �
****************** End of data ************************************************************

If the new file to import also looks like this, it can go straight to the archive (to keep a record of the fact it was received twice). Change the name by, for example, adding a letter to end to make it clear it was a duplicate file.

If the two files are different, I would question the bank - there is only supposed to be one file per day, and the date is part of the file name. If the second file should also be uploaded, the file name should be changed; but using a different method.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2016-11-30T20:23:51Z

Sheilav: /* Credit and Debit Card Transactions */

Information Systems:Bank EDI

2016-11-30T20:19:30Z

Sheilav: /* Bank EDI Does Not Post */

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R batch payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

When more than one card type is in a batch, this process is submitted to QBATCH for each type. As each may take a moment to run, the next must wait to be submitted. The user will see this screen -

*PL/480B* A/R batch payment update 11/30/16 11:53:49 FKR05101
-------------------------------------------------------------------------------
Accounting period... 17 10
Voucher type........ 75

Document type....... MC
Voucher date........ 113016
Identity............ MC

Remarks.............

Printer queue....... PRT01
Number of copies.... 1
Hold on spool file.. N

You cannot use this function now

They must wait a moment, then press enter to try again to submit the process.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2016-11-30T19:59:42Z

Sheilav: /* Bank EDI Does Not Post */

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R batch payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

When more than one card type is in a batch, this process submitted to QBATCH for each type. As each may take a moment to run, the next must wait to be submitted. The user will see this screen -

*PL/480B* A/R batch payment update 11/30/16 11:53:49 FKR05101
-------------------------------------------------------------------------------
Accounting period... 17 10
Voucher type........ 75

Document type....... MC
Voucher date........ 113016
Identity............ MC

Remarks.............

Printer queue....... PRT01
Number of copies.... 1
Hold on spool file.. N

You cannot use this function now

They must wait a moment, then press enter to try again to submit the process.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2016-11-30T00:25:24Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one A/R payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extensions process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

Generate EFT from statements, and Bank EDI have been changed to check for other A/R payment batched running, but it apparently doesn't always work properly (or the A/R payment process is called from another extension).

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

====To Post Manually ====

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2016-11-30T00:19:13Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. Do not confuse this with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process. Bank files are not received automatically; The finance department uses secure services to manually get them from the banks.

There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu.

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03
__ Chase Paymentech

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

The interface name is passed as a parameter to all called programs, and controls the kind of processing done. 'CIBC' is cheque clearing; the others are debit and credit card processing.

'Files waiting' have been received from the bank and placed onto the IFS, but have not yet been imported. 'Files in error' have been imported, but something prevents them from being posted.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, then put onto the IFS. Bank EDI is used to upload it an post it to ASW.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with the bank. Because of the combined volume, uniPHARM is able to get better rates than a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases.

Transactions are summarized by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT.

As well as these A/R transactions, entries to the G/L are also made; ie. credit A/R and debit cash.

===Store Payments to uniPHARM===

The finance department has a card reader which they use to process accounts receivable payments from stores, using their credit cards. These records can be identified by the fact that the merchant ID on them matches one of the uniPHARM merchant numbers in the configuration file. The credit card account number, and card type is used to read the merchant file, and get the ASW customer number. Then a payment to that account, and the underlying G/L entries, are created.

==Cheque Clearing==

These files are used to reconcile cheques, and update the cash book. They used to be are picked up by ‘TumbleWeed’, but are now done manually by the finance department.

==Configuration==

Press F8 for configuration. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do. Press page down to see the record. Not all of the fields fit on one screen, so press enter to see the rest.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 22378885
uniPHARM CP Merchant: 6077431
TD Folder: BankEDI2/TD
TD Archive Folder: BankEDI2/TD/Archive
Chase Payments Folder: BankEDI2/Chase
Chase Archive Folder: BankEDI2/Chase/Archive
CIBC Folder: BankEDI2/CIBC
CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1
Hold?: N
Save?: N
uniPHARM TD-M Merchant: 23035553
uniPHARM CP-M Merchant: 6077431
uniPHARM GP Merchant: 999999999999
Global Payments Folder: BankEDI2/Global
Global Archive Folder: BankEDI2/Global/Archive
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

The 'folders' are the locations in the IFS where files are imported from, then archived to. 'uniPHARM Merchant' numbers are used to identify transactions where shareholders are making payments to uniPHARM via their credit cards.

==Issues==

===Masked Credit Card Numbers===

Credit card account numbers are now being sent masked; ie part of the number is replace with asterisks. That makes it easier for us, as we don't have worry about having to keep them encrypted whenever we store them. Records on the merchant file contain the masked number so that transactions can be matched. The unmasked portion of the number seem to be enough to make them unique. If it happens that they aren't, the user will be prompted by a list, and asked to select one.

===Bank EDI Does Not Post===

Only one payment process can be run at a time. Base ASW makes sure this doesn't happen. Several extension process payments without checking first to make sure another isn't currently running. Originally this was okay, because QBATCH only ran one job at a time. We changed it to allow two.

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

'''To Post Manually –'''

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

[[Category: Extensions]]
[[Category: EDI]]

Information Systems:Bank EDI

2016-11-29T23:56:53Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T22:28:11Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T22:22:12Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T22:14:01Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T22:07:37Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T22:02:17Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T21:37:17Z

Sheilav:

Information Systems:Bank EDI

2016-11-29T21:18:20Z

Sheilav:

=Bank EDI=

Bank EDI is a custom extension for ASW that allows the system to automate the processing of files received from the banks. There are two types of files; debit and credit card transactions from stores, and detail of the cheques clearing uniPHARM's accounts.

==Credit and Debit Card Transactions==

Up to November 2016, we have been using the TD Bank for all of the debit card and credit card processing. After that, we will be switching to Chase Paymentech. The files are downloaded from the bank website by the finance department, and put onto the IFS. The Bank EDI extension is accessed from Mochasoft in the (1)UWD Extensions menu and then the (70)Bank EDI menu. A data file is downloaded from the bank and uploaded into the Bank EDI extension.

At a high level the way this works is that our shareholders get debit and credit card terminals for processing payments at their store through uniPHARM's account with TD Merchant Services. uniPHARM is able to get better rates than what a store could get on their own. The terminals are set up to deposit all of the funds collected into uniPHARM bank accounts. uniPHARM then uses the bank EDI extension process to move the funds back from the uniPHARM bank accounts onto the individual store accounts to offset their purchases. If a store makes less purchases than the amount collected then are sent an EFT for the difference. Do not confuse the Bank EDI extension with regular EDI (which is how we transmit and receive POs and invoices with our vendors) as this is a completely different and unrelated process.

For technical details on this click on the following document:
\\Superserver\Systemi Documentation\Extension Manuals\{{unc | \\superserver\Systemi Documentation\Extension Manuals\Bank EDI Technical Manual V1.0.doc | Bank EDI Technical Manual V1.0.doc}}

Or you can go to:
\\Superserver\Unity\S000- UNITY Project\P0300 - Phase III Implementation\P0350 - UNITY Subprojects\UP016 -- Bank EDI Interfaces\...
...to see all of the files associated with this extension project.

Below is a screen shot of the main (70)Bank EDI menu:

12/03/14 11:48:32 uniPHARM -- PRODUCTION BERIQ030/CTL
Bank EDI Status

FI=Files imported FW=Files waiting

---------- Files ---------- Last Last
Interface Waiting Imported In error Import Post
__ TD 2254 2014-12-03 2014-12-03
__ Global Payments 577 2007-07-19 2007-07-19
__ CIBC 2131 2014-12-03 2014-12-03

F3=Exit F5=Refresh F7=Merchants F8=Configuration F12=Previous

* note that Global Payments is no longer in use *

As mentioned above, transactions from the debit/credit card machines in shareholder stores are not sent to them; they are sent to us. We summarize them by card type, and put them into accounts receivable for the shareholder. They will show on the next statement. If they make their account go into credit, we put the amount into their bank account via EFT. These transactions come from TD.

In addition to the credit / debit card processing the Bank EDI extension also allows CIBC to send us a cheque clearing file, which we use to reconcile cheques, and update the cash book.

These files are picked up by ‘TumbleWeed’, and placed on the IFS. To see where, press F8 for configuration. Press page down to see the record. Note that this is DFU, which is an uncontrolled update program. Be very careful what you do.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : BECONFR File . . . . : BECONFP

*RECNBR: 1 uniPHARM TD Merchant: 22378885
uniPHARM GP Merchant: 999999999999
TD Folder: BankEDI2/TD

TD Archive Folder: BankEDI2/TD/Archive

Global Payments Folder: BankEDI2/Global

Global Archive Folder: BankEDI2/Global/Archive

CIBC Folder: BankEDI2/CIBC

CIBC Archive Folder: BankEDI2/CIBC/Archive
Printer: LP05
Copies: 1 Hold?: N
Save?: N uniPHARM TD-M Merchant: 23035553
uniPHARM GP-M Merchant: 999999999999

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

You can use Navigator to go into these directories, and copy files to your PC to look at.

'''Bank EDI Does Not Post'''

BERUP060 – writes transactions to SROKBP

BERUP070 – updates payment batches from SROKBP (which posts 120000 and 730200), then writes transfers from 730200 to correct bank account into SROIBT
Sometimes these batches do not completely post to ASW, but instead sit in SROKBP. (The function to update payment batch is locked by ASGR007. See job name FKR051 in file SROJBN. If status is ‘A’, the job is currently running, and cannot run again now.)

If there are records in SROKBP for the current batch with identity = ‘FI’, they will have to be changed to the correct identity. For example –

update srokbp set ptiden = 'VI' where ptiden = 'FI' and ptpadt = 20121207 and ptjono = 10006

So far, when I have had to do this, the records with an identity of FI have all had to be changed to VI.

'''To Post Manually –'''

Select option 7 – Update A/R batch payments on menu ARPAY A/R Payment Tasks.

Voucher type is 75.

Document type / identity is AMX / AX, DBT / DB, DS / DS, MC / MC, VIS/ VI.
This will post to A/R and 730200. Entries to move from 730200 to the correct bank accounts will not post, but will still be in SROIBT. The next time bank EDI is posted, they will be included. However one entry will be missing, so the journal will not be balanced. See ‘Problems / Finance / Journal in Error / Out of Balance – Debit/Credit Card Transactions’ for an explanation and how to fix it.

[[Category: Extensions]]

Information Systems:TEMPORARY - things to add

2016-03-18T21:23:22Z

Sheilav:

- finish purge

- add manual Atlas transmission

- add list of overnight jobs that have to run, and how to do them manually

- lost sales - comes from IOP and ASW; when and how are they combined?

- add item availability checking

Information Systems:EOMASW

2016-03-18T21:22:53Z

Sheilav:

/* CALCULATE CLOSING PERIOD AS YESTERDAY'S PERIOD (TODAY MINUS 1) */
/* ASW doesn't handle February 29 properly, so minus 2 instead */

CHGASWLDA TYPE(*DATDZ) RELVAL(-2) STARTPOS(001)
RTVDTAARA DTAARA(*LDA (1 8)) RTNVAR(&DATEC)
CHGVAR VAR(&DATE) VALUE(&DATEC)
GETPERIOD DATE(&DATE) PERIOD(&PERIOD)
CHGVAR VAR(&PERIODC) VALUE(&PERIOD)

/* DO A 'DEMAND ADJUSTMENT' OF PROMO SALES FOR LAST MONTH */

/* log entry is 'PXDEMAND' */

CALL PGM(PXCIU356) PARM(&PERIODC &DATEC)
PXDEMAND

/* CALCULATE CLOSING MONTH, AND 6 MONTHS AGO FOR ITEM SEGMENTATION */

CHGASWLDA TYPE(*DATDZ) RELVAL(-1) STARTPOS(001)
RTVDTAARA DTAARA(*LDA (1 6)) RTNVAR(&CCYYMMA)
RTVDTAARA DTAARA(*LDA (5 2)) RTNVAR(&MONTH)
RTVDTAARA DTAARA(*LDA (1 4)) RTNVAR(&YEAR)
CHGASWLDA TYPE(*DATDZ) RELVAL(-170) STARTPOS(001)
RTVDTAARA DTAARA(*LDA (1 6)) RTNVAR(&CCYYMMB)

/* PERIOD ROLLOVER */

/* log entry is 'ROLL OVER' */

RTVASWPAR PGM(ASGC032) PAID(MONTHROLL) USER(*ALL)
EXCASWPGM PGM(ASGC032) PARM(Y) DTA('N +
NNY *DEVTYPE +
N -
')
CHGASWCOM COMPANY(VA)

/* UNIQUELY IDENTIFY QUERY REPORT SO THAT CATAPULT POLLER CAN FILE IT ON */
/* SUPERSERVER. */

OVRPRTF FILE(QPQUPRFIL) OUTQ(FINANCE/FINTEMP) +
USRDTA(REPORT1)

/* PRINT INVENTORY VALUE */

/* log entry is 'INV VALUE' */

RUNQRY QRY(STOCKST03A)
DLTOVR FILE(QPQUPRFIL)

/* PRINT A/R RECONCILIATION */

/* log entry is 'A/R RECON' */

RTVASWPAR PGM(FSC291) PAID(MONTHENDAR) USER(*ALL)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(091) +
POSITIONS(6)
EXCASWPGM PGM(FSC291) PARM(N)

/* PRINT A/P RECONCILIATION */

/* log entry is 'A/P RECON' */

RTVASWPAR PGM(FSC291) PAID(MONTHEND) USER(*ALL)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(091) +
POSITIONS(6)
EXCASWPGM PGM(FSC291) PARM(N)

/* Send both reconciliations to Catapult. Run as a rule instead of */
/* being polled, as they go into QPRINT. We don't want the poller to */
/* go through QPRINT; it's 2300 spool files now, but will just keep */
/* getting bigger. */

ADDLIBLE LIB(XL_CATAPLT)
ZRUNRULE FILE(FSR297P) JOB(*) SPLNBR(*LAST) +
RULENBR(10397) TIMEOUT(20)
ZRUNRULE FILE(FSR297P) JOB(*) SPLNBR(*LAST) +
RULENBR(10397) TIMEOUT(20)

/* ACTIVE FORECAST PERIODS */

/* log entry is 'FORECAST' */

RTVASWPAR PGM(INVC522) PAID(ACTFOREPER) USER(*ALL)
EXCASWPGM PGM(INVC522) PARM(N)

/* AVERAGE STOCK LEVEL */

/* log entry is 'STOCK LEV' */

RTVASWPAR PGM(INVC520) PAID(AVERSTOCK) USER(*ALL)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(226) +
POSITIONS(6)
EXCASWPGM PGM(INVC520) PARM(N)

/* INVENTORY SEGMENTATION */

/* log entry is 'INV SEG' */

RTVASWPAR PGM(INVC441) PAID(UPDSEGCODE) USER(*ALL)
CHGASWLDA VALUE(&CCYYMMB) TYPE(*CHAR) STARTPOS(25) +
POSITIONS(6)
CHGASWLDA VALUE(&CCYYMMA) TYPE(*CHAR) STARTPOS(31) +
POSITIONS(6)
EXCASWPGM PGM(INVC441) PARM(N)

/* UNIQUELY IDENTIFY QUERY REPORT SO THAT CATAPULT POLLER CAN FILE IT ON */
/* SUPERSERVER. */

OVRPRTF FILE(QPQUPRFIL) OUTQ(FINANCE/FINTEMP) +
USRDTA(REPORT2)

/* RUN QUERY OF ALL UNMATCHED (UNINVOICED) P.O. RECEIPTS */

/* log entry is 'UNINV PO' */

RUNQRY QRY(FINUNMATCX)

/* RUN 'TURN OF THE YEAR' FOR DIS IF THIS IS END OF JANUARY */

/* log entry is 'TURN YEAR' */

IF COND(&MONTH = '01') THEN(DO)
RTVASWPAR PGM(DMC971) PAID(ENDOFYEAR) USER(*ALL)
EXCASWPGM PGM(DMC971) PARM(N)
ENDDO

/* TAKE COPY OF SROSRO IF THIS IS CALENDAR YEAR END */

/* log entry is 'SRO YEAR' */

IF COND(&MONTH = '12') THEN(DO)
CHGVAR VAR(&FILENAME) VALUE('SROSRO' || &YEAR)
CPYF FROMFILE(SROSRO) +
TOFILE(UP1480BFVA/&FILENAME) CRTFILE(*YES)
CHGVAR VAR(&FILENAME) VALUE('SRBSRO' || &YEAR)
CRTLF FILE(UP1480BFVA/&FILENAME) +
SRCFILE(XX2480BP/QDDSSRC) SRCMBR(&FILENAME)
ENDDO

/* TAKE COPY OF SROSRO IF THIS IS FISCAL YEAR END */

/* log entry is 'SRO FISC' */

IF COND(&MONTH = '01') THEN(DO)
CHGVAR VAR(&FILENAME) VALUE('SROSROF' || +
%SST(&YEAR 3 2))
CPYF FROMFILE(SROSRO) +
TOFILE(UP1480BFVA/&FILENAME) CRTFILE(*YES)
CHGVAR VAR(&FILENAME) VALUE('SRBSROF' || +
%SST(&YEAR 3 2))
CRTLF FILE(UP1480BFVA/&FILENAME) +
SRCFILE(XX2480BP/QDDSSRC) SRCMBR(&FILENAME)
ENDDO

/* RUN PROGRAM TO CREATE WORK FILE OF OUT OF BALANCE PO'S */

/* log entry is 'OOB PO' */

CALL PGM(BAL001CL)

/*ADD ONHANDS TO STATISTICS FILE */

/* log entry is 'ONH2STATS' */

CALL PGM(BLDPERONH) PARM(' ')

/* UNIQUELY IDENTIFY QUERY REPORT SO THAT CATAPULT POLLER CAN FILE IT ON */
/* SUPERSERVER. */

OVRPRTF FILE(QPQUPRFIL) OUTQ(FINANCE/FINTEMP) +
USRDTA(REPORT1)

/* RUN SURPLUS STOCK REPORT */

/* log entry is 'SURP STOCK' */

RUNQRY QRY(STOCKST06X) QRYFILE((*LIBL/SROPRG) +
(*LIBL/SROSRO))

/* FTP INVOICE DETAIL FOR ENDING MONTH TO PHARMASAVE */

/* log entry is 'PHAFTP02CL' */

SBMJOB CMD(CALL PGM(PHAFTP02CL) PARM('00000000' +
'00000000')) USER(PHARMASAVE)

/* BUILD ORDER STATISTICS FILE (SUMORDCST) FOR IN_ORDER01 */

/* log entry is 'BLDSUMORD' */

SBMJOB CMD(CALL PGM(BLDSUMORD) PARM(&CCYYMMA))

/* FTP SALES FOR ENDING MONTH TO IMS */

/* log entry is 'TSADUMPA' */

SBMJOB CMD(CALL PGM(TSADUMPA)) USER(IMSTSA)

/* DELETE OLD TRANSACTIONS */

/* log entry is 'PURGE' */

CALL PGM([[Periodic-Purge|PURGE01]])
MONMSG MSGID(CPF0000)

/* DELETE EDI SPOOL FILES OVER TWO MONTHS OLD */

/* log entry is 'OUTQCLREDI' */

CALL PGM(OUTQCLREDI)
MONMSG MSGID(CPF0000)

Information Systems:EODRPTW

2016-03-18T21:10:58Z

Sheilav:

Runs report of inventory onhand, and validate that SROSRO (Warehouse Balance), SROITR (Inventory Transactions), WHOLOP (Location Occupancy), and WHOLTR (Location Transactions) all balance with each other. It is called by [[EODWEEKLY]].

/* Uniquely identify Query report so that Catapult Poller can file it on */
/* SuperServer. */

OVRPRTF FILE(QPQUPRFIL) OUTQ(FINANCE/FINTEMP) USRDTA(REPORT3)

/* Print onhand inventory at cost by item account group for MAI and RET. */

/* log entry is 'INV VAL 2' */

RUNQRY QRY(STOCKST03A)
DLTOVR FILE(QPQUPRFIL)

/* Compare summary of WHOLTR to WHOLOP, and summary of SROITR to summary */
/* of WHOLTR. */

/* log entry is 'BAL TRANS' */

CALL PGM(BALTRANS) PARM('UP1480BFVA')

Information Systems:EODUPDW

2016-03-18T21:09:14Z

Sheilav:

This rebuilds ASW search files, and runs IC calcs (Inventory Control calculations). It is called by [[EODWEEKLY]].

/* Calculate IC CALCS period as calendar year and month (not fiscal) */

CHGASWLDA TYPE(*DATDZ) STARTPOS(001)
RTVDTAARA DTAARA(*LDA (1 6)) RTNVAR(&PERIOD)

/* Periodic balance update */

/* log entry is 'PER BAL UP' */

RTVASWPAR PGM(DIR345B) PAID(BALUPDATE) USER(*ALL)
CHGASWLDA TYPE(*PERDZ) STARTPOS(001)
CHGASWLDA TYPE(*PERDZ) STARTPOS(007)
EXCASWPGM PGM(DIR345B) PARM(N)

/* Rebuild item search fields */

/* log entry is 'ITM SEARCH' */

RTVASWPAR PGM(DMC981) PAID(ITEMSEARCH) USER(*ALL)
CHGASWLDA TYPE(*PERDZ) STARTPOS(007)
EXCASWPGM PGM(DMC981) PARM(N)

/* Rebuild name search fields */

/* log entry is 'NAM SEARCH' */

RTVASWPAR PGM(GDMC981) PAID(NAMESEARCH) USER(*ALL)
CHGASWLDA TYPE(*PERDZ) STARTPOS(007)
EXCASWPGM PGM(GDMC981) PARM(N)

/* Inventory calculations */

/* log entry is 'IC CALCS' */

RTVASWPAR PGM(INVC401) PAID(ICCALCS) USER(*ALL)
CHGASWLDA VALUE(&PERIOD) TYPE(*CHAR) STARTPOS(226) +
POSITIONS(6)
EXCASWPGM PGM(INVC401) PARM(N)

Information Systems:EODREBLD

2016-03-18T21:04:52Z

Sheilav:

This rebuilds/updates master and statistic files used by Web Orders and InfoNet. These are built as part of the overnight processing instead of when a user requests the information. This also clears work files and spool files. It is submitted to QBATCH by [[EOD]], to run after the restricted state has ended; about 5:00AM.

/* clear files and folders for Web Orders */
/* there are some Unix commands run in Qshell that sometimes fail, so */
/* submit it to batch. If it doesn't complete, it won't affect the end */
/* of day - but the image and specification in Web Orders may not be */
/* correct. */

/* log entry is 'WSOVERNIT1' */

SBMJOB CMD(CALL PGM([[WSOVERNIT1]])) JOBQ(QS36EVOKE)

/* Build consolidated item master file (XXITEMP). This must run before */
/* Web Order files are rebuilt. */

/* log entry is 'XXITEMP' */

CALL PGM(ITEMINFOCA)

/* rebuild files for Web Orders */

/* log entry is 'WSOVERNIT2' */

CALL PGM([[WSOVERNIT2]])

/* Run End of Day housekeeping. */

/* log entry is 'EODCLR' */

CALL PGM([[EODCLR]])

/* Build summary file of lost sales */
/* (ITEMSTAT uses this file, so this has to run first) */

/* log entry is 'SUMVENLST' */

CLRPFM FILE(SUMVENLST)
CALL PGM(BLDSUMLST)

/* Rebuild item statistics file (XXSTATSP) */

/* log entry is 'XXSTATSP' */

CLRPFM FILE(XXSTATSP)
CALL PGM(ITEMSTAT)

/* Rebuild promo results files (for InfoNet) */

/* log entry is 'PXRESBUILD' */

CALL PGM(PXRESBUILD)

/* Build summary file of sales (including brand) by customer */
/* (for IN_CUSTSLS) */

/* log entry is 'BLDCSTSL2' */

CALL PGM(BLDCSTSL2) PARM(' ')

/* Build summary file of freight vs sales (current and previous month) */

/* log entry is 'BLDSUMFRT' */

CALL PGM(BLDSUMFRT) PARM(' ')
CALL PGM(BLDSUMFRTP)

/* Build summary file to validate Analyser */

/* log entry is 'BLDANAWRK' */

CALL PGM(BLDANAWRK)

/* Search for duplicate keys in ANOSTK */

RUNQRY QRY(ANOSTKCNT1) QRYFILE((*LIBL/ANOSTK))
RUNQRY QRY(ANOSTKCNT2) QRYFILE((*LIBL/ANOCOUNT))

/* Build file of sales order pattern - sales by the hour */

/* log entry is 'BLDORDLIN' */

CALL PGM(BLDORDLIN) PARM(' ')

/* Build file of sales order statistics by day */

/* log entry is 'BLDDAYLINF' */

CALL PGM(BLDDAYLINF)

/* Build file of PO fill rates */

/* log entry is 'BLDPOFRT' */

CALL PGM(BLDPOFRT) PARM(' ')

/* Build file of sales and budget by item account group */

/* log entry is 'BLDSLSBUD' */

CALL PGM(BLDSLSBUD) PARM(' ')

/* Build summary file of lost sales by warehouse */

/* log entry is 'SUMWHSLST' */

CLRPFM FILE(SUMWHSLST)
CALL PGM(BLDWHSLST)

/* Build file of VEBA by province by day */

/* log entry is 'BLDVEBA' */

CALL PGM(BLDVEBA) PARM(' ')

/* send email that rebuild is complete */

CHGVAR VAR(&SMSG) VALUE('Statistics files rebuild +
is complete')
CHGVAR VAR(&LMSG) VALUE(&SMSG)
CALL PGM(OPMSGSEND) PARM(&SMSG &LMSG)

Information Systems:TEMPORARY - things to add

2016-03-18T20:54:01Z

Sheilav:

- finish purge

- add manual Atlas transmission

- finish 'log entries' for overnight processing

- add list of overnight jobs that have to run, and how to do them manually

- lost sales - comes from IOP and ASW; when and how are they combined?

- add item availability checking

Information Systems:ECU - Electronic Catalog Update

2016-03-18T20:53:40Z

Sheilav: /* Files */

uniPHARM used to supply a PC program called EOB (Electronic Order Book) to customers. Every week, ECU would build a file of changes to the item master file (one for each price list, as the prices would be different for each), and email them to ?. We no longer have the EOB, but we continue building change files and full catalogues every week for the POS systems, and for Web Orders.

==ECU Calendar==

Go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ010 -- Show Calendar.

3/16/16 16:11:10 uniPHARM -- PRODUCTION ECRIQ010/LISTCTL
ECU RUNNING ECU - Show Calendar Master File PRODUCTION 1.00
Display Order Field Test Values
DATEA DATE AND TIME A
Date Range Week Status AND
ST MAR 10 16 00 00 AND
Period
RH=Run History WK
MA=Main TR=Transmissions BA=Base File CH=Changes PR=Promo

Reference Week St Start/End Dates SCHED DATE PRICE DATE ADDED DATE
FU20160310 9725 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9726 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9727 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9728 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9729 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9730 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9731 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
MAR11 2016 1263 FI MAR 12 16 MAR 18 16 MAR 11 16 MAR 11 16 JUL 08 09
MAR18 2016 1264 NP MAR 19 16 MAR 25 16 MAR 18 16 MAR 18 16 JUL 08 09
MAR25 2016 1265 NP MAR 26 16 APR 1 16 MAR 25 16 MAR 25 16 JUL 08 09
APR01 2016 1266 NP APR 2 16 APR 8 16 APR 01 16 APR 01 16 JUL 08 09
APR08 2016 1267 NP APR 9 16 APR 15 16 APR 08 16 APR 08 16 JUL 08 09
APR15 2016 1268 NP APR 16 16 APR 22 16 APR 15 16 APR 15 16 JUL 08 09

F21=Scrn Reset
F3=Exit F5=Refresh F12=Previous F24=Scrn Save

This shows two things. Lines with a date formatted as MMMDD YYYY in the 'reference' column are [[Periodic-Calendar Year#Check ECU (Electronic Catalogue Update) Calendar|prebuilt]] to control the 'change' files that are created every week. The 'Week' is the sequentially numbered week since the EOB started. The last line shows, for example, that a file will be built using prices as of April 15th, to be in effect April 16th to April 22nd. Although these dates are all Fridays, we actually build the files Thursday evenings (through the job scheduler), so they will be available no matter how early stores or POS vendors want them. When command '''ECUREGULAR''' is run, it uses the first calendar record at status 'NP - not processed' - not the entry for the actual date. Which means if it is not run at all, the entry will have to manually flagged as 'FI - Finished'. Or if runs twice, another entry will have to added.

When the command '''ECUFULLCAT''' is run, a record is added to this file, with a reference starting with 'FU', then the date formatted as YYYYMMDD. The 'week' number is a sequential number that started at 7000. Around December 2016 it should reach 10000. This should not be a problem as the field is 5 digits long; but the 'Show Calendar' programs only uses 4, so may not work correctly.

==Weekly Electronic Catalog Update==

CL program ECUWEEKLY runs from the Job Scheduler every Thursday at 9:30PM. It runs –

- '''Command ECUREGULAR calling auto run ‘WEEKLYCAT’'''. It builds a file of changes the item file in the last week, for each price list (because they will each have different prices). These files are emailed to pre-set addresses, and sent to our FTP server. It also builds a change file that can be accessed by Web Orders.

- '''Command ECUFULLCAT calling auto run ‘ECUFULLCAT’''' for each price list.

- '''Program ECRUP385''' (ECU -- Generate and send full catalog files) calls ECCUP380 (ECU -- send change files to FTP server) for each catalogue built by ECUFULLCAT.

===Detail Process===

To see the details, go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ030 -- Show Auto Run Records.

3/16/16 11:53:08 uniPHARM -- PRODUCTION ECRIQ030/LISTCTL
ECU RUNNING ECU - Show Auto Run Master Records PRODUCTION 1.00
Display Order Field Test Values
NAME By Auto Run Nam
AND
AND
Date Range Status Timing
AD 00 00 00 00

MA=Main CP=Copy ST=Steps RU=Runs EX=Execute PU=Purge

Run Name and Description Ti PROGRAM START DATE END DATE
__ ECUFULLCAT FULL CATALOG -- SPECIAL RUN OR ECREX001 JAN 01 04 DEC 31 50
__ ECUPARTCAT PARTIAL CATALOG -- SPECIAL OR ECREX001 JAN 01 04 DEC 31 50
__ PROMONITE NIGHTLY PROMO EXTRACTS DY ECREX002 JAN 01 04 DEC 31 50
ST WEEKLYCAT WEEKLY CATALOG WK ECREX001 JAN 01 04 DEC 31 50

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Use option ST=Steps on run 'WEEKLYCAT'. You will have to page down to see all the steps.

3/16/16 11:59:15 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
WEEKLYCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
100 CREATE BASE FILE REGUL *ALL WEEKLYCAT ECRUP010 BASE
101 CREATE WEEKLY CHANGES FILE REGUL *ALL WEEKLYCAT ECRUP050 EXTR
120 CREATE WEEKLY PRICE CHANGES REGUL *ALL WEEKLYCAT ECRUP055 PRICH
130 CHECK FOR ANY TRANSMIT LIMITS REGUL *ALL WEEKLYCAT ECRUP060 TSIZE
150 CREATE BC SH PRICES REGUL SHARE-BC WEEKLYCAT ECRUP350 TFORM
200 CREATE BC NS PRICES REGUL NON-SH-BC WEEKLYCAT ECRUP350 TFORM
210 CREATE AB SH PRICES REGUL SHARE-AB WEEKLYCAT ECRUP350 TFORM
220 CREATE AB NS PRICES REGUL NON-SH-AB WEEKLYCAT ECRUP350 TFORM
225 CREATE PSC PRICES REGUL SHARE-PSC WEEKLYCAT ECRUP350 TFORM
230 CREATE PSC1 PRICES REGUL SHARE-PSC1 WEEKLYCAT ECRUP350 TFORM
235 CREATE YT SH PRICES REGUL SHARE-YT WEEKLYCAT ECRUP350 TFORM
250 SEND OUT WEEKLY BC SH REGUL SHARE-BC WEEKLYCAT ECRUP700 TRANS
300 SEND OUT WEEKLY BC NS REGUL NON-SH-BC WEEKLYCAT ECRUP700 TRANS
320 SEND OUT WEEKLY AB SH REGUL SHARE-AB WEEKLYCAT ECRUP700 TRANS
340 SEND OUT WEEKLY AB NS REGUL NON-SH-AB WEEKLYCAT ECRUP700 TRANS
350 SEND OUT WEEKLY PSC REGUL SHARE-PSC WEEKLYCAT ECRUP700 TRANS
360 SEND OUT WEEKLY PSC1 REGUL SHARE-PSC1 WEEKLYCAT ECRUP700 TRANS
370 SEND OUT WEEKLY YT SH REGUL SHARE-YT WEEKLYCAT ECRUP700 TRANS
531 BUILD CHANGES FILE FOR WEB REGUL *ALL WEEKLYCAT ECRUP360 BASE
601 COPY CHG FILES TO FTP SERVER REGUL *ALL WEEKLYCAT ECCUP380 BASE
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Repeat for run 'ECUFULLCAT'.

3/16/16 12:33:25 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
ECUFULLCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
10 CREATE WEEKLY CHANGES FILE REGUL *ALL ECUFULLCAT ECRUP050 EXTR
12 CREATE WEEKLY PRICE CHANGES REGUL *ALL ECUFULLCAT ECRUP055 PRICH
15 CREATE SHAREHOLDER PRICES FULL *RUN ECUFULLCAT ECRUP350 TFORM
25 SEND OUT TO INTERNAL MAIL LIST FULL *RUN ECUFULLCAT ECRUP700 TRANS
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

==Programs==

ECRUP010 (ECU -- Generate regular base files)

- Read active items from the ASW files, write to ECUIBAP, then call ECRUP011. (Note that this uses the status field in SROPRG; perhaps it should use XXITEMP?)

ECRUP011 (ECU -- Generate base prices for base item)

- Read CCP files to calculate current prices, and write to ECUIBPP.

ECRUP050 (ECU -- Generate weekly regular changes file)

- Compare current week base file (ECUIBAP) to previous week's; and write differences to ECUCHGP.

ECRUP055 (ECU -- Generate weekly price changes file)

- Compare current week base prices file (ECUIBPP) to previous week's; and write differences to ECUCHPP.

ECRUP060 (ECU -- Defer records if transmit limit exceeded)

- The limit is currently 30,000 (set up in table UX ECUTRMLIMI); so this is unlikely to happen.

ECRUP350 (ECU -- Generate OMS data for a regular cat. chg)

- Read change files (ECUCHGP and ECUCHPP) and write to ECUOMHP and ECUOMDP.

ECRUP360 (ECU -- Generate item change file to display on WEB)

- Read base files (ECUIBAP and ECUIBPP) and change files (ECUCHGP and ECUCHPP), and write to ECUCHGLOG; which is used by the Web Orders program UW_CHG01 (Changed Item Inquiry).

ECCUP380 (ECU -- send change files to FTP server)

- Sets up temporary input and output FTP files, then calls ECRUP380.

ECRUP380 (ECU -- Generate chg or full catalog files for FTP)

- Reads ECUOMHP and ECUOMDP, then writes ECUFTP. Then FTP's to our mail server for stores or POS vendors to pick up.

ECRUP385 (ECU -- Generate and send full catalog files)

- Calls ECCUP380 for the latest full catalogue files created.

ECRUP700 (ECU -- Transmit or retransmit a transmission)

- Reads data from ECUOMHP and ECUOMDP and writes it to the OMS files (OMSMHDP, OMSLINP, OMSADRP, and OMSQUEP) to be emailed.

==Files==

- File ECUIBAP (ECU -- Item Base File) contains all the fields (except prices) included in the catalogue and change files, for every week this is run.

- File ECUIBPP (ECU -- Item Base Price File) contains all the item prices for every week this is run.

- File ECUCHGLOG (ECU -- Catalog Change Log File for Web Inquiry) contains all base and price changed, can be queried and displayed in Web Orders.

- File ECUCHGP (ECU -- Catalog Changes File) contains all the items that have had any changes in ECUIBAP, from one week to the next.

- File ECUCHPP (ECU -- Catalog Price Changes File) contains all the items that have had any changes in ECUIBPP, from one week to the next.

- File ECUFTP (ECU -- changes file to send to FTP server) temporary file of records to be FTP'ed.

- File ECUOMDP (ECU -- Message Lines File) are the change and full catalogue files reformatted.

- File ECUOMHP (ECU -- Message Headers) header for each change and full catalogue file that has been add to ECUOMDP.

- File OMSADRP (OMS-Outbound Message Address File) the email address extracted from the catalogue distribution file, based on full or regular, and price list.

- File OMSLINP (OMS-Outbound Message Lines File)

- File OMSMHDP (OMS-Outbound Message Header File)

- File OMSQUEP (OMS-Outbound Message Queue File) contains the status of the OMS email.

Information Systems:Overnight Process Problems

2016-03-18T19:46:45Z

Sheilav:

* [[Overnight Processing Does not Complete]]
* [[Rebuild Time Axis Files Does not Complete]]

Information Systems:TEMPORARY - things to add

2016-03-18T19:35:47Z

Sheilav:

- finish ECU

- finish purge

- add manual Atlas transmission

- finish 'log entries' for overnight processing

- add list of overnight jobs that have to run, and how to do them manually

- lost sales - comes from IOP and ASW; when and how are they combined?

- add item availability checking

Information Systems:ECU - Electronic Catalog Update

2016-03-18T19:01:35Z

Sheilav:

uniPHARM used to supply a PC program called EOB (Electronic Order Book) to customers. Every week, ECU would build a file of changes to the item master file (one for each price list, as the prices would be different for each), and email them to ?. We no longer have the EOB, but we continue building change files and full catalogues every week for the POS systems, and for Web Orders.

==ECU Calendar==

Go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ010 -- Show Calendar.

3/16/16 16:11:10 uniPHARM -- PRODUCTION ECRIQ010/LISTCTL
ECU RUNNING ECU - Show Calendar Master File PRODUCTION 1.00
Display Order Field Test Values
DATEA DATE AND TIME A
Date Range Week Status AND
ST MAR 10 16 00 00 AND
Period
RH=Run History WK
MA=Main TR=Transmissions BA=Base File CH=Changes PR=Promo

Reference Week St Start/End Dates SCHED DATE PRICE DATE ADDED DATE
FU20160310 9725 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9726 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9727 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9728 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9729 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9730 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9731 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
MAR11 2016 1263 FI MAR 12 16 MAR 18 16 MAR 11 16 MAR 11 16 JUL 08 09
MAR18 2016 1264 NP MAR 19 16 MAR 25 16 MAR 18 16 MAR 18 16 JUL 08 09
MAR25 2016 1265 NP MAR 26 16 APR 1 16 MAR 25 16 MAR 25 16 JUL 08 09
APR01 2016 1266 NP APR 2 16 APR 8 16 APR 01 16 APR 01 16 JUL 08 09
APR08 2016 1267 NP APR 9 16 APR 15 16 APR 08 16 APR 08 16 JUL 08 09
APR15 2016 1268 NP APR 16 16 APR 22 16 APR 15 16 APR 15 16 JUL 08 09

F21=Scrn Reset
F3=Exit F5=Refresh F12=Previous F24=Scrn Save

This shows two things. Lines with a date formatted as MMMDD YYYY in the 'reference' column are [[Periodic-Calendar Year#Check ECU (Electronic Catalogue Update) Calendar|prebuilt]] to control the 'change' files that are created every week. The 'Week' is the sequentially numbered week since the EOB started. The last line shows, for example, that a file will be built using prices as of April 15th, to be in effect April 16th to April 22nd. Although these dates are all Fridays, we actually build the files Thursday evenings (through the job scheduler), so they will be available no matter how early stores or POS vendors want them. When command '''ECUREGULAR''' is run, it uses the first calendar record at status 'NP - not processed' - not the entry for the actual date. Which means if it is not run at all, the entry will have to manually flagged as 'FI - Finished'. Or if runs twice, another entry will have to added.

When the command '''ECUFULLCAT''' is run, a record is added to this file, with a reference starting with 'FU', then the date formatted as YYYYMMDD. The 'week' number is a sequential number that started at 7000. Around December 2016 it should reach 10000. This should not be a problem as the field is 5 digits long; but the 'Show Calendar' programs only uses 4, so may not work correctly.

==Weekly Electronic Catalog Update==

CL program ECUWEEKLY runs from the Job Scheduler every Thursday at 9:30PM. It runs –

- '''Command ECUREGULAR calling auto run ‘WEEKLYCAT’'''. It builds a file of changes the item file in the last week, for each price list (because they will each have different prices). These files are emailed to pre-set addresses, and sent to our FTP server. It also builds a change file that can be accessed by Web Orders.

- '''Command ECUFULLCAT calling auto run ‘ECUFULLCAT’''' for each price list.

- '''Program ECRUP385''' (ECU -- Generate and send full catalog files) calls ECCUP380 (ECU -- send change files to FTP server) for each catalogue built by ECUFULLCAT.

===Detail Process===

To see the details, go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ030 -- Show Auto Run Records.

3/16/16 11:53:08 uniPHARM -- PRODUCTION ECRIQ030/LISTCTL
ECU RUNNING ECU - Show Auto Run Master Records PRODUCTION 1.00
Display Order Field Test Values
NAME By Auto Run Nam
AND
AND
Date Range Status Timing
AD 00 00 00 00

MA=Main CP=Copy ST=Steps RU=Runs EX=Execute PU=Purge

Run Name and Description Ti PROGRAM START DATE END DATE
__ ECUFULLCAT FULL CATALOG -- SPECIAL RUN OR ECREX001 JAN 01 04 DEC 31 50
__ ECUPARTCAT PARTIAL CATALOG -- SPECIAL OR ECREX001 JAN 01 04 DEC 31 50
__ PROMONITE NIGHTLY PROMO EXTRACTS DY ECREX002 JAN 01 04 DEC 31 50
ST WEEKLYCAT WEEKLY CATALOG WK ECREX001 JAN 01 04 DEC 31 50

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Use option ST=Steps on run 'WEEKLYCAT'. You will have to page down to see all the steps.

3/16/16 11:59:15 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
WEEKLYCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
100 CREATE BASE FILE REGUL *ALL WEEKLYCAT ECRUP010 BASE
101 CREATE WEEKLY CHANGES FILE REGUL *ALL WEEKLYCAT ECRUP050 EXTR
120 CREATE WEEKLY PRICE CHANGES REGUL *ALL WEEKLYCAT ECRUP055 PRICH
130 CHECK FOR ANY TRANSMIT LIMITS REGUL *ALL WEEKLYCAT ECRUP060 TSIZE
150 CREATE BC SH PRICES REGUL SHARE-BC WEEKLYCAT ECRUP350 TFORM
200 CREATE BC NS PRICES REGUL NON-SH-BC WEEKLYCAT ECRUP350 TFORM
210 CREATE AB SH PRICES REGUL SHARE-AB WEEKLYCAT ECRUP350 TFORM
220 CREATE AB NS PRICES REGUL NON-SH-AB WEEKLYCAT ECRUP350 TFORM
225 CREATE PSC PRICES REGUL SHARE-PSC WEEKLYCAT ECRUP350 TFORM
230 CREATE PSC1 PRICES REGUL SHARE-PSC1 WEEKLYCAT ECRUP350 TFORM
235 CREATE YT SH PRICES REGUL SHARE-YT WEEKLYCAT ECRUP350 TFORM
250 SEND OUT WEEKLY BC SH REGUL SHARE-BC WEEKLYCAT ECRUP700 TRANS
300 SEND OUT WEEKLY BC NS REGUL NON-SH-BC WEEKLYCAT ECRUP700 TRANS
320 SEND OUT WEEKLY AB SH REGUL SHARE-AB WEEKLYCAT ECRUP700 TRANS
340 SEND OUT WEEKLY AB NS REGUL NON-SH-AB WEEKLYCAT ECRUP700 TRANS
350 SEND OUT WEEKLY PSC REGUL SHARE-PSC WEEKLYCAT ECRUP700 TRANS
360 SEND OUT WEEKLY PSC1 REGUL SHARE-PSC1 WEEKLYCAT ECRUP700 TRANS
370 SEND OUT WEEKLY YT SH REGUL SHARE-YT WEEKLYCAT ECRUP700 TRANS
531 BUILD CHANGES FILE FOR WEB REGUL *ALL WEEKLYCAT ECRUP360 BASE
601 COPY CHG FILES TO FTP SERVER REGUL *ALL WEEKLYCAT ECCUP380 BASE
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Repeat for run 'ECUFULLCAT'.

3/16/16 12:33:25 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
ECUFULLCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
10 CREATE WEEKLY CHANGES FILE REGUL *ALL ECUFULLCAT ECRUP050 EXTR
12 CREATE WEEKLY PRICE CHANGES REGUL *ALL ECUFULLCAT ECRUP055 PRICH
15 CREATE SHAREHOLDER PRICES FULL *RUN ECUFULLCAT ECRUP350 TFORM
25 SEND OUT TO INTERNAL MAIL LIST FULL *RUN ECUFULLCAT ECRUP700 TRANS
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

==Programs==

ECRUP010 (ECU -- Generate regular base files)

- Read active items from the ASW files, write to ECUIBAP, then call ECRUP011. (Note that this uses the status field in SROPRG; perhaps it should use XXITEMP?)

ECRUP011 (ECU -- Generate base prices for base item)

- Read CCP files to calculate current prices, and write to ECUIBPP.

ECRUP050 (ECU -- Generate weekly regular changes file)

- Compare current week base file (ECUIBAP) to previous week's; and write differences to ECUCHGP.

ECRUP055 (ECU -- Generate weekly price changes file)

- Compare current week base prices file (ECUIBPP) to previous week's; and write differences to ECUCHPP.

ECRUP060 (ECU -- Defer records if transmit limit exceeded)

- The limit is currently 30,000 (set up in table UX ECUTRMLIMI); so this is unlikely to happen.

ECRUP350 (ECU -- Generate OMS data for a regular cat. chg)

- Read change files (ECUCHGP and ECUCHPP) and write to ECUOMHP and ECUOMDP.

ECRUP360 (ECU -- Generate item change file to display on WEB)

- Read base files (ECUIBAP and ECUIBPP) and change files (ECUCHGP and ECUCHPP), and write to ECUCHGLOG; which is used by the Web Orders program UW_CHG01 (Changed Item Inquiry).

ECCUP380 (ECU -- send change files to FTP server)

- Sets up temporary input and output FTP files, then calls ECRUP380.

ECRUP380 (ECU -- Generate chg or full catalog files for FTP)

- Reads ECUOMHP and ECUOMDP, then writes ECUFTP. Then FTP's to our mail server for stores or POS vendors to pick up.

ECRUP385 (ECU -- Generate and send full catalog files)

- Calls ECCUP380 for the latest full catalogue files created.

ECRUP700 (ECU -- Transmit or retransmit a transmission)

- Reads data from ECUOMHP and ECUOMDP and writes it to the OMS files (OMSMHDP, OMSLINP, OMSADRP, and OMSQUEP) to be emailed.

==Files==

- File ECUIBAP (ECU -- Item Base File) contains all the fields (except prices) included in the catalogue and change files, for every week this is run.

- File ECUIBPP (ECU -- Item Base Price File) contains all the item prices for every week this is run.

- File ECUCHGP (ECU -- Catalog Changes File) contains all the items that have had any changes in ECUIBAP, from one week to the next.

- File ECUCHPP (ECU -- Catalog Price Changes File) contains all the items that have had any changes in ECUIBPP, from one week to the next.

- File ECUOMDP (ECU -- Message Lines File) are the change and full catalogue files reformatted.

- File ECUOMHP (ECU -- Message Headers) header for each change and full catalogue file that has been add to ECUOMDP.

Information Systems:TEMPORARY - things to add

2016-03-18T16:27:51Z

Sheilav:

Information Systems:ECU - Electronic Catalog Update

2016-03-17T21:09:54Z

Sheilav:

uniPHARM used to supply a PC program called EOB (Electronic Order Book) to customers. Every week, ECU would build a file of changes to the item master file (one for each price list, as the prices would be different for each), and email them to ?. We no longer have the EOB, but we continue building change files and full catalogues every week for the POS systems, and for Web Orders.

==ECU Calendar==

Go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ010 -- Show Calendar.

3/16/16 16:11:10 uniPHARM -- PRODUCTION ECRIQ010/LISTCTL
ECU RUNNING ECU - Show Calendar Master File PRODUCTION 1.00
Display Order Field Test Values
DATEA DATE AND TIME A
Date Range Week Status AND
ST MAR 10 16 00 00 AND
Period
RH=Run History WK
MA=Main TR=Transmissions BA=Base File CH=Changes PR=Promo

Reference Week St Start/End Dates SCHED DATE PRICE DATE ADDED DATE
FU20160310 9725 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9726 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9727 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9728 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9729 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9730 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9731 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
MAR11 2016 1263 FI MAR 12 16 MAR 18 16 MAR 11 16 MAR 11 16 JUL 08 09
MAR18 2016 1264 NP MAR 19 16 MAR 25 16 MAR 18 16 MAR 18 16 JUL 08 09
MAR25 2016 1265 NP MAR 26 16 APR 1 16 MAR 25 16 MAR 25 16 JUL 08 09
APR01 2016 1266 NP APR 2 16 APR 8 16 APR 01 16 APR 01 16 JUL 08 09
APR08 2016 1267 NP APR 9 16 APR 15 16 APR 08 16 APR 08 16 JUL 08 09
APR15 2016 1268 NP APR 16 16 APR 22 16 APR 15 16 APR 15 16 JUL 08 09

F21=Scrn Reset
F3=Exit F5=Refresh F12=Previous F24=Scrn Save

This shows two things. Lines with a date formatted as MMMDD YYYY in the 'reference' column are [[Periodic-Calendar Year#Check ECU (Electronic Catalogue Update) Calendar|prebuilt]] to control the 'change' files that are created every week. The 'Week' is the sequentially numbered week since the EOB started. The last line shows, for example, that a file will be built using prices as of April 15th, to be in effect April 16th to April 22nd. Although these dates are all Fridays, we actually build the files Thursday evenings (through the job scheduler), so they will be available no matter how early stores or POS vendors want them. When command '''ECUREGULAR''' is run, it will use the first calendar record at status 'NP - not processed' - not the entry for the actual date. Which means if it is not run at all, the entry will have to manually flagged as 'FI - Finished'. Or if runs twice, another entry will have to added.

When the command '''ECUFULLCAT''' is run, a record is added to this file, with a reference starting with 'FU', then the date formatted as YYYYMMDD.

==Weekly Electronic Catalog Update==

CL program ECUWEEKLY runs from the Job Scheduler every Thursday at 9:30PM. It runs –

- '''Command ECUREGULAR calling auto run ‘WEEKLYCAT’'''. It builds a file of changes the item file in the last week, for each price list (because they will each have different prices). These files are emailed to pre-set addresses, and sent to our FTP server. It also builds a change file that can be accessed by Web Orders.

- '''Command ECUFULLCAT calling auto run ‘ECUFULLCAT’''' for each price list.

- '''Program ECRUP385''' (ECU -- Generate and send full catalog files) calls ECCUP380 (ECU -- send change files to FTP server) for each catalogue built by ECUFULLCAT.

===Detail Process===

To see the details, go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ030 -- Show Auto Run Records.

3/16/16 11:53:08 uniPHARM -- PRODUCTION ECRIQ030/LISTCTL
ECU RUNNING ECU - Show Auto Run Master Records PRODUCTION 1.00
Display Order Field Test Values
NAME By Auto Run Nam
AND
AND
Date Range Status Timing
AD 00 00 00 00

MA=Main CP=Copy ST=Steps RU=Runs EX=Execute PU=Purge

Run Name and Description Ti PROGRAM START DATE END DATE
__ ECUFULLCAT FULL CATALOG -- SPECIAL RUN OR ECREX001 JAN 01 04 DEC 31 50
__ ECUPARTCAT PARTIAL CATALOG -- SPECIAL OR ECREX001 JAN 01 04 DEC 31 50
__ PROMONITE NIGHTLY PROMO EXTRACTS DY ECREX002 JAN 01 04 DEC 31 50
ST WEEKLYCAT WEEKLY CATALOG WK ECREX001 JAN 01 04 DEC 31 50

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Use option ST=Steps on run 'WEEKLYCAT'. You will have to page down to see all the steps.

3/16/16 11:59:15 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
WEEKLYCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
100 CREATE BASE FILE REGUL *ALL WEEKLYCAT ECRUP010 BASE
101 CREATE WEEKLY CHANGES FILE REGUL *ALL WEEKLYCAT ECRUP050 EXTR
120 CREATE WEEKLY PRICE CHANGES REGUL *ALL WEEKLYCAT ECRUP055 PRICH
130 CHECK FOR ANY TRANSMIT LIMITS REGUL *ALL WEEKLYCAT ECRUP060 TSIZE
150 CREATE BC SH PRICES REGUL SHARE-BC WEEKLYCAT ECRUP350 TFORM
200 CREATE BC NS PRICES REGUL NON-SH-BC WEEKLYCAT ECRUP350 TFORM
210 CREATE AB SH PRICES REGUL SHARE-AB WEEKLYCAT ECRUP350 TFORM
220 CREATE AB NS PRICES REGUL NON-SH-AB WEEKLYCAT ECRUP350 TFORM
225 CREATE PSC PRICES REGUL SHARE-PSC WEEKLYCAT ECRUP350 TFORM
230 CREATE PSC1 PRICES REGUL SHARE-PSC1 WEEKLYCAT ECRUP350 TFORM
235 CREATE YT SH PRICES REGUL SHARE-YT WEEKLYCAT ECRUP350 TFORM
250 SEND OUT WEEKLY BC SH REGUL SHARE-BC WEEKLYCAT ECRUP700 TRANS
300 SEND OUT WEEKLY BC NS REGUL NON-SH-BC WEEKLYCAT ECRUP700 TRANS
320 SEND OUT WEEKLY AB SH REGUL SHARE-AB WEEKLYCAT ECRUP700 TRANS
340 SEND OUT WEEKLY AB NS REGUL NON-SH-AB WEEKLYCAT ECRUP700 TRANS
350 SEND OUT WEEKLY PSC REGUL SHARE-PSC WEEKLYCAT ECRUP700 TRANS
360 SEND OUT WEEKLY PSC1 REGUL SHARE-PSC1 WEEKLYCAT ECRUP700 TRANS
370 SEND OUT WEEKLY YT SH REGUL SHARE-YT WEEKLYCAT ECRUP700 TRANS
531 BUILD CHANGES FILE FOR WEB REGUL *ALL WEEKLYCAT ECRUP360 BASE
601 COPY CHG FILES TO FTP SERVER REGUL *ALL WEEKLYCAT ECCUP380 BASE
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Repeat for run 'ECUFULLCAT'.

3/16/16 12:33:25 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
ECUFULLCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
10 CREATE WEEKLY CHANGES FILE REGUL *ALL ECUFULLCAT ECRUP050 EXTR
12 CREATE WEEKLY PRICE CHANGES REGUL *ALL ECUFULLCAT ECRUP055 PRICH
15 CREATE SHAREHOLDER PRICES FULL *RUN ECUFULLCAT ECRUP350 TFORM
25 SEND OUT TO INTERNAL MAIL LIST FULL *RUN ECUFULLCAT ECRUP700 TRANS
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

==Programs==

ECRUP010 (ECU -- Generate regular base files)

- Read active items from the ASW files, write to ECUIBAP, then call ECRUP011. (Note that this uses the status field in SROPRG; perhaps it should use XXITEMP?)

ECRUP011 (ECU -- Generate base prices for base item)

- Read CCP files to calculate current prices, and write to ECUIBPP.

ECRUP050 (ECU -- Generate weekly regular changes file)

- Compare current week base file (ECUIBAP) to previous week's; and write differences to ECUCHGP.

ECRUP055 (ECU -- Generate weekly price changes file)

- Compare current week base prices file (ECUIBPP) to previous week's; and write differences to ECUCHPP.

ECRUP060 (ECU -- Defer records if transmit limit exceeded)

- The limit is currently 30,000 (set up in table UX ECUTRMLIMI); so this is unlikely to happen.

ECRUP350 (ECU -- Generate OMS data for a regular cat. chg)

- Read change files (ECUCHGP and ECUCHPP) and write to ECUOMHP and ECUOMDP.

ECRUP360 (ECU -- Generate item change file to display on WEB)

- Read base files (ECUIBAP and ECUIBPP) and change files (ECUCHGP and ECUCHPP), and write to ECUCHGLOG; which is used by the Web Orders program UW_CHG01 (Changed Item Inquiry).

ECCUP380 (ECU -- send change files to FTP server)

- Sets up temporary input and output FTP files, then calls ECRUP380.

ECRUP380 (ECU -- Generate chg or full catalog files for FTP)

- Reads ECUOMHP and ECUOMDP, then writes ECUFTP.

ECRUP385 ()

-

ECRUP700 (ECU -- Transmit or retransmit a transmission)

-

==Files==

- File ECUIBAP (ECU -- Item Base File) contains all the fields (except prices) included in the catalogue and change files, for every week this is run.

- File ECUIBPP (ECU -- Item Base Price File) contains all the item prices for every week this is run.

- File ECUCHGP (ECU -- Catalog Changes File) contains all the items that have had any changes in ECUIBAP, from one week to the next.

- File ECUCHPP (ECU -- Catalog Price Changes File) contains all the items that have had any changes in ECUIBPP, from one week to the next.

- File ECUOMDP (ECU -- Message Lines File) are the change and full catalogue files reformatted.

- File ECUOMHP (ECU -- Message Headers) header for each change and full catalogue file that has been add to ECUOMDP.

Information Systems:ECU - Electronic Catalog Update

2016-03-17T00:02:03Z

Sheilav:

uniPHARM used to supply a PC program called EOB (Electronic Order Book) to customers. Every week, ECU would build a file of changes to the item master file (one for each price list, as the prices would be different for each), and email them to ?. We no longer have the EOB, but we continue building change files and full catalogues every week for the POS systems, and for Web Orders.

==ECU Calendar==

Go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ010 -- Show Calendar.

3/16/16 16:11:10 uniPHARM -- PRODUCTION ECRIQ010/LISTCTL
ECU RUNNING ECU - Show Calendar Master File PRODUCTION 1.00
Display Order Field Test Values
DATEA DATE AND TIME A
Date Range Week Status AND
ST MAR 10 16 00 00 AND
Period
RH=Run History WK
MA=Main TR=Transmissions BA=Base File CH=Changes PR=Promo

Reference Week St Start/End Dates SCHED DATE PRICE DATE ADDED DATE
FU20160310 9725 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9726 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9727 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9728 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9729 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9730 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9731 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
MAR11 2016 1263 FI MAR 12 16 MAR 18 16 MAR 11 16 MAR 11 16 JUL 08 09
MAR18 2016 1264 NP MAR 19 16 MAR 25 16 MAR 18 16 MAR 18 16 JUL 08 09
MAR25 2016 1265 NP MAR 26 16 APR 1 16 MAR 25 16 MAR 25 16 JUL 08 09
APR01 2016 1266 NP APR 2 16 APR 8 16 APR 01 16 APR 01 16 JUL 08 09
APR08 2016 1267 NP APR 9 16 APR 15 16 APR 08 16 APR 08 16 JUL 08 09
APR15 2016 1268 NP APR 16 16 APR 22 16 APR 15 16 APR 15 16 JUL 08 09

F21=Scrn Reset
F3=Exit F5=Refresh F12=Previous F24=Scrn Save

This shows two things. Lines with a date formatted as MMMDD YYYY in the 'reference' column are [[Periodic-Calendar Year#Check ECU (Electronic Catalogue Update) Calendar|prebuilt]] to control the 'change' files that are created every week. The 'Week' is the sequentially numbered week since the EOB started. The last line shows, for example, that a file will be built using prices as of April 15th, to be in effect April 16th to April 22nd. Although these dates are all Fridays, we actually build the files Thursday evenings, so they will be available no matter how early stores or POS vendors want them. When command '''ECUREGULAR''' is run, it will use the first calendar record at status 'NP - not processed' - not the entry for the actual date. Which means if it is not run at all, the entry will have to manually flagged as 'FI - Finished'. Or if runs twice, another entry will have to added.

When the command '''ECUFULLCAT''' is run, a record is added to this file, with a reference starting with 'FU', then the date formatted as YYYYMMDD.

==Weekly Electronic Catalog Update==

CL program ECUWEEKLY runs from the Job Scheduler every Thursday at 9:30PM. It runs –

- '''Command ECUREGULAR calling auto run ‘WEEKLYCAT’'''. It builds a file of changes the item file in the last week, for each price list (because they will each have different prices). These files are emailed to pre-set addresses, and sent to our FTP server. It also builds a change file that can be accessed by Web Orders.

- '''Command ECUFULLCAT calling auto run ‘ECUFULLCAT’''' for each price list.

- '''Program ECRUP385''' (ECU -- Generate and send full catalog files) calls ECCUP380 (ECU -- send change files to FTP server) for each catalogue built by ECUFULLCAT.

===Detail Process===

To see the details, go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ030 -- Show Auto Run Records.

3/16/16 11:53:08 uniPHARM -- PRODUCTION ECRIQ030/LISTCTL
ECU RUNNING ECU - Show Auto Run Master Records PRODUCTION 1.00
Display Order Field Test Values
NAME By Auto Run Nam
AND
AND
Date Range Status Timing
AD 00 00 00 00

MA=Main CP=Copy ST=Steps RU=Runs EX=Execute PU=Purge

Run Name and Description Ti PROGRAM START DATE END DATE
__ ECUFULLCAT FULL CATALOG -- SPECIAL RUN OR ECREX001 JAN 01 04 DEC 31 50
__ ECUPARTCAT PARTIAL CATALOG -- SPECIAL OR ECREX001 JAN 01 04 DEC 31 50
__ PROMONITE NIGHTLY PROMO EXTRACTS DY ECREX002 JAN 01 04 DEC 31 50
ST WEEKLYCAT WEEKLY CATALOG WK ECREX001 JAN 01 04 DEC 31 50

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Use option ST=Steps on run 'WEEKLYCAT'. You will have to page down to see all the steps.

3/16/16 11:59:15 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
WEEKLYCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
100 CREATE BASE FILE REGUL *ALL WEEKLYCAT ECRUP010 BASE
101 CREATE WEEKLY CHANGES FILE REGUL *ALL WEEKLYCAT ECRUP050 EXTR
120 CREATE WEEKLY PRICE CHANGES REGUL *ALL WEEKLYCAT ECRUP055 PRICH
130 CHECK FOR ANY TRANSMIT LIMITS REGUL *ALL WEEKLYCAT ECRUP060 TSIZE
150 CREATE BC SH PRICES REGUL SHARE-BC WEEKLYCAT ECRUP350 TFORM
200 CREATE BC NS PRICES REGUL NON-SH-BC WEEKLYCAT ECRUP350 TFORM
210 CREATE AB SH PRICES REGUL SHARE-AB WEEKLYCAT ECRUP350 TFORM
220 CREATE AB NS PRICES REGUL NON-SH-AB WEEKLYCAT ECRUP350 TFORM
225 CREATE PSC PRICES REGUL SHARE-PSC WEEKLYCAT ECRUP350 TFORM
230 CREATE PSC1 PRICES REGUL SHARE-PSC1 WEEKLYCAT ECRUP350 TFORM
235 CREATE YT SH PRICES REGUL SHARE-YT WEEKLYCAT ECRUP350 TFORM
250 SEND OUT WEEKLY BC SH REGUL SHARE-BC WEEKLYCAT ECRUP700 TRANS
300 SEND OUT WEEKLY BC NS REGUL NON-SH-BC WEEKLYCAT ECRUP700 TRANS
320 SEND OUT WEEKLY AB SH REGUL SHARE-AB WEEKLYCAT ECRUP700 TRANS
340 SEND OUT WEEKLY AB NS REGUL NON-SH-AB WEEKLYCAT ECRUP700 TRANS
350 SEND OUT WEEKLY PSC REGUL SHARE-PSC WEEKLYCAT ECRUP700 TRANS
360 SEND OUT WEEKLY PSC1 REGUL SHARE-PSC1 WEEKLYCAT ECRUP700 TRANS
370 SEND OUT WEEKLY YT SH REGUL SHARE-YT WEEKLYCAT ECRUP700 TRANS
531 BUILD CHANGES FILE FOR WEB REGUL *ALL WEEKLYCAT ECRUP360 BASE
601 COPY CHG FILES TO FTP SERVER REGUL *ALL WEEKLYCAT ECCUP380 BASE
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Repeat for run 'ECUFULLCAT'.

3/16/16 12:33:25 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
ECUFULLCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
10 CREATE WEEKLY CHANGES FILE REGUL *ALL ECUFULLCAT ECRUP050 EXTR
12 CREATE WEEKLY PRICE CHANGES REGUL *ALL ECUFULLCAT ECRUP055 PRICH
15 CREATE SHAREHOLDER PRICES FULL *RUN ECUFULLCAT ECRUP350 TFORM
25 SEND OUT TO INTERNAL MAIL LIST FULL *RUN ECUFULLCAT ECRUP700 TRANS
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

==Programs==

ECRUP010 (ECU -- Generate regular base files)

- Read active items from the ASW files, write to ECUIBAP, then call ECRUP011. (Note that this uses the status field in SROPRG; perhaps it should use XXITEMP?)

ECRUP011 (ECU -- Generate base prices for base item)

- Read CCP files to calculate current prices, and write to ECUIBPP.

ECRUP050 (ECU -- Generate weekly regular changes file)

- Compare current week base file (ECUIBAP) to previous week's; and write differences to ECUCHGP.

ECRUP055 (ECU -- Generate weekly price changes file)

- Compare current week base prices file (ECUIBPP) to previous week's; and write differences to ECUCHPP.

ECRUP060 (ECU -- Defer records if transmit limit exceeded)

- The limit is currently 30,000 (set up in table UX ECUTRMLIMI); so this is unlikely to happen.

ECRUP350 (ECU -- Generate OMS data for a regular cat. chg)

- Read change files (ECUCHGP and ECUCHPP) and write to ECUOMHP and ECUOMDP.

ECRUP360 (ECU -- Generate item change file to display on WEB)

- Read base files (ECUIBAP and ECUIBPP) and change files (ECUCHGP and ECUCHPP), and write to ECUCHGLOG; which is used by the Web Orders program UW_CHG01 (Changed Item Inquiry).

ECCUP380 (ECU -- send change files to FTP server)

- Sets up temporary input and output FTP files, then calls ECRUP380.

ECRUP380 (ECU -- Generate chg or full catalog files for FTP)

- Reads ECUOMHP and ECUOMDP, then writes ECUFTP.

ECRUP385 ()

-

ECRUP700 (ECU -- Transmit or retransmit a transmission)

-

==Files==

- File ECUIBAP (ECU -- Item Base File) contains all the fields (except prices) included in the catalogue and change files, for every week this is run.

- File ECUIBPP (ECU -- Item Base Price File) contains all the item prices for every week this is run.

- File ECUCHGP (ECU -- Catalog Changes File) contains all the items that have had any changes in ECUIBAP, from one week to the next.

- File ECUCHPP (ECU -- Catalog Price Changes File) contains all the items that have had any changes in ECUIBPP, from one week to the next.

- File ECUOMDP (ECU -- Message Lines File) are the change and full catalogue files reformatted.

- File ECUOMHP (ECU -- Message Headers) header for each change and full catalogue file that has been add to ECUOMDP.

Information Systems:ECU - Electronic Catalog Update

2016-03-16T23:40:38Z

Sheilav:

uniPHARM used to supply a PC program called EOB (Electronic Order Book) to customers. Every week, ECU would build a file of changes to the item master file (one for each price list, as the prices would be different for each), and email them to ?. We no longer have the EOB, but we continue building change files and full catalogues every week for the POS systems, and for Web Orders.

==ECU Calendar==

Go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ010 -- Show Calendar.

3/16/16 16:11:10 uniPHARM -- PRODUCTION ECRIQ010/LISTCTL
ECU RUNNING ECU - Show Calendar Master File PRODUCTION 1.00
Display Order Field Test Values
DATEA DATE AND TIME A
Date Range Week Status AND
ST MAR 10 16 00 00 AND
Period
RH=Run History WK
MA=Main TR=Transmissions BA=Base File CH=Changes PR=Promo

Reference Week St Start/End Dates SCHED DATE PRICE DATE ADDED DATE
FU20160310 9725 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9726 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9727 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9728 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9729 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9730 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
FU20160310 9731 FI MAR 10 16 DEC 31 50 MAR 10 16 MAR 11 16 MAR 10 16
MAR11 2016 1263 FI MAR 12 16 MAR 18 16 MAR 11 16 MAR 11 16 JUL 08 09
MAR18 2016 1264 NP MAR 19 16 MAR 25 16 MAR 18 16 MAR 18 16 JUL 08 09
MAR25 2016 1265 NP MAR 26 16 APR 1 16 MAR 25 16 MAR 25 16 JUL 08 09
APR01 2016 1266 NP APR 2 16 APR 8 16 APR 01 16 APR 01 16 JUL 08 09
APR08 2016 1267 NP APR 9 16 APR 15 16 APR 08 16 APR 08 16 JUL 08 09
APR15 2016 1268 NP APR 16 16 APR 22 16 APR 15 16 APR 15 16 JUL 08 09

F21=Scrn Reset
F3=Exit F5=Refresh F12=Previous F24=Scrn Save

This shows two things. Lines with a date (formatted as MMMDD YYYY) in the 'reference' column are [[Periodic-Calendar Year#Check ECU (Electronic Catalogue Update) Calendar|prebuilt]] to control the 'change' files that are created every week. The last line shows, for example, that a file will be built on April 15th, using prices as of that day, and will be in effect for April 16th to April 22nd. Although these dates are all Fridays, we actually build the files Thursday evenings, so they will be available no matter how early stores or POS vendors want them.

==Weekly Electronic Catalog Update==

CL program ECUWEEKLY runs from the Job Scheduler every Thursday at 9:30PM. It runs –

- '''Command ECUREGULAR calling auto run ‘WEEKLYCAT’'''. It builds a file of changes the item file in the last week, for each price list (because they will each have different prices). These files are emailed to pre-set addresses, and sent to our FTP server. It also builds a change file that can be accessed by Web Orders.

- '''Command ECUFULLCAT calling auto run ‘ECUFULLCAT’''' for each price list.

- '''Program ECRUP385''' (ECU -- Generate and send full catalog files) calls ECCUP380 (ECU -- send change files to FTP server) for each catalogue built by ECUFULLCAT.

===Detail Process===

To see the details, go to Unity / Start uniPharm Extensions / VA Company / UWD Extensions / ECU -- Catalog Update / ECRIQ030 -- Show Auto Run Records.

3/16/16 11:53:08 uniPHARM -- PRODUCTION ECRIQ030/LISTCTL
ECU RUNNING ECU - Show Auto Run Master Records PRODUCTION 1.00
Display Order Field Test Values
NAME By Auto Run Nam
AND
AND
Date Range Status Timing
AD 00 00 00 00

MA=Main CP=Copy ST=Steps RU=Runs EX=Execute PU=Purge

Run Name and Description Ti PROGRAM START DATE END DATE
__ ECUFULLCAT FULL CATALOG -- SPECIAL RUN OR ECREX001 JAN 01 04 DEC 31 50
__ ECUPARTCAT PARTIAL CATALOG -- SPECIAL OR ECREX001 JAN 01 04 DEC 31 50
__ PROMONITE NIGHTLY PROMO EXTRACTS DY ECREX002 JAN 01 04 DEC 31 50
ST WEEKLYCAT WEEKLY CATALOG WK ECREX001 JAN 01 04 DEC 31 50

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Use option ST=Steps on run 'WEEKLYCAT'. You will have to page down to see all the steps.

3/16/16 11:59:15 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
WEEKLYCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
100 CREATE BASE FILE REGUL *ALL WEEKLYCAT ECRUP010 BASE
101 CREATE WEEKLY CHANGES FILE REGUL *ALL WEEKLYCAT ECRUP050 EXTR
120 CREATE WEEKLY PRICE CHANGES REGUL *ALL WEEKLYCAT ECRUP055 PRICH
130 CHECK FOR ANY TRANSMIT LIMITS REGUL *ALL WEEKLYCAT ECRUP060 TSIZE
150 CREATE BC SH PRICES REGUL SHARE-BC WEEKLYCAT ECRUP350 TFORM
200 CREATE BC NS PRICES REGUL NON-SH-BC WEEKLYCAT ECRUP350 TFORM
210 CREATE AB SH PRICES REGUL SHARE-AB WEEKLYCAT ECRUP350 TFORM
220 CREATE AB NS PRICES REGUL NON-SH-AB WEEKLYCAT ECRUP350 TFORM
225 CREATE PSC PRICES REGUL SHARE-PSC WEEKLYCAT ECRUP350 TFORM
230 CREATE PSC1 PRICES REGUL SHARE-PSC1 WEEKLYCAT ECRUP350 TFORM
235 CREATE YT SH PRICES REGUL SHARE-YT WEEKLYCAT ECRUP350 TFORM
250 SEND OUT WEEKLY BC SH REGUL SHARE-BC WEEKLYCAT ECRUP700 TRANS
300 SEND OUT WEEKLY BC NS REGUL NON-SH-BC WEEKLYCAT ECRUP700 TRANS
320 SEND OUT WEEKLY AB SH REGUL SHARE-AB WEEKLYCAT ECRUP700 TRANS
340 SEND OUT WEEKLY AB NS REGUL NON-SH-AB WEEKLYCAT ECRUP700 TRANS
350 SEND OUT WEEKLY PSC REGUL SHARE-PSC WEEKLYCAT ECRUP700 TRANS
360 SEND OUT WEEKLY PSC1 REGUL SHARE-PSC1 WEEKLYCAT ECRUP700 TRANS
370 SEND OUT WEEKLY YT SH REGUL SHARE-YT WEEKLYCAT ECRUP700 TRANS
531 BUILD CHANGES FILE FOR WEB REGUL *ALL WEEKLYCAT ECRUP360 BASE
601 COPY CHG FILES TO FTP SERVER REGUL *ALL WEEKLYCAT ECCUP380 BASE
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

Repeat for run 'ECUFULLCAT'.

3/16/16 12:33:25 uniPHARM -- PRODUCTION ECRIQ040/LISTCTL
ECU RUNNING ECU - Show Auto Run Steps PRODUCTION 1.00
Display Order Field Test Values
NASTP Name, Step #
Limit to: Name Type Status AND
ECUFULLCAT AND
Catalog Type/Sub Type

MA=Main CP=Copy PU=Purge RU=Runs

Step # and Description Type Sub Type RUN NAME PROGRAM STEP TYPE
10 CREATE WEEKLY CHANGES FILE REGUL *ALL ECUFULLCAT ECRUP050 EXTR
12 CREATE WEEKLY PRICE CHANGES REGUL *ALL ECUFULLCAT ECRUP055 PRICH
15 CREATE SHAREHOLDER PRICES FULL *RUN ECUFULLCAT ECRUP350 TFORM
25 SEND OUT TO INTERNAL MAIL LIST FULL *RUN ECUFULLCAT ECRUP700 TRANS
* END *

F21=Scrn Reset
F3=Exit F5=Refresh F6=Add F12=Previous F24=Scrn Save

==Programs==

ECRUP010 (ECU -- Generate regular base files)

- Read active items from the ASW files, write to ECUIBAP, then call ECRUP011. (Note that this uses the status field in SROPRG; perhaps it should use XXITEMP?)

ECRUP011 (ECU -- Generate base prices for base item)

- Read CCP files to calculate current prices, and write to ECUIBPP.

ECRUP050 (ECU -- Generate weekly regular changes file)

- Compare current week base file (ECUIBAP) to previous week's; and write differences to ECUCHGP.

ECRUP055 (ECU -- Generate weekly price changes file)

- Compare current week base prices file (ECUIBPP) to previous week's; and write differences to ECUCHPP.

ECRUP060 (ECU -- Defer records if transmit limit exceeded)

- The limit is currently 30,000 (set up in table UX ECUTRMLIMI); so this is unlikely to happen.

ECRUP350 (ECU -- Generate OMS data for a regular cat. chg)

- Read change files (ECUCHGP and ECUCHPP) and write to ECUOMHP and ECUOMDP.

ECRUP360 (ECU -- Generate item change file to display on WEB)

- Read base files (ECUIBAP and ECUIBPP) and change files (ECUCHGP and ECUCHPP), and write to ECUCHGLOG; which is used by the Web Orders program UW_CHG01 (Changed Item Inquiry).

ECCUP380 (ECU -- send change files to FTP server)

- Sets up temporary input and output FTP files, then calls ECRUP380.

ECRUP380 (ECU -- Generate chg or full catalog files for FTP)

- Reads ECUOMHP and ECUOMDP, then writes ECUFTP.

ECRUP385 ()

-

ECRUP700 (ECU -- Transmit or retransmit a transmission)

-

==Files==

- File ECUIBAP (ECU -- Item Base File) contains all the fields (except prices) included in the catalogue and change files, for every week this is run.

- File ECUIBPP (ECU -- Item Base Price File) contains all the item prices for every week this is run.

- File ECUCHGP (ECU -- Catalog Changes File) contains all the items that have had any changes in ECUIBAP, from one week to the next.

- File ECUCHPP (ECU -- Catalog Price Changes File) contains all the items that have had any changes in ECUIBPP, from one week to the next.

- File ECUOMDP (ECU -- Message Lines File) are the change and full catalogue files reformatted.

- File ECUOMHP (ECU -- Message Headers) header for each change and full catalogue file that has been add to ECUOMDP.

Information Systems:ECU - Electronic Catalog Update

2016-03-16T22:52:26Z

Sheilav:

Information Systems:A/P Invoicing - Invoice Line Locked

2016-03-16T22:20:54Z

Sheilav: Created page with "Error number CF40206 (Order &1 line &2 is currently locked by &3) displayed by RPG program GCFR402(A/P invoice matching vs. goods rec trans). This program calls GCFR434 (A/P..."

Error number CF40206 (Order &1 line &2 is currently locked by &3) displayed by RPG program GCFR402(A/P invoice matching vs. goods rec trans).

This program calls GCFR434 (A/P inv matching - check goods reception line lock), which reads SROGRT (Goods reception transactions) for the PO number, and line number selected by invoice matching. If GWREFX (Reference number) is not either 0, or matching the A/P transaction in process, this error is issued.

A/P invoicing allocates a reference number for the invoice, puts it into the reference number field of all the goods reception transactions that are matched, then at the end, writes the transaction to the A/P file (SROLTA). If the process is interrupted, and the transaction is not written to SROLTA, GCFR434 will not allow the records in SROGRT to be selected again (they are locked).

The field GWREFX (labelled 'Ref no:') must be manually cleared, using [[DFU]] on file SR15GRT in library UP1480bfVA. (Press enter twice to get to the third page.)

Information Systems:Finance Problems

2016-03-16T21:39:32Z

Sheilav:

* [[Cannot Close Period]]
* [[A/R Reconciliation Not in Balance]]
* [[Cannot Use A/P Payment Proposal]]
* [[Journal in Error]]
* [[G/L Balances do Not Roll Over]]
* [[Cash Book Not in Balance]]
* [[Cannot Close Cash Book]]
* [[Change Document Date]]
* [[Rounding Error in Goods Receiving File]]
* [[Unmatched Purchase Orders Not in Balance]]
* [[Problem With EFT Batch]]
* [[Cannot Add to Standing Order]]
* [[FIN03FPMG Does Not Balance to FIN03]]
* [[A/P Invoicing - Invoice Line Locked]]

Information Systems:ECU - Electronic Catalog Update

2016-03-16T20:30:37Z

Sheilav:

Information Systems:ECU - Electronic Catalog Update

2016-03-16T19:39:20Z

Sheilav:

Information Systems:Monitor Pick List Numbers

2016-03-16T19:32:26Z

Sheilav:

==Pick List Numbers - estimated to Wrap in 2018==

We started in 2005 with pick list number 5000000. In July 2013, we reached 8999999 and went back to 3000001. '''WE WILL HAVE A PROBLEM WHEN WE REACH 5000000 AGAIN.'''

Note - March 9, 2016 - picks list beginning with '5' were removed (using program PURGE05A). This gives another 2.5 to 3 years. March 16, 2016 - removed pick lists starting with '6' and '7'.

'''Note that we cannot use pick list numbers starting with '1' or '2'. Normally, a shipment number is pick list number appended with the three digit box number. For a special box label, the shipment number is partner number appended with the 'day' part of the Julian date, and 2 digit sequential number from file CVUSDAP (CVU -- Customer/Vendor User Data Items), element 'WAYBILL#'. These numbers must not duplicate.'''

Here are the pick list numbers, and count, for each year. The count has gone down over the last couple of years; we have used order minimums to make customers submit fewer but larger orders, and have encouraged shareholders to do the same thing.

year starting ending starting ending used
2005 5000306 5387235 386,390
2006 5387236 5803474 416,239
2007 5803475 6232140 428,666
2008 6232141 6710591 478,451
2009 6710592 7225729 515,138
2010 7225730 7739607 513,878
2011 7739608 8235828 496,221
2012 8235829 8754526 518,698
2013 8754527 8999999 3000001 3203810 449,283
2014 3203811 3568043 364,233
2015 3568044 3904094 336,051

The sales order detail file (SROORSPL) has pick list number on it, and has a logical file using it. Before pick list numbers wrap, we will have to start clearing this field. Note that just the field should be cleared; the record should be left in the file.

Custom files PLDETL, and UXSDOCP will have to be archived and purged.

The shipment archive file (ATLARCHP) wasn't created until 2010, but will have to be purged when pick list numbers approach 7550000 again.

I don't know what effect this will have on ASW, or what other files could be involved. (2016Feb) Protelo has looked into the changes IBS made in later versions to deal with this, and had identified three programs -

DMR330 Pick list confirmation
WMR910 Location confirmation - List (Pick/Rec)
WMR960 Create pick suggestion

I've found more without looking very hard -

DMR307 reads by pick list number to find the lowest unused line number.
MDR344 (modification) reads by pick list to find if price tickets will be needed for any items on the invoice
NCRUP001 selects items to include on narcotic control form
RFHR512 (modification) only selects form PLDETLP if first pick list line in sales order file is status 30
etc
etc

It's starting to seem like the only option is to purge old pick list numbers from the sales order line file...

In order to monitor the process, get the current invoice number (series 2) from the [[Table Maintenance Programs|Number Series Table]], and periodically add it to this document.

2015 Dec 16 3890843
2016 Mar 1 3957647 66804 used in 2.5 months. At this rate, 39 months left (May 2019).

===Purge Pick List Numbers===

Go to Unity / Start uniPharm Extensions / VA Company (Production) / Work with UWD IT Tools / Purge Pick List Numbers.

This will call command PURGEPICK, which will prompt for the leading digit of the range of numbers to be purged, then will call RPG program PURGE05A.

The files purged will be -

SROORSPL (sales order lines) - clear pick list number and line number
PLDETL (pick list into) - delete records
ATLARCHP (Atlas shipment archive) - delete records
UXSDOCP (documents) - delete records

Before purging, the records that will be deleted are added to files PLDETLPURG, ATLARCHPRG, and UXSDOCPURG. Records can therefore be added back to the original file if necessary.

Information Systems:ECU - Electronic Catalog Update

2016-03-16T19:01:49Z

Sheilav:

Information Systems:ECU - Electronic Catalog Update

2016-03-16T18:54:19Z

Sheilav:

Information Systems:Monitor Pick List Numbers

2016-03-16T16:40:32Z

Sheilav: /* Pick List Numbers - estimated to Wrap in 2018 */

==Pick List Numbers - estimated to Wrap in 2018==

We started in 2005 with pick list number 5000000. In July 2013, we reached 8999999 and went back to 3000001. '''WE WILL HAVE A PROBLEM WHEN WE REACH 5000000 AGAIN.'''

Note - March 9, 2016 - picks list beginning with '5' were removed (using program PURGE05A). This gives another 2.5 to 3 years. March 16, 2016 - removed pick lists starting with '6'.

'''Note that we cannot use pick list numbers starting with '1' or '2'. Normally, a shipment number is pick list number appended with the three digit box number. For a special box label, the shipment number is partner number appended with the 'day' part of the Julian date, and 2 digit sequential number from file CVUSDAP (CVU -- Customer/Vendor User Data Items), element 'WAYBILL#'. These numbers must not duplicate.'''

Here are the pick list numbers, and count, for each year. The count has gone down over the last couple of years; we have used order minimums to make customers submit fewer but larger orders, and have encouraged shareholders to do the same thing.

year starting ending starting ending used
2005 5000306 5387235 386,390
2006 5387236 5803474 416,239
2007 5803475 6232140 428,666
2008 6232141 6710591 478,451
2009 6710592 7225729 515,138
2010 7225730 7739607 513,878
2011 7739608 8235828 496,221
2012 8235829 8754526 518,698
2013 8754527 8999999 3000001 3203810 449,283
2014 3203811 3568043 364,233
2015 3568044 3904094 336,051

The sales order detail file (SROORSPL) has pick list number on it, and has a logical file using it. Before pick list numbers wrap, we will have to start clearing this field. Note that just the field should be cleared; the record should be left in the file.

Custom files PLDETL, and UXSDOCP will have to be archived and purged.

The shipment archive file (ATLARCHP) wasn't created until 2010, but will have to be purged when pick list numbers approach 7550000 again.

I don't know what effect this will have on ASW, or what other files could be involved. (2016Feb) Protelo has looked into the changes IBS made in later versions to deal with this, and had identified three programs -

DMR330 Pick list confirmation
WMR910 Location confirmation - List (Pick/Rec)
WMR960 Create pick suggestion

I've found more without looking very hard -

DMR307 reads by pick list number to find the lowest unused line number.
MDR344 (modification) reads by pick list to find if price tickets will be needed for any items on the invoice
NCRUP001 selects items to include on narcotic control form
RFHR512 (modification) only selects form PLDETLP if first pick list line in sales order file is status 30
etc
etc

It's starting to seem like the only option is to purge old pick list numbers from the sales order line file...

In order to monitor the process, get the current invoice number (series 2) from the [[Table Maintenance Programs|Number Series Table]], and periodically add it to this document.

2015 Dec 16 3890843
2016 Mar 1 3957647 66804 used in 2.5 months. At this rate, 39 months left (May 2019).

===Purge Pick List Numbers===

Go to Unity / Start uniPharm Extensions / VA Company (Production) / Work with UWD IT Tools / Purge Pick List Numbers.

This will call command PURGEPICK, which will prompt for the leading digit of the range of numbers to be purged, then will call RPG program PURGE05A.

The files purged will be -

SROORSPL (sales order lines) - clear pick list number and line number
PLDETL (pick list into) - delete records
ATLARCHP (Atlas shipment archive) - delete records
UXSDOCP (documents) - delete records

Before purging, the records that will be deleted are added to files PLDETLPURG, ATLARCHPRG, and UXSDOCPURG. Records can therefore be added back to the original file if necessary.

Information Systems:Monitor Pick List Numbers

2016-03-16T15:43:32Z

Sheilav: /* Purge Pick List Numbers */

==Pick List Numbers - estimated to Wrap in 2018==

We started in 2005 with pick list number 5000000. In July 2013, we reached 8999999 and went back to 3000001. '''WE WILL HAVE A PROBLEM WHEN WE REACH 5000000 AGAIN.'''

Note - March 9, 2016 - picks list beginning with '5' were removed (using program PURGE05A). This gives another 2.5 to 3 years.

'''Note that we cannot use pick list numbers starting with '1' or '2'. Normally, a shipment number is pick list number appended with the three digit box number. For a special box label, the shipment number is partner number appended with the 'day' part of the Julian date, and 2 digit sequential number from file CVUSDAP (CVU -- Customer/Vendor User Data Items), element 'WAYBILL#'. These numbers must not duplicate.'''

Here are the pick list numbers, and count, for each year. The count has gone down over the last couple of years; we have used order minimums to make customers submit fewer but larger orders, and have encouraged shareholders to do the same thing.

year starting ending starting ending used
2005 5000306 5387235 386,390
2006 5387236 5803474 416,239
2007 5803475 6232140 428,666
2008 6232141 6710591 478,451
2009 6710592 7225729 515,138
2010 7225730 7739607 513,878
2011 7739608 8235828 496,221
2012 8235829 8754526 518,698
2013 8754527 8999999 3000001 3203810 449,283
2014 3203811 3568043 364,233
2015 3568044 3904094 336,051

The sales order detail file (SROORSPL) has pick list number on it, and has a logical file using it. Before pick list numbers wrap, we will have to start clearing this field. Note that just the field should be cleared; the record should be left in the file.

Custom files PLDETL, and UXSDOCP will have to be archived and purged.

The shipment archive file (ATLARCHP) wasn't created until 2010, but will have to be purged when pick list numbers approach 7550000 again.

I don't know what effect this will have on ASW, or what other files could be involved. (2016Feb) Protelo has looked into the changes IBS made in later versions to deal with this, and had identified three programs -

DMR330 Pick list confirmation
WMR910 Location confirmation - List (Pick/Rec)
WMR960 Create pick suggestion

I've found more without looking very hard -

DMR307 reads by pick list number to find the lowest unused line number.
MDR344 (modification) reads by pick list to find if price tickets will be needed for any items on the invoice
NCRUP001 selects items to include on narcotic control form
RFHR512 (modification) only selects form PLDETLP if first pick list line in sales order file is status 30
etc
etc

It's starting to seem like the only option is to purge old pick list numbers from the sales order line file...

In order to monitor the process, get the current invoice number (series 2) from the [[Table Maintenance Programs|Number Series Table]], and periodically add it to this document.

2015 Dec 16 3890843
2016 Mar 1 3957647 66804 used in 2.5 months. At this rate, 39 months left (May 2019).

===Purge Pick List Numbers===

Go to Unity / Start uniPharm Extensions / VA Company (Production) / Work with UWD IT Tools / Purge Pick List Numbers.

This will call command PURGEPICK, which will prompt for the leading digit of the range of numbers to be purged, then will call RPG program PURGE05A.

The files purged will be -

SROORSPL (sales order lines) - clear pick list number and line number
PLDETL (pick list into) - delete records
ATLARCHP (Atlas shipment archive) - delete records
UXSDOCP (documents) - delete records

Before purging, the records that will be deleted are added to files PLDETLPURG, ATLARCHPRG, and UXSDOCPURG. Records can therefore be added back to the original file if necessary.

Information Systems:EODRPT

2016-03-16T00:25:09Z

Sheilav:

This generates reports. It is called by [[EOD]].

/* DIS and WHM Integrity Reports - WHOLOP not balanced to SROSRO. For */
/* both MAI and RET. */

/* log entry is 'INTEG RPTS' */

RTVASWPAR PGM(WMC251S) PAID(MAIINT) USER(*ALL)
EXCASWPGM PGM(WMC251S) PARM(N)
RTVASWPAR PGM(WMC251S) PAID(RETINT) USER(*ALL)
EXCASWPGM PGM(WMC251S) PARM(N)

/* Print onhand inventory at cost for both warehouses */

/* log entry is 'STOCK STAT' */

CHGJOB OUTQ(ELAHO)
RUNQRY QRY(STOCKST02A)

/* Print Lost Sales Report */

/* log entry is 'LOST SALES' */

LOSTSALES

/* Reset out of stock code (or short code) of 'A', 'B', or 'N' for items */
/* now back in stock. */

/* log entry is 'OOS CODES' */

CALL PGM(PLZUP050)

Information Systems:EODUPD

2016-03-16T00:22:38Z

Sheilav:

This does all the updating that requires all users to be off the system. It is called by EOD.

/* Generate bills to suppliers for COOP AND VEDI. This has to run first */
/* so that generated entries will be included in the updates. */

/* log entry is 'MISC BILL1' */

CXBILL03C
CALL PGM(CXBILL06)

/* Run ASW command to put the current date minus 1 (as this job is */
/* running after midnight) into the LDA (local data area) */

CHGASWLDA TYPE(*DATDZ) RELVAL(-1) STARTPOS(001)

/* Extract yesterday's date from the LDA and convert it to numeric */

RTVDTAARA DTAARA(*LDA (1 8)) RTNVAR(&DATEC)
CHGVAR VAR(&DATE) VALUE(&DATEC)

/* Call ASW program to get yesterday's fiscal period, and convert to */
/* character. */

GETPERIOD DATE(&DATE) PERIOD(&PERIOD)
CHGVAR VAR(&PERIODC) VALUE(&PERIOD)

/* Print invoice journal. This will be file DMR352P in WRKSPLF EDOJOB. */
/* There are saved parameters for this. Just change the date and period.*/

/* log entry is 'INV JOURN' */

RTVASWPAR PGM(DMC352) PAID(INVJOURNAL) USER(*ALL)
CHGASWLDA TYPE(*DATDZ) RELVAL(-1) STARTPOS(082)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(090) +
POSITIONS(6)
EXCASWPGM PGM(DMC352) PARM(N)

/* Send invoice journal to Catapult. This is run as a rule instead of */
/* being polled, as it goes into QPRINT. We don't want the poller to */
/* go through QPRINT; it's 2300 spool files now, but will just keep */
/* getting bigger. */

ADDLIBLE LIB(XL_CATAPLT)
ZRUNRULE FILE(DMR352P) JOB(*) SPLNBR(*LAST) +
RULENBR(10393) TIMEOUT(20)

/* Run nightly DIS to FIN. Again, there are saved parameters for this. */
/* Change the date and period. */

/* log entry is 'DIS TO FIN' */

RTVASWPAR PGM(GCFC751) PAID(DIS2FIN) USER(*ALL)
CHGASWLDA TYPE(*DATDZ) RELVAL(-1) STARTPOS(082)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(090) +
POSITIONS(6)
EXCASWPGM PGM(GCFC751) PARM(N)

/* Delete all generated spool file except for invoice register */

DLTSPLF FILE(GCFP752) SPLNBR(*LAST)
DLTSPLF FILE(FKR050P) SPLNBR(*LAST)
DLTSPLF FILE(FMR050P) SPLNBR(*LAST)
DLTSPLF FILE(FMR050P) SPLNBR(*LAST)
DLTSPLF FILE(FMR066P) SPLNBR(*LAST)
DLTSPLF FILE(FMR065P) SPLNBR(*LAST)
DLTSPLF FILE(FMR065P) SPLNBR(*LAST)
DLTSPLF FILE(FMR056P) SPLNBR(*LAST)

/* Clear intermediate purchase suggestions from yesterday. */

/* log entry is 'PURCH SUG' */

RTVASWPAR PGM(DIC801) PAID(CLRSUGPO) USER(*ALL)
CHGASWLDA TYPE(*DATDZ) STARTPOS(1)
EXCASWPGM PGM(DIC801) PARM(N)

/* Generate purchase suggestions. */

RTVASWPAR PGM(INVC431) PAID(PURSUG2MAI) USER(*ALL)
EXCASWPGM PGM(INVC431) PARM(N)

RTVASWPAR PGM(INVC431) PAID(PURSUG3MAI) USER(*ALL)
EXCASWPGM PGM(INVC431) PARM(N)

/* Keep copy of purchase suggestions as there are sometimes questions */
/* about whether something was generated here, or manually. */

CPYF FROMFILE(UP1480BFVA/SROPUH) +
TOFILE(UP1480BFVA/SROPUH.B1) MBROPT(*REPLACE)
CPYF FROMFILE(UP1480BFVA/SROPUL) +
TOFILE(UP1480BFVA/SROPUL.B1) MBROPT(*REPLACE)

/* Update ASW Item Cost With Effective VEBA From CCP */

/* log entry is 'ASW COST' */

CALL PGM(IXRUP880)

/* Note that we can operate if the following jobs are not run. There may */
/* be some 'unexpected results', but that will not stop us from receiving,*/
/* picking, and shipping orders. */

/* Rebuild the Time Axis File */

/* log entry is 'TIME AXIS' */

RTVASWPAR PGM(DMC951) PAID(TIMEAXIS) USER(*ALL)
CHGASWLDA VALUE(&PERIODC) TYPE(*CHAR) STARTPOS(007) +
POSITIONS(6)
EXCASWPGM PGM(DMC951) PARM(N)

/* Rebuild A/R Credit Time Axis */

/* log entry is 'AR CRD AX' */

RTVASWPAR PGM(GDMC195) PAID(ARAXIS) USER(*ALL)
EXCASWPGM PGM(GDMC195) PARM(N)

/* Rebuild A/R and A/P Totals */

/* log entry is 'AR AP TOT' */

RTVASWPAR PGM(FSC880) PAID(ARAPREBLD) USER(*ALL)
EXCASWPGM PGM(FSC880) PARM(N)

/* Calculate items that will have a 5% increase in cost or 5% decrease */
/* in gross margin %, and email buyer. */

/* log entry is 'HI CST/GM' */

CALL PGM(IXRIQ405)

/* Send any 'READY' promos to ECU */

/* log entry is 'PROMO2ECU' */

ECUPROMO

/* Adjust demand by items on promo. This is so that purchase */
/* suggestions for regular stocked items are not inflated by promo sales.*/

/* log entry is 'ADJ DEMAND' */

PXDEMAND

/* Use average purchase cost for warehouse MAI in SROSRO to update */
/* average purchase cost in SROSRO for RET, and average purchase cost */
/* in base item master file SROPRG. */
/* Do not share open data path, as SRBPRG may not be open for update. */

/* log entry is 'AVE COST' */

OVRDBF FILE(SRBPRG) TOFILE(SRBPRG) SHARE(*NO)
CALL PGM(AVGCST01)

/* Run miscellaneous billing - extract VEDI and COOP to be billed */

/* log entry is 'MISC BILL2' */

CALL PGM(CXBILL)

/* FTP Sales Orders with no invoiced lines. Normally, the FTP'ed */
/* invoice file includes cancelled order lines. This will send orders */
/* that haven't generated an invoice. */

/* log entry is 'FTP INV1' */

CALL PGM(INVCUP300)

/* For miscellaneous (VEDI & COOP) billing, settle invoice to transfers */

/* log entry is 'MISC BILL3' */

CALL PGM(CXBILL07)

/* Cancel any held POS orders that are four days old or more */

/* log entry is 'HELD POS' */

CALL PGM(IOPMIN04)

/* Delete item notes that have expired */

/* log entry is 'DEL NOTES' */

CALL PGM(DMRUP101)

/* Try to reorganize Carrier Interface File */

/* log entry is 'REORG CAR' */

RGZPFM FILE(ATLASPF)

Information Systems:Overnight Logging

2016-03-15T23:53:20Z

Sheilav:

The overnight jobs use our custom logging system. Withing a program, insert the command (with parameters to identify the processing step) -

LOGENTRY LEVEL1(OVERNIGHT) LEVEL2(EODDAILY) LEVEL3(START) +
BEGEND(B) FROMPG(EODDAILY) CLASS(LOG)

To see it, go to Unity / Start uniPharm Extensions / VA Company (Production) / Work with UWD IT Tools / Display Log.

3/03/16 08:47:01 uniPHARM -- PRODUCTION LGRIQ100/USFUNCTL
Logging Utilities - Show Entries CSU Release: 6.0
Display Order Limit to: Date Range Err
DAT Date (Descending) ___ __ __ ___ __ __
Level 1 Level 2 Level 3 Class Program Error Id B/E User
__________ __________ __________ _____ __________

Date Time B Program LEVEL 1 LEVEL 2 LEVEL 3 ERROR ID
MAR 3 16 1:00:00 B EODDAILY ENDOFDAY EODDAILY START
MAR 3 16 1:00:01 B EODDAILY ENDOFDAY EODEND2 CALLED
MAR 3 16 1:00:01 B EODEND2 ENDOFDAY EODEND2 START
MAR 3 16 1:07:04 B EODEND2 ENDOFDAY EODEND2 END
MAR 3 16 1:07:04 B EODDAILY ENDOFDAY EOD CALLED
MAR 3 16 1:07:04 B EOD ENDOFDAY EOD START
MAR 3 16 1:07:04 B EOD ENDOFDAY EODBUTEMP CALLED
MAR 3 16 1:07:04 B EODBUTEMP ENDOFDAY EODBUTEMP START
MAR 3 16 1:57:32 B EODBUTEMP ENDOFDAY EODBUTEMP END
MAR 3 16 1:57:33 B EOD ENDOFDAY EODUPD CALLED
MAR 3 16 1:57:33 B EODUPD ENDOFDAY EODUPD START

F3=Exit F5=Refresh F8=More F12=Previous F21=Scrn Reset
F24=Scrn Save

'''Program''' is the name of the program that wrote the log (with the LOGENTRY command).

'''Level 1''' is the 'user data' of the job log spool file (QPJOBLOG) where you can find more details. (They are all in WRKSPLF EODJOB. Note that they will be automatically deleted after ten days.)

'''Level 3''' is the action.

'''Level 2''' is the object of the action.

It would be best to have the ''''Display Order'''' set to DAT date (Descending). If it isn't, set it to that, clear all other selection fields, and press F24 (upper-F12) to save it.

You can use the ''''Date Range' selection''' to look at a particular day. Be aware that because we are looking at records in descending order, the from and to date range works a little unexpectedly. If you want to look at a particular day, for example March 2, 2016, you can do it in two ways -

Date Range or Date Range NOT Date Range
___ __ __ MAR 2 16 MAR 2 16 MAR 2 16 MAR 2 16 ___ __ __

The third way will not work, as log entries from the requested date to today will show; with today at the top of the list, and March 2nd at the end.

If you want further information on the meanings of the values in Program, Level1, Level 2, or Level 3, key a question mark into that selection field and press enter. Also, you can select one of these 'actions' from the list, and display it only. You will then be able to see how times are changing, and whether of not they are trending up.

Information Systems:OMS - Outbound Message System

2016-03-15T23:32:44Z

Sheilav:

Job OMSPOSTPRD, which is program OMSNEP01CL (OMS-Process Outbound Email Msgs), runs all day in subsystem OMSSUBPRD.

RPG program OMSNEP01 (OMS-Process The Outbound Email Msgs for OMS System)

- Calls the Domino agent to run OMSMAIL.NSF

Program OMSCRTFL (OMS-Create The IFS File For Domino Process)

File OMSQUEP (OMS-Outbound Message Queue File)

File OMSMHDP (OMS-Outbound Message Header File)

File OMSLINP (OMS-Outbound Message Lines File)

File OMSOUTP (OMS-Outbound Message Holding File)

Information Systems:CCP - Miscellaneous Billing

2016-03-15T23:23:58Z

Sheilav: /* CXBILL03 - Generate Bill */

In the 'contract' part of CCP (Customer/Contract Pricing), we can enter rebates from the vendor. COOP, which are co-op fees as the contract level, or VEDI, which are vendor debits at the item level.

Bills to the vendor or rep are generated automatically, based on the entered parameters.

==Co-op Fees==

These are entered at the contract level.

2/09/16 12:12:49 uniPHARM -- PRODUCTION CXRIU410/UPDATE
UPDATE UX - Enter/Update Contract Level Billing PRODUCTION 1.00

'''Contract #'''
BNA007BLIS BLISTEX JULY MEMO

'''Seq # Class Timing Billing Date'''
10 COOP LAST SALE Last day of the sale 00 00

'''For Cust/Vend/Broker'''
BROK 10102 BLISTEX/ZARINA CONFECTIONER

'''Method Bill Basis $/Funds % $ per Unit'''
APDED FIXEDAMT 250.00 CAD .000 .000

'''Cost Centre Project Acct Bypass'''
IFP 007 N

'''Added by User/Date Last Updated User/Dte Posted Date'''
SHELLYL JUN 12 14 SHELLYL JUN 12 14 JUL 31 14

==='''Timing''' determines when the bill is generated===

FIRST SALE First day of the sale uses sales start date on the contract header
LAST SALE Last day of the sale uses sales end date on the contract header
PO RECEIPT Receipt of the first PO looks for PO's with the contract number in the shipment mark
SPEC DATE On billing date specified uses the billing date on this record

==='''Bill Basis''' determines how to calculate the amount of the fee===

AMTPURCH % of Total amount purchased unbilled PO receipts with this contract # in shipment mark
AMTSOLD % of Total amount sold sales for all items on this contract, since last bill date
FIXEDAMT Fixed amount amount from this record
UNITPURCH $ per unit purchased unbilled PO receipts with this contract # in shipment mark
UNITSOLD $ per unit sold sales for all items on this contract, since last bill date

Notice the difference in the way purchase orders and sales orders are described, even though they both look for the contract or promo number in the shipment mark. The shipment mark on a sales order will always be populated when the store gets the special prices, but it is not unusual for us to get the special price on purchase orders ordered outside the order window. The buyer can then go in InfoNet and update the shipment mark. Which means these programs have to look at more than just the last billed date. File CXPORECP contains a record of every PO line that has had a bill generated. If a PO line has the correct shipment mark, but is not in this file, it will be billed, then added.

The three fields that follow - $, %, and $ per unit - give the rates used to calculate the billing amount.

$ used when the billing basis is fixed amount
% used when the billing basis is amount purchased or amount sold
$ per unit used when the billing basis is units purchased or units sold

==='''Method''' determines how the vendor or rep is to be billed===

APCRD A/P credit will apply a credit against the vendor's A/P account
APCS A/P car stock will get equivalent value in car stock
APDED A/P Deduction will be deducted from the invoice for goods received
ARCHQ A/R Cheque
REPRT Report only

This is defaulted from field 'User Defined Alpha Field 1' on file SROLMA (A/P supplier file).

===Cost Centre and Project===

These are used in conjunction with the entry in the ‘Misc Billing Item and G/L’ (UX BILLITEM) table to build the account to which the billing will be posted. The cost centre will normally be obtained from the first three characters of the contract code, and the project from the next three.

==='''For Cust/Vend/Broker''' indicates to whom the bill is to be sent===

This indicates to whom the sales order and A/R invoice will be sent. It is defaulted from field 'User Defined Alpha Field 5' on file SROLMA (A/P supplier file).

If the 'Method' begins with 'AP', the vendor will be charged in A/P; even if the A/R charge is to the broker.

==Vendor Debit==

These are entered at the item level.

2/09/16 12:32:54 uniPHARM --Volume test CXRIU330/UPDATE
UPDATE UX - Enter Contract Item Further Details VOLUME 1.00

'''Contract # Vendor # Broker #'''
SH-DL-0811 ZERO BARS 22547 22547

'''Item'''
R 00874529 ZERO BARS GOLD 50GM DARK

'''Seq # Type For Warehouse Timing $ or % UOM Margin %'''
22 VEDI VEND *ANY PO REC 1.930 CAD BX

'''Applies to Acct Effect EDL Zone Price List Rebates?'''
NET VEND APDED *ANY *ANY N

'''Bill on Date Send Bill to Billing Line Description Bill Backs?'''
00 00 10843 N

'''Added by User/Date Last Upd by User/Date Posted Date'''
NORMAM AUG 10 15 NORMAM AUG 10 15 AUG 16 15

==='''Timing''' determines when the bill is generated===

MONTHLY At end of each month on the first of the month
PO REC On receipt of PO receipt of this item with contract # in shipment mark, since last bill date
SALE At time of sale sale for this item with contract # in shipment mark, since last bill date
SLS END At end of sales period after sales end date on the contract header
SPEC DT On billing date specified bill on date from this record

==='''Timing''' also determines how the amount is calculated===

MONTHLY At end of each month unbilled receipts of this item with contract # in shipment mark
PO REC On receipt of PO unbilled receipts of this item with contract # in shipment mark
SALE At time of sale sales for this item with contract # in shipment mark, since last bill date
SLS END At end of sales period sales for this item with contract # in shipment mark
SPEC DT On billing date specified receipts of this item with contract # in shipment mark

Notice the difference in the way purchase orders and sales orders are described, even though they both look for the contract or promo number in the shipment mark. The shipment mark on a sales order will always be populated when the store gets the special prices, but it is not unusual for us to get the special price on purchase orders ordered outside the order window. The buyer can then go in InfoNet and update the shipment mark. Which means these programs have to look at more than just the last billed date. File CXPORECP contains a record of every PO line that has had a bill generated. If a PO line has the correct shipment mark, but is not in this file, it will be billed, then added.

==='''Applies to''' determines in which price calculation this is used===

Note - be very careful in the use of this field.

MEMO Memo not used in any price calculation
NET SALE Net Sales Price affects our selling price
NET VEND Net Vendor Price affects our purchase price
PRICE TICK Price Ticket affects suggested retail price

==='''Accounting Effect'''===

*NONE No Accounting Effect
APCRD A/P Credit transaction will be transferred from A/R to A/P
APDED A/P Deduction transaction will be transferred from A/R to A/P
ARCHQ A/R Cheque
PO PRICE Purchase Order Price
REDUCECOST Reduce cost and print report
REPORT Report on

==='''Send Bill to'''===

This is automatically filled in, but can be changed if necessary. If the ‘For’ (for use) field is BROK, the broker number from the contract will be used. If it is VEND, the vendor number will be. If these fields are blank, the main supplier from the item master file will be used.

==='''$ or %''' – How the Debit will be Calculated===

$ debit will be the dollar amount times the quantity received/sold, adjusted to the correct units of measure
% debit will be a percentage of the received/sold amount

==='''For Use''' – who will get the invoice===

VEND the vendor will be billed
BROK the broker will be billed

==Programs==

===CXBILL01 - Contract Header Level Billing (COOP Fees)===

Using the values entered in 'Contract Level Billing', a bill is calculated and added to file CXBITMP (CCP - miscellaneous billing item work file).

This will run every night as part of the end of day processing. It will read the file CXBILLP (CONTRACTS – Miscellaneous Billings Master) and search for records that have not yet been billed, and are not flagged to bypass accounting. The ‘timing’ field is used to determine whether or not this record should be billed. ‘Spec Date’ will use the ‘billing date’ from the billing record; ‘First Sale’ and ‘Last Sale’ will use the sales dates from the contract header; ‘PO Receipt’ will bill as soon as an item with this contract number as a shipment mark is received. (Note- as this will run after midnight, the dates to be billed are compared to yesterday’s date.)

The ‘bill basis’ field, and the three billing fields, are used to calculate the amount. ‘Amtpurch’ and ‘Unitpurch’ will read the purchase order file for received items with this contract number as a shipment mark. (Only purchase order types that update onhand stock will be included.) ‘Amtsold’ and ‘Unitsold’ will read the sales order file for invoiced items with this contract number as a shipment mark. (Only sales order types that affect demand will be included.)

===CXBILL02 - Contract Detail Level Billing (VEDI)===

Using the values entered in 'Contract Item Further Details', a bill is calculated and added to file CXBITMP (CCP - miscellaneous billing item work file).

This will run every night as part of the end of day processing. It will read the file CXITPRP (Contract Item Prices) and search for records that have not yet been billed, and that have an amount or percent (pricing records are added according to a template, whether or not they are going to be used). The ‘timing’ field is used to determine whether or not this record should be billed. ‘Spec Date’ will use the ‘billing date’ from the item details record; ‘Sls End’ will use the sales dates from the contract header; ‘PO Rec’ will bill as soon as this item with this contract number as a shipment mark is received. (Note- as this will run after midnight, the dates to be billed are compared to yesterday’s date.)

Depending on the ‘timing’ field, this item with this contract as shipment mark will be read from either the purchase order file for received items, or the sales order file for invoiced items. (Only purchase order types that update on hand stock, and sales order types that affect demand will be included.) All quantities are converted to the same unit of measure as the billing record.

The ‘timing’ field, and the '$ or %' field, are used to calculate the amount. ‘MONTHLY’ and ‘PO Rec’ will read the purchase order file for this item with this contract number as a shipment mark. (Only purchase order types that update onhand stock will be included.) ‘SALE’ and ‘SLS END’ will read the sales order file for invoiced items with this contract number as a shipment mark. (Only sales order types that affect demand will be included.)

===CXBILL03 - Generate Bill===

Note that a bill is only created if the total is greater than $10.

File CXBITMP (CCP - miscellaneous billing item work file) is read. One bill is created for each contract number / bill type (COOP or VEDI) / bill to vendor / charge to vendor / accounting effect. Each PO number and item number will build a separate line. (The 'bill to' vendor gets the A/R charge, and the 'charge to' vendor gets the A/P one.)

We have to show the item on the sales order (in the comments) for the vendor's information; but we must bill to a fictitious item. Table UX BILLITEM indicates the number to use.

Records are added to IOP files IOPHDRP (IOP - Order headers to be posted to ASW), IOPLINP (IOP - Order lines to be posted to ASW), IOPEXTP (IOP - Order line extension file).

IOPPOS00 (IOP -- Run all prechecks and post to ASW) is called to move generated orders from IOP into ASW's EDI files, then use base programs to process them.

The ‘method’ field indicates how the bill will be paid. All miscellaneous billing will start as an A/R invoice to the person or company in the ‘for’ and ‘cust/vend/broker’ fields. If method is ‘ARCHQ’, the bill will be left in A/R. For the other methods, ‘APCRD’, ‘APCS’, and ‘APDED’, the transaction will be automatically transferred from A/R to A/P by adding a reversal to file SROKBA (A/R batch input file, invoices) and adding to file SROLBA (A/P Batch input file, invoices) to the account of this contract’s vendor. For both, G/L transactions are added to file SROIBT (Interface accounting trans.from pre-system) to transfer amount from 120000 to 210000.

The 'type' of the generated transaction depends on the 'Method' or 'Accounting Effect'

ACR APCRD A/P Credit
ADU APDED A/P Deduction

This billing record in CXBITMP (CCP - miscellaneous billing item work file) will be set to billed. There can be two values; ‘Y’ meaning that it has been billed (no more changes can be made to this record), or ‘P’ meaning that it is partially billed. This is applicable when the timing is ‘PO RECEIPT’ and billing basis in anything other than ‘FIXEDAMT’. This would be used to bill either ‘AMTPURCH’ or UNITPURCH’ every time a purchase order is received.

GCFC851 (Interface accounting transfer) is then called to post to the ASW transaction files.

===CXBILL06 - Update Transaction Numbers in A/P and A/R to Match Invoice===

When CXBILL03 created the transfer from A/R to A/P, the original bill had not yet been invoiced. So the sales order number was used instead on invoice number. That makes it difficult to match all the transactions together. This program, which is run after the invoice has been generated, uses the sales order number to read the invoice header, and get the invoice number. When it updates this, it places an 'X' in the very right of the text field to indicate this has been done.

===CXBILL07 - AutoSettle A/R Invoice with Generated Transfer===

Reads unsettles ACR and ADU transactions from file SRODTA (A/R Transaction file). If an unsettled record with document type INV, the same document number, and the same but reversed amount is found, settle them against each other. Records are added to SROVPH (A/R Settlement path heading), SROVPX (A/R Settlement path index); and records in SRODTA (A/R Transaction file) are marked as settled.

==Process==

These programs cannot just run one after the other. CXBILL07 cannot run until after DIS to FIN has posted transactions for the day.

EODUPD CXBILL03
CXBILL06
DIS to FIN
CXBILL01
CXBILL02
CXBILL07

Based on the above information, a sales order (order type MC - Miscellaneous Billing Credit, or MI - Miscellaneous Billing Invoice) is created.

and added into IOP. IOP then moves it into the EDI files, and posts to ASW. Because both these order types are set up with direct invoicing, the invoices will automatically generated right away. The A/R transaction that is generated will be posted during the overn

==Generate Billing==

Every night, [[CXBILL03C]], [[CXBILL06]], [[CXBILL]], and [[CXBILL07]] are called from [[EODUPD]].

Information Systems:IMP - Inbound Message Parsing

2016-03-15T20:53:08Z

Sheilav:

Job IMPPOSTPRD, which is program IMPNEP01CL (IMP-Parse Inbound POP Email Msgs), runs all day in subsystem IMPSUBPRD.

RPG program IMPNEP01 does some validation of files IMSMHDP () and IMSLINP (), then calls IMPPAR01 () to extract order fields from the X12 format, and write IMPOHDP (IMP-Inbound Parsing Order Header File) and IMPLINP (IMP-Inbound Parsing Order Lines File).

IMPNEP01 uses file IMPXRFP (IMP-EOB To Customer Code X-Ref File) to try to determine the ASW partner number of the store submitting the order. See [[Electronic Sales Orders#History|History]] for an explanation of this file. Some stores have their ASW partner number as the EOB number in this file. Then in the beginning of 2016, we changed this program to check against SRONAM (Name file) if the number in the order is not in IMPXRFP.

In this example, the store has an EOB number of '504' (in the N1 segment).

3/15/16 13:18:28 uniPHARM -- PRODUCTION IMRIQ070/LISTCTL
IMS -- Show message lines PRODUCTION 1.00
Message #
598350 X12 PO
OWL@UNIPHARM.COM
66.183.181.88 Date Added Date Sent
MAR 15 16 13:16:54 MAR 15 16 13:15:08
IMP Order#
596264 1 2 3 4 5
0 0 0 0 0
6 ~REF*4A*1000

7 ~DTM*010*160315

8 ~N1*BS*OWL DRUGS*91*504

9 ~N2*KEN LEUNG*03921

10 ~N3*199 EAST HASTINGS ST*KEN LEUNG(03921)

F3=Exit F5=Refresh F7=Prev Message F8=Next Message F12=Previous

Information Systems:IMP - Inbound Message Parsing

2016-03-15T20:34:09Z

Sheilav:

Job IMPPOSTPRD, which is program IMPNEP01CL (IMP-Parse Inbound POP Email Msgs), runs all day in subsystem IMPSUBPRD.

RPG program IMPNEP01 does some validation of files IMSMHDP () and IMSLINP (), then calls IMPPAR01 () to extract order fields from the X12 format, and write IMPOHDP (IMP-Inbound Parsing Order Header File) and IMPLINP (IMP-Inbound Parsing Order Lines File).

IMPNEP01 uses file IMPXRFP (IMP-EOB To Customer Code X-Ref File) to try to determine the ASW partner number of the store submitting the order. [[Electronic Sales Orders#History|EOB]]

3/15/16 13:18:28 uniPHARM -- PRODUCTION IMRIQ070/LISTCTL
IMS -- Show message lines PRODUCTION 1.00
Message #
598350 X12 PO
OWL@UNIPHARM.COM
66.183.181.88 Date Added Date Sent
MAR 15 16 13:16:54 MAR 15 16 13:15:08
IMP Order#
596264 1 2 3 4 5
0 0 0 0 0
6 ~REF*4A*1000

7 ~DTM*010*160315

8 ~N1*BS*OWL DRUGS*91*504

9 ~N2*KEN LEUNG*03921

10 ~N3*199 EAST HASTINGS ST*KEN LEUNG(03921)

F3=Exit F5=Refresh F7=Prev Message F8=Next Message F12=Previous

Information Systems:Test or Development Environment

2016-03-14T17:53:24Z

Sheilav: /* Refresh Data */

==Test or Development Environment==

The production company in ASW is ‘VA’ for ‘Validation’. The test company is ‘PL’ for ‘Pilot’. Those names aren’t particularly apt descriptions, but that’s the way it worked out. The conversion programs were all tested in ‘validation’ – by the time they were all working as well as we could get them, and all the parameter files were just right, we didn’t want to start changing company codes and risk breaking things.

===Library List===

In order to test new programs or changes, we need an environment that is separate from production. That means duplicate copies of all data libraries, and program test libraries that are not in the production [[Library List|library list]].

The operating system used to allow only 25 libraries in the user portion of the list (it now allows 250). Because we are running an older version, the ASW program to build the library list is restricted to 25 user libraries. That is fine for production, but when the development libraries are added, we go over, so two libraries are omitted. It’s okay that UNIPHARMIT is missing, as it doesn’t usually affect test – if it does we will have to work around it. Because we cannot have WEBPRDP (production web programs) in the list, all production programs must also be in WEBDEVP.

'''Remember this. The usual process is to delete programs from the test libraries when they are moved to production. Except for programs in WEBDEVP - leave them!'''

The following compares the library lists for ‘production’ and ‘development’ (sometimes we call this ‘test’; ASW calls it ‘quality control’). Most of the libraries are used in both environments; they contain programs or objects that are not changed. Data libraries are never used by both environments; each uses its own separate set of data files. Programs being tested are in separate libraries that are never used by production. They are in the test library list before the production program libraries so that they are found first.

This is the system portion of the library list. It is a system value, and is the same for all users.

UWDQSYS prod dev uniPharm - Custom - System Objects
QSYS prod dev System Library
QSYS2 prod dev System Library for CPI's
QHLPSYS prod dev
QUSRSYS prod dev System Library for Users
QTEMP prod dev

Next is the ASW data file library; VA for validation (production), and PL for pilot (test).

UP1480BFVA prod ASW PRODUCTION DATA FILE LIBRARY
UP1480BFPL dev

The next library is message files, objects need to do 'ASW Compiles', etc; and is the same for both environments.

UP1480BS prod dev ASW system objects for environment UP14

These are some customized objects; for example menus.

XX1480BQ dev
XX1480BP prod dev ASW rel XX1:480B UWD Extensions (non AS objects)

These are modified ASW programs, and custom programs that use ASW files. 'Q' is quality control, and 'P' is production. As the production program library is in the list, only programs currently being tested need to be in XX2480BP.

XX2480BQ dev ASW rel XX2:480B quality control librar
XX2480BP prod dev ASW rel XX2:480B object library

This is a quality control library that we have not used.

UP1480BQ dev ASW rel UP1:480B quality control library

These are program libraries, so can be in both environments. Notice that each release of ASW has the modified programs in a separate library.

UP1480BP prod dev Aldon/CMS IBS/ASW450/UP1480B (PDN)
U480BP prod dev Aldon/CMS IBS/ASW450/U480B (PDN)
U480AP prod dev Aldon/CMS IBS/ASW450/U480A (PDN)
CVT454AP prod dev ASW rel A:454A Appl CVT object library
A454AP prod dev ASW rel A:454A object library
A453AP prod dev ASW rel A:453A object library
A452AP prod dev ASW rel A:452A object library
A450AP prod dev ASW rel A:450A object library
QGPL prod dev General Purpose Library

Each environment has its own version of these data libraries, for utilities, and for the extensions. RCSUTILPRD contains programs, but as it also contains data files, it cannot be used in test. All the programs, as well as the data files, have to be in RCSUTILVOL.

RCSUTILPRD prod RCS -- Utility Objects and Data -- Prod
RCSUTILVOL dev RCS -- Utility Objects and Data
UWDASWPRDD prod UWD -- Extensions - VA – Data
UWDASWVOLD dev UWD -- Extensions - PL – Data

These are programs for the extensions. As the production program library is in the list, only programs currently being tested need to be in quality control.

UWDASWQUAP dev UWD -- Extensions - Quality Ctl - Objec
UWDASWPRDP prod dev UWD -- Extensions - Production -- Objec

This is a program library, so can be used by both environments.

TLABARCODE prod dev T.L. Ashford & Associates Barcode400

Each environment has its own version of these data libraries that are used by Web Orders and InfoNet.

WEBPRDD prod Web -- Data – Production
WEBDEVD dev Web -- Data

These are programs for the Web Orders and InfoNet. As this older version of ASW will only put 25 entries in the library list, WEBPRDP cannot be included for test. Therefore all programs and objects must be included in WEBDEVP.

WEBDEVP dev Web -- Programs -- Development
WEBPRDP prod Web -- Programs -- Production

UWDUTILPRD contains programs, but as it also contains data files, it cannot be used in test. All the programs, as well as the data files, have to be in UWDUTILVOL.

UWDUTILPRD prod UWD -- Extensions -- Common Utilities –
UWDUTILVOL dev Volume Testing Utilities

As this older version of ASW will only put 25 entries in the library list, UNIPHARMIT cannot be included for test.

UNIPHARMIT prod UniPHARM IT Tools -- Includes Source

===Refresh Data===

Eventually the data in ‘PL’ either gets so far out of date or corrupted by testing, that we need to get a fresh copy from production. In order to copy the production data libraries from disk, all users would have to be off the system, and all applications would have to be ended (like when the overnight backups are being done). To get around this, we refresh ‘PL’ from the temporary back up tape. This is tape 999999 which is written to every night before the end of day processing is done, and which is never removed from the tape library.

Make sure the development data libraries are not being used. To do that, key in WRKOBJLCK OBJ(UP1480BFPL) OBJTYPE(*LIB) and press enter.

Work with Object Locks
System: BART
Object . . . . : UP1480BFPL Type . . . . . : *LIB
Library . . : QSYS ASP device . . : *SYSBAS

Type options, press Enter.
4=End job 5=Work with job 8=Work with job locks

Opt Job User Lock Status Scope Thread
_ AMTRDR_PLA ASW4OWN *SHRRD HELD *JOB
_ AMTRDR_PLT ASW4OWN *SHRRD HELD *JOB
_ AMTRDR_PLT ASW4OWN *SHRRD HELD *JOB
_ DPRQ1_PL ASW4OWN *SHRRD HELD *JOB
_ DPRQ2_PL ASW4OWN *SHRRD HELD *JOB
_ DPRQ3_PL ASW4OWN *SHRRD HELD *JOB
_ ORDFLOW_PL ASW4OWN *SHRRD HELD *JOB
_ WEBTEST QTMHHTTP *SHRRD HELD *JOB

F3=Exit F5=Refresh F12=Cancel

This library is being used by ASW direct jobs for PL (test), and by the test Web Server. These can all be cancelled; unless of course there is testing currently going on. I normally refresh the test libraries on Saturday, so don’t have this issue.

From an ASW command line, in the production environment, key in SBMJOB and press F4 to prompt.

Submit Job (SBMJOB)

Type choices, press Enter.

Command to run . . . . . . . . . CALL BLDTEST______________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________
_____________________________________________________________________________________

Job name . . . . . . . . . . . . *JOBD Name, *JOBD
Job description . . . . . . . . *USRPRF Name, *USRPRF
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job queue . . . . . . . . . . . QS36EVOKE Name, *JOBD
Library . . . . . . . . . . . Name, *LIBL, *CURLIB
Job priority (on JOBQ) . . . . . *JOBD 1-9, *JOBD
Output priority (on OUTQ) . . . *JOBD 1-9, *JOBD
Print device . . . . . . . . . . *CURRENT Name, *CURRENT, *USRPRF...

F3=Exit F4=Prompt F5=Refresh F10=Additional parameters F12=Cancel
F13=How to use this display F24=More keys

Key in ‘CALL BLDTEST’ and change the job queue ‘QS36EVOKE’ (this means that this program will not interfere with production jobs).

This must run in production not test, as the test libraries will be deleted. Also because the programs used are in the library UNIPHARMIT, which isn’t in the library list for development.

There may be errors while this is running; if there are locks on other libraries that are cleared. If so, repeat the WRKOBJLCK command on that library, end those jobs, then Retry.

===Testing Programs===

====FTP Sales Orders and/or FTP Invoicing====

This is not necessarily to test our programming, but to test that the store’s Point of Sale system is doing this correctly.

'''Setup to Receive Orders and Send Invoices Via FTP'''

There is more involved than this; the store has to be set up with access to the FTP server, and directories have to be build. But I don’t know how to do that.

Go to Unity / Start uniPHARM Extensions / PL Company (VOLUME Testing) / Work with UWD IT Tools / FTP Connections / Sales Orders FTP Configuration.

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : AIINTFR File . . . . : AIINTFP

Name: 12305
Description: Longevity
FTP Server: mail.unipharm.com
FTP User ID: ftporders
FTP Password: visionit525
FTP Directory: 12305R/orders
FTP Archive Directory: archive
M=Move D=Delete N=None: M
Transmission Source: FTP
Customer # Type: UWD
Ext 1: X12
Ext 2: ___
Ext 3: ___

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

‘Name’ and ‘Description’ are just used to make it easier for us to identify the store sending the order (the program gets the store number from within the order file itself). Make sure that all of the ‘FTP Directories’ in test are NOT used in production – otherwise real orders will be loaded into test instead of production! The three extension types are very important – they tell program AIRUP020 (Post incoming FTP orders into IOP) the file structure of the incoming order. Currently, we are only receiving X12 orders from Kroll (extension KRO); a new one has been added for miscellaneous X12 orders (extension X12).

'''Select option Invoice FTP Configuration.'''

WORK WITH DATA IN A FILE Mode . . . . : CHANGE
Format . . . . : INVFTPR File . . . . : INVFTPP

Partner: 12305
Order Source: __________
Description: LONGEVITY COMPOUNDING PHARMACY
FTP Server: ftp.unipharm.com
FTP User ID: ftporders
FTP Password: visionit525
FTP Directory: 12305R/invoices

F3=Exit F5=Refresh F6=Select format
F9=Insert F10=Entry F11=Change

Add this record.

'''Get Orders from FTP Server'''

Go to Unity / Start uniPHARM Extensions / PL Company (VOLUME Testing) / UWD Extensions / EDI – IMS, IMP, etc / FTP =-- FTP Order Retrieval.

3/10/15 13:06:13 AIP Orders Status AIRIU010/CTL
uniPHARM --Volume test

Monitor status: Not running
Last activity: 03/10/15 12:38:48 Poll interval: 60 minutes

_______ ___ <-- Order type - CAN/DAT/KRL

Date Time Type File Renamed Recs
3/10/15 12:38 PM KRO ftp0075391b.kro FTP0075392 1
3/10/15 12:34 PM Simplicity ftp0075390b.txt FTP0075391 0
3/10/15 12:07 PM Simplicity ftp0075388b.txt FTP0075390 0
3/04/15 11:37 AM Simplicity ftp0275385.txt FTP0075389 0
3/04/15 11:35 AM Simplicity ftp0175387.txt FTP0075388 0
3/04/15 11:28 AM Simplicity order030215030630.txt FTP0075387 0
3/04/15 11:28 AM Simplicity order030215015252.txt FTP0075386 0
3/02/15 11:09 AM Simplicity order022715113636.txt FTP0075385 0
1/16/15 7:04 PM KRO 1836377.kro FTP0075384 3
1/16/15 7:00 PM KRO 618124384.kro FTP0075383 1
1/16/15 5:50 PM KRO 618124383.kro FTP0075382

F3=Exit F5=Refresh F7=Start Monitor
F13=Config F14=Interfaces F15=AIP Messages F16=W/W Mon Job F12=Exit

This shows the status of the FTP interface (as this is test, it is ‘Not running’), and a list of the last sales orders received.

Press F7 to start the monitor, and process orders from configured folders on the FTP server. The status will change to ‘Running’. Keep pressing F5 to refresh, until the status is ‘Running – waiting for next poll’. Then press F8 to end, and F3 to exit.

Go to IOP -- ASW Order Posting Fns / IOP -- List of Order Headers. You should see the order you just loaded, and it should be at status 60 (posted to ASW).

Go into ASW (test company), and look at sales orders. This order should be at status 30 (dropped for picking).

'''Pick Order'''

Go to Unity / Start uniPHARM Extensions / PL Company (VOLUME Testing) / Warehouse Menu / Picking and shipping menu / Pick list Status.

3/10/15 15:56:49 uniPHARM --Volume test PLRIQ040/LISTCTL
PLZ - Pick List Status VOLUME 1.00
Display Order Field Test Value
MAIN By Priority, Sched Dte, S __________ ____ _________________
Limit to: AND __________ ____ _________________
Date Range AND __________ ____ _________________
CU MAR 10 15 12:01 AM MAR 10 15 3:56 PM
Carr Stat Zone Group Del Locn Order Handler Customer Whs Item #
___ __ __________ __________ _______ __________ ___________ ___ ________
DT=Details
SD=Shipping Documents S #
Carr Zone Group Del Locn Schedule Pr h Lin STAT DESC CUST DESC
DT ATL HHCMEZZ INTOWN MAR 10 15 1:32 PM 50 Y 1 NOT START LONGEVITY
* END *

F21=Srcn Reset
F3=Exit F5=Refresh F8=More Info F12=Previous F24=Srcn Save

Find the order (it is probably the only one that will show), and use option DT.

3/10/15 16:00:18 uniPHARM --Volume test PLRIU045/LISTCTL
PLZ - Pick List Details VOLUME 1.00

Pick List Batch Consol PL# Customer
3583672 12305 LONGEVITY COMPOUNDING PHARMACY
Warehouse Zone Group Order No
MAI HHCMEZZ 3254737 711 COLUMBIA ST
Del Locn Share? # Lines Invoice NEW WESTMINSTER
INTOWN Y 1 BC V3M 1B2
Order Date Cutoff
Priority Scheduled Carrier TUE MAR 10 2015 TUE 1:05 PM
01 ATL Atlas Courier Pickup Date Added
Scheduled Pickup Status 1:32 PM MAR 10 15 12:38 PM
MAR 10 15 1:32 PM NOT STARTED Atlas Courier
O/H P
Line Zone/Locn Qty UOM Item Desription Size Qty k
10 H1 F133 2 BX COLOPLAST 0509 N
**END**

F3=Exit
F5=Refresh F9=Show UPC F10=Show Item # F12=Previous

Change the priority to ‘01’, so that you can pick this order – or at least go through the motions.

Go into ASW. Change to test, by keying 88 enter, then PL enter, enter. You can tell that you are in the test company , because *PL/480B* is in the upper left corner of the display. Key in GO RFH and press enter. Select option 4 – Process R/F instructions.

Hnd.. SHEILAV Select RF activity USRD8001N
Res.. 99 SHEILAV
Whs MAI
_ Picking
_ Packing
_ PO reception
_ Receiving put away
_ Replenishment
_ Cycle count
_ Location move
_ Inventory transaction
_ Reprint RF documents
_ Get new zone group
_ Inventory movement
_ Shipping
F8=Select resource

Go into ‘Get new zone group’, and select the one for the pick list; in this case, HHCMEZZ.

Go into ‘Picking’, and press F6 to get the next pick list – which should be for this test order, as the priority is 01. Select it, and press enter.

RFHD8021N
Loc: H1 F133 PCK 50/BX
Ord 2.00 EA
Rem 2.00 EA
00336610 COLOPLAST 0509

-PAR/LIC PICK- H1-F133

Loc: H1 F133
Itm: 00336610
Qty: 2

Lic: 30000111

F9=Pick zero F10=Pick partial

You will have to key in the location, item number, and quantity – which is shown at the top of the screen, so just copy it. Then key in a number starting with ‘3’ for the license.

This will be repeated for every line on the order.

Hnd: SHEILAV
Whse: MAI
Func: Print box labels
-----------------------

Enter number of box
labels required:

1

Press Enter

Press enter. The following screens will be repeated for all documents printed for this pick list. Again, key in the number displayed at the top of the screen.

Hnd: SHEILAV
Whse: MAI HHCMEZZ
Func: Conf Box Labels
-----------------------
Box labels should
be on the printer at
the packing station.

The bar code will
read 3583672

Scan the bar code on
the label now:
3583672

Press Enter. F7=Reprint

Hnd: SHEILAV
Whse: MAI HHCMEZZ
Func: Confirm Invoice
-----------------------
Invoice 7758860 should
be on the printer at
the packing station.

Scan the bar code on
the invoice now:
7758860

Press Enter. F7=Reprint

Hnd: SHEILAV
Whse: MAI HHCMEZZ
Func: Conf Price Tkts
-----------------------
Price tickets should
be on the printer at
the packing station.

The bar code will
read 3583672

Scan the bar code on
the price ticket now:
3583672

Press Enter. F7=Reprint

Look on the FTP server; the invoice should be there.

Information Systems:TEMPORARY - things to add

2016-03-14T17:52:12Z

Sheilav: Created blank page

Category:Information Systems

2016-03-14T16:53:30Z

Sheilav: /* System i Documentation */

<strong>Welcome to the uniPHARM Information Systems Internal Wiki</strong>

Find access to documentation on just about everything related to I.T. at uniPHARM. Use the search bar for the best results.

=IBM i=
===System i Documentation===

UNITY ('''u'''niPharm’s '''n'''ew '''i'''nformation '''t'''echnolog'''y''') was the name of the project to completely replace the out dated and undependable technology used by uniPHARM, and to use technology to increase efficiency.

* [[TEMPORARY - things to add]]
* [[System i Operations]]
* [[ASW (Application Soft Ware) by IBS (International Business Systems)]]
* [[Extensions]]
* [[Custom]]
* [[Problems]]

* [[Alert Management]]
* [[Auditors]]
* [[B.C. PharmaCare]]
* [[Catapult]]
* [[Carrier Interface]]
* [[Cheque Master]]
* [[Definitions]]
* [[Disaster Recovery]]
* [[EDI]]
* [[FTP]]
* [[Health Canada]]
* [[MMBC - Multi Materials British Columbia]]
* [[Monitor for Problems]]
* [[Sales]]
* [[Sales Reporting to IMS]]
* [[Security]]
* [[Technical]]
* [[Utilities]]
* [[WebSmart|WebSmart - Browser Access to Data on System i]]

===Hardware and System Configuration===
* [[Printing]]
* [[RF communication]]
* [[HMC Management]]
* [[BRMS]]

===Administration===
* [[Periodic Tasks]]
* [[Logs]]
* [[System Issues History]]

=The ''Darwin'' Pages: Sys/Net Admin=
* [[Quick how-tos]]

===Hardware and Software Servers===
* [[IBM System x Servers]]
* [[Windows Server]]
* [[Microsoft Licensing]]
* [[Blackberry Enterprise Server (BES)]]
* [[Mail Server]]

===Backups and Power===
* [[Tapes]]
* [[Building Power]]
* [[Alarms and Monitoring]]

===Ordering===
* [[Web Orders]]
* [[POS Ordering]]
* [[Order confirmations]]
* [[Serv-U FTP]]

===Mobile Computers (RF Guns)===
* [[General]]
* [[Administration]]
* [[MobiControl]]

===Email===
* [[IBM/Lotus Notes and Domino]]
* [[M-Daemon Mail Server]]
* [[Barracuda Email Security Service]]
* [[Google Apps (Postini)]]
* [[Mail Server Framework (MSF)]]

===Network===
* [[WAN]]
* [[Sophos UTM]]
* [[DNS]]
* [[Intranet/LAN]]
* [[Wireless/WiFi]]

===Printers and Faxes===
* [[Xerox printers]]
* [[Lexmark printers]]
* [[Zebra Thermal printers]]
* [[Mobile belt printers]]

===Misc.===
* [[Guide to this wiki]]
* [[Document Management System - Gauss]]
* [[Digital Signage]]
* [[Pitney Bowes Mail Machine]]
* [[Toshiba Digital Phone System]]
* [[Moodle eLearning]]
* [[Techinline Remote Support]]
* [[GMP Recalls]]
* [[Blackberry]]
* [[Norwin's Christmas 2015 Page]]

=Research, Ideas, and Projects=
Items should be moved out of this section after they become implemented
* '''[[Project Timeline]]'''
* '''[[State of the Union]]'''
* [[Server Virtualization]]
* [[Secure WAMP stack for Moodle and MediaWiki]]
* [[IBM i Access for Mobile]]
* [[Networking projects]]
* [[Green screen modernization]]
* [[Catapult - extended functionality]]
* [[Web Filter optimization/implementation]]
* [[QSH and Python on IBM i]]
* [[BYOD]]
* [[Web Orders Features]]
* [[IBM Sametime]]